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

Три года назад я был уверен, что перенос виртуальных машин на другую платформу делается за выходные. Выгрузил образ, загрузил в новое место, включил. Наш отдел тогда обслуживал около двухсот серверов: бухгалтерия, почта, документооборот, пара старых самописных систем, о которых знал только один человек, да и тот давно уволился. Когда пришло время уходить с VMware, я спокойно пообещал руководству управиться за месяц.

Управились за пять. И это ещё считалось неплохим результатом среди коллег, с которыми я потом обменивался опытом на отраслевых встречах. Ниже то, что я очень хотел бы знать заранее.

Почему переезд нельзя сделать простым копированием

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

Вторая сложность в том, что сервер редко живёт сам по себе. Почта общается с каталогом пользователей, база данных с приложением, приложение с файловым хранилищем. Перенесли половину связки, а вторая осталась на старом месте, и начинаются чудеса с задержками и обрывами связи.

Чаще всего проблемы вылезают вот где:

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

Как выглядит переезд, который проходит спокойно

Главное, что я понял: переезд начинается не с копирования, а с описи. Мы сели и честно составили карту всего, что работает. Какие машины, кто ими пользуется, от чего они зависят, сколько часов простоя переживёт каждая. Выяснилось, что треть серверов можно спокойно выключить на ночь, а четыре системы не выдерживают даже пятнадцати минут остановки.

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

Порядок действий, который в итоге сработал у нас:

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

Отказоустойчивость: вопрос, который всплывает сам собой

Пока мы переносили серверы, обнаружилась неприятная вещь. Резервные копии у нас были, а вот понимания, сколько времени займёт восстановление после серьёзной аварии, не было ни у кого. Резервная копия отвечает на вопрос, потеряем ли мы данные. На вопрос, сколько часов компания будет стоять, она не отвечает.

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

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

Что я посоветовал бы тем, кто только собирается

Не верьте обещаниям «перенесём за выходные», включая свои собственные. Заложите время на опись и пробный перенос, это половина успеха. Договоритесь с руководителями подразделений о допустимом простое для каждой системы заранее, а не в ночь переключения. И проверяйте не только то, что машина запустилась, а то, что люди реально могут работать: войти в систему, открыть документ, отправить письмо.

Наш переезд давно позади. Старая платформа выключена, резервный зал раз в квартал проверяется учебной аварией. А на любой вопрос «сколько займёт миграция» я теперь отвечаю встречным: «А вы знаете, сколько у вас серверов и кто от кого зависит?» Обычно после этого разговор становится гораздо честнее.