Metro-Cluster über mehrere Standorte

Absicherung kompletter Rechenzentren

27. Juni 2013, 6:00 Uhr | Heiko Wüst, Sales Engineer bei Nexenta Systems./pf

Phänomene wie Tsunamis, starke Erdbeben, Vulkanausbrüche oder extreme Überschwemmungen sind hierzulande zwar selten, aber auch bei uns gibt es jenseits von Großbränden, Leitungsschäden und Stromausfällen Szenarien, die ein komplettes Rechenzentrum außer Betrieb setzen können. Damit IT-Systeme auch unter extremen Umständen einsatzfähig bleiben, setzen Unternehmen auf so genannte Metro- oder Stretched Cluster zwischen zwei oder mehreren Standorten, um ganze Rechenzentren hochverfügbar auszulegen.Hochverfügbarkeit war schon immer eine Angelegenheit der Redundanz, und dies gilt auch für extreme Fälle, wenn es darum geht, ein ganzes Rechenzentrum vor einem Stromausfall oder einer Katastrophe zu schützen. Fällt ein RZ aus, schaltet ein Metro-Cluster automatisch auf ein zweites, oder gar drittes um - komplett ohne Ausfallzeit. Nimmt man es genau, ist dies nichts anderes als ein auf zwei oder drei Standorte auseinandergezogenes lokales Cluster mit einem lokal gespiegelten Speicher. Das Konzept eines Metro-Clusters 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. Letztere spiegeln jeweils ihre Daten zwischen den beiden Standorten und alle vier Nodes gehören zu einem standortübergreifenden 4-Node-Cluster. Der Metro-Cluster kann derart gestaltet sein, dass kein einziger "Point of Failure" übrig bleibt. Damit macht ein Hardwareausfall, gleichgültig auf welcher Ebene, noch kein Umschalten zwischen den Standorten notwendig. Der große Nutzen besteht darin, dass das Umschalten bei einem Problem vollkommen transparent geschieht - also komplett ohne das Eingreifen eines Administrators. Würde nur asynchrone Replikation eingesetzt, müsste immer noch ein Mensch entscheiden, ob und wann die Umschaltung erfolgt. Dies würde mitunter erhebliche Verzögerungen nach sich ziehen. Außerdem müsste ein Notfallplan vorhanden sein, der festlegt, wann und wie umzuschalten ist. Die Automatisierung dieses Prozesses garantiert hingegen eine durchgängige Uptime für sämtliche Applikationen. Ein Metro-Cluster bietet neben dem Schutz der Unternehmensdaten einen weiteren Pluspunkt: Metro-Cluster benötigen Ausfallzeiten weder für Upgrades der Hardware noch der Software. Sie sind zudem erstaunlich einfach in der Implementierung und bei der Verwaltung. Um einen Metro-Cluster aufzubauen müssen sich die Leitungen zwischen den Standorten allerdings durch eine sehr niedrige Latenz auszeichnen. Höhere Latenzzeiten beeinträchtigen die Leistung des Gesamtsystems. Daher sollte die Entfernungen der RZ-Standorte rund 50 Kilometer nicht überschreiten, da mit zunehmender Entfernung auch die Latenzzeiten steigen. Metro-Cluster eignen sich also besonders für Unternehmen, die entweder über einen größeren Campus verfügen oder über Niederlassungen innerhalb eines Radius von zirka 50 Kilometer. In den USA etwa ist dieses Konzept daher relativ unbekannt, weil die Unternehmensstandorte im Allgemeinen weiter entfernt sind und ein Metro-Cluster nicht infrage kommt. Liegen Niederlassungen jedoch nah beieinander, können viele Unternehmen mit geringen Investitionen die Verfügbarkeit ihrer Systeme auf ein bislang selten erreichtes Niveau heben.   Szenarien eines Systemausfalls Jeder Cluster bietet zahlreiche Schwachstellen, die das System lahmlegen können. Ziel eines Metro-Clusters ist es, für jeden dieser Schwachpunkte eine automatische Rückfalllösungen bereitzustellen, um Auswirkungen auf Applikationen zu vermeiden. Die folgenden sieben Ausfallszenarios und ihre Folgen sind am Beispiel eines Metro-Clusters aufbauend auf der ZFS-Dateisystemtechnik von Sun dargestellt, wie sie zum Beispiel die Lösung Nexentastor von Nexenta Systems nutzt. 1. 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 lassen sich anschließend automatisch wieder synchronisieren. 2. Ausfall wichtiger Komponenten in den Disk Shelves: Fällt ein SAS-Kabel (Serial Attached SCSI) eines SAS-HBAs (Host Bus Adapter) oder -Expanders aus, sorgt das Multi-Pathing der Storage Nodes beim Ausfall eines Kabels dafür, dass alle Services ohne Unterbrechung online bleiben. Auch in dieser Situation ersetzt der Administrator die Teile im laufenden Betrieb. 3. Ausfall eines ganzen Disk Shelves: Die RAID-Z2-Festplattenverbünde lassen sich so zwischen den JBODs (Just a Bunch of Disks) verteilen, dass auch ein kompletter JBOD-Ausfall zu verkraften ist. Geht JBOD nach einem Ausfall wieder online, so werden nur die bis dahin veränderten Daten synchronisiert. Alle Services bleiben damit 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 die Service-Nodes im oberen Bereich durchaus bemerken, 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 lässt sich durch Multi-Pathing der Service-Nodes bewältigen. Ein Failover auf das andere Rechenzentrum ist nicht notwendig und der Endanwender spürt keinerlei Beeinträchtigung der Applikationsleistung. 6. 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 an die Applikationen. Die Umschaltzeit ist abhängig von der Anzahl der Services wie NFS-Shares, CIFS-Shares oder iSCSI-Targets. Sie ist dagegen unabhängig von der Datenmenge. Es stellt dabei eine der Besonderheiten der ZFS-Technik im Gegensatz zu anderen Datei- und Speichersystemen dar, dass diese nie einen kompletten "File System Check" durchführen muss. Für die Applikations-Server ist diese Umschaltung transparent, im Fall von Fibre Channel müssen die Applikations-Server vom Betriebssystem einen ALUA-fähigen (Asymetric Logical Unit Access) Multi-Pathing-Treiber mitbringen, was heutzutage oft Standard ist. Der Cluster ist dabei 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 Metro-Cluster die Redundanz des Rechenzentrums für ein Failover, und der zweite Standort übernimmt alle Services. Den Anwendungs-Servern stehen somit alle Dienste zur Verfügung, wenn auch nur auf der Hälfte der Service-Nodes - also mit eingeschränkter Performance. Da in diesem Fall allerdings auch das Spiegeln, Lesen und Schreiben zwischen den Standorten entfällt, verbessert sich die Latenz, was zum Beispiel bei Datenbanken sogar zu besserer Performance führen kann. Geht der ausgefallene Standort wieder online, ist es dank ZFS nicht nötig, den kompletten Datenbestand zurückzuspielen. Nur das Delta, also die geänderten Daten, ist an das zwischenzeitlich ausgefallene Standortsystem zurückzuübermitteln, sodass das Rechenzentrum sehr schnell wieder produktiv gehen kann, wenn die lokalen Probleme gelöst sind.

Schematischer Aufbau eines Metro-Clusters über zwei Standorte hinweg.
LANline.

Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Lacie

Weitere Artikel zu Cognizant

Matchmaker+