Назад | Перейти на главную страницу

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

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

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

Маршрутизатор провайдера - это своего рода 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's Руководство по управлению и настройке:

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

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

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

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

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

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

Получить в руки стандарт 802.3ad оказалось непросто, потому что я не хочу тратить на него деньги. Сказав это, я смог почерпнуть некоторую информацию из полуофициального источника, которая проливает свет на то, что вы ищете. За эта презентация с собрания группы исследования IEEE High Speed ​​Study Group 2007 г. в Оттаве, Онтарио, Калифорния Стандарт 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 + порта.

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

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

В некоторых случаях паяльная лампа ALB / SLB (mode6) может работать лучше. Хотя с практической точки зрения это отстой.

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

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