Hyper-V-Cluster: Wenn patchen alleine nicht mehr reicht

Hyper-V erfreut sich zurecht großer Beliebtheit: Es skaliert gut, verursacht keine zusätzlichen Lizenzkosten, wenn man sowieso Windows Server einsetzt und kann mit Bordmitteln beachtliche Ergebnisse liefern. Eine solche – von Microsoft in dieser Form sehr stark beworbene – Konfiguration aus einem Hyper-V-Cluster auf einem Scaleout-Fileserver bereitet mir in letzter Zeit Kopfzerbrechen.

Scheinbar grundlose Hyper-V Ausfälle

So kam es Nachts ohne erkennbaren Grund zum Ausfall eines Clusterkontens und die dort laufenden VM blieben mit dem Status “Saved – Critical” stehen. Nach einem Resume bzw. Start im Hyper-V-Manager lief alles weiter.

An anderer Stelle kam es beim Patchen des Scale-Out-Fileservers zum temporären Ausfall eines der Storage Spaces – und in der Folge zu dutzenden Bluescreens auf Seite der VM. Wirklich gefunden habe ich zu diesem Zeitpunkt nichts, bis ich wegen eines Testlaufs mit Barracuda Backup ein Problem mit den Volume Shadow Copy Services (VSS) feststellte, dass sich nicht durch die von Microsoft empfohlenen Schritte lösen lies.

Als ich dann meine Suche nach dem VSS-Problem um die Komponenten Hyper-V-Cluster erweiterte, war ich baff:

Für den Betrieb eines Hyper-V-Clusters auf Windows Server 2012R2 werden mittlerweile 4(!) Hotfixes von Microsoft empfohlen – neben den üblichen Updates.

Kabinett der Grausamkeiten

KB 3072380 – “Hyper-V Cluster unnecessarily recovers the virtual machine resources in … 2012R2”

KB 3063283 – “Update to improve the backup of Hyper-V Integrated components…”

KB 3060678 – “Snapshots are not deleted after … backup operation by VSS…”

KB 3090343 – “Cluster Service Stops during the VSS backup in a Windows Server 2012 R2 or … 2012 based Hyper-V cluster”

Nachdem diese Sammlung von Grausamkeiten entdeckt war, erkannte ich spontan einige meiner Probleme und Fehlerbilder wieder. Führten diese doch zwischenzeitlich zu argen Selbstzweifeln und hässlichen Anmerkungen über das implementierte Gesamtkonstrukt, Freude kam aber dennoch nicht auf. Bis auf KB 3060678 kann ich alle diese Fehlerbilder in meinem Cluster nachweisen, auch die vergeblichen Versuche, die geiche VM immer und immer wieder neuzustarten, obwohl sie schon längst wieder sauber lief.

Hier der Link zur englischen Originalseite, die auch die empfohlenen regulären Patches auflistet – die deutsche Version ist maschinell übersetzt, was nicht vollständig zielführend ist.

Die Hotfixes patchen unter anderem den Clusterdienst und die VSS, so dass es sich durch die Bank um Hotfixes handelt, die einen Reboot erfordern. Außerdem setzen die Hotfixes das “April-Update” KB 2919355 voraus, ohne dieses läuft unter Server 2012 R2 nichts.

Mindestens genau so beeindruckend wie die Liste der Hotfixes und der Probleme, die sie fixen halte ich die Tatsache, dass Teile davon seit über einem Jahr nicht den Weg in ein ordenliches Update geschafft haben – Hotfixes installiert der Nutzer ja, im Gegensat zu Updates – auf eigenes Risiko und ohne Support seitens Microsoft. Auch wer bisher nur als “wichtig” klassifizierte Patches installiert, sollte seine Taktik überdenken, denn nicht alle der empfohlenen Updates sind so eingestuft.

Warum nur Hotfixes und keine Patches?

Ich bin zwar bei meinen Kollegen dafür bekannt, dass ich solche Probleme magisch anziehe. Davon unabhängig bin ich aber schon verwundert über die Tatsache, dass ein voll gepatchtes Clustersystem ohne Hotfixes trotzdem reichlich wackelig ist. Wenn ich für eine Scaleout-Fileserver schon zwei Windows Server plus Storage brauche, dann muss das mindestens so stabil laufen, wie eine billige iSCSI-SAN. Alles andere ist einfach nicht akzeptabel.

Aber man darf gespannt sein, wie das mit Server 2016 weitergeht – bestimmt wird alles wieder einmal viel besser…

Schreibe einen Kommentar