Tutorial: Migrieren von Oracle WebLogic Server auf Azure Virtual Machines mit Hochverfügbarkeit und Notfallwiederherstellung

Artikel
09/03/2024

Dieses Tutorial zeigt Ihnen eine einfache und effektive Methode zur Implementierung von Hochverfügbarkeit und Notfallwiederherstellung (HA/DR) für Java mit WebLogic Server (WLS) auf Azure Virtual Machines (VMs). Die Lösung veranschaulicht, wie sich mit einer einfachen, datenbankgesteuerten Jakarta EE-Anwendung, die auf WLS ausgeführt wird, eine niedrige Recovery Time Objective (RTO) und Recovery Point Objective (RPO) erreichen lassen. HA/DR ist ein komplexes Thema mit vielen möglichen Lösungen. Die beste Lösung hängt von Ihren individuellen Anforderungen ab. Weitere Möglichkeiten zum Implementieren von HA/DR finden Sie in den Ressourcen am Ende dieses Artikels.

In diesem Tutorial lernen Sie Folgendes:

Verwenden Sie für Azure optimierte Best Practices, um Hochverfügbarkeit und Notfallwiederherstellung zu erreichen.
Richten Sie eine Microsoft Azure SQL-Datenbank-Failovergruppe in Regionspaaren ein.
Richten Sie WLS-Clusterpaare auf Azure-VMs ein.
Richten Sie einen Azure Traffic Manager ein.
Konfigurieren Sie WLS-Cluster für Hochverfügbarkeit und Notfallwiederherstellung.
Testen Sie den Failover vom primären zum sekundären Standort.

Das folgende Diagramm veranschaulicht die von Ihnen erstellte Architektur:

Azure Traffic Manager überprüft den Status Ihrer Regionen und leitet den Datenverkehr entsprechend an die Anwendungsebene weiter. Sowohl die primäre als auch die sekundäre Region verfügt über eine vollständige Bereitstellung des WLS-Clusters. Allerdings bearbeitet nur die primäre Region aktiv Netzwerkanforderungen der Benutzer. Die sekundäre Region ist passiv und wird nur dann zum Empfang von Datenverkehr aktiviert, wenn in der primären Region eine Dienstunterbrechung auftritt. Azure Traffic Manager verwendet das Integritätsprüfungsfeature von Azure Application Gateway, um dieses bedingte Routing zu implementieren. Der primäre WLS wird ausgeführt, und der sekundäre Cluster wird heruntergefahren. Die Geo-Failover-RTO der Anwendungsebene hängt von der Zeit zum Starten der VMs und Ausführen des sekundären WLS-Clusters ab. Die RPO hängt von der Azure SQL-Datenbank ab, da die Daten in der Failovergruppe der Azure SQL-Datenbank persistent gespeichert und repliziert werden.

Die Datenbankebene besteht aus einer Azure SQL-Datenbank-Failovergruppe mit einem primären Server und einem sekundären Server. Der primäre Server befindet sich im aktiven Lese-/Schreibmodus und ist mit dem primären WLS-Cluster verbunden. Der sekundäre Server befindet sich im passiven schreibgeschützten Modus und ist mit dem sekundären WLS-Cluster verbunden. Sowohl bei manueller als auch automatischer Failover-Aktivierung schaltet das Geofailover alle sekundären Datenbanken in der Gruppe zur primären Rolle um. Informationen zu RPOs und RTO für Geofailover der Azure SQL-Datenbank finden Sie unter Übersicht über die Geschäftskontinuität.

Dieser Artikel wurde mit dem Azure SQL-Datenbankdienst geschrieben, da der Artikel auf die Features für hohe Verfügbarkeit (High Availability, HA) dieses Diensts basiert. Andere Datenbankoptionen sind möglich, aber Sie müssen die HA-Features der von Ihnen ausgewählten Datenbank berücksichtigen. Weitere Informationen, einschließlich Informationen zur Optimierung der Konfiguration von Datenquellen für die Replikation, finden Sie unter Konfigurieren von Datenquellen für die aktive/passive Bereitstellung von Oracle Fusion Middleware.

Voraussetzungen

Ein Azure-Abonnement. Wenn Sie kein Azure-Abonnement besitzen, erstellen Sie ein kostenloses Konto, bevor Sie beginnen.
Stellen Sie sicher, dass Sie im Abonnement über die Owner-Rolle oder die Contributor-Rolle und die User Access Administrator-Rolle verfügen. Sie können die Aufgabe überprüfen, indem Sie die Schritte in Auflisten von Azure-Rollenzuweisungen mithilfe des Azure-Portals befolgen.
Bereiten Sie einen lokalen Computer mit installiertem Windows, Linux oder macOS vor.
Installieren Sie Git, und richten Sie es ein.
Installieren Sie eine Java SE-Implementierung, Version 17 oder höher (z. B. der Microsoft-Build von OpenJDK).
Installieren Sie Maven, Version 3.9.3 oder höher.

Einrichten einer Azure SQL-Datenbank-Failovergruppe in Regionspaaren

In diesem Abschnitt erstellen Sie eine Azure SQL-Datenbank-Failovergruppe in Regionspaaren für die Verwendung mit Ihren WLS-Clustern und Ihrer App. In einem späteren Abschnitt konfigurieren Sie WLS so, dass die Sitzungsdaten und die Transaktionsprotokolldaten (TLOG) in dieser Datenbank gespeichert werden. Diese Vorgehensweise entspricht der Maximum Availability Architecture (MAA) von Oracle. Dieser Leitfaden bietet eine Azure-Anpassung für MAA. Weitere Informationen zu MAA finden Sie unter Oracle Maximum Availability Architecture.

Erstellen Sie zunächst die primäre Azure SQL-Datenbank, indem Sie die Schritte im Azure-Portal in Schnellstart: Erstellen einer Einzeldatenbank – Azure SQL-Datenbank befolgen. Befolgen Sie die Schritte bis zum Abschnitt „Ressourcen bereinigen“, jedoch nicht einschließlich dieses Abschnitts. Befolgen Sie die folgenden Anweisungen, während Sie den Artikel durchgehen, kehren Sie dann nach dem Erstellen und Konfigurieren der Azure SQL-Datenbank zu diesem Artikel zurück:

Wenn Sie den Abschnitt Erstellen einer Einzeldatenbank erreichen, verwenden Sie die folgenden Schritte:
1. Speichern Sie in Schritt 4 zum Erstellen einer neuen Ressourcengruppe den Wert Ressourcengruppenname, z. B. myResourceGroup.
2. Speichern Sie in Schritt 5 für den Datenbanknamen den Wert Datenbankname, z. B. mySampleDatabase.
3. Führen Sie in Schritt 6 zum Erstellen des Servers die folgenden Schritte aus:
  1. Speichern Sie den eindeutigen Servernamen, z. B. sqlserverprimary-ejb120623.
  2. Wählen Sie unter Standort die Option (USA) USA, Osten aus.
  3. Wählen Sie für Authentifizierungsmethode die Option SQL-Authentifizierung verwenden aus.
  4. Speichern Sie den Wert Serveradministratoranmeldung, z. B. azureuser.
  5. Speichern Sie den Wert Kennwort.
4. Wählen Sie in Schritt 8 für Workloadumgebung die Option Entwicklung aus. Sehen Sie sich die Beschreibung an, und berücksichtigen Sie weitere Optionen für Ihre Workload.
5. Wählen Sie in Schritt 11 für Redundanz für Sicherungsspeicher die Option Lokal redundanter Sicherungsspeicher aus. Ziehen Sie weitere Optionen für Ihre Sicherungen in Betracht. Weitere Informationen finden Sie im Abschnitt Redundanz des Sicherungsspeichers von Automatisierte Sicherungen in Azure SQL-Datenbank.
6. Wählen Sie in Schritt 14 in der Konfiguration der Firewallregeln für Azure-Diensten und -Ressourcen den Zugriff auf diesen Server erlauben die Option Ja aus.
Wenn Sie den Abschnitt Abfragen der Datenbank erreichen, verwenden Sie die folgenden Schritte:
1. Geben Sie in Schritt 3 Ihre Serveradministrator-Anmeldeinformationen der SQL-Authentifizierung zur Anmeldung ein.
  
  Hinweis
  
  Wenn die Anmeldung mit einer Fehlermeldung ähnlich der folgenden Client mit IP-Adresse 'xx.xx.xx.xx' darf nicht auf den Server zugreifen angezeigt wird, wählen Sie IP xx.xx.xx.xx im Server auf die Positivliste setzen <your-sqlserver-name> am Ende der Fehlernachricht aus. Warten Sie, bis die Serverfirewallregeln die Aktualisierung abgeschlossen haben, und wählen Sie dann erneut OK aus.
2. Nachdem Sie die Beispielabfrage in Schritt 5 ausgeführt haben, löschen Sie den Editor, und erstellen Sie Tabellen.

Geben Sie die folgende Abfrage ein, um ein Schema für TLOG zu erstellen.

create table TLOG_msp1_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table TLOG_msp2_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table TLOG_msp3_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table wl_servlet_sessions (wl_id VARCHAR(100) NOT NULL, wl_context_path VARCHAR(100) NOT NULL, wl_is_new CHAR(1), wl_create_time DECIMAL(20), wl_is_valid CHAR(1), wl_session_values VARBINARY(MAX), wl_access_time DECIMAL(20), wl_max_inactive_interval INTEGER, PRIMARY KEY (wl_id, wl_context_path));

Nach einer erfolgreichen Ausführung sollte die Meldung Die Abfrage war erfolgreich: Betroffene Zeilen: 0 angezeigt werden.

Diese Datenbanktabellen werden zum Speichern des Transaktionsprotokolls (TLOG) und der Sitzungsdaten für Ihre WLS-Cluster und -App verwendet. Weitere Informationen finden Sie unter Verwenden eines JDBC TLOG-Speichers und Verwenden einer Datenbank für persistenten Speicher (JDBC-Persistenz).

Erstellen Sie als Nächstes eine Azure SQL-Datenbank-Failovergruppe, indem Sie die Azure-Portal-Schritte unter Konfigurieren einer Failovergruppe für Azure SQL-Datenbank ausführen. Sie benötigen lediglich die folgenden Abschnitte: Erstellen einer Failovergruppe und Testen des geplanten Failovers. Befolgen Sie die folgenden Schritte, während Sie den Artikel durchgehen, kehren Sie dann nach dem Erstellen und Konfigurieren der Azure SQL-Datenbank-Failovergruppe zu diesem Artikel zurück:

Wenn Sie den Abschnitt Erstellen einer Failovergruppe erreichen, verwenden Sie die folgenden Schritte:
1. Wählen Sie in Schritt 5 zum Erstellen der Failovergruppe die Option aus, um einen neuen sekundären Server zu erstellen, und führen Sie dann die folgenden Schritte aus:
  1. Geben Sie den Namen der Failovergruppe ein, z. B. failovergroupname-ejb120623, und speichern Sie diesen.
  2. Geben Sie den eindeutigen Servernamen ein, z. B. sqlserversecondary-ejb120623, und speichern Sie diesen.
  3. Geben Sie denselben Serveradministrator und dasselbe Kennwort wie für Ihren primären Server ein.
  4. Wählen Sie für Standort eine andere Region als die aus, die Sie für die primäre Datenbank verwendet haben.
  5. Achten Sie darauf, dass Azure-Diensten Zugriff auf den Server erlauben aktiviert ist.
2. Wählen Sie zum Konfigurieren von Datenbanken in der Gruppe in Schritt 5 die Datenbank aus, die Sie im primären Server erstellt haben, z. B. mySampleDatabase.
Nachdem Sie alle Schritte im Abschnitt Geplantes Failover testen abgeschlossen haben, lassen Sie die Failovergruppenseite geöffnet, und verwenden Sie sie später für den Failovertest der WLS-Cluster.

Einrichten von gekoppelten WLS-Clustern auf Azure-VMs

Erstellen Sie in diesem Abschnitt zwei WLS-Cluster auf Azure-VMS mithilfe des Angebots Oracle WebLogic Server Cluster auf Azure VMs. Der Cluster in der Region USA, Osten ist der primäre und wird später als aktiver Cluster konfiguriert. Der Cluster in der Region USA, Westen ist der sekundäre und wird später als passiver Cluster konfiguriert.

Einrichten des primären WLS-Clusters

Öffnen Sie zunächst das Angebot Oracle WebLogic Server Cluster auf Azure VMs in Ihrem Browser, und wählen Sie Erstellen aus. Der Bereich Grundeinstellungen des Angebots sollte angezeigt werden.

Führen Sie die folgenden Schritte aus, um den Bereich Grundeinstellungen auszufüllen:

Stellen Sie sicher, dass der für Abonnement angezeigte Wert mit dem Wert übereinstimmt, der die im Abschnitt „Voraussetzungen“ aufgeführten Rollen enthält.
Sie müssen das Angebot in einer leeren Ressourcengruppe bereitstellen. Wählen Sie im Feld Ressourcengruppe die Option Neu erstellen aus, und geben Sie einen eindeutigen Wert für die Ressourcengruppe ein, z. B. wls-cluster-eastus-ejb120623.
Wählen Sie unter Instanzdetails für Region die Option USA, Osten aus.
Geben Sie unter Anmeldeinformationen für virtuelle Computer und WebLogic ein Kennwort für Administratorkonto der VM und WebLogic Administrator ein. Speichern Sie den Benutzernamen und das Kennwort für WebSphere Administrator.
Behalten Sie die Standardwerte für andere Felder bei.
Wählen Sie Weiter aus, um zum Bereich TLS/SSL-Konfiguration zu wechseln.

Behalten Sie die Standardwerte im Bereich TLS/SSL-Konfiguration bei, und wählen Sie Weiter aus, um zum Bereich Azure Application Gateway zu navigieren. Verwenden Sie dann die folgenden Schritte.

Wählen Sie für Mit Azure Application Gateway verbinden? die Option Ja aus.
Wählen Sie für die Option Gewünschtes TLS/SSL-Zertifikat auswählen die Option Ein selbstsigniertes Zertifikat erstellen aus.
Wählen Sie Weiter aus, um zum Bereich Netzwerk zu wechseln.

Ihnen sollten alle Felder im Bereich Netzwerk angezeigt werden, die mit den Standardwerten vorab ausgefüllt wurden. Gehen Sie wie folgt vor, um die Netzwerkkonfiguration zu speichern:

Wählen Sie Virtuelles Netzwerk bearbeiten aus. Speichern Sie den Adressraum des virtuellen Netzwerks, z. B. 10.1.4.0/23.
Wählen Sie wls-subnet aus, um das Subnetz zu bearbeiten. Speichern Sie unter Subnetzdetails die Startadresse und die Subnetzgröße, z. B. 10.1.5.0 und /28.
Wenn Sie Änderungen vornehmen, speichern Sie die Änderungen.
Kehren Sie zum Bereich Netzwerk zurück.
Wählen Sie Weiter aus, um zum Bereich Datenbank zu wechseln.

Die folgenden Schritte zeigen Ihnen, wie Sie den Bereich Datenbank ausfüllen:

Wählen Sie unter Mit Datenbank verbinden? die Option Ja aus.
Wählen Sie für Datenbanktyp auswählen die Option Microsoft SQL Server (unterstützt passwortlose Verbindung) aus.
Geben Sie für JNDI-Name den Namen jdbc/WebLogicCafeDB ein.
Ersetzen Sie für DataSource-Verbindungszeichenfolge die Platzhalter durch die Werte, die Sie im vorherigen Abschnitt für die primäre SQL-Datenbank gespeichert haben, z. B. jdbc:sqlserver://sqlserverprimary-ejb120623.database.windows.net:1433;database=mySampleDatabase.
Wählen Sie für Globales Transaktionsprotokoll die Option Keines aus.
Ersetzen Sie für Datenbankbenutzername die Platzhalter durch die Werte, die Sie im vorherigen Abschnitt für die primäre SQL-Datenbank gespeichert haben, z. B. azureuser@sqlserverprimary-ejb120623.
Geben Sie das Anmeldekennwort des Serveradministrators ein, das Sie zuvor für das Datenbankkennwort gespeichert haben. Geben Sie denselben Wert für Kennwort bestätigen ein.
Übernehmen Sie die Standardwerte für die anderen Felder.
Klicken Sie auf Überprüfen + erstellen.
Warten Sie, bis Abschließende Überprüfung wird ausgeführt... erfolgreich abgeschlossen ist. Wählen Sie dann Erstellen aus.

Nach einiger Zeit sollte die Seite Bereitstellung angezeigt werden, auf der Bereitstellung wird ausgeführt angezeigt wird.

Hinweis

Wenn bei Abschließende Überprüfung wird ausgeführt... Probleme auftreten, beheben Sie diese, und versuchen Sie es erneut.

Abhängig von den Netzwerkbedingungen und anderen Aktivitäten in der ausgewählten Region kann die Bereitstellung bis zu 50 Minuten dauern. Danach sollte auf der Bereitstellungsseite der Text Ihre Bereitstellung wurde abgeschlossen. angezeigt werden.

In der Zwischenzeit können Sie den sekundären WLS-Cluster parallel einrichten.

Einrichten des sekundären WLS-Clusters

Befolgen Sie die gleichen Schritte wie im Abschnitt Einrichten des primären WLS-Clusters, um den sekundären Cluster in der Region USA, Westen mit Ausnahme der folgenden Unterschiede einzurichten:

Verwenden Sie im Bereich Grundeinstellungen die folgenden Schritte:
1. Wählen Sie im Feld Ressourcengruppe die Option Neu erstellen aus, und geben Sie einen anderen eindeutigen Wert für die Ressourcengruppe ein, z. B. wls-cluster-westtus-ejb120623.
2. Wählen Sie unter Instanzdetails für Region die Option USA, Westen aus.
Verwenden Sie im Bereich Netzwerk die folgenden Schritte:
1. Geben Sie für Virtuelles Netzwerk bearbeiten denselben Adressraum des virtuellen Netzwerks wie für Ihren primären WLS-Cluster ein, z. B. 10.1.4.0/23.
  
  Hinweis
  
  Sie sollten eine Warnmeldung ähnlich der folgenden sehen: Der Adressraum „10.1.4.0/23 (10.1.4.0 - 10.1.5.255)“ überschneidet sich mit dem Adressraum „10.1.4.0/23 (10.1.4.0 - 10.1.5.255)“ des virtuellen Netzwerks „wls-vnet“. Virtuelle Netzwerke mit überlappendem Adressraum können nicht miteinander verbunden werden. Wenn Sie diese virtuellen Netzwerke miteinander verbinden möchten, ändern Sie den Adressraum „10.1.4.0/23 (10.1.4.0 - 10.1.5.255)“. Sie können diese Meldung ignorieren, da Sie zwei WLS-Cluster mit derselben Netzwerkkonfiguration benötigen.
2. Geben Sie für wls-subnet dieselbe Startadresse und Subnetzgröße wie Ihr primärer WLS-Cluster ein, z. B. 10.1.5.0 und /28.
Verwenden Sie im Bereich Datenbank die folgenden Schritte:
1. Ersetzen Sie für DataSource-Verbindungszeichenfolge die Platzhalter durch die Werte, die Sie im vorherigen Abschnitt für die sekundäre SQL-Datenbank gespeichert haben, z. B. jdbc:sqlserver://sqlserversecondary-ejb120623.database.windows.net:1433;database=mySampleDatabase.
2. Ersetzen Sie für Datenbankbenutzername die Platzhalter durch die Werte, die Sie im vorherigen Abschnitt für die sekundäre SQL-Datenbank gespeichert haben, z. B. azureuser@sqlserversecondary-ejb120623.

Spiegeln der Netzwerkeinstellungen für die beiden Cluster

Während der Phase der Wiederaufnahme ausstehender Transaktionen im sekundären WLS-Cluster nach einem Failover überprüft WLS den Besitz des TLOG-Speichers. Um die Überprüfung erfolgreich zu bestehen, müssen alle verwalteten Server im sekundären Cluster dieselbe private IP-Adresse wie der primäre Cluster aufweisen.

In diesem Abschnitt wird gezeigt, wie Sie die Netzwerkeinstellungen vom primären Cluster auf den sekundären Cluster spiegeln.

Führen Sie zunächst die folgenden Schritte aus, um Netzwerkeinstellungen für den primären Cluster zu konfigurieren, nachdem die Bereitstellung abgeschlossen wurde:

Wählen Sie im Bereich Übersicht der Seite Bereitstellung die Option Zu Ressourcengruppe wechseln aus.
Wählen Sie die Netzwerkschnittstelle adminVM_NIC_with_pub_ip aus.
1. Wählen Sie unter Einstellungen die Option IP-Konfigurationen aus.
2. Wählen Sie ipconfig1 aus.
3. Wählen Sie unter Private IP-Adresseinstellungen die Option Statisch für Zuteilung aus. Speichern Sie die private IP-Adresse.
4. Wählen Sie Speichern.
Kehren Sie zur Ressourcengruppe des primären WLS-Clusters zurück, und wiederholen Sie dann Schritt 3 für die Netzwerkschnittstellen mspVM1_NIC_with_pub_ip, mspVM2_NIC_with_pub_ip und mspVM3_NIC_with_pub_ip.
Warten Sie, bis alle Aktualisierungen abgeschlossen sind. Sie können das Benachrichtigungssymbol im Azure-Portal auswählen, um den Bereich Benachrichtigungen für die Statusüberwachung zu öffnen.
Kehren Sie zur Ressourcengruppe des primären WLS-Clusters zurück, und kopieren Sie dann den Namen für die Ressource mit dem Typ Privater Endpunkt, z. B. 7e8c8bsaep. Verwenden Sie diesen Namen, um die verbleibende Netzwerkschnittstelle zu finden, z. B. 7e8c8bsaep.nic.c0438c1a-1936-4b62-864c-6792eec3741a. Wählen Sie sie aus, und führen Sie die vorherigen Schritte aus, um die private IP-Adresse abzurufen.

Führen Sie dann die folgenden Schritte aus, um die Netzwerkeinstellungen für den sekundären Cluster nach Abschluss der Bereitstellung zu konfigurieren:

Wählen Sie im Bereich Übersicht der Seite Bereitstellung die Option Zu Ressourcengruppe wechseln aus.
Befolgen Sie für die Netzwerkschnittstellen adminVM_NIC_with_pub_ip, mspVM1_NIC_with_pub_ip, mspVM2_NIC_with_pub_ip und mspVM3_NIC_with_pub_ip die vorherigen Schritte, um die Zuteilung der privaten IP-Adresse auf Statisch zu aktualisieren.
Warten Sie, bis alle Aktualisierungen abgeschlossen sind.
Befolgen Sie für die Netzwerkschnittstelle mspVM1_NIC_with_pub_ip, mspVM2_NIC_with_pub_ip, und mspVM3_NIC_with_pub_ip die vorherigen Schritte, aktualisieren Sie jedoch die private IP-Adresse auf denselben Wert, der für den primären Cluster verwendet wird. Warten Sie, bis die aktuelle Aktualisierung der Netzwerkschnittstelle abgeschlossen ist, bevor Sie mit der nächsten fortfahren.

Hinweis

Sie können die private IP-Adresse der Netzwerkschnittstelle, die Teil eines privaten Endpunkts ist, nicht ändern. Um die privaten IP-Adressen von Netzwerkschnittstellen für verwaltete Server einfach zu spiegeln, sollten Sie die private IP-Adresse für adminVM_NIC_with_pub_ip auf eine nicht verwendete IP-Adresse aktualisieren. Je nach Zuordnung privater IP-Adressen in Ihren beiden Clustern müssen Sie möglicherweise auch die private IP-Adresse im primären Cluster aktualisieren.

Die folgende Tabelle zeigt ein Beispiel für die Spiegelung der Netzwerkeinstellungen für zwei Cluster:

Cluster	Netzwerkschnittstelle	Private IP-Adresse (vor)	Private IP-Adresse (nach)	Aktualisierungssequenz
Primär	`7e8c8bsaep.nic.c0438c1a-1936-4b62-864c-6792eec3741a`	`10.1.5.4`	`10.1.5.4`
Primär	`adminVM_NIC_with_pub_ip`	`10.1.5.7`	`10.1.5.7`
Primär	`mspVM1_NIC_with_pub_ip`	`10.1.5.5`	`10.1.5.5`
Primär	`mspVM2_NIC_with_pub_ip`	`10.1.5.8`	`10.1.5.9`	1
Primär	`mspVM3_NIC_with_pub_ip`	`10.1.5.6`	`10.1.5.6`
Secondary	`1696b0saep.nic.2e19bf46-9799-4acc-b64b-a2cd2f7a4ee1`	`10.1.5.8`	`10.1.5.8`
Secondary	`adminVM_NIC_with_pub_ip`	`10.1.5.5`	`10.1.5.4`	4
Secondary	`mspVM1_NIC_with_pub_ip`	`10.1.5.7`	`10.1.5.5`	5
Secondary	`mspVM2_NIC_with_pub_ip`	`10.1.5.6`	`10.1.5.9`	2
Secondary	`mspVM3_NIC_with_pub_ip`	`10.1.5.4`	`10.1.5.6`	3

Überprüfen Sie die Gruppe privater IP-Adressen für alle verwalteten Server, die aus dem Back-End-Pool des Azure Application Gateway besteht, das Sie in jedem Cluster bereitgestellt haben. Wenn sie aktualisiert wird, führen Sie die folgenden Schritte aus, um den Back-End-Pool des Azure Application Gateway entsprechend zu aktualisieren:

Öffnen Sie die Ressourcengruppe des Clusters.
Suchen Sie die Ressource myAppGateway mit dem Typ Application Gateway. Wählen Sie es aus, um es zu öffnen.
Wählen Sie im Abschnitt Einstellungen die Option Back-End-Pools und dann myGatewayBackendPool aus.
Ändern Sie die Werte Back-End-Ziele durch die aktualisierte(n) private(n) IP-Adresse(n), und wählen Sie dann Speichern aus. Warten Sie, bis der Vorgang abgeschlossen ist.
Wählen Sie im Abschnitt Einstellungen die Option Integritätstests und dann HTTPhealthProbe aus.
Stellen Sie sicher, dass Ich möchte vor dem Hinzufügen des Integritätstests die Back-End-Integrität testen ausgewählt ist, und wählen Sie dann Testen aus. Ihnen sollte angezeigt werden, dass der Wert Status des Back-End-Pools myGatewayBackendPool als „Fehlerfrei“ gekennzeichnet ist. Wenn dies nicht der Fall ist, überprüfen Sie, ob private IP-Adressen wie erwartet aktualisiert werden und die VMs ausgeführt werden, und testen Sie dann den Integritätstest erneut. Sie müssen das Problem beheben, bevor Sie fortfahren.

Im folgenden Beispiel wird der Azure Application Gateway-Back-End-Pool für jeden Cluster aktualisiert:

Cluster	Azure Application Gateway-Back-End-Pool	Back-End-Ziele (vor)	Back-End-Ziele (nach)
Primär	`myGatewayBackendPool`	(`10.1.5.5`, `10.1.5.8`, `10.1.5.6`)	(`10.1.5.5`, `10.1.5.9`, `10.1.5.6`)
Secondary	`myGatewayBackendPool`	(`10.1.5.7`, `10.1.5.6`, `10.1.5.4`)	(`10.1.5.5`, `10.1.5.9`, `10.1.5.6`)

Um die Spiegelung der Netzwerkeinstellungen zu automatisieren, sollten Sie die Azure CLI verwenden. Weitere Informationen finden Sie unter Erste Schritte mit der Azure-Befehlszeilenschnittstelle.

Überprüfen der Bereitstellungen der Cluster

Sie haben in jedem Cluster ein Azure Application Gateway und einen WLS-Administratorserver bereitgestellt. Das Azure Application Gateway fungiert als Load Balancer für alle verwalteten Server im Cluster. Der WLS-Administratorserver stellt eine Webkonsole für die Clusterkonfiguration bereit.

Führen Sie die folgenden Schritte aus, um zu überprüfen, ob das Azure Application Gateway und die WLS-Verwaltungskonsole in jedem Cluster funktionieren, bevor Sie zum nächsten Schritt wechseln:

Kehren Sie zur Seite Bereitstellung zurück, und wählen Sie dann Ausgaben aus.
Kopieren Sie den Wert der Eigenschaft appGatewayURL. Fügen Sie die Zeichenfolge weblogic/ready an, und öffnen Sie dann diese URL in einer neuen Browserregisterkarte. Sie sollten eine leere Seite ohne Fehlermeldung sehen. Wenn dies nicht der Fall ist, müssen Sie das Problem beheben, bevor Sie fortfahren.
Kopieren und speichern Sie den Wert der Eigenschaft adminConsole. Öffnen Sie sie auf einer neuen Browserregisterkarte. Die Anmeldeseite der WebLogic Server Administration Console sollte angezeigt werden. Melden Sie sich bei der Konsole mit dem Benutzernamen und Kennwort für den WebLogic-Administrator an, den Sie zuvor gespeichert haben. Wenn Sie sich nicht anmelden können, müssen Sie das Problem beheben, bevor Sie fortfahren.

Führen Sie die folgenden Schritte aus, um die IP-Adresse von Azure Application Gateway für jeden Cluster abzurufen. Sie verwenden diese Werte, wenn Sie später den Azure Traffic Manager einrichten.

Öffnen Sie die Ressourcengruppe, in der Ihr Cluster bereitgestellt wird. Wählen Sie beispielsweise Übersicht aus, um zum Bereich „Übersicht“ der Bereitstellungsseite zurückzukehren. Wählen Sie dann Zu Ressourcengruppe wechseln aus.
Suchen Sie die Ressource gwip mit dem Typ Öffentliche IP-Adresse. Wählen Sie sie dann aus, um sie zu öffnen. Suchen Sie nach dem Feld IP-Adresse, und speichern Sie den Wert.

Einrichten von Azure Traffic Manager

In diesem Abschnitt erstellen Sie einen Azure Traffic Manager zum Verteilen des Datenverkehrs an Ihre öffentlich zugänglichen Anwendungen in den globalen Azure-Regionen. Der primäre Endpunkt verweist auf das Azure Application Gateway im primären WLS-Cluster, und der sekundäre Endpunkt verweist auf das Azure Application Gateway im sekundären WLS-Cluster.

Erstellen Sie einen Azure Traffic Manager anhand von Schnellstart: Erstellen eines Traffic Manager-Profils unter Verwendung des Azure-Portals. Überspringen Sie den Abschnitt Voraussetzungen. Sie benötigen nur die folgenden Abschnitte: Erstellen eines Traffic Manager-Profils, Hinzufügen von Traffic Manager-Endpunkten und Testen des Traffic Manager-Profils. Führen Sie die folgenden Schritte aus, während Sie die folgenden Abschnitte durchlaufen, und kehren Sie nach dem Erstellen und Konfigurieren des Azure Traffic Managers zu diesem Artikel zurück.

Gehen Sie wie folgt vor, wenn Sie den Abschnitt Erstellen eines Traffic Manager-Profils erreichen:
1. Führen Sie in Schritt 2 Erstellen des Traffic Manager-Profils die folgenden Schritte aus:
  1. Speichern Sie den eindeutigen Traffic Manager-Profilnamen für Name, z. B. tmprofile-ejb120623.
  2. Speichern Sie den neuen Ressourcengruppennamen für Ressourcengruppe, z. B. myResourceGroupTM1.
Gehen Sie wie folgt vor, wenn Sie den Abschnitt Hinzufügen von Traffic Manager-Endpunkten erreichen:
1. Führen Sie diese zusätzliche Aktion nach dem Schritt Auswählen des Profils aus den Suchergebnissen aus.
  1. Klicken Sie unter Einstellungen auf Konfiguration.
  2. Geben Sie für DNS time to live (TTL) die Zahl 10 ein.
  3. Geben Sie unter Überwachungseinstellungen für Endpunkt für Pfad /weblogic/ready ein.
  4. Verwenden Sie unter Einstellungen für schnelles Endpunktfailover die folgenden Werte:
    - Geben Sie für Interne Tests die Zahl 10 ein.
    - Geben Sie für Tolerierte Anzahl von Fehlern die Zahl 3 ein.
    - Geben Sie für Testtimeout die Zahl 5 ein.
  5. Wählen Sie Speichern. Warten Sie, bis der Vorgang abgeschlossen ist.
2. Verwenden Sie in Schritt 4 zum Hinzufügen des primären Endpunkts myPrimaryEndpoint die folgenden Schritte:
  1. Wählen Sie für Zielressourcentyp die Option Öffentliche IP-Adresse aus.
  2. Wählen Sie das Dropdownmenü Öffentliche IP-Adresse auswählen aus, und geben Sie die IP-Adresse von Application Gateway im WLS-Cluster USA, Osten ein, den Sie zuvor gespeichert haben. Sie sollten einen übereinstimmenden Eintrag sehen. Wählen Sie diesen für Öffentliche IP-Adresse aus.
3. Verwenden Sie in Schritt 6 zum Hinzufügen eines Failover-/sekundären Endpunkts myFailoverEndpoint die folgenden Schritte:
  1. Wählen Sie für Zielressourcentyp die Option Öffentliche IP-Adresse aus.
  2. Wählen Sie das Dropdownmenü Öffentliche IP-Adresse auswählen aus, und geben Sie die IP-Adresse von Application Gateway im WLS-Cluster USA, Westen ein, den Sie zuvor gespeichert haben. Sie sollten einen übereinstimmenden Eintrag sehen. Wählen Sie diesen für Öffentliche IP-Adresse aus.
4. Warten Sie einen Moment. Wählen Sie Aktualisieren aus, bis der Wert Überwachungsstatus für beide Endpunkte Online lautet.
Gehen Sie wie folgt vor, wenn Sie den Abschnitt Testen eines Traffic Manager-Profils erreichen:
1. Verwenden Sie im Unterabschnitt Überprüfen des DNS-Namens den folgenden Schritt:
  1. Speichern Sie in Schritt 3 den DNS-Namen Ihres Traffic Manager-Profils, z. B. http://tmprofile-ejb120623.trafficmanager.net.
2. Führen Sie im Unterabschnitt Anzeigen von Traffic Manager in Aktion die folgenden Schritte aus:
  1. Fügen Sie in den Schritten 1 und 3 /weblogic/ready an den DNS-Namen Ihres Traffic Manager-Profils in Ihrem Webbrowser an, z. B. http://tmprofile-ejb120623.trafficmanager.net/weblogic/ready. Es sollte eine leere Seite ohne Fehlermeldung angezeigt werden.
  2. Stellen Sie nach Abschluss aller Schritte sicher, dass Sie Ihren primären Endpunkt durch den Verweis auf Schritt 2 aktivieren, aber ersetzen Sie Deaktiviert durch Aktiviert. Kehren Sie dann zur Seite Endpunkte zurück.

Jetzt verfügen Sie über beide Endpunkte Aktiviert und Online im Traffic Manager-Profil. Lassen Sie die Seite geöffnet, und verwenden Sie sie später zur Überwachung des Endpunktstatus.

Konfigurieren des WLS-Clusters für Hochverfügbarkeit und Notfallwiederherstellung

In diesem Abschnitt konfigurieren Sie WLS-Cluster für hohe Verfügbarkeit und Notfallwiederherstellung.

Vorbereiten der Beispiel-App

In diesem Abschnitt erstellen und verpacken Sie eine Beispiel-CRUD Java/JakartaEE-Anwendung, die Sie später für Failovertests auf WLS-Clustern bereitstellen und ausführen.

Die App verwendet die JDBC-Sitzungspersistenz von WebLogic-Server, um HTTP-Sitzungsdaten zu speichern. Die Datenquelle jdbc/WebLogicCafeDB speichert die Sitzungsdaten, um Failover und Lastenausgleich über einen Cluster von WebLogic-Servern zu ermöglichen. Sie konfiguriert ein Persistenzschema, um Anwendungsdaten coffee in derselben Datenquelle jdbc/WebLogicCafeDB zu speichern.

Verwenden Sie die folgenden Schritte, um das Beispiel zu erstellen und zu paketieren:

Verwenden Sie die folgenden Befehle, um das Beispiel-Repository zu klonen und das Tag auszuchecken, das diesem Artikel entspricht:
```
git clone https://github.com/Azure-Samples/azure-cafe.git
cd azure-cafe
git checkout 20231206
```
Wenn Ihnen eine Meldung über Detached HEAD angezeigt wird, können Sie sie einfach ignorieren.
Verwenden Sie die folgenden Befehle, um zum Beispielverzeichnis zu navigieren und dann das Beispiel zu kompilieren und zu verpacken:
```
cd weblogic-cafe
mvn clean package
```

Wenn das Paket erfolgreich generiert wird, finden Sie es unter <parent-path-to-your-local-clone>/azure-cafe/weblogic-cafe/target/weblogic-cafe.war. Wenn das Paket nicht angezeigt wird, müssen Sie das Problem beheben, bevor Sie fortfahren.

Bereitstellen der Beispiel-App

Führen Sie nun die folgenden Schritte aus, um die Beispiel-App für die Cluster bereitzustellen, beginnend mit dem primären Cluster:

Öffnen Sie die adminConsole des Clusters auf einer neuen Registerkarte Ihres Webbrowsers. Melden Sie sich bei der WebLogic Server Administration Console mit dem Benutzernamen und dem Kennwort des WebLogic-Administrators an, die Sie zuvor gespeichert haben.
Suchen Sie die Domänenstruktur>wlsd>Bereitstellungen im Navigationsbereich. Wählen Sie Bereitstellungen aus.
Wählen Sie Sperren & Bearbeiten>Installieren>Ihre Datei(en) hochladen>Datei auswählen aus. Wählen Sie die Datei weblogic-cafe.war aus, die Sie zuvor vorbereitet haben.
Wählen Sie Weiter>Weiter>Weiter aus. Wählen Sie cluster1 mit der Option Alle Server im Cluster für die Bereitstellungsziele aus. Klicken Sie auf Weiter>Fertig stellen. Wählen Sie Änderungen aktivieren aus.
Wechseln Sie zur Registerkarte Steuerung, und wählen Sie weblogic-cafe aus der Bereitstellungstabelle aus. Wählen Sie Start mit der Option Bearbeitung aller Anfragen>Ja aus. Warten Sie einen Moment und aktualisieren Sie die Seite, bis Sie sehen, dass der Status der Bereitstellung weblogic-cafe Aktiv lautet. Wechseln Sie zur Registerkarte Überwachung, und stellen Sie sicher, dass der Kontextstamm der bereitgestellten Anwendung /weblogic-cafe lautet. Lassen Sie die WLS-Verwaltungskonsole geöffnet, damit Sie sie später zur weiteren Konfiguration verwenden können.

Wiederholen Sie die gleichen Schritte in der WebLogic Server Administration Console, aber für den sekundären Cluster in der Region USA, Westen.

Aktualisieren des Front-End-Hosts

Führen Sie die folgenden Schritte aus, um Ihre WLS-Cluster auf den Azure Traffic Manager aufmerksam zu machen. Da der Azure Traffic Manager der Einstiegspunkt für Benutzeranforderungen ist, aktualisieren Sie den Fronthost des WebLogic Server-Clusters auf den DNS-Namen des Traffic Manager-Profils, beginnend mit dem primären Cluster.

Stellen Sie sicher, dass Sie bei der WebLogic Server Administration Console angemeldet sind.
Navigieren Sie im Navigationsbereich zu Domänenstruktur>wlsd>Umgebung>Cluster. Wählen Sie Cluster aus.
Wählen Sie cluster1 aus der Clustertabelle aus.
Wählen Sie Sperren & Bearbeiten>HTTP aus. Entfernen Sie den aktuellen Wert für Frontend-Host, und geben Sie den DNS-Namen des Traffic Manager-Profils ein, das Sie zuvor gespeichert haben, ohne die führenden http://, z. B. tmprofile-ejb120623.trafficmanager.net. Wählen Sie Speichern>Änderungen aktivieren aus.

Wiederholen Sie die gleichen Schritte in der WebLogic Server Administration Console, aber für den sekundären Cluster in der Region USA, Westen.

Konfigurieren des Transaktionsprotokollspeichers

Konfigurieren Sie als Nächstes den JDBC-Transaktionsprotokollspeicher für alle verwalteten Server von Clustern, beginnend mit dem primären Cluster. Diese Vorgehensweise wird unter Verwenden von Transaktionsprotokolldateien zum Wiederherstellen von Transaktionen beschrieben.

Führen Sie die folgenden Schritte für den primären WLS-Cluster in der Region „USA, Osten“ aus:

Stellen Sie sicher, dass Sie bei der WebLogic Server Administration Console angemeldet sind.
Navigieren Sie im Navigationsbereich zu Domänenstruktur>wlsd>Umgebung>Server. Wählen Sie Server.
Die Server msp1, msp2 und msp3 sollten Ihnen in der aufgeführten Servertabelle angezeigt werden.
Wählen Sie msp1>Dienste>Sperren & Bearbeiten aus. Wählen Sie unter Transaktionsprotokollspeicher die Option JDBC aus.
Wählen Sie für Typ>Datenquelle die Option jdbc/WebLogicCafeDB aus.
Vergewissern Sie sich, dass der Wert für Präfixname TLOG_msp1_ lautet. Dies ist der Standardwert. Wenn sich der Wert unterscheidet, ändern Sie ihn in TLOG_msp1_.
Wählen Sie Speichern.
Wählen Sie Server>msp2 aus, und wiederholen Sie dieselben Schritte, mit der Ausnahme, dass der Standardwert für Präfixname TLOG_msp2_ lautet.
Wählen Sie Server>msp3 aus, und wiederholen Sie dieselben Schritte, mit der Ausnahme, dass der Standardwert für Präfixname TLOG_msp3_ lautet.
Wählen Sie Änderungen aktivieren aus.

Wiederholen Sie die gleichen Schritte in der WebLogic Server Administration Console, aber für den sekundären Cluster in der Region USA, Westen.

Starten Sie die verwalteten Server des primären Clusters neu.

Führen Sie dann die folgenden Schritte aus, um alle verwalteten Server des primären Clusters neu zu starten, damit die Änderungen wirksam werden:

Stellen Sie sicher, dass Sie bei der WebLogic Server Administration Console angemeldet sind.
Navigieren Sie im Navigationsbereich zu Domänenstruktur>wlsd>Umgebung>Server. Wählen Sie Server.
Wählen Sie die Registerkarte Steuerung aus. Wählen Sie msp1, msp2 und msp3 aus. Wählen Sie Herunterfahren mit der Option Bei Abschluss der Arbeit>Ja aus. Wählen Sie das Aktualisierungssymbol aus. Warten Sie, bis der Wert Status der letzten Aktion AUFGABE ABGESCHLOSSEN lautet. Ihnen sollte angezeigt werden, dass der Wert Status für die ausgewählten Server HERUNTERFAHREN lautet. Wählen Sie das Aktualisierungssymbol erneut aus, um die Statusüberwachung zu beenden.
Wählen Sie erneut msp1, msp2 und msp3 aus. Wählen Sie Start>Ja aus. Wählen Sie das Aktualisierungssymbol aus. Warten Sie, bis der Wert Status der letzten Aktion AUFGABE ABGESCHLOSSEN lautet. Ihnen sollte angezeigt werden, dass der Wert Status für die ausgewählten Server WIRD AUSGEFÜHRT lautet. Wählen Sie das Aktualisierungssymbol erneut aus, um die Statusüberwachung zu beenden.

Beenden der VMs im sekundären Cluster

Führen Sie nun die folgenden Schritte aus, um alle VMs im sekundären Cluster zu beenden und sie somit passiv zu machen:

Öffnen Sie die Azure-Portal-Startseite in einer neuen Registerkarte Ihres Browsers, und wählen Sie dann Alle Ressourcen aus. Geben Sie im Feld Nach einem beliebigen Feld filtern... den Ressourcengruppennamen ein, in dem der sekundäre Cluster bereitgestellt wird, z. B. wls-cluster-westus-ejb120623.
Wählen Sie Typ gleich alle aus, um den Filter Typ zu öffnen. Geben Sie für Wert den Wert Virtueller Computer ein. Sie sollten einen übereinstimmenden Eintrag sehen. Wählen Sie ihn als Wert aus. Wählen Sie Übernehmen. Es sollten vier VMs aufgeführt sein, einschließlich adminVM, mspVM1, mspVM2 und mspVM3.
Wählen Sie diese Option aus, um die einzelnen virtuellen Computer zu öffnen. Wählen Sie Beenden aus, und bestätigen Sie dies für jeden virtuellen Computer.
Wählen Sie das Benachrichtigungssymbol aus dem Azure-Portal aus, um den Bereich Benachrichtigungen zu öffnen.
Überwachen Sie das Ereignis Beenden des virtuellen Computers für jede VM, bis der Wert in Virtuellen Computer erfolgreich beendet geändert wird. Lassen Sie die Seite geöffnet, damit Sie sie später für den Failovertest verwenden können.

Wechseln Sie nun zur Browserregisterkarte, auf der Sie den Status der Endpunkte des Traffic Manager überwachen. Aktualisieren Sie die Seite, bis Sie sehen, dass der Endpunkt myFailoverEndpoint Herabgestuft und der Endpunkt myPrimaryEndpoint Online ist.

Hinweis

Eine produktionsfähige HA/DR-Lösung würde wahrscheinlich versuchen, eine niedrigere RTO zu erreichen, indem die VMs ausgeführt werden, aber nur die auf den VMs ausgeführte WLS-Software gestoppt wird. Im Falle eines Failovers würden die virtuellen Computer dann bereits ausgeführt, und die WLS-Software würde weniger Zeit in Anspruch nehmen. In diesem Artikel wurde entschieden, die virtuellen Computer zu beenden, da die Software, die von Oracle WebLogic Server Cluster auf Azure VMs bereitgestellt wird, automatisch die WLS-Software startet, wenn die VMs gestartet werden.

Überprüfen der App

Da der primäre Cluster ausgeführt wird, fungiert er als aktiver Cluster und verarbeitet alle Benutzeranforderungen, die von Ihrem Traffic Manager-Profil weitergeleitet werden.

Öffnen Sie den DNS-Namen Ihres Azure Traffic Manager-Profils auf einer neuen Registerkarte des Browsers, indem Sie den Kontextstamm /weblogic-cafe der bereitgestellten App anfügen, z. B. http://tmprofile-ejb120623.trafficmanager.net/weblogic-cafe. Erstellen Sie einen neuen Kaffee mit Name und Preis, z. B. Kaffee 1 mit dem Preis 10. Dieser Eintrag wird sowohl in der Anwendungsdatentabelle als auch in der Sitzungstabelle der Datenbank beibehalten. Die angezeigte Benutzeroberfläche sollte dem folgenden Screenshot ähneln:

Wenn Ihre Benutzeroberfläche nicht ähnlich aussieht, führen Sie die Problembehebung durch und lösen Sie das Problem, bevor Sie fortfahren.

Lassen Sie die Seite geöffnet, damit Sie sie später für den Failovertest verwenden können.

Testen des Failovers vom primären zum sekundären Standort

Um das Failover zu testen, führen Sie ein manuelles Failover Ihres primären Datenbankservers und Clusters auf den sekundären Datenbankserver und Cluster durch und führen dann über das Azure-Portal in diesem Abschnitt ein Failback aus.

Failover an den sekundären Standort

Führen Sie zunächst die folgenden Schritte aus, um die virtuellen Computer im primären Cluster herunterzufahren:

Suchen Sie den Namen Ihrer Ressourcengruppe, in der der primäre WLS-Cluster bereitgestellt wird, z. B. wls-cluster-eastus-ejb120623. Führen Sie dann die Schritte im Abschnitt Beenden der VMs im sekundären Cluster durch, ändern Sie aber die Zielressourcengruppe in Ihren primären WLS-Cluster, um alle VMs in diesem Cluster zu stoppen.
Wechseln Sie zur Browserregisterkarte Ihres Traffic Manager, aktualisieren Sie die Seite, bis der Wert Überwachungsstatus des Endpunkts myPrimaryEndpoint in Herabgestuft geändert wird.
Wechseln Sie zur Browserregisterkarte der Beispiel-App, und aktualisieren Sie die Seite. Ihnen sollte 504 Gateway Time-out oder 502 Bad Gateway angezeigt werden, da keiner der Endpunkte zugänglich ist.

Führen Sie als Nächstes die folgenden Schritte aus, um ein Failover der Azure SQL-Datenbank vom primären Server auf den sekundären Server durchzuführen:

Wechseln Sie zur Browserregisterkarte Ihrer Azure SQL-Datenbank-Failovergruppe.
Wählen Sie Failover>Ja aus.
Warten Sie, bis der Vorgang abgeschlossen ist.

Führen Sie dann die folgenden Schritte aus, um alle Server im sekundären Cluster zu starten:

Wechseln Sie zur Browserregisterkarte, auf der Sie alle virtuellen Computer im sekundären Cluster beendet haben.
Wählen Sie die VM adminVM aus. Wählen Sie Starten aus.
Überwachen Sie das Ereignis Starten des virtuellen Computers für adminVM im Bereich Benachrichtigungen, und warten Sie, bis der Wert in Virtuellen Computer gestartet geändert wird.
Wechseln Sie zur Browserregisterkarte der WebLogic Administration Console für den sekundären Cluster, und aktualisieren Sie die Seite, bis die Willkommensseite zur Anmeldung angezeigt wird.
Wechseln Sie zurück zur Browserregisterkarte, auf der alle virtuellen Computer im sekundären Cluster aufgelistet sind. Wählen Sie für die VMs mspVM1, mspVM2 und mspVM3 jeden einzelnen Computer und dann Start aus.
Überwachen Sie für die VMs mspVM1, mspVM2 und mspVM3 das Ereignis Starten des virtuellen Computers im Bereich Benachrichtigungen, und warten Sie, bis die Werte in Virtueller Computer gestartet geändert werden.

Verwenden Sie abschließend die folgenden Schritte, um sicherzustellen, dass die Beispiel-App nach dem Endpunkt myFailoverEndpoint in den Status Online geändert wurde:

Wechseln Sie zur Browserregisterkarte Ihres Traffic Manager, und aktualisieren Sie die Seite, bis Sie sehen, dass der Wert Überwachungsstatus des Endpunkts myFailoverEndpoint in den Status Online wechselt.
Wechseln Sie zur Browserregisterkarte der Beispiel-App, und aktualisieren Sie die Seite. Sie sollten in der Anwendungsdatentabelle und in der Sitzungstabelle, die in der Benutzeroberfläche angezeigt werden, dieselben Daten sehen, wie im folgenden Screenshot dargestellt:

Wenn Sie dieses Verhalten nicht beobachten, liegt es möglicherweise daran, dass der Traffic Manager Zeit benötigt, um DNS auf die Failoverwebsite zu verweisen. Das Problem könnte auch sein, dass Ihr Browser das Ergebnis der DNS-Namensauflösung zwischengespeichert hat, das auf die fehlgeschlagene Website verweist. Warten Sie einen Moment, und aktualisieren Sie die Seite erneut.

Hinweis

Eine produktionsfähige HA/DR-Lösung würde das kontinuierliche und regelmäßige Kopieren der WLS-Konfiguration vom primären zum sekundären Cluster berücksichtigen. Informationen dazu finden Sie in den Verweisen auf die Oracle-Dokumentation am Ende dieses Artikels.

Um das Failover zu automatisieren, erwägen Sie die Verwendung von Warnungen für Traffic Manager-Metriken und Azure Automation. Weitere Informationen finden Sie im Abschnitt Warnungen für Traffic Manager-Metriken von Traffic Manager-Metriken und -Warnungen und Verwenden einer Warnung zum Auslösen eines Azure Automation-Runbooks.

Failback zum primären Standort

Führen Sie die gleichen Schritte im Abschnitt Failover an den sekundären Standort aus, um ein Failback auf den primären Standort einschließlich Datenbankserver und Cluster durchzuführen, mit Ausnahme der folgenden Unterschiede:

Fahren Sie zunächst die virtuellen Computer im sekundären Cluster herunter. Ihnen sollte angezeigt werden, dass der Endpunkt myFailoverEndpoint in Herabgestuft geändert wurde.
Führen Sie als Nächstes ein Failover der Azure SQL-Datenbank vom sekundären Server auf den primären Server durch.
Starten Sie dann alle Server im primären Cluster.
Überprüfen Sie schließlich die Beispiel-App, nachdem der Endpunkt myPrimaryEndpoint Online ist.

Bereinigen von Ressourcen

Wenn Sie die WLS-Cluster und andere Komponenten nicht mehr verwenden möchten, führen Sie die folgenden Schritte aus, um die Ressourcengruppen zu löschen und die in diesem Tutorial verwendeten Ressourcen zu bereinigen:

Geben Sie den Ressourcengruppennamen der Azure SQL-Datenbank-Server (z. B. myResourceGroup) im Suchfeld oben im Azure-Portal ein, und wählen Sie die übereinstimmende Ressourcengruppe aus den Suchergebnissen aus.
Wählen Sie die Option Ressourcengruppe löschen.
Geben Sie unter Ressourcengruppennamen eingeben, um den Löschvorgang zu bestätigen den Ressourcengruppennamen ein.
Klicken Sie auf Löschen.
Wiederholen Sie die Schritte 1–4 für die Ressourcengruppe von Traffic Manager, z. B. myResourceGroupTM1.
Wiederholen Sie die Schritte 1–4 für die Ressourcengruppe des primären WLS-Clusters, z. B. wls-cluster-eastus-ejb120623.
Wiederholen Sie die Schritte 1–4 für die Ressourcengruppe des sekundären WLS-Clusters, z. B. wls-cluster-westus-ejb120623.

Nächste Schritte

In diesem Tutorial richten Sie eine HA/DR-Lösung ein, die aus einer Aktiv-Passiv-Anwendungsinfrastrukturebene mit einer Aktiv-Passiv-Datenbankebene besteht und in der sich beide Ebenen über zwei geografisch unterschiedliche Standorte erstrecken. Am ersten Standort ist sowohl die Anwendungsinfrastrukturebene als auch die Datenbankebene aktiv. Am zweiten Standort wird die sekundäre Domäne heruntergefahren, und die sekundäre Datenbank befindet sich im Standbymodus.

Weitere Optionen zum Erstellen von HA/DR-Lösungen und Ausführen von WLS auf Azure werden in den folgenden Referenzen beschrieben:

Notfallwiederherstellungslösungen für Oracle Fusion Middleware-Produkte

Dokumentation zur Zuverlässigkeit von Azure

Erstellen von Lösungen für hohe Verfügbarkeit

Automatisches Failover mit Azure Traffic Manager

Weitere Informationen zu Oracle WebLogic auf Azure VMs

Weitere Informationen zu Oracle WebLogic in AKS