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.
Verstehen des Verfügbarkeitsbedarfs
Es ist weit verbreitet, die Verfügbarkeit einer Anwendung anfänglich als einzelnes Ziel für die Anwendung als Ganzes zu betrachten. Bei näherer Betrachtung können wir jedoch sehen, dass bestimmte Aspekte einer Anwendung oder eines Service unterschiedliche Verfügbarkeitsanforderungen aufweisen. Einige Systeme legen beispielsweise den Schwerpunkt auf die Fähigkeit, neue Daten vor dem Abrufen vorhandener Daten zu empfangen und zu speichern. Andere Systeme priorisieren Echtzeitvorgänge gegenüber Vorgängen, die sich auf die Konfiguration oder die Umgebung eines Systems auswirken können. Services können zu bestimmten Zeiten eines Tages möglicherweise mit sehr hohen Verfügbarkeitsanforderungen verknüpft sein, aber außerhalb dieser Zeiten wesentlich längere Ausfallzeiten tolerieren. Dies sind einige der Möglichkeiten, um eine Anwendung in ihre Bestandteile aufzugliedern und anschließend die Verfügbarkeitsanforderungen für diese Teile zu bewerten. Der Vorteil dieses Ansatzes besteht darin, dass der Fokus der Bemühungen (und der Kosten) gemäß den spezifischen Anforderungen auf die Verfügbarkeit gelegt werden kann, statt das gesamte System auf die strengste Anforderung hin zu konzipieren.
| Empfehlung |
|---|
| Sie sollten die einzigartigen Aspekte Ihrer Anwendungen kritisch bewerten und die Verfügbarkeits- und Notfallwiederherstellungsdesignziele ggf. differenzieren, damit sie die Anforderungen Ihres Unternehmens widerspiegeln. |
In AWS teilen wir Services in der Regel in „Datenebene“ und „Steuerebene“ auf. Die Datenebene ist zuständig für die Bereitstellung von Echtzeitservices, während die Steuerebene dazu verwendet wird, die Umgebung zu konfigurieren. So handelt es sich bei Amazon-EC2-Instances, Amazon-RDS-Datenbanken und Schreib-/Lesevorgängen in Amazon-DynamoDB-Tabellen beispielsweise ausschließlich um Datenebenenvorgänge. Im Gegensatz dazu handelt es sich beim Starten neuer EC2-Instances oder RDS-Datenbanken oder dem Hinzufügen oder Ändern von Tabellenmetadaten in DynamoDB um Vorgänge auf Steuerebene. Ein hoher Verfügbarkeitsgrad ist für all diese Funktionen wichtig. Allerdings verfolgt die Datenebene in der Regel Designziele für eine höhere Verfügbarkeit als die Steuerebene. Aus diesem Grund sollten Workloads mit hohen Verfügbarkeitsanforderungen keine Laufzeitabhängigkeiten von Abläufen der Steuerebene haben.
Viele AWS-Kunden verfolgen einen ähnlichen Ansatz, um ihre Anwendungen kritisch zu bewerten und Unterkomponenten mit abweichenden Verfügbarkeitsanforderungen zu identifizieren. Verfügbarkeitsdesignziele werden dann auf die verschiedenen Aspekte zugeschnitten und es werden entsprechende Bemühungen unternommen, um das System weiterzuentwickeln. AWS verfügt über ausgeprägte Erfahrungen beim Engineering von Anwendungen mit verschiedenen Verfügbarkeitsdesignzielen, einschließlich Services mit einer Verfügbarkeit von 99,999 % oder mehr. AWS Solution Architects (SAs) können Sie dabei unterstützen, ein Design entsprechend Ihren Verfügbarkeitszielen zu erarbeiten. Je eher Sie AWS in Ihren Designprozess integrieren, desto besser können wir Sie bei der Erfüllung Ihrer Verfügbarkeitsziele unterstützen. Das Planen der Verfügbarkeit erfolgt nicht erst direkt vor der Einführung Ihrer Workload. Es ist ein kontinuierlicher Prozess, mit dem Sie Ihr Design mit wachsender Kenntnis, dem Kennenlernen realer Ereignisse und der Bewältigung verschiedener Fehlerarten anpassen können. Anschließend können Sie geeignete Anstrengungen unternehmen, um Ihre Implementierung zu verbessern.
Die Verfügbarkeitsanforderungen, die für eine Workload erforderlich sind, müssen den geschäftlichen Anforderungen und der Kritikalität entsprechen. Legen Sie zunächst unternehmenskritische Rahmenbedingungen mit definieren RTO-, RPO- und Verfügbarkeitswerten fest, um anschließend die einzelnen Workloads zu bewerten. Ein solcher Ansatz erfordert, dass die Mitarbeiter, die an der Implementierung der Workload beteiligt sind, über das Framework und die Auswirkungen ihrer Workload auf die Geschäftsanforderungen informiert sind.
