Миграция в облако — теперь управляема и возможна для любой ИТ-системы

Какие бывают миграции и зачем они нужны?

Миграцией в ИТ называют «переезд» функционирующей системы на другую техническую подложку. Можно говорить о переезде отдельного приложения, например — базы данных, или о миграции способа управления задачами, которые ставятся перед разработчиками конкретного приложения (т.н. «тасктрекинг») из Excel в в специальную программу Jira. Бывают масштабные проекты, когда с одной площадки на другую перемещаются целые ИТ-инфраструктуры или их крупные части. Традиционная миграция может быть простым переездом из одного ЦОДа в другой, который включает в себя как перевозку серверов, так и пересылку данных.

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

Раньше решиться на такой переезд было непросто. Ведь каждая ИТ-система уникальна, поэтому переезд становился штучной задачей со многими неизвестными и с рисками, что в облаке что-то не заработает. Теперь миграция превратилась в предсказуемый процесс с управляемым, минимальным временем недоступности сервиса (т.н. «даунтайм»), которое, при желании, можно сделать равным нулю.

Разновидности?

Миграция в облако, в общем случае, может быть трех типов:

1. «Поднять и переместить» (lift & shift), «как есть» (as is);

2. Пересборка;

3. Гибридная.

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

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

Первый тип миграции уже сам по себе дает базовые преимущества облака: больший контроль над используемыми ресурсами, их более полную утилизацию, гибкие возможности по бэкапированию, увеличение надежности системы. При этом задействуются лишь некоторые возможности облачной платформы, а чтобы ее «сила» раскрылась на 100% требуется переработка самих приложений, которые оказались в облаке. Для этого существует следующий подход.

Пересборка – более сложная и тонкая разновидность миграции, чем по варианту «как есть». В частности, предполагается переделка монолитных приложений, идеальных для работы в традиционной ИТ-системе, на микросервисную, совместимую с облаком ( cloud-native) архитектуру, берущую от облака максимум его возможностей. Кроме того, некоторые приложения можно заменить на платформенные облачные сервисы. Например, отказаться от поддержки своими силами СУБД и воспользоваться услугой «база данных как сервис» (DBaaS).

Реализация пересборки, при всей его большей сложности, увеличивает эффективность использования ресурсов на десятки процентов и даже в разы, принципиально поднимает уровень надежности сервиса. А главное — дает возможность быстрее тестировать и выкатывать обновления сервисов в промышленную эксплуатацию, сокращая время вывода на рынок новых продуктов (time-to-market).

Гибридный тип миграции встречается, когда первоначально делается переезд «как есть», а затем выполняется пересборка, инфраструктура постепенно делается все более совместимой с облаком (cloud native). Такой подход позволяет прийти к пересборке в два этапа. При переезде сложных систем это может оказаться хорошей идеей, поскольку помогает разделаться с трудностями собственно переезда облака и последующей пересборки всей системы по очереди, а не одновременно.

Порядок действий

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

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

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

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

Как быстро проходит миграция?

Скорость миграции зависит, прежде всего, от объема данных. Второй и третий важные моменты – ширина канала связи, поскольку перенос данных осуществляется по сети, и скорость работы дисковых подсистем.

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

Как избежать привязки к одному вендору?

Избежать привязки к одному вендору (vendor lock) помогает следование набору правил. Первое – разработка сервисов на основе свободных программных продуктов. Это избавляет от зависимости от проприетарного вендора, его желания и возможностей разрабатывать и поддерживать продукт – все можно делать самостоятельно или с помощью сторонних разработчиков – участников экосистемы. Второе – использование при разработке приложений технологий контейнеризации (одна из самых популярных – Docker). Это дает возможность без проблем размещать приложения на любой из облачных платформ – будь то MCS, AWS, Azure или GC в рамках мультиоблака. Третье правило – ставка на мультиоблако, когда в случае падения одной из площадок есть возможность оперативно переключиться на другую облачную платформу. И четвертое правило – использование технологии описания инфраструктуры как кода (IaC). И один из популярных продуктов, позволяющих это сделать, – Terraform. По сути, это несложный язык конфигурирования. Однако он требует от администратора и определенных навыков, и знания, как работают облака. Зато – как инфраструктура описана, так она размещается и поддерживается в облаке. При этом одно и то же описание можно использовать для миграции на разные платформы, что и позволяет, в числе прочего, избежать привязки к одному вендору (vendor lock).

Проблемы? Предупрежден – значит, вооружен

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

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

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

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

Как понять, что провайдер – тот самый?

Основных критериев выбора провайдера несколько, и первый – технологичность провайдера, длина линейки доступных сервисов, и главное – его способность выполнить миграцию архитектуры заказчика. Например, на рынке есть провайдеры, которые поддерживают миграцию только совместимой с облаком (cloud native) архитектуры.

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

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

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

Для некоторых сервисов критично размещение данных на территории РФ, согласно Закону 152-ФЗ, и это пятый критерий.

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

Системный подход: эксперты MCS о правильной миграции

В клиентском портфеле MCS уже есть кейсы с самым разноплановым использованием возможностей платформы. Один из них – по сервису «Битрикс24», который работает на базе международного мультиоблака. Миграция сервиса в облако MCS проводилась в два этапа. На первом из AWS были перемещены пользовательские документы и архивы в объектное хранилище Cloud Storage MCS – сегодня там хранится порядка 1,5 петабайта. На втором была осуществлена миграция части вычислительных мощностей из дата-центра другого российского провайдера на площадку MCS – сервис арендует порядка 150 виртуальных машин в целях обеспечения отказоустойчивой инфраструктуры. При этом в мультиоблаке «Битрикс24» действует единая система сквозного мониторинга сервисов с единой консолью. Отметим здесь, что MCS рекомендует мультиоблако как правильный архитектурный подход к проблеме надежности и непрерывности бизнеса. Выбор нескольких надежных провайдеров значительно снижает риски недоступности сервиса.

Основная ценность облака MCS – возможность использования базовых инфраструктурных и платформенных сервисов, позволяющих строить надежные и эффективные в плане стоимости использования приложения в парадигме совместимости с облаком (cloud native). Специалисты компании оказывают всестороннюю поддержку во внедрении и эксплуатации таких сервисов, в зависимости от типа миграции. Конкретно для пересборки предусмотрены т.н. управляемые сервисы (managed services). Это комплексная услуга, когда провайдер предоставляет своих специалистов, обладающих богатой экспертизой в облачных технологиях и многих смежных задачах, а также может привлекать своих партнеров.

Если кратко резюмировать, то для миграции сначала нужно выполнить аудит, а потом на его основе спланировать порядок действий. При планировании инфраструктуры, которую нужно создать в облаке, нужно учитывать все возможности, которые сегодня можно получить от облака. Это и использование PaaS-сервисов (включая управляемые СУБД, инструменты анализа данных и многое другое), и контейнеризация, и автомасштабирование, и возможность описания инфраструктуры как кода, и возможности мультиоблачности. Учесть все это, выполнить миграцию, получить поддержку в эксплуатации и последующей модернизации ИТ-системы можно и самостоятельно, но для многих компаний хороший выход — это обращение к технологическому партнеру с нужной экспертизой.