Lebensversicherung für Rechenzentren

Der Autor ist Sales Engineer bei Nexenta Systems, Experte für Unix, Linux und Open Source und besitzt langjährige Erfahrung im Netzwerk-, Storage- und Virtualisierungsumfeld. Redundanz ist der Schlüssel zur Hochverfügbarkeit, das gilt auch für Rechenzentren. Ein Metrocluster ist ein auf zwei oder mehr Standorte aus­-
einander gezogenes lokales Cluster, bei dem ein lokal gespiegelter Speicher zum Einsatz kommt. Es kann so gestaltet werden, dass kein einziger Point of Failure bestehen bleibt. Der grösste Vorteil 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. Die Automatisierung dieses Prozesses garantiert dagegen eine durchgängige Uptime. 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. Die Vorteile: - Keine Ausfallzeiten wegen Upgrades, weder für Hardware noch Software - Einfacher Aufbau und einfache Verwaltung - Vollkommener Schutz aller unternehmens­kritischen Daten - Automatisches und manuelles Failover Lesen Sie auf der nächsten Seite: Die Voraussetzungen

Um einen Metrocluster aufzubauen, sollten zwei Bedingungen erfüllt sein: Erstens müssen sich die Leitungen zwischen den Rechenzentren durch eine sehr niedrige Latenz auszeichnen. Zweitens sollten die Entfernungen rund 50 Kilometer nicht überschreiten, da durch die Entfernung auch die Latenzzeiten steigen und 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. Das Konzept ist dort daher kaum bekannt. Die Idee orientiert sich an europäischen Gegebenheiten, wo Unternehmen oft mehrere Niederlassungen und Rechenzentren unterhalten, die nur wenige Kilometer von­einander entfernt sind. Mit relativ geringen
Investitionen lässt sich hier die Verfügbarkeit des Clusters auf ein sehr hohes Niveau heben.

Cluster haben zahlreiche Schwachstellen. Ziel eines Metroclusters ist es, für jeden Schwachpunkt automatische Rückfalllösungen bereitzustellen, um Folgen für die Applikationen zu vermeiden oder diese zumindest stark einzuschränken. Im Folgenden werden sieben Ausfallszenarien und ihre Folgen am Beispiel eines Metroclusters (basierend auf ZFS-Technologie) dargestellt: 1. 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. 2. Ausfall wichtiger Komponenten in den Disk Shelves: Das Multipathing 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. 3. 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. 4. 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, was 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. Lesen Sie auf der nächsten Seite: Weitere Szenarien 5. Ausfall eines Switches, Kabels oder Fibre Channel HBAs zwischen Storage Nodes und den oberen Service Nodes: Auch dieses Szenario wird durch Multipathing der Service Nodes bewältigt. Ein Failover auf das andere Rechenzentrum ist nicht notwendig und die Performance der Applikationen wird nicht merklich beeinträchtigt. 6. 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 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. 7. 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 ausgefallene Standort wieder online, wird niemals der komplette Datenbestand zurückgespielt, sondern nur alle bisher dahin geänderten Daten. Lesen Sie auf der nächsten Seite: Vermeidung eines «Split Brains»

Um bei einem einfachen Ausfall der Verbindungen zwischen den Rechenzentren nicht zu undefinierten Zuständen (Split Brain) zu ge­langen, wird ein ZFS-Metrocluster wie folgt implementiert: - 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. - Volume Service Locking sorgt dafür, dass bei einem einfachen Netzwerkausfall zwischen den Sites dieser auch nur als Netzwerkausfall erkannt wird. - Ein Cloud Beacon Repeater sorgt dafür, dass die beiden Standorte gegenseitig den «Herzschlag» des anderen hören und über dessen Zustand informiert sind. - 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. - Das Copy-on-write-Verfahren sorgt dafür, dass beim Schreiben die neuen Daten nicht den alten Datenblock ü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.

Hochverfügbare Rechenzentren sind heute das Rückgrat zahlreicher Unternehmen, die mitunter hohe Summen in ihre Geschäftstätigkeit investieren. Für alle Unternehmen, die ohnehin zwei Standorte innerhalb von 50 Kilometern 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.