Lernprogramm: Migrieren von WebSphere Liberty/Open Liberty zu Azure Kubernetes Service (AKS) mit hoher Verfü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 Liberty/Open Liberty auf Azure Kubernetes Service (AKS). Die Lösung veranschaulicht, wie Sie ein niedriges Recovery Time Objective (RTO) und Recovery Point Objective (RPO) mithilfe einer einfachen datenbankgesteuerten Jakarta EE-Anwendung erreichen, die auf WebSphere Liberty/Open Liberty 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 Liberty/Open Liberty-Cluster auf AKS ein.
Richten Sie die Notfallwiederherstellung für den Cluster mithilfe von Azure Backup ein.
Richten Sie den sekundären AKS-Cluster 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. Sowohl die primäre als auch die sekundäre Region verfügen über eine vollständige Bereitstellung des Liberty-Clusters. Allerdings bearbeitet nur die primäre Region aktiv Netzwerkanforderungen der Benutzer. Die sekundäre Region ist passiv wird nur dann zum Empfang von Datenverkehr aktiviert, wenn in der primären Region eine Dienstunterbrechung auftritt. Azure Traffic Manager verwendet das Integritätsprüfungsfeature von Azure Application Gateway, um dieses bedingte Routing zu implementieren. Der primäre Cluster wird ausgeführt, und der sekundäre Cluster wird heruntergefahren. Die Geofailover-RTO der Anwendungsebene hängt von der Zeit zum Starten virtueller Computer (VMs) und Ausführen des sekundären Clusters ab. Die RPO hängt von der Azure SQL-Datenbank ab, da die Daten in der Failovergruppe der Azure SQL-Datenbank persistent gespeichert und repliziert werden.

Die Datenbankebene besteht aus einer Azure SQL-Datenbank-Failovergruppe mit einem primären Server und einem sekundären Server. Der Lese-/Schreib-Listener-Endpunkt verweist immer auf den primären Server und ist in jeder Region mit einem WebSphere Liberty/Open Liberty-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 zum Geofailover-RPO und -RTO von Azure SQL-Datenbank finden Sie unter Übersicht über die Geschäftskontinuität mit Azure SQL Database.

Dieses Tutorial wurde mit den Azure Backup- und Azure SQL Database-Diensten geschrieben, da das Tutorial auf die HA-Features 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 Ihnen im Abonnement entweder die Owner-Rolle oder die Contributor- und User Access Administrator-Rolle zugewiesen wurde. 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 Database-Failovergruppe in gekoppelten Regionen für die Verwendung mit Ihren WebSphere Liberty/Open Liberty-Clustern und -Apps. In einem späteren Abschnitt konfigurieren Sie WebSphere Liberty/Open Liberty, um die Sitzungsdaten in dieser Datenbank zu speichern. 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:

Speichern Sie in Schritt 4 zum Erstellen einer neuen Ressourcengruppe den Wert Ressourcengruppenname, z. B. myResourceGroup.
Speichern Sie in Schritt 5 für den Datenbanknamen den Wert Datenbankname, z. B. mySampleDatabase.
Führen Sie in Schritt 6 zum Erstellen des Servers die folgenden Schritte aus:
1. Geben Sie einen eindeutigen Servernamen ein, z. B. sqlserverprimary-mjg032524.
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.
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.
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.
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.

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:

Wenn Sie den Abschnitt Erstellen einer Failovergruppe erreichen, verwenden Sie 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-mjg032524.
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-mjg032524.
  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 Geplantes Failover testen abgeschlossen haben, lassen Sie die Failovergruppenseite geöffnet, und verwenden Sie sie später für den Failovertest der WebSphere Liberty/Open Liberty-Cluster.

Einrichten des primären WebSphere Liberty/Open Liberty-Clusters auf AKS

In diesem Abschnitt erstellen Sie den primären WebSphere Liberty/Open Liberty-Cluster auf AKS mithilfe des IBM WebSphere Liberty and Open Liberty on Azure Kubernetes Service-Angebots. Der sekundäre Cluster wird während des Failovers mithilfe von Azure Backup später aus dem primären Cluster wiederhergestellt.

Bereitstellen des primären WebSphere Liberty/Open Liberty-Clusters

Verwenden Sie die folgenden Schritte, um den primären Cluster bereitzustellen:

Öffnen Sie das Angebot IBM WebSphere Liberty and Open Liberty on Azure Kubernetes Service in Ihrem Browser, und wählen Sie Create aus. Der Bereich Grundeinstellungen des Angebots sollte angezeigt werden.
Führen Sie die folgenden Schritte aus, um den Bereich Grundeinstellungen auszufüllen:
1. Stellen Sie sicher, dass der für Abonnement angezeigte Wert mit dem Wert übereinstimmt, der die im Abschnitt „Voraussetzungen“ aufgeführten Rollen enthält.
2. 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. liberty-aks-eastus-mjg032524.
3. Wählen Sie unter Instanzdetails für Region die Option USA, Osten aus.
4. Wählen Sie Weiter aus, um zum Bereich AKS zu navigieren.
Warten Sie einen Moment. Im AKS-Bereich sollten alle Felder mit den Standardwerten vorausgefüllt sein. Wählen Sie Weiter aus, um zum Bereich Lastenausgleich zu navigieren.
Führen Sie die folgenden Schritte aus, um den Bereich Lastenausgleich auszufüllen:
1. Wählen Sie für Mit Azure Application Gateway verbinden? die Option Ja aus.
2. Behalten Sie die Standardwerte für andere Felder bei.
3. Wählen Sie Weiter aus, und navigieren Sie zum Bereich Operator und Anwendung.
Verwenden Sie die folgenden Schritte, um den Bereich Operator und Anwendung auszufüllen:
1. Behalten Sie die Standardwerte für alle Felder bei.
  
  Hinweis
  
  In diesem Tutorial wird der Open Liberty-Operator mithilfe der Standardwerte bereitgestellt. Optional können Sie WebSphere Liberty Operator implementieren, indem Sie Ja für Von IBM unterstützt? auswählen.
2. Klicken Sie auf Überprüfen + erstellen.
3. 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 ungefähr bis zu 30 Minuten dauern. Danach sollte auf der Bereitstellungsseite der Text Ihre Bereitstellung wurde abgeschlossen. angezeigt werden.

Überprüfen der Bereitstellung des Clusters

Sie haben einen AKS-Cluster, eine Azure Container Registry-Instanz (ACR) und ein Azure Application Gateway in der primären Region bereitgestellt. Der AKS-Cluster ist die Zielcomputerplattform, auf der Ihre App bereitgestellt und ausgeführt wird. Die ACR-Instanz speichert das Anwendungsimage, das AKS während der App-Bereitstellung abruft. Das Azure Application Gateway fungiert als Load Balancer für die Anwendung, die im AKS-Cluster bereitgestellt wird.

Führen Sie die folgenden Schritte aus, um diese Schlüsselkomponenten zu überprüfen, 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 cmdToConnectToCluster. Öffnen Sie ein Terminal, fügen Sie den kopierten Befehl ein, und drücken Sie zum Ausführen die Eingabetaste. In der Ausgabe sollte eine Meldung ähnlich dem folgenden Beispiel angezeigt werden:
```
Merged "cluster3984d1-admin" as current context in <your-user>\.kube\config
```
Speichern Sie den Befehl, damit Sie ihn später verwenden können, um eine Verbindung mit dem Cluster herzustellen.

Führen Sie kubectl get pod --all-namespaces im Terminal aus, um alle Pods aufzuführen, die auf dem AKS-Cluster ausgeführt werden. Die Ausgabe sollte etwa folgendem Beispiel entsprechen:

NAMESPACE      NAME                                        READY   STATUS    RESTARTS      AGE
cert-manager   cert-manager-66bc9756fd-255pk               1/1     Running   0             8m55s
cert-manager   cert-manager-cainjector-669c9fb694-k4q88    1/1     Running   0             8m55s
cert-manager   cert-manager-webhook-84967d556d-vj4lp       1/1     Running   0             8m55s
kube-system    azure-ip-masq-agent-dgzkt                   1/1     Running   0             29m
kube-system    cloud-node-manager-6x7bp                    1/1     Running   0             29m
kube-system    coredns-789789675-6b7dh                     1/1     Running   0             28m
kube-system    coredns-789789675-n68wt                     1/1     Running   0             29m
kube-system    coredns-autoscaler-649b947bbd-zhdbn         1/1     Running   0             29m
kube-system    csi-azuredisk-node-h9p7m                    3/3     Running   0             29m
kube-system    csi-azurefile-node-jnllw                    3/3     Running   0             29m
kube-system    ingress-appgw-deployment-69944d8fb9-v9btr   1/1     Running   5 (12m ago)   17m
kube-system    konnectivity-agent-94878f88c-hfqng          1/1     Running   0             29m
kube-system    konnectivity-agent-94878f88c-ln2vp          1/1     Running   0             29m
kube-system    kube-proxy-28lkg                            1/1     Running   0             29m
kube-system    metrics-server-5fffcb8954-549xl             2/2     Running   0             28m
kube-system    metrics-server-5fffcb8954-fn56g             2/2     Running   0             28m
open-liberty   olo-controller-manager-7954d76cf8-qhmxw     1/1     Running   0             8m40s

Führen Sie kubectl get secret im Terminal aus, um alle geheimen Schlüssel auf dem AKS-Cluster auflisten zu können. Ihnen sollte ein geheimer Schlüssel in der Ausgabe angezeigt werden, wie im folgenden Beispiel dargestellt:
```
NAME           TYPE                DATA   AGE
secret3984d1   kubernetes.io/tls   2      24m
```
Dieser geheime Schlüssel ist ein TLS-Schlüssel, der Zertifikat- und Schlüsseldaten für TLS-Datenverkehr enthält. Kopieren Sie den Namen des geheimen Schlüssels, und speichern Sie ihn, z. B. secret3984d1. Sie verwenden ihn später bei der App-Bereitstellung.
Wechseln Sie zurück zur Seite Ausgaben. Kopieren Sie den Wert der Eigenschaft cmdToLoginInRegistry. Fügen Sie den kopierten Befehl im Terminal ein, und drücken Sie zum Ausführen die Eingabetaste. Ihnen sollte Anmeldung erfolgreich in der Ausgabe angezeigt werden. Lassen Sie das Terminal geöffnet, und verwenden Sie es später für die weitere Konfiguration des WebSphere Liberty/Open Liberty-Clusters.

Führen Sie die folgenden Schritte aus, um den Namen und den DNS-Namen der öffentlichen IP-Adresse von Azure Application Gateway abzurufen. Sie verwenden sie später für die App-Bereitstellung und das Azure Traffic Manager-Setup.

Geben Sie im Suchfeld des Azure-Portals Ressourcengruppen ein, und wählen Sie Ressourcengruppen aus den Suchergebnissen aus.
Wählen Sie den Namen der Ressourcengruppe für Ihre primäre Region aus, z. B. liberty-aks-eastus-mjg032524.
Suchen Sie die Ressource Public IP address mit dem Präfix gwip. Kopieren Sie sie dann, und speichern Sie ihren Namen.
Wählen Sie die Ressource Öffentliche IP-Adresse aus, kopieren Sie sie dann und speichern Sie sie zusammen mit dem DNS-Namen, z. B. olgw3984d1.eastus.cloudapp.azure.com.

Aktivieren von Georeplikationen für die ACR-Instanz

Die ACR-Instanz dient zum Speichern von Anwendungsimages sowohl für primäre als auch für sekundäre Cluster. Führen Sie die folgenden Schritte aus, um Georeplikationen für die ACR-Instanz zu aktivieren:

Geben Sie im Suchfeld des Azure-Portals Ressourcengruppen ein, und wählen Sie Ressourcengruppen aus den Suchergebnissen aus.
Wählen Sie den Namen der Ressourcengruppe für Ihre primäre Region aus, z. B. liberty-aks-eastus-mjg032524.
Suchen Sie die Ressource Container registry mit dem Präfix acr, und wählen Sie sie dann zum Öffnen aus.
Wählen Sie Eigenschaften aus. Wählen Sie für Preisplan die Option Premium und dann Speichern aus. Warten Sie, bis der Vorgang abgeschlossen ist.
Wählen Sie Georeplikationen und dann Hinzufügen aus. Wählen Sie für Standort die Option USA, Westen und dann Erstellen aus. Warten Sie, bis der Vorgang abgeschlossen ist.
Warten Sie einen Moment, und wählen Sie dann Aktualisieren aus. Wiederholen Sie den Vorgang, bis zwei Speicherorte aufgelistet sind, und der Status Bereit lautet.

Verwenden Sie die folgenden Schritte, um die ACR-Anmeldeinformationen abzurufen. Sie können sie später für die App-Bereitstellung verwenden.

Wählen Sie Zugriffsschlüssel aus.
Kopieren und speichern Sie den Wert für Anmeldeserver, Benutzername und Kennwort.

Bereitstellen einer Beispiel-App

Führen Sie die folgenden Schritte aus, um eine CRUD Java/Jakarta EE-Beispielanwendung auf WebSphere Liberty/Open Liberty-Cluster für den Failovertest für die Notfallwiederherstellung bereitzustellen und auszuführen:

Laden Sie das Beispiel anhand der folgenden Befehle herunter:
```
git clone https://github.com/Azure-Samples/open-liberty-on-aks.git
cd open-liberty-on-aks
export BASE_DIR=$PWD
git checkout 20240325
```
Die Anwendung konfiguriert eine Datenquelle jdbc/JavaEECafeDB, die eine Verbindung mit der zuvor bereitgestellten Azure SQL Database herstellt. Die Datenquelle wird zum Speichern von HTTP-Sitzungsdaten verwendet, wodurch Failover- und Lastenausgleich über einen Cluster von WebSphere Liberty/Open Liberty-Servern ermöglicht wird. Die Beispiel-App konfiguriert außerdem ein Persistenzschema, um Anwendungsdaten coffee in derselben Datenquelle beizubehalten. Beachten Sie, dass der Kontextstamm des Beispiels wie / in der Datei server.xml konfiguriert ist.

Verwenden Sie die folgenden Befehle, um Umgebungsvariablen mit den Werten zu definieren, die Sie zuvor gespeichert haben:

export DB_SERVER_NAME=<failover-group-name>.database.windows.net
export DB_NAME=mySampleDatabase
export DB_USER=azureuser@<failover-group-name>
export DB_PASSWORD='<SQL-Server-admin-login-password>'
export LOGIN_SERVER=<ACR-login-server>
export USER_NAME=<ACR-username>
export PASSWORD='<ACR-password>'
export INGRESS_TLS_SECRET=<TLS-secret-name>

Verwenden Sie die folgenden Befehle, um die App zu paketieren, das Docker-Image zu erstellen, das Image an die ACR-Instanz zu übertragen und das Beispiel im AKS-Cluster bereitzustellen:

cd $BASE_DIR/java-app
mvn clean install

cd $BASE_DIR/java-app/target

# If you deployed WebSphere Liberty Operator previously, use "Dockerfile-wlp" instead of "Dockerfile"
docker buildx build --platform linux/amd64 -t javaee-cafe:v1 --pull --file=Dockerfile .
docker tag javaee-cafe:v1 ${LOGIN_SERVER}/javaee-cafe:v1
docker login -u ${USER_NAME} -p ${PASSWORD} ${LOGIN_SERVER}
docker push ${LOGIN_SERVER}/javaee-cafe:v1

cd $BASE_DIR/java-app/target
kubectl apply -f db-secret.yaml

# If you deployed WebSphere Liberty Operator previously, use "webspherelibertyapplication-agic.yaml" instead of "openlibertyapplication-agic.yaml"
kubectl apply -f openlibertyapplication-agic.yaml

Führen Sie den folgenden Befehl aus, um die von Ihnen bereitgestellte Beispiel-App abzurufen:

# If you deployed WebSphere Liberty Operator previously, use "WebSphereLibertyApplication" instead of "OpenLibertyApplication"
kubectl get OpenLibertyApplication

In der Ausgabe sollte eine READY-Anwendung angezeigt werden:

NAME                       IMAGE                                 EXPOSED   RECONCILED   RESOURCESREADY   READY   AGE
javaee-cafe-cluster-agic   acr3984d1.azurecr.io/javaee-cafe:v1             True         True             True    45s

Führen Sie den folgenden Befehl aus, um den Status der während der Bereitstellung erstellten Pods abzurufen:

kubectl get pods

Das folgende Beispiel gibt an, dass alle Pods ausgeführt werden. Wenn keine ähnliche Ausgabe angezeigt wird, warten Sie eine Weile, und wiederholen Sie den Vorgang.

NAME                                        READY   STATUS    RESTARTS   AGE
javaee-cafe-cluster-agic-6bbb8d6f5c-2xjc4   1/1     Running   0          1m
javaee-cafe-cluster-agic-6bbb8d6f5c-4f449   1/1     Running   0          1m
javaee-cafe-cluster-agic-6bbb8d6f5c-m2wg6   1/1     Running   0          1m

Führen Sie die folgenden Schritte aus, um zu überprüfen, ob die App wie erwartet ausgeführt wird:
1. Öffnen Sie auf einer neuen Browserregisterkarte den DNS-Namen der öffentlichen IP-Adresse des Azure Application Gateway, das Sie zuvor gespeichert haben. Verwenden Sie das https-Protokoll, z. B. https://olgw3984d1.eastus.cloudapp.azure.com. Die Willkommensseite der Beispiel-App sollte angezeigt werden.
2. Erstellen Sie einen neuen Kaffee mit Namen und 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 mithilfe von Azure Backup

In diesem Abschnitt richten Sie die Notfallwiederherstellung für den AKS-Cluster in der primären Region mithilfe von Azure Backup ein.

Erstellen eines Speicherkontos

AKS-Sicherung verwendet einen BLOB-Container, um die AKS-Clusterressourcen zu enthalten. Sie erstellen einen weiteren Blobcontainer als Staging-Speicherort zur Verwendung während der regionsübergreifenden Wiederherstellung.

Verwenden Sie die folgenden Schritte, um ein Speicherkonto und zwei Container zu erstellen. Bei einigen Schritten werden Sie zu anderen Anleitungen weitergeleitet.

Melden Sie sich beim Azure-Portal an.
Erstellen Sie ein Speicherkonto, indem Sie die Schritte unter Erstellen eines Speicherkontos ausführen. Sie müssen nicht alle Schritte in diesem Artikel ausführen. Füllen Sie die Felder aus, wie im Bereich Grundeinstellungen dargestellt, indem Sie die folgenden Schritte durchführen:
1. Wählen Sie für Ressourcengruppe die vorhandene Ressourcengruppe aus, in der der primäre Cluster bereitgestellt wird, z. B. liberty-aks-eastus-mjg032524.
2. Geben Sie für Speicherkontoname einen eindeutigen Namen ein, z. B. storageeastusmjg032524.
3. Wählen Sie als Region die Option USA, Osten aus.
4. Wählen Sie Überprüfen + erstellen aus, um die Standardoptionen zu akzeptieren.
5. Fahren Sie mit der Überprüfung und Erstellung des Kontos fort, und kehren Sie zu diesem Artikel zurück.
Erstellen Sie einen Speichercontainer für die AKS-Sicherungserweiterung, indem Sie die folgenden Schritte in Erstellen eines Speichercontainers ausführen. Dieser Leitfaden verwendet aks-backup-ext als Containername.
Erstellen Sie einen anderen Speichercontainer als Stagingspeicherort für die Verwendung während der Wiederherstellung. Dieser Leitfaden verwendet staging als Containername.

Aktivieren der AKS-Sicherungserweiterung

Bevor Sie fortfahren, führen Sie die folgenden Schritte aus, um die AKS-Sicherungserweiterung auf dem Cluster in der primären Region zu installieren:

Aktivieren Sie die CSI-Treiber und Momentaufnahmen für Ihren Cluster. Aktualisieren Sie für den folgenden Befehl az aks update den Wert der Bash-Variablen RG_NAME in Ihren Ressourcengruppennamen, z. B. liberty-aks-eastus-mjg032524, und führen Sie ihn in Ihrem lokalen Bash-Terminal aus.
```
export RG_NAME=<your-aks-cluster-resource-group>
export AKS_NAME=$(az aks list \
    --resource-group ${RG_NAME} \
    --query "[0].name" \
    --output tsv | tr -d '\r')

az aks update \
    --resource-group ${RG_NAME} \
    --name ${AKS_NAME} \
    --enable-disk-driver \
    --enable-file-driver \
    --enable-blob-driver \
    --enable-snapshot-controller --yes
```
Es dauert etwa 5 Minuten, um die Treiber zu aktivieren. Stellen Sie sicher, dass die Befehle ohne Fehler abgeschlossen sind, bevor Sie fortfahren.
Öffnen Sie die Ressourcengruppe, die AKS bereitgestellt hat, z. B. liberty-aks-eastus-mjg032524. Wählen Sie den AKS-Cluster aus der Ressourcenliste aus.
Wählen Sie unter Settings auf der AKS-Zielseite die Option Sichern und dann Erweiterung installieren aus.
Wählen Sie auf der Seite AKS-Sicherungserweiterung installieren die Option Weiter aus. Wählen Sie das Speicherkonto storageeastusmjg032524 und den Blob-Container aks-backup-ext aus, die in derselben Ressourcengruppe erstellt wurden. Wählen Sie Weiter und dann Erstellen aus. Für diesen Schritt werden etwa fünf Minuten benötigt.

Sichern des AKS-Clusters

Verwenden Sie die folgenden Schritte, um den AKS-Cluster zu sichern:

Suchen Sie im Azure-Portal im Suchfeld nach Sicherungstresoren. Die Liste sollte unter Services angezeigt werden. Wählen Sie ihn aus.
Befolgen Sie die Schritte in Sichern von Azure Kubernetes Service mit Azure Backup, um die AKS-Sicherung für den primären Cluster zu aktivieren. Führen Sie die Schritte bis zum Abschnitt (nicht einschließlich) Verwenden von Hooks während der AKS-Sicherung aus, und verwenden Sie die restlichen Schritte in diesem Abschnitt, um Anpassungen vorzunehmen.
Wenn Sie den Abschnitt Sicherungstresor erstellen erreichen, verwenden Sie die folgenden Schritte:
1. Wählen Sie für Schritt 1 für Ressourcengruppe die vorhandene Ressourcengruppe aus, in der der primäre Cluster bereitgestellt wird, z. B. liberty-aks-eastus-mjg032524.
2. Geben Sie für Sicherungstresorname einen eindeutigen Wert ein, z. B. aks-backup-vault-eastus-mjg032524.
3. Wählen Sie als Region die Option USA, Osten aus.
4. Wählen Sie für Sicherungsspeicherredundanz die Option Global redundant aus.
5. Wählen Sie für Schritt 2 für Regionsübergreifende Wiederherstellung die Option Aktivieren aus.
Wenn Sie den Abschnitt Erstellen einer Sicherungsrichtlinie erreichen, verwenden Sie die folgenden Schritte:
1. Geben Sie für Schritt 3 einen Namen für die Sicherungsrichtlinie ein, z. B. aksbackuppolicy.
2. Wählen Sie den Sicherungstresor aus, den Sie in derselben Ressourcengruppe erstellt haben, z. B. aks-backup-vault-eastus-mjg032524.
3. Fügen Sie für Schritt 4 eine Aufbewahrungsregel hinzu, in der „Vault-standard“ ausgewählt ist.
4. Wählen Sie Hinzufügen.
Führen Sie im Abschnitt Configure backups (IDP konfigurieren) die folgenden Schritte aus:
1. Überspringen Sie die Schritt 1–5, die für die AKS-Erweiterungsinstallation sind. Beginnen Sie mit Schritt 6 für den AKS-Cluster in der primären Region.
2. Wählen Sie für Schritt 7 für Tresor den Sicherungstresor aus, den Sie in derselben Ressourcengruppe erstellt haben, z. B. aks-backup-vault-eastus-mjg032524. Wenn Berechtigungsfehler auftreten, wählen Sie Berechtigungen erteilen aus, um fortzufahren. Wenn der Fehler nach Abschluss der Berechtigungsbereitstellung weiterhin angezeigt wird, wählen Sie Revalidate aus, um die Rollenzuweisungen zu aktualisieren.
3. Suchen Sie für Schritt 10 nach Zu sichernde Ressourcen auswählen. Geben Sie für Sicherungsinstanzname einen eindeutigen Namen ein, z. B. akseastusmjg032524. Wählen Sie für Other options alle Optionen aus. Stellen Sie sicher, dass Include Secrets ausgewählt ist.
4. Bei Schritt 11 tritt ein Fehler bei der Rollenzuweisung auf. Führen Sie die Schritte 12 bis 14 aus, um den Fehler zu beheben.
5. Nachdem Sie in Schritt 15 die Option Sicherung konfigurieren ausgewählt haben, kehren Sie zur Seite Sicherung zurück. Warten Sie einen Moment, und wählen Sie Aktualisieren aus. Wiederholen Sie den Vorgang, bis Sie sehen, dass die Sicherungsinstanz aufgelistet ist und der Schutzstatus Schutz konfiguriert lautet.

Warten Sie, bis eine Vault-Standardsicherung ausgeführt wird.

In AKS ist die Ebene „Vault-standard“ die einzige Ebene, die Georedundanz und Regionsübergreifende Wiederherstellung unterstützt. Wie in Welche Sicherungsspeicherebene wird von AKS Backup unterstützt?, „Es wird nur ein geplanter Wiederherstellungspunkt pro Tag in die Vault-Stufe verschoben.“ angegeben, müssen Sie warten, bis eine Tresor-Standardsicherung ausgeführt wird. Eine gute Untergrenze besteht darin, nach Abschluss des vorherigen Schritts höchstens 24 Stunden zu warten, bevor Sie die Wiederherstellung durchführen.

Führen Sie die folgenden Schritte aus, um zu überprüfen, ob eine Vault-Standardsicherung verfügbar ist:

Wählen Sie auf der Seite Sicherung des primären AKS-Clusters die Backupinstanz aus.
Warten Sie einen Moment, und wählen Sie Aktualisieren aus. Wiederholen Sie den Vorgang, bis Sie sehen, dass mindestens ein Operational and Vault-standard-Wiederherstellungspunkt im Abschnitt RESTORE POINTS aufgeführt ist.

Einrichten des sekundären AKS-Clusters

Wenn Sie auf eine Vault-Standardsicherung für den primären AKS-Cluster warten, richten Sie Ihren sekundären AKS-Cluster für die Wiederherstellung später ein.

Verwenden Sie dieselben Schritte im Abschnitt Bereitstellen des primären WebSphere Liberty/Open Liberty-Clusters, um den sekundären AKS-Cluster in der sekundären Region einzurichten, mit Ausnahme der folgenden Unterschiede:

Verwenden Sie im Bereich Grundeinstellungen die folgenden Schritte:
1. Wählen Sie im Feld Ressourcengruppe die Option Neu erstellen aus, und geben Sie einen anderen eindeutigen Wert für die Ressourcengruppe ein, z. B. liberty-aks-westus-mjg032524.
2. Wählen Sie unter Instanzdetails für Region die Option USA, Westen aus.
Führen Sie im Bereich AKS die folgenden Schritte aus:
1. Wählen Sie unter Azure Container Registry (ACR) für ACR-Instanz auswählen die Option Nein aus.
2. Wählen Sie die vorhandene ACR-Instanz in der primären Region aus, die mit Georeplikationen aktiviert ist.

Führen Sie die gleichen Schritte im Abschnitt Überprüfen der Bereitstellung des Clusters aus, um die Bereitstellung in der sekundären Region mit Ausnahme der folgenden Unterschiede zu überprüfen:

Sie müssen den Namen des TLS-Schlüssels nicht kopieren und speichern. Der TLS-Schlüssel wird aus der Sicherung des primären AKS-Clusters wiederhergestellt.
Verwenden Sie die Ressourcengruppe des sekundären Clusters, z. B. liberty-aks-westus-mjg032524, wenn Sie den Namen und den DNS-Namen der öffentlichen IP-Adresse des in der sekundären Region bereitgestellten Azure Application Gateway nachschlagen.

Führen Sie die gleichen Schritte im Abschnitt Erstellen eines Speicherkontos aus, um ein Speicherkonto in der sekundären Region zu erstellen, mit Ausnahme der folgenden Unterschiede:

Wählen Sie für das Feld Ressourcengruppe die vorhandene Ressourcengruppe aus, in der der sekundäre Cluster bereitgestellt wird, z. B. liberty-aks-westus-mjg032524.
Geben Sie für Speicherkontoname einen eindeutigen Namen ein, z. B. storagewestusmjg032524.
Wählen Sie unter Region die Option USA, Westen aus.

Verwenden Sie dieselben Schritte im Abschnitt Aktivieren der AKS-Sicherungserweiterung, um die AKS Backup Extension für den Cluster in der sekundären Region mit Ausnahme der folgenden Unterschiede zu installieren:

Aktualisieren Sie in Schritt 1 den CSI-Treiber und Snapshots für Ihren sekundären Cluster, aktualisieren Sie den Wert der Bash-Variablen RG_NAME in die Ressourcengruppe in der sekundären Region, z. B. liberty-aks-westus-mjg032524.
Wählen Sie in Schritt 2 den AKS-Cluster aus der Ressourcengruppe in der sekundären Region aus, z. B. liberty-aks-westus-mjg032524.
Wählen Sie in Schritt 4 zum Installieren der AKS-Sicherungserweiterung für Ihren sekundären Cluster das Speicherkonto aus, das Sie in derselben Ressourcengruppe der sekundären Region erstellt haben, z. B. storagewestusmjg032524.

Um Kosten zu sparen, beenden Sie den AKS-Cluster in der sekundären Region, indem Sie die Schritte in Beenden und Starten eines Azure Kubernetes Service-Clusters (AKS) befolgen. Sie müssen es starten, bevor Sie den Cluster später wiederherstellen.

Einrichten von Azure Traffic Manager

Die Vault-Standardsicherung wurde im Abschnitt Warten, bis eine Vault-Standardsicherung ausgeführt wird erwähnt. Nachdem Sie sehen, dass die Sicherung „Vault-standard“ verfügbar ist, können Sie einen Azure Traffic Manager zum Verteilen von Datenverkehr an Ihre öffentlich zugänglichen Anwendungen in den globalen Azure-Regionen erstellen. Der primäre Endpunkt verweist auf die öffentliche IP-Adresse des Azure Application Gateway in der primären Region. Der sekundäre Endpunkt verweist auf die öffentliche IP-Adresse des Azure Application Gateway in der sekundären Region.

Erstellen Sie anhand der Schritte unter Schnellstart: Erstellen eines Traffic Manager-Profils unter Verwendung des 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. 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:

Wenn Sie den Abschnitt Erstellen eines Traffic Manager-Profils erreichen, verwenden Sie in Schritt 2 für Erstellen eines Traffic Manager-Profils die folgenden Schritte:
1. Geben Sie für Name einen eindeutigen Traffic Manager-Profilnamen ein, z. B. tmprofile-mjg032524.
2. Wählen Sie unter Routingmethode die Option Priorität aus.
3. Geben Sie für Ressourcengruppe den neuen Ressourcengruppennamen ein und speichern Sie ihn, 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 Protokoll https und für Port die Zahl 443 ein.
  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.
    - Geben Sie für Testtimeout die Zahl 5 ein.
  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 Azure Application 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 Azure Application 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 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.
Überprüfen und kopieren Sie den DNS-Namen des Traffic Manager-Profils, und ersetzen Sie das Protokoll http durch https. Beispiel: https://tmprofile-mjg032524.trafficmanager.net.
Öffnen Sie die URL auf einer neuen Browserregisterkarte. Der zuvor erstellte Kaffee sollte auf der Seite aufgeführt sein.
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.

Sie haben die Traffic Manager-Profileinrichtung abgeschlossen. 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

In diesem Abschnitt führen Sie zum Testen des Failovers ein manuelles Failover Ihres Azure SQL-Datenbank-Servers durch, und stellen die Sicherung Ihres AKS-Clusters wieder her. Führen Sie dann einen Failover durch, indem Sie das Azure-Portal verwenden.

Failover an den sekundären Standort

Um einen Ausfall der primären Region zu simulieren, beenden Sie den primären AKS-Cluster, indem Sie die Schritte in Beenden und Starten eines Azure Kubernetes Service (AKS)-Clusters befolgen.

Starten Sie als Nächstes den sekundären AKS-Cluster, damit er aus der Sicherung des primären Clusters wiederhergestellt werden kann.

Hinweis

Wenn WebSphere Liberty/Open Liberty-Anwendungen auf dem Wiederherstellungszielcluster ausgeführt werden, führen Sie zur Vermeidung von Konflikten die folgenden Schritte aus, um WebSphere Liberty/Open Liberty-Anwendungen zu bereinigen:

Stellen Sie eine Verbindung mit dem Zielcluster her, indem Sie den Befehl für cmdToConnectToCluster ausführen, den Sie zuvor gespeichert haben.
Führen Sie für Open Liberty-Anwendungen den folgenden Befehl aus:
```
kubectl delete OpenLibertyApplication --all --all-namespaces
```
Führen Sie für WebSphere Liberty-Anwendungen den folgenden Befehl aus:
```
kubectl delete WebSphereLibertyApplication --all --all-namespaces
```

Wechseln Sie dann zur Browserregisterkarte Ihres Traffic Manager-Profils, und überprüfen Sie, ob der Überwachungsstatus für beide Endpunkte myPrimaryEndpoint und myFailoverEndpoint Herabgestuft lautet.

Verwenden Sie nun 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-mjg032524.
Wählen Sie Failover und dann Ja aus.
Warten Sie, bis der Vorgang abgeschlossen ist.

Führen Sie als Nächstes die folgenden Schritte aus, um die Sicherung des primären AKS-Clusters auf dem sekundären AKS-Cluster wiederherzustellen:

Geben Sie im Suchfeld des Azure-Portals Backup center ein, und wählen Sie Backup center aus den Suchergebnissen aus.
Wählen Sie unter Verwalten die Option Sicherungsinstanzen aus. Filtern Sie nach dem Datenquellentyp Kubernetes Services. Suchen Sie die Sicherungsinstanz, die Sie im vorherigen Abschnitt erstellt haben, z. B. <aks-cluster-name>\akseastusmjg032524.
Wählen Sie die Sicherungsinstanz aus.
Wählen Sie Wiederherstellen aus.
Auf der Seite Wiederherstellen ist der Standardbereich Wiederherstellungspunkt. Wählen Sie Zurück aus, um zum Bereich Grundeinstellungen zu wechseln. Wählen Sie für Region wiederherstellen die Option Sekundäre Region und dann Weiter: Wiederherstellungspunkt aus.
Im Bereich Wiederherstellungspunkt wird der aktuelle Operational and Vault-standard-Wiederherstellungspunkt ausgewählt. Behalten Sie die Standardwerte bei, und wählen Sie Weiter: Wiederherstellungsparameter aus.
Führen Sie im Bereich Parameter wiederherstellen die folgenden Schritte aus:
1. Wählen Sie für Zielcluster auswählen den sekundären AKS-Cluster aus, den Sie in der Region „USA, Westen“ erstellt haben. Es tritt ein Berechtigungsproblem auf, wie im folgenden Screenshot angezeigt. Wählen Sie Berechtigung erteilen aus, um die Fehler zu beheben.
2. Wählen Sie für Sicherungs-Stagingstandort das Speicherkonto aus, das Sie in der Region „USA, Westen“ erstellt haben. Es tritt ein Berechtigungsproblem auf, wie im folgenden Screenshot angezeigt. Wählen Sie Fehlende Rollen zuweisen aus, um die Fehler zu beheben.
3. Wenn die Fehler nach Abschluss der Rollenzuweisungen weiterhin auftreten, wählen Sie Erneut überprüfen aus, um die Berechtigungen zu aktualisieren.
4. Wenn Sie fehlende Berechtigungen erteilen, akzeptieren Sie den Standardwert, wenn Sie zum Angeben eines Umfangs aufgefordert werden.
5. Wählen Sie Überprüfen aus. Dann sollte die Meldung Validation completed successfully angezeigt werden. Wenn nicht, behandeln und beheben Sie das Problem, bevor Sie fortfahren.
Klicken Sie auf Weiter: Überprüfen + Wiederherstellen. Dann wählen Sie Wiederherstellen aus. Die Wiederherstellung des Clusters dauert ca. 10 Minuten.
Sie können den Wiederherstellungsprozess aus Backup center>Überwachung + Berichterstellung>Sicherungsaufträge überwachen, wie im folgenden Screenshot angezeigt:
Warten Sie einen Moment, und wählen Sie dann Aktualisieren aus. Wiederholen Sie den Vorgang, bis Sie sehen, dass der Status in Abgeschlossen geändert wird.

Führen Sie dann die folgenden Schritte aus, um zu überprüfen, ob die Wiederherstellung wie erwartet funktioniert:

Wechseln Sie zum Terminal, an dem Sie mit dem sekundären AKS-Cluster verbunden sind.

Führen Sie den folgenden Befehl aus, um die Beispiel-App aus der Sicherung wiederherzustellen:

kubectl get OpenLibertyApplication

In der Ausgabe sollte eine READY-Anwendung angezeigt werden:

NAME                       IMAGE                                 EXPOSED   RECONCILED   RESOURCESREADY   READY   AGE
javaee-cafe-cluster-agic   acr3984d1.azurecr.io/javaee-cafe:v1             True         True             True    3m

Führen Sie den folgenden Befehl aus, um den Status der während der Bereitstellung erstellten Pods abzurufen:

kubectl get pods

In der Ausgabe sollten drei Pods angezeigt werden, die ausgeführt werden:

NAME                                        READY   STATUS    RESTARTS   AGE
javaee-cafe-cluster-agic-7bb57dd945-6ljll   1/1     Running   0          3m
javaee-cafe-cluster-agic-7bb57dd945-h2xdf   1/1     Running   0          3m
javaee-cafe-cluster-agic-7bb57dd945-k744w   1/1     Running   0          3m

Wechseln Sie zur Browserregisterkarte Ihres Traffic Manager-Profils, und aktualisieren Sie dann die Seite, bis Sie sehen, dass der Überwachungsstatus für den Endpunkt myFailoverEndpoint Online und der Überwachungsstatus für den Endpunkt myPrimaryEndpoint Herabgestuft lautet.
Wechseln Sie zur Browserregisterkarte mit dem DNS-Namen des Traffic Manager-Profils, z. B. https://tmprofile-mjg032524.trafficmanager.net. 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.

Hinweis

Die App konfiguriert das Sitzungstimeout als 1 Stunde. Je nachdem, wie viel Zeit für das Failover 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.

Erneutes Schützen des Failoverstandorts

Da die sekundäre Region nun der Failoverstandort und aktiv ist, sollten Sie sie mit Azure Backup erneut schützen.

Führen Sie zunächst die gleichen Schritte im Abschnitt Sichern des AKS-Clusters aus, um den sekundären AKS-Cluster zu sichern, mit Ausnahme der folgenden Unterschiede:

Führen Sie für Sicherungstresor erstellen die folgenden Schritte aus:
1. Wählen Sie für Ressourcengruppe die vorhandene Ressourcengruppe aus, die in der sekundären Region bereitgestellt wurde, z. B. liberty-aks-westus-mjg032524.
2. Geben Sie für Sicherungstresorname einen eindeutigen Wert ein, z. B. aks-backup-vault-westus-mjg032524.
3. Wählen Sie unter Region die Option USA, Westen aus.
Führen Sie für Sicherungsrichtlinie erstellen die folgenden Schritte aus:
1. Wählen Sie den Sicherungstresor aus, den Sie in der sekundären Region erstellt haben, z. B. aks-backup-vault-westus-mjg032524.
Verwenden Sie für Sicherungen konfigurieren die folgenden Schritte:
1. Wählen Sie den Sicherungstresor aus, den Sie in der sekundären Region erstellt haben, z. B. aks-backup-vault-westus-mjg032524.
2. Geben Sie für Sicherungsinstanzname einen eindeutigen Namen ein, z. B. akswestusmjg032524.

Verwenden Sie dann dieselben Schritte im Abschnitt Warten, bis eine Vault-Standardsicherung ausgeführt wird., um zu warten, bis die Sicherung „Vault-standard“ des sekundären AKS-Clusters verfügbar ist. Die Ausnahme besteht darin, dass Sie die Sicherungsinstanz auf der Seite Sicherung des sekundären AKS-Clusters auswählen.

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 AKS-Cluster durchzuführen, mit Ausnahme der folgenden Unterschiede:

Wenn Sie sich auf den Failback vorbereiten, führen Sie die folgenden Schritte aus:
1. Beenden Sie den sekundären AKS-Cluster, um einen Ausfall der sekundären Region zu simulieren.
2. Starten Sie den primären AKS-Cluster.
3. Stellen Sie eine Verbindung mit dem primären AKS-Cluster her, und bereinigen Sie WebSphere Liberty/Open Liberty-Anwendungen.
Wenn Sie die Sicherung des sekundären AKS-Clusters auf dem primären AKS-Cluster wiederherstellen, gehen Sie wie folgt vor:
1. Wählen Sie die Sicherungsinstanz in der sekundären Region aus, z. B. <aks-cluster-name>\akswestusmjg032524.
2. Verwenden Sie im Bereich Wiederherstellungsparameter die folgenden Schritte:
  1. Wählen Sie für Zielcluster auswählen den primären AKS-Cluster aus, den Sie in der Region „USA, Osten“ erstellt haben.
  2. Wählen Sie für Sicherungs-Stagingstandort das Speicherkonto aus, das Sie in der Region „USA, Osten“ erstellt haben.
Wenn Sie überprüfen, dass die Wiederherstellung wie erwartet funktioniert, verwenden Sie die folgenden Schritte:
1. Wechseln Sie zum Terminal, in dem Sie eine Verbindung mit dem primären AKS-Cluster hergestellt haben, und überprüfen Sie, ob die App erfolgreich wiederhergestellt wurde.
2. Wechseln Sie zur Browserregisterkarte Ihres Traffic Manager-Profils, und aktualisieren Sie dann die Seite, bis Sie sehen, dass der Überwachungsstatus für den Endpunkt myPrimaryEndpointOnline und der Überwachungsstatus für den Endpunkt myFailoverEndpointHerabgestuft lautet.

Bereinigen von Ressourcen

Wenn Sie die WebSphere Liberty/Open Liberty-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 Lernprogramm verwendeten Ressourcen zu bereinigen:

Geben Sie im Azure-Portal im Suchfeld den Ressourcengruppennamen Azure SQL-Datenbank Server ein, z. B. myResourceGroup, 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 des Azure-Portals Sicherungstresore ein, und wählen Sie Sicherungstresore aus den Suchergebnissen aus. Es sollten zwei Sicherungstresore aufgeführt sein, z. B. aks-backup-vault-eastus-mjg032524 und aks-backup-vault-westus-mjg032524. Führen Sie für jede die folgenden Schritte aus:
1. Wählen Sie diese Option aus, um den Sicherungstresor zu öffnen.
2. Wählen Sie Verwalten>Eigenschaften>Vorläufiges Löschen>Aktualisieren aus. Deaktivieren Sie neben Aktivieren von „Vorläufiges Löschen“ das Kontrollkästchen, und aktivieren Sie Aktualisieren.
3. Wählen Sie Verwalten>Sicherungsinstanzen aus. Filtern Sie nach dem Datenquellentyp Kubernetes Services. Wählen Sie die erstellte Instanz aus, und löschen Sie sie dann.
Warten Sie, bis die beiden Sicherungsinstanzen gelöscht werden.
Wiederholen Sie die Schritte 1–4 für die Ressourcengruppe des primären Clusters, z. B. liberty-aks-eastus-mjg032524.
Wiederholen Sie die Schritte 1–4 für die Ressourcengruppe des sekundären Clusters, z. B. liberty-aks-westus-mjg032524.

Nächste Schritte

In diesem Tutorial richten Sie eine WebSphere Liberty/Open Liberty 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 Azure Backup 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