Tutorial: Migrieren von WebSphere Application 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 WebSphere Application Server auf Azure Virtual Machines (VMs). Die Lösung veranschaulicht, wie Sie eine niedrige Recovery Time Objective (RTO) und Recovery Point Objective (RPO) mithilfe einer einfachen datenbankgesteuerten Jakarta EE-Anwendung erreichen, die auf WebSphere Application Server 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 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 den primären WebSphere-Cluster auf Azure-VMs ein.
Richten Sie die Notfallwiederherstellung für den Cluster mit Azure Site Recovery ein.
Richten Sie einen Azure Traffic Manager ein.
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. Die primäre Region verfügt über eine vollständige Bereitstellung des WebSphere-Clusters. Nachdem die primäre Region durch Azure Site Recovery geschützt ist, können Sie die sekundäre Region während des Failovers wiederherstellen. Dies führt dazu, dass die primäre Region aktiv Netzwerkanforderungen der Benutzer bearbeitet, während die sekundäre Region passiv ist und nur dann zum Empfang von Datenverkehr aktiviert wird, wenn in der primären Region eine Dienstunterbrechung auftritt.

Azure Traffic Manager erkennt den Zustand der im IBM HTTP Server bereitgestellten App, um das bedingte Routing zu implementieren. Die RTO des Geo-Failovers der Anwendungsebene hängt von der Zeit ab, die zum Herunterfahren des primären Clusters, zum Wiederherstellen des sekundären Clusters, zum Starten von VMs und zum Ausführen des sekundären WebSphere-Clusters benötigt wird. Die RPO hängt von der Replikationsrichtlinie von Azure Site Recovery und Azure SQL-Datenbank ab. Diese Abhängigkeit besteht, da die Clusterdaten im lokalen Speicher der VMs gespeichert und repliziert werden und die Anwendungsdaten in der Failovergruppe der Azure SQL-Datenbank persistent gespeichert und repliziert werden.

Das vorangehende Diagramm zeigt die primäre Region und die sekundäre Region als zwei Regionen, die die HA/DR-Architektur umfassen. Diese Regionen müssen Azure-Regionspaare sein. Weitere Informationen zu Regionspaaren finden Sie unter Regionsübergreifende Replikation in Azure. Der Artikel verwendet USA, Osten und USA, Westen als die zwei Regionen, aber es kann sich um beliebige Regionspaare handeln, die für Ihr Szenario sinnvoll sind. Eine Liste der Regionspaare finden Sie im Abschnitt Azure-Regionspaare von Regionsübergreifende Replikation in Azure.

Die Datenbankebene besteht aus einer Azure SQL-Datenbank-Failovergruppe mit einem primären Server und einem sekundären Server. Der Lese-/Schreiblistenerendpunkt verweist immer auf den primären Server und ist in den einzelnen Regionen mit dem WebSphere-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 zur Geofailover-RPO und -RTO der Azure SQL-Datenbank finden Sie unter Übersicht über die Geschäftskontinuität mit Azure SQL-Datenbank.

Dieses Tutorial wurde mit Azure Site Recovery und dem Azure SQL-Datenbankdienst geschrieben, da das Tutorial auf den HA-Funktionen dieser Dienste basiert. Andere Datenbankoptionen sind möglich, aber Sie müssen die HA-Features der von Ihnen ausgewählten Datenbank berücksichtigen.

Voraussetzungen

Ein Azure-Abonnement. Wenn Sie kein Azure-Abonnement besitzen, erstellen Sie ein kostenloses Konto, bevor Sie beginnen.
Stellen Sie sicher, dass Sie über die Contributor-Rolle im Abonnement 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 WebSphere-Clustern und Ihrer App. In einem späteren Abschnitt konfigurieren Sie WebSphere so, dass die Sitzungsdaten in dieser Datenbank gespeichert werden. In dieser Übung wird auf Erstellen einer Tabelle für die Sitzungspersistenz verwiesen.

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. Geben Sie einen eindeutigen Servernamen ein, z. B. sqlserverprimary-mjg022624.
  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 die Inhalte im Editor, und geben Sie die folgende Abfrage ein. Wählen Sie dann erneut Ausführen aus:
```
CREATE TABLE sessions (
   ID VARCHAR(128) NOT NULL,
   PROPID VARCHAR(128) NOT NULL,
   APPNAME VARCHAR(128) NOT NULL,
   LISTENERCNT SMALLINT,
   LASTACCESS BIGINT,
   CREATIONTIME BIGINT,
   MAXINACTIVETIME INT,
   USERNAME VARCHAR(256),
   SMALL VARBINARY(MAX),
   MEDIUM VARCHAR(MAX),
   LARGE VARBINARY(MAX)
);
```
  Nach einer erfolgreichen Ausführung sollte die Meldung Die Abfrage war erfolgreich: Betroffene Zeilen: 0 angezeigt werden.
  
  Die Datenbanktabelle sessions wird zum Speichern von Sitzungsdaten für Ihre WebSphere-App verwendet. Die WebSphere-Clusterdaten, einschließlich der Transaktionsprotokolle, werden im lokalen Speicher der VMs gespeichert, auf denen der Cluster bereitgestellt wird.

Erstellen Sie dann eine Azure SQL Database-Failovergruppe, indem Sie die Azure-Portal Schritte unter Konfigurieren einer Failovergruppe für Azure SQL Database 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:

Verwenden Sie im Abschnitt Erstellen einer Failovergruppe die folgenden Schritte:
1. Geben Sie in Schritt 5 zum Erstellen der Failovergruppe den eindeutigen Namen der Failovergruppe ein, und speichern Sie ihn, z. B. failovergroup-mjg022624.
2. Wählen Sie in Schritt 5 zum Konfigurieren des Servers die Option zum Erstellen eines neuen sekundären Servers aus, und führen Sie dann die folgenden Schritte aus:
  1. Geben Sie einen eindeutigen Servernamen ein, z. B. sqlserversecondary-mjg022624.
  2. Geben Sie denselben Serveradministrator und dasselbe Kennwort wie für Ihren primären Server ein.
  3. Wählen Sie unter Standort die Option (US) USA, Westen aus.
  4. Achten Sie darauf, dass Azure-Diensten Zugriff auf den Server erlauben aktiviert ist.
3. 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 Testen eines geplanten Failovers abgeschlossen haben, lassen Sie die Failovergruppenseite geöffnet, und verwenden Sie sie später für den Failovertest der WebSphere-Cluster.

Einrichten des primären WebSphere-Clusters auf Azure VMs

In diesem Abschnitt erstellen Sie die primären WebSphere-Cluster auf Azure-VMs mithilfe des Angebots IBM WebSphere Application Server Cluster auf Azure VMs . Der sekundäre Cluster wird während des Failovers mithilfe von Azure Site Recovery später aus dem primären Cluster wiederhergestellt.

Bereitstellen des primären WebSphere-Clusters

Öffnen Sie zuerst das Angebot IBM WebSphere Application 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. was-cluster-eastus-mjg022624.
Wählen Sie unter Instanzdetails für Region die Option USA, Osten aus.
Wählen Sie für Mit vorhandener WebSphere-Berechtigung oder mit Evaluierungslizenz bereitstellen? die Option Evaluierung für dieses Tutorial aus. Sie können auch Berechtigt auswählen, und Ihre IBMid-Anmeldeinformationen angeben.
Wählen Sie Ich habe die IBM Lizenzvereinbarung gelesen und akzeptiere sie. aus.
Behalten Sie die Standardwerte für andere Felder bei.
Wählen Sie Weiter aus, um zum Bereich Clusterkonfiguration zu navigieren.

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

Geben Sie für Kennwort für VM-Administrator ein Kennwort ein.
Geben Sie für Kennwort für WebSphere-Administrator ein Kennwort 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 Load Balancer zu navigieren.

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

Geben Sie für Kennwort für VM-Administrator ein Kennwort ein.
Geben Sie für Kennwort für IBM HTTP Server-Administrator ein Kennwort ein.
Behalten Sie die Standardwerte für andere Felder bei.
Wählen Sie Weiter aus, um zum Bereich Netzwerk zu wechseln.

Ihnen sollten alle Felder mit den Standardwerten im Bereich Netzwerk angezeigt werden. 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 aus.
Geben Sie für JNDI Name den Namen jdbc/WebSphereCafeDB ein.
Ersetzen Sie für Datenquellen-Verbindungszeichenfolge (jdbc:sqlserver://<host>:<port>;database=<database>) die Platzhalter durch die Werte, die Sie im vorherigen Abschnitt für die Failovergruppe für die Azure SQL-Datenbank gespeichert haben, z. B. jdbc:sqlserver://failovergroup-mjg022624.database.windows.net:1433;database=mySampleDatabase.
Geben Sie für Datenbankbenutzername den Serveradministrator-Anmeldenamen und den Failovergruppennamen ein, die Sie im vorherigen Abschnitt gespeichert haben, z. B. azureuser@failovergroup-mjg022624.

Hinweis

Achten Sie besonders darauf, den richtigen Hostnamen und Benutzernamen des Datenbankservers für die Failovergruppe zu verwenden und nicht den Serverhostnamen und Benutzernamen der primären oder Sicherungsdatenbank. Indem Sie die Werte aus der Failovergruppe verwenden, weisen Sie WebSphere praktisch an, mit der Failovergruppe zu kommunizieren. Für WebSphere handelt es sich jedoch lediglich um eine normale Datenbankverbindung.
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 25 Minuten dauern. Danach sollte auf der Bereitstellungsseite der Text Ihre Bereitstellung wurde abgeschlossen. angezeigt werden.

Überprüfen der Bereitstellung des Clusters

Sie haben einen IBM HTTP Server (IHS) und einen WebSphere Deployment Manager (Dmgr) im Cluster bereitgestellt. Der IHS fungiert als Load Balancer für alle Anwendungsserver im Cluster. Dmgr stellt eine Webkonsole für die Clusterkonfiguration bereit.

Überprüfen Sie mit den folgenden Schritten, ob die IHS- und Dmgr-Konsolen funktionieren, bevor Sie mit dem nächsten Schritt fortfahren:

Kehren Sie zur Seite Bereitstellung zurück, und wählen Sie dann Ausgaben aus.
Kopieren Sie den Wert der Eigenschaft ihsConsole. Öffnen Sie diese URL auf einer neuen Browserregisterkarte. Beachten Sie, dass wir in diesem Beispiel nicht https für den IHS verwenden. Eine Willkommensseite des IHS sollte ohne Fehlermeldung angezeigt werden. Wenn dies nicht der Fall ist, müssen Sie das Problem beheben, bevor Sie fortfahren. Lassen Sie die Konsole geöffnet, und verwenden Sie sie, um die App-Bereitstellung des Clusters später zu überprüfen.
Kopieren und speichern Sie den Wert der Eigenschaft adminSecuredConsole. Öffnen Sie sie auf einer neuen Browserregisterkarte. Akzeptieren Sie die Browserwarnung für das selbstsignierte TLS-Zertifikat. Gehen Sie nicht mit einem selbstsignierten TLS-Zertifikat in die Produktion.

Die Anmeldeseite von WebSphere Integrated Solutions Console sollte Ihnen angezeigt werden. Melden Sie sich bei der Konsole mit dem Benutzernamen und Kennwort für den WebSphere-Administrator an, den Sie zuvor gespeichert haben. Wenn Sie sich nicht anmelden können, müssen Sie das Problem beheben, bevor Sie fortfahren. Lassen Sie die Konsole geöffnet, und verwenden Sie sie später für die weitere Konfiguration des WebSphere-Clusters.

Führen Sie die folgenden Schritte aus, um den Namen der öffentlichen IP-Adresse des IHS abzurufen. Sie verwenden sie später, wenn Sie den Azure Traffic Manager einrichten.

Öffnen Sie die Ressourcengruppe, in der Ihr Cluster bereitgestellt wird. Wählen Sie Übersicht aus, um zurück zum Bereich „Übersicht“ der Bereitstellungsseite zurückzukehren. Wählen Sie dann Zu Ressourcengruppe wechseln aus.
Suchen Sie in der Tabelle der Ressourcen die Spalte Typ. Wählen Sie sie aus, um nach Ressourcentyp zu sortieren.
Suchen Sie die Ressource Öffentliche IP-Adresse mit dem Präfix ihs. Kopieren Sie sie dann, und speichern Sie ihren Namen.

Konfigurieren des Clusters

Führen Sie zunächst die folgenden Schritte aus, um die Option Änderungen mit Knoten synchronisieren zu aktivieren, damit jede Konfiguration automatisch mit allen Anwendungsservern synchronisiert werden kann:

Wechseln Sie zurück zur WebSphere Integrated Solutions Console, und melden Sie sich erneut an, wenn Sie abgemeldet sind.
Wählen Sie im Navigationsbereich Systemadministration>Konsoleneinstellungen aus.
Wählen Sie im Bereich Konsoleneinstellungen die Option Änderungen mit Knoten synchronisieren und dann Übernehmen aus. Die Nachricht Ihre Einstellungen wurden geändert. sollte angezeigt werden.

Führen Sie dann die folgenden Schritte aus, um die verteilten Sitzungen der Datenbank für alle Anwendungsserver zu konfigurieren:

Wählen Sie im Navigationsbereich Server>Servertypen>WebSphere-Anwendungsserver aus.
Im Bereich Anwendungsserver sollten drei Anwendungsserver aufgeführt sein. Verwenden Sie für jeden Anwendungsserver die folgenden Anweisungen zum Konfigurieren der verteilten Datenbanksitzungen:
1. Wählen Sie in der Tabelle unter dem Text Sie können die folgenden Ressourcen verwalten den Hyperlink für den Anwendungsserver aus, der mit MyCluster beginnt.
2. Wählen Sie im Abschnitt Containereinstellungen die Option Sitzungsverwaltung aus.
3. Wählen Sie im Abschnitt Zusätzliche Eigenschaften die Option Verteilte Umgebungseinstellungen aus.
4. Wählen Sie für Verteilte Sitzungen die Option Datenbank (wird nur für Web-Container unterstützt.) aus.
5. Wählen Sie Datenbank aus, und verwenden Sie die folgenden Schritte:
  1. Geben Sie für Datasource JNDI-Name den Namen jdbc/WebSphereCafeDB ein.
  2. Geben Sie für Benutzer-ID den Serveradministrator-Anmeldenamen und den Failovergruppennamen ein, die Sie im vorherigen Abschnitt gespeichert haben, z. B. azureuser@failovergroup-mjg022624.
  3. Geben Sie das Azure SQL Server-Administrator-Anmeldekennwort ein, das Sie zuvor für Kennwort gespeichert haben.
  4. Geben Sie für Tabellenbereichname Sitzungen ein.
  5. Wählen Sie Mehrzeiliges Schema verwenden aus.
  6. Wählen Sie OK aus. Sie werden zurück zum Bereich Verteilte Umgebungseinstellungen geleitet.
6. Wählen Sie im Abschnitt Zusätzliche Eigenschaften die Option Benutzerdefinierte Optimierungsparameter aus.
7. Wählen Sie für Optimierungsebene die Option Niedrig (für Failover optimieren) aus.
8. Wählen Sie OK aus.
9. Wählen Sie unter Nachrichten die Option Speichern aus. Warten Sie, bis der Vorgang abgeschlossen ist.
10. Wählen Sie Anwendungsserver aus der oberen Breadcrumbleiste aus. Sie werden zurück zum Bereich Anwendungsserver geleitet.
Wählen Sie im Navigationsbereich Server>Cluster>WebSphere-Anwendungsservercluster aus.
Im Bereich WebSphere-Anwendungsservercluster sollte der Cluster MyCluster aufgeführt sein. Aktivieren Sie das Kontrollkästchen neben MyCluster.
Wählen Sie Ripple-Start aus.
Warten Sie, bis der Cluster neu gestartet wird. Sie können das Symbol Status auswählen und falls das neue Fenster nicht Gestartet anzeigt, wechseln Sie zurück zur Konsole und aktualisieren Sie die Webseite nach einiger Zeit. Wiederholen Sie den Vorgang, bis Gestartet angezeigt wird. Möglicherweise wird Teilweiser Start angezeigt, bevor der Status Gestartet erreicht wird.

Lassen Sie die Konsole geöffnet, und verwenden Sie sie später für die App-Bereitstellung.

Bereitstellen einer Beispiel-App

In diesem Abschnitt erfahren Sie, wie Sie eine CRUD Java/Jakarta EE-Beispielanwendung für einen WebSphere-Cluster für den Failovertest für die Notfallwiederherstellung bereitstellen und ausführen.

Sie haben Anwendungsserver für die Verwendung der Datenquelle jdbc/WebSphereCafeDB zum Speichern von Sitzungsdaten konfiguriert, wodurch Failover- und Lastenausgleich über einen Cluster von WebSphere-Anwendungsservern hinweg ermöglicht wird. Die Beispiel-App konfiguriert auch ein Persistenzschema, um Anwendungsdatencoffee in derselben Datenquelle jdbc/WebSphereCafeDB beizubehalten.

Verwenden Sie zunächst die folgenden Befehle, um das Beispiel herunterzuladen, zu erstellen und zu paketieren:

git clone https://github.com/Azure-Samples/websphere-cafe
cd websphere-cafe
git checkout 20240326
mvn clean package

Wenn eine Meldung darüber angezeigt wird, dass der Status Detached HEAD lautet, kann diese Nachricht problemlos ignoriert werden.

Das Paket sollte erfolgreich generiert und unter <parent-path-to-your-local-clone>/websphere-cafe/websphere-cafe-application/target/websphere-cafe.ear platziert werden. Wenn das Paket nicht angezeigt wird, müssen Sie das Problem beheben, bevor Sie fortfahren.

Führen Sie dann die folgenden Schritte aus, um die Beispiel-App im Cluster bereitzustellen:

Wechseln Sie zurück zur WebSphere Integrated Solutions Console, und melden Sie sich erneut an, wenn Sie abgemeldet sind.
Wählen Sie im Navigationsbereich Anwendungen>Anwendungstypen>WebSphere-Unternehmensanwendungen aus.
Wählen Sie im Bereich Unternehmensanwendungen die Option Installieren>Datei auswählen aus. Suchen Sie dann das Paket unter <parent-path-to-your-local-clone>/websphere-cafe/websphere-cafe-application/target/websphere-cafe.ear, und wählen Sie Öffnen aus. Wählen Sie Weiter>Weiter>Weiter aus.
Drücken Sie im Bereich Zuweisen von Modulen zu Servern die Taste Strg, und wählen Sie alle Elemente unter Cluster und Server aus. Aktivieren Sie das Kontrollkästchen neben websphere-cafe.war. Wählen Sie Übernehmen. Wählen Sie Weiter aus, bis die Schaltfläche Fertig stellen angezeigt wird.
Wählen Sie Fertig stellen>Speichern aus, und warten Sie dann auf den Abschluss. Wählen Sie OK aus.
Wählen Sie die installierte Anwendung websphere-cafe und dann Start aus. Warten Sie, bis die Meldung angezeigt wird, dass die Anwendung erfolgreich gestartet wurde. Wenn die Meldung „Erfolgreich“ nicht angezeigt wird, müssen Sie das Problem beheben, bevor Sie fortfahren.

Führen Sie nun die folgenden Schritte aus, um zu überprüfen, ob die App wie erwartet ausgeführt wird:

Wechseln Sie zurück zur IHS-Konsole. Fügen Sie den Kontextstamm /websphere-cafe/ der bereitgestellten App an die Adressleiste an, z. B. http://ihs70685e.eastus.cloudapp.azure.com/websphere-cafe/, und drücken Sie dann die Eingabetaste. Die Willkommensseite der Beispiel-App sollte angezeigt werden.
Erstellen Sie einen neuen Kaffee mit einem Namen und einem Preis, z. B. Kaffee 1 mit dem Preis $10, der sowohl in der Anwendungsdatentabelle als auch in der Sitzungstabelle der Datenbank beibehalten wird. 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.

Einrichten der Notfallwiederherstellung für den Cluster mit Azure Site Recovery

In diesem Abschnitt richten Sie die Notfallwiederherstellung für Azure-VMs im primären Cluster mithilfe von Azure Site Recovery ein, indem Sie die Schritte im Tutorial: Einrichten der Notfallwiederherstellung für Azure-VMs befolgen. Sie benötigen nur die folgenden Abschnitte: Erstellen eines Recovery Services-Tresor und Aktivieren der Replikation. Beachten Sie beim Durcharbeiten des Artikels die folgenden Schritte, und kehren Sie dann zu diesem Artikel zurück, nachdem der primäre Cluster geschützt wurde:

Führen Sie im Abschnitt Erstellen eines Recovery Services-Tresors die folgenden Schritte aus:
1. Erstellen Sie in Schritt 5 für Ressourcengruppe eine neue Ressourcengruppe mit einem eindeutigen Namen in Ihrem Abonnement, z. B. was-cluster-westus-mjg022624.
2. Geben Sie in Schritt 6 für Tresorname einen Tresornamen ein, z. B. recovery-service-vault-westus-mjg022624.
3. Wählen Sie in Schritt 7 für Region die Option USA, Westen aus.
4. Bevor Sie in Schritt 8 Überprüfen + erstellen auswählen, wählen Sie Weiter: Redundanz aus. Wählen Sie im Bereich Redundanz die Option Georedundant für Redundanz für Sicherungsspeicher und Aktivieren für Regionsübergreifende Wiederherstellung aus.
  
  Hinweis
  
  Wählen Sie unbedingt Georedundant für Redundanz für Sicherungsspeicher und Aktivieren für Regionsübergreifende Wiederherstellung im Bereich Redundanz aus. Andernfalls kann der Speicher des primären Clusters nicht in die sekundäre Region repliziert werden.
5. Aktivieren Sie „Site Recovery“, indem Sie die Schritte im Abschnitt Site Recovery aktivieren ausführen.
Wenn Sie den Abschnitt Aktivieren der Replikation erreichen, verwenden Sie die folgenden Schritte:
1. Führen Sie im Abschnitt Auswählen der Quelleinstellungen die folgenden Schritte aus:
  1. Wählen Sie als Region die Option USA, Osten aus.
  2. Wählen Sie für Ressourcengruppe die Ressource aus, in der der primäre Cluster bereitgestellt wird, z. B. was-cluster-eastus-mjg022624.
    
    Hinweis
    
    Wenn die gewünschte Ressourcengruppe nicht aufgeführt ist, können Sie zuerst „USA, Westen“ für die Region auswählen und dann zurück zu „USA, Osten“ wechseln.
  3. Behalten Sie die Standardwerte für andere Felder bei. Wählen Sie Weiter aus.
2. Wählen Sie im Abschnitt Auswählen der VMs für Virtuelle Computer alle fünf aufgeführten VMs und dann Weiter aus.
3. Führen Sie im Abschnitt Überprüfen der Replikationseinstellungen die folgenden Schritte aus:
  1. Wählen Sie unter Zielstandort die Option USA, Westen aus.
  2. Wählen Sie für Zielressourcengruppe die Ressourcengruppe aus, in der der Dienstwiederherstellungstresor bereitgestellt wird, z. B. was-cluster-westus-mjg022624.
  3. Notieren Sie sich das neue virtuelle Failover-Netzwerk und das Failover-Subnetz, die denen in der primären Region zugeordnet sind.
  4. Behalten Sie die Standardwerte für andere Felder bei.
  5. Wählen Sie Weiter aus.
4. Führen Sie im Abschnitt Verwalten die folgenden Schritte aus:
  1. Verwenden Sie für Aufbewahrungsrichtlinie die Standardrichtlinie 24-Stunden-Aufbewahrungsrichtlinie. Sie können auch eine neue Richtlinie für Ihr Unternehmen erstellen.
  2. Behalten Sie die Standardwerte für andere Felder bei.
  3. Wählen Sie Weiter aus.
5. Führen Sie im Abschnitt Überprüfen die folgenden Schritte aus:
  1. Beachten Sie nach dem Auswählen von Replikation aktivieren die Nachricht Azure-Ressourcen werden erstellt. Dieses Blatt nicht schließen., die unten auf der Seite angezeigt wird. Führen Sie nichts aus, und warten Sie, bis der Bereich automatisch geschlossen wird. Sie werden zur Seite Site Recovery weitergeleitet.
  2. Klicken Sie unter Geschützte Elemente auf Replizierte Elemente. Zunächst sind keine Elemente aufgelistet, da die Replikation noch ausgeführt wird. Es dauert ungefähr eine Stunde, bis die Replikation abgeschlossen ist. Aktualisieren Sie die Seite regelmäßig, bis Sie sehen, dass sich alle VMs im Zustand Geschützt befinden, wie im folgenden Beispielscreenshot dargestellt:

Erstellen Sie als Nächstes einen Wiederherstellungsplan, der alle replizierten Elemente einschließt, sodass ein gemeinsames Failover möglich ist. Verwenden Sie die Anweisungen unter Erstellen eines Wiederherstellungsplans mit den folgenden Anpassungen:

Geben Sie in Schritt 2 einen Namen für den Plan ein, z. B. recovery-plan-mjg022624.
Wählen Sie in Schritt 3 für Quelle die Option USA, Osten und für Ziel die Option USA, Westen aus.
Wählen Sie in Schritt 4 für Elemente auswählen alle fünf geschützten VMs für dieses Tutorial aus.

Als Nächstes erstellen Sie einen Wiederherstellungsplan. Lassen Sie die Seite geöffnet, damit Sie sie später für den Failovertest verwenden können.

Weitere Netzwerkkonfiguration für die sekundäre Region

Außerdem benötigen Sie eine weitere Netzwerkkonfiguration, um den externen Zugriff auf die sekundäre Region in einem Failoverereignis zu aktivieren und zu schützen. Verwenden Sie die folgenden Schritte für diese Konfiguration:

Erstellen Sie eine öffentliche IP-Adresse für Dmgr in der sekundären Region, indem Sie die Anweisungen in Schnellstart: Erstellen einer öffentlichen IP mithilfe des Azure-Portals mit den folgenden Angaben befolgen:
1. Wählen Sie für Ressourcengruppe die Ressourcengruppe aus, in der der Dienstwiederherstellungstresor bereitgestellt wird, z. B. was-cluster-westus-mjg022624.
2. Wählen Sie unter Region die Option USA, Westen aus.
3. Geben Sie für Name einen Wert ein, z. B. dmgr-public-ip-westus-mjg022624.
4. Geben Sie für DNS-Namensbezeichnung einen eindeutigen Wert ein, z. B. dmgrmjg022624.
Erstellen Sie eine weitere öffentliche IP-Adresse für IHS in der sekundären Region, indem Sie denselben Leitfaden mit den folgenden Anpassungen befolgen:
1. Wählen Sie für Ressourcengruppe die Ressourcengruppe aus, in der der Dienstwiederherstellungstresor bereitgestellt wird, z. B. was-cluster-westus-mjg022624.
2. Wählen Sie unter Region die Option USA, Westen aus.
3. Geben Sie für Name einen Wert ein, z. B. ihs-public-ip-westus-mjg022624. Schreiben Sie es auf.
4. Geben Sie für DNS-Namensbezeichnung einen eindeutigen Wert ein, z. B. ihsmjg022624.
Erstellen Sie eine Netzwerksicherheitsgruppe in der sekundären Region, indem Sie die Anweisungen im Abschnitt Erstellen einer Netzwerksicherheitsgruppe von Erstellen, Ändern oder Löschen einer Netzwerksicherheitsgruppe mit den folgenden Anpassungen befolgen:
1. Wählen Sie für Ressourcengruppe die Ressourcengruppe aus, in der der Dienstwiederherstellungstresor bereitgestellt wird, z. B. was-cluster-westus-mjg022624.
2. Geben Sie für Name einen Wert ein, z. B. nsg-westus-mjg022624.
3. Wählen Sie unter Region die Option USA, Westen aus.
Erstellen Sie eine eingehende Sicherheitsregel für die Netzwerksicherheitsgruppe, indem Sie die Anweisungen im Abschnitt Erstellen einer Sicherheitsregel desselben Artikels mit den folgenden Anpassungen befolgen:
1. Wählen Sie in Schritt 2 die von Ihnen erstellte Netzwerksicherheitsgruppe aus, z. B. nsg-westus-mjg022624.
2. Wählen Sie in Schritt 3 Eingangssicherheitsregeln aus.
3. Passen Sie in Schritt 4 die folgenden Einstellungen an:
  1. Geben Sie unter Zielportbereiche den Wert 9060,9080,9043,9443,80 ein.
  2. Wählen Sie für Protokoll die Option TCP aus.
  3. Geben Sie für Name ALLOW_HTTP_ACCESS ein.
Ordnen Sie die Netzwerksicherheitsgruppe einem Subnetz zu, indem Sie die Anweisungen im Abschnitt Zuordnen einer Netzwerksicherheitsgruppe zu einer Netzwerkschnittstelle oder einem Subnetz bzw. deren Trennung davon desselben Artikels mit den folgenden Anpassungen befolgen:
1. Wählen Sie in Schritt 2 die von Ihnen erstellte Netzwerksicherheitsgruppe aus, z. B. nsg-westus-mjg022624.
2. Wählen Sie Zuordnen aus, um die Netzwerksicherheitsgruppe dem Failover-Subnetz zuzuordnen, das Sie zuvor notiert haben.

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 die öffentliche IP-Adresse des IHS in der primären Region. Der sekundäre Endpunkt verweist auf die öffentliche IP-Adresse des IHS in der sekundären Region.

Erstellen Sie anhand der Anleitungen in Schnellstart: Erstellen eines Traffic Manager-Profils mithilfe des Microsoft Azure-Portals ein Azure Traffic Manager-Profil. Sie benötigen nur die folgenden Abschnitte: Erstellen eines Traffic Manager-Profils und Hinzufügen von Traffic Manager-Endpunkten. Sie müssen die Abschnitte überspringen, in denen Sie zum Erstellen von App Service-Ressourcen aufgefordert werden. 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.

Verwenden Sie im Abschnitt Erstellen eines Traffic Manager-Profils in Schritt 2 für Erstellen eines Traffic Manager-Profils die folgenden Schritte:
1. Speichern Sie den eindeutigen Traffic Manager-Profilnamen für Name, z. B. tmprofile-mjg022624.
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. Nachdem Sie das Traffic Manager-Profil in Schritt 2 geöffnet haben, führen Sie auf der Seite Konfiguration die folgenden Schritte aus:
  1. Geben Sie für DNS time to live (TTL) die Zahl 10 ein.
  2. Geben Sie unter Endpunktüberwachungseinstellungen für Pfad /websphere-cafe/ ein. Dies ist der Kontextstamm der bereitgestellten Beispiel-App.
  3. Verwenden Sie unter Einstellungen für schnelles Endpunktfailover die folgenden Werte:
    - Wählen Sie für Interne Tests die Zahl 10 aus.
    - Geben Sie für Tolerierte Anzahl von Fehlern die Zahl 3 ein.
    - Verwenden Sie für Testtimeout die Zahl 5.
  4. 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 den Namen der öffentlichen IP-Adresse von IHS in der Region „USA, Osten“ ein, die 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 den Namen der öffentlichen IP-Adresse von IHS in der Region „USA, Westen“ ein, die 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 Überwachungsstatus für den Endpunkt myPrimaryEndpoint Online und der Überwachungsstatus für den Endpunkt myFailoverEndpoint Herabgestuft ist.

Führen Sie als Nächstes die folgenden Schritte aus, um zu überprüfen, ob auf die im primären WebShere-Cluster bereitgestellte Beispiel-App über das Traffic Manager-Profil zugegriffen werden kann:

Wählen Sie Übersicht für das Traffic Manager-Profil aus, das Sie erstellt haben.
Wählen Sie den DNS-Namen (Domain Name System) des Traffic Manager-Profils aus, kopieren Sie ihn und hängen Sie ihn an /websphere-cafe/ an, z. B. http://tmprofile-mjg022624.trafficmanager.net/websphere-cafe/.
Öffnen Sie die URL in einer neuen Registerkarte des Browsers. Ihnen sollte der zuvor erstellte Kaffee auf der Seite angezeigt werden.
Erstellen Sie einen anderen Kaffee mit einem anderen Namen und Preis, z. B. Kaffee 2 mit dem Preis 20, der sowohl in der Anwendungsdatentabelle als auch in der Sitzungstabelle der Datenbank beibehalten wird. 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 Konsole geöffnet, und verwenden Sie sie später für den Failovertest.

Nun richten Sie das Traffic Manager-Profil ein. Lassen Sie die Seite geöffnet, und verwenden Sie sie, um die Änderung des Endpunktstatus in einem Failoverereignis später zu überwachen.

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

Zum Testen des Failovers führen Sie ein manuelles Failover Ihres Azure SQL-Datenbank-Servers und -clusters durch, und führen Sie dann einen Failover mit dem Azure-Portal durch.

Failover an den sekundären Standort

Verwenden Sie zunächst die folgenden Schritte, um ein Failover der Azure SQL-Datenbank vom primären Server zum sekundären Server durchzuführen:

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

Führen Sie als Nächstes die folgenden Schritte aus, um ein Failover des WebSphere-Clusters mit dem Wiederherstellungsplan durchzuführen:

Geben Sie im Suchfeld oben im Azure-Portal Recovery Services-Tresore ein, und wählen Sie dann Recovery Services-Tresore in den Suchergebnissen aus.
Wählen Sie den Namen Ihres Recovery Services-Tresors aus, z. B. recovery-service-vault-westus-mjg022624.
Klicken Sie unter Verwalten auf Wiederherstellungspläne (Site Recovery). Wählen Sie den Wiederherstellungsplan aus, den Sie erstellt haben, z. B. recovery-plan-mjg022624.
Wählen Sie Failover aus. Wählen Sie Ich kenne die Risiken. Testfailover überspringen. aus. Übernehmen Sie die Standardwerte für die anderen Felder, und wählen Sie OK aus.

Hinweis

Sie können optional Testfailover und Testfailover bereinigen ausführen, um sicherzustellen, dass alles wie erwartet funktioniert, bevor Sie Failover testen. Weitere Informationen finden Sie unter Tutorial: Ausführen eines Notfallwiederherstellungsverfahrens für Azure-VMs. In diesem Tutorial wird das Failover direkt getestet, um die Übung zu vereinfachen.
Überwachen Sie das Failover in Benachrichtigungen, bis es abgeschlossen ist. Die Übung in diesem Tutorial dauert etwa 10 Minuten.
Optional können Sie Details des Failoverauftrags anzeigen, indem Sie das Failoverereignis über die Benachrichtigungen auswählen, z. B. Failover of 'recovery-plan-mjg022624' is in progress....

Führen Sie dann die folgenden Schritte aus, um den externen Zugriff auf die WebSphere Integrated Solutions Console und die Beispiel-App in der sekundären Region zu ermöglichen:

Geben Sie im Azure-Portal oben in das Suchfeld Ressourcengruppen ein, und wählen Sie dann Ressourcengruppen in den Suchergebnissen aus.
Wählen Sie den Namen der Ressourcengruppe für Ihre sekundäre Region aus, z. B. was-cluster-westus-mjg022624. Sortieren Sie Elemente nach Typ auf der Seite Ressourcengruppe.
Wählen Sie die Netzwerkschnittstelle mit dem Präfix dmgr aus. Wählen Sie IP-Konfigurationen>ipconfig1 aus. Wählen Sie Öffentliche IP-Adresse zuordnen aus. Wählen Sie für Öffentliche IP-Adresse die öffentliche IP-Adresse mit dem Präfix dmgr aus. Diese Adresse ist die, die Sie zuvor erstellt haben. In diesem Artikel lautet die Adresse dmgr-public-ip-westus-mjg022624. Wählen Sie Speichern aus, und warten Sie dann, bis der Vorgang abgeschlossen ist.
Wechseln Sie zurück zur Ressourcengruppe, und wählen Sie die Netzwerkschnittstelle mit dem Präfix ihs aus. Wählen Sie IP-Konfigurationen>ipconfig1 aus. Wählen Sie Öffentliche IP-Adresse zuordnen aus. Wählen Sie für Öffentliche IP-Adresse die öffentliche IP-Adresse mit dem Präfix ihs aus. Diese Adresse ist die, die Sie zuvor erstellt haben. In diesem Artikel lautet die Adresse ihs-public-ip-westus-mjg022624. Wählen Sie Speichern aus, und warten Sie dann, bis der Vorgang abgeschlossen ist.

Führen Sie nun die folgenden Schritte aus, um zu überprüfen, ob das Failover erwartungsgemäß funktioniert:

Suchen Sie die DNS-Namensbezeichnung für die öffentliche IP-Adresse des zuvor erstellten Dmgr. Öffnen Sie die URL der Dmgr WebSphere Integrated Solutions Console auf einer neuen Browserregisterkarte. Verwenden Sie unbedingt https. Beispiel: https://dmgrmjg022624.westus.cloudapp.azure.com:9043/ibm/console. Aktualisieren Sie die Seite, bis die Willkommensseite für die Anmeldung angezeigt wird.
Melden Sie sich bei der Konsole mit dem Benutzernamen und Kennwort für den WebSphere-Administrator an, den Sie zuvor gespeichert haben, und führen Sie dann die folgenden Schritte aus:
1. Wählen Sie im Navigationsbereich Server>Alle Server aus. Im Bereich Middleware-Server sollten vier Server aufgeführt sein, einschließlich drei WebSphere-Anwendungsserver mit WebSphere-Cluster MyCluster und einem Webserver, der ein IHS ist. Aktualisieren Sie die Seite, bis Sie sehen, dass alle Server gestartet werden.
2. Wählen Sie im Navigationsbereich Anwendungen>Anwendungstypen>WebSphere-Unternehmensanwendungen aus. Im Bereich Unternehmensanwendungen sollte eine Anwendung angezeigt werden – websphere-cafe – aufgeführt und gestartet.
3. Um die Clusterkonfiguration in der sekundären Region zu überprüfen, befolgen Sie die Schritte im Abschnitt Konfigurieren des Clusters. Ihnen sollte angezeigt werden, dass die Einstellungen für Änderungen mit Knoten synchronisieren und Verteilte Sitzungen in den Failovercluster repliziert werden, wie in den folgenden Screenshots gezeigt:
Suchen Sie die DNS-Namensbezeichnung für die öffentliche IP-Adresse des zuvor erstellten IHS. Öffnen Sie die URL der IHS-Konsole, die mit dem Stammkontext /websphere-cafe/ angefügt wurde. Beachten Sie, dass Sie nicht https verwenden dürfen. In diesem Beispiel wird für IHS nicht https verwendet, z. B. http://ihsmjg022624.westus.cloudapp.azure.com/websphere-cafe/. Sie sollten zwei Kaffeesorten sehen, die Sie zuvor auf der Seite erstellt haben.
Wechseln Sie zur Browser-Registerkarte Ihres Traffic Manager-Profils und aktualisieren Sie die Seite, bis Sie sehen, dass der Wert Überwachungsstatus des Endpunkts myFailoverEndpoint in Online geändert wird und der Wert Überwachungsstatus des Endpunkts myPrimaryEndpoint zu Herabgestuft wechselt.
Wechseln Sie zur Browserregisterkarte mit dem DNS-Namen des Traffic Manager-Profils, z. B. http://tmprofile-mjg022624.trafficmanager.net/websphere-cafe/. Aktualisieren Sie die Seite. Sie sollten die gleichen Daten sehen, die in der Anwendungsdatentabelle und in der angezeigten Sitzungstabelle gespeichert sind. Die angezeigte Benutzeroberfläche sollte dem folgenden Screenshot ähneln:

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.

Führen Sie ein Commit für das Failover aus.

Führen Sie die folgenden Schritte aus, um das Failover zu bestätigen, nachdem Sie mit dem Failover-Ergebnis zufrieden sind:

Geben Sie im Suchfeld oben im Azure-Portal Recovery Services-Tresore ein, und wählen Sie dann Recovery Services-Tresore in den Suchergebnissen aus.
Wählen Sie den Namen Ihres Recovery Services-Tresors aus, z. B. recovery-service-vault-westus-mjg022624.
Klicken Sie unter Verwalten auf Wiederherstellungspläne (Site Recovery). Wählen Sie den Wiederherstellungsplan aus, den Sie erstellt haben, z. B. recovery-plan-mjg022624.
Wählen Sie Commit>OK aus.
Überwachen Sie das Commit in Benachrichtigungen, bis es abgeschlossen ist.
Wählen Sie Elemente im Wiederherstellungsplan aus. Es sollten fünf Elemente angezeigt werden, die mit Commit für Failover ausgeführt aufgeführt sind.

Deaktivieren der Replikation

Führen Sie die folgenden Schritte aus, um die Replikation für Elemente im Wiederherstellungsplan zu deaktivieren und dann den Wiederherstellungsplan zu löschen:

Wählen Sie für jedes Element in Elemente im Wiederherstellungsplan die Schaltfläche mit den Auslassungspunkten (...) und dann Replikation deaktivieren aus.
Wenn Sie aufgefordert werden, einen Grund für die Deaktivierung des Schutzes für diesen virtuellen Computer anzugeben, wählen Sie einen Grund Ihrer Wahl aus, zum Beispiel Ich habe die Migration meiner Anwendung abgeschlossen. Wählen Sie OK aus.
Wiederholen Sie Schritt 1, bis Sie die Replikation für alle Elemente deaktivieren.
Überwachen Sie den Prozess in Benachrichtigungen, bis er abgeschlossen ist.
Wählen Sie Übersicht>Löschen aus. Wählen Sie Ja aus, um den Löschvorgang zu bestätigen.

Vorbereiten auf das Failback: Erneutes Schützen der Failover-Site

Die sekundäre Region ist jetzt der Failoverstandort und aktiv. Sie sollten ihn in Ihrer primären Region erneut schützen.

Führen Sie zunächst die folgenden Schritte aus, um ungenutzte Ressourcen zu bereinigen, die der Azure Site Recovery-Dienst später in Ihrer primären Region repliziert. Sie können die Ressourcengruppe nicht einfach löschen, da die Sitewiederherstellung die Ressourcen in der vorhandenen Ressourcengruppe wiederherstellt.

Geben Sie im Azure-Portal oben in das Suchfeld Ressourcengruppen ein, und wählen Sie dann Ressourcengruppen in den Suchergebnissen aus.
Wählen Sie den Namen der Ressourcengruppe für Ihre primäre Region aus, z. B. was-cluster-eastus-mjg022624. Sortieren Sie Elemente nach Typ auf der Seite Ressourcengruppe.
Führen Sie die folgenden Schritte aus, um die virtuellen Computer zu löschen:
1. Wählen Sie den Filter Typ und dann Virtueller Computer aus der Dropdownliste Wert aus.
2. Wählen Sie Übernehmen.
3. Wählen Sie alle virtuellen Computer und Löschen aus, und geben Sie dann zum Bestätigen des Löschvorgangs delete ein.
4. Klicken Sie auf Löschen.
5. Überwachen Sie den Prozess in Benachrichtigungen, bis er abgeschlossen ist.
Führen Sie die folgenden Schritte aus, um die Datenträger zu löschen:
1. Wählen Sie den Filter Typ und dann Datenträger aus der Dropdownliste Wert aus.
2. Wählen Sie Übernehmen.
3. Wählen Sie alle Datenträger und Löschen aus, und geben Sie dann zum Bestätigen des Löschvorgangs delete ein.
4. Klicken Sie auf Löschen.
5. Überwachen Sie den Prozess in Benachrichtigungen, und warten Sie, bis er abgeschlossen ist.
Führen Sie die folgenden Schritte aus, um die Endpunkte zu löschen:
1. Wählen Sie den Filter Typ und dann Privater Endpunkt aus der Dropdownliste Wert aus.
2. Wählen Sie Übernehmen.
3. Wählen Sie alle privaten Endpunkte und Löschen aus. Geben Sie dann zur Bestätigung des Löschvorgangs delete ein.
4. Klicken Sie auf Löschen.
5. Überwachen Sie den Prozess in Benachrichtigungen, bis er abgeschlossen ist. Ignorieren Sie diesen Schritt, wenn der Typ Privater Endpunkt nicht aufgeführt ist.
Verwenden Sie die folgenden Schritte, um die Netzwerkschnittstellen zu löschen:
1. Wählen Sie den Filter Typ und > dann Netzwerkschnittstelle aus der Dropdownliste Wert aus.
2. Wählen Sie Übernehmen.
3. Wählen Sie alle Netzwerkschnittstellen und Löschen aus. Geben Sie dann zur Bestätigung des Löschvorgangs delete ein.
4. Klicken Sie auf Löschen. Überwachen Sie den Prozess in Benachrichtigungen, bis er abgeschlossen ist.
Führen Sie die folgenden Schritte aus, um Speicherkonten zu löschen:
1. Wählen Sie den Filter Typ und > dann Speicherkonto aus der Dropdownliste Wert aus.
2. Wählen Sie Übernehmen.
3. Wählen Sie alle Speicherkonten und Löschen aus. Geben Sie dann zur Bestätigung des Löschvorgangs delete ein.
4. Klicken Sie auf Löschen. Überwachen Sie den Prozess in Benachrichtigungen, bis er abgeschlossen ist.

Verwenden Sie als Nächstes dieselben Schritte im Abschnitt Einrichten der Notfallwiederherstellung für den Cluster mit Azure Site Recovery für die primäre Region mit Ausnahme der folgenden Unterschiede:

Führen Sie für den Abschnitt Erstellen eines Recovery Services-Tresors die folgenden Schritte aus:
1. Wählen Sie die in der primären Region bereitgestellten Ressourcengruppe aus, z. B. was-cluster-eastus-mjg022624.
2. Geben Sie einen anderen Namen für den Diensttresor ein, z. B. recovery-service-vault-eastus-mjg022624.
3. Wählen Sie als Region die Option USA, Osten aus.
Verwenden Sie für Replikation aktivieren die folgenden Schritte:
1. Wählen Sie für Region in Quelle die Option USA, Westen aus.
2. Verwenden Sie für Replikationseinstellungen die folgenden Schritte:
  1. Wählen Sie für Zielressourcengruppe die vorhandene Ressourcengruppe aus, die in der primären Region bereitgestellt wurde, z. B. was-cluster-eastus-mjg022624.
  2. Wählen Sie für Failover für virtuelles Netzwerk ausführen das vorhandene virtuelle Netzwerk in der primären Region aus.
Wählen Sie für Wiederherstellungsplan erstellen und für Quelle die Option USA, Westen und für Ziel die Option USA, Osten aus.
Überspringen Sie die Schritte im Abschnitt Weitere Netzwerkkonfiguration für die sekundäre Region, da Sie diese Ressourcen zuvor erstellt und konfiguriert haben.

Hinweis

Möglicherweise stellen Sie fest, dass Azure Site Recovery den erneuten Schutz von VMs unterstützt, wenn die Ziel-VM vorhanden ist. Weitere Informationen finden Sie im Abschnitt Erneutes Schützen der VM im Tutorial: Ausführen eines Failovers in eine sekundäre Region für Azure-VMs. Aufgrund des Ansatzes, den wir für WebSphere verwenden, funktioniert dieses Feature nicht. Der Grund dafür ist, dass die einzigen Änderungen zwischen dem Quelldatenträger und dem Zieldatenträger basierend auf dem Überprüfungsergebnis für den WebSphere-Cluster synchronisiert werden. Um die Funktionalität zum erneuten Schutz der VM zu ersetzen, richtet dieses Tutorial nach dem Failover eine neue Replikation vom sekundären zum primären Standort ein. Die gesamten Datenträger werden von der Region, für die ein Failover ausgeführt wurde, in die primäre Region kopiert. Weitere Informationen erhalten Sie im Abschnitt Was geschieht beim erneuten Schützen? von Erneutes Schützen von virtuellen Azure-Computern, für die ein Failover zur primären Region durchgeführt wurde.

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:

Wählen Sie den in der primären Region bereitgestellten Wiederherstellungsdiensttresor aus, z. B. recovery-service-vault-eastus-mjg022624.
Wählen Sie die in der primären Region bereitgestellten Ressourcengruppe aus, z. B. was-cluster-eastus-mjg022624.
Nachdem Sie den externen Zugriff auf die WebSphere Integrated Solutions Console und die Beispiel-App in der primären Region aktiviert haben, rufen Sie die Browserregisterkarten für die WebSphere Integrated Solutions Console und die Beispiel-App für den primären Cluster erneut auf, die Sie zuvor geöffnet haben. Stellen Sie sicher, dass sie wie erwartet funktionieren. Je nachdem, wie viel Zeit für das Failback benötigt wurde, werden möglicherweise keine Sitzungsdaten im Abschnitt Neuer Kaffee der Beispiel-App-UI angezeigt, wenn sie länger als eine Stunde zuvor abgelaufen ist.
Wählen Sie im Abschnitt Ein Commit für das Failover ausführen Ihren Recovery Services-Tresor aus, den Sie am primären Standort bereitgestellt haben, z. B. recovery-service-vault-eastus-mjg022624.
Im Traffic Manager-Profil sollte Ihnen angezeigt werden, dass der Endpunkt myPrimaryEndpoint in Online geändert wird und der Endpunkt myFailoverEndpoint zu Herabgestuft wechselt.
Verwenden Sie im Abschnitt Vorbereiten auf das Failback: Erneutes Schützen der Failover-Site die folgenden Schritte:
1. Die primäre Region ist Ihr Failoverstandort und ist aktiv, daher sollten Sie ihn in Ihrer sekundären Region erneut schützen.
2. Bereinigen Sie die in Ihrer sekundären Region bereitgestellte Ressource, z. B. Ressourcen, die in was-cluster-westus-mjg022624 bereitgestellt wurden.
3. Verwenden Sie dieselben Schritte im Abschnitt Einrichten der Notfallwiederherstellung für den Cluster mit Azure Site Recovery zum Schutz der primären Region in der sekundären Region mit Ausnahme der folgenden Änderungen:
  1. Überspringen Sie die Schritte im Abschnitt Erstellen eines Recovery Services-Tresors, da Sie bereits zuvor einen erstellt haben, z. B. recovery-service-vault-westus-mjg022624.
  2. Wählen Sie für Replikation aktivieren>Replikationseinstellungen>Failover für virtuelles Netzwerk durchführen das vorhandene Netzwerk in der sekundären Region aus.
  3. Überspringen Sie die Schritte im Abschnitt Weitere Netzwerkkonfiguration für die sekundäre Region, da Sie diese Ressourcen zuvor erstellt und konfiguriert haben.

Bereinigen von Ressourcen

Wenn Sie die WebSphere-Cluster und anderen 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.
Geben Sie im Suchfeld oben im Azure-Portal Recovery Services-Tresore ein, und wählen Sie dann Recovery Services-Tresore in den Suchergebnissen aus.
Wählen Sie den Namen Ihres Recovery Services-Tresors aus, z. B. recovery-service-vault-westus-mjg022624.
Klicken Sie unter Verwalten auf Wiederherstellungspläne (Site Recovery). Wählen Sie den Wiederherstellungsplan aus, den Sie erstellt haben, z. B. recovery-plan-mjg022624.
Verwenden Sie dieselben Schritte im Abschnitt Deaktivieren der Replikation, um Sperren für replizierte Elemente zu entfernen.
Wiederholen Sie die Schritte 1–4 für die Ressourcengruppe des WebSphere-Clusters, z. B. was-cluster-westus-mjg022624.
Wiederholen Sie die Schritte 1–4 für die Ressourcengruppe des sekundären WebSphere-Clusters, z. B. was-cluster-eastus-mjg022624.

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 mit dem Azure Site Recovery-Dienst wiederhergestellt, und die sekundäre Datenbank befindet sich im Standbymodus.

Sehen Sie sich weiterhin die folgenden Referenzen an, um weitere Optionen zum Erstellen von HA/DR-Lösungen und zum Ausführen von WebSphere auf Azure zu erhalten:

Dokumentation zur Zuverlässigkeit von Azure

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

Automatisches Failover mit Azure Traffic Manager

Weitere Informationen zu WebSphere auf Azure

Freigeben über