Привет, Хабр! Я – Николайчук Никита, ведущий инженер по сетевым технологиям в T2. Сегодня речь пойдет о старом добром агрегировании каналов (LAG). Очень часто приходится слышать популярную и крайне обтекаемую фразу «балансировка в LAG осуществляется на основе хэш-функции». Но почему у одних вендоров (ни на кого не намекаем) черным по белому написано: «Для равномерной балансировки число каналов должно быть степенью двойки», а другие это требование категорически отрицают? Данная статья не претендует на полноту изложения и математическую точность, однако я постараюсь доступно описать логику и методы балансировки в LAG, а также сделать акцент на особенностях реализации у разных вендоров. Возможно, для сетевых гуру данная статья не станет источником новых знаний, но она точно будет полезна для тех, кого вопросы про балансировку трафика в LAG на собеседовании ставят в тупик.
Способы построения LAG
Прежде чем обсуждать тонкости балансировки, рассмотрим крупными мазками наиболее популярные способы построения агрегированных каналов.
Статическое объединение каналов. В этом случае в явном виде указываются интерфейсы, которые входят в Port-Channel. При этом никакого согласования конфигурации и параметров с противоположной стороной не происходит.
Динамическое объединение каналов с использованием специальных протоколов (LACP/PAgP). Чаще всего используется протокол LACP (Link Aggregation Control Protocol), при этом у компании Cisco есть свой протокол PAgP (Port Aggregation Protocol), который появился раньше LACP, однако на сегодняшний день хоть и поддерживается, но практически не используется. В случае динамического объединения каналов необходимо также указать интерфейсы, которые будут объединяться в Port-Channel. После этого на них поднимается протокол LACP и согласовывает Port-Channel с устройством, которое подключено с другой стороны. Если это согласование произошло, то порты объединяются в группу и формируют Port-Channel. Если по какой-то причине согласование не произошло, Port-Channel не сформируется. В этой ситуации возможно несколько сценариев работы:
каждый порт работает независимо;
один порт работает независимо, а остальные переходят в состояние down;
все порты не функционируют и ждут того момента, когда удастся согласовать Port-Channel с противоположной стороной.
Рассмотрим основные преимущества и недостатки статического и динамического (на примере протокола LACP) объединения каналов в группу.
При статическом объединении каналов Port-Channel формируется практически мгновенно, и через него сразу начинает передаваться трафик. Очевидное преимущество в том, что в такой ситуации не тратится время на согласование параметров с противоположной стороной. Это же можно отнести и к недостаткам статического объединения каналов: нет протокола согласования, который позволяет понять, что находится с противоположной стороны Port-Channe. В частности, может возникнуть ситуация, когда в агрегацию добавлены интерфейсы, которые на самом деле скоммутированы в разные устройства (см. рис. 1), и часть трафика отправляется не по назначению.
При использовании протокола LACP такой Port-Channel не соберется. Это связано с тем, что одно из полей сообщений LACPDU, которыми обмениваются устройства в процессе согласования канала, – MAC-адрес устройства. Если через разные физические порты одного логического канала пришли LACPDU с разными значениями MAC, то агрегация согласована не будет. Отметим, что LACP позволяет детектировать и ситуацию, представленную на рисунке ниже (см. рис. 2). Желающие могут легко залабить этот сценарий и написать в комментарии, на основе каких полей LAСPDU устройства понимают, что «здесь что-то не так».
Таким образом использование LACP позволяет детектировать сценарии с некорректной коммутацией сетевого оборудования и конфигурацией Port-Channel, но имеет некоторую задержку, связанную с согласованием соседства с противоположной стороной.
Протокол LACP позволяет одновременно объединить до 16 интерфейсов в Port-Channel. При этом одновременно передавать пользовательский трафик могут не более 8 интерфейсов. Еще 8 интерфейсов будут работать в «горячем резерве»: при отказе одного из работающих интерфейсов на его место встанет один из резервных.
Теперь, освежив в памяти основные принципы построения агрегированного канала, можно переходить к тому, ради чего мы здесь собрались – к балансировке.
Балансировка трафика в LAG
Как я уже отметил ранее, основная часть производителей сетевого оборудования использует протокол LACP для согласования параметров агрегированного канала, при этом сама технология агрегации может называться по-разному. У Cisco – это технология EtherChannel (вне зависимости от того, какой протокол используется для согласования канала: LACP, PAgP или ручная агрегация); у большинства других производителей сетевого оборудования будет фигурировать название LAG.
На основе чего устройство (не умаляя общности, будем считать, что это – коммутатор) примет решение, в какой из интерфейсов агрегированного канала отправить трафик?
Реализация балансировки трафика не регламентирована в стандартах, однако, чаще всего за распределение трафика по каналам отвечает хэш-функция. Устройства, которые принимают решения о передаче трафика в Port-Channel, могут учитывать ряд параметров, на основании которых получают значение хэш-функции.
В качестве параметров, на основании которых формируется хэш-функция, могут выступать MAC-адреса отправителя/получателя, номер VLAN для тегированного трафика, IP-адреса отправителя/получателя, а также при использовании коммутаторов, которые могут анализировать заголовки транспортного уровня, в качестве параметров можно использовать номера портов отправителя/получателя и протокол транспортного уровня (TCP/UDP). В общем случае хэш-функцию можно представить следующим образом:
Статическое хэширование. Обычно выбор пути определяется остатком от деления полученного хэша на число доступных путей. Именно такое решение реализуется у большинства производителей сетевого оборудования. При этом устройства, которые могут анализировать TCP/UDP-сессии, для каждого TCP/UDP-потока считают свой хэш. Например, хэши для семи разных потоков могут принимать следующие значения (естественно, носят иллюстративный характер): 18 (поток 1), 41 (поток 2), 23 (поток 3), 64 (поток 4), 11 (поток 5), 42 (поток 6), 16 (поток 7). Отметим, что для каждого конкретного потока значения MACs, MACd, IPs, IPd, VLAN ID, Protocol, Ports, Portd одинаковые. А для двух разных потоков хотя бы один из этих параметров должен отличаться, чтобы и хэши получились разные. Тогда для Port-Channel, собранного из 4 интерфейсов, остатки от деления хэша на количество интерфейсов будут принимать следующие значения: 2 (поток 1), 1 (поток 2), 3 (поток 3), 0 (поток 4), 3 (поток 5), 2 (поток 6), 0 (поток 7). Значение остатка от деления совпадает с номером канала (от 0 до 3), в который будет распределён данный TCP/UDP-поток:
Статическое хэширование позволяет добиться достаточно равномерного распределения трафика по интерфейсам при большом количестве потоков.
Технология EtherChannel. Технология EtherChannel, разработанная и внедренная компанией Cisco, использует похожий подход, однако берутся остатки от деления не на число доступных путей (количество интерфейсов в агрегированном канале), а на максимальное число путей, которое поддерживает LACP (одновременно трафик могут передавать 8 интерфейсов в Port-Channel). Далее, в зависимости от количества физических интерфейсов в Port-Channel, в соответствие каждому пути (каналу) ставятся потоки с определенными значениями остатка от деления хэша на 8. В случае, если в Port-Channel собрано 8 каналов, логика EtherChannel не отличается от логики работы статического хэширования. Если каналов меньше 8, то в каждый из них могут распределиться потоки с несколькими значениями остатков от деления хэша на 8:
На рисунке ниже (см. рис. 5) показано распределение потоков по четырем каналам (самый нижний канал – нулевой, самый верхний – третий) в группе агрегации для технологии EtherChannel. Количество потоков и значения хэша взяты из примера выше.
Отметим также, что в EtherChannel при изменении количества интерфейсов в группе (например, при выходе интерфейса из строя) коммутатору не придется пересчитывать значения остатков для всех хэшей. Нужно будет только перераспределить потоки по новому количеству путей (см. таблицы 2 и 3) в соответствии со значениями остатков от деления. При этом технология EtherChannel эффективна, только если число доступных путей – степень двойки: если число доступных путей не является степенью двойки, то потоки распределятся по ним неравномерно (см. таблицy 2). Неравномерность распределения потоков по каналам агрегации конкретно в нашем примере связана с маленьким количеством потоков (сделано для наглядности). Отметим, что на некоторых моделях коммутаторов Cisco Catalyst реализована логика с 256 значениями остатков, что статистически позволяет более равномерно распределить трафик по каналам даже в случае, если количество линков в агрегации не будет степенью двойки. Очевидно, например, что для трех каналов распределение остатков в соотношении 86:85:85 будет более равномерным, чем 3:3:2 (см. таблицу 2).
Устойчивое/консистентное (Resilient/Consistant) хэширование. Очевидным минусом предыдущих решений является неустойчивое распределение трафика по интерфейсам: при изменении количества интерфейсов в группе агрегации необходимо выполнить перераспределение всех потоков. Рассмотрим алгоритм устойчивого (обычно в применении к балансировке в LAG используют именно этот вариант) хэширования и поймем, как данный алгоритм решает описанную проблему.
Рассмотрим множество из целых чисел R = {1, 2, …, S}, где S достаточно велико (порядка 232). Значение S определено программной реализацией алгоритма и заведомо больше любого возможного значения хэша от TCP/UDP-потока. Данный хэш назовем ключом потока. Каждому из k доступных путей (интерфейсов группы агрегации) поставим в соответствие числа R1, R2, …, Rk. Для Ri выполнено условие: 1 < Ri < S, i=1,…,k. Реализация алгоритма позволяет распределить Ri равномерно по множеству S (см. рис. 6).
Таким образом появляются полуинтервалы [0, R1), [R1, R2), [R2, R3), …, [Ri-1, Ri), [Ri, Ri+1), …, [Rk, S), длины которых примерно одинаковые в силу равномерности распределения Ri. Далее на множество R наносятся значения ключей для потоков. С каждым полуинтервалом [Ri-1, Ri) соотносится группа ключей потоков { KRi }. В данном решении каждый доступный путь – это конкретный полуинтервал, с которым проассоциирована группа потоков. В случае удаления одного из путей два полуинтервала будут объединены в один: например, при удалении пути i+1 полуинтервалы [Ri-1, Ri), [Ri, Ri+1) будут объединены в полуинтервал [Ri-1, Ri+1), и все потоки, которые были распределены на i+1-й путь автоматически перераспределятся на путь с номером i. Аналогично, при добавлении нового пути произойдет разбиение соответствующего полуинтервала на два независимых. Другими словами, алгоритм устойчив к изменению количества интерфейсов в группе агрегации (отсюда собственно и говорящее название):
выход из строя одного из интерфейсов LAG не повлияет на потоки, распределенные на другие интерфейсы группы агрегации;
добавление нового интерфейса в LAG сведет к минимуму перераспределение потоков между интерфейсами.
Отметим, что на практике применяются различные оптимизации данного алгоритма. Они позволяют перераспределить потоки вышедшего из строя интерфейса равномерно по оставшимся участникам LAG (см. рис. 7).
Устойчивое хэширование нашло широкое применение в линейках оборудования для ЦОДов, где требование, чтобы пакеты приходили к получателям в правильном порядке (в том числе во время сбоев интерфейсов в LAG), может являться критичным.
Это решение нашло также распространено при распределении трафика между балансировщиками нагрузки в ЦОДах. При использовании статического хэширования и большинства других алгоритмов балансировки выключение/поломка одного из балансировщиков группы приводит к тому, что запросы всех клиентов перераспределятся на другие балансировщики. Соответственно, клиенты будут направлены к другим серверам (естественно, актуально для сценариев, когда эти балансировщики не собраны в кластер, иначе можно даже говорить о сохранении Persistence для пользователей). В результате все операции, которые были начаты в рамках взаимодействия со старыми серверами, возобновить не получится: скачивание файлов из файловых хранилищ, загрузку данных на сервера и любые другие операции придется начинать сначала, даже если процесс перед перераспределением был практически завершен. Аналогичная проблема наблюдается и при балансировке подключений удаленных пользователей к группе VPN-шлюзов: если между шлюзами нет синхронизации (например, кластера, если мы говорим про Cisco ASA), и один VPN-шлюз выйдет из строя, все подключения перераспределятся и будут разорваны. В этой ситуации всем удаленным пользователям необходимо будет заново установить VPN-соединение, что в определенных ситуациях (тут полет фантазии безграничен) может быть достаточно критичным для бизнеса. Устойчивость консистентного хэширования (использовал этот вариант во избежание тавтологии) к изменению количества устройств в группе (в данном случае – балансировщиков/VPN-шлюзов) решает данную проблему: «переезд сессий» произойдет только у тех пользователей, которые были подключены к вышедшему из строя балансировщику/VPN-шлюзу.
Заключение
Для полноты картины хотелось бы сказать пару слов о решении vPC/MLAG (именно пару слов, я сознательно не планирую освещать в данной статье сценарии отказа и обсуждать полный путь развития этого решения от стека до vPC с "пересадкой" на VSS). Классический Port-Channel предполагает по одному устройству с одной и с другой стороны. В таком решении каждый из коммутаторов (или любых других устройств, между которыми строится Port-Channel) является точкой отказа. При этом количество каналов между устройствами уже не имеет значения – в случае отказа одного из устройств связь в любом случае пропадает:
В решениях ЦОД и крупных кампусных сетях с современным архитектурным дизайном появилась конструкция, которая называется vPC (virtual Port-Channel)/MLAG (Multi-chassis LAG) и обычно используется на уровне агрегации. В таком решении два коммутатора объединяются в vPC/MLAG-пару и представляются для всех остальных устройств как единое целое, в том числе отправляют одинаковый MAC-адрес устройства при согласовании LACP. Такое решение позволяет построить на коммутаторе SW3 (см. рис. 9) Port-Channel, физические каналы которого подключены и к SW1, и к SW2.
В классическом Port-Channel это было невозможно и приводило к потере трафика (см. рис. 1). В решении vPC/MLAG для SW3 это выглядит как обычный Port-Channel до одного физического устройства, а со стороны SW1 и SW2 – это vPC/MLAG-пара. В таком решении SW3 обычно является коммутатором доступа, а SW1 и SW2 – коммутаторами агрегации.
+ пара слов после заключения
Если вы хотите поделиться своим опытом, у вас есть вопросы или примеры кейсов, которые хочется разобрать, пожалуйста, пишите в комментарии, я с удовольствием продолжу общение.