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

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

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

Миграция виртуальных мощностей в облако

Все проекты, которые реализуют наши специалисты, делятся на два типа:

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

Миграция с виртуализированной структуры в облако сервис-провайдера является самым популярным сценарием у заказчиков. Большинство из них находятся на начальном этапе использования облачных технологий, поэтому первостепенная задача для них – миграция с собственной инфраструктуры. И здесь, несмотря на большую популярность у крупных провайдеров OpenStack, Xen и ряда других платформ, в коммерческом корпоративном сегменте лидирующие позиции занимают все-таки VMware и Microsoft. Фактически подавляющее большинство наших проектов по миграции – это ситуации, когда заказчик располагает одной из упомянутых платформ виртуализации. Конвертация виртуальных машин (если у заказчика, например, VMware, а он мигрирует туда, где есть Hyper-V, OpenStack, Xen и т. д.), конечно же, возможна, и далее мы расскажем о таком варианте. Тем не менее будет разумнее, если позволяют обстоятельства, ее избежать.

Если говорить о Softline, то у нас есть два облака: одно – на базе Hyper-V, другое – на VMware. Например, для заказчиков, у которых стоит VMware, логично рассмотреть переход в облако, где есть аналогичная платформа. То есть конвертации можно избежать, и тогда виртуальная машина «переезжает» как есть. Таким образом, располагая облаками на базе двух популярных платформ, позволяет провести миграцию бесшовно и безболезненно.

В плане технических аспектов мы оперируем двумя подходами:

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

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

  1. Итак, при миграции с Azure в Hyper-V можно воспользоваться штатной функциональностью Windows Azure и выгрузить виртуальный жесткий диск машины на свою площадку для дальнейшего использования в виртуальной машине.
  2. У Amazon также присутствует штатная функциональность, которая позволяет производить экспорт виртуальных машин из инстансов Amazon EC
  3. Для конвертации виртуальных жестких дисков разных платформ существует достаточное количество инструментов, которые выпускают как сами вендоры, так и сторонние разработчики. Причем такого рода решения могут обладать либо дополнительной функциональностью, либо, напротив, окажутся максимально простыми в работе.

Если клиент использует в качестве средств управления облаком продукты Microsoft, то существует много возможностей для интеграции. Можно объединить виртуальные мощности, которые находятся в Azure, на Hyper-V, в облаке в одну систему, что позволит заказчику видеть пул ресурсов и управлять ими из единой консоли. Сейчас у такого решения немало ограничений, но в следующих версиях продуктов их станет меньше. Таким образом, процесс создания гибридных облаков продолжит свое развитие.

Миграция почтовых систем

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

Здесь также работают два сценария:

  • миграция почты клиента в облачный сервис;
  • миграция с одного облачного сервиса на другой.

Чаще всего клиенты располагают корпоративной электронной почтой на базе Exchange Server или других систем – Sandmail, Postfix, Lotus, бесплатных сервисах и т. д. Однако наиболее распространенные на сегодняшний день варианты – это Exchange Server и Lotus. Рассмотрим их подробнее.

Большинство облачных провайдеров предлагают сервисы на базе Microsoft Exchange. Если заказчик уже использует Exchange Server в своей инфраструктуре, то это значительно упрощает процесс миграции. Мы понимаем, что почта является одним из критичных бизнес-инструментов, и потому в первую очередь предлагаем варианты исполнения работ с минимальным простоем сервисов. В их числе миграция, проходящая путем масштабирования либо с размещением в домене заказчика, либо с размещением серверов в отдельном ресурсном лесу и дальнейшей синхронизацией учетных записей с помощью Forefront Identity Manager.

Если у заказчика решение Lotus, то это подразумевает практически всегда сложный, большой проект по миграции. Так как корпорация Microsoft исключила функциональность миграции с Lotus Domino после выпуска Exchange 2010, мы вынуждены использовать сторонние утилиты. Например, можно задействовать инструментарий Quest, который позволяет реализовать сосуществование почтовых систем на время самой миграции и выполнить ее с минимальным простоем ИТ-систем. Таким образом, работа с Lotus – это всегда относительно сложный процесс по миграции, поскольку он затрагивает не только почту, но и другие бизнес-процессы.

Обратимся к миграции с одного облачного почтового сервиса на другой. У Softline есть и собственная облачная система – «Виртуальный офис», которая располагает почтовым сервером на базе Exchange. Кроме того, мы занимаемся еще двумя облачными сервисами, наиболее востребованными в мире, – Office365 и Google Apps. Первый содержит Exchange, поэтому миграция на него достаточно проста. У Google Apps есть встроенные механизмы конвертации, но сам переход на него проходит чуть сложнее. Google использует Data Migration Services для миграции. В случае с Exchange заказчику необходимо иметь корректно настроенный Autodiscover и Exchange Web Services (EWS), тогда можно легко мигрировать почтовые сообщения и контакты. Для миграции других типов данных из Exchange, например содержимого календарей, нужно использовать Google Apps Migration for Microsoft Exchange (GAMME).

Кроме описанных выше сценариев перехода возможна миграция между Google Apps и Office365. Она осуществляется путем создания учетных записей в Office365 и настройки IMAP-синхронизации между ящиками. Когда этот процесс завершен, производится переключение MX-записей.

Сейчас, когда вступил в силу Федеральный закон РФ № 242 от 21 июля 2014 г. «О внесении изменений в отдельные законодательные акты Российской Федерации в части уточнения порядка обработки персональных данных в информационно-телекоммуникационных сетях», ужесточились требования к хранению персональных данных. Статья 2 этого закона обязывает операторов персональных данных «обеспечить запись, систематизацию, накопление, хранение, уточнение, (обновление, изменение), извлечение» данных граждан России с использованием баз данных, находящихся на территории РФ. У компаний, попадающих под действие № 242-ФЗ, есть несколько способов исполнить его требования: реорганизовать процессы обработки персональных данных, создать собственный ЦОД, использовать облачные мощности российских провайдеров. И если первые два варианта достаточно затратные и трудоемкие, то последний позволяет соблюсти законодательные нормы наиболее просто и экономично. Как следствие, у заказчиков возник интерес к аналогу решения Office365 в облаке нашей компании. Мы запустили свой сервис «Виртуальный офис» (пакет интегрированных программ – Lync, SharePoint, Exchange). Это система корпоративного уровня, ее основное отличие от Office365 – возможность кастомизации и размещения данных на территории России. Таким образом соблюдаются все требования действующего законодательства. Поэтому у заказчиков появился дополнительный спрос на миграцию с Office365 на «Виртуальный офис», и наши специалисты уже располагают всеми необходимыми техническими средствами для реализации подобных проектов.

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

Поделиться:
Спецпроект

Напряженный трафик или Современные требования к инфраструктуре ЦОД

Подробнее
Спецпроект

Специальный проект "Групповой спутниковый канал для территориально-распределенной сети связи"

Подробнее

Подпишитесь
на нашу рассылку