Jeden port X520-DA2 robi tylko 1 Gbit/s w iperf3 po przejściu z TrueNAS Core na SCALE 24.10
Serwer storage przeszedł z Core 13.0-U6.7 na SCALE 24.04, a potem na 24.10, i od tego czasu jeden port pełza, podczas gdy jego bliźniak na tej samej karcie jest w pełni zadowolony. Karta 25G zachowuje się tak samo, co sprawia, że nie dowierzam własnym oczom.
- Intel X520-DA2 z wielomodowymi optykami SFP+ Intela, 10G do switcha
- Intel XXV710-DA2 z optykami SFP28 Intela, 25G do tego samego switcha
- TrueNAS SCALE 24.10 na NAS-ie (wcześniej Core 13.0-U6.7, potem 24.04)
- iperf3 między NAS-em a klientem jako miernik
Stan linku na wolnym porcie wygląda dokładnie tak, jak powinien:
$ ethtool enp1s0f0 | grep -E 'Speed|Duplex|Link detected'
Speed: 10000Mb/s
Duplex: Full
Link detected: yes
$ iperf3 -c 192.168.3.2
# parks itself around 1 Gbit/s for the whole run
# the second port of the same card does line rate against its own client
Już zrobione:
- zamieniłem optyki między dwoma portami karty; wolny port został wolny, szybki został szybki
- porównałem sysctl net.ipv4.tcp_congestion_control na obu końcach, ta sama wartość
- wyjąłem i włożyłem oba końce jeszcze raz, wyczyściłem ferrule
Wszystko, co da się zmierzyć na warstwie linku, mówi 10G i 25G full duplex, a payload wciąż tkwi na mniej więcej gigabicie. Czy moduły się degradują, czy karta sieciowa umiera, czy patrzę na złą warstwę?
Comments 3
Sam już wykluczyłeś optyki: zamieniłeś je między portami, a powolność została przy porcie. Więc zostaw moduły w spokoju i rozdziel fakty z warstwy linku od liczb przepustowości, bo odpowiadają na różne pytania.
Dwie rzeczy zwykle różnią się między szybkim a wolnym portem na tej samej karcie. Spójrz na nie razem:
Jeśli jeden stoi na MTU 1500, a drugi na 9014, i są w różnych VLAN-ach, to twój wolny test nie wychodzi z karty i z powrotem, tylko przechodzi przez ścieżkę routingu hosta. Postaw klienta w tym samym VLAN-ie i podsieci co wolny port i uruchom iperf3 -c w jego stronę. Żadnego routera po drodze, żadnego niedopasowania MTU, nic do kłócenia się.
Jeśli test w jednym VLAN-ie daje ci line rate, port i transceiver są sprawne, a to, co faktycznie zmierzyłeś, to wydajność routingu między VLAN-ami na hoście, i tam ląduje spora część migracji z Core na SCALE: forwarding między VLAN-ami jest zauważalnie gorszy niż był pod Core.
To diagnoza, a nie właściwie lekarstwo. Większość tego odzyskasz, trzymając ciężkie przepływy wewnątrz jednego VLAN-u, albo oddając routing switchowi zamiast NAS-owi. Przynajmniej powstrzyma cię to przed zwrotem dwóch całkowicie sprawnych modułów SFP+.
Zanim ktokolwiek zacznie wyciągać optyki: co mówi switch o tych dwóch portach? Wynegocjowana prędkość, duplex i liczniki błędów na obu. I który koniec uruchamia serwer iperf3 w wolnym teście - czy sufit zostaje na miejscu, gdy odwrócisz kierunek i pchniesz z drugiej strony?
Potem wklej MTU i VLAN wolnego portu i szybkiego, obok siebie. Port, który negocjuje 10G, a przenosi tylko gigabit payloadu, w niemal każdym przypadku to problem forwardingu albo ścieżki, nie optyki. Jeśli oba porty nie siedzą w tym samym VLAN-ie, iperf3 ocenia twój router, nie twój link.
Inny sprzęt, ten sam kształt. Dwie maszyny back to back na kartach X520-DA przez DAC SFP+, Hyper-V Server Core 2012 R2 po jednej stronie i storage NAS4Free 9.1 po drugiej. Na wprost ta para robiła 8-9 Gbit/s przy odczycie i zapisie. W momencie, gdy port został przypięty do wirtualnego switcha Hyper-V, spadło to do czegoś koło 500 Mbit/s, a ponowne testowanie kart pod Windows Server 2012 R2 i Windows 8.1 niczego nie zmieniło.
Nigdy tego nie udowodniono. Jedyna odpowiedź, jaką dostałem, pytała, jakie dyski i jaki poziom RAID siedzą za każdym końcem, co jest sensownym pytaniem, bo storage potrafi być sufitem na długo, zanim stanie się nim ścieżka 10G. Nawyk, który z tego wyniosłem: mierzyć ten sam link z dodatkową warstwą podpiętą i odpiętą, i względem RAM disku, jeśli da się taki zorganizować. Kabel i karty też nie były tam problemem.