タグ: Ceph

同じデータを三つずつ保存する代わりに、細かく分けて復元用の情報を添えれば、必要な容量を減らせます。ただ、空き容量が増えることと、故障中も同じ速さで使い続けられることは別です。

分散ストレージのCephには、イレイジャーコーディング（Erasure Coding、EC）という保存方式があります。ここではデータ4断片と復元用2断片を組み合わせる「4＋2」を例に、三重複製との容量差、断片の置き場所、故障後に戻すまでの負担を、公式のTentacle系列の文書から読み解きます。4＋2は本記事の比較例であり、すべてのCeph環境の初期設定ではありません。^［1］

4＋2は、コピーを六つ作る方式ではない

三重複製では、同じデータのコピーを三つ持ちます。ECでは、元のデータをK個のデータ断片に分け、そこからM個の復元用断片を計算します。復元用断片は、元データをもう一度丸ごと保存したコピーではありません。失った部分を、残った断片と組み合わせて求めるための情報です。^{［1］ ［2］}

4＋2ならK＝4、M＝2です。符号化した断片の大きさをそろえると、保存する量は（4＋2）÷4＝1.5倍になります。たとえば論理データ1 TiBを保存する場合、符号化した断片の合計は理論上1.5 TiB、三重複製なら3 TiBです。これは圧縮や重複排除で中身を小さくした結果ではなく、故障に備える情報の持ち方による違いです。^［1］

この1.5 TiBを、そのまま購入すべきディスク容量にはできません。メタデータ、データ配置や復旧に残す空き容量、小さなオブジェクトの格納効率などは、別に見積もる必要があります。公式文書も、小さなファイルやオブジェクトが多い用途では、ECの実際の容量増加が大きくなり得ると注意しています。「利用できる容量が必ず2倍になる」と約束する数字ではありません。^［1］

二つ失っても戻せる、の「二つ」は何か

Cephでは、ディスク上のデータを扱うOSDという保存サービスへ断片を配置します。4＋2の構成で二つの断片を失っても復元できることと、どの二台のサーバーが止まってもよいことは、同じではありません。何台分が一緒に失われるかは、置き方で変わるからです。^［1］

たとえば六つの断片を六つのOSDへ置いていても、そのうち三つのOSDが同じホスト上にあれば、ホスト一台の故障で三断片を同時に失います。ディスクの本数だけを数えても、ホスト故障への備えは分かりません。これは配置条件を説明する仮の例です。

そこで使うのが、Cephの配置規則であるCRUSHの「障害ドメイン」です。障害ドメインをホストにすれば、同じデータを構成する断片を別々のホストへ分ける規則を作れます。ラック全体の停止を考えるなら、ラック単位に分ける規則と、それを満たす台数・構成が必要です。公式文書のラック配置例も、同じラックに二つの断片を置かない規則を示しています。^［1］

通常の4＋2配置では、少なくとも六つの障害ドメインが必要になります。公式文書は、K＋M個ちょうどより、さらに一つ多い障害ドメインを用意する運用上の利点にも触れています。容量表を作る段階で、復旧先となる場所と空き容量を合わせて考える理由です。ホスト間に分けた配置を、ラック間にも分かれていると読み替えてはいけません。^［1］

復元できても、読み書きを進めるとは限らない

ここで二つの条件を分けます。一つは、元のデータを再構成するために必要な断片数。もう一つは、利用者の読み書きを進めるために、Cephが最低限そろえる断片数です。

公式文書では、Octopus以降のECプールは、少なくともK個の断片が利用できれば復旧を進められると説明しています。一方、min_sizeは、データ配置の管理単位であるPGが動作し、I/Oを進めるために必要な最小の稼働断片数です。CephはECでKより大きい値を勧めています。K個しか残っていない状態でさらに断片を永久に失うと、復元に必要な情報が足りなくなるためです。^{［1］ ［3］}

4＋2でmin_size=5と設定した例なら、断片が四つ残っていても、読み書きを進めるための本数には届きません。再構成が可能なことだけを理由に、通常どおりサービスが続くとは言えないのです。

この区別は、保守時の判断にも関わります。「あと二つ失ってもデータは戻せる」という説明だけで、二つの障害ドメインを同時に止めてよいとは判断できません。現在の断片の状態とmin_sizeを確かめ、データを守れる範囲とサービスを続けられる範囲を別々に見ます。

節約した容量の代わりに、復旧では何をするのか

三重複製でコピーを失った場合は、残ったコピーから不足分を作れます。ECで断片を失った場合は、残った断片を読み、計算で再構成し、新しい断片を書き込みます。公式文書は、この読み取り・再構成・書き込みを復旧の処理として説明し、とくにHDDを使う場合や復旧・再配置の最中に性能との引き換えがあるとしています。^［1］

たとえば、長く保管する大きなデータが中心なら、平常時の容量差は魅力になります。それでもホスト一台を失った後には、残る機器が通常の要求に加えて復旧の読み取りや通信を受け持ちます。ここで確かめたいのは、空き容量が足りるかだけでなく、復旧中のアプリケーションの待ち時間と、冗長性が戻るまでの時間です。この評価の進め方は処理の仕組みから導くもので、本記事で測った結果ではありません。

Kを増やすと、同じMに対する容量の割合は小さくなります。しかし、配置に必要な障害ドメインも増え、性能への影響も変わります。容量効率の数字だけを最小にするのではなく、実際の読み書きと故障復旧を同じ条件で比べる必要があります。^［1］

小さな更新とメタデータには、別の条件がある

Cephの保存領域はプールという単位で方式を選びます。ECプールは、初期状態ではオブジェクト全体の書き込みや追記を扱います。一部だけを書き換えるには、BlueStoreという保存方式のOSDを使い、allow_ec_overwritesを有効にする条件があります。これによって、仮想ディスクを扱うRBDや、ファイルを扱うCephFSのデータにもECを使えるようになります。^［1］

ただし、ECプールはキーと値の情報を持つomapに対応していません。RBDやCephFSでは、データをECプールに置いても、メタデータは複製プールに残します。「保存領域を全部4＋2へ変える」という一括の計算では、この役割分担を見落とします。^［1］

Tentacle系列には、これとは別にallow_ec_optimizationsがあります。小さなI/Oの性能を改善し、容量を埋め合わせるパディングをなくす最適化ですが、一部上書きの許可と同じ設定ではありません。すべてのMON（クラスタ状態を管理するサービス）とOSDがTentacle以降であることに加え、対象のプラグインと符号化方式にも条件があり、有効にした後は無効へ戻せません。公式文書が挙げる対象はJerasure／ISA-Lのreed_sol_van方式です。^［1］

1ストライプあたり各データ断片へ割り当てる量を決めるstripe_unitも、読み書きの性質に関わります。最適化を使う場合、値を大きくすると小さな読み取りに利点がある一方、小さな連続書き込みには不利になると説明されています。この値はプール作成後には変更できません。既存プールへ最適化を有効にすれば、どの仕事も同じように速くなる、とは読まないようにします。^{［1］ ［2］}

容量、故障の範囲、戻るまでの負荷を一組で比べる

方式を選ぶなら、まず保存するデータの大きさと、一回の読み書きの大きさを分けて捉えます。大きなファイルでも、その一部を細かく更新する仕事はあります。次に、守りたい故障の単位に合わせて断片の配置を考え、min_sizeを含む停止条件を確認します。最後に、代表的な負荷をかけた平常時と復旧中で、必要容量・応答時間・復旧時間を比べます。

4＋2の1.5倍という計算は、この比較の出発点です。容量の利点を生かせるのは、減らした複製の代わりに必要になる配置と再構成の仕事まで、運用の中へ織り込めたときです。

参考資料

2026年10月12日確認。Ceph公式のTentacle系列の文書に基づく方式の解説です。容量と断片数の表は条件を示す計算例で、実機の性能試験ではありません。

1. Ceph authors and contributors, Erasure code。Erasure-code profiles、Erasure Coding with Overwrites、Erasure Coding Optimizations、Erasure-coded pool overhead、Erasure-coded pool recovery。
2. Ceph authors and contributors, Erasure code profiles。K・Mの定義とstripe_unit。
3. Ceph authors and contributors, Pools。Setting Pool Valuesのmin_size、allow_ec_overwrites、allow_ec_optimizations。