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.
REL01-BP06 Stellen Sie sicher, dass zwischen den aktuellen Kontingenten und der maximalen Nutzung eine ausreichende Lücke besteht, um ein Failover zu ermöglichen
In diesem Artikel wird erläutert, wie Sie den Abstand zwischen dem Ressourcenkontingent und Ihrer Nutzung beibehalten können und wie Ihr Unternehmen davon profitieren kann. Wenn Sie eine Ressource nicht mehr nutzen, wird diese Ressource möglicherweise noch auf ein Kontingent angerechnet. Dies kann zu einer fehlgeschlagenen oder nicht mehr erreichbaren Ressource führen. Überprüfen Sie, ob Ihre Kontingente die Überschneidung von ausgefallenen oder nicht zugreifbaren Ressourcen und deren Ersatz abdecken. Bei der Berechnung dieser Lücke sollten Sie Anwendungsfälle wie Netzwerkfehler, Fehler in der Availability Zone oder Fehler in einer Region berücksichtigen.
Gewünschtes Ergebnis: Kleine oder große Fehler bei Ressourcen oder der Ressourcenzugänglichkeit können innerhalb der aktuellen Service-Schwellenwerte abgedeckt werden. Zonenfehler, Netzwerkfehler oder sogar regionale Fehler wurden bei der Ressourcenplanung berücksichtigt.
Typische Anti-Muster:
-
Es werden Servicekontingente auf Grundlage des aktuellen Bedarfs eingerichtet, ohne dass Failover-Szenarien berücksichtigt werden.
-
Keine Berücksichtigung des Prinzips der statischen Stabilität bei der Berechnung des Spitzenkontingents für einen Service.
-
Keine Berücksichtigung des Potenzials nicht zugreifbarer Ressourcen bei der Berechnung des für jede Region benötigten Gesamtkontingents.
-
Ohne Berücksichtigung der Grenzen zur Isolierung von AWS Dienstfehlern für einige Dienste und ihrer potenziell abnormalen Nutzungsmuster.
Vorteile der Nutzung dieser bewährten Methode: Wenn die Verfügbarkeit von Anwendungen durch eine Service-Störung beeinträchtigt wird, bietet Ihnen die Cloud die Möglichkeit zur Implementierung von Strategien zur Abschwächung dieser Ereignisse oder der Wiederherstellung. Zu solchen Strategien gehört oft die Erstellung zusätzlicher Ressourcen, um ausgefallene oder unzugängliche Ressourcen zu ersetzen. Ihre Kontingent-Strategie muss diese Failover-Bedingungen berücksichtigen und würde nicht zu einer zusätzlichen Verschlechterung aufgrund des Erreichens von Service-Beschränkungen führen.
Risikostufe bei fehlender Befolgung dieser bewährten Methode: Mittel
Implementierungsleitfaden
Berücksichtigen Sie bei der Bewertung der Kontingente auch Failover-Fälle, die aufgrund einer Verschlechterung auftreten können. Die folgenden Arten von Failover-Fällen sollten in Betracht gezogen werden:
-
Ein unterbrochener oder VPC unzugänglicher Zugriff.
-
Ein Subnetz, auf das nicht mehr zugegriffen werden kann.
-
Eine Availability Zone wurde so stark beeinträchtigt, dass die Erreichbarkeit vieler Ressourcen beeinträchtigt ist.
-
Verschiedene Netzwerk-Routen oder Ingress- und Egress-Punkte sind blockiert oder verändert.
-
Eine Region ist so stark gestört, dass die Erreichbarkeit vieler Ressourcen beeinträchtigt ist.
-
Es gibt mehrere Ressourcen, aber nicht alle sind von einem Fehler in einer Region oder einer Availability Zone betroffen.
Die Entscheidung für einen Failover ist für jede Situation und jeden Kunden individuell, da die Auswirkungen auf den Geschäftsbetrieb sehr unterschiedlich sein können. Wenn Sie sich jedoch operativ für einen Failover von Anwendungen oder Services entscheiden, müssen Sie sich vor dem Ereignis mit der Kapazitätsplanung der Ressourcen am Failover-Standort und den entsprechenden Kontingenten befassen.
Überprüfen Sie die Service-Kontingente für jeden Service und berücksichtigen Sie dabei die möglichen Spitzenwerte. Diese Spitzen können mit Ressourcen zusammenhängen, die über Netzwerkproblemen oder Berechtigungen zwar noch aktiv, aber nicht erreichbar sind. Nicht beendete aktive Ressourcen werden weiterhin auf das Kontingent des Service angerechnet.
Implementierungsschritte
-
Vergewissern Sie sich, dass zwischen Ihrem Service-Kontingent und Ihrer maximalen Nutzung genügend Spielraum besteht, um einen Failover oder den Verlust der Erreichbarkeit aufzufangen.
-
Ermitteln Sie die Servicekontingente unter Berücksichtigung von Bereitstellungsmustern, der Verfügbarkeitsanforderungen und des Nutzungsanstiegs.
-
Fordern Sie bei Bedarf Kontingenterhöhungen an. Planen Sie den erforderlichen Zeitraums bis zur Bewilligung von Kontingenterhöhungen.
-
Bestimmen Sie Ihre Anforderungen an die Zuverlässigkeit (Anzahl der Neunen).
-
Legen Sie Fehlerszenarien fest (z. B. Verlust einer Komponente, Availability Zone oder Region).
-
Führen Sie eine Bereitstellungsmethode ein (z. B. Canary, Blau/Grün-Bereitstellung, Rot/Schwarz-Bereitstellung oder schrittweise).
-
Berücksichtigen Sie einen angemessenen Puffer (z. B. 15 %) in aktuellen Limits.
-
Berücksichtigen Sie gegebenenfalls Berechnungen zur statischen Stabilität (zonenbezogen und regional).
-
Planen Sie den Nutzungsanstieg (z. B. durch Überwachen des Nutzungstrends).
-
Berücksichtigen Sie die Auswirkungen der statischen Stabilität für Ihre kritischsten Workloads. Bewerten Sie Ressourcen entsprechend eines statisch stabilen Systems in allen Regionen und Availability Zones.
-
Ziehen Sie den Einsatz von On-Demand-Kapazitätsreservierungen in Betracht, um vor einem Failover Kapazitäten zu reservieren. Diese Strategie kann während kritischer Geschäftszeiten sinnvoll sein, um potenzielle Risiken bei der Beschaffung der richtigen Menge und Art von Ressourcen während eines Failovers zu verringern.
Ressourcen
Zugehörige bewährte Methoden:
-
REL01-BP02 Servicekontingente über Konten und Regionen hinweg verwalten
-
REL01-BP03 Berücksichtigung fester Servicequoten und Einschränkungen durch die Architektur
-
REL03-BP01 Wählen Sie, wie Sie Ihre Arbeitslast segmentieren möchten
-
REL10-BP01 Bereitstellen des Workloads an mehreren Standorten
-
REL11-BP01 Überwachen Sie alle Komponenten des Workloads, um Fehler zu erkennen
-
REL12-BP04 Testen der Ausfallsicherheit mit Chaos-Engineering
Zugehörige Dokumente:
-
AWS Die Zuverlässigkeitssäule von Well-Architected Framework: Verfügbarkeit
-
AWS Trusted Advisor Prüfungen bewährter Verfahren (siehe Abschnitt Service Limits)
-
APNPartner: Partner, die beim Konfigurationsmanagement helfen können
-
Verwaltung des Kontolebenszyklus in account-per-tenant SaaS-Umgebungen auf AWS
-
Verwaltung und Überwachung der API Drosselung Ihrer Workloads
-
Sehen Sie sich AWS Trusted Advisor Empfehlungen in großem Umfang an mit AWS Organizations
-
Automatisierung von Service-Limit-Erhöhungen und Unternehmenssupport mit AWS Control Tower
-
Aktionen, Ressourcen und Bedingungsschlüssel für Service Quotas
Zugehörige Videos:
Zugehörige Tools: