Patching: Ausfall statt Heilung

Sie gehören zum unangenehmen Teil der IT-Betreuung. Minimal einmal pro Monat – meist öfter – senden Hersteller ihre Software-Flicken über den IT-Äther zum Download. Doch was ist, wenn das Update den Rechner unbrauchbar macht?

Vom Patch-Dienstag und anderen Unannehmlichkeiten

Einmal pro Monat, jeden zweiten Dienstag, bringt Microsoft seine Software-Pakete auf Vordermann. Meist werden Sicherheitslücken geschlossen, manchmal Bugs bereinigt. Andere Hersteller sind weniger berechenbar, aber auch nicht weniger nervend (haben Sie schon einmal die Anzahl der installierten Flash-Updates gezählt?).

Für den Administrator – sei es auf PC- oder Serverseite – heißt dies, den Rollout organisieren und nach dem Neustart die Funktionalität prüfen. Im Unternehmensumfeld kommt dabei für Microsoft-Updates meist der WSUS zum Einsatz. Dies erleichtert die Kontrolle einer erfolgreichen Installation und notfalls etwaige Nacharbeiten. Die meisten Firmen verzichten vollständig auf jede Art von Client-Management (siehe eine Kaspersky-Studie). Doch was tun, wenn ausgerechnet ein Patch den Server funktionsuntüchtig macht?

Hoffen und Beten?

Diesen Monat ist es passiert. Der Albtraum jedes Server-Admins ist eingetreten. Ein von Microsoft veröffentlichter Patch hatte – auf manchen Systemen – zur Folge, dass diese teilweise nicht mehr starteten. Auf anderen Systemen funktionierten einzelne Applikationen nicht mehr. Betroffen waren Systeme mit Windows 7 und Server 2008 als Betriebssystem.

Die Möglichkeiten des Administrators im Vorfeld sind marginal. Welches Unternehmen leistet sich schon Testumgebungen, um Patches vorab zu prüfen? Und ein Testsystem tut es nicht, da kein Rechner dem anderen im Software-Setup gleicht. Da hilft nur das stille Hoffen, dass die Programmierer aus Redmond ihren Job gut erledigt haben, oder?

Nicht ohne Netz

Im aktuellen Fall rät Microsoft zur Deinstallation des Updates, wenn dieses bereits auf dem Rechner installiert wurde. Hilft bloß nicht viel, da es zu diesem Zeitpunkt nur zwei Varianten gibt: der Rechner funktioniert, oder nicht. Für den Fall, dass der neue Code den PC oder Server lahmlegt, wird die Rückkehr zu einem vorherigen Wiederherstellungspunkts nahegelegt. Ansonsten bleibt nur noch die Rettungskonsole und manuelle Arbeit.

Im PC-Umfeld mag diese „Rettungstechnik“ noch ihren Platz finden, wenngleich es in größeren Umgebungen dennoch zu massiven Produktionsausfällen führen wird. Die Heilung der Server ist auf diese Weise – Rückkehr zu einem vorhergehenden Systemzustand – meist gar nicht möglich. Abhängig von der Funktion des Servers kann ein Zurückdrehen des Status zusätzliche (schlechte) Auswirkungen auf den Betrieb haben.

Snapshots und Wiederherstellungspunkte

Virtualisierte Serversysteme haben für gewagte Änderungen am System ein schönes Zusatzfeature: den Snapshot. Dabei wird der aktuelle Zustand des Systems von der Virtualisierungssoftware „eingefroren“. Ab diesem Zeitpunkt werden alle Änderungen am System getrennt gespeichert, was die Rückkehr zur Ursprungszustand ermöglicht. Zum Unterschied eines Windows-Recovery-Points umfasst der Snapshot das gesamte Dateisystem des Servers und nicht nur dessen System.

So schön sich diese Möglichkeit auch anhört (und manchmal in der Praxis auch ist): Auch hier ist Vorsicht geboten. So kann etwas ein Active-Directory Schaden nehmen, da die Kommunikation mit anderen Domain-Controllern nicht so einfach auf einen älteren Stand zurückgesetzt werden kann. Gleiches gilt für einen Applikationsserver, der in eine Datenbank auf einem anderen Server schreibt. Auch hier gilt es, die Datenkonsistenz auf beiden Systemen zu berücksichtigen.

Für den Notfall gerüstet

Die Wiederherstellungskonsole im Microsoft-Umfeld ist sicherlich eine gute Waffe im Kampf mit Systemfehlern, die tief im Betriebssystem liegen. Für lange Fehlerrecherchen wird dem Administrator aber keine Zeit gegeben. Schließlich gilt es, die Ausfallzeit auf ein Minimum zu begrenzen.

Als letzter Rettungsanker gab und gibt es nur eines: ein funktionierendes Backup-System. Unmittelbar vor jeder Patch-Arbeit müssen alle betroffenen Server vollständig gesichert werden (Desaster-Recovery). Auch hier ist Virtualisierung der Freund des Administrator (siehe den Beitrag zum Thema Virtualisierung und Backup). Eine vollständige Wiederherstellung eines virtuellen Gastsystems ist – das richtige Backup-System vorausgesetzt – keine große Sache. Aber auch hier kann die Abhängigkeit der einzelnen Systeme zueinander aus einer Standardaufgabe eine Herausforderung machen.

Planung und Hoffen

Werden die genannten Punkte berücksichtigt, so bleibt dem IT-Admin nur noch eine Aufgabe: die Planung der regelmäßigen Patches. Obwohl aus Sicht der Sicherheit jede Softwarelücke so schnell wie möglich geschlossen werden sollte, kann ein wenig Abwarten manchmal nicht schaden. Hier ist allerdings der Grat zwischen Funktionalität und Fahrlässigkeit ein schmaler. Vor allem bei Systemen, die von außen zugänglich sind (Webserver, Systeme in der DMZ, etc.), spielt der Zeitverzug eines Patchvorgangs eine große Rolle. Bei anderen kann hier etwas toleranter agiert werden. Die Planung des Patchvorgangs hat hier jeden Server individuell zu berücksichtigen.

Ein entscheidender Punkt der Planung betrifft den Zeitpunkt des Patchvorgangs. Hier ist ein Zeitpuffer der große Freund des Administrators. Erfolgen die Updates am Abend oder Wochenende, so bleiben im Fehlerfall vielleicht einige Stunden mehr, um die Ursache zu finden und zu beheben. Systeme, die rund um die Uhr verfügbar sein müssen, sollten ohnehin redundant ausgelegt sein. Der Ausfall eines Cluster-Nodes bringt damit nicht sofort alles zum Stillstand.

Außer einem funktionierenden Backup-System und alle Punkte der Planung bleibt dann wirklich nur noch eines: Hoffen.