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

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

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

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

  • около 2000 vCPU;

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

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

Источник https://pbs.twimg.com/media/EPbxlaEXsAAFiZe.jpg:large 
Источник https://pbs.twimg.com/media/EPbxlaEXsAAFiZe.jpg:large 

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

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

Первый вариант – использовать конвертеры дисков.  Есть бесплатная утилита 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%. В такой ситуации мы выключали ВМ в облаке, включали в ЦОДе и проводили повторную миграцию.

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

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

Источник https://hsto.org/webt/u2/va/ke/u2vakeurncfmhe3cfitnzpfwa8o.jpeg
Источник 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, но поняли, что их производительности будет недостаточно для стабильной работы инфраструктуры как по пропускной способности, так и по вносимой задержке. Единственным решением оставалось прямое соединение ЦОДов заказчика и VK Cloud Solutions через сервис L2VPN от провайдеров услуг – так и сделали. Теперь у заказчика есть отказоустойчивое высокоскоростное подключение существующего ЦОДа к облаку VK Cloud Solutions на уровне 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, VK Cloud Solutions и специалистов «ЛАНИТ-Интеграции». Есть и не такой успешный пример – система резервного копирования EMC NetWorker пока функционирует неполноценно, коллеги из VK Cloud Solutions решают вопрос с совместимостью. 

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

Источник https://d28nd3of37804l.cloudfront.net/wp-content/uploads/2020/08/24.08.2020.jpg
Источник https://d28nd3of37804l.cloudfront.net/wp-content/uploads/2020/08/24.08.2020.jpg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Комментарии (17)


  1. zvlad_vitamin
    19.10.2021 11:33
    +1

    Т.е. были сайты на серверах, теперь на "облаках". А разница? С одного сервера на другой перекинули?

    Обычные сервера кто то назвал "облаком" и все, новый тренд )))


    1. password Автор
      19.10.2021 12:39

      Любые приложения (веб-сайты, базы данных и т.д.) выполняются на серверах, с этим не поспоришь)

      Например, можно ставить самому ОС на сервер, далее - все нужные приложения, проложить сеть до этого сервера, опубликовать доступ через интернет, потом еще смотреть, чтобы ничего не сломалось. А можно открыть веб-интерфейс, нажать пару кнопок и получить тоже самое - разница в удобстве, быстроте, надежности и т.д.


      1. Sergey-S-Kovalev
        19.10.2021 14:24
        +2

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

        Вы просто меняете одни головняки на другие. Например, как объяснить руководству почему приложение вдруг решило помолотить на 100% всеми 40 ядрами всю ночь, или зачем гасить часть виртуалок из прода на ночь что бы сэкономить сожранные тики тестовым контуром, в котором разрабы десятками раз делают конвертацию базы или тестовые перепроведения пока ловят ошибку.

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

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


        1. password Автор
          19.10.2021 15:47
          +1

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

          По поводу смены одних головняков на другие - это тоже верно, тут вопрос выбора более "комфортных" головняков:)


      1. demas
        19.10.2021 15:49
        +1

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

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

        В общем, все вот это - зачем мы переходим в облако.


        1. password Автор
          19.10.2021 15:53

          Если речь шла про это - то безусловно, переход на Cloud Native технологии позволяет получать наибольшие преимущества от облака. Как верно заметили в комментариях, пока количество готовых корпоративных сервисов в российских облаках действительно небольшое (если сравнивать с международными облачными провайдерами), поэтому бОльшая часть сервисов была смигрирована в IaaS.


      1. zvlad_vitamin
        21.10.2021 09:33

        Вот как раз в надежности и не удобство) Врядли такая система надежная. Удобная - возможно.

        С точки зрения економии денег - то вообще не економия. Это как спалить 1куб дров для того, что бы закипятить чайник маленький.


  1. kovserg
    20.10.2021 00:42
    +5

    image


  1. meforyou
    20.10.2021 13:56

    Привет @password Ильдар! :)) Мониторинг предоставляет интеграция или заказчик решил использовать услугу у Mail?


    1. password Автор
      20.10.2021 13:57

      Привет!

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


      1. meforyou
        20.10.2021 15:24

        То есть заказчик решил все-таки в SolarWinds погрузиться?)


        1. password Автор
          20.10.2021 17:30

          Судя по вопросам, ты обладаешь некоторой инсайдовой информацией:) только я не смог по нику определить

          Давай обсудим в личке эти вопросы)


  1. user2010
    20.10.2021 13:56
    +1

    Было удалено 67 маши, а всего было 40! Это как?


    1. password Автор
      20.10.2021 14:00

      Всего было более 300 ВМ, из них удалено 67.

      Из 40 ВМ состояла старая терминальная ферма


  1. Dr_Wut
    24.10.2021 17:35

    Ну в целом, как обычно:

    1. А считали TCO дальше 3 лет?

    2. А какой процент роста цен закладывали при расчете для облака?

    3. А считали риски связанные с тем, что инфра у облачного провайдера умрет в пятницу вечером и до утра понедельника никто к ней не подойдет?

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

    P.S. Облака это очень хороший инструмент, но как любой инструмент им надо понимать как пользоваться. Мой опыт показывает что почему-то все считают что перенеся сервисы в облако все их проблемы магическим образом исчезнут... Это не так.


    1. password Автор
      25.10.2021 10:15

      Про ТСО и рост цен - рост цен происходит и для on-premise инфраструктуры (и стоимость железа растет, и зарплаты сотрудников, и электричество и т.д.). Только ТСО в облаке считается проще. Ответ да, все считали, конкретную цифру роста цен не готов назвать.

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

      "отключите голову и переезжайте в облако" - вот таких советов точно не могу дать, как раз хотел больше осветить техническую сторону и возможные проблемы при миграции. Мы не облачный провайдер, мы интегратор, мы реализуем любые решения, что в облаке, что on-prem


  1. sergeyns
    31.10.2021 22:16

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

    Экономика таких проектов, как правило, считается нелегко, но при желании это сделать можно.

    Хотелось бы хоть в каких-нибудь попугаях понять, что в итоге получил заказчик.. Точнее сколько сэкономил (не можете в абсолютных величинах - скажите в процентах). Но без вот этого маркетинга "зато теперь стало надежнее". НО раз вы цифр не приводите, есть сильное подозрение что "рост отрицательный"..

    Я поверю что интернет-магазин на 3 кружки с рисунками проще держать в облаке, или модному стартапу выгоднее прятать capex в облаках, а тут вроде как более-менее нормальное число серверов, на которые уже имеет смысл держать выделенных людей..