© memephoto, Pixelio.de

Fibre-Channel-Arrays gelten als Königsklasse der Plattenspeicher, verpflichtend für alle, die höchste Performance oder Skalierbarkeit anstreben. Doch ist die Technik weder billig noch trivial. Zudem erwächst ihr Konkurrenz. Passen Ruf und Realität noch zusammen? Vier mittelgroße FC-Plattensilos im Test.

Bei einem Mediendienstleister war ein Diskarray zu installieren. An sich nichts Aufregendes – hier allerdings lagen die Dinge ein wenig anders: Der Kunde, ein Betrieb der Druckvorstufe, produzierte nämlich Kataloge für große Versandhäuser und musste deshalb Massen an Produktfotos, Logos und Grafiken speichern. Dafür brauchte er viel Platz und hatte darum ein Array bestellt, wie es beim liefernden Systemhaus noch keiner je installiert hatte: Übermannshoch und mit einem sechstelligen Preis so teuer, dass es eigentlich nur Techniker des Herstellers hätten einrichten dürfen. Die Kapazitätsangabe erschien fast als Synonym für unendlich: reichlich 1 Terabyte.

Vergleichen lohnt

Das ist inzwischen zehn Jahre her. Heute nimmt man die Speichermenge, die damals ein Rack füllte, im Mediamarkt als einzelne Platte für wenig mehr als 100 Euro mit. Bald steckt jedermann sie wahrscheinlich mit dem Handy in die Westentasche.

Ein Array für den Mittelstand dagegen erreicht inzwischen wenigstens die zehn- bis fünfzigfache Kapazität der damaligen Installation. Doch ungeachtet des enormen Preisverfalls bei Festplatten ist ein derartiger Plattensilo zwar inzwischen deutlich preiswerter als damals, jedoch nach wie vor nicht wirklich billig. Abhängig von der Größe und Ausstattung erreicht der Preis bei einem Markenhersteller leicht den Gegenwert eines Kleinwagens, manchmal bekäme man für dasselbe Geld sogar schon eine Mittelklasselimousine.

Das Vergleichen lohnt also nach wie vor. So hat sich das Linux-Magazin vier Fibre-Channel-Diskarrays mit einer Kapazität zwischen 10 und 50 TByte ins Hardwarelabor geholt, um sie nebst der zugehörigen Storagesoftware auf Herz und Nieren zu prüfen.

Sun Storagetek 6140

Der Common Array Manager (CAM, [1]), den die Firma Sun zur Verwaltung ihres Arrays ins Rennen schickt, folgt einer eigenen Philosophie. Im Unterschied zu seinen Vettern erlaubt er keine direkte Zuweisung eines Raid-Levels oder einer Record-Größe zu einer Gruppe von Platten, sondern verlangt stattdessen, einem Plattenpool ein vordefiniertes Profil zuzuordnen. Eine breite Palette solcher Profile hat der Manager bereits im Gepäck. Sie reichen von einer maßgeschneiderten Konfiguration für Oracle-Datenbanken im Veritas-Cluster bis etwa zu einem Setup für High Capacity Computing, für NFS oder für eine Sybase-Datenbank im OLTP-Betrieb (Abbildung 1).

Abbildung 1: Die Liste der vorbereiteten Konfigurationsprofile des Sun Storagetek kann sich der Admin auch auf der Kommandozeile ausgeben lassen.

Klarer Vorteil dieser Herangehensweise: Die vorkonfigurierten Einstellungen enthalten bereits ein gerüttelt Maß Know-how, das der Anwender nicht mitbringen muss. Wollte der Admin selber all die Kombinationen aus Record-Größe, Raid-Level, Plattentyp und Verwendungszweck austesten, die diese Profile bereits sortiert anbieten, hätte er einen ganz erheblichen Zeitaufwand zu bewältigen und bräuchte ein breites Fachwissen.

Einen kleinen Nachteil gibt es allerdings auch: Was nicht vordefiniert ist, das ist auch nicht gleich verwendbar. So erlaubt das Array beispielsweise die Konfiguration von Raid 6, aber kein Profil bietet es an. Der Ausweg führt in solchen Fällen über ein eigenes, kundenspezifisches Profil, das sich der Anwender zunächst beispielsweise via »sscs create … profile Name « anlegen muss.

Der Array Manager kommt wahlweise als Java-Applikation mit GUI oder als Command Line Interface daher. Beide Varianten beherrschen alle grundlegenden Administrationsaufgaben für das Erzeugen, Ändern und Löschen von Diskpools, virtuellen Platten und Volumes, sie verstehen sich darüber hinaus auf die Replikation von Volumes sowie auf Snapshots wie auch lokale Volumekopien. Ein wenig Übung und Erfahrung im Umgang mit Storagesoftware vorausgesetzt, geht die Bedienung beider Softwareversionen leicht von der Hand.

Das Monitoring unterstützen zahlreiche Optionen. Das Eventlog und die Performancewerte lassen sich via GUI oder Kommandozeile überwachen (Abbildung 2). Auf Wunsch meldet ein Feature namens Auto Service Request eine Störung auch selbstständig an den Hersteller, der sie im Rahmen entsprechender Wartungsvereinbarungen dann günstigenfalls behebt, bevor sie dem Kunden überhaupt auffällt. Alternativ kann sich der Admin vor Ort auch via E-Mail beziehungsweise SNMP alarmieren lassen. Auch in Sachen Performance gibt sich das Array von Sun im Test keine Blöße.

Abbildung 2: Alle Aktionen – wie hier beispielsweise die Initialisierung eines Volume – hält ein detailliertes Log fest.

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.

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.

Infortrend S16F-R1430

Das Array von Infortrend ist das einzige im Test, das sich auch ganz ohne Storagesoftware über ein kleines LCD-Panel an der Frontseite steuern lässt. Ein ähnliches Text-GUI kann der Admin auch über einen Telnet-Zugang bedienen (Abbildung 8). Das ist beispielsweise dann praktisch, wenn der Speicher nicht direkt von außen erreichbar ist, man sich aber per Terminal-Hopping in das jeweilige Subnetz begeben kann. Viel bedienfreundlicher ist allerdings die Weboberfläche SAN Watch [4], die ein eingebetteter Server anbietet (Abbildung 9). Als Alternative ist die Standalone-Java-Software Raid Watch [5] verfügbar.

Hat sich der Admin konnektiert, muss er sich als nächste kleine Hürde mit der ungewöhnlichen Terminologie des Herstellers auseinandersetzen, der einen Verbund mehrerer Platten als Logical Disk bezeichnet und eine oder mehrere dieser Disks zu einem logischen Volume zusammenfasst, wodurch sich dann beispielsweise auch Raid-10- oder -50-Konfigurationen bilden lassen. Allgemein gebräuchlicher ist allerdings die umgekehrte Definition eines Volume als Teil einer logischen Platte.

Alle weiteren Konfigurationsarbeiten lassen sich dann aber, unterstützt durch die gute Webapplikation, kinderleicht erledigen. Das Text-GUI macht es dem Konfigurator ebenfalls nicht schwer und schließlich gäbe es drittens zudem noch die bereits erwähnte kompakte grafische Applikation Raid Watch für das Setup des Array.

Auch das Monitoring unterstützt das Array sehr gut. Auf der Hardware-Seite reicht die Überwachung bis zu den Temperaturen der CPU oder Backplane, zu einzelnen Spannungen oder Lüfterdrehzahlen, Software-seitig gibt es ein detailliertes Eventlog. Für bestimmte Parameter lassen sich Schwellenwerte definieren, die Alarme auslösen. Auch kann sich das Array in einigen Situation – zum Beispiel nach einem Lüfterausfall oder auf ein Signal der USV hin – selbstständig herunterfahren. Alternativ ist eine Benachrichtigung des Admin via E-Mail oder SNMP möglich. Den insgesamt sehr guten Eindruck bestätigen auch die guten Performancewerte, die an keiner Stelle einbrechen und oft im vorderen Feld zu finden sind – und das für einen sehr moderaten Preis.

Abbildung 7: IBMs Storage Manager bietet eine gute Übersicht und unterstützt den Admin bei der Array-Konfiguration.

Abbildung 8: Ein Text-GUI, wie es auch ein kleines LCD-Panel an der Frontseite anbietet, ist beim Array von Infortrend via Telnet erreichbar.

Abbildung 9: Die Imfortrend-Einstiegsseite bietet eine ebenso übersichtliche wie detaillierte Übersicht über alle Komponenten.

Zusammenfassung

Alle Testkandidaten hinterlassen einen guten Eindruck, Unterschiede bei der Performance finden sich, bleiben aber undramatisch. Größere Differenzen ergeben sich bei Feature-Set und Preis, was die Geräte für jeweils unterschiedliche Einsatzszenarien empfiehlt.

Die breiteste Palette an Möglichkeiten bietet sicher das Storagetek-Array. Das Sun-Gerät ist das einzige, das eine eigene Replikationslösung mitbringt – neben Snapshots und lokalen Volumekopien, die es ebenfalls beherrscht. Nur mit ihm lässt sich der Speicher auf über 100 TByte aufrüsten und weiter in logische Domains aufteilen. Allein das Array von Sun unterstützt den Admin mit seinem Konzept vorkonfigurierter Profile derart weitgehend beim Setup für spezielle Einsatzfälle. Nur dieses Array ruft – wenn gewünscht – von ganz alleine zu Hause an und ordert einen Techniker, um sich reparieren zu lassen.

Das hat aber seinen Preis. Ist schon die Hardware nicht billig, schlagen die Lizenzen für Snapshot und Volumecopy noch mal mit brutto je 8000 Euro zu Buche, die Replikation gar mit 15800 Euro.

Dass auch ein sehr bekannter Markenname noch bezahlbar sein kann, beweist IBM mit seinem DS 3400. Zwar legt der Kaufinteressent auch hier für Snapshots noch einmal drauf, dafür kostet aber die voll ausgebaute Hardware auch nicht mehr als Suns Replikations-Lizenz. Unterstützung findet der Admin bei der zugehörigen Storagesoftware, die wenig Wünsche offen lässt, in Form kurzer Hilfetexte. Die Performance ist sehr gut.

Der Bolide von Lynx schlägt alle Mitbewerber in diesem Test in Sachen Packungsdichte. Zusammen mit der Erweiterungsoption auf 96 Platten lassen sich so sehr günstig extrem kompakte und große Plattenspeicher aufbauen. Auch die Software für die Geräteverwaltung muss sich nicht verstecken. Im Gegenteil: Einige Features wie die automatisch startbaren Media-Scans im Hintergrund heben sie sogar aus der Masse heraus.

Schließlich findet auch das Array von Infortrend sicherlich Freunde und kann nützliche Eigenheiten bieten. So lassen sich die Kanäle seiner Fibre-Channel-Controller beispielsweise optional mit einem integrierten Hub verbinden, der für ein einfaches Loadbalancing sorgen kann. Zudem ist es recht flott, die Management-Software ist ausgereift und – last but not least: Es ist das absolut günstigste Angebot. Kurzum: Für jeden Anspruch und jedes Budget findet sich ein passendes Angebot.

Tabelle 1: FC-Diskarrays im Überblick
Abbildung 10: Durchsatzvergleich mit »iostat« bei fester File- und Record-Größe für verschiedene Datei-Operationen.

Abbildung 10: Durchsatzvergleich mit »iostat« bei fester File- und Record-Größe für verschiedene Datei-Operationen.

Abbildung 11 IBM DS 3400, Schreiben auf Raid 5: Das Array vom IBM ist in vielen Disziplinen der Performance-Spitzenreiter des Tests.

Abbildung 12: Lynx Lysan T48F4C, Schreiben auf Raid 5: Sehr kompakt und skalierbar, aber nicht der schnellste Kandidat.

Abbildung 13: Infortrend S16F-R1430, Schreiben auf Raid 5: Erstaunlich ausgewogen und flott zu einem günstigen Preis.

Abbildung 14: Sun Storagetek 6140, Schreiben auf Raid 5: Die meisten Features, weit ausbaubar und keineswegs langsam.