Миграция и DR: зачем это нужно и как работает в MWS

Несмотря на осторожное отношение к виртуальной инфраструктуре многих российских компаний и до сих пор присутствующий страх миграции в облака, российский рынок облачных сервисов в 2018 году вырос на 25% по сравнению с предыдущим годом (по оценке iKS-Consulting). Инфраструктура как сервис становится все более востребована бизнесом в РФ. Прогнозы таковы, что этот рынок будет расти примерно на 23% в год и по итогам 2022 года может достичь 155 млрд рублей. Заметив усиление тренда на перенос корпоративных ИТ-систем в облака несколько лет назад, в этот сегмент рынка устремились и телеком-операторы в надежде найти новые точки роста для бизнеса.
 

Перспективы в облаках

Компания МТС начала оказывать услуги cloud computing под брендом MWS. Сейчас это крупный провайдер, который обслуживает и корпорации, и малый бизнес из самых разных сфер: промышленности, транспорта, онлайн- и офлайн-ретейлеров, банковского сектора, разработчиков и т. д. Клиентам провайдер с мобильными корнями предлагает джентльменский набор IaaS и целый пул сервисов сверх него.

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

Миграция и DR: как это работает на примере Cloud-to-Cloud

По мере того как к платформе подключались новые клиенты, вырисовывались и новые запросы, например оперативная миграция внутри облака или Disaster Recovery (DR). В итоге у провайдера возникла необходимость решать задачи по бесшовной миграции и незаметной аварийной защите.

Несмотря на то что DR и миграция — это довольно разные темы, кое-что общее у них все же есть.

Оба сценария подразумевают перемещение на новую площадку с минимальным простоем и потерями. В этой статье эксперты МТС простым и понятным языком описывают одно из решений для реализации процессов миграции и DR в рамках IaaS-платформы на базе стека продуктов VMware. Своей экспертизой поделились сразу два специалиста MWS — ведущие архитекторы Судариков Дмитрий и Калинкин Антон.

vCloud Availability уже довольно хорошо знаком сервис-провайдерам и на сегодняшний день состоит из трех решений, закрывающих все возможные активности в части миграции и DR: как с площадки клиента, так — как и в нашем случае — между площадками провайдера.

В мае 2018 года стал доступен первый паблик-релиз продукта vCloud Availability for Cloud-to-Cloud DR 1.0, в чем-то инновационный, в чем-то построенный на ранее известных и уже хорошо обкатанных технологиях. О нем-то мы сегодня и поговорим.

Cloud-to-Cloud имеет три ключевые особенности:

• репликация и восстановление vApp (VM) между двумя vCD-инстансами для миграции и осуществления Disaster Recovery;
• полноценный self-service портал на HTML5, полностью интегрированный с VMware vCloud Director, где клиент может самостоятельно настраивать и контролировать процесс репликации машин между своими организациями (площадками);
• простота управления.

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

По сути, vCloud Availability for Cloud-to-Cloud DR (далее для простоты C2C) — это прослойка между VMware vCloud Director и VMware vCenter Server. Продукт позволяет клиентам самостоятельно управлять аварийным восстановлением (как правило, такая возможность должна быть предусмотрена в соответствии с внутренними регламентами заказчиков) и непрерывностью приложений между виртуальными центрами IaaS, прозрачно балансировать нагрузку между арендуемыми площадками за счет наличия копии данных, расположенной в другой локации. При этом сохраняет возможность асинхронной репликации и восстановления для рабочих нагрузок как на уровне VM, так и на уровне vApp. Ключевые особенности решения — это возможности асинхронной репликации, восстановления работоспособности, миграции виртуальных машин (либо их групп, они же vApps).

Конечно, это репликация не аппаратная, а на уровне ПО. Для малого и среднего бизнеса Disaster Recovery на уровне оборудования — удовольствие чересчур дорогое, и провайдер в любом случае перекладывает затраченные ресурсы в конечную стоимость продукта, так как такая модель заставляет дублировать большую часть базовой инфраструктуры, при том что в основном «страховочные» мощности будут простаивать. Тогда как на асинхроне в том виде, в каком он реализован в MWS, ресурсы затрачиваются лишь по мере надобности — когда нужно перенести или синхронизировать данные, что благоприятно влияет на стоимость конечного продукта.

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

В целом с точки зрения монетизации облако МТС устроено так: какие мощности и насколько долго задействовал — столько и заплатил. Кстати, vCloud Availability for Cloud-to-Cloud DR убирает необходимость выделения исходного и целевого сайтов для восстановления информации — он способен совмещать два в одном.

Наиболее очевидный вариант применения C2C — это восстановление из одной облачной локации в другую. Однако решение является гораздо более гибким и предоставляет широкие возможности.

Среди ключевых вариантов применения C2C:

1. Миграция между площадками

Клиент или поставщик услуг может использовать C2C для переноса рабочих нагрузок из одной организации vCloud в другую, минимизируя недоступность управления vApp или VM через портал самообслуживания. Такой подход позволяет распределить рабочие нагрузки в разных orgVDC, дает возможность миграции между экземплярами vCloud Director или внутри одного и того же экземпляра vCloud Director. Ну и обладает простым в использовании механизмом переноса.

«С2С используется нами под конкретные целевые задачи, к примеру пару месяцев назад мы расширили линейку доступных версий ЦПУ на нашем ландшафте. Часто возникают задачи по переносу клиентских ВМ на более производительные версии ЦПУ, а специфика архитектуры такова, что перенос между конечными кластерами иногда требует длительных даунтаймов (в случае большого объема клиентских данных). В такой ситуации С2С позволяет произвести все необходимые подготовительные работы в фоне и в час икс переключить клиента с минимально возможным даунтаймом, необходимым для корректного отключения и включения конечных ВМ или vApp. Также иногда возникают немного иные задачи по переносу клиента с одной площадки на другую. Например, это относится к ситуациям, когда заказчик из своих личных соображений захотел изменить локацию в нашем облаке, но строго с минимальными даунтаймами и по возможности без реконфигурации своих виртуальных машин.», — Антон Калинкин, ведущий архитектор MWS

Переключение организации — пользователя IaaS с одной виртуальной площадки на другую внутри облака посредством С2С можно провести очень быстро.

Другой пример. На перевод рабочей среды клиента из Санкт-Петербурга в Москву при объеме данных в 0,5 Тб уйдет примерно 15–20 минут. У более крупных заказчиков этот процесс займет, как правило, час или чуть больше в зависимости от количества данных и типов систем у них «на борту». Впрочем, даже многие компании с разветвленной ИТ-инфраструктурой без проблем переключаются «на горячую»: та самая функция Availability, которая упомянута в названии решения, позволяет корректно отключить систему-источник и перейти на систему назначения с даунтаймом, равным времени остановки и старта переключаемой системы.

Наиболее значительные препятствия на пути «внутренней миграции» заказчиков, по статистике, обусловлены необходимостью вносить изменения в сторонние ресурсы. Несмотря на то что МТС — телеком-провайдер и ему не составляет труда перемещать IP-адреса между площадками (в таких процедурах МТС помогают выделенные каналы между центрами обработки данных), возможны не зависящие от него осложнения, например быстро ли вступят в силу изменения в DNS, вносимые на стороне клиента одновременно с «переездом», если это требовалось при миграции.

Следует уточнить, что в рассматриваемом сценарии система также гибко масштабируется горизонтально.

«Если клиенту нужно перенести свою среду в предельно сжатые сроки, под „миграционный“ проект выделяются добавочные мощности и расширяется канал между дата-центрами. На уровне бэкенда устанавливается несколько дополнительных компонентов — по 15–20 минут на каждый. Вычислительные ресурсы и пропускная способность канала увеличиваются, и клиента в форсированном темпе переправляют на площадку назначения. Сразу же по завершении процесса излишки мощностей убираются или могут быть использованы другими пользователями облака.», — Антон Калинкин, ведущий архитектор MWS

Важно, что при миграции не нужно создавать дополнительные порталы — функциональность С2С интегрирована в vCloud Director. Фактически клиент вводит свои логин и пароль, а затем видит в интерфейсе утилиты доступные площадки. Производится ряд подготовительных работ (в основном все работы связаны с подготовкой соответствующей сетевой инфраструктуры организации). Далее заказчик самостоятельно или с нашей помощью настраивает репликацию нужных vApp или VM в нужную сторону с заранее известным минимальным временем переноса изменяемых данных на ВМ. Затем мы ожидаем окончания репликации и в час икс переключаем системы. Если инфраструктура клиента позволяет, можно выполнить тестовое переключение без остановки текущей репликации.

2. DR для восстановления данных

 

Как говорят эксперты МТС, едва ли не самая частая потребность клиентов — это обезопасить себя от простоя ИТ-систем, в крайнем случае сократить даунтайм до допустимого для их бизнеса минимума. Это тот случай, когда клиенту требуется DR в рамках резервной площадки. Провайдер может обеспечить заказчику такую возможность, если у него есть несколько сайтов с многоуровневой средой. Провайдер на базе vCloud Availability for Cloud-to-Cloud DR может обеспечить аварийное восстановление или запланированный переход на другой сайт, предоставив при этом быстрое RTO, полное или частичное восстановление сайта, возможность выбора точки восстановления.

 

Часто бывает так, что у клиента повреждаются данные из-за его собственной активности: часто на продакшене что-то задеплоили, после чего система стала сбоить. Откатываться на бекап долго или клиент не понимает, как корректно откатиться (бывает и такое), на snapshot — часто нельзя либо его не сделали. Если заказчик четко знает, когда именно были сделаны «фатальные» изменения, то переключиться на DR-площадку с системой в том состоянии, в каком она была незадолго до изменений, просто. При условии, что это позволяет глубина хранения данных, обозначенная в договоре.

3. Предотвращение рисков возможных аварий

Предотвращение потенциально возможных отказов является одним из наиболее распространенных вариантов использования vCloud Availability for Cloud-to-Cloud DR. Решение позволит, к примеру, при возникновении техногенных рисков корректно завершить работу виртуальных машин и vApps на защищенном сайте, провести полную репликацию данных и запустить виртуальные машины и vApps на целевом сайте, обеспечив нулевую потерю данных и полную консистентность приложений. При этом все необходимые операции будут выполнены из единого интерфейса.
 

4. Тестирование обновлений

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

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

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

«Допустим, после очередных изменений в системе возник конфликт и необходимо понять, как эта модификация стыкуется со вчерашней конфигурацией. При наличии С2С это просто: „воскрешаем“ прошлый конфиг на тестовом стенде и проверяем, если нужно, исправляем. Все устраивает? Сносим стенд. Быстро возвращаемся к текущему состоянию системы и видим, что все в порядке. Основной продуктив во время тестовых испытаний не затрагивается. Причем на время тестов репликация не останавливается, и возможность резервации сохраняется всегда.», — Дмитрий Судариков, ведущий архитектор MWS 

 

Переезд в облако

До сих пор этот процесс ассоциируется у представителей российского бизнеса с болью. К сожалению, к тому есть предпосылки, даже при условии что в самом облаке все будет радужно, быстро и защищено. Если компания покидает со своим «ИТ-скарбом» облачного провайдера, реакция у второго часто бывает суровая: «Окей, у тебя три дня. Съезжай как хочешь. Вот порт доступа, вот канал интернета». Что «беглец» вытащит с каналом в 100 Мбит/с, если у него накопились терабайты данных, никого не волнует.

Пример выше — про переезд между облачными площадками разных провайдеров. Компании же неуклонно переселяются в облака с on-premise инфраструктуры. Существует несколько популярных сценариев переезда. Рассмотрим характерный кейс переключения клиента при помощи решения VMware vCloud Extender.

В первую очередь команда MWS уточняет состав и структуру той ИТ-среды, которая сложилась у клиента. А при необходимости проводит инвентаризацию — как показывает практика, бизнес не всегда четко и до конца понимает, с каким набором систем живет. Далее создается виртуальная организация в облаке МТС. Если заказчик накопил много данных, обычно ему предлагается построить выделенный канал до дата-центра оператора, так как перекачивать информацию через интернет по IPsec можно, но слишком долго. Следующим шагом клиенту уходят инструкции по Extender.

Сам же Extender — шаблон виртуальной машины. Его необходимо проинсталлировать и познакомить со своим vCenter Server. Да, Extender доступен только для стека VMware. Если у клиента, скажем, Hyper-V, необходимо прибегнуть к другому способу миграции. Дальше рассчитывается приблизительное время переноса среды. А также решается вопрос, нужно ли какое-либо тестовое восстановление.

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

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

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

В основе своей Extender работает приблизительно по той же модели, что и технология VMware vMotion. Он полностью синхронизирует две машины, а когда видит, что они почти идентичны, то ненадолго замораживает исходную и включает новую. Таким образом даунтайм удается сократить до минимума — иногда 15–30 секунд.

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

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

Куда мигрирует сам MWS

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