Remarques :
- Ce tutoriel nécessite un accès à Oracle Cloud. Pour vous inscrire à un compte gratuit, reportez-vous à Introduction au niveau gratuit d'Oracle Cloud Infrastructure.
- Il utilise des exemples de valeurs pour les informations d'identification, la location et les compartiments Oracle Cloud Infrastructure. Lorsque vous terminez votre atelier, remplacez ces valeurs par celles propres à votre environnement cloud.
Automatiser un plan de permutation et de basculement pour une application de démonstration déployée sur OCI Kubernetes Engine avec OCI Full Stack Disaster Recovery
Introduction
Ce tutoriel présente un cas d'utilisation d'Oracle Cloud Infrastructure Full Stack Disaster Recovery (OCI Full Stack DR) avec une application de e-commerce de démonstration déployée sur un cluster Oracle Cloud Infrastructure Kubernetes Engine (OCI Kubernetes Engine ou OKE).
Au moment de la rédaction de ce tutoriel, OCI Full Stack DR a annoncé une disponibilité limitée pour OKE. Dans une version limitée, nous pouvons essayer OCI Full Stack DR sur des applications basées sur OKE telles que MuShop, une application de démonstration basée sur les microservices qui utilise divers autres services Oracle Cloud Infrastructure (OCI) en tant qu'application unique.
Nous utiliserons une approche de secours à chaud : un modèle de récupération après sinistre où tout ou partie des composants d'application sont pré-déployés dans une région de secours pour permettre une transition plus rapide de la récupération après sinistre. Bien que ce modèle implique des coûts d'exploitation plus élevés, il fournit un objectif de temps de récupération (RTO) inférieur.
OCI Full Stack DR orchestre la transition des calculs, des bases de données et des applications entre les régions OCI du monde entier en un seul clic. Les clients peuvent automatiser les étapes nécessaires à la récupération d'un ou de plusieurs systèmes métier sans repenser ou modifier l'architecture de l'infrastructure, des bases de données ou des applications existantes sans avoir besoin de serveurs de gestion ou de conversion spécialisés.
Architecture de déploiement
Remarque : la région principale est Sydney et la région de récupération après sinistre est Melbourne.
Objectifs
-
Conformément à l'architecture, nous allons créer un groupe de protection de récupération après sinistre nommé
Mushop-Syd
dans la région principale de Sydney. -
Le DRPG principal contient un ensemble de différentes ressources OCI qui constituent une application et qui doivent être traitées comme un groupe combiné lors de l'exécution d'opérations de récupération après sinistre. Nous avons ajouté OKE et Oracle Autonomous Database Serverless (Autonomous Database Serverless) au DRPG principal. Ce tutoriel indique également les étapes de déploiement de l'application MuShop et de toutes les autres ressources nécessaires au déploiement.
-
Un DRPG similaire est créé dans la région de Melbourne en standby. OKE et Autonomous Database Serverless (en mode de secours) sont ajoutés au DRPG. Les équilibreurs de charge ne font pas partie du DRPG, mais seront exécutés indépendamment sur les deux sites, comme indiqué dans l'architecture de déploiement.
-
Une association est formée entre les deux DRPG.
-
Au niveau du DRPG de secours (Melbourne), un plan de récupération après sinistre est créé. Ce plan représente un workflow de récupération après sinistre (séquence d'étapes).
-
Exécutez un plan de récupération après sinistre. Une permutation est exécutée, qui prévoit une transition des services du DRPG principal vers le DRPG de secours. Les plans de permutation effectuent une transition ordonnée en arrêtant la pile d'applications dans la région principale, puis en la démarrant dans la région de secours. Par conséquent, les composants de pile d'applications et les autres services OCI requis doivent être disponibles dans les deux régions.
Prérequis
-
Privilèges d'administrateur ou configuration des stratégies Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) requises pour OCI Full Stack DR. Pour plus d'informations, reportez-vous à Configuration de stratégies Identity and Access Management (IAM) pour utiliser OCI Full Stack DR et à Stratégies pour OCI Full Stack DR.
-
Configuration de l'environnement :
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
Ajoutez les lignes suivantes à un fichier nommé
env
et sourcez-le.source env
Remarque :
- Pour plus d'informations sur les critères de mot de passe pour Autonomous Database Serverless, reportez-vous à A propos des mots de passe utilisateur sur Autonomous Database.
- Le nom sans serveur Autonomous Database ne peut contenir que des caractères alphanumériques.
- Remplacez
DB_PASSWORD
etWALLET_PW
dans les variables d'environnement ci-dessus.
Tâche 1 : installation et configuration d'Oracle Autonomous Database
-
Créez l'instance Oracle Autonomous Database principale.
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}
-
Extrayez l'OCID Oracle Autonomous Database principal.
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)
-
Créez la récupération après sinistre de secours et activez Oracle Data Guard inter-région.
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
-
Téléchargez et extrayez le portefeuille de base de données autonome à partir de l'instance Oracle Autonomous Database principale.
oci db autonomous-database generate-wallet --autonomous-database-id ${DB_ID}\ --password ${WALLET_PW} --file ${WALLET_ZIP} --region $PRIMARY_REGION
-
Décompressez le portefeuille sur le serveur principal.
unzip ${WALLET_ZIP} -d /tmp/wallet_primary
Remarque :
- Gardez ce portefeuille à portée de main car nous devrons l'ajouter en tant que clé secrète OKE ultérieurement.
- Le portefeuille doit être téléchargé séparément pour les régions principale et de secours car les entrées DNS
tnsnames.ora
sont différentes.
-
Extrayez l'OCID Oracle Autonomous Database de secours.
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)
-
Téléchargez et extrayez le portefeuille de base de données autonome à partir de la base de données de secours Oracle Autonomous Database.
oci db autonomous-database generate-wallet --autonomous-database-id \ ${STANDBY_DB_ID} --password ${WALLET_PW} \ --file ${STANDBY_WALLET_ZIP} --region $STANDBY_REGION
-
Décompressez le portefeuille de secours.
unzip ${STANDBY_WALLET_ZIP} -d /tmp/wallet_standby
Tâche 2 : créer un cluster OKE
Créez un cluster OKE sur les sites principal et de récupération après sinistre. Pour plus d'informations, reportez-vous à Création d'un cluster avec Oracle Cloud Infrastructure Container Engine for Kubernetes.
Nous avons utilisé l'option Création rapide pour créer des clusters avec les informations suivantes :
- Nom de cluster : entrez
primary-syd-oke-demo-cluster
(Sydney) etstandby-mel-oke-demo-cluster
(Melbourne). - Adresse d'API Kubernetes : sélectionnez Public.
- Type de noeud : sélectionnez Géré.
- Sélectionnez Processus actifs privés.
- Forme : sélectionnez VM Standard E3 Flex (4 OCPU, 64 Go de mémoire).
- Sélectionnez Oracle Linux 8.
Pour accéder à votre cluster, accédez à la console OCI, au service de développeur, au conteneur et aux artefacts, puis cliquez sur Clusters Kubernetes (OKE).
Ou
Exécutez la commande suivante pour accéder à votre 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
Tâche 3 : configuration des clés secrètes Kubernetes sur le site principal
-
Créez un espace de noms.
kubectl create ns mushop
-
Ajoutez la clé secrète de mot de passe d'administrateur Oracle Autonomous Database.
kubectl create secret generic oadb-admin \ --namespace mushop \ --from-literal=oadb_admin_pw=${DB_PASSWORD}
-
Ajoutez la clé secrète de connexion 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}
-
Ajoutez la clé secrète de portefeuille principale.
kubectl create secret generic oadb-wallet \ --namespace mushop --from-file=/tmp/wallet_primary
Tâche 4 : configuration de l'application MuShop
Remarque : l'application est déployée uniquement dans la région principale (
ap-sydney-1
).
-
Clonez le référentiel.
git clone git@github.com:naikvenu/fsdr-demo.git
-
Accédez au dossier Chart.
cd fsdr-demo/helm-chart/
-
Mettez à jour les dépendances du graphique.
helm dependency update ./setup
-
Installez et configurez le graphique.
helm upgrade --install mushop-utils setup --dependency-update --namespace mushop-utilities --create-namespace
-
Localisez l'adresse
EXTERNAL-IP
du contrôleur d'entrée.PRIMARY_EXTERNAL_IP=$(kubectl get svc -n mushop-utilities mushop-utils-ingress-nginx-controller -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
-
Installez l'application sur le cluster OKE.
helm upgrade --install -f ./mushop/values-dr.yaml \ fsdrmushop mushop -n mushop
-
Accédez à l'application MuShop principale à l'aide de l'adresse IP entrante.
kubectl get svc mushop-utils-ingress-nginx-controller \ --namespace mushop-utilities
-
Pour vérifier l'application, accédez à
http://<primary-site-ingress-ip-address>
et assurez-vous que tous les produits du catalogue MuShop sont répertoriés sans erreur.
Tâche 5 : configurer un cluster OKE sur le site de secours
Remarque : étant donné que nous utilisons une approche de secours à chaud, nous devons créer un cluster OKE et exécuter quelques opérations de base, telles que le contrôleur d'entrée. Les étapes suivantes vous aideront à le faire.
-
Pour accéder au cluster sur le site de secours, accédez à la console OCI, accédez au service de développeur, au conteneur et aux artefacts, puis cliquez sur Clusters Kubernetes (OKE).
Ou
Exécutez la commande suivante pour accéder au cluster sur le site de secours.
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
-
Clonez le référentiel.
git clone git@github.com:naikvenu/fsdr-demo.git
Ou
git clone https://github.com/naikvenu/fsdr-demo
-
Accédez au dossier des graphiques.
cd fsdr-demo/helm-chart/
-
Mettez à jour les dépendances du graphique.
helm dependency update ./setup
-
Installez et configurez les graphiques. Cette opération est requise pour déployer un contrôleur entrant (équilibreur de charge OCI) afin d'accéder à l'application.
Remarque : cette étape déploiera uniquement un contrôleur entrant (équilibreur de charge OCI) et non l'application complète.
helm upgrade --install mushop-utils setup --dependency-update --namespace mushop-utilities --create-namespace
-
Localisez l'adresse
EXTERNAL-IP
du contrôleur d'entrée.STANDBY_EXTERNAL_IP=$(kubectl get svc -n mushop-utilities mushop-utils-ingress-nginx-controller -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
-
Créez un espace de noms MuShop.
kubectl create namespace mushop
-
Créez une clé secrète pour le portefeuille.
kubectl create secret generic oadb-wallet \ --namespace mushop --from-file=/tmp/wallet_standby
Remarque : nous utilisons un portefeuille de secours.
Tâche 6 : configuration des zones DNS (facultatif)
Dans la région principale, accédez à la console OCI, accédez à Fonctions de réseau, à Gestion DNS, à Zones et cliquez sur Créer une zone.
Configuration:
The Zone type : Primary
‘A’ record: “mushop”
Le nom de la zone doit correspondre à votre nom de domaine acheté. Saisissez les serveurs de noms à ajouter à votre domaine.
L'application sera accessible à l'adresse https://mushop.<your-domain>.com
.
Tâche 7 : création de vérifications de l'état (facultatif)
Des vérifications de l'état sont requises pour configurer les stratégies de pilotage du trafic DNS OCI.
Exécutez la commande suivante pour créer des vérifications de l'état.
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
Ou
Accédez à la console OCI, accédez à Observation et gestion, à Surveillance, à Vérifications de l'état, cliquez sur Créer une vérification de l'état et entrez les informations suivantes.
- Nom : entrez
FSDR-APP-HEALTHCHECK
. - Cibles : entrez les adresses IP des équilibreurs de charge principal et de secours.
- Protocole : sélectionnez http.
- Port : entrez 80.
- Chemin cible : entrez
/
. - Method : sélectionnez GET.
- Délai d'expiration : entrez 30.
- Intervalle : entrez 30 secondes.
Tâche 8 : configuration de la stratégie de pilotage de la gestion du trafic (facultatif)
Accédez à la console OCI, accédez à Fonctions de réseau, à Gestion DNS, à Stratégies de pilotage de Traffic Management, cliquez sur Créer une stratégie de pilotage de Traffic Management et entrez les informations suivantes.
- Nom : entrez
FSDR-POLICY
. - TTL : entrez 60 secondes.
- Pool 1:
- Nom : entrez
Primary
. - Type : sélectionnez A.
- Rdata : entrez l'adresse IP de l'équilibreur de charge principal.
- Nom : entrez
- Pool 2:
- Nom : entrez
Standby
. - Type : sélectionnez A.
- Rdata : entrez l'adresse IP de l'équilibreur de charge de secours.
- Nom : entrez
- Sélectionner la priorité du pool :
- Pool1
- Pool2
- Associez la vérification de l'état créée dans la tâche 7.
Tâche 9 : configuration d'OCI Full Stack DR
-
Créez un DRPG dans les deux régions. Accédez à la console OCI, accédez à Migration et récupération après sinistre et cliquez sur Groupes de protection de récupération après sinistre. Par exemple,
primary-drpg-sydney
etstandby-drpg-melbourne
. -
Associez les DRPG. Accédez à la console OCI, accédez à Migration et récupération après sinistre, à Groupes de protection de récupération après sinistre, puis cliquez sur Associer.
-
Ajoutez des ressources au DRPG (région de Sydney). Accédez à la console OCI, accédez à Migration et récupération après sinistre, à Groupes de protection de récupération après sinistre, à Membres et cliquez sur Ajouter un membre.
-
Ajoutez le cluster OKE et Oracle Autonomous Database.
-
Ajoutez des ressources au DRPG (région de Melbourne) - cluster OKE et Oracle Autonomous Database.
-
Créez un plan de récupération après sinistre dans la région de secours (Melbourne). Accédez à la console OCI, accédez à Migration et récupération après sinistre, à Groupes de protection de récupération après sinistre, à Plans et cliquez sur Créer un plan.
L'image suivante présente un plan de récupération après sinistre qui orchestre la récupération pour l'ensemble d'une pile d'applications, qui peut inclure d'autres services avec OKE.
Comme vous pouvez le voir sur l'image, nous avons intégré des étapes pour OKE. Le service OCI Full Stack DR exécute un outil de sauvegarde développé en interne. Cet outil effectue régulièrement les sauvegardes du cluster de déploiements, d'ensembles de répliques, de pods, de CronJobs, d'ensembles de démons, etc.
Les sauvegardes seront stockées dans le bucket OCI Object Storage indiqué dans la propriété de membre.
-
OKE - Arrêter la sauvegarde et le nettoyage (principal) : arrête les sauvegardes et met fin à toutes les ressources mentionnées dans le cluster OKE.
-
OKE - Restaurer (de secours) : à l'aide de la sauvegarde, elle restaure la dernière sauvegarde dans le cluster OKE de récupération après sinistre, de sorte que toutes les ressources sont créées dans le cluster OKE.
-
OKE - Programmer une sauvegarde inversée (de secours) : définissez la sauvegarde inversée pour le plan de permutation.
Si vous utilisez PersistentVolume (PV) et PersistentVolumeClaim (PVC), vous devez configurer des groupes de volumes inter-région (stockage de blocs) et une réplication FSS inter-région (stockage de fichiers) et les ajouter en tant que membres dans le DRPG. Cela créera des groupes de plans supplémentaires, comme ce que nous avons vu pour OKE et Oracle Autonomous Database.
-
-
Réalisation d'une permutation. Cette étape doit être effectuée à partir du site de secours (Melbourne).
Accédez à la console OCI, accédez à Migration et récupération après sinistre, à Groupes de protection de récupération après sinistre, puis cliquez sur Exécuter le plan de récupération après sinistre.
Tâche 10 : tester et valider l'application
Accédez à l'application à partir de la région de secours et assurez-vous que tout fonctionne. L'application doit être accessible à l'adresse https://mushop.domain.com
ou utiliser l'adresse http://standbyloadbalancerIP.com
.
Assurez-vous que vous pouvez accéder aux articles du catalogue, ce qui indique que la base de données de secours est entièrement opérationnelle.
Remarque : dans ce tutoriel, nous avons exclu les étapes permettant d'inclure des certificats SSL sur l'équilibreur de charge OCI et d'utiliser OCI Web Application Firewall. Ces deux composants peuvent être ajoutés aux environnements de production.
Etapes suivantes
Vous avez vu comment une application de commerce électronique basée sur des microservices, déployée sur OCI Kubernetes Engine, peut être configurée avec le service OCI Full Stack DR pour permettre la récupération après sinistre en mode de secours à chaud. Nous avons montré comment cette application peut basculer sans aucune intervention manuelle. Pour plus d'informations, reportez-vous à la documentation OCI Full Stack DR dans la section Liens connexes.
Liens connexes
Remerciements
-
Auteur - Venugopal Naik (architecte cloud principal)
-
Contributeurs - Raphael Teixeira (membre principal du personnel technique pour FSDR), Suraj Ramesh (chef de produit principal pour MAA)
Ressources de formation supplémentaires
Explorez d'autres ateliers sur docs.oracle.com/learn ou accédez à d'autres contenus de formation gratuits sur le canal Oracle Learning YouTube. De plus, visitez le site education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.
Pour obtenir la documentation produit, consultez le site Oracle Help Center.
Automate a Switchover and Failover Plan for a Demo Application Deployed on OCI Kubernetes Engine with OCI Full Stack Disaster Recovery
G23614-01
December 2024