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

В этот раз мы хотим поведать две истории миграции крупных российских компаний из Microsoft Azure в наше облако.

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

Давайте рассмотрим оба случая на примере реальных кейсов. Клиент 1 после подписания NDA предоставил учётные данные, Клиент 2 не предоставил.

Миграция Клиента 1

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

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

Видеоконференция показала, что Клиент 1 будет мигрировать из Azure все данные, включая виртуальные машины. Клиент готов после подписания NDA передать административный доступ компании Cloud4Y для работ по миграции. Технические специалисты провайдера предложили вариант максимально бесшовного переноса инфраструктуры в облако Cloud4Y.

В ходе изучения инфраструктуры выяснилось, что у Клиента 1 уже был настроен конвектор к Azure из локальной среды Active Directory (AD). Но локальные контроллеры крутились на ВМ в Azure, а сам AD был настроен неправильно и давно не обновлялся. Поэтому перед миграцией необходимо было решить эту задачу.

Для начала мы развернули все необходимые ВМ под локальную инфраструктуру. Вот краткий список:

2 контроллера домена
2 сервера Exchange – в режиме DAG
2 SQL сервера с организацией групп высокой доступности
1 сервер-свидетель для кластеров
2 сервера для Skype for Business Server
1 сервер Skype for Business Server с edge role (для внешних подключений) и телефонии
2 Office Online Server (позволяет читать документы в вебе и нужен для почты, скайпа, Sharepoint)
2 сервера ADFS для SSO авторизаций
·2 сервера Sharepoint для создания фермы, в том числе с личными сайтами, что позволяет пользователям пользоваться корпоративным OneDrive
1 сервер Nextcloud для обмена с контрагентами
2 сервера антиспама
2 сервера Web Application Proxy
ещё около десятка инфраструктурных серверов

Дополнительномы предоставили Клиенту 1 сервис двухфакторной аутентификации на основе Мультифактора, WAF и некоторые другие средства безопасности и проверки.

В процессе установки Exchange выяснялось, что один из системных администраторов, ранее работавший в штате Клиента 1 пытался ставить локальный Exchange и не совсем удачно. Нашим специалистам пришлось чистить схему AD, она была некорректной. Для переноса почты мы настроили гибрид локального Exchange с Azure, и после исправления Microsoft Entra Connect переносили ящики штатным путём, незаметно для пользователей Клиента 1. Дополнительно исправили во внешнем DNS записи на локальный Exchange и потоки почты перенесли на него.

Для миграции ВМ воспользовались возможностью подключить локальный сервер бэкапов Veeam к тенанту Azure. Это позволило забэкапить все машины клиента. В согласованное техническое окно выключили их, добавили необходимые настройки и ВМ, после чего развернули их уже на нашем облаке. После запуска ВМ проверили с Клиентом 1 их работу, а через неделю удалили копии в Azure.

Во время миграции от Клиента 1 поступило много заявок на развёртывание новых систем и исправление старых. Так, технические специалисты Cloud4Y создали и настроили отдельный сервер лицензирования 1С. Ранее Клиент 1 неоднократно страдал от слетания программных лицензий. Также наши инженеры выполнили перенос баз данных на отказоустойчивый SQL‑сервер, настроили автоматическую активации Клиентских систем (Windows, Office).

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

Миграция Клиента 2

Этот кейс начинался стандартно — с обследования инфраструктуры и встреч с ответственными лицами Клиента 2. Но быстро вскрылся важный нюанс: Клиент 2 входил в состав одной глобальной организации, и от нас требовалось вычленить «кусок» их данных. Кроме того, на нас возлагалась задача по перенастройке сетевого оборудования и организации прямых линков до московского офиса, а также полная поддержка офиса и склада (за исключением компьютеров пользователей).

В этой ситуации мы развернули аналогичный набор локальных серверов у нас в облаке, но для конференций Клиент 2 выбрал продукт TrueConf. Запросили выгрузку пользователей у глобальной организации. Чтобы упростить процедуру, написали под эту задачу скрипты и передали инженерам Клиента 2.

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

Также технические специалисты Cloud4Y занимались сменой сетевой связанности и переключением офиса Клиента 2 на новую сеть, переключали компьютеры на новый домен, настраивали все системы безопасности. Из‑за некоторых особенностей работы Клиента 2 работы должны были выполняться с перерывами и преимущественно в ночное время или выходные дни.

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

И так бывает в нашей работе. Спасибо за внимание!

Как мигрировать из Microsoft Azure: опыт Cloud4Y