Hallo, zusammen
(english version)
Zwischen den günstigen iSCSI-Storage-Appliances (QNAP, Thecus, Buffalo, Cisco SMB und Co.) und den „großen“ Storages aus der Fiberchannel-Welt klafft eine große Lücke, sowohl in der Performance, der Features aber insbesondere im Preis. Im WorNet-Labor haben wir eine überzeugende Lösung gefunden, die diese Lücke überbrückt. Natürlich mit OpenSouce-Mitteln!
Schon lange setzen wir den auf Linux basierenden Openfiler für unsere iSCSI-Storage-Server ein. Allerdings waren wir mit der Performance nicht so recht zufrieden. Selbst mit leistungsfähiger Hardware kommt verglichen mit günstigen Appliances (in unserem Fall von QNAP) in den virtuellen Maschinen nur wenig mehr I/O-Leistung an. Die Testphase unseres neuen ESX-Clusters kam uns da sehr gelegen um systematisch an der Performance-Schraube zu drehen.
Hier hat sich ein optimales Vorgehen bei der Optimierung herauskristallisiert, bei dem die Reihenfolge der Optimierungsschritte  entscheidend ist.
Unsere Testumgebung:

• 1 ESXi 4.1 Server (Fujitsu RX 200 S6, 8 Cores 2,4 GHz, 48 GB RAM, 6 x GBit-Netzwerk Intel)
• 1 Openfiler 2.3 (Supermicro 8 Cores 2,0 GHz, 8 GB RAM, 3ware 9650SE 8 Ports, 6 x GBit-Netzwerk Intel, 8 Festplatten 2 TB SATA 7200U/min)
• 1 Switch Cisco Catalyst 2960S (24 Port GBit)

Je 4 GBit Interfaces werden für iSCSI genutzt. Dabei werden 4 VLANs mit verschiedenen IP-Bereichen definiert. Die Interfaces müssen dem iSCSI-HBA zugeordnet werden bevor die Ziele sichtbar werden.  Dann wird ein Volume mit VMFS formatiert und man erhält einen Datastore mit dem man die Tests durchführen kann. Die Verwendung der Pfade wird auf „Round Robin“ konfiguriert.
virtuelle Testmaschine:
Wir haben eine virtuelle Maschine mit 1 vCPU, 2 GB RAM mit Windows 7 installiert. Die Größe der virtuellen Festplatte sollte mindestens 15 GB + 2 * RAM des Storageservers betragen. Zusätzlich wird IOMETER und ein standardisiertes Konfigurationsfile aus dem VMware-Forum installiert. Mit diesem Test erhält man Werte die mit den Ergebnissen anderer Forumsbeiträge vergleichbar sind.
1. Schritt: Ausgangssituation
Zunächst messen wir die Performance des nicht-optimierten Systems. Dabei wählen wir die Größe des Testfiles bewusst kleiner als der Arbeitsspeicher des Storage-Servers, d.h. wir messen zwar die iSCSI-Anbindung, nicht aber das Festplattensystem.

Für 4 GBit Speicheranbindung ist das nicht gerade beeindruckend. Das RAID-System des Storage-Servers liefert lokal im Openfiler gemessen 420 MB/s!
2. Schritt: Optimierung der iSCSI-Speicheranbindung
Jetzt optimiert aggressiv man alle Parameter, die die Speicheranbindung betreffen. Dabei ist es in Ordnung, wenn unsichere Einstellungen (z.B. Write-Cache im RAID-Controller ohne vorhandene BBU) gewählt werden. Auch wählt man die Größe der Testdatei in IOMETER kleiner als den RAM des Storage-Systems, denn wir wollen möglichst wenig Einflüsse der Platten und statt dessen nur den Weg von der virtuellen Maschine bis zum iSCSI-Daemon im Storage-System testen.
Insbesondere konfiguriert man:

• Netzwerkkartenparameter (Jumbo Frames, TCP-Offload)
• iSCSI-Parameter (Round-Robin-Parameter)
• RAID-Controller (Write-Cache einschalten)

Bei uns machte sich das deutlich bemerkbar:

Damit sind wir sehr nahe am theoretischen Maximum (4 GBit entspricht ca. 440 MB/s inkl. iSCSI-Overhead).
Wichtig: Machen sie nicht weiter wenn Sie mit diesen Werten nicht 100%ig zufrieden sind. Ab hier wird es wieder schlechter!
Wenn man im vShpere-Client unter Leistung die Nutzung der iSCSI-Pfade bei sequentiellem Zugriff ansieht müssen die Pfade gleichmäßig mit je 1 GBit ausgelastet sein (Bild rechts).
Stolperfallen in unserem Test:

• fehlerhafte Jumbo-Frame-Konfiguration (Test: Ping mit großen Paketen und Dont-Fragment-Bit), hierbei auch an den Switch (Cisco 2960S: „set mtu jumbo 9000“) denken!
• Der Round-Robin-Algorithmus bei ESXi wechselt den Pfad im default nur nach 1000 IO-Operationen. Das muss man mit einem esxcli-Befehl umstellen.

3. Schritt: Optimierung der Storageparameter
Jetzt stellt man sinnvolle Werte für den Produktivbetrieb ein und  erhöht die Größe des Testfiles für IOMETER auf das doppelte des RAM des Storageservers. Aufpassen die „Maximum Disk Size“ wird in Blocks angegeben, ein Block hat 512 Bytes.
In unserem Fall haben wir nun verschiedene Raid-Level und Spindelzahlen verglichen.
Raid-10 mit 4 Platten zu je 2 TB (SATA, 7200 U/min):

Raid-10 mit 8 Platten:

Die Erhöhung der Anzahl der Festplatten von 4 auf 8 bei RAID-10 hat sich erstaunlicherweise nicht signifikant ausgewirkt. Da ist besser zwei unabhängige Datastores mit je 4 Platten anzulegen.
Ein Test mit einem RAID-6 aus 8 Festplatten ergab noch schlechtere Werte, insbesondere beim Random-Zugriff.
Fazit:
Mit knapp 400 MB/s und >10.000 IOPS sind wir absolut glücklich. Unser x86-Server mit Openfiler (ca. 4.000 Euro) schließt die Lücke zwischen den „kleinen“ (ca. 1.000 Euro und 70 MB/s und 2.000 IOPS) und den „großen“ jenseits der 10 k€.
Eine weitere Verbesserung der IOPS oder Latenzen ist mit schnelleren Festplatten, SSDs oder SAS-Platten sicher realisierbar. Eine Storage-Replikation ist mit „drbd“ machbar, wurde aber in diesem Test nicht untersucht.
Dieser Artikel basiert auf den Testreihen und Erfahrungen von Christian Eich, Richard Schunn und Toni Eimansberger.
IT bleibt spannend,
Christian Eich