Avant de commencer

Avant de créer les clusters, rassemblez les informations relatives au VPC et à l' Cloud Object Storage s dont vous aurez besoin pour remplir les commandes de création de cluster.

1. Récupérez vos identifiants VPC. Notez l'ID du VPC que vous souhaitez utiliser pour chaque cluster.

   ibmcloud is vpcs
   

2. Récupérer les détails du sous-réseau d'un VPC spécifique. Notez les identifiants de sous-réseau que vous souhaitez utiliser pour chaque cluster.

   ibmcloud is subnets --vpc VPC_ID
   

3. Répertoriez vos instances d' Cloud Object Storage.

   ibmcloud resource service-instances --service-name cloud-object-storage
   

4. Récupérez le CRN de l'instance que vous souhaitez utiliser. Notez la valeur dans le champ ID.

   ibmcloud resource service-instance SERVICE_INSTANCE
   

Etape 1. Créer le cluster central

Cluster Hub

Il s'agit du cluster sur lequel vous installez ACM pour gérer les clusters ODF principal et secondaire. Assurez-vous que votre cluster de hub dispose d'au moins de capacité de calcul 16 vCPU x 64 GB disponible.

Pour chaque cluster, assurez-vous d'autoriser le trafic sortant en incluant le paramètre --disable-outbound-traffic-protection dans le CLI ou en sélectionnant l'option de désactivation de la protection du trafic sortant dans l'interface utilisateur.

1. Créez un cluster VPC sur us-east pour y installer ACM. Il s'agit du cluster central que vous pouvez utiliser pour gérer vos clusters ODF. Assurez-vous que votre cluster Hub dispose d’au moins 3 nœuds de travail exécutant RHCOS, d’une capacité de calcul disponible d’au moins 16 vCPU et 64 Go, que le trafic sortant est désactivé et qu’il répond à toutes les conditions préalables pour ACM. L'exemple de commande suivant crée un cluster pour ACM dans us-east.

   ibmcloud ks cluster create vpc-gen2 --flavor bx2.16x64 --name acm-hub-cluster-dr-odf --subnet-id SUBNET_ID --vpc-id VPC_ID --zone us-east-2 --version 4.21.27_openshift --workers 3 --cos-instance COS_CRN --disable-outbound-traffic-protection --cni OVNKubernetes
   

2. Notez l'ID du cluster indiqué dans la sortie. Vous en aurez besoin à une étape ultérieure.

Étape 2. Créer un profil de confiance pour le cluster hub

Cluster Hub

1. Créer un profil de confiance.

   ibmcloud iam trusted-profile-create acm-operator-profile
   

2. Créez la règle de confiance des ressources de calcul, dont la portée est limitée à l'espace de kube-system noms des ressources de calcul d' Red Hat OpenShift.

   ibmcloud iam trusted-profile-rule-create acm-operator-profile \
     --name kube-system-rule \
     --type Profile-CR \
     --conditions claim:namespace,operator:EQUALS,value:kube-system \
     --cr-type ROKS_SA
   

3. Attribuez la politique d'accès IAM au profil. Remplacez CLUSTER_ID par l'ID de votre cluster de hub.

   ibmcloud iam trusted-profile-policy-create acm-operator-profile \
     --roles Reader,Viewer,Operator,Editor \
     --service-name containers-kubernetes \
     --service-instance CLUSTER_ID
   

4. Attribuez le profil de confiance au cluster du hub. Une fois que vous avez attribué un profil de confiance à un cluster, celui-ci ne peut plus être supprimé.

   ibmcloud oc experimental trusted-profile set --cluster CLUSTER_NAME_OR_ID --trusted-profile TRUSTED_PROFILE_ID
   

5. Si vous utilisez la version 4.21 ou une version ultérieure d’ODF, installez l’opérateur OpenShift GitOps sur le cluster hub. Pour connaître les étapes d'installation, consultez la section Installation d' Red Hat OpenShift GitOps Operator dans la console Web.

Étape 3. Créer les clusters gérés

Cluster géré

1. Créez un cluster VPC dans us-east comprenant au moins 3 nœuds de travail exécutant RHCOS, une capacité de calcul disponible d'au moins 16 vCPU et 64 Go, et la protection du trafic sortant désactivée. Il s'agit du premier cluster ODF géré. La commande suivante permet de créer un cluster dans us-east.

   ibmcloud ks cluster create vpc-gen2 --flavor bx2.16x64 --name managed-cluster-1-dr-odf --subnet-id SUBNET_ID --vpc-id VPC_ID --zone us-east-2 --version 4.21.27_openshift --workers 3 --cos-instance COS_CRN --disable-outbound-traffic-protection --cni OVNKubernetes
   

2. Créez un cluster VPC dans jp-tok comprenant au moins 3 nœuds de travail exécutant RHCOS, une capacité de calcul disponible d'au moins 16 vCPU et 64 Go, et la protection du trafic sortant désactivée. Il s'agit du cluster ODF secondaire géré. Pour la haute disponibilité, assurez-vous que le réseau du cluster secondaire ne chevauche pas le réseau du cluster primaire. La commande suivante permet de créer un cluster dans jp-tok.

   ibmcloud ks cluster create vpc-gen2 --flavor bx2.16x64 --name managed-cluster-2-dr-odf --subnet-id SUBNET_ID --vpc-id VPC_ID --zone jp-tok --version 4.21.27_openshift --workers 3 --cos-instance COS_CRN --disable-outbound-traffic-protection --cni OVNKubernetes
   

Étape 4. Préparer les secrets pour ACM

Cluster Hub

Pour chaque cluster que vous souhaitez gérer avec ACM, vous devez créer un secret sur le cluster hub qui inclut le jeton d'accès et l' URL du serveur du cluster géré.

Si vous souhaitez importer des clusters gérés lors du processus d'installation du module complémentaire ACM, suivez ces étapes avant de commencer l'installation. Si vous choisissez de créer les secrets et d'importer des clusters gérés après l'installation du module complémentaire sur le cluster hub, vous pouvez le faire en effectuant des étapes supplémentaires via l'interface de ligne de commande (CLI).

Suivez les étapes suivantes pour chaque cluster que vous souhaitez gérer.

1. Sur le cluster que vous souhaitez gérer avec ACM, exécutez la commande suivante pour trouver l' URL du serveur. Dans le résultat, recherchez et notez la valeur Master URL. Il s'agit de l' URL du serveur à indiquer dans le secret. Vous utiliserez également cette URL dans les étapes suivantes.

   ibmcloud oc cluster get -c CLUSTER_NAME_OR_ID
   

   Exemple de sortie.

   NAME:                           mycluster
   ID:                             1234567
   State:                          normal
   Created:                        2025-01-22T19:22:16+0000
   Location:                       dal10
   Master URL:                     https://c100-e.<region>.containers.cloud.ibm.com:<port>
   ...
   

2. Récupérer l' URL e de base du serveur OAuth de l' Red Hat OpenShift. Remplacez par MASTER_URL l' URL ion obtenue à l'étape précédente. La commande extrait l' URL de base sans le suffixe /oauth/token.

   curl -sS MASTER_URL/.well-known/oauth-authorization-server | jq -r .token_endpoint | sed 's#/oauth/token##'
   

   Exemple de sortie.

   https://c111-e.us-east.containers.cloud.ibm.com:31282
   

3. Récupérez un jeton d'accès à l'aide du point de terminaison obtenu à l'étape précédente.

   Exécutez la commande suivante : <CODE_INLINE> cURL </CODE_INLINE>, en remplaçant par URL la sortie de l'étape précédente et par API_KEY votre clé API <CODE_INLINE> IBM Cloud </CODE_INLINE >.

   Dans la réponse, recherchez le contenu ACCESS_TOKEN dans la réponse Location. Il s'agit du jeton d'accès à inclure dans le secret.

   Exemple de requête curl :

   curl -u 'apikey:API_KEY' -H "X-CSRF-Token: a" 'URL/oauth/authorize?client_id=openshift-challenging-client&response_type=token' -vvv
   

   Exemple de sortie. L'ACCESS_TOKEN est inclus dans la chaîne de réponse Location.

   < HTTP/1.1 302 Found
   < Cache-Control: no-cache, no-store, max-age=0, must-revalidate
   < Cache-Control: no-cache, no-store, max-age=0, must-revalidate
   < Expires: 0
   < Expires: Fri, 01 Jan 2030 00:00:00 GMT
   < Location: TOKEN_ENDPOINT/oauth/token/implicit#access_token=ACCESS_TOKEN&expires_in=86400&scope=user%3Afull&token_type=Bearer
   ...
   

4. Sur le cluster hub, créez un secret contenant le jeton d'accès au cluster et l' URL du serveur. Pour plus d’informations sur la création de secrets, consultez la section Utilisation des secrets dans la documentation d’ Kubernetes.

   Exemple de secret.

   apiVersion: v1
   kind: Secret
   metadata:
     name: SECRET_NAME
     namespace: SECRET_NAMESPACE  # The namespace that the secret is to be created in
   type: Opaque
   stringData:
     token: ACCESS_TOKEN
     server: SERVER_URL
   

Étape 5. Installez le module complémentaire ACM sur le cluster du hub

Cluster Hub

Utilisez l'interface de ligne de commande (CLI) pour installer le module complémentaire ACM sur le cluster hub.

1. Rechercher la version par défaut du module complémentaire ACM.

   ibmcloud oc cluster addon versions
   

2. Consultez les options d'extension ACM. Dans la commande, indiquez la version par défaut identifiée à l'étape précédente. Notez toutes les options que vous souhaitez inclure lors de l'installation du module complémentaire.

   ibmcloud oc cluster addon options --addon acm --version DEFAULT_VERSION
   

3. Si vous souhaitez importer des clusters destinés à être gérés par le module complémentaire, suivez les étapes décrites dans la section Préparation des secrets pour ACM si vous ne l'avez pas déjà fait. Veillez à enregistrer l'ID du cluster ainsi que le nom et l'espace de noms du secret que vous créez sur le cluster hub. Vous pouvez également effectuer cette procédure une fois le module complémentaire installé sur le cluster hub; toutefois, des étapes supplémentaires sont nécessaires pour importer les clusters gérés après l'installation.

4. Exécutez la commande pour activer le module complémentaire. Veillez à spécifier les isLicenseAccepted paramètres et billingPlan, ainsi que le --managedClusters paramètre facultatif si vous souhaitez importer des clusters au cours du processus d'installation.

   ibmcloud oc cluster addon enable acm --cluster HUB_CLUSTER_ID --param 'managedClusters=["clusterid:CLUSTER_ID;secretname:SECRET_NAME;secretnamespace:SECRET_NAMESPACE;action:IMPORT"]' --param 'billingPlan=PLAN' --param 'isLicenseAccepted=BOOLEAN'
   

   Paramètres de commande. Consultez la commande d'exemple ci-dessous pour voir un exemple de chaque type de paramètre.

   --cluster

   Obligatoire. L'ID du cluster hub sur lequel installer le module complémentaire ACM.

   --param 'managedClusters=["]

   Optionnel. Incluez ce paramètre une ou plusieurs fois pour importer des clusters gérés lors du processus d'installation du module complémentaire. Vous pouvez également effectuer cette étape plus tard. Pour plus d’informations, consultez la section Préparation des secrets pour ACM.

   Indiquez les valeurs suivantes :

   • clusterid: l'identifiant du cluster géré à importer.

   • secretname: nom du secret que vous avez créé sur le cluster du hub. Ce secret contient les identifiants d'accès au cluster géré.

   • secretnamespace: l'espace de noms du secret que vous avez créé sur le cluster hub. Ce secret contient les identifiants d'accès au cluster géré.

   • action:IMPORT: paramètre qui spécifie l'action IMPORT pour le cluster géré.

   --param 'billingPlan='

   Obligatoire. Le forfait de facturation que vous souhaitez sélectionner pour ACM. Précisez KUBERNETES pour le plan ACM Kubernetes.

   --param 'isLicenseAccepted='

   Obligatoire. Cochez cette case pour TRUE accepter le contrat de licence correspondant au forfait de facturation sélectionné. En acceptant cette licence, vous acceptez les conditions générales applicables et confirmez avoir pris connaissance des services inclus dans la formule sélectionnée.

   Exemple de commande permettant d'installer le module complémentaire ACM avec le plan de facturation ACM for Kubernetes et d'importer un cluster géré.

   ibmcloud ks cluster addon enable acm --cluster a5bcde982dfer2nwxq73 --param 'managedClusters=["clusterid:w7rthce34gfbq7ww12d3;secretname:managed-secret-1;secretnamespace:managed-ns1;action:Import"]' --param 'billingPlan=KUBERNETES' --param 'isLicenseAccepted=true'
   

5. Vérifiez que le module complémentaire est bien installé. L'affichage du module complémentaire dans les résultats suivants peut prendre plusieurs minutes.

   1. Sur le cluster hub, vérifiez que la ressource acmhub a bien été créée.

       oc get acmhub
       ```
       Exemple
       de sortie.
   
       ```sh {: screen}
           NAME       AGE
           acm-auto   1h
       ```
   1. Sur le cluster hub, vérifiez l'état `acmhub`.
   
   ```sh {: pre}
       oc describe acmhubstatus
       ```
       Exemple
       de sortie.
   
       ```sh {: screen}
       status
           phase: Ready
       ```
   

Étape 6. Configurer le module complémentaire Submariner

Cluster géré

Suivez les étapes pour installer et configurer le module complémentaire Submariner, qui établit la connectivité entre vos deux clusters gérés. Ces étapes utilisent la console ACM. Pour plus d'informations, consultez la section Déploiement de Submariner à l'aide de la console dans la documentation d' Red Hat.

1. Accédez à la console ACM. Cliquez ensuite sur Gestion de la flotte > Infrastructure > Clusters > Clusterset.
2. Cliquez sur Créer un ensemble de clusters. Suivez les invites pour ajouter vos deux clusters gérés à l'ensemble de clusters.
3. Cliquez sur l'option permettant d'installer le module complémentaire Submariner sur l'ensemble de clusters.
4. Sélectionnez les clusters gérés comme clusters cibles pour l'installation du module complémentaire.
5. Lors de la vérification de la configuration des deux clusters, modifiez les paramètres suivants comme indiqué et laissez les autres tels qu'ils sont par défaut. Cliquez ensuite sur Installer.

   globalnetEnabled: true (checked)
   gateways: 2
   NATTEnable: false (unchecked)
   cableDriver: vxlan.
   

6. Attendez que le statut de l'add-on Submariner indique que tout est en ordre (vert). Cela peut prendre jusqu'à 20 minutes.

Etape 7. Installer et configurer OpenShift Data Foundation

Cluster géré

Installez et configurez ODF sur vos 2 clusters gérés. Veillez à effectuer ces étapes à la fois sur le cluster géré principal et sur le cluster géré secondaire.

1. Suivez les étapes pour installer le module complémentaire OpenShift Data Foundation sur vos 2 clusters gérés. Spécifiez la version ODF par défaut ou ultérieure. Veillez à inclure l'option d'activation de NooBaa en tant qu'option complémentaire lors de l'installation.

2. Vérifiez que la fondation ODF a été installée avec succès. Dans la sortie, vérifiez que le statut indique Ready.

   oc get storagecluster -n openshift-storage ocs-storagecluster -o jsonpath='{.status.phase}{"\n"}'
   

3. Exécutez la commande pour mettre à jour le site ACM Managed Cluster Name dans la section multiClusterService de la ressource storageCluster. Cela permet à ODF d'utiliser GlobalNet. Pour plus d'informations, voir Création d'un cluster OpenShift Data Foundation sur des clusters gérés.

   Veillez à remplacer MANAGED_CLUSTER_NAME dans la commande par le nom de votre cluster géré.

   kubectl patch storagecluster -n openshift-storage ocs-storagecluster --type merge -p'{"spec":{"network":{"multiClusterService":{"clusterID":"MANAGED_CLUSTER_NAME","enabled":true}}}}'
   

4. Vérifier les exportations de services. Cela peut prendre quelques minutes pour apparaître dans le résultat.

   oc get serviceexport -n openshift-storage
   

   Exemple de sortie :

   NAME              AGE
   rook-ceph-mon-d   4d14h
   rook-ceph-mon-e   4d14h
   rook-ceph-mon-f   4d14h
   rook-ceph-osd-0   4d14h
   rook-ceph-osd-1   4d14h
   rook-ceph-osd-2   4d14h
   

5. Créez une exportation de service pour ocs-provider-server en utilisant le langage YAML suivant.

   apiVersion: multicluster.x-k8s.io/v1alpha1
   kind: ServiceExport
   metadata:
     name: ocs-provider-server
     namespace: openshift-storage
   

6. Exécutez la commande pour mettre à jour la ressource storageCluster afin d'utiliser l'exportation de service ocs-provider-server que vous avez créée.

   oc annotate storagecluster ocs-storagecluster -n openshift-storage ocs.openshift.io/api-server-exported-address=MANAGED_CLUSTER_NAME.ocs-provider-server.openshift-storage.svc.clusterset.local:50051.
   

7. Vérifiez que la ressource storageCluster est prête.

   oc get storagecluster -n openshift-storage
   

   Exemple de sortie.

   NAME                    PHASE  
   ocs-storagecluster      Ready   
   

Étape 8. Configurer la stratégie de reprise après sinistre régionale

Cluster Hub

Installez l'ODF Multicluster Orchestrator sur votre cluster central et créez la politique de reprise après sinistre (DR) qui permet la mise en miroir entre vos deux clusters gérés.

1. Suivez les étapes pour installer ODF Multicluster Orchestrator sur le cluster ACM. Pour assurer la compatibilité, assurez-vous d'installer le même numéro de version que la version d'ODF que vous avez installée sur les clusters gérés dans la section précédente.

2. Vérifiez l'installation en vous assurant que les modules d'exploitation fonctionnent.

   oc get pods -n openshift-operators
   

   Exemple de sortie.

   NAME                                        READY   STATUS       RESTARTS    AGE
   odf-multicluster-console-6845b795b9-blxrn   1/1     Running      0           4d20h
   odfmo-controller-manager-f9d9dfb59-jbrsd    1/1     Running      0           4d20h
   ramen-hub-operator-6fb887f885-fss4w         2/2     Running      0           4d20h
   

3. Sur le cluster ACM, créez une stratégie DR avec un intervalle de synchronisation de 5 minutes et spécifiez chaque cluster géré dans les paramètres. Cela crée NooBaa object buckets sur les deux clusters gérés et active ODF Ceph block pool mirroring pour la réplication des volumes.

   1. Accédez à la console ACM, puis cliquez sur Gestion de flotte > Services de données > Reprise après sinistre > Politiques > Créer une politique de reprise après sinistre.
   2. Créez une politique DR qui inclut les paramètres suivants.
      • Clusters connectés : PRIMARY_MANAGED_CLUSTER_NAME, SECONDARY_MANAGED_CLUSTER_NAME
      • Politique de réplication : Asynchrone
      • Intervalle de réplication : 5m

4. Sur le cluster hub, exécutez les commandes pour vérifier que la stratégie DR a été créée et appliquée aux clusters gérés.

   oc get drpolicy DRPOLICY_NAME -o jsonpath='{.status.conditions[].reason}{"\n"}'
   

   oc get drclusters
   

   Exemple de sortie.

   NAME        AGE
   managed-cluster1   4m42s
   managed-cluster2   4m42s
   

5. Sur chaque cluster géré, vérifiez que la politique DR a été appliquée et qu'elle est saine.

   oc get csv,pod -n openshift-dr-system
   

   Exemple de sortie.

   NAME                                                                          DISPLAY                         VERSION        REPLACES   PHASE
   clusterserviceversion.operators.coreos.com/odr-cluster-operator.v4.15.0       Openshift DR Cluster Operator   4.15.0                    Succeeded
   clusterserviceversion.operators.coreos.com/volsync-product.v0.8.0             VolSync                         0.8.0                     Succeeded
   NAME                                             READY   STATUS    RESTARTS   AGE
   pod/ramen-dr-cluster-operator-6467cf5d4c-cc8kz   2/2     Running   0          3d12h
   

   oc get cephblockpool ocs-storagecluster-cephblockpool -n openshift-storage -o jsonpath='{.status.mirroringStatus.summary}{"\n"}'
   

   Exemple de sortie.

   {"daemon_health":"OK","health":"OK","image_health":"OK","states":{}}
   

6. En option: Passez en revue les opérateurs que vous pouvez installer pour améliorer les fonctionnalités de reprise après sinistre régionale d'ODF.

7. Facultatif: Testez votre configuration de reprise après sinistre.

Opérateurs optionnels pour la reprise après sinistre régionale de l'ODF

Passez en revue les opérateurs optionnels que vous pouvez installer sur votre hub ACM ou sur les clusters gérés pour améliorer les fonctions de reprise après sinistre d'ODF Regional. Notez que IBM n'est pas responsable de la gestion de ces opérateurs.

Vous êtes responsable de la gestion de ces opérateurs, y compris, mais sans s'y limiter, de la mise à jour, de la surveillance, de la récupération et de la réinstallation.

Tester votre configuration de reprise après sinistre

Créez un exemple d'application pour tester votre solution de reprise après sinistre. Pour plus d'informations, voir Créer un exemple d'application pour tester l'application de reprise après sinistre.

1. Déployer une application par abonnement depuis la console ACM. L'onglet Topologie de l'application s'affiche en vert lorsque toutes les ressources de l'application sont déployées avec succès.

2. Sur la page de l'application, allez dans Actions > Gérer la politique de données.

3. Attribuez à cette application la stratégie de récupération des données créée précédemment.

4. Vérifiez que les pods d'application s'exécutent sur le cluster principal.

5. Sur la page de l'application, allez dans Actions > Application de basculement. Sélectionnez votre cluster ODF secondaire comme cluster cible. Cliquez sur Lancer.

6. Vérifiez que les pods d'application sont déplacés vers le cluster secondaire.

7. Sur la page de l'application, allez dans Actions > Déplacer l'application. Sélectionnez votre cluster ODF principal comme cluster cible. Cliquez sur Lancer.

8. Vérifiez que les pods d'application sont replacés dans le cluster principal.

Mise à niveau de votre environnement régional de reprise après sinistre ODF

Pour savoir quand et comment mettre à niveau les composants de votre environnement ODF-RDR, consultez la section « Mise à niveau de votre environnement ODF de reprise après sinistre régional ».

Traitement des incidents

Si vous rencontrez des problèmes avec la configuration de la reprise après sinistre régionale de votre ODF, consultez la section « Vérification de la configuration de la reprise après sinistre régionale de la base de données d' OpenShift » pour vérifier l'état de chaque composant de votre installation.

Applications et charges de travail prises en charge

Passez en revue les types d'applications et de charges de travail auxquels vous pouvez appliquer la fonctionnalité de reprise après sinistre régionale une fois la configuration terminée.

Sur abonnement

Une application est déployée à partir d'une source externe, telle que GitHub, un repo Helm, ou Object Storage.

Pour plus d'informations, voir Création d'un exemple d'application basée sur les abonnements dans la documentation Red Hat.

ApplicationSet-based

Une application est déployée à partir d'un dépôt GitHub à l'aide de l'opérateur GitOps, qui gère la livraison continue. Il existe deux sous-types :

• GitOps Modèle d'extraction ( ArgoCD pull): Un cluster géré tire l'application de GitHub à l'aide de l'opérateur GitOps.

• GitOps Modèle de poussée ( ArgoCD push): L'opérateur GitOps pousse l'application vers le cluster géré lors des déploiements et des mises à jour.

Pour plus d'informations, voir Créer des applications basées sur des jeux d'applications dans la documentation Red Hat.

Pour plus d'informations sur les sous-types GitOps, voir Déployer Argo CD avec le modèle Push et Pull dans la documentation Red Hat.

Applications découvertes

Une application a été pré-déployée dans un cluster géré sans utiliser ACM. Dans ce cas, vous pouvez utiliser la découverte ACM pour l'application préinstallée et continuer à configurer la politique DR.

Pour plus d'informations, voir la protection contre la reprise après sinistre pour les applications découvertes dans la documentation Red Hat.

Applications incluant des déploiements sur VM

Une application basée sur VM est déployée sur le cluster géré à partir de la console ACM. Ces applications d' VM s peuvent être proposées sous forme d'abonnement, d' ApplicationSet-based, s ou de découvertes, comme décrit précédemment. Des options permettant de démarrer, d'arrêter, de mettre en pause et de supprimer les opérations d' VM s sont disponibles depuis la console ACM pour ces types d'applications.

Pour plus d'informations, voir Red Hat Advanced Cluster Management for Virtualization dans la documentation Red Hat.