Das von Marathon mit "Everrun FT" verfolgte Konzept erinnert zunächst an klassische Virtualisierungslösungen, wie sie beispielsweise VMware oder Xensource anbieten. Anders als diese Hersteller mit ihren Hypervisor-Lösungen implementiert Marathon jedoch keine virtualisierte Hardware, sondern partitioniert die vorhandenen Systemressourcen lediglich.

Als Basis fungieren zwei Rechner mit Intel- oder AMD-CPU und dem Betriebssystem Windows 2003 Server. Über einen "Redirector" integriert sich Everrun FT in das Basis-Betriebssystem und partitioniert die verfügbaren physikalischen Ressourcen CPU, Hauptspeicher, Netzwerkkarten und Plattenplatz im "Virtual Application Environment" (VAE). Windows läuft auf beiden physikalischen Knoten und erhält dediziert eine CPU und 256 MB Hauptspeicher. Eine zweite CPU und der verbleibende Hauptspeicher stehen dem Virtual Application Environment zur Verfügung. Innerhalb des VAE läuft wiederum eine eigene Kopie von Windows 2003 Server, die simultan auf beiden physikalischen Maschinen ausgeführt wird. Die Installation der zu schützenden Applikation erfolgt innerhalb des VAE.

Gegenüber dem Virtual Application Environment und den darin laufenden Anwendungen werden beide physikalischen Server wie ein Einzelsystem betrachtet. Alle vorhandenen und per Redirector eingebundenen physikalischen Hardwarekomponenten erscheinen damit ebenfalls wie eine einzelne Komponente. Fällt ein Hardwareelement eines physikalischen Servers aus, übernimmt die entsprechende Komponente des zweiten Servers dessen Aufgabe. Da die im Virtual Application Environment installierte Kopie von Windows 2003 Server auf beiden Systemen parallel vorhanden ist, läuft der per Everrun FT geschützte Dienst selbst dann unterbrechungsfrei weiter, wenn einer der beiden physikalischen Server komplett den Dienst versagt.

Voraussetzung für die hohe Ausfallsicherheit ist, dass die beiden physikalischen Server über zwei dedizierte Gigabit-Ethernet-Verbindungen miteinander gekoppelt sind. Über diese Netzstrecke gleichen die beiden Knoten Speicherinhalte, Register-inhalte der beteiligten CPUs und die Daten im File-System ab. Die beiden Gigabit-Verbindun-gen gestatten es, beide Server bis zu 160 Kilometer entfernt von-einander aufzustellen, ohne dass weitere Tools oder Speichernetzwerke mit Zusatzsoftware zur Datenreplikation erforderlich wären. Die Einschränkung bei der Distanz fällt in der Praxis meist kaum ins Gewicht, da bei vielen Unternehmen Produktiv- und Ausfallrechenzentrum im Radius weniger Kilometer voneinander angesiedelt sind.

Datenkonsistenz

Um die auch bei Cluster-Systemen gefürchteten Split-Brain-Situationen auszuschließen, bietet Marathon eine Split-Site-Option. Diese beinhaltet einen Dienst, der eine Quorum-Funktion realisiert.

Split Brain bezeichnet eine Situation, in der zwei oder mehr Knoten eines Clusters noch funktionieren, allerdings keine Koordination mehr stattfinden kann. Dies kann beispielsweise passieren, wenn ein Knoten alle Netzwerkverbindungen verliert. Abgesehen von der Netzwerkverbindung bleibt der Knoten jedoch voll funktionsfähig. Split Brain kann bei Schreibzugriffen zu inkonsistenten Datenbeständen führen, die nicht mehr oder nur noch mit großem Aufwand aufgelöst werden können.

Die Split-Site-Option kann Split Brain durch Verwendung einer Quorum-Komponente vermeiden. Das heißt, nur derjenige Knoten arbeitet weiter, der noch am Leben ist und über das Netzwerk Zugriff auf das Quorum hat. Der andere Knoten schaltet sich selbsttätig ab.

Der Dienst kann auf jedem beliebigen Windows-Server im Unternehmensnetz installiert werden. Sollten die beiden physikalischen Everrun-Knoten nicht mehr direkt über das Netzwerk miteinander kommunizieren können, geht derjenige Knoten offline, der keine Verbindung mehr zum Quorum-Dienst herstellen kann. Auf diese Weise wird sichergestellt, dass die Datenbestände konsistent bleiben.

Vereinfachte Administration

Da der geschützte Dienst aus logischer Sicht auf einem Server läuft, muss er nicht Cluster-tauglich sein. Zudem entfallen spezielle Skripte. Ferner gibt es keine Umschaltzeiten und auch keine Probleme mit Applikationen.

Auch im Wartungsfall leistet Everrun FT gute Dienste, obwohl es von Marathon derzeit noch keine Tools gibt, um ein automatisiertes und unterbrechungsfreies Upgrade (Rolling Update) des VAE vorzunehmen. Mit einigen manuellen Handgriffen lässt sich die Ausfallzeit jedoch verkürzen. Dazu muss der Systemverwalter zunächst die im VAE ausgeführte Applikation stoppen und dann einen der beiden physikalischen Knoten über die Administrationsoberfläche von Everrun FT deaktivieren. Der abgetrennte und zu aktualisierende Knoten muss dann vollständig vom Netzwerk getrennt werden. Anschließend kann der noch mit dem Netzwerk verbundene Knoten wieder das VAE in Betrieb nehmen. Auf dem anderen, vom Netzwerk getrennten System kann der Systemverwalter das VAE nun ebenfalls starten, die gewünschten Upgrades einspielen und testen. Waren die Tests erfolgreich, muss man die Applikation erneut stoppen, um die Netzanbindung wiederherzustellen und die beiden physikalischen Knoten zu synchronisieren. Dabei wird das aktualisierte VAE vom zuvor netzwerkseitig abgetrennten Server auf den produktiven zurückgespiegelt, während die gegebenenfalls geänderten Daten in umgekehrter Richtung gespiegelt werden.

Falls das Software-Update beispielsweise das Schema einer Datenbank verändert, muss der Administrator die Daten migrieren, was längere Ausfallzeiten nach sich ziehen kann. Marathon will künftig Tools liefern, um den Upgrade-Prozess weitestgehend zu automatisieren.

Simulierter Totalausfall

Sofern alle Hardwarevoraussetzungen erfüllt sind, bereiten Installation und Konfiguration von Everrun FT keine nennenswerten Schwierigkeiten. Auch Standardprodukte wie Microsoft SQL Server einzurichten macht keine Probleme.

Positiv hervorzuheben ist in diesem Zusammenhang die umfangreiche und gut verständliche Dokumentation, die zwar nur in englischer Sprache vorliegt, aber kaum Fragen offenlässt. Zudem lässt sich das Marathon-Produkt dank einer klar gegliederten Benutzeroberfläche einfach bedienen. Alle wichtigen Betriebsstati sieht der Anwender auf einen Blick. Vorbildlich ist zudem, dass Everrun FT Aktivitäten im Windows-Eventlog protokolliert.

Simulierte Ausfälle von Festplatten, Netzkomponenten sowie einem kompletten physikalischen Server fing das System zuverlässig ab. Selbst umfangreiche Festplattensynchronisationen, die nach einem simulierten Totalausfall eines Servers im Testlabor erforderlich waren, nahmen nur wenige Minuten in Anspruch.

Everrun FT kann in Sachen Leistungsfähigkeit zwar nicht mit dedizierten Einzelsystemen mithalten, jedoch bewegen sich die Zahlen in einem akzeptablen Bereich.

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-Ver-sion 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- und 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.

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.

Ü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 Schwellenwerte überschritten werden. Ein SNMP-Agent erlaubt es, das Stratus-System in bestehende System-Management-Umgebungen einzubinden.

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.

Festplatten abgeklemmt

Um die Ausfallsicherheit des Systems unter die Lupe zu nehmen, zogen wir im laufenden Betrieb willkürlich Netzwerkverbindun-gen sowie Festplatten und kappten schließlich noch die Verbindung zu einem Netzteil. Der ftServer ließ sich jedoch durch keine einzige dieser Aktionen aus der Ruhe bringen. Auch vom Aus-schalten eines der beiden Blades im laufenden Betrieb zeigte sich die Stratus-Lösung unbeeindruckt. Gleichermaßen bereitete das Beheben der simulierten Ausfälle keinerlei Schwierigkei-ten, und so stand, abgesehen von der erforderlichen Festplattensynchronisation, nach wenigen Augenblicken wieder vollständige Redundanz zur Verfügung. Eine zum Server bestehende RDP-Verbindung (Remote Desktop Protocol), sowie ein Kopierjob liefen während des ganzen Testzeitraums klaglos weiter.

Eine Langfassung finden Sie unter http://www.computerwoche.de/1850007.

(fn)