Défaillance du nœud de stockage Fusion Data Foundation

Vous pouvez remplacer un nœud de manière proactive pour un nœud opérationnel et de manière réactive pour un nœud défaillant. Pour un nœud défaillant pris en charge par des périphériques de stockage locaux, vous devez remplacer le nœud de stockage Fusion Data Foundation.

Avant de commencer
IBM recommande que les nœuds de remplacement soient configurés avec une infrastructure, des ressources et des disques similaires à ceux du nœud prévu pour le remplacement.
Remarque: Contactez le IBM avant de procéder à l'un de ces correctifs.
Procédure
Procédez comme suit pour vérifier la présence d'une défaillance du nœud de stockage Fusion Data Foundation et identifier le nœud défaillant :
  1. Mettre le cluster Fusion Data Foundation en mode maintenance :
    oc label odfclusters.odf.isf.ibm.com -n ibm-spectrum-fusion-ns odfcluster "odf.isf.ibm.com/maintenanceMode=true"
    Résultat de l'exemple :
    [root@fu40 ~]# oc label odfclusters.odf.isf.ibm.com -n ibm-spectrum-fusion-ns odfcluster "odf.isf.ibm.com/maintenanceMode=true"
odfcluster.odf.isf.ibm.com/odfcluster labeled
  2. Identifiez le noeud défaillant:
    1. Connectez-vous à l'interface utilisateur de IBM Fusion.
    2. Accédez à la page Data foundation et recherchez les avertissements dans la section Health du cluster de stockage.
    Vous pouvez également utiliser la commande oc pour identifier le noeud:
    oc get node -l cluster.ocs.openshift.io/openshift-storage=
    Exemple de sortie :
    [root@fu71-f09-vm3 ~]# oc get node -l cluster.ocs.openshift.io/openshift-storage=
NAME                               STATUS     ROLES    AGE   VERSION
f09-prc4m-worker-cluster-b-9chb5   NotReady   worker   27d   v1.24.0+4f0dd4d
f09-prc4m-worker-cluster-c-mfb77   Ready      worker   31d   v1.24.0+4f0dd4d
f09-prc4m-worker-cluster-d-r5bxx   Ready      worker   27d   v1.24.0+4f0dd4d
  3. Identifiez les pods Mon (le cas échéant) et Red Hat OpenShift Dedicated qui s'exécutent dans le noeud et qui sont planifiés pour le remplacement:
    Dans un environnement de noeud de stockage opérationnel:
    oc get pods -n openshift-storage -o wide | grep -i <node_name>
  4. Si le noeud de stockage est défaillant dans un noeud de stockage défaillant, il n'y a pas de node_name pour les pods défaillants. Filtrez les pods pending à la place.
    oc get pods -n openshift-storage -o wide | grep -i pending
    Exemple de sortie: le déploiement Mon est rook-ceph-mon-det le déploiement Red Hat OpenShift Dedicated est ook-ceph-osd-0.
    [root@fu71-f09-vm3 ~]# oc get pods -n openshift-storage -o wide | grep -i pending
 rook-ceph-mon-d-67686857d7-zv62c                                  0/2     Pending     0          8m50s   <none>            <none>                             <none>           <none>
 rook-ceph-osd-0-75b954c9bf-62xm4                                  0/2     Pending     0          8m50s   <none>            <none>                             <none>           <none>
  5. Supprimez les objets ayant échoué.
    Supprimez le noeud défaillant de la ressource personnalisée odfcluster
    spec:
  autoScaleUp: false
  creator: CreatedByFusion
  deviceSets:
  - capacity: "0"
    count: 3
    name: ocs-deviceset-ibm-spectrum-fusion-local
    storageClass: ibm-spectrum-fusion-local
  encryption:
    keyManagementService: {}
  localVolumeSetSpec:
    deviceTypes:
    - disk
    - part
    size: 2Ti
  storageNodes:
  - f09-prc4m-worker-cluster-d-r5bxx
  - f09-prc4m-worker-cluster-c-mfb77
  - f09-prc4m-worker-cluster-b-9chb5 <<-- this one, remove this line.
    Retirez les pods mon et Red Hat OpenShift Dedicated
    Réduisez les déploiements des pods identifiés. Le déploiement Mon est rook-ceph-mon-d et le déploiement Red Hat OpenShift Dedicated est rook-ceph-osd-0.
    oc scale deployment rook-ceph-mon-d --replicas=0 -n openshift-storage
oc scale deployment rook-ceph-osd-0 --replicas=0 -n openshift-storage

    Veillez à confirmer les valeurs de mon_id et de osd_id.

    Retirer les pods crashcollector
    Retirez les pods crashcollector (le cas échéant). Vous devez mettre la réplique d'échelle à 0.
    oc scale deployment --selector=app=rook-ceph-crashcollector,node_name=<node_name>  --replicas=0 -n openshift-storage
    Marquer le noeud ayant échoué comme non planifiable
    Marquez le noeud comme SchedulingDisabled.
    oc adm cordon <node_name>
    Exemple de commande et de sortie:
    oc adm cordon f09-prc4m-worker-cluster-b-9chb5
node/f09-prc4m-worker-cluster-b-9chb5 cordoned
    oc get node -l cluster.ocs.openshift.io/openshift-storage=
    NOM STATUT DE LA VERSION D'ÂGE
f09-prc4m-worker-cluster-b-9chb5 NotReady,SchedulingDisabled worker 28d v1.24.0+4f0dd4d
f09-prc4m-worker-cluster-c-mfb77 Travailleur prêt 31d v1.24.0+4f0dd4d
f09-prc4m-worker-cluster-d-r5bxx Travailleur prêt 27d v1.24.0+4f0dd4d
    Retirer les pods qui sont à l'état Terminating
    Cette étape concerne le noeud d'archivage défaillant. Vous pouvez ignorer cette étape si vous supprimez un noeud opérationnel.
    oc get pods -A -o wide | grep -i <node_name> |  awk '{if ($4 == "Terminating") system ("oc -n " $1 " delete pods " $2  " --grace-period=0 " " --force ")}'
    Exemple de commande et de sortie:
    oc get pods -A -o wide | grep -i f09-prc4m-worker-cluster-b-9chb5 |  awk '{if ($4 == "Terminating") system ("oc -n " $1 " delete pods " $2  " --grace-period=0 " " --force ")}'
    avertissement: La suppression immédiate n'attend pas la confirmation que la ressource en cours d'exécution a été arrêtée. La ressource peut continuer à s'exécuter sur le cluster indéfiniment.
pod " isf-data-protection-operator-controller-manager-5c7cf574d5ms4xx " force deleted
    Opération DRAIN sur le noeud
    oc adm drain <node_name> --force --delete-emptydir-data=true --ignore-daemonsets
    Exemple de commande et de sortie:
    oc adm drain f09-prc4m-worker-cluster-b-9chb5 --force --delete-emptydir-data=true --ignore-daemonsets
node/f09-prc4m-worker-cluster-b-9chb5 already cordoned
    WARNING : ignorer DaemonSet-managed Pods : openshift-cluster-csi-drivers/vmware-vsphere-csi-driver-node-7696f, openshift-cluster-node-tuning-operator/tuned-fk949, openshift-dns/dns-default-gvv4m, openshift-dns/node-resolver-t5dk8, openshift-image-registry/node-ca-wtnp9, openshift-ingress-canary/ingress-canary-kgxts, openshift-local-storage/diskmaker-discovery-qkmh7, openshift-local-storage/diskmaker-manager-m9q42, openshift-machine-config-operator/machine-config-daemon-252j8, openshift-monitoring/node-exporter-cghwc, openshift-multus/multus-additional-cni-plugins-mkz4m, openshift-multus/multus-bz789, openshift-multus/network-metrics-daemon-57v5r, openshift-network-diagnostics/network-check-target-n6bhw, openshift-sdn/sdn-fhp47, openshift-storage/csi-cephfsplugin-5vsp9, openshift-storage/csi-rbdplugin-bfpfs
node/f09-prc4m-worker-cluster-b-9chb5 vidée
    Supprimer le noeud
    Supprimez le noeud défaillant:
    oc delete node <node_name>
    Si vous ne souhaitez pas détruire ce noeud à des fins de test, vous pouvez supprimer le libellé de stockage cluster.ocs.openshift.io/openshift-storage=.
    oc label nodes/f09-prc4m-worker-cluster-b-9chb5 cluster.ocs.openshift.io/openshift-storage-
  6. Ajouter de nouveaux nœuds OpenShift® de calcul.
    1. Créez un nouveau noeud de traitement et vérifiez que le nouveau noeud est à l'état Prêt.
    2. Mettez à jour les nouvelles informations de noeud dans la ressource personnalisée odfcluster .
      Editez le cr odfcluster et ajoutez un nouveau nom de noeud dans StorageNodes
      oc edit odfclusters.odf.isf.ibm.com -n ibm-spectrum-fusion-ns odfcluster

      storageNodes:
    - f09-prc4m-worker-cluster-b-djplp  <<--- new node
    - f09-prc4m-worker-cluster-d-r5bxx
    - f09-prc4m-worker-cluster-c-mfb77
      Vérifiez si les nouveaux noeuds sont correctement libellés en tant que noeud de stockage.
      oc get node -l cluster.ocs.openshift.io/openshift-storage
      NAME                               STATUS   ROLES    AGE   VERSION
f09-prc4m-worker-cluster-b-djplp   Ready    worker   27d   v1.24.0+4f0dd4d <<-- this node
f09-prc4m-worker-cluster-c-mfb77   Ready    worker   31d   v1.24.0+4f0dd4d
f09-prc4m-worker-cluster-d-r5bxx   Ready    worker   27d   v1.24.0+4f0dd4d
      Vérifiez si les nouveaux volumes persistants sont créés automatiquement. Le volume persistant local est créé automatiquement en peu de temps.
      oc get pv | grep Available
      local-pv-e97b23d7 2Ti RWO Delete Available ibm-spectrum-fusion-local 2m49s
    3. Remplacez les disques Red Hat OpenShift Dedicated qui ont échoué.

      Retirez du cluster Red Hat OpenShift Dedicated qui a échoué. Vous pouvez également spécifier plusieurs ID d'opération ayant échoué. Utilisez le failed_osd_idcorrect.

      failed_osd_id est l'entier du nom de pod immédiatement après le préfixe rook-ceph-osd . Vous pouvez ajouter des ID Red Hat OpenShift Dedicated séparés par des virgules dans la commande pour supprimer plusieurs Red Hat OpenShift Dedicated, par exemple, FAILED_OSD_IDS=0,1,2.

      Supprimez l' Red Hat OpenShift Dedicatedqui a échoué:
      
oc process -n openshift-storage ocs-osd-removal \
-p FAILED_OSD_IDS=<failed_osd_id> FORCE_OSD_REMOVAL=true | oc create -n openshift-storage -f -
      Résultat de l'exemple :
      
[root@fu71-f09-vm3 ~]# oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=0 FORCE_OSD_REMOVAL=true | oc create -n openshift-storage -f -
Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "operator" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "operator" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "operator" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "operator" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
job.batch/ocs-osd-removal-job created
      Vérifiez le statut du pod ocs-osd-removal-job pour vérifier si le Red Hat OpenShift Dedicated a été retiré. Le statut Terminé confirme que le travail de suppression Red Hat OpenShift Dedicated a abouti.
      oc get pod -l job-name=ocs-osd-removal-job -n openshift-storage
      Résultat de l'exemple :
      [root@fu71-f09-vm3 ~]# oc get pod -n openshift-storage  | grep ocs-osd-removal
ocs-osd-removal-job-ls65l                                         0/1     Completed   0          23s
      Vérifiez que la suppression de Red Hat OpenShift Dedicated est terminée:
      oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1 | egrep -i 'completed removal'
      Résultat de l'exemple :
      [root@fu71-f09-vm3 ~]# oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1 | egrep -i 'completed removal'
2022-11-24 15:19:28.750910 I | cephosd: completed removal of OSD 0
      Supprimez le ocs-osd-removal-job:
      oc delete -n openshift-storage job ocs-osd-removal-job
      Supprimez le Released PV qui est connecté au noeud précédent.
      oc get pv | grep -i released
      
local-pv-e4a12175                          2Ti        RWO            Delete           Released    openshift-storage/ocs-deviceset-ibm-spectrum-fusion-local-0-data-1m6gnz   ibm-spectrum-fusion-local              3h34m
[root@fu71-f09-vm3 ~]# oc delete pv local-pv-e4a12175
persistentvolume "local-pv-e4a12175" deleted
  7. Récupérez les objets ayant échoué.
    1. Redémarrez le déploiement / pod mon:
      1. Mettez à jour nodeSelector dans le déploiement avec le nouveau noeud.
        oc edit deployment -n openshift-storage rook-ceph-mon-d
        nodeSelector:
        kubernetes.io/hostname: f09-prc4m-worker-cluster-b-djplp <<--new node
      2. Mettez à l'échelle la réplique à 1 et attendez que les pods Mon soient en cours d'exécution.
        oc scale deployment rook-ceph-mon-d --replicas=1 -n openshift-storage
        Exemple :
        oc scale deployment rook-ceph-mon-d --replicas=1 -n openshift-storage
    deployment.apps/rook-ceph-mon-d scaled
        
[root@fu71-f09-vm3 ~]# oc get pod -n openshift-storage | grep mon
    rook-ceph-mon-a-5bbb9dd98b-z54fx                                  2/2     Running     0          4m45s
    rook-ceph-mon-b-7fdd8f958b-lk9g2                                  2/2     Running     0          5m18s
    rook-ceph-mon-d-6945fbbfc5-nhhw8                                  2/2     Running     0          5m41s
    2. Vérifiez les pods Red Hat OpenShift Dedicated .
      Attendez que tous les pods soient en cours d'exécution.
      oc get pods -o wide -n openshift-storage| grep osd

      [root@fu71-f09-vm3 ~]# oc get pods -o wide -n openshift-storage| grep osd
rook-ceph-osd-0-d559cc4fb-xspr8                                   2/2     Running     0          4m58s   10.129.6.49       f09-prc4m-worker-cluster-b-djplp   <none>           <none>
rook-ceph-osd-1-6df7f9c669-n94md                                  2/2     Running     0          5m20s   10.128.6.95       f09-prc4m-worker-cluster-d-r5bxx   <none>           <none>
rook-ceph-osd-2-5c5d48ff7c-sdd7l                                  2/2     Running     0          5m17s   10.129.4.125      f09-prc4m-worker-cluster-c-mfb77   <none>           <none>
rook-ceph-osd-prepare-1bf7dd3d71fe899383e625dd0c27ea37-x9vtk      0/1     Completed   0          4h8m    10.128.6.79       f09-prc4m-worker-cluster-d-r5bxx   <none>           <none>
rook-ceph-osd-prepare-24272b5641dc95baffc7932d78894e3c-zhz8m      0/1     Completed   0          5m24s   10.129.6.48       f09-prc4m-worker-cluster-b-djplp   <none>           <none>
rook-ceph-osd-prepare-6f3c3b4626ec9888b6fbe5597afd55ea-zh7cp      0/1     Completed   0          4h8m    10.129.4.113      f09-prc4m-worker-cluster-c-mfb77   <none>           <none>
    3. Vérifiez les paramètres de chiffrement Red Hat OpenShift Dedicated . Si le chiffrement à l'échelle du cluster est activé, vérifiez que le mot clé "crypt" à côté du ou des noms d'ensemble d'unités ocs-deviceset
      oc debug node/<new-node-name> -- chroot /host dmsetup ls
      Résultat de l'exemple :
      # oc debug node/fu47 -- chroot /host dmsetup ls
Starting pod/fu47-debug ...
To use host binaries, run `chroot /host`
ocs-deviceset-sc-lvs-0-data-0clwxf-block-dmcrypt	(253:0)

      Si la vérification échoue, contactez l'assistance IBM.

  8. Quittez le mode maintenance une fois toutes les étapes terminées.
    oc label odfclusters.odf.isf.ibm.com -n ibm-spectrum-fusion-ns odfcluster "odf.isf.ibm.com/maintenanceMode-"
    Résultat de l'exemple :
    [root@fu40 ~]# oc label odfclusters.odf.isf.ibm.com -n ibm-spectrum-fusion-ns odfcluster "odf.isf.ibm.com/maintenanceMode-"
odfcluster.odf.isf.ibm.com/odfcluster unlabeled
  9. Allez sur la page Data foundation dans l'interface utilisateur de IBM Fusion et vérifiez l'état du cluster de stockage dans la section Health.