High Availability
High-Availability-(HA-)Systeme sind so konzipiert, dass sie das maximale Potenzial für Verfügbarkeit und Barrierefreiheit sicherstellen.
Unternehmensanwendungen sind für den täglichen Geschäftsbetrieb von entscheidender Bedeutung und müssen verfügbar sein. Es wird erwartet, dass diese Systeme immer funktionieren und es keine Ausfallzeiten geben wird. Auch wenn es unmöglich ist, Ausfallzeiten vollständig auszuschließen, können Sie die negativen Auswirkungen von Ausfallzeiten minimieren, indem Sie sicherstellen, dass Ihre Anwendungen über HA verfügen. Um HA sicherzustellen, beseitigen Sie Single Points of Failure, sodass die Anwendung auch dann ausgeführt wird und verfügbar bleibt, wenn Komponenten ausfallen. Oracle Cloud Infrastructure (OCI) bietet HA-Funktionen und zuverlässige und resiliente Best Practices für Cloud-Topologien, mit denen Sie HA-Unternehmensanwendungen erstellen können.
Da Multi-Tier- oder 3-Tier-Architekturen in traditionellen On-Premise-Unternehmensanwendungen üblich sind, zeigen wir Ihnen anhand einer Multi-Tier-Unternehmensanwendung, wie Sie OCI-HA-Funktionen und die zuverlässigen und resilienten Best Practices für Cloud-Topologien verwenden können, um diese Anwendung hochverfügbar zu machen. Das folgende Diagramm zeigt ein Beispiel für eine Unternehmensanwendung in einer HA-Konfiguration mit einer Region.
Diese Informationen beziehen sich nicht auf die Konnektivität von On-Premise- zu OCI- oder Notfallwiederherstellungs-(DR-) Aspekten der Infrastruktur.
HA-Konzepte
Wenn Ihre Infrastruktur für eine nahezu Vollzeitverfügbarkeit konfiguriert ist, handelt es sich um ein HA-System.
Beachten Sie die folgenden Schlüsselelemente beim Entwerfen einer High-Availability-Architektur:
- Redundanz: Verfügt jede Ressource über mindestens eine ähnliche Ressource, die bereit ist, einzugreifen und zu übernehmen? Beachten Sie, dass die Ressourcen in jeder im Diagramm gezeigten Tier immer eine Primär- und eine Standbydatenbank haben und die Ressourcen sich in verschiedenen Availability-Domains und Faultdomains befinden, um Single Points of Failure (SPOF) zu vermeiden.
- Monitoring: Funktionieren die primären Ressourcen wie erwartet? Wenn nicht, an welchem Punkt übernimmt die Backupressource die Rolle der Primärdatenbank?
- Failover: Wenn die Kriterien für das Auslösen eines Wechsels von der Primärdatenbank zur Standbydatenbank erfüllt sind, ist die Standbydatenbank bereit?
Um HA zu erreichen, muss ein System alle diese Elemente berücksichtigen. High Availability kann zwar auf vielen verschiedenen Ebenen (einschließlich Anwendungsebene und Cloud-Infrastrukturebene) erreicht werden, der Schwerpunkt dieses Abschnitts liegt jedoch auf der Cloud-Infrastrukturebene. Weitere Informationen finden Sie unter Informationen zur Architektur einer hochverfügbaren Cloud-Topologie.
HA-Ansatz wählen
Einige Anwendungen sind wichtiger als andere. Anhand des folgenden Entscheidungsbaums können Sie bestimmen, welche OCI-HA-Funktionen beim Deployment von Multi-Tier-Unternehmensanwendungen auf OCI verwendet werden sollen.
Für unsere Beispiel-Unternehmensanwendung ist HA erforderlich, um einen Availability-Domainausfall zu überstehen. Darüber hinaus müssen wir einen regionalen Ausfall überstehen können, können aber Ausfallzeiten bewältigen, wenn eine Region betroffen ist. Aus diesen Gründen haben wir ein aktives/passives Deployment in mehreren Regionen gewählt. Die Aspekte des passiven Deployments werden unter Disaster Recovery behandelt.
HA messen
High Availability ist die Fähigkeit eines Systems, eine kontinuierliche Betriebsleistung oder Betriebszeit über einen bestimmten Zeitraum zu erreichen.
Die Verfügbarkeit wird in der Regel als Prozentsatz der Betriebszeit in einem Jahr ausgedrückt, häufig in der Anzahl der "Neuner". In der folgenden Tabelle werden die Verfügbarkeitsklassen und die zugehörige Ausfallzeit jeder Klasse angezeigt.
Verfügbarkeit % | Verfügbarkeit (Anzahl der Neuner) | Ausfallzeit pro Jahr | Ausfallzeit pro Monat | Ausfallzeit pro Woche | Ausfallzeit pro Tag |
---|---|---|---|---|---|
90% | Verfügbarkeitsklasse 1 | 36,53 Tage | 73,05 Stunden | 16,80 Stunden | 2,40 Stunden |
99% | Verfügbarkeitsklasse 2 | 3,65 Tage | 7,31 Stunden | 1,68 Stunden | 14,40 Minuten |
99,9% | Verfügbarkeitsklasse 3 | 8,77 Stunden | 43,83 Minuten | 10,08 Minuten | 1,44 Minuten |
99,99% | Verfügbarkeitsklasse 4 | 52,60 Minuten | 4,38 Minuten | 1,01 Minuten | 8,64 Sekunden |
99,999% | Verfügbarkeitsklasse 5 | 5,26 Minuten | 26,30 Sekunden | 6,05 Sekunden | 864,00 Millisekunden |
99,9999% | Verfügbarkeitsklasse 6 | 31,56 Sekunden | 2,63 Sekunden | 604,80 Millisekunden | 86,40 Millisekunden |
99,99999% | Verfügbarkeitsklasse 7 | 3,16 Sekunden | 262,98 Millisekunden | 60,48 Millisekunden | 8,64 Millisekunden |
99,999999% | Verfügbarkeitsklasse 8 | 315,58 Millisekunden | 26,30 Millisekunden | 6,05 Millisekunden | 864,00 Mikrosekunden |
99,9999999% | Verfügbarkeitsklasse 9 | 31,56 Millisekunden | 2,63 Millisekunden | 604,80 Mikrosekunden | 86,40 Mikrosekunden |
Jeder Oracle Cloud Infrastructure-Service verfügt in der Regel über ein Service Level Agreement (SLA), das die erwartete Verfügbarkeit des Service definiert. Die meisten Cloud-Lösungen erfordern eine Kombination von Services, um die gewünschte Architektur für Ihr Cloud-Deployment zu erreichen. Wenn Services in Kombination verwendet werden, hängt die Verfügbarkeit des Systems insgesamt von der Verfügbarkeit jedes Subsystems ab. Das gesamte SLA für ein System mit mehreren Komponenten wird als zusammengesetztes SLA bezeichnet.
Um das zusammengesetzte SLA eines Systems oder einer Anwendung zu berechnen, berücksichtigen Sie alle Subsysteme und die Konfiguration dieser Systeme. Beispiel: Ein Szenario, bei dem eine Anwendung von zwei Systemen abhängig ist: System A und System B. Jedes System hat eine Verfügbarkeit von 99,9%. Die Systeme sind seriell abhängig, wie in der folgenden Abbildung dargestellt.
Wenn System A oder System B nicht verfügbar ist, ist das gesamte System nicht verfügbar. Für diesen Typ der Systemkonfiguration können Sie das zusammengesetzte SLA berechnen, indem Sie die Verfügbarkeit der beiden Systeme multiplizieren: 99,9% × 99,9% = 99,8%. Aufgrund der seriellen Abhängigkeit zwischen den beiden Systemen ist das resultierende zusammengesetzte SLA von 99,8% niedriger als die einzelnen SLAs für jedes System.
HA-Design - Überlegungen
Oracle Cloud Infrastructure stellt die Bausteine bereit, mit denen Sie HA für Ihre Infrastruktur aktivieren können.
Die Beispielunternehmensanwendung verwendet Services innerhalb der OCI-Konzepte von Regionen, Availability-Domains und Faultdomains. Die Verwendung mehrerer Availability-Domains und Faultdomains innerhalb jeder dieser Availability-Domains erhöht die Redundanz und eliminiert SPOF. Hintergrundinformationen zu Regionen und einer Liste der Ressourcen, die regionsübergreifend, in einer einzelnen Region oder innerhalb einer Availability-Domain verfügbar sind, finden Sie unter Regionen und Availability-Domains.
Wir empfehlen Ihnen, die relevanten Informationen zur Resilienz des OCI-Produkts zu lesen. Passen Sie dann basierend auf den ausgewählten OCI-Plattformprodukten die Architekturen an, um Lücken zwischen den Produktfunktionen und ihren HA-Anforderungen zu schließen.
In Ihrer Hauptregion erstellt Oracle Ihren Mandanten. Hier werden die Identity and Access Management-(IAM-)Ressourcen Ihrer Organisation definiert. Je nach Ihren Geschäftsanforderungen können Sie andere Regionen abonnieren, und IAM propagiert Updates automatisch an alle Regionen Ihres Mandanten. Weitere Informationen finden Sie unter Regionen verwalten.
Networking
Nachdem Sie die Netzwerkgrundlage von virtuellen Cloud-Netzwerken (VCNs) und Subnetzen erstellt haben, müssen Sie den Load Balancing-Service verwenden, um den Traffic zu verteilen. Wenn ein Load Balancer bereitgestellt wird, verwendet er eine HA-Konfiguration, wie im Beispielarchitekturdiagramm dargestellt. Weitere Informationen finden Sie unter High Availability für Netzwerkressourcen planen.
Compute
Um SPOF zu eliminieren, erstellen Sie mehrere Compute-Instanzen, die auf Faultdomains in jeder der Availability-Domains verteilt sind. Platzieren Sie Compute-Instanzen hinter einem Load Balancer, um den Traffic zu verteilen und HA zu erreichen, wie in der Beispielarchitektur dargestellt. Weitere Informationen finden Sie unter Überblick über Compute Service, Best Practices für Ihre Compute-Instanzen und High Availability für Compute-Instanzen planen.
Speicher
OCI stellt eine Gruppe von Speicherservices (Block Volume, File Storage und Object Storage), bereit, die Sie konfigurieren können, um die Anforderungen einer High-Availability-Architektur zu erfüllen.
Object Storage ist eine internetbasierte, leistungsstarke Speicherplattform, die zuverlässige und kostengünstige Dauerhaftigkeit von Daten bietet. Object Storage ist ein regionaler Service und ist über alle Availability-Domains in einer Region hinweg verfügbar. Die Daten werden redundant auf mehreren Storage Servern und über mehrere Availability-Domains hinweg gespeichert, um High Availability sicherzustellen. Object Storage umfasst auch die automatische Selbstheilung und Überwachung der Datenintegrität, um die Dauerhaftigkeit und Verfügbarkeit weiter zu verbessern.
File Storage bietet ein dauerhaftes, skalierbares und sicheres Netzwerkdateisystem der Unternehmensklasse. Es verwendet eine robuste Architektur, die Daten fünfmal über verschiedene Faultdomains hinweg repliziert, um High Availability und Dauerhaftigkeit sicherzustellen. File Storage kann automatisch skaliert werden, um das Wachstum von bis zu 8 Exabyte an Daten zu unterstützen. Dateisystem-Snapshots und -Klone können verwendet werden, um Daten vor versehentlichem Löschen zu schützen und Daten sofort zu kopieren. Die Snapshots-Lebenszyklen können automatisch mit dem Feature für policy-basierte Snapshots verwaltet werden.
Block-Volumes sind dauerhaft und hochverfügbar, indem mehrere Kopien von Daten redundant auf Speicherservern mit integrierten Reparaturmechanismen gespeichert werden. Block-Volumes können an eine oder mehrere virtuelle Maschinen (VM) angehängt werden, und sie bleiben über die Lebensdauer virtueller Maschinen hinaus erhalten. Block-Volumes verbessern die High Availability mit automatisierten Backups in Object Storage und den Features Volume-Klonen weiter.
Die Schritte zum Erstellen von Speicherressourcen finden Sie unter Volumes erstellen, Dateisysteme erstellen und Buckets verwalten. Best Practices finden Sie unter High Availability für Storage planen.
Datenbank
OCI-Oracle-Datenbanken sind in mehreren Bereitstellungsmodellen oder Varianten erhältlich. Jedes Modell bietet immer mehr HA-Funktionen.
Unabhängig vom verwendeten Datenbanksystem wird empfohlen, dass Sie auf Maximum Availability Architecture (MAA) verweisen. Hierbei handelt es sich um eine Reihe von Best Practices, die von Oracle-Technikern über viele Jahre für die integrierte Verwendung von Oracle High-Availability-, Datenschutz- und Disaster-Recovery-Technologien entwickelt wurden.
Mit OCI Base Database Service können Sie die volle Kontrolle über Ihre Daten haben und gleichzeitig die Funktionen von Oracle Database und OCI nutzen. Eine Liste der unterstützten Datenbankeditionen und der zugrunde liegenden Compute-Ausprägungen, auf denen sie bereitgestellt werden können, finden Sie in der Dokumentation zu OCI Base Database Service. Die genannten HA-Features gelten für alle Datenbankversionen oder die zugrunde liegenden Compute-Ausprägungen.
Die Enterprise Edition Extreme Performance Edition ermöglicht ein RAC-(Real Application Cluster-)Datenbanksystem mit zwei Knoten, das verschiedene Faultdomains innerhalb derselben Availability-Domain umfasst. Dies bietet High Availability in den folgenden Szenarios:
- Knotenausfallschutz
- Keine Softwarewartung ohne Ausfallzeiten
- Elastische Änderungen (CPU, Arbeitsspeicher und Speicher) ohne Ausfallzeit
- (Fast) Transparente ungeplante Wartung
Wenn HA über Availability-Domains hinweg erforderlich ist, können Sie eine passive Standby-RAC-fähige Datenbank in Betracht ziehen, die das primäre RAC-Datenbanksystem spiegeln, wobei Daten über Oracle Data Guard repliziert werden. Ein Failover auf die passive Standby-Datenbank kann manuell mit einer geringen Ausfallzeit erfolgen.
Hinweis: OCI Base Database unterstützt maximal zwei RAC-Knoten. Bei Oracle Database-Versionen oder bei RAC-Knoten über 2 sollten Sie OCI Exadata Database on Dedicated Infrastructure (ExaDB-D) in Betracht ziehen.
Exadata Database on Dedicated Infrastructure (ExaDB-D)
Exadata bietet integrierte High Availability-Funktionen.
Alle vorhandenen Best Practices für Ihre On-Premise-Exadata sind anwendbar. Für die OCI Base Database wie RAC und Data Guard (für Standbydatenbank) beschriebene Konzepte gelten für Exadata Database on Dedicated Infrastructure (ExaDB-D) mit den folgenden zusätzlichen Attributen:
- Exadata Database on Dedicated Infrastructure (ExaDB-D) ermöglicht mehr als zwei RAC-Knoten. Dies ist eine Einschränkung für das Basisdatenbanksystem.
- Exadata-Skalierbarkeit, -Performance und -Verfügbarkeit
- Exadata-Agilität mit sich ändernder Anzahl an VMs, Speicher- und Compute-Ressourcen
- Datenschutz und Exadata QoS für Datenbankvorgänge
Exadata verfügt über eine sofortige Fehlererkennung, mit der Datenbankknoten-, Speicherserver- und Netzwerkfehler in weniger als 2 Sekunden erkannt und die Betriebszeit und Performance von Anwendungen und Datenbanken wieder aufgenommen werden können.
Wir empfehlen die folgenden Konfigurationen, um eine kontinuierliche Verfügbarkeit für Ihre Anwendungen sicherzustellen.
- Verwenden Sie von Oracle Clusterware verwaltete Datenbankservices, um Ihre Anwendung zu verbinden. Verwenden Sie für Oracle Data Guard-Umgebungen rollenbasierte Services.
- Verwenden Sie die empfohlene Verbindungszeichenfolge mit integrierten Timeout, Wiederholungen und Verzögerungen, damit bei Ausfällen keine Fehler bei eingehenden Verbindungen auftreten.
- Konfigurieren Sie Ihre Verbindungen mit Fast Application Notification.
- Nutzen Sie Application Continuity oder Transparent Application Continuity, um aktive, nicht festgeschriebene Transaktionen nach Fehlern transparent wiederzugeben.
Standardmäßig ist Oracle Autonomous Database (ADB) hochverfügbar und umfasst eine Konfiguration mit mehreren Knoten zum Schutz vor lokalisierten Hardwarefehlern.
Jeder ADB-Anwendungsservice befindet sich in mindestens einer Oracle Real Application Clusters-(Oracle RAC-)Instanz mit der Option, ein Failover zu einer anderen verfügbaren Oracle RAC-Instanz für ungeplante Ausfälle oder geplante Wartungsaktivitäten durchzuführen, um Ausfallzeiten von null oder nahezu null zu ermöglichen.
Wichtige Datenbankupgrades sind automatisiert. Darüber hinaus ist die Ausfallzeit für Oracle Autonomous Database Serverless (ADB-S) minimal.
Die Betriebszeit-Service-Level Agreements (SLAs) pro Monat betragen 99,95% (maximal 22 Minuten Ausfallzeit pro Monat).
ADB-S ermöglicht eine lokale (über ADs oder innerhalb von ADs für einzelne AD-Regionen) und eine zusätzliche Remotestandbydatenbank.
Autonomous Data Guard fügt einem Exadata-Rack lokal (über ADs oder innerhalb von ADs für einzelne AD-Regionen) eine symmetrische Standbydatenbank mit Oracle Data Guard hinzu, wobei eine weitere Datenbank in einer anderen Region vorhanden ist. Die Primär- und Standbydatenbanksysteme sind symmetrisch konfiguriert, um sicherzustellen, dass die Servicesbenen in Bezug auf die Performance nach den Data Guard-Rollenwechsel beibehalten werden.
Die Best Practices zur Aufrechterhaltung der Anwendungsbetriebszeiten sind hier beschrieben.
Monitoring
Mit Monitoring können Sie Ihre Cloud-Ressourcen aktiv und passiv überwachen, um die Verfügbarkeit zu verbessern und konsistente Servicelevel zu erzielen. Ein Beispiel finden Sie unter End-to-End-Überwachung von Anwendungen, die auf Oracle Cloud Infrastructure ausgeführt werden.
Mehr erfahren
Lösungs-Playbooks:
- Informationen zur Architektur einer hochverfügbaren Cloud-Topologie
- Zuverlässige und resiliente Cloud-Topologiepraktiken
- Infrastruktur für das Deployment von Oracle Enterprise Performance Management in der Cloud entwerfen (HA-Architektur: Eine Region, eine Availability-Domain)
Referenzarchitekturen:
- Hochverfügbare Webanwendung bereitstellen
- Stellen Sie Oracle REST Data Services mit High Availability auf Oracle Cloud Infrastructure bereit
- Hochverfügbares MySQL InnoDB-Cluster bereitstellen
- Hochverfügbare ASP.Net-Anwendungen auf Oracle Cloud Infrastructure bereitstellen
- Hochverfügbares CockroachDB-Cluster bereitstellen
- Hochverfügbare Bare-Metal-Datenbanken bereitstellen
- Hochverfügbare Microsoft SQL Server-Datenbank bereitstellen
- Hochverfügbares Apache Cassandra-Cluster bereitstellen
- Hochverfügbaren, verteilten Cache mit Redis bereitstellen
- Hochverfügbaren Session Border Controller bereitstellen
Blogs und andere Ressourcen: