Agregacja linków FreeBSD nie szybciej niż pojedynczy link

Umieściliśmy 4-portową kartę sieciową Intel I340-T4 na serwerze FreeBSD 9.3 ¹ i skonfigurowaliśmy ją do agregacji łączy w trybie LACP, próbując skrócić czas potrzebny do wykonania kopii lustrzanej 8 do 16 TiB danych z głównego serwera plików do 2- 4 klony równolegle. Spodziewaliśmy się przepustowości do 4 Gb / s, ale bez względu na to, czego próbowaliśmy, nigdy nie wychodzi ona szybciej niż 1 Gb / s. ²⁾

Używamy iperf3do testowania tego w spoczynkowej sieci LAN. ³ Pierwsza instancja prawie osiągnęła gigabit, zgodnie z oczekiwaniami, ale kiedy rozpoczynamy drugą równolegle, dwaj klienci zmniejszają prędkość do około ½ Gbit / s. Dodanie trzeciego klienta zmniejsza prędkość wszystkich trzech klientów do ~ ⅓ Gbit / s i tak dalej.

Zadbaliśmy o skonfigurowanie iperf3testów, w których ruch wszystkich czterech klientów testowych dociera do centralnego przełącznika na różnych portach:

Sprawdziliśmy, czy każda maszyna testowa ma niezależną ścieżkę z powrotem do przełącznika zębatkowego oraz że serwer plików, jego karta sieciowa i przełącznik mają przepustowość, aby to zrobić, dzieląc lagg0grupę i przypisując oddzielny adres IP każdemu z czterech interfejsów na tej karcie sieciowej Intel. W tej konfiguracji osiągnęliśmy łączną przepustowość rzędu ~ 4 Gbit / s.

Kiedy zaczynaliśmy tę ścieżkę, robiliśmy to ze starym przełącznikiem zarządzanym SMC8024L2 . (Arkusz danych PDF, 1,3 MB.) To nie był najwyższy przełącznik tego dnia, ale powinien to zrobić. Myśleliśmy, że może to być wina przełącznika z powodu jego wieku, ale uaktualnienie do znacznie bardziej wydajnego HP 2530-24G nie zmieniło objawu.

Przełącznik HP 2530-24G twierdzi, że cztery omawiane porty są rzeczywiście skonfigurowane jako dynamiczny łącznik 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    

Wypróbowaliśmy zarówno pasywny, jak i aktywny LACP.

Sprawdziliśmy, że wszystkie cztery porty NIC generują ruch po stronie FreeBSD dzięki:

$ sudo tshark -n -i igb$n

Co dziwne, tsharkpokazuje, że w przypadku tylko jednego klienta przełącznik dzieli strumień 1 Gbit / s na dwa porty, najwyraźniej ping-pong między nimi. (Zarówno przełączniki SMC, jak i HP wykazały takie zachowanie).

Ponieważ łączna przepustowość klientów łączy się tylko w jednym miejscu - na przełączniku w szafie serwerowej - tylko ten przełącznik jest skonfigurowany dla LACP.

Nie ma znaczenia, w którym kliencie uruchamiamy jako pierwszy ani w jakiej kolejności go uruchamiamy.

ifconfig lagg0 po stronie FreeBSD mówi:

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>

Zastosowaliśmy tyle rad zawartych w przewodniku dostrajania sieci FreeBSD, ile ma to sens w naszej sytuacji. (Wiele z nich jest nieistotnych, na przykład rzeczy dotyczące zwiększania maksymalnych FD).

Próbowaliśmy wyłączyć odciążanie segmentacji TCP bez zmiany wyników.

Nie mamy drugiej 4-portowej karty sieciowej do skonfigurowania drugiego testu. Z powodu udanego testu z 4 oddzielnymi interfejsami zakładamy, że żaden sprzęt nie jest uszkodzony. ³⁾

Widzimy te ścieżki naprzód, żadna z nich nie jest atrakcyjna:

1. Kup większy, mocniejszy przełącznik, mając nadzieję, że implementacja SMC LACP jest do bani, a nowy przełącznik będzie lepszy. (Aktualizacja do HP 2530-24G nie pomogła.)

2. Wpatrz się laggtrochę w konfigurację FreeBSD , mając nadzieję, że coś przeoczyliśmy. ⁴

3. Zapomnij o agregacji linków i użyj zamiast tego okrągłego systemu DNS, aby uzyskać równoważenie obciążenia.

4. Wymień kartę sieciową serwera i przełącz ponownie, tym razem na 10 GigE , przy około 4 × koszcie sprzętu tego eksperymentu LACP.

Przypisy

1. Pytasz, dlaczego nie przejść na FreeBSD 10? Ponieważ FreeBSD 10.0-RELEASE nadal korzysta z puli ZFS w wersji 28, a ten serwer został zaktualizowany do puli ZFS 5000, nowa funkcja w FreeBSD 9.3. Linia 10. x nie dostanie tego, dopóki FreeBSD 10.1 nie zostanie wysłany za miesiąc . I nie, przebudowa ze źródła, aby dostać się do krawędzi krwawienia 10.0-STABLE, nie jest opcją, ponieważ jest to serwer produkcyjny.

2. Nie wyciągaj pochopnych wniosków. Nasze wyniki testu w dalszej części pytania mówią, dlaczego nie jest to duplikat tego pytania .

3. iperf3jest czystym testem sieci. Podczas gdy ostatecznym celem jest próba wypełnienia tej rury agregacyjnej 4 Gb / s z dysku, nie jesteśmy jeszcze zaangażowani w podsystem dyskowy.

4. Może wadliwy lub źle zaprojektowany, ale nie bardziej zepsuty niż w momencie opuszczenia fabryki.

5. Zrobiłem to już ze skrzyżowanymi oczami.

Jaki algorytm równoważenia obciążenia jest używany zarówno w systemie, jak i przełączniku?

Całe moje doświadczenie z tym związane jest z Linuksem i Cisco, nie FreeBSD i SMC, ale ta sama teoria nadal obowiązuje.

Domyślnym trybem równoważenia obciążenia w trybie LACP sterownika łączenia w Linuksie oraz w starszych przełącznikach Cisco, takich jak 2950, ​​jest równoważenie wyłącznie na podstawie adresu MAC.

Oznacza to, że jeśli cały ruch przechodzi z jednego systemu (serwera plików) do drugiego MAC (bramy domyślnej lub przełączanego interfejsu wirtualnego na przełączniku), wówczas źródłowy i docelowy MAC będzie taki sam, więc tylko jeden slave będzie kiedykolwiek być użytym.

Z twojego diagramu nie wygląda na to, że wysyłasz ruch do domyślnej bramy, ale nie jestem pewien, czy serwery testowe są w wersji 10.0.0.0/24, czy też systemy testowe znajdują się w innych podsieciach i są kierowane przez interfejs warstwy 3 na przełączniku.

Jeśli routujesz na przełączniku, masz odpowiedź.

Rozwiązaniem tego problemu jest zastosowanie innego algorytmu równoważenia obciążenia.

Znów nie mam doświadczenia z BSD ani SMC, ale Linux i Cisco mogą balansować na podstawie informacji L3 (adres IP) lub informacji L4 (numer portu).

Ponieważ każdy z systemów testowych musi mieć inny adres IP, spróbuj przeprowadzić równoważenie w oparciu o informacje L3. Jeśli to nadal nie działa, zmień kilka adresów IP i sprawdź, czy zmienisz wzór równoważenia obciążenia.