Агрегация ссылок FreeBSD не быстрее, чем одиночная ссылка

Мы поместили 4-портовый сетевой адаптер Intel I340-T4 на сервер FreeBSD 9.3 ¹ и настроили его для агрегации каналов в режиме LACP , пытаясь уменьшить время, необходимое для зеркального отображения данных с 8 до 16 ТиБ с главного файлового сервера, до 2- 4 клона параллельно. Мы ожидали получить совокупную пропускную способность до 4 Гбит / с, но независимо от того, что мы пробовали, она никогда не выйдет быстрее, чем совокупная пропускная способность 1 Гбит / с. ²

Мы используем, iperf3чтобы проверить это в спокойной локальной сети. ³ Первый экземпляр почти достигает гигабита, как и ожидалось, но когда мы запускаем второй параллельно, скорость двух клиентов падает примерно до ½ Гбит / с. Добавление третьего клиента снижает скорость всех трех клиентов до ~ ⅓ Гбит / с и так далее.

При настройке iperf3тестов мы позаботились о том, чтобы трафик всех четырех тестовых клиентов поступал в центральный коммутатор на разных портах:

Мы убедились, что у каждого тестового компьютера есть независимый путь назад к коммутатору стойки, и что файловый сервер, его сетевая карта и коммутатор имеют пропускную способность, чтобы справиться с этим, разбив lagg0группу и назначив отдельный IP-адрес каждому из четырех интерфейсов на этой сетевой карте Intel. В этой конфигурации мы достигли совокупной пропускной способности ~ 4 Гбит / с.

Когда мы пошли по этому пути, мы делали это со старым управляемым коммутатором SMC8024L2 . (Таблица данных в формате PDF, 1,3 МБ.) Это был не самый дорогой коммутатор своего времени, но он должен был это сделать. Мы думали, что переключатель может быть неисправен из-за его возраста, но обновление до более мощного HP 2530-24G не изменило симптом.

Коммутатор HP 2530-24G утверждает, что эти четыре порта действительно настроены как динамическая магистраль LACP:

# show trunks
Load Balancing Method:  L3-based (default)

  Port | Name                             Type      | Group Type    
  ---- + -------------------------------- --------- + ----- --------
  1    | Bart trunk 1                     100/1000T | Dyn1  LACP    
  3    | Bart trunk 2                     100/1000T | Dyn1  LACP    
  5    | Bart trunk 3                     100/1000T | Dyn1  LACP    
  7    | Bart trunk 4                     100/1000T | Dyn1  LACP    

Мы пробовали как пассивный, так и активный LACP.

Мы убедились, что все четыре порта NIC получают трафик на стороне FreeBSD:

$ sudo tshark -n -i igb$n

Как ни странно, tsharkпоказывает, что в случае только одного клиента коммутатор разделяет поток 1 Гбит / с по двум портам, по-видимому, пинг-понг между ними. (Оба коммутатора SMC и HP показали это поведение.)

Так как совокупная пропускная способность клиентов собирается только в одном месте - на коммутаторе в стойке сервера - только этот коммутатор настроен для LACP.

Неважно, с какого клиента мы начинаем первым или в каком порядке мы его запускаем.

ifconfig lagg0 на стороне FreeBSD говорит:

lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=401bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO>
    ether 90:e2:ba:7b:0b:38
    inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255
    inet6 fe80::92e2:baff:fe7b:b38%lagg0 prefixlen 64 scopeid 0xa 
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
    media: Ethernet autoselect
    status: active
    laggproto lacp lagghash l2,l3,l4
    laggport: igb3 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
    laggport: igb2 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
    laggport: igb1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
    laggport: igb0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>

Мы применили столько советов из руководства по настройке сети FreeBSD, сколько имеет смысл в нашей ситуации. (Многое из этого не имеет значения, например материал об увеличении максимального FD.)

Мы попытались отключить разгрузку сегментации TCP без изменений в результатах.

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

Мы видим эти пути вперед, ни один из них не привлекателен:

1. Купите больший, плохой коммутатор, надеясь, что реализация SMC LACP просто отстой, и что новый коммутатор будет лучше. (Обновление до HP 2530-24G не помогло.)

2. Посмотрите еще на laggконфигурацию FreeBSD , надеясь, что мы что-то упустили. ⁴

3. Забудьте об агрегации ссылок и используйте циклический DNS для обеспечения балансировки нагрузки.

4. Замените серверную сетевую карту и снова переключитесь, на этот раз с 10 гигабайтами , примерно в 4 раза дороже аппаратных средств этого эксперимента LACP.

Сноски

1. Вы спрашиваете, почему бы не перейти на FreeBSD 10? Поскольку FreeBSD 10.0-RELEASE по-прежнему использует пул ZFS версии 28, и этот сервер был обновлен до пула ZFS 5000, новой функции в FreeBSD 9.3. 10. х линия не получит , что до FreeBSD 10.1 отгружается около месяца , следовательно . И нет, перестройка из исходного кода для получения доступа к 10.0-STABLE не возможна, так как это рабочий сервер.

2. Пожалуйста, не спешите с выводами. Результаты нашего теста, приведенные далее в этом вопросе, говорят вам, почему это не дубликат этого вопроса .

3. iperf3это чистый сетевой тест. Хотя конечная цель состоит в том, чтобы попытаться заполнить этот агрегатный канал 4 Гбит / с с диска, мы пока не задействуем дисковую подсистему.

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

5. Я уже сошел с ума от этого.

Какой алгоритм балансировки нагрузки используется в системе и на коммутаторе?

Весь мой опыт работы с этим связан с Linux и Cisco, а не с FreeBSD и SMC, но все еще применяется та же теория.

Режим балансировки нагрузки по умолчанию в режиме LACP драйвера связывания Linux и в более старых коммутаторах Cisco, таких как 2950, ​​должен балансировать только на основе MAC-адреса.

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

Из вашей диаграммы не похоже, что вы отправляете трафик на шлюз по умолчанию, но я не уверен, что тестовые серверы находятся в 10.0.0.0/24, или тестовые системы находятся в других подсетях и маршрутизируются через интерфейс уровня 3 на коммутаторе.

Если вы маршрутизируете на коммутаторе, есть ваш ответ.

Решением этой проблемы является использование другого алгоритма распределения нагрузки.

Опять же, у меня нет опыта работы с BSD или SMC, но Linux и Cisco могут балансировать либо на основе информации L3 (IP-адрес), либо информации L4 (номер порта).

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