[PROLOG]
Nach meinen Überlegungen zur Einrichtung eines Failover mit QNAP in meinem vorherigen Artikel, soll es in diesem Artikel nun darum gehen, ein System mittels Sync-Job entsprechend einzurichten. Die Möglichkeit der Einrichtung mittels Snapshots folgt in einem weiteren Artikel.
Ich habe mich bei der Sync-Variante für ein TS-131P entschieden.
Diese Variante erscheint mir am sympathischsten, da die Einrichtung und der Wechsel zum Failover leicht von der Hand gehen werden, außerdem bestünde die Möglichkeit die Daten stets per active Sync aktuell zu halten. Dass Snapshots ohnehin nicht von jedem System unterstützt werden und zudem die Performance beeinträchtigen ist ein anderes Thema…
Stolze 6 Seiten sind es im Nachfolgenden geworden. Das klingt nach viel Aufwand, aber vermutlich nur weil ich viele Worte verwendet habe, denn so aufwändig war es gar nicht!
[DIE EINRICHTUNG]
Die TS-131P steht eigentlich an einem anderen Ort und ist nur über VPN erreichbar, für den Versuch habe ich das Gerät mit nach Hause genommen und es über das LAN eingerichtet.
Dem NAS gebe ich einen eindeutigen Hostnamen, der bei mir zwangsläufig „Failover“ enthält. Außerdem bekommt das Gerät - bei mir selbstverständlich - eine feste IP Adresse, was zwar optional, aber empfehlenswert ist. Sync-Jobs auf das Gerät sind zwar bereits eingerichtet, aber unbrauchbar für den vorgesehenen Zweck. Warum sehen wir später, ich erstelle im Verlauf also neue Jobs.
1. Volume und Freigaben vorbereiten (Failover-System)
Zunächst bedarf es eines Volumes mit ausreichender Kapazität, damit sämtliche benötigten Daten Platz finden. Backups von anderen Geräten, welche möglicherweise auf dem Haupt-System liegen würde ich zum Beispiel gar nicht für das Failover berücksichtigen um Platz und demnach Kosten zu sparen, aber das ist meine persönliche Entscheidung: Ich brauche diese Daten im Failover-Betrieb einfach nicht. Hoffe ich zumindest.
Nachdem ein Volume erstellt wurde geht es mit den Freigabeordnern weiter. Natürlich können zuvor auch mehrere Volumes erstellt werden, das spielt keine Rolle, Hauptsache die Größe passt zu den Freigaben, die darauf landen und gesynct werden sollen.
Die Freigabeordner müssen nun manuell vom Haupt-System übernommen werden, auf welchem Volume diese liegen ist egal. Die Freigabeverwaltung von beiden NAS parallel geöffnet erstelle ich nach und nach jede einzelne Freigabe, so wie sie auch am Haupt-System heißt und übernehme auch gleich etwaige Optionen. Die Berechtigungen (außer eventuelle Gastzugriffsrechte) lasse ich erstmal links liegen. Außerdem übernehme ich nur jene Freigaben, die im Failover für mich von Bedeutung sind.
Bei meinen 6 Freigaben ging das recht flott von der Hand. Sollte später mal eine zu berücksichtigende Freigabe dazukommen, so muss diese parallel auch auf dem Failover-System erstellt werden.
2. User vorbereiten (Failover-System)
In der Userverwaltung des Haupt-Systems exportiere ich die User via Erstellen > importieren/ exportieren und importiere sie analog auf dem Failover-System. Damit sind nur die User per se und ihre Passwörter importiert. Es werden leider weder Berechtigungen, noch weitere Einstellungen wie Kommentare oder Gültigkeiten übernommen, allerdings hatte ich einiges gar nicht erst gesetzt, möglicherweise wird hier doch etwas mehr übernommen als ich feststellen kann. Benutzergruppen werden übrigens auch übernommen. So müssen nun also unter Umständen noch etwaige Optionen der User angepasst werden.
Jetzt kommt der Punkt, der mir der größte Dorn im Auge ist: Die manuelle Vergabe der Berechtigungen. Glücklicherweise ist dies nur bei der Ersteinrichtung und falls mal User dazukommen der Fall. Hier gilt natürlich auch: Nur diejenigen anpassen, die im Failover von Bedeutung sind. Solche die nicht interessieren kann man direkt löschen oder so belassen, sie haben bis auf Leserechte im Standardordner „public“ nämlich keine Rechte.
Auch das geht bei meinen 5 relevanten Usern recht schnell, der Admin ist ohnehin schon vorhanden, 4 irrelevante User habe ich direkt wieder gelöscht.
Nachträglich, wo ich schon mit allem durch bin stellt sich mir die Frage was wäre, wenn ich die Konfig meines Haupt-Systems sichere und auf dem Failover-System wiederherstelle... könnte da was gehen? Das werde ich später nochmal separat ausprobieren.
Erstes Zwischenfazit:
Bei wenigen Usern und Freigaben ist das noch kein großer Aufwand, wenn auch dennoch alles einem Workaround gleicht und im ersten Moment abschreckend wirkt. Die weitere Pflege bei relevanten Änderungen darf aber nicht aus den Augen verloren werden, sollte jedoch unproblematisch sein, wenn nicht massenweise Änderungen auf einen Schlag auftreten. Auch die Passwörter sind auf jetzigem Stand; sollten User ihr Passwort zwischenzeitlich ändern und ein Zugriff im Failover-Betrieb dadurch nicht möglich sein, muss lediglich ein neues Passwort vergeben werden. Unwahrscheinlich dass dies bei mir eintritt, aber wenn, dann ist das auch kein Problem… seit QTS 4.5.1 gibt es außerdem die Möglichkeit dass User ihr Passwort via Mail zurücksetzen können, was natürlich weiterer Konfiguration unter Punkt 4 bedarf.
3. Sync-Jobs erstellen (Haupt-System)
Auch hier werde ich nicht alles schrittweise bis ins kleinste Detail durchkauen; es beginnt mit der Einrichtung von HBS (hier HBS3) auf dem Failover-System als Server für den Empfang von Sync-Jobs.
Ich nehme wie üblich RTRR, hämmere ein Passwort rein und lasse den Rest wie voreingestellt.
Weiter auf dem Haupt-System, wird das Failover-System in HBS3 als Speicherplatz angelegt.
Im Anschluss werden die Sync-Jobs als One-Way erstellt. Ein einzelner Job wäre ausreichend, da es entsprechend konfigurierbar ist, ich persönlich ziehe es aber vor mehrere Sync-Jobs anzulegen, nämlich jeweils einer für eine Freigabe. Dadurch habe ich für mich einen besseren Überblick, außerdem sind nicht alle Daten betroffen wenn ein Sync-Job mal fehlschlägt.
Wichtig hierbei ist, dass bei der Quelle die jeweils gesamte Freigabe ausgewählt wird und beim Ziel ebenfalls direkt die entsprechende Freigabe, sonst passt später die Ordnerstruktur nicht mehr wenn wir in den Failover-Betrieb gehen. Das war dann übrigens auch der Grund weshalb ich die Sync-Jobs neu anlegen musste und die alten nicht verwenden konnte: Die Ordnerstruktur entsprach nicht dem Haupt-System, sodass etwaige Programme ihre Dateien nicht finden oder angelegte Verknüpfungen auf die Freigaben nicht funktionieren würden.
An dieser Stelle auch gleich angemerkt, warum es ein Sync-Job sein muss und kein Backup-Job: Bei einem Backup-Job werden die Daten in entsprechende Unterordner gesteckt, die dem Jobnamen und Datum entsprechen, ergo würde die Ordnerstruktur nicht stimmen.
Da ich mein Failover-System nicht ständig in Betrieb haben will, erstelle ich einen Zeitplan so, dass einmal täglich ein Sync erfolgt. Wichtig: Das Failover-System muss zu diesem Zeitpunkt eingeschaltet und betriebsfähig sein, was ich über das geplante Ein- und Ausschalten sicherstelle. An diesem Punkt bin ich mir gar nicht sicher, ob man die Jobs nicht auch auf dem Failover-System erstellen kann, damit sich das System die Daten holt, wenn es eingeschaltet ist. Wenn möglich wäre das die scharmantere Lösung, die ich zukünftig auch umsetzen wollte... naja...
Um die Daten stets aktuell zu haben, kann man hier natürlich einen aktiven Sync erstellen, das Failover-System muss dazu allerdings 24/7 laufen, was ich vermeiden will.
Optionen für den Job setze ich nicht großartig, außer dass zusätzliche Dateien im Zielordner entfernt werden, ich will ja 1:1 die Daten wie auf dem Hauptsystem. Fertig.
Die Jobs können jetzt manuell gestartet werden oder später automatisch durchrödeln, ich würde es jetzt machen und das System in Ruhe arbeiten lassen, denn ich finde dass an dieser Stelle das erste Bier verdient ist. 
Zweites Zwischenfazit:
Der Aufwand ist nahezu lächerlich, man muss sich nur entscheiden wie aktuell die Daten, die auf dem Failover zur Verfügung gestellt werden, sein sollen und welchen Preis man dafür in Kauf nimmt. Mir reicht die tägliche Sync, außerdem findet diese um 12h zeitversetzt zu meinem normalen (internen) Backup statt, sodass ich dort -je nachdem wann das Failover aktiv werden muss - aktuellere Daten finden kann. Ohne aktiven Sync-Job ist es so natürlich nicht möglich, einen Ausfall während der Arbeit abzufangen, vorausgesetzt die Arbeit wurde überhaupt mal zwischendurch gespeichert => ich liebe meinen immerwährenden STRG+S Tick 
.
4. Optional weitere Dienste einrichten (Failover-System)
Dieser Step ist viel zu individuell um näher darauf einzugehen. Wie oben schon erwähnt kann es hilfreich sein einen SMTP Server zu konfigurieren, damit das Passwort per Mail zurückgesetzt werden kann, sofern das QTS auf dem Failover-System dies unterstützt. Für mich steht fest: Ich möchte nicht, dass der DLNA Server während des regulären Betriebs läuft, also deaktiviere ich ihn nach der Ersteinrichtung. Auch ist ein Zugriff via SMB im Normalbetrieb nicht von Nöten, demnach wird auch dieser nach der Einrichtung deaktiviert. Ich würde alle Dienste nur soweit möglich vorkonfigurieren, aber abgeschaltet lassen.
Wenn das Gerät nicht ständig laufen soll und ein Sync per Zeitplan erstellt wurde, sollte spätestens jetzt daran gedacht werden, dass das System automatisch ein- und ausgeschaltet werden muss, und vor allem auch betriebsfähig ist, wenn es Daten empfangen soll.
Lustig: gerade lese ich einen Beitrag im Forum über pfSense auf dem QNAP… für jemanden der sowas am Laufen hat dürfte ein Failover noch interessanter werden, damit bei Ausfall des QNAP wenigstens noch Zugriff aufs Internet besteht. Mir ist jedenfalls noch keine FW-Appliance abgeraucht, natürlich habe ich trotzdem eine zweite eingerichtet als Ersatz stehen… und fühle mich nun ein bisschen wie ein Nerd 
Die Frage mit dem Backup
An dieser Stelle stellt sich natürlich auch die Frage, wie das mit Backups im Failover-Betrieb ist, und ob man bei der Einrichtung weiterer Dienste auch ein automatisches Backup einrichten sollte, so wie es zumindest bei mir am Haupt-System der Fall ist. Mir schießt dazu direkt folgendes in den Sinn: Wenn an einem KFZ das primäre Bremssystem versagt, kann auf ein sekundäres Bremssystem aka „Handbremse“ oder „Feststellbremse“ zurückgegriffen werden. Und wie ist das sekundäre System gesichert, falls es ausfällt? Gar nicht... je nach Fahrzeug bleibt dann eventuell die „Flinstones-Methode“ .
Ich jedenfalls werde zunächst kein „Backup vom Backup“ machen und damit den doppelten Fehlerfall absichern, kann aber nachvollziehen, wenn der ein oder andere den Wunsch danach hat, schließlich kann der Failover-Betrieb auch mehrere Wochen andauern. Ganz abgeschoben habe ich diesen Gedanken auch noch nicht, mir fehlt es lediglich an Kapazität am Backup-System. Fest steht für mich: das Failover wird in keiner Weise in die „originalen“ Backups des Haupt-Systems reingrätschen. Sollte ich Speicherplatz im Backup-System nachrüsten, dann würde ich separate Backup-Jobs für den Failover-Betrieb anlegen. Eine Kostenfrage, mehr nicht.
5. Failover-Konfig erstellen (optional) und kurzer Funktionstest
Bis hierhin ist ein System erstellt, welches lediglich für den Einsatz als Failover vorbereitet wurde. Im Ernstfall muss dieses System aber das Haupt-System ersetzen. Wesentlich verantwortlich für viele Anwendungen sind dafür die IP sowie der Hostname. Wer die Ruhe hat, kann diesen Step einfach überspringen und die Konfiguration dann vornehmen, wenn der Ernstfall eintritt. Ich möchte das aber nicht, denn ich will ja schnellstmöglich ein betriebsfähiges Failover haben, wenn es schon nicht „just in time“ möglich ist.
Um Konflikte innerhalb meines Netzwerks zu vermeiden, fahre ich das Haupt-System herunter oder isoliere es vom Netzwerk indem ich die LAN Verbindung trenne. Damit ist der Ernstfall auch gleich simuliert: Mein Haupt-System ist nicht mehr verfügbar.
Mein Failover-System nennt sich aktuell aber auch noch genauso in seinem Hostnamen und auch die IP ist für alles, was irgendwo auf den Clients eingerichtet ist, nicht korrekt. Als erstes ändere ich also die IP des Failover-Systems und vergebe dem System die IP, die mein Haupt-System zuvor verwendet hat. Außerdem ändere ich den Hostnamen ebenfalls, sodass das System ab sofort den Hostnamen meines Haupt-Systems trägt. Auch wenn ich eigentlich nicht mit Hostnamen arbeite… irgendwo taucht der dann doch mal auf, außerdem könnten sich User verunsichert fühlen, wenn „das Ding“ plötzlich anders heißt.
Nun fehlt eigentlich nur noch die Aktivierung der entsprechenden Dienste, damit das Failover-System den Job des ausgefallenen Haupt-Systems übernehmen kann. Bei mir ist das SMB (was ich grundsätzlich abschalte solange es nicht benötigt wird) sowie der DLNA Server, der erstmal indexieren muss bis er bereit ist, ansonsten kann nun wie gewohnt weiter gearbeitet werden; der ein oder andere Client mag eventuell einen Reboot benötigen. Der Datenstand entspricht nun dem des letzten Syncs, der bei mir täglich um 1500 erfolgt. Nachts um 0300, also 12h versetzt läuft bei mir allerdings das reguläre Backup, sodass ich bei einem Ausfall vor 1500 aktuellere Dateien im Backup finde. Änderungen zwischen 0300 und 1500 werden nicht abgebildet, das ist aber nur eine Frage der Konfiguration (Stichwort active Sync).
Da ich das Ganze gerade nicht nur aus Jux und Tollerei gemacht habe, speichere ich mir diese Konfig ab, die ich im Ernstfall direkt laden kann, ohne die einzelnen Einstellungen manuell vornehmen zu müssen. Viele Dienste, insbesondere Apps müssen aber dennoch manuell aktiviert werden, da sie kein Bestandteil der gesicherten Konfig sind. Das Aktivieren solcher Dienste an dieser Stelle taugt also nur zu Testwecken.
Sollte dem Haupt- oder Failover-System die IP mittels DHCP gegeben werden, ist grundsätzlich - wie immer mit DHCP - Obacht geboten, hier müsste noch der DHCP Server angepackt werden! Ich arbeite bei solchen Geräten aber ohnehin ausschließlich mit fester IP, daher habe ich keine Sorgen.
Nachdem die Konfig für den Failover-Fall erstellt ist und etwaige Tests abgeschlossen sind, kann wieder die „normale“ Konfig (inkl. Abschaltung von Diensten) des Failover-Systems hergestellt und das Haupt-System anschließend wieder betriebsbereit gemacht werden.
[WECHSEL ZUM FAILOVER-BETRIEB]
Wenn es dazu kommen sollte, dass das Haupt-System ausfällt ist das Failover-System schnell in Betrieb genommen, im Grunde passiert hier nichts anderes als in Step 5 der Einrichtung, sofern man diesen gemacht hat. Daher in Kurzform, aber wichtig vorab: Sicherstellen, dass das Hauptsystem wirklich nicht mehr im Netzwerk unterwegs ist! Trotz Defekt könnte es mit seiner IP ja noch im LAN rumlungern und im nächsten Step Konflikte verursachen.
- Failover-System hochfahren
- IP und Hostnamen des Haupt-Systems übernehmen bzw. die entsprechende Konfig laden
- Weitere Dienste aktivieren
- User informieren, dass eventuell das Passwort zurückgesetzt werden muss und dass es - je nach Konfig - Restriktionen geben kann.
[FAILBACK - AUF DAS (NEUE) HAUPT-SYSTEM „ZURÜCK“ WECHSELN]
Nach unbestimmter Zeit, in der hoffentlich niemand deutliche Einschränkungen erfahren musste, wird es so weit sein, dass das defekte System ersetzt wurde, sei es durch ein anderes Gerät oder Reparatur. Auch das Failback soll nach Möglichkeit ohne nennenswerte Ausfallzeiten geschehen.
Das jetzige Vorgehen ist abhängig davon, ob die ursprünglichen HDD weiter betrieben werden können oder dem Defekt zum Opfer gefallen sind und ersetzt wurden. Letzteres ist sicherlich der absolute Worst-Case, meist wird sicherlich nur der QNAP selbst den Geist aufgeben, aber wir wollten uns ja auch auf den schlimmsten Fall vorbereiten, und so soll dieser nicht unerwähnt bleiben.
Neue/ formatierte HDD
Sollten es neue HDD sein, bzw. die alten HDD blankgemacht worden sein, kann das neue System in Ruhe aufgesetzt werden, natürlich vorerst mit IP und Hostname, die nicht dem Failover-System entsprechen, denn mit dem wird vorerst weiter gearbeitet. In diesem Fall müssen natürlich Freigaben, User und Berechtigungen wieder manuell angelegt werden, wie sie ursprünglich vorhanden waren. Wieder ein Workaround, wieder schade, dass QNAP kein entsprechendes Feature bereitstellt. Ist das alles erstmal erledigt, gilt es zunächst den „grundlegenden“ Datenbestand auf das System zu holen, das geschieht mit Hilfe eines One-Way Sync-Jobs vom Failover-System auf das Neue, und zwar so, dass die Struktur der Freigaben erhalten bleibt. Damit ist zumindest die Zeit der bevorstehenden Nichtverfügbarkeit deutlich reduziert. Der Stand des neuen Systems sollte anschließend dem entsprechen, wie einem neuen System wenn die alten HDD weiter verwendet würden, mit der Ausnahme, dass der Datenbestand ein anderer ist. Somit fahren wir im Grunde fort wie im Falle, dass die HDD ohne Änderung weiter verwendet werden können:
Beibehaltung der alten HDD / der alten Konfig
Nun gilt es einen günstigen Zeitpunkt auszumachen um die nachfolgenden Arbeiten auszuführen, denn die Systeme stehen fortan für einen gewissen, aber relativ kurzen Zeitraum nicht zur Verfügung, abhängig natürlich von den Änderungen, die seit Beginn des Failover-Betriebs aufgetreten sind.
Sollte es sich um viele Änderungen handeln, die die Zeit für den bevorstehenden Sync verlängern, wäre es eine Alternative das neue System zunächst zu isolieren, bzw. mit einer anderen IP in Betrieb zu nehmen (Stichwort zwei gleiche IPs im Netz) und die Masse der Daten zu synchronisieren bevor das eigentliche Failback beginnt, aber darauf möchte ich hier nicht weiter eingehen, zumal es in meinem Fall unwahrscheinlich ist, dass während des Failover-Betriebs Unmengen an Daten geändert werden.
Das neue System betriebsbereit, mehr oder weniger im Zustand vor dem Ausfall geht es damit los, das Failover-System in den „normalen“ Zustand zurückzuholen, in dem es darauf wartet eingesetzt zu werden: Dienste werden abgeschaltet, IP und Hostname werden geändert, etwaige User im Vorfeld natürlich informiert (und zum Speichern der Arbeit aufgefordert, ist ja nicht selbstverständlich )
Nun kann das neue System auch schon in Betrieb genommen werden und nach dem Booten steht es in dem Zustand bereit, wie wir es kannten. IP, Hostname und Dienste sind in diesem Fall wie es sein soll; haben wir das NAS zuvor neu initialisiert und eingerichtet, passen wir das entsprechend an bzw. starten die gewünschten Dienste und richten sie ein, falls noch nicht geschehen.
Damit die Arbeit unbeirrt weitergehen kann, muss nun noch der aktuelle Datenbestand in das neue System gezaubert werden. Hier bediene ich mich wieder der Funktion von HBS3. Im vorgenannten Fall, dass ein neu initialisiertes System zum Tragen kommt und bereits der grundlegende Datenbestand synchronisiert wurde, werden jetzt nochmal die aktuellsten Daten synchronisiert. Können die alten HDD weiter verwendet werden, werden nun sämtliche Daten synchronisiert, die während des gesamten Failover-Betriebs geändert wurden (nur wegen Klartext und so: „geändert“ beinhaltet auch neue und gelöschte Daten).
Ein Two-Way Sync-Job auf dem neuen System soll die Sache richten (ich habe mir übrigens im Vorfeld Job-Vorlagen für den Ernstfall auf dem Failover-System erstellt und arbeitete mit mehreren Jobs, einer tut es aber auch).
Der Job sieht wie folgt aus:
Als Quelle sämtliche Freigaben des Failover-Systems und als Ziel die des Haupt-Systems.
Natürlich kann man hier auch einzelne Freigaben angeben, wenn man weiß, dass nicht überall Änderungen stattgefunden haben.
Konfliktrichtlinie: „ältere Dateien überschreiben“ * , Zeitplan: keiner (manuell).
Anschließend wird der Job gestartet. Da auf dem Failover die aktuellsten Daten liegen, sollten nur die Daten vom Failover zum Haupt-System gesynct werden, die im Failover-Betrieb geändert wurden. Daten die gelöscht wurden, werden auch auf dem Haupt-System gelöscht. Das war mir wichtig, deshalb übrigens ein Two-Way Sync, da es User verwirren könnte, wenn bereits gelöschte Dateien plötzlich wieder da sind.
An dieser Stelle bekomme ich grad etwas Bauchweh und ich sehe Konflikte mit zwischenzeitlich gelöschten Daten... aber da wird mir der Praxistest Aufschluss geben.
* Für etwas mehr „Sicherheit“ bietet sich statt der Konfliktrichtlinie „ältere Dateien überschreiben“ die Richtlinie „lokale Dateien umbenennen“ an. So kann man sicherstellen, dass die aktuellen Daten nicht einen ungesicherten Datensatz überschreiben, der vor dem Fehlerfall geändert wurde und ggf. benötigte Daten enthält, die im Failover nicht vorhanden sind. In diesem Fall müssen die User informiert werden, dass entsprechende Dateien überprüft und zusammengeführt oder gelöscht werden sollten. Wenn ich so darüber nachdenke, werde ich zukünftig ebenfalls diese Richtlinie verwenden.
Letztes Zwischenfazit vor dem Praxistest:
Mit nicht allzu vielen Freigaben und Usern geht sowohl die Einrichtung als auch der Übergang zum Failover-Betrieb und zurück recht schnell. Da ich nebenbei hier geschrieben habe fällt es mir jedoch schwer einzuschätzen, wie viel Zeit die jeweiligen Aktionen wirklich erfordert haben. Ich erachte den Aufwand als sehr gering für das, was ich dadurch erreichen kann.
Meine Einschätzung: Einrichtung ca. 20min, Umstellung jeweils ca. 5min (ohne Hochfahren und Synchronisierung).
Wie gut die ganze Theorie wirklich funktioniert wird mir hoffentlich der Praxistest zeigen, für den ich mir eine Freigabe mit unbedeutenden Dateien anlegen werde und im Failover-Betrieb sowie in der Zeit zwischen Sync und Failover-Betrieb möglichst viele Dateioperationen durchführe. Hier soll sich dann auch zeigen, wie viel "Diszplin" beim Umgang mit den Daten erforderlich ist - ich hatte es vorher schon kurz erwähnt - wenn die Datenstände vor, während und nach dem Failover-Betrieb unterschiedlich sind und es dadurch zu Konflikten kommt.
Bevor es zum Praxistest des „Sync-Job-Failover“ übergeht möchte ich im nächsten Artikel aber erst eine weitere Variante einrichten, bei der ich das Ganze mittels Snapshot-Vault realisiere, eventuell gibt es hier Erleichterungen die es komfortabler machen, außerdem möchte ich die Praxis vergleichen können um meine "best practice" zu finden.