Metrocluster – Lebensversicherung für das Rechenzentrum

Anbieter zum Thema

Szenarien eines Systemausfall

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

1. Ausfall einer Festplatte

Fällt eine Festplatte aus, hat das 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 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.

3. Ausfall eines ganzen Disk-Shelves

Die 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.

5. 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.

6. Ausfall eines Service Nodes

Bei einem kompletten Ausfall 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-Technik 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.

(ID:37117360)

Absicherung kompletter Rechenzentren