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

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

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

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

Мы проверили, что каждая тестовая машина имеет независимый путь обратно к коммутатору стойки и что файловый сервер, его сетевая карта и коммутатор имеют пропускную способность, чтобы выполнить это, разбив lagg0 group и присвоение отдельного 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. Купите коммутатор побольше и посложнее, надеясь, что реализация LACP SMC - отстой и новый коммутатор будет лучше. (Обновление до HP 2530-24G не помогло.)

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

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

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

Сноски

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

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

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

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

5. Я уже косился от этого.