---
title: "Cephとは？RADOSとCRUSHの仕組みとcephadmでの構築手順、S3互換をオンプレで建てる判断を解説"
url: "https://www.issoh.co.jp/tech/details/18661/"
published: 2026-10-21
updated: 2026-10-21
categories: ["データベース"]
publisher: "株式会社一創"
---

# 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の全体構造

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

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

ライセンスは[GitHubのREADME](https://github.com/ceph/ceph)によると、大部分がLGPL 2.1または3.0のデュアルライセンスです。社内基盤として使う分には、ライセンス料は発生しません。

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

分散ストレージの多くは「どのデータがどこにあるか」を記録した索引サーバを持ちます。Cephは持ちません。[CRUSHマップの公式解説](https://docs.ceph.com/en/latest/rados/operations/crush-map/)は、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系の保守期限と新規構築で選ぶ系列

[公式のリリース一覧](https://docs.ceph.com/en/latest/releases/)では、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のインストール手順](https://docs.ceph.com/en/latest/cephadm/install/)が挙げる要件は、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`に入れてから登録します。[ホスト管理の手順](https://docs.ceph.com/en/latest/cephadm/host-management/)にある構文で、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サービスの公式解説](https://docs.ceph.com/en/latest/cephadm/services/osd/)によると、デバイスが使えると判定されるのは、パーティションがない、LVMの状態がない、マウントされていない、ファイルシステムがない、BlueStoreのOSDが残っていない、5GiB以上ある、の6条件をすべて満たすときに限られます。OSのインストーラが自動でパーティションを切ったディスクは弾かれるため、サーバ調達の段階で「OSD用に未使用のディスクを1台あたりN本」と仕様に書き込んでおくのが確実です。

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

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

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

[プール運用の公式解説](https://docs.ceph.com/en/latest/rados/operations/pools/)によると、Cephは既定で3つの複製を持ちます。障害ドメインがhostなら3つの複製は別々のホストへ置かれるので、OSDを持つホストは最低3台必要です。

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

Proxmox VEの[Ceph統合ガイド](https://pve.proxmox.com/wiki/Deploy%5FHyper-Converged%5FCeph%5FCluster)も、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サービスの公式手順](https://docs.ceph.com/en/latest/cephadm/services/rgw/)に沿うと、名前と配置先を指定するだけでゲートウェイが立ちます。ポートを指定しない場合の待ち受けポートは80番です。続いて[RGW管理ガイド](https://docs.ceph.com/en/latest/radosgw/admin/)の`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の互換表](https://docs.ceph.com/en/latest/radosgw/s3/)が公開されており、2026年10月時点で部分対応とされているのはバケットレプリケーションだけです。備考には、ゾーン間でのみ許可されると書かれています。バケットポリシー、ライフサイクル、静的Webサイト、バケット通知は対応と記載されています。

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

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

オンプレミスに[オブジェクトストレージ](https://www.issoh.co.jp/tech/details/13369/)を建てる候補として、まず比べられるのがMinIOです。判断の軸は「オブジェクト以外も要るか」の1点に絞れます。

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

逆に、仮想マシンのディスクや共有ファイルも同じ基盤で持ちたいなら、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本目のディスク故障で初めて事態に気づく構図になります。

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

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

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

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

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

仮想マシンが主役なら、[Proxmox VE](https://www.issoh.co.jp/tech/details/3883/)の統合機能が近道です。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回程度の系列更新を両方とも運用計画に入れておきます。

## 関連記事

- [Rook Cephとは？Kubernetes上でCephを動かすオペレータの仕組み](https://www.issoh.co.jp/tech/details/17287/)：Kubernetesの中でCephを運用する場合の続き。
- [Longhornとは？Kubernetes分散ブロックストレージの仕組み](https://www.issoh.co.jp/tech/details/17254/)：ブロックだけで足りる場合の比較先。
- [MinIOとは？S3互換オブジェクトストレージの仕組み](https://www.issoh.co.jp/tech/details/16006/)：S3互換だけを建てる場合の候補。
- [オブジェクトストレージとは？S3互換APIの範囲とブロックとの違い](https://www.issoh.co.jp/tech/details/13369/)：RGWで払い出す形式の土台。
- [Proxmox VEとは？できることと推奨スペック](https://www.issoh.co.jp/tech/details/3883/)：仮想化基盤とCephを一体で持つ選択肢。
- [Kubernetes永続化ストレージ入門｜PV・PVC・StorageClass](https://www.issoh.co.jp/tech/details/15294/)：Cephをコンテナから使うときの枠組み。
- [RAIDとは？RAID0/1/5/6/10の違いと構成](https://www.issoh.co.jp/tech/details/13465/)：1台の中で完結する冗長化との比較。

---

出典: [Cephとは？RADOSとCRUSHの仕組みとcephadmでの構築手順、S3互換をオンプレで建てる判断を解説](<https://www.issoh.co.jp/tech/details/18661/>)（株式会社一創）
