Verfügbarkeit bei Hardwareausfall - Einrichtung einer Failover-Lösung mittels Snapshots

[PROLOG]

Nachdem ich mein Failover im vorherigen Artikel via Sync-Job eingerichtet habe, möchte ich dies nun nochmal mit meiner zweiten Vorstellung, der Verwendung von Snapshots, wiederholen um für mich herauszufinden, welche Lösung ich zukünftig verwende. Eigentlich bin ich von der Einrichtung und meinen theoretischen Vorstellungen, wie es in der Praxis läuft schon ganz zufrieden mit dem Zwischenergebnis des „Sync-Failover“, aber wer weiß was mir die Verwendung von Snapshots versüßen.

Einige Punkte werden sich hier mit der vorherigen Variante decken. Um nicht alles zu wiederholen versuche ich so gut es möglich ist auf den vorherigen Artikel aufzubauen und übereinstimmende Punkte nur kurz anzureissen.

[DIE EINRICHTUNG]

Ich habe mich bei dieser Variante für ein TS-453A/8G entschieden, auf dem ich bereits das Snapshot Vault verwende. Dennoch werde ich das Anlegen von Snapshots im Vault nochmals durchführen, die Beschreibung dazu aber kurz halten.

Da ich mich für dieses Unterfangen schon mit Snapshots beschäftigt habe weiß ich, dass die Einrichtung bereits mit einem Scheidepunkt beginnt: Müssen die Freigaben wieder manuell übernommen werden oder nicht? Das hängt davon ab, wie man die Snapshots später beim Failover-Betrieb verwendet. Kurz gesagt: Man könnte a) die Snapshots dann klonen und als Volume einbinden oder b) Daten / Verzeichnisse aus den Snapshots in den Freigaben wiederherstellen.

Die Möglichkeit b) spricht mich zunächst überhaupt nicht an… alle Verzeichnisse beim Wechsel auf das Failover manuell wiederherstellen… zu kompliziert! Es wird also für Möglichkeit a) eingerichtet.

1. Volume und Freigaben vorbereiten (Failover-System)

Für den Empfang von Snapshots benötigen wir einen Speicherpool mit ausreichender Kapazität für die Abbilder des Haupt-Systems *. Die Erstellung von Volumes ist nicht erforderlich, da Snapshots direkt im Speicherpool gelagert und geklont (als Volume erstellt) werden. Lediglich für das System, also die Nutzung von Apps habe ich ein kleines 40GB Volume angelegt. Das ist dann auch schon der Punkt, der Snapshots so verführerisch macht: Die Freigaben werden beim Klonen der Snapshots automatisch erstellt, sodass ich mir an dieser Stelle die manuelle Übernahme der Freigaben sparen kann und auch bei Änderungen nichts im Blick behalten muss.

Da ich meine originalen Daten beim Testen unangetastet lassen will und das nur durch ein separates Volume sichergestellt ist, erstelle ich mir ein Testvolume, ausnahmsweise mal thick-provisioned.

* Vorab angemerkt: „ausreichende Kapazität“ entspricht hier mindestens der doppelten, auf dem Hauptsystem zugewiesenen und zu berücksichtigenden Kapazität! Entscheidend ist hier auch, ob mit Thin- oder Thick-Volumes gearbeitet wird. Eigentlich ein ganz anderes Thema, ich möchte es spätestens im Praxistest dennoch kurz anreißen.

2. User vorbereiten (Failover-System)

Diesen Step kann ich mir leider nicht ersparen, er erfolgt analog zu der Variante mit Sync-Jobs.

3. Snapshots einrichten (Haupt-System)

Da die Einrichtung und Verwendung von Snapshots schon einen eigenen Artikel wert ist, will ich es an dieser Stelle kurz machen:

Das Haupt-System muss über einen Speicherpool und Thin-/ oder Thick-Volumes verfügen auf denen die Freigaben liegen, damit die Verwendung von Snapshots möglich ist. Bei mir ist das der Fall, ich arbeite mit Thin-Volumes, was mir später noch zum Vorteil wird. Über den Schnappschussmanager wird das Erstellen von Snapshots nach Zeitplan aktiviert.

Hierbei entscheidet die Aufnahmefrequenz darüber, wie aktuell die Daten im Failover sein werden. Je häufiger Snapshots aufgenommen werden, desto aktueller werden die Daten im Failover sein. Die Anzahl der beibehaltenen Snapshots ist hier irrelevant, ich stelle sie für mein Testvolume auf 1, selbstredend, dass nur für Volumes die im Failover relevant sind Snapshots benötigt werden.

Den ersten Snapshot nehme ich auch direkt manuell auf.

4. Snapshot Replica einrichten (Haupt-System)

Bevor es am Haupt-System weitergeht, muss SSH auf dem Failover-System aktiviert werden um Snapshots empfangen zu können. Ich wähle hier auch gleich einen anderen Port als 22.

Zurück am Haupt-System geht es ins Snapshot Replica. Hier wird wieder für alle im Failover relevanten Volumes ein Replikationsauftrag erstellt, so dass das Replika immer dann startet, wenn ein lokaler Snapshot erstellt wurde. Für das Failover ist es ausreichend, wenn auch hier nur jeweils ein Snapshot beibehalten wird. Auch selbstredend: Das Failover-System muss betriebsbreit sein, wenn es Snapshots empfangen soll.

Erstes Zwischenfazit:

Die Einrichtung von Snapshots und Replika ist etwas aufwändig, auch wird das nicht von jedem System unterstützt. Immerhin konnte ich mir die manuelle Übernahme der Freigaben sparen, was besonders bei vielen Freigaben erfreulich ist. Zumindest bis zu diesem Punkt...

5. Optional weitere Dienste aktivieren (Failover-System)

Dieser Punkt ist ebenfalls deckungsgleich mit der anderen Variante.

6. Failover-Konfig erstellen (optional) und kurzer Funktionstest (Failover-System)

Auch hier ist nahezu alles deckungsgleich mit der anderen Variante, der Fokus liegt auf IP und Hostname.
Kleiner Unterschied: An diesem Punkt sind noch keinerlei Daten „nutzbar“ auf dem Failover-System vorhanden, diese mache ich erst im nächsten Kapitel verfügbar.

[WECHSEL ZUM FAILOVER-BETRIEB]

Für einen kurzen Augenblick ändert sich noch nichts gegenüber der Sync-Variante, wenn das Failover-System den Dienst übernehmen muss:

IP, Hostname und Dienste müssen vom Haupt-System übernommen und gestartet werden. Bei der Sync-Variante war das schon alles, bei der Snapshot-Variante liegen aber immer noch keine Daten vor, mit denen gearbeitet werden kann. Um die Daten bereit zu stellen, muss nun zu „Speicher/ Snapshots“ gewechselt werden. Hier finden wir neben eventuellen Volumes auch sämtliche Snapshots, die vom Haupt-System empfangen wurden. Jeder einzelne Snapshot (die neueste Aufnahme) muss hier nun manuell gewählt und geklont werden. Dabei wird ein Volume mit sämtlichen Daten und Freigaben im Speicherpool erstellt, der Name des neuen Volumes ist egal.

Erfreulicherweise werden dabei auch direkt die Freigaben in der Freigabeverwaltung aufgeführt. Schöner kann es gar nicht sein… denkste! Denn jetzt kommt wieder der hässliche Teil: die Vergabe der Benutzerrechte. Das passiert ebenfalls analog zu der Sync-Variante und bedeutet denselben Aufwand, unglücklicherweise aber genau jetzt wo es schnell gehen muss. Dennoch geht das bei meinen paar Usern wieder recht schnell von der Hand, die Einsatzbereitschaft des Systems wird aber trotzdem etwas verzögert. Alternativ dazu gäbe es noch die Variante, die ich bereits zu Beginn für mich ausgeschlossen hatte: Freigaben und Berechtigungen im Vorfeld anlegen und im Ernstfall die Daten aus den Snapshots manuell in den entsprechenden Freigaben wiederherstellen. Welches Verfahren an dieser Stelle schneller erledigt ist, ist abhängig von Anzahl der User und Freigaben die wiederhergestellt werden müssen. Mein Bauchgefühl sagt mir für meinen Fall, dass dies schon die schnellere Variante war.

[FAILBACK - AUF DAS (NEUE) HAUPT-SYSTEM „ZURÜCK“ WECHSELN]

Der Ablauf ist wieder weitestgehend identisch mit der Sync-Variante, lediglich das Vorgehen der Datenwiederherstellung unterscheidet sich... sofern man möchte…

Für mich beginnt hier kurzzeitig der totale Verlust des Überblicks über Möglichkeiten und Funktionen. Eigentlich wollte ich mit Snapshots arbeiten, aber wie bekomme ich die Volumes auf dem Failover-System, mit denen zuletzt gearbeitet wurde, mittels Snapshots in mein Hauptsystem? Von den Volumes auf dem Failover-System gibt es noch gar keine Snapshots! Dazu müsste ich jetzt wohl das Snapshot-Replica umgekehrt einrichten: Snapshots auf dem Failover-System erstellen und diese per Replika auf das Haupt-System bringen, um dann die Daten in den Freigaben oder eben direkt auf den Volumes wiederherzustellen?! Das wäre alles andere als schnell erledigt und „schnell“ ist eines der Hauptkriterien die ein Failover und Failback erfüllen sollte. Ein bisschen enttäuscht wende ich mich ab von dem Gedanken, das Failback ebenfalls über Snapshots laufen zu lassen, denn das benötigt neben Zeit auch noch zusätzliche Kapazität!

An dieser Stelle muss ich mich dann wohl wieder eines Sync-Jobs bedienen, der dann genau so aussieht wie in der zuvor beschriebenen Variante. Im Anschluss könnten dann die aus den Snapshots erstellen Volumes auf dem Failover-System gelöscht werden, damit es für das nächste Mal direkt einsatzbereit ist.

Letztes Zwischenfazit vor dem Praxistest:

Komplett bei der Verwendung von Snapshots kann man nicht bleiben, wenn Zeit eine Rolle bei dem Failback spielt. Ohnehin erfordert die Verwendung von Snapshots zwei entsprechend leistungsfähige Systeme, die auch noch entsprechend mit Speicherpools eingerichtet sein müssen. Bereits hier macht sich deutlich, dass diese Variante nur dann sinnvoll ist, wenn ohnehin mit Snapshots und Replika gearbeitet wird. Nicht zu vernachlässigen ist hier auch der enorme Kapazitätsbedarf, den ich vorhin nur angemerkt hatte.

Ein kleiner Ausflug zu Snapshots und Volumes:

Auch wenn Snapshot, Speicherpool sowie Thin- und Thick-provisioning ein jeweils eigenes Thema darstellen möchte ich kurz darauf eingehen, was es für den Einsatz in diesem Failover-Szenario bedeutet.

Ein lokaler Snapshot erfordert - je nach enthaltenen Änderungen - nicht sonderlich viel Kapazität im Speicherpool. Ein mittels Replika ausgelagerter initialer Snapshot im Vault eines anderen Systems benötigt abhängig von der Provisionierung deutlich mehr Kapazität:

• Bei einem Snapshot eines Thin-Volume wird hier die Kapazität benötigt, die dem Volume zugewiesen ist. Das entspricht etwas mehr als der durch Daten belegten Kapazität. Bei einem 1TB Volume kann die durch ein Snapshot-Replika benötigte Kapazität also auch 500GB entsprechen, wenn nicht mehr Daten auf dem Volume liegen.
• Bei einem Snapshot eines Thick-Volume hingegen wird unweigerlich die Gesamtkapazität des Volumes belegt. Ein Volume von 1TB schluckt beim Snapshot-Replika also auch 1TB, unabhängig davon, wie viele Daten darauf liegen.

Da mit diesen Daten im Failover aber zunächst nicht gearbeitet werden kann, musste von den Snapshots ein Klon in Form eines Volumes in einem Speicherpool erstellt werden, was eben nochmal die entsprechend belegte Kapazität des Snapshots erfordert. Bei Thin-Volumes wird auf dem Failover-System demnach mindestens die doppelte zugewiesene Gesamtkapazität aller Volumes benötigt, bei Thick-Volumes sogar die doppelte Gesamtkapazität aller Volumes.

Dies würde sich dann auch direkt bei dem Failback mittels Snapshots bemerkbar machen:

Da es erforderlich zu sein scheint, zunächst Snapshots von den Volumes auf dem Failover-System zu erstellen und per Replika auf das Haupt-System zu senden, würde auch hier für die Wiederherstellung die entsprechend doppelte Kapazität erforderlich sein, sofern man die eventuell noch bestehenden Volumes nicht zuvor komplett leer macht.

Ein teurer Spaß also, der gegenüber der Sync-Variante nicht einmal Vorteile zu bieten scheint. Ich bin mir relativ sicher, dass das nicht meine „best practice“ wird. Ich habe nicht einmal mehr Lust die Praxis dieser Variante zu testen, zumal ich selbst mit meinem "Kapazitäts-Vorteil" durch Thin-Volumes bereits an meine Kapazitätsgrenzen gelange. Ohne die Aufrüstung von Festplatten ließe sich das also ohnehin nicht in die Realität überführen. Ich sehe aktuell auch keinen anderen adäquaten Weg um da noch etwas zu optimieren.

Im nächsten Artikel werde ich nun also die Praxis des „Sync-Failover“ dokumentieren, dies sollte eigentlich als Vergleich mit der eben beschriebenen Snapshot-Variante erfolgen, von der nach aktuellem Stand ungewiss bleibt, ob ich diese überhaupt testen werde. Für meinen vorerst letzten Urlaubstag hatte ich mir ein schickeres Ergebnis erhofft.
Naja, gehört dazu wenn man was ausprobiert.

Glücklicherweise ist es gleich schon 1400 Uhr... Cheers!