Informationen zum Verwalten von Fehlern

Die gestreckte Clustertopologie von Oracle Fusion Middleware (FMW) ist resilienz gegenüber Fehlern in jeder einzelnen Komponente.

Jede Site befolgt die in der Topologie des Oracle FMW Enterprise-Deployments beschriebenen Best Practices für High Availability. So wird sichergestellt, dass lokale Redundanz vor Unterbrechungen auf Komponentenebene (wie Load Balancer, Oracle HTTP Server-Instanzen, Oracle WebLogic Server oder Datenbankinstanz) schützt.

In den folgenden Abschnitten werden die Überlegungen zur Adressierung von Szenarios wie einem vollständigen Tierfehler innerhalb eines Standorts oder einem vollständigen Sitefehler erläutert.

Verwalten Sie den Ausfall aller Webserver auf einer Website

Wenn eine Site alle Oracle HTTP Server-Instanzen verliert, muss das Frontend-System (ob ein globaler Load Balancer oder eine Steuerungs-Policy für Oracle Cloud Infrastructure-(OCI-)Trafficmanagement) die Site als fehlerhaft markieren.

Alle Clientanforderungen, unabhängig von ihrer Standortvoreinstellung, werden an die andere Site weitergeleitet.

Daher erhalten die Oracle WebLogic-Server der Site mit den ausgefallenen Webservern keine neuen Anforderungen. Sie können weiterhin einige Verarbeitungsschritte ausführen (z.B. die Verarbeitung von Oracle SOA-Composites und Java Message Service-(JMS-)Nachrichten). HTTP-Callbacks, die intern von diesen Servern generiert werden, schlagen jedoch fehl, weil sie auf ihre eigene Site verweisen, deren Webserver ausgefallen sind.

Das folgende Diagramm zeigt Fehler in allen Webservern auf einer Site

Beschreibung der Abbildung failure-all-web-servers-one-site.png

Fehler-all-web-servers-one-site-oracle.zip

Nach Fehler beheben

Für eine sofortige Wiederherstellung nach einem Ausfall auf allen Webservern auf einer Site ist kein manueller Eingriff erforderlich.

Clients werden mithilfe von Steuerungs-Policys für Oracle Cloud Infrastructure (OCI) Traffic Management oder dem Global Load Balancer (GLBR) automatisch an die andere Site umgeleitet.

Wenn die Wiederherstellung der verlorenen Webserverinstanzen kurzfristig nicht möglich ist, können Sie die folgenden Schritte ausführen, um die WebLogic-Server der Site mit der ausgefallenen Web-Tier zu verwenden:

1. Konfigurieren Sie die Oracle HTTP Server-(OHS-)Instanzen an der anderen Site, um Anforderungen an die Oracle WebLogic Server-Instanzen auf der ausgefallenen Site weiterzuleiten.
   1. Aktualisieren Sie die OHS-Konfiguration, und setzen Sie den Parameter DynamicServerList auf ON.
   2. Wenden Sie diese Änderung an, indem Sie OHS im Rolling-Modus neu starten, um Ausfallzeiten zu vermeiden.
   3. Stellen Sie außerdem sicher, dass die regionsübergreifende Kommunikation von den Webservern zu den WebLogic-Servern auf der anderen Site zulässig ist.
2. Um Fehler bei HTTP-(Hypertext Transfer Protocol-)Callbacks zu verhindern, die von der Site mit nicht verfügbaren OHS-Servern stammen, aktualisieren Sie den Eintrag für den Frontend-Namen in der Datei /etc/hosts oder dem DNS (Private Domain Name System) der WebLogic-Serverhosts, um auf den Load Balancer an der anderen Site zu verweisen.

Nachdem die ausgefallenen Server wieder verfügbar sind:

1. Starten Sie die OHS-Prozesse in der ausgefallenen Site.

   Sobald die Oracle Cloud Infrastructure Health Checks wieder in Ordnung sind, führt die Trafficmanagement-Steuerungs-Policy ein Load Balancing der Clientanforderungen zwischen beiden Sites durch, gemäß den definierten Regeln.

2. Setzen Sie DynamicServerList in der anderen Site erneut auf OFF.
3. Setzen Sie alle Änderungen in der Datei /etc/hosts (oder dem privaten DNS) der WebLogic-Server zurück, sodass sie erneut auf ihren eigenen Site Load Balancer verweisen.

Die folgende Abbildung zeigt Java Message Service-(JMS-)Warteschlangennachrichten und Clientfehleranforderungen bei einem Ausfall aller Webserver auf einer Site:

Beschreibung der Abbildung failure-messages-all-web-servers-one-site.png

Erwartetes Recovery-Zeitziel

Bei der Verwendung von Steuerungs-Policys für das Oracle Cloud Infrastructure-(OCI-)Trafficmanagement für globales Balancing werden Fehler während eines Zeitraums von etwa 1 Minute + DNS-Laufzeit (TTL) beobachtet.

Die DNS-Aktualisierung wirkt sich auf Clients aus, deren Steuerungs-Policy-Voreinstellung auf die fehlerhafte Region gesetzt ist. Der TTL-Wert bestimmt, wie lange diese Clients den alten Eintrag weiter verwenden, bevor er aktualisiert wird, um auf den fehlerfreien Standort zu verweisen. Die zusätzliche Zeit (ca. 1 Minute) hängt von der Häufigkeit und dem Timeout der Health Checks ab, die in der OCI-Steuerungs-Policy konfiguriert sind (im obigen Test wurden 30 Sekunden für das Health Check-Intervall und ein Timeout von 10 Sekunden verwendet).

Bei der Verwendung eines Global Load Balancers (GLBR) hängt die Ausfallzeit von der Häufigkeit der in GLBR konfigurierten Health Checks ab. Sobald der GLBR einen Pool als fehlerhaft markiert, werden die eingehenden Anfragen an die andere Site weitergeleitet. Bei einem GLBR gibt es kein DNS-Update, sodass der TTL-Wert des Frontend-Eintrags irrelevant ist.

Fehler aller Oracle WebLogic-Server auf einer Site verwalten

Wenn alle WebLogic-Server an einer Site heruntergefahren werden, setzt die andere Site die Verarbeitung von Anforderungen fort.

Der Load Balancer der ausgefallenen Site gibt eine nicht erfolgreiche Antwort zurück. Daher muss das globale Frontend-Balancing-Feature, das auf Steuerungs-Policys und Health Checks für Oracle Cloud Infrastructure-(OCI-)Traffic basiert, die Site als fehlerhaft markieren. Alle Clientanforderungen, unabhängig von ihrer Präferenz, werden an die andere Site weitergeleitet.

Die Services WebLogic Java Message Service (JMS) und Java Transaction API (JTA) werden automatisch zu den Servern auf der anderen Site migriert, wenn Automatic Service Migration zusammen mit persistenten Java Database Connectivity-(JDBC-)Speichern verwendet wird.

Wenn im SOA-Fall von Oracle Fusion Middleware (FMW) der Cluster-Master für automatisches Recovery auf den ausgefallenen Servern gehostet wurde, entsteht auf der verfügbaren Site ein neuer Cluster-Master. Dieser Server führt ein automatisches Recovery von SOA-Instanzen durch, die auf der anderen Site initiiert wurden.

Das folgende Diagramm zeigt den Fehler aller WebLogic-Server auf einer Site:

Beschreibung der Abbildung failure-all-weblogic-servers-one-site.png

Fehler-all-weblogic-servers-one-site-oracle.zip

Die folgende Abbildung zeigt nicht erfolgreiche Clientanforderungen und JMS-Nachrichten pro Server, wenn alle WebLogic-Server auf einer Site nicht erfolgreich sind.

Beschreibung der Abbildung failure-messages-all-weblogic-servers-one-site.png

Im JMS-Nachrichtendiagramm befinden sich vier Zeilen, die jeweils die JMS-Queue eines Servers darstellen. Die grünen und blauen Linien (die fast überlappt sind) entsprechen den Servern, die getötet wurden. Die Anzahl der JMS-Nachrichten für diese Queues erhöht sich nach Beginn des Ausfalls nicht.

Die roten und gelben Linien stellen die Server dar, die in Region 2 hoch bleiben. Wenn alle Anforderungen an diese Region umgeleitet werden, erhält jeder verbleibende Server 50% der Gesamtlast. Die Rate, mit der sich Nachrichten in ihren Queues ansammeln, ist jedoch unterschiedlich. Dies liegt daran, dass die JMS-Server der ausgefallenen Server auf einen der verbleibenden Server migriert wurden. Daher werden die Nachrichten auf diesem Server jetzt von drei Queues verarbeitet. Infolgedessen wird die Steigung niedriger in der gelben angezeigt (beachten Sie, dass das Überwachungstool die Nachrichtenanzahl für die migrierten Queues nicht anzeigt).

Nach Fehler beheben

Für ein sofortiges Recovery nach einem Ausfall auf allen Oracle WebLogic Server-Servern auf einer Site sind keine manuellen Eingriffe erforderlich.

Nachdem die ausgefallenen Server wieder verfügbar sind:

1. Starten Sie die Managed Server auf der ausgefallenen Site.
2. Sobald die Oracle Cloud Infrastructure Health Checks wieder fehlerfrei sind, lädt die Steuerungs-Policy für Trafficmanagement das Load Balancing der Clientanforderungen zwischen beiden Sites gemäß den definierten Regeln.

Erwartetes Recovery-Zeitziel

Bei der Verwendung von Steuerungs-Policys für das Oracle Cloud Infrastructure-(OCI-)Trafficmanagement für globales Balancing werden Fehler während eines Zeitraums von etwa 1 Minute + DNS-Laufzeit (TTL) beobachtet.

Dies ähnelt dem Szenario, in dem ein Ausfall aller Webserver auf einer Website auftritt.

Die DNS-Aktualisierung wirkt sich auf Clients aus, deren Steuerungs-Policy-Voreinstellung auf die fehlerhafte Region gesetzt ist. Der TTL-Wert bestimmt, wie lange diese Clients den alten Eintrag weiter verwenden, bevor er aktualisiert wird, um auf den fehlerfreien Standort zu verweisen. Die zusätzliche Zeit (ca. 1 Minute) hängt von der Häufigkeit und dem Timeout der Health Checks ab, die in der OCI Traffic Management-Steuerungs-Policy konfiguriert sind (30 Sekunden wurden im Test für das Health Check-Intervall und ein Timeout von 10 Sekunden verwendet).

Bei der Verwendung eines Global Load Balancers (GLBR) hängt die Ausfallzeit von der Häufigkeit der in GLBR konfigurierten Health Checks ab. Sobald der GLBR einen Pool als fehlerhaft markiert, werden die eingehenden Anfragen an die andere Site weitergeleitet. Bei einem GLBR gibt es kein DNS-Update, sodass der TTL-Wert des Frontend-Eintrags irrelevant ist.

Fehler in der Datenbank verwalten: Data Guard Switchover und Failover

Wenn sich ein Problem nur auf die Primärdatenbank auswirkt, führen Sie so bald wie möglich ein Datenbank-Switchover oder Failover auf die andere Site aus.

Die Java Database Connectivity-(JDBC-)URL-Zeichenfolge und die Oracle Notification Service-(ONS-)Konfiguration, die zuvor unter "WebLogic-Datenquellen einrichten" bereitgestellt wurde, stellen sicher, dass die Neuverbindung automatisch mit der neuen primären Datenbank erfolgt. Für diese genauen Tests (mit Oracle Fusion Middleware (FMW) SOA FOD und selbst bei hohen Workloads von 160 gleichzeitigen Aufrufen) dauert der Datenbank-Switchover oder Failover weniger als ein paar Minuten. Diese Zeit kann je nach Systemkonfiguration und Umgebung variieren. In gut abgestimmten Systemen sind die Switchover-Zeiten von 1 bis 5 Minuten üblich. Faktoren wie Systemgröße, Ressourcen, Workload, Redo-Logsynchronisierung und Netzwerkperformance können sich jedoch auf die Gesamtdauer auswirken. Im Abschnitt "Weitere Informationen anzeigen" finden Sie Links zur Oracle Data Guard-Dokumentation und zu anderen Ressourcen.

Bei einem Switchover oder Failover der Datenbank treten Anwendungsfehler auf. Außerdem können die WebLogic-Server, die Servicemigration verwenden, vom Node Manager automatisch heruntergefahren und neu gestartet werden, wenn sie ihre Leasing-Tabelle nicht aktualisieren können. Das erwartete Verhalten mit den Standardleasingparametern lautet:

1. Wenn der Datenbankausfall sehr kurz ist (<1-2 min), wird kein automatischer Neustart des WebLogic-Servers erwartet.
2. Wenn der Datenbankausfall länger ist (2-10 Minuten), können die WebLogic-Server automatisch neu gestartet werden, weil beim Neustart der Datenbank "ein Leasing verloren" wurde.

   Das untere Limit kann erhöht werden, indem die Neuversuche für das Datenbankleasing von WebLogic optimiert werden, wie oben in "Tuning WebLogic Database Leasing konfigurieren" beschrieben.

3. Wenn der Datenbankausfall viel länger ist (>10 min), können WebLogic-Server aufgrund anderer Fehler wie dem Verlust des Zugriffs auf kritische JDBC-Speicher automatisch neu gestartet werden ("JDBC-Speicher von JTA ist nicht verfügbar").

Das folgende Diagramm zeigt den Datenbank-Switchover in der Topologie der gestreckten FMW-Cluster

Beschreibung der Abbildung stretched-clusters-db-switchover.png

gestreckt-cluster-db-switchover-oracle.zip

Die folgende Abbildung zeigt die Performance von Clientanforderungen und Java Message Service-(JMS-)Nachrichten pro Serverqueue während eines Datenbank-Switchovers in einem gestreckten FMW-Cluster.

Beschreibung der Abbildung stretched-clusters-db-switchover-messages.png

Nach Fehler beheben

So führen Sie ein sofortiges Recovery nach einem Datenbankfehler durch:

1. Führen Sie einen Datenbank-Switchover mit der Oracle Cloud Infrastructure-(OCI-)Konsole oder der Oracle Data Guard Broker-Befehlszeilenschnittstelle aus.
2. Wenn die Primärdatenbank nicht verfügbar sind, führen Sie ein Datenbank-Failover aus der Standbydatenbank aus.

   Die Oracle WebLogic Server-Server verbinden sich automatisch wieder mit der neuen Primärdatenbank, sodass keine manuellen Aktionen erforderlich sind, außer um bei Bedarf nach anwendungsspezifischen Fehlern wiederherzustellen (z.B. in Oracle SOA Suite müssen Sie Composites im Error Hospital möglicherweise wiederherstellen).

Nachdem die ausgefallenen Server wieder verfügbar sind:

1. Reaktivieren Sie die nicht erfolgreiche Datenbank, wenn Sie ein Datenbank-Failover ausgeführt haben.

   Diese Aktion ist nicht erforderlich, wenn Sie einen Switchover ausgeführt haben.

2. Führen Sie ein Datenbank-Switchback auf die ursprüngliche Site aus.

Erwartetes Recovery-Zeitziel

Bei einem geplanten Switchover ist die Gesamtzeit für das Recovery kurz und hängt von der Zeit ab, die die Datenbank für das Switchover oder Failover benötigt.

Für die durchgeführten Tests dauert die Umschaltung weniger als 2 Minuten.

Bei einem ungeplanten Switchover oder Failover hängt die gesamte Ausfallzeit von der Ausfallzeit der Datenbank ab:

• Wenn Sie das Datenbank-Failover oder Switchover fast sofort ausführen, ist die Gesamtzeit für das Recovery kurz. Dies hängt von der Zeit ab, die die Datenbank für das Switchover oder Failover benötigt. Für die durchgeführten Tests dauert die Umschaltung weniger als 2 Minuten, sodass das erwartete Recovery Time Objective (RTO) wie folgt lautet:

  RTO = DB DOWNTIME + SHORT TIME (1-2 min)

• Wenn die Ausfallzeit der Datenbank länger ist, können zusätzliche Fehler auftreten, wie automatische Neustarts von Oracle WebLogic Server, die das RTO erhöhen. In diesem Fall ist das erwartete RTO:

  RTO = DB DOWNTIME + WEBLOGIC START TIME

Verwalten von Fehlern auf dem WebLogic Administration Server

Prozessfehler für den Administrationsserver werden vom Node Manager WebLogic in diesem Knoten behoben.

Node Manager startet den ausgefallenen Server automatisch direkt neu.

Sie müssen jedoch ein Failover des Administration Servers auf einen anderen Knoten durchführen, wenn sich ein Ausfall vollständig auf den Host auswirkt, auf dem der Administration Server ausgeführt wird.

Im Wesentlichen besteht dies darin, den Administration Server auf einem anderen Knoten neu zu starten, indem sichergestellt wird, dass er auf den Speicherort verweist, der das Administration Server-Domänenverzeichnis enthält, und dass er eine Listening-Adresse verwendet, die der entsprechenden virtuellen IP (VIP) zugeordnet ist.

Dieses Administration Server-Domainverzeichnis kann ein Shared Storage-Speicherort sein, der für verschiedene Knoten in derselben Region verfügbar ist, oder ein Restore aus einem Backup oder einer Dateisystemreplikation, das Knoten in einer anderen Region zur Verfügung gestellt wird.

Hinweis:

Unabhängig von der Konfiguration des gestreckten Clusters wird erwartet, dass die entsprechenden Backupprozeduren für Ihre Oracle WebLogic-Domain vorhanden sind.

Bei einer gestreckten Clustertopologie von Oracle Fusion Middleware (FMW) gelten daher unterschiedliche Überlegungen beim Migrieren des Administrationsservers zu einem Knoten in einer anderen Region als beim Migrieren zu einem Knoten in derselben Region.

Das folgende Diagramm zeigt den Failover des Administrationsservers auf die andere Site im gestreckten FMW-Cluster

Beschreibung der Abbildung Fehler-admin-server.png

Fehler-admin-server-oracle.zip

Failover zu einer anderen Region

Führen Sie die folgenden Schritte aus, um den Administration Server in eine andere Region zu übertragen.

1. Stellen Sie das Backup des Domainverzeichnisses (ASERVER_HOME) des Administrationsservers auf der Failover-Site zur Verfügung.
2. Stellen Sie das Verzeichnis ASERVER_HOME (einschließlich Domain- und Anwendungsverzeichnis) in der Failover-Site wieder her, sodass dieselbe Domainverzeichnisstruktur mit der ursprünglichen Site konsistent ist.
3. In den Subnetzen in Region 1 und Region 2 werden in der Regel verschiedene Classless Inter-Domain Routing-(CIDR-)Blöcke verwendet. Daher ist die vom Administrationsserver in Region 1 verwendete virtuelle IP (VIP) (z.B. 10.10.10.1) in Region 2 nicht gültig. Wenn der Administrationsserver in Region 2 ausgeführt wird, verwendet er eine andere VIP (z.B. 20.20.20.1). Aktualisieren Sie die Hostnamenauflösung, damit die Listening-Adresse (ADMINHOSTVHN) des Administrationsservers der neuen VIP zugeordnet wird.
   1. Weisen Sie dem Host, der den Administrationsserver in der Region 2 ausführt, eine virtuelle IP zu, und hängen Sie sie an, wie im Blog Virtuelle IP (VIP) in Oracle Cloud Infrastructure verwenden beschrieben.
   2. Aktualisieren Sie die privaten Ansichten /etc/hosts oder DNS (Domain Name System) in beiden Regionen, um den Datensatz ADMINHOSTVHN von der vorherigen IP (z.B. 10.10.10.1) in die neue IP zu ändern (z.B. 20.20.20.1).
4. Ändern Sie die Datei $NM_HOME/nodemanager.domains in dem Knoten, auf dem der Administrationsserver wiederhergestellt wird, so dass sie ASERVER_HOME enthält, und starten Sie den Node Manager neu:

   domain_name=MSERVER_HOME;ASERVER_HOME

5. Starten Sie den Administration Server auf dem neuen Host.
6. Oracle HTTP Server-Instanzen verwenden einen DNS-Cache, der von der Direktive WLDNSRefreshInterval in mod_wl_ohs.conf gesteuert wird. Es ist standardmäßig 0, was "Cache forever" bedeutet. Sie müssen OHS neu starten, um den DNS-Auflösungscache zu aktualisieren. Es gibt zwei Ansätze:
   1. Starten Sie die OHS-Server neu, um den DNS-Auflösungscache zu aktualisieren.
   2. Oder legen Sie einen Wert ungleich Null für WLDNSRefreshInterval in mod_wl_ohs.conf fest.

   Andernfalls versucht OHS weiterhin, eine Verbindung zum Administration Server mit der vorherigen IP-Adresse herzustellen.

Prüfen Sie, ob der Administrationsserver ordnungsgemäß funktioniert, indem Sie sowohl auf die WebLogic Remotekonsole als auch auf Oracle Enterprise Manager Fusion Middleware Control zugreifen.

Failover zu derselben Region

Um einen Failover des Administrationsservers auf einen Host in derselben Region auszuführen, müssen Sie das Domainverzeichnis des Administrationsservers nicht kopieren, und der Wert der virtuellen IP (VIP) ändert sich nicht.

Daher ist die Failover-Prozedur die gleiche wie im Enterprise Deployment Guide für den Administration Server unter Verifying Manual Failover of the Administration Server beschrieben.

Zur Verwaltung der virtuellen IP (VIP) des Administrationsservers in Oracle Cloud Infrastructure-(OCI-)Systemen können Sie die im Blog Virtuelle IP (VIP) in Oracle Cloud Infrastructure verwenden beschriebenen Schritte verwenden.

Fehler in der gesamten Region verwalten, in der die Primärdatenbank gehostet wird

Wenn sich ein Ausfall auf die gesamte Region 1 auswirkt, führen Sie so bald wie möglich ein Datenbank-Switchover oder ein Failover auf die andere Site/Region durch.

Die Oracle WebLogic Server-Instanzen auf der verbleibenden Site verbinden sich automatisch wieder mit der neuen Primärdatenbank, wenn sie die im vorherigen Abschnitt beschriebene empfohlene Konfiguration verwenden.

Der Load Balancer der nicht erfolgreichen Site gibt eine nicht erfolgreiche Antwort zurück, sodass das globale Frontend-Ausgleichsfeature die Site als fehlerhaft kennzeichnen muss. Alle Clientanforderungen, unabhängig von ihrer Präferenz, werden an die andere Site weitergeleitet.

Die JMS- und JTA-Services WebLogic werden automatisch zu den Servern auf der anderen Site migriert, wenn Automatic Service Migration zusammen mit persistenten JDBC-Speichern verwendet wird. Wenn in Oracle Fusion Middleware (FMW) Oracle SOA Suite der Cluster Master für automatisches Recovery auf den ausgefallenen Servern gehostet wurde, entsteht auf der verfügbaren Site ein neuer Cluster Master. Der neue Cluster Manager führt ein automatisches Recovery von SOA-Instanzen durch, die auf der anderen Site initiiert wurden.

Das folgende Diagramm zeigt den Fehler der gesamten Region 1 in der FMW-Topologie mit gedehnten Clustern:

Beschreibung der Abbildung failure-entire-region.png

Fehler-gesamt-region-oracle.zip

Nach Fehler beheben

So beheben Sie ein sofortiges Recovery nach einem vollständigen Fehler in Region 1:

1. Führen Sie einen Datenbank-Switchover mit der Oracle Cloud Infrastructure-(OCI-)Konsole oder der Oracle Data Guard Broker-Befehlszeilenschnittstelle aus.

   Wenn die Primärdatenbank nicht verfügbar sind, führen Sie ein Datenbank-Failover aus der Standbydatenbank aus.

2. Die Oracle WebLogic Server-Instanzen verbinden sich automatisch wieder mit der neuen Primärdatenbank, sodass keine manuellen Aktionen erforderlich sind, außer zum Recovery nach anwendungsspezifischen Fehlern (z.B. in Oracle SOA Suite müssen Sie Composites im Error Hospital möglicherweise wiederherstellen).
3. Führen Sie bei Bedarf ein Administration Server Failover zu Region 2 durch.

Nachdem die ausgefallene Site wiederhergestellt wurde und wieder verfügbar ist:

1. Starten Sie die Prozesse in den ausgefallenen Hosts neu: Oracle-HTTP-Server, WebLogic-Administrationsserver und Managed Server.

   Stellen Sie sicher, dass die virtuelle IP (VIP) des Administrationsservers festgelegt ist und keine verwaisten Dateien vorhanden sind, die den Start verhindern.

2. Reaktivieren Sie die nicht erfolgreiche Datenbank, wenn Sie ein Datenbank-Failover ausgeführt haben.

   Diese Aktion ist nicht erforderlich, wenn Sie einen Switchover ausgeführt haben.

3. Führen Sie einen Datenbank-Switchover auf die ursprüngliche Site aus.

Erwartetes Recovery-Zeitziel

Wenn die Datenbank heruntergefahren ist, ist das System nicht verfügbar.

Die Server auf der verbleibenden Site können die Verarbeitung von Anforderungen fortsetzen, sobald die Datenbank wieder auf der verbleibenden Site ausgeführt wird. Daher hängt die Ausfallzeit von der Zeit ab, die vor dem Umschalten der Datenbank verwendet wird.

• Wenn Sie das Datenbank-Failover oder Switchover fast sofort ausführen, ist die Gesamtzeit für das Recovery kurz. Dies hängt von der Zeit ab, die die Datenbank für das Switchover oder Failover benötigt. Für den durchgeführten Test dauert das Switchover weniger als 2 Minuten, sodass das erwartete RTO:

  RTO = DB DOWNTIME + SHORT TIME (1-2 min).

• Wenn die Ausfallzeit der Datenbank länger ist, können zusätzliche Fehler auftreten, wie automatische Neustarts von Oracle WebLogic Server, die das RTO erhöhen. Das erwartete RTO ist:

  RTO = DB DOWNTIME + WEBLOGIC START TIME

Fehler in der gesamten Region verwalten, in der die Standbydatenbank gehostet wird

Wenn sich ein Fehler auf die gesamte Region 2 auswirkt, sollte das globale Ausgleichsfeature des Frontends die Site als fehlerhaft markieren.

Alle Clientanforderungen, unabhängig von ihrer Standortvoreinstellung, werden an Region 1 weitergeleitet, wodurch die Verarbeitung von Anforderungen fortgesetzt wird. Die JMS- und JTA-Services WebLogic werden automatisch zu den Servern in Site 1 migriert, wenn Automatic Service Migration zusammen mit persistenten JDBC-Speichern verwendet wird.

Wenn im Fall Oracle Fusion Middleware (FMW) mit Oracle SOA Suite der Cluster-Master für automatisches Recovery auf den ausgefallenen Servern gehostet wurde, entsteht auf der verfügbaren Site ein neuer Cluster-Master. Dieser Server führt ein automatisches Recovery von SOA-Instanzen durch, die auf der anderen Site initiiert wurden.

Ein Datenbank-Switchover ist nicht erforderlich, da sich der Ausfall nicht auf die Primärdatenbank auswirkt.

Das folgende Diagramm zeigt den Ausfall der gesamten Region 2 in der FMW-gedehnten Clustertopologie.

Beschreibung der Abbildung failure-standby-db-region.png

Fehler-standby-db-region-oracle.zip

Nach Fehler beheben

Für eine sofortige Wiederherstellung nach einem vollständigen Ausfall in Region 2 ist kein manuelles Eingreifen erforderlich.

Nachdem die ausgefallene Site wieder verfügbar ist, starten Sie die Prozesse in den ausgefallenen Hosts für die Oracle HTTP-Server und WebLogic-Managed Server neu.

Stellen Sie sicher, dass keine verwaisten Dateien vorhanden sind, die das Starten von WebLogic verhindern.

Dank des globalen Load-Balancer-Features (entweder Oracle Cloud Infrastructure Traffic Management-Steuerungs-Policys oder ein globaler Load Balancer) werden die Anforderungen des Clients erneut zwischen den 2 Sites verteilt.

Erwartetes Recovery-Zeitziel

Wenn Sie Oracle Cloud Infrastructure-(OCI-)Trafficsteuerungs-Policys für globales Balancing verwenden, beträgt der Zeitraum mit Fehlern etwa 1 Minute mehr als die Gültigkeitsdauer (TTL) des in der Steuerungs-Policy definierten Frontend-Eintrags.

Das Domain Name System-(DNS-)Update wirkt sich auf Clients aus, für die Region 2 in der Geolocation-Steuerungs-Policy als Voreinstellung festgelegt ist. Die DNS-Aktualisierung wirkt sich auf Clients aus, deren Steuerungs-Policy-Voreinstellung auf die fehlerhafte Region gesetzt ist. Der TTL-Wert bestimmt, wie lange diese Clients den alten Eintrag weiter verwenden, bevor er aktualisiert wird, um auf den fehlerfreien Standort zu verweisen. Die zusätzliche Zeit (ca. 1 Minute) hängt von der Häufigkeit und dem Timeout der Health Checks ab, die in der OCI Traffic Management-Steuerungs-Policy konfiguriert sind (30 Sekunden wurden im obigen Test für das Health Check-Intervall und ein Timeout von 10 Sekunden verwendet).

Bei der Verwendung eines Global Load Balancers (GLBR) hängt die Ausfallzeit von der Häufigkeit der in GLBR konfigurierten Health Checks ab. Sobald der GLBR einen Pool als fehlerhaft markiert, werden die eingehenden Anfragen an die andere Site weitergeleitet. Bei einem GLBR gibt es kein DNS-Update, sodass der TTL-Wert des Frontend-Eintrags irrelevant ist.