Für Rechenzentrumsexperten sind Überwachung und Alerts nichts Neues. Dennoch kann es manchmal helfen, sich die enorme Entlastung durch Automatisierung nochmal vor Augen zu führen. Leon Adato, Technikspezialist bei Solarwinds, zeigt dies anhand einiger praktischer Beispiele.
"Datenträger voll"-Warnungen sind ein einfaches Konzept mit verwirrend vielen beweglichen Teilen. Daher ist es wichtig, die Warnung zunächst richtig zu verstehen. So bedeutet beispielsweise eine Warnung bei 90-prozentiger Belegung eines Datenträgers mit 2 TByte, dass immerhin noch 204,8 GByte frei sind.
Hier könnte der RZ-Experte einfach den Prozentsatz sowohl an belegten als auch an freien Speicherplatz prüfen. Oder noch besser: Der Administrator integriert Logik in die Warnung, die den gesamten Speicher des Datenträgers prüft und dann Datenträger mit weniger als 1 TByte nach anderen Kriterien bewertet als Datenträger mit mehr als 1 TByte Speicherkapazität. Diese Tests sollten möglichst alle im Rahmen derselben Warnung ausgeführt werden, damit man den Platz auf dem Datenträger der jeweiligen Größe entsprechend sinnvoll überwachen kann und die Automatisierung nur die notwendigen Warnungen generiert.
Als Nächstes ist es ratsam, nicht benötigte Datenträgerdateien aus den verschiedenen Verzeichnissen zu entfernen. Alle Systeme besitzen ein temporäres Verzeichnis, in dem der IT-Verantwortliche alle Dateien dieses Ordners ohne negative Konsequenzen löschen kann. Die Herausforderung dabei ist einzig der Identitätswechsel. Viele Überwachungslösungen laufen auf demselben Server wie das Systemkonto. Folglich erfordert das Ausführen bestimmter Aktionen das Skript für den Wechsel zu einem privilegierten Benutzerkonto. Dafür gibt es zahlreiche Methoden. Daher müssen IT-Experten an dieser Stelle selber entscheiden, welche Lösung am besten zu ihrer individuellen Umgebung passt.
Ist das Problem mit dem Identitätswechsel gelöst, taucht die nächste Herausforderung der "Datenträger voll"-Warnung auf: Prüft man wirklich die richtigen Verzeichnisse für den speziellen Server? Am besten ist es daher, einen allgemeinen freigegebenen Ordner zu verwenden, der allen Servern zugeordnet ist, und dort eine Skriptdatei abzulegen. Mit dem Skript lässt sich festlegen, dass zuerst die richtigen Verzeichnisse ermittelt und diese anschließend und unter Berücksichtigung der erforderlichen Sicherheitsmaßnahmen und Tests bereinigt werden.
Ein Neustart des Anwendungspools ist häufig die einfachste und beste Lösung für Website-bezogene Probleme. Damit ist gemeint, dass die Eingabe der Befehle appcmd stop… und appcmd start… keine schnelle Lösung bietet, da dieser Ansatz größere Probleme ignoriert. Häufig behebt erst das Zurücksetzen des Anwendungspools das Problem.
Das Hinzuziehen eines Experten, der die Arbeit übernimmt, ist meist die teuerste Option. Allerdings kann ein Server mehrere Websites ausführen, die wiederum mehrere Anwendungspools verwalten - oder ein großer Anwendungspool steuert mehrere Websites. Alles hängt davon ab, wie man die Server und Websites konfiguriert hat. Aber das können die IT-Admins beziehungsweise die Automation selber nicht wissen.
Die gute Nachricht ist, dass sofern die Überwachungslösung den Anwendungspool überwachen kann, diese auch den Namen mitteilt. Bei den meisten umfangreicheren Überwachungslösungen ist das bereits der Fall. Sobald man den Namen weiß, kann der IT-Verantwortliche wie folgt vorgehen:
# IIS-Modul laden: Import-Module WebAdministration
# Namen für die Site festlegen, deren Pool neu gestartet werden soll: $site = „Default Web Site“
# Poolnamen nach dem Sitenamen abrufen: $pool = (Get-Item ?IIS:\Sites\$site?| Select-Object applicationPool).applicationPool
# Anwendungspool neu starten: Restart-WebAppPool $pool
Knapp an zweiter Stelle nach der Option Neustarten des Anwendungspools folgt die Option, IIS zurückzusetzen. Das ist allerdings die Radikallösung unter den Website-Problembehebungen, da man damit alle Websites und Verbindungen platzen lässt. Das mag zwar drastisch sein, doch in manchen Fällen absolut notwendig.
Wie beim Neustarten des Anwendungspools gilt auch hier: Einen Experten für diese ausgesprochen einfache Aktion zu bemühen, verschwendet nur die Zeit der Beteiligten und das Geld des Unternehmens. Es ist wesentlich besser, die Website automatisch neu zu starten und nach ein oder zwei Minuten erneut zu prüfen. Ist dann alles in Ordnung, kann man später im Rahmen der nachträglichen Problemanalyse die Server-Protokolle überprüfen. Funktioniert die Website immer noch nicht, kommt ein Neustart de IIS-Web-Servers infrage. Dazu gibt es mehrere Möglichkeiten:
Dienste stoppen gelegentlich. Wahrscheinlich schaltet man daraufhin Dutzende von Dienstausfallwarnungen ab. Aber es gäbe auch die Möglichkeit Dienste neu zu starten. Meistens hilft ein Neustart, um das Problem zu beseitigen. In diesem Fall gibt es folgende Möglichkeiten:
Alles bisher Besprochene bezieht sich auf Maßnahmen, die das Problem direkt beheben. In einigen Fällen kann Automatisierung jedoch auch defensiv und informativ sein. Konfigurationen von Netzwerkgeräten sind ein gutes Beispiel. Damit lassen sich zwar keine Probleme beheben, jedoch zusätzliche Informationen sammeln, mit deren Hilfe man das Problem später beheben kann.
Zwischen 40 und 80 Prozent aller Ausfallzeiten in Unternehmen entstehen durch unautorisierte oder unkontrollierte Änderungen an Netzwerkgeräten. Wenn sich also eine Gerätekonfiguration anhand eines Ereignisauslösers spontan abrufen lässt, ist das außerordentlich hilfreich. Zu diesem Zweck kann man folgendermaßen vorgehen:
New-SshSession
$Results = Invoke-Sshcommand -InvokeOnAll -Command "show run? | Out-File “
Remove-SshSession -RemoveAll
Das Ausführen dieser automatischen Aktion empfiehlt sich für zwei allgemeine Fälle. Erstens, wenn die Überwachungslösung eine Trap zu einer Konfigurationsänderung empfängt. Die Einzelheiten von SNMP-Traps würden an dieser Stelle zu weit führen. IT-Experten können jedoch ihre Netzwerkgeräte so konfigurieren, dass diese basierend auf bestimmten Ereignissen spontane Warnungen ausgeben. Eine Konfigurationsänderung gehört zu diesen Ereignissen.
Zweitens, wenn sich das Verhalten eines Geräts drastisch ändert, etwa wenn der Ping-Erfolg unter 75 Prozent sinkt oder die Ping-Latenz ansteigt. In beiden Fällen ist das Gerät dann bald nicht mehr verfügbar. Manchmal steht die Situation aber noch auf der Kippe und man kann sich ein Bild von der Konfiguration machen, bevor sie völlig ausfällt. In jedem Fall liefert die letzte Konfiguration wertvolle forensische Informationen, die bei der Problembehandlung hilfreich sein können. Gegebenenfalls kann man auch die absolut letzte als funktionierend bekannte Konfiguration wiederherstellen.