Drei Strategien, um auf große Systemausfälle zu reagieren
In komplexen IT-System kann ein Ausfall einen Rattenschwanz an Folgeproblemen nach sich ziehen. Der Artikel stellt drei Ansätze vor, um auf diese Dominoeffekte zu reagieren.
Egal, ob sie am Netzwerk, der Cloud oder im Rechenzentrum beschäftigt sind: so gut wie jeden IT-Mitarbeiter packt das Grausen bei der Vorstellung, dass ein Dominoeffekt von Ausfällen durch das System rollt.
Wenn eine zentrale Ressource ausfällt, verursacht dies häufig eine Reihe von zusätzlichen Ausfällen in anderen Teilen des Systems, die von der ausgefallenen wichtigen Komponente abhängig waren. Diese sekundären Ausfälle wiederum verursachen selbst weitere Ausfälle, was zu einer Welle von Fehlermeldungen führt, angesichts derer das IT-Personal Schwierigkeiten hat, überhaupt zu verstehen, was passiert ist, geschweige denn zielgerichtet zu reagieren.
Die Virtualisierung verstärkt diesen Effekt noch: Das liegt erstens ihrer Natur als Lösung, mit der Ressourcen geteilt werden. Ein einzelner physischer Server beherbergt viele virtuelle Maschinen (VMs) beziehungsweise Container, von denen jeder einen unabhängigen Hosting-Ort darstellt.
Aus diesem Grund führt fast jeder Ausfall einer physischen Ressource in einer virtualisierten Infrastruktur zu einer Kaskade von Fehlern. Ein Ausfall kann somit ein Dutzend weitere verursachen, die dann Anwendungsfehler auslösen können, die wiederum Dutzende weitere Ausfälle in IT-Systemen verursachen.
Zweitens ist es für IT-Administratoren komplizierter, Probleme in einer virtualisierten Infrastruktur zu identifizieren und zu beheben als in einer physischen Infrastruktur; sie müssen das eigentliche Problem ausmachen, ohne eine 1:1-Beziehung zwischen Maschine und Anwendung annehmen zu können, und allein das kann einen beträchtlichen Aufwand bei der Zuordnung von virtuellen zu physischen Ressourcen bedeuten.
Als wäre das nicht schon schwierig genug, müssen Administratoren zeitgleich virtuelle Workloads neuen physischen Ressourcen zuweisen, um den ursprünglichen IT-Systemausfall auszugleichen. Durch solche Änderungen an der Lastenverteilung können sie aber negative Auswirkungen auf Anwendungen und Dienste verursachen, die gar nichts mit dem ursprünglichen Problem zu tun hatten. Häufig ist es unvermeidlich, dass beim Beheben von Fehlern neue entstehen.
Im Folgenden werden drei Ansätze vorgestellt, mit denen IT-Personal am besten auf einen solchen Dominoeffekt reagiert oder verhindert, dass es überhaupt so weit kommt. Die sogenannte Fehlerkorrelation ist eine Form der Ursachenanalyse (Root Cause Analysis), bei der es darum geht, ein Problem mit dessen Ursachen in Verbindung zu bringen.
Ein Verteilungs- oder Life-Cycle-Diagramm kodiert die Zuordnungen von virtuellen zu physischen Ressourcen, die mit einer Anwendung oder einem Service verbunden sind. Beim Einsatz von Kapazitätsplanung und adaptiven Ressourcen hingegen ignoriert das IT-Team gezielt Anwendungs- und Serviceprobleme, mit der Ausnahme, eine Untersuchung des Zustands physischer Ressourcen auszulösen. Jeder Ansatz hat seine Vorteile und Grenzen.
Fehlerkorrelation
Korrelation ist der traditionelle Ansatz zur Bewältigung von Fehlerlawinen. Es ist ein statistisches Konzept, das davon ausgeht, dass es eine gemeinsame Ursache geben muss, wenn mehrere Fehler innerhalb eines kurzen Zeitraums auftreten.
IT-Administratoren untersuchen den Zeitpunkt von Fehlern zusammen mit anderen Details, wie zum Beispiel deren Orten, um Fehler miteinander in Zusammenhang zu bringen und eine wahrscheinliche Grundursache abzuleiten. Bei mehreren Virtualisierungsebenen im IT-Stack wird es jedoch schwer, die Beziehungen zwischen den Fehlern zu erkennen, so dass es bei stark virtualisierten IT-Umgebungen am besten ist, sich nach anderen Optionen umzusehen.
Verteilungs- und Lifecycle-Diagramme
Eine Anwendung ist ein Satz von koordinierten Komponenten, die auf der Grundlage eines Regelwerks bereitgestellt werden. Netzwerkdienste und andere Aspekte des IT-Betriebs basieren auf einem ganz ähnlichen Konzept. IT-Teams können dies Regeln und Richtlinien anhand derer die Zuweisung von Ressourcen im korrekten Betrieb erfolgt, als Modelle aufzeichnen.
Sie bieten dann Orientierung bei der Suche nach Fehlerursachen und Durchführung von Korrekturmaßnahmen. Oft geben sie Administratoren den entscheidenden Hinweis darauf, wo das eigentliche Problem liegt und wie es in Zukunft vermieden werden kann.
DevOps, NetOps, Containerorchestrierung und die Topologie- und Orchestrierungsspezifikation für Cloud-Anwendungen von OASIS sind Beispiele für diesen modellgesteuerten Ansatz. Wenn Teams die Diagramme ordnungsgemäß entwerfen und laufend pflegen, eröffnen sie sich damit einen Weg, Probleme schnell zu isolieren und das Geflecht aus sekundären und primären Warnungen zu entwirren. Diese Modelle ermöglichen es den Teams auch, Anwendungen oder Netzwerkdienste wieder aufzubauen.
Dieser gesamte Prozess ist unter dem Konzept Lifecycle-Management zusammengefasst. Dieses muss aber durch ein oder mehrere kombinierte Tools unterstützt werden. Es ist nicht immer einfach, diese komplexen Modelle richtig zu entwerfen und zu pflegen oder sie mit den geeigneten Tools auszustatten. Inzwischen ist dieser Ansatz vor allem dort verbreitet, wo Virtualisierung und Cloud-Computing verwendet werden. Die Bereitstellung erfordert hier immer die Einrichtung bestimmter Bedingungen durch den Administrator.
Kapazitätsplanung und adaptive Ressourcen
Die letzte Strategie durchbricht zur Bewältigung des Dominoeffekts im Wesentlichen all diese Korrelationen und Analysen. Die Organisation erstellt auf der Grundlage der Kapazitätsplanung einen Pool von Ressourcen – wie zum Beispiel Server-Farmen – für eine bestimmte Anwendung oder Anwendungen.
Eine Kombination aus richtlinienbasierten Modellen und flexiblem Kapazitäteneinsatz ist der beste Weg, um in einer Flut von IT-Systemausfällen nicht ins Schwimmen zu kommen.
Die verfügbaren Ressourcen werden auf die erwartete Last und erforderliche Servicequalität abgestimmt. IT-Administratoren konzentrieren sich dann darauf, sicherzustellen, dass die Ressourcen gemäß dieses Kapazitätsplans arbeiten, und behandeln nur Fehler an den physischen Ressourcen. Wenn eine Anwendung oder ein Dienst ausfällt, siedeln die Teams sie einfach auf funktionierende physische Ressourcen um und gehen davon aus, dass dies das Problem beheben und vertrauen darauf, dass die Kapazität vorhanden ist, um mit der Veränderung umzugehen.
Dieses Modell kann bei einem sich selbst anpassenden Ressourcen-Pool noch ausgeweitet werden, nämlich indem das System Fehler automatisch vermeidet oder umgeht. In IP-Netzwerken kann beispielsweise Dynamic Source Routing ohne jegliches Eingreifen menschlicher Mitarbeiter den Datenverkehr um Engpässe oder Ausfälle herumleiten. IT-Teams müssen weder Dienste oder Anwendungen reparieren noch das Routing manuell durchführen. Infrastructure as Code Frameworks (IaC) zielen ebenfalls auf diese Selbstheilungsfähigkeit ab.
Der Ansatz die Ressourcen zu reparieren, nicht den Ausfall, hat noch einen weiteren Vorteil: Statt sich auf der Suche nach der Ursache durch das Beziehungsgeflecht zwischen virtuellen und physischen Ressourcen zu wühlen, können IT-Administratoren sich einfach auf letztere konzentrieren.
Eine Kombination aus richtlinienbasierten Modellen und flexiblem Kapazitäteneinsatz ist wahrscheinlich der beste Weg, um in einer Flut von IT-Systemausfällen nicht ins Schwimmen zu kommen. Große Organisationen mit umfangreichen Server-Farmen oder Cloud-Budgets verfügen über die Mittel, die Gefahr mit Kapazitätsplanung und adaptiven Ressourcen einzudämmen, während diejenigen mit eingeschränkteren Ressourcen eher vom modellbasierten Ansatz profitieren.
Jedes Administratorenteam sollte sorgfältige Planung und gründliches Management laufender Aktivitäten gewährleisten – andernfalls können selbst die besten Fehlerbehebungstechniken nichts mehr retten.
