Nota
- Questa esercitazione richiede l'accesso a Oracle Cloud. Per iscriverti a un account gratuito, consulta Inizia a utilizzare Oracle Cloud Infrastructure Free Tier.
- Utilizza valori di esempio per le credenziali, la tenancy e i compartimenti di Oracle Cloud Infrastructure. Al termine del laboratorio, sostituisci questi valori con quelli specifici del tuo ambiente cloud.
Automatizza un piano di switchover e failover per un'applicazione demo distribuita su OCI Kubernetes Engine con OCI Full Stack Disaster Recovery
Introduzione
Questa esercitazione descrive un caso d'uso di Oracle Cloud Infrastructure Full Stack Disaster Recovery (OCI Full Stack DR) con un'applicazione di e-commerce demo distribuita su un cluster Oracle Cloud Infrastructure Kubernetes Engine (OCI Kubernetes Engine o OKE).
Al momento di scrivere questa esercitazione, OCI Full Stack DR ha annunciato una disponibilità limitata per OKE. In una release limitata, possiamo provare OCI Full Stack DR su applicazioni basate su OKE come MuShop, un'applicazione demo basata su microservizi che utilizza vari altri servizi Oracle Cloud Infrastructure (OCI) come un'unica applicazione.
Utilizzeremo un approccio di warm standby: un modello di disaster recovery (DR) in cui alcuni o tutti i componenti dell'applicazione vengono pre-distribuiti in una standby region per consentire una transizione DR più rapida. Sebbene questo modello comporti costi operativi più elevati, fornisce un obiettivo RTO (Recovery Time Objective).
OCI Full Stack DR orchestra la transizione di calcoli, database e applicazioni tra le region OCI di tutto il mondo con un solo clic. I clienti possono automatizzare i passaggi necessari per recuperare uno o più sistemi aziendali senza riprogettare o riprogettare l'infrastruttura, i database o le applicazioni esistenti senza dover ricorrere a server di gestione o conversione specializzati.
Architettura di distribuzione
Nota: l'area principale è Sydney e l'area DR è Melbourne.
Obiettivi
-
Secondo l'architettura, creeremo un gruppo di protezione DR (DRPG) denominato
Mushop-Syd
nella regione principale di Sydney. -
Il DRPG primario contiene una raccolta di diverse risorse OCI che costituiscono un'applicazione e che devono essere considerate come un gruppo combinato quando si eseguono operazioni DR. Abbiamo aggiunto OKE e Oracle Autonomous Database Serverless (Autonomous Database Serverless) al DRPG primario. Questa esercitazione descrive inoltre i passi necessari per distribuire l'applicazione MuShop e tutte le altre risorse necessarie per la distribuzione.
-
Un DRPG simile viene creato nella standby Melbourne region. OKE e Autonomous Database Serverless (in modalità standby) vengono aggiunti al DRPG. I load balancer non fanno parte del DRPG, ma verranno eseguiti in modo indipendente in entrambi i siti, come evidenziato nell'architettura di distribuzione.
-
Si forma un'associazione tra i due DRPG.
-
Nel DRPG in standby (Melbourne), viene creato un piano DR. Questo piano rappresenta un flusso di lavoro DR (una sequenza di passi).
-
Eseguire un piano DR. Viene eseguito uno switchover, che prevede una transizione dei servizi dal DRPG primario al DRPG in standby. I piani di switchover eseguono una transizione ordinata arrestando lo stack di applicazioni nell'area primaria e quindi attivandolo nella standby region. Pertanto, un piano di switchover richiede che i componenti dello stack di applicazioni e altri servizi OCI necessari siano disponibili in entrambe le aree.
Prerequisiti
-
Privilegi di amministratore o configurazione dei criteri Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) necessari per OCI Full Stack DR. Per ulteriori informazioni, vedere Configurazione dei criteri IAM (Identity and Access Management) per l'uso di OCI Full Stack DR e Criteri per OCI Full Stack DR.
-
Impostazione ambiente:
export COMPARTMENT_ID=ocid1.compartment.oc1.. export DB_NAME=fsdrdemoadb export DB_DISPLAY_NAME=fsdrdemoadb export DB_PASSWORD=<Your DB Password> export WALLET_PW=<Your DB Password> export DB_SERVICE_NAME=${DB_NAME}_tp export WALLET_ZIP=/tmp/Wallet_${DB_NAME}.zip export STANDBY_WALLET_ZIP=/tmp/Wallet_${DB_NAME}_Standby.zip export PRIMARY_REGION=ap-sydney-1 export STANDBY_REGION=ap-melbourne-1 export STANDBY_DB_NAME=${DB_NAME}_remote
Aggiungere le righe seguenti a un file denominato
env
e assegnarne l'origine.source env
Nota:
- Per ulteriori informazioni sui criteri delle password per Autonomous Database Serverless, vedere Informazioni sulle password utente in Autonomous Database.
- Il nome serverless di Autonomous Database può contenere solo caratteri alfanumerici.
- Sostituire
DB_PASSWORD
eWALLET_PW
nelle variabili di ambiente sopra riportate.
Task 1: installare e impostare Oracle Autonomous Database
-
Crea l'istanza primaria di Oracle Autonomous Database.
oci db autonomous-database create --compartment-id ${COMPARTMENT_ID} \ --db-name ${DB_NAME} --admin-password ${DB_PASSWORD} --db-version 19c \ --cpu-core-count 1 --data-storage-size-in-tbs 1 \ --display-name ${DB_DISPLAY_NAME} --region ${PRIMARY_REGION}
-
Recupera l'OCID primario di Oracle Autonomous Database.
DB_ID=$(oci db autonomous-database list -c ${COMPARTMENT_ID} \ --region ${PRIMARY_REGION} --display-name $DB_NAME \ --query "data[?\"db-name\"=='${DB_NAME}'].id | [0]" --raw-output)
-
Crea il DR in standby e abilita Oracle Data Guard tra più aree.
oci db autonomous-database create-adb-cross-region-data-guard-details \ --compartment-id ${COMPARTMENT_ID} --db-name ${DB_NAME} --source-id ${DB_ID} \ --cpu-core-count 1 --data-storage-size-in-tbs 1 \ --region ${FAILOVER_REGION} --db-version 19c
-
Scaricare ed estrarre il wallet del database autonomo dal database primario Oracle Autonomous Database.
oci db autonomous-database generate-wallet --autonomous-database-id ${DB_ID}\ --password ${WALLET_PW} --file ${WALLET_ZIP} --region $PRIMARY_REGION
-
Estrarre il wallet dal database primario.
unzip ${WALLET_ZIP} -d /tmp/wallet_primary
Nota:
- Mantenere questo portafoglio a portata di mano in quanto sarà necessario aggiungerlo come segreto OKE in seguito.
- Il wallet deve essere scaricato separatamente per le region primarie e standby perché le voci DNS
tnsnames.ora
sono diverse.
-
Recupera l'OCID di Oracle Autonomous Database di standby.
STANDBY_DB_ID=$(oci db autonomous-database list -c ${COMPARTMENT_ID} \ --region ${STANDBY_REGION} --display-name $STANDBY_DB_NAME \ --query "data[?\"db-name\"=='${DB_NAME}'].id | [0]" --raw-output)
-
Scaricare ed estrarre il wallet del database autonomo da Oracle Autonomous Database in standby.
oci db autonomous-database generate-wallet --autonomous-database-id \ ${STANDBY_DB_ID} --password ${WALLET_PW} \ --file ${STANDBY_WALLET_ZIP} --region $STANDBY_REGION
-
Estrarre il wallet in standby.
unzip ${STANDBY_WALLET_ZIP} -d /tmp/wallet_standby
Task 2: creare un cluster OKE
Creare un cluster OKE sia nei siti principale che in quelli DR. Per ulteriori informazioni, vedere Crea un cluster con Oracle Cloud Infrastructure Container Engine for Kubernetes.
È stata utilizzata l'opzione Creazione rapida per creare cluster con le informazioni riportate di seguito.
- Nome cluster: immettere
primary-syd-oke-demo-cluster
(Sydney) estandby-mel-oke-demo-cluster
(Melbourne). - Endpoint API Kubernetes: selezionare Pubblico.
- Tipo di nodo: selezionare Gestito.
- Selezionare Lavoratori privati.
- Forma: selezionare VM Standard E3 Flex (4 OCPU, 64 GB di memoria).
- Seleziona Oracle Linux 8.
Per accedere al cluster, andare alla console OCI, andare a Servizio sviluppatore, Container e artifact e fare clic su Cluster Kubernetes (OKE).
Oppure
Eseguire il comando seguente per accedere al cluster.
oci ce cluster create-kubeconfig --cluster-id <cluster-id> --file $HOME/.kube/config --region ap-sydney-1 --token-version 2.0.0 --kube-endpoint PUBLIC_ENDPOINT
Task 3: impostare i segreti Kubernetes nel sito principale
-
Creare uno spazio di nomi.
kubectl create ns mushop
-
Aggiungere il segreto password amministratore Oracle Autonomous Database.
kubectl create secret generic oadb-admin \ --namespace mushop \ --from-literal=oadb_admin_pw=${DB_PASSWORD}
-
Aggiungere il segreto di connessione di Oracle Autonomous Database.
kubectl create secret generic oadb-connection \ --namespace mushop \ --from-literal=oadb_wallet_pw=${WALLET_PW} \ --from-literal=oadb_service=${DB_SERVICE_NAME}
-
Aggiungere il segreto wallet primario.
kubectl create secret generic oadb-wallet \ --namespace mushop --from-file=/tmp/wallet_primary
Task 4: impostare l'applicazione MuShop
Nota: l'applicazione viene distribuita solo nell'area principale (
ap-sydney-1
).
-
Duplicare il repository.
git clone git@github.com:naikvenu/fsdr-demo.git
-
Andare alla cartella del grafico.
cd fsdr-demo/helm-chart/
-
Aggiornare le dipendenze del grafico.
helm dependency update ./setup
-
Installazione e configurazione del grafico.
helm upgrade --install mushop-utils setup --dependency-update --namespace mushop-utilities --create-namespace
-
Individuare l'indirizzo
EXTERNAL-IP
del controller in entrata.PRIMARY_EXTERNAL_IP=$(kubectl get svc -n mushop-utilities mushop-utils-ingress-nginx-controller -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
-
Installare l'applicazione nel cluster OKE.
helm upgrade --install -f ./mushop/values-dr.yaml \ fsdrmushop mushop -n mushop
-
Accedere all'applicazione MuShop primaria utilizzando l'IP in entrata.
kubectl get svc mushop-utils-ingress-nginx-controller \ --namespace mushop-utilities
-
Per verificare l'applicazione, accedi a
http://<primary-site-ingress-ip-address>
e assicurati di vedere tutti i prodotti del catalogo MuShop elencati senza errori.
Task 5: impostazione di un cluster OKE nel sito in standby
Nota: poiché si sta utilizzando un approccio di warm standby, è necessario creare un cluster OKE ed eseguire alcune operazioni di base, ad esempio il controller in entrata. I seguenti passaggi ti aiuteranno a farlo.
-
Per accedere al cluster nel sito in standby, andare alla console OCI, andare a Servizio sviluppatore, Container e artifact e fare clic su Cluster Kubernetes (OKE).
Oppure
Eseguire il comando riportato di seguito per accedere al cluster nel sito in standby.
oci ce cluster create-kubeconfig --cluster-id <cluster-id> --file $HOME/.kube/config --region ap-sydney-1 --token-version 2.0.0 --kube-endpoint PUBLIC_ENDPOINT
-
Duplicare il repository.
git clone git@github.com:naikvenu/fsdr-demo.git
Oppure
git clone https://github.com/naikvenu/fsdr-demo
-
Andare alla cartella dei grafici.
cd fsdr-demo/helm-chart/
-
Aggiornare le dipendenze del grafico.
helm dependency update ./setup
-
Installare e impostare i grafici. È necessario per distribuire un controller in entrata (OCI Load Balancer) per accedere all'applicazione.
Nota: questo passo distribuirà solo un controller in entrata (OCI Load Balancer) e non l'applicazione completa.
helm upgrade --install mushop-utils setup --dependency-update --namespace mushop-utilities --create-namespace
-
Individuare l'indirizzo
EXTERNAL-IP
del controller in entrata.STANDBY_EXTERNAL_IP=$(kubectl get svc -n mushop-utilities mushop-utils-ingress-nginx-controller -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
-
Creare uno spazio di nomi MuShop.
kubectl create namespace mushop
-
Creare un segreto per il wallet.
kubectl create secret generic oadb-wallet \ --namespace mushop --from-file=/tmp/wallet_standby
Nota: viene utilizzato un wallet in standby.
Task 6: Impostazione delle zone DNS (facoltativo)
Nell'area primaria, andare alla console OCI, andare a Networking, Gestione DNS, Zone e fare clic su Crea zona.
Configuration:
The Zone type : Primary
‘A’ record: “mushop”
Il nome della zona deve corrispondere al nome del dominio acquistato. Inserisci i nameserver da aggiungere al tuo dominio.
L'applicazione sarà accessibile all'indirizzo https://mushop.<your-domain>.com
.
Task 7: Crea controlli dello stato (Facoltativo)
I controlli dello stato sono necessari per impostare i criteri di indirizzamento del traffico DNS OCI.
Eseguire il comando riportato di seguito per creare i controlli dello stato.
oci health-checks http-monitor create --compartment-id ${COMPARTMENT_ID} --display-name fsdr-test --interval-in-seconds 30 --targets '[“${PRIMARY_EXTERNAL_IP}”]' --protocol http --path "/" --port 80
Oppure
Andare alla console OCI, andare a Osservabilità e gestione, Monitoraggio, Controlli dello stato, fare clic su Crea controllo dello stato e immettere le informazioni riportate di seguito.
- Nome: immettere
FSDR-APP-HEALTHCHECK
. - Destinazioni: immettere gli IP dei load balancer primari e in standby.
- Protocollo: selezionare http.
- Porta: immettere 80.
- Percorso di destinazione: immettere
/
. - Metodo: selezionare GET.
- Timeout: immettere 30.
- Intervallo: immettere 30 secondi.
Task 8: configurazione del criterio di indirizzamento per la gestione del traffico (Facoltativo)
Andare alla console OCI, accedere a Networking, Gestione DNS, Criteri di indirizzamento per la gestione del traffico, fare clic su Crea criterio di indirizzamento per la gestione del traffico e immettere le informazioni riportate di seguito.
- Nome: immettere
FSDR-POLICY
. - TTL: immettere 60 secondi.
- Pool 1:
- Nome: immettere
Primary
. - Tipo: selezionare A.
- Rdata: immettere l'IP del load balancer primario.
- Nome: immettere
- Pool 2:
- Nome: immettere
Standby
. - Tipo: selezionare A.
- Rdata: immettere l'IP del load balancer di standby.
- Nome: immettere
- Seleziona priorità pool:
- Pool1
- Pool2
- Allega il controllo dello stato creato nel task 7.
Task 9: Impostazione di OCI Full Stack DR
-
Creare un DRPG in entrambe le aree. Andare alla console OCI, andare a Migrazione e recupero da errori irreversibili e fare clic su Gruppi di protezione DR. Ad esempio,
primary-drpg-sydney
estandby-drpg-melbourne
. -
Associare i DRPG. Andare alla console OCI, andare a Migrazione e recupero da errori irreversibili, Gruppi di protezione DR e fare clic su Associa.
-
Aggiungi risorse al DRPG (regione Sydney). Andare alla console OCI, andare a Migrazione e disaster recovery, gruppi di protezione DR, Membri e fare clic su Aggiungi membro.
-
Aggiungere il cluster OKE e Oracle Autonomous Database.
-
Aggiungi risorse alla regione di DRPG (Melbourne): cluster OKE e Oracle Autonomous Database.
-
Crea un piano DR nella standby region (Melbourne). Andare alla console OCI, andare a Migrazione e recupero da errori irreversibili, gruppi di protezione DR, Piani e fare clic su Crea piano.
L'immagine seguente mostra un piano DR che orchestra il recupero per un intero stack di applicazioni, che può includere altri servizi insieme a OKE.
Come potete vedere dall'immagine, abbiamo dei passaggi integrati per OKE. Il servizio DR OCI Full Stack esegue uno strumento di backup sviluppato internamente. Questo strumento eseguirà periodicamente i backup del cluster di distribuzioni, set di repliche, pod, CronJobs, set di daemon e così via.
I backup verranno memorizzati nel bucket di storage degli oggetti OCI specificato nella proprietà del membro.
-
OKE - Arresta backup e cleanup (principale): arresta i backup e termina tutte le risorse menzionate nel cluster OKE.
-
OKE - Ripristina (in standby): utilizzando il backup, viene ripristinato il backup più recente nel cluster OKE DR, in modo da avere tutte le risorse create nel cluster OKE.
-
OKE - Pianifica backup inverso (in standby): impostare il backup inverso per il piano di switchback.
Se si utilizza PersistentVolume (PV) e PersistentVolumeClaim (PVC), è necessario configurare i gruppi di volumi tra più aree (storage a blocchi) e la replica FSS tra più aree (storage di file) e aggiungerli come membri nel DRPG. Ciò creerà ulteriori gruppi di piani, come quello che abbiamo visto per OKE e Oracle Autonomous Database.
-
-
Eseguire uno switchover. Questo passo deve essere eseguito dal sito in standby (Melbourne).
Andare alla console OCI, andare a Migrazione e recupero da errori irreversibili, Gruppi di protezione DR e fare clic su Esegui piano DR.
Task 10: Test e convalida dell'applicazione
Accedi all'applicazione dalla standby region e assicurati che tutto funzioni. L'applicazione deve essere accessibile all'indirizzo https://mushop.domain.com
o utilizzare l'indirizzo http://standbyloadbalancerIP.com
.
Assicurati di poter accedere agli elementi del catalogo, a indicare che il database in standby è completamente operativo.
Nota: in questa esercitazione sono stati esclusi i passi per includere i certificati SSL su OCI Load Balancer e utilizzare OCI Web Application Firewall. Questi due componenti possono essere aggiunti agli ambienti di produzione.
Passi successivi
Hai visto come un'applicazione di e-commerce basata su microservizi, distribuita su OCI Kubernetes Engine, può essere configurata con il servizio OCI Full Stack DR per abilitare il disaster recovery in modalità warm standby. Abbiamo mostrato come questa applicazione può eseguire senza problemi il failover senza alcun intervento manuale. Per ulteriori informazioni, consulta la documentazione di OCI Full Stack DR nella sezione Collegamenti correlati.
Collegamenti correlati
Conferme
-
Autore - Venugopal Naik (architetto cloud principale)
-
Contributori - Raphael Teixeira (membro principale dello staff tecnico per FSDR), Suraj Ramesh (Principal Product Manager per MAA)
Altre risorse di apprendimento
Esplora altri laboratori su docs.oracle.com/learn o accedi a più contenuti gratuiti sulla formazione su Oracle Learning YouTube channel. Inoltre, visita education.oracle.com/learning-explorer per diventare un Oracle Learning Explorer.
Per la documentazione del prodotto, visita l'Oracle Help Center.
Automate a Switchover and Failover Plan for a Demo Application Deployed on OCI Kubernetes Engine with OCI Full Stack Disaster Recovery
G23615-01
December 2024