pikesaku’s blog

個人的な勉強メモです。記載内容について一切の責任は持ちません。

OpenStackアーキテクチャメモ(Cinder)

参考

www.amazon.co.jp
 
 

機能と役割

・ブロックボリュームを管理
・Cinderが管理するストレージにブロックボリューム領域の作成・削除を実施
・作成したブロックボリュームをインスタンスに外部ストレージとして提供
・作成したボリュームにOSをインストールし、仮想マシンを起動可能(Boot from Volume) 
 
 

プロセス

プロセス構造はnovaと類似。理由は元々novaに統合されていた機能であるため。

プロセス名 説明
cinder-api CinderのREST APIを提供
cinder-scheduler ブロックボリュームを作成するストレージ装置を選択
cinder-volume ストレージ装置の操作を実施
cinder-backup ブロックボリュームのバックアップを管理

 
 

【cinder-api

APIは機能がシンプルでブロックボリューム、スナップショット、クローンの作成・削除・確認・バックアップ取得が、ほぼ全て。
停止してもインスタンスのブロックボリュームアクセスに影響なし
 
 

【cinder-scheduler】

Cinder管理のストレージの中から、どれを利用するか選択する。
nova同様にフィルターと重みで選択

フィルタ 説明
AvailabilityZoneFilter 指定されたAZに属するストレージにマッチ
CapabilitiesFilter 機能や要件の指定でマッチング
CapacityFiler 使用済み容量の割合(上限値)でマッチング

デフォルトでは空き容量が大きいストレージから利用される
 
 

【cinder-volume】

・管理対象のストレージ装置に対する実際の制御を行うプロセス
・複数ストレージの管理が可能
・停止しても仮想マシンのブロックボリュームアクセスに影響は無し
・プロセス間連携はメッセージングサーバ経由だが、並列化による冗長化はできない。
 ※理由はCinderがボリューム操作する際に、DBに操作ホスト情報を記録し、その後の操作時は、該当ホストのみがメッセージングサーバからリクエストを取り出し実行する仕様のため。
 ※複数のCinder-volumeによる同時アクセスによるブロックボリュームの破壊を防ぐ仕様(??)
 ※ボリューム操作時にDBに登録されるホスト情報は、cinder.confのhostパラメタで指定
冗長化はActive & Standbyで実装する。Active & Standby側でhostパラメタは同一の値にする
 
 

【cinder-backup】

・Cinderのバックアップ機能を提供
・Swiftにバックアップ可能
・cinder-apiがバックアップリウクエストを受付、メッセージングサーバにリクエスト格納し、cindr-backupプロセスが取り出し、バックアップを実行
 
 

処理の流れ

f:id:pikesaku:20171008175336p:plain

 

f:id:pikesaku:20171008175658p:plain