Сейчас мы будем переносить физические и виртуальные серверы со всеми запущенными на них службами и прикладным ПО. Я считаю наиболее эффективным и незаметным для конечных пользователей вариант миграции, который проходит по принципу масштабирования в облачную инфраструктуру с последующим отказом от физического оборудования. Но это идеальный вариант, поэтому говорить будем о мгновенном или очень краткосрочном переезде. Простых способов «запороть» его — море, например, замена или апдейт компонента системы без предварительных тестов.
Каждый перенос инфраструктуры в «облако» — мероприятие индивидуальное. Рассматривать как выполнить перенос в каждом конкретном случае попросту нет смысла, речь про типичные ошибки, которые приводят к длительному полному или частичному простою ИТ-систем, служб и компонентов. Ошибки немного на уровне ликбеза, но я слишком часто вижу, как их совершают раз за разом.
Инвентаризация
Для начала еще перед принятием решения о миграции необходимо провести инвентаризацию инфраструктуры, чтобы четко понимать из каких компонент состоит ваша система и как они друг с другом связаны. Это поможет вам привести в порядок всю текущую документацию по инфраструктуре. А, возможно, в особо запущенных случаях — создать таковую. Но что важнее всего — сэкономить время при отладке неизбежных ошибок функционирования. Пропускаете инвентаризацию — готовьтесь к сорванным срокам и инцидентам со стороны службы поддержки.
Тестовый стенд
Предположим, решение о миграции по тем или иным причинам принято, а ряд потенциальных облачных провайдеров выбран. На данном этапе важно выделить время на то чтобы протестировать как облачного провайдера, так и частично отработать механизм переноса. Оценивайте всё, особенно обращая внимание на удобство и интуитивность интерфейса управления виртуальным датацентром, цены, адекватность и быстроту реакции службы поддержки, возможность миграции не только в конкретную облачную среду, но и возможностью миграции из неё (пути отступления тоже надо иметь), способы резервного копирования, а также сроки восстановления вашей инфраструктуры, которые предлагает и определяет для вас провайдер. Уделите внимание конкретным особенностям работы с каждым конкретным провайдером, например, способы создания клонов виртуальных серверов, дисков, способы увеличения производительности ваших виртуальных серверов (а вообще такое позволяют? Или придется каждый раз горизонтально масштабироваться?), не забудьте про работу с виртуальными сетями.
Если не тестировать, может сложиться ощущение, что всё можно перенести без сложностей. Часто это ощущение неверное, и масштаб «нарисовавшихся» сложностей может неприятно удивить.
Безопасность
Как минимум — надо уточнить возможность защиты от DDOS-атак, оценить пропускную способность каналов связи и наличие системы обнаружения вторжений. Для ряда заказчиков эти опции могут сильно сэкономить время и нервы. Подробнее про безопасность я и мои коллеги ещё будем рассказывать в корпоративном блоге, как, например, вот в этом чеклисте.
Хороший план
Последним шагом перед началом процесса переноса будет написание плана миграции, где должно быть описано, что в какой последовательности и в какой момент переносить. Рекомендация одна — план должен быть достаточно точный, чтобы отразить все шаги миграции, и особенности переноса конкретных, выявленных на этапе инвентаризации компонент. За иллюстрацией далеко ходить не надо — в крупной компании при организации миграции инфраструктуры, состоящей из отдельных зависимых друг от друга служб, переносить их было необходимо в несколько этапов в определенной последовательности. Отсутствующий четкий план действий стоил полутора недель дополнительных работ.
Правильное время
Конечно же, повторюсь, идеальный вариант — это масштабирование в виртуальную инфраструктуру, но если сделать это по каким-то причинам невозможно, лучшим будет вариант переноса слепков жестких дисков. Далее возможен перенос через резервное копирование физических систем с последующим восстановлением последних в виртуальном окружении, ну и наконец, если система позволяет – чистая установка на только что запущенные виртуальные сервера. Ответ на вопрос «Когда?» вполне очевиден — в моменты минимальной загрузки инфраструктуры. Инфраструктуру определяют конкретные службы, которые в ней запущены и функционируют, а значит, удобнее всего здесь иметь в виду так называемую «среднюю температуру по больнице», когда выбираются несколько наиболее критичных сервисов, анализируется информация по их загрузке и на основе этой информации выбирается конкретные временные интервалы миграции.
Процесс миграции
Не меняйте программные составляющие информационных систем в процессе миграции. Например, в относительно недалеком прошлом замена Apache на Nginx стала причиной четырех часов простоя одного посещаемого портала — не все rewrite-правила работали корректно даже после проведения тестовой миграции. Вообще, IMHO, если миграция выполняется не способом масштабирования ИТ-инфраструктуры или информационной системы в облачную среду, лучше всего ничего не менять до окончания процедуры. Данное утверждение спорно, т.к., безусловно, бывали миграции, когда обновление тех или иных компонент информационных систем помогало решить технические трудности. В конечном счете, последний выбор делает конкретный инженер со стороны заказчика, который взвешивает все «за» и «простив», основываясь на знании переносимой им системы или службы, а также сообщенных ему рисках.
Отдельным подпунктом можно выделить вопрос совместимости. Часто бывает, что не все операционные системы можно «запросто» перенести в облачную среду, например, в силу не поддерживаемости облачным провайдером схемы лицензирования компонентов вашего решения.
Надеюсь, это поможет чуть организованнее переносить инфраструктуру при срочных переездах. Если у вас были «грабли» во время переездов, поделитесь, пожалуйста, в комментариях.