Ceph RBDを本番ブロックストレージに採用する｜iSCSI代替の移行判断とフェイルバック設計

なぜいま Ceph RBD が iSCSI 代替の選択肢に上がるのか

ブロックストレージの世界は長らく iSCSI が支配してきました。しかし2026年現在、多くの運用現場では「専用 SAN を更改するタイミングで OSS に切り替えたい」という声が増えています。その理由は大きく二つあります。一つはハードウェア依存からの脱却、もう一つはクラウドネイティブなワークロードとの親和性です。

iSCSI は成熟した技術ですが、専用イニシエーター/ターゲットの組み合わせが多く、ベンダーロックインが根強く残ります。ファームウェア管理、ゾーニング、マルチパス設定といった運用コストも無視できません。対して Ceph RBD（RADOS Block Device）は、汎用サーバーの集合体で高可用なブロックストレージを構成でき、KRBD（カーネルモジュール）や librbd 経由で Linux ホストへ直接マウントできます。さらに Rook を使えば Kubernetes 上で宣言的に管理することも可能です。

ただし「OSS だから安い」という単純な話ではありません。移行判断には、既存 iSCSI 構成の棚卸し、レイテンシー特性の比較、フェイルバック設計の整備が必要です。以下では移行を検討するための判断軸から、実際の手順と検証、切り戻しまでを順に説明します。

移行判断の軸：iSCSI と Ceph RBD の特性比較

移行を決定する前に、両者の根本的な設計思想の違いを整理しておくことが重要です。

iSCSI はブロック I/O を TCP/IP 上に乗せる「プロトコル」です。ターゲット側のストレージ実装に依存し、単体ノードの RAID コントローラーや専用 NAS/SAN アプライアンスが典型的な構成です。一方 Ceph RBD は、Ceph クラスター全体に存在する RADOS オブジェクトストアの上に仮想ブロックデバイスを提供します。データは複数の OSD（Object Storage Daemon）に分散・レプリケーションされ、特定ノードの障害に対してクラスター全体で吸収します。

現場でよく比較される観点を整理すると、以下のような傾向があります。

• レイテンシー：KRBD を使った RBD は NVMe over Fabrics には劣りますが、HDD 構成の iSCSI と比べると同等かそれ以上のスループットを出せるケースもあります。オールフラッシュ構成の iSCSI と正面から比較するには、OSD のバックエンドに NVMe を用いた BlueStore 構成が前提になります。
• 可用性：Ceph は OSD の過半数が稼働していれば I/O を継続します。iSCSI のデュアルコントローラー構成よりも障害耐性の設計が柔軟です。
• スナップショット：RBD スナップショットはコピーオンライト（COW）で取得でき、一貫性のある差分バックアップが容易です。iSCSI も VAAI 等でスナップショットを提供しますがベンダー依存になりがちです。
• 運用コスト：Ceph は監視・ヘルスチェック・PG（Placement Group）管理などクラスター固有の概念が多く、学習コストは高めです。iSCSI に比べてトラブルシューティングの難易度が上がることを覚悟する必要があります。

これらを踏まえると、移行を進めるべき典型的なシナリオは「既存の iSCSI アプライアンスがハードウェア EOL を迎えており、マルチノードのコモディティサーバーが調達できる環境」です。逆に、レイテンシーが数十マイクロ秒単位で要求されるデータベースや、専任の Ceph エキスパートがいない小規模チームでは、iSCSI の継続もリスク管理の観点から合理的な選択です。

Ceph RBD の構成手順：Rook を使った現行標準アプローチ

2026年時点でオンプレミス Kubernetes 環境に Ceph RBD を導入する際、Rook Operator を使った構成が事実上の標準です。以前は手動で ceph-deploy や cephadm を用いるケースが多かったですが、Rook は宣言的なマニフェスト管理と Kubernetes ライフサイクルへの統合によって運用負担を大幅に軽減します。

前提条件の確認

Rook Ceph を導入する前に、以下を確認してください。

• Kubernetes クラスター（v1.28 以降推奨）が稼働していること
• OSD 用の raw デバイスまたはパーティションがノードに存在すること（既存のファイルシステムがないこと）
• 各ノードに lvm2 パッケージがインストールされていること
• 最低3ノード構成で OSD が3台以上確保できること（replication size=3 の場合）

Rook Operator とクラスターのデプロイ

Rook の公式 Helm チャートまたは GitHub リポジトリのマニフェストを使って Operator をデプロイします。rook-ceph Namespace に Operator Pod が起動したら、CephCluster カスタムリソースを適用してクラスターを構成します。マニフェストの storage.useAllDevices または storage.devices で OSD に割り当てるデバイスを指定します。

クラスターの健全性は kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- ceph status で確認できます。HEALTH_OK と表示され、PG が active+clean の状態になれば基本構成は完了です。

RBD ストレージクラスの作成と PVC のプロビジョニング

CephBlockPool リソースで RBD プールを作成し、対応する StorageClass を定義します。StorageClass に provisioner: rook-ceph.rbd.csi.ceph.com を指定することで、PVC（PersistentVolumeClaim）を作成するたびに自動的に RBD イメージが生成されます。

既存の iSCSI ボリュームからデータを移行する場合は、rsync や dd によるブロックレベルコピーが現実的です。ただしデータ整合性の観点から、移行時にはアプリケーションを停止した状態でのコールドコピーを推奨します。オンラインのライブマイグレーションは、データベースなど書き込みが頻繁なワークロードでは特に注意が必要です。

動作検証：移行後に確認すべきポイント

構成が完了したら、本番投入前に以下の観点で検証を行います。

I/O パフォーマンスの計測については、fio を使ったシーケンシャル・ランダム読み書きのベンチマークが定番です。既存の iSCSI 環境での計測値と比較し、ワークロードが許容範囲に収まるかを確認します。特にランダム小ブロック（4KB）の IOPS はデータベース系ワークロードの代理指標として重要です。

フェイルオーバーの動作確認では、OSD を1台意図的に停止し、クラスターが自動復旧するまでのアプリケーションへの影響を測定します。ceph osd out <id> でノードを論理的に切り離し、PG の再配置（backfill/recovery）が完了するまでの I/O レイテンシーを記録します。

スナップショットとリストアの確認も欠かせません。kubectl apply で VolumeSnapshot を作成し、別の PVC へのリストアが正常に完了するかを確認します。バックアップ運用の手順書と合わせて動作を保証しておくことで、障害時の対応スピードが格段に上がります。

フェイルバック設計：iSCSI に戻す判断基準と手順

本番移行後に問題が発生した場合、iSCSI 環境へ切り戻す手順をあらかじめ設計しておくことが運用の鉄則です。「フェイルバックの手順がない移行計画は移行計画ではない」と言われるほど、現場ではこの設計が重視されます。

切り戻しを判断する主なトリガーは以下の通りです。

• Ceph クラスターの HEALTH_WARN または HEALTH_ERR が解消されず、SLA に影響が出ている
• PG の復旧に要する時間がビジネス要件を超えている
• 運用チームが障害対応のスキルセットを持っておらず、ベンダーサポートも調達できない
• レイテンシーの計測値がアプリケーション要件を継続的に下回っている

フェイルバックの基本的な流れは、アプリケーションを停止 → RBD ボリュームからデータを iSCSI LUN へコピー → iSCSI マウントに切り替えてアプリケーションを再起動、という順序です。移行時と同様にコールドコピーが安全です。

重要なのは、iSCSI 側の構成を移行後もしばらく維持しておくことです。現場では「移行完了と同時に iSCSI を解体してしまい、問題発生時に戻し先がなくなった」という事例が少なからず報告されています。少なくとも本番稼働後1〜3ヶ月は旧環境を維持することを推奨します。

2026年の現行環境差分：Ceph と Rook の最新動向

Ceph の最新安定版は Squid（19.x 系）です。BlueStore の最適化が進んでおり、特にオールフラッシュ構成での IOPS 改善が報告されています。また、cephadm による管理機能も成熟し、Rook を使わないベアメタル構成でも宣言的な運用が可能になっています。

Rook は v1.15 系が現行です。CSI ドライバーの安定性が向上し、VolumeGroupSnapshot（複数 PVC の一括スナップショット）のサポートが GA になっています。これにより、複数ボリュームを使うステートフルアプリケーションの一貫性バックアップが、従来より格段に扱いやすくなっています。

一方で注意すべき点もあります。Ceph のバージョンアップは Rook Operator のバージョンと密接に連動しており、Operator を先にアップグレードせずに Ceph クラスターのみを更新しようとすると互換性の問題が発生します。アップグレード手順は必ず Rook の公式ドキュメントに沿って実施することが現場での共通認識になっています。

また、iSCSI との比較という観点では、NVMe-oF（NVMe over Fabrics）の普及が今後の選択肢を複雑にしています。超低レイテンシーが要求される用途では NVMe-oF が台頭しており、Ceph RBD は「高可用性・大容量・コスト効率」を重視する用途で引き続き有力な選択肢であり続けるという位置づけが明確になりつつあります。

Ceph RBD への移行は、正しく設計すれば iSCSI の代替として十分な実績を持ちます。移行判断のポイントは「技術的優劣」ではなく「自分たちのチームが長期間運用できるか」という問いに帰着します。フェイルバック設計を含めた移行計画を丁寧に作ることが、本番環境での採用を成功させる最短経路です。