Архитектура L3 Clos Fabric на базе Host-based Routing в HCI «ОТВ эв3»

Раздел: Архитектура | Дата публикации: 14 октября 2026 г.

Описываемая архитектура демонстрирует передовой подход к построению сетей в современных ЦОД — Routing to the Host (маршрутизация до хоста). В этой модели сетевой уровень (L3) заканчивается не на коммутаторе доступа, а непосредственно на сервере (хосте). Это позволяет полностью избавиться от классических ограничений L2-сетей (протокола STP, ARP-штормов, неэффективного использования каналов) и обеспечить максимальную горизонтальную масштабируемость.

В качестве эталонного примера развертывания в рассматриваемой топологии применяется гиперконвергентный кластер «ОТВ эв3».

1. Введение и концепция

Представленная конфигурация обеспечивает высочайшую отказоустойчивость и предсказуемость сетевой фабрики. Архитектура является vendor-neutral (вендоронезависимой): она одинаково успешно реализуется как на базе Open Source решений (FRR, SONiC), так и на проприетарном оборудовании (Cisco, Juniper, Arista, Huawei), поскольку опирается исключительно на стандартные RFC протоколов BGP и BFD.

Текущий статус валидации архитектуры:

• Логическая структура: L3 Clos Fabric (Spine-Leaf топология, где каждый хост фактически выступает в роли Leaf-узла).
• Data Plane (Плоскость данных): Балансировка трафика ECMP (Equal-Cost Multi-Path) на 3 узла работает корректно.
• Control Plane (Плоскость управления): Протокол BGP Anycast обеспечивает распределение нагрузки и отказоустойчивость Active-Active без использования устаревших механизмов VRRP/Keepalived.
• Сходимость (Convergence): Протокол BFD (Bidirectional Forwarding Detection) настроен для мгновенного обнаружения сбоев на физическом и логическом уровнях.

Рекомендация для продакшена: Данная конфигурация приоритетна для высоконагруженных кластеров баз данных, Kubernetes-инфраструктур и построения частных облаков на базе «ОТВ эв3».

2. Логическая схема сетевой топологии L3 Clos Fabric

ВНЕШНИЙ МИР (Internet / Core)
       |                   |
  +---------+         +---------+
  |  frr1   |         |  frr2   |   <-- ЯДРО СЕТИ (AS 65000)
  |(10.1.0.1|         |(10.2.0.1|       ECMP: Multipath-relax
  +---------+         +---------+
       |                   |
  -----+-------------------+-----   (L3 Fabric / eBGP Peering)
  /    |                   +----+ +----+       ...     +----+
|HCI | |HCI |               |HCI |  <-- УЗЛЫ КЛАСТЕРА (Hosts)
|0001| |0002|               |0003|
+----+ +----+               +----+
(AS 4200000021)             (AS 4200000023)
      |                   /
  -----+-------------------+-----
               |
       ANYCAST VIP (IP)
         192.168.0.2
   (Active-Active-Active)

2.1. Ключевые параметры сетевой инфраструктуры

3. Разбор компонентов и механизмов работы

3.1. Агрегация и ECMP (Equal-Cost Multi-Path)

На Spine-маршрутизаторах (frr1 и frr2) настроена функция maximum-paths 64 и активирована директива as-path multipath-relax.

• Как это работает: Маршрутизатор видит три эквивалентных пути к VIP-адресу 192.168.0.2/32 (через каждый узел HCI «ОТВ эв3»). Команда multipath-relax заставляет систему считать пути одинаковыми, даже если номера AS хостов различаются (при условии равенства длины AS_PATH).
• Результат: Трафик распределяется по всем доступным путям одновременно. Это кратно увеличивает общую пропускную способность сети и обеспечивает балансировку нагрузки без использования выделенных аппаратных балансировщиков (Load Balancer).

3.2. Пример конфигурации программного BGP-роутера (frr1)

Ключевая особенность конфигурации — применение динамических соседей (Dynamic Neighbors). Это критически важно для масштабируемых Clos-сетей: новые вычислительные узлы подключаются автоматически без ручной правки конфигурации на Spine-коммутаторах.

frr defaults traditional
hostname frr1
log file /var/log/frr/frr.log
no ipv6 forwarding
service integrated-vtysh-config
!
route-map ALLOW-ALL permit 10
!
router bgp 65000
 bgp router-id 10.1.0.1
 ! Разрешение балансировки между разными автономными системами хостов
 bgp bestpath as-path multipath-relax
 !
 neighbor HCI-DYNAMIC peer-group
 neighbor HCI-DYNAMIC remote-as external
 neighbor HCI-DYNAMIC bfd
 !
 bgp listen limit 10
 bgp listen range 10.1.0.0/24 peer-group HCI-DYNAMIC
 !
 address-family ipv4 unicast
  maximum-paths 64
  maximum-paths ibgp 64
  network 10.1.0.0/24
  neighbor HCI-DYNAMIC next-hop-unchanged
  neighbor HCI-DYNAMIC default-originate
  neighbor HCI-DYNAMIC route-map ALLOW-ALL in
  neighbor HCI-DYNAMIC route-map ALLOW-ALL out
 exit-address-family
exit

Пояснения к общим системным параметрам и настройкам BGP:

• frr defaults traditional: устанавливает классические значения таймеров и параметров протоколов.
• service integrated-vtysh-config: сохраняет всю конфигурацию в один файл frr.conf, не разбивая её по отдельным демонам.
• bgp listen range 10.1.0.0/24 peer-group...: включает режим Dynamic Neighbors. Маршрутизатор слушает входящие соединения из указанной подсети и автоматически создает сессии.
• neighbor HCI-DYNAMIC default-originate: автоматически генерирует и анонсирует маршрут по умолчанию (0.0.0.0/0) всем динамическим соседям.

3.3. Пример конфигурации реализации L3 to the Host на узле hci-0001

Сервер сам становится полноценным участником BGP-процесса. Это устраняет необходимость в L2-технологиях агрегации (MLAG/LACP) и использует ECMP для балансировки исходящего трафика.

frr defaults traditional
hostname hci-0001
log file /var/log/frr/frr.log
!
ip forwarding
!
! Фильтр для выделения только хостовых маршрутов /32
ip prefix-list HCI-NET permit 192.168.0.0/22 ge 32
!
route-map RM-HCI-NET permit 10
 match ip address prefix-list HCI-NET
 set origin igp
!
router bgp 4200000021
 bgp router-id 192.168.0.21
 ! Прямое подключение к двум независимым фабрикам/коммутаторам
 neighbor 10.1.0.1 remote-as 65000
 neighbor 10.2.0.1 remote-as 65000
 neighbor 10.1.0.1 allowas-in 1
 neighbor 10.2.0.1 allowas-in 1
 neighbor 10.1.0.1 description ROUTER-FRR-0001
 neighbor 10.2.0.1 description ROUTER-FRR-0002
 neighbor 10.1.0.1 bfd
 neighbor 10.2.0.1 bfd
 !
 address-family ipv4 unicast
  maximum-paths 2
  ! Экспорт локальных адресов приложений и VIP в BGP
  redistribute connected route-map RM-HCI-NET
  !
  neighbor 10.1.0.1 activate
  neighbor 10.1.0.1 route-map ALLOW-ALL in
  neighbor 10.1.0.1 route-map ALLOW-ALL out
  neighbor 10.2.0.1 activate
  neighbor 10.2.0.1 route-map ALLOW-ALL in
  neighbor 10.2.0.1 route-map ALLOW-ALL out
 exit-address-family
!
route-map ALLOW-ALL permit 10
exit

Пояснения к ключевым параметрам хоста:

• ip forwarding: включает на уровне ядра Linux пересылку пакетов, превращая операционную систему сервера в маршрутизатор.
• allowas-in 1: разрешает прием префиксов, содержащих собственный номер AS в пути (до одного повторения), что необходимо в некоторых Clos-топологиях для сохранения связности без риска образования петель.
• redistribute connected route-map...: сервер берет свои локальные IP-адреса (включая адрес СУБД) и анонсирует их во внешнюю сеть.

3.4. Пример конфигурации сетевого интерфейса для работы базы данных и виртуального адреса

Для реализации концепции Host-based Routing де-факто стандартом является использование виртуальных изолированных интерфейсов типа dummy. В отличие от физических портов, они всегда находятся в статусе UP.

auto lo
iface lo inet loopback

# Анонс виртуального Anycast VIP для endpoint API «ОТВ эв3»
auto vip_adm
iface vip_adm inet static
    address 192.168.0.2
    netmask 255.255.255.255
    pre-up ip link add vip_adm type dummy
    post-down ip link del vip_adm

# Объявление локального прикладного адреса конкретного хоста
auto hci
iface hci inet static
    address 192.168.0.21
    netmask 255.255.255.255
    pre-up ip link add hci type dummy
    post-down ip link del hci

Почему это важно:

Если приложение (например, СУБД Galera Cluster или API-сервис «ОТВ эв3») привязано к IP-адресу физического интерфейса (eth0), то при падении линка на сетевой карте сервис станет недоступен локально. Интерфейс dummy гарантирует перманентную локальную доступность адреса, в то время как динамический протокол BGP берет на себя задачу распространить информацию о путях к этому адресу через оставшиеся «живые» физические аплинки. Маска 255.255.255.255 (/32) указывает на то, что адрес является чисто хостовым и не привязан к физическому кабельному пространству.

3.5. Anycast как замена VRRP

Традиционный протокол VRRP/Keepalived работает по неэффективному принципу Active-Passive (один узел активен, остальные простаивают). В рассматриваемой архитектуре все три узла инфраструктуры «ОТВ эв3» одновременно анонсируют один и тот же IP 192.168.0.2 на интерфейсах lo:vip_admin. Сеть функционирует в режиме Active-Active-Active. При выходе из строя одного узла BGP-сессия разрывается, и маршрут автоматически удаляется из таблиц коммутаторов.

3.6. Быстрое обнаружение отказов (BFD)

Использование протокола BFD на всех узлах позволяет обнаруживать падение линка или зависание демона маршрутизации за доли секунды (миллисекунды). Это критически важно для синхронных баз данных Galera в составе «ОТВ эв3», так как позволяет избежать долгого ожидания стандартных тайм-аутов BGP (до 180 секунд) и предотвращает возникновение сетевых расщеплений.

4. Перенос на физическую архитектуру Leaf-Spine

Логическая структура ПО полностью повторяет topology промышленной физической сети Clos Fabric. При миграции на физическое «железо» роли распределяются следующим образом:

4.1. Физический Spine-уровень

Заменяет программные роутеры frr1 и frr2. В качестве Spine выступают высокопроизводительные магистральные коммутаторы. В физической сети они не имеют прямого подключения друг к другу. Их единственная задача — аппаратная коммутация транзитных пакетов между Leaf-коммутаторами на максимальной скорости порта (Line-rate) с использованием ECMP.

4.2. BGP Unnumbered (RFC 5549): избавляемся от IP-адресов на стыках

В классическом eBGP-дизайне для связи каждого сервера с ToR-коммутатором требуется выделить point-to-point подсеть (например, /31). Если в ЦОД тысячи серверов, планирование, распределение и мониторинг этих тысяч мелких подсетей превращается в административный кошмар. Архитектура FRR позволяет полностью решить эту проблему.

• В чем суть технологии: Вместо явного указания IP-адреса соседа в конфигурации (neighbor 10.1.0.1) мы пишем привязку к физическому интерфейсу: neighbor enp2s0 interface.
• Техническая реализация: Сессии eBGP поднимаются поверх автоматически сгенерированных IPv6 Link-Local адресов (интерфейсы обмениваются ими по умолчанию при включении IPv6, вычисляя их на основе своего MAC-адреса).
• Передача IPv4 через IPv6: Благодаря стандарту RFC 5549, в рамках этой IPv6-сессии маршрутизаторы без проблем обмениваются привычными IPv4-маршрутами (в нашем случае — префиксами /32 хостов и Anycast VIP). В качестве Next-Hop для IPv4-маршрута используется IPv6 Link-Local адрес соседа.

4.3. Физический Leaf-уровень (ToR-коммутаторы)

Серверы подключаются напрямую к Leaf-коммутаторам доступа. При этом Leaf больше не является Default Gateway для сервера через традиционные ARP/VLAN механизмы. Между сервером и ToR-коммутатором настраивается eBGP-соседство (либо через компактные подсети /31, либо через экономный механизм BGP Unnumbered на базе IPv6 Link-Local адресов). На Leaf-коммутаторах полностью отсутствуют VLAN-интерфейсы (SVI) для клиентских подсетей — фабрика остается «чистым» Layer 3 доменом.

4.4. Преимущества сохранения L3 в ОС (Host-based Routing)

• Масштабируемость (Scale-out): Чтобы добавить в кластер еще 100 узлов, не нужно менять настройки VLAN на коммутаторах. Достаточно физически подключить сервер, и он сам анонсирует свои ресурсы в общую сеть.
• Устранение «L2-домена»: Сетевые проблемы одного сервера (например, ARP-шторм или петля) физически не могут повлиять на соседние серверы, так как они изолированы друг от друга на уровне L3.
• Контроль трафика: ОС сервера сама решает, через какой интерфейс отправить пакет, основываясь на метриках BGP. Мы получаем честный ECMP прямо от процессора сервера до ядра сети.
• Мобильность сервисов: Можно перенести любой сервис или базу данных на другой физический сервер в любой части ЦОДа. Его Anycast IP (VIP) просто «переедет» вместе с ним, а BGP обновит маршруты по всей фабрике за доли секунды.

4.5. Техническая реализация Dual-ToR

В классических L2-сетях для подключения сервера к двум коммутаторам требуется сложный MLAG/vPC. В предлагаемом решении никакие MLAG не нужны. Сервер просто имеет две независимые BGP-сессии. Если один ToR-коммутатор уходит на обслуживание, BGP на сервере фиксирует это через BFD и мгновенно переключает весь трафик на второй линк.

5. Вывод и стратегия развития

Приведенная в качестве примера сетевая топология на FRR практически готова к развертыванию на реальное железо и рекомендуется для применения в составе complexes под управлением «ОТВ эв3».

• Железо: Подойдут любые коммутаторы с поддержкой BGP — как Bare-metal решения под управлением SONiC или Cumulus Linux, так и классическое оборудование Arista, Cisco, Huawei.
• Автоматизация: При описанном подходе конфигурация Leaf-коммутаторов становится полностью однотипной и шаблонной, что идеально для автоматизации через Ansible или Terraform.
• Гибкость: Пользователь получает сетевую инфраструктуру, которая работает по принципам глобальной сети Интернет — максимально надежно, предсказуемо и строго на базе открытых стандартов.