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

Hub cluster

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 requises 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.31_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 dans une étape ultérieure.

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

Hub cluster

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. Vérifiez que le secret du profil de confiance a bien été créé dans le cluster. Cette commande peut prendre jusqu’à 10 minutes. Attendez que la clé secrète s'affiche avant de procéder à l'installation du module complémentaire ACM. Si vous poursuivez avant que le secret ne soit créé, l'installation du module complémentaire ACM échouera.

   oc get secrets -n kube-system | grep ibm-cloud-credentials
   

6. Si vous utilisez la version 4.21 ou une version ultérieure d'ODF, installez l'opérateur OpenShift GitOps sur le cluster hub.

   1. Dans la console Web OpenShift de la plateforme Core du cluster central, accédez à Écosystème > Catalogue de logiciels et recherchez Red Hat OpenShift GitOps.

   2. Cliquez sur la vignette Red Hat OpenShift ( GitOps ).

   3. Sur la page Install Operator, sélectionnez un canal de mise à jour et une version d' GitOps à installer.

   4. Choisissez un espace de noms installé. L'espace de noms d'installation par défaut est openshift-gitops-operator.

      Pour les versions d' GitOps1.10 et ultérieures, l'espace de noms par défaut est passé de à openshift-operators openshift-gitops-operator.

   5. Cochez la case Activer la surveillance du cluster recommandée par l'opérateur sur cet espace de noms pour activer la surveillance du cluster.

   6. Cliquez sur Install. Red Hat OpenShift GitOps est installé dans tous les espaces de noms du cluster.

   7. Vérifiez que l'opérateur Red Hat OpenShift GitOps figure bien dans la liste Opérateurs > Opérateurs installés et que le statut indique Réussi.

   Une fois l'installation terminée, OpenShift GitOps configure automatiquement une instance Argo CD prête à l'emploi dans l'espace de noms openshift-gitops, et une icône Argo CD s'affiche dans la barre d'outils de la console.

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

Managed cluster

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.31_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.31_openshift --workers 3 --cos-instance COS_CRN --disable-outbound-traffic-protection --cni OVNKubernetes
   

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

Hub cluster

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 complémentaires de l'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. Exécutez la commande pour activer le module complémentaire. Veillez à spécifier les paramètres isLicenseAccepted et billingPlan.

   ibmcloud oc cluster addon enable acm --cluster HUB_CLUSTER_ID --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 '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 true pour accepter le contrat de licence du forfait de facturation sélectionné. Le module complémentaire ne s'installera pas correctement tant que la licence n'aura pas été acceptée. 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 pour installer le module complémentaire ACM avec le plan de facturation ACM pour l' Kubernetes.

   ibmcloud oc cluster addon enable acm --cluster a5bcde982dfer2nwxq73 --param 'billingPlan=KUBERNETES' --param 'isLicenseAccepted=true'
   

4. 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 acmhub
       ```
       Exemple
       de sortie.
   
       ```sh {: screen}
       Status
           Message: ACM installed successfully
       ```
   

Étape 5. Importer les clusters gérés dans ACM

Hub cluster Managed cluster

Importez les deux clusters gérés dans ACM afin que le cluster central puisse les gérer.

1. Ouvrez la console Web OpenShift pour le cluster de hubs.

2. Dans Fleet Management, cliquez sur Importer un cluster.

3. Saisissez le nom du premier cluster géré, sélectionnez un ensemble de clusters le cas échéant, puis saisissez des étiquettes supplémentaires le cas échéant.

4. Pour le mode Importation, sélectionnez Exécuter les commandes d'importation manuellement, puis cliquez sur Suivant.

5. Vous pouvez, si vous le souhaitez, sélectionner un modèle d'automatisation, puis cliquer sur Suivant.

6. Vérifiez les détails, puis cliquez sur Générer la commande. Copiez la commande qui s'affiche.

7. Connectez-vous au premier cluster géré et exécutez la commande copiée en utilisant la configuration définie kubectl pour ce cluster.

8. Répétez les étapes 2 à 7 pour le deuxième cluster géré.

9. Dans la vue Fleet Management, vérifiez que les deux clusters gérés apparaissent dans la liste et affichent le statut Ready avant de continuer.

Étape 6. Configurer le module complémentaire Submariner

Managed cluster

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 du parc > Clusters > Ensembles de clusters.
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

Managed cluster

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.

Avant d'exécuter toute commande oc de cette section, assurez-vous que votre contexte est défini sur le cluster géré que vous êtes en train de configurer. Exécutez ibmcloud oc cluster config --cluster MANAGED_CLUSTER_NAME_OR_ID --admin pour changer de contexte, puis vérifiez avec oc config current-context.

1. Pour chaque cluster géré, installez le module complémentaire OpenShift Data Foundation depuis la console IBM Cloud.

   1. Accédez à la page Aperçu de votre cluster, puis faites défiler vers le bas jusqu'à la section Modules complémentaires.
   2. Sous OpenShift Data Foundation, cliquez sur Installer.
   3. Cochez la case Déployer la passerelle d’objets multi-cloud d’ NooBaa.
   4. Cliquez à nouveau sur Installer pour confirmer.
   5. Attendez que le statut du module complémentaire ODF passe de En cours d'activation à Normal (coche verte) avant de continuer.

2. Vérifiez que l'installation d'ODF s'est déroulée correctement. Dans la sortie, vérifiez que le statut indique Ready.

   Le statut Normal de l'interface utilisateur indique que le module complémentaire a été déployé, mais que l'opérateur ODF peut encore avoir besoin de quelques minutes pour terminer l'initialisation et l'enregistrement de ses ressources.

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

Les étapes suivantes doivent être effectuées sur chaque cluster géré. Passez au premier cluster géré à l'aide de ibmcloud oc cluster config --cluster MANAGED_CLUSTER_NAME_OR_ID --admin, effectuez toutes les étapes jusqu'à la fin de cette section, puis passez au deuxième cluster géré et répétez l'opération.

1. Exécutez la commande pour mettre à jour le dans ACM Managed Cluster Name la section multiClusterService de storageCluster la ressource. 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.

   Remplacez par MANAGED_CLUSTER_NAME le nom du cluster vers lequel votre contexte pointe actuellement.

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

   Exemple de sortie.

   storagecluster.ocs.openshift.io/ocs-storagecluster patched
   

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

3. Créer une exportation de service pour ocs-provider-server.

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

   Exemple de sortie.

   serviceexport.multicluster.x-k8s.io/ocs-provider-server created
   

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

   Exemple de sortie.

   storagecluster.ocs.openshift.io/ocs-storagecluster annotated
   

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

Hub cluster

Installez 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. Installez l'ODF Multicluster Orchestrator sur le cluster central.

   1. Installez l'opérateur OpenShift GitOps sur le cluster hub si ce n'est pas déjà fait. Pour connaître les étapes d'installation, reportez-vous à la fin de l'étape 2. Créer un profil de confiance pour le cluster hub.
   2. Dans la console Web OpenShift du cluster hub de la plateforme Core, accédez à Écosystème > Catalogue de logiciels et recherchez ODF Multicluster Orchestrator.
   3. Cliquez sur la vignette ODF Multicluster Orchestrator. Veillez à sélectionner le même numéro de version que celui de la version ODF que vous avez installée sur les clusters gérés dans la section précédente. Conservez tous les autres paramètres par défaut et cliquez sur Installer.
   4. Assurez-vous que les ressources d'opérateur sont installées dans le projet openshift-operators et disponibles pour tous les espaces de noms. Cliquez à nouveau sur Installer pour confirmer.

   L'ODF Multicluster Orchestrator installe également l'opérateur DR Hub d' OpenShift sur le cluster hub en tant que dépendance.

2. Vérifiez l'installation en vous assurant que les modules d'exploitation fonctionnent. Assurez-vous que votre contexte CLI est défini sur le cluster hub avant d'exécuter cette commande.

   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 central, créez une politique de reprise après sinistre avec un intervalle de synchronisation de 5 minutes et spécifiez chaque cluster géré dans les paramètres. Cela crée des compartiments d'objets d' NooBaa s sur les deux clusters gérés et active la mise en miroir du pool de blocs ODF Ceph pour la réplication des volumes.

   1. Dans la section Gestion de la flotte de la console Web OpenShift du cluster central, accédez à 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
      • Le cas échéant, sélectionnez Activer la prise en charge de la reprise après sinistre pour les instances restaurées et clonées d’ PersistentVolumeClaims (pour Data Foundation uniquement) dans les paramètres avancés.

      Red Hat Il est explicitement indiqué que cette option ne doit être utilisée qu’avec des applications et des environnements détectés dans lesquels les volumes RBD clonés/restaurés sont activement pris en charge.

4. Sur le cluster central, exécutez les commandes suivantes pour vérifier que la politique de reprise après sinistre a bien été créée et appliquée aux clusters gérés. Assurez-vous que votre contexte CLI est défini sur le cluster hub avant d'exécuter ces commandes.

   ibmcloud oc cluster config --cluster HUB_CLUSTER_NAME --admin
   

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

   Exemple de sortie.

   Succeeded
   

   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 de reprise après sinistre a bien été appliquée et qu'elle est en bon état de fonctionnement. Passez dans le contexte CLI de chaque cluster géré avant d'exécuter ces commandes.

   ibmcloud oc cluster config --cluster MANAGED_CLUSTER_NAME --admin
   

   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.