6
Hyper-V, DPM, Consistency Checks nach Reboot der Nodes
Moin zusammen.
Ich beobachte hier schon länger ein Phänomen, für das ich keinerlei Erklärung finde - evtl. hat ja einer von euch ne Idee dazu.
Umgebung:
Hyper-V 2012 R2 Cluster (drei Stück; zwei Mal vier Nodes, ein Mal zwei Nodes) und DPM 2012 R2. In den Clustern viele, viele VMs, alles Windows Server Maschinen (2008 R2/2012/2012 R2), die per VSS-Snapshot vom DPM gesichert werden.
Problem:
Klappt soweit alles prima, mit einer (leider immer wiederkehrenden) Ausnahme:
Wenn ich die Nodes mit Updates versorgt und neu gestartet habe, schlagen reproduzierbar die nächsten Recovery Points auf dem DPM fehl, es folgt immer ein Consistency Check _aller_ VMs im jeweiligen Cluster.
Wir haben auch noch einige Standalone Hyper-V Nodes, bei denen tritt das nicht auf; die kann ich rebooten, wie ich will, die Backups per DPM laufen stressfrei durch, ohne Consistency Check.
VSS-Logs hab ich schon vor und zurück gewälzt, hier gibt es keinerlei Probleme, alles sieht gut aus. Auf dem DPM finde ich ebenfalls keinerlei Hinweise, ausser dieser Standardfehlermeldung:
Damit komme ich allerdings auch nicht weiter, die Ergebnisse einer google-Suche dazu sind sehr diffus und beziehen sich in aller Regel auf Hyper-V 2008 (R2) und DPM 2010.
Den Clustern selbst geht es ebenfalls gut, Validation klappt und auch die Cluster-Logs liefern keine brauchbaren Hinweise.
Hat jemand eine ähnliche Umgebung und kennt dieses Verhalten?
Sachdienliche Hinweise werden dankend entgegengenommen.
Grazie Mille!
Cheers,
jsysde
Ich beobachte hier schon länger ein Phänomen, für das ich keinerlei Erklärung finde - evtl. hat ja einer von euch ne Idee dazu.
Umgebung:
Hyper-V 2012 R2 Cluster (drei Stück; zwei Mal vier Nodes, ein Mal zwei Nodes) und DPM 2012 R2. In den Clustern viele, viele VMs, alles Windows Server Maschinen (2008 R2/2012/2012 R2), die per VSS-Snapshot vom DPM gesichert werden.
Problem:
Klappt soweit alles prima, mit einer (leider immer wiederkehrenden) Ausnahme:
Wenn ich die Nodes mit Updates versorgt und neu gestartet habe, schlagen reproduzierbar die nächsten Recovery Points auf dem DPM fehl, es folgt immer ein Consistency Check _aller_ VMs im jeweiligen Cluster.
Wir haben auch noch einige Standalone Hyper-V Nodes, bei denen tritt das nicht auf; die kann ich rebooten, wie ich will, die Backups per DPM laufen stressfrei durch, ohne Consistency Check.
VSS-Logs hab ich schon vor und zurück gewälzt, hier gibt es keinerlei Probleme, alles sieht gut aus. Auf dem DPM finde ich ebenfalls keinerlei Hinweise, ausser dieser Standardfehlermeldung:
Change Tracking has been marked inconsistent due to one of the following reasons
1. Unexpected shutdown of the protected server
2. Unforeseen issue in DPM Bitmap failover during cluster failover of one or more datasources sharing the tracked volume. (ID 30501 Details: Unknown error (0xe0062041) (0xE0062041))Damit komme ich allerdings auch nicht weiter, die Ergebnisse einer google-Suche dazu sind sehr diffus und beziehen sich in aller Regel auf Hyper-V 2008 (R2) und DPM 2010.
Den Clustern selbst geht es ebenfalls gut, Validation klappt und auch die Cluster-Logs liefern keine brauchbaren Hinweise.
Hat jemand eine ähnliche Umgebung und kennt dieses Verhalten?
Sachdienliche Hinweise werden dankend entgegengenommen.
Grazie Mille!
Cheers,
jsysde
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 289323
Url: https://administrator.de/forum/hyper-v-dpm-consistency-checks-nach-reboot-der-nodes-289323.html
Ausgedruckt am: 24.12.2024 um 19:12 Uhr
6 Kommentare
Neuester Kommentar
Ist bei dir das Clusterfähige Aktualisieren aktiv?
Moin.
Nope. Wir machen das noch "manuell".
Cheers,
jsysde
Nope. Wir machen das noch "manuell".
Cheers,
jsysde
Moin.
Habe gestern noch ein wenig "gespielt":
Zwei-Node-Cluster, Node2 leergeräumt und neu gestartet, dann die VMs wieder auf Node2 geschoben. Im DPM einen Recovery Point gemacht => Fehler => Consistency Check. Auf Node1, der nicht neu gestartet wurde, klappen Recovery Points erwartungsgemäss.
Vorher wild VMs zwischen Nodes migriert, VMs neu gestartet, Owner der CSVs geändert - alles ohne Auswirkungen auf's Backup, es liegt also reproduzierbar am Neustart der Cluster-Nodes.
Anyone?
Cheers,
jsysde
Habe gestern noch ein wenig "gespielt":
Zwei-Node-Cluster, Node2 leergeräumt und neu gestartet, dann die VMs wieder auf Node2 geschoben. Im DPM einen Recovery Point gemacht => Fehler => Consistency Check. Auf Node1, der nicht neu gestartet wurde, klappen Recovery Points erwartungsgemäss.
Vorher wild VMs zwischen Nodes migriert, VMs neu gestartet, Owner der CSVs geändert - alles ohne Auswirkungen auf's Backup, es liegt also reproduzierbar am Neustart der Cluster-Nodes.
Anyone?
Cheers,
jsysde
Da muss ich passen :D sorry
N'Abend.
Habe mich -da ich den Urlaub ja ein wenig produktiv nutzen muss *g*- mal ein wenig in CAU eingelesen und werde mal schauen, ob mir das weiterhilft.
Cheers,
jsysde
Habe mich -da ich den Urlaub ja ein wenig produktiv nutzen muss *g*- mal ein wenig in CAU eingelesen und werde mal schauen, ob mir das weiterhilft.
Cheers,
jsysde
Moin moin.
So, noch ein bisschen Input von mir, vielleicht hat ja noch jemand ne Idee.
Wir betreiben mehrere Hyper-V Cluster an verschiedenen Standorten, mit unterschiedlicher Hardware.
Der oben beschriebene Fehler tritt nur am Hauptstandort auf, dort ist eine NetApp in Betrieb und der ClusterStorage liegt auf eben dieser. Die Cluster-Nodes sind allesamt DELL Blade Server (M610e, M620e), die allesamt in einer M1000e stecken.
An anderen Standorten laufen die Hyper-V Cluster auf DELL VRTX Systemen -teils Server 2012, teils 2012R2- und dort tritt der Fehler nicht auf.
Auch an den Kleinst-Standorten, an denen nur ein einzelner (DELL) Server als Hyper-V Host läuft und kein Cluster vorhanden ist, tritt kein Fehler auf, wenn ich den Host neugestartet habe.
Ich mutmaße jetzt also, dass es in irgendeiner Form mit der M1000e/den Blade Servern und/oder der NetApp zu tun haben muss - denn das sind die einzigen Unterschiede, die ich im Vergleich zu den anderen Hyper-V Clustern feststellen kann.
Vorschläge? Ideen? Irgendjemand?
Danke und Cheers,
jsysde
So, noch ein bisschen Input von mir, vielleicht hat ja noch jemand ne Idee.
Wir betreiben mehrere Hyper-V Cluster an verschiedenen Standorten, mit unterschiedlicher Hardware.
Der oben beschriebene Fehler tritt nur am Hauptstandort auf, dort ist eine NetApp in Betrieb und der ClusterStorage liegt auf eben dieser. Die Cluster-Nodes sind allesamt DELL Blade Server (M610e, M620e), die allesamt in einer M1000e stecken.
An anderen Standorten laufen die Hyper-V Cluster auf DELL VRTX Systemen -teils Server 2012, teils 2012R2- und dort tritt der Fehler nicht auf.
Auch an den Kleinst-Standorten, an denen nur ein einzelner (DELL) Server als Hyper-V Host läuft und kein Cluster vorhanden ist, tritt kein Fehler auf, wenn ich den Host neugestartet habe.
Ich mutmaße jetzt also, dass es in irgendeiner Form mit der M1000e/den Blade Servern und/oder der NetApp zu tun haben muss - denn das sind die einzigen Unterschiede, die ich im Vergleich zu den anderen Hyper-V Clustern feststellen kann.
Vorschläge? Ideen? Irgendjemand?
Danke und Cheers,
jsysde
