Jump to content

Sicherung Windows 2012 Failover-Cluster / Hyper-V


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo zusammen,
ich arbeite gerade an einer Testumgebung mit einem Failover-Cluster unter Windows 2012.
Nun geht es um die Sicherung, die Server-Sicherung / wbadmin bringt unter 2012 ja einige Neuerungen mit sich.
Hierbei stellen sich mir einige Fragen, bei denen ihr mir vielleicht weiterhelfen könnt.

 

Szenario:
Failover-Cluster (2012) mit zwei Nodes, derzeit wird auf dem Cluster als Rolle nur Hyper-V ausgeführt (4VMs), was sich aber ggf. ändern kann (evtl. noch Fileserver, DHCP, etc. geplant).
Die VMs liegen auf einem CSV auf einer QNAP-NAS(Pro) mit iSCSI.
Ziel ist es, den kompletten Cluster zu sichern, ohne Ausfall der VMs und unabhängig davon, wo sich die VMs gerade befinden.
Hierzu soll das integrierte wbadmin genutzt werden, DPM kommt aktuell nicht in Frage.
Sicherungsziel ist eine Freigabe auf einem dedizierten Backup-Server, wo die Sicherungen quasi "online" liegen sollen und regelmäßig auf ein lokal angeschlossenes RDX oder LTO gezogen werden (mit Backup-Exec, unabhängig von der Laufzeit der "primären" Sicherung).

 

Wenn ich nun den wbadmin-Assistent auf einem Node starte (zum Testen, später wird gescripted), sehe ich nun zwei Möglichkeiten:

 

1.) Ich kann den Server selbst, inkl. der gerade auf dem Server laufenden(!) VMs und das Quorum sichern.
Das CSV selbst kann ich nicht mit wählen (was ja bezüglich der VMs auch "doppelt gemoppelt" wäre, später (s.o.) aber sinnvoller sein könnte).
Prinzipiell wäre dies zunächst ja hinreichend, wenn dies auf beiden Nodes konfiguriert wäre.
Fraglich ist nur, ob die VMs in der Sicherung dann auch immer entsprechend berücksichtigt werden, wenn diese zwischen den Knoten verschoben werden (?).
Eher problematisch sehe ich jedoch zwei Punkte:
- Was ist, wenn das CSV mal mehr Daten als die VMs enthält (z.B. Fileserver, etc.) - die werden dann nicht gesichert... (?)
- Wenn die VMs zwischen den Knoten verschoben werden, werden diese mal mit dem einem, mal mit dem anderen Knoten gesichert (hoffentlich - siehe oben). Dadurch "blähen" sich die Sicherungsdateien ziemlich auf und belegen mehr Speicher auf dem Backup-Server als nötig (wie ja auch schon mit wbadmin unter 2008 R2)

 

2.) Alternativ kann ich nur das CSV selber sichern. Dabei werden die VMs in den Status "Sicherung wird ausgeführt" versetzt.
Dies erscheint zunächst sinnvoller, da dann ja alle Daten des CSVs mitgenommen werden und die VMs nicht evtl. doppelt agelegt werden.
Man könnte also als Job dies auf einem Node durchführen und auf jedem Node dann nochmal den "Rest" (also den jeweiligen Server, ohne Hyper-V und CSV) - dann sollte man doch alles haben, oder?
Fraglich ist für mich hier, ob die VMs auch korrekt gesichert werden (so "sicher" wie per Child-Snapshot in der o.g. Lösung), es ist auch Exchange und SQL auf den VMs im Einsatz...
Ebenso fraglich sind für mich die Recovery-Optionen (dich ich wegen des doch hohen Aufwands noch nicht getestet habe).
Desaster-Fall (kompletter Cluster ist zerstört): Kann ich mit dieser Sicherung die VMs auch lauffähig wiederherstellen ohne den kompletten Cluster zu rekonstruieren?
(Ist ja meistens so: Server bereit stellen, Sicherung liegt dateibasiert vor, Einlesen der Sicherung und Starten der VMs sollte auf diesem Einzelgerät, ohne Cluster etc. möglich sein!)


Vielleicht gibt es ja jemanden, der hiermit schon Erfahrung hat und ein paar Tipps geben kann.

Schöne Grüße,
Jan



Okay - Update in dieser Sache (ich war eben etwas voreilig - sorry):

 

Nachdem ich nun schon einiges getestet habe, fällt Option 1.) weg, da die Hyper-V Maschinen nicht gesichert werden können, wenn sie auf einem CSV liegen.
 

Dies gibt Microsoft auch so an, habe ich erst nur falsch verstanden:

 

http://technet.microsoft.com/en-us/library/jj614621.aspx
1. Virtual machines hosted on CSV’s cannot be added as part of backup configuration
2. Windows Server Backup has to be configured on all nodes to ensure that backup and recovery will be available in the event of a failure on one of the nodes in the cluster.
3. Volumes recovery not supported
4. Security access control lists are not applicable on CSV file service root. Therefore, file recovery to the root of CSV volume is not supported.

 

Bleibt also nur die Sicherung des CSVs.
Hier treten nun wieder folgende Fragen auf:
- zu 2.: "on all nodes" ?! Das würde ja bedeuten, dass alle VMs doppelt gesichert würden?!!!
- Wie ist das dann mit dem Recovery (s.o.) - hat da jemand schon (Test-) Erfahrungen?

 

Das nächste Problem bleibt dann die Sicherung der Nods selber.
Wie oben gesagt, könne keine lokalen UND CSV-Daten in einer Sicherung enthalten sein.
Wenn ich einen Node mit "Bare-Metal" sichern will, wählt er C: komplett aus (was ja das CSV "logisch" enthalten würde) und bricht ab, da CSVFS-Daten nicht mitgesichert werden können (an sich logisch).
Entferne ich C:\ClusterStorage, geht Bare-Metal nicht mehr.
Wähle ich Bare-Metal ab, kommt die Meldung "Einer für die Sicherung angegebenen Dateipfade befindet sich unterhalb eines Analysepunktes...") geht also auch nicht....

 

Jetzt bin ich etwas fraglos...

Link zu diesem Kommentar

Moin,

 

Failover-Cluster (2012) mit zwei Nodes, derzeit wird auf dem Cluster als Rolle nur Hyper-V ausgeführt (4VMs), was sich aber ggf. ändern kann (evtl. noch Fileserver, DHCP, etc. geplant).

 

schlechte Idee. Ein Host ist ein Host ist ein Host. Niemals andere Rollen auf einem Hyper-V-Hostserver einrichten.

 

Wenn du File- oder DHCP-Server clustern willst, bau dafür einen separaten Cluster.

 

Ziel ist es, den kompletten Cluster zu sichern

 

Das klingt nicht durchdacht. Warum sollte das Ziel sein, den Cluster zu sichern? Das Ziel besteht doch wohl eher darin, nach Ausfällen oder Datenverlusten deine Applikationen und Daten wiederherzustellen, oder? Also solltest du auch vom Ziel her planen.

 

Du machst hier den beliebten Fehler, von einer bekannten oder angenommenen Methode her zu denken. Erfahrungsgemäß kommt man damit bei Recovery-Planungen nicht weit.

 

Hierzu soll das integrierte wbadmin genutzt werden, DPM kommt aktuell nicht in Frage.

 

Neben wbadmin (das ich nur in Ausnahmefällen nutzen würde) und DPM gibt es ja noch eine ganze Reihe weiterer Werkzeuge und Ansätze.

 

Desaster-Fall (kompletter Cluster ist zerstört)

 

Das wäre ganz sicher ein Desaster und gehört selbstverständlich in die Liste der zu berücksichtigen Schadensszenarien. Ein solcher Komplettausfall ist aber ausgesprochen unwahrscheinlich und ebenso selten. Viel häufiger wirst du dich mit anderen Szenarien herumschlagen müssen. Für die brauchst du auch Lösungen. In den meisten Situationen gelingt eine Wiederherstellung auf Basis von "Komplett-Backups" nicht, wenn kein Komplett-Restore erforderlich ist.

 

Die meisten Kunden, die den Restore-Fall wirklich durchplanen, landen bei hybriden Verfahren, in denen Backups auf Applikationsebene und Backups auf VM-Ebene fallweise kombiniert werden. Den Cluster als solchen zu sichern, ist nicht grundsätzlich unsinnig, aber auch nicht immer sinnvoll, denn meist ist ein Cluster bzw. Clusterknoten schneller neu wieder aufgesetzt als restauriert.

 

Gruß, Nils

bearbeitet von NilsK
Link zu diesem Kommentar
  • 9 Monate später...

Hi,

 

bin gerade via Google auf diesen Artikel gestoßen, da ich eine ähnliche Thematik habe.

Ist das Problem gelöst? Wenn ja wie?

 

Ich selbst habe gerade meinen ersten Hyper-V Cluster auf Basis von Server 2012 R2 aufgebaut. Als zentraler Storage dient eine HP MSA P2000 1GB iSCSI mit ~1,8TB. Hierauf sind Quorum und CSV abgelegt.

Frage: wie sichere ich die Daten/VMs, die auf diesem System liegen? Mein Chef kam eben um die Ecke und will - da das System eine Demoumgebung ist - die MSA auch mal zu Testzwecken an Kunden verleihen. Ich brauche also eine Lösung, welche schnell sichert und schnell recovert, habe bisher aber keine Erfahrung mit Sicherungen eines Cluster/Storage.

 

Für Fragen stehe ich gerne bereit und hoffe nun auf eure Hilfe.

 

Gruß Manuel

Link zu diesem Kommentar

Hallo,

 

ein Chef der 'um die Ecke kommt' und 'mal eben schnell' sind ungünstige Vorraussetzungen für gute Planung ;)

 

Da wirst Du wohl den Cluster 'kaputtmachen' müssen, wenn kein äquivalenter Ersatz zur Verfügung steht.

Die HA VMs aus dem Cluster entfernen und zurück auf die Hosts schieben. Zur Not auf eine externe USB Platte - ist ja nur eine Tesumgebung

Sind alle ehemaligen Cluster VMs auf die Hosts verteilt, kannst Du den Cluster sauber auflösen.

 

Kommt das Storage zurück, kannst Du einen neuen Cluster bauen und die VMs wieder hochverfügbar machen

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...