Как мы перенесли в облако ИТ-инфраструктуру крупнейшей сети фастфуда

Тренд на использование облаков и облачных сервисов российскими компаниями становится все более заметным. Основные причины, на мой взгляд, – достаточный уровень зрелости российских облачных провайдеров, простота и скорость развертывания новых сервисов, нативные сервисы облака, удобство в оплате (OpEx вместо CapEx) и другие. 

Наш заказчик, крупнейшая сеть фастфуда в России, тоже принял решение о миграции в облако. Перед командой «ЛАНИТ-Интеграции» стояла амбициозная задача – примерно за полгода мигрировать всю ИТ-инфраструктуру заказчика в облако Mail.ru Cloud Solutions (MCS). Как мы решали эту задачу, с какими трудностями столкнулись в процессе, а также какие результаты получили, расскажу подробно в этой статье.

Технологические решения

Исходная ИТ-инфраструктура занимала суммарно семь стоек. Она включала в себя серверы, системы хранения данных, сетевое оборудование, телефонию. Система виртуализации заказчика была Microsoft Hyper-V с системой управления System Center Virtual Machine Manager (VMM). Всего в системе виртуализации было более 300 виртуальных машин, с общим количеством ресурсов:

• около 2000 vCPU;

• около 6 ТБ оперативной памяти;

• около 300 ТБ пространства на жестких дисках.

Перенос виртуальных машин

Первая задача, которую предстояло решить на пути к поставленной цели, – миграция виртуальных машин с системы виртуализации Hyper-V на целевую KVM + модифицированный OpenStack, на базе которых построено облако MCS. Есть несколько вариантов конвертации виртуальной машины из одной системы виртуализации в другую.

Первый вариант – использовать конвертеры дисков.  Есть бесплатная утилита qemu-img, которая позволяет решить задачу. В этом случае алгоритм миграции будет состоять из следующих этапов:

1. выключение виртуальной машины в ЦОДе;

2. конвертация диска виртуальной машины из vhdx в raw или qcow2 с помощью утилиты конвертации;

3. загрузка сконвертированного диска в облако;

4. создание виртуальной машины в облаке с использованием сконвертированного диска. 

Плюс этого варианта - можно использовать бесплатный конвертер.

Но есть и минусы.

• Потребуется большое время простоя сервиса, так как после первого этапа до четвертого виртуальная машина будет выключена. Если диск виртуальной машины достаточно большого размера (например, емкостью в несколько терабайт), то может потребоваться до нескольких суток, пока диск будет перекачиваться в облако. 

• Таким способом нельзя переконвертировать RDM-тома, а они у заказчика были. 

• Очень много ручной работы на каждом этапе.

Второй вариант – использовать специальные инструменты для миграции в облако. Для миграции в «заграничные» облака есть решения с говорящими именами – AWS Migration Services, Azure Migration Tools, Google Migration Services/Velostrata. Hystax Acura – фактически монополист в области миграции в российские облака.

Кратко опишем механизм работы Hystax Acura.

1. Установка агента на систему виртуализации (если это VMWare) или внутрь гостевых ОС (если это Hyper-v или другая система виртуализации или если есть диски RDM).

2. Запуск репликации ВМ, после чего в целевом облаке создается ВМ и настраиваются его параметры.

3. Создание снэпшота диска с помощью агента, который потом передается в облако. Если диск большого размера, то первая синхронизация может занимать довольно много времени.

4. За время, пока передается снэпшот, накапливается разница данных на диске с момента создания первого снэпшота. Создается второй снэпшот, который однозначно меньше всего размера диска – вряд ли диск меняет свое содержимое полностью даже за неделю-месяц, соответственно второй снэпшот будет передаваться быстрее. Таким же образом создаются последующие снэпшоты, передаются в облако и склеиваются, реплика диска в облаке практически догоняет состояние исходного диска в ЦОДе. 

5. Переключение ВМ, исходная ВМ в ЦОДе выключается и включается в облаке.

Плюсы данного варианта

• Минимизация времени простоя переносимых ВМ и вследствие времени простоя сервиса. Во время репликации данных в облако сама ВМ работает, downtime требуется только в момент переключения ВМ из локального ЦОДа на работу в облаке. Обычно такой downtime небольшой, занимает около 15-30 минут вместе с проверкой, что все запустилось корректно. 

• Hystax Acura также умеет переносить RDM-тома, если установить агента в операционную систему внутри ВМ. 

• Отличная поддержка со стороны вендора. Разработчик оперативно отвечал на все возникающие вопросы. 

Минусы

• Решение не бесплатное.

• Иногда после миграции ВМ не запускается, или диск ВМ отличается от исходного диска. Обычно таких ВМ немного – при данной миграции проблемы были с 6 ВМ, что составляет 2%. В такой ситуации мы выключали ВМ в облаке, включали в ЦОДе и проводили повторную миграцию.

Сетевая связность

Следующий вопрос – как обеспечить связность существующего ЦОД с облаком на период миграции и после него? Все ИТ-сервисы должны продолжать свою работу, пользователи должны сохранять возможность подключаться к корпоративным приложениям, взаимодействие между серверами должно быть сохранено. 

Мы рассматривали два варианта сетевого подключения локаций – на уровне L2 (канальный) и L3 (сетевой) модели OSI. 

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

Связность на уровне L3 сделать проще, и нет проблем с петлями широковещательного трафика, но при миграции придется менять IP-адресацию всех ВМ. Это может быть довольно трудозатратно в большой ИТ-инфраструктуре, которая много лет развивается, в которой работает много ИТ-команд, и потребуется проведение более тщательного аудита перед миграцией. Но даже после этого остаются риски отказа сервиса, так как существует кэш DNS, есть системы, в которых указаны непосредственно IP-адреса целевых серверов вместо их DNS-имен и т.д. 

Здесь универсального ответа нет, каждый проект требует взвешенного решения. Мы же выбрали вариант растянуть продуктивные L2-сегменты в облако с сохранением существующей сетевой логики – расположение шлюзов, маршрутизация, межсетевое экранирование не менялись. Дополнительной каплей в чашу весов в пользу L2 были планы по миграции в облако всей инфраструктуры в будущем, что позволило бы отказаться от растягивания подсети между ЦОД и облаком.

Для обеспечения физической связности сначала мы рассматривали L2-туннелирование Ethernet-трафика через IPSec VPN между существующим ЦОДом заказчика и облаком. Для этого провели пилотирование на виртуальных маршрутизаторах Cisco CSR, но поняли, что их производительности будет недостаточно для стабильной работы инфраструктуры как по пропускной способности, так и по вносимой задержке. Единственным решением оставалось прямое соединение ЦОДов заказчика и MCS через сервис L2VPN от провайдеров услуг – так и сделали. Теперь у заказчика есть отказоустойчивое высокоскоростное подключение существующего ЦОДа к облаку MCS на уровне L2 модели OSI.

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

Нюансы миграции отдельных серверов

При миграции серверов нас поджидали следующие особенности:

1. В любом облаке есть ограничения по количеству CPU и оперативной памяти. Они могут немного отличаться у разных облачных провайдеров и зависят от самых «жирных» гипервизоров, которые есть у провайдера. При этом у нас были серверы HPE Superdome с 96 ядрами и 6ТБ оперативной памяти – такой сервер не «влез» в облако, поэтому было принято решение оставить его на ко-локации.

2. После миграции важно не потерять производительность системы, а это в большой степени зависит от производительности дисков (процессоры и ОП обычно у всех примерно одинаковые). Как правило, у облачных провайдеров есть несколько типов хранения – HDD, SSD, локальные NVME SSD и так далее. При миграции важно оценить требования к производительности дисковой подсистемы для каждого сервера и выбирать правильные целевые расположения. Для размещения высоконагруженных систем оптимальным вариантом может стать выбор локальных SSD на гипервизорах и обеспечение отказоустойчивости на уровне приложения или информационной системы. 

3. Совместимость информационной системы/приложения с облаком. Часто встречается, что вендоры выпускают Virtual Appliance только под гипервизоры VMWare и Hyper-V, а под KVM не выпускают. У нас из таких систем была MDM-система Mobile Iron – версия, развернутая у заказчика, не имела дистрибутива под KVM, а новая версия Mobile Iron имела дистрибутив, совместимый только с ванильным OpenStack. Вопрос решили совместной работой вендора Mobile Iron, MCS и специалистов «ЛАНИТ-Интеграции». Есть и не такой успешный пример – система резервного копирования EMC NetWorker пока функционирует неполноценно, коллеги из MCS решают вопрос с совместимостью. 

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

Экономика и результаты

Обычно триггером для старта такого проекта является износ оборудования. Затем начинается оценка, что будет выгоднее – покупка нового оборудования/ПО или переезд в облако. В нашем проекте  заказчиком было принято решение не покупать новые серверы под виртуализацию, а перенести всю нагрузку в облако.

Экономика таких проектов, как правило, считается нелегко, но при желании это сделать можно. Если ТСО (Total Cost of Ownership - совокупная стоимость владения) в облаке плюс-минус понятен – количество необходимых ресурсов и их стоимость, например, на ближайшие 5 лет, то ТСО исходной локальной инфраструктуры может зависеть от огромного количества факторов – стоимости оборудования (серверов, СХД, шкафов, ИБП, сетевого оборудования и т.д.), стоимости сервисных контрактов на оборудование, стоимости ПО, обеспечивающего работу ИТ-инфраструктуры, стоимости помещения, стоимости электричества, зарплат обеспечивающего персонала и т.д. Это может быть усложнено еще тем, что ИТ-инфраструктура сильно разнесена территориально, имеется множество различных вариаций оборудования/ПО, множество команд, отвечающих за свои маленькие участки в большой ИТ-инфраструктуре и т.д. В таком случае я бы рекомендовал выделить небольшие проекты и считать их отдельно. 

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

1. инвентаризация оборудования и информационных систем,

2. оптимизация и обновление компонентов ИТ-инфраструктуры.

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

• Выявлено 67 устаревших ВМ, которыми уже никто не пользовался, – они были отключены и удалены.

• Исходная система терминального доступа состояла из двух ферм, суммарно более 40 ВМ. Наши специалисты проанализировали архитектуру ферм, существующую нагрузку и выявили, что выделенное количество ресурсов и архитектура ферм не оптимальны. В ходе миграции была развернута одна новая терминальная ферма в облаке, на которую перенесли всю исходную нагрузку, и количество потребляемых ресурсов сократили примерно вдвое.

• Специалисты по Power BI развернули новую систему отчетности сразу в облаке, тем самым совместив работы по обновлению системы и миграцию в облако.

• Была переработана архитектура хранения почтовой системы, чтобы соответствовать рекомендациям MCS по размерам дисков и для улучшения показателей RPO (Recovery Point Objective – допустимая потеря данных) и RTO (Recovery Time Objective – допустимое время восстановления данных) почтовой системы. Размер каждой почтовой базы был уменьшен за счет увеличения количества баз и распределения почтовых ящиков между ними.

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

В качестве заключения

Миграция в облако – непростой процесс, который требует тщательной подготовки и качественного исполнения. При правильном подходе можно избежать или минимизировать время простоя сервисов, тем самым сохранив эффективность компании. А штатные пользователи даже не заметят, что теперь работают в облаке. В итоге заказчик получает легко масштабируемую, удобную для администрирования и обслуживания ИТ-инфраструктуру.