Schutzbrief

Inhaltsverzeichnis

Der Betrieb eines Fileservers gestattet die zentrale Bereitstellung von Benutzerdaten für eine verteilte Rechnerumgebung. Sollen auf einem derartigen Server noch Info-Dienste wie WWW und FTP etabliert werden, so übersteigt die Größe der Datenbestände in der Regel die Kapazität verfügbarer Einzelplatten. RAID-Systeme können Abhilfe schaffen.

Im konkreten Fall stellte sich die Aufgabe, in einem hetrogenen Rechnernetz bestehend aus Sun-, HP- und Linux-Workstations sowie einem Windows-Pool eine Storage-Lösung bereitzustllen, die alle anfallenden Datenmengen aufnehmen kann. Der Einsatz einer konventionellen Backup-Lösung zur Sicherung der Datenbestände kam nicht in Frage, da die Veränderungsfrequentierung des gesammten Datenbestandes so hoch war, daß praktisch das Erstellen neuer Backups einem täglichen Full-Backup nahe käme.
Nicht zuletzt aus Administrationsgründen galt eine zentrale RAID-Fileserver-Lösung für die mit den Berechnungen betrauten Festplatten auch wegen der erhöhten Ausfallsicherheit als Favorit gegenüber der Anschaffung einzelner großer Festplatten.

Aus Kostengründen kam eine Stand-alone Lösung in Form eines externen SCSI/RAID-Festplattensubsystems nicht in Frage. Wir entschieden uns für Software-RAID und als Alternative dazu die Verwendung eines RAID-Controllers. iX stellt zunächst ein unter Linux arbeitendes Software-RAID und anschließend eine kommerzielle Lösung - den Linux-RAID-Server von bee - vor.

Bestellt wurde ein Pentium-II-System mit fünf SCSI-Platten und einem UW-SCSI-Controller, das die Aachener Computerfirma Get It! liefern sollte. Bereits bei der Bestellung wiesen wir darauf hin, daß die Belüftung der Laufwerke für ein Serversystem im Dauerbetrieb aureichend dimensioniert sein sollte.

Versucht man ein solches System nun - wie geliefert - in einem konventionellen PC-Gehäuse unterzubringen, halten sich die positiven Eindrücke in Grenzen: Aus Platzmangel wurden die Festplatten ohne jeglichen Abstand voneinander eingebaut. Dadurch erwärmten sie sich unzulässig und mehrmals verweigerte das System seinen Dienst. Auch die drei installierten ‘Just-Cooler’-Lüftungselemente in der Frontplatte des Rechners stellten keine ausreichende Lösung dar. Jedes dieser Elemente besteht aus zwei kleinen Lüftern, deren MTBF-Rate im Tagesbereich liegen muß. Nur so erklärt sich, daß einige bereits nach wenigen Tagen die ersten Ausfallerscheinungen zeigten und schließlich ganz ihren Geist aushauchten.

Abhilfe schaffte nur die etwas unkonventionelle Montage der Platten um jeweils eine halbe Plattenhöhe versetzt, verbunden mit dem zusätzlichen Einbau von sechs großen Papstlüftern. Drei bauten wir an der Vorderseite in einer selbstgefertigten Frontblende ein, die nunmehr die kalte Luft direkt zwischen die Festplatten leiten (siehe Abbildung 1). Die restlichen drei Lüfter befinden sich auf der Rückseite und befördern die erwärmte Luft wieder aus dem Gehäuse heraus. Erst mit dieser Maßnahme erreicht man einen angemessenen horizontalen Luftstrom.

Grundsätzlich empfiehlt es sich, bei der Auswahl des Gehäuses nicht am falschen Ende zu sparen. Die Kosten durch Ausfallzeiten und Datenverlust sowie die für nachträgliche Umbauten wiegen den relativ geringen Mehrpreis für ein professionelles Servergehäuse leicht auf.

Scheibchen für Scheibchen

Betrachtet man den Datenbestand eines beliebigen Rechnersystems, lassen sich die dort abgespeicherten Dateien in Klassen mit unterschiedlichen Sicherheitsanforderungen einteilen: Benutzerdateien, deren Wiederherstellung schwierig wenn nicht sogar unmöglich ist, programmspezifische Dateien und allgemeine Systemdaten, die sich durch erneutes Installieren relativ einfach wiederherstellen lassen. Am geringsten sind die Sicherheitsanforderungen an temporäre Dateien und den Swap-Bereich.

Mit diesem Sicherheitsprofil läßt sich ein RAID-System aufbauen, das auf die jeweiligen Sicherheitsanforderungen optimal abgestimmt werden kann. Datenbestände, die ‘sicher’ abgelegt werden müssen, plaziert man am besten auf RAID-1- oder RAID-5-Devices. Temporäre Dateien lassen sich ohne Verlust an physikalischem Speicherplatz auf einem RAID-0-Device unterbringen.

Die fünf Platten des Testsystems wurden zunächst in Partitionen unterschiedlicher Größe eingeteilt. Die Abbildung 3 zeigt die Aufteilung und ihre jeweilige Verwendung.

Die jeweils erste Partition der Laufwerke dient unterschiedlichen Zwecken. Festplatte A enthält die Boot-Partition mit einer minimalen Linux-Installation. Dort liegt das Kernel- und ein RAM-Disk-Image, aus dem im Normalfall gebootet wird. Diese RAM-Disk wird benötigt, damit unmittelbar nach dem Booten des Kernels die RAID-Devices initialisiert werden. Der eigentliche Boot-Vorgang geschieht auf dem dann verfügbaren RAID-1-Root-Bereich, der aus der jeweils ersten Partition von Platte B und C besteht. Dieser Umweg über die RAM-Disk ist notwendig, weil der Linux-Kernel zur Zeit noch kein RAID-1 beim Boot-Vorgang unterstützt. Im Falle eines Defekts dieser Boot-Partition läßt sich das System mit Hilfe einer Diskette problemlos wiederbeleben.

Auf Platte D sind in der ersten Partition noch keine Daten gespeichert, während Laufwerk E die Logfiles aufnimmt.

Für den Swap-Bereich - jeweils auf der zweiten Partition abgelegt - ist RAID für eine Performance-Steigerung nicht notwendig, da der Kernel von sich aus Daten auf mehrere Partitionen analog zu RAID-0 verteilt.
Zur Ablage temporärer Dateien dient das Directory /tmp. Hier stellt ein RAID-0-Array auf der jeweils dritten Partition mit insgesamt 2,5 GByte ausreichend Speicherplatz zur Verfügung.

Der kommerzielle Vergleich

System- und andere Applikationen, die das Sytem nicht zum Hochfahren benötigt, sind auf /usr abgelegt. Auch den Speicherplatz für dieses Verzeichnis stellt ein RAID-0-Device (Größe 12 GByte) bereit.
Die größten Partitionen mit je 5,6 GByte sind zu einem RAID-5-Array zusammengefaßt. In dem entstandenen circa 21 GByte großen Bereich liegen die eigentlichen Benutzerdaten.

Nach erfolgreicher Installation und nunmehr sechsmonatigem Betrieb des Servers fand ein Vergleich des Systems mit einem kommerziell erhältlichen Gerät mit ähnlichen Ausgangsdaten statt. Dazu stellte uns ‘bee - Baastrup EDV-Entwicklung GmbH’, Dortmund, ein Vorführgerät zum Test zur Verfügung (siehe Abbildung 2). Dieses System verfügt über den RAID-Controller GDT6527RP der Firma ICP-Vortex, der mit zwei Ultra-Wide-SCSI-Kanälen ausgestattet ist. Die notwendige RAID-Rechenarbeit leistet auf dem Controller Intels 960 CPU.

Das bee-System überzeugte zunächst auf Anhieb durch sein solides, hervorragend durchlüftetes Gehäuse. Auch dieses Gerät ist allerdings aufgrund der lauten Lüfter als direkter Arbeitsplatzrechner ebensowenig geeignet wie das beschriebene Software-RAID-System, auch wenn letzteres eher aufgrund der unangenehmen Festplattengeräusche als störend empfunden wird.

Die fünf eingebauten Festplatten sind in speziellen Einschüben montiert, die zusätzlich mit einem batteriegepufferten Mikrocontroller ausgestattet sind, über den die Versorgungsspannungen und die Festplattentemperatur überwacht werden. Diese Informationen sowie die MTBF der Platte lassen sich auch bei ausgeschaltetem Rechner auf einem kleinen LCD-Display ablesen. Die Temperatur liegt durch zwei in die Rahmen vorn und hinten integrierte kleine - sogar per Mikrocontroller geregelte - Lüfter auch im Dauerbetrieb zwischen unkritischen 28°C und 32°C.

Eine der Platten des bee-Systems ist als Systemdisk konfiguriert, die anderen vier sind zu einem RAID-5-Device zusammengefaßt. Vermutlich zur besseren Lastverteilung sind zwei Platten an einem SCSI-Kanal angeschlossen. Die Einstellung des Controllers erfolgte problemlos ohne Studium der Bedienungsanleitung. Nachteilig erwies sich die Tatsache, das jeweils nur vollständige Festplatten zu einem RAID-Device gruppiert werden können, daher war es nicht möglich eine direkt vergleichbare Konfiguration zum Software-RAID-System zu testen. Eine Partitionierung zur effektiven Aufteilung der Daten auf verschiedene RAID-Level ist bei diesem Hadware-RAID nicht möglich.

Soll ein RAID-5-Array mit geringem Verlust an nutzbarem Speicherplatz durch die Redundanzinformationen erstellt werden, müssen möglichst viele Platten zusammengefaßt werden. Bei der vorliegenden Konfiguration des RAID-5-Ensembles mit vier Platten bleibt netto die Kapazität dreier Festplatten übrig. Befindet sich keine weitere Platte im System, muß die Swap-Partition auf dem RAID-5-Array liegen. Negativ kann bei dieser Methode die Performance durch höhere Memory-Last des Systems erscheinen. Ein solcher Aufwand ist daher nur für Systeme mit extrem hohen Erwartungen an die Ausfallsicherheit angemessen - aus Geschwindigkeitsgründen ist für den Swap-Bereich eher RAID-0 zu empfehlen.

Das Testverfahren

Zur Bestimmung der Leistungsfähigkeit der Systeme diente ein I/O-Test auf Basis eines angepaßten bonnie. Der Bonnie bestimmt den Datendurchsatz unter Verwendung verschiedener Schreib-/Lese-Routinen. Zum einen führt er byteweise Lese- und Schreiboperationen durch (seq. out per char, seq. in per char) - was vor allem die effektive Implementierung der entsprechenden I/O-Routinen des Betriebssystems testet. Auf der anderen Seite erfolgen die Zugriffe blockweise (seq. out block, seq. in block), wobei die volle RAID-Performance zur Geltung kommt.

Der ‘rewrite’-Test liest einen zuvor angelegten Testbereich blockweise ein, ändert ein Byte des Blockes und schreibt diesen anschließend zurück. Damit wird der Filepointer nach jedem Block um eine Blockgröße zurückgesetzt.

Durch das statistische Zugriffsmuster beim ‘random seek’-Test verringert sich bei steigender Blockgröße die ‘cache hit’-Wahrscheinlichkeit, was letztlich die Performance einer Einzelplatte bestimmt.

Diese Plattentests wurden bis zu einer Größe von 640 MByte in 32-MByte-Schritten durchgeführt und bei jeder Blockgröße - zur statistischen Absicherung der Meßwerte - zehnmal wiederholt. Zwischen den einzelnen Durchläufen erfolgte jeweils eine Minute Pause, um sicherzustellen, daß vor jedem Lauf eine vergleichbare Ausgangssituation vorliegt. In den Abbildungen sind die Ergebnisse der Messungen zunächst arithmetisch gemittelt dargestellt.

Plattenanzahl bestimmt Performance

Auf den ersten Blick läßt sich erkennen, daß beide Systeme mit kleinen Request-Größen offenbar besser umgehen können als mit großen. Ab einer Größe von 128 MByte konvergieren die Transferraten gegen ihren asymptotischen Grenzwert.

Ein deutlich unterschiedliches Verhalten zeigen die Systeme unterhalb der 128-MByte-Grenze. Während das Hardware-RAID-System bereits bei Dateigrößen von 64 MByte erste Einbrüche zeigt, kann das Software-RAID-System bis 96 MByte seine durchaus ansehnlichen Transferraten tapfer halten. Dieser Umstand darf jedoch nicht darüber hinwegtäuschen, daß das Hardware-RAID-System bei kleinen Requests zum Teil erheblich höhere Transferraten bietet (man beachte die logarithmische Skalierung der Ordinate). Dieser Umstand ist zum Teil dadurch begründet, daß in diesem System leistungsfähigere Platten verwandt wurden (IBM DDRS im Gegensatz zu IBM DCHS).

Die Ergebnisse sind leicht anhand der Hardware-Merkmale der Geräte zu erklären: Das Hardware-RAID-System enthält einen 64 MByte großen Controller-Cache. Dadurch wird sichergestellt, daß bis zu dieser Grenze Write-Requests vornehmlich zwischen Hauptspeicher und Controller-Cache ablaufen können. Das Software-RAID besitzt jedoch kein Controller-Cache. Alle Schreibzugriffe erfolgen daher ‘unmittelbar’ auf die Festplatten. Dieses ‘unmittelbar’ muß allerdings relativiert werden. Der Linux-Kernel selber führt beim Schreiben ein recht effizientes Caching der Daten in einem Teil des zur Verfügung stehenden Hauptspeichers durch.

Das ist der Grund, warum sich beide Systeme ab einer Request-Größe von 128 MByte und mehr praktisch gleich verhalten. Der Controller-Cache des Hardware-RAID verliert auf Grund der für ihn zu großen Requests seine Bedeutung. Übrig bleibt das nackte RAID-5-Array, verbunden mit einem Rechner, der 128 MByte Hauptspeicher besitzt.

In diesem Bereich schneidet das Software-RAID-System deutlich besser ab, trotz Verwendung von weniger performanten Einzelplatten und einer 30 % langsameren Host-CPU. Die Datentransferrate beim Schreibzugriff übertrifft die des Hardware-RAID annähernd um den Faktor drei.

Eine Möglichkeit für dieses Verhalten des Software-RAID ist, daß hier fünf Platten verwandt wurden - bei dem Hardware-RAID-System waren es nur vier. Hiermit wäre nur eine Verbesserung um maximal 25 % zu erreichen. Die Hauptursache für das schlechte Verhalten des Hardware-RAID-Systems liegt vermutlich in der mangelnden Leistungsfähigkeit der Controller-CPU.

Der Vorteil der größeren ‘Datenstreuung’ trägt offenbar mehr zur Performance-Steigerung bei als die Verwendung zweier SCSI-Kanäle an einer ohnehin überforderten Controller-CPU. Die Nutzung mehrerer SCSI-Kanäle ist erst dann sinnvoll, wenn die angeschlossenen Platten in ihrer Gesamttransferrate die Bandbreite des Kanals auch ausnutzen können. Bei UltraWide-SCSI sind damit bei einer theoretischen Peak-Performance von 40 MByte/s pro Kanal derzeit wenigstens fünf Platten erforderlich - vorausgesetzt die Controller-CPU verkraftet die damit verbundene Datenrate überhaupt noch.

Einzig der Randomseek-Test unterliegt beim Software-RAID, da hier basierend auf einem statistischen Zugriffsmuster nicht periodisch auf das Platten-Array zugegriffen wird, was praktisch nur die Positionierzeit der Platten bestimmt.

RAID-0 bringt Durchsatz

Bei RAID-0 werden im Gegensatz zu RAID-5 die Daten ohne zusätzliche Redundanz abgelegt. Die Datenrate zu und von einem RAID-0-Device ergibt sich theoretisch aus der Summendatenrate der Einzelplatten. Zudem belastet Software-RAID die Host-CPU nicht durch die Berechnung der Redundanzdaten. Man sollte davon ausgehen können, daß ein RAID-0-Device eine höhere Performance als ein RAID-5-Device zeigen muß. Diese Aussage gilt wie oben beschrieben erst außerhalb des Cache-Einflusses. Die Meßdaten für den Bereich oberhalb der 128-MByte-Grenze verifizieren diese Aussage: Der Datendurchsatz für alle Tests liegt über den Werten von RAID-5. Bis auf den Randomseek-Test liegen alle gemessenen Transferraten auf diesem hohen Niveau. Daß dieser auch in diesem Vergleich unterliegt, ist wie beschrieben nicht verwunderlich.

Die vorliegenden Testergebnisse müssen allerdings relativ gesehen werden. War doch die dem Test zugrunde liegende Hardware nicht identisch. So wurden unterschiedliche Festplatten benutzt, IBM DCHS09U im Gegensatz zu IBM DDRS 29130W und bei dem Verdi System übernahm die CPU auf dem Motherboard die Rechenleistung. Im Gegensatz zum Rechner der Firma bee, der einen Controller mit eigener CPU besaß. Auch die Prozessoren selbst wiesen unterschiedliche Taktfrequenzen auf. Nach Angaben der Firma ICP Vortex, die den im bee-Rechner installierten Controller herstellt, wurden beim eigenen Bonnie-Test andere Meßergebnisse erzielt, als es in der Testumgebung der Fall war. Sie lagen durchschnittlich bei 29 MByte pro Sekunde, während im Test nur 10 MByte pro Sekunde erreicht wurden.

GUIDO BARTSCH und OLIVER SCHMITZ
sind wissenschaftliche Mitarbeiter an der RWTH-Aachen und entwickeln Verfahren zur numerischen Simulation akustischer Schallfelder.

Literatur

[1] Marcus Friedrich; Massenspeicher; Plattenschrank; Starlines RAID-Controller IFT-3102UA; iX 03/97; S. 56 ff

Mehr Infos

iX-TRACT

• Eine zentrale RAID-Fileserver-Lösung erhöht sowohl das nutzbare Speichervolumen als auch die Ausfallsicherheit.
• Bei kleinen zu verarbeitenden Datenmengen übertrifft Hardware-RAID das Software-RAID im Durchsatz.
• Beim Schreibzugriff schneidet das Softwaresystem um den Faktor drei besser ab.

Mehr Infos

RAID im Überblick

Mit dem Begriff ‘RAID’ wird allgemein die Technik beschrieben, Platten zu einem Array zusammenzufassen, obgleich der Begriff ursprünglich nur für ‘Redundant-Array-of-Independent-Disks’, also für die Zusammenfassung von Festplatten zur Erhöhung der Redundanz steht. In einigen Veröffentlichungen findet man auch den Begriff ‘Redundant-Array-of-Inexpensive-Disks’. Da sich unter dem Oberbegriff RAID teilweise völlig unterschiedliche Konzepte verbergen, wird zur Klassifikation eines RAID-Systems dessen RAID-Level angegeben:

RAID-0: Beschleunigt den Plattenzugriff, da es die Daten in einzelnen Blöcken (Stripes) auf mehrere Festplatten verteilt. Fällt eine Platte aus, sind die Daten verloren.

RAID-1: Wesentlich höhere Redundanz als RAID-0. Alle Schreibzugriffe erfolgen parallel auf zwei Laufwerke, wodurch ein Spiegelbild der Platten entsteht. Dieses Mirroring stellt die Daten doppelt zur Verfügung. Die Festplattenkapazität wird daher ebenfalls doppelt benötigt.

RAID-4: Ausgangspunkt ist ein Plattenarray mit mindestens zwei Festplatten. Von diesen wird eine als Stripe-Set betrieben, die als Nutzdatenträger bezeichnet wird. Die andere dient als Redundanzlaufwerk. Fällt dieses aus, ist ein direkter Datenzugriff über Nutzdatenträger möglich. Ist hingegen ein Nutzdatenlaufwerk defekt, sind die auf den Redundanzlaufwerken abgespeicherten Daten nicht mehr direkt verfügbar. Auf Basis der verbleibenden Nutzdatenträger können die Daten mit Hilfe der Redundanzplatte rekonstruiert werden.

RAID-5: Grundlage ist RAID-4. Indem die Paritätsdaten über alle Laufwerke verteilt werden, können auch die Schreibvorgänge schneller erfolgen. Die Performance wird deutlich verbessert. Die Schreibgeschwindigkeit ist aber schlechter als unter RAID-1.

Testsysteme
Hersteller	verdi	bee
Motherboard	Asus P2L97	Asus P2L97
CPU	Intel Pentium-II 233 MHz	Intel Pentium-II 333 MHz
RAM	128 MByte	128 MByte (12 ns SDRAM)
Controller	Adaptec AHA2940 UW	GDT 6527 RP 1
Festplatten	5 x IBM DCHS09U, 9.1 GByte SCSI A 0-2	5 x IBM DDRS 39130W, (9.1 GByte) SCSI B 1-2
Betriebssystem	Linux, Kernelversion 2.1.124	Linux, Kernel Version 2.1.x
Distribution	Slackware	Red-Hat-Software 5.1
RAID-Tools	Version 0.42	-
Preis	circa 6.300 DM	circa 11.190 DM
1 von ICP-vortex mit 64 MByte RAM, BIOS-Version 2.55d, Firmware 2.22.02-R016, zwei SCSI (Ultra-)Wide Kanäle - ‘hot swap’ und ‘hot fix’ - RAID-Level 0, 1, 4, 5, 10 - Alarm
Preise ohne Mehrwertsteuer

(jok)