MLAG

Многие администраторы уже давно смирились с мыслью, что за удобство иметь несколько резервных путей в L2 сети приходится платить, задействуя только часть из имеющихся каналов. Это приблизительно как ехать на Ferrari по мегаполису в час пик — потенциал под капотом большой, но задействовать его не получается. Всему виной небезызвестный и традиционно используемый протокол Spanning Tree (в его множественных ипостасях). К числу его недостатков относятся следующие

— низкая скорость сходимости при выходе из строя компонентов сети (в сложных топологиях — десятки секунд)

— простаивание ресурсов (за которые, между прочим, заплачены деньги) — при наличии нескольких возможных путей между точками A и Б STP оставит активным только один.

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

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

— на какой скорости работает стек?

— как делится пропускная способность между коммутаторами стека? Какова логическая схема включения коммутаторов в стек — кольцо, шина? Как осуществляется контроль доступа к стековому каналу?

— что произойдет со стеком в случае выхода из строя master коммутатора? Каково будет время сходимости?

— что произойдет со стеком в ситуации split-brain?

Если вы уже используете стек в своей сети и можете уверенно ответить на каждый из предложенных вопросов — значит, это действительно подходящее решение в вашей ситуации. Однако бывают случаи, когда организовать стек не представляется возможным. К примеру, не поддерживается на коммутаторах (на уровне агрегации или ядра сети часто устанавливают модульные коммутаторы, которые не поддерживают функционал стекирования). В таких ситуациях стоит вспомнить о технологиях Link Aggregation.

В простом случае, когда речь идет о каналах, связывающих два коммутатора между собой, решение существует достаточно давно. У администратора есть возможность использовать либо статический механизм агрегации каналов, либо прибегнуть к динамическим протоколам, вроде стандартного LACP (Link Aggregation Control Protocol, 802.3ad).

В случае использования такого рода технологии агрегированный канал для протокола STP ‘виден’ как один (рис. 1).

Рис. 1

Однако, как упоминалось в начале статьи, “обмануть” STP — еще не полное решение (хотя и значительная его часть, ибо LAG позволяет значительно уменьшить время сходимости до времени порядка миллисекунд). Вторая часть задачи — обеспечить загрузку всех интерфейсов, участвующих в LAG. Иначе может случиться ситуация, когда в группе, к примеру, 2 интерфейса — а загружен всего один. Надеюсь, что большинство читателей этой статьи все же знают, каким образом происходит балансировка трафика по интерфейсам в LAG. Для тех же, кто ранее с этим не сталкивался, или просто не задавался таким вопросом (самая опасная, на мой взгляд, ситуация) — сделаю несколько пояснений.

Выбор исходящего физического интерфейса в группе LAG делается всегда на отправляющем коммутаторе. Алгоритм выбора заключается в хешировании некоторых атрибутов из заголовков проходящих пакетов(фреймов). Как правило, используются Source-MAC и Destination-MAC, Source-IP и Destination-IP, Source-L4-Port и Destination-L4-Port. Результатом работы хэш-функции является номер физического интерфейса в группе. Таким образом, важно выбрать правильный алгоритм балансировки, с учетом характера потоков трафика. К примеру, если основной объем трафика создается одним из серверов в ЦОД, то понятно, что Source-MAC (интерфейс сервера), Destination-MAC (интерфейс шлюза по умолчанию) и Source-IP(интерфейс сервера) для таких потоков будут одинаковыми. Следовательно, для более равномерной загрузки LAG, в хэширование нужно включить Destination-IP и, возможно, номера портов протокола 4 уровня. Или другой пример. Представим себе интернет-провайдера, подключающего абонентов по технологии PPPoE. Собственно заголовок IP пакета в такого рода подключениях запрятан достаточно глубоко (за заголовками PPPoE) и анализировать его возможности нет. Следовательно, использовать информацию L3 (и тем более L4) при балансировке в таких случаях неактуально. А вот L2 для этого сценария — как раз будет правильным выбором.

Объединение в LAG каналов, связывающих два коммутатора — не всегда достаточная мера для максимального задействования пропускной способности. Проблема остается, к примеру, на участках между коммутаторами доступа и агрегации (рис. 2).

Рис. 2

Или в случаях, когда требуется подключить сервер к двум разным коммутаторам (рис. 3).

Рис. 3

Как раз для таких ситуаций создана технология, позволяющая объединить в LAG группу порты, принадлежащие двум разным коммутаторам — примерно так, как на рис. 4. У разных производителей такого рода технологии называются по-разному. В этой статье я буду использовать термин MLAG — Multiswitch LAG.

Рис. 4

С точки зрения сервера (на его месте может быть коммутатор или любое другое устройство, это не принципиально), данная конструкция выглядит и настраивается как обычный LAG. На стороне же коммутаторов SW1 и SW2 (рис. 4) — все немного сложнее. Для того чтобы перейти к пояснению принципов работы, хотелось бы ввести в обращение такие сущности как control plane и data plane в коммутаторе. Если подходить к ним упрощенно, то в задачи data plane на коммутаторе входит собственно коммутация пакетов в соответствии с содержимым таблицы MAC адресов. А вот за формирование этой таблицы отвечает control plane. Условно говоря, это разделение функций в теле на мозг и мышцы. Мышцы выполняют работу, мозг — контролирует как работают мышцы.

Строго говоря, функционирование control plane не сводится лишь к формированию таблицы коммутации. Существуют еще и протоколы вроде STP и OSPF — и за обработку сообщений этих протоколов также отвечает control plane. В этой статье я бы хотел, прежде всего, дать общее представление о том, что такое MLAG. Поэтому предлагаю условиться о следующем — если в комментариях к этой статье не менее трех посетителей выскажут пожелание узнать больше о специфичных случаях совместного использования MLAG c STP, OSPF и пр. — я посвящу этому отдельную статью.

Так вот, возвращаясь к механизмам функционирования MLAG — вся хитрость заключена в том, как работают control plane и data plane на коммутаторах SW1 и SW2. Сразу необходимо отметить, что если LACP — это стандарт, то для MLAG — каждый производитель решает задачу по-своему. Как следствие, не существует ‘единственного правильного’ способа реализации этой технологии — и описание принципов работы тоже сильно привязано к определенному оборудованию. Однако, все же, можно выделить общие идеи решения этой задачи.

С точки зрения data plane, каждый коммутатор действует самостоятельно — за счет этого как раз достигается возможность обеспечить загрузку обоих каналов. Соответственно, вся задача организации MLAG сводится к организации совместной работы control plane двух коммутаторов. Координация действий достигается за счет обмена сообщениями между членами группы MLAG, по отдельно выделенному для этого каналу — Inter-Switch Connection, ISC (рис. 4).

При организации MLAG есть несколько вариантов. В одном из них явно выделяется master коммутатор, на котором control plane остается активным. Роль control plane второго коммутатора исключительно пассивна. Такая модель MLAG реализована, к примеру, у Cisco в устройствах линейки 6500 (VSS). Как мы увидим дальше, такого рода решения с совмещенной control plane (а фактически, это кластер) плохо себя ведут в ситуациях split-brain, в случае потери связи через ISC. Другой вариант — control plane обоих коммутаторов активны и независимы друг от друга, лишь синхронизируют необходимую информацию ‒ содержимое таблицы коммутации. Такая модель с расщепленной control plane реализована у Extreme, а также у Cisco в устройствах линейки Nexus (VPC).

Перейдем теперь к обсуждению принципов работы MLAG. Если вернуться к рис. 4, то видно, что в нарисованной топологии присутствует петля. Для ее предотвращения, при работе в штатном режиме трафик на канале ISC блокируется коммутаторами — это тоже одна из особенностей MLAG. Разблокирование происходит при переходе во внештатный режим, однако, об этом несколько позже.

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

С технической точки зрения штатный режим не настолько интересен, как случаи выхода из строя отдельных компонентов схемы. Да, вообще говоря, и не только с технической — т.к. это именно те ситуации, ради которых и задумывался MLAG. Рассмотрим, что может случиться.

В самом простом случае — выходит из строя один из коммутаторов. В такой ситуации трафик направляется по работающему каналу (рис. 5)

Рис. 5

В другом случае — выходит из строя один из каналов MLAG. В этом случае логика работы MLAG сводится к ‘открытию’ ISC и перенаправлению в него трафика. Схематично это изображено на рис. 6

Рис. 6

После восстановления канала связи коммутаторы снова блокируют трафик на ISC, корректируют таблицы коммутации, и обмен трафиком возобновляется в штатном режиме.

В третьем случае, еще чуть более сложном — отказывает канал ISC между коммутаторами. Здесь поведение будет зависеть от того, каким образом реализован MLAG у производителя — статически или с использованием LACP. В случае если используется статический механизм агрегирования, то проблем не наблюдается. Рассмотрим в качестве примера рис. 6. Сервер не будет знать об отказе ISC, для него по-прежнему будет существовать единый LAG. Трафик будет отправляться в соответствии с правилами балансировки, а коммутаторы будут направлять трафик в соответствии с локальными правилами коммутации.

В случае использования LACP — не все так однозначно. Дело в том, что при создании группы в LACP ведется контроль, какие порты в нее включать, а какие нет. Включаются только порты, для которых в полученных сообщениях LACPPDU т.н. System Identifier одинаков. Этот механизм призван защищать от ошибок при физической коммутации кабелей. В случае же со split-brain каждый из коммутаторов будет иметь собственный идентификатор. Следовательно, сервер должен будет переформировать LAG и в результате из одной группы может получиться две. К примеру, в случае VPC документация явно говорит о том, что один из коммутаторов в ситуации split-brain блокирует свои каналы MLAG (“If the vPC primary switch is alive, the vPC secondary switch will suspend its vPC member ports to prevent potential looping while the vPC primary switch keeps all its vPC member ports active”) .

Однако, можно пойти и другим путем — изменив поведение коммутаторов после split-brain. Если каждый из них сохранит System Identifier, то, как и в случае со статическим LAG, для сервера ничего не изменится и трафик будет следовать теми же путями, как и в штатном режиме. Такой подход применяют коммутаторы Extreme.

Напоследок я отложил экспериментальную часть, в которой хотел поговорить о скорости сходимости MLAG. У меня была возможность оценить ее в трех вышеописанных сценариях отказов, при условиях работы в окружении L2. Схема лабораторного стенда представлена на рис. 7.

Рис. 7

В лабораторных испытаниях использовались коммутаторы Extreme Networks (Summit x460, XOS 15.3). На компьютере (PC) установлен генератор пакетов, направляющий трафик на сервер. На сервере, соответственно, установлен сниффер. По количеству потерянных пакетов измерялось время пропадания связи в сети после отказа одного из компонентов (генератор создавал 100 пакетов в секунду, соответственно, каждый потерянный пакет эквивалентен 10мс времени).

В случае выхода из строя коммутатора или канала связи LAG время сходимости составило порядка 50-80 мс. В случае выхода из строя ISC пакеты не терялись. Сравните это время сходимости с STP и, как говорится, почувствуйте разницу.

В заключение статьи хотелось бы сделать следующее резюме. В проектах, с которыми нам в компании доводилось встречаться, применения MLAG было достаточно. Вы можете мне возразить, что в некоторых ситуациях он все же может выступить в роли ограничивающего фактора, т.к. на данный момент производители ограничивают число коммутаторов в MLAG (а, следовательно, и количество портов) до двух. В таких случаях я мог бы порекомендовать несколько направлений, в которых можно осуществлять поиски решения. Во-первых, это технологии TRILL и SPB. Они разрабатывались как замена STP в ЦОД, где необходимо обеспечить непрерывность функционирования и максимизировать утилизацию каналов связи. Второе направление — на мой взгляд, более перспективное — это переход на т.н. SDN — Software Defined Network, в частности, на использование протокола OpenFlow.