Wer viel mit NetApp draußen im Feld unterwegs ist und den ein oder anderen Fabric attached cDOT MetroCluster (FMC) gebaut hat sieht sich mit den immer selbern Fragen der Kunden konfrontiert.
Kunde: „Was passiert wenn ein Diskshelf ausfällt?“
Ihr: „Nichts, Daten kommen aus dem Remote Shelf“Kunde: „Was passiert wenn die Verbindungen zwischen den RZs gekappt werden?“
Ihr: „Nichts, die Sites liefern weiter ihre Daten nur der Spiegel ist gebrochen“
Und so weiter… und sofort…
Kurz um. Der NetApp Fabric attached MetroCluster ist einfach scheinbar unverwüstlich. Fast!
Ja der NetApp FMC macht einen transparenten Failover, wenn ihr ihm das sagt. Ja er kann den transparenten FailOver auch alleine Versuchen. Es kommt hier auf die Umstände an.
Hat gerade eine Boing 747 den Landeanflug auf euer Rechenzentrum beendet und von einer Seite des FMC sind nur noch pulverisierte Partikel übrig, dann macht der MetroCluster *trommelwirbel* nichts! Na gut vielleicht plärrt euch die „überlebende“ Seite mit Alarmmeldungen voll. „Remote Plex nicht sichtbar, Remote Controller weg, etc.“
Eine Umschaltung passiert hier an dieser Stelle nicht. Der Admin ist nun gefragt, in Seelenruhe einen Switchover zu befehlen, damit die überlebende Seite die „tote“ Seite übernimmt. Doofe Sache was ? Es gibt natürlich Lösungen für das Dilemma.
Möglichkeiten für den automatischen transparenten Failover im Desaster Fall:
- Ihr beschäftigt eine Armee von Admins bei denen eine arme Sau 24 Stunden den Finger auf dem Switchover Knopf hat. (Kostet zu viel und der schläft irgendwann auch mal ein)
- Ihr setzt auf den NetApp TieBreaker. Wasn das?
- Der TieBreaker ist eine dritte Instanz an einer dritten Lokation, welche die ganze Zeit per LAN beide MetroCluster Seiten sehen muss/sollte.
- Verliert der TieBreaker die LAN Connection zu beiden Seiten kann er den MetroCluster nicht mehr schützen
- Verliert er die Verbindung zu einer Seite des MetroClusters, geht er davon aus, dass dort eine Katastrophe passiert ist und startet den Switchover.
- War einfach nur die Verbindung weg und die andere Seite kommt wieder hoch, ist das echt Käse.
- Ihr nehmt Cluster Lion für NetApp
Puhhh. Lange Rede kurzer Sinn. Heute möchte ich euch ein Bisschen über Cluster Lion für NetApp erzählen.
Ich persönlich hatte die Thematik lange Zeit nicht auf dem Schirm. Bin aber durch eine Veranstaltung wieder darauf gestoßen worden.
Was macht Cluster Lion nun eigentlich anders als der TieBreaker und vor was schützt er meinen MetroCluster?
Cluster Lion ist erstmal ein Stück Hardware, welches an jeder Seite eures MetroCluster mit aufgebaut wird. Im ersten Schritt wird die Stromversorgung eurer FMC Controller nicht direkt an den Strom angeschlossen, sondern durch die Cluster Lion Appliance „geschliffen“. Das Durchschleifen des Stroms passiert dabei durch ein Industrie Relay. Keine Sicherung, keine Backplane. Einfach nur ein Industrie Relay. Warum machen wir das denn? Damit der Cluster Lion als erster mitbekommt, wenn es einen Stromausfall gibt. Und nein der ist dann selbst nicht „tot“ weil er eingebaute Batterien hat.
Das machen wir natürlich auf beiden Seiten. Danach wird die Cluster Lion Appliance auf einen Netzwerkport eurer FAS Controller verbunden, damit der Cluster Lion auch mit den Controllern interagieren kann. Das Besondere dabei ist, dass hier die NetApp Mandantenfähigkeit genutzt wird und der Cluster Lion Netzwerkport quasi ein eigener Mandant ist, welcher keinerlei Möglichkeit hat in die anderen Netzwerke einzugreifen. Stichwort IPSpaces und BroadCast Domains.
Um aber noch ein Stückchen sicherer zu sein, verwendet der Cluster Lion spezielle Netzwerkkabel. Diese Netzwerkkabel haben nur zwei Adern. RX/TX. Es ist also nur Kommunikation in eine Richtung möglich.
So nun haben wir zwei Stück Hardware unter jedem unserer MetroCluster Seiten. Und jetzt ?
Joar jetzt sag ich euch, dass der Cluster Lion auf jeder Seite noch zwei 3G Module inklusive SIM-Karten verbaut hat. Diese können, wenn im Serverraum kein 3G Empfang ist, bis zu 100m weiter gepatched werden. Wichtig!!! Gepatched, nicht geswitched, da die 3G Module von der Cluster Lion Appliance per PoE versorgt werden.
Und ab jetzt wirds geil:
Der Zeuge, eure Quorum, euer Witness, nennt es wie ihr wollt, liegt in der Cloud (Kann aber auch in einem dritten RZ von euch sein). Die 3G Module „unterhalten“ sich ständig über zwei verschiedene Telekommuniktionsanbieter in einer Telefonkonferenz (Keine Angst keine Telefonkostenexplosion). Der Chef der Telko ist dabei quasi ein Dienst von Cluster Lion in der Cloud. Dieser Clouddienst dient daher als „Zeuge“ oder Quorum.
Habt ihr nun ein Desaster in einem eurer Rechenzentren, so funkt die Quorum, aus der Cloud, der überlebenden Cluster Lion Appliance, dass sie da mal bitte gucken soll, was da los ist. Die überlebende Appliance prüft dann, ob die FMC Controller der Meinung sind, dass die Gegenseite weg ist. Wird dies von den Controllern mit JA beantwortet, so initiert die Cluster Lion ein Switchover. 
Der gesamte Prozess von Landung der Boing 747 in eurem RZ bis zum Switchover passiert binnen 30 Sekunden. Ich bleibe euch noch einige Details schuldig, wenn ihr danach fragt 😉
So viel erstmal zu Cluster Lion. Ihr erreicht die Jungs unter www.clusterlion.at oder über Twitter
Appendix:
Ja ich weiß, dass das ganze Thema etwas komplexer ist und ich hier viele Verallgemeinerungen benutzt habe. Ich blogge hier und schreibe kein Buch. Wobei ich doch denke, dass das Thema MetroCluster irgendwer mal als Doktorarbeit nutzen wird.
Habt ihr was Beizutragen? Nutzt die Kommentarfunktion!
Sehr guter Artikel. Danke