Geringe Leistung sowohl bei iSCSI als auch bei AoE

Wir suchen einen Speicher mit vernünftiger Geschwindigkeit. Aufgrund des geringen Budgets haben wir uns für die Verwendung von Software-iSCSI- oder AoE-Zielen entschieden. Bevor wir unsere Produktionsinfrastruktur ändern, führen wir einige Tests durch, um die beste Technologie auszuwählen.

Zum Testen verwenden wir:

• Fujitsu Siemens RX200 S4 als Ziel
• Fujitsu Siemens RX200 S4 als Initiator
• NetGear verwaltete 1 GBit-Switch
• Onboard-NICs (Broadcom mit TOE), EdiMax-NICs, Broadcom-NICs mit TOE - alle 1 GBit
• Der Zielserver verwendet einen QLogic-Controller mit 6 2 TB WD Blue SATA-Laufwerken.
• Sowohl das Ziel- als auch das Initiator-Betriebssystem sind Ubuntu 16.04 LTS mit allen Updates. Der Switch ist für Speicherzwecke vorgesehen. Wir testen Anleihen und Multipathing.

Unser Problem ist die niedrige Lesegeschwindigkeit. Zum Testen verwenden wir ddeine 40-100GB Datei.

• Das lokale Lesen und Schreiben auf einem Zielserver beträgt über 300 MB / s.
• Das Schreiben auf den Server per iSCSI oder AoE beträgt über 200 MB / s, was uns zufriedenstellt.
• Das Lesen vom Server beträgt immer 95-99 MB / s.

Wir haben ietd, aoetools, LIO ausprobiert. Wir haben Anleihen von 2 NICs verwendet: balance-rr und LACP, Multipathing mit rr. Verwendet normale und Jumbo-Frames. Schließlich haben wir sogar eine direkte Ethernet-Verbindung zwischen Ziel und Host hergestellt (kein Switch).

Alle Tests liefern mehr weniger die gleichen Ergebnisse (natürlich ergab die Verwendung gängiger Netzwerkkarten ohne EVG und iSCSI 20 bis 30% schlechtere Ergebnisse).

Das Testen des Netzwerks mit iperf ergab Übertragungen von etwa 200 MB / s (2 GBit). Das Beobachten der NIC-Nutzung auf dem Ziel mit bmon zeigte die gleiche Auslastung beider Geräte (jeweils etwa 50 MB / s zum Lesen, etwa 100 MB / s zum Schreiben).

Da wir kein Glück hatten, entschieden wir uns für eine dritte Netzwerkkarte (beide Seiten natürlich). Die Ergebnisse waren seltsam:

• 2 Netzwerkkarten - jeweils 50 MB / s
• 3 Netzwerkkarten - jeweils 33 MB / s

Gibt es eine Begrenzung für die Zielsoftware, die eine Ausgabe von mehr als 1 GBit / s deaktiviert?

Was machen wir falsch?

Um die maximale Leistung des mit iSCSI verbundenen Speichers zu erzielen, sollten Sie Jumbo Frames und MPIO (nicht LACP) verwenden. RDMA / iSER wird empfohlen, wenn Sie dies tun können.

AOE (ATA über Ethernet) ist alt und scheiße. Wir haben Coraid schon vor Jahren losgeworden. Wir verwenden StarWind https://www.starwindsoftware.com/ bereits seit einiger Zeit als iSCSI-Ziel, und StarWind hat uns gebeten, von Coraid auf einen beliebigen Speicherplatz zu migrieren.

Im Moment sind wir sehr gut mit iSCSI von StarWind und verwenden Windows, ESX und SCST http://scst.sourceforge.net/ unter Linux als Initiatoren. Mit RDMA / iSER macht es bis zu 10 Gbit, bisher sehr zufrieden.

Ihre Erwartungen an die Funktionsweise der Ethernet-Link-Aggregation sind falsch.

Alle anderen Aggregationsmethoden als balance-rr (dh alle Methoden, deren Modus> 0 ist) bieten keinen höheren Durchsatz für Einzelverbindungen. Sie erhöhen vielmehr die insgesamt verfügbare Bandbreite, wenn mehrere Verbindungen von / zu den betroffenen Hosts hergestellt werden. Mit anderen Worten, LAG / LACP bietet Ihnen keine Vorteile für dieses Szenario mit einer Verbindung.

Die einzige Aggregationsmethode, mit der Sie einen Durchsatz für eine Sitzung erzielen können, der höher ist als der, den Sie normalerweise auf einer einzelnen Schnittstelle haben können, ist balance-rr , mit dem Pakete im Round-Robin- Verfahren verteilt werden. Sie hatten zu setzen Balance-rr auf sowohl den Initiator und das Ziel. Ein großer Haken ist jedoch, dass dies weitgehend schalterabhängig ist.

Wenn Sie sowohl das Ziel als auch den Initiator auf balance-rr einstellen, sollten Sie durch direktes Verbinden der beiden Computer eine höhere Leistung erzielen. Wenn nicht, können Sie eine iperfmit balance-rr und beiden Maschinen direkt verbinden (kein Schalter)? Geben Sie außerdem den genauen ddBefehl ein, den Sie für das Benchmarking verwendet haben.

Hinweis: Ich spreche hier nur von iSCSI. Ich habe keine Erfahrung mit AoE, außer darüber zu lesen, und ich würde es sowieso nicht in eine neue Infrastruktur implementieren (es ist so gut wie nicht mehr vorhanden).

Verwenden Sie balance-rr nur für bestimmte Punkt-zu-Punkt-Protokolle. Es hat eine schreckliche Leistung, wenn es unter fast jeder realen Last steht, und verursacht eine Reihe von Netzwerkproblemen (wie z. B. viel Jitter). Verwenden Sie es auf keinen Fall mit einem Schalter.

Verwenden Sie MPIO ohne Bindung auf der Initiatorseite, um einen Lastausgleich und eine Fehlertoleranz zu erreichen. Um sicherzustellen, dass Ihre Pfade nicht durch Verwechseln des gesamten Datenverkehrs über einen einzigen Pfad "verwechselt" werden, platzieren Sie einzelne Pfade (in Ihrem Fall Gigabit-NICs zwischen Ziel und Initiator) in separaten Subnetzen.

Fühlen Sie sich frei, die Zielseite mit LACP pro Pfad zu verbinden (wie bei zwei Bindungen für zwei Pfade für insgesamt vier Netzwerkkarten, als Beispiel für die Konfiguration des Zielports). Dies funktioniert hervorragend und kann mehrere Initiatorverbindungen ausgleichen, die dieselben Pfade verwenden. Verwenden Sie nach Möglichkeit auch Jumbo-Frames und iSER. Durch die Verwendung von LACP auf dem Ziel werden die Verbindungen zu jedem Pfad zwischen mehreren Netzwerkkarten ausgeglichen.

Die Verwendung von LACP auf dem Initiator ist nur dann effektiv, wenn viele Zielportalverbindungen bei gleichzeitiger Verwendung hergestellt werden (nicht üblich für nahezu jede Arbeitslast). Selbst wenn Sie LACP pro Pfad auf dem Initiator effektiv implementieren würden, würde es schnell zu einem Alptraum für die Verkabelung werden, (zum Beispiel) vier zusätzliche Fabrics für jede Box zu verwenden. Wenn Sie einen Durchsatz von mehr als ~ 2 Gib / s zu einem einzelnen Initiator benötigen, ziehen Sie ein Ethernet mit 10 GiB / s in Betracht.

Die meisten Antworten auf AoE sind völlig falsch, kontrafaktisch und weisen einen Mangel an AoE-Kenntnissen und -Erfahrungen auf. Zunächst einmal ist es nicht verstorben. CORAID ist der Anbieter von AoE und wurde unter Beibehaltung der Marke CORAID als „SouthSuite“ neu gestartet. Sie sind auch die gleichen Entwickler. Sie stellen neue Produkte her und unterstützen die meisten alten. Sie treiben auch die AoE-Entwicklung voran, wie ihre offenen technischen Mailinglisten deutlich zeigen. Überprüfen Sie die Website, es ist alles auf dem neuesten Stand und erzählt die ganze Geschichte auf ihrer Verlaufsseite.

Jemand sagte, AoE würde nicht von Jumbo-Frames profitieren und sei auch völlig falsch. Es wurde unterstützt, nachdem Version 13 von 'vbladed' veröffentlicht wurde. Sie müssen Ihre MTU anpassen, um die neue Bildgröße zu unterstützen, aber ansonsten funktioniert es hervorragend.

iSCSI wird in Schicht 5 des OSI-Modells ausgeführt. Der übliche Transport ist TCP. Dadurch erhalten Sie eine Fehlerkorrektur (aufgrund von Prüfsummen in TCP) und können den Datenverkehr auf Schicht 3 über IP weiterleiten. Hier hören die Vorteile von iSCSI auf. Die Leistung in der realen Welt ist geradezu schrecklich, wenn man sie tatsächlich mit etwas wie FCP, AoE oder FCoE vergleicht. Ich möchte Sie einladen, "iscsi-Leistungsvergleich" für die Horrorshow zu googeln.

Ihr Problem mit der Lesegeschwindigkeit könnte auf eine Fehlkonfiguration des Netzwerks zurückzuführen sein. Deaktivieren Sie die Flusskontrolle und stellen Sie sicher, dass Sie einen ausreichend großen Socket-Puffer verwenden. Sie haben auch nicht erwähnt, ob Ihr zugrunde liegendes Dateisystem für das Lese-Prefetching optimiert wurde oder nicht. Abhängig von Ihrem Szenario kann dies Ihnen sehr helfen. Achten Sie jedoch darauf, dass Sie dies nicht bei bestimmten Datenbanken verwenden, bei denen das Caching deaktiviert werden muss.

Die 802.3ad-Aggregation erhöht den Durchsatz einzelner Streams selbst in einem Round-Robin-Szenario nicht sehr. Dies verkompliziert auch Ihre Netzwerkkonfiguration und bietet Ihnen einige neue Möglichkeiten, sich in den Fuß zu schießen, indem Sie die PDU-Intervalle nicht übereinstimmen oder Ihre Cisco VPC-Verbindung falsch konfigurieren, um den Aktiv-Aktiv-Status zu unterstützen. Verwenden Sie LACP nicht mit AoE, sondern lassen Sie es sein eigenes Multipathing und Multiplexing durchführen. Spätere Versionen von AoE handhaben dies wunderbar und in den meisten Fällen eleganter als sogar FCP, da alles automatisch erfolgt. Zusätzliche Ethernet-Ports bieten Ihnen mehr Bandbreite und mehr Ausfallsicherheit. Wenn Sie die Host- und Initiator-Ethernet-Ports auf mehrere Switches verteilen, kann dies zu noch mehr Redundanz führen. Es ist nicht erforderlich, einen Verbindungsmodus zu konfigurieren. Führen Sie IP auch nicht auf denselben Schnittstellen aus, die Sie für AoE verwenden.

Kurz gesagt, hören Sie nicht auf die AoE-Neinsager, sie scheinen nicht viel Erfahrung zu haben und fahren nur trendige Gehirnströme. Meide die Herde. Wenn Sie einen Backing Store mit handabgestimmtem Prefetching konfigurieren, wird Ihr Lesedurchsatz wahrscheinlich deutlich steigen. Lassen Sie die Verwendung von Aggregationsprotokollen fallen und führen Sie das Schreien von iSCSI aus. Eine letzte Sache, hör auf, 'dd' zu verwenden, es ist kein großartiger Test und unterliegt schlechten Caching-Effekten. Verwenden Sie ein echtes Benchmark-Tool wie "fio", "iozone" oder "dbench". Diese liefern viel zuverlässigere Ergebnisse.

Ich weiß, dass LACP für mehrere Verbindungen vorgesehen ist. Es zu testen war ein Akt der Verzweiflung :)

Alle Tests wurden mit balance-rr und zwei NICs durchgeführt.

Schreiben in das iSCSI-Ziel:
dd if = / dev / zero von = / mnt / zero.bin bs = 1M count = 2000
2000 + 0 przeczytanych recordów
2000 + 0 zapisanych recordów
2097152000 Bytes (2,1 GB, 2,0 GiB) kopiert , 10.1093 s, 207 MB / s

Lesen vom iSCSI-Ziel:
dd if = / mnt / zero.bin von = / dev / null bs = 1M
2000 + 0 przeczytanych recordów
2000 + 0 zapisanych recordów
2097152000 bytes (2,1 GB) , 2,0 GiB) kopiert, 16.1684 s, 130 MB / s

Netzwerkgeschwindigkeit:
iperf -c 172.16.10.80
------------------------ ------------------------------------
Client stellt eine Verbindung zu 172.16.10.80 her, TCP-Port 5001
TCP-Fenstergröße: 325 KByte (Standard)
----------------------------------------- ---------------
[3] lokaler 172.16.10.70-Port 37024, verbunden mit 172.16.10.80-Port 5001
[ID] Intervallübertragungsbandbreite
[3] 0,0-10,0 Sek. 2,30 GByte 1,98 Gbit / s Das

Testen mit iperf- und Jumbo-Frames ergab die gleichen Ergebnisse.

Ich habe durch Ausführen des Initiators eine gewisse Lesegeschwindigkeit erreicht:
hdparm -a 2048 / dev / dm-1
Zuvor waren es 256 und die Lesegeschwindigkeit 96 MB / s.
Mein Ziel ist es, eine Lesegeschwindigkeit von etwa 200 MB / s zu erreichen.

EDIT:
1. Wir verwenden kein LACP - es war ein einmaliger Test.
2. Tests mit balance-rr und MPIO ergeben genau die gleichen Ergebnisse. Multipathing wurde mit NICs in verschiedenen Subnetzen getestet.
3. Das Hinzufügen weiterer Netzwerkkarten erhöht nicht die Lesegeschwindigkeit, sondern verringert nur die Auslastung der einzelnen Netzwerkkarten.
4. Wir glauben, dass das Problem eine Einschränkung (Treiber, Modul?) Ist, die es nicht erlaubt, schneller zu lesen. Ich bin mir aber nicht sicher, ob es sich um eine Ziel- oder Initiatorseite handelt.


BEARBEITEN 2: Habe gerade einen zusätzlichen Test durchgeführt: Den gleichen Host als Ziel und Initiator konfiguriert, um Netzwerkhardwareprobleme zu beseitigen. Ich war schockiert: genau die gleiche Lesegeschwindigkeit! 130 MB / s! Das Schreiben beträgt 227 MB / s.

Wie haben Sie Ihre NICs konfiguriert? Sind alle Puffer richtig eingerichtet? Haben Sie den Netzwerkpuffern genügend RAM zugewiesen? Verwenden Sie hier auch keine Bindung. Sie können 2 iscsi-Kanäle verwenden und diese auf dem Initiator multipathen. Dies gilt auch für ATAoE, die Initiator-Multipaths über Shelf und Lun ID auf einem beliebigen Pfad.