検索

2.2. IBM Z または LinuxONE インフラストラクチャーでのストレージノードの置き換え

download PDF

以下のいずれかの手順を選択して、ストレージノードを置き換えることができます。

2.2.1. IBM Z または LinuxONE インフラストラクチャーでの動作するノードの置き換え

この手順を使用して、IBM zSystems または LinuxONE インフラストラクチャー上の運用ノードを交換します。

手順

  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-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
  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 zSystem ストレージノードを交換品として入手します。
  9. Pending 状態の OpenShift Data Foundation に関連する証明書署名要求 (CSR) の有無を確認します。

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

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

    ユーザーインターフェイスを使用する場合
    1. 新規ノードについて、Action Menu (⋮) Edit Labels をクリックします。
    2. cluster.ocs.openshift.io/openshift-storage を追加し、Save をクリックします。
    コマンドラインインターフェイスの使用
    • 以下のコマンドを実行して、OpenShift Data Foundation ラベルを新規ノードに適用します。
    $ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""
  13. 新規ワーカーノードを localVolumeDiscovery および localVolumeSet に追加します。

    1. 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 が新規ノードになります。

    2. 編集する localVolumeSet を決定します。

      以下のコマンドの local-storage-project は、ローカルストレージプロジェクトの名前に置き換えます。OpenShift Data Foundation 4.6 以降では、デフォルトのプロジェクト名は openshift-local-storage です。以前のバージョンでは、デフォルトで local-storage を使用します。

      # oc get -n local-storage-project localvolumeset
      NAME          AGE
      localblock   25h
    3. localVolumeSet 定義を更新して、新規ノードを追加し、障害が発生したノードを削除します。

      # 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 が新規ノードになります。

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

    $ 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
                                              -nvs68
  15. openshift-storage プロジェクトを変更します。

    $ oc project openshift-storage
  16. 失敗した 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=${osd_id_to_remove} |oc create -f -

      コマンドにコンマ区切りの OSD ID を追加して、複数の OSD を削除できます。(例: FAILED_OSD_IDS=0,1,2)

      警告

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

  17. ocs-osd-removal Pod のステータスをチェックして、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
  18. 障害のあるノードに関連付けられた 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
  19. 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
  20. ocs-osd-removal ジョブを削除します。

    # oc delete job ocs-osd-removal-${osd_id_to_remove}

    出力例:

    job.batch "ocs-osd-removal-0" 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 状態にあることを確認します。
  4. 新しいオブジェクトストレージデバイス (OSD) Pod が置き換えるノードで実行されていることを確認します。

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

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

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

      $ oc debug node/<node_name>
      $ chroot /host
    2. 使用可能なブロックデバイスのリストを表示します。

      $ lsblk

      1 つ以上の ocs-deviceset 名の横にある crypt キーワードを確認します。

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

2.2.2. IBM Z または LinuxONE インフラストラクチャーでの障害のあるノードの置き換え

手順

  1. OpenShift Web コンソールにログインし、Compute Nodes をクリックします。
  2. 障害のあるノードを特定し、その Machine Name をクリックします。
  3. Actions Edit Annotations をクリックし、Add More をクリックします。
  4. machine.openshift.io/exclude-node-draining を追加し、Save をクリックします。
  5. Actions Delete Machine をクリックしてから、Delete をクリックします。
  6. 新しいマシンが自動的に作成されます。新しいマシンが起動するのを待ちます。

    重要

    このアクティビティーには、少なくとも 5〜10 分以上かかる場合があります。この期間中に生成された Ceph エラーは一時的なものであり、新しいノードにラベルを付けると自動的に解決され、機能します。

  7. Compute Nodes をクリックします。新しいノードが Ready 状態にあることを確認します。
  8. 以下のいずれかを使用して、OpenShift Data Foundation ラベルを新規ノードに適用します。

    ユーザーインターフェイスから
    1. 新規ノードについて、Action Menu (⋮) Edit Labels をクリックします。
    2. cluster.ocs.openshift.io/openshift-storage を追加し、Save をクリックします。
    コマンドラインインターフェイスの使用
    • OpenShift Data Foundation ラベルを新規ノードに適用します。
    $ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""
    <new_node_name>
    新しいノードの名前を指定します。

検証手順

  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 状態にあることを確認します。
  4. 新しいオブジェクトストレージデバイス (OSD) Pod が置き換えるノードで実行されていることを確認します。

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

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

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

      $ oc debug node/<node_name>
      $ chroot /host
    2. 使用可能なブロックデバイスのリストを表示します。

      $ lsblk

      1 つ以上の ocs-deviceset 名の横にある crypt キーワードを確認します。

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

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.