Metrocluster – Lebensversicherung für das Rechenzentrum

Feuer, Erdbeben, Überschwemmung oder ein kompletter Stromausfall – dies sind zwar seltene Phänomene in unseren Breitengraden, aber dafür Situationen, die ein komplettes Rechenzentrum außer Betrieb setzen können. Um die Einsatzfähigkeit ihrer IT-Systeme selbst unter solchen Umständen zu garantieren, setzen Firmen die auf Hochverfügbarkeit angewiesen sind auf Metrocluster. Diese schalten beim Ausfall eines Rechenzentrums einfach auf ein zweites Rechenzentrum um.

Absicherung kompletter Rechenzentren

Redundanz ist der Schlüssel zu Hochverfügbarkeit, das gilt auch für den Extremfall, in dem man ein ganzes Rechenzentrum vor Stromausfällen und Katastrophen schützt. Ein Metrocluster ist im Grunde genommen ein auf zwei oder mehr Standorte auseinander gezogenes lokales Cluster bei dem ein lokal gespiegelter Speicher zum Einsatz kommt. Ein Metrocluster kann so gestaltet werden, dass kein einziger Point of Failure bestehen bleibt, und mit der Prämisse, dass ein einzelner Hardwareausfall noch kein Umschalten zwischen den Sites notwendig macht. Der größte Vorteil eines Metroclusters besteht darin, bei einem Problem automatisch, ohne Eingreifen eines Administrators, auf die Alternative umzuschalten. Beim Einsatz von asynchroner Replikation müsste ein Mensch entscheiden, wann und ob umgeschaltet wird. Dies würde wiederum einen vorher definierten Notfallplan bedingen. Eine Automatisierung dieses Prozesses kann dagegen eine durchgängige Uptime für Applikationen garantieren.

Pro Standort besteht das Konzept aus einem Storage Layer der jeweils lokal hochverfügbar ausgelegt ist – d.h. jeweils ein Cluster mit zwei Nodes. Dieser Cluster stellt den Festplattenspeicher für die Service Nodes zur Verfügung. Die Service Nodes spiegeln jeweils ihre Daten zwischen den beiden Standorten und alle vier Nodes gehören zu einem standortübergreifenden 4-Node-Cluster.

Ein voller Metrocluster bietet zahlreiche Vorteile:

• Keine Ausfallzeiten wegen Upgrades, weder für Hardware noch Software
• Einfacher Aufbau und Verwaltung
• Vollkommener Schutz aller unternehmenskritischen Daten
• Automatisches und manuelles Failover

Um einen Metrocluster aufzubauen, sollten zwei Bedingungen erfüllt sein:

• Die Leitungen zwischen den Rechenzentren müssen sich durch eine sehr niedrige Latenz auszeichnen.
• Die Entfernungen sollten rund 50 Kilometer nicht überschreiten, da durch die Entfernung auch die Latenzzeiten steigen und höhere Latenzen die Leistung des Gesamtsystems beeinträchtigen.

In den USA, wo Standorte oft tausende von Kilometern voneinander entfernt sind, besteht aus diesem Grund in den meisten Fällen überhaupt keine technische Möglichkeit, ein Metrocluster einzusetzen und das Konzept ist dort daher kaum bekannt. Die Idee eines Metroclusters orientiert sich an europäischen Gegebenheiten, wo Unternehmen oft mehrere Niederlassungen und Rechenzentren haben, die nur wenige Kilometer voneinander entfernt sind. Hier können viele Unternehmen mit relativ geringen Investitionen die Verfügbarkeit ihres Clusters auf ein sehr hohes Niveau heben.

Szenarien eines Systemausfalls – und Lösung dieser mit einem Metrocluster

Ein Cluster hat zahlreiche Schwachstellen. Ziel eines Metroclusters ist, für jeden Schwachpunkt automatische Rückfall-Lösungen bereitzustellen, um eine Auswirkung auf Applikationen zu vermeiden oder diese zumindest stark einzuschränken. Im Folgenden werden sieben Ausfallszenarios und ihre Folgen am Beispiel eines Metroclusters aufbauend auf ZFS-Technologie dargestellt.

• Ausfall einer Festplatte

Fällt eine Festplatte aus, hat dies für den operativen Betrieb so gut wie keine Folgen. Der Administrator tauscht die Platte im laufenden Betrieb aus, die Daten der defekten Platte werden einfach wieder synchronisiert.

• Ausfall eines wichtiger Komponenten in den Disk-Shelves

Das Multi-pathing der Storage Nodes sorgt beim Ausfall eines SAS Kabels, SAS-HBAs oder Expanders dafür, dass alle Services ohne Unterbrechung online bleiben. Der Administrator ersetzt die Teile im laufenden Betrieb.

• Ausfall eines ganzen Disk-Shelves

Die Verteilung der RAIDZ-2-Festplattenverbünde werden so zwischen den JBODs verteilt, dass auch ein kompletter JBOD-Ausfall verkraftet wird. Geht nach einem Ausfall eines JBODs dieser wieder online, so werden nur die bis dahin veränderten Daten synchronisiert. Alle Services bleiben so ohne Unterbrechung online, ohne dass ein nennenswerter Einbruch der Performance zu erwarten ist.

•  Ausfall eines Storage Nodes

Beim Ausfall eines kompletten Servers der Storage Nodes übernimmt ein zweiter Server am selben Standort die Aufgaben des defekten Servers innerhalb weniger Sekunden. Obwohl der I/O-Datenstrom kurzzeitig aussetzt, welches von den Service Nodes im oberen Bereich bemerkt wird, werden diese Aussetzer nicht an die Anwendungen weitergereicht, da zu jeder Zeit noch der Spiegel zum zweiten Standort vorhanden ist.

• Ausfall eines Switches, Kabels oder Fibre Channel-HBAs zwischen Storage Nodes und den oberen Service Nodes

Auch dieses Szenario wird durch Multi-pathing der Service Nodes bewältigt. Ein Failover auf das andere Rechenzentrum ist nicht notwendig und die Performance der Applikationen wird nicht merklich beeinträchtigt.

• Ausfall eines Service Nodes

Bei einem kompletten Ausfalls eines Service-Nodes kommt es bei der Nutzung von ZFS nur zu einer kurzen, einige Sekunden dauernden Unterbrechung des I/O-Stroms an die Applikationen. Die Umschaltzeit ist abhängig von der Anzahl der Services wie NFS Shares, CIFS-Shares, iSCSI-Targets. Sie ist dagegen unabhängig von der Datenmenge, da ZFS-Technologie im Gegensatz zu anderen Systemen nie einen kompletten ‘File System Check’ durchführen muss.

Für die Applikationsserver ist diese Umschaltung transparent, im Falle von Fibre Channel müssen die Applikationsserver vom Betriebssystem einen ALUA-fähigen Multi-pathing Treiber mitbringen, was heutzutage oft Standard ist. Das Cluster wird so konfiguriert, dass die Services immer zuerst auf den lokal benachbarten Node umgezogen werden, um ein Site Failover nur für den kompletten Ausfall eines Standorts nötig zu machen.

• Ausfall eines kompletten Standorts

Im schlimmsten anzunehmenden Fall, fällt ein kompletter Standort aus. Erst in diesem Fall nutzt der Metrocluster die Redundanz des Rechenzentrums für ein Failover und der zweite Standort übernimmt alle Services. Den Anwendungsservern stehen somit alle Dienste zur Verfügung, wenn auch nur auf der Hälfte der Service Nodes, d.h. mit eingeschränkter Performance. Da in diesem Fall allerdings auch das Spiegeln, Lesen und Schreiben zwischen den Standorten wegfällt, verbessert sich die Latenz, was zum Beispiel bei Datenbanken sogar zu besserer Performance führen kann. Geht der ausgefallenen Standort wieder online, wird niemals der komplette Datenbestand zurückgespielt, sondern nur alle bisher dahin geänderten Daten.

Vermeidung eines ‘Split Brains’

Um bei einem einfachen Ausfall der Verbindungen zwischen den Rechenzentren nicht zu undefinierten Zuständen („Split Brain“) zu gelangen, wird ein ZFS-Metrocluster wie folgt implementiert:

1. Bei undefinierten Zuständen wird nicht auf Verdacht ein automatisches Umschalten zwischen den Sites ausgeführt. Services bleiben zuerst dort, wo sie bisher liefen, online. Ein Manuelles eingreifen des Administrators ist mit einem Mausklick natürlich möglich.
2. Volume Service Lockung sorgt dafür, dass bei einem einfachen Netzwerkausfall zwischen den Sites dieser auch nur als Netzwerkausfall erkannt wird.
3. Ein Cloud Bacon Repeater sorgt dafür, dass die beiden Standorte gegenseitig den „Herzschlag“ des anderen hören und über dessen Zustand informiert sind.
4. End-to-End-Prüfsummen über den gesamten Datenbestand hinweg sorgen dafür, dass fehlerhafte Daten automatisch gefunden und mittels der Parität repariert werden können. 
5. Das Copy-on-write-Verfahren sorgt dafür, dass beim Schreiben neue Daten nicht den alten Daten-Block überschreiben. Stattdessen wird ein neuer Block zugewiesen und die Metadaten als Referenz des Originals ändern sich, um auf den neuen Block zu verweisen. Auf diese Weise sind Daten in ZFS stets konsistent.

Metrocluster bieten viele Vorteile

Hochverfügbare Rechenzentren sind heute das Rückgrat zahlreicher Unternehmen und sie investieren hohe Summen in ihre Geschäftstätigkeit. Für alle Unternehmen, die ohnehin zwei Standorte innerhalb von 50 Kilometer Umkreis besitzen oder die Ressourcen in einem von Dienstleistern betriebenen Rechenzentrum in Anspruch nehmen können, ist ein Metrocluster eine geeignete Methode, ihre Systeme unter allen Umständen zugänglich und aktiv zu halten.

von Heiko Wüst, Sales Engineer bei Nexenta Systems

www.nexenta.com