Was sind Kaskadenfehler?

Was sind Kaskadenfehler?

  • ITOps & DevOps
6 Minuten Lesezeit Aktualisiert Jun 3, 2020

Auf einen Blick: Kaskadierende Ausfälle treten in komplexen Systemen auf, wenn kleine Fehler aufgrund von Überlastungen und Rückkopplungsschleifen zu weit verbreiteten Zusammenbrüchen führen. Die Wiederherstellung ist oft herausfordernd und kann einen vollständigen Systemabschaltung erfordern.

  • Kaskadierende Ausfälle können systemweite Ausfälle verursachen.
  • Eine effektive Wiederherstellung erfordert in der Regel einen vollständigen Neustart des Systems.

In komplexen Computersystemen besteht weiterhin ein ständiges Risiko kleiner Fehler. Manchmal kümmern sich diese Fehler um ihre eigenen Angelegenheiten und alles kehrt schnell zur Normalität zurück. Manchmal verursacht ein Fehler ein weiteres verwandtes Problem, das wiederum in den ursprünglichen Fehler oder vielleicht in einen anderen Teil des Systems zurückfließt. Der daraus resultierende Dominoeffekt zunehmender Ausfälle aufgrund positiver Rückkopplungsmechanismen wird als Kaskadenausfall bezeichnet.

Rückkopplungsmechanismen

Eigenständige Fehler stellen für Systeme eine viel geringere Bedrohung dar als solche, die zu Rückkopplungsschleifen beitragen. In einer solchen Rückkopplungsschleife können verteilte Softwaresysteme zunächst eine relativ geringe Kapazitätsreduktion, einen Anstieg der Fehler oder eine Zunahme der Latenz erleben. Wenn andere Teile des Systems versuchen, auf das ursprüngliche Problem zu reagieren und es zu beheben, verschlimmern sie es am Ende.

Zum Beispiel könnte ein Server in einer Gruppe von Servern, die zusammenarbeiten, eine Überlast erleben, die zum Ausfall führt. Regelmäßig würde er einen kleinen Überschuss auf einen benachbarten Server abgeben, der als Backup fungiert und gleichzeitig seine eigene Last aufrechterhält. Aber dieser zweite Server kann nach dem vollständigen Ausfall des ersten Servers nicht mehr zwei vollständige Lasten bewältigen, daher fällt er ebenfalls aus.

Die überschüssigen Lasten werden weiter über die benachbarten Server verteilt und wachsen zu immer größeren Überlasten, bis das gesamte System zusammenbricht.  Diese Art von Kaskadenausfall ist eine Mischung aus Überlastung und proximitätsbasierten Failover-Feedback-Auslösern, wie unten erwähnt.

Rückkopplungsauslöser von kaskadierenden Ausfällen

Mehrere Auslöser können den typischen Kaskadenausfall erklären, sowohl einzeln als auch in Verbindung miteinander, darunter:

  • Lastspitzen und Überlastung
  • Proximity-basiertes Failover
  • Prozess-Tod/Abfrage des Todes
  • Übermäßiges Wiederholungsverhalten von Klienten
  • Ressourcenerschöpfung
  • Ressourcenbeschränkungen
  • Ressourcenabhängigkeit
  • CPU-Probleme
  • Gedächtnisprobleme
  • Fadenhunger
  • Neue Ausführungen und Änderungen
  • Organisches Wachstum
  • Lange Startzeiten
  • Verschobener Verkehrsmix

Wenn Ihr System noch nie einen Kaskadenausfall erlebt hat, lassen Sie sich nicht in falsche Sicherheit locken. Jederzeit kann Ihr System versuchen, außerhalb seiner Grenzen zu arbeiten, was zu einem unerwarteten Problem führen kann.

Einige dieser Auslöser sind durch die richtige Strukturierung und Verwaltung eines Systems vermeidbar. Andere sind im Wesentlichen unvermeidbar, können aber durch Untersuchung ihrer Funktionsweise vorbereitet und gemildert werden, bevor sie erhebliche Probleme verursachen.

Zum Beispiel sind Lastspitzen ein erwarteter Teil des Systembetriebs und der häufigste Rückkopplungsauslöser für kaskadierende Ausfälle. Sie können sie nicht vernünftigerweise stoppen, aber Sie können steuern, wie Ihr System darauf reagiert. Während das Aufgabenplanungssystem und der Load Balancer typische Lasten auf eine Weise verwalten, die normalerweise funktioniert, sollten sie auch auf abnormale Lasten vorbereitet sein. Wenn die Last über den Durchschnitt hinaus steigt, müssen sie möglicherweise neue Taktiken einsetzen, um einen Kaskadenausfall zu verhindern.

Erholung von einem Kaskadenausfall

Unabhängig vom Auslöser ist die Erholung von einem Kaskadenausfall fast immer äußerst schwierig. Häufig erfordert das System einen vollständigen Abschalten, weil es sich ohne manuelles Eingreifen nicht mehr restabilisieren kann.

Warum ist es so schwierig?

Wenn dein System die richtigen Bedingungen für einen Kaskadenausfall enthält, hast du wahrscheinlich keine Ahnung und das Ereignis tritt fast sofort ohne jede Vorwarnung ein. Und sobald es begonnen hat, besteht kaum eine Chance, es zu verlangsamen oder zu stoppen. Der Zustand des Systems wird meist immer schlechter, ohne dass sich in irgendeiner Weise selbst heilt.

Viele Teams haben vielleicht den Instinkt, das System durch das Hinzufügen von mehr Kapazität wiederherzustellen. Aber auch das trägt wahrscheinlich nur zum positiven Feedback des Ausfalls bei. Wenn du eine neue gesunde Instanz hinzufügst, wird sie sofort von der überschüssigen Last anderer ausfallender Instanzen getroffen. Eine so große Last sättigt die neue Instanz, sodass sie ausfällt, bevor sie helfen kann, und die Möglichkeit ausschließt, dass du einen Punkt erreichen kannst, an dem du genügend Bedienkapazität hast, um die Last zu bewältigen.

Das System im Voraus so einzurichten, dass nicht alle Anfragen nur an gesunde Instanzen gesendet werden, könnte diese Art von Problem verhindern und einen Kaskadierenausfall verlangsamen oder stoppen. Ohne solche Voraussicht ist es jedoch oft nur möglich, sich von einem Kaskadenausfall zu erholen, den gesamten Service herunterzufahren und dann die Last wieder einzuführen.

Taktiken zur Behebung eines Fehlers

Wenn Ihr System bereits einen Kaskadenausfall erlebt, gibt es einige Schritte, die Sie unternehmen können, um dies sofort zu beheben, bevor Sie zu einem vollständigen Systemabschalten greifen. Überprüfen Sie zunächst, ob überlastete Kapazitäten nicht auf ungenutzte Ressourcen zurückzuführen sind. Das Hinzufügen von leeren Ressourcen zu den aktiven Aufgaben kann ein System schnell wiederherstellen, wenn die Last nicht zu groß ist.

Wenn alle Ressourcen aktiv teilnehmen, kann ein verändertes Gesundheitscheck-Verhalten die Spirale stoppen. Wenn das System die Gesundheit von Aufgaben überprüft, stellt es fest, dass viele Aufgaben ungesund sind und andere neu gestartet werden. Daher wird typischerweise unverhältnismäßige Belastungen an die wenigen verbliebenen gesunden Instanzen gesendet, wodurch auch diese ungesund werden.

Das vorübergehende Deaktivieren oder Ändern des Verhaltens dieser Art von Selbstgesundheitsprüfungen könnte helfen, das System wieder zu stabilisieren. Eine Möglichkeit ist, dass das System zwischen völlig nicht reagierenden und vorübergehend nicht reagierenden Aufgaben unterscheidet, sodass letztere Typen in die Lastverteilung aufgenommen werden können.

Eine drastischere Reaktion auf einen Kaskadenausfall ist es, den Datenverkehr zu verlieren und in degradierte Modi zu wechseln. Diese Taktik erfordert eine gewisse Aggression, um zu funktionieren, wobei der Datenverkehr erheblich auf etwa 1 % der regulären Raten reduziert wird. Mit der Erholung der Server kann nach und nach mehr Verkehr durchgehen. Wenn die Last wieder auf normales Niveau zurückkehrt, können die Caches sich erwärmen und Verbindungen herstellen, aber die Nutzer werden eine sehr negative Erfahrung machen.

Die Reduzierung des Datenverkehrs auf diese Weise muss gleichzeitig mit einer Reparatur des zugrundeliegenden Problems implementiert werden. Andernfalls kann es zu einem zweiten Kaskadenausfall kommen, sobald die Wiederherstellung abgeschlossen ist und der Verkehr wieder normal ist. Wenn dem Computer der Speicher ausgeht oder das System nicht genügend Kapazität hat, sollten Sie vor dem Versuch, den Datenverkehr wieder einzuführen, mehr Speicher oder Aufgaben hinzufügen.

Darüber hinaus können Systeme, die in der Lage sind, verschiedene Verkehrsarten zu unterscheiden, weniger wichtigen oder schlechten Verkehr gezielt eliminieren. Dies muss bereits Teil der Systemfunktionen sein, aber es kann eine Priorisierung des durchgehenden Verkehrs ermöglichen, um negative Folgen zu verringern.

Ebenso kann die Diskriminierung weniger wichtiger Lastchargen die Belastung von Aufgaben verringern und negative Ergebnisse minimieren. Das Anhalten von Quellen wie Statistikerfassung, Datenkopien und Indexupdates kann zu einer Wiederherstellung beitragen.

Wenn all diese Strategien den Kaskadenausfall nicht stoppen können, ist ein vollständiger Systemabschaltung wahrscheinlich die einzige verbleibende Option.

Kaskadierende Ausfälle verhindern, bevor sie beginnen

Überlastete Server verhindern

Da Überlastung der häufigste Auslöser ist, kann der Fokus auf Überlastvermeidung wesentlich dazu beitragen, kaskadierende Ausfälle zu vermeiden. Um Überlastung zu vermeiden, sollten Sie die Anzahl der eingehenden Anfragen an das System begrenzen. Das Annehmen einer unbegrenzten Anzahl von Anfragen kann riesige Warteschlangen von Anfragen und gleichzeitigen Threads erzeugen, die während eines kaskadierenden Ausfalls ausgeführt werden wollen.

Diese Ansammlung führt dazu, dass das System nicht mehr reagiert, was häufig ein Eingreifen oder Neustart erfordert. Um dies zu vermeiden, sollten Sie das Wiederversuchsverhalten des Clients mäßigen, um Überflutungen von erneuten Anfragen zu vermeiden, die Last pro Instanz zu begrenzen und Lastabschaltungen an einem Lastausgleicher in Betracht ziehen. Letzteres setzt einige Grenzen für Ihren Dienst, aber ebenso die Alternative eines Kaskadenausfalls.

Durchführung von Tests

Wenn es um andere potenzielle Feedback-Auslöser geht, merkt man manchmal nicht einmal, dass das System eine unzureichende Einrichtung oder Reaktion hat. Der beste Weg, herauszufinden, wie es problematische Situationen handhabt, ist, es gegen sie zu testen.

Fuzz-Tests können helfen, Programme zu erkennen, die bei schlechten Eingaben, auch bekannt als Queries of Death, abstürzen. Anstatt abzustürzen, sollte ein Programm erkennen können, ob sein interner Zustand Sicherheitsbedenken darstellt, und so reagieren, dass es keinen Absturz verursacht. Diese Art von Tests ist besonders nützlich für Dienste, die häufig Eingaben von außerhalb der Organisation erhalten.

Testen Sie neben der Last das Verhalten der Clienten und nicht-kritische Backends. Clients sollten ihre Arbeit in der Warteschlange einordnen können, während das System offline ist, und sie sollten bei Fehlern exponentiell zurückfahren. Gleichzeitig sollte die Nichtverfügbarkeit von Backends während eines Ausfalls die kritischeren Teile des Systems nicht beeinträchtigen.

Berücksichtigen Sie bei jeglichen Tests sowohl allmähliche als auch impulsive Musteränderungen. Das System kann gut auf allmähliche Lastanstiege reagieren, aber bei einem plötzlichen Spitzenanstieg abstürzen. Und sobald ein Ausfall im System auftritt, werden Sie weiter getestet, um zu sehen, ob und wie es sich wiederherstellen kann.

Nachdem Sie die für Ihr System einzigartigen Probleme identifiziert haben, können Sie entsprechende Änderungen umsetzen. Die Änderung der Systemeinrichtung und die Verbesserung der Reaktionsfähigkeit können Kaskadenausfälle abmildern und sogar vollständig verhindern.

Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.

Mehr aus ITOps & DevOps

Interessieren Sie sich für mehr von BMC?

The Brief ist unsere monatliche E-Mail zum Mainframe und zur Enterprise-Orchestrierung: Recherchen, Kundenberichte, Produktnachrichten, Events.

Mit der Registrierung für dieses Angebot bestätigen Sie, dass Sie die Datenschutzrichtlinie von BMC gelesen und zugestimmt haben.

Sie haben The Brief abonniert

Das Briefing umfasst die Mainframe- und Enterprise-Orchestrierung – BMC AMI und Control-M – sowie die Analystenforschung, Kundeneinsätze und Events in beiden Bereichen.