Миграция ЦОД, или взгляд на переезд со стороны ИТ

Мы планируем переезд! Новый офис будет современнее, удобнее, красивее и больше. Хорошая новость для сотрудников, но непростая – для айтишников.  В этой статье решили разобрать ключевые вопросы переезда со стороны ИТ-оборудования и ПО: какие миграции бывают, на что нужно обратить внимание и как справляться с некоторыми трудностями. Причём предлагаем расширить тему: переезд не всегда связан с перемещением именно пользователей, персонал может остаться в том же офисе, но оборудование и системы по каким-то причинам мигрировать нужно. Вот об этом поговорим.

На простом языке миграция ЦОД — это и есть переезд. Он может происходить на двух уровнях: физическом («железо») и логическом (ПО), а может объединять и тот и другой. Таким образом, все миграции ЦОД можно разделить на три типа. Мы пойдем от простого к сложному.

Физические переезды

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

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

Кстати, такое бывает реже: далеко не все бизнесы работают 24/7 и предоставляют услуги B2C, функционируют в формате цифровой дистрибуции и т.д. Главное при таком типе переезда — с пониманием дела перевезти оборудование. То есть точно нужно:

• правильно изучить исходные наборы оборудования и площадку

• тщательно обследовать целевую площадку и посмотреть, хватит ли места в стойках

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

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

Оборудование не всегда легко выключить. У него есть определенные процедуры, особенно если мы говорим про какое-то серьезное High-End-оборудование. Соответственно, всё выключается, декоммутируется, все провода вытаскиваются, всё демонтируется.

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

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

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

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

Логические переезды

Второй тип переездов связан с переносом данных — это ключевая задача, а конфигурации на уровне оборудования могут быть любыми. Например, вы приобрели какие-то новые «железки», пусть будут хранилища (СХД). У вас система как работала, так и работает, но нужно переехать со старой на новую. Или ситуация, когда у клиента система так работает в некоем распределенном режиме в разных ЦОДах, но снизу всегда есть место хранения. Оно почти всегда одно, потому что с точки зрения ограничений записи — всегда есть точка, которая является мастер-данными. И вот владелец хочет эти мастер-данные перенести со старой СХД. «Железка» или целый комплекс — это неважно. Нужно перенести объект как сущность, хранилище, на новое. Такая миграция может происходить внутри ЦОДа, между ЦОДами, между странами — это неважно. При таком типе переезда важно то, что чаще всего отсутствуют работы на физическом уровне с оборудованием, потому что есть старое оборудование и новое.

Помимо этого, почти всегда есть требования, что переезд должен происходить вообще без прерывания сервиса и без прерывания доступа к данным. Такие ограничения присущи онлайн-сервисам, процессингу в банках, каким-то карточным историям в программах лояльности — в общем, тем, что работает 24/7. При этом данные мигрировать надо, потому что старое хранилище заканчивается, ломается или что-то ещё нехорошее с ним происходит. В таких случаях самое сложное — это продумать, как осуществить переезд с одного хранилища на другое так, чтобы системы, которые эти данные используют, ничего не заметили. И тут масса вариантов.

Так, если мы говорим о базе данных, то у самой БД есть ряд инструментов, которые позволяют создать ее копию, перенести все данные, а потом в какой-то момент относительно быстро и с коротким перерывом переключить нагрузку систем на новую локацию. Такой локацией может оказаться новая «железка», новый ЦОД, новая страна. Если это какие-то абстрактные данные, то есть не конкретная СУБД, а какие-то абстрактные данные, и снизу меняется «железка» или комплекс «железок», который это все реализует, тогда продумываются истории с репликацией низкого уровня — хранилища данных.

Есть пример: требовалось перевезти хранилище высокого класса, которое поддерживало active-active-репликацию. Записи проходили справа налево и слева направо одновременно в онлайн. В реальности стоит одно хранилище, где лежат все данные, и которое поддерживает одну из технологий active-active-репликации. В целевой локации ставится такое же или совместимое хранилище и объединяется в репликационную пару. Это позволяет взять локальные LUN первой СХД и растянуть их в распределенные LUN, которые в свою очередь поддерживают одновременную запись с двух сторон и двунаправленную репликацию. Выполнив все условия создания такой сущности, объединив их в некий репликационный кластер, их называют по-разному. Не важно, первое сейчас устройство работает или второе, для системы это будет прозрачно. Пока хотя бы одно из них работает, будет прозрачно: таким образом можно данные из первого устройства перенести во второе незаметно для систем, потом первое выключить, а системы продолжат работать во втором. Это называется перенос данных.

На самом деле вариантов много. Так, в случае с виртуальными машинами (абстрактные сущности), существует множество технологий. Они позволяют переносить виртуальные машины (далее – ВМ) с места на место так, чтобы системы, которые работают внутри ВМ, и системы, которые взаимодействуют вокруг, ничего не заметили, пока происходит переезд в другую систему, ЦОД или страну. Существуют даже целые идеологии, которые продвигали зарубежные крупные вендоры, — follow the moon, follow the sun. Их смысл заключается в том, что если у вас транснациональная компания и есть цепочка ЦОДов по всему миру, around the globe, то вы максимально локализуете трафик. Вы можете уносить данные, системы, виртуальные машины и все остальное от пользователей максимально далеко, в ту часть земного шара, где сейчас ночь и где самое дешевое электричество, при этом люди будут работать в светлое время суток и тем самым экономить. Переносим данные — нужно исходное и целевое «железо» — это минимальное требование.

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

Переезды ИТ-систем

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

Самые часто встречающиеся кейсы — это когда построены или арендованы новые ЦОДы и туда планируется переезд. При этом бизнес такой большой и зависимый от ИТ, что он не может выключить все на выходные или на пять дней, перевезти на физическом уровне и включить. Или, например, планируется переезд со старого оборудования на новое, но целиком. Либо нужно, чтобы информационная система, которая сейчас работает на двух серверах, переехала в новый ЦОД. Благодаря этому два сервера в основном ЦОД превращаются в четыре: 2 в ОЦОД и 2 в РЦОД (резерв). Одним словом, когда у тебя накапливается какой-то набор изменений, самый простой способ их все разом применить — это заново развернуть систему в новой инфраструктуре.

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

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

Второй отягчающий фактор встречается, когда люди переезжают, потому что отделяются от головной компании, например, и создают собственную ИТ-инфраструктуру. В таких случаях меняется IP-адресация, домен, авторизация, порядок именования объекта, да что угодно. При этом применяется собственная техническая политика, которая определяет стандарты версии операционных систем, СУБД и т.д. Конечно, такой переезд — это, по сути, пересоздание всех систем в новых ЦОДах, в новой инфраструктуре. И подобную активность никак нельзя рассматривать как новый цикл внедрения систем. Они давно работают, в них накоплен объем настроек и данных, поэтому это именно миграция. Когда построены новые ЦОДы и есть понимание, что от всего старого оборудования нельзя отказаться, и докупается некий пул, например 30%, то освобождаются старые 30%, переносится часть своих систем, данных виртуальных машин на новые, добавляются в общий пул, выключаются старые мощности.

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

Когда готовится посистемный план миграции, необходимо подумать обо всем:

• из чего состоит система

• из каких серверов состоит

• где эти серверы лежат, физические и виртуальные

• где лежат их данные

• какие есть между ними дополнительные компоненты, файловые шары и т.д.

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

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

Если забираешь старые виртуальные машины либо сервер, нужно подумать:

• как эти старые компоненты со старыми прошивками, со старыми версиями лягут в новую инфраструктуру;

• обновление до новых версий и могут ли они обновиться до новых версий;

• готовность держать в своей новой и чистенькой современной инфраструктуре старые куски и чем это будет грозить.

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

Все это значит, что в моменте планирования большой миграции надо подготовить запасные пути, какие-то «костыли», потому что переехать целиком на новую адресацию сразу точно не выйдет. Что делать? Сохранять связи со старым ядром, инфраструктурой, забирать маленькие кусочки сетевой адресации, забирать старое именование. Это может сильно помочь, если, допустим, появляются проблемы в именах: не всегда можно поменять имя у сервера, либо у соседнего компонента, либо у сервиса, который тоже опирается на DNS A-запись, либо не получается создать Alias, чтобы сохранить старое имя, не сохраняя старое имя, и т.д. Практически ни одна крупная компания не переехала в таком формате в новую чистую красивую инфраструктуру целиком, у всех оставались «костыли» к старой инфраструктуре.

Миграция: как?

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

Так, очень часто возникает какая-то точка переключения. Грубо говоря, система работает в ЦОД А, ты поднял новую систему в ЦОД Б, перенес настройки, скопировал данные. В результате, есть исходная система и целевая точно такая же, даже лучше. Теперь нужно, чтобы пользователи перестали ходить в систему А и начали ходить в систему Б. Даже если точка входа в систему со всех сторон абстрагирована, где-то на внешнем балансировщике создана точка балансировки, куда приходят пользователи. Потом там идет технологический редирект через несколько слоев, и только тогда пользователи оказываются на системе, ничего, конечно, не зная о ее внутренних частях. В этом случае нужно как минимум в этой точке балансировки убрать старые серверы и добавить новые. Получается короткий период недоступности систем на время перенастройки точки балансировки, и пользователи ходить не смогут. Итого: немного работ в даунтайме, часть — вне его. И так по каждой системе — классика!

Есть менее классические подходы. Среди них встречаются случаи, когда приходится разбирать взаимосвязи системы, группировать их на какие-то глубоко связанные друг с другом группы — кусочки. Например, есть пять систем, которые реализуют какую-то одну бизнес-функцию. Они тесно друг с другом связаны, то есть выключение любой из них делает все остальные бессмысленными, цепочка рвется, бизнес не работает. Поэтому, если есть такие взаимосвязи, это обычно серьезная нагрузка на специалистов в самой компании, на технологов и тех, кто понимает бизнес-процессы.

На практике это происходит так. Представим, что у нас в час Х не будет работать функционал кредитного конвейера, потому что мы возьмем все системы, которые участвуют в автоматическом одобрении кредитов, и их перенесем из ЦОДа А в ЦОД Б. Мы понимаем, из чего они состоят, как они друг с другом интегрируются, что нужно в них поменять в зависимости от ситуации. После этого все системы разом подготавливаются, гасятся, переносятся или подготавливаются на новом месте и переключаются. Таким образом у нас происходит перенос группами. Такой тип переезда случается реже, потому что владельцы бизнеса крайне редко знают о всех взаимосвязях. Т.е. понятно, что есть система кредитный конвейер. Но это лишь одно звено, а ведь у него много источников данных, приемников данных и т.д. Целостное знание отсутствует, поэтому переносим по одной системе.

Третий способ миграции — это перенос ЦОДами. Данный тип тоже касается больших ИТ-инфраструктур со сложной взаимосвязью с работой систем 24/7. Но почему тогда не использовать другой тип? Тут появляется еще одно условие — вся инфраструктура на момент старта переезда имеет два контура. Условно, есть системы с резервным контуром во втором ЦОД, но нет нового набора железа в целевом ЦОД для посистемного перехода. Поэтому переезд происходит целиком ЦОДом и системы едут вместе с оборудованием.

Как это происходит? На двух площадках размещены полностью идентичные продуктивные контуры, и есть понятный механизм переноса нагрузки с площадки A на площадку Б и обратно. Тогда, например, если не покупать для новых площадок новое оборудование или покупать его в очень ограниченных количествах, придется использовать свою резервную инфраструктуру для переезда на уровне ЦОДов. Что это такое? Это когда есть два ЦОДа, 50–100 систем. Будем считать, что они все зарезервированы, все идеально, хотя так не бывает. Берем всю нагрузку пользователей, все подключения внешние и внутренние и переключаем, чтобы все это шло на площадку А. Убеждаемся, что площадка Б функционирует, но все ресурсы там, по сути, в пассиве. Проверяется это очень легко — нужно их выключить. Таким образом, когда все сделано, следующий шаг — это выключение и проверка, не перестали ли работать бизнес-функции и корректно ли все перенеслось. Обычно с первого раза не получается. Выключаем площадку, с которой снята нагрузка, и выходит – половина сервисов отъезжает. Выясняется: алгоритмы переключения у владельцев систем написаны не очень хорошо. Тогда включаем обратно, разбираемся, где что потеряли, корректируем алгоритмы.

По опыту, со второго или третьего раза точно получается. Зато мы точно можем спокойно на какое-то необходимое время избавиться от второй площадки. Безусловно, ИТ-инфраструктура в этот момент находится в аварийном состоянии без резерва. Но это допустимое зло. Если мы из двух ЦОДов в два переезжаем, мы подготавливаем два ЦОДа, связываем их друг с другом, со старыми ЦОДами, настраиваем. Cетевое оборудование в любом случае будет дублироваться. Все готовится заранее: покупаются необходимые объемы оборудования, чтобы минимизировать этот переезд, выключается ЦОД, с которого снята нагрузка, увозится, все там размещается, так же как в физическом переезде, планы коммутации, планы размещения и т.д. Все запускается. У нас ЦОД А1, который остался в старом месте, начинает работать с ЦОДом Б2, то есть ЦОД Б, но уже на новом месте. Все работает (проверяем). Затем всю нагрузку всех систем переносим, но теперь из ЦОДа А1, старого, в ЦОД Б2, уже новый. Снова убеждаемся, что все функционировало, как надо. Потом выключаем ЦОД А1, все идет по плану: увозим в ЦОД А2, включаем. Восстанавливаем все взаимосвязи, репликации обратно, догоняем, чтобы они снова стали синхронными, или заново синхронизируем. Всё, переехали двумя ЦОДами в два новых ЦОДа — стало А2, Б2.

Третий способ миграции по срокам самый короткий. Да, долгий процесс подготовки, много-много нюансов на самом деле, но в целом это намного быстрее, чем переезд по системам или группами. Все потому, что при переезде на уровне ЦОДа не нужно так глубоко разбираться в системах, в их составе и взаимосвязи. Конечно, при условии, что на момент старта работ все системы действительно симметрично зарезервированы в ЦОД А1 и Б1.

В целом это всё, что нужно знать о миграциях и трудностях при переезде.

ВЫВОДЫ

Подводя резюме, ключевое, о чём нужно помнить при миграции ЦОД:

1. Любой переезд – это сложный технологический процесс

2. Необходимо тщательное планирование

3. Необходимо следовать плану переезда

Следуя этим шагам, вы сильно облегчите себе жизнь и перевезёте весь ИТ-парк максимально бесшовно, независимо от масштабов компании. Но сроки важны всегда – чем больше времени у вас на подготовку, тем меньше рисков при переезде.