Переезд инфраструктуры — задача, которую почти всегда считают логистической. Пришли такелажники, аккуратно перевезли, включили, разошлись. На практике перевозка — самая короткая и самая предсказуемая часть работы. Всё интересное происходит до неё и после.
В конце августа у нас совпали два переезда. Первый — перенос программно-аппаратного комплекса с нагрузкой в виде баз данных Oracle из одного машинного зала в другой. Второй — переезд офиса, где две стойки с двух этажей съезжались в один шкаф на новой площадке. Разница в классе оборудования очевидна. Гораздо интереснее другое: стратегии переноса получились принципиально разными, и дело не в бюджете.
Постановка
Два объекта, одна неделя
Оборудование разного класса, но стратегия в обоих случаях определялась одним вопросом — что здесь вообще можно продублировать заранее.
Начнём с того, что переносили, — без этого дальнейшие решения выглядят произвольными.
Объект первый. Два шкафа программно-аппаратного комплекса с нагрузкой в виде баз данных Oracle, три отдельных комплекса меньшего типоразмера того же класса и сетевое ядро. Исходный и целевой машинные залы находятся в разных зданиях на расстоянии около 150 метров, по внутренней территории. Новые шкафы предоставил заказчик, исходные оставались на месте — то есть оборудование не переезжало «вместе со стойкой», а разбиралось и собиралось заново.
Объект второй. Офис: две стойки, которые нужно свести в один шкаф 42U на новой площадке. Внутри — головной маршрутизатор, три коммутатора агрегации, коммутаторы доступа, коммутатор 10G, шесть патч-панелей, восемь точек Wi-Fi, телефонная платформа в отказоустойчивой паре плюс вторая, отдельная, и четыре сервера: три узла с офисными сервисами на Proxmox и сервер резервного копирования. Плюс источники бесперебойного питания и блоки распределения. В итоговой компоновке занято около 27 юнитов из 42.
Оба переезда делала одна и та же команда с разницей в пару дней, и это оказался полезный эксперимент. Одни и те же инженеры, один и тот же подход к планированию — а решения на выходе противоположные. Значит, дело не в предпочтениях исполнителя и не в размере бюджета, а в условиях, которые сложились задолго до того, как кто-то вообще заговорил о переезде.
Ключевое различие — не размер и не цена. У первого объекта уже была настроена репликация между двумя комплексами. У второго не было ни второй площадки, ни дублирования сервисов, зато была возможность подготовить новую площадку заранее и целиком. Это и определило обе стратегии.
Комплекс с базами данных
Переносим роль, а не оборудование
Первым едет тот комплекс, который в этот момент резервный. Пользователи замечают только переключение ролей.
Между двумя комплексами первого объекта работала штатная репликация Oracle в режиме Active/Standby. План строился вокруг неё.
Сначала переносится тот комплекс, который в момент работ выполняет роль резервного: его остановка на пользователей не влияет вообще никак. Комплекс разбирается, перевозится, собирается в новом шкафу, включается, проверяется, догоняет накопленные архивные журналы и возвращается в строй как резервный. Затем — переключение ролей. Бывший резервный становится основным, бывший основной — резервным, и теперь уже он едет в новый зал по той же схеме.
Как это выглядело по времени. Перенос первого комплекса занял 10 часов 55 минут и был выполнен единым заходом, без разбивки на смены. Переключение ролей — 8 минут. Второй комплекс переехал на следующий день и уложился уже в 9 часов: все накладки первого захода к этому моменту были известны и учтены. Ни разу за эти три дня база данных не была недоступна целиком: единственное окно, которое могли заметить пользователи, — те самые восемь минут.
Комплексы меньшего типоразмера переносились иначе. Репликации у них нет, зато есть другая особенность: на них живут тестовые базы и среды разработки. Полная остановка возможна только в выходные — чтобы в рабочие дни разработчики могли нормально работать. Так дата окна определилась не графиком работ и не наличием бригады, а календарём команды разработки. Само окно отработали дисциплинированно: штатный останов, фиксация состояния, перевозка двумя партиями, сборка, включение в обратном порядке и поштучная проверка. Порядок партий выбирался не по удобству погрузки, а по тому, что должно подняться первым.
Не всё прошло гладко. При переключении ролей не поднялся поток на одну из нод — пришлось вручную создать журнальные файлы и перезапустить ноду. Плюс по ходу работ появилось требование, которого не было в исходных вводных: очищать и продувать оборудование перед заносом в чистый машинный зал.
Про людей. Отдельный ресурс, который надо планировать наравне с техникой, — инженеры с реальным опытом именно таких комплексов. У нас на переносе работали два удалённых инженера по Oracle: консультации и удалённая поддержка на всех этапах. Важно, что в начале того же августа они уже делали такой же перенос у другого заказчика, где с места на место переезжали сразу три комплекса. Свежий опыт стоит дороже любой инструкции: человек, который проходил эту процедуру три недели назад, знает, где она обычно спотыкается, и не тратит на выяснение технологическое окно.
Подготовка и сроки
Критический путь оказался не в такелаже
Закупка недостающего и режим доступа на площадку длиннее самих работ на два порядка.
Теперь про то, что действительно съело сроки. Ни один из реализовавшихся рисков не был связан с перевозкой.
Целевой зал. Ни заказчик, ни мы изначально не знали, что в новом машинном зале с розетками, кроссами, портами и длинами. Пришлось добавлять в план отдельный этап обследования, а по его итогам — закупку недостающих кабелей, трансиверов, переходников и розеток. Здесь повезло: всё нашлось и было куплено за пять дней. Но это везение, а не норма — трансивер или переходник нужного типа может ехать и месяц, и тогда именно он определит дату переезда.
Полнота вводных. План работ пересчитывался четыре раза, и дело не в арифметике. Каждая редакция появлялась после того, как выяснялось что-то новое: состав целевого зала, порядок партий перевозки, кто именно допущен на площадку, в каком режиме идут работы. Первая версия любого плана переезда оптимистична ровно настолько, насколько неполны исходные данные, поэтому длительности в ней стоит считать черновиком, а не обязательством.
Допуск людей. Отдельная строчка, о которую спотыкаются почти все. В плане роль такелажной бригады была записана как «исполнитель или привлекаемый подрядчик». На режимный объект сторонних грузчиков не пускают — значит, тяжести двигают те же инженеры, которые потом собирают комплекс, и это надо закладывать и в график, и в состав бригады.
Baseline и маркировка
Что зафиксировать до того, как взяли отвёртку
Отчёт о состоянии защищает обе стороны, а собственная маркировка — единственное, чему можно доверять при сборке.
До начала работ мы сняли полные диагностические отчёты по обоим комплексам. Это дало две вещи сразу.
Первая — список дефектов, которые существовали до нас. Не установлены патчи ядра без перезагрузки, некорректно сконфигурирована энергонезависимая память на ячейках хранения, вышел из строя конденсатор кэша на одном из контроллеров, патчи не зарегистрированы в самой базе, выключен flashback, на одном из серверов почти закончилось место в системной группе томов. Общая оценка состояния — 92–93 балла из 100, что для комплекса такого возраста неплохо. Но три критических замечания в каждом кластере были.
Вторая — защита от разговора «после вашего переезда у нас перестало работать». Если оно не работало и до переезда, это видно в отчёте с датой. Заказчик при этом получает честную картину состояния своего комплекса бесплатно и до того, как что-то сломается. Если снимать такой отчёт после работ — он уже ничего не доказывает.
Теперь про маркировку, и это не мелочь. Главное правило: не доверять существующей маркировке. Вы никогда не знаете, кто и сколько раз пересобирал или переносил этот комплекс до вас, соответствует ли фактическое подключение портовой карте из документации и не переставляли ли что-то «временно» три года назад.
Поэтому порядок такой. Сначала фиксируем фактическое состояние — фотографии шкафа с обеих сторон, схема портов как есть, а не как в документе. Потом маркируем сами, заново, и клеим на всё: на оборудование, на кабели, на патч-панели, на розетки питания. Маркировка должна быть максимально простой и однозначной, чтобы её понял человек, который видит этот шкаф впервые. Каждый кабель маркируется с обеих сторон, и на бирке — куда он воткнут: юнит, порт, розетка, позиция. Не «uplink-2», а конкретное место назначения.
Вы никогда не знаете, кто и сколько раз пересобирал этот комплекс до вас.
Это скучная работа на несколько часов. Она окупается ровно один раз — когда на новой площадке что-то не поднялось и надо за минуту понять, тот ли кабель в том ли порту.
Расходники
Кабели переезд переносят по-разному
Что едет как есть, что осматривается поштучно, а что заменяется новым без обсуждения.
Отдельная тема, на которой экономят чаще всего, — расходники. Кабель кажется вечным, пока не начинает подводить под нагрузкой.
Медные DAC на 100 гигабит для фабрики RoCE переезд и перетыкание переносят спокойно: они короткие, жёсткие, разъём цельный. Достаточно осмотреть разъём и защёлку. А вот DAC на 10 и 25 гигабит требуют отдельного осмотра каждого экземпляра: они тоньше, легче заламываются, фиксаторы вытягиваются. Медные патч-корды cat5e и cat6 — туда же: смотрим на изломы, продавленную изоляцию, поломанные защёлки.
С многомодовой оптикой OM3 и OM4 разговор короткий: при переезде она меняется на новую. Микроизгибы копятся годами эксплуатации, клей и пластик рассыхаются от температуры в горячем коридоре, а разборка и протяжка добавляют свою долю повреждений. Проблема ещё и в том, что такой патч-корд не отказывает честно и сразу — он даёт растущее количество ошибок под нагрузкой, и причину будут искать где угодно, только не в нём.
Лучше выкинуть дешёвый расходник, чем потом ловить плавающую деградацию на критической системе.
Лучше выкинуть дешёвый расходник, чем потом ловить плавающую деградацию на критической системе. Это, пожалуй, единственное место в переезде, где экономить совсем нечего.
Офисный переезд
Офис: один заход на подготовленную площадку
Реплики нет, отката нет. Значит, вся страховка уходит в подготовку площадки — и она больше самого переезда.
Теперь второй объект. Здесь нет второй площадки и нет репликации сервисов. Роль одна, переключать нечего.
Мы рассматривали вариант с подменным фондом: временно поставить на старом месте коммутаторы из резерва, а целевые увезти вперёд и поднять на новой площадке заранее. От идеи отказались. Не хотелось размазывать рабочую конфигурацию по двум комплектам, настраивать всё дважды и всё равно везти актуальные железки следом. Решили перевозить сразу актуальную конфигурацию, целиком, одним заходом.
Это значит, что отката нет. Переезд необратимый: за один день оборудование снимается со старой площадки, перевозится, монтируется и запускается на новой. Раз отката нет, вся страховка переносится в подготовку — и подготовка тут больше самого переезда.
Основная работа — кабельная система. Новая СКС на площадке строилась заранее, полностью, вплоть до розеток в рабочих столах, силами бригады монтажников. Отдельным сюжетом шёл разбор фальшпола, под которым была протянута старая проводка. Вся новая система сведена в шесть 24-портовых патч-панелей в одном шкафу — и это, если честно, главный результат переезда: раньше кроссировка была размазана по двум стойкам, теперь она в одном месте и читается.
К приезду оборудования розетки в столах уже работали, трассы были прозвонены и промаркированы, а в шкафу оставалось смонтировать активную часть и воткнуть кроссировку по готовой схеме. Поэтому переезд и уложился в день.
Две стойки в одну — это пересборка, а не сложение. Считать пришлось заново: юниты, порты, потребление, вес, тепловыделение и длины патч-кордов. Компоновка собирается с нуля и по правилам: патч-панели сверху, активное сетевое оборудование под ними, телефония ниже, серверы в нижней трети, источники бесперебойного питания в основании — два по два юнита.
Отдельно — про свободное место. В середине шкафа сознательно оставлен непрерывный блок примерно в 13 юнитов. Не потому, что не влезло, а потому, что через год-полтора туда встанут новые серверы, и разносить их по огрызкам свободного пространства не хочется. Свободные юниты в новом шкафу — не потери, а единственный дешёвый способ купить себе следующий апгрейд без ещё одного переезда.
И про связь. Услуг у оператора было четыре, и каждая переносится отдельно: интернет для офисных сервисов и пользователей; отдельный канал под Wi-Fi; основная телефония в отказоустойчивой конфигурации; вторая телефонная линия для второстепенных обращений. Схема рабочая и предсказуемая, если заявки поданы заранее: оператор протягивает оптику на новую площадку до переезда, а само переключение услуг делает по факту, в день работ. Ключевое слово — заранее. Заявки уходят первыми, до того как назначена дата, а приёмка идёт не по формулировке «услуга активирована», а по факту «звонок прошёл, канал держит нагрузку».
Чек-лист
Что спросить до того, как назначать дату
Одиннадцать вопросов, которые превращают дату переезда из пожелания в обоснованный план.
Итог
Вместо вывода
Стратегии выглядят разными, но обе сводятся к одному правилу: рискованный момент надо чем-то накрыть заранее. Отличается только то, чем именно. В первом случае — репликацией, которую настроили задолго до нас. Во втором — подготовкой площадки: кабельной системой, доведённой до розеток в столах прежде, чем приехала первая стойка.
Отсюда неприятный для планирования вывод: возможность спокойно переехать закладывается не в момент переезда. Если реплики нет и площадка не готова, никакая бригада не сделает переезд бесшовным — можно только сократить окно и заранее решить, чем вы рискуете.
И в обоих проектах критический путь лежал вне перевозки: там — закупка кабелей и трансиверов, здесь — монтаж кабельной системы и заявки оператору. Обе позиции измеряются неделями, тогда как сами работы — часами. Поэтому разговор о переезде правильно начинать не с вопроса «когда приедет машина», а с вопроса «что мы ещё не знаем про целевую площадку».