Миграция в виде матрёшки: как мы перевозили систему-монстра из одного города в другой

Переезд ИТ-инфраструктуры из одного дата-центра в другой — стандартная задача, с которой мы имеем дело постоянно. Но иногда особенности и условия проекта делают эту процедуру суперсложной. В этом посте расскажем о том, как наша команда однажды переселяла «тяжелую» бизнес-систему из одного ЦОД в другой, и почему эту миграцию на самом деле нужно умножить на десять.

Бизнес-система поддерживала работу с кадрами крупного предприятия. HR-cпециалисты пользовались ей каждый день. Для нас, айтишников, такая система — набор железа и софта, а для нескольких десятков тысяч сотрудников нашего заказчика — это вовремя выплаченная зарплата, оформленные отпуска, больничные, командировки и многое другое. Всего у информационной системы (ИС) было около 1000 пользователей. Требования к её доступности высокие, поэтому сопровождение ИС передали нашей компании. «Сервисмены» отвечают за работу всех сред: продуктива, препродуктива, разработки и тестирования.

Сопровождение началось ещё в первом ЦОД, из которого ИС должна была мигрировать в новый.

Переезд неизбежен

Система и оборудование под ней должны были переехать, скажем, из Вологды в Питер. Максимальное время простоя для прода было 8 часов, а среды разработки, тестирования и предпрода нам разрешили «задержать» на сутки. На новой площадке нужно было подготовить временное оборудование для запуска каждой из сред — ведь физически переместить оборудование и настроить его за такое короткое время невозможно. Часть временного железа предоставили мы из своего демофонда, часть — выделил заказчик.

Чтобы обеспечить необходимое время простоя для продуктивных систем, на временном оборудовании мы заранее развернули отказоустойчивые конфигурации, подготовили новые вычислительные машины и новые кластеры. Это решение в случае аппаратного сбоя переключает приложения на резервные узлы (в нашем случае все узлы кластера работали на платформе виртуализации VMware), и пользователи продолжают работать с минимальным простоем. К миграции всё было готово.

Интернетом? Самолетом!

И вот пробил час Х. Мы ждали канал связи, чтобы за ночь мигрировать терабайты данных. Это было логичное решение для такой задачи. Однако стыковка между вологодским и питерским провайдерами дата-центров не давала нужной скорости передачи данных. Провайдер, на чьей стороне обнаружилась проблема, обещал всё исправить, но время шло, а скорости в каналах связи не прибавлялось. И через месяц надежд стало понятно, что ждать больше уже нельзя.

Решили сначала мигрировать менее критичные подсистемы. В их число попали среды разработки и тестирования, на каждую из которых выделили выходные. Наш агент специалист прилетел в Вологду, откуда система переезжала, выключил её, скопировал на накопители, спрятал в чемоданчик и повёз в местный аэропорт. Ценный чемодан встретили в Питере с мигалками. А дальше диски были быстро доставлены в ЦОД, где данные скопировали.

После этого мы кропотливо меняли IP-адреса, наименования доменов и настроек ОС, чтобы перевезённые системы заработали. Этот первый этап миграции не самых критически важных компонентов имел свои плюсы — мы до мелочей разобрались в том, какие именно параметры в новом дата-центре не отвечают старым настройкам, и всесторонне подготовились к миграции продуктивной среды.

Когда канал связи был наконец готов, мы стартовали миграцию продуктивной среды. И её запуск благодаря доскональной проработке прошел и-де-аль-но.

Дополнительные «ИТ-пассажиры»

Вместе с основной ИС переезжали и другие сервисы: печать и средства аналитики. При этом внутреннюю интеграционную шину нужно было оставить в Вологде. Через шину шло практически всё взаимодействие компонентов ИС, и на перенос внутренней шины нам дали крайне жёсткие сроки. Усложнял процесс ещё один факт: продуктивная среда была реализована с помощью кластерного ПО. Во время миграции для управления серверами заказчика пришлось обновлять компоненты этого кластерного ПО для работы с новым софтом. Новую внутреннюю шину мы развернули в питерском ЦОД — тоже на временном оборудовании. А поскольку сервис был критичным, то для гарантии отказоустойчивости построили кластер.

Все построенные кластеры имели в своём составе четыре ноды (и приложения, и БД). Это даёт автоматический правильный запуск и остановку целиком системы, а не её отдельных компонентов.

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

Те, кто выполнял миграцию, на своем опыте знают: если что-то может пойти не так, это с большой долей вероятности случится. Чтобы создать себе дополнительный резерв по времени к «официальному» простою, мы назначили миграцию на день регламентных работ заказчика. В этот период компания готова к задержкам. У нас получилось уместить переезд продуктивной среды в целевые 8 часов, лишь немного «заехав» на временной резерв.

Перевоз оборудования

Итак, софт благополучно работал. Пришло время перевозить оборудование, на котором «крутилась» монструозная ИС и все сопутствующие ей системы. Когда все данные с дисков были удалены (чтобы не случилось утечек персональных данных), мы запаковали серверы, перевезли их на новую площадку и установили рядом с временными.

Здесь появилось одно «но». На перевоз и запуск комплекса технических средств на новой локации у нас были только одни выходные. Препродуктивный контур, запуск которого не планировался на временном оборудовании в Питере, был крайне нужен разработчикам. Поэтому данные с этого контура мы заранее скопировали в новый ЦОД и, после включения и настройки оборудования, первым делом подняли и настроили препродуктивный ландшафт. Все работы по демонтажу, доставке, монтажу, переустановке ESXi и настройке препрода прошли с пятницы по воскресенье.

Обратный процесс миграции с временного оборудования на «ПМЖ» тоже потребовал детальной проработки из-за кластерных решений MSCS с RDM-дисками в системе. Дополнительно, после миграции оборудования из Вологды в Питер, возникла задача переноса на него системы новой внутренней шины.

Кроме этого, заказчик на своем временном оборудовании внедрил внешнюю интеграционную шину, но у неё возникли проблемы с производительностью на временных серверах. И экстренно, за одну ночь, мы «переселили» её на «родные серверы». Это «оживило» шину и вернуло ей нормальную производительность.

Итоги

Итак, проект миграции ИС оказался суммой 10-ти отдельных миграций, 14-ти бессонных ночей, а также масштабных работ по подготовке оборудования и смене конфигураций. В целом в северную столицу переехали 18 серверов разной степени крутости, 3 мощных СХД и 2 SAN-коммутатора, которые теперь работают на новой площадке в более отказоустойчивых конфигурациях, чем ранее. А поскольку в процессе миграции мы, можно сказать, разобрали систему до винтиков, а потом собрали заново, то знаем мы её очень «близко». Это и хорошо, ведь на плечах наших сервисных инженеров — ответственность за сопровождение системы-монстра.

Антон Шипулин

Главный архитектор «Инфосистемы Джет»