Självstudie: Migrera WebSphere Liberty/Open Liberty till Azure Kubernetes Service (AKS) med hög tillgänglighet och haveriberedskap

Artikel
05/17/2024

Den här självstudien visar ett enkelt och effektivt sätt att implementera hög tillgänglighet och haveriberedskap (HA/DR) för Java med hjälp av WebSphere Liberty/Open Liberty på Azure Kubernetes Service (AKS). Lösningen visar hur du uppnår ett rto-mål (Low Recovery Time Objective) och Recovery Point Objective (RPO) med hjälp av ett enkelt databasdrivet Jakarta EE-program som körs på WebSphere Liberty/Open Liberty.

HA/DR är ett komplext ämne med många möjliga lösningar. Den bästa lösningen beror på dina unika krav. Andra sätt att implementera HA/DR finns i resurserna i slutet av den här artikeln.

I den här självstudien lär du dig att:

Använd azure-optimerade metodtips för att uppnå hög tillgänglighet och haveriberedskap.
Konfigurera en Redundansgrupp för Microsoft Azure SQL Database i parkopplade regioner.
Konfigurera det primära WebSphere Liberty/Open Liberty-klustret på AKS.
Konfigurera haveriberedskap för klustret med hjälp av Azure Backup.
Konfigurera det sekundära AKS-klustret.
Konfigurera en Azure Traffic Manager.
Testa redundans från primär till sekundär.

Följande diagram illustrerar arkitekturen som du skapar:

Azure Traffic Manager kontrollerar hälsotillståndet för dina regioner och dirigerar trafiken enligt programnivån. Både den primära regionen och den sekundära regionen har en fullständig distribution av Liberty-klustret. Det är dock bara den primära regionen som aktivt hanterar nätverksbegäranden från användarna. Den sekundära regionen är passiv och aktiveras för att endast ta emot trafik när den primära regionen upplever ett avbrott i tjänsten. Azure Traffic Manager använder hälsokontrollfunktionen i Azure Application Gateway för att implementera den här villkorliga routningen. Det primära klustret körs och det sekundära klustret stängs av. RTO för geo-redundans på programnivån beror på tiden för att starta virtuella datorer och köra det sekundära klustret. RPO:et är beroende av Azure SQL Database eftersom data sparas och replikeras i Azure SQL Database-redundansgruppen.

Databasnivån består av en Azure SQL Database-redundansgrupp med en primär server och en sekundär server. Läs-/skrivlyssningsslutpunkten pekar alltid på den primära servern och är ansluten till ett WebSphere Liberty/Open Liberty-kluster i varje region. En geo-redundansväxlar alla sekundära databaser i gruppen till den primära rollen. Information om RPO för geo-redundans och RTO för Azure SQL Database finns i Översikt över affärskontinuitet med Azure SQL Database.

Den här självstudien skrevs med Azure Backup- och Azure SQL Database-tjänsterna eftersom självstudien förlitar sig på ha-funktionerna i dessa tjänster. Andra databasval är möjliga, men du måste överväga ha-funktionerna i vilken databas du än väljer.

Förutsättningar

En Azure-prenumeration. Om du inte har en Azure-prenumeration kan du skapa ettkostnadsfritt konto innan du börjar.
Kontrollera att du har tilldelats rollen Owner eller rollerna Contributor och User Access Administrator i prenumerationen. Du kan verifiera tilldelningen genom att följa stegen i Lista Azure-rolltilldelningar med hjälp av Azure Portal.
Förbered en lokal dator med Windows, Linux eller macOS installerat.
Installera och konfigurera Git.
Installera en Java SE-implementering, version 17 eller senare, till exempel Microsoft-versionen av OpenJDK.
Installera Maven, version 3.9.3 eller senare.

Konfigurera en Azure SQL Database-redundansgrupp i parkopplade regioner

I det här avsnittet skapar du en Azure SQL Database-redundansgrupp i parkopplade regioner för användning med dina WebSphere Liberty/Open Liberty-kluster och din app. I ett senare avsnitt konfigurerar du WebSphere Liberty/Open Liberty så att dess sessionsdata lagras i den här databasen. Den här metoden refererar till Att skapa en tabell för sessionspersistence.

Skapa först den primära Azure SQL Database genom att följa de Azure Portal stegen i Snabbstart: Skapa en enkel databas – Azure SQL Database. Följ stegen upp till, men inte inkludera, avsnittet "Rensa resurser". Använd följande anvisningar när du går igenom artikeln och gå sedan tillbaka till den här artikeln när du har skapat och konfigurerat Azure SQL Database.

När du kommer till avsnittet Skapa en enkel databas använder du följande steg:

I steg 4 för att skapa en ny resursgrupp sparar du värdet Resursgruppnamn , till exempel myResourceGroup.
Spara värdet Databasnamn åt sidan i steg 5 för databasnamn, mySampleDatabasetill exempel .
I steg 6 för att skapa servern använder du följande steg:
1. Fyll i ett unikt servernamn – till exempel sqlserverprimary-mjg032524.
2. För Plats väljer du (USA) USA, östra.
3. Som Autentiseringsmetod väljer du Använd SQL-autentisering.
4. Spara åt sidan för inloggningsvärdet serveradministratör – till exempel azureuser.
5. Spara lösenordet åt sidan.
I steg 8 väljer du Utveckling för Arbetsbelastningsmiljö. Titta på beskrivningen och överväg andra alternativ för din arbetsbelastning.
I steg 11 för Redundans för säkerhetskopieringslagring väljer du Lokalt redundant lagring av säkerhetskopiering. Överväg andra alternativ för dina säkerhetskopior. Mer information finns i avsnittet Säkerhetskopieringslagringsredundans i Automatiserade säkerhetskopieringar i Azure SQL Database.
I steg 14 går du till konfigurationen brandväggsregler och väljer Ja för Tillåt Azure-tjänster och resurser att komma åt den här servern.

Skapa sedan en Azure SQL Database-redundansgrupp genom att följa de Azure Portal stegen i Konfigurera en redundansgrupp för Azure SQL Database. Du behöver bara följande avsnitt: Skapa redundansgrupp och Testa planerad redundans. Följ stegen nedan när du går igenom artikeln och gå sedan tillbaka till den här artikeln när du har skapat och konfigurerat redundansgruppen för Azure SQL Database:

När du kommer till avsnittet Skapa redundansgrupp använder du följande steg:
1. I steg 5 för att skapa redundansgruppen anger du och sparar det unika redundansgruppens namn , till exempel failovergroup-mjg032524.
2. I steg 5 för att konfigurera servern väljer du alternativet för att skapa en ny sekundär server och använder sedan följande steg:
  1. Ange ett unikt servernamn – till exempel sqlserversecondary-mjg032524.
  2. Ange samma serveradministratör och lösenord som din primära server.
  3. För Plats väljer du (USA) USA, västra.
  4. Kontrollera att Tillåt Azure-tjänster att komma åt servern är valt.
3. I steg 5 för att konfigurera databaserna i gruppen väljer du den databas som du skapade på den primära servern , till exempel mySampleDatabase.
När du har slutfört alla steg i avsnittet Testa planerad redundans håller du sidan för redundansgruppen öppen och använder den för redundanstestet av WebSphere Liberty/Open Liberty-kluster senare.

Konfigurera det primära WebSphere Liberty/Open Liberty-klustret på AKS

I det här avsnittet skapar du det primära WebSphere Liberty/Open Liberty-klustret på AKS med hjälp av IBM WebSphere Liberty och Open Liberty i Azure Kubernetes Service-erbjudandet . Det sekundära klustret återställs från det primära klustret under redundansväxlingen med Azure Backup senare.

Distribuera det primära WebSphere Liberty/Open Liberty-klustret

Använd följande steg för att distribuera det primära klustret:

Öppna IBM WebSphere Liberty och Open Liberty på Azure Kubernetes Service-erbjudandet i webbläsaren och välj Skapa. Du bör se fönstret Grundläggande i erbjudandet.
Använd följande steg för att fylla i fönstret Grundläggande :
1. Kontrollera att värdet som visas för Prenumeration är samma som har de roller som anges i avsnittet för förhandskrav.
2. Du måste distribuera erbjudandet i en tom resursgrupp. I fältet Resursgrupp väljer du Skapa ny och fyller i ett unikt värde för resursgruppen , till exempel liberty-aks-eastus-mjg032524.
3. Under Instansinformation väljer du USA, östra för Region.
4. Välj Nästa för att gå till AKS-fönstret.
Vänta ett tag. Du bör se alla fält ifyllda med standardvärdena i AKS-fönstret. Välj Nästa för att gå till fönstret Belastningsutjämning .
Använd följande steg för att fylla i fönstret Belastningsutjämning:
1. För Anslut till Azure Application Gateway? väljer du Ja.
2. Lämna standardvärdena för andra fält.
3. Välj Nästa för att gå till fönstret Operator och program .
Använd följande steg för att fylla i fönstret Operator och program :
1. Lämna standardvärdena för alla fält.
  
  Kommentar
  
  Den här självstudien distribuerar Open Liberty Operator med standardvärdena. Du kan också distribuera WebSphere Liberty Operator genom att välja Ja för IBM som stöds?.
2. Välj Granska + skapa.
3. Vänta tills den slutgiltiga verifieringen har körts... har slutförts och välj sedan Skapa.

Efter ett tag bör du se sidan Distribution där distribution pågår visas.

Kommentar

Om du ser några problem när du kör den slutliga valideringen... kan du åtgärda dem och försöka igen.

Beroende på nätverksförhållanden och annan aktivitet i den valda regionen kan distributionen ta upp till cirka 30 minuter att slutföra. Därefter bör du se texten Distributionen är klar visas på distributionssidan.

Kontrollera distributionen av klustret

Du har distribuerat ett AKS-kluster, en Azure Container Registry-instans (ACR) och en Azure Application Gateway i den primära regionen. AKS-klustret är målplattformen för databehandling där din app distribueras och körs. ACR-instansen lagrar den programbild som AKS hämtar under appdistributionen. Azure Application Gateway fungerar som lastbalanserare för programmet som distribueras till AKS-klustret.

Använd följande steg för att verifiera dessa nyckelkomponenter innan du går vidare till nästa steg:

Gå tillbaka till sidan Distribution och välj sedan Utdata.
Kopiera värdet för egenskapen cmdToConnectToCluster. Öppna en terminal, klistra in det kopierade kommandot och tryck på Retur för att köra. Du bör se ett meddelande som liknar följande exempel som ingår i utdata:
```
Merged "cluster3984d1-admin" as current context in <your-user>\.kube\config
```
Spara kommandot åt sidan så att du kan använda det för att ansluta till klustret senare.

Kör kubectl get pod --all-namespaces i terminalen för att visa en lista över alla poddar som körs i AKS-klustret. Du bör se utdata som liknar följande exempel:

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

Kör kubectl get secret i terminalen för att visa en lista över alla hemligheter som är installerade i AKS-klustret. Du bör se en hemlighet i utdata, som du ser i följande exempel:
```
NAME           TYPE                DATA   AGE
secret3984d1   kubernetes.io/tls   2      24m
```
Den här hemligheten är en TLS-hemlighet som innehåller certifikat- och nyckeldata för TLS-trafik. Kopiera och spara namnet på hemligheten , till exempel secret3984d1, du använder den i appdistributionen senare.
Växla tillbaka till sidan Utdata . Kopiera värdet för egenskapen cmdToLoginInRegistry. Klistra in det kopierade kommandot i terminalen och tryck på Retur för att köra. Du bör se Inloggningen lyckades i utdata. Håll terminalen öppen och använd den för ytterligare konfiguration av WebSphere Liberty/Open Liberty-klustret senare.

Använd följande steg för att hämta namnet och DNS-namnet på den offentliga IP-adressen för Azure Application Gateway. Du använder dem för appdistribution och Azure Traffic Manager-konfigurationen senare.

I Azure Portal i sökrutan anger du Resursgrupper och väljer Resursgrupper i sökresultaten.
Välj namnet på resursgruppen för den primära regionen , till exempel liberty-aks-eastus-mjg032524.
Leta reda på den offentliga IP-adressresursen med gwipprefixet och kopiera och spara dess namn.
Välj den offentliga IP-adressresursen och kopiera och spara dns-namnet åt sidan, olgw3984d1.eastus.cloudapp.azure.comtill exempel .

Aktivera geo-replikering för ACR-instansen

ACR-instansen är utformad för att lagra programavbildningar för både primära och sekundära kluster. Använd följande steg för att aktivera geo-replikering för ACR-instansen:

I Azure Portal i sökrutan anger du Resursgrupper och väljer Resursgrupper i sökresultaten.
Välj namnet på resursgruppen för den primära regionen , till exempel liberty-aks-eastus-mjg032524.
Leta upp containerregisterresursen med prefixet acroch välj den sedan för att öppna den.
Välj Egenskaper. För Prisplan väljer du Premium och sedan Spara. Vänta tills processen är klar.
Välj Geo-replikering och välj sedan Lägg till. För Plats väljer du USA, västra och sedan Skapa. Vänta tills processen är klar.
Vänta ett tag och välj Uppdatera. Upprepa åtgärden tills du ser att två platser visas och Status är Klar.

Använd följande steg för att hämta autentiseringsuppgifterna för ACR-inloggning. Du använder dem för appdistribution senare.

Välj Åtkomstnycklar.
Kopiera och spara värdet för inloggningsserver, användarnamn och lösenord.

Distribuera en exempelapp

Använd följande steg för att distribuera och köra ett CRUD Java/Jakarta EE-exempelprogram på WebSphere Liberty/Open Liberty-kluster för redundanstest för haveriberedskap senare:

Ladda ned exemplet med hjälp av följande kommandon:
```
git clone https://github.com/Azure-Samples/open-liberty-on-aks.git
cd open-liberty-on-aks
export BASE_DIR=$PWD
git checkout 20240325
```
Programmet konfigurerar en datakälla jdbc/JavaEECafeDB som ansluter till den Azure SQL Database som du distribuerade tidigare. Datakällan används för att lagra HTTP-sessionsdata, vilket möjliggör redundans och belastningsutjämning över ett kluster av WebSphere Liberty/Open Liberty-servrar. Exempelappen konfigurerar också ett beständigt schema för att bevara programdata coffee i samma datakälla. Observera att kontextroten i exemplet har konfigurerats som / i server.xml-filen.

Använd följande kommandon för att definiera miljövariabler med de värden som du sparade åt sidan tidigare:

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>

Använd följande kommandon för att paketera appen, skapa Docker-avbildningen, skicka avbildningen till ACR-instansen och distribuera exemplet till AKS-klustret:

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

Kör följande kommando för att hämta exempelappen som du distribuerade:

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

Du bör se ett READY-program i utdata:

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

Kör följande kommando för att hämta status för de poddar som skapades under distributionen:

kubectl get pods

Följande exempel anger att alla poddar körs. Om du inte ser liknande utdata väntar du ett tag och upprepar åtgärden.

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

Använd följande steg för att kontrollera att appen körs som förväntat:
1. På en ny webbläsarflik öppnar du DNS-namnet på den offentliga IP-adressen för Azure Application Gateway som du sparade åt sidan tidigare. Använd protokollet https , till exempel https://olgw3984d1.eastus.cloudapp.azure.com. Du bör se välkomstsidan för exempelappen.
2. Skapa en ny kaffe med namn och pris – till exempel Kaffe 1 med pris 10 – som sparas i både programdatatabellen och sessionstabellen i databasen. Användargränssnittet som du ser bör likna följande skärmbild:
Om användargränssnittet inte ser liknande ut kan du felsöka och lösa problemet innan du fortsätter.

Konfigurera haveriberedskap för klustret med Azure Backup

I det här avsnittet konfigurerar du haveriberedskap för AKS-klustret i den primära regionen med hjälp av Azure Backup.

Skapa ett lagringskonto

AKS-säkerhetskopiering använder en blobcontainer för att lagra AKS-klusterresurserna. Du skapar en annan blobcontainer som mellanlagringsplats för användning under återställning mellan regioner.

Använd följande steg för att skapa ett lagringskonto och två containrar. Vissa av de här stegen leder dig till andra guider.

Logga in på Azure-portalen.
Skapa ett lagringskonto genom att följa stegen i Skapa ett lagringskonto. Du behöver inte utföra alla steg i artikeln. Fyll i fälten som visas i fönstret Grundläggande med hjälp av följande steg:
1. För Resursgrupp väljer du den befintliga resursgrupp där det primära klustret distribueras , till exempel liberty-aks-eastus-mjg032524.
2. Som Lagringskontonamn anger du ett unikt namn , till exempel storageeastusmjg032524.
3. För Region väljer du USA, östra.
4. Välj Granska + skapa för att acceptera standardalternativen.
5. Fortsätt att verifiera och skapa kontot och gå sedan tillbaka till den här artikeln.
Skapa en lagringscontainer för AKS Backup-tillägget genom att följa stegen i Skapa en lagringscontainer. Den här guiden använder aks-backup-ext som containernamn.
Skapa en annan lagringscontainer som en mellanlagringsplats för användning under återställningen. Den här guiden använder staging som containernamn.

Aktivera AKS-säkerhetskopieringstillägget

Innan du fortsätter använder du följande steg för att installera AKS Backup-tillägget i klustret i den primära regionen:

Aktivera CSI-drivrutiner och ögonblicksbilder för klustret. För följande az aks update kommando uppdaterar du värdet för Bash-variabeln RG_NAME till resursgruppens namn, till exempel liberty-aks-eastus-mjg032524 , och kör i din lokala Bash-terminal.
```
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
```
Det tar cirka 5 minuter att aktivera drivrutinerna. Kontrollera att kommandona har slutförts utan fel innan du fortsätter.
Öppna den resursgrupp som har AKS distribuerat – till exempel liberty-aks-eastus-mjg032524. Välj AKS-klustret från resurslistan.
Under Inställningar för AKS-landningssidan väljer du Säkerhetskopiera och sedan Installera tillägg.
På sidan Installera AKS Backup-tillägget väljer du Nästa. Välj lagringskontot storageeastusmjg032524 och blobcontainern aks-backup-ext som skapats i samma resursgrupp. Välj Nästa och sedan Skapa. Det tar ungefär fem minuter att slutföra det här steget.

Säkerhetskopiera AKS-klustret

Använd följande steg för att säkerhetskopiera AKS-klustret:

I Azure Portal söker du efter Säkerhetskopieringsvalv i sökrutan. Du ser den under Tjänster. Välj den.
Följ stegen i Säkerhetskopiera Azure Kubernetes Service med hjälp av Azure Backup för att aktivera AKS Backup för det primära klustret. Kör stegen upp till, men inte inklusive, avsnittet Använd krokar under AKS-säkerhetskopiering och använd resten av stegen i det här avsnittet för att göra justeringar när du går.
När du kommer till avsnittet Skapa ett säkerhetskopieringsvalv använder du följande steg:
1. För steg 1 för Resursgrupp väljer du den befintliga resursgrupp där det primära klustret distribueras , till exempel liberty-aks-eastus-mjg032524.
2. Som Backup-valvnamn anger du ett unikt värde , till exempel aks-backup-vault-eastus-mjg032524.
3. För Region väljer du USA, östra.
4. För Redundans för säkerhetskopieringslagring väljer du Globalt redundant.
5. För steg 2 väljer du Aktivera för Återställning mellan regioner.
När du kommer till avsnittet Skapa en säkerhetskopieringsprincip använder du följande steg:
1. För steg 3 anger du ett namn för säkerhetskopieringsprincipen , till exempel aksbackuppolicy.
2. Välj det Säkerhetskopieringsvalv som du skapade i samma resursgrupp , till exempel aks-backup-vault-eastus-mjg032524.
3. För steg 4 lägger du till en kvarhållningsregel där Vault-standard har valts.
4. Markera Lägga till.
I avsnittet Konfigurera säkerhetskopior använder du följande steg:
1. Hoppa över steg 1–5, som gäller installation av AKS-tillägg. Börja från steg 6 för AKS-klustret i den primära regionen.
2. För steg 7 för Valv väljer du det säkerhetskopieringsvalv som du skapade i samma resursgrupp, till exempel aks-backup-vault-eastus-mjg032524. När du stöter på behörighetsfel väljer du Bevilja behörigheter för att gå vidare. När behörighetsdistributionen har slutförts väljer du Omvalidera för att uppdatera rolltilldelningarna om felet fortfarande visas.
3. För steg 10 hittar du Välj resurser som ska säkerhetskopieras. För Namnet på säkerhetskopieringsinstansen fyller du i ett unikt namn , till exempel akseastusmjg032524. För Andra alternativ väljer du alla alternativ. Kontrollera att Inkludera hemligheter är markerat.
4. För steg 11 stöter du på ett rolltilldelningsfel. Följ steg 12–14 för att åtgärda felet.
5. När du har valt Konfigurera säkerhetskopiering i steg 15 går du tillbaka till sidan Säkerhetskopiering . Vänta en stund och välj sedan Uppdatera. Upprepa åtgärden tills du ser att säkerhetskopieringsinstansen visas och dess skyddsstatus är Skydd konfigurerat.

Vänta tills en säkerhetskopia av valvstandard inträffar

I AKS är valvstandardnivån den enda nivån som stöder geo-redundans och återställning mellan regioner. Som anges i Vilken lagringsnivå för säkerhetskopiering stöder AKS-säkerhetskopiering?, "Endast en schemalagd återställningspunkt per dag flyttas till valvnivå." Du måste vänta tills en säkerhetskopia av valvstandard inträffar. En bra nedre gräns är att vänta högst 24 timmar efter att du slutfört föregående steg innan du återställer.

Använd följande steg för att kontrollera att en säkerhetskopia av valvstandard är tillgänglig:

På sidan Säkerhetskopiering i det primära AKS-klustret väljer du säkerhetskopieringsinstansen.
Vänta ett tag och välj Uppdatera. Upprepa åtgärden tills du ser att minst en återställningspunkt av drifts- och valvstandard visas i avsnittet ÅTERSTÄLLNINGSPUNKTER .

Konfigurera det sekundära AKS-klustret

I väntan på att en säkerhetskopia av valvstandard ska ske för det primära AKS-klustret konfigurerar du ditt sekundära AKS-kluster för återställning senare.

Använd samma steg i avsnittet Distribuera det primära WebSphere Liberty/Open Liberty-klustret för att konfigurera det sekundära AKS-klustret i den sekundära regionen, förutom följande skillnader:

I fönstret Grundläggande använder du följande steg:
1. I fältet Resursgrupp väljer du Skapa ny och fyller i ett annat unikt värde för resursgruppen , till exempel liberty-aks-westus-mjg032524.
2. Under Instansinformation väljer du USA, västra för Region.
I AKS-fönstret använder du följande steg:
1. Under Azure Container Registry (ACR) för Välj ACR-instans väljer du Nej.
2. Välj den befintliga ACR-instansen i den primära regionen som har aktiverats med geo-replikering.

Använd samma steg i avsnittet Verifiera distributionen av klustret för att verifiera distributionen i den sekundära regionen, förutom följande skillnader:

Du behöver inte kopiera och spara namnet på TLS-hemligheten åt sidan. TLS-hemligheten återställs från säkerhetskopieringen av det primära AKS-klustret.
Använd resursgruppen för det sekundära klustret – till exempel liberty-aks-westus-mjg032524 – när du letar upp namnet och DNS-namnet på den offentliga IP-adressen för Azure Application Gateway som distribuerats i den sekundära regionen.

Använd samma steg i avsnittet Skapa ett lagringskonto för att skapa ett lagringskonto i den sekundära regionen, förutom följande skillnader:

I fältet Resursgrupp väljer du den befintliga resursgrupp där det sekundära klustret distribueras , till exempel liberty-aks-westus-mjg032524.
Som Lagringskontonamn anger du ett unikt namn , till exempel storagewestusmjg032524.
För Region väljer du USA, västra.

Använd samma steg i avsnittet Aktivera AKS Backup-tillägget för att installera AKS Backup Extension för klustret i den sekundära regionen, förutom följande skillnader:

I steg 1 för att aktivera CSI-drivrutiner och ögonblicksbilder för ditt sekundära kluster uppdaterar du värdet för Bash-variabeln RG_NAME till resursgruppen i den sekundära regionen , liberty-aks-westus-mjg032524till exempel .
I steg 2 väljer du AKS-klustret från resursgruppen i den sekundära regionen , till exempel liberty-aks-westus-mjg032524.
I steg 4 för att installera AKS Backup-tillägget för ditt sekundära kluster väljer du det lagringskonto som du skapade i samma resursgrupp i den sekundära regionen , till exempel storagewestusmjg032524.

För att spara kostnader stoppar du AKS-klustret i den sekundära regionen genom att följa stegen i Stoppa och starta ett AKS-kluster (Azure Kubernetes Service). Du måste starta det innan du återställer klustret senare.

Konfigurera en Azure Traffic Manager

Säkerhetskopia av valvstandard nämndes i avsnittet Vänta tills en säkerhetskopia av valvstandard ska ske. När du ser att en säkerhetskopia av valvstandard är tillgänglig kan du skapa en Azure Traffic Manager för att distribuera trafik till dina offentliga program i de globala Azure-regionerna. Den primära slutpunkten pekar på den offentliga IP-adressen för Azure Application Gateway i den primära regionen. Den sekundära slutpunkten pekar på den offentliga IP-adressen för Azure Application Gateway i den sekundära regionen.

Skapa en Azure Traffic Manager-profil genom att följa stegen i Snabbstart: Skapa en Traffic Manager-profil med hjälp av Azure Portal. Du behöver bara följande avsnitt: Skapa en Traffic Manager-profil och Lägg till Traffic Manager-slutpunkter. Använd följande steg när du går igenom de här avsnitten och gå sedan tillbaka till den här artikeln när du har skapat och konfigurerat Azure Traffic Manager:

När du kommer till avsnittet Skapa en Traffic Manager-profil använder du följande steg i steg 2 för Att skapa Traffic Manager-profil:
1. Som Namn anger du ett unikt Traffic Manager-profilnamn – till exempel tmprofile-mjg032524.
2. För Routningsmetod väljer du Prioritet.
3. För Resursgrupp anger och sparar du det nya resursgruppens namn , till exempel myResourceGroupTM1.
När du kommer till avsnittet Lägg till Traffic Manager-slutpunkter använder du följande steg:
1. När du har öppnat Traffic Manager-profilen i steg 2 går du till sidan Konfiguration och använder följande steg:
  1. Ange 10 för TTL (DNS time to live).
  2. Under Inställningar för slutpunktsövervakare för Protokoll väljer du https och för Port anger du 443.
  3. Under Inställningar för snabb slutpunktsredundans använder du följande värden:
    - För Avsökning internt väljer du 10.
    - För Tolererat antal fel anger du 3.
    - För timeout för avsökning anger du 5.
  4. Välj Spara. Vänta tills den är klar.
2. I steg 4 för att lägga till den primära slutpunkten myPrimaryEndpointanvänder du följande steg:
  1. Som Målresurstyp väljer du Offentlig IP-adress.
  2. Välj listrutan Välj offentlig IP-adress och ange namnet på den offentliga IP-adressen för Azure Application Gateway i regionen USA, östra som du sparade åt sidan tidigare. Du bör se en post matchad. Välj den för offentlig IP-adress.
3. I steg 6 för att lägga till en redundans/sekundär slutpunkt myFailoverEndpointanvänder du följande steg:
  1. Som Målresurstyp väljer du Offentlig IP-adress.
  2. Välj listrutan Välj offentlig IP-adress och ange namnet på den offentliga IP-adressen för Azure Application Gateway i regionen USA, västra som du sparade åt sidan tidigare. Du bör se en post matchad. Välj den för offentlig IP-adress.
4. Vänta ett tag. Välj Uppdatera tills övervakningsstatusen för slutpunkten myPrimaryEndpoint är Online och Övervakningsstatus för slutpunkten myFailoverEndpoint har degraderats.

Använd sedan följande steg för att kontrollera att exempelappen som distribueras till det primära klustret är tillgänglig från Traffic Manager-profilen:

Välj Översikt över Traffic Manager-profilen som du skapade.
Kontrollera och kopiera ned DNS-namnet på Traffic Manager-profilen och ersätt protokollet http med https. Exempel: https://tmprofile-mjg032524.trafficmanager.net
Öppna URL:en på en ny webbläsarflik. Du bör se att kaffet som du skapade tidigare visas på sidan.
Skapa ytterligare en kaffe med ett annat namn och pris – till exempel Kaffe 2 med pris 20 – som sparas i både programdatatabellen och sessionstabellen i databasen. Användargränssnittet som du ser bör likna följande skärmbild:

Om användargränssnittet inte ser liknande ut kan du felsöka och lösa problemet innan du fortsätter. Håll konsolen öppen och använd den för redundanstestet senare.

Du har slutfört konfigurationen av Traffic Manager-profilen. Håll sidan öppen och du använder den för att övervaka ändringen av slutpunktens status i en redundanshändelse senare.

Testa redundans från primär till sekundär

I det här avsnittet redundanstestar du manuellt Azure SQL Database-servern och återställer säkerhetskopieringen av AKS-klustret och redundansväxlar sedan tillbaka med hjälp av Azure Portal.

Redundansväxling till den sekundära platsen

Om du vill simulera ett avbrott i den primära regionen stoppar du det primära AKS-klustret genom att följa stegen i Stoppa och starta ett AkS-kluster (Azure Kubernetes Service).

Starta sedan det sekundära AKS-klustret så att det kan återställas från säkerhetskopieringen av det primära klustret.

Kommentar

Om du har WebSphere Liberty/Open Liberty-program som körs i återställningsmålklustret kan du använda följande steg för att rensa WebSphere Liberty/Open Liberty-program för att undvika konflikter:

Anslut till målklustret genom att köra kommandot för cmdToConnectToCluster det som du sparade åt sidan tidigare.

Kör följande kommando för Open Liberty-program:

kubectl delete OpenLibertyApplication --all --all-namespaces

Kör följande kommando för WebSphere Liberty-program:

kubectl delete WebSphereLibertyApplication --all --all-namespaces

Växla sedan till webbläsarfliken i Traffic Manager-profilen och kontrollera att övervakningsstatusen för båda slutpunkterna myPrimaryEndpoint och myFailoverEndpoint är Degraderad.

Använd nu följande steg för att redundansväxlar Azure SQL Database från den primära servern till den sekundära servern:

Växla till webbläsarfliken i din Azure SQL Database-redundansgrupp – till exempel failovergroup-mjg032524.
Välj Redundans och välj sedan Ja.
Vänta tills den är klar.

Använd sedan följande steg för att återställa säkerhetskopieringen av det primära AKS-klustret till det sekundära AKS-klustret:

I Azure Portal går du till sökrutan och anger Säkerhetskopieringscenter och väljer Säkerhetskopieringscenter i sökresultaten.
Under Hantera väljer du Säkerhetskopieringsinstanser. Filtrera på datakällans typ Kubernetes Services. Leta reda på den säkerhetskopieringsinstans som du skapade i föregående avsnitt , till exempel <aks-cluster-name>\akseastusmjg032524.
Välj säkerhetskopieringsinstansen.
Välj Återställ.
På sidan Återställ är standardfönstret Återställningspunkt. Välj Föregående för att ändra till fönstret Grundläggande . För Återställ region väljer du Sekundär region och sedan Nästa: Återställningspunkt.
I fönstret Återställningspunkt väljs den senaste återställningspunkten För drift och valvstandard . Behåll standardvärdena och välj Nästa: Återställ parametrar.
Använd följande steg i fönstret Återställningsparametrar :
1. För Välj målkluster väljer du det sekundära AKS-kluster som du skapade i regionen USA, västra. Du stöter på ett behörighetsproblem enligt följande skärmbild. Välj Bevilja behörighet för att åtgärda felen.
2. För Mellanlagringsplats för säkerhetskopiering väljer du det lagringskonto som du skapade i regionen USA, västra. Du stöter på ett behörighetsproblem enligt följande skärmbild. Välj Tilldela saknade roller för att åtgärda felen.
3. Om felen fortfarande inträffar när rolltilldelningarna har slutförts väljer du Förnya för att uppdatera behörigheterna.
4. När du beviljar saknade behörigheter godkänner du standardvärdet om du uppmanas att ange ett omfång.
5. Välj validera. Du bör se meddelandet . Validation completed successfully Annars kan du felsöka och lösa problemet innan du fortsätter.
Välj Nästa: Granska + återställ. Välj sedan Återställ. Det tar cirka 10 minuter att återställa klustret.
Du kan övervaka återställningsprocessen från Säkerhetskopieringscenter>Övervakning + rapportering>Säkerhetskopieringsjobb, enligt följande skärmbild:
Vänta ett tag och välj sedan Uppdatera. Upprepa åtgärden tills statusen har slutförts.

Använd sedan följande steg för att kontrollera att återställningen fungerar som förväntat:

Växla till terminalen där du anslöt till det sekundära AKS-klustret.

Kör följande kommando för att återställa exempelappen från säkerhetskopian:

kubectl get OpenLibertyApplication

Du bör se ett READY-program i utdata:

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

Kör följande kommando för att hämta status för de poddar som skapades under distributionen:

kubectl get pods

Du bör se tre poddar som körs i utdata:

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

Växla till webbläsarfliken i Traffic Manager-profilen och uppdatera sedan sidan tills du ser att Övervaka status för slutpunkten myFailoverEndpoint är Online och Övervaka status för slutpunkten myPrimaryEndpoint är Degraderad.
Växla till webbläsarfliken med DNS-namnet på Traffic Manager-profilen , till exempel https://tmprofile-mjg032524.trafficmanager.net. Uppdatera sidan så bör du se samma data som sparas i programdatatabellen och sessionstabellen som visas. Användargränssnittet som du ser bör likna följande skärmbild:

Om du inte ser det här beteendet kan det bero på att Traffic Manager tar tid att uppdatera DNS för att peka på redundansplatsen. Problemet kan också vara att webbläsaren cachelagrade dns-namnmatchningsresultatet som pekar på den misslyckade webbplatsen. Vänta ett tag och uppdatera sidan igen.

Kommentar

Appen konfigurerar tidsgränsen för sessionen som 1 timme. Beroende på hur lång tid det tog att redundansväxlar kan det hända att du inte ser sessionsdata som visas i avsnittet Nytt kaffe i exempelappens användargränssnitt om det upphörde att gälla mer än en timme tidigare.

Skydda redundansplatsen igen

Nu när den sekundära regionen är redundansplatsen och är aktiv bör du skydda den igen med Azure Backup.

Använd först samma steg i avsnittet Säkerhetskopiera AKS-klustret för att säkerhetskopiera det sekundära AKS-klustret, förutom följande skillnader:

Använd följande steg för Att skapa ett säkerhetskopieringsvalv:
1. För Resursgrupp väljer du den befintliga resursgruppen som distribuerats i den sekundära regionen , till exempel liberty-aks-westus-mjg032524.
2. Som Backup-valvnamn anger du ett unikt värde , till exempel aks-backup-vault-westus-mjg032524.
3. För Region väljer du USA, västra.
Använd följande steg för att skapa en säkerhetskopieringsprincip:
1. Välj det säkerhetskopieringsvalv som du skapade i den sekundära regionen , till exempel aks-backup-vault-westus-mjg032524.
För Konfigurera säkerhetskopior använder du följande steg:
1. Välj det säkerhetskopieringsvalv som du skapade i den sekundära regionen , till exempel aks-backup-vault-westus-mjg032524.
2. För Namnet på säkerhetskopieringsinstansen fyller du i ett unikt namn , till exempel akswestusmjg032524.

Använd sedan samma steg i avsnittet Vänta tills en säkerhetskopia av valvstandard inträffar tills en säkerhetskopia av valvstandard för det sekundära AKS-klustret är tillgänglig, förutom att välja säkerhetskopieringsinstansen från sidan Säkerhetskopiering i det sekundära AKS-klustret.

Växla tillbaka till den primära platsen

Använd samma steg i avsnittet Redundansväxling till den sekundära platsen för att återställa till den primära platsen, inklusive databasservern och AKS-klustret, förutom följande skillnader:

När du förbereder för återställning efter fel använder du följande steg:
1. Stoppa det sekundära AKS-klustret för att simulera ett avbrott i den sekundära regionen.
2. Starta det primära AKS-klustret.
3. Anslut till det primära AKS-klustret och rensa WebSphere Liberty/Open Liberty-program.
När du återställer säkerhetskopieringen av det sekundära AKS-klustret till det primära AKS-klustret använder du följande steg:
1. Välj säkerhetskopieringsinstansen i den sekundära regionen , till exempel <aks-cluster-name>\akswestusmjg032524.
2. I fönstret Återställningsparametrar använder du följande steg:
  1. För Välj målkluster väljer du det primära AKS-klustret som du skapade i regionen USA, östra.
  2. För Mellanlagringsplats för säkerhetskopiering väljer du det lagringskonto som du skapade i regionen USA, östra.
När du kontrollerar att återställningen fungerar som förväntat använder du följande steg:
1. Växla till terminalen där du anslöt till det primära AKS-klustret och kontrollera att appen har återställts.
2. Växla till webbläsarfliken i Traffic Manager-profilen och uppdatera sedan sidan tills du ser att Övervaka status för slutpunkten myPrimaryEndpoint är Online och Övervaka status för slutpunkten myFailoverEndpoint är Degraderad.

Rensa resurser

Om du inte kommer att fortsätta att använda WebSphere Liberty/Open Liberty-kluster och andra komponenter använder du följande steg för att ta bort resursgrupperna för att rensa de resurser som används i den här självstudien:

I Azure Portal i sökrutan anger du resursgruppens namn på Azure SQL Database-servrar – till exempel myResourceGroup – och väljer den matchade resursgruppen i sökresultaten.
Välj Ta bort resursgrupp.
I Ange resursgruppens namn för att bekräfta borttagningen anger du resursgruppens namn.
Välj Ta bort.
Upprepa steg 1–4 för resursgruppen i Traffic Manager – till exempel myResourceGroupTM1.
I Azure Portal i sökrutan anger du Säkerhetskopieringsvalv och väljer Säkerhetskopieringsvalv i sökresultaten. Du bör se två säkerhetskopieringsvalv i listan – till exempel aks-backup-vault-eastus-mjg032524 och aks-backup-vault-westus-mjg032524. Använd följande steg för var och en av dem:
1. Välj för att öppna säkerhetskopieringsvalvet.
2. Välj Hantera>egenskaper>Mjuk borttagningsuppdatering.> Avmarkera kryssrutan bredvid Aktivera mjuk borttagning och välj sedan Uppdatera.
3. Välj Hantera>säkerhetskopieringsinstanser. Filtrera på datakällans typ Kubernetes Services. Välj den instans som du skapade och ta sedan bort den.
Vänta tills de två säkerhetskopieringsinstanserna har tagits bort.
Upprepa steg 1–4 för resursgruppen i det primära klustret , till exempel liberty-aks-eastus-mjg032524.
Upprepa steg 1–4 för resursgruppen för det sekundära klustret , till exempel liberty-aks-westus-mjg032524.

Nästa steg

I den här självstudien konfigurerar du en WebSphere Liberty/Open Liberty HA/DR-lösning som består av en aktiv-passiv programinfrastrukturnivå med en aktiv-passiv databasnivå och där båda nivåerna sträcker sig över två geografiskt olika platser. På den första platsen är både programinfrastrukturnivån och databasnivån aktiva. På den andra platsen återställs den sekundära domänen med Azure Backup och den sekundära databasen är i vänteläge.

Fortsätt att utforska följande referenser för fler alternativ för att skapa HA/DR-lösningar och köra WebSphere på Azure:

Dokumentation om Azure-tillförlitlighet

Skapa lösningar för hög tillgänglighet

Automatisk redundans med Azure Traffic Manager

Läs mer om WebSphere i Azure

Dela via