データベース

Cephとは?RADOSとCRUSHの仕組みとcephadmでの構築手順、S3互換をオンプレで建てる判断を解説

Cephとは?RADOSとCRUSHの仕組みとcephadmでの構築手順、S3互換をオンプレで建てる判断を解説

Cephは、汎用のx86サーバやarm64サーバに載せたディスクを束ね、ブロック・ファイル・S3互換オブジェクトの3種類を1つのクラスタから払い出すオープンソースの分散ストレージです。この記事では2026年10月時点のTentacle 20.2系を前提に、RADOSとCRUSHによるデータ配置の仕組み、cephadmで3ノードのクラスタを建てる手順とOSDが作られないときの原因、レプリカ数の決め方、RGWでS3互換のエンドポイントをオンプレミスに建てる手順を順に追います。最後に、MinIOやRook、Proxmox VE、クラウドのマネージドストレージとどう選び分けるかを言い切ります。

まとめ:Cephは1つのRADOSクラスタからブロックとファイルとS3を出す分散基盤

Cephの中心はRADOSという分散オブジェクトストアです。ブロックデバイスのRBD、POSIX互換ファイルシステムのCephFS、S3互換のRGWは、いずれもRADOSの上に載った「入口」にすぎません。データをどのディスクに置くかはCRUSHというアルゴリズムが計算するため、中央の索引サーバがボトルネックになりません。

2026年10月21日時点で保守されている系列はTentacle(20.2系)とSquid(19.2系)の2つで、Squidの推定EOLは2026年10月31日です。これから建てるならTentacle一択と判断してください。

採用してよいのは、ブロック・ファイル・オブジェクトのうち2種類以上を同じ基盤で賄いたく、OSD用の空きディスクを持つサーバを3台以上確保でき、Cephの挙動を読める担当者を置けるときです。S3互換のエンドポイントだけが欲しい、あるいはブロックだけで足りるなら、Cephは過剰になります。

Cephの定義とRADOS・CRUSH・配置グループで成り立つデータ配置の仕組み

まず、Cephがデータをどう受け取り、どこへ置いているのかを押さえます。障害時にどのログを読むかは、この構造の理解で決まります。

RADOSの上にRBD・CephFS・RGWの3つの入口が載るCephの全体構造

公式のアーキテクチャ解説は、RADOSを「すべてのCephサービスの下にあるオブジェクトストア」と位置づけています。その上にlibradosというライブラリがあり、さらに上でRBD・CephFS・RGWが動く三層の構造です。アプリケーションがどの入口から書き込んでも、最終的にはRADOSのオブジェクトとしてディスクに収まります。

この構造の利点は、容量の器が1つで済む点にあります。仮想マシンのディスクはRBD、部署共有のファイルはCephFS、ログやバックアップはRGWと用途を分けても、裏のディスクプールは共通です。RAIDによるディスク冗長化が1台のサーバの中で完結するのに対し、Cephはサーバをまたいで複製を持つため、筐体ごと止まってもデータを読み続けられます。

ライセンスはGitHubのREADMEによると、大部分がLGPL 2.1または3.0のデュアルライセンスです。社内基盤として使う分には、ライセンス料は発生しません。

CRUSHアルゴリズムが中央の索引なしで格納先OSDを計算する仕組み

分散ストレージの多くは「どのデータがどこにあるか」を記録した索引サーバを持ちます。Cephは持ちません。CRUSHマップの公式解説は、CRUSHが格納先を計算で決め、クライアントは中央のサーバやブローカーを介さずにOSDと直接通信すると説明しています。

計算の途中には配置グループ(PG)という中間単位が挟まります。オブジェクトはまずPGに割り振られ、PGがCRUSHの規則に従って複数のOSDへ割り当てられる流れです。OSDを足したり外したりすると、動くのはPG単位なので、全データを並べ替える必要はありません。

OSDは既定で、動いているノード名を持つhostバケットの下に登録されます。障害ドメインをhostにしておけば、複製の配置先は必ず別々のホストです。ラックや電源系統をまたぎたい規模になったら、ここを広げる設計に切り替えます。

mon・mgr・OSD・MDS・RGWの5種類のデーモンが担う役割と台数の目安

Cephクラスタは役割の違うデーモンの集まりです。設計時に台数を決める対象は次の5種類になります。

デーモン 役割 配置の目安
mon クラスタマップを保持し多数決で一貫性を保つ 3台か5台の奇数
mgr メトリクス収集とダッシュボード・オーケストレータ 現用と待機の2台
OSD ディスク1本ごとに動きデータ本体を保持 ディスク本数と同数
MDS CephFSのメタデータ処理 CephFSを使うときだけ
RGW S3・Swift互換のHTTPゲートウェイ RGWを使うときだけ複数

優先して設計すべきはmonとOSDです。monが過半数を失うとクラスタ全体が書き込みを止めるため、2台構成では1台の停止で詰みます。OSDはディスク本数に比例して増え、復旧時にはCPUとネットワークを大きく使います。

Cephのバージョン系列と保守期限から決める2026年10月時点の採用版

Cephは系列ごとに保守期限が切られています。一度建てると数年動かす基盤なので、どの系列から始めるかは最初に決めます。

Tentacle 20.2系とSquid 19.2系の保守期限と新規構築で選ぶ系列

公式のリリース一覧では、2026年10月21日時点で保守中の系列を次のように示しています。

系列 版 最新の修正版 EOL
Tentacle 20.2系 20.2.4 2027年6月1日(推定)
Squid 19.2系 19.2.7 2026年10月31日(推定)
Reef 18.2系 18.2.8 2026年3月20日に終了

Squidは残り10日で期限を迎えるため、新規構築の候補から外れます。Reefで動いている既存クラスタは、すでに修正が届かない状態です。Squidを経由してTentacleへ上げる計画を急いでください。

Tentacleの推定EOLも2027年6月1日で、残りは8か月弱です。Cephは毎年メジャー系列が出て、2系列だけが保守される運用です。年1回の系列更新を最初から運用計画と予算に入れておく必要があります。

cephadmでCephクラスタを3ノードに構築する検証環境の作業手順

ここからは手を動かします。現行の標準的な構築ツールはcephadmで、デーモンをコンテナとして動かし、2台目以降の操作もすべてceph orchコマンドから行います。

cephadmの前提条件とbootstrapで1台目にmonとmgrを立てる手順

cephadmのインストール手順が挙げる要件は、Python 3、Systemd、PodmanかDocker、chronyなどの時刻同期、LVM2の5つです。時刻がずれるとmon同士の合意が崩れるため、時刻同期は検証環境でも省かないでください。

# Ubuntu の場合(CentOS Stream は centos-release-ceph-tentacle を先に入れる)
apt install -y cephadm

# 1台目でクラスタを初期化する(IPは1台目のアドレス)
cephadm bootstrap --mon-ip 10.10.0.101

# 状態を確認する
cephadm shell -- ceph -s

bootstrapを実行すると、1台目にmonとmgrが立ち上がり、クラスタ用のSSH鍵、/etc/ceph/ceph.pub、最小構成のceph.conf、管理者用のキーリングが書き出されます。1台目には_adminラベルも付き、ここが以後の管理端末になります。

ホスト追加とOSD作成でつまずく未使用デバイスの判定に必要な6条件

2台目以降は、bootstrapで書き出された公開鍵を新ホストのrootのauthorized_keysに入れてから登録します。ホスト管理の手順にある構文で、IPを添えて追加します。

# ホストを追加する
ceph orch host add host2 10.10.0.102
ceph orch host add host3 10.10.0.103

# OSDに使えるデバイスを確認し、使えるものを全部OSDにする
ceph orch device ls
ceph orch apply osd --all-available-devices

# 検証で使ったディスクを再利用するときだけ消去する(データは戻らない)
ceph orch device zap host2 /dev/sdb --force

構築初日に最も多い詰まり方が「OSDが1つもできない」です。OSDサービスの公式解説によると、デバイスが使えると判定されるのは、パーティションがない、LVMの状態がない、マウントされていない、ファイルシステムがない、BlueStoreのOSDが残っていない、5GiB以上ある、の6条件をすべて満たすときに限られます。OSのインストーラが自動でパーティションを切ったディスクは弾かれるため、サーバ調達の段階で「OSD用に未使用のディスクを1台あたりN本」と仕様に書き込んでおくのが確実です。

プール設計とレプリカ数の決め方、本番で避けるsizeとmin_sizeの設定値

クラスタが立ったら、データの入れ物であるプールを作ります。ここで決める複製数が、容量の見積もりと障害時の振る舞いを同時に縛ります。

既定の3レプリカと障害ドメインhostから逆算するノード台数と実容量

プール運用の公式解説によると、Cephは既定で3つの複製を持ちます。障害ドメインがhostなら3つの複製は別々のホストへ置かれるので、OSDを持つホストは最低3台必要です。

実容量は素直に3分の1になります。100TBのディスクを並べても、預けられるデータは約33TBです。しかもOSDが満杯に近づくとCephは書き込みを止めるため、運用上は使用率に余白を残します。3台構成では、1台が止まっても3つ目の複製を作り直す別ホストがなく、冗長が欠けたまま復旧を待つしかありません。4台以上なら残りのホストで複製を作り直せますが、そのぶんの空き容量が要ります。使用率を高く保ったまま1台を失うと、作り直しで残りのOSDがあふれて書き込みが止まる、という事故につながります。

Proxmox VEのCeph統合ガイドも、3ノード以上かつOSD 12本以上を各ノードへ均等に配る構成を推奨しています。3台は動く最小値であって、余裕のある本番値ではありません。

size 2やmin_size 1を本番で避ける理由とイレージャーコーディングの使い所

容量を稼ぐために複製数を2に落としたくなる場面があります。公式ドキュメントは、本番でsizeを2、またはmin_sizeを1にするとデータ損失の危険があり、緊急時に一時的に限るべきだと明記しています。min_sizeはPGが読み書きを受け付けるのに必要な最低限の複製数です。1にすると、複製が1つしか残っていない状態でも書き込みを受け付け、そのディスクが壊れた時点で書いた内容が消えます。

容量効率を上げたいなら、複製数を削るのではなくイレージャーコーディングを選びます。データをK個の断片とM個のパリティに分ける方式で、複製より少ない容量で同じ程度の耐障害性を得られます。ただし書き込みの遅延と復旧時のCPU負荷が上がるため、データベースのような遅延に敏感な処理には向きません。RGWに入れるバックアップやログのように、大きなファイルをまとめて書く用途で使うのが合っています。

オンプレでS3互換を建てるRGWの構築手順とS3 API互換範囲の確認

クラウドに出せないデータを、S3と同じAPIでオンプレミスに置きたい。この要件をCephではゲートウェイの追加で満たします。

ceph orch apply rgwでゲートウェイを立てS3ユーザーを発行する手順

RGWサービスの公式手順に沿うと、名前と配置先を指定するだけでゲートウェイが立ちます。ポートを指定しない場合の待ち受けポートは80番です。続いてRGW管理ガイドのradosgw-admin user createでユーザーを作ると、出力のJSONにアクセスキーとシークレットキーが含まれます。

# 2台のホストにRGWを1つずつ置く
ceph orch apply rgw objstore --placement="2 host2 host3"

# S3クライアント用のユーザーを作る(出力の keys に access_key と secret_key)
radosgw-admin user create --uid=app01 --display-name="app01"

# AWS CLIからエンドポイントを指定して確かめる
aws --endpoint-url http://10.10.0.102 s3 mb s3://test-bucket
aws --endpoint-url http://10.10.0.102 s3 ls

本番では80番の平文のまま公開せず、前段にTLSを終端するロードバランサを置きます。RGWを2台以上に分けておけば、片方を止めて更新する運用も組めます。

RGWのS3互換表で部分対応になるバケットレプリケーションの扱い

「S3互換」と書かれていても、どこまで同じかは製品ごとに違います。RGWについてはS3 APIの互換表が公開されており、2026年10月時点で部分対応とされているのはバケットレプリケーションだけです。備考には、ゾーン間でのみ許可されると書かれています。バケットポリシー、ライフサイクル、静的Webサイト、バケット通知は対応と記載されています。

移行時に効いてくるのはこの差です。Amazon S3のクロスリージョンレプリケーション設定をそのまま持ち込むことはできず、RGWのマルチサイト構成(realm・zonegroup・zone)で組み直す必要があります。ほかに、レスポンスヘッダのx-amz-id-2は返りません。アプリケーションのコードがこのヘッダを読んでいないか、移行前にgrepで確かめてください。

MinIOとRGWのどちらでS3互換を建てるかを用途別に選ぶ判断基準

オンプレミスにオブジェクトストレージを建てる候補として、まず比べられるのがMinIOです。判断の軸は「オブジェクト以外も要るか」の1点に絞れます。

要るのがS3互換のエンドポイントだけなら、RGWのためにmon・mgr・OSDを含むCephクラスタを丸ごと運用するのは重すぎます。構成要素の少ない単機能の実装を選ぶほうが筋がよいでしょう。ただしMinIOはOSS版のアーカイブで採用条件が変わったため、ライセンスと保守の継続性を先に確認する必要があります。

逆に、仮想マシンのディスクや共有ファイルも同じ基盤で持ちたいなら、RGWが素直な選択です。ディスクプールが1つにまとまり、容量の増設も監視も1系統で済みます。オブジェクト単体の性能や手軽さで比べるのではなく、基盤を1つに寄せたいかどうかで決めてください。

Cephを採用する条件と見送る場面、Rook・Proxmox VE・クラウドとの選び分け

ここが採否の分かれ目です。機能の多さではなく、要件の広さと運用体制の2軸で判断します。

Cephを採用できる条件と自社で運用するために必要な体制の判断基準

Cephを選んでよいのは、次の3つが同時に成り立つときです。1つ目は、ブロック・ファイル・オブジェクトのうち2種類以上が要件に入っていること。2つ目は、OSD用の未使用ディスクを持つサーバを3台以上確保し、容量の伸びに合わせて足し続けられること。3つ目は、PG・CRUSH・リバランスといった概念を読み、年1回の系列更新を回せる担当者を置けることです。

3つ目の運用担当者の確保を軽く見ることは、導入失敗の原因です。Cephは止まらないように作られている反面、不調の兆候はHEALTH_WARNの一行で静かに出ます。誰も読まないまま放置すると、2本目のディスク故障で初めて事態に気づく構図になります。

典型的な採用場面は、プライベートクラウドの土台として仮想マシンのディスクとS3互換のバックアップ置き場を一体で持つ構成です。クラウドとオンプレミスの役割分担を含めた構成の相談は、インフラ構築の支援で受け付けています。

Cephを見送る場面とストレージ要件別に選べる代替手段の比較表

次の場面では、Cephを素のまま建てる判断は勧めません。代替の選択肢とあわせて並べます。

場面 判断 代替
S3互換のエンドポイントだけが要る 見送り オブジェクト専用の実装
Kubernetesのブロックボリュームのみで十分 見送り Longhornかクラウドのブロック
サーバ3台未満か空きディスクを確保できない 見送り クラウドのマネージドストレージ
Kubernetesの中でCephを動かしたい 形を変えて採用 Rookオペレータ経由
仮想化基盤とストレージを一体で持ちたい 形を変えて採用 Proxmox VEのCeph統合

Kubernetesのクラスタ内にストレージを同居させるなら、cephadmではなくRookでオペレータとして動かす形になります。ブロックだけで足りる場合の比較先はLonghornで、構成要素が少ないぶん運用の担当範囲も小さく収まります。

仮想マシンが主役なら、Proxmox VEの統合機能が近道です。Web画面とpvecephコマンドからCephを構築・管理でき、ハイパーバイザとストレージを同じサーバに載せられます。Cephを単独で建てるのは、これらの枠に収まらず、複数の基盤から1つのストレージを共有したいときです。

よくある質問

Cephの検討段階でよく出る疑問に、公式ドキュメントの記述をもとに答えます。

Cephは何台のサーバから始められますか?

既定の3レプリカと障害ドメインhostの組み合わせでは、OSDを持つホストが3台あれば動きます。ただし3台では1台停止中に複製を作り直す先がなく、もう1台止まれば読み取りもできない状態です。Proxmox VEのガイドも3ノード以上かつOSD 12本以上を推奨しており、本番は4台以上で余裕を持たせる設計を勧めます。

CephとRAIDはどう違いますか?

RAIDは1台のサーバの中で複数のディスクを束ね、ディスク故障に備える仕組みです。Cephはサーバをまたいで複製やパリティを持つため、筐体や電源の故障にも耐えます。そのぶんネットワークとサーバ台数が要るので、1台で完結する用途ならRAIDのほうが簡素です。

CephFSは本番で使えますか?

使えますが、前提が1つ増えます。メタデータを処理するMDSが追加で要り、小さなファイルを大量に扱う処理ではMDSが先に詰まりやすくなります。複数のサーバから同じディレクトリへ同時に書く要件があるときに絞って採用してください。

キャッシュティアリングで高速化できますか?

公式のアーキテクチャ解説は、Cache Tieringを非推奨とし、既存クラスタのために残している機能だと位置づけています。新規構築で速度を上げたいなら、OSDにNVMeを割り当てる、遅いHDDとSSDでプールを分けるといった構成側の手段を選んでください。

Cephの更新はどのくらいの頻度で必要ですか?

公式のリリース一覧を見ると、系列ごとの保守期間は初回リリースから1年半〜2年半ほどです。2026年10月時点ではTentacleの推定EOLが2027年6月1日です。期限内でも修正版は数か月おきに出るため、修正版の適用と年1回程度の系列更新を両方とも運用計画に入れておきます。

関連記事

お気に入りに入れた記事の一覧

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.07 テックブログ ファインズの不正アクセスと153万件の予約者情報|予約システムを使う店舗の報告と通知の手順
  2. 2026.10.19 テックブログ コミックシーモア不正アクセスで会員情報流出:再開時期・パスワード再設定と運営側のログ点検
  3. 2026.10.16 テックブログ バーガーキング情報漏洩どうしたらいい?約1,118万件の対象確認・補償・退会とメールの真偽
  4. 2026.10.15 テックブログ 銀のさら不正アクセス:最大650万件の対象確認と窓口、パスワード変更・退会の手順
  5. 2026.10.14 テックブログ ブックオフ不正アクセス:約638万人の対象確認と本物メールの見分け方

RELATED POSTS 関連記事

目次