GlusterFSからCephへの移行可否判断｜並行稼働設計・データ整合性検証・切り戻しフロー

GlusterFSからCephへの移行を検討すべきタイミング

GlusterFSとCephはどちらもOSSの分散ストレージですが、設計思想が大きく異なります。GlusterFSはファイルシステム層を直接スタックするシンプルなアーキテクチャを採用しており、比較的少ないノード数での構築や、既存のPOSIX環境への馴染みやすさが評価されてきました。一方、Cephは独自の分散オブジェクトストア（RADOS）を基盤に、オブジェクト（RGW）・ブロック（RBD）・ファイル（CephFS）の3プロトコルを統合的に提供します。

移行の検討が現実的になるのは、次のような状況です。GlusterFSでの書き込み性能がボトルネックになっている、OpenStackやKubernetesとの統合が複雑になってきた、あるいはRed Hatによる上流開発の縮小傾向を受けてサポートの持続性に懸念が生じている場合などが典型的です。GlusterFSの上流コミュニティは2020年代に入ってから活動ペースが落ちており、主要ディストリビューターの製品戦略も変わりつつあります。これらの変化は中長期の運用計画に影響を与えます。

ただし「Cephに移行すれば必ず良くなる」という単純な話ではありません。Cephは高機能な反面、運用の複雑さとハードウェア要件が高く、小規模環境では過剰投資になることもあります。移行を始める前に、現在の課題がCephで本当に解決されるかどうかを丁寧に見極めることが出発点です。

移行可否を判断するための評価軸

移行可否の判断は、技術要件・運用コスト・リスクの3軸で整理すると見通しがよくなります。

技術要件の確認

まず、現在どのプロトコルでストレージを利用しているかを整理します。GlusterFSはNFS・SMB・GlusterFS Native Protocolによるファイルアクセスが中心です。Cephに移行する場合、CephFSはPOSIXファイルシステムとして利用できますが、GlusterFS固有のgeoレプリケーション設定やカスタムtranslatorの動作はCephFSにそのまま引き継げません。アプリケーション側がNFS経由でマウントしているだけであれば移行障壁は比較的低く、GlusterFS Native Protocolに強く依存している場合は改修コストを見積もる必要があります。

次に、ノード数とディスク構成を確認します。CephはOSD（Object Storage Daemon）ごとに専有ディスクを推奨しており、RAIDコントローラー上のディスクはキャッシュ設定によって性能が変わります。また、CephのMON（Monitor）・MGR（Manager）・MDS（CephFS利用時）は別途プロセスとして動作するため、既存ノードへの役割集約が可能かどうかも確認が必要です。

運用コストとスキル要件

Cephの運用にはCRUSHマップの理解、PG（Placement Group）数の設計、OSDの追加・削除時のリバランス挙動への対応など、GlusterFSとは異なるスキルが求められます。特にPG数の設計ミスはパフォーマンス劣化に直結するため、初期設計の段階で公式ドキュメントとpgcalcツールを参照した上で慎重に決定することが重要です。運用チームがCephに不慣れな場合、学習コストを移行判断に織り込む必要があります。

ハードウェア要件の見直し

CephはメモリをGlusterFSより多く消費する傾向があります。OSD 1台あたり2〜4GBのRAMが最低ラインとされており、大規模クラスターでは全体の必要メモリが相当量になります。既存サーバーのRAM容量が不足している場合は、増設コストを移行コストとして計上します。ディスクのI/Oレイテンシに対してもCephは敏感で、低速なディスクはパフォーマンス全体に影響します。

並行稼働設計のポイント

本番データを保護しながら移行を進めるには、GlusterFSとCephを並行稼働させる期間を設けることが基本です。並行稼働設計では、書き込み先をどこにするか、同期の方向をどう設定するか、切り替えタイミングをどう決めるかの3点を明確にします。

典型的な並行稼働パターンとしては、アプリケーション側からGlusterFSへの書き込みを継続しながら、rcloneまたはrsyncを使ってCephFS側に差分同期を流す方法があります。rcloneはS3プロトコル経由でCeph RGWとも連携できるため、オブジェクトストレージへの移行を視野に入れる場合にも有効です。一方でrsyncはファイルレベルの差分同期に向いており、CephFSをマウントした状態でGlusterFSボリュームから直接同期を行えます。

並行稼働中は、双方のストレージに対して監視を設けます。GlusterFS側は gluster volume status および gluster volume heal info でスプリットブレインやヒール状態を確認します。Ceph側は ceph status と ceph health detail で常時HEALTH_OKを維持できているかを監視します。並行期間中にいずれかで異常が発生した場合、即座に切り替えを中断できる体制を整えておきます。

並行稼働期間の目安はデータ量・変更頻度・チームのキャパシティによって異なりますが、初期フル同期が完了した後、差分同期のラグが許容範囲内（想定例：数分以内）に収まり、かつCeph側の検証が完了した時点を切り替え判断の基準とするのが一般的です。

データ整合性の検証手順

並行稼働から本番切り替えに進む前に、データ整合性の検証は欠かせないステップです。検証の粒度はユースケースに応じてファイル数・ファイルサイズ・チェックサムの3レベルで行います。

ファイル数・サイズの一致確認

GlusterFS側とCephFS側の両マウントポイントに対して、find コマンドでファイル数を比較します。

find /mnt/glusterfs -type f | wc -l
find /mnt/cephfs   -type f | wc -l

ファイル数が一致したら、du コマンドで総使用量を確認します。ハードリンクやスパースファイルが混在する環境では数値にずれが生じることがあるため、差異が出た場合はその原因を特定します。

チェックサムによる整合性確認

重要ファイルについてはmd5sumまたはsha256sumでチェックサムを取得し、両ストレージ間で一致するかを確認します。全ファイルのチェックサム取得はI/O負荷が高いため、一般的にはサンプリングまたは重要度の高いディレクトリに絞って実施します。

find /mnt/glusterfs/important-dir -type f -exec sha256sum {} \; | sort > /tmp/gluster_checksums.txt
find /mnt/cephfs/important-dir   -type f -exec sha256sum {} \; | sort > /tmp/ceph_checksums.txt
diff /tmp/gluster_checksums.txt /tmp/ceph_checksums.txt

差異が検出された場合は、rsyncの --checksum オプションを使って再同期し、再検証します。差異の原因がタイムスタンプのみの場合はアプリケーション互換性への影響を個別に確認します。

アプリケーション層での動作確認

ファイルレベルの整合性確認に加え、アプリケーションがCephFSマウント上で正常に動作するかをステージング環境または本番と同等の構成で検証します。ロックファイルの扱い・シンボリックリンク・拡張属性（xattr）など、アプリケーションがPOSIXセマンティクスの細部に依存している場合は特に注意が必要です。CephFSはPOSIX準拠ですが、クライアントバージョンやカーネルバージョンによって挙動が異なるケースがあります。

切り戻しフローと注意点

本番切り替え後に問題が発生した場合を想定し、切り戻し手順を事前に文書化しておくことが重要です。切り戻しの基本は、GlusterFSマウントを切り戻し先として保持したまま、アプリケーションのマウントポイントをCephFSからGlusterFSに戻す操作です。

切り戻し時の最大リスクは、Ceph側に書き込まれたデータがGlusterFS側に存在しないことです。本番切り替え後もCeph→GlusterFSの逆方向差分同期を継続しておくか、あるいは切り替え後のCephへの書き込みをGlusterFSにも二重書きする仕組みを設けることでこのリスクを軽減できます。ただし二重書きはI/Oコストが増加するため、切り戻し期間をあらかじめ限定（想定例：72時間以内）した上で運用するのが現実的です。

切り戻し判断基準も事前に合意しておきます。よくある切り戻し判断のトリガーとしては、Cephクラスターのヘルスが一定時間HEALTH_WARNまたはHEALTH_ERRを継続する、アプリケーションのエラーレートが切り替え前と比較して有意に増加する、I/OレイテンシがSLO（サービスレベル目標）を超過するなどが挙げられます。こうした定量的な基準を先に設けておくことで、切り戻し判断を迅速に行えます。

切り戻し後はGlusterFSを再度メインストレージとして安定稼働させつつ、Ceph側の問題原因を調査します。移行の失敗原因が設計・スキル・ハードウェアのどこにあるかを特定した上で次の移行試行に備えることが、再発防止につながります。

2026年現在の環境差分と留意事項

2026年時点でのCephの主流リリースはReef（18.x系）とSquid（19.x系）です。Squidではダッシュボードの改善やRGWのマルチサイト管理の強化が行われており、オブジェクトストレージワークロードへの対応が充実しています。一方、GlusterFSの上流開発は継続されているものの、Red Hatの主要サポート対象はRed Hat Ceph StorageおよびRed Hat OpenShift Data Foundationに移行しており、GlusterFSを基盤とするRed Hat Gluster Storageのメインストリームサポートは終了しています。

ディストリビューション側では、Ubuntu 24.04 LTS（Noble Numbat）でCeph Reefが標準リポジトリから利用可能です。Rocky Linux 9・AlmaLinux 9でもCeph公式リポジトリからのインストールが確立されており、導入障壁は以前より下がっています。一方でGlusterFSはRHEL9系での公式パッケージが整理されているため、インストール方法を事前に確認する必要があります。

Kubernetesとの統合面では、Rook-Ceph（CephをオペレーターパターンでKubernetes上に展開するプロジェクト）が成熟しており、PersistentVolume（RBDおよびCephFS）として広く利用されています。GlusterFSのCSIドライバーはメンテナンス状態になっているため、Kubernetes環境でのストレージ選定においてはCephに軍配が上がる場面が増えています。GlusterFSからCephへの移行を検討する背景にKubernetesへの移行がある場合は、この点も重要な判断材料になります。

なお、cephadmを使ったCephクラスターの展開はCeph Octopus以降の標準的なデプロイ方法となっており、従来のceph-deployは非推奨です。新規構築時はcephadmまたはRookを使用し、既存のceph-deployで構築されたクラスターが残っている場合はcephadmへの移行手順を別途計画する必要があります。移行作業の全体スケジュールを組む際には、ストレージ移行と並行してデプロイ基盤の整備も計画に含めておくと、後からの手戻りを防げます。