Remarques :

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

Architecture de déploiement OKE

Remarque : la région principale est Sydney et la région de récupération après sinistre est Melbourne.

Objectifs

Prérequis

Tâche 1 : installation et configuration d'Oracle Autonomous Database

  1. 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}
    
  2. 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)
    
  3. 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
    
  4. 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
    
  5. 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.
  6. 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)
    
  7. 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
    
  8. 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 :

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

  1. Créez un espace de noms.

    kubectl create ns mushop
    
  2. 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}
    
  3. 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}
    
  4. 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).

  1. Clonez le référentiel.

    git clone git@github.com:naikvenu/fsdr-demo.git
    
  2. Accédez au dossier Chart.

    cd fsdr-demo/helm-chart/
    
  3. Mettez à jour les dépendances du graphique.

    helm dependency update ./setup
    
  4. Installez et configurez le graphique.

    helm upgrade --install mushop-utils setup --dependency-update --namespace mushop-utilities --create-namespace
    
  5. 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}')
    
  6. Installez l'application sur le cluster OKE.

    helm upgrade --install -f ./mushop/values-dr.yaml \
       fsdrmushop mushop -n mushop
    
  7. Accédez à l'application MuShop principale à l'aide de l'adresse IP entrante.

    kubectl get svc mushop-utils-ingress-nginx-controller \
       --namespace mushop-utilities
    
  8. 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.

  1. 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
    
  2. Clonez le référentiel.

    git clone git@github.com:naikvenu/fsdr-demo.git
    

    Ou

    git clone  https://github.com/naikvenu/fsdr-demo
    
  3. Accédez au dossier des graphiques.

    cd fsdr-demo/helm-chart/
    
  4. Mettez à jour les dépendances du graphique.

    helm dependency update ./setup
    
  5. 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
    
  6. 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}')
    
  7. Créez un espace de noms MuShop.

    kubectl create namespace mushop
    
  8. 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.

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.

Tâche 9 : configuration d'OCI Full Stack DR

  1. 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 et standby-drpg-melbourne.

  2. 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.

  3. 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.

  4. Ajoutez le cluster OKE et Oracle Autonomous Database.

    Membres DRPG

  5. Ajoutez des ressources au DRPG (région de Melbourne) - cluster OKE et Oracle Autonomous Database.

    Membres DRPG

  6. 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.

    Membres DRPG

    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.

  7. 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.

Membres DRPG

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.

Remerciements

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.