Windows Server 2012 R2 Update 2 lässt Hyper-V Failover Cluster abstürzen - Hyper-V Server Blog

Windows Server 2012 R2 Update 2 lässt Hyper-V Failover Cluster abstürzen

Vorlage-Button-WinServ2012R2_thumbIch hatte diese Woche einen Supportfall in einer Umgebung, in der Windows Server 2012 R2 Systeme mit Hyper-V ein Failover Cluster betreiben. Als Storage wird ein Equallogic-SAN von Dell eingesetzt, welches per iSCSI die LUNs an die jeweiligen Hosts bringt. Der Kunde hat letztes Wochenende einen großen Teil seiner Umgebung geupdatet, unter Anderem das SAN und die Hyper-V Hosts. Nach dem Update-Vorgang kam es dann zu einem sehr komischen Verhalten: Der Zugriff auf die LUNs war für einige Minuten nicht möglich, die Rollen (VMs) im Failover Cluster stürzten daraufhin ab und wurden als “fehlerhaft” gekennzeichnet.

Nachdem ein Supportfall bei Dell eröffnet wurde haben sich die Techniker das SAN angeschaut, da hier ein Update der Firmware vorgenommen wurde. Das SAN selbst wurde aber als mögliche Fehlerquelle weitestgehend ausgeschlossen, da alle Verbindungen aufgebaut werden konnten und auch sonst keinerlei Fehler auftauchten. An dieser Stelle kam ich ins Spiel und habe mir das Failover Cluster gemeinsam mit dem Kunden näher angeschaut. Mir sind vor Allem die vielen Fehlermeldungen im Failovercluster-Manager aufgefallen:

Cluster resource ‚Virtueller Computer „<VMName>“‚ of type ‚Virtual Machine‘ in clustered role ‚<VMName>‘ failed. The error code was ‚0x2‘ (‚The system cannot find the file specified.‘).

Based on the failure policies for the resource and role, the cluster service may try to bring the resource online on this node or move the group to another node of the cluster and then restart it.  Check the resource and group state using Failover Cluster Manager or the Get-ClusterResource Windows PowerShell cmdlet.

Cluster Shared Volume ‚Volume1‘ (‚<CSV>‘) is no longer accessible from this cluster node because of error ‚(1460)‘. Please troubleshoot this node’s connectivity to the storage device and network connectivity.

Cluster Shared Volume ‚Volume1‘ (‚<CSV>‘) has entered a paused state because of ‚(80000011)‘. All I/O will temporarily be queued until a path to the volume is reestablished.

Source war hier Microsoft-Windows-FailoverClustering, die Kategorien waren Resource Control Manager und Cluster Shared Volume. Die Event-IDs sind 1069, 5142 und 5120. Das Log war ziemlich voll mit diesen Einträgen:

image

Das Verhalten war wie folgt: Zwei der drei Cluster Nodes waren im pausierten Zustand, da es sonst zu einer Verschiebung der CSV-Datenträger kommt und der Datenträger in einem undefiniertem Zustand verbleibt. Im Wechsel von drei bis fünf Minuten waren die CSV-Datenträger erreichbar (über C:\ClusterStorage\), danach frierte z.B. der Explorer ein oder ein Zugriff per Failover Cluster Manager war nicht möglich.

Ich habe mir die installierten Updates angeschaut, es war unter Anderem das November-Update mit der KB-Nummer KB3000850 bzw. KB3000853 installiert. Wir haben zwei der Server im Wartungsmodus belassen (Knoten angehalten) und auf dem dritten Server das Update deinstalliert. Nach einem Neustart startete das Failover Cluster wieder automatisch und brachte auch wieder alle Datenträger online. Seit diesem Zeitpunkt war der Zugriff auf die Datenträger möglich, in den kommenden 20 Minuten passierten keine weiteren Aussetzer. Ein Zugriff auf C:\ClusterStorage war ebenfalls problemlos möglich, und nach und nach konnten alle virtuellen Server wieder eingeschaltet werden. Ich habe mit dem Kunden noch abgesprochen, das die beiden anderen Server im kompletten Offline-Zustand ebenfalls wieder auf den Stand vor dem November-Update gebracht werden (durch eine Deinstallation des Updates). Dies scheint funktioniert zu haben, ich habe seitdem keine Meldung mehr bekommen, dass das Problem weiter existiert.

Was genau die Installation des Updates bewirkt hat, kann ich aktuell nicht sagen. Ich habe bereits mehrere Server und Installationen auf das neue Update hochgezogen, bisher gab es solche Probleme nicht. Dieses Failover Cluster ist aber auch das Einzige, das mit LUNs arbeitet, alle anderen Systeme die geupdatet wurden, arbeiten mit einem Scale-Out File Server zusammen.

Jan Kappen
 

Jan Kappen ist ausgebildeter Fachinformatiker in der Richtung Systemintegration. Er hat seine Ausbildung im Sommer 2008 abgeschlossen und arbeitete bis August 2018 bei der Rachfahl IT-Solutions GmbH & Co. KG. Seit September 2018 arbeitet er als Senior Netzwerk- und Systemadministrator bei einem großen mittelständischen Unternehmen im schönen Sauerland. Jan Kappen ist unter anderen MCITP Server Administrator, Enterprise Administrator und Enterprise Messaging Administrator 2010 sowie MCTS für System Center Virtual Machine Manager 2008, Windows Server 2008 Active Directory, Windows Server Virtualization und Windows Server 2008 Network Infrastructure. Seit 2015 wird Jan Kappen im Bereich "File System Storage" bzw. "Cloud & Datacenter Management" für seine Expertise und seine Community-Arbeit mit dem MVP Award von Microsoft ausgezeichnet.

  • Andreas Altermann sagt:

    Hi Jan,
    interessant, da mit KB3000850 eigentl. ein anderer Bug in Zusammenhang mit SOFS gelöst sein sollte. Implementiere aktuell einen 3 Knoten Hyper Cluster mit einem SOFS und habe die System auf dem aktuellem Stand ohne Probleme.
    (hier alles Intel-Systeme).

  • Jan Kappen sagt:

    Hallo Andreas,
    in diesem Fall war kein SOFS vorhanden, sondern ein iSCSI-SAN von Dell. Das Problem lag auch gefühlt an der iSCSI-Anbindung der Datenträger. Das SAN direkt hat funktioniert und auch die Anbindung fehlerfrei durchgängig angenommen, nur das Failover Cluster mit den Hyper-V VMs hat in einem Zyklus von ca. 5 Minuten den Zugriff erlaubt, dann wieder nicht, dann ging es wieder ein paar Minuten, dann wieder nicht, usw…
    Wenn kein Zugriff auf den Storage da ist finden das die VMs natürlich unspannend und crashen alle nach einer gewissen Zeit. Der Kunde versucht das weiter mit Dell zu erforschen, was der Grund für das Problem sein könnte. Falls ich was hierzu höre ergänze ich das noch im Artikel.
    Gruß, Jan

  • Florian Schalk sagt:

    Moin,
    wir haben das gleiche Problem gehabt, aber mit einem SOFS Cluster.
    Gleiche Meldungen im Log.
    Bei uns hat sich das aber selbst nach ein paar Stunden repariert.
    Die meisten Msschinen waren für ca. 15 Minuten weg, danach waren der SOFS wieder erreichbar. Wir haben zwar auch das Update 3000850 installiert, aber das war schon Tage vorher.
    Bei uns war die mögliche Ursache das Backup.
    Zum Zeitpunkt des absturzes hat unser Veeam gerade die Snapshots des Backups aufgelöst.
    Jan: war das möglicherweise auch bei dem anderen Kunden der Fall?

  • Markus sagt:

    Hallo Jan,

    dies ist vielleicht für den ein oder anderen interessant:

    ich verwende ein FC-SAN (HP EVA) Im Cluster (WS2012 R2) und habe die o.g. November Updates noch nicht installiert. CAU lief das letzte Mal am 11.11.2014

    Ein invoke-causcan heute gibt keinen der o.g. Patches zur Installation zurück. In Windows Update bekomme ich aber KB3000850 als optionales Update angeboten.

    Nach Deinen Infos werde ich meinen regulären CAU ausführen (ohne optionale Updates) und dann manuell KB3000850 an einem Knoten im Wartungsmode installieren.

    Mal sehen wie das ausgeht.

    Grüße aus Baden,
    Markus

  • >