LASSIC Media らしくメディア
Cephで分散ストレージ基盤を外注構築
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- Cephはブロック・オブジェクト・ファイルを1つの基盤(RADOS)で提供する分散ストレージのOSSです。
- OSD・MON・MGRの役割分担とCRUSHアルゴリズムによる自己修復の仕組みを整理します。
- MinIOやSANとの違い、構築を外注する場合の判断軸を解説します。
目次
Cephとは何か—RADOSが支える統合ストレージ
Ceph（セフ）とは、ブロック・オブジェクト・ファイルの3種類のストレージを単一の基盤で提供する、オープンソースの分散ストレージシステムを指します*1。中核となるのはRADOS（Reliable Autonomic Distributed Object Store）と呼ばれる分散オブジェクトストレージサービスで、各ノードが持つ処理能力を活用して信頼性を確保する設計です*1。
Ceph公式ドキュメントは「Cephはユニークに、オブジェクト・ブロック・ファイルストレージを単一のシステムで提供する」と説明しています*1。ブロックストレージのRBD（RADOS Block Device）、オブジェクトストレージのRGW（RADOS Gateway）、ファイルストレージのCephFSは、いずれもRADOSという同一基盤の上に構築されたクライアントインターフェースです*1。個別の用途ごとにストレージ製品を分けて調達するのではなく、1つのクラスタで複数の用途に応じたインターフェースを提供できる点が、Cephを検討する際の起点となります。
OSD・MON・MGR・MDS—クラスタを支える4種のデーモン
Cephクラスタは複数の種類のデーモン（常駐プロセス）が協調して動作します。それぞれの役割を理解することが、構築や運用設計の前提になります。
OSD（Object Storage Daemon）は、実際のデータを格納するデーモンです*1。Ceph公式ドキュメントは「Ceph OSDデーモンは自身の状態と他のOSDの状態をチェックし、モニターに報告する」と説明しており*1、単純にデータを保管するだけでなく、自身と周囲のOSDの健全性を監視する機能を持ちます。通常、物理ディスク1台につき1つのOSDプロセスが対応します。
MON（Monitor）は、クラスタマップという構成情報の正本を保持するデーモンです*1。公式ドキュメントでは「モニターはクラスタマップの正本を保持し、Cephクライアントに提供する」とされています*1。単一のMONは単一障害点になるため、本番クラスタでは最低3台のMONを稼働させることが推奨されています*2。MON間の合意形成にはPaxosという分散合意アルゴリズムが使われ、過半数のMONが応答可能な状態（クォーラム）でなければクラスタマップは更新されません*2。この性質から、MONは3・5・7台など奇数構成が基本になります*2。
MGR（Manager）は、監視・オーケストレーション・プラグインモジュールのエンドポイントとして機能します*1。ダッシュボードや外部監視ツールとの連携、クラスタ状態の集計といった役割を担い、MONの負荷を切り離す位置づけです。MDS（Metadata Server）はCephFSを利用する場合にのみ必要なデーモンで、ファイルのメタデータ管理を専任します*1。メタデータはデータ本体とは別のRADOSプールに保存され、MDSクラスタ自体もスケール可能な構成になっています*3。
RBD・RGW・CephFS—3つのアクセス方式の違い
Cephを構築する際は、どのアクセス方式を主に使うかで設計が変わります。3方式はいずれもRADOSを基盤にしますが、クライアントから見た性質は異なります。
RBD（RADOS Block Device）は、ブロックデバイスのイメージを複数のオブジェクトにストライピング（分割配置）して保存する方式です*1。仮想マシンのディスクイメージやコンテナのボリュームなど、OS側でファイルシステムを載せる用途に向きます。
RGW（RADOS Gateway、Ceph Object Gateway）は、librados（RADOSにアクセスするライブラリ）の上に構築されたHTTPサーバーで、Amazon S3 REST APIの大部分と互換性を持つインターフェースを提供します*4。S3互換APIとSwift APIが同一の名前空間を共有するため、一方のAPIで書き込んだオブジェクトを他方のAPIから読み取ることもできます*4。アプリケーションからS3互換のオブジェクト操作を行いたい場合に適した方式です。
CephFS（Ceph File System）は、RADOSの上に構築されたPOSIX準拠の分散ファイルシステムです*3。ファイルのメタデータをデータ本体と別のRADOSプールに保存し、MDSクラスタが分散メタデータキャッシュの権限を協調的に維持する設計になっています*3。複数クライアントから共有ファイルシステムとして同時にマウントする用途に使われます。3方式は排他的ではなく、同一クラスタ内でRBD・RGW・CephFSを併用する構成も可能です。
CRUSHアルゴリズムとデータ複製・Erasure Codingの仕組み
Cephとは、データの配置先を中央管理サーバーに問い合わせるのではなく、クライアントとOSDがそれぞれ計算して導き出す点に大きな特徴があります*1。この計算を担うのがCRUSH（Controlled Replication Under Scalable Hashing）というアルゴリズムです。
CRUSHは「クラスタのマップ（CRUSHマップ）を使ってデータをOSDにマッピングし、設定された複製ポリシーと障害ドメインに従ってクラスタ全体にデータを分散させる」と説明されています*5。CRUSHマップにはOSDの一覧と、host・rackといった階層構造（バケット）、複製ルールが含まれます*5。物理的な設置構成をマップに反映させることで、同一ラックの複数ディスクが同時に故障するような相関障害にも対応できる設計です*5。
データ保護の方式には、レプリケーションとErasure Coding（消失訂正符号、EC）の2種類があります。レプリケーションは同一データを複数コピー保持する方式で、少なくとも2つのコピー(size=2)を基本としつつ、3つのコピー(replication with three copies)が推奨されています*6。ECはデータをK個のデータチャンクとM個のコーディングチャンクに分割して保存する方式です*7。M個は「クラスタから失われても損失にならないOSD数」に相当し*7、既定のk=2・m=2構成では、3倍の容量を要するレプリケーション(size=3)に対して1倍の容量で同等の�、障害耐性を確保できるとされています*7。一方でECには性能面のトレードオフがあり、特にHDD使用時やクラスタのリカバリ時に影響が出やすいとされています*7。容量効率を優先するか、復旧性能を優先するかで方式を選ぶ必要があります。
自己修復とスケールアウト—障害にどう対応するか
Cephは、OSDが自律的(autonomous)かつ自己修復的(self-healing)に振る舞うことを前提に設計されています*1。公式ドキュメントは「各Ceph OSDデーモンは、クラスタ内の他のOSDデーモンを認識しており、これによりOSDデーモン同士が直接やり取りできる」と述べています*1。中央の調整役を経由しないことで、クライアントはOSDと直接通信でき、ボトルネックが生じにくい構成になります*1。
OSDはハートビートによる相互監視、ピアリング、リバランシング、データのスクラビング(整合性検査)を自動的に実行し、障害の検出と復旧につなげます*1。新しいOSDを追加すると、CRUSHマップ上のhostバケットに自動的に登録される仕組みも用意されています*5。ディスクやノードを追加していくことでクラスタ全体の容量・性能を線形に拡張できるのが、スケールアウト型ストレージとしてのCephの基本的な振る舞いです。ただし、リバランスや復旧の詳細な挙動はプールの設定やクラスタ規模によって変わるため、実運用では監視体制を含めた設計が欠かせません。
構築に必要なハードウェア要件
Cephを構築する際は、デーモンの種類ごとに求められるリソースが異なります。公式ドキュメントが示す推奨事項を整理すると、次のようになります*8。
| 項目 | 推奨事項 |
|---|---|
| OSD用CPU | HDDでは1OSDあたり最小1スレッド(推奨3スレッド)。NVMe SSDでは4〜6スレッドが目安です*8。 |
| MON/MGR用CPU | 最小2コア。OSDに比べ軽量な要件です*8。 |
| OSD用RAM | 既定で1デーモンあたり4GB。サーバー全体では「OSD数×osd_memory_target×2」以上を目安にします*8。 |
| MON/MGR用RAM | 小規模クラスタで32GB、300OSD規模で64GB、それ以上では128GBが目安です*8。 |
| OSD用ストレージ | 1台あたり最小1TiBを推奨。OS用・OSD用・BlueStoreのWAL/DB用を分離する構成が推奨されます*8。 |
| ネットワーク | 最小1Gb/s。実運用では25Gb/s以上、高密度ノードでは100Gb/s以上が推奨されます*8。 |
HDDをOSDに使う場合、WAL/DBをSSDやNVMeにオフロードする構成も選択肢になります。公式ドキュメントでは、SATA SSD1台あたりHDD OSD4〜5台、NVMe SSD1台あたりHDD OSD15台程度を目安とする記載があります*8。ノード数・OSD数が増えるほどMON/MGRに必要なメモリも段階的に増えるため、将来の拡張を見込んだ設計が必要です。
MinIO・SANとの違い—どのストレージを選ぶか
分散ストレージを検討する際、MinIOのようなS3互換オブジェクトストレージや、従来型のSAN(Storage Area Network)と何が違うのかが論点になりやすいポイントです。
MinIOはS3互換のオブジェクトストレージに機能を絞ったソフトウェアで、単一のアクセス方式（オブジェクト）に最適化されています。一方Cephは、RADOSという共通基盤の上でRBD(ブロック)・RGW(オブジェクト)・CephFS(ファイル)の3方式を同一クラスタで提供する統合型の設計です*1。ブロックデバイスと共有ファイルシステム、オブジェクトストレージを別々の製品で構築・運用する必要がなく、1つのクラスタ管理体制に集約できる点がCephの位置づけです。
SANは専用のストレージ筐体とファイバーチャネル等の専用ネットワークで構成される、集中型のブロックストレージ基盤です。特定の筐体・コントローラに処理が集約されるため、安定した性能を出しやすい一方、拡張は筐体単位の追加やアップグレードが基本になります。Cephはコモディティサーバーを束ねてOSDを追加していくスケールアウト型で、CRUSHアルゴリズムによって中央のコントローラを介さずにデータ配置を決定します*1。特定機種への依存を避け、ノード追加で容量・性能を積み上げていく運用に向いた設計です。
どちらが優れているかは一概には言えず、単一用途に特化した性能や運用のシンプルさを取るか、統合基盤としての拡張性・可用性を取るかという判断軸になります。可用性を重視する大規模環境や、ブロック・オブジェクト・ファイルの複数用途を1つの基盤で満たしたい場合に、Cephが選択肢に入ってきます。
外注と内製の判断軸
Cephの構築そのものはオープンソースソフトウェアとして公開されており、ハードウェアとネットワークを用意すれば導入は可能です。ただし、実運用に乗せるまでには複数の専門知識が必要になります。MON・MGR・OSD・MDSといったデーモンの配置設計、CRUSHマップの障害ドメイン設計、レプリケーションかErasure Codingかの選定、ネットワーク帯域の確保など、検討事項は一つひとつが運用の安定性に直結します。
内製で構築・運用する場合には、分散システムの設計知識に加えて、日々の監視・障害対応・バージョンアップ対応を担う体制が欠かせません。MONの過半数割れやOSDの相次ぐ故障といった事態が起きた際に、CRUSHマップやプール設定を理解した上で対応できる人員を確保できるかが、内製の実現性を左右します。設計を誤ると、リバランス時の性能劣化やデータ配置の偏りといった問題が長期化するおそれもあります。
外部の専門パートナーに構築を委ねる場合は、要件定義の段階でアクセス方式(RBD/RGW/CephFS)の優先順位、想定容量、可用性要件を明確にした上で、ハードウェア選定からCRUSHマップ設計、監視体制の構築までを一貫して依頼できます。構築後の運用保守を含めて委託することで、専門知識を持つ人員を自社で抱え続けるコストと、障害時の対応スピードを比較検討できるようになります。自社の要件と体制を踏まえ、どこまでを内製化し、どこから外部に委ねるかを整理することが、Ceph導入を検討する際の実務的な出発点になります。
まとめ：Ceph導入で押さえるべき3つの視点
本稿ではCephの基本構造と、統合ストレージとしての特徴を整理しました。要点を3つに集約すると次の通りです。第一に、CephはRADOSを基盤にRBD・RGW・CephFSの3方式を1つのクラスタで提供する統合型の分散ストレージです*1。第二に、CRUSHアルゴリズムとOSD・MON・MGRの自律的な動作により、中央集約なしでのスケールアウトと自己修復を実現しています*1。第三に、MinIOやSANとは用途・規模の前提が異なり、構築・運用には専門知識を要するため、内製と外注のどちらが自社に合うかを要件定義の段階で見極める必要があります。
よくある質問
CephとMinIOはどちらを選ぶべきですか。
用途によって異なります。オブジェクトストレージのみで十分な場合はMinIOのようなS3互換ストレージが構成をシンプルにできます。ブロック・ファイル・オブジェクトを1つの基盤にまとめたい場合や、大規模・可用性重視の環境では、RADOSを基盤に3方式を統合するCephが選択肢になります*1。
Cephクラスタは最小どのくらいの規模から構築できますか。
MONは本番運用で最低3台の稼働が推奨されており*2、OSDもレプリケーションやErasure Codingの構成によって必要台数が変わります。小規模な検証環境と、可用性を確保した本番環境とでは求められる台数が異なるため、用途に応じた設計が必要です。
Erasure Codingとレプリケーションはどちらが良いですか。
単純な優劣ではなく、容量効率と性能特性のトレードオフです。Erasure Codingは同等の耐障害性をより少ない容量で実現できますが*7、特にHDD使用時やリカバリ時に性能面の影響が出やすいとされています*7。読み書きの頻度や復旧時間の許容度に応じて選ぶ必要があります。
CephFSはどのような用途に向いていますか。
CephFSはPOSIX準拠の分散ファイルシステムで、複数クライアントから同一のファイルシステムを共有マウントする用途に向いています*3。メタデータはMDSクラスタが管理し、データ本体と別のRADOSプールに保存されます*3。
Cephの構築を外注する場合、何を先に決めておくべきですか。
まずRBD・RGW・CephFSのどの方式を主に使うか、想定するデータ容量と可用性要件を整理することが出発点になります。これらが明確であれば、ハードウェア選定やCRUSHマップの障害ドメイン設計、レプリケーション方式の選定を委託先と具体的に検討できます。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Ceph「Architecture — Ceph Documentation」https://docs.ceph.com/en/latest/architecture/
- *2 出典：Ceph「Monitor Config Reference — Ceph Documentation」https://docs.ceph.com/en/latest/rados/configuration/mon-config-ref/
- *3 出典：Ceph「CephFS — Ceph Documentation」https://docs.ceph.com/en/latest/cephfs/
- *4 出典：Ceph「Ceph Object Gateway — Ceph Documentation」https://docs.ceph.com/en/latest/radosgw/
- *5 出典：Ceph「CRUSH Maps — Ceph Documentation」https://docs.ceph.com/en/latest/rados/operations/crush-map/
- *6 出典：Ceph「Architecture — Ceph Documentation」（レプリケーションに関する記載）https://docs.ceph.com/en/latest/architecture/
- *7 出典：Ceph「Erasure Coding — Ceph Documentation」https://docs.ceph.com/en/latest/rados/operations/erasure-code/
- *8 出典：Ceph「Hardware Recommendations — Ceph Documentation」https://docs.ceph.com/en/latest/start/hardware-recommendations/
