NLB Watcher

NLB ist nicht "Service Aware", d.h. NLB merkt nicht, wenn der Service auf dem Server nicht erreichbar ist, sondern prüft nur, ob der TCP-Stack erreichbar ist. Das ist natürlich ungeschickt, wenn ein Server weiter Verbindungen annimmt, obwohl er sie nicht mehr korrekt bedienen kann. Ein Monitoring des Servers ist ein erster Ansatz aber wenn ein Fehler oder Problem entdeckt wird, dann muss das System auch handeln.

Dienst überwachen

Zuerst müssen Sie ermitteln, welche Dienste der Server anbietet und wie sie diese Funktion sinnvoll überwachen können. Einen Webserver kann ein HTTP-GET überwachen. Einen Mailserver könnte man mit einem einfachen TCP-Connector oder einem HELP/BYE überwachen.

Allerdings sollte ein Monitoring-Skript natürlich "richtig" müssen. Die NLB-IP-Adresse kann es nicht abfragen, sondern muss die lokale IP des Servers nutzen. Dazu muss aber auch gesichert sein, dass der Server auch auf diesen Adressen lauscht und es die gleiche Instanz ist. Wer also auf der NLB-IP einen Webserver als eigene virtuelle Webseite betreibt und die Überwachung auf eine andere IP-Adresse mit einem anderen Web durchführt, misst den falschen Puls.

Gerade bei Webseiten reicht es aber nicht zu sehen, ob der Webserver etwas "ausliefert", sondern auch was er ausliefert. Je genauer Sie bestimmten können, welche Ergebnisse einer synthetischen Abfrage den Status wiedergeben, desto zuverlässiger können Sie einen Knoten im Fehlerfall aus der Farm ausnehmen oder nach der Wiederherstellung der Funktion wieder online nehmen.

Bedenken Sie bei der Wahl ihrer Prüfung auch den Status beim Neustart des Servers (Warmlaufphase) und beim geplanten Shutdown (z.B. für Updates und Patches). Nicht dass Sie den Knoten "geplant" außer Betrieb nehmen und das Skript ihn gleich wieder online schaltet, wenn der Service selbst noch aktiv ist.

Beispielskript

Das folgende Beispiel soll zeigen, Wie sie mit Windows 2008R2 und den PowerShell-Commandlets für NLB eine einfache Überwachung einer Webseite per HTTP-Abruf erreichen.

[CmdletBinding()]
param (
   $URL = "http://www.msxfaq.de"
)

write-verbose "Loading Module NetworkLoadBalancingClusters"
Import-Module NetworkLoadBalancingClusters

write-verbose "Initialize WebClient"
$webclient = new-object System.Net.WebClient

write-verbose "Start Healtchcheck"
While ($true) {
   $result=$null
   try {
      write-verbose "Checking"
      $result = $webclient.DownloadString($URL)
   }
   catch {
   write-host "Error checking $URL.  stopping NLB Node"
   Stop-NlbClusterNode
   }
   if ($result -ne $null) {
      write-verbose "Result not null. assume working."
      if ((Get-NLBClusterDriverInfo).currenthoststate -ne "startet") {
         write-verbose "Starting NLB"
         Start-NlbClusterNode
      }
   }
   write-verbose "Sleeping 5 Sek ...."
   Start-sleep –seconds 5
}

Das Skript enthält nun natürlich keinerlei Logging (Eventlog) oder Alarmierungsfunktionen.

Einplanen

Ein PowerShell Script ist natürlich kein "Windows Dienst" aber der Windows Taskmanager kann auch PowerShell Skripte starten. Ihnen stehen nun zwei Wege offen

  • Taskplaner startet immer wieder
    Wenn das Script prüft und sich dann wieder beendet, dann kann der Taskplaner das Script z.B.: jede Minute starten. Windows kann den genutzten Speicher immer wieder freigeben, ein Fehler im Skript wird vom Taskplaner bemerkt etc. Allerdings bedeutet dies auch, dass die Überwachen nicht allzu eng ist und jedes Mal eine komplette PowerShell-Umgebung instanziert wird.
  • Taskplaner startet "beim Hochfahren".
    Der Taskplaner kann auch ein Programm oder Skript schon beim Hochfahren starten und laufen lassen. Dann muss das PowerShell-Script natürlich in einer Schleife arbeiten und kann das sehr viel häufiger machen. Allerdings sollten Sie dann hier etwas mehr Grips in Logging und Fehlerbehandlung stecken.

Beide Varianten haben ihre Vor- und Nachteile.

Weitere Links