Lebenszyklusaufgaben

Eine regelmäßige Lebenszyklusverwaltung ist erforderlich, um die sekundäre Site mit der primären Site synchron zu halten. Während des gesamten Lebenszyklus können Sie ein geplantes Switchover ausführen, um die Rollen der primären und sekundären Sites zu wechseln und auf unerwartete oder ungeplante Vorgänge zu reagieren.

Informationen zur Konfigurationsreplikation

Eine anfängliche Replikation des Inhalts, der sich in den Dateisystemen befindet, wurde während des DR-Setups ausgeführt. Sie müssen die Dateisystemreplikation regelmäßig wiederholen, damit die sekundäre Site mit der primären Site auf dem neuesten Stand bleibt.

Sie können dieselben Skripte verwenden, die Sie beim DR-Setup erstellt haben, Dateisystemartefakte auf OCI replizieren und das Dateisystemreplikat mit den folgenden Aspekten für jedes Artefakt planen:

• Replikation der Oracle Homes während des Lebenszyklus

  Dies ist ein statisches Artefakt. Sie ändert sich nicht häufig, sodass sie nicht regelmäßig repliziert werden muss. Nur wenn Sie eine Änderung im Oracle Home ausführen (wie Patching-Aktivität), müssen Sie sie replizieren.

• Replikation der gemeinsamen WebLogic-Domainkonfiguration während des Lebenszyklus

  Dies ist ein dynamisches Artefakt. Sie enthält unter anderem die Datei ASERVER_HOME, bei der es sich um die Wahrscheinlichkeit der SOA-Domainkonfiguration handelt, und die Datei APPLICATION_HOME, die jedes Mal aktualisiert wird, wenn eine Anwendung bereitgestellt, nicht bereitgestellt, aktualisiert wird usw.

  Es wird erwartet, dass sich diese gemeinsam verwendete WebLogic-Domainkonfiguration häufig ändert. Planen Sie ein reguläres Replikat dieses Artefakts, das mehr oder weniger häufig sein sollte, je nachdem, wie häufig Konfigurationsänderungen in Ihrem System auftreten. Eine weitere kontrollierte Methode besteht darin, jedes Mal ein Replikat auszuführen, wenn Sie eine Konfigurationsänderung an der primären Datenbank vornehmen.

• Replikation der privaten WebLogic-Domainkonfiguration während des Lebenszyklus

  Dies ist auch ein dynamisches Artefakt, das MSERVER_HOME und NM_HOME enthält. Es wird nicht erwartet, dass nach dem anfänglichen Setup häufige Updates im Home-Verzeichnis nodemanager vorhanden sind. Der Inhalt von MSERVER_HOME ändert sich so häufig wie ASERVER_HOME, da er den von den Managed Servern verwendeten Domainordner enthält. Der Großteil des Inhalts (ASERVER_HOME/config) wird jedoch aktualisiert und von AdminServer heruntergeladen, wenn die Managed Server gestartet werden und wenn Konfigurationsänderungen mit dem WebLogic Scripting Tool (WLST) oder der Oracle WebLogic Server Administration Console angewendet werden. Es ist nicht so wichtig, dieses Artefakt genauso häufig wie die gemeinsame Konfiguration zu replizieren. Die Replikation ist nur erforderlich, wenn Änderungen an anderen Ordnern in MSERVER_HOME vorgenommen werden (z.B. eine Änderung im Ordner MSERVER_HOME/bin).

• Replikation des freigegebenen Laufzeitordners

  Wenn Sie ein Laufzeitartefakt in diesem Ordner speichern, planen Sie das Replikat entsprechend Ihren Geschäftsanforderungen auf die Standbydatenbank.

  Anstatt das Oracle Cloud Infrastructure File Storage-Dateisystem zu verwenden und mit rsync zu replizieren, können Sie einen Oracle Database File System-(DBFS-)Mount für die freigegebenen Laufzeitinhalte verwenden. Auf diese Weise befindet sich der Inhalt in der Datenbank und wird automatisch mit dem zugrunde liegenden Oracle Data Guard-Replikat auf die sekundäre Datenbank repliziert. Weitere Informationen zur Verwendung von DBFS finden Sie unter Info zu Oracle Database-Dateisystem.

Die folgende Tabelle enthält eine Zusammenfassung der Empfehlungen zur Replikation von Dateisystemartefakten während des Lebenszyklus.

Artefakt	Enthält	Empfehlung
Oracle Homes	FMW-Home, JDK, Bestand	Replikation nur unter Bedarf (Beispiel: nach dem Patching)
WebLogic Gemeinsame Domainkonfiguration	ASERVER_HOME, Anwendungen, Deployment-Pläne, Keystores	Replikation planen. Möglicherweise ist eine hohe Häufigkeit erforderlich. Die Häufigkeit hängt davon ab, wie oft die Konfigurationsänderungen an dem SOA-System vorgenommen werden.
WebLogic Private Domainkonfiguration	MSERVER_HOMES, nodemanager config	Replikation planen. Eine hohe Häufigkeit ist normalerweise nicht erforderlich.
Gemeinsame Laufzeit	Kundenspezifische Laufzeitartefakte (nicht JMS, nicht TLOGS)	Bestimmt durch Ihre Anforderungen. Wenn es sich um einen DBFS-Mount handelt, wird der Inhalt automatisch von Oracle Data Guard repliziert.

Switchover ausführen

Ein Switchover ist ein geplanter Vorgang, bei dem ein Administrator die Rollen der beiden Sites zurücksetzt. Nach einem Switchover wird das primäre System zum sekundären und das sekundäre System zum primären System. Bei einem Switchover kommt es zu Ausfallzeiten in der primären Site.

Bevor Sie einen Switchover in einer SOA-Hybrid-DR-Konfiguration ausführen, propagieren Sie alle ausstehenden Konfigurationsänderungen. Stellen Sie sicher, dass keine replizierten Änderungen an der sekundären Site ausstehen.

1. Deaktivieren Sie die geplante Replikation während des Switchovers, da sie möglicherweise ausfällt und den Switchover-Vorgang selbst beeinträchtigt.
2. Stoppen Sie die Oracle HTTP Server-Systeme auf der primären Site.
3. Stoppen Sie die Server auf der primären Site.
   Verwenden Sie die WebLogic Administration Server-Konsole oder die Skripte, um die WebLogic-Server auf der primären Site zu stoppen.

   Hinweis:

   Der Admin-Server in der primären Site kann während des Switchovers hochgefahren bleiben. Es wird jedoch empfohlen, sie zu stoppen, wenn sich die Site in der Standbyrolle befindet, da erwartet wird, dass die Domainkonfiguration in der Standby Site während des Lebenszyklus durch die primäre Konfiguration außer Kraft gesetzt wird. Wenn der Admin-Server hochgefahren ist, wird er mit einer veralteten Konfiguration ausgeführt.
4. Wechseln Sie zum Frontend-DNS-Namen.

   Führen Sie den erforderlichen DNS-Push in dem DNS-Server aus, der die vom System verwendeten Namen hostet, oder ändern Sie die Dateihostauflösung in Clients, um den virtuellen Frontend-Namen des Systems auf die öffentliche IP zu verweisen, die vom Load Balancer auf der sekundären Site verwendet wird.

   Für Szenarios, in denen DNS für die externe Frontend-Auflösung verwendet wird (wie OCI-DNS oder kommerzielles DNS), können Sie die Änderung mit einer API per Push übertragen. Um ein Beispiel anzuzeigen, in dem diese Änderung in einem OCI-DNS übertragen wird, gehen Sie zu GitHub. Beispielskripte.

   Beachten Sie, dass sich der TTL-Wert des DNS-Eintrags auf das RTO des Switchovers auswirkt: Wenn der TTL-Wert hoch ist (z.B. 20 Minuten), nimmt die DNS-Änderung diese Zeit in den Clients in Anspruch. Wenn Sie niedrigere TTL-Werte verwenden, ist dies schneller. Dies kann jedoch zu einem Overhead führen, da Clients das DNS häufiger treffen, anstatt gecachte Namen zu verwenden. Ein guter Ansatz besteht darin, die TTL vorübergehend (z.B. 1 Min.) auf einen niedrigen Wert zu setzen, bevor die DNS-Änderung erfolgt. Führen Sie dann die Änderung aus. Sobald die Switchover-Prozedur abgeschlossen ist, setzen Sie die TTL wieder auf den ursprünglichen Wert zurück.

5. Verwenden Sie als oracle-Benutzer Oracle Data Guard-Broker im primären Datenbankhost, um das Datenbank-Switchover auszuführen.
   Sie benötigen Ihr Systemkennwort und den eindeutigen Namen der Primärdatenbank.

   [oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
   DGMGRL> switchover to secondary_db_unqname

6. Wenn sie noch nicht hochgefahren sind, starten Sie die Oracle HTTP Server-Systeme in der sekundären Site (neue Primärdatenbank).
7. Starten Sie den Admin-Server in der sekundären Site (neue primäre Site), oder starten Sie den Server neu, wenn er bereits gestartet wurde.
   Wenn Sie den Admin-Server starten, werden Konfigurationsänderungen aktiviert, die repliziert wurden, während dies eine Standby-Datenbank war.
8. Starten Sie die sekundären Managed Server auf der sekundären Site (neue primäre Site).
   Verwenden Sie die Konsole oder die Skripte WebLogic, um die sekundären Managed Server zu starten.

Failover ausführen

Ein Failover-Vorgang ist im Allgemeinen ein ungeplanter Vorgang, der ausgeführt wird, wenn die primäre Site nicht verfügbar ist. Sie können den Rollenwechsel einer Standby-Datenbank in die primäre Datenbankrolle ausführen, wenn die ursprüngliche Primärdatenbank nicht erfolgreich verläuft und keine Möglichkeit besteht, sie rechtzeitig wiederherzustellen. Je nachdem, ob die primären und die Ziel-Standby-Datenbanken beim Ausfall der primären Datenbank konsistent waren, kann es zu einem Datenverlust kommen.

1. Gegebenenfalls ausstehende Konfigurationsänderungen propagieren.
   Informationen zum Replizieren von Änderungen an der sekundären Site finden Sie unter Dateisystemartefakte in OCI replizieren.
2. Deaktivieren Sie die geplante Replikation während des Switchovers, da sie möglicherweise ausfällt und den Switchover-Vorgang selbst beeinträchtigt.
3. Stoppen Sie die Oracle HTTP Server-Systeme auf der primären Site.
4. Stoppen Sie wenn möglich die Managed Server auf der primären Site.

   Verwenden Sie die Administration Server-Konsole oder die Skripte WebLogic, um Managed Server in der primären Datenbank zu stoppen.

5. Wechseln Sie über den Frontend-DNS-Namen.

   Führen Sie den erforderlichen DNS-Push in dem DNS-Server aus, der die vom System verwendeten Namen hostet, oder ändern Sie die Dateihostauflösung in Clients, um den virtuellen Frontend-Namen des Systems auf die öffentliche IP zu verweisen, die vom Load Balancer auf der sekundären Site verwendet wird.

   Für Szenarios, in denen DNS für die externe Frontend-Auflösung (OCI-DNS, kommerzielles DNS usw.) verwendet wird, verwenden Sie die entsprechende API, um die Änderung per Push zu übermitteln. Ein Beispiel, das diese Änderung in einem OCI-DNS überträgt, finden Sie hier.

   Hinweis:

   der TTL-Wert des DNS-Eintrags wirkt sich auf das RTO des Switchovers aus. Wenn die TTL hoch ist (z.B. 20 Minuten), nimmt die DNS-Änderung diese Zeit in den Clients in Anspruch. Wenn Sie niedrigere TTL-Werte verwenden, wird dies schneller. Dies kann jedoch zu einem Overhead führen, da Clients das DNS häufiger treffen, anstatt gecachte Namen zu verwenden. Ein guter Ansatz besteht darin, die TTL vorübergehend (z.B. 1 Min.) auf einen niedrigen Wert zu setzen, bevor die DNS-Änderung erfolgt. Führen Sie dann die Änderung aus, und setzen Sie die TTL nach Abschluss der Switchover-Prozedur auf den ursprünglichen Wert zurück.
6. Verwenden Sie als oracle-Benutzer Oracle Data Guard Broker auf dem sekundären Datenbankhost, um den Failover auszuführen.
   Sie benötigen Ihr Systemkennwort und den eindeutigen Namen der Primärdatenbank.

   [oracle@hydrdb1 ~]$ dgmgrl sys/your_sys_password@secondary_db_unqname
   DGMGRL> failover to secondary_db_unqname

7. Wenn sie noch nicht hochgefahren sind, starten Sie die Oracle HTTP Server-Systeme in der sekundären Site (neue Primärdatenbank).
8. Starten Sie den Admin-Server in der sekundären Site (neue primäre Site), oder starten Sie den Server neu, wenn er bereits gestartet wurde.
   Wenn Sie den Admin-Server starten, werden Konfigurationsänderungen aktiviert, die repliziert wurden, während dies eine Standby-Datenbank war.
9. Starten Sie die sekundären Managed Server auf der sekundären Site (neue primäre Site).
   Verwenden Sie die Konsole oder die Skripte WebLogic, um die sekundären Managed Server zu starten.

Sekundär zur Validierung öffnen

Sie können die Standbysite validieren, ohne einen vollständigen Switchover auszuführen, indem Sie die Standbydatenbank in Snapshot Standby konvertieren. Dadurch können die sekundären SOA-Server auf der Standbysite gestartet und das sekundäre System geprüft werden. Alle Änderungen, die in der Standbydatenbank vorgenommen werden, während sie sich im Snapshot Standby-Modus befindet, werden verworfen, sobald sie wieder in die physische Standbydatenbank konvertiert werden. Primäre Daten sind von Validierungen der sekundären Site nicht betroffen.

Hinweis:

Dieser Vorgang muss mit Vorsicht ausgeführt werden: Wenn bei der Konvertierung in einen Snapshot ausstehende Nachrichten oder Composites in der Datenbank vorhanden sind, verarbeiten die SOA-Server der Standbysite diese beim Start. Prüfen Sie, ob keine ausstehenden Aktionen in der Primärdatenbank bei der Konvertierung in die Snapshot Standby-Datenbank vorhanden sind. Andernfalls entfernen Sie Datensätze aus SOA-Laufzeittabellen in der Standbydatenbank, nachdem sie in die Snapshot-Standbydatenbank konvertiert wurde, und bevor Sie die SOA-Server der sekundären Site starten. Die Schritte zum Validieren der Standby Site ohne Switchover finden Sie unter Datensätze aus Laufzeittabellen entfernen, ohne die Tabellen zu löschen.

1. Verwenden Sie als oracle-Benutzer Oracle Data Guard-Broker im primären DB-Host, und konvertieren Sie die sekundäre Datenbank in eine Snapshot Standby-Datenbank.

   [oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
   DGMGRL> convert database secondary_db_unqname to snapshot standby
   

   Prüfen Sie mit dem Befehl show configuration, ob die Konvertierung korrekt ausgeführt wurde.
2. Stellen Sie sicher, dass keine ausstehenden Aktionen in der sekundären Umgebung vorhanden sind.
   Wenn bei der Konvertierung der Standbydatenbank in einen Snapshot ausstehende Aktionen (Transaktionen, Nachrichten) in der primären DB vorhanden sind, versuchen die sekundären SOA-Server, diese zu verarbeiten, wenn sie start.You das SOA-Kürzungsskript verwenden können, um die Datensätze aus den SOA-Laufzeittabellen in der sekundären Datenbank zu entfernen, um die Laufzeitdaten zu bereinigen, bevor die sekundären Server gestartet werden. Führen Sie diese Aktion mit VORSICHT aus. Schneiden Sie keine Tabellen in der Primärdatenbank ab. Siehe Datensätze aus Laufzeittabellen entfernen, ohne die Tabellen zu löschen.
3. Wenn sie noch nicht hochgefahren sind, starten Sie die Oracle HTTP Server-Systeme auf der sekundären Site.
4. Starten Sie den Administrationsserver auf der sekundären Site.
5. Starten Sie die sekundären Managed Server auf der sekundären Site.
   Verwenden Sie die Konsole oder die Skripte WebLogic, um die sekundären Managed Server zu starten.
6. Sekundäre Site validieren.

   Da dies kein Switchover ist und die primäre Site noch aktiv ist, wird der virtuelle Frontend-Name in die Load-Balancer-IP-Adresse der primären Site aufgelöst, sodass jeder Browserzugriff standardmäßig auf die aktive primäre Site umgeleitet wird.

   Um direkt auf die SOA-Services der sekundären Site zuzugreifen, müssen Sie die Datei /etc/hosts in einem kontrollierten Client (z.B. einem Laptop) aktualisieren, den virtuellen Frontend-Namen auf die Frontend-IP-Adresse der sekundären Site setzen und eine Validierung von diesem Client ausführen.

   Hinweis:

   Stellen Sie sicher, dass der für Validierungen verwendete Client nicht über einen HTTP-Proxy auf das System zugreift, da der HTTP-Proxy den virtuellen Frontend-Namen weiterhin mit der IP-Adresse des Load Balancers der primären Site auflösen kann, unabhängig davon, welcher Name im /etc/hosts des Clients enthalten ist.

   Nicht-Linux-Clients erfordern möglicherweise eine Zurücksetzung ihres lokalen DNS-Caches, bevor ein Browser die IP-Adresse mit dem benutzerdefinierten Hostdateieintrag auflöst.

   Nachdem die sekundäre Site validiert wurde, gehen Sie zum nächsten Schritt, um sie auf die Standbyrolle zurückzusetzen.

   Hinweis:

   Die Validierung der sekundären Site kann einige Zeit in Anspruch nehmen.
7. Stoppen Sie die Managed Server und Administration Server auf der sekundären Site.
   Verwenden Sie die sekundäre WebLogic-Konsole, um die Managed Server und den Admin-Server auf der sekundären Site herunterzufahren.
8. Verwenden Sie als oracle-Benutzer Oracle Data Guard Broker im primären Datenbankhost, und konvertieren Sie die sekundäre in die physische Standby-Datenbank erneut.
   Sie benötigen Ihr Systemkennwort und den eindeutigen Namen der Primärdatenbank.

   [oracle@dbhost1 ~]$ dgmgrl sys/your_sys_password@primary_db_unqname
       DGMGRL> convert database secondary_db_unqname to physical standby

   Verwenden Sie show configuration, um die Konvertierung zu prüfen.
9. Stellen Sie alle aktualisierten /etc/hosts-Dateien wieder her.
   Wenn Sie /etc/hosts-Dateien in einem Client so aktualisiert haben, dass sie auf die sekundäre Site für Validierungen verweisen, setzen Sie den Vorgang zurück, sodass der virtuelle Frontend-Name erneut auf die primäre Frontend-IP-Adresse verweist.

Hinweis:

ORA-01403: Keine Daten gefunden ORA-06512 Fehler

Beim Validieren der sekundären Site wie hier beschrieben (ohne ein vollständiges Switchover auszuführen, d.h. nur das Öffnen der Standby-Datenbank im Snapshot Standby-Modus) "ORA-01403: In den Logs der Standby-SOA-Server können keine ORA-06512-Fehler gefunden werden. Diese Fehler beziehen sich auf den SOA-Job zum automatischen Löschen. Diese Fehler treten auf, weil Jobs in der Datenbank möglicherweise DB-Rollenabhängigkeiten aufweisen (sie sind nur dann aktiviert, wenn sich die Datenbank in der primären Rolle befindet). Dies ist ein erwartetes und gewünschtes Verhalten, das verhindert, dass Jobs zweimal ausgeführt werden (einmal in der primären Datenbank und einmal in der Standby-Datenbank). Der SOA-Job zum automatischen Löschen ist mit der primären Rolle definiert. Er wird daher nicht in der Ansicht DBA_SCHEDULER_JOBS angezeigt, wenn sich die Datenbank im Snapshot Standby-Modus befindet. Die für jeden Job definierte database_role kann in der Ansicht DBA_SCHEDULER_JOB_ROLE angezeigt werden. Zusammenfassend lässt sich sagen, dass diese Fehler ignoriert werden können, solange sie im Standby-System angezeigt werden. Der Scheduler-Job für das automatische Löschen von SOA wird in der Datenbank ausgeführt, wenn die Instanz ihre Rolle in PRIMARY ändert.

Lokales Failover des Administration Servers auf OCI

Sie können den Administrationsserver auf einem anderen Knoten auf derselben Site starten, wenn ein Fehler auf dem Host aufgetreten ist, auf dem der Administrationsserver ursprünglich ausgeführt wurde. Ein vollständiges Switchover des Systems auf den anderen Standort ist nicht erforderlich.

Hinweis:

Diese Lebenszyklusaufgabe ist nur anwendbar, wenn WebLogic Administrationsserver eine VIP für lokale High Availability-Zwecke verwenden und sich der Konfigurationsordner des Administrationsservers (ASERVER_HOME) in einem gemeinsamen Verzeichnis befindet.

Das Verfahren hierzu wird unter Verifying Manual Failover of the Administration Server beschrieben. Dies bietet lokalen Failover-Schutz für den Administrationsserver. Beachten Sie, dass dies für die Managed Server nicht erforderlich ist, die einen lokalen High Availability-Schutz basierend auf dem Feature "Automatische Servicemigration" aufweisen.

Wenn Sie ein Failover des Administrationsservers auf einen anderen Host ausführen müssen, wenn die Primärdatenbank in der OCI-Site ausgeführt wird, können Sie dieses Verfahren befolgen. Im Zusammenhang mit dem Schritt "Virtuelle IP-Adresse von ADMINVHN zum zweiten Host migrieren" ist jedoch eine zusätzliche Aktion erforderlich.

Führen Sie die folgenden Schritte aus, um die VIP von dem SOA-Host, auf dem der Administrationsserver ausgeführt wurde, zu trennen und an den SOA-Host anzuhängen, auf dem die Administration verschoben wird (trennen Sie die VIP von SOAHOST1, und hängen Sie sie an SOAHOST2 auf der OCI-Site an):

1. Führen Sie als Benutzer root die folgenden Befehle in SOAHOST1 aus, um die VIP des Administrationsservers aus der Netzwerkschnittstelle zu entfernen.
   1. Administration Server stoppen, falls er noch ausgeführt wird
   2. Bestätigen Sie, wo die VIP ausgeführt wird.

      ip addr show dev ens3

   3. Entfernen Sie die IP-Adresse aus der Netzwerkschnittstelle.

      ip addr del 100.70.8.120/20 dev ens3

2. Trennen Sie die VIP des Administrationsservers von SOAHOST1.
   1. Stellen Sie eine Verbindung zur OCI-Konsole her, und wählen Sie die entsprechende Region und das entsprechende Compartment aus.
   2. Navigieren Sie zur Compute-Instanz. Klicken Sie auf Compute, Instanzen, und klicken Sie dann auf SOAHOST1.
   3. Klicken Sie auf Angehängte VNICs, und wählen Sie die VNIC aus, an die die Administration Server-VIP angehängt ist.
   4. Klicken Sie auf IPv4-Adressen, und bearbeiten Sie die vom Administration Server verwendete VIP.
   5. Speichern Sie die IP-Adresse und den fqdn-Namen der VIP in einem Hinweis (Beispiel: 100.70.8.120, hydrsoa-vip.midtiersubnet.hydrvcn.oraclevcn.com).
   6. Klicken Sie auf Private IP löschen.
3. Hängen Sie die VIP des Administrationsservers an SOAHOST2 an.
   1. Navigieren Sie zur Compute-Instanz. Klicken Sie auf Compute, Instanzen, und klicken Sie dann auf SOAHOST2.
   2. Klicken Sie auf Angehängte VNICs, und wählen Sie die VNIC aus, an die die Administration Server-VIP angehängt ist.
   3. Klicken Sie auf Sekundäre private IP-Adresse zuweisen.
   4. Klicken Sie auf IPv4-Adressen und dann auf Sekundäre private IP-Adresse zuweisen.
   5. Geben Sie die zuvor verwendeten Werte für die private IP-Adresse und den Hostnamen ein. Beispiel: 100.70.8.120 für die IP und hydrsoa-vip als Hostname.
4. Melden Sie sich als Root-Benutzer bei SOAHOST2 an, und führen Sie dann die folgenden Befehle aus, um die VIP des Administrationsservers an die Netzwerkschnittstelle anzuhängen.
   1. Bestätigen Sie, wo die Netzwerkschnittstelle ausgeführt wird.

      ip addr show dev ens3

   2. Fügen Sie die VIP des Administration Servers zur Netzwerkschnittstelle hinzu.

      ip addr add 100.70.8.120/20 dev ens3 label ens3:1

5. Führen Sie die restlichen Schritte aus, wie unter Manuelles Failover des Administrationsservers prüfen beschrieben.