Proxmox VE統合型Ceph Storage構築・設定ガイド：自己修復機能を備えた分散ストレージの実現 - ITFROMZERO - Share tobe shared! 3ノード構成のProxmox VEクラスタにおけるCeph Storage実践導入ガイド。専用10GbEネットワーク設定やPLP搭載エンタープライズSSDの選定、ノードダウン時の自己修復シミュレーション検証まで詳しく解説。

Table of Contents

課題の背景：集中型ストレージのジレンマとHA（高可用性）の壁

これまで、Proxmoxクラスタにおけるストレージ選定は多くのシステム管理者にとって頭痛の種でした。選択肢は主にローカルストレージ（Local ZFS/LVM）を利用するか、外付けのNAS/SAN（iSCSI/NFS経由のTrueNASなど）を導入するかの2択であり、どちらにも厄介なボトルネックが存在していたからです。

ローカルストレージを使用する場合、ホストがダウンすると仮想マシン（VM）も道連れになり、High Availability（HA）機能は実質的に役に立ちません。一方で、共有ストレージとして専用のSAN/NASアプライアンスを導入すると、致命的な単一障害点（SPOF）が生じてしまいます。NASの電源ユニット故障やストレージスイッチの不具合が1つ起きるだけで、各ノード上の10〜20台ものVMが一斉にダウンすることになります。

約6か月前、筆者はホームラボのインフラ全体を、Proxmox VE 8に統合されたCephを用いたハイパーコンバージドインフラストラクチャ（HCI）へと移行することにしました。3台のミニサーバーノードで構成されるラボ環境では、PostgreSQLやRedisのクラスタからGitLabに至るまで、12台のVMと8個のLXCコンテナを稼働させています。高負荷な書き込み処理中にLANケーブルを活線抜去したりSSDを引き抜いたりといった、半年間にわたる過酷な検証を経ても、Cephは高価なSAN機器に頼ることなく、驚異的な自己修復（セルフヒーリング）能力による堅牢性を証明してくれました。

Proxmox VEにおけるCephのコア概念

Cephはオープンソースの分散ストレージシステムです。各ノードに搭載された物理ドライブを統合し、単一のストレージプールを形成します。Cephに書き込まれたデータは4MBのオブジェクトに分割され、CRUSHアルゴリズムによって中央のメタデータサーバーを介することなく計算され、各サーバーへ均等に分散配置されます。

Proxmox上でCephクラスタを円滑に運用するために、最低限押さえておくべき4つの主要コンポーネントは以下の通りです：

OSD (Object Storage Daemon): 各物理ドライブ（NVMe/SSD）に1対1で対応するデーモンです。該当ドライブの読み書き、データ複製、健全性監視を担います。
MON (Ceph Monitor): クラスタ全体のステータスマップ（Cluster Map）を管理する頭脳です。クォーラム（Quorum：定足数）の合意形成を維持するため、奇数台（個別の3ノード上に最低3つのMON）の配置が必須となります。
MGR (Ceph Manager): パフォーマンスメトリクス（IOPS、レイテンシ、容量使用率）を収集し、Proxmox Web GUIでリアルタイムグラフを表示するためのAPIを提供します。
RBD (RADOS Block Device): ProxmoxがKVM仮想マシンに仮想ディスク（raw形式）を割り当てるために使用するブロックデバイス形式であり、瞬時のスナップショット作成やクローン作成をネイティブにサポートします。

セルフヒーリング（自己修復）メカニズムは、レプリケーションパラメータであるsize/min_sizeに基づいて動作します。例えばsize=3かつmin_size=2に設定した場合、Cephは常に3ノード間で3つのレプリカ（複製）を相互に保持します。仮にノード3が突然停電でダウンしても、Cephは残り2つのレプリカを検知します。依然としてmin_size=2の閾値を満たしているため、ノード1とノード2上のVMはレイテンシの劣化なしに通常通りディスクの読み書きを継続できます。

ハードウェア要件：実体験から得た教訓

Cephは非常に強力ですが、その反面ハードウェア要件には極めてシビアです。以下の3つの基準を満たしていないインフラ環境では、Cephの運用は避けるべきです：

ノード数：物理的に独立したノードが最低3台必要です。ネットワークが不安定になった際にスプリットブレイン（Split-brain）の大惨事を招きたくなければ、2ノード構成での運用は絶対にやめましょう。
ネットワークインフラ：1Gbpsネットワークは論外です。ノードが切断されて再接続した際、Cephはリバランス（再同期）プロセスを開始します。1Gbpsでは即座に帯域が枯渇し、I/Oレイテンシが1msから1000ms以上に跳ね上がり、VMが完全にフリーズしてしまいます。許容される最低ラインは2.5Gbpsですが、レイテンシ0.1ms未満を実現できるDAC（Direct Attach Copper）ケーブルで直結された10Gbps SFP+カードの利用が最も理想的です。
SSDドライブ：Intel D3-S4510、Micron 5300 PRO、Kioxia CD6など、PLP（Power Loss Protection：停電保護機能）を備えたエンタープライズ向けSSDを必ず選定してください。民生用SSD（Samsung 980やCrucial P3など）はライトキャッシュ保護用コンデンサを搭載していないため、Ceph BlueStoreが頻繁にディスクフラッシュを強制実行することになります。その結果、ランダムライト速度が400MB/sから10〜25MB/sという悲惨な数値まで低下します。

実践手順：3ノード構成でのCephクラスタ構築と設定

ステップ1：Ceph専用ネットワークインターフェースの設定

PVEの管理用IPレンジと、Cephデータ転送用の内部IPレンジを完全に分離します。CephのトラフィックがVMのネットワークトラフィックと帯域競合を起こす事態は絶対に避ける必要があります。

各ノード（本例ではノード1 – pve-01）の/etc/network/interfacesファイルを編集します：

# 通常のPVE管理およびVM用ネットワーク（1Gbps）
auto vmbr0
iface vmbr0 inet static
    address 192.168.1.11/24
    gateway 192.168.1.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0

# Cephクラスタ専用10GbEネットワーク
auto enp3s0
iface enp3s0 inet static
    address 10.10.10.11/24
    mtu 9000

ノード2（10.10.10.12/24）およびノード3（10.10.10.13/24）でも同様の設定を行います。変更後はifreload -aコマンドで反映させます。mtu 9000（ジャンボフレーム）を設定することで、NICがより大きなデータフレームを処理できるようになり、クラスタが高スループットを処理する際のCPU割り込み負荷を約15%軽減できます。

ステップ2：クラスタ全ノードへのCeph Reefパッケージのインストール

SSH経由で3台すべてのサーバー上で、Ceph Reef（Proxmox VE 8でデフォルトの安定版）をインストールするコマンドを実行します：

pveceph install --version reef

ステップ3：最初のノードでのCephクラスタ初期化

初期化コマンドの実行は、ノード1（pve-01）で1度だけ行います。先ほど設定した10Gサブネットを指定します：

pveceph init --network 10.10.10.0/24

このコマンドにより標準設定ファイル/etc/pve/ceph.confが生成され、Proxmox Cluster File System（pmxcfs）を介して残り2つのノードへ自動的に同期されます。

ステップ4：全3ノードでのMonitorおよびManagerの作成

最高レベルの耐障害性を確保するため、各ノードにMONおよびMGRデーモンを作成します：

# pve-01、pve-02、pve-03の順にそれぞれ実行：
pveceph mon create
pveceph mgr create

以下のコマンドでクォーラム（Quorum）の状態を確認します：

ceph mon stat

出力結果にquorum 0,1,2 pve-01,pve-02,pve-03と表示されれば、3ノードすべてが正常にハンドシェイクを完了したことを示しています。

ステップ5：空きディスクからのOSD初期化

各ノードに/dev/nvme0n1として空のNVMeドライブが1台ずつ追加されていると仮定します。まず競合エラーを防ぐため、古いメタデータやパーティションを完全に消去します：

# OSDを追加する前に各ノードで実行
wipefs -a /dev/nvme0n1
pveceph osd create /dev/nvme0n1

3ノードすべてで実行後、以下のコマンドでOSDのツリー構造を確認します：

ceph osd tree

すべてのOSDがupかつinの状態になり、容量が正確に表示されていることを確認してください。

ステップ6：Cephプールの作成と仮想マシン用ストレージの割り当て

次に、3レプリカ構成でceph-vm-poolという名称のストレージプールを作成します：

pveceph pool create ceph-vm-pool --size 3 --min_size 2 --add_storages 1

--add_storages 1フラグを指定することで、このプールが/etc/pve/storage.cfgに自動追加されます。新規VMを作成する際は、ハードディスク（Hard Disk）の項目でストレージとしてceph-vm-poolを選択するだけです。これにより、VMの仮想ディスクデータは自動的にオブジェクト分割され、3台の物理ホストへ均等に分散配置されます。

ステップ7：実際の障害シミュレーション検証

実際の障害テストで自己修復機能を検証します。ノード1上でLinux VMを起動し、連続書き込みベンチマークコマンドを実行します：

fio --name=test --ioengine=libaio --rw=randwrite --bs=4k --size=2G --numjobs=1 --iodepth=16 --runtime=60 --time_based

VMが約180MB/sの速度でデータを書き込んでいる最中に、ノード3の電源プラグをそのまま引き抜きます。その後、ノード1に戻ってステータスを確認します：

ceph status

ターミナルに以下のような警告ステータス（HEALTH_WARN）が表示されます：

  cluster:
    id:     a7b28c31-7e89-4d22-b91c-123456789abc
    health: HEALTH_WARN
            1/3 mons down, quorum pve-01,pve-02
            1 host down
            1/3 osds down

  services:
    mon: 3 daemons, 2 in quorum (pve-01, pve-02)
    mgr: pve-01(active), standbys: pve-02
    osd: 3 osds: 2 up, 2 in

仮想マシン内のfioコマンドは、I/Oエラーを一切発生させることなく実行を継続します。最初の3秒間だけレイテンシが1.2msから2.5msへわずかに上昇したものの、すぐに元の安定状態へと復帰しました。

ノード3が10分以上オフラインのままになると（mon_osd_down_out_intervalパラメータのデフォルト値は600秒）、CephはそのノードのOSDを自動的にoutとしてマークします。クラスタ内にスペアドライブが存在する場合、Cephは不足しているPlacement Group（PG）を新しいドライブへ即座に複製し、安全な3レプリカ状態を自律的に再構築します。

まとめ

Proxmox VE上のCephは、大掛かりなSANソリューションに多額の予算を費やすことなく、高性能な分散ストレージを実現するための最適な解答です。本番（プロダクション）環境への導入に着手する前に、以下の3つの重要な原則を必ず心に留めておいてください：

クォーラムの合意形成を維持するため、ノード数は常に奇数（最低3ノード）を確保すること。
再同期に伴うレイテンシを排除するため、DACケーブルや光トランシーバーを用いた10Gbps以上の専用ネットワークに投資すること。
BlueStoreアーキテクチャの同期書き込み性能を維持するため、必ずPLP機能を備えたエンタープライズ向けSSD/NVMeを採用すること。

これら3つの要件を確実に満たすことで、高い耐障害性を誇り、ストレージの拡張も容易で、ハードウェア障害が発生しても夜中に叩き起こされることのない、エンタープライズ品質の仮想化クラスタを手に入れることができます。