2.3. Replacing storage nodes on IBM Power infrastructure
For OpenShift Data Foundation, you can perform node replacement proactively for an operational node, and reactively for a failed node, for the deployments related to IBM Power.
2.3.1. Replacing an operational or failed storage node on IBM Power 링크 복사링크가 클립보드에 복사되었습니다!
Prerequisites
- Ensure that the replacement nodes are configured with the similar infrastructure and resources to the node that you replace.
- You must be logged into the OpenShift Container Platform cluster.
Procedure
Identify the node, and get the labels on the node that you need to replace:
$ oc get nodes --show-labels | grep <node_name><node_name>- Specify the name of node that you need to replace.
Identify the
mon(if any), and Object Storage Device (OSD) pods that are running in the node that you need to replace:$ oc get pods -n openshift-storage -o wide | grep -i <node_name>Scale down the deployments of the pods identified in the previous step:
For example:
$ oc scale deployment rook-ceph-mon-a --replicas=0 -n openshift-storage$ oc scale deployment rook-ceph-osd-1 --replicas=0 -n openshift-storage$ oc scale deployment --selector=app=rook-ceph-crashcollector,node_name=<node_name> --replicas=0 -n openshift-storageMark the node as unschedulable:
$ oc adm cordon <node_name>Remove the pods which are in
Terminatingstate:$ 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 ")}'Drain the node:
$ oc adm drain <node_name> --force --delete-emptydir-data=true --ignore-daemonsetsDelete the node:
$ oc delete node <node_name>- Get a new IBM Power machine with the required infrastructure. See Installing a cluster on IBM Power.
- Create a new OpenShift Container Platform node using the new IBM Power machine.
Check for the Certificate Signing Requests (CSRs) related to OpenShift Container Platform that are in
Pendingstate:$ oc get csrApprove all the required OpenShift Container Platform CSRs for the new node:
$ oc adm certificate approve <certificate_name><certificate_name>- Specify the name of the CSR.
-
Click Compute
Nodes in the OpenShift Web Console. Confirm that the new node is in Ready state. Apply the OpenShift Data Foundation label to the new node using any one of the following:
- From the user interface
-
For the new node, click Action Menu (⋮)
Edit Labels. -
Add
cluster.ocs.openshift.io/openshift-storage, and click Save.
-
For the new node, click Action Menu (⋮)
- From the command-line interface
- Apply the OpenShift Data Foundation label to the new node:
$ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=''<new_node_name>- Specify the name of the new node.
Identify the namespace where OpenShift local storage operator is installed, and assign it to the
local_storage_projectvariable:$ local_storage_project=$(oc get csv --all-namespaces | awk '{print $1}' | grep local)For example:
$ local_storage_project=$(oc get csv --all-namespaces | awk '{print $1}' | grep local)echo $local_storage_projectExample output:
openshift-local-storageAdd a newly added worker node to the
localVolume.Determine the
localVolumeyou need to edit:# oc get -n $local_storage_project localvolumeExample output:
NAME AGE localblock 25hUpdate the
localVolumedefinition to include the new node, and remove the failed node:# oc edit -n $local_storage_project localvolume localblockExample output:
[...] nodeSelector: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: #- worker-0 - worker-1 - worker-2 - worker-3 [...]Remember to save before exiting the editor.
In the this example,
worker-0is removed andworker-3is the new node.
Verify that the new
localblockPersistent Volume (PV) is available:$ oc get pv | grep localblockExample output:
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS AGE local-pv-3e8964d3 500Gi RWO Delete Bound ocs-deviceset-localblock-2-data-0-mdbg9 localblock 25h local-pv-414755e0 500Gi RWO Delete Bound ocs-deviceset-localblock-1-data-0-4cslf localblock 25h local-pv-b481410 500Gi RWO Delete Available localblock 3m24s local-pv-5c9b8982 500Gi RWO Delete Bound ocs-deviceset-localblock-0-data-0-g2mmc localblock 25hNavigate to the
openshift-storageproject:$ oc project openshift-storageRemove the failed OSD from the cluster. You can specify multiple failed OSDs if required.
Identify the Persistent Volume Claim (PVC):
$ osd_id_to_remove=1$ oc get -n openshift-storage -o yaml deployment rook-ceph-osd-${<osd_id_to_remove>} | grep ceph.rook.io/pvcwhere,
<osd_id_to_remove>is the integer in the pod name immediately after therook-ceph-osdprefix.In this example, the deployment name is
rook-ceph-osd-1.Example output:
ceph.rook.io/pvc: ocs-deviceset-localblock-0-data-0-g2mmc ceph.rook.io/pvc: ocs-deviceset-localblock-0-data-0-g2mmcRemove the failed OSD from the cluster. You can specify multiple failed OSDs if required:
$ oc process -n openshift-storage ocs-osd-removal \ -p FAILED_OSD_IDS=<failed_osd_id> | oc create -f -<failed_osd_id>Is the integer in the pod name immediately after the
rook-ceph-osdprefix. You can add comma separated OSD IDs in the command to remove more than one OSD, for example,FAILED_OSD_IDS=0,1,2.The
FORCE_OSD_REMOVALvalue must be changed totruein clusters that only have three OSDs, or clusters with insufficient space to restore all three replicas of the data after the OSD is removed.주의This step results in the OSD being completely removed from the cluster. Ensure that the correct value of
osd_id_to_removeis provided.
Verify that the OSD was removed successfully by checking the status of the
ocs-osd-removal-jobpod.A status of
Completedconfirms that the OSD removal job has succeeded.# oc get pod -l job-name=ocs-osd-removal-job -n openshift-storageEnsure that the OSD removal is completed.
$ oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1 | egrep -i 'completed removal'Example output:
2022-05-10 06:50:04.501511 I | cephosd: completed removal of OSD 0중요If the
ocs-osd-removal-jobfails, and the pod is not in the expectedCompletedstate, check the pod logs for further debugging.For example:
# oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1Delete the PV associated with the failed node.
Identify the PV associated with the PVC:
# oc get pv -L kubernetes.io/hostname | grep localblock | grep ReleasedExample output:
local-pv-5c9b8982 500Gi RWO Delete Released openshift-storage/ocs-deviceset-localblock-0-data-0-g2mmc localblock 24h worker-0The PVC name must be identical to the name that is obtained while removing the failed OSD from the cluster.
If there is a PV in
Releasedstate, delete it:# oc delete pv <persistent_volume>For example:
# oc delete pv local-pv-5c9b8982Example output:
persistentvolume "local-pv-5c9b8982" deleted
Identify the
crashcollectorpod deployment:$ oc get deployment --selector=app=rook-ceph-crashcollector,node_name=<failed_node_name> -n openshift-storageIf there is an existing
crashcollectorpod deployment, delete it:$ oc delete deployment --selector=app=rook-ceph-crashcollector,node_name=<failed_node_name> -n openshift-storageDelete the
ocs-osd-removal-job:# oc delete -n openshift-storage job ocs-osd-removal-jobExample output:
job.batch "ocs-osd-removal-job" deleted
Verification steps
Verify that the new node is present in the output:
$ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1Click Workloads
Pods. Confirm that at least the following pods on the new node are in Running state: -
csi-cephfsplugin-* -
csi-rbdplugin-*
-
Verify that all other required OpenShift Data Foundation pods are in Running state.
Ensure that the new incremental
monis created and is in the Running state:$ oc get pod -n openshift-storage | grep monExample output:
rook-ceph-mon-b-74f6dc9dd6-4llzq 1/1 Running 0 6h14m rook-ceph-mon-c-74948755c-h7wtx 1/1 Running 0 4h24m rook-ceph-mon-d-598f69869b-4bv49 1/1 Running 0 162mThe OSD and monitor pod might take several minutes to get to the
Runningstate.Verify that the new OSD pods are running on the replacement node:
$ oc get pods -o wide -n openshift-storage| egrep -i <new_node_name> | egrep osdOptional: If cluster-wide encryption is enabled on the cluster, verify that the new OSD devices are encrypted.
For each of the new nodes identified in the previous step, do the following:
Create a debug pod and open a chroot environment for the one or more selected hosts:
$ oc debug node/<node_name>$ chroot /hostDisplay the list of available block devices:
$ lsblkCheck for the
cryptkeyword beside the one or moreocs-devicesetnames.
- If the verification steps fail, contact Red Hat Support.