Обработка нештатных ситуаций в MLAG

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

Некоторое время назад я уже делал заметку о технологии MLAG (здесь). В этом блоге я хотел бы слегка дополнить тот текст, подробнее рассмотрев особенности поведения этой технологии во внештатном режиме в L3 окружении.

Почему я делаю упор именно на L3? Причины для этого две. Первая — если рассматривать работу MLAG в окружении L2 — действительно нет никаких проблем. Система полностью защищена от любого одиночного отказа (канал связи, устройство целиком или его часть). В том числе, и от выхода из строя канала связи ISC (InterSwitch Connection) — для этого сценария уместно несколько более развернутое объяснение.

Рис. 1

Для трафика, идущего с сервера (рис. 1), в случае выхода из строя ISC, ничего не изменится — таблицы коммутации и маршрутизации не поменяются, коммутаторы будут перенаправлять пакеты так же, как и в сценарии до отказа. Будет отсутствовать синхронизация этих таблиц — но это не большая проблема, и вот почему. Допустим, у одного из коммутаторов в таблице нет информации о MAC адресе сервера (например, истекло время жизни), а у другого — эта запись есть. Во-первых, связность с сервером не нарушается, пакеты с маршрутизатора ядра всегда будут доходить до него, хотя это и приведет к излишнему флудингу (напоминаю, что мы сейчас обсуждаем сценарий окружения L2, и пакет с неизвестным MAC адресом назначения будет копироваться во все порты данного VLAN). Во-вторых, такая ситуация не может длиться долго, так как рано или поздно сервер отправит хотя бы один фрейм по каждому из каналов LAG и отработает механизм MAC learning на коммутаторе.

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

В свете обозначенных выше двух причин, продолжим обсуждение. Рассмотрим рисунок 2.

Рис. 2

Сервер и маршрутизатор ядра (Core) находятся в разных VLAN. Шлюз по умолчанию для сервера находится на коммутаторах, образующих MLAG. Сервер начинает передавать и принимать трафик, работает механизм MAC learning в коммутаторах, формируются таблицы коммутации — все, как отображено на рис. 2. Причем, канал связи между коммутаторами служит для синхронизации информации об изученных MAC адресах.

<Небольшое отступление>. В англоязычной технической литературе достаточно широко распространены термины northbound и southbound направления. Общая идея таких сокращений — аналогия с географической картой. Направление вверх на схеме — север, вниз — юг. Будем в дальнейшем придерживаться этой терминологии.

Рассмотрим трафик в направлении север-юг (входящий к серверу). IP адресом назначения для таких пакетов будет 10.1.1.5. Маршрутизатор ядра направит этот трафик в соответствии с локальной таблицей маршрутизации, с учетом балансировки при наличии двух эквивалентных маршрутов. Трафик попадет на SW1 или SW2. Для любого из этих коммутаторов сеть 10.1.1.0 является непосредственно подключенной, поэтому, используя ARP, коммутатор узнает MAC адрес сервера и в соответствии с локальной таблицей коммутации направит трафик на порт номер 1. Вот здесь кроется один из нюансов, о котором я хотел бы поговорить (рис. 3).

Рис. 3

Допустим, пакет идет к серверу через SW1. Коммутатор отправляет ARP запрос через свой MLAG порт в сторону сервера. Сервер получает этот запрос, обрабатывает его и формирует ответ. Однако стоит помнить, что у сервера в группу LAG объединены два интерфейса. Может так случиться, что, в соответствии с алгоритмом выбора исходящего порта, ARP ответ направится к SW2. В случае, когда между коммутаторами присутствует канал ISC — этот фрейм по правилам коммутации будет направлен в ISC и достигнет адресата — SW1. Однако когда этот канал обрывается, часть трафика к серверу будет пропадать, т.к. SW2 не сможет перенаправить ARP ответ.

Каковы же подходы к парированию такой ситуации?
Первый вариант — архитектурный. Необходимо добавить еще один уровень иерархии в ЦОД, выделяя отдельно уровень доступа (L2) и отдельно — уровень аггрегации (L3). К примеру, это могло бы выглядеть следующим образом (рис. 4):

Рис. 4

В этом случае роль MLAG коммутаторов выполняют SW3 и SW4. Шлюз по умолчанию для сервера расположен на SW1 и SW2 (это может быть классический VRRP, к примеру). Изолировав MLAG в пределах L2, мы стабилизировали его работу — теперь выход из строя любого компонента по-прежнему не прерывает коммуникаций между сервером и внешним миром. Рассмотренная на рис. 2 ситуация при обрыве ISC здесь повториться не может, т.к. SW3 и SW4 имеют каналы связи к каждому из шлюзов по умолчанию (к SW1 и SW2), и, независимо от того, к которому из них придет ARP ответ от сервера, смогут направить его, соответственно, на MAC1 или MAC2. У этой схемы есть небольшой недостаток в плане масштабируемости. Если потребуется добавить коммутаторы на уровень доступа, то добавлять их нужно будет парами, т.к. образовать MLAG с уже существующими SW3 и SW4 они не смогут (максимальное количество коммутаторов в MLAG — 2). Кроме этого, станет невозможным растянуть один VLAN на несколько таких пар, т.к. это приведет к возникновению петли и необходимости запуска STP. А в случае использования технологий виртуализации в ЦОД, это достаточно существенное ограничение. К примеру, если при перезапуске виртуальной машины на другом сервере будет отсутствовать нужный VLAN (миграция прошла между серверами, подключенными к разным парам коммутаторов), то необходимо будет придумывать дополнительные ухищрения, вроде оверлейных сетей.

Второй вариант — технологический. Коммутаторы, участвующие в MLAG, могут детектировать ситуацию split-brain (как это, к примеру, сделано у Cisco в серии Nexus и у Juniper в их EX/QFX). Специально для этого выделяется еще один канал (keepalive), который должен идти по другой трассе, нежели ISC. В случае если происходит обрыв ISC, но остается активным keepalive, один из коммутаторов, настроенный на роль standby, отключает свои MLAG интерфейсы. Таким образом, активным остается единственный возможный путь для трафика.

Подводя итог, хочется сказать следующее. У каждой реализации MLAG есть свои области применения. Там, где можно ограничиться L2 — не стоит ожидать особых проблем от MLAG, в том числе и при внештатных ситуациях. Для случаев, когда необходимо маршрутизировать трафик — нужно помнить о том, что существует опасность split-brain. Конечно, достаточно весомым может являться аргумент о том, что канал ISC можно организовать с использованием технологии LAG, пустив несколько каналов по разным трассам и тем самым значительно уменьшив вероятность одновременного отказа. Но, все же, и в этом случае лучше подстраховаться и использовать один из предложенных выше вариантов парирования.