Kontinuierliche Verfügbarkeit im RZ-Verbund

Softwarebasierende Site-Replikation

23. Februar 2015, 7:00 Uhr | Bas Raayman, Senior Systems Engineer bei Nutanix, www.nutanix.com./jos

Heute übliche Service-Level-Vereinbarungen zwingen die RZ-Betreiber in allen Bereichen zu extremen Sicherungs- und Stabilisierungsmaßnahmen. Der traditionelle Ansatz dafür ist die Bildung von Redundanzen auf jeder einzelnen Hardwareebene. Dennoch führen Ausfälle in der Infrastruktur, Naturkatastrophen und nicht selten auch ganz reguläre Wartungsarbeiten immer wieder zu Ausfallzeiten, für die kürzlich eine Ponemon-Studie Kosten von durchschnittlich 690.000 Dollar pro Fall errechnet hat.

International agierende Firmen, die ihre Dienstleistungen rund um die Uhr und an 365 Tagen im Jahr zuverlässig erbringen müssen, haben im Wettbewerb heute nur eine Chance, wenn sie ihre Rechenzentren auf bestmögliche Verfügbarkeit (ergibt sich aus dem Verhältnis von Ausfallzeit zu Gesamtzeit) getrimmt haben. Als Nachweis dafür dient auf globaler Ebene oft die Klassifizierung gemäß dem amerikanischen Uptime Institute, die die Verfügbarkeit von Rechenzentren in vier Stufen (Tiers) gliedert.
Haben die Vermeidung von Datenverlust und Downtimes höchste Priorität, müssen Daten und Dienste an anderer Stelle synchron mitlaufen. Spätestens bei dieser Site-übergreifenden Redundanz stoßen Hardwarekonzepte an ihre Grenzen.
Auf allen Tiers liegt die jährliche Verfügbarkeit über 99,96 Prozent, aber die wenigen Hundertstel Prozent Unterschied zwischen den Stufen (von Tier 1: 99,671 - entsprechend maximal 28,8 Stunden Ausfallzeit/Jahr - bis Tier 4: 99,991 (maximal 0,8 Stunden Ausfallzeit/Jahr) erfordern gravierende Unterschiede in Aufbau und Struktur der entsprechenden Rechenzentren. Dies betrifft Dinge wie Redundanz der IT-Infrastruktur, Verkabelung und WAN-Verbindung, unterbrechungsfreie Stromversorgung (USV), Brandschutz und einiges mehr.
In der Praxis reden inzwischen auch Versicherungen mit, wenn es um die IT-Verfügbarkeitsmaßnahmen bei ihren Klienten geht. Einige verlangen beispielsweise, dass die USVs alle vier Jahre umfassend getestet werden. Eine solche "Wartung" bedeutet jedoch eine eingeschränkte Sicherung der Stromversorgung für die Zeit des Tests. In Europa ist die Informationstechnik meist auf Grundlage der ISO-15408-Norm zertifiziert, die organisatorischen Abläufe im Sicherheits-Management nach ISO/IEC 27001/27002 und ISO 20000. Dafür gibt es auch entsprechende Zertifikate, die unterschiedliche Prüfstellen nach umfassendem Check erteilen und anschließend immer wieder kontrollieren. Der deutsche Industrieverband Bitkom sieht hier beispielsweise den TSI-Prüfkatalog des TÜVs als mit am meisten genutzte Zertifizierungsstelle. Das BSI (Bundesamt für Sicherheit in der Informationstechnik) hat insgesamt sechs Verfügbarkeitsklassen (VK-0 bis VK-5) definiert. Basis sind dabei die IT-Grundschutzkataloge sowie das Hochverfügbarkeitskompendium. Besonders interessant ist hier die Verfügbarkeitsklasse 5 - der Verfügbarkeitswert liegt hier bei 100 Prozent.
Es gibt viele Maßnahmen, die ein Rechenzentrum sicher machen. Vollständige Ausfallsicherheit ist jedoch selbst mit den aufwändigsten Vorkehrungen letztlich eine Illusion, denn wenn Naturkatastrophen oder Anschläge ganze Gebäude fluten oder zerstören, läuft eben nichts mehr. Eine Verfügbarkeit von annähernd 100 Prozent ist daher nur möglich, wenn auch die Zerstörung eines gesamten Rechenzentrums nicht zu Datenverlust und Downtime führt. Das BSI nennt das "desastertolerant". Voraussetzung für diese Eigenschaft ist, dass an anderer Stelle ein weiteres Rechenzentrum betrieben wird, das den Betrieb der "Gegenstelle" redundant mitführt.
 
Synchrone Replikation
Damit der Betrieb dort ohne Ausfallzeiten weiterlaufen kann, müssen alle Daten aller Anwendungen parallel in beiden Lokationen vorliegen. Die gängige Methode, um Daten gewissermaßen in Echtzeit von einem auf einen anderen Standort zu spiegeln, nennt sich synchrone Replikation. Ein Speichervorgang gilt dabei erst als abgeschlossen, wenn beide Standorte den erfolgreichen Abschluss des Speichervorgangs bestätigt haben. Auf diese Weise lässt sich sicherstellen, dass die Daten des einen Rechenzentrums sofort auch am Spiegelrechenzentrum verfügbar sind. Einige Applikationen (beispielsweise Datenbanken) und Dienste (etwa MS Exchange) unterstützen die synchrone Replikation bereits nativ ab Quelle. Das Gros der in Unternehmen üblichen Apps und Services kommt jedoch ohne eine solche Funktion. Dann muss die Infrastruktur den Job übernehmen.
Der bei den gängigen Lösungen der einschlägigen Anbieter übliche Ansatz stützt sich im Wesentlichen auf eine bestimmte Hardware. So werden oft auf beiden Seiten die gleichen zertifizierten Switches verlangt. Die Speicher- und Server-Systeme müssen ebenfalls in der Regel an beiden Standorten identisch sein. Wenn nach mehreren Jahren auf einer Seite eine Komponente ihren Dienst quittiert, ist sie beim Hersteller eventuell schon nicht mehr verfügbar. Der Anwender ist gezwungen, für beide Seiten neue Komponenten nachzukaufen - entsprechender Installations- und Konfigurationsaufwand inklusive. Das Gleiche gilt auch, wenn aufgrund einer Modernisierungsmaßnahme bestimmte Geräte durch neuere Modelle ersetzt werden sollen. Die Bandbreite für die Verbindung zwischen den Rechenzentren ist durch die Netzwerkgeräte fix vorgegeben.
Ein großes Problem gerade in Zeiten zunehmender Virtualisierung ist, dass solche Lösungen oft nur unidirektional funktionieren. Die Richtung der Spiegelung ist bei der Implementierung festgelegt, eine Änderung der Richtung ist mit erheblichem Aufwand verbunden. Dies führt zu massiven Einschränkungen, wenn es um den Umzug virtueller Maschinen (VMs) geht.
Die Bereitstellung von hardwarebasierenden Replikationslösungen für Site-übergreifende Redundanz gilt daher als sehr komplex, teuer und unzureichend. Hersteller modernerer Prägung kommen inzwischen mit ersten Lösungen, die sich von der Hardware abkoppeln. Das Versprechen ist ein großes Plus bei Einfachheit und Flexibilität. So erfordert die Einrichtung keinerlei zusätzliche Hardware und die Netzwerkregeln sind flexibel. Der entscheidende Vorteil in jüngsten Lösungen liegt jedoch sicher darin, dass sich im Normalbetrieb auf beiden Seiten Lese- und Schreiboperationen ausführen lassen. Ein Shared Namespace sorgt im Hintergrund für konsistente Datencontainer auf beiden Seiten. Und da Daten in beide Richtungen replizierbar sind, gibt es auch bei der freien Verschiebung von VMs keine Hindernisse.
Die Verantwortung für eine adäquate Netzwerkverbindung liegt bei den Nutzern - immerhin sind die Bandbreiten ebenso wie die genutzten Geräte nicht fest vorgegeben. Großes Rationalisierungspotenzial gibt es beim Management der synchronen Replikation. Wo hardwarebasierende Lösungen nach Installation der eben zusätzlich nötigen Hardware oft noch tagelange Folgeaktionen erfordern, versprechen Anbieter softwarebasierender Lösungen Setup, Failover und Failback in wenigen Klicks und Management über ein einfaches Gesamt-Interface.
 
Fazit
Niemand kann garantieren, dass RZs nicht durch natürliche oder menschengemachte Ereignisse zerstört werden können. Aber die Garantie, dass selbst solche drastischen Ereignisse nicht zu Datenverlust und Downtime führen, lässt sich über softwarebasierende Replikation vergleichsweise einfach realisieren.

Nach einem Netzwerkausfall zwischen zwei Sites sind die Datencontainer nicht synchron. Kommt die Verbindung wieder hoch, genügt ein Knopfdruck, um die Synchronisation wiederherzustellen. Quelle: Nutanix

Fällt ein komplettes Rechenzentrum aus, erkennt das System dies automatisch, und alle I/O-Vorgänge pausieren. Das Peering muss manuell abgebrochen werden. Danach starten die I/Os aller VMs im Spiegel-RZ neu. Nachdem der Spiegel-Datencontainer (blau) angemeldet ist (manuell), erfolgt ein Neustart der VMs auf dem Spiegel-Cluster. Quelle: Nutanix

Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Cognizant

Weitere Artikel zu SEIDENADER VISION GmbH

Matchmaker+