Windows Cluster patchen und automatisch Verteilung wieder herstellen

Jeder kennt es, Server und deren Betriebssysteme in produktiven Umgebungen (in Testumgebungen natürlich auch) müssen regelmäßig gepatcht werden. Solange es sich um Standalone-Systeme handelt gibt es selten Probleme…
Wenn man aber Ressourcen auf einem Cluster verteilt hat, dann sind so manche OS-Kollegen leider so uneinsichtig oder engstirnig, dass man sich ganz die Termine merken muss, wann diese Kollegen wieder das SQL Server Cluster patchen wollen.

Ich habe leider immer wieder die Erfahrung machen müssen, dass die Kollegen das Cluster nur als Aktiv-Passiv-System (=> alles läuft auf einem Knoten und schwenkt im Fehlerfall auf den Ersatzknoten) ansehen, ein Cluster kann aber eben auch als Aktiv-Aktiv-System betrieben werden. Ok, dann muss man darauf achten, dass im Fehlerfall alle Ressourcen auf einer Seite gemeinsam Lauffähig sind. Man muss sich also im Vorweg Gedanken machen zur optimalen Konfiguration (beispielhaft Min./Max Memory) um alle SQL-Server auf einer Cluster-Knoten betreiben zu können.

Aber was passiert mit den Cluster-Ressourcen nach einem Patch-Durchgang? Die oben bereits genannten Kollegen haben nur ihren Part im Kopf und patchen einfach nur die Systeme, heißt sie machen einen Knoten des Cluster frei und patchen diesen freie Knoten. Um natürlich auch Ressourcen und Kosten zu sparen, werden solche Dinge automatisiert in der Nacht durchgeführt.

Aber was passiert nach dem Patchen mit dem Cluster? Hat sich jemand die ursprüngliche Verteilung gemerkt? Werden die Ressourcen wieder auf die ursprünglichen Knoten verteilt?
Aus leidlicher Erfahrung muss ich leider „Nein“ sagen…

Auswirkungen dieser Nicht-Beachtung

Auch wenn man sich im Vorwege ausreichend Gedanken gemacht hat, dann ist es (zumindest bei uns) so, dass die einzelnen Cluster-Ressourcegruppen nicht alle die volle RAM-Ausstattung nutzen können, da es hier oft zu Engpässen kommt.

Wir konfigurieren unsere geclusterten SQL-Server meist so, dass der Parameter „Min.Memory“ die Hälfte des Parameters „Max.Memory“ erhält. Sollten dann tatsächlich alle Instanzen auf einem Knoten laufen, kommt es immer wieder zu RAM-Engpässen da alle SQL Server Instanzen versuchen unter Last ihren konfigurierten Wert für „Max.Memory“ erreicht. Da dies dann nicht passt, „prügeln“ sich die einzelnen Instanzen eben um die knappen System-Ressourcen.

Also wäre es das Idealste nach dem Patchen eben genau die vorgesehen Verteilung wieder herzustellen, damit alle Ressourcen möglichst optimal arbeiten können. Aber wie erreicht man dies?
Auf jedem System wird Powershell mitgeliefert, mittels Powershell werden immer mehr Skripte geschrieben, so dass man sein ganzes System oder sein ganzen Windows-Cluster sehr gut mit Powershell administrieren kann.

In der Theorie klingt das alles so einfach:

• Systemzustand ermitteln
• Cluster-Ressource-Gruppen ermitteln
• durch die einzelnen Gruppen durchlaufen
  • Prefered-Owner der jeweiligen Ressource-Gruppe ermitteln
  • mit dem aktuellen Owner vergleichen
  • bei Abweichungen auf den Prefered-Owner schwenken
• Fertig

Da ich diese Aktivität in der Hauptsache bei meinen Betriebssystem-Kollegen sehe, hatte ich dort einmal nachgefragt und erhielt Antworten, die mich nicht wirklich hoffen ließen. (ansatzweise habe ich das weiter oben schon angedeutet)
Also musste ich mir selber Gedanken machen… aber erst einmal googlen… warum sollte ich das Rad neu erfinden… 😉

hier die Lösung für die Cluster Umverteilung

Und siehe da, es hatte mir jemand die Arbeit abgenommen… 😉
Fermin Sanchez von der fsis GmbH hatte sich zu diesem Thema schon einmal Gedanken gemacht und (für mich) glücklicherweise in seinem Blog veröffentlicht.

Import-Module FailoverClusters
 
$clustergroups = Get-ClusterGroup | Where-Object {$_.IsCoreGroup -eq $false}
foreach ($cg in $clustergroups)
{
    $CGName = $cg.Name
    Write-Host "`nWorking on $CGName"
    $CurrentOwner = $cg.OwnerNode.Name
    $POCount = (($cg | Get-ClusterOwnerNode).OwnerNodes).Count
    if ($POCount -eq 0)
    {
        Write-Host "Info: $CGName doesn't have a preferred owner!" -ForegroundColor Magenta
    }
    else
    {
        $PreferredOwner = ($cg | Get-ClusterOwnerNode).Ownernodes[0].Name
        if ($CurrentOwner -ne $PreferredOwner)
        {
            Write-Host "Moving resource to $PreferredOwner, please wait..."
            $cg | Move-ClusterGroup -Node $PreferredOwner
        }
        else
        {
            write-host "Resource is already on preferred owner! ($PreferredOwner)"
        }
    }
}
Write-Host "`n`nFinished. Current distribution: "
Get-ClusterGroup | Where-Object {$_.IsCoreGroup -eq $false}

Da Fermin das Skript in seinem Blog „as-is“ veröffentlicht hat, musste ich das Skript natürlich erst einmal testen, hierzu habe ich die eigentliche „Move-Zeile“ auskommentiert. Das Ergebnis dieses Testlauf brachte genau das Ergebnis, was ich mir erhofft hatte. Im Rahmen des letzten Patchdays habe ich das Skript nach dem Patchen erfolgreich eingesetzt und konnte so Kundenbeschwerden über mangelhafte Performance des SQL-Server vermeiden.

Vielen Dank an Fermin und seine Leistung!