Höchste Zuverlässigkeit
Entwerfen Sie anhand der Grundsätze von High Availability und Disaster Recovery eine Cloud-Architektur für höchste Zuverlässigkeit.
High-Availability-(HA-)Systeme sollen sicherstellen, dass sie das maximale Potenzial für Betriebszeit und Barrierefreiheit haben. Um HA sicherzustellen, beseitigen Sie Single Points of Failure, sodass die Anwendung auch dann ausgeführt wird und verfügbar bleibt, wenn Komponenten ausfallen.
Mit einem gut strukturierten Disaster-Recovery-(DR-)Plan können Sie Ihren Benutzern nach Katastrophen schnell wieder Services bereitstellen. DR dient der Vorbereitung auf Katastrophen und dem schnellen Recovery danach. Eine Katastrophe kann jedes Ereignis sein, das Ihre Anwendungen gefährdet, von Netzwerkausfällen über Geräte- und Anwendungsausfälle bis hin zu Naturkatastrophen. Zum Entwerfen von DR müssen Sie Ihre geschäftskritischen Anwendungen in mehreren Regionen bereitstellen und regionsübergreifend asynchrone Replikation verwenden. Planen Sie DR auf allen Layern des Stacks, einschließlich Networking, Compute, Object Storage, Database und Monitoring.
Architekturempfehlungen für höchste Zuverlässigkeit
Wir empfehlen einen gestaffelten Ansatz für höchste Zuverlässigkeit. In der ersten Phase stellen Sie eine Architektur mit HA-Funktionen bereit, indem Sie die Faultdomains in einer Availability-Domain nutzen. Wenn mehr Resilienz erforderlich ist, stellen Sie in der zweiten Phase eine Architektur bereit, die sich über mehrere Regionen erstreckt.
Weitere Informationen zu Regionen, Availability-Domains und Faultdomains finden Sie unter Regionen und Availability-Domains.
Phase 1: Instanzen auf Faultdomains verteilen
High-Availability-Systeme sind darauf ausgelegt, Single Points of Failure zu vermeiden. Einer der Hauptgrundsätze beim Entwerfen eines High-Availability-Systems ist die Verteilung von Instanzen auf mehrere Faultdomains. Wenn Sie Faultdomains ordnungsgemäß nutzen, können Sie die Verfügbarkeit von Anwendungen erhöhen, die auf Oracle Cloud Infrastructure ausgeführt werden.
Die Architektur Ihrer Anwendung bestimmt, ob Sie Instanzen mithilfe von Faultdomains trennen oder gruppieren.
Szenario A: High-Availability-Architektur
Bei diesem Szenario ist eine High-Availability-Anwendung vorhanden, beispielsweise über zwei Webserver und eine Clusterdatenbank. In diesem Szenario müssen Sie einen Webserver und einen Datenbankknoten in einer Faultdomain und die andere Hälfte jedes Paares in einer anderen Faultdomain gruppieren. Diese Platzierung stellt sicher, dass ein Fehler in einer Faultdomain nicht zu einem Ausfall in der Anwendung führt.
Szenario B: Architektur mit einem Webserver und einer Datenbankinstanz
In diesem Szenario ist die Anwendungsarchitektur nicht hochverfügbar, beispielsweise wenn Sie einen Webserver und eine Datenbankinstanz haben. In diesem Szenario müssen sich Webserver und Datenbankinstanz in derselben Faultdomain befinden, um Ausfälle beim Kunden zu minimieren. Durch diese Platzierung wird sichergestellt, dass Ihre Anwendung nur von Fehlern dieser einzelnen Faultdomain betroffen ist, wodurch insgesamt eine höhere Anwendungsverfügbarkeit erzielt wird.
Zusammengesetzte SLAs
Wenn Services in Kombination verwendet werden, hängt die gesamte Systemverfügbarkeit von der Verfügbarkeit der einzelnen Subsysteme ab. Um die Verfügbarkeit eines Systems mit mehreren Unterkomponenten zu maximieren, reduzieren Sie die Abhängigkeiten der Unterkomponenten untereinander. Das bedeutet, dass Sie je nach Ihrer Anwendungsarchitektur für einen bestimmten Entwicklungsaufwand möglicherweise die größte Zuverlässigkeit erreichen, indem Sie die Faultdomains in einer Availability-Domain nutzen, anstatt Ihre Ressourcen auf Availability-Domains zu verteilen.
Phase 2: Ressourcen in mehreren Regionen bereitstellen
Um die Resilienz Ihrer Workloads zu maximieren, stellen Sie Ihre Cloud-Workloads über mehrere Regionen und nicht über mehrere Availability-Domains hinweg bereit.
Durch das Deployment in mehreren Regionen können Sie die Risiken im Zusammenhang mit einem regionalen Ausfall minimieren, da ein regionaler Ausfall alle Availability-Domains in der Region betreffen kann. Durch die Bereitstellung in mehreren Regionen wird auch der Wert des technischen Aufwands maximiert, den Sie in die Portierung Ihrer Workloads über mehrere Data Center hinweg investieren.
Szenario C: Architektur mit mehreren Regionen
In diesem Szenario repliziert Ihre Architektur denselben Stack über zwei Regionen hinweg.
Um eine konsistente Datenquelle in beiden Regionen bereitzustellen, verwenden Sie Replikationsfunktionen wie GoldenGate für den Datenlayer, Autonomous Data Guard für den Datenbanklayer und Object Storage-Replikations-Policys für den Quell-Bucket, in dem die Region und der zu replizierende Bucket identifiziert werden.
Erstellen Sie für das Frontend und den Anwendungslayer einen Load Balancer, und konfigurieren Sie die Health-Check-Funktionen in den Backend-Ressourcen, die über Faultdomains in beiden Regionen bereitgestellt werden. Jedes Mal, wenn Sie eine neue Anwendung in Produktionsumgebungen bereitstellen, stellen Sie die Anwendung für Instanzen in beiden Regionen bereit.
Mehr erfahren
Dokumentation: