Миграция — это больно: развенчиваем мифы

«Lift-and-Shift»: ЗА и ПРОТИВ

С этого подхода начинается анализ миграции в облако любой инфраструктуры, любого сервиса, любого приложения. Подход «Lift-and-Shift» — буквально означает взяли и перенесли «как есть». Он понятен и его легко обосновать бизнесу, так как обладает понятными плюсами:

• Гибкость и масштабируемость: при переезде в облачную инфраструктуру «как есть» повышается гибкость и масштабируемость, потому что вы можете оперативно докупать или отключать мощности.
• Оптимизация затрат: на этапе переезда возможно все правильно заранее спланировать, отказаться от переноса части сервисов и проследить за тем, сколько же платиться за инфраструктуру в целом и за конкретный сервис в отдельности. Это позволяет принимать правильные управленческие решения.
• Снижение бизнес-рисков: не нужно самим осуществлять контроль за наличием у дата-центров сертификатов TIER 3, PCI DSS и других или же заботиться о том, как заменить вышедшее из строя охлаждение, диски или блок резервного питания.
• Отказоустойчивость: встроенные элементы безопасности, резервного копирования, отказоустойчивые дата-центры — это всё уже доступно всем пользователям облачной экосистемы.
• Безопасность данных: облачные провайдеры следят за соблюдением сертификации ФСТЭК, различных гос. стандартов и т.д.

Однако, есть у подхода «Lift-and-Shift» и свои минусы, которые не критичны, но это те важные моменты, о которых необходимо помнить, планируя миграцию именно таким способом:

• Перенос устаревшего ПО. Если ваше ПО не является изначально облачным, то выбирая «Lift-and-Shift», вы сталкиваетесь с рисками дополнительных издержек на сервисный контракты, на поддержку ПО, а также с рисками утечки технических специалистов, которые не хотят продолжать работать с устаревшим техническим стеком и терять свою компетенцию, ценность на рынке труда.
• Двойная работа. К примеру, вы берёте и переносите отказоустойчивый кластер баз данных в облако «как есть». Но у облака уже есть свои встроенные средства, такие как DBaaS (Database as Service, т.е. управляемые базы данных), в которые уже встроено резервное копирование, отказоустойчивость и которые значительно проще масштабируются по производительности. И здесь вы либо платите просто больше за инфраструктуру и ее сопровождение, либо в дальнейшем, когда вы запланируете в миграцию на PaaS-решения (частью которых является и DBaaS), вам придётся делать часть работы повторно.
• Сложности автоматизации (DevOps подходы, IaC). При переводе инфраструктуры «как есть», как правило, технический долг не сокращается, он только увеличивается и впоследствии стоимость владения такой инфраструктуры может вырасти.

Планирование миграции — почему это важно

Уже никогда не будет 100% облачных решений инфраструктуры и никогда не будет решений, которые останутся только «на земле». Всегда будет некий гибрид с перевесом в какую-то сторону. Именно поэтому правильное планирование оно важно. Но не стоит делать миграцию ради миграции, нужно правильно спланировать каждый шаг. Правильное планирование включает в себя 5 важных аспекта: сроки, технологии, SLA\RTO\RPO, люди и коммуникации.

Сроки — вы должны чётко понимать и планировать сроки миграции для того, чтобы не ошибиться на пару месяцев с поставленными задачами. Если вы запланировали сделать трансформационную историю за 3 месяца, а сделали за 6, то, конечно же, бизнес от этого сильно пострадает. Обычно длительность миграции равняется по длительности запланированным часам плюс еще 30% или 50% от этого времени. На сроки миграции могут влиять разные факторы. Например, планируется ли мигрировать виртуальные машины напрямую в облако (через перенос за счет поблочного копирования) или через их пересоздание в облаке и настройку приложений заново. Первый способ требователен к полосе пропускания и его сложнее распараллелить (например, при полосе пропускания 300 Мбит/с в среднем получится мигрировать 4-8 виртуальные машины в день), тогда как вторым способом значительно проще создавать виртуальные машины параллельно, но потребуется выделить время на их настройку.

Технологии — на этапе подготовки очень важно принять решение, какой сценарий миграции выбирается «Lift-and-Shift» либо какой-то другой, например, рефакторинг, трансформация (например, замена сервера базы данных и переход от виртуальной машины к управляемому аналогу). Для экспертов ICL Services такие проекты не редкость. Частый запрос — мигрировать 1С в связке с MSSQL в облако, в этом случае мы сразу прорабатываем не только миграцию с MSSQL на PostgreSQL, но и миграцию на Managed Service for PosthreSQL.

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

SLA\RTO\RPO^[1]. Эти параметры для большинства on-prem систем определены. При миграции их необходимо оценить отдельно и определить их значения для облачной среды. Часто говоря об облаке, можно услышать о SLA минимум 99,95%. С одной стороны, это так и есть, с другой — SLA проектируемой или переносимой системы будет произведением SLA ее компонентов. Например, если SLA виртуальной машины 99,95%, а сервера баз данных — 99,99%, то SLA системы, которая использует эти два компонента, будет 99,94%. Если требуется SLA повысить, но необходимо предпринимать дополнительные шаги. С данными вопрос должен изучаться еще более внимательно, так как потеря данных — это обычно значительно более негативное событие, чем даже сбой инфраструктуры, поэтому RTO\RPO желательно определить заранее.

Люди и коммуникации — два объединенных важных аспекта. В вопросах миграции необходимо понять, кто же является лицом, отвечающим за весь проект миграции целиком и его успешность как с технической точки зрения, так и с точки зрения бизнеса, кто является владельцем каждого конкретного бизнес-приложения, и объединить их в коммуникационную команду. Команда позволит чётко ранжировать, какой специалист за какой этап принятия решения отвечает и на каком шаге к нему будут обращаться. Это позволит избежать лишних коммуникаций, со словами «а я это не знал», «а я это не согласовывал», «а для меня это сюрприз». Чёткое выявление матрицы ответственности просто обязательно даже для небольших миграций. А если точнее, то люди и коммуникации в первую очередь нужны для небольших миграций. Потому что, когда осуществляется даже небольшая миграция, переносится какая-то часть сервиса, очень часто не учитываются взаимосвязи с теми сервисами и инфраструктурными компонентами, которые остаются «на земле».

Технические аспекты

Если дальше углубиться в планирование, то его можно разбить на важные организационные этапы (рис. 1).

Оценка — сбор информации о текущей инфраструктуре и бизнес-приложениях, которые развернуты поверх нее. У бизнеса нет цели перенести DNS или AD в облако, цели касаются именно бизнес-приложений и бизнес-процессов, например, повысить отказоустойчивость или доступность ERP, CRM-систем или сделать процесс согласования более гибким и менее длительным. Данные об инфраструктуре можно получить из CDB или же с помощью специализированных решений и анализа документов. Как правило на этом этапе находятся артефакты, которые нигде не описаны и, возможно, даже никем не учитывались при планировании, например, в бюджетах при первоначальной защите. А это позволяет выявить тех самых ответственных лиц (stakeholder), и чётко зафиксировать, кто же в действительности заинтересован в той или иной системе внутри инфраструктуры.

Сделав это, стоит приступить к планированию Landing Zones (логическое разбиение на уровне облачных аккаунтов). Это выделение внутри будущей облачной экосистемы аккаунтов для того, чтобы разделить логически домены, а также планирование сетевой топологии (DMZ, LAN и т.п.). . Даже если идет миграция «Lift-and-Shift», где-то может появиться дополнительный роутер, где-то поменяется IP-адрес или произойдет другой более ложный случай. Landing Zones важно сделать заранее, так как после того, как что-то уже будет имплементировано в облако изменение Landing Zones будет затрагивать все объекты и потребует дополнительных трудозатрат.

Лицензия, про которую довольно часто забывают, особенно при миграциях «Lift-and-Shift». Модель лицензирования многих производителей ПО может различаться для «наземной» инфраструктуры и облачной и это обязательно необходимо учитывать. Кроме того, если есть привязка лицензий к конкретному оборудованию или к USB-ключам, то при миграции в облако потребуется такие случаи разобрать, так как виртуальные машины в облаке переезжают с одного оборудования на другое довольно часто, а при таком переезде «лицензия» может «слететь». Большинство производителей ПО адаптировались, в том числе и к облачному лицензированию своих продуктов, поэтому обычно смена схемы лицензирования — это не проблема, тонкие моменты бывают только, если используются устаревшие версии ПО. Другой пример, который касается лицензий — это привязка лицензий к конкретному IP-адресу. При переезде в облако IP-адреса обычно меняются (т.к. на первых этапах должна работать и старая система со старыми IP- адресами, и новая, а также пул публичных IP-адресов у каждого облачного провайдера свой), это тоже необходимо заранее учитывать при планировании миграции.

Данные. Всегда необходимо отдельно планировать миграцию данных, но очень часто забывается, что данные — это не только ценность в виде информации, но ещё и такой фактор как объём, который в облако необходимо перенести (пусть и не одномоментно, но в разумные сроки). Например, если у вас 50-60 ТБ данных, которые вам критичны, за 8 часов вы их не перенесёте. И если вы правильным образом не спланируете перенос данных и не учтете их консистентность, и если вы правильным образом не спланируете этот последовательный момент по передаче данных с сохранением их актуализации в будущую вашу облачную экосистему, то вы рискуете какую-то часть данных просто потерять.

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

Для виртуальных машин необходимо заранее продумать и чётко решить для себя, а нужно ли их переносить «как есть» (то есть через образы) или проще поднять с нуля в облаке. При переносе через образы может потребоваться их конвертация в поддерживаемый целевым образом формат и дополнительная интеграция в них cloud-init. Получается, что требуется немало этапов, на каждом из которых может возникнуть сложность или проблемы совместимости. Другим популярным переносом виртуальных машин является использование сторонних сервисов, например, Hystax Acura (Хайстекс Акура), которые осуществляют поблочную репликацию дисков и последующую их синхронизацию до момента финального переключения. При таком подходе время простоя будет минимальных и копирование напрямую выполняется между исходной и целевой средой (тогда как при миграции через образы приходится скачивать и конвертировать образ в некоторой «локальной среде»). Но есть и минусы — поддерживаются многие ОС и версии ядер, но не все, кроме того, требуется оплатить лицензии на использование инструмента для миграции каждой виртуальной машины. Взвешивая плюсы и минусы этих двух подходов, иногда выбирают третий подход — разворачивания виртуальной машины и системы с нуля. Зачастую такой вариант требует меньше усилий, чем миграция виртуальной машины «как есть» и поиск, а также устранение возникающих проблем совместимости.

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

Как бизнесу взять максимум от облачной инфраструктуры

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

• Облако дает нам возможность быстро проверять гипотезы. Это означает, что можно быстро развернуть что-то новое, проверить насколько оно подходит и быстро свернуть, и не платить много за поддержку этой истории. Вы проверяете свою гипотезу и если она оправдала ожидания, то продолжаете ее развивать без дополнительных капитальных затрат на поддержание своей тестовой экосистемы.
• Инфраструктура работает как код, что помогает снизить капитальные затраты и возможность человеческой ошибки.
• Мониторинг использования ресурсов — очень важный фактор. В процессе использования часто любая инфраструктура обрастает кучей ненужных артефактов. Если мы используем облако, то нужно выстроить внутри себя культуру отслеживания под какую конкретную задачу, проект, бизнес-ценность у нас используются те или иные ресурсы облака. Желательно, чтобы под каждую конкретную бизнес-задачу формировался отдельный бизнес-владелец, ответственный за потребление облачного ресурса. Он должен уметь чётко ответить, что мы потребили столько-то, принеся вот такую ценность компании. Если у вас это заработало, то вы будете уверены в своих бюджетах и не будете переплачивать.
• Повышение надёжности, так как облака — это и отказоустойчивые дата-центры, встроенные облачные средства резервного копирования, антивирусной защиты, мониторинга и оповещения.
• Частичное снижение капитальных затрат. Хотя у вас не будет затрат на собственный дата-центр, но при этом не стоит забывать, что чаще всего в компаниях используется гибридный формат для поддержки ИТ-инфраструктуры, поэтому большого снижения по бюджету не будет, но тем не менее это будут заметные цифры.
• Использование сервисов вместо серверов. Раз уж вы уходите в облако, то зачем поднимать виртуальные машины там, где вы можете обойтись контейнером или сервисом. Хороший пример — базы данных, под которые по старой привычке поднимается как отдельный сервис. Но если ваше приложение может работать с DBааS, то нужно его и использовать. Это действительно серьёзно экономит время, средства и нервы.

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

Примечания