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.
Multi-Region-Grundlage 1: Die Anforderungen verstehen
Wie bereits erwähnt, sind hohe Verfügbarkeit und Betriebskontinuität häufige Gründe für die Entwicklung von Architekturen mit mehreren Regionen. Verfügbarkeitsmetriken messen den Prozentsatz der Zeit, in der ein Workload über einen bestimmten Zeitraum genutzt werden kann, wohingegen Kennzahlen zur Betriebskontinuität die Wiederherstellungszeit für umfangreiche und in der Regel längere Ereignisse messen.
Die Messung der Verfügbarkeit ist ein nahezu kontinuierlicher Prozess. Spezifische Messwerte können variieren, basieren aber in der Regel auf einer Zielverfügbarkeitsmetrik, die am häufigsten als Neun bezeichnet wird (z. B. Verfügbarkeit von 99,99 Prozent). Bei Verfügbarkeitszielen gibt es keine Einheitslösung. Sie sollten Verfügbarkeitsziele auf Workload-Ebene festlegen und unkritische Komponenten von kritischen Komponenten trennen, anstatt ein einziges Ziel für alle Workloads festzulegen.
Um die Betriebskontinuität zu gewährleisten, werden in der Regel die folgenden point-in-time Messwerte verwendet:
-
Recovery Time Objective (RTO) — RTO ist die maximal zulässige Verzögerung zwischen der Betriebsunterbrechung und der Wiederherstellung des Dienstes. Dieser Wert bestimmt eine akzeptable Dauer, für die der Dienst beeinträchtigt ist.
-
Recovery Point Objective (RPO) — RPO ist die maximal zulässige Zeitspanne seit dem letzten Datenwiederherstellungspunkt. Dies bestimmt, was als akzeptabler Datenverlust zwischen dem letzten Wiederherstellungspunkt und einer Betriebsunterbrechung angesehen wird.
Ähnlich wie bei der Festlegung von Verfügbarkeitszielen sollten RTO und RPO auch auf Workload-Ebene definiert werden. Eine aggressivere Betriebskontinuität oder hohe Verfügbarkeit erfordern höhere Investitionen. Allerdings kann oder erfordert nicht jede Anwendung das gleiche Maß an Belastbarkeit. Als Ausgangspunkt kann es hilfreich sein, Geschäfts- und IT-Verantwortliche darauf abzustimmen, die Wichtigkeit von Anwendungen anhand ihrer geschäftlichen Auswirkungen zu bewerten und sie dann entsprechend zu klassifizieren. Die folgenden Tabellen enthalten Beispiele für Tiering.
Diese Tabelle zeigt ein Beispiel für ein Resilienz-Tiering für Service Level Agreements (). SLAs
| Stufe der Resilienz | Verfügbarkeit SLA | Akzeptable Ausfallzeiten/Jahr |
|---|---|---|
Platin |
99,99 % |
52.60 Minuten |
Gold |
99,90% |
8,77 Stunden |
Silber |
99,5 % |
1,83 Tage |
Die folgende Tabelle zeigt ein Beispiel für Resilienz-Tiering für RTO und RPO.
| Stufe der Resilienz | Maximaler RTO | Maximaler RPO | Kriterien | Kosten |
|---|---|---|---|---|
Platin |
15 Minuten |
5 Minuten |
Unternehmenskritische Workloads |
$$$ |
Gold |
15 Minuten — 6 Stunden |
2 Stunden |
Wichtige, aber nicht geschäftskritische Workloads |
$$ |
Silber |
6 Stunden — ein paar Tage |
24 Stunden |
Nicht kritische Workloads |
$ |
Wenn Sie Workloads auf Ausfallsicherheit auslegen, sollten Sie den Zusammenhang zwischen hoher Verfügbarkeit und Betriebskontinuität berücksichtigen. Wenn ein Workload beispielsweise eine Verfügbarkeit von 99,99 Prozent erfordert, sind nicht mehr als 53 Minuten Ausfallzeit pro Jahr tolerierbar. Es kann mindestens 5 Minuten dauern, bis ein Fehler erkannt wird, und weitere 10 Minuten, bis ein Bediener eingreift, Entscheidungen über Wiederherstellungsschritte trifft und diese Schritte ausführt. Es ist nicht ungewöhnlich, dass es 30 bis 45 Minuten dauert, bis ein einzelnes Problem behoben ist. In diesem Fall ist es von Vorteil, eine Strategie für mehrere Regionen zu verfolgen, um eine isolierte Instanz bereitzustellen, die korrelierte Auswirkungen beseitigt. Auf diese Weise kann der Betrieb fortgesetzt werden, indem innerhalb einer bestimmten Zeit ein Failover vorgenommen wird, während Sie die anfängliche Beeinträchtigung selbstständig prüfen. In diesem Fall ist es erforderlich, die angemessene begrenzte Wiederherstellungszeit festzulegen und sicherzustellen, dass eine entsprechende Anpassung erfolgt.
Ein regionsübergreifender Ansatz eignet sich möglicherweise für geschäftskritische Workloads mit extremen Verfügbarkeitsanforderungen (z. B. 99,99 Prozent oder mehr Verfügbarkeit) oder strengen Anforderungen an die Betriebskontinuität, die nur durch einen Failover in eine andere Region erfüllt werden können. Diese Anforderungen gelten jedoch in der Regel nur für einen kleinen Teil des Workload-Portfolios eines Unternehmens, für das eine begrenzte Wiederherstellungszeit gilt, die in Minuten oder Stunden gemessen wird. Sofern für eine Anwendung keine Wiederherstellungszeit von Minuten oder einigen Stunden erforderlich ist, ist es möglicherweise besser, abzuwarten, bis eine regionale Unterbrechung der Anwendung in der betroffenen Region behoben ist. Dieser Ansatz ist in der Regel auf Workloads niedrigerer Stufen ausgerichtet.
Vor der Implementierung einer Architektur mit mehreren Regionen sollten sich Entscheidungsträger und technische Teams im Hinblick auf die Auswirkungen auf die Kosten, einschließlich betrieblicher und infrastruktureller Kostentreiber, einig sein. Eine typische Architektur mit mehreren Regionen kann doppelt so hohe Kosten verursachen wie ein Ansatz mit nur einer Region. Zwar gibt es mehrere regionsübergreifende Muster für die Geschäftskontinuität, wie z. B. den Betrieb mit Hot-Standby -, Warm-Standby - oder Kontrolllampe, aber das Muster mit dem geringsten Risiko, die Wiederherstellungsziele zu erreichen, beinhaltet den Betrieb im Hot-Standby-Modus, wodurch sich die Kosten für Ihre Arbeitslast verdoppeln.
Wichtige Leitlinien
-
Ziele für Verfügbarkeit und Kontinuität des Betriebs wie RTO und RPO sollten pro Workload festgelegt und mit den Geschäfts- und IT-Stakeholdern abgestimmt werden.
-
Die meisten Ziele in Bezug auf Verfügbarkeit und Kontinuität des Betriebs können innerhalb einer einzigen Region erreicht werden. Für Ziele, die innerhalb einer einzelnen Region nicht erreicht werden können, sollten Sie mehrere Regionen in Betracht ziehen, wobei ein klares Bild von Kompromissen zwischen Kosten, Komplexität und Nutzen gezogen werden muss.
