In einer professionellen Serverumgebung sollte ein leistungsfähiges und flexibles Raid-Subsystem nicht fehlen. Zum Test stand uns ein Hardware-Raid-Controller des Typs GDT6517RP des Herstellers ICP Vortex zur Verfügung. Das Subsystem verfügt über einen eigenen Prozessor, einen Intel i960 mit 33 MHz Takt. Außerdem ist genügend lokaler Speicher vorhanden: Die Kapazität beträgt 4 MByte bis 64 MByte; wir hatten für den Test die Karte voll bestückt. Damit entlastet der Controller das Gesamtsystem spürbar.
Ab der Kernel-Version 2.0.31 von Linux ist der entsprechende Treiber bereits fest integriert. Je nach Linux-Version beziehungsweise Distribution handelt es sich dabei allerdings um ältere Treiber. In jedem Fall sollte man auf der Web-Site des Herstellers (http://www.icp-vortex.com) nachsehen, ob inzwischen eine aktuellere Variante verfügbar ist. Zwar kann man den Treiber in vielen Fällen auch als ladbares Modul während des Linux-Bootvorgangs starten, doch bietet es sich bei einem so zentralen Element an, ihn gleich in den Kernel zu integrieren.
Genau das haben wir getan, weil es uns darum ging, ein leistungsfähiges und vor allem fehlertolerantes Festplattensubsystem auf Linux-Basis aufzubauen. Das besprochene System basiert auf der Linux-Distribution Suse 6.0. Es bietet bereits von Hause aus den Zugang zur ICP-Hardware. Den Raid-Controller kann man bei dieser Distribution leicht direkt aus dem zentralen Konfigurationstool "Yast" auswählen und damit den passenden Treiber in die Bootkonfiguration aufnehmen.
Zur Konfiguration des Kernels, notwendig bei einer nachträglichen Integration der Raid-Hardware, stehen einige zum Teil recht komfortable Konfigurations-Utilities wie make config, make xconfig und make menuconfig zur Verfügung. Probleme gab es, sobald hierbei die Kernel-Option "lesbare SCSI-Fehlermeldungen" aktiviert war. Danach ging beim Booten ab einem bestimmten Zeitpunkt nichts mehr. Wohl dem, der den alten Kernel dann noch im Zugriff hat.
Im Gegensatz zu anderen Herstellern meint es ICP-Vortex mit dem Linux-Support für den Raid-Controller ernst. Dies bedeutet, daß nicht nur der Treiber zur Ansteuerung der Hardware und damit der nackten Festplatten zur Verfügung steht, sondern darüber hinaus auch noch der sogenannte "GDTMonitor". Dies ist ein Zusatzprogramm, welches man später zur Online-Verwaltung benötigt. Hiermit ist es möglich, neue Festplatten einzubinden, Zustandsinformationen abzurufen oder die Raid-Konfiguration zu modifizieren.
Konfiguration
Die Erstkonfiguration der Raid-Umgebung erfolgt direkt aus einem Flash-Bios, das die Firmware enthält und der dort abgelegten Utility "GDTSETUP", welche man zur Bootzeit des Rechners mit CTRL-G erreicht. Damit geht der Hersteller einen eigenständigen Weg, denn alle notwendigen Schritte zum Setup erfolgen direkt in der Firmware und sind damit nicht betriebssystemabhängig. Damit erkannte das Testsystem allerdings nach dem ersten Bootvorgang und dem Check der noch jungfräulichen Festplatten den eigenen Controller nicht mehr. Erst beim zweiten Boot ertönte der typische Vierfach-Beep des Controllers, der bei einem fehlerfreien System nach dem Selbsttest akustisch Entwarnung gibt.
Der Controller selbst läßt einige Optionen wie Memory-Selbsttest oder Auto-Terminierung zu. Bei einem neuen System sollte man zur Sicherheit den Speichertest einschalten, der beim Booten den lokalen Cache-Speicher untersucht. Ist alles in Ordnung, kann man diesen relativ zeitintensiven Vorgang abschalten, um die Bootzeit bei einem fertig konfigurierten System entsprechend zu verkürzen. Normalerweise findet der Controller alle angeschlossenen SCSI-Devices automatisch. Ohne Reboot lassen sich, eine entsprechende Hot-Swap-Umgebung vorausgesetzt, zusätzliche Laufwerke sofort integrieren und durch einen "Rescan for new Device" durch den Controller einbeziehen.
Die Standard-Firmware (Controller GDT61xyRP) bietet Raid 0 (Data Striping) und Raid 1 (Disk Mirroring/Duplexing). Der zum Test verfügbare Controller (GDT6515RP) mit der "Raydyne"-Option bietet darüber hinaus noch Raid 4 (Data Striping mit separatem Parity-Laufwerk) sowie Raid 5 (Data Striping mit verteilter Parity) und Raid 10 (Raid 0 und Raid 1 kombiniert). Hierbei lassen sich ein oder mehrere Laufwerke als sogenannte "Hotfix"-Drives konfigurieren. Diese stehen als Ersatzlaufwerke zur Verfügung: Sobald ein "heißes" Laufwerk ausfällt, erkennt das der Controller automatisch und setzt das Zusatzlaufwerk in Betrieb.
Beide Firmware-Versionen arbeiten auf vier hierarchisch aufeinander aufbauenden Levels. Die niedrigste Ebene 1 arbeitet mit den physikalisch vorhandenen Laufwerken, die als Grundbausteine für die logischen Laufwerke der höheren Ebenen dienen. Die nächste Ebene arbeitet mit "logischen" Laufwerken. Diese stehen zwar in direktem Bezug zu einem physikalischen Laufwerk, jedoch ist es durch diese Abkoppelung möglich, einzelne Laufwerke im Betrieb zu isolieren und durch neue Festplatten zu ersetzen. In der dritten Ebene arbeitet das System mit sogenannten "Array Drives". Diese können bereits eine von der physikalischen Anordnung abweichende logische Struktur aufweisen. Beispielsweise ist es möglich, einzelne Laufwerke zu einem neuen logischen Laufwerk zusammenzubauen oder man kann hier bereits eine Raid-Konfiguration vorgeben.
In der vierten und höchsten Ebene erzeugt man die sogenannten "Host"-Drives. Nur diese Laufwerke "sieht" das Betriebssystem. Auf Wunsch kann man dabei den gesamten Festplattenpool unterschiedlichen Host-Laufwerken zuordnen um beispielsweise ein Raid-5-System parallel zu einer einfachen Raid-0-Struktur oder gar einem "normalen" (also einzelnen) logischen Laufwerk ohne zusätzliche Sicherheit betreiben zu können.
Vor der erstmaligen Verwendung müssen die Laufwerke initialisiert werden. Interessant ist in diesem Zusammenhang, daß die Platten dabei eine eigenständige Kennung bekommen, mit deren Hilfe sie später zu identifizieren sind. Der Controller "weiß" also, um welches Laufwerk es sich jeweils handelt und damit auch, welche Daten sich darauf befinden sollten. Wechselt man den Controller aus, so sorgt diese interne ID dafür, daß die Daten sofort wieder "zusammenpassen". Hierzu legt die Firmware am Anfang und am Ende des Datenbereichs der Festplatte redundant jeweils einen 300 KByte großen Bereich für die Konfigurationsdaten des gesamten Raid-Verbands ab.
Im einfachsten Fall muß man sich allerdings nicht mühsam durch die vier Ebenen hangeln, sondern man kann gleich mit der Definition des "Host"-Drives - dies ist die vierte und oberste Ebene - über den sogenannten "Express Setup" beginnen. Sind alle Laufwerke richtig erkannt, so bietet die Setup-Routine alle angeschlossenen physikalischen beziehungsweise logischen Laufwerke an. Je mehr Laufwerke man bei diesem Schritt auswählt, um so mehr Raid-Konfigurationen stehen zur Verfügung. Die Firmware sorgt dann dafür, daß die physikalischen, logischen und Array-Laufwerke entsprechend vorbereitet sind.
Möchte man ganz sichergehen, so sollte man insbesondere neue Festplatten mit der Funktion "Check Surface" überprüfen. Bei diesem Check schreibt die Firmware vier unterschiedliche Bitmuster auf die Platte und vergleicht diese nach einem Lesevorgang mit den Soll-Daten. Tauchen im späteren Betrieb Probleme auf, so meldet die Monitor-Routine entsprechende "Retries", die auf kommende oder bereits aufgetretene Probleme hinweisen.
Gralshüter
Der beste Schutz ist nichts wert, wenn man sich nicht darauf verlassen kann. Deshalb ist es zwingend notwendig, daß zur Laufzeit Statusinformationen zur Verfügung stehen, um bei Bedarf entsprechende Schritte einzuleiten. Im Zentrum der ICP-Vortex-Lösung steht der Raid-Monitor "GDTMON", der ständig über den aktuellen Status informiert und im laufenden Betrieb für Fehlerkorrektur und Optimierung zur Verfügung steht.
Der Monitor erlaubt auch ein Verändern der Cache-Arbeitsparameter. So lassen sich Optionen wie "Delayed Write" oder wahlweise auch der gesamte Cache ein- oder ausschalten. Die Parameter jeder einzelnen Festplatte - SCSI-Protokoll, synchroner oder asynchroner Betrieb, synchrone Transferrate, Disconnect/Reconnect sowie Disk Cache und Tagged Queues - lassen sich ebenfalls im Betrieb modifizieren. Die Paritätsinformationen der Raid-Hosts stehen ebenfalls auf Abruf bereit.
Interessant ist die Möglichkeit, den gewählten Raid-Modus im laufenden Betrieb anzupassen. Zudem lassen sich zur Kapazitätserhöhung neue Festplatten integrieren, ohne daß hierzu das System offline gestellt werden muß. Verabschiedet sich einmal eine Festplatte in die ewigen Jagdgründe, so kann der Sysadmin jetzt eine Ersatzplatte integrieren, sofern er nicht sowieso für diesen Moment eine Hotfix-Festplatte in Reserve gehalten hat.
Unter Betriebssystemen wie Windows 95/98 beziehungsweise NT oder Netware besteht die Möglichkeit, auch über das Netzwerk an die Monitordaten zu gelangen. Hierzu bietet "GDTMON" einen kleinen Netzwerkserver, über den die Daten abrufbar sind. Unter Unix kann man sich aber jederzeit direkt per Telnet oder mit Hilfe des X-Windows-Systems einwählen und dann lokal auf den Monitor zugreifen. Damit steht einer Fernwartung nichts im Weg.
Die mit diesem Controller ausgestatteten Systeme arbeiteten auch unter Last fehlerfrei. Ein testhalber erzeugter mutwilliger Festplattenfehler (Deaktivieren der Platte durch den Schalter im Wechselrahmen) brachte das System nicht aus der Ruhe. Der Controller erkennt den Fehler und veranlaßt eine entsprechende Systemmeldung, die auch in der Logdatei /var/log/messages erscheint. Sofort läuft der Hotfix-Vorgang an, bei dem die bislang freie Platte die Stelle des fehlerhaften Massenspeichers einnimmt. Der Rebuild-Vorgang, bei dem die jetzt fehlenden Daten aus den verteilten Paritätsdaten neu erzeugt werden, dauert eine ganze Weile. Hierzu las der Controller die Daten beim Testsystem (Pentium II-CPU, 400 MHz) mit etwa 3,4 MByte/s und schrieb die umgerechneten Datenpakete dann mit etwas mehr als 1 MByte/s auf das "neue" Laufwerk. Natürlich darf in diesem Zeitraum kein weiterer Festplattenfehler auftreten, denn die Redundanzdaten sind ja nur für den Ausfall einer einzigen Festplatten vorbereitet. Das System ist allerdings zur Regenerationszeit weiter voll einsatzbereit.
Insgesamt hinterläßt der Raid-Controller GDT6517RP von ICP Vortex einen vorzüglichen Eindruck. Sowohl die Installation als auch der Betrieb unter Linux sind problemlos. Das mitgelieferte Handbuch sowie die verfügbaren White Paper des Herstellers sind in deutscher Sprache gehalten und absolut lesenswert, geben sie doch essentielle und vor allem praxisbezogene Tips. Linux ist durch diesen Controller wieder ein Stück professioneller geworden. (ch)