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）