Как именно и конкретно работает хеширование адреса назначения LACP уровня 3?

Основываясь на более раннем вопросе более года назад ( мультиплексированный Ethernet 1 Гбит / с? ), Я ушел и установил новую стойку с новым провайдером с LACP-связями повсюду. Нам это нужно, потому что у нас есть отдельные серверы (одно приложение, один IP-адрес), обслуживающие тысячи клиентских компьютеров по всему Интернету со скоростью свыше 1 Гбит / с.

Предполагается, что эта идея LACP позволит нам преодолеть барьер 1 Гбит / с, не тратя целое состояние на коммутаторы 10GoE и сетевые адаптеры. К сожалению, я столкнулся с некоторыми проблемами, связанными с распределением исходящего трафика. (Это несмотря на предупреждение Кевина Куфала в приведенном выше связанном вопросе.)

Маршрутизатор ISP - это своего рода Cisco. (Я вывел это из MAC-адреса.) Мой коммутатор - HP ProCurve 2510G-24. А серверами являются HP DL 380 G5, работающие на Debian Lenny. Один сервер является горячим резервом. Наше приложение не может быть кластеризовано. Вот упрощенная схема сети, которая включает в себя все соответствующие сетевые узлы с IP-адресами, MAC-адресами и интерфейсами.

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

Поэтому я ушел и установил свой комплект на новую стойку и подключил кабели моего провайдера от их маршрутизатора. Оба сервера имеют связь LACP с моим коммутатором, а коммутатор имеет связь LACP с маршрутизатором ISP. С самого начала я понял, что моя конфигурация LACP была неправильной: тестирование показало, что весь трафик к каждому серверу и от него проходил по одному физическому каналу GoE исключительно между сервером и коммутатором и маршрутизатором.

После нескольких поисков в Google и большого количества времени RTMF, связанного с сетевыми картами Linux, я обнаружил, что могу управлять связыванием сетевых карт, модифицируя /etc/modules

# /etc/modules: kernel modules to load at boot time.
# mode=4 is for lacp
# xmit_hash_policy=1 means to use layer3+4(TCP/IP src/dst) & not default layer2 
bonding mode=4 miimon=100 max_bonds=2 xmit_hash_policy=1

loop

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

Нам нужен этот трафик, проходящий через оба физических канала. Прочитав и перечитав Руководство по настройке и настройке 2510G-24 , я обнаружил:

[LACP использует] пары адресов источника-получателя (SA / DA) для распределения исходящего трафика по транковым каналам. SA / DA (адрес источника / адрес назначения) заставляет коммутатор распределять исходящий трафик по каналам внутри группы СЛ на основе пар адресов источника / назначения. То есть коммутатор отправляет трафик с одного и того же адреса источника на один и тот же адрес назначения через одну и ту же транкинговую ссылку и отправляет трафик с одного и того же адреса источника на другой адрес назначения через другую ссылку, в зависимости от чередования назначений пути среди ссылки в багажнике.

Кажется, что в связанном канале представлен только один MAC-адрес, и поэтому мой путь от сервера к маршрутизатору всегда будет проходить по одному пути от коммутатора к маршрутизатору, потому что коммутатор видит только один MAC (а не два - один из каждый порт) для обеих ссылок LACP.

Понял. Но это то, что я хочу:

Более дорогой коммутатор HP ProCurve - это 2910al, использующий адреса источника и назначения уровня 3 в своем хэше. Из раздела «Распределение исходящего трафика по транковым каналам» в Руководстве по управлению и настройке ProCurve 2910al :

Фактическое распределение трафика через транк зависит от расчета с использованием битов из адреса источника и адреса назначения. Когда IP-адрес доступен, вычисление включает в себя последние пять бит IP-адреса источника и IP-адреса назначения, в противном случае используются MAC-адреса.

ХОРОШО. Итак, чтобы это работало так, как я хочу, адрес назначения является ключевым, поскольку мой исходный адрес является фиксированным. Это приводит к моему вопросу:

Как именно и конкретно работает хэширование LACP уровня 3?

Мне нужно знать, какой адрес назначения используется:

• IP-адрес клиента , конечный пункт назначения?
• Или IP-адрес маршрутизатора , следующего пункта назначения передачи физического канала.

Мы еще не ушли и купили сменный выключатель. Пожалуйста, помогите мне точно понять, является ли хеширование адреса назначения LACP уровня 3 тем, что мне нужно. Покупка другого бесполезного выключателя не вариант.

То, что вы ищете, обычно называют «политикой передачи хэша» или «алгоритмом передачи хэша». Он управляет выбором порта из группы агрегатных портов, с которых следует передавать кадр.

Попасть в руки стандарта 802.3ad оказалось непросто, потому что я не хочу тратить на него деньги. Сказав это, я смог собрать некоторую информацию из полуофициального источника, который пролил некоторый свет на то, что вы ищете. В соответствии с этой презентацией, проведенной в 2007 году в Оттаве, штат Огайо, штат Калифорния, IEEE High Speed ​​Study Group, отвечающей стандарту 802.3ad, не предусмотрены конкретные алгоритмы для «распределителя кадров»

Этот стандарт не требует какого-либо конкретного алгоритма (ов) распространения; однако любой алгоритм распределения должен обеспечивать, чтобы при приеме кадров сборщиком кадров, как указано в п. 43.2.3, алгоритм не должен вызывать а) неправильное упорядочение кадров, являющихся частью какого-либо данного разговора, или б) дублирование кадров , Вышеупомянутое требование для поддержания порядка кадров удовлетворяется за счет того, что все кадры, составляющие данный диалог, передаются по одной линии в том порядке, в котором они генерируются Клиентом MAC; следовательно, это требование не включает добавление (или модификацию) какой-либо информации в кадр MAC, ни какую-либо буферизацию или обработку со стороны соответствующего сборщика кадров для переупорядочения кадров.

Таким образом, какой бы алгоритм ни использовался драйвером коммутатора / сетевого адаптера для распределения передаваемых кадров, он должен соответствовать требованиям, изложенным в этой презентации (которая, предположительно, цитировалась из стандарта). Конкретный алгоритм не указан, определено только совместимое поведение.

Даже если не указан алгоритм, мы можем взглянуть на конкретную реализацию, чтобы понять, как этот алгоритм может работать. Например, драйвер «связывания» ядра Linux имеет 802.3ad-совместимую хэш-политику передачи, которая применяет эту функцию (см. Bonding.txt в каталоге Documentation \ network источника ядра):

Destination Port = ((<source IP> XOR <dest IP>) AND 0xFFFF) 
    XOR (<source MAC> XOR <destination MAC>)) MOD <ports in aggregate group>

Это приводит к тому, что как IP-адреса источника и назначения, так и MAC-адреса источника и назначения влияют на выбор порта.

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

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

На ваших диаграммах показаны запросы, поступающие напрямую на серверы из Интернета, но стоит указать, что прокси может сделать в этой ситуации. Если вы передаете запросы клиентов на ваши серверы, то, как говорит Крис в своем ответе, вы можете вызвать узкие места. Если этот прокси-сервер делает запрос со своего собственного IP-адреса источника, а не с IP-адреса интернет-клиента, у вас будет меньше возможных «потоков» в политике хеширования на основе строго уровня 3.

Политика передачи хэша также может учитывать информацию уровня 4 (номера портов TCP / UDP), при условии, что она соответствует требованиям стандарта 802.3ad. Такой алгоритм есть в ядре Linux, как вы указали в своем вопросе. Помните, что документация для этого алгоритма предупреждает, что из-за фрагментации трафик может не обязательно проходить по одному и тому же пути, и, как таковой, алгоритм не строго соответствует стандарту 802.3ad.

Удивительно, но несколько дней назад наше тестирование показало, что xmit_hash_policy = layer3 + 4 не будет иметь никакого эффекта между двумя напрямую подключенными серверами Linux, весь трафик будет использовать один порт. оба запускают xen с 1 мостом, который имеет связующее устройство в качестве члена. Очевидно, что мост может вызвать проблему, просто он не имеет смысла ВСЕ, учитывая, что будет использоваться хеширование на основе порта ip +.

Я знаю, что некоторые люди на самом деле умудряются выдвигать 180MB + по связанным ссылкам (то есть пользователи ceph), так что это работает в целом. Возможные вещи, на которые стоит обратить внимание: - Мы использовали старую CentOS 5.4 - Пример OPs будет означать, что второй LACP «снимает» соединения - имеет ли это смысл, когда-нибудь?

Что эта ветка и чтение документации и т. Д. Показали мне:

• Как правило, все знают много об этом, они хорошо излагают теорию по связующим принципам или даже стандартам IEEE, в то время как практический опыт близок к нулю.
• Документация RHEL в лучшем случае неполная.
• Документация по склеиванию с 2001 года и недостаточно актуальная
• Режим layer2 + 3, по-видимому, отсутствует в CentOS (он не отображается в modinfo, и в нашем тесте он отбрасывал весь трафик при включении)
• Не помогает, чтобы у SUSE (BONDING_MODULE_OPTS), Debian (-o bondXX) и RedHat (BONDING_OPTS) были разные способы задания настроек режима для каждой связи
• Модуль ядра CentOS / RHEL5 «безопасен для SMP», но не «поддерживает SMP» (см. Доклад о высокой производительности на Facebook) - он НЕ масштабируется выше одного ЦП, поэтому при соединении более высоких тактовых частот ЦП> многих ядер

Если кто-то заканчивает с хорошей высокопроизводительной установкой соединения или действительно знает, о чем он говорит, было бы здорово, если бы им потребовалось полчаса, чтобы написать новый небольшой документ, описывающий ОДИН рабочий пример с использованием LACP, без лишних вещей и пропускной способности. > одна ссылка

Если ваш коммутатор видит истинное назначение L3, он может хэшировать это. В основном, если у вас есть 2 ссылки, подумайте, что ссылка 1 предназначена для нечетных адресатов, а ссылка 2 - для четных адресатов. Я не думаю, что они когда-либо используют IP следующего перехода, если не настроены для этого, но это почти то же самое, что и использование MAC-адреса цели.

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

Вы будете в худшем состоянии, если где-то там есть балансировщик нагрузки, потому что тогда «удаленный» IP всегда будет либо IP-адресом балансировщика нагрузки, либо сервером. Вы можете обойти это немного, используя множество IP-адресов на балансировщике нагрузки и на сервере, но это хак.

Возможно, вы захотите немного расширить свой кругозор поставщиков. Другие поставщики, такие как экстремальные сети, могут хэшировать такие вещи, как:

Алгоритм L3_L4 - уровень 3 и уровень 4, объединенные IP-адреса источника и назначения и номера портов TCP и UDP источника и назначения. Доступно на коммутаторах серий SummitStack и Summit X250e, X450a, X450e и X650.

Таким образом, в основном, пока изменяется исходный порт клиента (который обычно сильно меняется), вы будете равномерно распределять трафик. Я уверен, что другие поставщики имеют аналогичные функции.

Даже хэширования на IP-адресе источника и назначения будет достаточно, чтобы избежать «горячих точек», если в миксе нет балансировщика нагрузки.

Я буду догадываться, что это от IP-адреса клиента, а не маршрутизатора. Реальные IP-адреса источника и назначения будут иметь фиксированное смещение в пакете, и это будет быстро для хэширования. Хэширование IP-адреса маршрутизатора потребовало бы поиска на основе MAC, верно?

Так как я только что вернулся сюда, я кое-что узнал к этому моменту: чтобы избежать седых волос, вам нужен приличный коммутатор, который поддерживает политику layer3 + 4, и то же самое в Linux.

Во многих случаях стандартная паяльная лампа ALB / SLB (режим 6) может работать лучше. Оперативно это отстой, хотя.

Я сам стараюсь использовать 3 + 4, где это возможно, поскольку мне часто нужна эта пропускная способность между двумя соседними системами.

Я также пытался с OpenVSwitch и однажды был случай, когда это нарушило потоки трафика (каждый первый пакет потерян ... я понятия не имею)