Каждый современный сервер работает под высокой нагрузкой и выделяет от 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