Вопрос: Как точно и конкретно работает хэш-процесс адресата LACP уровня 3?


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

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

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

alt text

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

alt text

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

alt text

С некоторыми поисковыми запросами Google и большим количеством времени RTMF, касающегося LINK NIC, я обнаружил, что могу контролировать связь NIC путем модификации /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

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

alt text

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

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

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

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

alt text

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

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

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

Как точно и конкретно работает хэш-процесс LACP уровня 3?

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

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

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


52
2017-08-17 10:33


Источник


Отличный, хорошо изученный вопрос! К сожалению, я не знаю ответа ... - Doug Luxem
Можете ли вы взглянуть на стоимость связующего дерева каждого моста / туловища на ProCurve? - dbasnett
Также государство и приоритет? Похоже, что при HP <---> Cisco, что соединительные линии могут не иметь одинакового приоритета и блокироваться. Реклама для смешивания продавцов ???? - dbasnett
Это, возможно, лучший форматированный вопрос, который я видел в случае ошибки сервера - sclarson
Надеюсь, кто-то может занять ту же самую осторожность в ответ, что и на вопрос. - Neil Trodden


Ответы:


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

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

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

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

Несмотря на то, что алгоритм не указан, мы можем взглянуть на конкретную реализацию, чтобы понять, как такой алгоритм может работать. Например, драйвер «привязки» ядра 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.


13
2017-08-19 22:47



Да, я разобрал сервер linux "передавать хеш-политику", (Очень образовательный опыт, который поставил этот вопрос возможным.) Это переключатель штопа, который имеет меня в маринаде. Спасибо за информацию о IP-фреймах - я немного слаб, как на более низких уровнях сетевого стека. На мой взгляд, кадр был адресован маршрутизатору, причем место назначения занято более глубоко в полезной нагрузке. :П - Stu Thompson


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

Я знаю, что некоторым людям удается надавить 180 МБ + на связанные ссылки (т. Е. Пользователи 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» (см. Разговор с highperformance в facebook) - он не масштабируется выше одного процессора, поэтому с привязкой более высоких часов процессора> много ядер

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


5
2018-06-16 12:30



Ухудшается: у разных версий Debian есть разные способы настройки склейки! Я фактически задокументировал, как я настраиваю свое соединение в сообщении в блоге, которое, похоже, получает приличный трафик. - Stu Thompson


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

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

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

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

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

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

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


2
2017-08-19 19:53



Благодарю. Балансировка нагрузки отсутствует. И я не беспокоюсь о входящем трафике - у нас есть коэффициент 50: 1: в отношении трафика. (Это приложение для веб-видео.) - Stu Thompson
Я думаю, что в вашем случае хэш по назначению не получит ничего, поскольку коммутатор увидит назначение как ваш сервер. L2 транспортная инженерия просто не очень хороша. И «хеш» в этом виде приложения будет довольно примитивным - цифра, которую вы можете сделать, - это собрать все биты в любом адресе (ах), и если результат равен 0, выйдите из одной ссылки или 1 выйдите другой. - chris
Как я понимаю из моей приведенной выше цитаты ProCurve 2910al, хэш находится на последних пяти битах источника а также место назначения. Таким образом, независимо от того, фиксирован ли один (мой сервер), другой будет меняться почти для каждого клиента на уровне 3. Уровень 2? Это моя текущая проблема - есть только один источник и один адрес назначения для хэша. - Stu Thompson


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


0
2017-08-19 16:47





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

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

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

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


-1
2018-03-26 18:24