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.
# Verfügbarkeit verstehen
Verfügbarkeit ist eine der wichtigsten Methoden, mit denen wir die Ausfallsicherheit quantitativ messen können. Wir definieren Verfügbarkeit, *A*, als den Prozentsatz der Zeit, in der ein Workload zur Nutzung verfügbar ist. Es ist ein Verhältnis der erwarteten „Verfügbarkeit“ (Verfügbarkeit) zur gemessenen Gesamtzeit (der erwarteten „Betriebszeit“ plus der erwarteten „Ausfallzeit“).
![\[Bild der Gleichung. A = Verfügbarkeit/(Betriebszeit + Ausfallzeit)\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/availability-and-beyond-improving-resilience/images/availability.png)
Um diese Formel besser zu verstehen, schauen wir uns an, wie Verfügbarkeit und Ausfallzeit gemessen werden können. Zunächst möchten wir wissen, wie lange der Workload fehlerfrei sein wird. Das nennen wir MTBF (*Mean Time Between Failure*). Dabei handelt es sich um die durchschnittliche Zeit zwischen der Aufnahme des Normalbetriebs eines Workloads und seinem nächsten Ausfall. Dann möchten wir wissen, wie lange die Wiederherstellung nach einem Ausfall dauern wird.
Wir nennen das *Mean Time to Repair (or Recovery) (MTTR)*. Dabei handelt es sich um einen Zeitraum, in dem der Workload nicht verfügbar ist, während das ausgefallene Subsystem repariert oder wieder in Betrieb genommen wird. Ein wichtiger Zeitraum in der MTTR ist die *mittlere Zeit bis zur Erkennung* (MTTD), also die Zeitspanne zwischen dem Auftreten eines Fehlers und dem Beginn der Reparaturvorgänge. Das folgende Diagramm zeigt, wie all diese Metriken zusammenhängen.
![\[Diagramm, das die Beziehung zwischen MTTD, MTTR und MTBF zeigt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/availability-and-beyond-improving-resilience/images/availability-metrics.png)
Somit können wir die Verfügbarkeit *A* mithilfe von MTBF, der Zeit, zu der die Arbeitslast hoch ist, und MTTR, der Zeitpunkt, zu dem die Arbeitslast ausgefallen ist, ausdrücken.
![\[Bild der Gleichung. A = MTBF/(MTBF + MTTR)\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation2.png)
*Und die Wahrscheinlichkeit, dass die Arbeitslast „ausgefallen“ ist (d. h. nicht verfügbar), ist die Ausfallwahrscheinlichkeit F.*
![\[Bild der Gleichung. F = 1 - A\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation3.png)
[Zuverlässigkeit](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/reliability.html) ist die Fähigkeit eines Workloads, auf Anfrage innerhalb der angegebenen Reaktionszeit das Richtige zu tun. Das ist es, was Verfügbarkeit misst. Wenn ein Workload seltener ausfällt (längere MTBF) oder eine kürzere Reparaturzeit (kürzere MTTR) hat, verbessert sich die Verfügbarkeit.
**Regel 1**
Weniger häufige Ausfälle (längere MTBF), kürzere Fehlererkennungszeiten (kürzere MTTD) und kürzere Reparaturzeiten (kürzere MTTR) sind die drei Faktoren, die zur Verbesserung der Verfügbarkeit in verteilten Systemen verwendet werden.
**Topics**
+ [Verfügbarkeit verteilter Systeme](distributed-system-availability.md)
+ [Verfügbarkeit mit Abhängigkeiten](availability-with-dependencies.md)
+ [Verfügbarkeit mit Redundanz](availability-with-redundancy.md)
+ [Satz von CAP](cap-theorem.md)
+ [Fehlertoleranz und Fehlerisolierung](fault-tolerance-and-fault-isolation.md)
# Verfügbarkeit verteilter Systeme
Verteilte Systeme bestehen sowohl aus Software- als auch aus Hardwarekomponenten. Einige der Softwarekomponenten können selbst ein anderes verteiltes System sein. Die Verfügbarkeit sowohl der zugrunde liegenden Hardware- als auch der Softwarekomponenten wirkt sich auf die daraus resultierende Verfügbarkeit Ihres Workloads aus.
Die Berechnung der Verfügbarkeit mithilfe von MTBF und MTTR hat ihre Wurzeln in Hardwaresystemen. Verteilte Systeme scheitern jedoch aus ganz anderen Gründen als ein Teil der Hardware. Während ein Hersteller konsistent die durchschnittliche Zeit berechnen kann, bis eine Hardwarekomponente abgenutzt ist, können dieselben Tests nicht auf die Softwarekomponenten eines verteilten Systems angewendet werden. Hardware folgt in der Regel der „Badewannenkurve“ der Ausfallrate, während Software einer gestaffelten Kurve folgt, die durch zusätzliche Fehler verursacht wird, die mit jeder neuen Version auftreten (siehe [Softwarezuverlässigkeit](https://users.ece.cmu.edu/~koopman/des_s99/sw_reliability)).
![\[Diagramm, das die Ausfallraten von Hardware und Software zeigt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/availability-and-beyond-improving-resilience/images/failure-rates.png)
Darüber hinaus ändert sich die Software in verteilten Systemen in der Regel exponentiell schneller als die Hardware. Beispielsweise kann eine magnetische Standardfestplatte eine durchschnittliche jährliche Ausfallrate (AFR) von 0,93% aufweisen, was in der Praxis für eine Festplatte eine Lebensdauer von mindestens 3—5 Jahren bedeuten kann, bevor sie den Verschleißzeitraum erreicht, möglicherweise länger (siehe [Backblaze](https://www.backblaze.com/b2/hard-drive-test-data.html) Hard Drive Data and Stats, 2020). Die Festplatte ändert sich während dieser Lebensdauer nicht wesentlich. In 3 bis 5 Jahren könnte Amazon beispielsweise mehr als 450 bis 750 Millionen Änderungen an seinen Softwaresystemen vornehmen. (Siehe [Amazon Builders' Library — Automatisieren sicherer, automatischer Bereitstellungen.)](https://aws.amazon.com/about-aws/whats-new/2020/06/new-abl-article-automating-safe-hands-off-deployments/)
Hardware unterliegt auch dem Konzept der geplanten Obsoleszenz, d. h. sie hat eine feste Lebensdauer und muss nach einer bestimmten Zeit ausgetauscht werden. (Siehe [Die große Glühbirnenverschwörung](https://spectrum.ieee.org/tech-history/dawn-of-electronics/the-great-lightbulb-conspiracy).) Software unterliegt theoretisch nicht dieser Beschränkung, sie hat keine Abnutzungszeit und kann unbegrenzt betrieben werden.
All dies bedeutet, dass dieselben Test- und Prognosemodelle, die für Hardware zur Generierung von MTBF- und MTTR-Zahlen verwendet werden, nicht für Software gelten. Seit den 1970er Jahren gab es Hunderte von Versuchen, Modelle zur Lösung dieses Problems zu entwickeln, aber sie lassen sich im Allgemeinen alle in zwei Kategorien einteilen: Vorhersagemodellierung und Schätzmodellierung. (Siehe [Liste der Modelle zur Softwarezuverlässigkeit](https://en.wikipedia.org/wiki/List_of_software_reliability_models).)
Daher wird die Berechnung einer vorausschauenden MTBF und MTTR für verteilte Systeme und somit einer vorausschauenden Verfügbarkeit immer von einer Art von Vorhersage oder Prognose abgeleitet. Sie können durch prädiktive Modellierung, stochastische Simulation, historische Analysen oder strenge Tests generiert werden, aber diese Berechnungen sind keine Garantie für Verfügbarkeit oder Ausfallzeit.
Die Gründe, warum ein verteiltes System in der Vergangenheit ausgefallen ist, werden sich möglicherweise nie wiederholen. Die Gründe, warum es in future scheitert, sind wahrscheinlich unterschiedlich und möglicherweise nicht erkennbar. Die erforderlichen Wiederherstellungsmechanismen können sich auch für future Ausfälle von denen unterscheiden, die in der Vergangenheit verwendet wurden, und sie können erheblich unterschiedliche Zeiträume in Anspruch nehmen.
Außerdem handelt es sich bei MTBF und MTTR um Durchschnittswerte. Es wird eine gewisse Abweichung zwischen dem Durchschnittswert und den tatsächlich gemessenen Werten geben (die Standardabweichung, σ, misst diese Variation). Daher kann es bei Workloads im Produktionsbetrieb zu kürzeren oder längeren Zeitabständen zwischen Ausfällen und Wiederherstellungen kommen.
Davon abgesehen ist die Verfügbarkeit der Softwarekomponenten, aus denen ein verteiltes System besteht, nach wie vor wichtig. Software kann aus zahlreichen Gründen ausfallen (mehr dazu im nächsten Abschnitt) und beeinträchtigt die Verfügbarkeit der Arbeitslast. Daher sollte bei hochverfügbaren verteilten Systemen der Schwerpunkt auf die Berechnung, Messung und Verbesserung der Verfügbarkeit von Softwarekomponenten ebenso gelegt werden wie auf Hardware- und externe Softwaresubsysteme.
**Regel 2**
Die Verfügbarkeit der Software in Ihrem Workload ist ein wichtiger Faktor für die Gesamtverfügbarkeit Ihres Workloads und sollte ebenso berücksichtigt werden wie andere Komponenten.
Es ist wichtig zu beachten, dass MTBF und MTTR für verteilte Systeme zwar schwer vorherzusagen sind, sie aber dennoch wichtige Erkenntnisse zur Verbesserung der Verfügbarkeit bieten. Die Verringerung der Ausfallhäufigkeit (höhere MTBF) und die Verkürzung der Wiederherstellungszeit nach einem Ausfall (niedrigere MTTR) werden beide zu einer höheren empirischen Verfügbarkeit führen.
## Arten von Ausfällen in verteilten Systemen
In verteilten Systemen gibt es im Allgemeinen zwei Arten von Fehlern, die sich auf die Verfügbarkeit auswirken. Sie werden liebevoll *Bohrbug und *Heisenbug** genannt (siehe [„A Conversation with Bruce Lindsay“, ACM Queue Band 2, Nr. 8 — November 2004).](http://queue.acm.org/detail.cfm?id=1036486)
Ein Bohrbug ist ein wiederholbares funktionales Softwareproblem. Bei derselben Eingabe erzeugt der Fehler immer dieselbe falsche Ausgabe (wie das deterministische Bohr-Atommodell, das solide und leicht zu erkennen ist). Diese Arten von Fehlern treten selten auf, wenn ein Workload in Betrieb genommen wird.
Ein Heisenbug ist ein vorübergehender Fehler, was bedeutet, dass er nur unter bestimmten und ungewöhnlichen Bedingungen auftritt. Diese Bedingungen beziehen sich normalerweise auf Dinge wie Hardware (z. B. ein vorübergehender Gerätefehler oder Besonderheiten der Hardwareimplementierung wie die Registergröße), Compileroptimierungen und Sprachimplementierung, Grenzbedingungen (z. B. vorübergehender Speichermangel) oder Race-Bedingungen (z. B. die Nichtverwendung einer Semaphore für Multithread-Operationen).
Heisenbugs machen den Großteil der Fehler in der Produktion aus und sind schwer zu finden, da sie schwer zu finden sind und ihr Verhalten zu ändern scheinen oder zu verschwinden scheinen, wenn man versucht, sie zu beobachten oder zu debuggen. Wenn Sie das Programm jedoch neu starten, wird der fehlgeschlagene Vorgang wahrscheinlich erfolgreich sein, da die Betriebsumgebung etwas anders ist, wodurch die Bedingungen, die den Heisenbug verursacht haben, beseitigt sind.
Daher sind die meisten Produktionsausfälle vorübergehender Natur, und wenn der Vorgang erneut versucht wird, ist es unwahrscheinlich, dass er erneut fehlschlägt. Um widerstandsfähig zu sein, müssen verteilte Systeme fehlertolerant gegenüber Heisenbugs sein. Wie dies erreicht werden kann, werden wir im Abschnitt [Erhöhung der MTBF für verteilte Systeme](increasing-mtbf.md#increasing-mtbf.title) untersuchen.
# Verfügbarkeit mit Abhängigkeiten
Im vorherigen Abschnitt haben wir erwähnt, dass Hardware, Software und möglicherweise andere verteilte Systeme allesamt Komponenten Ihres Workloads sind. Wir nennen diese Komponenten *Abhängigkeiten, also* die Dinge, von denen Ihr Workload abhängt, um seine Funktionalität bereitzustellen. Es gibt *harte* Abhängigkeiten, also Dinge, ohne die Ihr Workload nicht funktionieren kann, und *weiche* Abhängigkeiten, deren Nichtverfügbarkeit für einen gewissen Zeitraum unbemerkt bleiben oder toleriert werden kann. Harte Abhängigkeiten wirken sich direkt auf die Verfügbarkeit Ihres Workloads aus.
Vielleicht möchten wir versuchen, die theoretische maximale Verfügbarkeit eines Workloads zu berechnen. Dies ist das Produkt der Verfügbarkeit aller Abhängigkeiten, einschließlich der Software selbst (*α* *n* ist die Verfügbarkeit eines einzelnen Subsystems), da jedes einzelne Subsystem betriebsbereit sein muss.
![\[Bild der Gleichung. A = α 1 X α 2 X... X α n Tiefpunkt>\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation4.png)
Die in diesen Berechnungen verwendeten Verfügbarkeitszahlen beziehen sich normalerweise auf Dinge wie SLAs oder Service Level Objectives (SLOs). SLAs definieren das erwartete Serviceniveau, das Kunden erhalten, die Kennzahlen, anhand derer der Service gemessen wird, und Abhilfemaßnahmen oder Strafen (in der Regel monetär) für den Fall, dass das Serviceniveau nicht erreicht wird.
Anhand der obigen Formel können wir schlussfolgern, dass ein Workload rein mathematisch gesehen nicht mehr verfügbar sein kann als jede seiner Abhängigkeiten. In der Realität sehen wir jedoch normalerweise, dass dies nicht der Fall ist. Ein Workload, der aus zwei oder drei Abhängigkeiten mit SLAs für eine Verfügbarkeit von 99,99% erstellt wurde, kann selbst immer noch eine Verfügbarkeit von 99,99% oder höher erreichen.
Dies liegt daran, dass es sich bei diesen Verfügbarkeitszahlen, wie wir im vorherigen Abschnitt dargelegt haben, um Schätzungen handelt. Sie schätzen oder prognostizieren, wie oft ein Fehler auftritt und wie schnell er repariert werden kann. Sie sind keine Garantie für Ausfallzeiten. Abhängigkeiten überschreiten häufig ihre angegebene Verfügbarkeit (SLA oder SLO).
Abhängigkeiten können auch höhere interne Verfügbarkeitsziele haben, auf deren Grundlage sie die Leistung anstreben, als die in öffentlichen SLAs angegebenen Zahlen. Dies bietet ein gewisses Maß an Risikominderung bei der Einhaltung von SLAs, wenn etwas Unbekanntes oder Unbekanntes passiert.
Schließlich kann es sein, dass Ihr Workload Abhängigkeiten aufweist, deren SLAs nicht bekannt sind oder die kein SLA oder SLO bieten. Beispielsweise ist weltweites Internet-Routing eine häufige Abhängigkeit für viele Workloads, aber es ist schwierig zu wissen, welche Internetdienstanbieter Ihr globaler Traffic nutzt, ob sie SLAs haben und wie konsistent diese zwischen den Anbietern sind.
All dies zeigt uns, dass die Berechnung einer maximalen theoretischen Verfügbarkeit wahrscheinlich nur zu einer groben Berechnung der Größenordnung führt, aber für sich genommen wahrscheinlich nicht genau ist oder aussagekräftige Erkenntnisse liefert. Die Mathematik zeigt uns, dass die Wahrscheinlichkeit eines Fehlers insgesamt sinkt, je weniger Dinge Ihre Arbeitslast benötigt. Je weniger Zahlen kleiner als eins miteinander multipliziert werden, desto größer ist das Ergebnis.
**Regel 3**
Die Reduzierung von Abhängigkeiten kann sich positiv auf die Verfügbarkeit auswirken.
Die Mathematik hilft auch bei der Auswahl von Abhängigkeiten. Der Auswahlprozess wirkt sich darauf aus, wie Sie Ihre Arbeitslast entwerfen, wie Sie Redundanz in Abhängigkeiten nutzen, um deren Verfügbarkeit zu verbessern, und ob Sie diese Abhängigkeiten als weich oder hart betrachten. Abhängigkeiten, die sich auf Ihre Arbeitslast auswirken können, sollten sorgfältig ausgewählt werden. Die nächste Regel enthält Hinweise dazu, wie Sie dies tun können.
**Regel 4**
Wählen Sie im Allgemeinen Abhängigkeiten aus, deren Verfügbarkeitsziele den Zielen Ihres Workloads entsprechen oder diese übertreffen.
# Verfügbarkeit mit Redundanz
Wenn ein Workload mehrere, unabhängige und redundante Subsysteme nutzt, kann ein höheres Maß an theoretischer Verfügbarkeit erreicht werden, als wenn ein einzelnes Subsystem verwendet würde. Stellen Sie sich zum Beispiel eine Arbeitslast vor, die aus zwei identischen Subsystemen besteht. Es kann vollständig betriebsbereit sein, wenn entweder das erste Teilsystem oder das zweite Teilsystem betriebsbereit ist. Damit das gesamte System ausgefallen ist, müssen beide Teilsysteme gleichzeitig ausgefallen sein.
*Wenn die Ausfallwahrscheinlichkeit eines Teilsystems 1 − *α* ist, dann ist die Wahrscheinlichkeit, dass zwei redundante Teilsysteme gleichzeitig ausfallen, das Produkt der Ausfallwahrscheinlichkeit jedes Teilsystems, *F* = (1− *α1) × (1− α*).* 2 Für eine Arbeitslast mit zwei redundanten Subsystemen ergibt sich unter Verwendung von Gleichung *(3)* eine Verfügbarkeit, die wie folgt definiert ist:
![\[Bild von drei Gleichungen\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation5.png)
Für zwei Subsysteme mit einer Verfügbarkeit von 99% beträgt die Wahrscheinlichkeit, dass eines ausfällt, also 1% und die Wahrscheinlichkeit, dass beide ausfallen, beträgt (1− 99%) × (1− 99%) = 0,01%. Das macht die Verfügbarkeit bei Verwendung von zwei redundanten Subsystemen zu 99,99%.
**Dies kann generalisiert werden, um auch zusätzliche redundante Ersatzteile einzubeziehen.** In Gleichung *(5) wurde* nur von einem einzigen Ersatzgerät ausgegangen, aber ein Workload kann aus zwei, drei oder mehr Ersatzteilen bestehen, sodass er den gleichzeitigen Verlust mehrerer Subsysteme überstehen kann, ohne die Verfügbarkeit zu beeinträchtigen. *Wenn eine Arbeitslast aus drei Subsystemen besteht und zwei Ersatzsysteme sind, beträgt die Wahrscheinlichkeit, dass alle drei Subsysteme gleichzeitig ausfallen, (1− α) × (1− *α*) × (1− *α*) oder (1− *α*) 3.* *Im Allgemeinen schlägt ein Workload mit *S-Ersatzteilen nur fehl, wenn s* \$1 1-Subsysteme ausfallen.*
*Bei einer Arbeitslast mit *n* Subsystemen und *s* Spares ist *f* die Anzahl der Ausfallursachen oder die Art und Weise, wie *s* \$1 1-Subsysteme von n ausfallen können.*
*****Das ist quasi der Binomialsatz, die kombinatorische Mathematik, bei der *k Elemente aus einer Menge von *n ausgewählt werden, oder „n* wähle k*“.***** **In diesem Fall ist k s \$1 1.**
![\[Bild von vier Gleichungen\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation6.png)
Wir können dann eine allgemeine Näherung der Verfügbarkeit erstellen, die die Anzahl der Ausfallursachen und die Einsparung berücksichtigt. (Um zu verstehen, warum das ungefähr so ist, siehe Anhang 2 von Highleyman et al. [Die Verfügbarkeitsbarriere durchbrechen](https://www.amazon.com/Breaking-Availability-Barrier-Survivable-Enterprise/dp/1410792331).)
![\[Bild von vier Gleichungen\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation7.png)
Sparing kann auf jede Abhängigkeit angewendet werden, die Ressourcen bereitstellt, die unabhängig voneinander ausfallen. Beispiele hierfür AWS-Regionen sind Amazon EC2 EC2-Instances in verschiedenen AZs oder Amazon S3 S3-Buckets in verschiedenen. Die Verwendung von Ersatzteilen trägt dazu bei, dass diese Abhängigkeit eine höhere Gesamtverfügbarkeit erreicht, um die Verfügbarkeitsziele des Workloads zu erreichen.
**Regel 5**
Verwenden Sie Sparing, um die Verfügbarkeit von Abhängigkeiten in einem Workload zu erhöhen.
Sparing ist jedoch mit Kosten verbunden. Jedes weitere Ersatzteil kostet genauso viel wie das Originalmodul, was die Kosten zumindest linear ansteigen lässt. Der Aufbau einer Workload, die Ersatzteile verwenden kann, erhöht auch deren Komplexität. Es muss wissen, wie man Fehler in Abhängigkeit erkennt, die Arbeit davon abwälzt und auf eine gesunde Ressource umverteilt und die Gesamtkapazität der Arbeitslast verwaltet.
Redundanz ist ein Optimierungsproblem. Zu wenige Ersatzteile, und der Workload kann häufiger ausfallen als gewünscht, zu viele Ersatzteile und der Betrieb des Workloads kostet zu viel. Es gibt einen bestimmten Schwellenwert, ab dem das Hinzufügen weiterer Ersatzteile mehr kostet als die zusätzliche Verfügbarkeit, die sie erreichen.
Unter Verwendung unserer Formel für allgemeine Verfügbarkeit mit Ersatzteilen, Gleichung *(7)*, für ein Subsystem mit einer Verfügbarkeit von 99,5% beträgt die Verfügbarkeit der Arbeitslast bei zwei Ersatzteilen *A* ≈ 1 − (1) (1−.995) 3 = 99,9999875% (ca. 3,94 Sekunden Ausfallzeit pro Jahr), und bei 10 Ersatzteilen erhalten wir *A* ≈ 1 − (1) (1−.995) 11 = 25,5 9 ′ *s* (die ungefähre Ausfallzeit) wäre 1,26252 × 10 −15 *m* *s* pro Jahr, effektiv 0). Beim Vergleich dieser beiden Workloads haben wir die Kosten für das Sparen um das Fünffache erhöht, sodass wir die Ausfallzeiten pro Jahr um vier Sekunden reduzieren konnten. Bei den meisten Workloads wäre der Anstieg der Kosten aufgrund dieser Erhöhung der Verfügbarkeit ungerechtfertigt. Die folgende Abbildung zeigt diesen Zusammenhang.
![\[Diagramm, das die sinkenden Erträge aus vermehrter Sparsamkeit zeigt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/availability-and-beyond-improving-resilience/images/effect-of-sparing.png)
Bei drei Ersatzteilen und mehr führt dies zu Sekundenbruchteilen der erwarteten Ausfallzeit pro Jahr, was bedeutet, dass Sie nach diesem Zeitpunkt den Bereich mit sinkenden Renditen erreichen. Möglicherweise besteht der Drang, „einfach mehr hinzuzufügen“, um eine höhere Verfügbarkeit zu erreichen, aber in Wirklichkeit verschwindet der Kostenvorteil sehr schnell. Die Verwendung von mehr als drei Ersatzteilen bringt keinen wesentlichen Nutzen. Ein spürbarer Gewinn für fast alle Workloads, wenn das Subsystem selbst eine Verfügbarkeit von mindestens 99% aufweist.
**Regel 6**
Es gibt eine Obergrenze für die Kosteneffizienz von Sparsamkeit. Verwenden Sie die wenigsten Ersatzteile, die erforderlich sind, um die erforderliche Verfügbarkeit zu erreichen.
Bei der Auswahl der richtigen Anzahl von Ersatzteilen sollten Sie die Fehlereinheit berücksichtigen. Schauen wir uns zum Beispiel einen Workload an, für den 10 EC2-Instances erforderlich sind, um Spitzenkapazität zu bewältigen, und die in einer einzigen AZ bereitgestellt werden.
Da AZs als Grenzen zur Fehlerisolierung konzipiert sind, handelt es sich bei der Ausfalleinheit nicht nur um eine einzelne EC2-Instance, da eine gesamte Anzahl von EC2-Instances zusammen ausfallen kann. In diesem Fall sollten Sie die [Redundanz durch eine weitere AZ erhöhen](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) und 10 zusätzliche EC2-Instances bereitstellen, um die Last im Fall eines AZ-Ausfalls zu bewältigen, also insgesamt 20 EC2-Instances (entsprechend dem Muster der statischen Stabilität).
Dies scheint zwar 10 Ersatz-EC2-Instances zu sein, aber in Wirklichkeit handelt es sich nur um eine einzige Ersatz-AZ, sodass wir den Punkt sinkender Renditen nicht überschritten haben. Sie können jedoch noch kosteneffizienter arbeiten und gleichzeitig Ihre Verfügbarkeit erhöhen, indem Sie drei AZs verwenden und fünf EC2-Instances pro AZ bereitstellen.
Auf diese Weise steht eine Ersatz-AZ mit insgesamt 15 EC2-Instances (gegenüber zwei AZs mit 20 Instances) zur Verfügung, sodass immer noch die insgesamt erforderlichen 10 Instances zur Verfügung stehen, um die Spitzenkapazität während eines Ereignisses, das sich auf eine einzelne AZ auswirkt, zu bedienen. Daher sollten Sie Sparing einbauen, um über alle vom Workload verwendeten Grenzen der Fehlerisolierung (Instanz, Zelle, AZ und Region) hinweg fehlertolerant zu sein.
# Satz von CAP
Eine andere Art, wie wir über Verfügbarkeit nachdenken könnten, bezieht sich auf das CAP-Theorem. Der Satz besagt, dass ein verteiltes System, das aus mehreren Knoten besteht, die Daten speichern, nicht gleichzeitig mehr als zwei der folgenden drei Garantien bieten kann:
+ **Konsistenz**: Jede Leseanforderung erhält den letzten Schreibvorgang oder einen Fehler, wenn die Konsistenz nicht garantiert werden kann.
+ Verfügbarkeit: Jede Anfrage erhält **eine** fehlerfreie Antwort, auch wenn Knoten ausgefallen oder nicht verfügbar sind.
+ **Partitionstoleranz**: Das System arbeitet trotz des Verlusts einer beliebigen Anzahl von Nachrichten zwischen Knoten weiter.
(Weitere Einzelheiten finden Sie in Seth Gilbert und Nancy Lynch, [http://dl.acm.org/citation.cfm?id=564601&CFID=609557487&CFTOKEN=15997970](http://dl.acm.org/citation.cfm?id=564601&CFID=609557487&CFTOKEN=15997970) *ACM SIGACT News, Band 33, Ausgabe 2 (2002), S. 51—59*.)
Die meisten verteilten Systeme müssen Netzwerkausfälle tolerieren, weshalb Netzwerkpartitionierung zulässig sein muss. Das bedeutet, dass diese Workloads bei einer Netzwerkpartition zwischen Konsistenz und Verfügbarkeit wählen müssen. Wenn sich der Workload für Verfügbarkeit entscheidet, gibt er immer eine Antwort zurück, allerdings mit potenziell inkonsistenten Daten. Wenn er sich für Konsistenz entscheidet, würde er während einer Netzwerkpartition einen Fehler zurückgeben, da der Workload nicht sicher sein kann, ob die Daten konsistent sind.
Für Workloads, deren Ziel es ist, ein höheres Maß an Verfügbarkeit zu gewährleisten, könnten sie Verfügbarkeit und Partitionstoleranz (AP) wählen, um zu verhindern, dass während einer Netzwerkpartition Fehler (Nichtverfügbarkeit) erneut auftreten. Dies führt dazu, dass ein lockereres [Konsistenzmodell](https://en.wikipedia.org/wiki/Consistency_model) erforderlich ist, wie z. B. letztendliche Konsistenz oder monotone Konsistenz.
# Fehlertoleranz und Fehlerisolierung
Dies sind zwei wichtige Konzepte, wenn wir über Verfügbarkeit nachdenken. Fehlertoleranz ist die Fähigkeit, dem [Ausfall eines Subsystems standzuhalten](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html) und die Verfügbarkeit aufrechtzuerhalten (das Richtige innerhalb einer festgelegten SLA zu tun). Um Fehlertoleranz zu implementieren, verwenden Workloads Ersatzsubsysteme (oder redundante). Wenn eines der Subsysteme in einer redundanten Gruppe ausfällt, nimmt ein anderes seine Arbeit wieder auf, normalerweise fast nahtlos. In diesem Fall handelt es sich bei Ersatzteilen um echte Reservekapazitäten. Sie stehen zur Verfügung, um 100% der Arbeit des ausgefallenen Subsystems zu übernehmen. Bei echten Ersatzteilen sind mehrere Ausfälle von Subsystemen erforderlich, um sich negativ auf die Arbeitslast auszuwirken.
Durch die Fehlerisolierung wird das Ausmaß der Auswirkungen minimiert, wenn ein Fehler auftritt. Dies wird in der Regel durch Modularisierung implementiert. Workloads werden in kleine Subsysteme aufgeteilt, die unabhängig voneinander ausfallen und isoliert repariert werden können. Der Ausfall eines Moduls überträgt [sich nicht über das Modul hinaus](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-interactions-in-a-distributed-system-to-mitigate-or-withstand-failures.html). Diese Idee erstreckt sich sowohl vertikal über unterschiedliche Funktionen innerhalb eines Workloads als auch horizontal über mehrere Subsysteme, die dieselbe Funktionalität bieten. Diese Module dienen als Fehlercontainer, die den Umfang der Auswirkungen während eines Ereignisses einschränken.
Die architektonischen Muster der Steuerungsebenen, Datenebenen und der statischen Stabilität unterstützen direkt die Implementierung von Fehlertoleranz und Fehlerisolierung. Der Artikel [Statische Stabilität mithilfe von Availability Zones in](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) der Amazon Builders' Library bietet gute Definitionen für diese Begriffe und erklärt, wie sie sich auf den Aufbau robuster, hochverfügbarer Workloads anwenden lassen. In diesem Whitepaper werden diese Muster im Abschnitt [Entwerfen hochverfügbarer verteilter Systeme](designing-highly-available-distributed-systems-on-aws.md#designing-highly-available-distributed-systems-on-aws.title) verwendet. Außerdem fassen wir ihre Definitionen hier zusammen. AWS
+ **Kontrollebene** — Der Teil der Arbeitslast, der mit der Durchführung von Änderungen verbunden ist: Hinzufügen von Ressourcen, Löschen von Ressourcen, Ändern von Ressourcen und Weitergabe dieser Änderungen an die Stellen, an denen sie benötigt werden. Steuerungsebenen sind in der Regel komplexer und haben mehr bewegliche Teile als Datenebenen. Daher ist die Wahrscheinlichkeit, dass sie ausfallen und weniger verfügbar sind, statistisch gesehen höher.
+ **Datenebene** — Der Teil der Arbeitslast, der die day-to-day Geschäftsfunktionen bereitstellt. Datenebenen sind in der Regel einfacher und können mit höheren Datenvolumen betrieben werden als Steuerungsebenen, was zu höheren Verfügbarkeiten führt.
+ **Statische Stabilität** — Die Fähigkeit eines Workloads, trotz eingeschränkter Abhängigkeiten den korrekten Betrieb fortzusetzen. Eine Implementierungsmethode besteht darin, Abhängigkeiten der Steuerungsebene von den Datenebenen zu entfernen. Eine andere Methode besteht darin, Workload-Abhängigkeiten lose miteinander zu koppeln. Möglicherweise sieht der Workload keine aktualisierten Informationen (wie neue Dinge, gelöschte oder geänderte Dinge), die seine Abhängigkeit hätte liefern sollen. Alles, was es getan hat, bevor die Abhängigkeit beeinträchtigt wurde, funktioniert jedoch weiterhin.
Wenn wir über eine Beeinträchtigung der Arbeitsbelastung nachdenken, gibt es zwei grundlegende Ansätze, die wir für die Wiederherstellung in Betracht ziehen können. Die erste Methode besteht darin, auf diese Beeinträchtigung zu reagieren, nachdem sie eingetreten ist, indem AWS Auto Scaling möglicherweise neue Kapazitäten hinzugefügt werden. Die zweite Methode besteht darin, sich auf diese Beeinträchtigungen vorzubereiten, bevor sie auftreten, etwa indem die Infrastruktur eines Workloads überdimensioniert wird, sodass dieser weiterhin ordnungsgemäß funktionieren kann, ohne dass zusätzliche Ressourcen benötigt werden.
Ein statisch stabiles System verwendet den letztgenannten Ansatz. Es stellt vorab Kapazitätsreserven bereit, die bei einem Ausfall zur Verfügung stehen. Mit dieser Methode wird vermieden, dass im Wiederherstellungspfad des Workloads eine Abhängigkeit von einer Steuerungsebene entsteht, um neue Kapazitäten für die Wiederherstellung nach einem Ausfall bereitzustellen. Darüber hinaus nimmt die Bereitstellung neuer Kapazitäten für verschiedene Ressourcen Zeit in Anspruch. Während Sie auf neue Kapazitäten warten, kann es sein, dass Ihr Workload durch die bestehende Nachfrage überlastet wird und sich weiter verschlechtert, was zu einem „Brown-Out“ oder einem vollständigen Verfügbarkeitsverlust führt. Sie sollten jedoch auch die Kostenauswirkungen berücksichtigen, die sich aus der Nutzung vorab bereitgestellter Kapazität im Vergleich zu Ihren Verfügbarkeitszielen ergeben.
Statische Stabilität gibt die nächsten beiden Regeln für Hochverfügbarkeits-Workloads vor.
**Regel 7**
Gehen Sie in Ihrer Datenebene keine Abhängigkeiten von den Steuerungsebenen ein, insbesondere nicht bei der Wiederherstellung.
**Regel 8**
Koppeln Sie Abhängigkeiten nach Möglichkeit lose miteinander, sodass Ihr Workload trotz Beeinträchtigung der Abhängigkeit korrekt funktionieren kann.