Агрегація посилань FreeBSD не швидше, ніж одна посилання

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

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

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

Ми перевірили, що кожен тестовий апарат має незалежний шлях до перемикача стійки і що файловий сервер, його NIC і комутатор мають пропускну здатність, щоб вивести це, розбиваючи 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 Гбіт / сек на два порти, мабуть, ping-ponging між ними. (І перемикачі 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 , не змінюючи результатів.

У нас немає другого NIC-сервера 4-портових для встановлення другого тесту. Через успішний тест з 4-ма окремими інтерфейсами, ми продовжуємо припускати, що жодне обладнання не пошкоджено. ³

Ми бачимо ці шляхи вперед, жоден з них не є привабливим:

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

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

3. Забудьте про агрегацію посилань і використовуйте кругоподібний DNS, щоб зробити замість цього балансування навантаження.

4. Замініть серверний NIC і переключіться знову, на цей раз з 10 GigE- матеріалів, приблизно за 4 × апаратну вартість цього експерименту LACP.

Виноски

1. Чому б ви не перейшли до FreeBSD 10? Оскільки FreeBSD 10.0-RELEASE все ще використовує пул ZFS версії 28, а цей сервер було оновлено до пулу ZFS 5000, нова функція у FreeBSD 9.3. Рядок 10. x не отримає цього, поки 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-адрес і побачите, чи змінено вирівнювання навантаження.