Stratus ftServer 2400
Im Gegensatz zum rein softwarebasierenden Ansatz von Marathon offeriert Stratus eine fehlertolerante Lösung, die auf einer gemeinsam mit NEC entwickelten Hardware basiert. Außerdem stellt Stratus gehärtete Treiber für die 32-Bit-Variante von Windows 2003 Server und die 64-Bit-Version von Red Hat Enterprise Linux AS 4 zur Verfügung. Wir haben das Einstiegsmodell ftServer 2400 getestet.
Defekte Komponenten isolieren
Die hohe Verfügbarkeit erreicht Stratus durch "Dual Modular Redundancy" (DMR). Bei dieser Technik sind alle kritischen Hardwarekomponenten redundant ausgelegt. Die gehärteten Treiber versetzen den Hersteller nach eigener Aussage in die Lage, ein defektes PCI-Bus-Gerät zu erkennen und zu isolieren. Ein fehlertolerantes I/O-System, das vom CPU- beziehungsweise Speicher-Subsystem getrennt ist, vermag defekte Teile zu isolieren.
Der ftServer besteht aus zwei Server-Blades, die über eine gemeinsame Hochgeschwindigkeits-Backplane miteinander gekoppelt sind. Über diese tauschen die beiden Server Informationen, Betriebszustände und Ein-Ausgabe-Operationen aus. Die Lockstep-Technik stellt sicher, dass beide Systeme immer identische Instruktionen ausführen. Partnerkomponenten wie CPU, Hauptspeicher oder SCSI-Controller fungieren wechselseitig als Ersatzteile, welche im Notfall im laufenden Betrieb die Funktion eines ausgefallenen Gegenstücks übernehmen können.
Hardwaretausch im laufenden Betrieb
Sollte tatsächlich einmal ein Teil den Dienst versagen, so ist ein Techniker oder auch der Endkunde selbst in der Lage, bestimmte Server-Bestandteile im laufenden Betrieb auszutauschen, ohne das Komplettsystem herunterfahren zu müssen. Beim ftServer 2400 beschränkt sich die Austauschbarkeit jedoch auf die Festplatten und die Netzteile. Sobald der Hauptspeicher, eine CPU oder die Netzwerkkarten betroffen sind, erfolgt die Reparatur durch Austausch des kompletten Blades. Der Betrieb des zweiten Blade-Moduls wird hierdurch jedoch nicht beeinträchtigt.
Über eine Call-Home-Funktion kann der ftServer zudem im Fehlerfall per Modem- oder Internet-Anbindung Kontakt zum Hersteller aufnehmen und melden, welche Komponenten defekt sind. Falls eine tiefer gehende Problemanalyse erforderlich sein sollte, besteht für einen Stratus-Servicetechniker die Möglichkeit zur Ferndiagnose, indem er sich über das "Virtual Technician Module" (VTM) auf den betreffenden Server aufschaltet. Das VTM basiert auf Hardware, die auch noch nach Betriebssystem-Abstürzen arbeitet.
Zusatz-Tools vereinfachen Administration
Über die "ftServer Management Console" verschafft sich der Systemverwalter einen vollständigen Überblick über sämtliche Hard- und Softwarekomponenten. Auch die Konfiguration zahlreicher Stratus-spezifischer Funktionen wie zum Beispiel des Virtual Technician Module ist hierüber möglich. Der "Software Availability Manager" überwacht Betriebssystem-Komponenten. Einstellen kann der Verwalter, dass die Lösung E-Mails versendet oder Programme startet, wenn bestimmte Schwellwerte überschritten werden. Ein SNMP-Agent erlaubt es, das Stratus-System in bestehende System-Management-Umgebungen einzubinden.
Automatisiertes Rolling Upgrade
Für Upgrades der ftServer im laufenden Betrieb (Rolling Upgrades) bietet Stratus die Zusatzsoftware "Active Upgrade". Sie unterbricht die Verbindung zwischen beiden physikalischen Systemen und gestattet es, das Software-Update vorzunehmen, zu testen und anschließend beide Systeme wieder zu synchronisieren. Auch hier weisen die beiden Lösungen von Marathon und Stratus konzeptionelle Gemeinsamkeiten auf, nur mit dem Unterschied, dass bei Stratus die Vorgehensweise bereits sehr umfassend automatisiert ist. Die Active-Upgrade-Software prüft zunächst, ob alle Systemkomponenten einwandfrei arbeiten und sich die Redundanz ohne Schäden aufbehen lässt. Ist der Test erfolgreich, kann der Systemverwalter die Blades trennen und festlegen, welches System weiterhin für Client-Anfragen zur Verfügung stehen und auf welchem das Upgrade stattfinden soll. Das Stratus-System synchronisiert beide Rechner im Chassis, bevor es die Verbindung kappt. Das zu aktualisierende Blade wird sodann vollständig vom Netzwerk getrennt und ist nun nur noch über die Konsole des zweiten Blade-Systems erreichbar. Ab diesem Zeitpunkt kann der Systemverwalter Updates einspielen und testen. Danach führt er die beiden Systeme wieder zusammen, indem er das aktualisierte System für den Client-Zugriff freischaltet und durch eine Synchronisierung der Betriebssystem-Partitionen das bis dahin aktive System aktualisiert. Die Daten werden gespiegelt, was wie beim Marathon-System auch bei Stratus nur dann unterbrechungsfrei funktioniert, wenn keine strukturellen Datenänderungen, etwa in einer Datenbank, stattfinden. Ist dies der Fall, müssen die Daten über einen zusätzlichen Schritt, der mit einer Ausfallzeit verbunden ist, migriert werden.