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.
In Bezug auf Fehlermodi denken
Beim Entwerfen einer Anwendung oder eines Systems mit hoher Verfügbarkeit müssen Sie berücksichtigen, welche Komponenten ausfallen könnten, welche Auswirkungen Komponentenausfälle auf das System haben und welche RPO-/RTO-Ziele
Sie sollten die Fehlermodi in diesem Abschnitt bei der Planung Ihrer Outposts und Anwendungsbereitstellungen berücksichtigen. In den folgenden Abschnitten wird untersucht, wie Sie diese Fehlermodi minimieren können, um eine höhere Hochverfügbarkeit für Ihre Anwendungsumgebung zu erreichen.
Fehlermodus 1: Netzwerk
Eine Outpost-Bereitstellung ist für Verwaltung und Überwachung auf eine stabile Verbindung zur übergeordneten Region angewiesen. Netzwerkunterbrechungen können durch eine Vielzahl von Ausfällen wie Bedienungsfehler, Geräteausfälle und Ausfälle von Dienstanbietern verursacht werden. Ein Außenposten, der aus einem oder mehreren am Standort miteinander verbundenen Racks bestehen kann, gilt als unterbrochen, wenn er nicht über den Service Link mit der Region kommunizieren kann.
Redundante Netzwerkpfade können dazu beitragen, das Risiko von Unterbrechungen zu verringern. Sie sollten die Anwendungsabhängigkeiten und den Netzwerkverkehr zuordnen, um zu verstehen, welche Auswirkungen Unterbrechungen auf Workload-Operationen haben können. Planen Sie eine ausreichende Netzwerkredundanz ein, um Ihre Anforderungen an die Anwendungsverfügbarkeit zu erfüllen.
Während eines Verbindungsabbruchs laufen die auf einem Outpost laufenden Instanzen weiter und sind von lokalen Netzwerken aus über das Outpost Local Gateway (LGW) zugänglich. Lokale Workloads und Dienste können beeinträchtigt werden oder ausfallen, wenn sie auf Dienste in der Region angewiesen sind. Mutationsanfragen (wie das Starten oder Stoppen von Instances auf dem Outpost), der Betrieb der Kontrollebene und die Service-Telemetrie (z. B. CloudWatch Metriken) schlagen fehl, solange der Outpost von der Region getrennt ist. CloudWatch Metriken werden für kurze Zeiträume einer Netzwerkunterbrechung lokal auf Ihrem Outpost gespoolt und zur Überprüfung an die Region gesendet, wenn die Service Link-Verbindung wieder hergestellt ist.
Fehlermodus 2: Instanzen
EC2 Amazon-Instances können beeinträchtigt werden oder ausfallen, wenn der Server, auf dem sie ausgeführt werden, ein Problem hat oder wenn bei der Instance ein Betriebssystem oder eine Anwendung ausfällt. Wie Anwendungen mit solchen Fehlern umgehen, hängt von der Anwendungsarchitektur ab. Monolithische Anwendungen verwenden in der Regel Anwendungs- oder Systemfunktionen für die Wiederherstellung, während modulare serviceorientierte Architekturen oder Microservice-Architekturen
Mithilfe automatisierter Mechanismen wie Amazon EC2 Auto Scaling Scaling-Gruppen können Sie ausgefallene Instances durch neue Instances ersetzen. Die auto Instanzwiederherstellung kann Instanzen neu starten, die aufgrund von Serverausfällen ausfallen, sofern auf den verbleibenden Servern genügend freie Kapazität verfügbar ist und der Service Link weiterhin verbunden ist.
Fehlermodus 3: Compute
Server können ausfallen oder beeinträchtigt werden und müssen möglicherweise aus einer Vielzahl von Gründen außer Betrieb genommen werden (vorübergehend oder dauerhaft), z. B. aufgrund von Komponentenausfällen und geplanten Wartungsarbeiten. Wie die Dienste im Outposts-Rack mit Serverausfällen und -beeinträchtigungen umgehen, ist unterschiedlich und kann davon abhängen, wie Kunden Hochverfügbarkeitsoptionen konfigurieren.
Sie sollten ausreichend Rechenkapazität bestellen, um ein N+M
Verfügbarkeitsmodell zu unterstützen, bei dem N
die erforderliche Kapazität und die M
Reservekapazität für Serverausfälle bereitgestellt werden.
Hardwareersatz für ausgefallene Server wird im Rahmen des vollständig verwalteten AWS Outposts Rack-Service bereitgestellt. AWS überwacht aktiv den Zustand aller Server und Netzwerkgeräte in einer Outpost-Bereitstellung. Wenn physische Wartungsarbeiten erforderlich sind, vereinbaren AWS wir einen Termin für einen Besuch vor Ort, um ausgefallene Komponenten auszutauschen. Durch die Bereitstellung von Reservekapazitäten können Sie Ihre Workloads vor Hostausfällen schützen, während fehlerhafte Server außer Betrieb genommen und ersetzt werden.
Fehlermodus 4: Racks oder Rechenzentren
Rackausfälle können aufgrund eines Totalausfalls der Stromversorgung der Racks oder aufgrund von Umwelteinflüssen wie Kühlungsausfällen oder physischen Schäden am Rechenzentrum durch Überschwemmungen oder Erdbeben auftreten. Mängel in der Architektur der Stromverteilung in Rechenzentren oder Fehler bei der standardmäßigen Wartung der Stromversorgung von Rechenzentren können dazu führen, dass ein oder mehrere Racks oder sogar das gesamte Rechenzentrum nicht mit Strom versorgt werden.
Diese Szenarien können durch die Bereitstellung von Infrastruktur auf mehreren Stockwerken oder voneinander unabhängigen Standorten im Rechenzentrum auf demselben Campus oder in derselben Metropolregion abgemildert werden.
Wenn Sie diesen Ansatz mit AWS Outposts Rack verfolgen, müssen Sie sorgfältig abwägen, wie Anwendungen so konzipiert und verteilt werden, dass sie auf mehrere separate logische Outposts laufen, um die Anwendungsverfügbarkeit aufrechtzuerhalten.
Fehlermodus 5: AWS Availability Zone oder Region
Jeder Außenposten ist in einer bestimmten Availability Zone (AZ) innerhalb eines verankert. AWS-Region Ausfälle innerhalb der Basis-AZ oder der übergeordneten Region können zum Verlust des Outpost-Managements und der Veränderbarkeit führen und die Netzwerkkommunikation zwischen dem Outpost und der Region stören.
Ähnlich wie bei Netzwerkausfällen können Ausfälle in AZ oder Region dazu führen, dass der Außenposten von der Region getrennt wird. Die auf einem Outpost laufenden Instances laufen weiter und sind von lokalen Netzwerken aus über das Outpost Local Gateway (LGW) zugänglich. Sie können beeinträchtigt werden oder ausfallen, wenn sie, wie zuvor beschrieben, auf Dienste in der Region angewiesen sind.
Um die Auswirkungen von Ausfällen in AWS AZ und Region zu mildern, können Sie mehrere Outposts einsetzen, die jeweils in einer anderen AZ oder Region verankert sind. Anschließend können Sie Ihren Workload so gestalten, dass er in einem verteilten Bereitstellungsmodell mit mehreren Außenstellen ausgeführt wird. Dabei können Sie viele der ähnlichen Mechanismen und Architekturmuster verwenden, die Sie heute für die Planung und Bereitstellung verwenden. AWS
Die Kontrollebene der Dienste, auf denen sie ausgeführt werden, AWS Outposts befindet sich in der Region, in der sie verankert sind, wodurch eine Abhängigkeit sowohl von zonalen Diensten wie Amazon EC2 und Amazon EBS als auch von regionalen Diensten wie Amazon RDS, Elastic Load Balancing und Amazon EKS entsteht. In Outposts können Anwendungen im Rahmen des Konzepts der statischen Stabilität eingesetzt werden, um die Widerstandsfähigkeit gegenüber Beeinträchtigungen durch Kontrollebenen zu verbessern.