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 der AWS Regel unterteilen wir Dienste in die „Datenebene“ und die „Kontrollebene“. Die Datenebene ist zuständig für die Bereitstellung von Echtzeitservices, während die Steuerebene dazu verwendet wird, die Umgebung zu konfigurieren. Beispielsweise handelt es sich bei EC2 Amazon-Instances, RDS Amazon-Datenbanken und Lese-/Schreibvorgängen für Amazon DynamoDB-Tabellen um Datenebenenoperationen. Im Gegensatz dazu werden das Starten neuer EC2 Instances oder RDS Datenbanken oder das Hinzufügen oder Ändern von Tabellenmetadaten in DynamoDB als Operationen auf der Steuerungsebene betrachtet. 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, wenn es darum geht, ihre Anwendungen kritisch zu bewerten und Unterkomponenten mit unterschiedlichen Verfügbarkeitsanforderungen zu identifizieren. Die Ziele des Verfügbarkeitsdesigns werden dann auf die verschiedenen Aspekte zugeschnitten, und es werden die entsprechenden Anstrengungen unternommen, um das System zu entwickeln. AWS verfügt über umfangreiche Erfahrung in der Entwicklung von Anwendungen mit einer Reihe von Verfügbarkeitszielen, einschließlich Services mit einer Verfügbarkeit von 99,999% oder mehr. AWS Solution Architects (SAs) können Ihnen helfen, Ihr Design entsprechend Ihren Verfügbarkeitszielen zu entwerfen. Durch AWS frühzeitige Einbindung in Ihren Entwurfsprozess können wir Sie besser dabei unterstützen, Ihre Verfügbarkeitsziele zu erreichen. 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. Definieren Sie zunächst ein Framework für die Geschäftskritikalität mit definierter RTO Verfügbarkeit und können dann die einzelnen Workloads bewerten. RPO 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.