検索

2.3. IBM Power インフラストラクチャー上のストレージノードの置き換え

download PDF

OpenShift Data Foundation では、ノード置き換えを、IBM Power 関連のデプロイメントで動作するノードについてプロアクティブに実行し、失敗したノードのそれぞれについてリアクティブに実行することができます。

2.3.1. IBM Power Systems で動作するストレージまたは障害のあるストレージノードの置き換え

前提条件

  • Red Hat では、交換前のノードと同様のインフラストラクチャーおよびリソースで、交換後のノードを設定することを推奨します。
  • OpenShift Container Platform (RHOCP) クラスターにログインしている必要があります。
  • 以前のバージョンから OpenShift Data Foundation 4.9 にアップグレードし、LocalVolumeDiscovery オブジェクトを作成していない場合は、 ローカルストレージでサポートされるクラスターの更新後の設定の変更についての以下の手順に従って、これを実行します。

手順

  1. ノードを特定し、置き換えるノードのラベルを取得します。

    $ oc get nodes --show-labels | grep <node_name>
  2. 置き換えるノードで実行されている mon(ある場合) およびオブジェクトストレージデバイス (OSD) Pod を特定します。

    $ oc get pods -n openshift-storage -o wide | grep -i <node_name>
  3. 先の手順で特定された Pod のデプロイメントをスケールダウンします。

    以下に例を示します。

    $ 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-storage
  4. ノードにスケジュール対象外 (unschedulable) のマークを付けます。

    $ oc adm cordon <node_name>
  5. 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 ")}'
  6. ノードをドレイン (解放) します。

    $ oc adm drain <node_name> --force --delete-emptydir-data=true --ignore-daemonsets
  7. ノードを削除します。

    $ oc delete node <node_name>
  8. 必要なインフラストラクチャーで新規の IBM Power マシンを取得します。クラスターの IBM Power へのインストール を参照します。
  9. 新規 IBM Power マシンを使用して新規 OpenShift Container Platform ノードを作成します。
  10. Pending 状態の OpenShift Container Platform に関連する証明書署名要求 (CSR) の有無を確認します。

    $ oc get csr
  11. 新規ノードに必要なすべての OpenShift Container Platform CSR を承認します。

    $ oc adm certificate approve <Certificate_Name>
  12. OpenShift Web コンソールで Compute Nodes をクリックし、新規ノードが Ready 状態にあることを確認します。
  13. 以下のいずれかを使用して、OpenShift Data Foundation ラベルを新規ノードに適用します。

    ユーザーインターフェイスを使用する場合
    1. 新規ノードについて、Action Menu (⋮) Edit Labels をクリックします。
    2. cluster.ocs.openshift.io/openshift-storage を追加し、Save をクリックします。
    コマンドラインインターフェイスの使用
    1. 以下のコマンドを実行して、OpenShift Data Foundation ラベルを新規ノードに適用します。
    $ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=''
  14. OpenShift ローカルストレージ Operator がインストールされている namespace を特定し、これを local_storage_project 変数に割り当てます。

    $ local_storage_project=$(oc get csv --all-namespaces | awk '{print $1}' | grep local)

    以下に例を示します。

    $ local_storage_project=$(oc get csv --all-namespaces | awk '{print $1}' | grep local)
    echo $local_storage_project
    openshift-local-storage
  15. 新規ワーカーノードを localVolumeDiscovery に追加します。

    1. localVolumeDiscovery 定義を更新し、新規ノードを追加して失敗したノードを削除します。

      # oc edit -n $local_storage_project localvolumediscovery auto-discover-devices
      [...]
         nodeSelector:
          nodeSelectorTerms:
            - matchExpressions:
                - key: kubernetes.io/hostname
                  operator: In
                  values:
                  #- worker-0
                  - worker-1
                  - worker-2
                  - worker-3
      [...]

      エディターを終了する前に必ず保存します。

      上記の例では、worker-0 が削除されて worker-3 が新規ノードになります。

  16. 新規に追加されたワーカーノードを localVolume に追加します。

    1. 編集する localVolume を決定します。

      # oc get -n $local_storage_project localvolume
      NAME           AGE
      localblock    25h
    2. localVolume 定義を更新して、新規ノードを追加し、障害が発生したノードを削除します。

      # oc edit -n $local_storage_project localvolume localblock
      [...]
          nodeSelector:
          nodeSelectorTerms:
            - matchExpressions:
                - key: kubernetes.io/hostname
                  operator: In
                  values:
                  #- worker-0
                  - worker-1
                  - worker-2
                  - worker-3
      [...]

      エディターを終了する前に必ず保存します。

      上記の例では、worker-0 が削除されて worker-3 が新規ノードになります。

  17. 新規 localblock PV が利用可能であることを確認します。

    $ oc get pv | grep localblock
    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     25h
  18. openshift-storage プロジェクトを変更します。

    $ oc project openshift-storage
  19. 失敗した OSD をクラスターから削除します。必要に応じて、複数の障害のある OSD を指定することができます。

    1. 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_removerook-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 です。

    2. 失敗した OSD をクラスターから削除します。

      $ oc process -n openshift-storage ocs-osd-removal \
      -p FAILED_OSD_IDS=<failed_osd_id> FORCE_OSD_REMOVAL=false | oc create -n openshift-storage -f -

      OSD が 3 つしかないクラスター、または OSD が削除された後にデータの 3 つのレプリカすべてを復元するにはスペースが不十分なクラスターでは、FORCE_OSD_REMOVAL 値を true に変更する必要があります。

      警告

      この手順により、OSD はクラスターから完全に削除されます。osd_id_to_remove の正しい値が指定されていることを確認します。

  20. ocs-osd-removal-job Pod のステータスをチェックして、OSD が正常に削除されたことを確認します。

    Completed のステータスで、OSD の削除ジョブが正常に完了したことを確認します。

    # oc get pod -l job-name=ocs-osd-removal-job -n openshift-storage
  21. OSD の取り外しが完了したことを確認します。

    $ oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1 | egrep -i 'completed removal'

    出力例:

    2022-05-10 06:50:04.501511 I | cephosd: completed removal of OSD 0
    重要

    ocs-osd-removal-job が失敗し、Pod が予想される Completed の状態にない場合、追加のデバッグのために Pod ログを確認します。

    以下に例を示します。

    # oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1
  22. 障害のあるノードに関連付けられた PV を削除します。

    1. 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-0
    2. Released 状態の PV がある場合は、これを削除します。

      # oc delete pv <persistent-volume>

      以下に例を示します。

      # oc delete pv local-pv-5c9b8982
      persistentvolume "local-pv-5c9b8982" deleted
  23. crashcollector Pod デプロイメントを特定します。

    $ oc get deployment --selector=app=rook-ceph-crashcollector,node_name=<failed_node_name> -n openshift-storage

    既存の crashcollector Pod デプロイメントがある場合は、これを削除します。

    $ oc delete deployment --selector=app=rook-ceph-crashcollector,node_name=<failed_node_name> -n openshift-storage
  24. ocs-osd-removal-job を削除します。

    # oc delete -n openshift-storage job ocs-osd-removal-job

    出力例:

    job.batch "ocs-osd-removal-job" deleted

検証手順

  1. 以下のコマンドを実行して、出力で新規ノードが表示されていることを確認します。

    $ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1
  2. Workloads Pods をクリックし、新規ノード上の少なくとも以下の Pod が Running 状態にあることを確認します。

    • csi-cephfsplugin-*
    • csi-rbdplugin-*
  3. 他の必要なすべての OpenShift Data Foundation Pod が Running 状態にあることを確認します。

    また、増分の mon が新規に作成されており、Running 状態にあることを確認します。

    $ oc get pod -n openshift-storage | grep mon

    出力例:

    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          162m

    OSD と Mon が Running 状態になるまで数分かかる場合があります。

  4. 新規 OSD Pod が交換後のノードで実行されていることを確認します。

    $ oc get pods -o wide -n openshift-storage| egrep -i new-node-name | egrep osd
  5. (オプション) クラスターでクラスター全体の暗号化が有効な場合には、新規 OSD デバイスが暗号化されていることを確認します。

    直前の手順で特定された新規ノードごとに、以下を実行します。

    1. デバッグ Pod を作成し、選択したホストの chroot 環境を開きます。

      $ oc debug node/<node name>
      $ chroot /host
    2. lsblk を実行し、ocs-deviceset 名の横にある crypt キーワードを確認します。

      $ lsblk
  6. 検証手順が失敗した場合は、Red Hat サポートにお問い合わせください
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.