Ceph/RADOSの実装から動作の仕組みを理解する：Ceph/RADOS入門（2）（3/3 ページ）

OpenStack環境下の分散ストレージとして注目を集めるCeph/RADOS。今回は各コンポーネントを深掘りして挙動を理解していく。分散の仕組みや特徴を理解することで、より良いシステム構成検討を目指そう。

[佐藤友昭，VA Linux Systemsジャパン]

Ceph/RADOSが持つサービスインターフェースの種類と挙動

RESTインターフェースとファイルインターフェース

　RADOSGWは、アプリケーションがRESTfulなHTTP APIで接続するためのゲートウェイです。Amazon S3 APIとOpenStack Swift APIに対応しています。

　RADOSGWを介することで両方のAPIから同じデータにアクセスできるようになります。RADOSGWはApache Webサーバーから起動され、libradosライブラリでRADOSプールにアクセスします。

　最新版のCeph/RADOS（v0.80以降）では、Apacheから起動されるのではなくスタンドアロンで動作できるようです。

（出典：Ceph、PDF）

　MDSは、Meta Data Serverの略で、アプリケーションがファイルインターフェース（CepfFS）で接続するためのコンポーネントです。MDSは二台以上でアクティブ／スタンバイの構成とするか、MDSクラスターの構成として分散メタデータ管理を行うこと（fragment directories）ができます。

　fragment directoriesはデフォルトでは無効の設定です。Ceph/RADOSドキュメントにMDSクラスター構成の具体的な情報記載がない状況です。本稿においてもMDSクラスター構成は使用していません。

　クライアント側はカーネルモジュール（ceph.ko）またはFUSEが必要です。

　クライアント側がCephFSマウントする際に指定するのはMDSではなくmonitorです。クライアントはファイル名空間との対話をMDSとやり取りします。

　メタデータ自体は、通常のデータと同様にOSDに格納されます。各ディレクトリのメタデータ内容（ファイル名とi-node情報）が一個のオブジェクトに格納され、レプリカされます。

　各MDSはジャーナルを管理します。ジャーナルはオブジェクトにコミットされていないメタデータキャッシュ（メモリ）上のデータを持っており、ジャーナルを再生するとメタデータキャッシュも復元されます。

　Ceph/RADOSの設計当初から分散メタデータ管理はファイルシステムのスケーラビリティを向上させる主要なアプローチの一つとして含まれています。

　大きなディレクトリや負荷が集中するディレクトリの負荷を複数のMDSに分散させるため、ディレクトリをディレクトリフラグメントの単位で動的に分割するアプローチで、Ceph/RADOS プロトタイプの時点でMDSクラスターは瞬間的に発生する大量の負荷を分散するトラフィック制御機構を実装しています。

　これは、MDSクラスターがクライアントに指示を与えることで、メタデータ要求をディレクトリ・フラグメントを担当する（authoritative）MDSに振り向けたり、トラフィックの集中するメタデータへの要求を、メタデータキャッシュ上にレプリカを持つ複数のMDSに分散して振り向けたりします。

ブロックインターフェース

　KRBD、librbdは、アプリケーションがブロックインターフェース（RBD：Ceph RADOS Block Device）で接続するためのコンポーネントです。プール内に作成したボリュームへのアクセスを提供します。KRBDはLinuxカーネルモジュール（rbd.ko）で、アプリケーションはブロック特殊ファイルを介してボリュームにアクセスします。

　librbdはライブラリで、アプリケーションは直接ボリュームにアクセスします。QEMU/KVMはlibrbdでボリュームに接続し仮想マシンに仮想ディスクを提供します。

（出典：Ceph、PDF）

Ceph/RADOSとOpenStack

　ここまでで見てきたように、Ceph/RADOSはクライアントに対して各種サービスインターフェースを提供するので、Ceph/RADOSのみでOpenStackのストレージをまかなうことができます。

　本連載第1回で言及したリストを基に具体的な方法を示すと次のようになるでしょう。

• compute service（Nova）が使用するファイルシステム（/var/lib/nova/instances）にCephFS（FUSE）を使用する
• Image service（Glance）のバックエンドストレージにRBD（librbd）を使用する
• Volume service（cinder）のバックエンドストレージにRBD（librbd）を使用する
• Object storage（Swift）の代わりにRADOSGW（librados）を使用する

　ただし、上記の構成は、QEMU/KVMの仮想化プラットフォームを利用した場合に限定されます。QEMU/KVM以外の仮想化プラットフォームでCeph/RADOSを使用する場合は、NFSサービスやiSCSIサービスをCephFS/RBD上に構築する必要があります。

　ここまでで、Ceph/RADOSの概要やインターフェースの種類などの特徴を紹介しました。次回は、Ceph Storage Clusterの構築を順を追って紹介していきます。お楽しみに。

筆者プロフィール

佐藤友昭（さとうともあき）

VA Linux Systems Japan株式会社 クラウド基盤エキスパート。

　UNIX系オペレーティングシステムの開発において、ローカルファイルシステム、ネットワークファイルシステム、論理ボリュームマネージャーなどを担当。

　HPC向けネットワークファイルシステム、ディスクアレイ、Flash SSDアレイストレージの開発にも携わるなど、ストレージ開発のスペシャリストとして活躍する。

　また、InfiniBandやiWarp（10GbE）などのRDMAネットワーク向けのファイルシステムプロトコル策定、リファレンス実装の分野におけるOSS開発の実績を持つ。