Sicherung und Hochverfügbarkeit von Rechenzentren

Naturkatastrophen wie Tsunamis, Erdbeben oder Vulkanausbrüche sind hierzulande zwar selten, aber auch hier gibt es jenseits von Großbränden, Leitungsschäden und Stromausfällen Szenarien, die ein komplettes Rechenzentrum außer Betrieb setzen können. Fällt ein solches aus, kann das IT-System automatisch auf ein zweites oder gar drittes Rechenzentrum umschalten – komplett ohne Ausfallzeit.

Hochverfügbarkeit war schon immer eine Sache der Redundanz. Das gilt auch, wenn es darum geht, ein ganzes Rechenzentrum vor einem Stromausfall oder einer Katastrophe zu schützen. Nimmt man es genau, ist ein Metrocluster nichts anderes als ein auf zwei oder drei Standorte auseinandergezogenes lokales Cluster mit einem lokal gespiegelten Speicher. Das Konzept eines Metroclusters besteht pro Standort aus einem Storage-Layer, der jeweils lokal hochverfügbar ausgelegt ist, also 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.

Kein einziger Point of Failure

Ein Metrocluster kann derart gestaltet sein, dass kein einziger Point of Failure übrigbleibt. Damit macht ein Hardware-Ausfall kein Umschalten zwischen den Standorten notwendig. Der Vorteil besteht darin, dass das Umschalten im Ernstfall vollkommen transparent geschieht. Würde nur asynchrone Replikation eingesetzt, müsste immer noch ein Mensch entscheiden, ob und wann umgeschaltet wird. Die Automatisierung dieses Prozesses garantiert dagegen eine durchgängige Uptime für sämtliche Applikationen. Um einen Metrocluster aufzubauen, müssen sich die Leitungen zwischen den Standorten durch eine niedrige Latenz auszeichnen.

Höhere Latenzzeiten beeinträchtigen die Leistung des Gesamtsystems, daher sollte die Entfernung eines Metroclusters rund 50 Kilometer nicht überschreiten. Geeignet sind diese also für Unternehmen, die entweder einen größeren Campus oder Niederlassungen haben, die nah beieinander liegen. So kann man mit geringen Investitionen die Verfügbarkeit der Systeme auf ein höheres Niveau heben.

Ausfallszenarien und wie ein Metrocluster sie löst

Jeder Cluster hat zahlreiche Schwachstellen, die das System lahmlegen können. Ziel eines Metroclusters ist, für jeden dieser Schwachpunkte eine automatische Rückfall-Lösung bereitzustellen. Die folgenden sieben Ausfallszenarios und ihre Folgen werden am Beispiel eines Metroclusters aufbauend auf ZFS-Technologie dargestellt:
Ausfall einer Festplatte: Der Ausfall einer Festplatte hat für den operativen Betrieb keinerlei Folgen. Ein Administrator kann die Platte im laufenden Betrieb austauschen. Die Daten werden anschließend automatisch synchronisiert.
Ausfall wichtiger Komponenten in den Disk-Shelves: Fällt ein SAS-Kabel eines SAS-HBAs oder Expanders aus, sorgt das Multi-Pathing der Storage-Nodes dafür, dass alle Services ohne Unterbrechung online bleiben. Teile werden im laufenden Betrieb ersetzt.
Ausfall eines ganzen Disk-Shelves: Die Verteilung der RAIDZ2-Festplattenverbünde werden so zwischen den JBODs verteilt, dass auch ein kompletter JBOD-Ausfall verkraftet wird. Geht dieser nach einem Ausfall wieder online, so müssen nur die bis dahin veränderten Daten synchronisiert werden.
Ausfall eines Storage-Nodes: Beim Ausfall eines kompletten Servers der Storage-Nodes übernimmt ein zweiter Server am selben Standort die Aufgaben innerhalb weniger Sekunden.
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.
Ausfall eines Service-Nodes: Bei einem kompletten Ausfall eines Service-Nodes kommt es bei der Nutzung von ZFS zu einer kurzen, wenige Sekunden dauernden Unterbrechung des I/O-Stroms. Die Umschaltzeit ist abhängig von der Anzahl der Services, jedoch unabhängig von der Datenmenge.
Ausfall eines kompletten Standorts: Erst im Fall eines kompletten Standortausfalls 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. Geht der ausgefallenen Standort wieder online, ist es dank ZFS nicht nötig, den kompletten Datenbestand zurückzuspielen. Nur das Delta, also die geänderten Daten, werden an den zwischenzeitlich ausgefallenen Standort zurückübermittelt.

Quelle: Nexenta Systems

Bildquelle: Thinkstock/Fuse