Vérification du module complémentaire ACM sur le cluster de hubs

Groupe de moyeux

Suivez les étapes suivantes sur le cluster de hubs.

1. Vérifiez que le module complémentaire ACM est installé et qu'il est en état « normal ». Recherchez le module « acm » dans les résultats et vérifiez que son statut indique « Addon Ready ».

   ibmcloud oc cluster addon ls --cluster HUB_CLUSTER_NAME | grep -i acm
   

   Exemple de sortie :

   acm   2.15.0   normal   Addon Ready. For more info: http://ibm.biz/addon-state (H1500)
   

   Si le module complémentaire ACM n'apparaît pas dans la liste, installez-le.

2. Vérifiez que les pods complémentaires ACM s'exécutent dans l'espace de noms kube-system. Recherchez les pods « acm-agent » et « ibm-acm-operator-controller-manager », puis vérifiez que les deux affichent le statut « Running ».

   oc get pods -n kube-system | grep acm
   

   Exemple de sortie :

   acm-agent-6d9d49cbf6-tsmxd                           1/1   Running   118 (107m ago)   19d
   ibm-acm-operator-controller-manager-bc7b7f969-pr9lj   1/1   Running   3 (7d17h ago)    19d
   

3. Vérifiez que les pods de l'opérateur ACM et ceux d' MultiClusterHub fonctionnent dans l'espace de noms « open-cluster-management ».

   oc get pods -n open-cluster-management
   

   Exemple de sortie :

   multiclusterhub-operator-dcd787649-sqrcx     1/1   Running   0   14d
   console-chart-console-v2-7c8c6649cc-hmg6g    1/1   Running   0   15d
   submariner-addon-76986fdf45-v9kgm            1/1   Running   0   15d
   volsync-addon-controller-6575568dc6-6pjsb    1/1   Running   0   15d
   

   Si certains modules sont manquants ou ne sont pas à l'état « Running », consultez la section « Installation du module complémentaire ACM ».

Vérification de l'importation et de la disponibilité des clusters gérés

Groupe de moyeux

Effectuez l'étape suivante sur le cluster de concentrateurs.

Vérifiez que tous les clusters gérés ont bien été importés et que la valeur « True » apparaît dans les colonnes « JOINED » et « AVAILABLE ».

oc get managedclusters

Exemple de sortie :

NAME             HUB ACCEPTED   MANAGED CLUSTER URLS                                 JOINED   AVAILABLE   AGE
local-cluster    true           https://c100.au-syd.containers.cloud.ibm.com:30253   True     True        14d
managedcluster1  true           https://c100.au-syd.containers.cloud.ibm.com:31003   True     True        14d
managedcluster2  true           https://c100.au-syd.containers.cloud.ibm.com:31888   True     True        14d

Si un cluster géré est manquant ou indisponible, réimportez-le.

Vérification de la connectivité du Submariner

{: tag-blue} [de cluster de hubs] Cluster géré

Submariner assure la connectivité réseau entre vos clusters gérés. Suivez les étapes décrites dans chaque sous-section relative au cluster indiqué.

Vérification de l'ODF sur les clusters gérés

Cluster géré

Effectuez les étapes suivantes sur chaque cluster géré.

1. Vérifiez que l' StorageCluster ODF est prête et que l'état de santé de Ceph est HEALTH_OK. Dans le résultat, vérifiez que la colonne « PHASE » affiche « Ready » pour « StorageCluster » et que la colonne « HEALTH » affiche « HEALTH_OK » pour « CephCluster ».

   oc get storagecluster -n openshift-storage
   oc get cephcluster -n openshift-storage
   

   Exemple de sortie :

   NAME                 AGE   PHASE   EXTERNAL   CREATED AT             VERSION
   ocs-storagecluster   12d   Ready              2026-03-17T10:51:46Z   4.20.7
   NAME                              DATADIRHOSTPATH   MONCOUNT   AGE   PHASE   MESSAGE                       HEALTH      EXTERNAL   FSID
   ocs-storagecluster-cephcluster    /var/lib/rook     3          12d   Ready   Cluster created successfully  HEALTH_OK              5fb59e70-bd54-438f-9190-c09ddcf04c0c
   

   S'il s'agit d'une nouvelle installation d'ODF et qu'aucune application n'a encore été déployée, envisagez de réinstaller ODF en suivant le guide d'installation d'ODF.

2. Vérifiez que les « ServiceExports » requis sont bien présents. Vérifiez que les entrées ocs-provider-server, rook-ceph-mon-* et rook-ceph-osd-* figurent bien dans la liste.

   oc get serviceexports -n openshift-storage
   

   Exemple de sortie :

   NAME                  AGE
   ocs-provider-server   12d
   rook-ceph-mon-d       12d
   rook-ceph-mon-e       12d
   rook-ceph-mon-f       12d
   rook-ceph-osd-0       12d
   rook-ceph-osd-1       12d
   rook-ceph-osd-2       12d
   

   Si le fichier « ocs-provider-server » ( ServiceExport ) est manquant, recréez-le en suivant l'étape 5 de la procédure de configuration de la reprise après sinistre régionale ODF.

3. Vérifiez que la configuration réseau multicluster est correctement définie sur StorageCluster. Dans la sortie, vérifiez que multiClusterService.enabled correspond bien à true et que clusterID correspond au nom du cluster géré. Vérifiez également que l'annotation « ocs.openshift.io/api-server-exported-address » est bien présente et correctement configurée.

   oc get storagecluster -n openshift-storage -o yaml
   

   Recherchez les valeurs suivantes dans la sortie :

   network:
     multiClusterService:
       clusterID: <cluster-name>
       enabled: true
   

   Et l'annotation suivante :

   ocs.openshift.io/api-server-exported-address: <cluster-name>.ocs-provider-server.openshift-storage.svc.clusterset.local:50051
   

Vérification de l'orchestrateur ODF Multicluster sur le cluster central

Groupe de moyeux

Suivez les étapes suivantes sur le cluster de hubs.

1. Vérifiez que les pods de l'opérateur OpenShift GitOps sont en cours d'exécution. L'ODF Multicluster Orchestrator nécessite l'installation préalable d' GitOps.

   oc get pods -n openshift-gitops
   

   Exemple de sortie :

   NAME                                                           READY   STATUS    RESTARTS   AGE
   cluster-6484df7d8f-fbk9b                                       1/1     Running   0          4d12h
   gitops-plugin-8646dcfd5d-kj5mf                                 1/1     Running   0          4d12h
   openshift-gitops-application-controller-0                      1/1     Running   0          4d12h
   openshift-gitops-applicationset-controller-664645457b-8n9gj    1/1     Running   0          4d12h
   openshift-gitops-dex-server-74ddb4bb94-trxk6                   1/1     Running   0          4d12h
   openshift-gitops-redis-68469975f8-mlkrq                        1/1     Running   0          14d
   openshift-gitops-repo-server-76567d7c46-j9fjq                  1/1     Running   0          4d12h
   openshift-gitops-server-6d74f8d998-f97zx                       1/1     Running   0          4d12h
   

   Si « GitOps » n'est pas installé, consultez la section « Installation d' Red Hat OpenShift » à l'adresse GitOps Operator dans la console Web.

2. Vérifiez que les pods de l'opérateur ODF Multicluster Orchestrator s'exécutent dans l'espace de noms « openshift-operators ». Vérifiez que les pods « odf-multicluster-console » et « odfmo-controller-manager » affichent tous deux le statut « Running ».

   oc get pods -n openshift-operators | grep -i odf
   

   Exemple de sortie :

   odf-multicluster-console-cdd786658-2bdbz   1/1   Running   0             12d
   odfmo-controller-manager-8585c4bf9-mwhvf   1/1   Running   2 (16h ago)   12d
   

3. Vérifiez que le pod de l'opérateur Ramen Hub s'exécute dans l'espace de noms « submariner-operator ».

   oc get pods -n submariner-operator
   

   Exemple de sortie :

   NAME                                  READY   STATUS    RESTARTS      AGE
   submariner-operator-6bf8d56f74-7v44v  1/1     Running   3 (17h ago)   14d
   

4. Vérifiez que le pod de l'opérateur du cluster Ramen DR est en cours d'exécution sur chaque cluster géré dans l'espace de noms « openshift-dr-system ».

   oc get pods -n openshift-dr-system | grep -i ramen
   

   Exemple de sortie :

   ramen-dr-cluster-operator-785d878dbc-lbrgz   2/2   Running   0   2d15h
   

Vérification de la politique de reprise après sinistre et de l' MirrorPeer s sur le cluster de hubs

Groupe de moyeux

Suivez les étapes suivantes sur le cluster de hubs.

1. Vérifiez que la DRPolicy est valide. Dans le résultat, vérifiez que la condition « Validated » a pour valeur « status » : "True".

   oc get drpolicy -A
   oc describe drpolicy <drpolicy_name>
   

   Exemple de résultat obtenu à partir de oc describe:

   status:
     conditions:
       - type: Validated
         status: "True"
   

   Si la DRPolicy n'est pas validée, vérifiez que les compartiments de l'objet « NooBaa » ont bien été créés sur les deux clusters gérés.

2. Vérifiez que la phase « MirrorPeer » est « ExchangedSecret ». Décrivez la ressource « MirrorPeer » et cochez la case « Phase ».

   oc get mirrorpeers -A
   oc describe mirrorpeer <mirrorpeer_name>
   

   Exemple de résultat obtenu à partir de oc describe:

   Status:
     Phase: ExchangedSecret
   Events: <none>
   

   Si la phase indique « ExchangingSecret », vérifiez la connectivité du Submariner en suivant les instructions de la section « Vérification de la connectivité du Submariner ».

Vérification des opérateurs optionnels sur les clusters gérés

Cluster géré

Si vous avez installé des opérateurs optionnels lors de la configuration de votre ODF RDR, vérifiez qu'ils fonctionnent bien sur chaque cluster géré.

Vous êtes chargé de la gestion des composants optionnels, notamment leur mise à jour, leur surveillance, leur restauration et leur réinstallation.

1. Vérifiez que les pods de l'opérateur OpenShift GitOps sont en cours d'exécution. Vérifiez que les pods « openshift-gitops-application-controller », « openshift-gitops-server » et les autres pods de type « GitOps » affichent le statut « Running ».

   oc get pods -n openshift-gitops
   

2. Vérifiez que les pods de l'opérateur de l'API « OpenShift » pour la protection des données ( OADP ) sont en cours d'exécution. Vérifiez que les pods « openshift-adp-controller-manager » et « velero » affichent tous deux le statut « Running ».

   oc get pods -n openshift-adp
   

   Exemple de sortie :

   NAME                                                  READY   STATUS    RESTARTS   AGE
   openshift-adp-controller-manager-7c8fc7f964-j2jnq    1/1     Running   1          12d
   velero-9cdf64b8b-9c2kk                               1/1     Running   1          12d
   

   Si un opérateur est manquant, réinstallez-le en suivant le guide d'installation correspondant.

Collecte des journaux indispensables

{: tag-blue} [de cluster de hubs] Cluster géré

Si vous ne parvenez pas à résoudre un problème en suivant les étapes de vérification précédentes, veuillez récupérer les fichiers journaux indispensables sur votre hub et vos clusters gérés, puis les transmettre au support technique d' IBM.

#!/bin/bash
# Usage: ./hub-check.sh <cluster-name>
CLUSTER_NAME=$1
if [[ -z "$CLUSTER_NAME" ]]; then
  echo "Usage: $0 <cluster-name>"
  exit 1
fi
echo "===== Verify ACM ====="
ibmcloud oc cluster addon ls --cluster "$CLUSTER_NAME" | grep -i acm
oc get pods -n kube-system | grep acm
oc get pods -n open-cluster-management
oc get managedclusters
echo "===== Verify Submariner ====="
oc get pods -n submariner-operator
oc get managedclusteraddon -A | grep submariner
oc get managedclusteraddon -A -o yaml
oc get broker -A
echo "===== Verify Multicluster Operator ====="
oc get pods -n openshift-operators | grep -i odf
oc get drpolicy -A
oc get mirrorpeers -A
echo "===== Verify Additional Operators ====="
oc get pods -n openshift-gitops
oc get pods -n openshift-adp

#!/bin/bash
# Usage: ./managedCluster-check.sh
echo "===== Verify Submariner ====="
oc get pods -n submariner-operator
oc get submariner -A
echo "===== Verify DR Operator ====="
oc get pods -n openshift-dr-system | grep -i ramen
echo "===== Verify ODF ====="
oc get storagecluster -n openshift-storage
oc get cephcluster -n openshift-storage
oc get serviceexports -n openshift-storage
oc get storagecluster -n openshift-storage -o yaml
echo "===== Verify Additional Operators ====="
oc get pods -n openshift-gitops
oc get pods -n openshift-adp

Etapes suivantes

• Si tous les composants fonctionnent correctement, testez votre configuration de reprise après sinistre en simulant un scénario de basculement et de relocalisation.
• Si vous avez besoin d'une aide supplémentaire, contactez le support technique d' IBM et joignez-y les fichiers journaux indispensables que vous avez recueillis.
• Consultez le guide de configuration de la reprise après sinistre régionale ODF afin de vérifier que toutes les étapes d'installation ont été correctement effectuées.

Liens connexes

• Dépannage de la reprise après sinistre régionale
• Red Hat Guide de dépannage ODF
• Red Hat Rencontre incontournable de l'ACM
• Installation du module complémentaire ACM