Dieses Dokument wird derzeit aktualisiert. In der Zwischenzeit sind einige Inhalte möglicherweise nicht korrekt.
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 Entwurf 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 Mechanismen Sie implementieren können, um die Auswirkungen von Komponentenausfällen zu mindern oder zu eliminieren. Wird Ihre Anwendung auf einem einzelnen Server, in einem einzigen Rack oder in einem einzigen Rechenzentrum ausgeführt? Was passiert, wenn ein Server, ein Rack oder ein Rechenzentrum vorübergehend oder dauerhaft ausfällt? Was passiert, wenn ein kritisches Subsystem wie das Netzwerk oder die Anwendung selbst ausfällt? Dies sind Fehlermodi.
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 Anwendungsabhängigkeiten und 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 () zugänglich. LGW 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.
Fehlermodus 2: Instanzen
EC2Instanzen können beeinträchtigt werden oder ausfallen, wenn der Server, auf dem sie ausgeführt werden, ein Problem hat oder wenn bei der Instanz 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 in der Regel ausgefallene Komponenten ersetzen, um die Serviceverfügbarkeit aufrechtzuerhalten.
Mithilfe automatisierter Mechanismen wie 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.
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 der vollständig verwalteten Lösung bereitgestellt AWS Outposts Rack-Service. AWS überwacht aktiv den Zustand aller Server und Netzwerkgeräte in einer Outpost-Bereitstellung. Wenn physische Wartungsarbeiten erforderlich sind, AWS wird einen Termin für den Besuch Ihrer Website vereinbaren, um ausgefallene Komponenten auszutauschen. Durch die Bereitstellung von Reservekapazitäten können Sie Ihre Workloads am Laufen halten, während ausgefallene Server außer Betrieb genommen und ersetzt werden.
Ausfallmodus 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.
Wir verfolgen diesen Ansatz mit AWS Outposts Ein Rack erfordert eine sorgfältige Abwägung darüber, wie Anwendungen so konzipiert und verteilt werden, dass sie über 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önnten zum Verlust der Verwaltung und der Veränderbarkeit der Außenposten führen und die Netzwerkkommunikation zwischen dem Außenposten 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 auf Dienste in der Region angewiesen sind, wie zuvor beschrieben.
Um die Auswirkungen von zu mildern AWS Bei Ausfällen in AZ und Region 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 und dabei viele der ähnlichen Mechanismen und Architekturmuster verwendet, die Sie für den Entwurf und die Bereitstellung auf AWS heute.
