現在のOSDリソース制限を確認する

リソース制限を変更する前に、OSDポッドの現在のCPUおよびメモリ設定を確認してください。 現在のリクエスト数と制限値をメモしておき、後で実際の使用状況や更新後の数値と比較できるようにしておきましょう。

oc get pods -n openshift-storage -l app=rook-ceph-osd \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{range .spec.containers[*]}  Container: {.name}{"\n"}    Requests - CPU: {.resources.requests.cpu}, Memory: {.resources.requests.memory}{"\n"}    Limits   - CPU: {.resources.limits.cpu}, Memory: {.resources.limits.memory}{"\n"}{end}{"\n"}{end}'

出力結果を確認し、各OSDコンテナの現在のCPUおよびメモリの要求量と制限を特定してください。 次のコマンドで、これらの値を実際の使用状況と比較してください。 CPU やメモリの使用率が設定された上限に常に近づいている場合は、上限を引き上げることでボトルネックの解消につながる可能性があります。

実際のリソース使用状況を確認するには、次のコマンドを実行し、CPUおよびメモリの使用率を、あらかじめ記録しておいた上限値と比較してください：

oc adm top pods -n openshift-storage -l app=rook-ceph-osd

OSDのリソース制限を引き上げる

VM のワークロードに対して現在の制限が不十分な場合は、「 ocs-storagecluster 」リソースを編集して制限を更新してください。

また、 ocs-storagecluster の設定で、 mon、 mgr、 rgw など、他の Rook-Cephポッドの制限値を変更することもできます。 詳細については、 Red Hat のソリューション 6959127 を参照してください。

1. ストレージクラスタのリソースを開いて編集します。

   oc edit storagecluster ocs-storagecluster -n openshift-storage
   

2. storageDeviceSets の該当するエントリで、「 resources 」フィールドを追加または更新してください。 以下の部分的な例では、上限をCPU 4個、メモリ24 Giに設定し、要求値をCPU 2個、メモリ24 Giとしています：

   storageDeviceSets:
     - name: ocs-deviceset
       resources:
         limits:
           cpu: "4"
           memory: "24Gi"
         requests:
           cpu: "2"
           memory: "24Gi"
   

   CPUおよびメモリの要求量は、制限値以下でなければなりません。

3. エディターを保存して終了します。

   変更を保存すると、OSDポッドは自動的に再起動します。 ローリング再起動が完了するまで待ってから、他のストレージ操作を実行してください。

更新されたリソース制限を確認する

ローリング再起動が完了したら、更新された制限がすべてのOSDポッドに適用されていることを確認してください。

1. ローリング再起動を監視し、すべてのOSDポッドが「 Running 」状態に戻ることを確認します。 すべてのOSDポッドのステータスが「 Running 」となり、「 Pending 」または「 Terminating 」となっているポッドがなくなれば、再起動は完了です。

   oc get pods -n openshift-storage | grep osd | grep -v prepare | grep -v rotation
   

2. 新しいリソースの値が適用されていることを確認してください。

   oc get pods -n openshift-storage -l app=rook-ceph-osd \
     -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{range .spec.containers[*]}  Container: {.name}{"\n"}    Requests - CPU: {.resources.requests.cpu}, Memory: {.resources.requests.memory}{"\n"}    Limits   - CPU: {.resources.limits.cpu}, Memory: {.resources.limits.memory}{"\n"}{end}{"\n"}{end}'
   

   CPU およびメモリの値が、設定した値と一致していることを確認してください。

基本的なヘルスチェックを実行する

Ceph の全体的な健全性概要を確認するには、次のコマンドを実行してください。 正常なクラスターでは、 HEALTH_OK が返されます。

oc rsh -n openshift-storage $(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name) ceph status

現在発生している警告やエラーを確認するには、次のコマンドを実行してください：

oc rsh -n openshift-storage $(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name) ceph health detail

クラスタの状態を理解する

ceph status の出力には、データの健全性を示す配置グループ（PG）の状態が含まれます。

アクティブ／クリーン

理想的な状態。 すべての配置グループがアクティブであり、すべてのデータがレプリケートされており、データの移動は発生していません。 アクションは不要です。

アクティブ＋リマップ済み、アクティブ＋バックフィリング中、アクティブ＋復旧中

データの再配布が行われています。 OSDリソースの変更、ノードの交換、またはスケーリング操作の後、これらの状態は正常なものです。 クラスタが active/clean の状態に戻るまで待ってから、追加の変更を行ってください。

正常な出力の例：

HEALTH_OK

リバランス中の出力例：

HEALTH_WARN
  Degraded data redundancy: 123/456 objects degraded (26.974%)
  Recovery 50/456 objects degraded (10.965%)

配置グループとOSDの状態を確認する

データの分布やOSDの状態についてより詳細に把握するには、以下の確認作業を行ってください。

1. 配置グループのステータスを確認し、「 active+clean 」状態ではないグループを特定します。

   oc rsh -n openshift-storage $(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name) ceph pg stat
   

2. 個々のOSDの状態を確認し、OSDが「 up 」および「 in 」であることを確認してください。

   oc rsh -n openshift-storage $(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name) ceph osd status