Привет, Хабр! На связи Евгений Мартынов, CIO Рег.облака. Сегодня мы подключили вторую зону доступности облака в Москве на базе дата-центра «Медведково-2» . И вместе с новым запуском провели значительный апгрейд технологический базы: пересобрали сетевую архитектуру, ушли от большого L2, навели порядок в изоляции трафика и перевели API на BGP-анонсы. В статье расскажу про конкретные решения — как и что мы пробовали, какие процессы отложили и к каким выводам пришли.
Навигация по тексту:
Интро: зачем облаку понадобилась вторая зона доступности в Москве
Сегодня в Рег.облаке подключена сеть из 10 дата-центров уровня Tier III в разных регионах России. Мы строим ее как геораспределенный контур: площадки соединены между собой резервированными каналами, что снижает риски и позволяет разворачивать отказоустойчивые сервисы.
В Москве до недавнего времени у нас была одна крупная площадка публичного облака — KIAEHOUSE. Этот ЦОД стал ядром столичного контура, однако, для дальнейшего развития требовались дополнительные мощности. Параллельно мы видим спрос на дополнительные зоны доступности: компании всё чаще строят геораспределённые архитектуры и выбирают сценарии disaster recovery внутри региона.
Чтобы расширить пул мощностей и повысить отказоустойчивость внутри региона, мы решили запустить вторую площадку — «Медведково-2». Важный момент, что она не дублирует KIAEHOUSE, а дополняет ее: больше вычислительных ресурсов и хранилища, современная сетевая архитектура и интерконнект до 100 Гбит/с.
Теперь в Москве у нас доступен полноценный двухзонный контур: это дает клиента предсказуемые RTO/RPO — целевое время восстановления (RTO) и целевую точку восстановления (RPO), гибкость в сценариях репликации и балансировки, надежный сценарий disaster recovery.
Технические ресурсы новой облачной площадки
В московском регионе дата-центр KIAEHOUSE и новая площадка работают как равноправные зоны доступности. Вместе они формируют общий контур с резервом вычислительных ресурсов и обновлённой архитектурой сети.
В «Медведково-2» мы развернули дополнительные вычислительные ресурсы и хранилище, ввели новые линейки серверов (включая высокочастотные на AMD EPYC) и интерконнект до 100 Гбит/с внутри площадки и между зонами.
Ниже — ключевые характеристики.
Параметр |
Значение |
Виртуальные ядра (vCPU) |
до 25 000 |
Оперативная память |
30 ТБ |
Доступное хранилище |
более 1 ПБ |
Серверные линейки |
стандартные, производительные, высокочастотные (AMD EPYC) |
Сетевой интерконнект |
40 Гбит/с к серверам, |
Отказоустойчивость |
N+1 для ключевых элементов |
Благодаря этому «Медведково-2» открывает клиентам больше возможностей для масштабных проектов: от размещения ресурсоемких нагрузок до сценариев, где критична скорость сети и предсказуемость инфраструктуры.
На старте в «Медведково-2» для пользователей уже доступны виртуальные серверы разных классов ( IaaS) и сервис резервного копирования.
Сетевая инфраструктура: leaf–spine, border-leaf, OVN/Geneve
Логично, что когда облако растет, сетевая архитектура становится одним из ключевых ограничений.
L2 (канальный уровень) — это сеть, где все устройства находятся в одном большом сегменте и видят все широковещательные запросы друг друга.
Но такой подход удобен на старте и плохо масштабируется: широковещательные домены разрастаются, появляются ARP-штормы, а любое перемещение или расширение VLAN становится дорогим и сложным.
В других дата-центрах мы уже сталкивались с этими ограничениями, поэтому в «Медведково-2» изначально решили заложить другой подход.
Leaf–spine и border-leaf
Мы выбрали схему сети leaf–spine (структура, где есть «ствол» spine и «листья» leaf, соединенные между собой). Такая структура распределяет нагрузку равномерно и избавляет от узких мест.
Дополнительно мы используем border-leaf — это «лист», который работает как граница фабрики и внешних сетей, то есть именно через него облако общается с внешними доменами. Такой подход упрощает управление и позволяет масштабировать сеть без переделки всей фабрики.
Overlay на Geneve
Мы развернули виртуальную сеть (overlay) на базе Geneve (это современный аналог VXLAN, предназначенный для тех же задач, но с расширяемым форматом заголовка и большим функционалом). Geneve инкапсулирует L2-трафик в UDP, позволяя строить масштабируемые виртуальные сети поверх IP. За счет этого сеть остается предсказуемой и управляемой.
SDN на OVN
Для управления сетью мы используем программно-определяемую сеть OVN (Open Virtual Network). Это замена классического SDN, которая пришла на смену связке Neutron ML2/OVS в OpenStack. OVN позволяет централизованно управлять виртуальными сетями. CMS задаёт правила на логическом уровне, а система автоматически реализует их на инфраструктуре. Такой подход упрощает администрирование и делает изменения в сети быстрыми и предсказуемыми.
Что попробовали и почему отложили
Мы тестировали вариант с полноценным L3 между стойками — когда маршрутизация вынесена на уровень ToR-коммутаторов (Top of Rack). Дополнительно использовали BGP-анонсы от SDN для обмена маршрутами.
На пилоте выяснилось, что при таком подходе сервисный и клиентский трафик могут пересекаться. Это создает риск для изоляции и стабильности сервисов, поэтому мы отказались от такого решения и усилили разделение сетей.
Отказоустойчивый доступ к API — BGP вместо keepalived
На других площадках API OpenStack мы держали на классической схеме отказоустойчивости: два сервера с keepalived (VRRP-кластер виртуального IP) — утилитой, которая отслеживает состояние узлов и при сбое переводит трафик на резервный. Один из серверов работал в активном режиме, а второй оставался в резерве. Если основной сервер выходил из строя, резервный брал нагрузку на себя, но с паузой — именно в этот момент пользователи могли заметить задержку в работе API.
В новой зоне мы отказались от схемы с keepalived, потому что она давала паузу при переключении и ограничивала масштабирование. Вместо этого развернули несколько HAProxy и связали их через BGP с ECMP — маршрутизацией с несколькими равнозначными путями (equal-cost multi-path). Каждый сервер теперь одновременно анонсирует один и тот же адрес, и получается схема «актив–актив–актив»: все фронты API работают параллельно и делят нагрузку между собой.
Чтобы проверить этот сценарий, мы специально вывели один сервер из строя: оставшиеся фронты продолжили обслуживать трафик без задержек. Такой сценарий был заранее заложен в архитектуру: если один узел выходит из строя, остальные берут нагрузку без пауз и ручных переключений.
Изоляция трафика: «матрешка» туннелей
Мы понимали, что одна из ключевых задач в новой зоне — развести служебный и клиентский трафики так, чтобы они не пересекались. Это важно для устойчивости: любые изменения в служебном контуре (например, обновление или настройка SDN) не должны влиять на пользовательские сети.
На рынке обычно есть разные подходы: где-то служебный и клиентский трафик идут рядом, но с логическим разделением. Мы же решили выстроить многоуровневую схему — своеобразную «матрешку» из туннелей:
Фабрика leaf-spine — физическая сеть.
Опорные туннели (VXLAN между стойками) — базовый слой сети, на котором строятся и служебные, и клиентские сегменты
Туннели SDN (Geneve между нодами) — слой сети, на котором строятся клиентские сегменты.
Клиентские логические сегменты — изолированный пользовательский трафик внутри Geneve.
Таким образом сбой на одном уровне не перекидывается на другие — поведение сети предсказуемо.
Мониторинг и метрики
Следующий важный момент — это мониторинг. Известно, что надежная инфраструктура невозможна без мониторинга. В облаке мы используем связку Prometheus и Grafana, а также стандартные сервисные статистики OpenStack.
Prometheus собирает метрики сервисов (например, нагрузку или состояние интерфейсов), а Grafana показывает их в дашбордах и графиках. Вместе они дают понятную картину работы системы.
Такой набор закрывает базовые сценарии, Это делает сеть прозрачнее для инженеров: сбои видны раньше, а инциденты разбираются быстрее. Для клиентов это означает предсказуемость и стабильность сервисов даже при высокой нагрузке.
Что в итоге у нас получилось
Перевод API на схему с BGP+ECMP избавил от паузы при переключении и сделал систему горизонтально масштабируемой: новые серверы можно добавлять без ручных манипуляций. Для клиентов это значит предсказуемую работу API даже при росте нагрузки или отказе отдельных узлов.
Изоляция на трех уровнях в SDN-контуре также подтвердила устойчивость. Служебный и клиентский трафик идут раздельно, поэтому внутренние изменения не отражаются на пользовательских сервисах.
Выводы запуска и что мы сделали бы иначе
Запуск новой локации расширил московский контур Рег.облака и показал, что выбранные решения оправдали себя:
схема BGP+ECMP для API убрала задержки при переключениях и упростила масштабирование;
«матрешка» туннелей в SDN-контуре дала устойчивую изоляцию клиентского и служебного трафика;
Что мы сделали бы иначе
Основной вывод — при проектировании ресурсов лучше закладывать больший запас: нагрузка растет быстрее, чем кажется на старте. Нам это помогло скорректировать подход к планированию стоек на будущих площадках.
Что дальше: интерконнект и новые сервисы
Следующий шаг — связать площадки между собой. Мы планируем приватный интерконнект, чтобы клиенты могли строить свои сети сквозь разные зоны и управлять ими.
Параллельно развиваем сервисы: в ближайших планах запуск GPU-инстансов, объектного хранилища S3, управляемых баз данных и Kubernetes, а также расширение PaaS-направления.
Новая зона в «Медведково-2» стала еще одной точкой опоры в московском контуре. Для Рег.облака это упрощает масштабирование и по ресурсам, и по сетевой архитектуре. Кто знает, какую территорию мы будем осваивать и где встретимся с вами в следующий раз? Следите за обновлениями — будет интересно.