Zonengebundene Services

Availability Zone Independence (A Bol) ermöglicht AWS es , zonale Services wie Amazon EC2 und Amazon EBS bereitzustellen. Ein zonaler Service bietet die Möglichkeit anzugeben, in welcher Availability Zone die Ressourcen bereitgestellt werden. Diese Services funktionieren unabhängig in jeder Availability Zone innerhalb einer Region und, was noch wichtiger ist, schlagen auch unabhängig in jeder Availability Zone fehl. Das bedeutet, dass Komponenten eines Services in einer Availability Zone keine Abhängigkeiten von Komponenten in anderen Availability Zones annehmen. Dies ist möglich, da ein zonaler Service zonale Datenebenen hat. In einigen Fällen, z. B. mit EC2, enthält der Service auch zonale Steuerebenen für zonell ausgerichtete Operationen, wie das Starten einer EC2-Instance. Für diese Services bietet AWS auch einen regionalen Endpunkt der Steuerebene, um die Interaktion mit dem Service zu vereinfachen. Die regionale Steuerebene bietet auch regionale Funktionen und dient als Aggregations- und Routing-Ebene über den zonalen Steuerebenen. Dies ist in der folgenden Abbildung dargestellt.

Ein zonaler Service mit zonenisolierten Steuerebenen und Datenebenen

Availability Zones bieten Kunden die Möglichkeit, Produktions-Workloads zu betreiben, die hochverfügbarer, fehlertoleranter und skalierbarer sind, als dies in einem einzigen Rechenzentrum möglich wäre. Wenn ein Workload mehrere Availability Zones verwendet, sind Kunden besser isoliert und vor Problemen geschützt, die sich auf die physische Infrastruktur einer einzelnen Availability Zone auswirken. Dies hilft Kunden dabei, Services zu erstellen, die über Availability Zones hinweg redundant sind, und, wenn sie korrekt konzipiert sind, betriebsbereit zu bleiben, auch wenn in einer Availability Zone Ausfälle auftreten. Kunden können die Vorteile von A nutzen, um hochverfügbare und belastbare Workloads zu erstellen. Die Implementierung von A in Ihrer Architektur hilft Ihnen, sich nach einem isolierten Ausfall der Availability Zone schnell zu erholen, da Ihre Ressourcen in einer Availability Zone die Interaktion mit Ressourcen in anderen Availability Zones minimieren oder eliminieren. Dies hilft, Abhängigkeiten zwischen Availability Zones zu entfernen, was die Evakuierung von Availability Zones vereinfacht. Weitere Informationen zur Erstellung von Availability-Zone-Evakuierungsmechanismen finden Sie unter Erweiterte Multi-AZ-Ausfallsicherheitsmuster. Darüber hinaus können Sie Availability Zones weiter nutzen, indem Sie einige der gleichen bewährten Methoden befolgen, die für ihre eigenen Services AWS verwendet, z. B. nur Änderungen gleichzeitig in einer einzelnen Availability Zone bereitstellen oder eine Availability Zone aus dem Service entfernen, wenn eine Änderung in dieser Availability Zone schlecht geht.

Statische Stabilität ist auch ein wichtiges Konzept für Architekturen mit mehreren Availability Zones. Einer der Fehlermodi, den Sie bei Architekturen mit mehreren Availability Zones einplanen sollten, ist der Verlust einer Availability Zone, was zum Verlust der Kapazität einer Availability Zone führen kann. Wenn Sie nicht genügend Kapazität bereitgestellt haben, um den Verlust einer Availability Zone zu bewältigen, kann dies dazu führen, dass Ihre verbleibende Kapazität durch die aktuelle Last überfordert wird. Darüber hinaus müssen Sie von den Steuerebenen der Zonendienste abhängen, die Sie verwenden, um diese verlorene Kapazität zu ersetzen, was weniger zuverlässig sein kann als ein statisch stabiles Design. In diesem Fall kann Ihnen die Vorabbereitstellung von ausreichend zusätzlicher Kapazität helfen, statisch stabil gegenüber dem Verlust einer Fehlerdomäne, z. B. einer Availability Zone, zu sein, da Sie den normalen Betrieb fortsetzen können, ohne dass dynamische Änderungen erforderlich sind.

Sie können eine Auto-Scaling-Gruppe von EC2-Instances verwenden, die über mehrere Availability Zones bereitgestellt werden, um je nach den Anforderungen Ihres Workloads dynamisch zu skalieren. Auto Scaling funktioniert gut für schrittweise Nutzungsänderungen, die über Minuten bis zu Dutzenden Minuten auftreten. Das Starten neuer EC2-Instances dauert jedoch Zeit, insbesondere wenn Ihre Instances Bootstrapping erfordern (z. B. die Installation von Agenten, Anwendungsbinärdateien oder Konfigurationsdateien). Während dieser Zeit könnte Ihre verbleibende Kapazität durch die aktuelle Last überfordert sein. Darüber hinaus basiert die Bereitstellung neuer Instances durch Auto Scaling auf der EC2-Steuerebene. Dies stellt einen Kompromiss dar: Um beim Verlust einer einzelnen Availability Zone statisch stabil zu sein, müssen Sie genügend EC2-Instances in den anderen Availability Zones bereitstellen, um die Last zu bewältigen, die von der beeinträchtigten Availability Zone weg verschoben wurde, anstatt sich auf Auto Scaling zu verlassen, um neue Instances bereitzustellen. Für die Vorabbereitstellung zusätzlicher Kapazität können jedoch zusätzliche Kosten anfallen.

Nehmen wir beispielsweise an, dass Ihr Workload sechs Instances benötigt, um den Kundenverkehr über drei Availability Zones zu bedienen. Um bei einem Ausfall einer einzelnen Availability Zone statisch stabil zu sein, würden Sie drei Instances in jeder Availability Zone bereitstellen, also insgesamt neun. Wenn eine einzelne Availability-Zone-Shift von Instances ausgefallen wäre, hätten Sie immer noch sechs links und können Ihren Kundenverkehr weiterhin bedienen, ohne während des Ausfalls neue Instances bereitstellen und konfigurieren zu müssen. Das Erreichen der statischen Stabilität für Ihre EC2-Kapazität ist mit zusätzlichen Kosten verbunden, da Sie in diesem Fall 50 % zusätzliche Instances ausführen. Nicht für alle Services, für die Sie Ressourcen vorab bereitstellen können, fallen zusätzliche Kosten an, z. B. die Vorabbereitstellung eines S3-Buckets oder eines Benutzers. Sie müssen alle Nachteile der Implementierung statischer Stabilität gegen das Risiko abwägen, die gewünschte Wiederherstellungszeit für Ihren Workload zu überschreiten.

AWS Local Zones und Outposts bringen die Datenebene AWS ausgewählter Services näher an Endbenutzer. Die Steuerebenen für diese Services befinden sich in der übergeordneten Region. Ihre Local Zone- oder Outposts-Instance hat Abhängigkeiten auf Steuerebene für zonale Services wie EC2 und EBS in der Availability Zone, in der Sie Ihr Local Zone- oder Outposts-Subnetz erstellt haben. Sie werden auch Abhängigkeiten von regionalen Steuerebenen für regionale Services wie Elastic Load Balancing (ELB), Sicherheitsgruppen und der von Amazon Elastic Kubernetes Service (Amazon EKS) verwalteten Kubernetes-Steuerebene haben (wenn Sie EKS verwenden). Weitere Informationen zu Outposts finden Sie in der Dokumentation und den häufig gestellten Fragen zu Support und Wartung. Implementieren Sie statische Stabilität, wenn Sie Local Zones oder Outposts verwenden, um die Ausfallsicherheit bei Beeinträchtigungen der Steuerebene oder Unterbrechungen der Netzwerkkonnektivität zur übergeordneten Region zu verbessern.