OpenStack Cinderについてまとめています。OpenStackとは何か?は書いていないので、知っている前提です。
OpenStack Cinderとは
AWSで言うとAmazon Elastic Block Store(EBS)相当のサービスを提供します。
仮想マシンインスタンスに対して、永続的なブロックストレージを割り当てるために使用します。
アーキテクチャ
上の図の①~③の説明は以下の通りです。
- Cinderのサービス(cinder-volume service)によってAPIを通じてボリュームが作成される
- Novaのサービス(nova-compute service)はストレージネットワーク経由でComputeホストのハイパーバイザーをボリュームに接続する
- ハイパーバイザーはボリュームに接続された後、ボリュームをローカルハードウェアデバイスとしてインスタンスに提供する
もう少し細かい話
Cinderの裏ではストレージバックエンドソフトウェア存在しており、物理ストレージとのやり取りを担います。
Cinderはストレージバックエンドに対して要求に応じたボリュームを作成するよう指示を行います。
イメージは以下です。(この図ではLinux Volume Managerがストレージバックエンド)
上のアーキテクチャの図で「Infrastructure control plane host」がこの図のCinderのホスト、「Compute host」がNovaのホストに対応します。
Cinderのコンポーネント
Cinderには以下の4つのコンポーネントが存在します。
- cinder-api
- 要求に応答し、メッセージキューに配置します。APIサービスはブロックストレージ要求のためのHTTPエンドポイントを提供します。
- cinder-scheduler
- タスクをキューに割り当て、プロビジョニングするボリュームサーバーを決定します。
- cinder-volume
- 仮想マシン用にストレージを指定します。
- cinder-backup
- ブロックストレージボリュームを外部のストレージリポジトリーにバックアップします。デフォルトでは、OpenStack Object Storageサービス(Swift)を使用してバックアップを保管します。
それぞれの関係は以下のようになります。
ストレージバックエンド
ストレージバックエンドは、Cinderがドライバをサポートしている必要があります。
以下にサポート対象のドライバ一覧があります。
LVMの他にCephやストレージベンダーのドライバなどが対応していますが、統計調査ではCinderのバックエンドとしてはCephが73%であり、圧倒的です。
おわりに
Cinderをきっかけにストレージ回りに興味が出てきたので、そのうちLVMやCephについてもアーキテクチャを調べて書いてみたいと思います。
また、OpenStackの他のストレージサービス(以下)についても機会があれば書きたいと思います。
- オブジェクトストレージ(Swift)
- ファイルストレージ(Manila)
- データベース(Trove)