Esercitazione: Eseguire la migrazione di WebSphere Liberty/Open Liberty a servizio Azure Kubernetes (AKS) con disponibilità elevata e ripristino di emergenza

Articolo
05/17/2024

Questa esercitazione illustra un modo semplice ed efficace per implementare la disponibilità elevata e il ripristino di emergenza (HA/DR) per Java usando WebSphere Liberty/Open Liberty in servizio Azure Kubernetes (servizio Azure Kubernetes). La soluzione illustra come ottenere un obiettivo RTO (Recovery Time Objective) e un obiettivo del punto di ripristino (RPO) usando una semplice applicazione Jakarta EE basata su database in esecuzione in WebSphere Liberty/Open Liberty.

Disponibilità elevata/ripristino di emergenza è un argomento complesso, con molte possibili soluzioni. La soluzione migliore dipende dai requisiti specifici. Per altri modi per implementare disponibilità elevata/ripristino di emergenza, vedere le risorse alla fine di questo articolo.

In questa esercitazione apprenderai a:

Usare le procedure consigliate ottimizzate per Azure per ottenere disponibilità elevata e ripristino di emergenza.
Configurare un gruppo di failover database SQL di Microsoft Azure in aree abbinate.
Configurare il cluster WebSphere Liberty/Open Liberty primario nel servizio Azure Kubernetes.
Configurare il ripristino di emergenza per il cluster usando Backup di Azure.
Configurare il cluster del servizio Azure Kubernetes secondario.
Configurare un Gestione traffico di Azure.
Failover di test da primario a secondario.

Il diagramma seguente illustra l'architettura compilata:

Gestione traffico di Azure controlla l'integrità delle aree e indirizza il traffico di conseguenza al livello applicazione. Sia l'area primaria che l'area secondaria hanno una distribuzione completa del cluster Liberty. Tuttavia, solo l'area primaria sta eseguendo attivamente la manutenzione delle richieste di rete dagli utenti. L'area secondaria è passiva e viene attivata per ricevere traffico solo quando l'area primaria subisce un'interruzione del servizio. Gestione traffico di Azure usa la funzionalità di controllo dell'integrità del gateway di app Azure lication per implementare questo routing condizionale. Il cluster primario è in esecuzione e il cluster secondario viene arrestato. L'RTO di failover geografico del livello applicazione dipende dal tempo per l'avvio di macchine virtuali (VM) ed esecuzione del cluster secondario. L'RPO dipende dal database SQL di Azure perché i dati vengono mantenuti e replicati nel gruppo di failover database SQL di Azure.

Il livello di database è costituito da un gruppo di failover database SQL di Azure con un server primario e un server secondario. L'endpoint listener di lettura/scrittura punta sempre al server primario ed è connesso a un cluster WebSphere Liberty/Open Liberty in ogni area. Un failover geografico passa tutti i database secondari del gruppo al ruolo primario. Per il rpo di failover geografico e l'obiettivo RTO di database SQL di Azure, vedere Panoramica della continuità aziendale con database SQL di Azure.

Questa esercitazione è stata scritta con i servizi Backup di Azure e database SQL di Azure perché l'esercitazione si basa sulle funzionalità a disponibilità elevata di questi servizi. Sono possibili altre opzioni di database, ma è necessario considerare le funzionalità a disponibilità elevata di qualsiasi database scelto.

Prerequisiti

Una sottoscrizione di Azure. Se non si ha una sottoscrizione di Azure, creare un account gratuito prima di iniziare.
Assicurarsi di essere assegnati al ruolo o ai ruoli Owner o Contributor e User Access Administrator nella sottoscrizione. È possibile verificare l'assegnazione seguendo la procedura descritta in Elencare le assegnazioni di ruolo di Azure usando il portale di Azure.
Preparare un computer locale con Windows, Linux o macOS installato.
Installare e configurare Git.
Installare un'implementazione java SE, versione 17 o successiva, ad esempio la build Microsoft di OpenJDK.
Installare Maven, versione 3.9.3 o successiva.

Configurare un gruppo di failover database SQL di Azure in aree abbinate

In questa sezione viene creato un gruppo di failover database SQL di Azure in aree abbinate da usare con i cluster e l'app WebSphere Liberty/Open Liberty. In una sezione successiva si configura WebSphere Liberty/Open Liberty per archiviare i dati di sessione in questo database. Questa procedura fa riferimento alla creazione di una tabella per la persistenza della sessione.

Creare prima di tutto il database SQL di Azure primario seguendo la procedura portale di Azure descritta in Avvio rapido: Creare un database singolo - database SQL di Azure. Seguire i passaggi fino a, ma non includere, la sezione "Pulire le risorse". Usare le istruzioni seguenti durante l'articolo, quindi tornare a questo articolo dopo aver creato e configurato il database SQL di Azure.

Quando si raggiunge la sezione Creare un database singolo, seguire questa procedura:

Nel passaggio 4 per la creazione di un nuovo gruppo di risorse salvare il valore del nome del gruppo di risorse, myResourceGroupad esempio .
Nel passaggio 5 per il nome del database salvare il valore Nome database, mySampleDatabasead esempio .
Nel passaggio 6 per la creazione del server, seguire questa procedura:
1. Immettere un nome di server univoco, sqlserverprimary-mjg032524ad esempio .
2. In Località selezionare (USA) Stati Uniti orientali.
3. Per Metodo di autenticazione selezionare Usa autenticazione SQL.
4. Salvare a parte il valore di account di accesso amministratore del server, azureuserad esempio .
5. Salvare il valore password .
Nel passaggio 8, per Ambiente del carico di lavoro, selezionare Sviluppo. Esaminare la descrizione e prendere in considerazione altre opzioni per il carico di lavoro.
Nel passaggio 11, per Ridondanza dell'archiviazione di backup, selezionare Archiviazione di backup con ridondanza locale. Prendere in considerazione altre opzioni per i backup. Per altre informazioni, vedere la sezione Ridondanza dell'archiviazione di backup in Backup automatici in database SQL di Azure.
Nel passaggio 14, nella configurazione delle regole del firewall, per Consenti ai servizi e alle risorse di Azure di accedere a questo server, selezionare Sì.

Creare quindi un gruppo di failover database SQL di Azure seguendo la procedura portale di Azure descritta in Configurare un gruppo di failover per database SQL di Azure. Sono necessarie solo le sezioni seguenti: Creare un gruppo di failover e Testare il failover pianificato. Usare la procedura seguente durante l'articolo, quindi tornare a questo articolo dopo aver creato e configurato il gruppo di failover database SQL di Azure:

Quando si raggiunge la sezione Creare un gruppo di failover, seguire questa procedura:
1. Nel passaggio 5 per la creazione del gruppo di failover immettere e salvare il nome univoco del gruppo di failover, failovergroup-mjg032524ad esempio .
2. Nel passaggio 5 per la configurazione del server selezionare l'opzione per creare un nuovo server secondario e quindi seguire questa procedura:
  1. Immettere un nome univoco del server, sqlserversecondary-mjg032524ad esempio .
  2. Immettere lo stesso amministratore del server e la stessa password del server primario.
  3. Per Località selezionare (Stati Uniti) Stati Uniti occidentali.
  4. Assicurarsi che l'opzione Consenti ai servizi di Azure di accedere al server sia selezionata.
3. Nel passaggio 5 per la configurazione dei database all'interno del gruppo selezionare il database creato nel server primario, mySampleDatabasead esempio .
Dopo aver completato tutti i passaggi nella sezione Testare il failover pianificato, tenere aperta la pagina del gruppo di failover e usarla per il test di failover dei cluster WebSphere Liberty/Open Liberty in un secondo momento.

Configurare il cluster WebSphere Liberty/Open Liberty primario nel servizio Azure Kubernetes

In questa sezione viene creato il principale cluster WebSphere Liberty/Open Liberty nel servizio Azure Kubernetes usando l'offerta IBM WebSphere Liberty e Open Liberty su servizio Azure Kubernetes. Il cluster secondario viene ripristinato dal cluster primario durante il failover usando Backup di Azure versioni successive.

Distribuire il cluster WebSphere Liberty/Open Liberty primario

Usare la procedura seguente per distribuire il cluster primario:

Aprire l'offerta IBM WebSphere Liberty e Open Liberty in servizio Azure Kubernetes nel browser e selezionare Crea. Verrà visualizzato il riquadro Informazioni di base dell'offerta.
Per compilare il riquadro Informazioni di base, seguire questa procedura:
1. Assicurarsi che il valore visualizzato per Subscription sia lo stesso che include i ruoli elencati nella sezione prerequisiti.
2. È necessario distribuire l'offerta in un gruppo di risorse vuoto. Nel campo Gruppo di risorse selezionare Crea nuovo e compilare un valore univoco per il gruppo di risorse, liberty-aks-eastus-mjg032524ad esempio .
3. In Dettagli istanza selezionare Stati Uniti orientali in Area.
4. Selezionare Avanti per passare al riquadro servizio Azure Kubernetes.
Aspetta un po' di tempo. Verranno visualizzati tutti i campi prepopolati con le impostazioni predefinite nel riquadro servizio Azure Kubernetes . Selezionare Avanti per passare al riquadro Bilanciamento del carico.
Per compilare il riquadro Bilanciamento del carico, seguire questa procedura:
1. Per Connetti a app Azure lication Gateway?, selezionare Sì.
2. Lasciare le impostazioni predefinite per gli altri campi.
3. Selezionare Avanti per passare al riquadro Operatore e applicazione .
Per compilare il riquadro Operatore e applicazione , seguire questa procedura:
1. Lasciare le impostazioni predefinite per tutti i campi.
  
  Nota
  
  Questa esercitazione distribuisce Open Liberty Operator usando le impostazioni predefinite. Facoltativamente, è possibile distribuire WebSphere Liberty Operator selezionando Sì per IBM supportato?.
2. Selezionare Rivedi e crea.
3. Attendere il completamento dell'esecuzione della convalida finale e quindi selezionare Crea.

Dopo un po', verrà visualizzata la pagina Distribuzione in cui è in corso la distribuzione.

Nota

Se si verificano problemi durante l'esecuzione della convalida finale, correggerli e riprovare.

A seconda delle condizioni di rete e di altre attività nell'area selezionata, il completamento della distribuzione può richiedere fino a circa 30 minuti. Successivamente, verrà visualizzato il testo La distribuzione è stata completata nella pagina di distribuzione.

Verificare la distribuzione del cluster

È stato distribuito un cluster del servizio Azure Kubernetes, un'istanza di Registro Azure Container (ACR) e un gateway di app Azure lication nell'area primaria. Il cluster del servizio Azure Kubernetes è la piattaforma di elaborazione di destinazione in cui viene distribuita ed eseguita l'app. L'istanza di Registro Azure Container archivia l'immagine dell'applicazione che il servizio Azure Kubernetes esegue il pull durante la distribuzione dell'app. Il gateway di app Azure lication funge da servizio di bilanciamento del carico per l'applicazione distribuita nel cluster del servizio Azure Kubernetes.

Seguire questa procedura per verificare questi componenti chiave prima di passare al passaggio successivo:

Tornare alla pagina Distribuzione e quindi selezionare Output.
Copiare il valore della proprietà cmdToConnectToCluster. Aprire un terminale, incollare il comando copiato e premere INVIO per eseguire. Nell'output dovrebbe essere visualizzato un messaggio simile all'esempio seguente:
```
Merged "cluster3984d1-admin" as current context in <your-user>\.kube\config
```
Salvare il comando in modo da poterlo usare per connettersi al cluster in un secondo momento.

Eseguire kubectl get pod --all-namespaces nel terminale per elencare tutti i pod in esecuzione nel cluster del servizio Azure Kubernetes. L'output dovrebbe essere simile all'esempio seguente:

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

Eseguire kubectl get secret nel terminale per elencare tutti i segreti installati nel cluster del servizio Azure Kubernetes. Nell'output dovrebbe essere visualizzato un segreto, come illustrato nell'esempio seguente:
```
NAME           TYPE                DATA   AGE
secret3984d1   kubernetes.io/tls   2      24m
```
Questo segreto è un segreto TLS che include i dati del certificato e della chiave per il traffico TLS. Copiare e salvare il nome del segreto, secret3984d1ad esempio , che verrà usato nella distribuzione dell'app in un secondo momento.
Tornare alla pagina Output . Copiare il valore della proprietà cmdToLoginInRegistry. Incollare il comando copiato nel terminale e premere INVIO per eseguire. Nell'output dovrebbe essere visualizzato Login Succeeded .You should see Login Succeeded in the output. Tenere aperto il terminale e usarlo per altre configurazioni del cluster WebSphere Liberty/Open Liberty in un secondo momento.

Usare la procedura seguente per ottenere il nome e il nome DNS dell'indirizzo IP pubblico del gateway di app Azure lication. Le si usano per la distribuzione delle app e la configurazione Gestione traffico di Azure in un secondo momento.

Nella casella di ricerca della portale di Azure immettere Gruppi di risorse e selezionare Gruppi di risorse nei risultati della ricerca.
Selezionare il nome del gruppo di risorse per l'area primaria, liberty-aks-eastus-mjg032524ad esempio .
Trovare la risorsa indirizzo IP pubblico preceduta da gwip, quindi copiare e salvare il nome.
Selezionare la risorsa Indirizzo IP pubblico, quindi copiare e salvare il nome DNS, olgw3984d1.eastus.cloudapp.azure.comad esempio .

Abilitare le repliche geografiche per l'istanza di Registro Azure Container

L'istanza di Registro Azure Container è progettata per archiviare le immagini dell'applicazione per cluster primari e secondari. Usare la procedura seguente per abilitare le repliche geografiche per l'istanza di Registro Azure Container:

Nella casella di ricerca della portale di Azure immettere Gruppi di risorse e selezionare Gruppi di risorse nei risultati della ricerca.
Selezionare il nome del gruppo di risorse per l'area primaria, liberty-aks-eastus-mjg032524ad esempio .
Trovare la risorsa del Registro Contenitori preceduta da acr, quindi selezionarla per aprirla.
Selezionare Proprietà. Per Piano tariffario selezionare Premium, quindi selezionare Salva. Attendere il completamento.
Selezionare Repliche geografiche e quindi Aggiungi. Per Località selezionare Stati Uniti occidentali, quindi selezionare Crea. Attendere il completamento.
Attendere un po' di tempo, selezionare Aggiorna. Ripetere l'operazione finché non vengono visualizzate due posizioni e Lo stato è Pronto.

Usare la procedura seguente per ottenere le credenziali di accesso di Registro Azure Container. Le si usano per la distribuzione di app in un secondo momento.

Selezionare Chiavi di accesso.
Copiare e salvare il valore per Server di accesso, Nome utente e password.

Distribuire un'app di esempio

Usare la procedura seguente per distribuire ed eseguire un'applicazione CRUD Java/Jakarta EE di esempio nel cluster WebSphere Liberty/Open Liberty per il test di failover di ripristino di emergenza in un secondo momento:

Scaricare l'esempio usando i comandi seguenti:
```
git clone https://github.com/Azure-Samples/open-liberty-on-aks.git
cd open-liberty-on-aks
export BASE_DIR=$PWD
git checkout 20240325
```
L'applicazione configura un'origine dati jdbc/JavaEECafeDB che si connette al database SQL di Azure distribuito in precedenza. L'origine dati viene usata per l'archiviazione dei dati della sessione HTTP, che consente il failover e il bilanciamento del carico in un cluster di server WebSphere Liberty/Open Liberty. L'app di esempio configura anche uno schema di persistenza per rendere persistenti i dati coffee dell'applicazione nella stessa origine dati. Si noti che la radice del contesto dell'esempio è configurata come / nel file server.xml .

Usare i comandi seguenti per definire le variabili di ambiente con i valori salvati in precedenza:

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>

Usare i comandi seguenti per creare un pacchetto dell'app, compilare l'immagine Docker, eseguire il push dell'immagine nell'istanza di Registro Azure Container e distribuire l'esempio nel cluster del servizio Azure Kubernetes:

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

Eseguire il comando seguente per ottenere l'app di esempio distribuita:

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

Nell'output dovrebbe essere visualizzata un'applicazione READY :

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

Eseguire il comando seguente per ottenere lo stato dei pod creati durante la distribuzione:

kubectl get pods

L'esempio seguente indica che tutti i pod sono in esecuzione. Se non viene visualizzato un output simile, attendere un po' di tempo e ripetere l'operazione.

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

Usare la procedura seguente per verificare che l'app sia in esecuzione come previsto:
1. In una nuova scheda del browser aprire il nome DNS dell'indirizzo IP pubblico del gateway di app Azure lication salvato in precedenza. Usare il https protocollo , https://olgw3984d1.eastus.cloudapp.azure.comad esempio . Verrà visualizzata la pagina iniziale dell'app di esempio.
2. Creare un nuovo caffè con nome e prezzo, ad esempio Coffee 1 con prezzo 10 , che viene salvato in modo permanente nella tabella dati dell'applicazione e nella tabella di sessione del database. L'interfaccia utente visualizzata dovrebbe essere simile alla schermata seguente:
Se l'interfaccia utente non è simile, risolvere e risolvere il problema prima di continuare.

Configurare il ripristino di emergenza per il cluster usando Backup di Azure

In questa sezione viene configurato il ripristino di emergenza per il cluster del servizio Azure Kubernetes nell'area primaria usando Backup di Azure.

Creare un account di archiviazione

Il backup del servizio Azure Kubernetes usa un contenitore BLOB per contenere le risorse del cluster del servizio Azure Kubernetes. Si crea un altro contenitore BLOB come percorso di gestione temporanea da usare durante il ripristino tra aree.

Usare la procedura seguente per creare un account di archiviazione e due contenitori. Alcuni di questi passaggi indirizzano l'utente ad altre guide.

Accedere al portale di Azure.
Creare un account di archiviazione seguendo la procedura descritta in Creare un account di archiviazione. Non è necessario eseguire tutti i passaggi dell'articolo. Compilare i campi come illustrato nel riquadro Informazioni di base seguendo questa procedura:
1. In Gruppo di risorse selezionare il gruppo di risorse esistente in cui viene distribuito il cluster primario, liberty-aks-eastus-mjg032524ad esempio .
2. Per Nome account di archiviazione immettere un nome univoco, storageeastusmjg032524ad esempio .
3. In Area selezionare Stati Uniti orientali.
4. Selezionare Rivedi e crea per accettare le opzioni predefinite.
5. Continuare a convalidare e creare l'account, quindi tornare a questo articolo.
Creare un contenitore di archiviazione per l'estensione di backup del servizio Azure Kubernetes seguendo la procedura descritta in Creare un contenitore di archiviazione. Questa guida usa aks-backup-ext come nome del contenitore.
Creare un altro contenitore di archiviazione come percorso di staging da usare durante il ripristino. Questa guida usa staging come nome del contenitore.

Abilitare l'estensione di backup del servizio Azure Kubernetes

Prima di continuare, seguire questa procedura per installare l'estensione di backup del servizio Azure Kubernetes nel cluster nell'area primaria:

Abilitare i driver e gli snapshot CSI per il cluster. Per il comando seguente az aks update , aggiornare il valore della variabile RG_NAME Bash con il nome del gruppo di risorse, ad esempio , liberty-aks-eastus-mjg032524 ed eseguire nel terminale Bash locale.
```
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
```
L'abilitazione dei driver richiede circa 5 minuti. Assicurarsi che i comandi vengano completati senza errori prima di continuare.
Aprire il gruppo di risorse con servizio Azure Kubernetes distribuito, liberty-aks-eastus-mjg032524ad esempio . Selezionare il cluster del servizio Azure Kubernetes nell'elenco delle risorse.
In Impostazioni della pagina di destinazione del servizio Azure Kubernetes selezionare Backup e quindi selezionare Installa estensione.
Nella pagina Installa estensione del backup del servizio Azure Kubernetes selezionare Avanti. Selezionare l'account storageeastusmjg032524 di archiviazione e il contenitore aks-backup-ext BLOB creato nello stesso gruppo di risorse. Selezionare Avanti e quindi Crea. Per completare questo passaggio sono necessari circa cinque minuti.

Eseguire il backup del cluster del servizio Azure Kubernetes

Usare la procedura seguente per eseguire il backup del cluster del servizio Azure Kubernetes:

Nella casella di ricerca della portale di Azure cercare Insiemi di credenziali di backup. Viene visualizzato in Servizi. Selezionarlo.
Seguire la procedura descritta in Eseguire il backup servizio Azure Kubernetes usando Backup di Azure per abilitare il backup del servizio Azure Kubernetes per il cluster primario. Eseguire i passaggi fino a , ma non includere, la sezione Usare hook durante il backup del servizio Azure Kubernetes e usare il resto dei passaggi di questa sezione per apportare modifiche durante il passaggio.
Quando si raggiunge la sezione Creare un insieme di credenziali di backup, seguire questa procedura:
1. Per il passaggio 1, in Gruppo di risorse selezionare il gruppo di risorse esistente in cui viene distribuito il cluster primario, liberty-aks-eastus-mjg032524ad esempio .
2. Per Nome dell'insieme di credenziali di backup immettere un valore univoco, aks-backup-vault-eastus-mjg032524ad esempio .
3. In Area selezionare Stati Uniti orientali.
4. Per Ridondanza archiviazione di backup selezionare Con ridondanza globale.
5. Per il passaggio 2, per Ripristino tra aree selezionare Abilita.
Quando si raggiunge la sezione Creare un criterio di backup, seguire questa procedura:
1. Per il passaggio 3 immettere un nome per i criteri di backup, aksbackuppolicyad esempio .
2. Selezionare l'insieme di credenziali di backup creato nello stesso gruppo di risorse, aks-backup-vault-eastus-mjg032524ad esempio .
3. Per il passaggio 4, aggiungere una regola di conservazione in cui è selezionato Vault-standard.
4. Selezionare Aggiungi.
Nella sezione Configura backup seguire questa procedura:
1. Ignorare il passaggio 1-5, che sono per l'installazione dell'estensione del servizio Azure Kubernetes. Iniziare dal passaggio 6 per il cluster del servizio Azure Kubernetes nell'area primaria.
2. Per il passaggio 7, per Vault selezionare l'insieme di credenziali di backup creato nello stesso gruppo di risorse, aks-backup-vault-eastus-mjg032524ad esempio . Quando si verificano errori di autorizzazione, selezionare Concedi autorizzazioni per spostarsi. Al termine della distribuzione delle autorizzazioni, se l'errore persiste, selezionare Revalidate per aggiornare le assegnazioni di ruolo.
3. Per il passaggio 10, trovare Selezionare le risorse per il backup. Per Nome istanza di backup immettere un nome univoco, akseastusmjg032524ad esempio . Per Altre opzioni selezionare tutte le opzioni. Assicurarsi che l'opzione Includi segreti sia selezionata.
4. Per il passaggio 11 si verifica un errore di assegnazione di ruolo. Seguire il passaggio 12-14 per attenuare l'errore.
5. Dopo aver selezionato Configura backup nel passaggio 15, tornare alla pagina Backup . Attendere un po' e quindi selezionare Aggiorna. Ripetere l'operazione finché non si noterà che l'istanza di backup è elencata e che lo stato protezione è configurato.

Attendere l'esecuzione di un backup standard dell'insieme di credenziali

Nel servizio Azure Kubernetes il livello Standard dell'insieme di credenziali è l'unico livello che supporta la ridondanza geografica e il ripristino tra aree. Come indicato in Quale livello di archiviazione di backup supporta il backup del servizio Azure Kubernetes? "Viene spostato un solo punto di ripristino pianificato al giorno nel livello dell'insieme di credenziali". È necessario attendere che venga eseguito un backup standard dell'insieme di credenziali. Un limite inferiore valido consiste nell'attendere al massimo 24 ore dopo aver completato il passaggio precedente prima di eseguire il ripristino.

Usare la procedura seguente per verificare che sia disponibile un backup standard dell'insieme di credenziali:

Nella pagina Backup del cluster del servizio Azure Kubernetes primario selezionare l'istanza di backup.
Attendere un po' e selezionare Aggiorna. Ripetere l'operazione fino a quando non viene visualizzato almeno un punto di ripristino operativo e standard dell'insieme di credenziali nella sezione RESTORE POINTS .

Configurare il cluster del servizio Azure Kubernetes secondario

Durante l'attesa di un backup standard dell'insieme di credenziali per il cluster del servizio Azure Kubernetes primario, configurare il cluster del servizio Azure Kubernetes secondario per il ripristino in un secondo momento.

Usare gli stessi passaggi nella sezione Distribuire il cluster WebSphere Liberty/Open Liberty primario per configurare il cluster del servizio Azure Kubernetes secondario nell'area secondaria, ad eccezione delle differenze seguenti:

Nel riquadro Informazioni di base seguire questa procedura:
1. Nel campo Gruppo di risorse selezionare Crea nuovo e compilare un valore univoco diverso per il gruppo di risorse, liberty-aks-westus-mjg032524ad esempio .
2. In Dettagli istanza selezionare Stati Uniti occidentali in Area.
Nel riquadro servizio Azure Kubernetes seguire questa procedura:
1. In Registro Azure Container (Registro Azure Container) selezionare No per Selezionare l'istanza di Registro Azure Container.
2. Selezionare l'istanza di Registro Azure Container esistente nell'area primaria abilitata con le repliche geografiche.

Usare gli stessi passaggi nella sezione Verificare la distribuzione del cluster per verificare la distribuzione nell'area secondaria, ad eccezione delle differenze seguenti:

Non è necessario copiare e salvare il nome del segreto TLS. Il segreto TLS viene ripristinato dal backup del cluster del servizio Azure Kubernetes primario.
Usare il gruppo di risorse del cluster secondario, ad esempio, liberty-aks-westus-mjg032524 quando si cerca il nome e il nome DNS dell'indirizzo IP pubblico del gateway di app Azure lication distribuito nell'area secondaria.

Usare gli stessi passaggi nella sezione Creare un account di archiviazione per creare un account di archiviazione nell'area secondaria, ad eccezione delle differenze seguenti:

Per Il campo Gruppo di risorse selezionare il gruppo di risorse esistente in cui viene distribuito il cluster secondario, liberty-aks-westus-mjg032524ad esempio .
Per Nome account di archiviazione immettere un nome univoco, storagewestusmjg032524ad esempio .
Per Area selezionare Stati Uniti occidentali.

Usare gli stessi passaggi nella sezione Abilitare l'estensione di backup del servizio Azure Kubernetes per installare l'estensione di backup del servizio Azure Kubernetes per il cluster nell'area secondaria, ad eccezione delle differenze seguenti:

Nel passaggio 1 per abilitare i driver e gli snapshot CSI per il cluster secondario aggiornare il valore della variabile RG_NAME Bash al gruppo di risorse nell'area secondaria, liberty-aks-westus-mjg032524ad esempio .
Nel passaggio 2 selezionare il cluster del servizio Azure Kubernetes dal gruppo di risorse nell'area secondaria, liberty-aks-westus-mjg032524ad esempio .
Nel passaggio 4 per installare l'estensione di backup del servizio Azure Kubernetes per il cluster secondario selezionare l'account di archiviazione creato nello stesso gruppo di risorse dell'area secondaria, storagewestusmjg032524ad esempio .

Per risparmiare sui costi, arrestare il cluster del servizio Azure Kubernetes nell'area secondaria seguendo i passaggi descritti in Arrestare e avviare un cluster del servizio Azure Kubernetes servizio Azure Kubernetes. È necessario avviarlo prima di ripristinare il cluster in un secondo momento.

Configurare un Gestione traffico di Azure

Il backup standard dell'insieme di credenziali è stato menzionato nella sezione Attendere che venga eseguito un backup standard dell'insieme di credenziali. Dopo aver visto che è disponibile un backup standard di Vault, è possibile creare un Gestione traffico di Azure per distribuire il traffico alle applicazioni pubbliche nelle aree di Azure globali. L'endpoint primario punta all'indirizzo IP pubblico del gateway di app Azure lication nell'area primaria. L'endpoint secondario punta all'indirizzo IP pubblico del gateway di app Azure lication nell'area secondaria.

Creare un profilo di Gestione traffico di Azure seguendo la procedura descritta in Avvio rapido: Creare un profilo di Gestione traffico usando il portale di Azure. Sono necessarie solo le sezioni seguenti: Creare un profilo di Gestione traffico e Aggiungere endpoint Gestione traffico. Usare la procedura seguente durante l'esecuzione di queste sezioni, quindi tornare a questo articolo dopo aver creato e configurato il Gestione traffico di Azure:

Quando si raggiunge la sezione Creare un profilo di Gestione traffico, nel passaggio 2, per Creare un profilo Gestione traffico, seguire questa procedura:
1. In Nome immettere un nome di profilo Gestione traffico univoco, tmprofile-mjg032524ad esempio .
2. Per Routing method (Metodo di routing) selezionare Priority (Priorità).
3. Per Gruppo di risorse immettere e salvare il nuovo nome del gruppo di risorse, myResourceGroupTM1ad esempio .
Quando si raggiunge la sezione Aggiungere endpoint Gestione traffico, seguire questa procedura:
1. Dopo aver aperto il profilo di Gestione traffico nel passaggio 2, nella pagina Configurazione seguire questa procedura:
  1. Per durata (TTL) dns immettere 10.
  2. In Impostazioni monitoraggio endpoint, per Protocollo, selezionare https e per Porta immettere 443.
  3. In Impostazioni di failover rapido dell'endpoint usare i valori seguenti:
    - Per Ricerca interna selezionare 10.
    - Per Numero tollerato di errori, immettere 3.
    - In Timeout probe immettere 5.
  4. Seleziona Salva. Attendere il completamento.
2. Nel passaggio 4 per aggiungere l'endpoint myPrimaryEndpointprimario, seguire questa procedura:
  1. In Tipo di risorsa di destinazione selezionare Indirizzo IP pubblico.
  2. Selezionare l'elenco a discesa Scegli indirizzo IP pubblico e immettere il nome dell'indirizzo IP pubblico del gateway di app Azure lication nell'area Stati Uniti orientali salvata in precedenza. Dovrebbe essere visualizzata una voce corrispondente. Selezionarlo per Indirizzo IP pubblico.
3. Nel passaggio 6 per l'aggiunta di un endpoint myFailoverEndpointdi failover/secondario, seguire questa procedura:
  1. In Tipo di risorsa di destinazione selezionare Indirizzo IP pubblico.
  2. Selezionare l'elenco a discesa Scegli indirizzo IP pubblico e immettere il nome dell'indirizzo IP pubblico del gateway di app Azure lication nell'area Stati Uniti occidentali salvata in precedenza. Dovrebbe essere visualizzata una voce corrispondente. Selezionarlo per Indirizzo IP pubblico.
4. Aspetta un po' di tempo. Selezionare Aggiorna fino a quando lo stato di monitoraggio per l'endpoint myPrimaryEndpoint è Online e Lo stato di monitoraggio per l'endpoint myFailoverEndpoint non è danneggiato.

Usare quindi la procedura seguente per verificare che l'app di esempio distribuita nel cluster primario sia accessibile dal profilo Gestione traffico:

Selezionare Panoramica del profilo Gestione traffico creato.
Controllare e copiare il nome DNS del profilo Gestione traffico, sostituendo il protocollo http con https. Ad esempio: https://tmprofile-mjg032524.trafficmanager.net.
Aprire l'URL in una nuova scheda del browser. Si noterà che il caffè creato in precedenza è elencato nella pagina.
Creare un altro caffè con un nome e un prezzo diversi, ad esempio Coffee 2 con prezzo 20, che viene salvato in modo permanente nella tabella dati dell'applicazione e nella tabella di sessione del database. L'interfaccia utente visualizzata dovrebbe essere simile alla schermata seguente:

Se l'interfaccia utente non è simile, risolvere e risolvere il problema prima di continuare. Mantenere aperta la console e usarla per il test di failover in un secondo momento.

La configurazione del profilo di Gestione traffico è stata completata. Mantenere aperta la pagina e usarla per monitorare la modifica dello stato dell'endpoint in un evento di failover in un secondo momento.

Failover di test da primario a secondario

In questa sezione, per testare il failover, eseguire manualmente il failover del server database SQL di Azure e ripristinare il backup del cluster del servizio Azure Kubernetes e quindi eseguire il failback usando il portale di Azure.

Failover nel sito secondario

Per simulare un'interruzione dell'area primaria, arrestare il cluster del servizio Azure Kubernetes primario seguendo i passaggi descritti in Arrestare e avviare un cluster del servizio Azure Kubernetes servizio Azure Kubernetes.

Avviare quindi il cluster del servizio Azure Kubernetes secondario in modo che possa essere ripristinato dal backup del cluster primario.

Nota

Se nel cluster di destinazione di ripristino sono in esecuzione applicazioni WebSphere Liberty/Open Liberty, per evitare conflitti, seguire questa procedura per pulire le applicazioni WebSphere Liberty/Open Liberty:

Connettersi al cluster di destinazione eseguendo il comando per cmdToConnectToCluster cui è stato salvato in precedenza.
Per le applicazioni Open Liberty, eseguire il comando seguente:
```
kubectl delete OpenLibertyApplication --all --all-namespaces
```
Per le applicazioni WebSphere Liberty, eseguire il comando seguente:
```
kubectl delete WebSphereLibertyApplication --all --all-namespaces
```

Passare quindi alla scheda del browser del profilo di Gestione traffico e verificare che lo stato di Monitoraggio sia per gli myPrimaryEndpoint endpoint sia myFailoverEndpoint danneggiato.

Usare ora i passaggi seguenti per eseguire il failover del database SQL di Azure dal server primario al server secondario:

Passare alla scheda del browser del gruppo di failover database SQL di Azure, failovergroup-mjg032524ad esempio .
Selezionare Failover e quindi Sì.
Attendere il completamento.

Usare quindi la procedura seguente per ripristinare il backup del cluster del servizio Azure Kubernetes primario nel cluster del servizio Azure Kubernetes secondario:

Nella casella di ricerca della portale di Azure immettere Centro backup e selezionare Centro backup nei risultati della ricerca.
In Gestisci selezionare Istanze di backup. Filtrare in base al tipo di origine dati Servizi Kubernetes. Trovare l'istanza di backup creata nella sezione precedente, <aks-cluster-name>\akseastusmjg032524ad esempio .
Selezionare l'istanza di backup.
Selezionare Ripristina.
Nella pagina Ripristina il riquadro predefinito è Punto di ripristino. Selezionare Indietro per passare al riquadro Informazioni di base. Per Area di ripristino selezionare Area secondaria, quindi selezionare Avanti: Punto di ripristino.
Nel riquadro Punto di ripristino è selezionato il punto di ripristino operativo e standard dell'insieme di credenziali più recente. Mantenere le impostazioni predefinite e selezionare Avanti: Ripristina parametri.
Nel riquadro Parametri di ripristino seguire questa procedura:
1. Per Seleziona cluster di destinazione selezionare il cluster del servizio Azure Kubernetes secondario creato nell'area Stati Uniti occidentali. Si verifica un problema di autorizzazione, come illustrato nello screenshot seguente. Selezionare Concedi autorizzazione per attenuare gli errori.
2. Per Percorso di gestione temporanea del backup selezionare l'account di archiviazione creato nell'area Stati Uniti occidentali. Si verifica un problema di autorizzazione, come illustrato nello screenshot seguente. Selezionare Assegna ruoli mancanti per attenuare gli errori.
3. Se gli errori si verificano ancora al termine delle assegnazioni di ruolo, selezionare Riconvalida per aggiornare le autorizzazioni.
4. Quando si concedono autorizzazioni mancanti, se viene richiesto di specificare un ambito, accettare il valore predefinito.
5. Selezionare Convalida. Dovrebbe essere visualizzato il messaggio Validation completed successfully. In caso contrario, risolvere e risolvere il problema prima di continuare.
Selezionare Avanti: Rivedi e ripristina. Selezionare quindi Ripristina. Il ripristino del cluster richiede circa 10 minuti.
È possibile monitorare il processo di ripristino dal monitoraggio del centro>backup e creare report>sui processi di backup, come illustrato nello screenshot seguente:
Attendere un po', quindi selezionare Aggiorna. Ripetere l'operazione finché non viene visualizzato lo stato diventa Completato.

Usare quindi la procedura seguente per verificare che il ripristino funzioni come previsto:

Passare al terminale in cui si è connessi al cluster del servizio Azure Kubernetes secondario.

Eseguire il comando seguente per ripristinare l'app di esempio dal backup:

kubectl get OpenLibertyApplication

Nell'output dovrebbe essere visualizzata un'applicazione READY :

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

Eseguire il comando seguente per ottenere lo stato dei pod creati durante la distribuzione:

kubectl get pods

Nell'output dovrebbero essere visualizzati tre pod in esecuzione :

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

Passare alla scheda del browser del profilo di Gestione traffico, quindi aggiornare la pagina fino a quando non viene visualizzato Il monitoraggio dello stato dell'endpoint myFailoverEndpoint è Online e Lo stato di monitoraggio per l'endpoint myPrimaryEndpoint è danneggiato.
Passare alla scheda del browser con il nome DNS del profilo Gestione traffico, https://tmprofile-mjg032524.trafficmanager.netad esempio . Aggiornare la pagina e verranno visualizzati gli stessi dati salvati in modo permanente nella tabella dei dati dell'applicazione e nella tabella della sessione visualizzata. L'interfaccia utente visualizzata dovrebbe essere simile alla schermata seguente:

Se non si osserva questo comportamento, la Gestione traffico richiede tempo per aggiornare IL DNS in modo che punti al sito di failover. Il problema potrebbe anche essere che il browser ha memorizzato nella cache il risultato della risoluzione dei nomi DNS che punta al sito non riuscito. Attendere un po' e aggiornare di nuovo la pagina.

Nota

L'app configura il timeout della sessione come 1 ora. A seconda del tempo impiegato per il failover, è possibile che i dati della sessione non vengano visualizzati nella sezione Nuovo caffè dell'interfaccia utente dell'app di esempio se sono scaduti più di un'ora in precedenza.

Riprotezione del sito di failover

Ora che l'area secondaria è il sito di failover ed è attiva, è necessario proteggerla nuovamente con Backup di Azure.

Prima di tutto, usare gli stessi passaggi nella sezione Eseguire il backup del cluster del servizio Azure Kubernetes per eseguire il backup del cluster del servizio Azure Kubernetes secondario, ad eccezione delle differenze seguenti:

Per Creare un insieme di credenziali di backup, seguire questa procedura:
1. Per Gruppo di risorse selezionare il gruppo di risorse esistente distribuito nell'area secondaria, liberty-aks-westus-mjg032524ad esempio .
2. Per Nome dell'insieme di credenziali di backup immettere un valore univoco, aks-backup-vault-westus-mjg032524ad esempio .
3. Per Area selezionare Stati Uniti occidentali.
Per Creare un criterio di backup, seguire questa procedura:
1. Selezionare l'insieme di credenziali di backup creato nell'area secondaria, aks-backup-vault-westus-mjg032524ad esempio .
Per Configurare i backup, seguire questa procedura:
1. Selezionare l'insieme di credenziali di backup creato nell'area secondaria, aks-backup-vault-westus-mjg032524ad esempio .
2. Per Nome istanza di backup immettere un nome univoco, akswestusmjg032524ad esempio .

Usare quindi gli stessi passaggi nella sezione Attendere che venga eseguito un backup standard dell'insieme di credenziali fino a quando non è disponibile un backup standard dell'insieme di credenziali del cluster del servizio Azure Kubernetes secondario, ad eccezione della selezione dell'istanza di backup nella pagina Backup del cluster del servizio Azure Kubernetes secondario.

Eseguire il failback nel sito primario

Usare gli stessi passaggi nella sezione Failover nel sito secondario per eseguire il failback nel sito primario, incluso il server di database e il cluster del servizio Azure Kubernetes, ad eccezione delle differenze seguenti:

Quando si prepara per il failback, seguire questa procedura:
1. Arrestare il cluster del servizio Azure Kubernetes secondario per simulare un'interruzione dell'area secondaria.
2. Avviare il cluster del servizio Azure Kubernetes primario.
3. Connettersi al cluster del servizio Azure Kubernetes primario e pulire le applicazioni WebSphere Liberty/Open Liberty.
Quando si ripristina il backup del cluster del servizio Azure Kubernetes secondario nel cluster del servizio Azure Kubernetes primario, seguire questa procedura:
1. Selezionare l'istanza di backup nell'area secondaria, <aks-cluster-name>\akswestusmjg032524ad esempio .
2. Nel riquadro Parametri di ripristino seguire questa procedura:
  1. Per Seleziona cluster di destinazione selezionare il cluster del servizio Azure Kubernetes primario creato nell'area Stati Uniti orientali.
  2. Per Percorso di gestione temporanea del backup selezionare l'account di archiviazione creato nell'area Stati Uniti orientali.
Quando si verifica che il ripristino funzioni come previsto, seguire questa procedura:
1. Passare al terminale in cui si è connessi al cluster del servizio Azure Kubernetes primario e verificare che l'app sia stata ripristinata correttamente.
2. Passare alla scheda del browser del profilo di Gestione traffico, quindi aggiornare la pagina fino a quando non viene visualizzato Il monitoraggio dello stato dell'endpoint myPrimaryEndpoint è Online e Lo stato di monitoraggio per l'endpoint myFailoverEndpoint è danneggiato.

Pulire le risorse

Se non si intende continuare a usare i cluster WebSphere Liberty/Open Liberty e altri componenti, seguire questa procedura per eliminare i gruppi di risorse per pulire le risorse usate in questa esercitazione:

Nella casella di ricerca della portale di Azure immettere il nome del gruppo di risorse dei server database SQL di Azure, ad esempio , myResourceGroup e selezionare il gruppo di risorse corrispondente nei risultati della ricerca.
Selezionare Elimina gruppo di risorse.
In Immettere il nome del gruppo di risorse per confermare l'eliminazione immettere il nome del gruppo di risorse.
Selezionare Elimina.
Ripetere i passaggi da 1 a 4 per il gruppo di risorse del Gestione traffico, myResourceGroupTM1ad esempio .
Nella casella di ricerca della portale di Azure immettere Insiemi di credenziali di backup e selezionare Insiemi di credenziali di backup nei risultati della ricerca. Verranno visualizzati due insiemi di credenziali di backup, ad esempio aks-backup-vault-eastus-mjg032524 e aks-backup-vault-westus-mjg032524. Per ognuno di essi, seguire questa procedura:
1. Selezionare questa opzione per aprire l'insieme di credenziali di backup.
2. Selezionare Gestisci>proprietà>Eliminazione temporanea>Aggiornamento. Accanto a Abilita eliminazione temporanea, deselezionare la casella di controllo e quindi selezionare Aggiorna.
3. Selezionare Gestisci>istanze di backup. Filtrare in base al tipo di origine dati Servizi Kubernetes. Selezionare l'istanza creata e quindi eliminarla.
Attendere l'eliminazione delle due istanze di Backup.
Ripetere i passaggi da 1 a 4 per il gruppo di risorse del cluster primario, liberty-aks-eastus-mjg032524ad esempio .
Ripetere i passaggi da 1 a 4 per il gruppo di risorse del cluster secondario, liberty-aks-westus-mjg032524ad esempio .

Passaggi successivi

In questa esercitazione viene configurata una soluzione WebSphere Liberty/Open Liberty HA/DR costituita da un livello di infrastruttura di applicazione attivo-passivo con un livello di database attivo-passivo e in cui entrambi i livelli si estendono su due siti geograficamente diversi. Nel primo sito, sia il livello di infrastruttura dell'applicazione che il livello di database sono attivi. Nel secondo sito il dominio secondario viene ripristinato con Backup di Azure e il database secondario è in standby.

Continuare a esplorare i riferimenti seguenti per altre opzioni per creare soluzioni di disponibilità elevata/ripristino di emergenza ed eseguire WebSphere in Azure:

Documentazione sull'affidabilità di Azure

Creare soluzioni per la disponibilità elevata

Failover automatico con Gestione traffico di Azure

Altre informazioni su WebSphere in Azure

Condividi tramite