Миграция ЦОД — не новая история. Казалось бы, про важность обследования инфраструктуры перед переездом уже знают все. Но на практике ошибки повторяются снова и снова — даже у тех, кто делает это не впервые.

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

Миграция ЦОД – это всегда серьезный вызов для любой IT-инфраструктуры. И подходы к её реализации могут быть совершенно разными.

Классика жанра перед переездом ЦОД
Классика жанра перед переездом ЦОД

Как правило, процесс миграции можно разбить на три ключевых этапа

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

  1. Проектирование целевой архитектуры. Разработка оптимальной конфигурации оборудования и сетевых сервисов в новом ЦОД с учетом требований к производительности, отказоустойчивости и масштабируемости.

  2. Непосредственно миграция. Комплексный перенос оборудования, сервисов и приложений в новый ЦОД с обеспечением соответствия целевым показателям SLA.

Стоит отметить, что способ реализации третьего этапа может отличаться кардинально. Можно пойти по пути наименьшего сопротивления – остановить сервисы, перевезти железо и запустить всё заново. Это, безусловно, простой и рабочий вариант, но и самый болезненный для заказчика: бизнес в это время буквально ложится на бок.

Альтернативный подход – бесшовная миграция, когда сервисы продолжают работать во время переезда. Конечно, это и более сложная задача: нужно оценить масштаб бедствия (или, наоборот, убедиться, что все не так страшно) и подготовить почву для успешного переезда. 

Сегодня мы подробно рассмотрим первый этап – обследование инфраструктуры. Ведь, как известно, семь раз отмерь…

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

Итак, обследование состоит из следующих этапов:

  1. Определяем объем работ. Решаем, что именно нужно обследовать и в каких границах.

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

  3. Сбор данных по коммутации. Переезд — не повод терять связи, особенно сетевые.

  4. Обследование старой площадки. Это о проверке текущего состояния. Главное, чтобы на этом этапе не выяснилось, что «по документам» и «в реальности» — это две разные инфраструктуры;

  5. Обследование новой площадки — оценка её готовности к развертыванию инфраструктуры;

  6. Формирование итогового отчета — фиксируем всё, что нашли и сделали.

С чего начать обследование, чтобы не пришлось начинать заново?

Для начала нужно определить, сколько оборудования предстоит перевезти. Здесь понадобится подробный список с указанием моделей и серийных номеров. Дальше выясняем, где всё это добро физически находится. И вот тут часто возникает самое интересное: за разные куски инфраструктуры отвечают разные люди. Поэтому еще до физического обследования лучше собрать актуальную информацию у всех ответственных лиц о расположении оборудования и его подключениях (LAN, SAN, MGMT). 

Как показывает практика, точные сведения о расположении и коммутациях встречаются крайне редко. Ответственные сотрудники обычно лишь пожимают плечами и говорят: «Так всё и досталось!». В такой ситуации стоит сразу закладывать время не на проверку, а на полноценный сбор данных.

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

Ошибка №1: не вести кабельный журнал
Ошибка №1: не вести кабельный журнал

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

На фото кабельный журнал здорового инженера. Кабельный журнал курильщика не пережил миграцию
На фото кабельный журнал здорового инженера. Кабельный журнал курильщика не пережил миграцию

Еще одно препятствие на пути к качественному обследованию – опрятность коммутации. Тут, как правило, встречаются три варианта:

Первый: когда приятно смотреть. Второй: когда лучше не смотреть. Третий: когда не можешь не смотреть т.к. реально интересно на чём оно тут держится.
Первый: когда приятно смотреть. Второй: когда лучше не смотреть. Третий: когда не можешь не смотреть т.к. реально интересно на чём оно тут держится.

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

Ошибка №2: недооценить состояния кабельной инфраструктуры.

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

Пример, где совпали сразу две классические ошибки.

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

Кабель-менеджмент? Не слышали! Или: вот как это было
Кабель-менеджмент? Не слышали! Или: вот как это было

Ну ладно, посмеялись — теперь к делу. Что именно нужно записывать, чтобы потом не искать концы (в буквальном смысле)?

  • Номер стойки: уникальный идентификатор стойки, в которой размещено оборудование. Номер стойки позволяет точно определить физическое расположение оборудования в ЦОД. Убедитесь, что используемая система нумерации стоек понятна и последовательна, например, буквенно-цифровая (A1, A2, B1, B2) или цифровая (1, 2, 3, …).

  • Юнит: позиция оборудования в стойке (например, 1U, 2U, 4U). Если оборудование занимает несколько юнитов, необходимо указывать номер самого нижнего юнита, который оно занимает.

  • Высота: общая высота оборудования в юнитах (U). Указывается отдельно от расположения (юнита), так как это упрощает дальнейшую работу с данными. Раздельное указание этих параметров позволяет легко фильтровать и анализировать информацию, например, для оптимизации размещения оборудования в стойках.

  • Интерфейс: тип и номер интерфейса подключения (например, LAN 1 порт 1, SAN 2 порт 4). Описывается тип и номер сетевого адаптера. В зависимости от системы и производителя интерфейс подключения может отличаться.

  • Порт: номер порта на оборудовании, идентифицирующий конкретный физический разъем для подключения кабеля (например, eth0, fa0/1, fc1). Указывать стоит полное и точное обозначение порта, как оно отображается в настройках оборудования (например, Ethernet1/1 вместо 1/1).

  • Скорость порта оборудования: скорость передачи данных, поддерживаемая портом, указывающая на максимальную пропускную способность канала связи. Указывайте скорость порта в принятых единицах измерения (например, 1 Gbps, 10 Gbps, 40 Gbps). При наличии нескольких скоростей (например, 1/10 Gbps), укажите все поддерживаемые значения.

  • Тип подключения: физический тип подключения, определяющий конструктивное исполнение разъема и используемую среду передачи данных (например, RJ45, SFP+, QSFP+, MMF, SMF, BNC). Укажите тип разъема, используемого для подключения оборудования к сети или другим устройствам.

  • Конечный порт коммутатора: номер порта на коммутаторе, к которому подключено оборудование, позволяющий отследить соединение между оборудованием и сетевой инфраструктурой. Укажите полное имя коммутатора и номер порта, как они отображаются в системе управления сетью (например, switch1:ge1/1, switch2:te0/5).

  • Мощность блока питания: номинальная мощность блока питания, определяющая максимальную потребляемую мощность оборудования. Укажите мощность в ваттах (W) или киловаттах (kW). Примеры: 500W, 750W, 1.2kW. Для оборудования с резервными блоками питания укажите мощность каждого блока питания отдельно и общее количество блоков (например, 750W x 2).

Все полученные данные собираем в архив для дальнейшего анализа
Все полученные данные собираем в архив для дальнейшего анализа

Обследование новой площадки: готовим плацдарм для переезда.

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

Ошибка №3: неполная информация о новой площадке.

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

Когда я только начинал работать с проектами по миграции, опыта, мягко говоря, не хватало. Какие-то мелочи казались несущественными — а потом именно эти мелочи превращались в большие проблемы, которые приходилось решать на месте в срочном порядке. Так, например, однажды мы не учли расстояние между стойками. В итоге часть оборудования просто не смогли скоммутировать, и нам пришлось тасовать железо по стойкам, переставлять блоки и пританцовывать вокруг кабелей: пока всё наконец не сошлось (с такой миграцией абонемент в спортзал становится неактуален). 

Что нужно зафиксировать на новом месте:

  • Заполненность стоек и расстояние между ними;

  • Количество свободных портов в каждой патч-панели (если они есть). Если мы говорим про пустой машинный зал, то проблем не возникнет. А вот при обследовании действующего ЦОДа нужно актуализировать информацию о заполненности стоек, чтобы понимать, куда размещать оборудование;

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

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

 Ошибка №4: отсутствие патч-панелей. Это может привести к проблемам при замене кабелей, увеличению времени коммутации, риску повреждения портов.

По личному опыту могу сказать, что патч-панели сильно упрощают жизнь во время коммутации. С ними мы чаще всего используем кабели длиной 2 и 3 метра. Без патч-панелей коммутация превращается в сущий кошмар. Приходится использовать 5-15 метровые кабели. Все излишки укладываются петлями на лоток и наслаиваются друг на друга. В будущем замена какого-либо кабеля превращается в большую проблему. Чтобы такого не происходило, я очень советую использовать патч-панели в каждой стойке, и тогда очередная замена кабеля не будет превращаться для вас в квест с высотными работами.

Ошибка №5: Игнорирование энергопотребления оборудования.

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

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

Собираем все воедино и формируем отчет

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

Таблица обследования старой площадки, содержащая:

  • серийный номер;

  • модель;

  • имя;

  • интерфейсы;

  • порты;

  • скорость портов;

  • тип подключений;

  • целевые подключения;

  • мощность БП;

  • расположение;

  • высота для каждой единицы оборудования.

Таблица обследования новой площадки, содержащая:

  • список всех стоек;

  • заполненность стоек;

  • заполненность патч-панелей;

  • нагрузка на стойку по энергопотреблению;

  • расположение и заполненность портов коммутаторов (если помещение уже используется).

Карта местности перед погружением в новый ЦОД
Карта местности перед погружением в новый ЦОД

Инструменты для оформления документации

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

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

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

Ну и напоследок, пример чек-листа для обследования инфраструктуры в ЦОД.

Этот чек-лист — мой стартовый набор пунктов, с которого обычно начинается аудит. Дальше его можно расширять под конкретный проект.

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

Чек-лист: версия 1.0
Чек-лист: версия 1.0

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

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

Расскажите в комментариях, какие инструменты для аудита вы считаете самыми эффективными? Какие нестандартные ситуации возникали у вас при миграции ЦОД? И какие «грабли» вы советуете обходить стороной?