Миграция в облако – критически важный шаг на пути к цифровой трансформации и непростое решение для любого бизнеса. Непростое оно не только потому, что требует значительных ресурсов.
Предположим, что в компании отточены все процессы, а все локальные системы работают как часы. Значит ли это, что и миграция в облако пройдет проще простого? Увы, это не так.
В нашей статье вы прочтете пять небольших уроков о миграции в облако – на примере кейса компании Infopulse, официального CSP и сертифицированного партнера Microsoft в Украине.
Облачная трансформация для крупного поставщика IT-услуг
Клиент Infopulse, о котором пойдет речь в нашей статье – большая европейская компания, в свое время разраставшаяся путем покупок компаний помельче. Как это часто бывает в таких случаях, в наследство наш клиент получил множество разрозненных систем и устаревших серверов. И вот, когда затраты на поддержку стали превышать рентабельность и КПД в целом, клиент задумался о переходе на облачные технологии. Приблизительно в этот период, компании начали массово избавляться от быстро стареющего железа и унифицировать технологические стеки. Тогда, в 2014 году, и начался наш многоступенчатый проект длительностью в несколько лет и состоящий из двух основных и нескольких промежуточных этапов:
Итак, вот пять главных уроков, которые мы вынесли из этого кейса.
1. Миграция пользователей из старых систем занимает много времени.
Когда необходимо развернуть и настроить Office 365 с нуля – это делается достаточно быстро и просто. И совсем непросто, когда, как в нашем случае, нам пришлось мигрировать в облако данные порядка шести тысяч пользователей из двух устаревших систем. Половина пользователей использовала Exchange 2010, а вторая половина – отслужившую свое, но все еще популярную на тот момент в Европе систему IBM Lotus.
Миграция получилась очень сложной технически и заняла почти 2 года – казалось бы, нереальный срок. Выглядело это следующим образом:
Рис.1. Интеграция между Azure AD и On-Premises AD
Скорость миграции была ограничена из-за необходимости вырабатывать индивидуальный подход к каждому пользователю. В связи с большим количеством пользовательских данных, мигрировать нам удавалось по десять-двадцать пользователей в день, с использованием специального программного обеспечения. Не обошлось и без множества технологических конфликтов.
Стоила ли овчинка выделки? Безусловно, ведь для пользователей все закончилось идеально – ни один килобайт данных не утерян, все интегрированы в единую инфраструктуру и получают современные сервисы с обслуживанием в облаке. Стоит заметить, что все это время бизнес не простаивал – перенос данных не затронул работоспособность пользователей. Но самое главное здесь – не процесс, а итоговые результаты.
Вывод: Проекты миграции – не всегда быстрый процесс. Многое зависит от имеющегося технологического стека, от особенностей инфраструктуры, и от многих других факторов, оценить которые (и соответственно, понять сроки и объемы) – одна из первоочередных задач перед началом проекта миграции. В любом случае, всем компаниям раньше или позже приходится проходить через тернии миграции. И конечно, чем раньше вы начнете, тем скорее перейдете на следующий этап.
2. До миграции необходимо подготовить сетевую инфраструктуру.
Наш клиент владеет большим количеством дата центров, расположенных на различных локациях в Европе. Часть дата центров находилась в очень запущенном состоянии, а у другой части заканчивалась аренда. Чтобы не продлевать аренду, не возиться со старым железом и его поддержкой (стоящей, к слову, немалых денег), необходимо было выполнить миграцию всех систем и серверов в облако. Для этих целей Microsoft предоставляет Azure Site Recovery, службу облачного восстановления, помимо всего прочего, позволяющую мигрировать физические и виртуальные сервера в облако.
Согласно процедуре ASR (и для того, чтобы все работало как надо), необходимо было вложить много усилий в построение и настройку надлежащей сетевой инфраструктуры. Со стороны Infopulse, этой задачей занималась отдельная команда, которая должна была обеспечить хорошую связь между локальными и облачными серверами, а также с софтом для Azure, позволяющим видеть виртуальные машины. Нам необходимо было сделать полный дизайн, все нарисовать, нарезать сеть, организовать связь, и так далее. Помимо этого, мы также внедрили сервис Microsoft ExpressRoute, с помощью которого локальная сеть расширяется до виртуальных сетей Azure. Все это заняло около двух месяцев. Только после этих всех процедур мы смогли вынести часть серверов Active Directory, начали строить сервисы и переносить данные в Azure.
Вывод: миграция – это не просто перенос данных. Такие проекты подразумевают усовершенствование множества других, казалось бы, отлично работающих компонентов.
3. Инвентаризация и документация – два критически важных шага.
Еще один важный шаг перед миграцией – это проведение процесса инвентаризации серверов. При миграции крупного дата центра нам необходимо работать с сотнями серверов, отвечающих за работу самых различных сервисов и систем. Какие сервера отключать, какие переносить в другие дата центры, а какие мигрировать – без инвентаризации и последующей документации этого не выяснить.
Для того, чтобы разобраться во всем детально, необходимо наладить коммуникацию с владельцами каждого сервера и провести пилотную миграцию на простеньких и никому не нужных серверах. Именно так мы и сделали, параллельно работая над планом миграции. Этот подробнейший документ описывает все детали этого процесса, вплоть до того, какую кнопку нажать, какой IP-адрес поменять, и что восстановить – шаг за шагом.
После серии предварительных тестов, мы смогли наконец подобраться к продуктивным серверам и провести их полную инвентаризацию: что на них работает, какие сервисы, какие приложения, определить степень важности и приоретизировать по очередности, разделяя сервера на лоты согласно их критичности. Только после этого мы смогли приступить к миграции серверов.
Вывод: хорошо налаженная коммуникация помогает решить даже самые сложные проблемы. Без надлежащего понимания ролей и вовлеченности в процессе всех сторон степень успешности выполнения задач резко падает.
4. Устаревшие системы и сервера требуют особых подходов.
Миграция серверов потребовала от нас вырабатывать множество нестандартных подходов и приемов.
Одной из сложностей, с которой мы столкнулись – было организовать процесс миграции так, чтобы наша работа никак не отразилась на рабочих процессах клиента. Иными словами, мигрировать крупные сервера в рабочее время было нельзя, ведь это могло повлиять на доступность сервисов. Поэтому нашей команде иногда приходилось работать в не бизнес-время.
Но были и куда более сложные нюансы, оказавшие влиявшие на течение всего проекта миграции. К примеру, множество серверов было настолько старыми, что они не поддерживались программным обеспечением, применяемым для миграции. Чтобы смигрировать неподдерживаемый сервер (например, Windows 2003) из VMware в Azure, нужно было провести дополнительную конвертацию:
Сначала мы использовали инструмент MVMC от Microsoft, чтобы перенести виртуальную машину VMware в виртуальную машину Mircrosoft Hyper-V.
И только после этого Azure поддерживает переезд такой машины с онпрема в Azure.
Обе операции требуют даунтайма.
Еще один пример: у пользователей одного древнего приложения должен был быть статический MAC-адрес, иначе приложение переставало работать. В Azure пока что нельзя развернуть сервис со статическим MAC-адресом. Пришлось оставить такие сервера как есть.
К тому же, при переезде менялся IP-адрес серверов, что также добавляло нюансы.
Весь процесс выглядел следующим образом:
К тому же далеко не все данные поддавались переносу, поэтому и не все сервера можно было мигрировать в Azure – частично из-за того, что это крайне сложно сделать. В некоторых случаях нам пришлось воссоздавать сервера и базы данных с нуля вручную, но зато без ошибок и очень аккуратно.
Вывод: каждый кейс – уникален. Нет таких единых универсальных подходов, которые можно было бы применить повсеместно, зачастую даже в рамках одного проекта.
5. Миграция – ресурсоемкий проект. Но результаты оправдывают вложения.
Подобные изменения показательны в том плане, что требуют множество усилий и ресурсов от всей компании. Инфраструктура нашего клиента была слишком уж устаревшей по всем техническим показателям. И с этим огромным количеством старых серверов нужно было срочно что-то решать, чтобы не думать о затратах на поддержку, настройку и замену запчастей. Мало того, системы постоянно и регулярно падали, а чинить и оплачивать время простоя значительно дороже, нежели вынести все в облачный сервис.
В результате, наш клиент получил глобальную экономию ресурсов и ускорение всех процессов. Столь глобальное обновление инфраструктуры стоит рассматривать не как затраты, а исключительно как инвестиции в развитие бизнеса, которые довольно быстро окупают себя. Помимо того, что облако упрощает и автоматизирует многое из того, что ранее делалось вручную, Azure также предоставляет очень удобную статистику. Тут все прозрачно - учитывается каждый гигабайт. Если вы считаете, что облачный сервер стал «занимать слишком много места» и потреблять слишком много средств, его можно временно отключить. Это в высшей степени удобно, ведь в этом случае можно не платить за этот сервер, а данные при этом сохраняются.
Вывод: не стоит засиживаться на старых технологиях. Принцип «если что-то работает - не трогай это», может в результате больше навредить, чем принести пользы, ведь рынок и темпы его развития диктуют свои условия.
Подводя итоги
Успех этого проекта был критически важен для бизнеса нашего клиента. Теперь, благодаря построению гибридной инфраструктуры Azure, в облаке размещаются большинство серверов и сервисов, связанных с Active Directory, а также сотни бизнес-приложений. При этом менеджмент многих сервисов до сих пор происходит в онпреме, что добавляет гибкости возможностям управления. Благодаря миграции, нам удалось консолидировать тысячи пользователей, ускорить процессы и автоматизировать множество задач. Все новые сервера будут создаваться сразу в облаке.
Немного статистики:
Что же дальше? Проект миграции дата центров успешно продолжается. А учитывая размеры бизнеса нашего клиента, нам предстоит еще много совместной работы.
Вместо постскриптума
Можем смело вас заверить – решить можно любую задачу даже в самых сложных случаях. Каким бы большим и сложным ни был ваш бизнес, нужно не бояться проводить изменения. Помните – технологии – это в первую очередь инструмент, и в правильных руках – это залог вашего успеха.
Об Infopulse
Компания Infopulse, часть скандинавской группы IT-компаний EVRY ASA – поставщик услуг и решений в сегменте высоких технологий, работающий на международном рынке с 1991 года. Больше информации – на официальном веб-сайте компании www.infopulse.com.