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

Меня зовут Дамир Ибрагимов, я руководитель инженерного направления платформы Advanced. Ещё со школы мне был интересен мир информационных технологий: тогда я пытался запустить Counter-Strike на iMac 2007 года. Тогда же я в первый раз познакомился с виртуализацией (Parallels, VMware Fusion) и понял, что ПК — это нечто большее, чем коробка для игр. Мой интерес и хобби переросли в профессию, которая мне очень нравится. Как сертифицированный архитектор облачных решений сегодня я расскажу о нюансах миграции в российское облако.

Миграция

Есть два типа миграции: постепенная и полная.

При постепенной миграции мы сначала переносим не самые критичные сервисы, всё остальное — потом. При полной миграции мы просто берем всё, что у нас есть, и сразу перевозим в облако.

Мы выделили 5 простых шагов:

1. Стратегия;

2. Инвентаризация и анализ;

3. План;

4. Дорожная карта;

5. Миграция.

Сначала нам нужно разработать стратегию миграции, чтобы оценить, нужно ли нам вообще ехать в облако: иногда этого делать не стоит. На втором этапе мы смотрим на всю бизнес- и IT-инфраструктуру и оцениваем риски, ценность и плюсы переезда в облако.

Далее, как и в старом добром  видео, — у нас с самого начала должен быть какой-то план, которого мы должны придерживаться. Нам нужно понять, какие системы можно сразу перенести в облако, а какие проприетарные решения лучше оставить в локальной инфраструктуре.

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

Последний шаг — это провести миграцию, выполнив все подготовленные шаги.

Case Study

Какие проблемы могут возникнуть при миграции:

1. Многим коммерческим компаниям и финансовым институтам в наследство достался legacy-продукт в виде монолита, и они не знают, что с ним делать.

2. Несмотря на продвинутость клиентов и их знания о PaaS, немногие понимают архитектуру данного решения. Это может вызывать некоторые сложности.

3. Иногда клиент просит IaaS виртуалками, чтобы создать собственный PaaS: пользователю просто не нравится версия сервиса провайдера, которая чуть старее опенсорсной.

4. Клиент всегда прав, и это действительно так, но иногда у него бывает недостаточно опыта, чтобы провести определённые операции. Более того, он не общается со своим облачным провайдером.

Посмотрим, как облачная платформа Advanced от Cloud поможет решить эти проблемы.

Что такое Advanced 

Решение OpenStack + KVM, на базе которого можно разворачивать как IaaS, так и PaaS-решения.

OpenStack — модульная платформа, состоящая из нескольких компонентов с открытым исходным кодом — их можно модифицировать под свои нужды. Чаще всего OpenStack по умолчанию используют с гипервизором KVM.

Мы уже знаем, что OpenStack — это довольно продвинутый и популярный инструмент, который используют многие зарубежные провайдеры. По большому счету Cloud Native — тренд нашего времени, который в свою очередь тоже связан во многом с OpenStack.

Примеры подходов cloud-native в виде PaaS:

Среди них я выделил:

1. Cloud Container Engine — сервис для развёртывания приложений на базе Kubernetes;

2. DMS for Kafka — распределённый брокер сообщений с высокой пропускной способностью, горизонтальной масштабируемостью и потоковой обработкой данных;

3. RDS for PostgreSQL — профессиональная платформа управления базами данных PostgreSQL.

Есть и другие сервисы, на базе которых работает Advanced. Разберём их подробнее.

Server Migration Service (SMS)

Служба миграции помогает переносить локальные физические серверы x86 или виртуальные машины из частных и публичных сред в облако.

Процесс миграции — это довольно простая история. На вашу исходную машину устанавливается агент, а в облаке зеркально по техническим характеристикам в вашей инфраструктуре разворачивается виртуальная машина, куда потихоньку начинают заливаться данные. Для Windows используется VSS, для Linux — Rsync. 

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

Data Replication Service (DRS)

Похож на предыдущий сервис, только для баз данных. DRS помогает переносить БД в облако Advanced, а также синхронизировать данные в реальном времени.

Часто возникает вопрос, как переносить базы данных, делать бэкапы или другие действия. Именно тут Advanced предлагает готовый сервис, который подключается к вашей БД и начинает переносить таблицы и сами структуры.

Основная фишка такого сервиса — возможность не только импортировать, но и экспортировать данные. Если вам нужна offside-реплика вашей БД в своей локальной инфраструктуре, вы можете сделать её с помощью этого сервиса.

Image Management Service (IMS)

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

Многие выходцы от VMware часто говорят, что хотят развернуть свою ванильную виртуалку из образа. Встречаются такие клиенты, которых приходится уговаривать заехать к облачному провайдеру, а они в свою очередь думают,  что тот не позволит им развернуть ничего из своих образов. Инженеры Cloud подумали и сделали сервис IMS таким, чтобы он позволял не только использовать образ как основу для виртуальной машины клиента, но VMDK для VMware, VHDX для Hyper-V и QCOW2 для  вашего OpenStack или KVM.

DAYU

Универсальная платформа для интеграции и работы с данными. Позволяет создавать комплексные интеллектуальные системы обработки данных.

Этот сервис — волшебная палочка. Он может всё, если вы работаете с данными и вам нужно перенести неординарные истории. В качестве источников данных могут быть S3-bucket, Data Lake Insight (DLI), Data Warehouse и пр. На выходе вы загружаете их в похожий сервис в облаке Advanced.

Case Study. Решение

Теперь у нас есть представление, как устроена миграция. Посмотрим на решение указанных ранее проблем:

1. Не надо монолитить. Если ПО не готово к облакам, мигрировать просто так не стоит. Но никто вам не мешает заказать у облачного провайдера уже готовый кластер, инфраструктуру или ресурсы, начать готовить и перерабатывать своё решение и адаптировать его к облаку, чтобы заехать чуть позже.

2. Оставьте в покое PaaS. Конфигурацию сервиса выставляет и регулируют Control Plane облака. PaaS представляет уже готовое коробочное решение, которое со стороны облачного провайдера, в частности Cloud, гарантирует работу данного сервиса, его отказоустойчивость, SLA. Попытка клиентов что-то изменять в этом сервисе может привести к тому, что их сервис упадёт, а провайдер помочь не сможет. 

3. Лучше взять готовое, чем строить своё. Когда клиент пытается развернуть свой PaaS на IaaS, часто может произойти неприятная ситуация: некоторых кросс-интеграций и фичей, которые уже есть в готовом сервисе от провайдера, просто не будет в том решении, которое клиент построит сам.

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

Почему это актуально?

Статистическая оценка

По данным исследований, 68% компаний сейчас занимаются переходом с монолита на микросервисы. При этом из них 36% — крупные компаний, 50% — средние и 44% — малые.

Что касается роста рынка PaaS: 38% приходится на обычный публичный рынок и 30% на рынок гибридных решений. Мы наблюдаем рост спроса на различные виды PaaS. Так, спрос на сервисы хранения вырос в два раза. На потребления Kubernetes — в 3,5 раза, на базы данных — в 2,5 раза, а на сервисы информационной безопасности — в 5 раз.

Да и в целом спрос на рынке IT-услуг и IT-консалтинга вырос на 5%.

Примеры неудачной миграции

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

— Клиент развернул свою инфраструктуру (PaaS) на базе IaaS. В итоге он потерял возможность использовать интеграцию с соседними облачными сервисами.

— Клиент использовал Ansible вместе с Terraform. Теперь, чтобы «прикрутить» остальные сервисы, он должен начать дополнительную разработку.

— Клиент развернул свой кластер Kubernetes. Это зря потраченное время и не готовая к использованию инфраструктура.

Клиент вроде бы следовал всем принципам Cloud Native, использовал Terraform и Ansible для развертывания, но у него получился обычный кластер Kubernetes. Когда он начал сравнивать своё решение и аналогичное от Cloud, понял, что различные кросс-интеграции готовых решений для него недоступны. К ним относятся:

• Использование PVC на базе объектного хранилища Cloud; 

• Использование NFS, как того же самого PVC;

• Использование балансировщиков нагрузки.

А всё потому, что у него была своя разработка Kubernetes.

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

Пример удачной миграции

Теперь перейдём к удачному кейсу. Начнём с плана миграции, как профессиональные архитекторы.

 Как и в задачах по физике, у нас есть «дано»:

• Физические серверы;

• Kubernetes as a Service;

• MySQL, PostgreSQL.

И «решение» следующими опциями:

• Виртуальные машины с дисками Elastic Cloud Server;

• Cloud Container Engine — сервис для развёртывания приложений на базе Kubernetes;

• RDS — сервис для адаптации баз данных MySQL и PostgreSQL.

Используя Kubernetes, клиент может достаточно просто изменить существующие манифесты (на примере PVC):

В существующий манифест добавлена пара аннотаций.

Дальше облако, зафиксировав в манифесте запрос от Kubernetes о развёртывании определённого типа PVC (s3fs), получает сигнал о том, что надо создать новый бакет и примонтировать его нужным драйвером к кластеру. .

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

В итоге за одни выходные получили прирост в 12000 ядер. Причем оказалось, что среди этих 12000 ядер 8000 — клиента, а оставшиеся 4000 — ядра клиентов, которые решили расшириться просто параллельно в эти же выходные.

Кстати, команду Advanced вдохновил опыт миграции наших клиентов и сейчас мы запустили большую акцию «Переезжай совсем»: предлагаем гранты на миграцию в облако Cloud.

Выводы

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

Лучше мигрировать не только IaaS, но и PaaS. Нельзя забывать о том, что PaaS, помимо хорошего инфраструктурного решения, которое позволяет упростить работу с приложениями и системами, предлагает ещё одну полезную опцию: вы делаете описание ваших приложений один раз и потом можете их интегрировать с различными облачными провайдерами. Если упадёт метеорит и один из дата-центров вашего провайдера “умрёт”, вы можете переехать к другому, просто перенеся манифесты и конфигурации, а не заниматься конкретной миграцией всех данных и виртуальных машин.

Смотрите полную версию доклада Дамира Ибрагимова с HighLoad++ Foundation:

Приглашаем вас на Saint HighLoad++ 22 и 23 сентября в Санкт-Петербурге, где продолжим обсуждать возможности облаков и узнаем, как проводить безопасные вычисления в облаке и многое другое. Подробности, расписание и билеты ищите по ссылке.