Fibre-Channel-Diskarrays im Vergleich - Seite 2

Lysan T48F4C

Eine Eigenschaft des Lysan-Array fällt sofort auf, sobald das Gehäuse geöffnet ist: die enorme Packungsdichte. Ganze 48 1-TByte-Disks auf nur vier Höheneinheiten (Abbildung 3) sind rekordverdächtig. Auf diese Weise würde fast ein halbes Petabyte in ein herkömmliches 19-Zoll-Rack passen, was wertvollen Platz im Rechenzentrum spart.

Abbildung 3: Blick in das geöffnete Lysan-Array. Dicht an dicht – 48 Platten passen in das nur 4 HE große Gehäuse, eine sehr hohe Packungsdichte.

Eine andere Besonderheit offenbart sich erst auf den zweiten Blick: Die Storagesoftware Starview, mit der sich das Array konfigurieren und überwachen lässt, läuft hier embedded auf den Fibre-Channel-Controllern, verfügt über einen eingebauten kleinen Webserver und ist so mit jedem beliebigen Browser erreichbar. Das erübrigt die Installation irgendwelcher Clientsoftware und macht das Management des Array gänzlich plattformunabhängig.

Auch eine In-Band-Verbindung via Fibre Channel wäre theoretisch möglich, allerdings liegt selbst der neuesten Software-Release dafür nur eine Host-Applikation bei, die nach uralten Linux-Distributionen verlangt: SLES 8 oder RHEL 3, jeweils 32 Bit. Versionen, die der Admin einem heutigen Server sicher nicht antun möchte, falls er sie überhaupt noch in der Mottenkiste findet.

Bleibt also doch nur die Webapplikation. Abstriche an der Funktionalität braucht der Admin dabei nicht zu machen. Die üblichen Tasks beim Einrichten des Array lassen sich ohne Handbuchstudium bewerkstelligen. Auch am Monitoring sowohl der Events wie auch der Performancewerte, gibt es nichts auszusetzen (Abbildung 4).

Abbildung 4: Das detaillierte Eventlog des Array von Lynx hilft etwa bei der Diagnose von Störungen.

Blickt man auf die Maximalwerte für die Performance in den einzelnen Disziplinen des Benchmark, hält das Lysan-Array nicht ganz mit den Schnellsten mit: Es findet sich am häufigsten auf dem letzten Rang. Welche praktische Relevanz das hat, wäre eine andere Frage. Wenn die Applikation ohnehin nicht die Bedingungen bieten kann, unter denen das Maximum erreichbar ist, käme dieses Manko womöglich kaum zum Tragen. Schließlich ist auch das günstige Preis-Leistungs-Verhältnis zu bedenken, das schnell über ein paar MByte/s weniger hinwegtrösten hilft.

Iozone - die Grundlagen
Der Benchmark Iozone [2] testet die I/O-Performance bei verschiedenen Schreib- und Leseoperationen. Im Einzelnen handelt es sich dabei um das Lesen und Schreiben wahlweise inklusive der Metadatenverwaltung beim Anlegen neuer Files (Read und Write) oder ohne (Re-Read und Re-Write) und um das Lesen und Schreiben an zufälligen Positionen (Random Read und Write). Weiter um das Rückwärtslesen (Backward Read), das Lesen mit Zugriffsmustern aus sequenziellen und zufälligen Elementen (Stride Read) und Record-weises Schreiben eines Hotspot (Record Rewrite) sowie Lesen und Schreiben mit Hilfe von Bibliotheksfunktionen (Fread, Freread, Fwrite und Frewrite). Die Geschwindigkeit jeder Operation misst das Programm in Verbindung mit verschieden großen Testfiles und verschieden großen Records. Da ein solcher Record nicht größer als das File sein kann, dem er entstammt, nimmt die Anzahl testbarer Record-Größen mit steigender Filegröße zu. Das erklärt die ansteigende Rampe an der linken Seite des Graphen (Abbildung 5). Abbildung 5: Graphen des Iozone-Benchmark haben eine charakteristische Gestalt, die sich aus den Gesetzmäßigkeiten erklärt, nach denen das Testprogramm die Plattenperformance misst. Beim Durchprobieren immer größerer Files und dazu passender Records erreicht der Benchmark schließlich den Punkt, bei dem die zu lesende oder zu schreibende Datenmenge in einen Record und dieser Record gerade noch in den Cache der CPU passt, wo er am schnellsten speicher- oder abrufbar ist. Das ist der schmale Gipfel an der höchsten Stelle der Kurve, der das absolute Performance-Maximum kennzeichnet. Rechts und unterhalb dieses Gipfels finden sich nur niedrigere Werte: So sind rechts größere Files, die das Fassungsvermögen des CPU-Cache übersteigen, langsamer. Sie müssen zwar dennoch nicht ohne Zwischenspeicher auskommen, aber um sie kümmert sich der nicht ganz so performante Buffer Cache, für den Linux fast allen anderweitig nicht benötigten Hauptspeicher einsetzt. Er und auch Caches der Raid-Controller, die im Spiel sein können, beschleunigen den Durchsatz. Ebenfalls langsamer laufen - in der Grafik unterhalb des Spitzenwerts - I/O-Operationen ab, die sich bei gleicher Filegröße auf mehr und kleinere Records verteilen. Cache spielt fast immer mit Übersteigt die im Testverlauf wachsende Filegröße am Ende auch den physisch vorhandenen RAM des Servers und sprengt so jeden Cache, fällt die Performance auf den Wert zurück, den die ungepufferte Festplatte zu liefern imstande ist, die so genannte Spindle Speed. Der Einfluss der verschiedenen Caches erzeugt die treppenförmige Abwärtsbewegung der Geschwindigkeitskurve entlang der Dateigrößen-Achse. Den Einfluss der unterschiedlichen Record-Größen spiegelt die farbliche Schichtung des Graphen wider. Das heißt aber auch: In den Benchmark fließen fast immer die Wirkungen der Caches ein. Anders wären die Messwerte auch nicht plausibel, denn über eine 4-GBit/s-Fibre-Channel-Verbindung lassen sich Daten nun mal selbst im Idealfall höchstens mit 400 MByte/s bewegen. Ergeben sich etwa beim Lesen Spitzenwerte bis zum 20-Fachen, dann steckt in ihnen ein großes Stück RAM-Geschwindigkeit. Das behindert die Separierung von Hardware-Effekten, steigert aber die Praxisnähe: Denn im wirklichen Leben sind ja alle vom Benchmark mitgemessenen Einflüsse tatsächlich auch im Spiel. Orientierung im Datenwust Iozone produziert eine Unmenge Daten und braucht entsprechend viel Zeit: Mehr als 30 Stunden für einen kompletten Durchlauf im Automatik-Mode sind nicht selten. Doch welcher der vielen Werte ist nun interessant? Bedeutsam sind zum einen die Extremwerte: Schneller als am Gipfelpunkt der Kurve kann das Plattensystem zum Beispiel unter keinen Umständen reagieren. Die praktisch relevanten Fälle liegen allerdings irgendwo zwischen den niedrigsten Werten und den Performancespitzen - wo genau, das bestimmt die Applikation, die oft ein spezifisches Zugriffsmuster erzeugt. Kennt der Admin die Bedürfnisse seiner Anwendungen, kann er aus dem umfassenden Testprogramm von Iozone gezielt die Tests herausgreifen, die jene File- und Record-Größen sowie Datei-Operationen kombinieren, die bei ihm die häufigsten sind. Schließlich ist bei der Interpretation der Ergebnisse zu bedenken, dass die I/O-Kette noch aus weiteren Komponenten besteht, die ebenfalls Einfluss auf die Performance haben, etwa der FC-Host-Bus-Adapter (siehe extra Artikel), das Filesystem oder der I/O-Scheduler von Linux. Es ist nicht garantiert, dass sich in diesem komplexen System die positiven Wirkungen addieren, im Gegenteil: Weil es etwa zwischen Plattencontroller und I/O-Scheduler keine Kommunikation gibt, können sie sich im Bemühen um Optimierung durchaus gegenseitig ein Bein stellen.

Iozone - die
Grundlagen

Der Benchmark Iozone [2] testet die I/O-Performance bei verschiedenen Schreib- und Leseoperationen. Im Einzelnen handelt es sich dabei um das Lesen und Schreiben wahlweise inklusive der Metadatenverwaltung beim Anlegen neuer Files (Read und Write) oder ohne (Re-Read und Re-Write) und um das Lesen und Schreiben an zufälligen Positionen (Random Read und Write). Weiter um das Rückwärtslesen (Backward Read), das Lesen mit Zugriffsmustern aus sequenziellen und zufälligen Elementen (Stride Read) und Record-weises Schreiben eines Hotspot (Record Rewrite) sowie Lesen und Schreiben mit Hilfe von Bibliotheksfunktionen (Fread, Freread, Fwrite und Frewrite).

Die Geschwindigkeit jeder Operation misst das Programm in Verbindung mit verschieden großen Testfiles und verschieden großen Records. Da ein solcher Record nicht größer als das File sein kann, dem er entstammt, nimmt die Anzahl testbarer Record-Größen mit steigender Filegröße zu. Das erklärt die ansteigende Rampe an der linken Seite des Graphen (Abbildung 5).

Abbildung 5: Graphen des Iozone-Benchmark haben eine charakteristische Gestalt, die sich aus den Gesetzmäßigkeiten erklärt, nach denen das Testprogramm die Plattenperformance misst.

Beim Durchprobieren immer größerer Files und dazu passender Records erreicht der Benchmark schließlich den Punkt, bei dem die zu lesende oder zu schreibende Datenmenge in einen Record und dieser Record gerade noch in den Cache der CPU passt, wo er am schnellsten speicher- oder abrufbar ist. Das ist der schmale Gipfel an der höchsten Stelle der Kurve, der das absolute Performance-Maximum kennzeichnet.

Rechts und unterhalb dieses Gipfels finden sich nur niedrigere Werte: So sind rechts größere Files, die das Fassungsvermögen des CPU-Cache übersteigen, langsamer. Sie müssen zwar dennoch nicht ohne Zwischenspeicher auskommen, aber um sie kümmert sich der nicht ganz so performante Buffer Cache, für den Linux fast allen anderweitig nicht benötigten Hauptspeicher einsetzt. Er und auch Caches der Raid-Controller, die im Spiel sein können, beschleunigen den Durchsatz. Ebenfalls langsamer laufen - in der Grafik unterhalb des Spitzenwerts - I/O-Operationen ab, die sich bei gleicher Filegröße auf mehr und kleinere Records verteilen.

Cache spielt fast immer mit

Übersteigt die im Testverlauf wachsende Filegröße am Ende auch den physisch vorhandenen RAM des Servers und sprengt so jeden Cache, fällt die Performance auf den Wert zurück, den die ungepufferte Festplatte zu liefern imstande ist, die so genannte Spindle Speed. Der Einfluss der verschiedenen Caches erzeugt die treppenförmige Abwärtsbewegung der Geschwindigkeitskurve entlang der Dateigrößen-Achse. Den Einfluss der unterschiedlichen Record-Größen spiegelt die farbliche Schichtung des Graphen wider.

Das heißt aber auch: In den Benchmark fließen fast immer die Wirkungen der Caches ein. Anders wären die Messwerte auch nicht plausibel, denn über eine 4-GBit/s-Fibre-Channel-Verbindung lassen sich Daten nun mal selbst im Idealfall höchstens mit 400 MByte/s bewegen. Ergeben sich etwa beim Lesen Spitzenwerte bis zum 20-Fachen, dann steckt in ihnen ein großes Stück RAM-Geschwindigkeit. Das behindert die Separierung von Hardware-Effekten, steigert aber die Praxisnähe: Denn im wirklichen Leben sind ja alle vom Benchmark mitgemessenen Einflüsse tatsächlich auch im Spiel.

Orientierung im Datenwust

Iozone produziert eine Unmenge Daten und braucht entsprechend viel Zeit: Mehr als 30 Stunden für einen kompletten Durchlauf im Automatik-Mode sind nicht selten. Doch welcher der vielen Werte ist nun interessant? Bedeutsam sind zum einen die Extremwerte: Schneller als am Gipfelpunkt der Kurve kann das Plattensystem zum Beispiel unter keinen Umständen reagieren. Die praktisch relevanten Fälle liegen allerdings irgendwo zwischen den niedrigsten Werten und den Performancespitzen - wo genau, das bestimmt die Applikation, die oft ein spezifisches Zugriffsmuster erzeugt.

Kennt der Admin die Bedürfnisse seiner Anwendungen, kann er aus dem umfassenden Testprogramm von Iozone gezielt die Tests herausgreifen, die jene File- und Record-Größen sowie Datei-Operationen kombinieren, die bei ihm die häufigsten sind.

Schließlich ist bei der Interpretation der Ergebnisse zu bedenken, dass die I/O-Kette noch aus weiteren Komponenten besteht, die ebenfalls Einfluss auf die Performance haben, etwa der FC-Host-Bus-Adapter (siehe extra Artikel), das Filesystem oder der I/O-Scheduler von Linux.

Es ist nicht garantiert, dass sich in diesem komplexen System die positiven Wirkungen addieren, im Gegenteil: Weil es etwa zwischen Plattencontroller und I/O-Scheduler keine Kommunikation gibt, können sie sich im Bemühen um Optimierung durchaus gegenseitig ein Bein stellen.

IBM DS 3400

Das DS 3400 erreichte die Redaktion bestückt mit sechs SAS-Server-Festplatten (Seagate ST3146855SS) mit je 146 GByte Brutto-Kapazität und 15000 Umdrehungen pro Minute, die sich wahlweise einem von zwei Fibre-Channel-Controllern (4 GBit/s) zuordnen ließen. Für die Konfiguration steht dem Käufer eine Java-Software namens IBM Storage Manager [3] zur Seite, die er kostenlos downloaden kann (Abbildung 6).

Mit ihrer Hilfe lässt sich das Array manuell oder halbautomatisch konfigurieren. Die manuelle Konfiguration verschafft dem Admin die größtmögliche Freiheit für individuelle Lösungen, die automatisierte Variante ist dagegen die deutlich bequemere. Im halbautomatischen Fall präsentiert der Storage Manager für jeden der möglichen Raid-Level (6, 5, 3, 1, 0) einen informativen Text, der die Einsatzmöglichkeiten der gewählten Konfiguration erläutert, und wählt anschließend selbst die benötigten Platten.

Dabei reserviert die Halbautomatik prinzipiell eine Hotspare-Platte und verteilt alle restlichen freien Disks entsprechend den Vorgaben. Verlangt der Admin aber etwa eine Spiegelung (Raid 1) aus beispielsweise 6 Platten, dann zweigt die Software wieder eine Reserveplatte für den Standby-Betrieb ab und bildet aus den übrigen Disks zwei Spiegelpaare, die sie dann in einem Stripe-Set zusammenfasst (Raid 10). In diesem Fall bleibt eine Platte übrig.

Gibt der Konfigurator dagegen beispielsweise Raid 6 vor, bezieht das Array fünf Platten in einen entsprechenden Verbund ein und verwendet die sechste wiederum als Hotspare, was verglichen mit der Spiegelvariante die anderthalbfache Kapazität ergibt.

Die meisten solcher Arbeitsabschnitte strukturiert der Storage Manager in so genannten Tasks, die die nötigen Schritte zusammenfassen und in eine Reihenfolge bringen. Diese vorbereiteten Schrittfolgen decken die meisten Aufgaben von der Einrichtung des Host über die Konfiguration von logischen Laufwerken und Arrays bis hin zum Mapping dieser Speichereinheiten auf LUNs ab, die sich ihrerseits dann Server-seitig partitionieren und mounten lassen.

Eine ganz besondere Task aus dem Kürprogramm des IBM Storage Manager ist der Wechsel des Raid-Levels für ein bestimmtes Volume im laufenden Betrieb, und zwar ohne dass es dabei zu einem Datenverlust kommt. Das ist schon eine gehobene Schwierigkeit, an die sich im Testfeld hier nur noch ein weiterer Kandidat heranwagt.

Die Performance des IBM-Geräts reicht in allen Disziplinen des Tests für einen Podestplatz, am häufigsten sogar für das oberste Treppchen.

So haben wir getestet
Für die Benchmarks dieses Beitrags kamen auf allen Arrays immer Volumes aus fünf Platten zum Einsatz, deren Größe dann natürlicherweise mit der Kapazität der eingesetzten Platten schwankte. Als Filesystem verwendeten die Tester stets Ext 3 mit den Default-Einstellungen von »mke2fs«, also beispielsweise eine Blockgröße von 4 KByte. In der Regel haben die Tester verschiedene Raid-Level gemessen, können die Ergebnisse aus Platzgründen hier allerdings nur auszugsweise darstellen. Für die Messungen waren die Arrays über ein optisches Kabel mit einem Servermodell Proserv II der Firma Exus Data verbunden (Abbildung 6), und zwar bestückt mit zwei Quadcore-Xeon-5460-64-Bit-CPUs (3,16 GHz) und 16 GByte RAM. Als Betriebssystem verwendetete der Server eine 64-Bit-Version von SLES 10 mit Kernel 2.6.16-60. Als Fibre-Channel-Host-Bus-Adapter diente in allen Fällen ein Qlogic Sansurfer QLA 2460. Abbildung 6: Der Testserver von Exus Data.

So haben wir
getestet

Für die Benchmarks dieses Beitrags kamen auf allen Arrays immer Volumes aus fünf Platten zum Einsatz, deren Größe dann natürlicherweise mit der Kapazität der eingesetzten Platten schwankte. Als Filesystem verwendeten die Tester stets Ext 3 mit den Default-Einstellungen von »mke2fs«, also beispielsweise eine Blockgröße von 4 KByte. In der Regel haben die Tester verschiedene Raid-Level gemessen, können die Ergebnisse aus Platzgründen hier allerdings nur auszugsweise darstellen.

Für die Messungen waren die Arrays über ein optisches Kabel mit einem Servermodell Proserv II der Firma Exus Data verbunden (Abbildung 6), und zwar bestückt mit zwei Quadcore-Xeon-5460-64-Bit-CPUs (3,16 GHz) und 16 GByte RAM. Als Betriebssystem verwendetete der Server eine 64-Bit-Version von SLES 10 mit Kernel 2.6.16-60. Als Fibre-Channel-Host-Bus-Adapter diente in allen Fällen ein Qlogic Sansurfer QLA 2460.