Überprüfung des ACM-Add-ons auf dem Hub-Cluster

Hub-Cluster

Führen Sie die folgenden Schritte auf dem Hub-Cluster aus.

1. Stellen Sie sicher, dass das ACM-Add-on installiert ist und sich im Status „ normal “ befindet. Suchen Sie in der Ausgabe nach dem Zusatz „ acm “ und vergewissern Sie sich, dass der Status „ Addon Ready “ lautet.

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

   Beispielausgabe:

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

   Falls das ACM-Add-on nicht aufgeführt ist, installieren Sie das ACM-Add-on.

2. Stellen Sie sicher, dass die ACM-Add-on-Pods im Namespace „ kube-system “ ausgeführt werden. Suchen Sie nach den Pods „ acm-agent “ und „ ibm-acm-operator-controller-manager “ und vergewissern Sie sich, dass bei beiden der Status „ Running “ angezeigt wird.

   oc get pods -n kube-system | grep acm
   

   Beispielausgabe:

   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. Stellen Sie sicher, dass die ACM-Operator-Pods und die „ MultiClusterHub “-Pods im Namespace „ open-cluster-management “ ausgeführt werden.

   oc get pods -n open-cluster-management
   

   Beispielausgabe:

   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
   

   Falls Pods fehlen oder sich nicht im Status „ Running “ befinden, lesen Sie den Abschnitt „ Installieren des ACM-Add-ons “.

Überprüfen, ob verwaltete Cluster importiert wurden und verfügbar sind

Hub-Cluster

Führen Sie den folgenden Schritt auf dem Hub-Cluster aus.

Stellen Sie sicher, dass alle verwalteten Cluster erfolgreich importiert wurden und in den Spalten „ JOINED “ sowie „ AVAILABLE “ der Wert „ True “ angezeigt wird.

oc get managedclusters

Beispielausgabe:

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

Falls ein verwalteter Cluster fehlt oder nicht verfügbar ist, importieren Sie den Cluster erneut.

Überprüfung der Submariner-Konnektivität

Hub-Cluster Verwalteter Cluster

Submariner sorgt für die Netzwerkverbindung zwischen Ihren verwalteten Clustern. Führen Sie die Schritte in jedem Unterabschnitt des angegebenen Clusters durch.

Überprüfung von ODF auf den verwalteten Clustern

Verwalteter Cluster

Führen Sie die folgenden Schritte auf jedem verwalteten Cluster aus.

1. Stellen Sie sicher, dass der ODF- StorageCluster-Dienst bereit ist und der Ceph-Zustand „ HEALTH_OK “ lautet. Vergewissern Sie sich in der Ausgabe, dass in der Spalte „ PHASE “ für „ StorageCluster “ der Wert „ Ready “ und in der Spalte „ HEALTH “ für „ CephCluster “ der Wert „ HEALTH_OK “ angezeigt wird.

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

   Beispielausgabe:

   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
   

   Wenn es sich um eine neue ODF-Installation handelt und noch keine Anwendungen bereitgestellt wurden, sollten Sie eine Neuinstallation von ODF in Betracht ziehen, indem Sie die Anweisungen im ODF-Installationshandbuch befolgen.

2. Stellen Sie sicher, dass die erforderlichen „ ServiceExports “ vorhanden sind. Vergewissern Sie sich, dass „ ocs-provider-server “ sowie die Einträge „ rook-ceph-mon-* “ und „ rook-ceph-osd-* “ aufgeführt sind.

   oc get serviceexports -n openshift-storage
   

   Beispielausgabe:

   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
   

   Falls die Datei „ ocs-provider-server “ ( ServiceExport ) fehlt, erstellen Sie sie neu, indem Sie Schritt 5 der Anleitung zur Einrichtung der regionalen Notfallwiederherstellung für ODF befolgen.

3. Stellen Sie sicher, dass die Multicluster-Netzwerkkonfiguration auf dem „ StorageCluster “ korrekt eingerichtet ist. Vergewissern Sie sich in der Ausgabe, dass „ multiClusterService.enabled “ mit „ true “ übereinstimmt und dass „ clusterID “ mit dem Namen des verwalteten Clusters übereinstimmt. Stellen Sie außerdem sicher, dass die Annotation „ ocs.openshift.io/api-server-exported-address “ vorhanden und korrekt eingestellt ist.

   oc get storagecluster -n openshift-storage -o yaml
   

   Achten Sie in der Ausgabe auf die folgenden Werte:

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

   Und die folgende Anmerkung:

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

Überprüfung des ODF Multicluster Orchestrator auf dem Hub-Cluster

Hub-Cluster

Führen Sie die folgenden Schritte auf dem Hub-Cluster aus.

1. Stellen Sie sicher, dass die Operator-Pods „ OpenShift “ und „ GitOps “ ausgeführt werden. Für den ODF Multicluster Orchestrator muss zuvor „ GitOps “ installiert werden.

   oc get pods -n openshift-gitops
   

   Beispielausgabe:

   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
   

   Falls „ GitOps “ nicht installiert ist, lesen Sie den Abschnitt „ Installation von Red Hat OpenShift GitOps Operator in der Webkonsole “.

2. Stellen Sie sicher, dass die Operator-Pods des ODF Multicluster Orchestrator im Namespace „ openshift-operators “ ausgeführt werden. Vergewissern Sie sich, dass die Pods „ odf-multicluster-console “ und „ odfmo-controller-manager “ beide den Status „ Running “ aufweisen.

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

   Beispielausgabe:

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

3. Stellen Sie sicher, dass der Ramen-Hub-Operator-Pod im Namespace „ submariner-operator “ ausgeführt wird.

   oc get pods -n submariner-operator
   

   Beispielausgabe:

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

4. Stellen Sie sicher, dass der Ramen-DR-Cluster-Operator-Pod auf jedem verwalteten Cluster im Namespace „ openshift-dr-system “ ausgeführt wird.

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

   Beispielausgabe:

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

Überprüfung der DR-Richtlinie und der „ MirrorPeer “ im Hub-Cluster

Hub-Cluster

Führen Sie die folgenden Schritte auf dem Hub-Cluster aus.

1. Stellen Sie sicher, dass die DRPolicy validiert ist. Vergewissern Sie sich in der Ausgabe, dass die Bedingung „ Validated “ den Wert „ status “ mit dem Wert „ "True" “ aufweist.

   oc get drpolicy -A
   oc describe drpolicy <drpolicy_name>
   

   Beispielausgabe von oc describe:

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

   Falls die DRPolicy nicht validiert wurde, überprüfen Sie, ob die Objekt-Buckets „ NooBaa “ auf beiden verwalteten Clustern erfolgreich erstellt wurden.

2. Stellen Sie sicher, dass die Phase „ MirrorPeer “ auf „ ExchangedSecret “ eingestellt ist. Beschreiben Sie die Ressource „ MirrorPeer “ und aktivieren Sie das Kontrollkästchen „ Phase “.

   oc get mirrorpeers -A
   oc describe mirrorpeer <mirrorpeer_name>
   

   Beispielausgabe von oc describe:

   Status:
     Phase: ExchangedSecret
   Events: <none>
   

   Wenn in diesem Schritt „ ExchangingSecret “ angezeigt wird, überprüfen Sie die Verbindung zum Submariner, indem Sie die Anweisungen unter „Überprüfen der Verbindung zum Submariner“ befolgen.

Überprüfung optionaler Operatoren auf den verwalteten Clustern

Verwalteter Cluster

Wenn Sie im Rahmen Ihrer ODF-RDR-Einrichtung optionale Operatoren installiert haben, stellen Sie sicher, dass diese auf jedem verwalteten Cluster ausgeführt werden.

Sie sind für die Verwaltung optionaler Komponenten verantwortlich, einschließlich der Aktualisierung, Überwachung, Wiederherstellung und Neuinstallation.

1. Stellen Sie sicher, dass die Operator-Pods „ OpenShift “ und „ GitOps “ ausgeführt werden. Vergewissern Sie sich, dass die Pods „ openshift-gitops-application-controller “, „ openshift-gitops-server “ und andere „ GitOps “-Pods den Status „ Running “ aufweisen.

   oc get pods -n openshift-gitops
   

2. Stellen Sie sicher, dass die Operator-Pods der „ OpenShift “-API für den Datenschutz ( OADP ) ausgeführt werden. Vergewissern Sie sich, dass die Pods „ openshift-adp-controller-manager “ und „ velero “ beide den Status „ Running “ aufweisen.

   oc get pods -n openshift-adp
   

   Beispielausgabe:

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

   Falls ein Treiber fehlt, installieren Sie ihn erneut, indem Sie die entsprechende Installationsanleitung befolgen.

Erfassung der unbedingt benötigten Protokolle

Hub-Cluster Verwalteter Cluster

Falls Sie ein Problem nicht durch die Durchführung der vorangegangenen Überprüfungsschritte beheben können, sammeln Sie bitte die erforderlichen Protokolle von Ihrem Hub und Ihren verwalteten Clustern und leiten Sie diese an den IBM-Support weiter.

#!/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

Nächste Schritte

• Wenn alle Komponenten einwandfrei funktionieren, testen Sie Ihre Notfallwiederherstellungskonfiguration, indem Sie ein Failover- und ein Standortwechsel-Szenario durchführen.
• Sollten Sie weitere Hilfe benötigen, wenden Sie sich bitte an den IBM-Support und fügen Sie die von Ihnen gesammelten, unbedingt erforderlichen Protokolle bei.
• Lesen Sie die Einrichtungsanleitung für die regionale Notfallwiederherstellung von ODF durch, um sicherzustellen, dass alle Installationsschritte korrekt durchgeführt wurden.

Zugehörige Links

• Fehlerbehebung bei der regionalen Notfallwiederherstellung
• Red Hat Leitfaden zur Fehlerbehebung bei ODF
• Red Hat ACM-Treffen, das man nicht verpassen darf
• Installation des ACM-Add-ons