Меня зовут Рене, я сетевой инженер в FirstVDS. В прошлой статье я рассказывал, как мы переезжали из euNetworks в QupraDC и почему даже маленькую площадку полезно строить как нормальную фабрику, а не как одну большую коробку на всё.

Сначала я не планировал писать отдельную статью про второй переезд. Со стороны всё выглядело слишком похоже: снова Amsterdam, снова EVPN/VXLAN-фабрика, снова временная связность между дата-центрами и постепенный перенос серверов. Казалось, что получится пересказ той же истории другими названиями площадок.

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

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

Именно в процессе подготовки стало понятно, что это всё-таки отдельная история. В первом переезде у нас не было такого набора ограничений: временный Leaf упёрся в 48 портов, постоянный Leaf пришлось освобождать через перекоммутацию оставшихся серверов, Spine нельзя было просто выключить и увезти, а прямую Leaf-to-Leaf связность после переезда мы решили оставить как аварийный путь.

Ниже — не повтор статьи про euNetworks → QupraDC, а разбор второго переезда: как мы готовили NorthC, как использовали подменный leaf3, как пережили нехватку портов, как перевезли spine1 без потери EVPN-сигнализации и почему временная перемычка между Leaf в итоге стала частью аварийного сценария.

Исходное состояние и план переезда
Перед новым переездом площадка уже была построена как EVPN/VXLAN-фабрика. У нас были Leaf-коммутаторы, Spine, routed host networking для гипервизоров, BGP-анонсы VM-префиксов и внешний транзит, разнесённый по Leaf.

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

Базовая идея осталась прежней:

• поставить новый Leaf в NorthC;
• временно включить его в существующую фабрику;
• постепенно переносить серверы;
• сохранить клиентскую адресацию;
• не останавливать сервис;
• после завершения миграции вернуть временное оборудование поставщику.

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

• подменное железо на время миграции — L3-коммутатор класса Leaf с 48 портами доступа и 6 портами QSFP28, тот самый будущий leaf3;
• два L2 40G-канала между QupraDC и NorthC;
• два L3 100G-канала в Интернет для внешней связности уже из нового дата-центра;
• management-подключение для управления подменным коммутатором;
• отдельные management-подключения для постоянных коммутаторов после их физического переезда в NorthC.

Здесь важно не перепутать назначение каналов. L2 40G между дата-центрами был нужен не для растягивания клиентских VLAN и не для построения большого L2-домена между площадками. Это был временный транспорт, поверх которого мы могли поднять свою IP-связность и включить новый Leaf в существующую фабрику. А два L3 100G-канала в Интернет были нужны для того, чтобы новая площадка получила внешнюю связность до завершения всего физического переезда.

Только после того как поставщик реализовал эти условия, мы начали саму миграцию. В таких работах нельзя сначала перевезти железо, а потом внезапно выяснить, что нет out-of-band управления, не готовы междатацентровые каналы или внешняя связность в новом ЦОД существует только на схеме.

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

Отдельная бытовая, но важная деталь — первичная настройка подменного коммутатора. Leaf3 приехал без нашей конфигурации, а значит, его сначала нужно было как-то настроить до появления нормального management-доступа через продакшен-сеть. Для этого я использовал наш старый Vertiv Avocent ACS804, который мы заранее сняли из QupraDC. Консольный сервер в таких работах — не роскошь, а страховка от ситуации, когда коробка стоит в другой стране с пустым конфигом, OOBM ещё не настроен, а единственный способ поговорить с ней — serial console.

Задача leaf3 была простой: стать временным Leaf в новой локации и дать нам возможность начать перенос серверов до того, как туда переедет всё основное сетевое оборудование.

Первая волна: leaf3 в NorthC и миграция до упора в порты
Leaf3 физически установили в NorthC и временно включили в существующую фабрику. С точки зрения сети он стал ещё одним Leaf-коммутатором, только расположенным в новом дата-центре.

Как и в прошлой миграции, нам была важна не магия конкретного канала между площадками, а его свойства: нормальная IP-связность underlay, достаточный MTU, стабильность и возможность использовать канал как временный транспорт для overlay. Временная связность нужна была для того, чтобы Leaf в новой локации мог стать участником существующей IP-фабрики.

После включения leaf3 мы начали переносить серверы в NorthC партиями. Модель подключения гипервизоров не менялась: серверы по-прежнему работали в routed-модели, VM-префиксы продолжали анонсироваться через BGP, а достижимость внутри фабрики обеспечивалась через EVPN/VXLAN.

Но быстро проявилось ограничение, которого в первой миграции не было в таком виде: портовая ёмкость.

На временном Leaf было 48 портов доступа. При нашей схеме подключения один такой коммутатор физически не мог принять всю площадку целиком. Портовая ёмкость закончилась раньше, чем закончились серверы.


Поэтому мы мигрировали до тех пор, пока на leaf3 не закончились свободные порты. Это было нормальное промежуточное состояние: часть серверов уже работала в NorthC через leaf3, часть оставалась в QupraDC на старых Leaf-коммутаторах, а фабрика продолжала жить как единая система.

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

Освобождаем leaf1 и продолжаем переезд
Чтобы продолжить перенос, нам нужно было получить ещё один Leaf в NorthC. Покупать новый постоянный коммутатор под эту задачу не хотелось, а leaf3 был временным и должен был вернуться поставщику. Поэтому мы пошли другим путём: освободили один из действующих Leaf-коммутаторов.

На тот момент часть серверов ещё оставалась в QupraDC. Мы перекоммутировали оставшиеся подключения так, чтобы освободить leaf1: все порты серверов, которые ещё оставались в старой локации, временно собрали на leaf2. Leaf2 продолжал работать в QupraDC и держал оставшуюся часть нагрузки. Это стало возможным за счёт того, что часть серверов с leaf1 и leaf2 уже переехала в NorthC на leaf3, освободив достаточное количество портов на leaf2, чтобы принять оставшуюся нагрузку.

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

После освобождения leaf1 мы физически перевезли его в NorthC и включили в фабрику уже в новой локации. В NorthC у нас появились два Leaf-коммутатора: временный leaf3 и постоянный leaf1. Это дало дополнительную портовую ёмкость и позволило завершить перенос оставшейся серверной нагрузки.

В итоге серверная нагрузка переехала в NorthC, но оставалась следующая важная проблема: как перевезти Spine.

Самая неприятная часть: как перевезти Spine и не порвать overlay
Если Leaf-коммутаторы уже находятся в NorthC, а Spine всё ещё остаётся в QupraDC, фабрика продолжает работать за счёт временной междатацентровой связности. Но Spine нельзя просто выключить и перевезти, если Leaf-коммутаторы в новой локации используют его как точку обмена маршрутной и EVPN-информацией.

Проблема была в следующем: если выключить spine1 без подготовки, leaf1 и leaf3 потеряют через него маршруты друг друга. А это уже риск для overlay-сервисов и для клиентского трафика.

Нам нужно было сделать так, чтобы Leaf-коммутаторы в NorthC продолжали видеть loopback-адреса друг друга и обмениваться EVPN-информацией даже в момент, когда spine1 физически выключен и едет из одного дата-центра в другой.

Решение получилось простым и достаточно красивым: мы соединили leaf1 и leaf3 напрямую 100G DAC-кабелем.

Но одного физического кабеля оказалось недостаточно. Нужно было временно построить маленький underlay между этими двумя Leaf-коммутаторами и дать overlay нормальную достижимость.

Для underlay между leaf1 и leaf3 мы использовали ISIS (протокол маршрутизации). Его задача была не заменить всю фабрику, а решить конкретную временную задачу: просигнализировать loopback-адреса Leaf-коммутаторов и обеспечить IP-достижимость, поверх которой можно продолжить работу overlay.

После этого между Leaf-коммутаторами была настроена BGP-сигнализация для EVPN. Иными словами, мы дали leaf1 и leaf3 возможность обмениваться EVPN-информацией напрямую, минуя spine1 на время его физического переезда.

С точки зрения логики это был временный обходной путь:

• физически leaf1 и leaf3 соединены прямым 100G DAC;
• underlay-достижимость loopback-адресов обеспечивается через ISIS;
• overlay продолжает работать через EVPN;
• Leaf-коммутаторы видят необходимые префиксы друг друга;
• spine1 можно выключить и перевезти без потери клиентского сервиса.

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

После проверки прямой связности, ISIS-соседства, loopback reachability и EVPN-обмена мы перевезли spine1 в NorthC. Клиентский трафик при этом не пострадал: Leaf-коммутаторы на новой площадке продолжили видеть друг друга через временную прямую связку.

После переезда Spine мы решили не убирать саму идею прямой Leaf-to-Leaf связности полностью. Временная перемычка показала себя полезной как аварийный сценарий на случай проблем с единственным Spine, поэтому в целевой схеме между постоянными Leaf-коммутаторами мы оставили прямой 100G DAC-линк.

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

На уровне overlay на каждом Leaf в экспортной политике мы добавили трёхкратный AS-PATH prepend с собственной AS — искусственно увеличив длину AS-PATH. EVPN-маршруты, полученные через прямую Leaf-to-Leaf BGP-сессию, становятся менее предпочтительными по AS-PATH. Пока BGP-сигнализация overlay нормально работает через spine1, маршруты через прямую Leaf-to-Leaf сессию не выбираются как основные.

На уровне underlay мы тоже не хотели, чтобы прямой линк случайно стал приоритетным путём при исправном Spine. Поэтому ISIS на этой перемычке был настроен как локальный L1 с выставленным route preference 171. То есть такой underlay-путь заведомо менее предпочтителен, чем любой путь через eBGP в основной фабрике.

В результате прямой 100G DAC между Leaf не нагружает обычный трафик при исправном spine1. Он вступает в работу только тогда, когда ломается основной путь: пропадает нормальная BGP-сигнализация overlay через Spine и вместе с ней основной underlay-путь до loopback-адресов. Получается не постоянный обход Spine, а аварийная страховка от его отказа.

Возвращаем временный Leaf поставщику
После переезда spine1 в NorthC у нас в новой локации оказалось больше сетевого оборудования, чем нужно для целевого состояния. Временный leaf3 выполнил свою задачу: он дал нам возможность начать миграцию, пережить нехватку портов и сохранить управляемость переезда. Но по условиям проекта его нужно было вернуть поставщику.

Leaf3 нельзя было оставлять по принципу «пусть пока постоит». Основная проблема была не только в том, что в схеме оставался временный коммутатор и связанный с ним технический долг. Более критичным фактором были операционные расходы: временное железо быстро превращается в постоянный OPEX и начинает ежемесячно увеличивать стоимость эксплуатации, хотя в целевой архитектуре оно уже не требуется.

Поэтому возврат leaf3 поставщику был не формальностью, а полноценным этапом миграции. К этому моменту в NorthC уже можно было собрать целевую схему на постоянных Leaf-коммутаторах, поэтому мы начали обратную перекоммутацию: переносили серверные подключения с leaf3 на leaf1 и leaf2.

Как мы перекоммутировали серверные линк-и без остановки VM
Отдельно стоит рассказать, как именно мы переключали серверы с временного leaf3 на постоянные leaf1 и leaf2. Со стороны это выглядит как простая физическая перекоммутация: был линк в leaf3, стал линк в leaf1 или leaf2. Но если сделать это грубо, можно получить потери трафика или неочевидную асимметрию маршрутизации.

Мы делали переключение шагающим способом. Сначала административно гасили нужный интерфейс на leaf3. После этого для сервера линк переходил в состояние down, а связанный с ним next-hop исчезал из RIB/FIB. Для исходящего трафика это было ключевым моментом: сервер больше не пытался отправлять пакеты через уже выключенный путь, а оставшийся живой next-hop продолжал использоваться как рабочий путь в ECMP-группе.

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

С входящим трафиком логика была похожей, но работала через BGP-сигнализацию. Достижимость клиентских виртуальных машин была анонсирована через BGP и два route reflector. Когда один из путей становился недоступен, соответствующая сигнализация пропадала, и путь к пересылке уходил на оставшийся живой next-hop. Поскольку порты гасились непосредственно на коммутаторе, событие link down доходило до сетевого стека сразу, без ожидания долгих таймаутов. После этого обновлялись RIB/FIB, и фабрика переставала использовать нерабочий путь.

В результате физическая перекоммутация серверов не требовала остановки клиентских VM. Мы не переносили риск на уровень виртуальных машин, а управляли им на уровне линков, next-hop'ов и BGP-сигнализации. Каждый шаг был маленьким: погасили один порт, убедились, что трафик ушёл на живой путь, перенесли линк, проверили восстановление связности и только после этого переходили к следующему.

После перекоммутации серверов на leaf1 и leaf2 мы вывели leaf3 из фабрики, проверили, что на нём не осталось клиентской и сервисной нагрузки, и вернули коммутатор поставщику.

В целевом состоянии площадка в NorthC снова осталась на постоянной архитектуре:

• серверы подключены к leaf1 и leaf2;
• spine1 находится в новой локации;
• временный leaf3 выведен из эксплуатации;
• между постоянными Leaf оставлена прямая 100G-связность как резервный путь для EVPN и underlay-достижимости;
• клиентская адресация сохранена;
• overlay/underlay-модель не менялась;
• миграция выполнена без остановки сервиса.

Что получилось в итоге
Этот переезд был похож на предыдущий только на верхнем уровне: добавить Leaf в новой локации, перенести серверы, перевезти старое оборудование, разобрать временные связи. На практике он оказался интереснее из-за портовой ёмкости и необходимости аккуратно перевезти Spine.

Главное отличие было в том, что нам пришлось мигрировать не просто «из старого ЦОД в новый», а через несколько вынужденных состояний:

1. Сначала запросить у поставщика подменный Leaf, два L2 40G-канала между дата-центрами, два L3 100G-канала в Интернет и management-доступ.
2. Дождаться готовности этой базовой инфраструктуры.
3. Смонтировать несколько пустых серверов под живую миграцию клиентских VM.
4. Поднять первичный доступ к подменному Leaf через консольный сервер.
5. Затем включить leaf3 как подменный Leaf в NorthC.
6. Потом провести миграцию до исчерпания его 48 портов.
7. Затем освободить leaf1 за счёт временной концентрации оставшейся нагрузки на leaf2.
8. Далее перенести перенос leaf1 в NorthC и завершить серверную миграцию.
9. Пробросить прямой 100G DAC между leaf1 и leaf3, ISIS как временный underlay между Leaf-коммутаторами, организовать EVPN-соседство между ними без участия spine1.
10. Выполнить физический переезд spine1.
11. Шагающая перекоммутация серверных линков с leaf3 на leaf1 и leaf2 через управляемый link down;
12. Вернуть leaf3 поставщику.

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

Мы снова сделали переезд дистанционно из России, используя удалённые руки в дата-центре. Для такой работы критично, чтобы сеть была управляемой фабрикой с понятными ролями устройств, понятной маршрутизацией, понятной телеметрией и доступом к оборудованию вне основной продакшен-сети.

Практические выводы
1. Миграция начинается не с перетыкания серверов, а с подготовки внешних зависимостей. Резервные коммутаторы, междатацентровые каналы, внешняя связность, management-доступ, консольный доступ и пустые серверы под live migration должны быть готовы до начала работ, иначе контролируемый переезд быстро превращается в импровизацию.

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

2. Портовая ёмкость — это не мелочь. Если у каждого сервера несколько физических подключений, один 48-портовый Leaf очень быстро перестаёт быть достаточным для переезда всей площадки. План миграции должен учитывать не только BGP, EVPN и MTU, но и банальное количество физических портов.

4. Освобождение постоянного оборудования может быть частью плана. Мы не покупали ещё одну коробку только потому, что временный leaf3 упёрся в 48 портов. Вместо этого мы временно сконцентрировали остаток нагрузки на leaf2, освободили leaf1, перевезли его и продолжили миграцию.

5. Spine нельзя считать просто «транспортной коробкой», которую можно выключить в любой момент. Если через него Leaf-коммутаторы получают EVPN-информацию друг о друге, его переезд нужно готовить отдельно. В нашем случае прямой 100G DAC между Leaf, ISIS для underlay и EVPN-сигнализация поверх него позволили перевезти spine1 без удара по клиентскому трафику.

6. Временную аварийную связность иногда имеет смысл оставить, но только если она не становится основным путём. Прямой 100G DAC между Leaf мы оставили как страховку от проблем с единственным Spine, но сделали его менее предпочтительным сразу на двух слоях. В overlay — через eBGP AS-PATH prepend. В underlay — через ISIS с L1 preference 171. В штатном режиме сигнализация и трафик идут через Spine; прямой Leaf-to-Leaf линк нужен только тогда, когда основной путь через Spine перестаёт работать.

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

Итог простой: IP-фабрика снова позволила нам переехать без остановки сервиса. В первый раз она помогла превратить вынужденный переезд в улучшение архитектуры. Во второй — позволила пережить нехватку портов, временный подменный Leaf и физический переезд Spine, не меняя базовую сетевую модель и не заставляя клиентов участвовать в наших приключениях.

Автор статьи: Рене, сетевой инженер FirstVDS
firstvds.ru

Выполняем обещание и переносим инфраструктуру на новую площадку. Рассказываем о партнёре и плане миграции.

3 июля мы опубликовали подробный разбор инцидентов в локации «Амстердам» и сообщили о решении найти для наших серверов новую площадку. Мы понимаем, насколько важна стабильность ваших проектов, поэтому сегодня готовы объявить: мы переезжаем в дата-центр NorthC Amsterdam 1.

Почему мы уходим из Qupra DC2 и почему именно сейчас
Охлаждение в Qupra DC2 всё ещё работает на резервном чиллере без резервного питания. Ждать полного восстановления площадки небезопасно для ваших проектов — переезжать нужно срочно.

Найти дата-центр уровня Tier 3 со свободными мощностями и возможностью экстренного переезда было сложно. Мы сравнили доступные варианты в Нидерландах и выбрали NorthC Amsterdam 1 как самый оптимальный баланс надёжности и скорости миграции.

Наш новый дом: NorthC Amsterdam 1
NorthC Amsterdam 1 полностью отвечает заявленным нами требованиям к новой площадке.

Что это значит для вас

• Надёжность уровня Tier 3. Соответствие этому стандарту означает резервирование ключевых инженерных систем: электропитания, охлаждения и сетевых подключений. Все системы имеют резерв, который включается автоматически в случае сбоя.
• Прямое подключение к AMS-IX. NorthC является точкой присутствия (PoP) Amsterdam Internet Exchange — одной из крупнейших точек обмена трафиком в мире. Это обеспечит серверам отличную связность и минимальные задержки.
• Современная инфраструктура. Площадка отвечает высоким стандартам эксплуатации и принадлежит NorthC — крупному оператору, который управляет сетью дата-центров в Нидерландах, Германии и Швейцарии.

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

План переезда: что будет дальше
Мы уже начали подготовку к миграции. Полный переезд локации займет 1–1,5 месяцев. Точные даты и детальный график работ мы анонсируем отдельной новостью, как только план будет окончательно согласован. Мы постараемся сделать переезд максимально бесшовным.

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

• Минимальный простой: Мы спланируем работы так, чтобы исключить время недоступности ваших сервисов или свести его к минимуму. Перенос будет проходить в ночное время и в выходные дни.
• Сохранение IP-адресов: Как и обещали, все ваши текущие IP-адреса будут сохранены. Вам не придётся вносить изменения в настройки DNS или конфигурацию своих проектов.
• Персональные уведомления: Каждый клиент, чьи услуги затронуты, заранее получит отдельное письмо на электронную почту и уведомление в личном кабинете со временем проведения работ по его серверу.

Спасибо за ваше терпение и понимание. Следите за нашими новостями и почтовыми рассылками.

Каждый современный сервер работает под высокой нагрузкой и выделяет от 250 Вт тепла. Чтобы обеспечить надежность и производительность оборудования, важно поддерживать оптимальную температуру.

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

Дата-центры Tier III
Всё оборудование мы размещаем в дата-центрах, которые соответствуют стандарту Tier III.

Такие ДЦ обладают вспомогательным (дублирующим) охлаждением и работают по принципу не менее чем N+1, а в некоторых случаях N+2 или даже 2N – если один элемент системы охлаждения ЦОД выходит из строя или обслуживается, остальные продолжают поддерживать требуемую температуру, поскольку нагрузка распределяется между оставшимся оборудованием.

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

Владимир Мыскин, заместитель руководителя отдела эксплуатации ЦОД “Миран”

Мониторинг и инспекция серверного оборудования
Регулярный контроль за оборудованием позволяет своевременно выявлять неисправности и предотвращать сбои.

В дата-центрах осуществляется круглосуточный контроль работы оборудования в режиме 24/7 – например, в дата-центре NLS все критические события и аварийные ситуации автоматически дублируются уведомлениями в Telegram, что позволяет оперативно реагировать на любые изменения.

Инспекция серверного оборудования осуществляется и в других дата-центрах – например, в ЦОД “Миран” дважды в сутки проводятся визуальные осмотры оборудования, раз в квартал – обслуживание с замерами рабочих параметров и ежегодно – планово-предупредительные ремонты.

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

Владимир Мыскин, заместитель руководителя отдела эксплуатации ЦОД “Миран”

В систему мониторинга дата-центра “РТК-ЦОД” стекаются сигналы от всего инженерного оборудования. Инженеры круглосуточно отслеживают основные показатели работы: состояние систем энергоснабжения и кондиционирования, климат в каждом зале, физическую безопасность. Для наблюдения за многими параметрами в центре мониторинга оборудована видеостена. У дежурных в диспетчерской также стоит отдельный монитор для слежения за системой.

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

Подобная система охлаждения для сервера обеспечивает рациональное распределение воздушных потоков.

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

Владимир Мыскин, заместитель руководителя отдела эксплуатации ЦОД “Миран”

Отгороженный холодный коридор между двумя рядами стоек в ЦОД “Миран”


Перфорированные плиты фальшпола, через которые в холодный коридор подается охлажденный воздух в ЦОД “Миран”


В дата-центре “РТК-ЦОД” стойки в залах также расставлены по принципу горячих и холодных коридоров. Оборудование выбрасывает нагретый воздух в горячий коридор и забирает охлажденный воздух из холодного коридора через перфорированные плитки фальшпола.

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

Например, в дата-центре “РТК-ЦОД” в каждом холодном коридоре поддерживается температура 23±2 °C и влажность 30–70%.

В ЦОД “Миран” оптимальной температурой серверного зала считается 22±2 °C в холодном коридоре (на входе в серверный шкаф), а PUE (Power Usage Effectiveness – показатель оценки энергоэффективности) поддерживается в диапазоне 1,4–1,6. При этом следить за показателями помогают датчики температуры и влажности: они расположены на дверях серверных стоек на высоте 1,4–1,6 м с шагом 3–4 стойки – таким образом происходит условное зонирование коридора.

Также в конце прошлого года оператор коммерческих центров обработки данных IXcellerate, где мы размещаем облачные гипервизоры, запатентовал инновационное ус­трой­ство для ох­лаж­де­ния вы­соко­наг­ру­жен­ных ма­шин­ных за­лов ЦО­Дов, которое позволяет:

• исключить риски перегрева высоконагруженного ИТ-оборудования;
• повысить энергоэффективность и обеспечить охлаждение ЦОД;
• снизить потребление электроэнергии за счет оптимизации системы;
• достигнуть оптимального температурного графика теплоносителя.

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

Ряд прецизионных кондиционеров, установленных в серверном зале ЦОД “Миран”


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

• в ЦОД “Миран” используется фреоновое охлаждение прецизионными или полупромышленными кондиционерами (CRAC/DX);
• в дата-центре NLS функционируют чиллеры HiRef и кондиционеры Conteg, зарекомендовавшие себя как надежные решения для объектов с повышенными требованиями к отказоустойчивости и контролю микроклимата;
• в дата-центре “РТК-ЦОД” охлаждение оборудования обеспечивает чиллерная схема холодоснабжения с этиленгликолем в качестве теплоносителя, при этом все элементы зарезервированы по схеме N+1.

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

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

Заглушки, закрывающие пустующие юниты для исключения паразитных перетоков горячего воздуха в ЦОД “Миран”

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

Владимир Мыскин, заместитель руководителя отдела эксплуатации ЦОД “Миран”

Заключение
Охлаждение – одна из крупнейших постоянных статей расходов дата-центров.

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

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

beget.com/ru/

Статус на момент публикации (3.07.2026). Все серверы локации «Амстердам» работают в штатном режиме. Дата-центр функционирует на внешнем (резервном) чиллере; работы по восстановлению основной системы охлаждения продолжаются. Мы держим ситуацию под усиленным контролем. Пока основная система охлаждения не восстановлена и не подтверждён резерв, мы считаем ситуацию незакрытой.

Это подробный разбор того, что произошло с локацией «Амстердам» в мае–июле 2026 года, почему это случилось, что мы сделали не так и что делаем дальше. Мы понимаем, что подвели вас, и приносим извинения. Ниже — по существу

Коротко о главном

• В мае–июле 2026 года в дата-центре нашей локации «Амстердам» (Qupra DC2) произошла серия отказов системы охлаждения. Оборудование уходило в аппаратную защиту от перегрева, из-за чего серверы были недоступны.
• Первопричина — отказы системы охлаждения на стороне дата-центра. Аномальная жара стала триггером, но не единственной причиной: цепочка инженерных и эксплуатационных отказов на площадке превратила единичный сбой в каскад (подробно — ниже).
• Данные клиентов сохранены. Аварии касались доступности, а не целостности данных.
• Компенсация и бонусы для пострадавших клиентов локации «Амстердам»: возврат за фактический простой на баланс (тикет в техподдержку, по SLA) плюс бонусы-промокоды на продление — QUPRA100 (100% на 14 дней) и следом QUPRA15 (15% на 3 месяца). Для уже ушедших клиентов — отдельный порядок. Подробнее — в разделе «Компенсации и бонусы».
• Мы не рассматриваем гарантии или доработки со стороны Qupra — только переезд локации на новый дата-центр.
• Повышение цен, о котором вы получили уведомление, — не связано с инцидентом: это совпадение по времени, и мы это учли (см. раздел «О ценах»).

Что произошло
В дата-центре Qupra DC2 (Амстердам), где размещена наша локация «Амстердам», несколько раз выходила из строя система охлаждения. Когда охлаждение останавливается, оборудование в стойках быстро перегревается, и включается защита. Часть её срабатывает автоматически, на уровне железа: процессоры снижают частоты (троттлинг), а при достижении критической температуры сервер аппаратно выключается сам. Часть — управляемо, по нашему решению: чтобы не ронять машины жёстко и сохранить ваши данные, мы штатно и контролируемо выключаем серверы (graceful shutdown), а дата-центр при необходимости обесточивает перегретые стойки со своей стороны. Результат в любом случае один: сервер временно недоступен.

Каждый такой отказ приводил к многочасовому простою локации. Самая длительная авария в конце июня — начале июля растянулась почти на двое суток.

Хронология
Ниже — все известные нам эпизоды недоступности локации «Амстердам», связанные с охлаждением. Время указано по МСК.

• 27.05.2026, 12:33 → 19:42 (≈5 часов). Отказ системы охлаждения: вышел из строя основной чиллер на крыше. Вечером дата-центр привёз и установил резервный чиллер.
• 26.06.2026, 16:51 → 21:55 (≈5 часов). Снова отказ охлаждения. Инцидент пришёлся на ночь выходного дня. Мы не опубликовали о нём информацию своевременно — это была ошибка (см. раздел «Что мы сделали неправильно»).
• 29.06.2026, 13:10 → 16:58 (≈4 часа). Очередной отказ охлаждения.
• 29.06 (поздний вечер) → 01.07.2026, 22:24 — самая длительная авария (≈44 часа). Отказавший чиллер запустить не удалось. Дата-центр организовал доставку и подключение внешнего чиллера, но подключение затянулось из-за отсутствия на площадке нужных силовых кабелей — их привезли только 1 июля. Внешний чиллер подключили около 14:00, серверы начали подниматься примерно с 15:30, восстановление шло поэтапно.

Суммарная недоступность локации за май–июль составила порядка 58 часов. Мы не считаем это приемлемым и не спорим с вашими собственными подсчётами простоя — они верны.

Почему это произошло
Триггером отказов стала аномальная жара в Западной Европе летом 2026 года: система охлаждения площадки не удержала тепловую нагрузку при высокой наружной температуре. Но жара — не единственная причина. За затяжным простоем конца июня стоит цепочка инженерных и эксплуатационных отказов на самой площадке.

Что именно отказало
Приводим восстановленную картину работы инженерных систем дата-центра — по информации, которой мы располагаем.

• До конца мая охлаждение обеспечивал основной чиллер на крыше здания. 27 мая он вышел из строя.
• Дата-центр привёз резервный чиллер, разместил его за зданием и запитал от внешнего дизель-генератора, подключив к системе охлаждения. Нам сообщили, что основной (крышный) чиллер также восстановлен.
• В конце июня внешний дизель-генератор, питавший резервный чиллер, был убран с площадки — и резервный чиллер обесточился.
• Дата-центр переключился на основной чиллер, но тот, вопреки сообщению о восстановлении, к вечеру отказал окончательно — запустить его не удалось даже с привлечённым сервисным инженером.
• Оперативно найти замену дизель-генератору не получилось. Для подключения резервного чиллера напрямую к электрощиту площадки пришлось заказывать силовые кабели (около 60 метров), доставка заняла порядка суток. На это время охлаждение держали на фрикулинге, без компрессора.
• После доставки кабелей резервный чиллер подключили штатно, и охлаждение вышло на рабочий режим. На сегодня локацию охлаждает один исправный чиллер; второй (на крыше) остаётся в восстановлении.

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

Наша ответственность
Мы не будем прятаться за формулировкой «виноват дата-центр». За питание и охлаждение физически отвечает площадка, а не хостинг-провайдер, — но выбор площадки это наша ответственность. Мы разместили вашу инфраструктуру в Qupra DC2, мы на ней оставались, и перед вами за результат отвечаем мы. Именно поэтому наше решение — уходить с площадки, а не ждать её доработок (см. «Что мы меняем»).

Мы переехали в Qupra DC2 в конце 2025 года, когда прежняя площадка (euNetworks) закрывалась и просила арендаторов освободить помещение. Новый дата-центр оказался не готов держать нашу нагрузку. Это в том числе наш урок по выбору и аудиту площадки.

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

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

Что мы сделали неправильно
Отдельно и без смягчений — о наших собственных ошибках.

Мы не остановили приём заказов в проблемной локации. Во время аварии заказ новых серверов в локации «Амстердам» оставался доступен. Из-за этого часть клиентов оформили серверы, которые невозможно было развернуть сразу, пока инфраструктура была недоступна. Это наша ошибка. Все такие серверы были развёрнуты после восстановления работы кластера.

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

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

Компенсации и бонусы
Разделяем две вещи: компенсацию за фактический простой и бонус сверх неё. Оба доступны клиентам локации «Амстердам», чьи затронутые услуги были активны в период инцидента.

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

Бонусы (промокоды)
Сверх компенсации — два промокода на продление серверов локации NL (все тарифы). Тикет для них не нужен, они применяются вами самостоятельно в личном кабинете. Действуют только для услуг, заказанных до 1 июля 2026; скидка распространяется и на сам сервер, и на дополнительные услуги.

Промокоды применяются последовательно, именно в таком порядке:

• QUPRA100 — скидка 100% на 14 дней. Активировать с 3 июля по 3 августа. После активации сервер будет работать две недели бесплатно.
• QUPRA15 — скидка 15% на 3 месяца. Активировать с 18 июля по 31 августа, после того как отработают 14 дней по QUPRA100.

Важно: сначала QUPRA100, затем QUPRA15. Если активировать 15% раньше, он перебьёт скидку 100%. Все действующие скидки отображаются в личном кабинете в разделе «Скидки». Пошаговая инструкция — здесь.

Если вы уже отказались от услуги из-за инцидента

• Компенсация — в общем порядке: напишите тикет в техподдержку, мы вернём стоимость простоя на баланс (с последующим выводом на вашу карту или счёт).
• Бонус — в ручном режиме: напишите тикет в отдел продаж и опишите ситуацию. Мы вручную назначим скидку на новую услугу с аналогичными условиями (100% на 14 дней, далее 15% на 3 месяца).

Стоимость новых услуг не должна превышать стоимость ваших услуг, пострадавших в результате инцидента.

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

Мы понимаем, что для многих из вас простой — это не «минус несколько часов аренды», а остановленные заказы, недоступные кассы, сорванные процессы и потерянные клиенты. Это реальный ущерб, и мы его не обесцениваем.

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

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

О ценах
Понимаем, как это выглядит со стороны: сервис падал — а вы получили уведомление о повышении цен. Это совпадение по времени: плановое изменение тарифов готовилось заранее и не связано с инцидентом. Тем не менее момент вышел болезненным, и та же скидка 15% на продление затронутых услуг (см. «Компенсации и бонусы») смягчает для вас это повышение.

Что мы меняем
Площадка. Принято решение уходить из Qupra DC2. Сейчас мы выбираем новый дата-центр. Основной кандидат, которого мы оцениваем, — площадка в Амстердаме уровня Tier 3 с сертификацией управления непрерывностью бизнеса (ISO 22301) и точкой присутствия AMS-IX; параллельно рассматриваем ещё несколько вариантов. Решение принимаем на этой неделе. Конкретную площадку, график переезда и порядок переноса объявим отдельным анонсом. Сам переезд спланируем так, чтобы исключить или свести простой к минимуму и заранее предупредить вас по каждой затронутой услуге. Текущие IP-адреса на услугах будут сохранены.

Текущее состояние. До восстановления основной системы охлаждения и подтверждения резерва локация остаётся под усиленным мониторингом. Сейчас она работает на внешнем чиллере.

Коммуникация. Мы работаем по принципу, который в этом инциденте показал себя как единственно

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

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

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

Меня зовут Рене, я сетевой инженер в FirstVDS. В первой части я рассказывал, как мы запускали небольшую европейскую площадку в Амстердаме: один Leaf, один Spine, routed host networking для гипервизоров, EVPN-VXLAN как сервисная плоскость, DDoS в отдельном VRF, OOBM и Flow-коллектор.

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

Хорошая новость в том, что стартовая схема была построена не вокруг одной большой god-box, а как маленькая, но нормальная фабрика. Именно это позволило нам не делать одно рискованное переключение «всё сразу», а провести переезд через несколько контролируемых промежуточных состояний.

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

А потом пришла вводная: дата-центр euNetworks закрывается, оборудование нужно перевозить.

Для бизнеса вопрос звучал просто: что нужно купить, чтобы переехать? Следом появился второй, более интересный вопрос: можно ли не покупать ничего лишнего или взять это временно в аренду и переехать без остановки клиентского сервиса?

Требования получились такими:

• по возможности не покупать дополнительное сетевое оборудование;
• не останавливать продажи и не останавливать клиентский сервис;
• переносить серверы постепенно;
• сохранить старую клиентскую IP-адресацию;
• не сводить переезд к одному большому окну работ, в котором нужно переключить всё и сразу.

Переводя это на сетевой язык, я понял, что нам просто нужен ещё один Leaf в QupraDC, который можно временно включить в существующую фабрику. Старый Spine оставляем в euNetworks, новый Leaf физически ставим в QupraDC, а между площадками поднимаем временный IP-транспорт.

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

Так вынужденный переезд превратился ещё и в проект по повышению отказоустойчивости.

Временный DCI и первые серверы в QupraDC
Чтобы подключить новый Leaf в QupraDC к существующей фабрике, нам понадобился канал между дата-центрами.

На самом деле нам было почти всё равно, как именно поставщик реализует этот канал внутри своей сети: тёмная оптика, лямбда, проброс VLAN по коммутационной фабрике оператора, L2VPN, L3VPN или какой-то иной транспорт. Для нашей задачи была важна не технология, а конкретные технические свойства:

• пропускная способность не меньше 40G;
• возможность передавать IP-пакеты между старой и новой площадкой и желательно одним p2p-линком с /31-адресацией;
• MTU 9216;
• возможность быстро разобрать канал после завершения миграции;
• недорого.

Dot1q теги нам были не нужны, потому что мы не тащили пользовательские VLAN между дата-центрами, а даже если бы такая потребность была, то мы бы cделали это силами EVPN-VXLAN. Underlay-интерфейсы на Leaf и Spine были обычными L3-портами с IP-адресацией. По временному каналу должны были ходить IP-пакеты underlay и поверх них — VXLAN-инкапсулированный трафик overlay.

MTU был критичен. Внутри underlay передаются не только обычные IP-пакеты, но и трафик виртуальных машин в VXLAN-инкапсуляции. Если клиентская VM отправляет стандартный 1500-байтный пакет, к нему добавляется накладной расход VXLAN/UDP/IP. Если забыть про это на междатацентровом канале, можно получить неприятные проблемы с фрагментацией или чёрными дырами для части трафика. Отдельная практическая причина — сервисная потребность использовать jumbo frames для сетевых хранилищ: такие сценарии тоже требуют нормального запаса MTU в фабрике.

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

Важно подчеркнуть: мы не строили stretched-L2 между дата-центрами. Временный L2-канал от поставщика использовался как транспорт для нашей L3-связности underlay. Для фабрики новый Leaf выглядел как ещё один Leaf, который просто находится чуть дальше, чем ожидалось ранее.

Никаких растянутых клиентских VLAN через xSTP, никаких попыток склеить две площадки в один большой L2-домен. Только IP-связность underlay и EVPN-VXLAN поверх неё.

Новый Leaf должен был быть точно такой же модели, чтобы сетевые чипы и версии программного обеспечения были максимально идентичны. В миграции под давлением и в условиях дефицита времени это важно. Теоретически EVPN должен нормально работать между разными платформами, но на практике смешивание разных чипов, разных версий ПО и разных профилей поведения control plane может превратить переезд в отладку ещё неразрешенных багов.

После физической установки нового Leaf в QupraDC последовательность работ была такой:

• Подключили новый Leaf через временный 40G-канал к существующему Spine.
• Настроили базовую IP-связность underlay.
• Проверили reachability между участниками фабрики.
• Подняли BGP-сессии underlay и overlay.
• Отмониторили стабильность BGP-сессий и качество канала.
• Проверили, что новый Leaf участвует в EVPN control plane и корректно получает необходимые маршруты.

На этом этапе важно было не торопиться с клиентской нагрузкой. Сначала должна стабильно заработать управляющая плоскость: reachability VTEP-адресов, MP-EBGP EVPN, передача маршрутной, MAC/IP-информации и EVPN Type 5 routes, а также программирование EVPN database. Только после этого можно перевозить первые серверы.



Когда новый Leaf стал частью фабрики, мы вывели один родительский сервер из клиентской нагрузки, физически перевезли его в QupraDC и подключили к новому Leaf.

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

Получилась временная, но рабочая топология: часть серверов оставалась в euNetworks, часть уже находилась в QupraDC, старый Spine физически оставался в euNetworks, новый Leaf был в QupraDC, между площадками работал временный канал, а логически всё это оставалось одной фабрикой.

Маршрут до виртуальной машины на перенесённом сервере мог выглядеть так: интернет → старый Leaf → Spine → междатацентровый канал (DCI) → новый Leaf → гипервизор → VM.

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

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

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

Перенос внешней связности и инфраструктуры


Когда в QupraDC оказалась примерно половина нагрузки, стало нерационально гонять весь внешний трафик через старую площадку. Серверы уже физически находились в новом дата-центре, но весь входящий и исходящий трафик всё ещё проходил через euNetworks, старый Leaf и временный междатацентровый канал.

К счастью, наш IP-транзитный оператор присутствовал и в QupraDC. Это позволило перенести одну из BGP-сессий с апстримом в новую локацию.

Здесь важно уточнить: в QupraDC мы не повторяли старую физику 2×10G. При переносе стыка в новую локацию сразу включили 100G-подключение на новом Leaf. Сервисно это выглядело как перенос одной из двух BGP-сессий вместе с её VLAN и point-to-point-адресацией /31, а физически — как переход новой площадки на 100G-аплинк.

После этого схема стала такой:

• одна BGP-сессия с апстримом осталась на старом Leaf в euNetworks через старый 10G-стык;
• вторая BGP-сессия с тем же апстримом поднялась на новом Leaf в QupraDC уже через 100G-подключение;
• оба Leaf продолжили участвовать в общей фабрике;
• внешний трафик начал распределяться между двумя площадками.

С нашей стороны появился второй выход к тому же оператору, но уже из новой локации и на новой физике. На каждом Leaf был свой локальный default-route от апстрима. Кроме того, default-route мог распространяться внутри overlay как EVPN Type 5 route, чтобы у фабрики сохранялась связность между частями временной схемы.

Оператор со своей стороны также использовал multipath и старался отдавать входящий трафик относительно симметрично. В результате мы получили два полезных эффекта.

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

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

DDoS-сервис переносился параллельно и по той же логике. DDoS-защитный провайдер тоже присутствовал в QupraDC, поэтому его подключение можно было перенести в новую локацию без изменения прежней модели. Стык с ним также состоял из двух BGP-сессий на двух разных юнитах, с разными VLAN-тегами на два разных Leaf. С точки зрения маршрутизации и фильтров всё осталось прежним: изменилось только физическое место подключения.

На этом этапе состояние выглядело так: часть серверов уже в QupraDC, часть ещё в euNetworks, внешний транзит, в том числе защищённый, работает на обеих площадках, в QupraDC уже используется 100G-стык к апстриму, оба Leaf участвуют в маршрутизации, миграция продолжается без остановки клиентского сервиса.

После переноса основной части клиентской нагрузки пришла очередь инфраструктурных виртуальных машин.

Перевозить route reflector нужно аккуратно. Если одновременно потерять оба, гипервизоры не смогут нормально распространять маршруты до виртуальных машин, и сеть начнёт терять информацию о достижимости префиксов VDS.

Поэтому мы переносили их по одному: проверяли текущее состояние BGP-сессий и набор отражаемых маршрутов, выводили один route reflector из активной эксплуатации, перевозили или перезапускали его в новой локации, дожидались восстановления BGP-сессий, проверяли, что маршруты от гипервизоров снова видны на Leaf, и только после этого переходили ко второму route reflector.

В сетевой инфраструктуре route reflector — это не просто очередная виртуальная машина. Это элемент управляющей плоскости, и обращаться с ним нужно соответствующе.

После переноса RR и оставшейся инфраструктуры мы перенесли вторую BGP-сессию с апстримом в QupraDC. Напомню, внешняя связность в новой локации уже строилась на 100G: целевая схема предусматривала два независимых 100G-стыка, по одному на каждый Leaf.

К этому моменту вся клиентская и инфраструктурная нагрузка находилась в QupraDC. Старая площадка фактически оставалась только местом, где ещё физически стояли старые Leaf и Spine, а также один инфраструктурный сервер виртуализации, который нужно было убрать последним.

Финальный переезд железа и приведение схемы к отказоустойчивому виду
Когда клиентской нагрузки в euNetworks уже не осталось, мы смогли перевезти старое сетевое оборудование и другие остатки инфраструктуры.

На этом этапе старый Leaf и Spine уже не были критичны для клиентского сервиса в прежнем смысле. Основная нагрузка находилась в QupraDC, внешние BGP-сессии были перенесены туда же, а временный междатацентровый канал продолжал поддерживать связность на время завершения работ.

Мы обесточили старый Leaf и Spine, демонтировали их, перевезли в QupraDC, смонтировали и включили обратно.

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

После этого переезд можно было считать завершённым: клиентская нагрузка находилась в QupraDC, инфраструктурные сервисы находились там же, обе BGP-сессии к апстриму были подняты из QupraDC на 100G-стыках, стык с DDoS-провайдером был перенесён в QupraDC, старое сетевое оборудование было физически перевезено на новую площадку.

Временный междатацентровый канал, который был нужен только как инструмент миграции, мы незамедлительно разобрали.


После переезда обнаружилась ожидаемая промежуточная ситуация: большая часть серверов по-прежнему была подключена только к одному Leaf — тому самому, который мы первым установили в QupraDC для миграции.

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

Поэтому следующим этапом мы начали перекладывать серверные подключения так, чтобы каждый гипервизор имел по одному рабочему 10G-линку в каждый Leaf.

Здесь важно не спутать это с классическим LACP/ESI-LAG. Мы не собирали два физических линка в один L2-агрегат и не строили multihoming через LACP. Модель осталась той же, что и раньше. Разница только в том, что теперь эти два L3-пути идут не в один и тот же Leaf, а в два разных.

Так мы получили простую и понятную отказоустойчивость на уровне доступа. Если падает один линк, трафик остаётся на втором. Если падает один Leaf, для гипервизора это также выглядит как потеря одного из next-hop, а второй путь продолжает работать.

С точки зрения диагностики такая схема остаётся очень прозрачной. Нет необходимости выяснять, что именно произошло с LACP-состоянием, кто из пары коммутаторов считает себя активным и как отработала дополнительная сигнализация EVPN multihoming. В такой схеме DF election завязан на Type 4 — Ethernet Segment route, а aliasing и mass-withdraw — на Type 1 Ethernet A-D routes: per-ES и per-EVI. Это рабочая модель, но при отказах в ней появляется больше состояний, которые нужно уметь проверять и отлаживать.

В нашем случае есть интерфейс, есть connected route, есть next-hop, есть BGP-анонс VM-префикса. Каждый элемент можно проверить отдельно.

Важный нюанс — IPMI. У большинства серверов отдельный порт управления один. Его невозможно одновременно подключить в два Leaf без дополнительной схемы. Поэтому IPMI-порты мы распределили симметрично: часть серверов смотрит в первый Leaf, часть — во второй. При отказе одного Leaf мы теряем доступ к IPMI части серверов, но не ко всем сразу. Для этой задачи это приемлемый компромисс.

После финальной коммутации внешняя связность выглядела так:

• каждый Leaf имеет собственное 100G-подключение к апстриму;
• каждая BGP-сессия поднимается независимо;
• оба Leaf могут анонсировать одинаковый набор наших префиксов;
• отказ одного Leaf не убивает внешний канал целиком;
• отказ одного 100G-линка не оставляет площадку без транзита;
• входящий и исходящий трафик может распределяться через multipath.

Проверка отказов и один Spine как компромисс
После миграции и перекладки серверных линков мы провели серию отказных тестов. Это обязательный этап: отказоустойчивость нельзя считать существующей только потому, что она нарисована на схеме.

Проверяли несколько сценариев.

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

Второй сценарий — перезагрузка второго Leaf. Проверка симметричная, но её всё равно нужно проводить отдельно. В реальной эксплуатации часто выясняется, что «одинаковые» устройства отличаются мелочами: набором подключённых серверов, BGP-соседствами, политиками или физической коммутацией.

Третий сценарий — отключение серверных интерфейсов. При физическом обрыве всё работает быстро: сетевой стек гипервизора видит carrier loss, маршрут через этот интерфейс перестаёт использоваться, и трафик остаётся на другом ECMP-пути. В этом случае не нужно ждать истечения BGP holdtime, потому что проблема видна на уровне интерфейса.

BGP-таймеры важны для других случаев: например, если BGP-демон на соседней стороне завис, а физический линк при этом остался поднятым. Для таких сценариев худшее время обнаружения зависит уже от настроек BGP/BFD.

Четвёртый сценарий — отключение линков к апстриму. Когда внешний интерфейс становится недоступен, из таблицы маршрутизации уходят связанные с ним connected routes, BGP-сессия к оператору теряет транспортную связность и сбрасывается. После этого маршруты через этот стык перестают использоваться, а трафик перераспределяется через оставшийся внешний путь.

Пятый сценарий — проверка DDoS-сегмента. Здесь всё плюс/минус аналогично, проверяется отказ стыка к DDoS-провайдеру.

Для быстрой детекции отказов в самой IP-фабрике используется BFD. Благодаря BFD мы не ждём длинных BGP-таймаутов: если сосед перестаёт отвечать, путь быстрее признаётся нерабочим, и трафик перераспределяется по другим next-hop'ам в рамках ECMP-группы

В итоге мы получили то, что хотели: базовую отказоустойчивость на уровне серверных подключений, разнесение внешнего транзита по двум Leaf и кратный рост внешней полосы.

Внимательный читатель заметит: после всех улучшений Spine всё ещё один. Значит ли это, что он остаётся single point of failure?

Формально — да, если смотреть на фабрику как на каноническую Spine–Leaf-архитектуру. В идеальном мире Spine тоже должно быть минимум два. Тогда отказ любого одного устройства на любом уровне не приводит к потере связности фабрики.

Но в нашей текущей топологии отказ Spine не равен полной остановке клиентского сервиса.

Причина в том, что два Leaf после переезда не завязаны на Spine как на единственную точку выхода наружу или единственный шлюз для серверов:

• каждый Leaf имеет собственную BGP-сессию к апстриму;
• каждый Leaf получает свой локальный default-route от оператора;
• оба Leaf анонсируют одинаковый набор наших внешних префиксов;
• гипервизоры подключены к обоим Leaf отдельными L3-связями;
• маршруты до виртуальных машин распространяются через BGP;
• если нет BGP-сигнализации до конкретного VM-префикса, сеть не считает этот путь рабочим.

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

При этом один Spine всё равно остаётся техническим компромиссом. Он приемлем для текущего масштаба и текущей топологии, но его не нужно выдавать за идеальную архитектуру. Когда появится следующий Leaf или вырастут требования к отказоустойчивости fabric-underlay, я буду предлагать вернуться к вопросу второго Spine.

В какой-то момент один Spine перестаёт быть разумным компромиссом и становится техническим долгом. Тогда фабрику нужно будет довести до более канонической Clos-топологии с избыточностью на каждом уровне.

Итоги второй части и что дальше
В результате мы не просто переехали из euNetworks в QupraDC. Мы использовали вынужденную миграцию как повод улучшить архитектуру.

До переезда схема была минимальной: один Leaf, один Spine, вся нагрузка в одной физической локации, внешний аплинк 2×10G, Leaf одновременно выполняет роли server leaf и border leaf, отказоустойчивость на уровне фабрики минимальная.

После переезда схема стала заметно сильнее: два Leaf в новой локации, серверные подключения разнесены по двум Leaf, внешние BGP-сессии к апстриму подняты с разных Leaf, внешняя физическая связность в QupraDC сразу собрана на 2×100G, DDoS-сервис перенесён в QupraDC, его подключения также разнесены по двум Leaf.

Главное — что мы не меняли архитектурную модель в процессе переезда. Новый Leaf встроился в уже существующую фабрику, серверы продолжили работать в routed-модели, VM-префиксы продолжили распространяться через BGP, а EVPN-VXLAN остался общей управляющей и сервисной основой площадки.

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

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

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

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

Следующий необходимый этап — второй независимый апстрим. Две BGP-сессии к одному оператору дают резервирование на уровне наших стыков, Leaf-коммутаторов и физических линков. Но они не защищают от аварии внутри сети самого ISP: проблем на магистрали, ошибок маршрутизации, отказов route-server'ов провайдера или неудачных изменений в его политике. В такой ситуации уже не так важно, что с нашей стороны подняты две сессии: если проблема находится внутри операторской сети, оба стыка могут деградировать одновременно.

Поэтому нужен хотя бы полуавтоматический резерв через другого оператора. На первом этапе это не обязательно должна быть полноценная схема с балансировкой. Достаточно иметь резервный default-route от второго апстрима, менее приоритетный через BGP policy: основной default используется через текущего оператора, а при его отказе трафик автоматически уходит через резервный путь.

Но здесь есть важный нюанс: такое переключение сработает само только если BGP-сессия действительно погасла и маршрут был отозван. Аварии внутри операторской сети не всегда выглядят именно так. Сессия может оставаться поднятой, default-route — присутствовать в RIB, а качество связности при этом уже стать неприемлемым. В таких случаях нужны мониторинг, понятные процедуры переключения и рабочий OOBM-доступ, чтобы можно было быстро вмешаться и поменять политику маршрутизации не через сломанную сеть.

И вполне вероятно, что в какой-то момент появится смысл вынести внешнюю маршрутизацию на полноценную пару border-router'ов операторского класса с full view. Но это уже следующий этап для нас: сотни гигабит трафика, несколько апстримов, более сложный traffic engineering и отдельные требования к пиринговой политике.

Ещё один очевидный шаг — второй Spine. Пока один Spine остаётся приемлемым компромиссом для текущей топологии, но при дальнейшем росте Leaf-коммутаторов и требований к отказоустойчивости его нужно будет добавить. Тогда фабрика станет ближе к канонической Clos-топологии: несколько Leaf, несколько Spine и отсутствие единственной точки отказа не только в underlay, но и в overlay control plane. В нашей схеме Spine участвует в распространении EVPN-информации, поэтому его резервирование важно не только для транспортного уровня, но и для управляющей плоскости overlay.

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

Автор статьи: Рене, сетевой инженер FirstVDS

firstvds.ru

Все серверы, расположенные в euNetworks, перенесены в новый дата-центр Qupra DC2 в Амстердаме. Услуги работают штатно, стоимость аренды не изменилась.

Открываем новую площадку в Амстердаме — Qupra DC2.

Qupra — надёжный оператор с 30-летним опытом работы. ЦОД спроектирован в соответствии с высокими стандартами безопасности, оснащён резервированными системами электроснабжения и кондиционирования. Подробнее о преимуществах новой площадки рассказали здесь.

Все серверы, расположенные в euNetworks, перенесли в новый дата-центр. Миграция прошла бесшовно: стоимость аренды серверов не изменилась, а все услуги работают в штатном режиме.

https://firstvds.ru