FlashArray: Things You shouldn't do - ActiveCluster: DNS, Gateway placement
Aktualisiert: 9. Mai 2021
Um den einwandfreien Betrieb des ActiveClusters sicherzustellen, gilt es besonderem Augenmerk den hierfür nötigten Diensten zu schenken. Eine Verfügbarkeit von z. B. DNS-Services ist jederzeit sicherzustellen. Eine Abhängigkeit ist bei den folgenden zwei Szenarien auf jeden Fall gegeben:
Verwendung des Cloud-Mediatores oder Nutzung weiterer Pure1 Features.
Einsatz eines On-Premise-Mediatores mit der Anbindung über den DNS-Hostname.
Was macht eigentlich der Mediator?
Der Mediator ist eine Komponente des ActiveClusters, der sich in einer von beiden Peer-FlashArrays unabhängigen Fehlerdomäne (failure domain) befindet. Die Anforderungen an den Mediator sind bescheiden - er reagiert auf Heartbeats der Peers (FlashArrays) und akzeptiert oder lehnt deren Kontaktanfragen ab, wenn sie ihre Verbindungen untereinander verlieren. Der Mediator bestimmt, welches FlashArray den Pod bei Verbindungsausfall online halten soll.
Das sogenannte "Split Brain" ist bei Cluster-Systemen bekannt. Wenn zwei Systeme, die Informationen austauschen/koordinieren, nicht miteinander kommunizieren können, kann keines von beiden feststellen, was das andere tut, sodass eine Koordination unmöglich ist. Das Problem ist besonders bei der synchronen Replikation fatal, da dessen Zweck es ist, die Volumes auf beiden Arrays identisch zu halten. Beim ActiveCluster werden Aktualisierungen innerhalb sogenannter Pod-Volumes synchronisiert, dies erfordert, dass die Peer-Arrays bei jedem Schreibvorgang miteinander interagieren. Wenn beide FlashArrays Host-Befehle empfangen, die innerhalb eines Pod-Volumes geschrieben werden, aber nicht miteinander kommunizieren können, muss jedes für sich entscheiden, ob es die Befehle ausführt oder ablehnt. Um das Problem mit dem Split-Brain zu lösen, verwendet ActiveCluster einen Mediator.
Das erste Array, welches den Mediator erreicht, bleibt online; spätere Anfragen des anderen FlashArrays werden abgelehnt. Somit verliert das andere Array "das Rennen" (Pure Storage bezeichnet dies auch als Mediator Race), d. h. es antwortet nicht mehr auf IOs, die an Pod-Volumes gerichtet sind (lokale Volumes oder Volumes in anderen Pods sind davon nicht betroffen). Im Gegensatz zu anderen Lösungen der Wettbewerber ist der ActiveCluster Mediator passiv: im Regelbetrieb - während die ActiveCluster-Arrays Verbindung besteht - ist seine einzige Aufgabe auf Heart-Beats zu antworten, die sicherstellen, dass die Peers mit dem Mediator kommunizieren können. Wenn ActiveCluster Peers versuchen, den Mediator zu kontaktieren, akzeptiert er die erste Anfrage und lehnt die zweite ab, ansonsten kommuniziert diese Instanz nicht mit den FlashArrays *.
Es gibt viele Deployment-Szenarien und es ist abzuwägen, welches für Sie/Ihr Unternehmen am besten passend. Nutzen Sie den On-Premise oder den Cloud-Mediator? Können Sie im Fehlerfall auf Pure1 Features verzichten? ... dies sollte bei der Einrichtung evaluiert und definiert werden.
Je nach Unternehmensgröße findet man verschiedenste Systemstrukturen vor, welche unzählige Optionen bieten, aber auch oft statisch und wenig flexible Infrastrukturen. Ich möchte aufzeigen, was Sie auf keinen Fall konfigurieren sollten. Das ActiveCluster Setup ist bekannterweise einfach in wenigen Minuten erledigt, doch haben Sie auch alle Abhängigkeiten gedacht?:
Gateway/Router (Cloud-Mediator)
DNS-Server
Proxy-Server
Zum Thema Gateway nur ganz kurz: sollten Sie keinen redundanten Internet-Break-Out haben, "könnte" dies im Fehlerfall ebenfalls Ihr gesamtes HA-Konstrukt in Gefahr bringen. Pure hat durch kontinuierliche Systemverbesserung auch hier einen Weg gefunden - später hierzu mehr.
Der Pure1 Cloud-Mediator
Ich erstellte eine Visualisierung zweier Setups, welche im Fehlerfall (vor Purity 5.3) zum Stillstand des Clusters führten. Eine Umgebung mit nur einem Gateway und eine mit redundanten Gateways. In beiden Fällen wird der Cloud-Mediator eingesetzt. Wir nehmen in den nachfolgenden Fallbeispielen einen Ausfall der Replikationsverbindung in einem Uniform ActiveCluster an.
Es kommt nun zum sogenannten "Mediator-Race": beide FlashArrays versuchen den Cloud-Mediator zu erreichen. Dieser Vorgang wird jedoch scheitern, da durch Verschiebungen (oder auch beim Setup) der VMs die hinterlegten DNS-Server sich innerhalb eines Pods befinden, welche temporär "eingefroren" sind und keine DNS-Anfragen bearbeiten können.
Ebenfalls ist dies bei eingesetzten Proxys (falls in Purity konfiguriert) zu beachten, welche Pod-Volumes nutzen. Eine kleine Unachtsamkeit, welche uns im Fehlerfall einen Cluster komplett "außer Gefecht" setzen können *.
Um das Problem bei der Namensauflösung zu vermeiden, kann man ganz einfach vorgehen. Wir müssen dafür sorgen, dass die DNS-Dienste in einem Speicherbereich liegen, welcher dennoch redundant, jedoch unabhängig der Pods ist.
Hierzu legt man sich auf beiden FlashArrays non-Pod (Standalone) Volumes an, da diese wie beschrieben immer verfügbar sind und keine Abhängigkeit zum ActiveCluster haben. Die erstellten Volumes mappt man an die lokalen (auch RZ-übergreifendes Mapping an Server optional möglich) Server. Das optionale Mapping sehe ich jedoch als nicht zwingend erforderlich an, da DNS-Server sich applikationsseitig replizieren, kann jedoch bei z. B. Rechenzentrumsabschaltungen (geplante Verlagerungs-/Migrationsszenarien) von Vorteil sein.
Sollte ein übergreifendes Mapping einrichtet sein, sorge ich mit den on-board Mitteln von VMware (VM/Host-Gruppen/Regeln) dafür, dass die DNS-VMs immer auf den lokalen Hosts ausgeführt werden.
Daraus ergeben sich nachfolgende Visualisierungen:
Wie bereits geschrieben, können nun DNS-Anfragen jederzeit erfolgreich aufgelöst werden, da die virtuellen Maschinen außerhalb des temporär eingefrorenen Pod-Volumes "POD" liegen.
HINWEIS: wir sprechen beim "eingefrorenen" Zustand von wenigen Sekunden, was die Anwendung in der Regel (je nach Latenz zum Mediator) nicht einmal bemerkt.
Im Beispiel gewinnt FlashArray "PURE-1" das "Rennen" und der Zugriff auf das "POD::VOL1" wird über die verfügbaren Pfade am FlashArray des Datacenter 1 aktiviert. Systeme (physische Server, VMs) werden - ohne Eingriffe - aus dem DC1 versorgt, bis der Regelzustand wiederhergestellt wurde.
Der On-Premise-Mediator
Sollte ein Quorum On-Premise genutzt werden, so sind die DNS-Abhängigkeiten nicht so entscheidend, vorausgesetzt: man spricht den Mediator nicht über DNS an. Sollte dies doch der Fall sein, muss man ebenfalls die DNS-Server außerhalb des Pods platzieren. Ich rate im Generellen immer zu letzterem, da man so immer alle Pure1 Features (proaktiven Support etc.) nutzen kann!
Prüfung der Einstellungen
Sollten Sie DNS-Einstellungen prüfen, oder auch ändern, dann können Sie dies unter den Netzwerkeinstellungen (Settings > Network) der FlashArrays. Man sollte Änderungen jedoch beim Support zumindest vorab mitteilen, da anderenfalls proaktiv Tickets erstellt werden könnten (sollte ein Heartbeat während Änderung nicht möglich sein - Interval alle 5min/default).
Es können bis zu drei DNS-Server (Purity 6.0.4) hinterlegt werden. Sollte man über ein drittes Rechenzentrum verfügen, rate ich pro RZ einen DNS-Server anzugeben, um so maximale DNS-Verfügbarkeit zu schaffen.
Der eingesetzte Mediator ist für jeden Pod definierbar, wobei "purestorage" immer für den Cloud-Mediator steht. Mit der Option "Failover Preference" ist es zusätzlich möglich einem FlashArray beim "Mediator Race" einen Vorsprung (head start) zu geben - in der Regel macht diese Option nur bei nicht-redundanten Gateways Sinn. Hier sollte dann das FlashArray am nähesten zum Gateway die Preference sein.
(*) Pre-Election Feature
Dieses Feature ist im Default mit Purity 5.3 verfügbar/aktiv (erfordert keine Aktivierung/Always-On) und stellt sicher, dass die Pod-Volumes bei einer verlorenen Mediatorverbindung beider FlashArrays und zusätzlichem Ausfall der Replikationsverbindung auf jeden Fall online bleiben.
Was macht Pre-Election?
Nachdem die FlashArrays erkennen, dass der Mediator nicht verfügbar ist, wird eine Vorauswahl (= pre-elect) getroffen:
sicherstellen, dass das vorausgewählte Array im Pod online bleibt, wenn das Replikationsnetzwerk bzw. das NICHT gewählte Array ausfällt.
das ausgewählte Array den Pod-Failover-Präferenzen entspricht, falls nicht konfiguriert -> Pre-Election wie oben beschrieben.
Nachdem das/die FlashArrays über eine erneute Mediatorverbindung verfügen zum Regelbetrieb des ActiveClusters zurückzukehren.
Das Feature ersetzt den Einsatz eines Mediators fürs Generelle nicht! Pre-Election greift nicht, wenn die Mediator- & Replikationsverbindung gleichzeitig ausfallen. Die Pre-Election muss im Heart-Beat Intervall ausgeführt worden sein.
HINWEIS: es ist wichtig zu wissen, sollte das Pre-Election Feature einmal greifen, so wird dies auch erst wieder deaktiviert, wenn das pre-elected FlashArray wieder eine Verbindung zum Peer hat und der Mediator erreichbar ist.
Denkbare Ausfallszenarien
Es gibt eine gute Übersicht verschiedenster Ausfallszenarien von ActiveClusters Komponenten. Ich muss sagen...mit den zusätzlich verfügbaren Features ist es schon extrem unwahrscheinlich die Vefügbarkeit der Volumes nicht aufrecht zu erhalten - insofern immer die ActiveCluster-Basics beachtet werden!
Ich verweise an dieser Stelle ebenfalls auf den offiziellen "ActiveCluster Planning and Design Guide" im Pure Technical Services Portal. Ebenfalls finden Sie hier die Dokumentation für eine erfolgreiche Pure1 Mediator-Verbindung "FlashArray Port Assignments".
Weitere Infos - Links
Sämtliche offiziell veröffentlichten Einstellungsmöglichkeiten in der GUI, aber auch CLI können über die "on-board" User Guides der Pure Storage Systeme nachgelesen werden.
Im Purity Hauptmenü hierzu auf "Help" klicken.
Der User Guide ist wie das Hauptmenü gegliedert und kann von Ebene zu Ebene geöffnet werden. Eine Suchfunktion ist auch integriert - hier kann mit Schlagworten gesucht werden.
WEB: Pure Storage (Pure1) Supportportal - Ticketsystem und Unterstützung *(erfordert registrierte FlashSysteme)
TEL: Pure Storage Telefonsupport: GER - (+49) (0)800 7239467; INTERNATIONAL - (+1) 650 7294088
WEB: Pure Storage OFFICIAL Blog