Endlich echtes Always-On in allen Situationen für NetApp MetroCluster!

02:30 Uhr irgendwo in Deutschland

Das Handy klingelt. Wer ruft um diese Zeit an? Eine englische Stimme mit sehr freundlichem aber leider schwer verständlichem indischem Akzent. Was will der Kerl von mir…? Site Desaster?

Auf einmal bin ich hellwach. Unser zentrales Storage-System steht! Ich checke meine eMails. Stimmt! Um 02:13 Uhr kam die Meldung der überlebenden Seite. Was stand nochmal im Desaster Plan, den wir bei der Abnahme durchgespielt haben? Analysieren, Isolieren und dann der forcetakeover, aber was war dieses Isolieren nochmal schnell?

Mist, hätten wir das bloß ein paar mal trocken geübt!

Ist die andere Seite wirklich weg und alles aus oder ist nur der Interconnect unterbrochen? Zu beiden RZs brauche ich mindestens 1 Stunde und bis ich rein darf vergeht locker nochmal eine weitere Stunde. Wie lange dürfen die Dienste maximal down sein? 30 Minuten, danach wird es richtig teuer für die Firma.

Soll ich einfach mal auf Verdacht den forcetakeover machen? Lieber nicht! Dateninkonsitenz droht, aber was wenn ich Morgen dann den Anpfiff bekomme… weil ich eben nichts unternommen habe und die Services länger down waren als erlaubt.

Schon mal wirklich erlebt oder bisher nur davon geträumt?

Damit Sie zukünftig gut schlafen können, möchten wir Sie auf eine praktikable Lösung aufmerksam machen, welche es seit kurzem auf dem Markt gibt und wir für Sie getestet haben: dem ClusterLion!

Wie es technisch im Detail funktioniert und worauf man achten sollte

Viele unserer Kunden setzen auf einen NetApp MetroCluster der durch die Verteilung auf zwei Standorte und die synchrone Spiegelung aller Daten auf Block-Basis grundsätzlich beste Voraussetzungen für einen transparenten Failover bietet, aber leider nicht in allen Situationen.

Die folgende Tabelle stellt dar in welchen Fällen ein automatischer und damit transparenter Failover ohne weitere Hilfsmittel wie z.B. ClusterLion möglich ist und wo noch Optimierungsbedarf besteht:

Gerade die letzten beiden Situationen erforden ein händisches Eingreifen des Administrators, da ein 7-Mode MetroCluster hier nicht selbst zwischen einem Ausfall und dem Split-Brain-Zustand unterscheiden kann. Beim Split-Brain-Zustand handelt es sich um einen ungewollten Zustand, der sich durch die vollständige Trennung der beiden Standorte ergibt, z.B. durch die meist befürchtete Baggerschaufel die alle RZ-Querverbindungen kappt.

Ein clustered ONTAP MetroCluster ist in dieser Betrachtung noch anfälliger als ein 7-Mode MetroCluster, da die eigentliche Hochverfügbarkeitsfunktionalität nur am lokalen Standort gegeben ist. Ein Schwenk an den anderen Standort ist hauptsächlich für den DR-Fall vorgesehen und findet daher nur nach einem manuellen Eingriff des Administrators statt.

Zur Sicherung der Datenkonsistenz muss vor dem Ausführen eines DR-Takeover grundsätzlich durch den Administrator geprüft werden, dass die vermeintlich ausgefallene Seite wirklich keine Daten mehr ausliefert (Analyse) und nicht mehr ausliefern wird (Isolation, z.B. durch physikalisches Abschalten des betroffenen Controllers). Andernfalls ist die Storage-Identität sowohl am isolierten Standort als auch am intakten Standort aktiv und es werden die Daten unabhängig voneinander an beiden Standorten verändert.

Mit dem ClusterLion stellt die Firma ProLion aus Österreich jedoch eine einfache Ergänzung für die oben genannten Situationen zur Verfügung. Beim ClusterLion handelt es sich um eine Ergänzung zu Ihrem NetApp MetroCluster (7-Mode und clustered Data ONTAP) die durchgehend den aktuellen Status der einzelnen Storage-Controller, die Interconnect-Verbindungen sowie die Stromversorgung überwacht. Jeder ClusterLion erfüllt zusätzlich noch die Funktion einer unterbrechungsfreien Stromversorgung um jederzeit einen transparenten Failover durch die NVRAM-Spiegelung zu ermöglichen. Im Falle eines Failovers kann zudem durch die Trennung der Storage-Controller von der Stromversorgung sichergestellt werden, dass die Storage-Identität jederzeit nur an einem Standort aktiv ist.

Die Verbindung der beiden Standorte kann dabei wahlweise über Kupferkabel erfolgen (ClusterLion, max. 100m) oder über eine UMTS-Verbindung (ClusterLion Advanced Protection). Bei der Nutzung der „kleinen Variante“ müssen die ClusterLion-Querverkabelungen natürlich über andere Leitungswege als die bereits vorhandenen ISL-Verbindungen des Storage-Systemes erfolgen um eine Verbesserung des aktuellen Zustandes zu erreichen. Andernfalls würde der oben beschriebene Bagger schlimmstenfalls auch den ClusterLion in eine Spli-Brain-Situation befördern.

Die UMTS-Variante als „große Lösung“ nutzt zwei redundante UMTS-Gateways pro Standort und garantiert dabei durch die Nutzung zweier verschiedener Telekom-Provider eine höchstmögliche Verfügbarkeit der Verbindung zum Remote-Quorum. Das Remote-Quorum ermöglicht durch die permanente Abfrage der beiden ClusterLion jederzeit eine Unterscheidung zwischen einem Ausfall-Szenario und dem Split-Brain-Zustand. Somit kann der Administrator auch in der anfangs beschriebenen Situation beruhigt sein, da der ClusterLion innerhalb weniger Augenblicke die sichere Unterscheidung zwischen Isolation und Ausfall ermöglicht und im zweiten Fall durch einen automatischen Failover jegliche Downtime vermeidet.

Egal ob es Ihnen um den ruhigen Schlaf Ihrer Mitarbeiter geht oder „nur“ die Storage-Downtime vermieden werden soll, eine Nachrüstung des ClusterLion an vorhandenen MetroCluster Installationen ist jederzeit und unterbrechungsfrei möglich. Somit können auch Bestandssysteme ohne großen Aufwand aufgewertet werden.

Bernd Löhlein

Bernd Löhlein ist seit Ende 2010 für die Firma Proact Deutschland aktiv. Sein Fokus liegt hauptsächlich auf NetApp Hard- und Software, die angrenzenden Themen Virtualisierung und Netzwerk sind für Ihn dabei auch kein Neuland. Neben den üblichen Consulting-Einsätzen ist er auch noch als Trainer im NetApp Umfeld aktiv.