Как мы перенесли в облако ИТ-инфраструктуру крупнейшей сети фастфуда
Тренд на использование облаков и облачных сервисов российскими компаниями становится все более заметным. Основные причины, на мой взгляд, — достаточный уровень зрелости российских облачных провайдеров, простота и скорость развертывания новых сервисов, нативные сервисы облака, удобство в оплате (OpEx вместо CapEx) и другие.
Наш заказчик, крупнейшая сеть фастфуда в России, тоже принял решение о миграции в облако. Перед командой «ЛАНИТ-Интеграции» стояла амбициозная задача — примерно за полгода мигрировать всю ИТ-инфраструктуру заказчика в облако Mail.ru Cloud Solutions (MCS). Как мы решали эту задачу, с какими трудностями столкнулись в процессе, а также какие результаты получили, расскажу подробно в этой статье.
Технологические решения
Исходная ИТ-инфраструктура занимала суммарно семь стоек. Она включала в себя серверы, системы хранения данных, сетевое оборудование, телефонию. Система виртуализации заказчика была Microsoft Hyper-V с системой управления System Center Virtual Machine Manager (VMM). Всего в системе виртуализации было более 300 виртуальных машин, с общим количеством ресурсов:
Источник https://pbs.twimg.com/media/EPbxlaEXsAAFiZe.jpg: large
Перенос виртуальных машин
Первая задача, которую предстояло решить на пути к поставленной цели, — миграция виртуальных машин с системы виртуализации Hyper-V на целевую KVM + модифицированный OpenStack, на базе которых построено облако MCS. Есть несколько вариантов конвертации виртуальной машины из одной системы виртуализации в другую.
Первый вариант — использовать конвертеры дисков. Есть бесплатная утилита qemu-img, которая позволяет решить задачу. В этом случае алгоритм миграции будет состоять из следующих этапов:
выключение виртуальной машины в ЦОДе;
конвертация диска виртуальной машины из vhdx в raw или qcow2 с помощью утилиты конвертации;
загрузка сконвертированного диска в облако;
создание виртуальной машины в облаке с использованием сконвертированного диска.
Плюс этого варианта — можно использовать бесплатный конвертер.
Но есть и минусы.
Потребуется большое время простоя сервиса, так как после первого этапа до четвертого виртуальная машина будет выключена. Если диск виртуальной машины достаточно большого размера (например, емкостью в несколько терабайт), то может потребоваться до нескольких суток, пока диск будет перекачиваться в облако.
Таким способом нельзя переконвертировать RDM-тома, а они у заказчика были.
Очень много ручной работы на каждом этапе.
Второй вариант — использовать специальные инструменты для миграции в облако. Для миграции в «заграничные» облака есть решения с говорящими именами — AWS Migration Services, Azure Migration Tools, Google Migration Services/Velostrata. Hystax Acura — фактически монополист в области миграции в российские облака.
Кратко опишем механизм работы Hystax Acura.
Установка агента на систему виртуализации (если это VMWare) или внутрь гостевых ОС (если это Hyper-v или другая система виртуализации или если есть диски RDM).
Запуск репликации ВМ, после чего в целевом облаке создается ВМ и настраиваются его параметры.
Создание снэпшота диска с помощью агента, который потом передается в облако. Если диск большого размера, то первая синхронизация может занимать довольно много времени.
За время, пока передается снэпшот, накапливается разница данных на диске с момента создания первого снэпшота. Создается второй снэпшот, который однозначно меньше всего размера диска — вряд ли диск меняет свое содержимое полностью даже за неделю-месяц, соответственно второй снэпшот будет передаваться быстрее. Таким же образом создаются последующие снэпшоты, передаются в облако и склеиваются, реплика диска в облаке практически догоняет состояние исходного диска в ЦОДе.
Переключение ВМ, исходная ВМ в ЦОДе выключается и включается в облаке.
Плюсы данного варианта
Минимизация времени простоя переносимых ВМ и вследствие времени простоя сервиса. Во время репликации данных в облако сама ВМ работает, downtime требуется только в момент переключения ВМ из локального ЦОДа на работу в облаке. Обычно такой downtime небольшой, занимает около 15–30 минут вместе с проверкой, что все запустилось корректно.
Hystax Acura также умеет переносить RDM-тома, если установить агента в операционную систему внутри ВМ.
Отличная поддержка со стороны вендора. Разработчик оперативно отвечал на все возникающие вопросы.
Минусы
Решение не бесплатное.
Иногда после миграции ВМ не запускается, или диск ВМ отличается от исходного диска. Обычно таких ВМ немного — при данной миграции проблемы были с 6 ВМ, что составляет 2%. В такой ситуации мы выключали ВМ в облаке, включали в ЦОДе и проводили повторную миграцию.
Сетевая связность
Следующий вопрос — как обеспечить связность существующего ЦОД с облаком на период миграции и после него? Все ИТ-сервисы должны продолжать свою работу, пользователи должны сохранять возможность подключаться к корпоративным приложениям, взаимодействие между серверами должно быть сохранено.
Источник https://hsto.org/webt/u2/va/ke/u2vakeurncfmhe3cfitnzpfwa8o.jpeg
Мы рассматривали два варианта сетевого подключения локаций — на уровне L2 (канальный) и L3 (сетевой) модели OSI.
Если сделать связность сетей на уровне L2, то можно оставить существующие IP-адресы виртуальных машин, что значительно упрощает процесс миграции, но тогда придется решать задачу отказоустойчивости подключения и избегания петель широковещательного трафика.
Связность на уровне L3 сделать проще, и нет проблем с петлями широковещательного трафика, но при миграции придется менять IP-адресацию всех ВМ. Это может быть довольно трудозатратно в большой ИТ-инфраструктуре, которая много лет развивается, в которой работает много ИТ-команд, и потребуется проведение более тщательного аудита перед миграцией. Но даже после этого остаются риски отказа сервиса, так как существует кэш DNS, есть системы, в которых указаны непосредственно IP-адреса целевых серверов вместо их DNS-имен и т.д.
Здесь универсального ответа нет, каждый проект требует взвешенного решения. Мы же выбрали вариант растянуть продуктивные L2-сегменты в облако с сохранением существующей сетевой логики — расположение шлюзов, маршрутизация, межсетевое экранирование не менялись. Дополнительной каплей в чашу весов в пользу L2 были планы по миграции в облако всей инфраструктуры в будущем, что позволило бы отказаться от растягивания подсети между ЦОД и облаком.
Для обеспечения физической связности сначала мы рассматривали L2-туннелирование Ethernet-трафика через IPSec VPN между существующим ЦОДом заказчика и облаком. Для этого провели пилотирование на виртуальных маршрутизаторах Cisco CSR, но поняли, что их производительности будет недостаточно для стабильной работы инфраструктуры как по пропускной способности, так и по вносимой задержке. Единственным решением оставалось прямое соединение ЦОДов заказчика и MCS через сервис L2VPN от провайдеров услуг — так и сделали. Теперь у заказчика есть отказоустойчивое высокоскоростное подключение существующего ЦОДа к облаку MCS на уровне L2 модели OSI.
Отлично. Мы определились, как будем переносить серверы и как сохраним сетевую связность между ЦОД и облаком. Далее можно перейти к детальному плану по миграции каждого сервера.
Нюансы миграции отдельных серверов
При миграции серверов нас поджидали следующие особенности:
В любом облаке есть ограничения по количеству CPU и оперативной памяти. Они могут немного отличаться у разных облачных провайдеров и зависят от самых «жирных» гипервизоров, которые есть у провайдера. При этом у нас были серверы HPE Superdome с 96 ядрами и 6ТБ оперативной памяти — такой сервер не «влез» в облако, поэтому было принято решение оставить его на ко-локации.
После миграции важно не потерять производительность системы, а это в большой степени зависит от производительности дисков (процессоры и ОП обычно у всех примерно одинаковые). Как правило, у облачных провайдеров есть несколько типов хранения — HDD, SSD, локальные NVME SSD и так далее. При миграции важно оценить требования к производительности дисковой подсистемы для каждого сервера и выбирать правильные целевые расположения. Для размещения высоконагруженных систем оптимальным вариантом может стать выбор локальных SSD на гипервизорах и обеспечение отказоустойчивости на уровне приложения или информационной системы.
Совместимость информационной системы/приложения с облаком. Часто встречается, что вендоры выпускают Virtual Appliance только под гипервизоры VMWare и Hyper-V, а под KVM не выпускают. У нас из таких систем была MDM-система Mobile Iron — версия, развернутая у заказчика, не имела дистрибутива под KVM, а новая версия Mobile Iron имела дистрибутив, совместимый только с ванильным OpenStack. Вопрос решили совместной работой вендора Mobile Iron, MCS и специалистов «ЛАНИТ-Интеграции». Есть и не такой успешный пример — система резервного копирования EMC NetWorker пока функционирует неполноценно, коллеги из MCS решают вопрос с совместимостью.
Вопросов при миграции в облако, конечно же, множество, но я хотел осветить те, с которыми столкнется большинство. Отдельной статьи заслуживают вопросы по информационной безопасности и обеспечению соответствия информационных систем ФЗ-152, поэтому я их в данной статье не описываю.
Источник https://d28nd3of37804l.cloudfront.net/wp-content/uploads/2020/08/24.08.2020.jpg
Экономика и результаты
Обычно триггером для старта такого проекта является износ оборудования. Затем начинается оценка, что будет выгоднее — покупка нового оборудования/ПО или переезд в облако. В нашем проекте заказчиком было принято решение не покупать новые серверы под виртуализацию, а перенести всю нагрузку в облако.
Экономика таких проектов, как правило, считается нелегко, но при желании это сделать можно. Если ТСО (Total Cost of Ownership — совокупная стоимость владения) в облаке плюс-минус понятен — количество необходимых ресурсов и их стоимость, например, на ближайшие 5 лет, то ТСО исходной локальной инфраструктуры может зависеть от огромного количества факторов — стоимости оборудования (серверов, СХД, шкафов, ИБП, сетевого оборудования и т.д.), стоимости сервисных контрактов на оборудование, стоимости ПО, обеспечивающего работу ИТ-инфраструктуры, стоимости помещения, стоимости электричества, зарплат обеспечивающего персонала и т.д. Это может быть усложнено еще тем, что ИТ-инфраструктура сильно разнесена территориально, имеется множество различных вариаций оборудования/ПО, множество команд, отвечающих за свои маленькие участки в большой ИТ-инфраструктуре и т.д. В таком случае я бы рекомендовал выделить небольшие проекты и считать их отдельно.
Правильный подход при миграции в облако, помимо основной задачи переноса информационных систем, может еще нести следующие побочные ценности. Это:
инвентаризация оборудования и информационных систем,
оптимизация и обновление компонентов ИТ-инфраструктуры.
Достигается это благодаря подробному аудиту всей ИТ-инфраструктуры — как минимум, необходимо произвести инвентаризацию всего оборудования и виртуальных машин, найти ответственных за каждую систему, чтобы в дальнейшем составить подробный план работ с окнами на миграцию каждой системы. Как максимум, можно воспользоваться ситуацией и оптимизировать или обновить сервисы, внедрить новые решения. Например, мы выполнили несколько оптимизаций.
Выявлено 67 устаревших ВМ, которыми уже никто не пользовался, — они были отключены и удалены.
Исходная система терминального доступа состояла из двух ферм, суммарно более 40 ВМ. Наши специалисты проанализировали архитектуру ферм, существующую нагрузку и выявили, что выделенное количество ресурсов и архитектура ферм не оптимальны. В ходе миграции была развернута одна новая терминальная ферма в облаке, на которую перенесли всю исходную нагрузку, и количество потребляемых ресурсов сократили примерно вдвое.
Специалисты по Power BI развернули новую систему отчетности сразу в облаке, тем самым совместив работы по обновлению системы и миграцию в облако.
Была переработана архитектура хранения почтовой системы, чтобы соответствовать рекомендациям MCS по размерам дисков и для улучшения показателей RPO (Recovery Point Objective — допустимая потеря данных) и RTO (Recovery Time Objective — допустимое время восстановления данных) почтовой системы. Размер каждой почтовой базы был уменьшен за счет увеличения количества баз и распределения почтовых ящиков между ними.
В результате выполненных работ по миграции в облако у заказчика осталось три стойки с оборудованием — это телефония, серверы HPE Superdome и другие системы, которые на данном этапе нецелесообразно или невозможно перенести в облако.
В качестве заключения
Миграция в облако — непростой процесс, который требует тщательной подготовки и качественного исполнения. При правильном подходе можно избежать или минимизировать время простоя сервисов, тем самым сохранив эффективность компании. А штатные пользователи даже не заметят, что теперь работают в облаке. В итоге заказчик получает легко масштабируемую, удобную для администрирования и обслуживания ИТ-инфраструктуру.
