Komplettsystem ftServer tritt gegen die Softwarelösung Everrun FT an

Test: Fehlertolerante Server von Marathon und Stratus mit leichten Schwächen

07.12.2007
Von Dirk Pelzer
Fehlertolerante Server versprechen nicht nur eine Verfügbarkeit, die deutlich über der von gängigen Cluster-Systemen liegen soll, sondern auch eine vereinfachte Administration. Die COMPUTERWOCHE hat die Lösungen von Stratus und Marathon Technologies verglichen, um zu sehen, ob die Hersteller halten, was sie versprechen. Beide Produkte glänzen durch einfache Handhabung, zeigen aber Schwächen in bestimmten Einsatzbereichen.

Ansätze, Intel-Server hochverfügbar zu machen, gibt es viele. Dazu zählen klassische Cluster-Lösungen ebenso wie Replikations-Tools. Die meisten dieser Produkte beruhen auf dem Failover-Prinzip, bei dem es im Notfall zu einer mehr oder weniger langen Ausfallzeit kommt. Zudem sind Failover-basierende Systeme kompliziert zu bedienen, da Systemspezialisten Skripte schreiben müssen. Außerdem müssen die auf den Rechnern laufenden Applikationen Cluster-tauglich sein. Ohne speziell ausgebildetes Personal lassen sich diese Computer nicht betreiben.

Hochverfügbarkeit durch Fehlertoleranz

Eine Alternative versprechen die Firmen Marathon und Stratus mit ihren Produkten "Everrun FT" beziehungsweise "ftServer". Die Lösungen sollen zu 99,999 Prozent verfügbar sein. Das entspricht einer ungeplanten Ausfallzeit von zirca fünf Minuten pro Jahr. Während Marathon mit seiner rein softwarebasierenden Everrun-FT-Lösung ein breites Spektrum unterschiedlicher Server unterstützt, setzt Stratus auf eigene Hardware.

Marathon Everrun FT

Das von Marathon mit Everrun FT verfolgte Konzept erinnert zunächst an klassische Virtualisierungslösungen, wie sie beispielsweise VMware oder Xensource anbieten. Vor allem durch die von Marathon verwendeten Terminologie besteht zunächst Verwechslungsgefahr, denn der Hersteller spricht von einer virtuellen Maschine, die simultan parallel auf zwei voneinander getrennten Hardwaresystemen ausgeführt wird. Anders als VMware oder Xensource mit ihren Hypervisor-Lösungen implementiert Marathon jedoch keine virtualisierte Hardware, sondern partitioniert die vorhandenen Systemressourcen lediglich.

Der Marathon Manager zeigt auf einen Blick, ob alle Komponenten einwandfrei arbeiten.
Der Marathon Manager zeigt auf einen Blick, ob alle Komponenten einwandfrei arbeiten.

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 stehten 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, Registerinhalte der beteiligten CPUs und die Daten im File- System ab. Die beiden Gigabit-Verbindungen gestatten es, beide Server bis zu 160 Kilometer entfernt voneinander 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 als oberstes Gebot

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.