Миграция в облака

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

^[1]

Можно найти немало кейсов, в том числе и российских, демонстрирующих успешную миграцию ИТ-инфраструктуры в облако провайдера. Компании используют облако в качестве дополнительной площадки для некритичных сервисов, как среду разработки и тестирования ПО (PaaS), либо полностью переносят ИТ-инфраструктуру в облако (по модели IaaS).

Сценарии использования облаков становятся все сложнее, компании все чаще переносят в них критичные системы и сервисы. На облачную платформу нередко переезжают организации с сезонными всплесками активности, либо те, кто ожидает быстрого роста клиентской базы. Это помогает им справляться с пиковыми нагрузками и масштабировать используемые ресурсы. Также в облака мигрируют территориально распределенные компании (например, крупные торговые сети) с собственным ЦОД, крупные компании, которым трудно управлять своим разросшимся ИТ-парком, либо компании сегмента SMB, где ресурсов недостаточно для покупки и содержания серверов и СХД. А начинающим компаниям и новым направлениям бизнеса аренда мощностей ИТ позволяет быстро стартовать.

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

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

Бизнес в облаках

По данным отчета Flexera ^[2] «Облачные решения: текущее состояние» (Rightscale 2019 State of the Cloud Report from Flexera), 94% респондентов уже используют то или иное облачное решение, а затраты компаний на облачные технологии продолжают быстро расти. Их планируемые расходы на публичные облака в 2019 году на 24% превышают показатели 2018 года. В среднем 38% рабочей нагрузки приходится у респондентов на публичные облака, а 41% относится к частным. В малом и среднем бизнесе пропорция иная: 43% — публичные облака, 35% — частные.

Отделы ИТ в компаниях и на предприятиях фокусируются на управлении облачными ресурсами и оптимизации расходов на облачные технологии. 66% предприятий уже имеют выделенную группу специалистов по облачным технологиям, либо центр компетенций и передового опыта. 21% компаний планирует его организовать. Приоритетным в деятельности отделов ИТ считается оптимизация затрат и грамотное управление облачными ресурсами (68%), подготовка аргументации и принятие решений о том, какие приложения и в каких облачных средах использовать (62%), продумывание и настройка политик для облачных приложений (59%).

По прогнозу Oracle, в ближайшие десять лет в облака будут перенесены до 80% бизнес-приложений, туда же мигрируют практически все корпоративные данные, в облачной среде будет выполняться вся разработка и тестирование приложений.

Как попасть в облако?

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

Для многих организаций, еще не использующих возможности облачных технологий, важнейшим вопросом становится «миграция в облака ^[3]» — подготовка к переносу ИТ-инфраструктуры компании в виртуальное пространство с целью повышения качества сервисов и снижения затрат на эксплуатацию. Какие шаги для этого необходимы? Миграция включает разработку плана, развертывание инфраструктуры в облаке, перенос данных, тестирование инфраструктуры и запуск сервисов. 

1. Выбор облачного провайдера

Миграция в облако предполагает перемещение данных, настроек, сервисов и приложений с локальной площадки компании или организации в виртуальный ЦОД облачного провайдера. Занимает такая миграция обычно несколько дней. Серьезная задача — выбор поставщика услуг ^[4] – облачного провайдера, соответствующего всем требованиям проекта миграции.

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

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

3. Список для переезда

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

Принимая решение об использовании облаков, компании часто задаются вопросом, насколько безопасно переносить корпоративные данные в облако. Хотя современные облачные сервисы характеризует достаточно высокий уровень безопасности, не стоит «выносить» в облако все подряд, это может быть сопряжено с серьезными рисками для бизнеса.  

Если такую работу не может выполнить сам заказчик, то провайдеры нередко предлагают свои услуги по первичному аудиту информационных систем ^[5]. Этот аудит позволяет не только более качественно спланировать перенос сервисов на облачную платформу, но и выявить текущие недочеты и проблемы существующего ИТ-ландшафта и устранить их.

4. Выбор инструментов миграции

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

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

Инструмент VMware vCloud Extender позволяет объединять облака и переносить ВМ в облако, используя интуитивно понятный графический интерфейс. Для конвертации физического сервера в виртуальную машину и ее переноса в облако провайдера можно воспользоваться утилитой VMware vCenter Converter. При этом основной сервер продолжает работу. Другой вариант – создание образов физических дисков, их преобразование в формат виртуальных дисков и перенос в облако провайдера, в виртуальную среду. Еще один метод «естественного» переезда — резервное копирование и восстановление на новой площадке.

5. Обеспечение сетевой связности

Отдельный вопрос – обеспечение сетевого взаимодействия ИТ-инфраструктуры клиента и облачной платформы провайдера, то есть сетевой связности. Он решается совместными усилиями провайдера и клиента. Каналы связи должны гарантировать доступ пользователей к облаку ^[5]. Для этого может потребоваться принять во внимание маршрутизацию, адресацию, пропускную способность и надежность каналов связи, а также информационную безопасность (например, необходимость в VPN), горизонтальную (увеличение числа ВМ) и вертикальную (наращивание мощности конкретной ВМ) масштабируемость облака.
 
6. Составление детального плана миграции

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

В плане миграции нужно определить показатели RTO (время простоя) и RPO (величина потери данных) и способы их минимизации. Обновлять и модифицировать приложения лучше до переноса, иначе сложно будет выявить источник проблем. Карты зависимостей приложений поможет проработать механизмы корректного переноса в облако. Четкий план миграции также прописывает процедуры переноса данных. 

7. Тестовая миграция 

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

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

До начала тестовой миграции полезно определить требования к работоспособности и доступности облачного сервиса. 

Полезные советы

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

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

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

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

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

Сценарии и варианты реализации

В числе возможных сценариев — полный перенос конкретного бизнес-приложения в облако ^[7], миграция отдельных функций, развертывание новых сервисов или обеспечение взаимодействия локальных и облачных сервисов. При этом могут использоваться публичные, частные или гибридные облака, либо набирающие популярность мультиоблачные среды. Различны варианты реализации и тарификации облачных структур, их состав и функциональность. 

Облачные провайдеры, системные интеграторы, владеющие собственными виртуализированными ЦОД, предлагают услуги ^[8] по предоставлению безопасной и производительной ИТ-инфраструктуры, развернутой в их облаке. При необходимости клиент может получить в свое распоряжение выделенный и полностью готовый к работе виртуальный центр обработки данных ^[9] (ВЦОД). 

В зависимости от потребностей и бизнес-задач клиента такой ЦОД включает  вычислительные ресурсы (виртуальные процессоры, виртуальная оперативная память), ресурсы для хранения информации (виртуальное дисковое пространство с заявленной производительностью), сетевую инфраструктуру, систему управления и мониторинга, а также различное другое программное обеспечение: операционная система, СУБД, приложения, специализированные продукты для анализа больших данных, виртуальные маршрутизаторы, средства самоуправления, сервисы резервного копирования, репликации, информационной безопасности и др. 

Для доступа к информационным системам в облаке используются интернет, каналы L2 и L3 VPN, ГОСТ VPN, либо аренда оптического волокна. 

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

Его можно использовать как платформу для систем или бизнес приложений с фиксированными требованиями к производительности (например, виртуальные АТС, 1С), либо как платформу для систем и приложений, которым не нужна высокая производительность (тестовые среды и среды разработки). 

Облако может снять с вам непрофильные ИТ-задачи, позволяя сосредоточиться на своем бизнесе. Все задачи по поддержке и обслуживанию ИТ-инфраструктуры берет на себя специализированная компания. Она обеспечивает прописанные в договоре параметры SLA, быстрый отклик бизнес-приложений, высокий уровень информационной безопасности, предлагает профессиональные услуги и сервисы ^[9]. 

Преимущества облачной среды давно известны:

На успех перехода в облако влияет зрелость бизнес-процессов в компании, наличие стратегии ее развития и готовность руководства к переменам. Конечно, каждый такой проект индивидуален, требования заказчиков разнообразны, возможны разные сценарии. Кроме того, далеко не все организации владеют подобными компетенциями, поэтому нужен грамотный партнёр ^[10], обладающий соответствующим опытом.

Автор: Dmitry Egorov

Источник ^[11]