Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Übersicht über das -Framework
Der Rahmen für die Resilienzanalyse wurde entwickelt, indem die gewünschten Resilienzeigenschaften einer Arbeitslast ermittelt wurden. Bei den gewünschten Eigenschaften handelt es sich um die Dinge, die für das System gelten sollen. Resilienz wird in der Regel an der Verfügbarkeit gemessen. Daher sind fünf Eigenschaften die Merkmale eines hochverfügbaren verteilten Systems: Redundanz, ausreichende Kapazität, rechtzeitige Ausgabe, korrekte Ausgabe und Fehlerisolierung. Diese Eigenschaften sind in der folgenden Abbildung dargestellt.
-
Redundanz— Fehlertoleranz wird durch Redundanz erreicht, die Single Points of Failure (SPOFs) eliminiert. Die Redundanz kann sich von Ersatzkomponenten in Ihrem Workload bis hin zu vollständigen Replikaten Ihres gesamten Anwendungsstapels erstrecken. Wenn Sie Redundanz für Ihre Anwendungen in Betracht ziehen, ist es wichtig, den Grad der Redundanz zu berücksichtigen, den die Infrastruktur, die Datenspeicher und die Abhängigkeiten bieten, die Sie verwenden. Amazon DynamoDB und Amazon Simple Storage Service (Amazon S3) bieten beispielsweise Redundanz, indem sie Daten über mehrere Availability Zones in einer Region replizieren, undAWS Lambdaführt Ihre Funktionen über mehrere Worker-Knoten in mehreren Availability Zones aus. Berücksichtigen Sie bei jedem Service, den Sie verwenden, was der Service bietet und wofür Sie entwerfen müssen.
-
Ausreichende Kapazität— Ihr Workload benötigt ausreichend Ressourcen, um wie vorgesehen zu funktionieren. Zu den Ressourcen gehören Arbeitsspeicher, CPU-Zyklen, Threads, Speicher, Durchsatz, Servicekontingenten und viele andere.
-
Rechtzeitige Ausgabe— Wenn Kunden Ihren Workload nutzen, erwarten sie, dass er seine vorgesehene Funktion innerhalb eines angemessenen Zeitraums erfüllt. Sofern der Service kein Service ein Service Level Agreement (SLA) für die Latenz vorsieht, basieren ihre Erwartungen in der Regel auf empirischen Erkenntnissen, d. h. auf ihren eigenen Erfahrungen. Dasdurchschnittliches Kundenerlebniswird normalerweise als die mittlere Latenz (P50) in Ihrem System angesehen. Wenn Ihre Arbeitslast länger als erwartet dauert, kann sich diese Latenz auf das Kundenerlebnis auswirken.
-
Richtige Ausgabe— Die korrekte Ausgabe der Software Ihres Workloads ist erforderlich, damit dieser die beabsichtigte Funktionalität bereitstellen kann. Ein falsches oder unvollständiges Ergebnis kann schlimmer sein als gar keine Antwort.
-
Isolierung von Fehlern— Durch die Fehlerisolierung wird der Einflussbereich auf den vorgesehenen Fehlercontainer beschränkt, wenn ein Fehler auftritt. Sie stellt sicher, dass bestimmte Komponenten Ihres Workloads gleichzeitig ausfallen, und verhindert gleichzeitig, dass ein Ausfall auf andere unbeabsichtigte Komponenten übergreift. Es trägt auch dazu bei, den Umfang der Auswirkungen Ihres Workloads auf die Kunden zu begrenzen. Die Fehlerisolierung unterscheidet sich etwas von den vorherigen vier Eigenschaften, da sie akzeptiert, dass ein Fehler bereits aufgetreten ist, dieser aber eingedämmt werden sollte. Sie können eine Fehlerisolierung in Ihrer Infrastruktur, Ihren Abhängigkeiten und Softwarefunktionen einrichten.
Wenn eine gewünschte Eigenschaft verletzt wird, kann dies dazu führen, dass ein Workload nicht verfügbar ist oder als nicht verfügbar wahrgenommen wird. Basierend auf diesen gewünschten Resilienzeigenschaften und unserer Erfahrung in der Zusammenarbeit mit vielenAWSFür unsere Kunden haben wir fünf gängige Fehlerkategorien identifiziert: einzelne Fehlerquellen, übermäßige Auslastung, übermäßige Latenz, Fehlkonfigurationen und Bugs sowie Shared Fate, was wir mit SEEMS abkürzen. Diese bieten eine einheitliche Methode zur Kategorisierung potenzieller Fehlerarten und werden in der folgenden Tabelle beschrieben.
Kategorie des Fehlers |
Verstößt |
Definition |
|---|---|---|
Single Points of Failure (SPOFs) |
Redundanz |
Ein Ausfall einer einzelnen Komponente unterbricht das System aufgrund mangelnder Redundanz der Komponente. |
Übermäßige Belastung |
Ausreichende Kapazität |
Ein übermäßiger Verbrauch einer Ressource durch übermäßigen Bedarf oder übermäßigen Verkehr verhindert, dass die Ressource ihre erwartete Funktion erfüllt. Dies kann das Erreichen von Grenzwerten und Kontingenten beinhalten, was zu einer Drosselung und Ablehnung von Anfragen führen kann. |
Übermäßige Latenz |
Rechtzeitige Ausgabe |
Die Latenz bei der Systemverarbeitung oder beim Netzwerkverkehr überschreitet die erwartete Zeit, die erwarteten Service Level Objectives (SLOs) oder Service Level Agreements (SLAs). |
Fehlkonfiguration und Bugs |
Korrekte Ausgabe |
Softwarefehler oder eine Fehlkonfiguration des Systems führen zu einer falschen Ausgabe. |
Geteiltes Schicksal |
Isolierung von Fehlern |
Ein Fehler, der durch eine der vorherigen Fehlerkategorien verursacht wurde, überschreitet die Grenzen der vorgesehenen Fehlerisolierung und überträgt sich auf andere Teile des Systems oder auf andere Kunden. |
