Максимальная пропускная способность агрегации каналов (LACP / 802.3ad)


10

Я наблюдаю некоторую путаницу в отношении связанных интерфейсов в Linux, и я хотел бы описать ситуацию в надежде, что кто-то сможет прояснить это для меня.

У меня есть два сервера: Сервер 1 (S1) имеет 4x 1 Гбит соединения Ethernet; Сервер 2 (S2) имеет 2x 1 Гбит соединения Ethernet. Оба сервера работают под управлением Ubuntu 12.04, хотя и с ядром 3.11.0-15 (из пакета lts-saucy linux-generic).

Оба сервера имеют все свои сетевые интерфейсы, объединенные в единый интерфейс bond0 со следующей конфигурацией (in /etc/network/interfaces):

bond-mode 802.3ad
bond-miimon 100
bond-lacp-rate fast
bond-slaves eth0 eth1 [eth2 eth3]

Между серверами есть пара коммутаторов HP, которые (я думаю) правильно настроены для LACP на рассматриваемых портах.

Теперь связь работает - сетевой трафик проходит счастливо на обе машины. И все соответствующие интерфейсы используются, так что агрегация не дает сбоев. Однако мне нужно как можно больше пропускной способности между этими двумя серверами, и я не получаю ~ 2 Гбит / с, чего я ожидал.

В моем тестировании я заметил, что каждый сервер выделяет каждое TCP-соединение (например, iperf, scp, nfs и т. Д.) Одному подчиненному интерфейсу. По сути, все кажется ограниченным максимумом в 1 гигабит.

Установив bond-xmit-hash-policy layer3+4, я могу использовать iperf -c S1 -P2для отправки на двух подчиненных интерфейсах, но на стороне сервера, прием по-прежнему происходит только на одном подчиненном интерфейсе, и поэтому общая пропускная способность ограничена 1 Гбит / с, то есть клиент показывает ~ 40-50 МБ / с. на двух подчиненных интерфейсах сервер показывает ~ 100 МБ / с на одном подчиненном интерфейсе. Без настройки bond-xmit-hash-policyотправка также ограничивается одним подчиненным интерфейсом.

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

Мое понимание LACP неверно? Или я где-то пропустил некоторые параметры конфигурации? Любые предложения или подсказки для расследования будет принята с благодарностью!

Ответы:


18

Быстрое и грязное объяснение состоит в том, что одна линия связи, использующая LACP, не будет разбивать пакеты по нескольким интерфейсам. Например, если у вас есть одно TCP-соединение, передающее потоковые пакеты от HostA к HostB, оно не будет охватывать интерфейсы для отправки этих пакетов. В последнее время я много смотрел на LACP, чтобы найти решение, над которым мы работаем, и это распространенное заблуждение, что «соединение» или «объединение» нескольких сетевых интерфейсов с LACP дает вам «пропускную способность» комбинированных интерфейсов. Некоторые производители сделали проприетарные драйверы, которые будут маршрутизироваться через несколько интерфейсов, но стандарт LACP отличается от того, что я читал. Вот ссылка на приличную диаграмму и объяснение, которое я нашел в HP при поиске похожих проблем: http://www.hp.com/rnd/library/pdf/59692372.pdf


1
Это все имеет смысл. Я понятия не имею, почему я не обнаружил свое заблуждение раньше; Должно быть, я просто обходил правильные условия поиска и страницы документации. Кажется, что в зависимости от сетевого оборудования, мы могли бы изменить режим хеширования src-dest и испытать удачу в мультиинтерфейсной пропускной способности, но я думаю, что на этом этапе я просто буду доволен тем, что у нас есть. Спасибо за ваши разъяснения и очень полезную ссылку.
Зеттен

Рад помочь. В последнее время я много читал об этом, пытаясь уточнить терминологию, касающуюся транкинга и соединения, которая по-разному используется разными поставщиками. Я обнаружил, что за пределами конкретных стандартов, таких как те, что определены поставщиками IEEE, некоторые термины используются взаимозаменяемо ...
Майк Найлор,

6
Документ больше не доступен по оригинальному URL, но он по-прежнему доступен через Интернет-архив: web.archive.org/web/20030324105208/http://www.hp.com/rnd/…
smbear

3

bond-xmit-hash-policy layer3+4устанавливает балансировку нагрузки с вашего исходного сервера на коммутатор. Он не устанавливает алгоритм балансировки нагрузки от вашего коммутатора ко второму серверу. Это почти наверняка все еще слой-2 или слой-3 сбалансированы, то есть совсем нет.


2

Ну, во-первых, когда вы используете командный драйвер, это создаст некоторые издержки и снизит ожидаемую максимальную пропускную способность, которая составляет ~ 940 МБ / с на адаптере 1 ГБ, на ~ 10%.

Я не уверен, какой у вас адаптер, но если вы используете встроенные драйверы, настройки, вероятно, не идеальны для максимальной пропускной способности. Вы можете добавить до 4 очередей, так как одна очередь на адаптере, вероятно, не может достичь скорости передачи.

Другое соображение заключается в том, что одна нить iperf, вероятно, не получит максимальной скорости. Для 1 ГБ, вероятно, более 2-6 потоков лучше, вы можете использовать простой скрипт bash для одновременного запуска нескольких потоков.

Для Intel NIC, но RSS и Hardware RSC могут влиять на пропускную способность, на Broadcom убедитесь, что ОО работает.

Первый шаг, однако, состоит в том, чтобы удалить LAG и просто попробовать протестировать 1 порт трафика в каждой системе, чтобы увидеть, какую пропускную способность он получает, сделать это со всеми портами, а затем попробовать 2. LACP - непостоянный зверь для настройки. верно, и я никогда не пытался настроить его на коммутаторе HP, только Force10 (до Dell).

Кроме того, почему есть пара выключателей?


Как описано в другом ответе, основной проблемой было мое понимание LACP, но просто для того, чтобы заполнить картину: боксы Linux используют драйвер связывания ядра. Каждый интерфейс в отдельности может увеличить пропускную способность почти до максимальной гигабитной (примерно 110-117 МБ / с в зависимости от другого трафика), поэтому я просто хотел увеличить пропускную способность, а не настраивать отдельные сетевые адаптеры. Что касается коммутаторов, у нас есть офис с несколькими офисами, и есть магистральные коммутаторы с оптоволоконным мультиплексором / демультиплексором и различными другими битами и бобами. У меня были оба сервера на одном коммутаторе HP 2920-48G для тестирования.
Зеттен

В iperf есть --parallelпараметр, который контролирует количество параллельных клиентских потоков, которые нужно запустить
8.8.8.8
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.