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.

Konfigurationsreplikation

Während des DR-Setups wurde eine anfängliche Replikation des Inhalts in den Dateisystemen durchgeführt. Sie müssen die Dateisystemreplikation regelmäßig wiederholen, damit die sekundäre Site mit der primären Site auf dem neuesten Stand ist.

Sie können dieselben Skripte verwenden, die Sie beim DR-Setup erstellt haben, Dateisystemartefakte in OCI replizieren und das Dateisystemreplikat mit den folgenden Überlegungen 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 Konfiguration der Domain WebLogic während des Lebenszyklus
Dies ist ein dynamisches Artefakt. Sie enthält unter anderem die ASERVER_HOME, die Quelle der Wahrheit der Domainkonfiguration WebLogic Server, und die 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 Konfiguration der Domain WebLogic während des Lebenszyklus
Dies ist auch ein dynamisches Artefakt. Es enthält MSERVER_HOME und NM_HOME. Es wird nicht erwartet, dass häufige Updates im Home-Verzeichnis nodemanager nach dem anfänglichen Setup vorhanden sind. Der Inhalt von MSERVER_HOME ändert sich so oft wie der ASERVER_HOME, da er den Domainordner enthält, der von den Managed Servern verwendet wird. Der größte 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-Administrationskonsole angewendet werden. Dieses Artefakt muss nicht so häufig wie die gemeinsame Konfiguration repliziert werden. Dies muss nur repliziert werden, wenn Änderungen an anderen Ordnern in der 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 Standby.

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 für die Replikation von Dateisystemartefakten während des Lebenszyklus.

Artefakt	Enthält	Empfehlung
Oracle Homes	FMW-Home, JDK, Bestand	Nur unter Bedarf replizieren (Beispiel: nach dem Patching)
Gemeinsame Konfiguration der Domain WebLogic	`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 auf dem System WebLogic Server vorgenommen werden.
Private Domainkonfiguration WebLogic	`MSERVER_HOMES`, `nodemanager config`	Planen Sie die Replikation. Hochfrequenz 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 WebLogic Server-Hybrid-DR-Konfiguration ausführen, propagieren Sie alle ausstehenden Konfigurationsänderungen. Stellen Sie sicher, dass keine replizierten Änderungen an der sekundären Site ausstehen.

Deaktivieren Sie eine geplante Replikation, während das Switchover ausgeführt wird, da dies möglicherweise nicht erfolgreich verläuft und den Switchover-Vorgang selbst beeinträchtigt.
Stoppen Sie die Oracle HTTP Server-Systeme auf der primären Site.
Stoppen Sie die Server in der primären Site.
Verwenden Sie die Administrationsserverkonsole WebLogic oder Skripte, um die WebLogic-Server in 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 von der primären Konfiguration außer Kraft gesetzt wird. Wenn der Admin-Server während dieses Vorgangs hochgefahren ist, wird er mit einer veralteten Konfiguration ausgeführt.
Wechseln Sie zum Frontend-DNS-Namen.

Führen Sie den erforderlichen DNS-Push in den 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 in 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 (Beispiel: 20 Min.), dauert die DNS-Änderung diese Zeit, bis sie in den Clients wirksam wird. Wenn Sie niedrigere TTL-Werte verwenden, wird dies beschleunigt. Dies kann jedoch zu einem Overhead führen, da Clients das DNS häufiger erreichen, anstatt gecachte Namen zu verwenden. Ein guter Ansatz besteht darin, den TTL-Wert vorübergehend (z.B. 1 Min.) vor der Änderung im DNS auf einen niedrigen Wert zu setzen. Führen Sie dann die Änderung aus. Sobald die Switchover-Prozedur abgeschlossen ist, setzen Sie die TTL wieder auf ihren ursprünglichen Wert zurück.
Verwenden Sie als oracle-Benutzer den Oracle Data Guard-Broker auf dem Primärdatenbankhost, um den 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
```
Wenn sie noch nicht hochgefahren sind, starten Sie die Oracle HTTP Server-Systeme in der sekundären Site (neue Primärdatenbank).
Starten Sie den Admin-Server auf der sekundären Site (neue primäre Site), oder starten Sie den Server neu, wenn er bereits gestartet wurde.
Durch das Starten des Admin-Servers werden Konfigurationsänderungen aktiviert, die repliziert wurden, während dies eine Standby-Datenbank war.
Starten Sie die sekundären Managed Server in der sekundären Site (neue primäre Site).
Verwenden Sie die WebLogic-Konsole oder -Skripte, 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 mehr verfügbar ist. Sie können eine Standbydatenbank in eine Primärdatenbankrolle übertragen, wenn die ursprüngliche Primärdatenbank ausfällt und keine Möglichkeit besteht, sie rechtzeitig wiederherzustellen. Je nachdem, ob die Primär- und die Ziel-Standbydatenbank beim Ausfall der Primärdatenbank konsistent waren, kann es zu Datenverlust kommen.

Sofern möglich, propagieren Sie alle ausstehenden Konfigurationsänderungen.
Informationen zum Replizieren von Änderungen an der sekundären Site finden Sie unter Dateisystemartefakte in OCI replizieren.
Deaktivieren Sie eine geplante Replikation, während das Switchover ausgeführt wird, da dies möglicherweise nicht erfolgreich verläuft und den Switchover-Vorgang selbst beeinträchtigt.
Stoppen Sie die Oracle HTTP Server-Systeme auf der primären Site.
Stoppen Sie wenn möglich die Managed Server in der primären Site.

Verwenden Sie die Administrationsserverkonsole WebLogic oder Skripte, um Managed Server in der Primärdatenbank zu stoppen.
Wechseln Sie über den Frontend-DNS-Namen.

Führen Sie den erforderlichen DNS-Push in den 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 in 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 der TTL-Wert hoch ist (z.B. 20 Minuten), nimmt die DNS-Änderung diese Zeit in den Clients in Anspruch. Die Verwendung niedrigerer TTL-Werte beschleunigt dies. Dies kann jedoch zu einem Overhead führen, weil Clients das DNS häufiger erreichen, anstatt gecachte Namen zu verwenden. Ein guter Ansatz besteht darin, den TTL-Wert vorübergehend (z.B. 1 Min.) vor der Änderung im DNS auf einen niedrigen Wert zu setzen. Führen Sie dann die Änderung durch, und setzen Sie nach Abschluss des Switchover-Vorgangs den TTL-Wert auf den ursprünglichen Wert zurück.
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
```
Wenn sie noch nicht hochgefahren sind, starten Sie die Oracle HTTP Server-Systeme in der sekundären Site (neue Primärdatenbank).
Starten Sie den Admin-Server auf der sekundären Site (neue primäre Site), oder starten Sie den Server neu, wenn er bereits gestartet wurde.
Durch das Starten des Admin-Servers werden Konfigurationsänderungen aktiviert, die repliziert wurden, während dies eine Standby-Datenbank war.
Starten Sie die sekundären Managed Server in der sekundären Site (neue primäre Site).
Verwenden Sie die WebLogic-Konsole oder -Skripte, um die sekundären Managed Server zu starten.

Sekundäre 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 WebLogic Server-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 JMS-Nachrichten in der Datenbank ausstehen, wenn sie in einen Snapshot konvertiert werden, verarbeiten die Server der Standbysite sie beim Starten. Stellen Sie sicher, dass bei der Konvertierung in die Snapshot-Standbydatenbank keine ausstehenden Aktionen in der Primärdatenbank vorhanden sind.

Verwenden Sie als oracle-Benutzer Oracle Data Guard Broker auf dem 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.
Wenn sie noch nicht hochgefahren sind, starten Sie die Oracle HTTP Server-Systeme auf der sekundären Site.
Starten Sie den Administrationsserver auf der sekundären Site.
Starten Sie die sekundären Managed Server in der sekundären Site.
Verwenden Sie die WebLogic-Konsole oder -Skripte, um die sekundären Managed Server zu starten.
Validieren Sie die sekundäre Site.

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 WebLogic-Serveranwendungen 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 zur Auflösung in die Frontend-IP-Adresse der sekundären Site festlegen 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 müssen möglicherweise ihren lokalen DNS-Cache zurücksetzen, 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:
Es kann einige Zeit dauern, die sekundäre Site zu validieren.
Stoppen Sie die Managed Server und Admin-Server in der sekundären Site.
Verwenden Sie die sekundäre WebLogic-Konsole, um die Managed Server und den Admin-Server in der sekundären Site herunterzufahren.
Verwenden Sie als oracle-Benutzer Oracle Data Guard Broker auf dem primären Datenbankhost, und konvertieren Sie die sekundäre in die physische Standbydatenbank 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.
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.

Lokales Failover des Administrationsservers 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 vom Host des WebLogic-Servers, auf dem der Administrationsserver ausgeführt wurde, zu trennen und an den Host des WebLogic-Servers anzuhängen, auf dem die Administration verschoben wird (trennen Sie die VIP von APPHOST1, und hängen Sie sie an APPHOST2 auf der OCI-Site an):

Führen Sie als Benutzer root die folgenden Befehle in APPHOST1 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 von der Netzwerkschnittstelle.
```
ip addr del 100.70.8.120/20 dev ens3
```
Trennen Sie die VIP des Administrationsservers von APPHOST1.
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 APPHOST1.
3. Klicken Sie auf Angehängte VNICs, und wählen Sie die VNIC aus, an die das Administrationsserver-VIP angehängt ist.
4. Klicken Sie auf IPv4-Adressen, und bearbeiten Sie die vom Administrationsserver verwendete VIP.
5. Speichern Sie die IP-Adresse und den fqdn-Namen der VIP in einem Hinweis (Beispiel: 100.70.8.120, hydrwls-vip.midtiersubnet.hydrvcn.oraclevcn.com).
6. Klicken Sie auf Private IP löschen.
Hängen Sie die VIP des Administrationsservers an APPHOST2 an.
1. Navigieren Sie zur Compute-Instanz. Klicken Sie auf Compute, Instanzen, und klicken Sie dann auf APPHOST2.
2. Klicken Sie auf Angehängte VNICs, und wählen Sie die VNIC aus, an die das Administrationsserver-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 hydrwls-vip als Hostname.
Melden Sie sich als Root-Benutzer bei APPHOST2 an, und führen Sie dann die folgenden Befehle aus, um die VIP des Administrationsservers an die Netzwerkschnittstelle anzuhängen.
1. Prüfen Sie, wo die Netzwerkschnittstelle ausgeführt wird.
```
ip addr show dev ens3
```
2. Fügen Sie die VIP des Administrationsservers zur Netzwerkschnittstelle hinzu.
```
ip addr add 100.70.8.120/20 dev ens3 label ens3:1
```
Führen Sie die restlichen Schritte aus, wie unter Manuelles Failover des Administrationsservers prüfen beschrieben.