Szenarien von Systemausfällen

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 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, das heißt 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.