Lernprogramm: Migrieren von Oracle WebLogic Server zu virtuellen Azure-Computern mit hoher Verfügbarkeit und Notfallwiederherstellung

Artikel
01/11/2024

In diesem Lernprogramm wird eine einfache und effektive Möglichkeit zum Implementieren von hoher Verfügbarkeit und Notfallwiederherstellung (HA/DR) für Java mithilfe von Oracle WebLogic Server (WLS) auf virtuellen Azure-Computern (VMs) gezeigt. Die Lösung veranschaulicht, wie Sie ein low Recovery Time Objective (RTO) und Recovery Point Objective (RPO) mithilfe einer einfachen datenbankgesteuerten Jakarta EE-Anwendung erreichen, die auf WLS ausgeführt wird. 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 azure optimierte bewährte Methoden, um hohe Verfügbarkeit und Notfallwiederherstellung zu erzielen.
Richten Sie eine Microsoft Azure SQL-Datenbank Failovergruppe in gekoppelten Regionen ein.
Richten Sie gekoppelte WLS-Cluster auf Azure-VMs ein.
Richten Sie einen Azure Traffic Manager ein.
Konfigurieren Sie WLS-Cluster für hohe Verfügbarkeit und Notfallwiederherstellung.
Testen Sie failover von primär auf sekundär.

Das folgende Diagramm veranschaulicht die Architektur, die Sie erstellen:

Azure Traffic Manager überprüft den Status Ihrer Regionen und leitet den Datenverkehr entsprechend an die Anwendungsebene weiter. Sowohl die primäre Region als auch die sekundäre Region verfügen über eine vollständige Bereitstellung des WLS-Clusters. Allerdings wird nur die primäre Region aktiv Netzwerkanforderungen von den Benutzern gewartet. Die sekundäre Region ist passiv und aktiviert, um Datenverkehr nur zu empfangen, wenn die primäre Region eine Dienstunterbrechung erlebt. Azure Traffic Manager verwendet das Integritätsprüfungsfeature des Azure-App lizenzierungsgateways, um dieses bedingte Routing zu implementieren. Der primäre WLS-Cluster wird ausgeführt, und der sekundäre Cluster wird heruntergefahren. Die Geofailover-RTO der Anwendungsebene hängt von der Zeit für das Starten von VMs und ausführen des sekundären WLS-Clusters ab. Das RPO hängt vom Azure SQL-Datenbank ab, da die Daten in der Azure SQL-Datenbank Failovergruppe beibehalten 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 Geofailover-RPO und RTO von Azure SQL-Datenbank finden Sie unter Übersicht über die Geschäftskontinuität.

Dieser Artikel wurde mit dem Azure SQL-Datenbank-Dienst 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 Configuring Data Sources for Oracle Fusion Middleware Active-Passive Deployment.

Voraussetzungen

Wenn Sie kein Azure-Abonnement besitzen, erstellen Sie ein kostenloses Konto, bevor Sie beginnen.
Stellen Sie sicher, dass Sie entweder über die Owner Rolle oder die ContributorUser Access Administrator Rollen im Abonnement verfügen. Sie können die Aufgabe überprüfen, indem Sie die Schritte in Azure-Rollenzuweisungen mithilfe der Azure-Portal auflisten.
Bereiten Sie einen lokalen Computer vor, auf dem Windows, Linux oder macOS installiert ist.
Installieren und Einrichten von Git.
Installieren Sie eine Java SE-Implementierung, Version 17 oder höher (z . B. den Microsoft-Build von OpenJDK).
Installieren Sie Maven, Version 3.9.3 oder höher.

Einrichten einer Azure SQL-Datenbank Failovergruppe in gekoppelten Regionen

In diesem Abschnitt erstellen Sie eine Azure SQL-Datenbank Failovergruppe in gekoppelten Regionen 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 Maximalen Verfügbarkeitsarchitektur (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 Azure-Portal Schritte in der Schnellstartanleitung ausführen: Erstellen einer einzelnen Datenbank – Azure SQL-Datenbank. Führen Sie die Schritte bis zum Abschnitt "Ressourcen bereinigen" aus, aber nicht einschließen. Verwenden Sie die folgenden Anweisungen, während Sie den Artikel durchgehen, und kehren Sie nach dem Erstellen und Konfigurieren des Azure SQL-Datenbank zu diesem Artikel zurück:

Wenn Sie den Abschnitt "Erstellen einer einzelnen Datenbank" erreichen, führen Sie die folgenden Schritte aus:
1. Notieren Sie in Schritt 4 zum Erstellen einer neuen Ressourcengruppe den Ressourcengruppennamenwert , z. B. myResourceGroup.
2. Notieren Sie in Schritt 5 für den Datenbanknamen den Datenbanknamenwert , z. B. mySampleDatabase.
3. Führen Sie in Schritt 6 zum Erstellen des Servers die folgenden Schritte aus:
  1. Notieren Sie sich 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 die Authentifizierungsmethode die SQL-Authentifizierung verwenden aus.
  4. Notieren Sie sich den Anmeldewert des Serveradministrators – z. B. azureuser.
  5. Notieren Sie sich den Kennwortwert .
4. Wählen Sie in Schritt 8 für die Workload-Umgebung 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 Sicherungsspeicherredundanz lokal redundanten Sicherungsspeicher aus. Ziehen Sie weitere Optionen für Ihre Sicherungen in Betracht. Weitere Informationen finden Sie im Abschnitt zur Redundanz des Sicherungsspeichers in Azure SQL-Datenbank.
6. Wählen Sie in Schritt 14 in der Firewallregelnkonfigurationdie Option "Azure-Dienste und -Ressourcen für den Zugriff auf diesen Server zulassen" die Option "Ja" aus.
Wenn Sie den Abschnitt "Abfrage der Datenbank" erreichen, führen Sie die folgenden Schritte aus:
1. Geben Sie in Schritt 3 Die Anmeldeinformationen ihres SQL-Authentifizierungsserveradministrators ein, um sich anzumelden.
  
  Hinweis
  
  Wenn die Anmeldung mit einer Fehlermeldung fehlschlägt, die dem Client mit der IP-Adresse "xx.xx.xx.xx.xx" ähnelt, nicht auf den Server zugreifen darf, wählen Sie "Allowlist IP xx.xx.xx.xx" auf server <your-sqlserver-name> am Ende der Fehlermeldung 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 Sitzungsdaten für Ihre WLS-Cluster und -App verwendet. Weitere Informationen finden Sie unter Using a DATABASE TLOG Store and Using a Database for Persistent Storage (PERSISTENT Persistence).

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. Führen Sie die folgenden Schritte aus, während Sie den Artikel durchgehen, und kehren Sie nach dem Erstellen und Konfigurieren der Azure SQL-Datenbank Failovergruppe zu diesem Artikel zurück:

Wenn Sie den Abschnitt "Failovergruppe erstellen" erreichen, führen Sie die folgenden Schritte aus:
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, und notieren Sie ihn, z. B. failovergroupname-ejb120623.
  2. Geben Sie den eindeutigen Servernamen ein, und notieren Sie ihn, z. B. sqlserversecondary-ejb120623.
  3. Geben Sie denselben Serveradministrator und dasselbe Kennwort wie Ihren primären Server ein.
  4. Wählen Sie für "Speicherort" einen anderen Bereich als den Bereich aus, den Sie für die primäre Datenbank verwendet haben.
  5. Stellen Sie sicher, dass Azure-Dienste für den Zugriff auf den Server aktiviert sind.
2. Wählen Sie in Schritt 5 zum Konfigurieren der Datenbanken innerhalb der Gruppe die Datenbank aus, die Sie auf dem 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

In diesem Abschnitt erstellen Sie zwei WLS-Cluster auf Azure-VMs mithilfe des Oracle WebLogic Server Cluster on Azure VMs offer. Der Cluster in Ost-USA ist primär und wird später als aktiver Cluster konfiguriert. Der Cluster in West-US ist sekundär und wird später als passiver Cluster konfiguriert.

Einrichten des primären WLS-Clusters

Öffnen Sie zunächst den Oracle WebLogic Server Cluster auf Azure VMs im Browser, und wählen Sie " Erstellen" aus. Der Bereich "Grundlagen" des Angebots sollte angezeigt werden.

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

Stellen Sie sicher, dass der für Abonnement angezeigte Wert identisch ist, der die im Abschnitt "Voraussetzungen" aufgeführten Rollen aufweist.
Sie müssen das Angebot in einer leeren Ressourcengruppe bereitstellen. Wählen Sie im Feld "Ressource" die Option "Neu erstellen" aus, und füllen Sie einen eindeutigen Wert für die Ressourcengruppe aus, z. B. wls-cluster-eastus-ejb120623.
Wählen Sie unter "Instanzdetails" für "Region" die Option "Ost-USA" aus.
Geben Sie unter "Anmeldeinformationen für virtuelle Computer" und "WebLogic" ein Kennwort für das Administratorkonto der VM bzw . des WebLogic-Administrators an. Notieren Sie sich den Benutzernamen und das Kennwort für WebLogic Administrator.
Behalten Sie die Standardwerte für andere Felder bei.
Wählen Sie "Weiter" aus, um zum Bereich "TLS/SSL-Konfiguration " zu wechseln.

Lassen Sie die Standardwerte im Bereich TLS/SSL-Konfiguration, wählen Sie "Weiter" aus, um zum Bereich "Azure-App lizenzierungsgateway" zu wechseln, und führen Sie dann die folgenden Schritte aus.

Wählen Sie für Verbinden zum Azure-App Lizenzierungsgateway "Ja" aus.
Wählen Sie für die Option "Gewünschtes TLS/SSL-Zertifikat auswählen" die Option "Selbstsigniertes Zertifikat generieren" aus.
Wählen Sie "Weiter" aus, um zum Netzwerkbereich zu wechseln.

Im Netzwerkbereich sollten alle Felder angezeigt werden, die bereits mit den Standardwerten aufgefüllt wurden. Führen Sie die folgenden Schritte aus, um die Netzwerkkonfiguration zu speichern:

Wählen Sie "Virtuelles Netzwerk bearbeiten" aus. Notieren Sie sich den Adressraum des virtuellen Netzwerks , z. B. 10.1.4.0/23.
Wählen Sie diese Option wls-subnet aus, um das Subnetz zu bearbeiten. Notieren Sie sich 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 Netzwerkbereich zurück.
Wählen Sie "Weiter" aus, um zum Datenbankbereich zu wechseln.

Die folgenden Schritte zeigen, wie Sie den Datenbankbereich ausfüllen:

Wählen Sie "Ja" aus, um Verbinden zur Datenbank zu verwenden.
Wählen Sie für "Datenbanktyp auswählen " Microsoft SQL Server (Kennwortlose Verbindung unterstützen) aus.
Geben Sie für JNDI Name folgendes ein : enter enter providers/WebLogicCafeDB.
Ersetzen Sie für "DataSource Verbinden ion String" die Platzhalter durch die Werte, die Sie aus dem vorherigen Abschnitt für die primäre SQL-Datenbank geschrieben haben, z. B. "sqlserver:sqlserver://sqlserverprimary-ejb120623.database.windows.net:1433"; database=mySampleDatabase.
Wählen Sie für das globale Transaktionsprotokoll "Keine" aus.
Ersetzen Sie für den Benutzernamen der Datenbank die Platzhalter durch die Werte, die Sie aus dem vorherigen Abschnitt für die primäre SQL-Datenbank geschrieben haben , z. B. azureuser@sqlserverprimary-ejb120623.
Geben Sie das Anmeldekennwort des Serveradministrators ein, das Sie zuvor für das Datenbankkennwort geschrieben haben. Geben Sie denselben Wert für das Kennwort bestätigen ein.
Behalten Sie die Standardwerte für die anderen Felder bei.
Klicken Sie auf Überprüfen + erstellen.
Warten Sie, bis die endgültige Überprüfung ausgeführt wird... erfolgreich abgeschlossen, und wählen Sie dann "Erstellen" aus.

Nach einer Weile sollte die Bereitstellungsseite angezeigt werden, auf der die Bereitstellung ausgeführt wird.

Hinweis

Wenn beim Ausführen der endgültigen Überprüfung Probleme auftreten , beheben Sie sie, und versuchen Sie es erneut.

Je nach Netzwerkbedingungen und anderen Aktivitäten in Ihrer ausgewählten Region kann die Bereitstellung bis zu 50 Minuten dauern. Danach sollte der Text "Ihre Bereitstellung abgeschlossen " auf der Bereitstellungsseite angezeigt werden.

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

Einrichten des sekundären WLS-Clusters

Führen Sie die gleichen Schritte wie im Abschnitt Einrichten des primären WLS-Clusters zum Einrichten des sekundären WLS-Clusters in der Region West-USA aus, mit Ausnahme der folgenden Unterschiede:

Führen Sie im Bereich " Grundlagen" die folgenden Schritte aus:
1. Wählen Sie im Feld "Ressource" die Option "Neu erstellen" aus, und füllen Sie einen anderen eindeutigen Wert für die Ressourcengruppe aus, z. B. wls-cluster-westtus-ejb120623.
2. Wählen Sie unter "Instanzdetails" für "Region" die Option "USA west" aus.
Führen Sie im Netzwerkbereich die folgenden Schritte aus:
1. Geben Sie für "Virtuelles Netzwerk bearbeiten" den gleichen Adressraum des virtuellen Netzwerks wie Ihr primärer WLS-Cluster ein, z. B. 10.1.4.0/23.
  
  Hinweis
  
  Es sollte eine Warnmeldung wie die folgende angezeigt werden: Adressraum "10.1.4.0/23 (10.1.4.0 - 10.1.5.255)" überlappt mit 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 peered werden. Wenn Sie diese virtuellen Netzwerke peeren 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, geben Sie dieselbe Startadresse und Subnetzgröße wie Ihr primärer WLS-Cluster ein , z. B. 10.1.5.0 und /28.
Führen Sie im Datenbankbereich die folgenden Schritte aus:
1. Ersetzen Sie für "DataSource Verbinden ion String" die Platzhalter durch die Werte, die Sie aus dem vorherigen Abschnitt für die sekundäre SQL-Datenbank geschrieben haben, z. B. "sqlserver:sqlserver://sqlserversecondary-ejb120623.database.windows.net:1433"; database=mySampleDatabase.
2. Ersetzen Sie für den Benutzernamen der Datenbank die Platzhalter durch die Werte, die Sie aus dem vorherigen Abschnitt für die sekundäre SQL-Datenbank geschrieben haben , z. B. azureuser@sqlserversecondary-ejb120623.

Spiegeln der Netzwerkeinstellungen für die beiden Cluster

Während der Phase der Fortsetzung 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 zum sekundären Cluster Spiegel.

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 Übersichtsbereich der Seite "Bereitstellung" die Option "Zur Ressourcengruppe wechseln" aus.
Wählen Sie die Netzwerkschnittstelle adminVM_NIC_with_pub_ipaus.
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 Die Zuordnung" aus. Notieren Sie sich 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_ipund mspVM3_NIC_with_pub_ip.
Warten Sie, bis alle Updates abgeschlossen sind. Sie können das Benachrichtigungssymbol im Azure-Portal auswählen, um den Benachrichtigungsbereich 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 re Standard ing-Netzwerkschnittstelle zu finden , z. B. 7e8c8bsaep.nic.c0438c1a-1936-4b62-864c-6792eec3741a. Wählen Sie es aus, und führen Sie die vorherigen Schritte aus, um die private IP-Adresse zu notieren.

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 "Zur Ressourcengruppe wechseln" aus.
Führen Sie für die Netzwerkschnittstellen adminVM_NIC_with_pub_ip, mspVM1_NIC_with_pub_ip, mspVM2_NIC_with_pub_ipund mspVM3_NIC_with_pub_ip, die vorherigen Schritte aus, um die private IP-Adresszuweisung auf Static zu aktualisieren.
Warten Sie, bis alle Updates abgeschlossen sind.
Führen Sie für die Netzwerkschnittstellen mspVM1_NIC_with_pub_ipmspVM2_NIC_with_pub_ip, und mspVM3_NIC_with_pub_ipführen Sie die vorherigen Schritte aus, aktualisieren sie jedoch die private IP-Adresse auf denselben Wert, der mit dem primären Cluster verwendet wird. Warten Sie, bis die aktuelle Aktualisierung der Netzwerkschnittstelle abgeschlossen ist, bevor Sie mit dem 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 problemlos Spiegel zu können, sollten Sie die private IP-Adresse für adminVM_NIC_with_pub_ip 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 Spiegel 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-App lication 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-App lizenzierungsgateways 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 Back-End-Pools aus, und wählen Sie dann ausmyGatewayBackendPool.
Ändern Sie die Back-End-Zielwerte mit der aktualisierten privaten IP-Adresse oder -Adressen, und wählen Sie dann "Speichern" aus. Warten Sie, bis sie abgeschlossen ist.
Wählen Sie im Abschnitt Einstellungen Integritätssonden und dann HTTPhealthProbe aus.
Stellen Sie sicher, dass ich die Back-End-Integrität testen möchte, bevor die Integritätsprüfung ausgewählt ist, und wählen Sie dann "Testen" aus. Sie sollten sehen, dass der Statuswert des Back-End-Pools myGatewayBackendPool als fehlerfrei gekennzeichnet ist. Wenn dies nicht der Grund ist, überprüfen Sie, ob private IP-Adressen wie erwartet aktualisiert werden und die virtuellen Computer ausgeführt werden, und testen Sie die Integritätsprüfung erneut. Sie müssen das Problem beheben und beheben, bevor Sie fortfahren.

Im folgenden Beispiel wird der back-End-Pool des Azure-App lizenzierungsgateways für jeden Cluster aktualisiert:

Cluster	Back-End-Pool für Azure-App lizenzierungsgateway	Back-End-Ziele (vor)	Back-End-Ziele (nach)
Primär	`myGatewayBackendPool`	(`10.1.5.5`, , `10.1.5.610.1.5.8`)	(`10.1.5.5`, , `10.1.5.610.1.5.9`)
Secondary	`myGatewayBackendPool`	(`10.1.5.7`, , `10.1.5.410.1.5.6`)	(`10.1.5.5`, , `10.1.5.610.1.5.9`)

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

Überprüfen der Bereitstellungen der Cluster

Sie haben ein Azure-App lication Gateway und einen WLS-Administratorserver in jedem Cluster bereitgestellt. Das Azure-App lizenzierungsgateway fungiert als Lastenausgleich 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-App lizenzierungsgateway 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 diese URL dann auf einer neuen Browserregisterkarte. Es sollte eine leere Seite ohne Fehlermeldung angezeigt werden. Andernfalls müssen Sie das Problem beheben und beheben, bevor Sie fortfahren.
Kopieren Und notieren Sie den Wert der Eigenschaft adminConsole. Öffnen Sie es auf einer neuen Browserregisterkarte. Die Anmeldeseite der WebLogic Server-Verwaltungskonsole sollte angezeigt werden. Melden Sie sich bei der Konsole mit dem Benutzernamen und kennwort für den WebLogic-Administrator an, den Sie zuvor geschrieben haben. Wenn Sie sich nicht anmelden können, müssen Sie das Problem beheben und beheben, bevor Sie fortfahren.

Führen Sie die folgenden Schritte aus, um die IP-Adresse des Azure-App lizenzierungsgateways für jeden Cluster zu notieren. Sie verwenden diese Werte, wenn Sie den Azure Traffic Manager später einrichten.

Öffnen Sie die Ressourcengruppe, in der Ihr Cluster bereitgestellt wird, z. B. " Übersicht" , um zum Übersichtsbereich der Bereitstellungsseite zurückzukehren. Wählen Sie dann "Gehe zur Ressourcengruppe" aus.
Suchen Sie die Ressource gwip mit dem Typ "Öffentliche IP-Adresse", und wählen Sie sie aus, um sie zu öffnen. Suchen Sie nach dem IP-Adressfeld , und notieren Sie den Wert.

Einrichten eines Azure Traffic Managers

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

Erstellen Sie ein Azure Traffic Manager-Profil mithilfe der folgenden Schnellstartanleitung: Erstellen Sie ein Traffic Manager-Profil mithilfe der Azure-Portal. Überspringen Sie den Abschnitt "Voraussetzungen" . Sie benötigen lediglich die folgenden Abschnitte: Erstellen eines Traffic-Manager-Profils, Hinzufügen von Traffic Manager-Endpunkten und Test Traffic Manager-Profil. Führen Sie die folgenden Schritte aus, während Sie diese Abschnitte durchlaufen, und kehren Sie nach dem Erstellen und Konfigurieren des Azure Traffic Managers zu diesem Artikel zurück.

Wenn Sie den Abschnitt " Erstellen eines Traffic Manager-Profils" erreichen, führen Sie die folgenden Schritte aus:
1. Führen Sie in Schritt 2 das Profil "Traffic Manager erstellen" die folgenden Schritte aus:
  1. Notieren Sie sich den eindeutigen Traffic Manager-Profilnamen für "Name ", z. B. "tmprofile-ejb120623".
  2. Notieren Sie sich den namen der neuen Ressourcengruppe für die Ressourcengruppe , z. B. myResourceGroupTM1.
Wenn Sie den Abschnitt "Traffic Manager-Endpunkte hinzufügen" erreichen, führen Sie die folgenden Schritte aus:
1. Führen Sie diese zusätzliche Aktion nach dem Schritt "Profil aus den Suchergebnissen auswählen" aus.
  1. Klicken Sie unter Einstellungen auf Konfiguration.
  2. Geben Sie 10 ein, um dns time to live (TTL) zu leben.
  3. Geben Sie unter den Endpunktüberwachungseinstellungen für "Pfad" /weblogic/ready ein.
  4. Verwenden Sie unter "Failovereinstellungen für schnelle Endpunkte" die folgenden Werte:
    - Geben Sie für internes Probing 10 ein.
    - Geben Sie für "Tolerierte Anzahl von Fehlern" den Wert "3" ein.
    - Für Probetimeout 5.
  5. Wählen Sie Speichern. Warten Sie, bis sie abgeschlossen ist.
2. Führen Sie in Schritt 4 zum Hinzufügen des primären Endpunkts myPrimaryEndpointdie folgenden Schritte aus:
  1. Wählen Sie für den Ressourcentyp "Ziel" die Option "Öffentliche IP-Adresse" aus.
  2. Wählen Sie die Dropdownliste " Öffentliche IP-Adresse auswählen" aus, und geben Sie die IP-Adresse des Anwendungsgateways ein, das im WLS-Cluster ost-US bereitgestellt wurde, den Sie zuvor geschrieben haben. Es sollte ein Übereinstimmen eines Eintrags angezeigt werden. Wählen Sie sie für die öffentliche IP-Adresse aus.
3. Führen Sie in Schritt 6 zum Hinzufügen eines Failovers/sekundären Endpunkts "myFailoverEndpoint" die folgenden Schritte aus:
  1. Wählen Sie für den Ressourcentyp "Ziel" die Option "Öffentliche IP-Adresse" aus.
  2. Wählen Sie die Dropdownliste " Öffentliche IP-Adresse auswählen" aus, und geben Sie die IP-Adresse des Anwendungsgateways ein, das im WLS-Cluster "West US " bereitgestellt wurde, den Sie zuvor geschrieben haben. Es sollte ein Übereinstimmen eines Eintrags angezeigt werden. Wählen Sie sie für die öffentliche IP-Adresse aus.
4. Warten Sie eine Weile. Wählen Sie "Aktualisieren" aus, bis der Statuswert "Überwachen" für beide Endpunkte "Online" lautet.
Wenn Sie den Abschnitt "Test Traffic Manager"-Profil erreicht haben, führen Sie die folgenden Schritte aus:
1. Verwenden Sie im Unterabschnitt "Überprüfen des DNS-Namens" den folgenden Schritt:
  1. Notieren Sie sich in Schritt 3 den DNS-Namen Ihres Traffic Manager-Profils , http://tmprofile-ejb120623.trafficmanager.netz. B. .
2. Führen Sie im Unterabschnitt "Datenverkehrs-Manager in Aktion" die folgenden Schritte aus:
  1. Fügen Sie in Schritt 1 und 3 /weblogic/ready an den DNS-Namen Ihres Traffic Manager-Profils in Ihrem Webbrowser an , http://tmprofile-ejb120623.trafficmanager.net/weblogic/readyz. B. . Es sollte eine leere Seite ohne Fehlermeldung angezeigt werden.
  2. Stellen Sie nach Abschluss aller Schritte sicher, dass Sie Ihren primären Endpunkt aktivieren, indem Sie auf Schritt 2 verweisen, aber "Deaktiviert" durch "Aktiviert" ersetzen. 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 Sie verwenden sie, um den Endpunktstatus später zu überwachen.

Konfigurieren der WLS-Cluster für hohe Verfü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 Sitzungspersistenz von WebLogic Server ZUR Speicherung von HTTP-Sitzungsdaten. Die Datenquelle jdbc/WebLogicCafeDB speichert die Sitzungsdaten, um Failover und Lastenausgleich über einen Cluster von WebLogic-Servern zu ermöglichen. Es konfiguriert ein Persistenzschema , um Anwendungsdaten coffee in derselben Datenquelle jdbc/WebLogicCafeDBzu speichern.

Führen Sie die folgenden Schritte aus, um das Beispiel zu erstellen und zu verpacken:

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 eine Meldung angezeigt Detached HEADwird, ist es sicher zu 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-café/weblogic-café/target/weblogic-café.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-Verwaltungskonsole mit dem Benutzernamen und Kennwort des WebLogic-Administrators an, den Sie zuvor geschrieben haben.
Suchen Sie do Standard struktur>wlsd>Deployments im Navigationsbereich. Wählen Sie Bereitstellungen aus.
Wählen Sie "Sperren und Bearbeiten>">"Datei hochladen" aus.> Wählen Sie die Datei weblogic-café.war aus, die Sie zuvor vorbereitet haben.
Wählen Sie Weiter>Weiter>Weiter aus. Wählen Sie cluster1 die 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 "Steuerelement ", und wählen Sie weblogic-cafe aus der Bereitstellungstabelle aus. Wählen Sie "Start " mit der Option " Alle Anforderungen>warten" aus. Warten Sie eine Weile, und aktualisieren Sie die Seite, bis Sie sehen, dass der Status der Bereitstellung weblogic-cafe aktiv ist. Wechseln Sie zur Registerkarte "Überwachung", und stellen Sie sicher, dass der Kontextstamm der bereitgestellten Anwendung /weblogic-café ist. 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-Verwaltungskonsole, aber für den sekundären Cluster in der Region West US.

Aktualisieren des Front-End-Hosts

Führen Sie die folgenden Schritte aus, um Ihre WLS-Cluster über den Azure Traffic Manager zu sensibilieren. Da 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 vom primären Cluster.

Stellen Sie sicher, dass Sie bei der WebLogic Server-Verwaltungskonsole angemeldet sind.
Navigieren Sie im Navigationsbereich zu "Do Standard struktur>wlsd>Environment>Clusters". Wählen Sie "Cluster" aus.
Wählen Sie cluster1 aus der Clustertabelle aus.
Wählen Sie "SPERREN" und "HTTP bearbeiten" aus>. Entfernen Sie den aktuellen Wert für Frontend-Host, und geben Sie den DNS-Namen des Traffic Manager-Profils ein, das Sie zuvor geschrieben haben, ohne die führende http:// , z . B. tmprofile-ejb120623.trafficmanager.net. Wählen Sie "Änderungen speichern>" aus.

Wiederholen Sie die gleichen Schritte in der WebLogic Server-Verwaltungskonsole, aber für den sekundären Cluster in der Region West US.

Konfigurieren des Transaktionsprotokollspeichers

Konfigurieren Sie als Nächstes den TRANSACTION-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 Ost" aus:

Stellen Sie sicher, dass Sie bei der WebLogic Server-Verwaltungskonsole angemeldet sind.
Navigieren Sie im Navigationsbereich zu "Do Standard Struktur>wlsd>Environment>Servers". Wählen Sie Server.
Sie sollten Server msp1, msp2und msp3 in der Servertabelle aufgeführt werden.
Wählen Sie msp1>"Dienste>sperren und bearbeiten" aus. Wählen Sie unter "Transaktionsprotokollspeicher" DIE Option "STORES" aus.
Wählen Sie für "Datenquelle eingeben>" die Option jdbc/WebLogicCafeDBaus.
Vergewissern Sie sich, dass der Wert für präfixname TLOG_msp1_ ist, bei dem es sich um den Standardwert handelt. Wenn der Wert anders ist, ändern Sie ihn in TLOG_msp1_.
Wählen Sie Speichern.
Wählen Sie Servermsp2> aus, und wiederholen Sie dieselben Schritte, mit der Ausnahme, dass der Standardwert für präfixname TLOG_msp2_ ist.
Wählen Sie "Server>msp3" aus, und wiederholen Sie dieselben Schritte, mit der Ausnahme, dass der Standardwert für den Präfixnamen TLOG_msp3_ ist.
Wählen Sie " Änderungen aktivieren" aus.

Wiederholen Sie die gleichen Schritte in der WebLogic Server-Verwaltungskonsole, aber für den sekundären Cluster in der Region West US.

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-Verwaltungskonsole angemeldet sind.
Navigieren Sie im Navigationsbereich zu "Do Standard Struktur>wlsd>Environment>Servers". Wählen Sie Server.
Wählen Sie die Registerkarte "Steuerelement" aus. Wählen Sie aus, msp2und klicken Sie msp1dann auf msp3. Wählen Sie "Herunterfahren" mit der Option "Nach Abschluss>der Arbeit Ja" aus. Wählen Sie das Aktualisierungssymbol aus. Warten Sie, bis der Status des Werts "Letzte Aktion" AUFGABE ABGESCHLOSSEN ist. Sie sollten sehen, dass der Statuswert für die ausgewählten Server HERUNTERFAHREN ist. Wählen Sie das Aktualisierungssymbol erneut aus, um die Statusüberwachung zu beenden.
Wählen Sie msp1, msp2, und msp3 erneut. Wählen Sie ">Start ja" aus. Wählen Sie das Aktualisierungssymbol aus. Warten Sie, bis der Status des Werts "Letzte Aktion" AUFGABE ABGESCHLOSSEN ist. Sie sollten sehen, dass der Statuswert für die ausgewählten Server AUSGEFÜHRT wird. Wählen Sie das Aktualisierungssymbol erneut aus, um die Statusüberwachung zu beenden.

Beenden der virtuellen Computer im sekundären Cluster

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

Öffnen Sie die Azure-Portal Start in einer neuen Registerkarte Ihres Browsers, und wählen Sie dann "Alle Ressourcen" aus. Geben Sie im Feld "Filter für ein beliebiges Feld" den Ressourcengruppennamen ein, in dem der sekundäre Cluster bereitgestellt wird , z. B. wls-cluster-westus-ejb120623.
Wählen Sie "Typ" aus , um den Typfilter zu öffnen. Geben Sie für "Wert" den virtuellen Computer ein. Es sollte ein Übereinstimmen eines Eintrags angezeigt werden. Wählen Sie ihn für "Wert" aus. Wählen Sie Übernehmen. Es sollten vier VMs aufgeführt sein, einschließlich adminVM, , mspVM1, mspVM2und mspVM3.
Wählen Sie diese Option aus, um die einzelnen virtuellen Computer zu öffnen. Wählen Sie "Beenden" und "Bestätigen" für jeden virtuellen Computer aus.
Wählen Sie im Azure-Portal das Symbol "Benachrichtigungen" aus, um den Benachrichtigungsbereich zu öffnen.
Überwachen Sie das Ereignis "Beenden des virtuellen Computers" für jeden virtuellen Computer, bis der Wert erfolgreich beendet 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 Datenverkehrs-Managers überwachen. Aktualisieren Sie die Seite, bis Sie sehen, dass der Endpunkt herabgestuft ist und der Endpunkt myPrimaryEndpoint online ist.myFailoverEndpoint

Hinweis

Eine produktionsfähige HA/DR-Lösung würde wahrscheinlich eine niedrigere RTO erreichen, indem die virtuellen Computer ausgeführt werden, aber nur die WLS-Software auf den virtuellen Computern beendet 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-café der bereitgestellten App anfügen , http://tmprofile-ejb120623.trafficmanager.net/weblogic-cafez. B. . Erstellen Sie einen neuen Kaffee mit Name und Preis , z. B. Kaffee 1 mit 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, beheben Sie das Problem, bevor Sie fortfahren.

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

Testen des Failovers von primär auf sekundär

Zum Testen des Failovers schlägt der primäre Datenbankserver und der Cluster manuell auf den sekundären Datenbankserver und Cluster fehl, und führen Sie dann einen Failover durch, indem Sie die Azure-Portal in diesem Abschnitt verwenden.

Failover auf 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 "VMs beenden" im sekundären Clusterabschnitt aus, ändern Sie jedoch die Zielressourcengruppe in Ihren primären WLS-Cluster, um alle virtuellen Computer in diesem Cluster zu beenden.
Wechseln Sie zur Browserregisterkarte Ihres Datenverkehrs-Managers, aktualisieren Sie die Seite, bis Sie sehen, dass der Statuswert des Endpunkts myPrimaryEndpoint beeinträchtigt wird.
Wechseln Sie zur Browserregisterkarte der Beispiel-App, und aktualisieren Sie die Seite. Es sollte 504 Gatewaytimeout oder 502 Ungültiges Gateway angezeigt werden, da auf keine Endpunkte zugegriffen werden kann.

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

Wechseln Sie zur Registerkarte "Browser" Ihrer Azure SQL-Datenbank Failovergruppe.
Wählen Sie "Failover>Ja" aus.
Warten Sie, bis sie 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 den virtuellen Computer adminVMaus. Wählen Sie Start aus.
Überwachen Sie das Ereignis "Virtuelle Maschine startenadminVM" im Bereich "Benachrichtigungen", und warten Sie, bis der Wert zum virtuellen Computer gestartet wird.
Wechseln Sie zur Browserregisterkarte der WebLogic Server-Verwaltungskonsole für den sekundären Cluster, und aktualisieren Sie dann die Seite, bis die Willkommensseite für die 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 virtuellen Computer mspVM1mspVM2und die einzelnen mspVM3Computer aus, um sie zu öffnen, und wählen Sie dann "Start" aus.
Überwachen Sie für die virtuellen Computer mspVM1mspVM2und das mspVM3Ereignis "Virtuelle Computer starten" im Bereich "Benachrichtigungen" das Ereignis "Starten", und warten Sie, bis die Werte zum virtuellen Computer "Gestartet" werden.

Führen Sie abschließend die folgenden Schritte aus, um die Beispiel-App zu überprüfen, nachdem sich der Endpunkt myFailoverEndpoint im Onlinestatus befindet:

Wechseln Sie zur Browserregisterkarte Ihres Datenverkehrs-Managers, und aktualisieren Sie dann die Seite, bis Sie sehen, dass der Monitorstatuswert des Endpunkts myFailoverEndpoint in den Onlinestatus wechselt.
Wechseln Sie zur Browserregisterkarte der Beispiel-App, und aktualisieren Sie die Seite. Sie sollten die gleichen Daten sehen, die in der Anwendungsdatentabelle gespeichert sind, und die Sitzungstabelle, die auf der Benutzeroberfläche angezeigt wird, wie im folgenden Screenshot gezeigt:

Wenn Sie dieses Verhalten nicht beobachten, liegt es möglicherweise daran, dass der Datenverkehrs-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 eine Weile, und aktualisieren Sie die Seite erneut.

Hinweis

Eine produktionsfähige HA/DR-Lösung würde das kontinuierliche Kopieren der WLS-Konfiguration von der primären in die sekundären Cluster in einem regelmäßigen Zeitplan 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 zu Datenverkehrs-Manager-Metriken " mit Metriken und Warnungen und verwenden sie eine Warnung, um ein Azure Automation-Runbook auszulösen.

Fehler beim Zurücksetzen auf den primären Standort

Führen Sie die gleichen Schritte im Failover für den sekundären Standortabschnitt aus, um den primären Standort einschließlich Datenbankserver und Cluster nicht zu verwenden, mit Ausnahme der folgenden Unterschiede:

Fahren Sie zunächst die virtuellen Computer im sekundären Cluster herunter. Sie sollten sehen, dass der Endpunkt myFailoverEndpoint beeinträchtigt wird.
Als Nächstes failovern Sie die Azure SQL-Datenbank vom sekundären Server auf den primären Server.
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 weiterhin verwenden werden, führen Sie die folgenden Schritte aus, um die Ressourcengruppen zu löschen, um die in diesem Lernprogramm verwendeten Ressourcen zu sauber:

Geben Sie den Ressourcengruppennamen von Azure SQL-Datenbank Servern (zmyResourceGroup. B. ) in das Suchfeld oben im Azure-Portal ein, und wählen Sie die übereinstimmene Ressourcengruppe aus den Suchergebnissen aus.
Wählen Sie die Option Ressourcengruppe löschen.
Geben Sie im Namen der Ressourcengruppe den Namen der Ressourcengruppe ein, um den Löschvorgang zu bestätigen.
Klicken Sie auf Löschen.
Wiederholen Sie die Schritte 1 bis 4 für die Ressourcengruppe des Datenverkehrs-Managers , myResourceGroupTM1z. B. .
Wiederholen Sie die Schritte 1 bis 4 für die Ressourcengruppe des primären WLS-Clusters , wls-cluster-eastus-ejb120623z. B. .
Wiederholen Sie die Schritte 1 bis 4 für die Ressourcengruppe des sekundären WLS-Clusters , wls-cluster-westus-ejb120623z. B. .

Nächste Schritte

In diesem Lernprogramm richten Sie eine HA/DR-Lösung ein, die aus einer aktiv-passiven Anwendungsinfrastrukturebene mit einer aktiv-passiven Datenbankebene besteht und in der beide Ebenen zwei geografisch unterschiedliche Standorte umfassen. Am ersten Standort sind sowohl die Anwendungsinfrastrukturebene als auch die Datenbankebene aktiv. Am zweiten Standort wird die sekundäre Do Standard heruntergefahren, und die sekundäre Datenbank befindet sich im Standbymodus.

Weitere Optionen zum Erstellen von HA/DR-Lösungen und zum Ausführen von WLS in Azure erhalten Sie unter den folgenden Referenzen:

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 auf AKS