Verificação do complemento ACM no cluster de hubs

Conjunto de hubs

Siga as etapas a seguir no site cluster de hubs.

1. Verifique se o complemento ACM está instalado e se encontra no estado “ normal ”. Procure o complemento “ acm ” na saída e confirme se o status exibe “ Addon Ready ”.

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

   Saída de exemplo:

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

   Se o complemento ACM não estiver listado, instale-o.

2. Verifique se os pods do complemento ACM estão em execução no namespace kube-system. Procure os pods “ acm-agent ” e “ ibm-acm-operator-controller-manager ” e verifique se ambos apresentam o status “ Running ”.

   oc get pods -n kube-system | grep acm
   

   Saída de exemplo:

   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. Verifique se os pods do operador ACM e os pods do MultiClusterHub estão em execução no namespace open-cluster-management.

   oc get pods -n open-cluster-management
   

   Saída de exemplo:

   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
   

   Se algum pod estiver faltando ou não estiver no status “ Running ”, consulte a seção “Instalando o complemento ACM ”.

Verificar se os clusters gerenciados foram importados e estão disponíveis

Conjunto de hubs

Siga a etapa a seguir no site cluster de hubs.

Verifique se todos os clusters gerenciados foram importados com sucesso e se exibem “ True ” nas colunas “ JOINED ” e “ AVAILABLE ”.

oc get managedclusters

Saída de exemplo:

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

Se um cluster gerenciado estiver faltando ou indisponível, reimporte o cluster.

Verificação da conectividade do Submariner

Cluster de hubs Cluster gerenciado

O Submariner fornece conectividade de rede entre seus clusters gerenciados. Siga as etapas descritas em cada subseção do cluster indicado.

Verificação do ODF nos clusters gerenciados

Cluster gerenciado

Execute as etapas a seguir em cada cluster gerenciado.

1. Verifique se o ODF StorageCluster está pronto e se o estado do Ceph é HEALTH_OK. Na saída, verifique se a coluna “ PHASE ” exibe “ Ready ” para “ StorageCluster ” e se a coluna “ HEALTH ” exibe “ HEALTH_OK ” para “ CephCluster ”.

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

   Saída de exemplo:

   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
   

   Se esta for uma instalação nova do ODF e nenhum aplicativo tiver sido implantado, considere reinstalar o ODF seguindo o guia de instalação do ODF.

2. Verifique se os arquivos de configuração necessários ( ServiceExports ) estão presentes. Verifique se ocs-provider-server e as entradas rook-ceph-mon-* e rook-ceph-osd-* estão listadas.

   oc get serviceexports -n openshift-storage
   

   Saída de exemplo:

   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
   

   Se o arquivo ocs-provider-server ServiceExport estiver faltando, recrie-o seguindo a Etapa 5 da configuração de Recuperação de Desastres Regional do ODF.

3. Verifique se a configuração de rede multicluster está definida corretamente no StorageCluster. Na saída, verifique se multiClusterService.enabled corresponde a true e se clusterID corresponde ao nome do cluster gerenciado. Confirme também se a anotação ocs.openshift.io/api-server-exported-address está presente e configurada corretamente.

   oc get storagecluster -n openshift-storage -o yaml
   

   Procure os seguintes valores na saída:

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

   E a seguinte anotação:

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

Verificação do ODF Multicluster Orchestrator no cluster central

Conjunto de hubs

Siga as etapas a seguir no site cluster de hubs.

1. Verifique se os pods do operador OpenShift GitOps estão em execução. O ODF Multicluster Orchestrator requer que o GitOps e seja instalado primeiro.

   oc get pods -n openshift-gitops
   

   Saída de exemplo:

   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
   

   Se o GitOps não estiver instalado, consulte “Instalando o Red Hat OpenShift GitOps Operator no console da web ”.

2. Verifique se os pods do operador do ODF Multicluster Orchestrator estão em execução no namespace openshift-operators. Verifique se os pods odf-multicluster-console e odfmo-controller-manager apresentam, ambos, o status “ Running ”.

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

   Saída de exemplo:

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

3. Verifique se o pod do operador do hub do Ramen está em execução no namespace submariner-operator.

   oc get pods -n submariner-operator
   

   Saída de exemplo:

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

4. Verifique se o pod do operador do cluster Ramen DR está em execução em cada cluster gerenciado no namespace openshift-dr-system.

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

   Saída de exemplo:

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

Verificação da política de DR e do MirrorPeer no cluster do hub

Conjunto de hubs

Siga as etapas a seguir no site cluster de hubs.

1. Verifique se a DRPolicy foi validada. Na saída, verifique se a condição “ Validated ” possui um “ status ” com o valor “ "True" ”.

   oc get drpolicy -A
   oc describe drpolicy <drpolicy_name>
   

   Exemplo de saída do site oc describe:

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

   Se a DRPolicy não for validada, verifique se os buckets do objeto NooBaa foram criados com sucesso em ambos os clusters gerenciados.

2. Verifique se a fase “ MirrorPeer ” está em “ ExchangedSecret ”. Descreva o recurso MirrorPeer e marque o campo Phase.

   oc get mirrorpeers -A
   oc describe mirrorpeer <mirrorpeer_name>
   

   Exemplo de saída do site oc describe:

   Status:
     Phase: ExchangedSecret
   Events: <none>
   

   Se a fase indicar “ ExchangingSecret ”, verifique a conectividade do Submariner seguindo as instruções da seção “Verificação da conectividade do Submariner ”.

Verificação de operadores opcionais nos clusters gerenciados

Cluster gerenciado

Se você instalou operadores opcionais como parte da configuração do ODF RDR, verifique se eles estão em execução em cada cluster gerenciado.

Você é responsável pelo gerenciamento dos operadores opcionais, incluindo atualização, monitoramento, recuperação e reinstalação.

1. Verifique se os pods do operador OpenShift GitOps estão em execução. Verifique se os pods openshift-gitops-application-controller, openshift-gitops-server e outros GitOps apresentam o status Running.

   oc get pods -n openshift-gitops
   

2. Verifique se os pods do operador da API do OpenShift para Proteção de Dados ( OADP ) estão em execução. Verifique se os pods openshift-adp-controller-manager e velero apresentam, ambos, o status “ Running ”.

   oc get pods -n openshift-adp
   

   Saída de exemplo:

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

   Caso falte um operador, reinstale-o seguindo o guia de instalação correspondente.

Coleta de registros indispensáveis

Cluster de hubs Cluster gerenciado

Caso não consiga resolver um problema seguindo as etapas de verificação anteriores, colete os logs essenciais do seu hub e dos clusters gerenciados e os envie ao Suporte 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

Próximas etapas

• Se todos os componentes estiverem funcionando corretamente, teste sua configuração de recuperação de desastres executando um cenário de failover e realocação.
• Caso precise de mais ajuda, entre em contato com o Suporte do IBM e inclua os logs essenciais que você coletou.
• Consulte o guia de configuração da Recuperação de Desastres Regional do ODF para confirmar se todas as etapas de instalação foram concluídas corretamente.

Links relacionados

• Solução de problemas na recuperação de desastres regionais
• Red Hat Guia de solução de problemas do ODF
• Red Hat Evento imperdível da ACM
• Instalando o complemento ACM