Teaser iSCSI - Carpe diem GmbH

iSCSI ist langsam !?
Das iSCSI Protokoll wurde Ende der 1990er Jahre als "Proof-of-Concept" vorgestellt.
Ein erster "Draft" entstand 2000 und wurde in 2003 ratifiziert.
Auch mehr als 10 Jahre danach hört man immer wieder: "iSCSI ist langsam!".
Aber was bedeutet eigentlich "langsam"? Die Zeiten von 10 und 100 MegaBit-Ethernet sind
lange, lange vorbei (zum Glück). Schon seit mehreren Jahren kann aktuelle Hard- und Software die Bandbreite von GigaBit-Ethernet auch ausnutzen.
Schon im Jahr 2007 konnten wir unter VMware ESX Version 2.5 mit einem Windows 2003
Gast und zwei GigaBit Leitungen zu einem damals handelsüb-lichen iSCSI SAN-Array einen
Durchsatz von ca. 180 MegaByte/Sekunde erreichen. Natürlich, das war ein Test mit einem
Benchmark Programm, dass auf möglichst viel Datendurchsatz (MegaByte/Sekunde) optimiert
war und dieses Programm war der einzige Nutzer des Arrays. In der Praxis wird kaum eine
Firma ihr Geld mit dem Lauf von Benchmark-Programmen verdienen.
Wie sieht es also heute in der Praxis aus?
Einer unserer Kunden setzt eine Kombination aus 3 HP ProLiant Servern (DL380 Gen8) mit
VMware ESXi V5.1 ein. Diese greifen auf einen Verbund aus zwei HP StoreVirtual 4730 iSCSI
Storage Systemen zu.
StoreVirtual 4000 ist ein Speichersystem nach dem Grid-Prinzip (auch wenn der "Grid-Hype"
inzwischen verschwunden ist). Die Daten werden von der SAN-Software automatisch auf
beiden Speichersystemen abgelegt, so dass auch bei Ausfall eines Systems ohne Datenverlust weiter gearbeitet werden kann. Diese Konfiguration ist seit über 2 Jahren im Einsatz. Nach
der ursprünglichen Virtualisierung der vorhandenen Server wurden eine Reihe von Maschinen
aktualisiert und erweitert. Da war es an der Zeit, sich einmal die aktuelle Situation des Speichersystems anzuschauen.
Hierzu wurden mit der Management Console (CMC) alle Performance-Daten gesammelt und
in eine ".CSV"-Datei geschrieben. Dies hat den Vorteil, dass man sich zu einem späteren
Zeitpunkt einzelne Datengruppen (Durchsatz MB/s oder IO/s oder Latenzzeiten) genauer
ansehen kann. Der zeitliche Zusammenhang der Daten ist trotzdem gewährleistet.
Das Ergebnis
Im ersten Bild ist der Datendurchsatz des Clusters (also des Verbundes aus zwei Speichersystemen) dargestellt. Der Durchsatz liegt über 200 Megabyte/Sekunde, weil alle Systeme
über zwei GigaBit-Pfade miteinander verbunden sind. Ausserdem ist die I/O-Last auf die
beiden Speichersysteme verteilt - es ist nicht so, dass die Datenspiegelung auf ein zweites
(passives) System durchgeführt wird.
Ein so hoher Datendurchsatz ist eher ungewöhnlich für den normalen Betrieb. Wir hatten hier
allerdings keine Benchmark-Programme laufen lassen, sondern es fand parallel zum Normalbetrieb eine Datenbankmigration statt.
Es ist nicht besonders schwierig, aus einem Speichersystem mit passenden Abfragen eine
hohe Zahl an MegaByte/Sekunde zu erreichen. Wie aber verhält sich das System für andere
Abfragen - also zum Beispiel Schreibzugriffen? Hier hilft ein Blick auf die Latenzzeiten.
Ein Hinweis vorweg: wenn Sie sich die Grafik und die Legende anschauen, werden ihnen
einige negative Werte mit "-2" ins Auge fallen. Das sind keine Messfehler. Hier wurden
lediglich alle Werte größer als 15 Millisekunden auf -2 gesetzt. Im normalen Betrieb kommt es
immer wieder einmal zu einzelnen Ausreißern, die aber die Skalierung so stark verzerrt, dass
die Normalwerte auf ein kleines "Rauschen" reduzieren würde.
Die Speichersysteme arbeiten mit 24 aktiven 2,5" 10KRPM SAS Festplatten in jeweils zwei
RAID-5 Verbünden. Dazu kommt eine Spare-Disk.
Die Latenzzeit des Speicher-Clusters liegt in der Regel unter der Latenzzeit einer physikalischen Festplatte. Für Schreiben, weil die Systeme mit Writeback-Cache arbeiten. Für Lesen
teilweise auch, weil der Datenbank-Export ein sequentieller Zugriff ist und die Systeme mit
Read-Ahead Caching arbeiten können, so dass sich die Daten bereits im Lese-Cache
befinden, wenn die Anwendung die Lese-Anforderung schickt.
Beim Datendurchsatz (MegaByte/Sekunde) ist die Konfiguration durch den Einsatz von
GigaBit-Ethernet beschränkt. Tatsächlich werden die eingesetzten Speichersysteme aber ab
Werk mit 10 GigaBit-Ethernet ausgeliefert. Wir hatten uns anhand des Sizing vor 2 Jahren
jedoch dagegen entschieden. Die Datenbank-migrationen finden auch nicht laufend statt.
In Fragen Latenzzeit ist das System vergleichbar mit Speichersystemen auf Fibre ChannelBasis - hier ist einfach die physikalische Festplatte der Engpass. Die Grundtechnologie ist
heute im Prinzip immer eine 2,5" oder 3,5" SAS, SAS-MDL oder SATA Festplatte.
Die StoreVirtual 4000 Systeme bieten neben der redundanten Speicherung der Daten über
Rechnerraum-Grenzen hinweg einen transparenten Failover, der im Fibre Channel-Umfeld
teilweise gar nicht oder nur mit zusätzlichem finanziellen und teilweise erheblichen
technischen Auswand (bis hin zu in-Band Virtualisierungsappliances) realisiert werden kann.
Die Software der Systeme läßt sich auch als Virtuelle Maschine auf einem Virtualisierungshost
mit den selben Funktionen wie transparentem Failover betreiben. Damit ist Desastertoleranz
auch für "kleine" Kunden möglich.
Heute wird dieses Konzept (mit zusätzlicher Verwaltungssoftware) als "Hyper-Converged"
Lösung abgepriesen, aber die ersten Implementierungen mit StoreVirtual VSA hatten wir
bereits im Jahr 2008 (also vor 7 Jahren!) erfolgreich durchgeführt, betrieben und erweitert/
aktualisiert.
Fazit - iSCSI ist weder "langsam" noch rückständig.
Besonders für kleinere Kunden lassen sich trotzdem technisch anspruchsvolle Lösungen zu
einem realistischen Preis realisieren.

Download Report