連載
» 2014年12月19日 20時50分 UPDATE

Ceph/RADOS入門(4):Cephがスケールできる理由、単一障害点を排除する仕組み、負荷を減らす実装 (1/4)

Ceph/RADOS が採用しているCRUSH、Paxosといった、分散したデータから正しく応答するための仕組みを支えるアルゴリズムの概要を学びながら、挙動を見ていきます。

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

backn2.gif

連載バックナンバー

 本連載では、オープンソースの分散オブジェクトストレージであるCeph/RADOSの技術詳細、実装について見ていきます。第1回ではCephの概要を、第2回ではCeph/RADOSを構成する要素を、第3回では実際にインストールして動作させるところまでを見てきました。

 第4回である今回は、Ceph/RADOSの動作する仕組みについて、採用している分散アルゴリズムや単一障害点をなくす仕組み、メタデータ削減の方法などを見ていきます。

Ceph/RADOSのアーキテクチャ概要

 Ceph/RADOSのアーキテクチャ概要はCeph Documentationの「ARCHITECTURE」のページにまとめられています。本稿ではそれをさらに要約して見ていきましょう。

 Ceph/RADOSを理解する上で、いくつかの分散のアルゴリズムや、合意形成の仕組みなども確認しておきます。ここでは、第1〜3回で紹介した仕組みを思い出してから読み進めてみましょう。monitorやOSDといった各種コンポーネントについては第2回で言及しています。

Ceph Storage Clusterの構成例(本連載第3回から引用) Ceph Storage Clusterの構成例(本連載第3回から引用)

CRUSHアルゴリズム(1)オブジェクト所在の確認

 Ceph/RADOSには中央サーバーがなく、各クライアントがOSDとの間で直接オブジェクトをやりとりします。また、各OSDはオブジェクトの複製を別のノード上に作成し、高可用性を確保します。このときの各OSD間も必要な情報を直接やりとりします。

 クライアントとOSDはオブジェクトの所在を計算する際にCRUSHアルゴリズムを使用します。CRUSHアルゴリズムは、各クライアント、各OSDが「Ceph Storage Clusterのトポロジを知っていること(持っている情報)」に依存しています。

mhceph01.png Ceph/RADOSでのクライアントからの問い合わせとオブジェクト所在確認の挙動の概略(出典:http://ceph.com/docs/master/architecture/

「クラスターマップ」を構成する要素

 Ceph Storage Clusterのトポロジは「クラスターマップ」で管理されます。クラスターマップはさらに下記5つのマップで構成されています。

  1. モニタマップ
  2. OSDマップ
  3. PGマップ
  4. CRUSHマップ
  5. MDSマップ

 クラスターマップはmonitorが管理します。monitorはデータをkey/value型データストア(leveldb)に格納します。その実体は(デフォルトでは)各monitorの/var/lib/ceph/mon/配下にあります。

 クライアントはOSDとやりとりする前にmonitorから最新のクラスターマップを取得する必要があります。この時、monitorが何らかのアクシデントで「不在」とならないように、monitorはクラスター構成を採っておきます。

       1|2|3|4 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

@IT Special

- PR -

TechTargetジャパン

この記事に関連するホワイトペーパー

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。