【ITニュース解説】From RADOS to Ceph Services: RBD, RGW, and CephFS
2025年09月23日に「Dev.to」が公開したITニュース「From RADOS to Ceph Services: RBD, RGW, and CephFS」について初心者にもわかりやすく解説しています。
ITニュース概要
Cephは、RBD(ブロック)、CephFS(ファイル)、RGW(オブジェクト)といった多様なストレージサービスを提供する。これらはRADOSという基盤上で動作し、データをオブジェクトとして分散保存する。RADOSはデータの複製や自己修復機能により、高い信頼性と可用性を実現する。
ITニュース解説
Cephは、現代のITインフラストラクチャにおいて非常に重要な役割を果たす、高性能でスケーラブルな分散ストレージシステムである。システムエンジニアを目指すなら、データがどのように保存され、管理されているかを理解することは必須であり、Cephはそのための優れた学習対象となる。このシステムは、データの安全性とアクセス性を確保しながら、必要な時に容量を柔軟に増やすことができるため、企業からクラウドサービスまで幅広い場所で利用されている。
Cephが提供する主なストレージの種類は三つあり、それぞれ異なる用途とアクセス方法を持っている。
まず、RBD(RADOS Block Device)は、ブロックデバイス型のストレージだ。これは、物理的なハードディスクと同じように扱うことができる仮想ディスクだと考えると分かりやすい。例えば、仮想マシンやコンテナが動作するために必要なストレージとして使われることが多い。まるで個別のハードディスクを割り当てて使うような感覚で、高いパフォーマンスが求められる場合に特に有効だ。例えば、Proxmoxなどの仮想化環境で仮想サーバーの起動ディスクとして利用すれば、高速かつ安定した動作を実現できる。
次に、CephFS(Ceph File System)は、分散ファイルシステム型のストレージである。これは、私たちが普段パソコンで使うフォルダのように、ネットワーク経由で共有フォルダとしてマウントして利用できる。例えば、/mnt/cephfsといったパスでアクセスし、ファイルを読み書きすることができる。データのバックアップ、ISOイメージファイルの保存、コンテナのテンプレート、チーム内でのデータ共有など、ファイル単位でのアクセスが求められる用途に適している。複数のユーザーが同時にアクセスしても高い一貫性を保ちながら利用できる点が特徴だ。
そして、RGW(RADOS Gateway)、別名Ceph Object Storageは、オブジェクトストレージ型のストレージだ。これは、Amazon S3やSwiftといった、Webサービスでよく利用されるクラウドストレージの標準的なインターフェース(API)と互換性がある。ファイルやデータを「オブジェクト」という単位で管理し、Webアプリケーションから直接アクセスできるため、非常にスケーラブルで柔軟なデータ保存が可能だ。例えば、Nextcloudのようなクラウドストレージサービスや、MinIOといったオープンソースのオブジェクトストレージシステム、あるいはS3互換のバックアップ先として利用される。大量の非構造化データ(画像、動画、ドキュメントなど)を保存し、アプリケーションから高速にアクセスする必要がある場合に最適である。
これらRBD、CephFS、RGWといった多様なストレージサービスは、すべてRADOS(Reliable Autonomic Distributed Object Store)というCephの根幹を成す基盤の上に構築されている。RADOSは、Cephクラスター内でデータを「オブジェクト」という形で保存する役割を担っている。その名前が示す通り、「Reliable(信頼性が高い)」のは、データの損失を防ぐために複製(レプリケーション)や冗長化(イレイジャーコーディング)といった仕組みを使ってデータを保護するからだ。「Autonomic(自律的)」なのは、システムの異常を自動で検知し、管理者が手動で操作しなくても自己修復(セルフヒーリング)や自己管理を行う能力を持っているからである。「Distributed(分散型)」なのは、データが単一のサーバーではなく、複数のストレージデバイス(OSD)やサーバーに均等に分散されて保存されるためだ。RADOSはデータを直接ファイルやブロックとして扱うのではなく、オブジェクトとして格納し、そのオブジェクトをさらにOSDにマッピングすることで、上記三つのサービスが異なるアクセス方法を提供しながらも、強固な基盤の上で動作することを可能にしている。
RADOSの仕組みを理解するためには、その主要なコンポーネントを知る必要がある。
まず、OSD(Object Storage Daemon)は、実際にデータをオブジェクトとしてディスクに保存するプロセスである。一般的には、一つの物理ディスクにつき一つのOSDが割り当てられ、例えばosd.0、osd.1のように識別される。これがデータの物理的な保管場所となる。
次に、MON(Monitor)は、Cephクラスター全体の健全性や状態、どのコンポーネントが稼働しているかといった重要なメタデータを管理する。クラスターの状態を正確に把握するために、最低でも三つのMONノードを配置し、多数決(クォーラム)によって合意を形成することが推奨されている。これにより、一部のMONが停止してもクラスターの管理が継続できる。
MGR(Manager)は、MONの機能を補完する役割を持つ。主にクラスターの統計情報の収集や、負荷分散に関する調整を行い、より効率的なクラスター運用をサポートする。
CRUSH Mapは、Cephにおけるデータ配置のルールブックのようなものだ。データオブジェクトをどのOSDに、どのように分散して保存するかを決定するアルゴリズムと設定情報を含んでいる。これにより、データの地理的な配置やラック単位での冗長性なども考慮した、きめ細かなデータ配置が可能となる。
最後に、PG(Placement Group)は、オブジェクトがOSDに直接保存される前に、一時的に収容される「論理的なバケット」のようなものだ。RADOSは、何十万、何百万というオブジェクトを個別に管理するのではなく、これらのオブジェクトをいくつかのPGにグループ化し、そのPGをOSDに分散させる。これにより、管理のオーバーヘッドを減らし、大規模なクラスターでも効率的にデータを扱えるようになる。オブジェクトはまずPGに割り当てられ、そのPGが複数のOSDに分散配置される仕組みとなっている。
RADOSのデータ管理は、これらのコンポーネントが連携して動作することで実現されている。
RADOSは、データを直接ファイルとして扱うのではなく、すべてをオブジェクトとして格納する。データが書き込まれると、それは小さく分割され、それぞれがユニークなIDを持つオブジェクトとなる。これらのオブジェクトは、CRUSH Mapのルールに従って、クラスター内のOSDへと分散して保存される。
データの信頼性を確保するため、RADOSはレプリケーション(複製)またはイレイジャーコーディングという手法を用いる。レプリケーションの場合、例えばデフォルト設定では、一つのオブジェクトのコピーが三つの異なるOSDに自動的に保存される。これにより、もし一つのOSDが故障しても、残りのコピーからデータを読み出すことができ、データの損失を防ぐことができる。イレイジャーコーディングは、より効率的に冗長性を確保する技術で、パリティ情報を用いてデータを復元できるようにする。これにより、必要なストレージ容量を抑えつつ、高い信頼性を実現する。
このレプリケーションやイレイジャーコーディングの仕組みが、RADOSのセルフヒーリング能力を支えている。もしOSDの一つが故障し、データの一部が失われた場合、RADOSはMONとMGRによってその状態を検知する。そして、自動的に、失われたデータのコピーを他の健全なOSDに再作成する「リバランシング」または「リカバリー」プロセスを開始する。このプロセスは管理者の手動介入なしに行われ、データが常に設定された冗長性レベルを保つようにする。
RADOSはまた、強い一貫性(strong consistency)のプロトコルを採用しているため、どの時点からデータを読み出しても、常に最新かつ正確なデータが保証される。複数のクライアントが同時にデータを更新しようとした場合でも、データの整合性が保たれるように設計されている。
より具体的に、RADOSがどのようにデータを配置し、障害から回復するかを見てみよう。データがCephクラスターに書き込まれると、それはオブジェクトに分割される。これらのオブジェクトは、直接OSDに置かれるのではなく、まずPG(Placement Group)と呼ばれる論理的なグループに割り当てられる。このPGが、CRUSH Mapの指示に従って、クラスター内の複数のOSDへと分散して配置されるのだ。
例えば、レプリケーションサイズが3に設定されている場合、一つのオブジェクトは三つの異なるOSDにコピーされて保存される。仮に「Object A」が「OSD1」「OSD3」「OSD5」に保存され、「Object B」が「OSD2」「OSD4」「OSD6」に保存されたとする。このように、すべてのOSDがすべてのデータをミラーリングしているわけではなく、CRUSH Mapのルールに基づいて、オブジェクトのコピーが最適な形で分散される。
ここで、もし「OSD1」が故障したとする。MONとMGRはすぐにこのOSDの障害を検知する。その結果、「OSD1」にデータの一部を持っていたPGのステータスは「degraded」(劣化状態)となる。これは、必要なレプリカ数が満たされなくなったことを意味する。Cephは、自動的にCRUSH Mapを再計算し、失われたレプリカを再構築するプロセスを開始する。「Object A」は「OSD1」にコピーがあったため、その失われたコピーを補うために、クラスター内の別の健全なOSD、例えば「OSD7」に新しいコピーが作成される。こうして、「Object A」は再び「OSD3」「OSD5」「OSD7」に三つのコピーを持つ状態に戻る。
ここで重要なのは、この「リバランシング」や「リカバリー」と呼ばれるプロセスは、クラスター全体のデータを一から再配置するわけではない、という点だ。あくまで、障害によってレプリカが失われたオブジェクトについてのみ、新しいレプリカを作成し、それを適切なOSDに配置し直す。この際、新しいレプリカが特定のOSDに集中しないよう、CRUSH Mapのルールに従って、データがクラスター全体に均等に分散されるように配慮される。
故障したOSDが修理されてクラスターに復帰した場合、CephはそのOSDに保存されていたデータの整合性をチェックする。もしデータが有効であれば、以前に作成された一時的なレプリカを削除したり、データを同期したりする。この一連のプロセスが完了すると、該当するPGのステータスは「active+clean」に戻り、クラスターが完全に健全な状態になったことを示す。
このように、CephのRADOSは、データをオブジェクトとして賢く細分化し、PGとCRUSH Mapを使って最適な形で分散配置する。そして、レプリケーションやイレイジャーコーディングによってデータの安全性を確保し、OSDの障害が発生した際には、自律的なセルフヒーリング機能によって迅速にデータを復旧させる。これにより、RBD、CephFS、RGWといった多様なストレージサービスが、高い信頼性と柔軟性を持って提供されているのだ。