Ceph/RADOSの実装から動作の仕組みを理解する：Ceph/RADOS入門（2）（1/3 ページ）
OpenStack環境下の分散ストレージとして注目を集めるCeph/RADOS。今回は各コンポーネントを深掘りして挙動を理解していく。分散の仕組みや特徴を理解することで、より良いシステム構成検討を目指そう。
Ceph/RADOSの実装から動作の仕組みを理解する
前回の記事ではCeph/RADOSの成り立ちや、注目されている理由、他の類似プロダクトとの違いを見てきました。
今回はCeph/RADOSがどのような構成で分散ストレージを実現しているのかを理解していきましょう。
Ceph/RADOSの実装を見る
まず、Ceph/RADOSの技術的な概要を見ていきましょう。
Ceph/RADOS環境は、分散オブジェクトストレージであるRADOSがベースとなっています。RADOSはアプリケーションから直接使用する他、コンポーネントを足すことで各種サービスインターフェース（ブロックインターフェースやファイルインターフェースなど）を追加する構成になっています（インターフェースの種類は後述します）。
これはCeph/RADOSが設計される際、ファイルシステムのスケーラビリティを向上させるアーキテクチャの必要に対して、ハードディスクをオブジェクトベースストレージに置き換えるアプローチを選択した結果です。
ブロック割り当てなどの低レベルなファイルシステムオペレーションをオブジェクトストレージにオフロードすることで、従来は一台のファイルサーバーに集中していたメタデータ管理負荷の一部が多数のオブジェクトストレージに分散されます。
Ceph Storage Clusterの構成
RADOSを使用するためにはCeph Storage Clusterというクラスターシステムを構成します。
Ceph Storage Clusterのプラットホームには各種Linuxディストリビューションが使用できます。本稿ではCentOS 6.4（x86_64）を使用しています。
具体的な構築例は後述しますので、ここではコンポーネントの紹介のみを行います。
クライアント
ここには図示していませんが、まずRADOS上のオブジェクトにアクセスするクライアントがあります。
クライアントはCeph Storage Clusterを記述した「クラスターマップ」という小さなデータ構造と、CRUSHアルゴリズム（ハッシュ関数）を用いてオブジェクトの所在を自ら計算しオブジェクトにアクセスします。オブジェクトディレクトリサーバーへのオブジェクト所在問い合わせを排除し、メタデータ管理負荷の集中を起こりにくくする狙いがあります。
クライアントはmonitor（図の「M」アイコン）という、Ceph Storage Clusterのメンバーシップを管理するコンポーネントから最新のクラスターマップを取得します。
monitor
Monitorは3台以上の奇数台が必要です。monitorはステートマシンの実装で、合意アルゴリズム（Paxsos）を用いて互いに通信し、それぞれにクラスターマップの最新コピーを維持します。
OSD（Object Storage Device）
OSDはデータを格納するコンポーネントで、2台以上が必要です。クライアントはOSDに直接アクセスしてデータの入出力を行います。データはオブジェクトの単位でOSDに冗長配置されます。オブジェクトのコピー（レプリカ）配置は、クライアントではなくOSDがクラスターマップとCRUSHアルゴリズムで配置すべきOSDを計算して行います。
各OSDが自律的にオブジェクトのレプリカを配置する他、レプリカ間のデータ整合性を監視・修復したり、OSD相互の死活を監視し、monitorに通知することでCeph Storage Clusterの管理負荷が多数のOSDに分散されます。
多くの場合、HDDごとにOSDを構成します。1つのOSDはHDD、ファイルシステム、デーモン（OSD daemon）で構成されます。図は1台のOSD用サーバー内に5台のOSDが構成されている様子を表しています。
Copyright © ITmedia, Inc. All Rights Reserved.