Отказоустойчивость между ЦОДами без растягивания VLAN: архитектура на L3 с Балансировщиком 5А

Когда сервис размещён в двух ЦОДах, одна из первых задач — обеспечить его работу при отказе одной из площадок. На практике для этого до сих пор нередко растягивают VLAN между ЦОДами: обе площадки оказываются в одной подсети, а VIP можно переключать между балансировщиками с помощью VRRP.

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

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

Почему не стоит растягивать VLAN между ЦОДами

Сам по себе L2 stretch не является ошибкой. Есть системы, которым действительно нужна L2 adjacency между площадками, и есть технологии, которые позволяют такую сеть построить.

Вопрос скорее в другом: стоит ли создавать общий L2-домен только ради отказоустойчивости сервиса?

Чаще всего — нет.

Первая причина — увеличивается домен отказа. Пока у каждого ЦОДа свой L2, сетевые проблемы одной площадки в значительной степени остаются внутри неё. Когда VLAN растянут между площадками, часть событий L2 начинает затрагивать уже оба ЦОДа. То есть резервная площадка, которая должна страховать основную, сама становится частью общего сетевого контура.

Вторая проблема — зависимость от DCI. МежЦОДовый канал теперь нужен не просто для обмена данными между двумя площадками. Он становится частью L2-инфраструктуры, от которой зависит работа механизмов HA.

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

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

И наконец, если VLAN растягивается только для того, чтобы между двумя площадками работал VRRP, мы фактически подстраиваем архитектуру сети под ограничения конкретного механизма HA.

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

Поэтому логичнее разделить эти задачи: VRRP использовать внутри ЦОДа, а отказоустойчивость между ЦОДами строить на маршрутизации.

Что меняется при переходе на L3

При L3-схеме ЦОДы больше не нужно помещать в одну подсеть.

Например, сеть первого ЦОДа может быть 10.10.0.0/16, второго — 10.20.0.0/16. У каждого остаются свои VLAN, шлюзы и локальная сетевая инфраструктура. Между площадками работает обычная маршрутизация.

То есть вместо одного большого L2-домена мы получаем два самостоятельных сетевых домена:

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

При L2-подходе мы говорим сети: «VIP физически переехал с одного устройства на другое».

При L3-подходе задача формулируется иначе: «сервис доступен через этот ЦОД, поэтому маршрут к нему нужно вести сюда».

Именно эту задачу хорошо решает BGP.

Как в эту схему встраивается Балансировщик 5А

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

Предположим, сервис доступен по VIP:

10.100.10.10

Балансировщик может анонсировать в сеть маршрут:

10.100.10.10/32

При этом VLAN 10.100.10.0/24 между ЦОДами растягивать не требуется. Для сети VIP — это просто маршрут, доступный через определённый next hop.

В Балансировщике 5А для этого используется BGP и механизм Route Health Injection (RHI). В актуальной конфигурации L4/L7 RHI позволяет автоматически управлять анонсом VIP в зависимости от доступности клиентских серверов. Можно задать минимальный процент доступных backend'ов, при котором VIP должен оставаться в BGP-анонсе.

Получается следующая логика:

Пока сервис в ЦОДе работоспособен, Балансировщик 5А анонсирует VIP.

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

Если количество доступных backend'ов падает ниже заданного порога, ситуация уже считается проблемой сервиса целиком. В этом случае RHI снимает VIP из BGP-анонса. Маршрут через этот ЦОД исчезает, и сеть выбирает путь через вторую площадку.

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

Может возникнуть вполне реальная ситуация:

маршрутизатор → BGP → балансировщик работает → backend не работает

С точки зрения маршрутизации всё в порядке, но пользователь сервис не получает.

RHI связывает эти два уровня: состояние приложения начинает влиять на наличие маршрута к сервису.

И в данном сценарии это одна из ключевых ролей Балансировщика 5А.

Два уровня отказоустойчивости вместо одного

Если в каждом ЦОДе установлено по два балансировщика, гораздо логичнее разделить HA на два уровня.

Внутри каждого ЦОДа два экземпляра Балансировщика 5А работают в локальной HA-схеме. Здесь как раз уместен VRRP: оба узла находятся в одном L2-сегменте, один работает как MASTER, второй готов принять его роль при отказе.

А уже между ЦОДами используется BGP/RHI.

Такое разделение важно ещё и потому, что далеко не каждый локальный отказ должен приводить к переключению всего ЦОДа.

Допустим, в ЦОД-1 вышел из строя один балансировщик. Это локальная проблема. Второй узел принимает его роль по VRRP, и трафик продолжает идти через ЦОД-1.

Если отказал один backend, его исключает Health Check. Остальной пул продолжает работать, поэтому необходимости уводить пользователей в другой ЦОД тоже нет.

Если же недоступной становится значительная часть backend-пула и его состояние опускается ниже установленного порога, RHI может снять VIP из BGP-анонса. Вот здесь уже происходит переключение на другую площадку.

При полном отказе ЦОД-1 результат тот же: маршрут через него исчезает, и сеть оставляет путь через ЦОД-2.

За счёт этого небольшой локальный сбой не запускает более тяжёлый сценарий переключения между ЦОД-ами.

Что происходит при отказе канала между ЦОД

Это один из сценариев, в котором особенно хорошо видно отличие L3-архитектуры от растянутого VLAN.

Если общий L2 между площадками не используется, потеря непосредственной связности между ЦОДами сама по себе не разрушает локальную сеть каждой площадки. ЦОД-1 продолжает работать в своих VLAN, ЦОД-2 — в своих.

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

То есть межЦОДовый канал перестаёт быть обязательным условием существования общего L2-домена.

Это и есть одно из главных преимуществ L3: ЦОДы можно проектировать как действительно самостоятельные failure domains.

Active-Passive или Active-Active

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

В Active-Passive основной путь ведёт через ЦОД-1, а ЦОД-2 используется как резервный. Приоритет маршрутов задаётся BGP-политиками в сетевой инфраструктуре. Пока основной маршрут существует, трафик идёт через ЦОД-1. Если анонс исчезает, выбирается маршрут через ЦОД-2.

В Active-Active оба ЦОДа одновременно анонсируют VIP и принимают трафик. При соответствующей настройке сети маршрутизаторы могут использовать ECMP и распределять потоки между площадками.

BGP Active-Active для L4/L7-конфигураций поддерживается Балансировщиком 5А; при недоступности одного из модулей его BGP-сессия разрывается, после чего трафик остаётся на доступном модуле.

Но Active-Active предъявляет больше требований уже не к балансировщику, а к самому приложению. Если оба ЦОДа одновременно принимают запросы, данные, сессии и зависимые сервисы должны быть к этому готовы.

Поэтому выбор между Active-Passive и Active-Active — это не только сетевой вопрос.

А если у ЦОДов должны быть разные VIP?

Единый VIP, который анонсируется из двух ЦОДов через BGP, — не единственный вариант.

Иногда проще оставить у каждой площадки собственный адрес. Например:

ЦОД-1 — 10.10.100.10

ЦОД-2 — 10.20.100.10

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

У Балансировщика 5А есть отдельный GSLB-модуль, который позволяет выбирать сервер в том числе по географическому положению клиента, приоритету и доступности узлов.

Это особенно удобно, если площадки находятся в разных сетях или регионах и нет необходимости сохранять один IP сервиса.

Почему такая схема проще масштабируется

У L3-подхода есть ещё одно преимущество, которое становится особенно заметно по мере роста инфраструктуры.

Если появляется третий ЦОД, архитектуру не приходится принципиально переделывать.

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

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

Каждая площадка остаётся самостоятельной, а сеть знает, через какие площадки в данный момент доступны нужные сервисы.

Именно поэтому для распределённой инфраструктуры модель «L2 внутри площадки, L3 между площадками» обычно оказывается проще в эксплуатации и понятнее при масштабировании.

Как выглядит итоговая схема

Для двух ЦОДов с Балансировщиком 5А целевая архитектура может выглядеть следующим образом.

Внутри каждого ЦОДа работает своя L2-сеть. Пара Балансировщиков 5А обеспечивает локальную отказоустойчивость, например через VRRP.

Между площадками нет общего VLAN. Связность строится на L3.

Балансировщик проверяет состояние backend-сервисов и через RHI управляет анонсом VIP. Пока сервис способен принимать нагрузку, маршрут присутствует в сети. Если доступность падает ниже заданного порога, анонс снимается и маршрутизация переводит новый трафик на другую площадку.

В результате ЦОДы не приходится объединять в один L2-домен только ради того, чтобы обеспечить переключение сервиса.

Вывод

Растянутый VLAN — вполне рабочая технология, когда для него есть реальная необходимость. Например, если конкретное приложение или инфраструктурный компонент требует L2 adjacency между площадками.

Но использовать L2 stretch как базовый механизм межЦОДовой отказоустойчивости только потому, что «так проще перенести VIP», не всегда оправданно.

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

В такой схеме каждый механизм занимается своей задачей: VRRP обеспечивает локальную отказоустойчивость, Health Check следит за состоянием backend-серверов, RHI связывает состояние сервиса с анонсом VIP, а BGP определяет, через какой ЦОД этот сервис сейчас доступен.

Для Балансировщика 5А это не обходной сценарий, а штатная архитектура.