複製プール（デフォルト）

ODFのデフォルト設定では、3ウェイレプリケーションが使用されます。 すべてのデータは、異なるノードに3つのコピーとして保存され、最大2つのディスクまたはノードの同時障害からデータを保護します。

• 利点：シンプルなアーキテクチャ、高速な読み取り、迅速な復旧、および予測可能なレイテンシ。
• 使用量の増加： 3x 利用可能なデータ1バイトあたり、生のストレージ容量。

コピーが紛失した場合はどうなるのか（ rep3 ）：

min_size パラメータは、CephがI/Oを許可する前に利用可能でなければならない最小コピー数を制御する。 ODFでは、デフォルトで rep3 プールに対して min_size=2 が設定されており、これは requireSafeReplicaSize: true を通じて強制されます。つまり、2つまたは3つのコピーが利用可能な場合、読み取りおよび書き込みは通常通り行われます。 利用可能なコピーが1つしかない場合、Cephはデータの不整合がさらに広がるのを防ぐため、I/Oをブロックします。

この動作は、可用性よりもデータの整合性を優先させる、意図的な安全対策です。

2つ目のコピーが失われてから再レプリケーションが完了するまでの期間が、最も危険な時期です。 この間、3回目の故障でデータが永久に失われる。 Cephの再レプリケーション速度は、利用可能なクラスタの帯域幅と空き容量に依存するため、キャパシティプランニングが重要となるのです。 負荷がかかりすぎている、あるいはほぼ満杯の状態にあるクラスタでは、再レプリケーションに時間がかかり、その結果、脆弱性が生じる期間が長引きます。

rep2 のプールでは、進行がより急速です。 コピーが1部失われた場合、残るコピーは1部のみとなる。 min_size=2 （デフォルト）では、欠落したOSDが復帰するか、新しいコピーがレプリケートされるまで、影響を受けるPGのI/Oは直ちにブロックされます。 min_size=1 を使用すると、残りの 1 つのコピーで I/O は継続されますが、2 度目の障害が発生すると、データが永久に失われてしまいます。

Red Hat OpenShift （ Kubernetes Service ）のODFアドオンは、 ocs-storagecluster-cephblockpool を使用して、 rep3 プールのみを自動的に作成します。 Rep2 プールはこのアドオンによって作成されるものではありません。 replicated.size: 2 およびそれに対応する StorageClass を使用して、カスタム CephBlockPool を手動で作成する必要があります。 詳細については、「 仮想化向けのカスタム StorageClass の作成 」を参照してください。

rep2 は rep3 に比べて耐障害性が低いため、ストレージの節約効果が、ワークロードにおけるリスクの増加に見合うかどうかを評価してください。

IBM 可用性とデータの耐久性を確保するため、すべての本番環境の仮想化ワークロードに対して、3ウェイレプリケーションを推奨しています。

消去符号化プール

ストレージ容量の効率が優先される環境のために、ODFは消去符号化（EC）プールもサポートしている。 ECはデータを k のデータチャンクと m のパリティチャンクに分割することで、レプリケーションと比較して生のストレージ使用量を削減しつつ、フォールトトレランスを確保します。

サポート状況： ODFにおけるRBDおよび CephFS 向けのイレイジャーコーディングは、開発者向けプレビュー機能であり、ODFで初めて導入されました 4.20。 開発者向けプレビュー機能は、本番環境での使用には対応していません。 また、これらは Red Hat お客様ケース管理の対象外となります。 ODF 4.20 が公開される前は、RGW（オブジェクトストレージ）ECのみが開発者向けプレビューとして利用可能でした（ODF 4.16 参照）。 基礎となるCephストレージエンジンは、Luminousリリース（2017年）以降、RBDのECオーバーライトをサポートしているが、ODFオペレータとその管理された導入モデルは、本番ブロックストレージワークロード用のECプールをまだ認証していない。 すべての本番環境の VM ストレージには、レプリケートされたプール（ rep2 または rep3 ）を使用するように計画し、ECプールについては、開発者プレビューの制限が許容できる非本番環境でのみ評価してください。

参考までに、利用可能なすべてのプールタイプを以下の表にまとめました。

以下のリストは、消去符号化における主な考慮事項を示しています。

• ECプールは、パリティ計算や1回の操作あたりにより多くのチャンクを書き込む必要があるため、レプリケートプールよりも書き込みレイテンシが高くなります。
• ECプールは、競争力のあるシーケンシャル・リード・スループットを提供するが、ランダム・ライトIOPSが低下する可能性がある。
• 失敗ドメインの数は、少なくとも k+m 以上でなければならない。 3ノードのクラスタでは、 rep2、 rep3、および ec-2-1 のみが利用可能です。
• 6ノードのクラスタの場合、前述のすべてのプールタイプが利用可能です。

単一のレプリカプール（開発およびテスト用のみ、耐障害性なし）

ODFアドオン・バージョン 4.14 以降、 Red Hat OpenShift Kubernetes Service は、 addSingleReplicaPool パラメーターを通じて単一のレプリカ（ rep1 ）プールをサポートしています。 このパラメータを指定すると、データのレプリケーションを行わないCephの非耐障害性ブロックプールが作成され、各データブロックは1回だけ保存されます。

ODF をデプロイする際にシングルレプリカプールを有効にするには、次のコマンドを実行してください

ibmcloud oc cluster addon enable openshift-data-foundation -c <cluster_name> \
  --version <version> \
  --param "addSingleReplicaPool=true"

このコマンドは、追加の StorageClass:

• ocs-storagecluster-ceph-non-resilient-rbd: WaitForFirstConsumer ボリュームバインディングによるシングルレプリカブロックストレージ。

標準の replica-3 プール（ocs-storagecluster-cephblockpool ）は、これを使用して引き続き作成されます。 非弾力性プールは、別途、オプトイン・オプションである。

1つのレプリカプールには、次のようなユースケースがあります。

• 開発およびテスト環境 ― データの永続性がそれほど重要ではなく、ストレージコストの削減が優先される環境。
• レプリケーション機能を組み込んだアプリケーション ― これらのアプリケーションは、アプリケーション層で独自のデータ冗長性を管理します。 これらのアプリケーションは、ノード間で複数のコピーを保持しているため、ストレージレベルのレプリケーションは冗長となります。

単一のレプリカ・プールはゼロ・フォールト・トレランスを提供する。 単一のOSDまたはノードの障害は、そのOSD上のすべてのデータについて、永久的で回復不能なデータ損失をもたらす。 IBM Cloud、このオプションはデータ損失、データ破損、システム不安定化のリスクを高めると、文書で明確に警告している。 詳細については、 Cephのドキュメントを参照してください。

制限事項

• ブロックストレージのみ：ファイルストレージは、レプリカが1つの場合はサポートされていません。
• 追加のディスクが必要： replica-3 プールで使用されるディスクとは別に、ノードごとに少なくとも1台の追加のNVMeディスクが必要です。 この追加ディスクがないと、 replica-1 OSDは起動せず、ストレージクラスタは進行状態のままである。
• 障害ドメインごとに1つのプール：ODFは、 WaitForFirstConsumer を使用してデータのローカリティを検証することによってバインドされたボリュームを持つ、障害ドメインごとに1つの非復旧性 CephBlockPool を作成します。
• 仮想マシンのワークロードのルートディスクには推奨されません：ルートディスクをホストするOSDに障害が発生すると、仮想マシンのワークロードが永久に失われます。 開発またはテスト仮想マシンのワークロードで、使い捨てのデータディスクのみに非復旧性プールを使用します。

本番環境の仮想化ワークロードについては、常に replica-3 （または少なくとも replica-2 ）のプールを使用してください。

VMware vSAN 移行の比較

VMware vSAN™ から移行するチームにとって、これらの Ceph プールタイプは、おなじみの vSAN ストレージポリシーに対応しています：

との主な違い vSAN:

• 最小ホストが小さい：Cephはクラスタクォーラムをデータ配置から分離します。 rep3 のプールに必要なホストは3台だけで済みます。これは、各ホストが1つの完全なコピーを保存するためです。 vSAN RAID-1 FTT=2 には5台のホストが必要です。
• rep2 標準の vSAN に準拠しています。 RAID-1: vSAN の導入事例のほとんどでは、2 つのコピーを保存する FTT=1 が使用されています。 Cephの rep2 がこれに直接相当します。
• ec-3-1 vSAN および に一致します。どちらも 3+1 構成を採用しており、 の使用率を実現しています。これは、単一障害耐性において最もスペース効率の高い選択肢です。 RAID-5: 1.33x
• ec-4-2 vSAN および に一致します。どちらも 4+2 レイアウトを採用しており、二重障害耐性を備えながら、 の使用率を実現しています。 RAID-6: 1.5x
• ec-2-1 また、 ec-2-2 には、 vSAN に直接対応する構成はありません。データチャンクの数が少ない、より小規模なCeph EC構成であり、これにより1バイトあたりの使用率は高くなりますが、必要なホスト数は少なくて済みます。 これらは、ストレージ効率を犠牲にする代わりに、必要なホスト数を少なくしています。

計画能力

ODFクラスタを計画する際は、選択したデータ保護ポリシーによるストレージの実際の使用量をアカウント。 使用可能な容量は、未加工のNVMe容量の合計よりも少ない。

使用可能容量の計算式は Usable capacity = Total raw NVMe capacity / Replication or EC overhead factor である。

ノードあたり8 x 3.2 TB NVMeドライブ（合計 76.8 TB raw）を搭載した3ノード・クラスターの計算例を以下に示します：

仮想マシンのワークロード容量の見積もり：30GBのルートディスクと100GBのデータディスクを持つ典型的な仮想マシンのワークロードは、130GBの使用可能なストレージを使用します。 rep3 を使用する場合、その仮想マシンのワークロードには 390 GB の生ストレージ容量が必要です。 前述の3ノードクラスターでは、この規模の仮想マシンワークロードを約196台プロビジョニングできるでしょう。 実際には、パフォーマンスを維持し、リカバリ作業をサポートするために、Cephの使用率を75%未満に抑える。

Cephのパフォーマンスは、クラスタの使用量が増えるにつれて低下します。 ODFは、いずれかのOSDの使用率が75%を超えた場合、「 CephOSDNearFull 」 Prometheus というアラートを発行します。 85%に達すると、Cephはネイティブの nearfull OSDフラグ（mon_osd_nearfull_ratio ）を設定し、ODFは CephOSDCriticallyFull アラートを発火させます。 90%に達すると、Cephは影響を受けたOSDへのバックフィルおよびリカバリ操作を停止します（mon_osd_backfillfull_ratio ）。95%に達すると、CephはOSDを full としてマークし（mon_osd_full_ratio ）、すべての書き込みをブロックし、 HEALTH_ERR を発行します。 通常運用時には使用率が70%未満になるよう容量を計画し、ノードのメンテナンスや障害発生時にデータ復旧やリバランスを行うための余裕を確保してください。

現在のクラスタの使用状況を確認するには、次のコマンドを実行してください：

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

ワーカーノード数とトポロジー

IBM Cloud のODFアドオンで使用されるフェイルドメインのトポロジーは、クラスタの構成によって異なります：

• マルチゾーンクラスター（3つのアベイラビリティゾーン）： 障害ドメインは「 zone 」に設定されています。 ワーカーノードは各ゾーンに分散配置されており、ゾーン間のバランスを維持するためには、ODFを3の倍数ずつ拡張する必要があります。 可用性、パフォーマンス、およびデータの安全性を最適化するには、ODF ストレージクラスタで 3、6、または 9 ノードを使用してください。各ゾーンには、同じ数のノードが割り当てられます。
• シングルゾーンのクラスター、またはアベイラビリティゾーンが3つ未満のクラスター： 柔軟なスケーリングが自動的に有効になり、フェイルドメインは host に設定されます。 まずは3つのノードから始めて、1つずつノードを追加していくことができます。

ODFストレージクラスタに参加するノードはすべてベアメタルでなければならない。 同じODFクラスタ内で仮想化ノードとベアメタルノードを混在させることはサポートされていません。

マルチゾーンクラスターの場合、3の倍数ではない数のノードを追加すると、ゾーン間の不均衡が生じます。 ノードが4つある場合、1つのゾーンに2つのノードが割り当てられ、他のゾーンにはそれぞれ1つずつ割り当てられるため、OSDの負荷分散が不均一になり、データの配置が最適でなくなり、使用率が不均一になり、一部のOSDがアイドル状態になってしまう。

マルチゾーンクラスターの場合、ゾーントポロジーのバランスを保つために、常に3の倍数でスケールアウトしてください。

oc get nodes -l node-role.kubernetes.io/worker= \
  -o custom-columns='NAME:.metadata.name,RACK:.metadata.labels.topology\.kubernetes\.io/rack'

ODF購読プラン

ご要件に最も適したプランをお選びください：

• 基本情報

  • コストの削減
  • 内部モードでの展開のみ
  • ディザスタリカバリ、ストレッチクラスタ、および外部モードでの展開には対応していません
  • テストおよび開発環境、概念実証（PoC）、あるいは小規模な導入に最適です

• アドバンスト

  • ディザスタリカバリ、ストレッチクラスタ、外部モードでの展開、高度なきめ細かな暗号化、マルチクラスタ対応などを含む充実した機能セット
  • 仮想マシンを用いた生産環境の仮想化ワークロードに推奨されます

どちらのプランにも、ブロックプールでの BlueStore 圧縮、シンプロビジョニング、スナップショット、およびクローン機能が含まれています。 各プランの違いは、ストレージ効率に関する機能というよりは、災害復旧、暗号化の粒度、および導入の柔軟性に関するものです。

ODFは、Multicloud Object Gateway（MCG）を介したオブジェクトストレージに対してのみ重複排除をサポートする。 ブロックストレージは重複排除をサポートしていない。 このサポートは、「Essentials」プランと「Advanced」プランの両方に適用されます。 RBD用のアップストリームCeph重複排除はまだ実験的であり、ODFでの使用は認証されていません。

詳細については、「 ODFの基礎」と「ODFの応用 」を参照してください。

ストレージ・タイプ

• ローカルストレージを選択します。
• ローカルストレージは、ベアメタルワーカーノードで利用可能なローカルNVMeインスタンスストレージを使用します。
• NVMeドライブは、仮想マシンのワークロード用ディスクに求められる低レイテンシと高いIOPS性能を実現します。

ODFリソースプロファイル

ODFは、Cephデーモン用に予約されるCPUとメモリを制御する3つのリソース割り当てプロファイルを提供します。

• リーン：最小限の資源配分。 リーン・プロファイルは、リソースに制約のある環境、テスト、開発、概念実証に適している。 生産環境の仮想化ワークロードには、Leanの使用は推奨されません。
• バランス： Red Hat OpenShift Kubernetes Service のデフォルトプロファイル。 Balancedプロファイルは、汎用ワークロードのリソース消費とパフォーマンスのバランスを提供する。
• パフォーマンス：Cephデーモンにより多くのCPUとメモリを割り当てることで、デーモン側のボトルネックが発生するリスクを低減します。 高いIOPSを必要とするワークロード、多数の仮想サーバー、および高負荷なアプリケーションに最適です。

ローカルのNVMeドライブを使用したベアメタル展開では、「 Performance 」リソースプロファイルを使用してください。 ノードあたり8台以上のNVMeドライブを搭載したベアメタルノードでは、ホストあたりのOSD数が多くなります。 「Balanced」プロファイルでは、基盤となるNVMeハードウェアが飽和状態に達する前に、CephデーモンのCPUおよびメモリの上限に達してしまうことが多く、その結果、IOPSが制限され、レイテンシが増加します。 「パフォーマンス」プロファイルは、ベアメタル環境における本番環境の Red Hat OpenShift 仮想化ワークロードに対して推奨される最低限のプロファイルです。

ODFインストール中に Red Hat OpenShift Webコンソールに表示されるリソース要件は、クラスタOSD数に基づいて動的に計算されます。 したがって、NVMeドライブの数が多ければ多いほど、それに応じてより多くのリソースが必要となります。 これらの値は固定されていません。 コンソールに表示される要件を、特定のクラスタ構成について常に確認してください。

プロファイルは、 Red Hat OpenShift ウェブ・コンソールの Configure Performance 画面から StorageSystem 作成時に選択します。 リソースが不足しているCephデーモンは、隠れたボトルネックとなり、基盤となるストレージハードウェアが提供できる水準よりもIOPSが低下したり、レイテンシが高くなったりする原因となる可能性があります。

ベアメタルサーバーのプロファイルを、選択したプロファイルに表示されるリソース要件に合わせます： IBM Cloud VPCベアメタルサーバプロファイル

ベアメタルサーバーでは、リソースのわずかなオーバーサブスクリプションはしばしば許容される。 ただし、表示されている最小要件を大幅に下回る設定を行わないでください。そうすると、ODFのパフォーマンスと安定性が低下します。

ノードあたりのOSDディスク数

• 各ベアメタルサーバーで利用可能なローカルNVMeドライブの台数を特定します。
• ノードごとに設定するOSDの数が、使用可能なNVMeドライブの数を上回らないようにしてください。
• 最適なパフォーマンスと障害の特定を確実にするため、NVMeドライブ1台につきOSDを1台配置することを推奨します。
• OSDディスクの数は、通常、ベアメタルノード1台あたりのNVMeドライブの数と一致するようにしてください。 UIに表示されるストレージ容量の計算値は、ローカルストレージ構成における実際の使用可能容量を反映していないため、無視して構いません。

StorageSystem の作成中にノードを選択する際は、クラスター内のすべてのノードを選択しないようにしてください。 すべてのノードを選択すると、 nodeSelector を指定しない LocalVolumeSet （LVS）が作成されます。 今後クラスタに追加されるワーカーノードは、たとえストレージ用として意図されていないものであっても、ODFによって自動的に検出されます。 予期せず検出されたノードは、LVSから手動で削除する必要があります。 これを防ぐには、専用ストレージワーカープール内のノードのみを選択するか、 StorageSystem の作成前に、それらのノードに cluster.ocs.openshift.io/openshift-storage ラベルが付与されていることを確認してください。

クラスタのデフォルト StorageClass

ODFの導入後、通常は followingStorageClasses が作成されます：

• ocs-storagecluster-ceph-rbd:ブロックストレージ
• ocs-storagecluster-cephfs:ファイルストレージ
• ocs-storagecluster-ceph-rgw:オブジェクトストレージ

ワークロードが追加の設定なしで、ODF ベースの高性能な永続ブロックストレージを自動的に使用できるようにするには、デフォルトのストレージクラスとして「 Ceph RADOS ブロックデバイス (RBD) を使用する 」を選択するか、ODF アドオンのインストール後に、クラスタのデフォルトの StorageClass として「 RBD （ocs-storagecluster-ceph-rbd ）」を手動で設定してください。

1. RBDをデフォルトとしてマークする：

   oc patch storageclass ocs-storagecluster-ceph-rbd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
   

2. 必要に応じて、以前に設定したデフォルト設定から「default」を削除してください：

   oc patch storageclass <previous-default-name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
   

ODF設定チェックリスト

• クラスタに少なくとも1つのベアメタルサーバプールが含まれている
• Red Hat OpenShift バージョン 4.17 以降
• ODFアドオンとオペレータがインストールされ、実行されている
• ベアメタルサーバーには、十分な使用可能なローカルNVMeドライブがある
• 選択されたリソースプロファイルがノードの容量と一致する
• ODF ストレージクラスタは、最低 3 ノードで構成されます。マルチゾーンクラスタの場合は、3 の倍数（3、6、9、…）のノード数で構成する必要があります ゾーンのバランスを維持するため
• ODF参加ノードはすべてベアメタル
• RBD StorageClass を作成し、できればデフォルトに設定する
• ODFクラスタのステータスは「Ready」です（oc get storagecluster -n openshift-storage ）
• Cephのヘルス状態は HEALTH_OK です (oc -n openshift-storage rsh $(oc get pod -l app=rook-ceph-tools -o name) ceph status)

前提条件： Red Hat OpenShift 仮想化オペレーターをインストールする

IBM Cloud で Red Hat OpenShift の仮想化機能を使用する前に、 Red Hat OpenShift の Kubernetes Service クラスタに Red Hat OpenShift 仮想化オペレーターがインストールされていることを確認してください。

Red Hat OpenShift 仮想化オペレーターにより、 Kubernetes ネイティブの仮想マシンワークロード管理が可能になります。 また、必要なコントローラ、CRD、ストレージやネットワーキング・コンポーネントとの統合も提供する。

詳細は IBM Cloud の Red Hat OpenShift 仮想 化を参照。

仮想マシンのワークロードにODFストレージを使用する

Red Hat OpenShift Data Foundation (ODF) は、 Red Hat OpenShift 上で実行される仮想化ワークロードに、永続的なソフトウェア定義ストレージを提供する。 仮想マシンのストレージバックエンドとしてODFを使用する場合、パフォーマンス、安定性、および全機能の互換性を確保するためには、適切な StorageClass を選択することが極めて重要です。

以下の状況では、適切な StorageClass を指定する必要があります：

• 仮想サーバーが作成されます
• 仮想サーバーがインポートまたはクローンされます
• 仮想サーバーが、 Red Hat OpenShift Kubernetes Service クラスターへ移行されます

デフォルトの仮想化 StorageClass

Red Hat OpenShift Virtualization Operator がインストールされ、ODF クラスタが利用可能になると、仮想化ワークロード向けに最適化された StorageClass が自動的に作成されます

• ocs-storagecluster-ceph-rbd-virtualization

この StorageClass ：

• ランダムリード、ライト、持続的スループットなどのディスクI/Oパターンに合わせてチューニング
• 開始、停止、ライブマイグレーション、スナップショットなどの仮想化ライフサイクル操作で検証済み
• Red Hat OpenShift 仮想化環境は完全にサポートされており、本番環境での使用を推奨しています

ほとんどの場合、この StorageClass。

ライブマイグレーション・ストレージ要件

ライブマイグレーションは、稼働中の仮想マシンのワークロードを、ダウンタイムなしにワーカーノード間で移動させます。 ライブマイグレーションを成功させるためには、ソースノードとデスティネーションノードの両方から同時にストレージにアクセスできなければならない。 ライブマイグレーションを行うには、以下の設定が必要です。

• ReadWriteMany 仮想マシンのワークロードPVC上のアクセスモード。 Ceph RBDはブロックモードでRWXをサポートします。これはODF仮想化 StorageClass のデフォルト構成です。
• ocs-storagecluster-ceph-rbd-virtualization （ StorageClass ）には、RBDブロックモードによる ReadWriteMany のサポートが事前に設定されています。 この StorageClass を使用する仮想サーバーは、余分な設定なしに移行できる。
• 一般的な ocs-storagecluster-ceph-rbd StorageClass は、デフォルトで ReadWriteOnce アクセスモードを使用する。 RWO PVCを使用する仮想サーバーは、ライブマイグレーションを実行できません。 移行元ノードに接続したまま移行先ノードにPVCをマウントできないため、移行に失敗します。

ライブマイグレーションが必要な仮想サーバー用に customStorageClasses を作成する場合は、PVCが accessModes: [ReadWriteMany] および volumeMode: Block で作成されていることを確認してください。

ライブマイグレーションも必要だ：

• Red Hat OpenShift Virtualization Operator を適切な移行ポリシーで設定する
• デスティネーション・ノードで十分なCPUとメモリが利用可能であることを確認する

汎用RBDと比較した場合の仮想化特化 StorageClass

仮想マシンでは汎用の Ceph RBD（ StorageClass, ）を使用することも可能ですが、仮想化専用の StorageClass は、仮想マシンのワークロードディスク特有の I/O およびライフサイクルの特性に合わせて最適化されています。

汎用 RBD（ StorageClasses ）はコンテナワークロードには引き続き適していますが、本番の仮想化環境では、仮想化専用の StorageClass を使用することをお勧めします。

仮想化用のカスタム StorageClass の作成

シナリオによっては、特定のパフォーマンス、回復力、または容量要件を満たすために、カスタム StorageClass。

カスタム StorageClass 要件を作成するには、まずカスタム CephBlockPool を作成する必要があります。 カスタム・プールを作成する場合、プールに targetSizeRatio を設定する必要があります。 この設定がない場合、Cephのプレースメントグループ・オートスケーラーは、プールに対して1つのプレースメントグループのみを割り当てます。 この割り当てにより、すべてのI/Oが単一のOSDでボトルネックとなり、デフォルトのプールよりもパフォーマンスが低下します。

仮想化ワークロード用のカスタム StorageClass を作成する場合は、以下のパラメータが正しく構成されていることを確認します。

• プロビジョナー

  StorageClass では、ODFが提供するCeph RBD CSIプロビジョナーを使用する必要があります：

  openshift-storage.rbd.csi.ceph.com
  

  このプロビジョナは、ODFクラスタによってバックアップされるCeph RBDボリュームの動的プロビジョニングを可能にします。

• ストレージ・プール

  仮想マシ ンの ワー ク ロ ー ド デ ィ ス ク をバ ッ ク ア ッ プす る CephBlockPool を指定 し ます。 以下のいずれかのオプションを選択できます。

  • デフォルトのブロックプール。 ODFによって作成されるデフォルトの3ウェイ複製Cephブロックプール：

      ocs-storagecluster-cephblockpool
      ```
  
  - 特注のブロックプール。 ユーザー定義の CephBlockPool。 パフォーマンスの落とし穴を避けるために、プールには以下の設定を含める必要がある：
  
  ```yaml
        apiVersion: ceph.rook.io/v1
        kind: CephBlockPool
        metadata:
        name: my-custom-pool
        namespace: openshift-storage
       spec:
         failureDomain: zone          # Default for multi-zone clusters — data copies spread across zones; use host for single-zone flexible-scaling clusters
         deviceClass: ssd             # Match OSD device class
         enableCrushUpdates: true     # Keep CRUSH rules current on topology changes
         enableRBDStats: true         # Enable per-volume I/O monitoring
         replicated:
          size: 3
          requireSafeReplicaSize: true
              targetSizeRatio: 0.1       # CRITICAL — prevents 1-PG bottleneck
          ```
      The `targetSizeRatio` instructs the placement group autoscaler to proportionally preallocate placement groups based on the expected capacity share. Without it, the pool receives 1 PG and all I/O is funneled through a single OSD.
      
  

• 画像の特徴

  StorageClass には、ワークロードのパフォーマンスにとって重要なRBDイメージの特徴が含まれていなければならない：

  imageFeatures: layering,deep-flatten,exclusive-lock,object-map,fast-diff
  

  RBD画像の特徴とその目的

  特長	目的
  exclusive-lock	ライトバック・キャッシングとシングル・ライターの最適化を有効にする。 この機能がない場合、書き込みIOPSは最大で 7x。
  object-map	疎な画像に対して、割り当てられたオブジェクトのビットマップ追跡を可能にする。
  fast-diff	スナップショットの差分と DataVolume クローン操作を高速化し、起動時間を短縮します。
  deep-flatten	クローンを平らにした後、完全に独立させる。
  layering	DataVolume クローニングに必要なコピーオンライト・クローニングを有効にする。

• 地図オプション

  mapOptions: krbd:rxbounce
  

  このオプションは、Windows 仮想サーバーでカーネルの RBD ドライバーを使用する際に発生するデータ破損の問題を修正します。 互換性を確保するため、カーネルに対し、受信データに対してバウンスバッファを使用するよう強制します。 このオプションは、すべてのワークロードの StorageClasses で設定する必要があります。

• 完全なカスタム StorageClass の例

  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
    name: my-custom-virt-sc
  provisioner: openshift-storage.rbd.csi.ceph.com
  parameters:
    clusterID: <your-cluster-id>
    pool: my-custom-pool
    imageFormat: "2"
    imageFeatures: layering,deep-flatten,exclusive-lock,object-map,fast-diff
    mapOptions: krbd:rxbounce
    csi.storage.k8s.io/provisioner-secret-name: rook-csi-rbd-provisioner
    csi.storage.k8s.io/provisioner-secret-namespace: openshift-storage
    csi.storage.k8s.io/controller-expand-secret-name: rook-csi-rbd-provisioner
    csi.storage.k8s.io/controller-expand-secret-namespace: openshift-storage
    csi.storage.k8s.io/node-stage-secret-name: rook-csi-rbd-node
    csi.storage.k8s.io/node-stage-secret-namespace: openshift-storage
    csi.storage.k8s.io/fstype: ext4
  reclaimPolicy: Delete
  allowVolumeExpansion: true
  volumeBindingMode: Immediate
  

  クラスタの clusterID を見つけるには、以下のコマンドを実行します：

  oc get sc ocs-storagecluster-ceph-rbd -o jsonpath='{.parameters.clusterID}'
  

  イレイジャー符号化プール（開発者プレビュー版のみ）については、 「データ保護の概要」を 参照し、ECプールを指す dataPool を追加し、 pool はデフォルトのレプリケーションプールを指したままにしてください：

  parameters:
    pool: ocs-storagecluster-cephblockpool   # Replicated pool for metadata
    dataPool: my-ec-pool                      # EC pool for data blocks
  

圧縮

ODFは、Cephブロックプールで BlueStore インライン圧縮をサポートし、ディスクが使用する未加工ストレージを削減できる。 圧縮はOSDレイヤーで透過的に行われるため、仮想マシンのワークロードやそのゲストOSは、データが圧縮されていることに気づきません。

apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
  name: compressed-block-pool
  namespace: openshift-storage
spec:
  failureDomain: zone          # Default for multi-zone clusters; use host for single-zone flexible-scaling clusters
  deviceClass: ssd
  enableCrushUpdates: true
  enableRBDStats: true
  replicated:
    size: 3
    requireSafeReplicaSize: true
    targetSizeRatio: 0.1
  parameters:
    compression_mode: "aggressive"

暗号化

ODFは複数のレイヤーでデータアットレスト暗号化をサポートしており、個別に有効にすることができます。

• IBM Cloud インフラストラクチャの暗号化：物理NVMeドライブに対するフルディスク暗号化 - IBM Cloud によって管理されています。
• ODFクラスタ全体の暗号化：すべてのCeph OSDディスクは、dm-cryptを使用してデバイスレベルで暗号化されます。 ストレージクラスタのCRにある encryption.clusterWide: true を通じて有効化されます。 物理的なディスクの盗難から保護します。
• ODFのボリューム単位の暗号化：個々のRBDボリュームは LUKS2 で暗号化され、それぞれに独自のデータ暗号化キーが割り当てられます。 テナント間の分離と、きめ細かな鍵管理を実現します。

Red Hat OpenShift Kubernetes Service では、ODFは IBM Key Protect と統合され、クラスタ全体とボリュームごとの暗号化の両方の外部鍵管理サービスとして利用できる。 ボリュームごとの暗号化を有効にすると、ODFは自動的に -encrypted StorageClass のバリアント（たとえば ocs-storagecluster-ceph-rbd-encrypted ）を作成する。

NVMeベアメタル環境におけるCephのパフォーマンスチューニング

Cephのデフォルト設定は、一般的なワークロードに合わせて最適化されています。 以下のパラメータ値は、 mx2d.metal.96x768 のベアメタルプロファイルで検証されており、同プロファイル上の VM ディスクワークロードにおいて、IOPSを大幅に向上させ、レイテンシを低減します。 別のベアメタルプロファイルを使用している場合は、これらを参考として、ご使用のプロファイルにおけるNVMeドライブの数や利用可能なCPU数に応じて値を調整してください。

Ceph ツールボックス ポッドの ceph config set コマンドを使用して、各パラメータを適用します

TOOLS_POD=$(oc get pod -n openshift-storage -l app=rook-ceph-tools -o name)
# OSD memory and shard tuning
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd osd_memory_target 8589934592
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd osd_op_num_shards_ssd 16
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd osd_op_num_threads_per_shard_ssd 2
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd bluestore_prefer_deferred_size_ssd 0
# RocksDB tuning
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd rocksdb_write_buffer_size 268435456
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd rocksdb_max_write_buffer_number 16
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd rocksdb_max_background_jobs 12

適用後、設定が正常に反映されたことを確認してください：

oc exec -n openshift-storage ${TOOLS_POD} -- ceph config dump | grep -E "osd_memory_target|osd_op_num_shards|bluestore_prefer_deferred|rocksdb"

ceph config set の変更を行う場合、OSDポッドを再起動する必要はありません。 Cephは設定を動的に適用します。 ただし、 BlueStore によるキャッシュの変更（osd_memory_target ）は、各OSDポッドがリサイクルされて初めて完全に反映されます。 OSDポッドは、メンテナンス時間帯に、I/Oを中断することなく1つずつリサイクルすることができます。

ベンチマークの参考情報： 200台のVMと無制限のIOPSを備えた3ノードの mx2d.metal.96x768 クラスターでの内部テストの結果、16シャード、8 GBのOSDメモリ、および256 MBの RocksDB 書き込みバッファの組み合わせにより、約 194,000 IOPS および758 MB/sのスループットを達成したことが確認されました。 シャード数を8から16に増やすと、すべてのテスト構成において、IOPSの向上幅が常に最大となりました。

スナップショットベースのバックアップ

ODFは、Ceph RBDボリュームの Kubernetes VolumeSnapshots。 ディスクのスナップショットを取るには、以下のコマンドを使う：

oc apply -f - <<EOF
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-vm-snapshot
spec:
  volumeSnapshotClassName: ocs-storagecluster-rbdplugin-snapclass
  source:
    persistentVolumeClaimName: my-vm-data-disk
EOF

VolumeSnapshots コピー・オン・ライトで、ほぼ即座に作成できる。 これらを使用して、仮想マシンのワークロードを以前の状態に復元したり、ディスクをクローンしたりすることができます。 Red Hat OpenShift Virtualizationには、構成やすべてのディスクを含む仮想マシンのワークロードの状態全体を、1回の操作でキャプチャする組み込みの VM スナップショットおよび復元APIも備わっています。

アプリケーション一貫性スナップショットのための仮想マシンのワークロードの静止

実行中の仮想マシンのワークロードのスナップショットを撮影する際は、ディスク上のデータが一貫性のある状態である必要があります。 静止させることなく、スナップショットは、部分的に書き込まれたトランザクション、ダーティバッファ、インフライトI/Oなど、その瞬間にディスク上にあるものをすべてキャプチャする。 この処理により、クラッシュ一貫性のあるスナップショットが生成されますが、復元時にはアプリケーションレベルの復旧が必要になる場合があります。

アプリケーションの一貫性を保ったスナップショットを作成するには、スナップショット作成前にゲストファイルシステムをフリーズし、作成後にフリーズを解除してください。 Red Hat OpenShift の仮想化機能では、QEMUゲストエージェントを使用してこのプロセスを自動化します。

スナップショットコントローラがQEMUゲストエージェントを検出します。 スナップショットを撮影する前に、 guest-fsfreeze-freeze コマンドを実行して、すべてのファイルシステムのI/Oを停止させます。ファイルシステムが凍結されている間に、 VolumeSnapshot が取得されます。 スナップショットが完了したら、 guest-fsfreeze-thaw コマンドでI/Oを再開する。 スナップショットのステータスは、達成された一貫性レベルを示しています。 各ステータスの意味については、次の表をご覧ください。

すべての本番用VMについては、QEMUゲストエージェントのインストールが推奨されます。 Linux のゲストでは、次のコマンドを実行してください。

# RHEL / CentOS / Fedora
sudo dnf install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent
# Ubuntu / Debian
sudo apt-get install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent

Windows ゲストの場合は、QEMU ゲストエージェントサービスを含む VirtIO ドライバパッケージをインストールします。

アプリケーション向けのカスタムフリーズ／スローフック：ファイルシステムのフリーズに加えて、さらなるクワイエシングが必要なデータベースやその他のステートフルアプリケーションについては、ゲスト仮想マシンのワークロード内の /etc/qemu-ga/fsfreeze-hook.d/ にカスタムフックスクリプトを配置してください。 これらのスクリプトは、ファイルシステムが凍結される前に「 freeze 」引数とともに、またファイルシステムの凍結が解除された後に「 thaw 」引数とともに、ゲストエージェントによって自動的に実行されます。 フックの実行ログは /var/log/qga-fsfreeze-hook.log に書き込まれる。

例えば、次のような PostgreSQL フリーズフックを /etc/qemu-ga/fsfreeze-hook.d/postgresql.sh ：

#!/bin/bash
case "$1" in
  freeze)
    sudo -u postgres psql -c "SELECT pg_backup_start('snapshot');" 2>/dev/null || true
    ;;
  thaw)
    sudo -u postgres psql -c "SELECT pg_backup_stop();" 2>/dev/null || true
    ;;
esac

VMware 比較：この例は、アプリケーションの一貫性を保ったスナップショットを作成するために「 VMware Tools」で使用される、 VMware の「pre-freeze」および「post-thaw」スクリプトに類似しています。 QEMUのゲストエージェントは、スナップショット時のクワイエスシングにおいて、 VMware ツールと同じ役割を果たします。

ブロック・トラッキングの制限を変更

変更ブロック追跡（Changed Block Tracking）は、前回のバックアップ以降に変更されたブロックのみを特定することで、増分バックアップを可能にします。 VMware のVADP（ vStorage データ保護用API）は、この仕組みを利用して効率的な増分バックアップを実現しています。

CBTは、 Red Hat OpenShift 仮想化上のODFおよびCeph RBDでは利用できません。 現在のバックアップはフルスナップショットに依存しているため、バックアップウィンドウが長くなったり、ストレージ使用量が増加したりする可能性があります。

CBTの開発は複数のレベルで進行中である：

Ceph RBDは、スナップショット間の変更されたブロックを特定する基盤となる rbd diff の機能をサポートしていますが、この機能は現時点では Kubernetes のCSI Changed Block Tracking APIを通じて公開されていません。 フルスタック（CSI CBT API + Ceph CSIドライバサポート + KubeVirt 統合）が整うまでは、ブロックレベルでの増分バックアップは利用できない。

バックアップ・ソリューション

いくつかのバックアップベンダーは、現在のスナップショットベースのモデル内で動作する、 Red Hat OpenShift 仮想化向けのソリューションを提供しています：

• Veeam® Kasten： Kubernetes- Red Hat OpenShift ODFの仮想化サポートと増分スナップショット機能を備えたネイティブ・データ保護。 詳細については、 Veeam Kastenリファレンス・アーキテクチャを参照してください。
• Trilio for Kubernetes ： Red Hat OpenShift ODF統合による仮想化ワークロードのバックアップとリカバリ。 詳細については、 Trilio Red Hat OpenShift 仮想化サポートを参照してください。
• Red Hat OpenShift 仮想化をサポートする Veritas NetBackup: Enterprise バックアップ。 詳細については、以下を参照してください。 NetBackup- 包括的なエンタープライズデータ保護。

VMware マイグレーションに関する推奨事項

現在の VMware 環境がCBTベースの増分バックアップに依存している場合、以下の推奨事項を検討してください：

• フルスナップショットバックアップを計画する。 増分バックアップではなく、 VolumeSnapshots のフルバックアップに基づいて、バックアップウィンドウとストレージ要件を評価してください。
• Kubernetes ネイティブバックアップツールを評価する。 Veeam KastenおよびTrilioは、 Kubernetes および Red Hat OpenShift の仮想化環境向けに設計されており、現在のスナップショットモデル内で動作します。
• Cephのスナップショット効率を使用する。 Ceph RBDのスナップショットはコピー・オン・ライト方式を採用しており、スナップショット作成後は変更されたブロックのみを保存するため、フルコピーに比べてスナップショットの継続的な保存がより効率的になります。

ODFとCephの健全性を監視する

ODFストレージクラスタの定期的な監視は、可用性とパフォーマンスを維持するために不可欠です。 次のセクションでは、主要なコマンドとその出力について説明します。

TOOLS_POD=$(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name)
oc exec -n openshift-storage ${TOOLS_POD} -- ceph status

  cluster:
    id:     a1b2c3d4-...
    health: HEALTH_OK          ← What you want to see
  services:
    mon: 3 daemons             ← Should be 3 (quorum)
    mgr: 1 active              ← Manager daemon running
    osd: 24 osds: 24 up, 24 in ← All OSDs healthy (should match your NVMe count)
  data:
    pools:   4 pools, 353 pgs
    objects: 12.5k objects, 48 GiB
    usage:   152 GiB used, 69 TiB / 70 TiB avail   ← Cluster usage

oc exec -n openshift-storage ${TOOLS_POD} -- ceph health detail

oc exec -n openshift-storage ${TOOLS_POD} -- ceph osd tree

oc exec -n openshift-storage ${TOOLS_POD} -- ceph df

oc exec -n openshift-storage ${TOOLS_POD} -- ceph osd pool stats

ODFのアップグレード Red Hat OpenShift Kubernetes Service

IBM Cloud Red Hat OpenShift Data Foundation (ODF) アドオンは、同一のマイナーリリース内での z-stream の更新を自動的に適用します。 これらのアップデートは IBM Cloud を通して管理される。

ただし、メジャーバージョンおよびマイナーバージョンのアップグレード（例： 4.18 → 4.19 ）は自動的には行われません。 データの安全性とクラスタの安定性を確保するため、手動アップグレードの手順に従ってください。

Red Hat OpenShift Kubernetes Service クラスタ上でのODFのアップデートは、主に2つのフェーズで構成されます。

1. ODFワーカーノードをアップグレードまたは交換する。

   • ODFは、ストレージコンポーネントをホストする専用またはラベル付きのワーカーノードに依存している。
   • メジャーまたはマイナー・アップグレードの際には、これらのワーカー・ノードをアップグレードまたは交換して、ターゲットの Red Hat OpenShift とODFのバージョンに合わせる必要があります。
   • このプロセスは、ODFポッド（Ceph OSD、MON、マネージャなど）が正しく再スケジュールされ、データを失うことなく機能し続けることを保証するのに役立ちます。
   • ストレージの可用性を維持するため、この手順を開始する前に、十分な容量とノードの正常性を確認してください。

2. ODFアドオンを更新する。

   • ワーカーノードをアップグレードまたは交換した後、ODFアドオンを更新します。
   • このステップでは、ODFオペレータ、CSIドライバ、および関連コンポーネントをターゲットバージョンにアップグレードします。
   • アドオンの更新が完了すると、クラスタは自動的にODFリソースを調整し、必要な変更を適用します。

   アップグレード後の検証を実行し、以下を確認してください：

   • ODFとCephクラスタの健全性
   • StorageClasses 可用性
   • アプリケーションによるPVCの読み書きに成功

詳細については、 VPCクラスタでのODFの更新を 参照してください。

ODFストレージの拡張について Red Hat OpenShift Kubernetes Service

したがって、ワークロードの拡大やストレージ需要の増加に伴い、ストレージインフラストラクチャを拡張することが不可欠となります。 ODFの拡張は、実行中のアプリケーションを中断することなく、ストレージ容量を増やし、パフォーマンスを向上させ、回復力を維持することを可能にする重要な2日目の操作です。

IBM Cloud Red Hat OpenShift Kubernetes Service 環境では、拡張には通常、ストレージ・ワーカー・プールの拡張が伴う。 この操作は最小限のダウンタイムで実行されるため、ストレージクラスタのシームレスな拡張が可能になります。

1. VPCクラスターにワーカーノードを追加します。 ストレージクラスターが3つのアベイラビリティゾーンにまたがるマルチゾーンクラスターの場合、ゾーン間のバランスを維持するために、ワーカーノードを3の倍数（たとえば3、6、9など）で追加してください。 フレキシブルスケーリングが有効になっているシングルゾーンクラスターの場合、ノードを1つずつ追加することができます。

2. ノードを追加したら、それらをODFに登録してください。 クラスタ内のすべてのワーカーノードで ODF が実行されている場合、新しいノードはストレージトポロジーに自動的に追加されます。 ODFが一部のワーカーノードでのみ実行されている場合は、次の手順に進んでください。

3. クラスタ内のすべてのワーカーノードでODFが実行されている場合、新しいワーカーノードは自動的にODFストレージクラスタトポロジに追加されます。 ODFがワーカーノードの一部でのみ実行される場合は、 OcsCluster カスタムリソース内で、 <workerNodes> のプライベートパラメータを指定してください。 カスタムリソース定義を編集して、新しいワーカーノードの名前を ODF 配置に追加します。 「 OcsCluster 」カスタムリソースを次のように変更してください：

   • ocscluster を検索

     oc get ocscluster
     

   • ocscluster カスタムリソースファイルを編集し、新しいワークノードを追加する

     oc edit ocscluster <ocs cluster name> -o yaml
     

   • OcsCluster のカスタムリソースファイルを保存して、クラスターに再適用してください。

4. OcsCluster のカスタムリソースにある 'numOfOsd' の値を大きくすることで、OCSが新しく追加されたワーカーノードにODFコンポーネントをデプロイし、ストレージクラスター内に追加のOSDをプロビジョニングできるようになります。

   'numOfOsd' への調整は、ノードあたりの OSD ディスク数と、追加されたノード数の両方に依存します。 たとえば、各ノードにOSD専用として8台のNVMeディスクが搭載されている場合、ノードを3台追加すると 'numOfOsd' は8増加し、6台追加すると16増加します。

5. 次のコマンドを実行して、結果を確認してください：

   oc exec -n openshift-storage ${TOOLS_POD} -- ceph osd tree
   

6. 新しいワーカーノードが追加され、各ゾーンに均等に分散されていること（マルチゾーンクラスターの場合）、あるいは個別のホストバケットとして表示されていること（シングルゾーンのフレキシブルスケーリングクラスターの場合）、および各ノードに割り当てられた対応する数のOSDを確認してください。

詳細については、「 VPC クラスターにワーカーノードを追加して ODF を拡張する 」を参照してください。

柔軟なスケーリング

IBM Cloud のODFアドオンは、クラスタ構成に応じて異なるフェイルドメイントポロジーを使用します：

• マルチゾーンクラスター（3つのアベイラビリティゾーン）： 障害ドメインは「 zone 」に設定されています。 OSDは、ゾーン間のデータレプリケーションと高可用性を維持するため、3の倍数でプロビジョニングされ、ゾーンごとに1セットが割り当てられます。 ゾーンのバランスを保つためには、ストレージクラスタは3の倍数だけ拡張する必要があります。
• シングルゾーンのクラスター、またはアベイラビリティゾーンが3つ未満のクラスター： 柔軟なスケーリングが自動的に有効になります。 障害ドメインは「 host 」に設定されており、これは個々のノードがそれぞれ独立した障害ドメインであることを意味します。 ノードは1つずつ追加でき、ストレージをきめ細かく拡張できます。

ODF 4.21 以降、柔軟なスケーリング動作は、初期導入時にクラスタのトポロジに基づいて自動的に決定され、その後変更することはできません。

シングルゾーンまたはフレキシブル・スケーリングの展開環境では、 replica-3 プールは、任意の1台のホストが失われても稼働し続けます。 マルチゾーン展開では、 replica-3 プールは、ゾーン全体が失われた場合でも稼働し続けます。 ODFを本番環境で展開する前に、クラスタのトポロジーおよびそれに関連する耐障害性が、レジリエンス要件を満たしているかどうかを評価してください。

アドオンパラメータの全一覧およびコンソールを使用したインストール手順については、「 VPCクラスターへの OpenShift Data Foundationのデプロイ 」を参照してください。

ノード拡張時のパフォーマンス： フレキシブルスケーリング対応のODFクラスタにノードを追加すると、Cephのデータリバランスがトリガーされます。 以下で説明する内部テストでは、IOPSとスループットは安定していたものの、書き込みレイテンシが一時的に増加した。 50,000 IOPSの負荷下で、100台のVMを稼働させる3ノードのクラスタを用いた社内テストにおいて、以下の結果が得られました：

リバランスが完了すると、書き込みレイテンシは基準値に戻ります。 ワークロードが書き込みレイテンシの急上昇に敏感な場合は、 VM のアクティビティが低い時間帯にノードの追加を計画してください。