Добрый день, коллеги

Планируем переезд ландшафта (несколько десятков систем) на новую платформу, при перезде планируется поменять имена северов.

Старый ландшафт архитектурно имел имя физического хоста (величина переменная) и на него были нахлобучены логические имена хостов (величина постоянная), это было довольно болезненно с точки зрения фаерволлов и интерфейы периодически сходили с ума, когда траффик начинал прибывать с незивестного хоста. Но, в общем-то, зная об этом - проблемы быстро решались. новая архитектура предполагает только логические имена, они же физические

Клиент ну очень хочет сохранить старые логические имена (очень сложно менять имена на многих уровнях и хотят что б юзеры ничего не заметили), на уровне конфигурации новыех серверов это невозможно, думаем насчет прописывания старого алиаса новым ИП адресам в client DNS

Понятно, что это чревато проблемами на уровне САПа, некоторым приложениям однозначно "заплохеет", ландшафт ну очень запутанный, и набор продуктов - ECC/BI/PI/BPC/EP/CRM/SRM etc
Я уже составила список того где это может "выстрелить", но скорее всего список неполный

Поделитесь своими соображениями!

Заранее спасибо

был опыт миграции продуктивов,
в том числе со сменой имен хостов,
IP адресов без изменения имени хоста
и еще много чего разного.

логично предположить точки общего Netweaver: SM59, SCOT, SPAD, SMLG, SMGW, SMICM, SM61

у меня встречный вопрос - системы поедут одновременно или постепенно?
как я понимаю, будет гетерогенная копия?

З.ы. с PI будет непросто.. кмк

да, я для этого же клиента делала предыдущую миграцию (гетерогенную) - но тогда смена хостов прошла нормально, если б не файрволлы и интерфейсы И юзеров был не так много. Как это делается - в общем ничего особенного, вроде известно. Волнует именно вариант с DNS - вот на какое имя хоста сертификат заказывать например? и все такое

Эта миграция гомогенная, системы едут по ландшафтам - DEV-TEST-QA-PROD

Думаю, у портала крышу однозначно сорвет - уже проходили, юзеры захотели бизнес-URL - поиметь, так пришлось делать URL substitution, а потом ече вылезало в разныех местах

просто непонятно что легче/дешевле провернуть, времени маловато

Alena__
както у вас там совсем все - по взрослому...
не в облака, часом, съезжаете?

в качестве совета, чтоб не попасться в ту же яму:
мой вопрос про очереднесть миграции, не праздный...
на одной из миграций имел удовольствие поменяться IP адрес ERP системы, при условии что на PI и иных смежных системах процессы только приостанавливались
так вот при смене данных в DNS, смежные системы встали в ступор при обращении к мигрируемой системе, до тех пор, пока в SMGW не были сброшены буфера имен хостов.
хотя, вероятно, Вы это и знаете


на досуге поразмыслю над Вашим вопросом.. вечером в пятницу уже голова отказывается думать

да нет, в общем обычная миграция, и, к сожалению, не в облака. но как обычно с закидонами - архитекторов много на квадратный мегабайт

спасибо за наводку про буфер, полезно. И за обещание подумать

собстно особо смертельных проблем так и не придумалось...
если делать дополнительный dns для старых имен хостов, то должно все получиться...
а вот с сертификатами действительно может быть засада... насколько я помню, сап внятно осознает сертификаты, выданные на имя хоста, которое он получается из команды hostname, т.е. реальное имя, возвращаемое reverse dns (либо /etc/hosts)

хотя...если всем юзерам в домене импортировать сертификат *.domainname, то чисто теоретически должно отрабатывать подключение и по старым именам хостов. но это так....теоретизируя

Ну что могу сказать - по результатам тестирования финальной миграции со старым алиасом в ДНС крыша действительно сьехала только:
- у сертификатов завязанных на имя хоста
- немного у веб диспатчера, он себя не узнал:)
- еще проксик во внешний мир не опознал нового хоста по старому имени, но это его туда просто забыли добавить
- порталу тоже заплохело - некоторые коннекторы были завязаны на имя хоста, и он искал старый хост - но не находил почему-то. портал фактически пришлось заново переставлять, но это не только из-за имени хоста

Вся бодяга со старыми именами хоста затевалась чтобы не менять saplogon.ini для юзеров - цель была в конечном итоге достигнута, но не на 100%
Ну и после обновления ДНС юзеры не могли подконнектиться к некоторым системам еще 2 дня - синхронизация ДНС так долго шла

так как все это было найдено во время тестобого проката - на продуктивную миграцию повлиять не должно, все запротоколировано

есть ещё одна очень серьёзная проблема, чтобы менять имена хостов


вы там поаккуратнее! а то и так с климатом не всё в порядке... а тут ещё и переполюсовка...
прямо таки запланированный апокалипсис...

вот до чего же скучно я живу...

З.ы. хотя...если проект с ERP HANA таки начнется в активной фазе, то даже чихнуть времени не будет

еще апдейт после начала эксплуатации - затевая описанное выше с ДНС надо не забыть про такие мелочи если где есть IP-based rules

юзеры заметили что им в САП письма извне не приходят, а казалось бы - должны, ведь ДНС поправлен, все резолвится на новый IP
оказалось - на exchange сервере правила пересылки настроены по IP, в итоге несколько сотен писем ушло в никуда, что создало очень серьезную проблему в SRM

Алена, а что мешает использовать централизованное серверное хранение файла конфигурации клиента? В этом случае файл корректируется один раз и все юзеры утром довольны и ничего не подозревають! :о)

безопасность имхо

я не вдавалась особо в основы сапгуивождения этого клиента, но процесс смены имени хоста - вынос мозга. Фаилы на серверах хранятся, в нескольких местах и как-то хитро синхронизируются с файлами у пользователей, которых несколько тысяч. поменять одну строчку - процесс занимает месяц наверное и нужно собрать сотню подписей

по мне так - причина так себе, но против ПМа не попрешь:)