2.2. IBM Z または LinuxONE インフラストラクチャーでのストレージノードの置き換え
以下のいずれかの手順を選択して、ストレージノードを置き換えることができます。
2.2.1. IBM Z または LinuxONE インフラストラクチャーでの動作するノードの置き換え リンクのコピーリンクがクリップボードにコピーされました!
この手順を使用して、IBM zSystems または LinuxONE インフラストラクチャー上の運用ノードを交換します。
手順
ノードを特定し、置き換えるノードのラベルを取得します。ラックラベルをメモします。
$ oc get nodes --show-labels | grep <node_name>置き換えるノードで実行されている mon(ある場合) およびオブジェクトストレージデバイス (OSD) Pod を特定します。
$ oc get pods -n openshift-storage -o wide | grep -i <node_name>先の手順で特定された Pod のデプロイメントをスケールダウンします。
以下に例を示します。
$ oc scale deployment rook-ceph-mon-c --replicas=0 -n openshift-storage $ oc scale deployment rook-ceph-osd-0 --replicas=0 -n openshift-storage $ oc scale deployment --selector=app=rook-ceph-crashcollector,node_name=<node_name> --replicas=0 -n openshift-storageノードにスケジュール対象外 (unschedulable) のマークを付けます。
$ oc adm cordon <node_name>Terminating 状態の Pod を削除します。
$ 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 ")}'ノードをドレイン (解放) します。
$ oc adm drain <node_name> --force --delete-emptydir-data=true --ignore-daemonsetsノードを削除します。
$ oc delete node <node_name>- 新しい IBM zSystem ストレージノードを交換品として入手します。
Pending状態の OpenShift Data Foundation に関連する証明書署名要求 (CSR) の有無を確認します。$ oc get csr新規ノードに必要なすべての OpenShift Data Foundation CSR を承認します。
$ oc adm certificate approve <Certificate_Name>-
OpenShift Web コンソールで Compute
Nodes をクリックし、新規ノードが Ready 状態にあることを確認します。 以下のいずれかを使用して、
openshift-storageラベルを新しいノードに適用します。- ユーザーインターフェイスを使用する場合
-
新規ノードについて、Action Menu (⋮)
Edit Labels をクリックします。 -
cluster.ocs.openshift.io/openshift-storageを追加し、Save をクリックします。
-
新規ノードについて、Action Menu (⋮)
- コマンドラインインターフェイスの使用
- 以下のコマンドを実行して、OpenShift Data Foundation ラベルを新規ノードに適用します。
$ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""
新規ワーカーノードを
localVolumeDiscoveryおよびlocalVolumeSetに追加します。localVolumeDiscovery定義を更新し、新規ノードを追加して失敗したノードを削除します。# oc edit -n local-storage-project localvolumediscovery auto-discover-devices [...] nodeSelector: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - server1.example.com - server2.example.com #- server3.example.com - newnode.example.com [...]エディターを終了する前に必ず保存します。
上記の例では、
server3.example.comが削除され、newnode.example.comが新規ノードになります。編集する
localVolumeSetを決定します。以下のコマンドの local-storage-project は、ローカルストレージプロジェクトの名前に置き換えます。OpenShift Data Foundation 4.6 以降では、デフォルトのプロジェクト名は
openshift-local-storageです。以前のバージョンでは、デフォルトでlocal-storageを使用します。# oc get -n local-storage-project localvolumeset NAME AGE localblock 25hlocalVolumeSet定義を更新して、新規ノードを追加し、障害が発生したノードを削除します。# oc edit -n local-storage-project localvolumeset localblock [...] nodeSelector: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - server1.example.com - server2.example.com #- server3.example.com - newnode.example.com [...]エディターを終了する前に必ず保存します。
上記の例では、
server3.example.comが削除され、newnode.example.comが新規ノードになります。
新規
localblockPV が利用可能であることを確認します。$ oc get pv | grep localblock CAPA- ACCESS RECLAIM STORAGE NAME CITY MODES POLICY STATUS CLAIM CLASS AGE local-pv- 931Gi RWO Delete Bound openshift-storage/ localblock 25h 3e8964d3 ocs-deviceset-2-0 -79j94 local-pv- 931Gi RWO Delete Bound openshift-storage/ localblock 25h 414755e0 ocs-deviceset-1-0 -959rp local-pv- 931Gi RWO Delete Available localblock 3m24s b481410 local-pv- 931Gi RWO Delete Bound openshift-storage/ localblock 25h d9c5cbd6 ocs-deviceset-0-0 -nvs68openshift-storageプロジェクトを変更します。$ oc project openshift-storage失敗した OSD をクラスターから削除します。必要に応じて、複数の障害のある OSD を指定することができます。
PVC を特定します。後に、その特定の PVC に関連付けられた PV を削除する必要があるためです。
$ osd_id_to_remove=1 $ oc get -n openshift-storage -o yaml deployment rook-ceph-osd-${osd_id_to_remove} | grep ceph.rook.io/pvcここで、
osd_id_to_removeはrook-ceph-osd接頭辞の直後にくる Pod 名の整数です。この例では、デプロイメント名はrook-ceph-osd-1です。出力例:
ceph.rook.io/pvc: ocs-deviceset-localblock-0-data-0-g2mmc ceph.rook.io/pvc: ocs-deviceset-localblock-0-data-0-g2mmcこの例では、PVC 名は
ocs-deviceset-localblock-0-data-0-g2mmcです。失敗した OSD をクラスターから削除します。
$ oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=${osd_id_to_remove} |oc create -f -コマンドにコンマ区切りの OSD ID を追加して、複数の OSD を削除できます。(例: FAILED_OSD_IDS=0,1,2)
警告この手順により、OSD はクラスターから完全に削除されます。
osd_id_to_removeの正しい値が指定されていることを確認します。
ocs-osd-removalPod のステータスをチェックして、OSD が正常に削除されたことを確認します。Completedのステータスで、OSD の削除ジョブが正常に完了したことを確認します。# oc get pod -l job-name=ocs-osd-removal-osd_id_to_remove -n openshift-storage注記ocs-osd-removalが失敗し、Pod が予想されるCompletedの状態にない場合、追加のデバッグのために Pod ログを確認します。以下に例を示します。# oc logs -l job-name=ocs-osd-removal-osd_id_to_remove -n openshift-storage --tail=-1次のように、削除された OSD を手動でクリーンアップする必要がある場合があります。
ceph osd crush remove osd.osd_id_to_remove ceph osd rm osd_id_to_remove ceph auth del osd.osd_id_to_remove ceph osd crush rm osd_id_to_remove障害のあるノードに関連付けられた PV を削除します。
PVC に関連付けられた PV を特定します。
PVC 名は、失敗した OSD をクラスターから削除する際に取得された名前と同じである必要があります。
# oc get pv -L kubernetes.io/hostname | grep localblock | grep Released local-pv-5c9b8982 500Gi RWO Delete Released openshift-storage/ocs-deviceset-localblock-0-data-0-g2mmc localblock 24h worker-0Released状態の PV がある場合は、これを削除します。# oc delete pv <persistent-volume>以下に例を示します。
# oc delete pv local-pv-5c9b8982 persistentvolume "local-pv-5c9b8982" deleted
crashcollectorPod デプロイメントを特定します。$ oc get deployment --selector=app=rook-ceph-crashcollector,node_name=<failed_node_name> -n openshift-storage既存の
crashcollectorPod デプロイメントがある場合は、これを削除します。$ oc delete deployment --selector=app=rook-ceph-crashcollector,node_name=<failed_node_name> -n openshift-storageocs-osd-removalジョブを削除します。# oc delete job ocs-osd-removal-${osd_id_to_remove}出力例:
job.batch "ocs-osd-removal-0" deleted
検証手順
新しいノードが出力に存在することを確認します。
$ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1Workloads
Pods をクリックします。新しいノードの少なくとも次の Pod が Running 状態になっていることを確認します。 -
csi-cephfsplugin-* -
csi-rbdplugin-*
-
- 他の必要なすべての OpenShift Data Foundation Pod が Running 状態にあることを確認します。
新しいオブジェクトストレージデバイス (OSD) Pod が置き換えるノードで実行されていることを確認します。
$ oc get pods -o wide -n openshift-storage| egrep -i <new_node_name> | egrep osdオプション: クラスターでデータの暗号化が有効な場合には、新規 OSD デバイスが暗号化されていることを確認します。
直前の手順で特定された新しい各ノードに以下を実行します。
デバッグ Pod を作成し、選択した 1 つ以上のホストの chroot 環境を開きます。
$ oc debug node/<node_name>$ chroot /host使用可能なブロックデバイスのリストを表示します。
$ lsblk1 つ以上の
ocs-deviceset名の横にあるcryptキーワードを確認します。
- 検証手順が失敗した場合は、Red Hat サポートにお問い合わせください。
2.2.2. IBM Z または LinuxONE インフラストラクチャーでの障害のあるノードの置き換え リンクのコピーリンクがクリップボードにコピーされました!
手順
-
OpenShift Web コンソールにログインし、Compute
Nodes をクリックします。 - 障害のあるノードを特定し、その Machine Name をクリックします。
-
Actions
Edit Annotations をクリックし、Add More をクリックします。 -
machine.openshift.io/exclude-node-drainingを追加し、Save をクリックします。 -
Actions
Delete Machine をクリックしてから、Delete をクリックします。 新しいマシンが自動的に作成されます。新しいマシンが起動するのを待ちます。
重要このアクティビティーには、少なくとも 5〜10 分以上かかる場合があります。この期間中に生成された Ceph エラーは一時的なものであり、新しいノードにラベルを付けると自動的に解決され、機能します。
-
Compute
Nodes をクリックします。新しいノードが Ready 状態にあることを確認します。 以下のいずれかを使用して、OpenShift Data Foundation ラベルを新規ノードに適用します。
- ユーザーインターフェイスから
-
新規ノードについて、Action Menu (⋮)
Edit Labels をクリックします。 -
cluster.ocs.openshift.io/openshift-storageを追加し、Save をクリックします。
-
新規ノードについて、Action Menu (⋮)
- コマンドラインインターフェイスの使用
- OpenShift Data Foundation ラベルを新規ノードに適用します。
$ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""<new_node_name>- 新しいノードの名前を指定します。
検証手順
新しいノードが出力に存在することを確認します。
$ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= | cut -d' ' -f1Workloads
Pods をクリックします。新しいノードの少なくとも次の Pod が Running 状態になっていることを確認します。 -
csi-cephfsplugin-* -
csi-rbdplugin-*
-
- 他の必要なすべての OpenShift Data Foundation Pod が Running 状態にあることを確認します。
新しいオブジェクトストレージデバイス (OSD) Pod が置き換えるノードで実行されていることを確認します。
$ oc get pods -o wide -n openshift-storage| egrep -i <new_node_name> | egrep osdオプション: クラスターでデータの暗号化が有効な場合には、新規 OSD デバイスが暗号化されていることを確認します。
直前の手順で特定された新しい各ノードに以下を実行します。
デバッグ Pod を作成し、選択した 1 つ以上のホストの chroot 環境を開きます。
$ oc debug node/<node_name>$ chroot /host使用可能なブロックデバイスのリストを表示します。
$ lsblk1 つ以上の
ocs-deviceset名の横にあるcryptキーワードを確認します。
- 検証手順が失敗した場合は、Red Hat サポートにお問い合わせください。