Wir haben eine Intel I340-T4-Netzwerkkarte mit 4 Ports in einen FreeBSD 9.3-Server 1 eingebaut und für die Verbindungsaggregation im LACP-Modus konfiguriert , um die Zeit zum Spiegeln von 8 bis 16 TiB Daten von einem Master-Dateiserver auf 2 zu verkürzen. 4 Klone parallel. Wir hatten erwartet, eine Gesamtbandbreite von bis zu 4 Gbit / s zu erreichen, aber egal, was wir versucht haben, es kommt nie schneller als eine Gesamtbandbreite von 1 Gbit / s heraus. 2
Wir verwenden dies iperf3, um dies in einem ruhenden LAN zu testen. 3 Die erste Instanz erreicht erwartungsgemäß fast einen Gigabit, aber wenn wir eine zweite parallel starten, sinken die Geschwindigkeit der beiden Clients auf ungefähr ½ Gbit / s. Durch Hinzufügen eines dritten Clients werden die Geschwindigkeiten aller drei Clients auf ~ ⅓ Gbit / s usw. gesenkt.
Wir haben beim Einrichten der iperf3Tests darauf geachtet , dass der Datenverkehr von allen vier Testclients über verschiedene Ports in den zentralen Switch gelangt:
Wir haben überprüft, dass jeder Testcomputer einen unabhängigen Pfad zurück zum Rack-Switch hat und dass der Dateiserver, seine Netzwerkkarte und der Switch über die Bandbreite verfügen, um dies zu erreichen, indem wir die lagg0Gruppe aufteilen und jedem eine separate IP-Adresse zuweisen der vier Schnittstellen auf dieser Intel-Netzwerkkarte. In dieser Konfiguration haben wir eine Gesamtbandbreite von ~ 4 Gbit / s erreicht.
Als wir diesen Pfad eingeschlagen haben, haben wir dies mit einem alten verwalteten SMC8024L2-Switch getan . (PDF-Datenblatt, 1,3 MB.) Es war nicht der High-End-Switch seiner Zeit, aber es soll dazu in der Lage sein. Wir dachten, der Switch könnte aufgrund seines Alters fehlerhaft sein, aber ein Upgrade auf einen viel leistungsfähigeren HP 2530-24G hat das Symptom nicht geändert.
Der HP 2530-24G-Switch behauptet, die vier fraglichen Ports seien tatsächlich als dynamischer LACP-Trunk konfiguriert:
# 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
Wir haben sowohl passives als auch aktives LACP ausprobiert.
Wir haben überprüft, dass alle vier NIC-Ports Datenverkehr auf der FreeBSD-Seite erhalten mit:
$ sudo tshark -n -i igb$n
Seltsamerweise tsharkzeigt sich, dass bei nur einem Client der Switch den 1-Gbit / s-Stream auf zwei Ports aufteilt, anscheinend zwischen ihnen. (Sowohl der SMC- als auch der HP-Switch zeigten dieses Verhalten.)
Da die Gesamtbandbreite der Clients nur an einem einzigen Ort zusammenkommt - am Switch im Server-Rack - ist nur dieser Switch für LACP konfiguriert.
Es spielt keine Rolle, in welchem Client wir zuerst starten oder in welcher Reihenfolge wir sie starten.
ifconfig lagg0 auf der FreeBSD-Seite sagt:
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>
Wir haben so viele Ratschläge im FreeBSD-Netzwerk-Tuning-Handbuch angewendet, wie es für unsere Situation sinnvoll ist. (Vieles davon ist irrelevant, wie das Zeug über das Erhöhen der maximalen FDs.)
Wir haben versucht , das Auslagern der TCP-Segmentierung zu deaktivieren , ohne die Ergebnisse zu ändern.
Wir haben keine zweite 4-Port-Server-Netzwerkkarte, um einen zweiten Test einzurichten. Aufgrund des erfolgreichen Tests mit 4 separaten Schnittstellen gehen wir davon aus, dass keine Hardware beschädigt ist. 3
Wir sehen diese Wege vorwärts, keiner von ihnen ist ansprechend:
Kaufen Sie einen größeren, schlechteren Switch, in der Hoffnung, dass die LACP-Implementierung von SMC einfach nur scheiße ist und der neue Switch besser wird.(Ein Upgrade auf einen HP 2530-24G hat nicht geholfen.)Starren Sie noch einmal auf die FreeBSD-
laggKonfiguration und hoffen Sie, dass wir etwas verpasst haben. 4Vergessen Sie die Link-Aggregation und verwenden Sie stattdessen Round-Robin-DNS, um den Lastausgleich zu bewirken.
Ersetzen Sie die Server-Netzwerkkarte und wechseln Sie erneut, diesmal durch 10-GigE- Daten, was etwa dem 4- fachen der Hardwarekosten dieses LACP-Experiments entspricht.
Fußnoten
Warum nicht zu FreeBSD 10 wechseln? Da FreeBSD 10.0-RELEASE weiterhin ZFS-Pool Version 28 verwendet und dieser Server auf ZFS-Pool 5000 aktualisiert wurde, eine neue Funktion in FreeBSD 9.3. Die 10. x- Zeile wird das erst erhalten, wenn FreeBSD 10.1 in etwa einem Monat ausgeliefert wird . Und nein, eine Neuerstellung von der Quelle auf die 10.0-STABLE-Aktualisierung ist keine Option, da dies ein Produktionsserver ist.
Bitte springen Sie nicht zu Schlussfolgerungen. Unsere Testergebnisse später in der Frage zeigen Ihnen, warum dies kein Duplikat dieser Frage ist .
iperf3ist ein reiner Netzwerktest. Während das letztendliche Ziel darin besteht, diese 4-Gbit / s-Aggregatleitung von der Festplatte zu füllen, ist das Festplattensubsystem noch nicht beteiligt.Vielleicht fehlerhaft oder schlecht designt, aber nicht kaputter als beim Verlassen der Fabrik.
Ich habe schon die Augen verschränkt.