OpenStack 2012.2で追加された新機能「Cinder」を使う

OpenStack 2012.2（コードネーム「Folsom」）で追加された新たなコンポーネントの1つに、ブロックストレージの管理を行う「Cinder」がある。従来は「Nova」というコンポーネントがこの機能を提供していたが、Folsom以降ではCinderへの移行が進められている。本記事では、LVMおよびNFSと組み合わせてCinderを利用するための基本的な設定やその使い方を紹介する。

既存のコンポーネントからボリュームストレージ機能が独立、選択肢が増える

最近「クラウド」という言葉が多方面で使われているが、インフラストラクチャ関連でクラウドというとAmazon Web Service（AWS）やGoogle App Engine、Windows Azureなどのような、仮想化されたサーバーを提供するサービスのことを指すことが多い。OpenStackはこれらのようなクラウドインフラストラクチャサービスを構築するためのソフトウェア集である。

OpenStackについては以前「さくらの専用サーバとOpenStackで作るプライベートクラウド」という記事でも解説を行っているためそちらを参照してほしいが、2012年9月27日にリリースされたOpenStackで6番目となるメジャーリリース「OpenStack 2012.2（コードネーム「Folsom」）では、新たにブロックストレージサービス「Cinder」やネットワークサービス「Quantum」といったコンポーネントが追加されている。

OpenStackは機能ごとに別々のコンポーネントに分割されており、それぞれにコードネームが付けられている（表1）。

Folsomで追加されたCinderおよびQuantumは、元々はComputeサービスを提供するコンポーネントである「Nova」に含まれていた機能を独立されたものだ。Novaは仮想マシンの作成や設定、管理といった機能を提供するコンポーネントだが、それに付随して必要となる仮想ストレージの管理サービス（nova-volumeサービス）やネットワーク管理サービス（nova-networkサービス）などの機能も備えていた。これらの機能を独立したコンポーネントとして実装したものがCinderおよびQuantumとなる。

Folsomでは仮想ストレージやネットワークの管理に従来どおりnova-volumeやnova-networkを利用することも可能だが、これらの機能は今後廃止されることになっている。また、CinderやQuantumではより柔軟な構成を実現できるほか機能も強化されているため、新たにプライベートクラウド環境を構築するならこれらの利用を検討すべきだろう。ただし、Quantumについてはまだ一部未実装の機能もあり、nova-networkと完全に同一の構成は実現できない場合があるのでその点にも留意したい。

なお、以下ではCentOS 6.3（64ビット）環境を使ってCinderのインストールや設定方法を解説していく。CentOSの標準リポジトリではOpenStack関連パッケージは提供されていないため、EPEL（Extra Packages for Enterprise Linux）というFedoraプロジェクトが提供しているパッケージリポジトリも利用している。EPELの利用方法については前述の「さくらの専用サーバとOpenStackで作るプライベートクラウド」という記事でも説明している。また、Cinder以外のコンポーネントの基本的なインストール/設定方法についてはOpenStack 2012.1（essex）からほぼ変わっていないので、こちらについてもこの記事を参照してほしい。

OpenStackにおける「ボリューム」とCinder

Cinder（Block Storage Service）は仮想マシンインスタンスが使用するブロックストレージデバイス（「ボリューム」）を提供するサービスで、以下のような機能を備えている。

• ボリュームの作成/削除
• テナントごとのquotaの設定
• スナップショットの作成/削除

OpenStackでの仮想マシンインスタンスには一定容量のローカルストレージが割り当てられているが、これらは仮想マシンインスタンスを削除すると同時に消えてしまう。そのため、ブロックストレージは永続化したいデータを保存するのに使われる。ブロックストレージはnovaコマンドやHorizon（ダッシュボード）からの操作に応じて指定されたストレージデバイス上に確保され、インスタンスに接続される。接続されたブロックストレージは仮想マシンで稼働しているOSからブロックデバイスとして認識され、OSからフォーマットやマウントを行ってファイルシステムとして利用できる。

CinderはNovaの一部（nova-volume）のソースコードをベースとして開発されており、nova-volumeと同様にドライバを切り替えることでLVMやSANなど各種ストレージデバイスをバックエンドとして利用できる。デフォルトのドライバではLVMを使用するようになっているが、NFSボリュームや各種iSCSIデバイス、NetAppやNexenta、EMCなどのストレージシステムなどを利用することも可能だ。

nova-volumeからCinderへの移行

Cinderはnova-volumeと同じAPIを提供している。そのため、nova-volumeを利用してすでに構築された環境でCinderを利用する場合はnova-volumeサービスを停止させ、APIエンドポイントなどの設定をあらかじめ削除しておく必要がある。また、データベースの移行などの作業も必要だ。データベースの移行については、cinder-manage migrateコマンドで行える。詳しい手順は環境によって異なるため割愛するが、詳しくはOpenStackのWikiページで解説されているので、そちらを確認していただきたい。

また、APIエンドポイントの設定削除は以下のようにして行える。まず、Novaを稼働させているホストでnova-volumeサービスを停止させる。

# service openstack-nova-volume stop

続いて、keystoneからnova-volumeサービス関連のエントリを削除しておく。この作業はkeystoneが稼働しているホスト上で行う。まず、下記のようにexportコマンドを実行してSERVICE_TOKENおよびSERVICE_ENDPOINT環境変数を適切に設定しておく。

export SERVICE_TOKEN=＜keystoneの設定用サービストークン文字列＞
export SERVICE_ENDPOINT=http://localhost:35357/v2.0/

次に、以下のようにしてvolumeサービスのエントリを削除しておく。まず、keystone service-listコマンドで削除すべきサービスを確認する。

$ keystone service-list
+----------------------------------+----------+--------------+---------------------------+
| id | name | type | description |
+----------------------------------+----------+--------------+---------------------------+
| 84a7bfda5d86469390bd02598465ea58 | volume | volume | Nova Volume Service |
| 8e0edd993fb24d06b785b1c6f9f16110 | nova | compute | Nova Compute Service |
| e88a405a79bc416cb6ec0a710b48bec0 | glance | image | Glance Image Service |
| f782c561f238407ebff6e2c51af5548e | keystone | identity | Keystone Identity Service |
+----------------------------------+----------+--------------+---------------------------+

この場合、volumeサービスのIDは「84a7bfda5d86469390bd02598465ea58」となっている。続いてこのIDを引数にkeystone service-deleteコマンドを実行してサービスを削除する。

$ keystone service-delete 84a7bfda5d86469390bd02598465ea58

最後にkeystone endpoint-listコマンドでエンドポイント一覧を確認し、削除すべきエンドポイントを確認する。

$ keystone endpoint-list
+----------------------------------+-----------+---------------------------------------------+---------------------------------------------+---------------------------------------------+----------------------------------+
| id | region | publicurl | internalurl | adminurl | service_id |
+----------------------------------+-----------+---------------------------------------------+---------------------------------------------+---------------------------------------------+----------------------------------+
| 057bb1d67bb143e8971364ecaae6ad1e | RegionOne | http://192.168.100.21:8776/v1/%(tenant_id)s | http://192.168.100.21:8776/v1/%(tenant_id)s | http://192.168.100.21:8776/v1/%(tenant_id)s | 84a7bfda5d86469390bd02598465ea58 |
| 05de5c6dc9d346eb9c3eece39b0839df | RegionOne | http://192.168.100.21:8774/v2/%(tenant_id)s | http://192.168.100.21:8774/v2/%(tenant_id)s | http://192.168.100.21:8774/v2/%(tenant_id)s | 8e0edd993fb24d06b785b1c6f9f16110 |
| 29d928e55d604d64a63de3e05022c35e | RegionOne | http://192.168.100.21:9292/v1 | http://192.168.100.21:9292/v1 | http://192.168.100.21:9292/v1 | e88a405a79bc416cb6ec0a710b48bec0 |
| 9ef64ef3fcb84456bdd7ac16374d28c9 | RegionOne | http://192.168.100.21:5000/v2.0 | http://192.168.100.21:5000/v2.0 | http://192.168.100.21:35357/v2.0 | f782c561f238407ebff6e2c51af5548e |
+----------------------------------+-----------+---------------------------------------------+---------------------------------------------+---------------------------------------------+----------------------------------+

この場合、volumeサービスのIDである「84a7bfda5d86469390bd02598465ea58」に対応するエンドポイントのIDは「057bb1d67bb143e8971364ecaae6ad1e」となっている。このIDを引数にkeystone endpoint-deleteコマンドを実行してエンドポイントを削除する。

$ keystone endpoint-delete 057bb1d67bb143e8971364ecaae6ad1e
Endpoint has been deleted.

以上でnova-volume関連設定の削除は完了だ。

LVMをバックエンドストレージとしてCinderを使う

以下ではまずCinderのストレージとしてLVM（Logical Volume Manager）を利用する場合の設定例を紹介し、続いてNFSを使用する方法についても解説していく。

なお、LVMをバックエンドストレージとして利用する場合、ボリュームはLVMの論理ボリューム（LV）として確保され、ボリューム1つごとに1つの論理ボリュームが作成される。また、仮想マシンインスタンスとの接続はiSCSIプロトコルを使って行われる。

Cinderのインストール

CinderはOpenStackのほかのコンポーネントと同様、MySQLデータベースやRESTベースのAPI、AMQP（Advanced Message Queuing Protocol）によるメッセージングを利用してコンポーネント間通信を行う。それぞれのコンポーネントを異なるサーバーにインストールできる点も同じだ。基本的なインストール方法は変わらないが、構成によって設定ファイルに記述するホスト名などが変わる点には注意したい。

CinderはEPELの「openstack-cinder」パッケージで提供されている。このパッケージをインストールすると、Cinderの利用に必要な関連パッケージなどがまとめてインストールされる。また、OpenStackの各コンポーネントで共通の各種ユーティリティが含まれる「openstack-utils」パッケージもインストールしておこう。

# sudo yum --enablerepo=epel install openstack-cinder openstack-utils

なお、本記事で利用しているopenstack-cinderパッケージのバージョンは次のとおりだ。

# rpm -q openstack-cinder
openstack-cinder-2012.2.1-1.el6.noarch

データベースの作成

CinderはOpenStackのほかのコンポーネントと同様、データベースに各種設定やサービスの状態を保存する。OpenStackでは使用するデータベースとしてMySQLやPostgreSQL、SQLiteを利用できるが、以下ではMySQLを利用することとする。

MySQLを利用する場合、openstack-utilsパッケージに含まれるopenstack-dbコマンドを使用してデータベースの初期設定が可能だ。openstack-dbコマンドはNovaおよびGlance、Keystone、Cinder用のデータベース設定を行うもので、以下のようなオプションを指定できる。

openstack-db --service ＜サービス名＞ --init|--drop --password ＜データベース接続に使用するパスワード＞

サービス名には「nova」および「glance」、「keystone」、「cinder」が指定できる。また、データベースを作成する場合は「--init」オプションを、削除する場合は「--drop」オプションを選択する。なお、openstack-dbはローカルで稼働しているMySQLサーバーに接続してデータベースを作成する点に注意したい。つまり、MySQLサーバーが稼働しているホスト上で実行する必要がある。また、実行時にはMySQLサーバーのrootパスワードが必要だ。

たとえばCinder用のデータベースを作成し、そのパスワードを「cinder」とするには次のように実行する。

# openstack-db --service cinder --init --password cinder
Please enter the password for the 'root' MySQL user:
Verified connectivity to MySQL.
Creating 'cinder' database.
Asking openstack-cinder to sync the database.

なお、Cinderを稼働させているサーバーとは別のホストでMySQLを実行させている場合、下記のようなエラーメッセージが表示される。これはそのホスト上にCinderの設定ファイルが存在しないために発生するエラーなので、無視しても問題ない。

runuser: user cinder does not exist
ERROR 1146 (42S02) at line 1: Table 'cinder.migrate_version' doesn't exist
Final sanity check failed.
Please file a bug report on bugzilla.redhat.com against the openstack-cinder package.

設定ファイルの編集

Cinderの設定ファイルは/etc/cinderディレクトリ内に格納されている。主に編集が必要なのはCinder関連サービスの設定を記述したcinder.confと、CinderのAPI関連の設定が記述されたapi-paste.iniだ。

まずcinder.confだが、変更が必要なのは下記の太字で示した部分だ。

[DEFAULT]
logdir = /var/log/cinder
state_path = /var/lib/cinder
lock_path = /var/lib/cinder/tmp
volumes_dir = /etc/cinder/volumes
iscsi_helper = tgtadm

# MySQLサーバーが稼働しているホスト名と接続に使用するユーザー名およびパスワード、データベース名を指定する
sql_connection = mysql://＜ユーザー名＞:＜パスワード＞@＜ホスト名＞/＜データベース名＞

# 使用するAMQPクライアントライブラリを指定する
rpc_backend = cinder.openstack.common.rpc.impl_kombu

# AMQPサーバー（RabbitMQサーバー）のホスト名などを追加する
rabbit_host = ＜AMQPサーバーが稼働しているホスト名＞
rabbit_port = 5672
rabbit_userid = ＜接続に使用するユーザー名＞
rabbit_password = ＜接続に使用するパスワード＞
rabbit_virtual_host = ＜使用するバーチャルホスト名＞

rootwrap_config = /etc/cinder/rootwrap.conf

# 使用するLVMのボリュームグループ（VG）を指定する設定を追加する
volume_group = ＜VG名＞

# ホストのIPアドレスを指定する
my_ip = ＜ホストのIPアドレス＞

# 認証にkeystoneを使用する設定を追加する
auth_strategy = keystone

[keystone_authtoken]
# keystoneへの接続に使用する情報を追加する
admin_tenant_name = ＜サービス用のテナント名＞
admin_user = ＜keystoneに登録したcinder用ユーザー名＞
admin_password = ＜keystoneに登録したcinder用パスワード＞
auth_host = ＜keystoneが稼働しているホスト名＞
auth_port = 35357
auth_protocol = http
signing_dirname = /tmp/keystone-signing-cinder

まずデータベース名の設定だが、「mysql://＜ユーザー名＞:＜パスワード＞@＜ホスト名＞/＜データベース名＞」という形式でデータベースへの接続に使用するアカウントやサーバーなどを指定する。たとえばユーザー名およびパスワードが「cinder」、MySQLサーバーが稼働しているホストが192.168.100.20、データベース名が「cinder」だった場合は以下のようになる。

sql_connection = mysql://cinder:cinder@192.168.100.20/cinder

続いて、使用するAMQPクライアントを指定する。AMQPサーバーとしてRabbitMQを使用している場合、クライアントライブラリとして「cinder.openstack.common.rpc.impl_kombu」を指定し、rabbit_hostやrabbit_userid、rabbit_password、rabbit_virtual_hostといった項目でRabbitMQサーバーへの接続に使用するアカウント情報を指定する。たとえばRabbitMQが稼働しているホストが192.168.100.20、ユーザー名およびパスワードが「nova」、ヴァーチャルホスト名が「/nova」だった場合、以下のような設定になる。なお、CinderはデフォルトでRabbitMQを使用するようになっており、「rpc_backend」項目が省略された場合は「cinder.openstack.common.rpc.impl_kombu」が指定されたものと見なされる。

rpc_backend = cinder.openstack.common.rpc.impl_kombu
rabbit_host = 192.168.100.20
rabbit_port = 5672
rabbit_userid = nova
rabbit_password = nova
rabbit_virtual_host = /nova

バックエンドストレージとしてLVMを使用する場合、volume_groupおよびvolume_name_template項目で使用するLVMのボリュームグループ名を指定しておく。デフォルトでは「cinder-volume」となっているが、別のものを指定することも可能だ。

volume_group = cinder-volumes

また、Cinderや関連サービスがほかのOpenStackコンポーネントと通信するのに使用するNICに割り当てられているIPアドレスをmy_ip項目で指定しておく。ほかのホストがCinderやストレージサービスにアクセスする際はこのIPに向けて接続が行われる。たとえば192.168.100.21というIPアドレスを利用する場合、以下のようになる。

my_ip = 192.168.100.21

最後に、認証に使用するKeystoneの情報などを追加する。たとえば「service」テナントにCinderサービスを登録し、ユーザー名およびパスワードがともに「cinder」、Keystoneが稼働しているホストが192.168.100.20だった場合、以下のようになる。

auth_strategy = keystone

[keystone_authtoken]
admin_tenant_name = service
admin_user = cinder
admin_password = cinder
auth_host = 192.168.100.20
auth_port = 35357
auth_protocol = http

以上でcinder.confの設定は完了だ。続いて、api-paste.iniも環境に応じて変更しておく。api-paste.iniで変更が必要なのは下記の個所だ。

[filter:authtoken]
paste.filter_factory = keystone.middleware.auth_token:filter_factory

# cinder APIを提供するホスト名およびポートを指定する
service_protocol = http
service_host = ＜keystoneが稼働しているホスト名＞
service_port = 5000

# keystoneへの接続に使用する情報を追加する
auth_protocol = http
auth_host = ＜keystoneが稼働しているホスト名＞
auth_port = 35357
admin_tenant_name = ＜サービス用のテナント名＞
admin_user = ＜keystoneに登録したcinder用ユーザー名＞
admin_password = ＜keystoneに登録したcinder用パスワード＞

たとえばkeystoneの「service」テナントにCinderサービスを登録し、ユーザー名およびパスワードがともに「cinder」、keystoneが稼働しているホストが192.168.100.20だった場合以下のようになる。

[filter:authtoken]
paste.filter_factory = keystone.middleware.auth_token:filter_factory
service_protocol = http
service_host = 192.168.100.20
service_port = 5000

auth_protocol = http
auth_host = 192.168.100.20
auth_port = 35357
admin_tenant_name = service
admin_user = cinder
admin_password = cinder

以上の設定が完了したら、以下のようにcinder-manageコマンドを実行して設定をデータベースに反映させておく。

# cinder-manage db sync

LVMおよびtgtの設定

続いて、LVMでCinderが使用する論理ボリュームが有効化されるよう、/etc/lvm/lvm.confの「volume_list」項目に使用する論理ボリュームを追加しておく。たとえば「cinder-volumes」という論理ボリュームを使用する場合、下記の太字の部分を追加しておく。

# If volume_list is defined, each LV is only activated if there is a
# match against the list.
# "vgname" and "vgname/lvname" are matched exactly.
# "@tag" matches any tag set in the LV or VG.
# "@*" matches if any tag defined on the host is also set in the LV or VG
#
# volume_list = [ "vg1", "vg2/lvol1", "@tag1", "@*" ]
volume_list = [ "cinder-volumes" ]

また、Cinderが使用するtgtdの設定ファイルについても変更が必要だ。まず、メインの設定ファイルである/etc/tgt/targets.confの先頭部分に「include /etc/tgt/conf.d/*.conf」という記述を追加しておく。

# This one includes other config files:

#include /etc/tgt/temp/*.conf
include /etc/tgt/conf.d/*.conf

続いて、/etc/tgt/conf.dディレクトリ内のcinder.confというファイル内でコメントアウトされている「include /etc/cinder/volumes/*」という行を有効化しておく。

# Note this config mode is not supported by scsi-target-utils in RHEL <= 6.4
# include /etc/cinder/volumes/
# So instead please add the following line (without the leading comment char)
# to the top of /etc/tgt/targets.conf
include /etc/cinder/volumes/* ←コメントアウトされているので「#」を削除して有効にする

ファイアウォールの設定

Cinderでは、サービスを提供するためにTCPの8776番ポートを使用する。また、Cinderが内部で使用するtgtdサービスはTCPおよびUDPの3260番ポートを利用する。ファイアウォールの設定を適宜変更し、これらのポートにほかのOpenStackノードからアクセスできるよう設定しておこう。

sudoersの設定

Cinderの各種サービスは、パッケージのインストール時に作成された「cinder」というユーザーの権限で実行される。ただし、ストレージ関連の操作など一部の操作はsudoを利用してroot権限で実行される。そのため、cinderユーザーがsudoを使ってroot権限でのコマンド実行を行えるよう、/etc/sudoersファイルに下記の記述を追加しておく。

cinder ALL=(ALL) NOPASSWD:ALL

サービスの起動

最後にCinder関連サービスおよびtgtdサービスを再起動しておく。

service openstack-cinder-api restart
service openstack-cinder-volume restart
service openstack-cinder-scheduler restart
service tgtd restart

keystoneの設定

以上でCinderサービス側の設定は完了だが、そのほかに認証サービスであるkeystoneにCinder用のユーザーおよびサービスの作成とエンドポイントの登録を行っておくく必要がある。ここではkeystoneを実行しているサーバー上で以下のようなスクリプトを実行して設定を追加している。太字の部分は環境に応じて適宜変更してほしい。

CINDER_HOST=＜Cinderサービスを実行しているホスト名/IPアドレス＞
TENANT_NAME=＜サービスを登録するテナント名＞
REGION=＜サービスを登録するリージョン名＞
CINDER_USER=＜使用するユーザー名＞
PASSWORD=＜ユーザー名に対応するパスワード＞

export SERVICE_TOKEN=＜Keystoneの設定用サービストークン文字列＞
export SERVICE_ENDPOINT=http://localhost:35357/v2.0/

# ユーザーの作成
ADMIN_ROLE=$(keystone role-list | awk '/admin/ {print $2}')
TENANT_ID=$(keystone tenant-list | awk "/$TENANT_NAME/ {print \$2}")
keystone user-create --tenant_id $TENANT_ID --name cinder --pass cinder
CINDER_USER_ID=`keystone user-list | grep cinder | awk '{print $2}'`
keystone user-role-add --user_id $CINDER_USER_ID --tenant_id $TENANT_ID --role_id $ADMIN_ROLE

# サービスの作成
keystone service-create --name=cinder --type=volume --description="Cinder Volume Service"

# エンドポイントの登録
CINDER_ID=$(keystone service-list | awk '/cinder/ {print $2}')
keystone endpoint-create --region $REGION --service_id $CINDER_ID --publicurl "http://$CINDER_HOST:8776/v1/%(tenant_id)s" --adminurl "http://$CINDER_HOST:8776/v1/%(tenant_id)s" --internalurl "http://$CINDER_HOST:8776/v1/%(tenant_id)s"

たとえばCinderを実行しているホストのIPアドレスが192.168.100.21、テナント名が「service」、リージョン名が「RegionOne」、Cinderのユーザー名およびパスワードがともに「cinder」だった場合、スクリプトの先頭部分は以下のようになる。

CINDER_HOST=192.168.100.21
TENANT_NAME=service
REGION=RegionOne
CINDER_USER=cinder
PASSWORD=cinder

nova.confの設定

NovaからCinderを利用するには、Novaの設定ファイルであるnova.confの設定を一部変更しておく必要がある。まず、有効化するAPIを指定するenabled_apis項目について下記のように設定しておく。

enabled_apis = ec2,osapi_compute,metadata

もしここで「osapi_volume」という記述があった場合、ボリューム関連のAPIも有効化されてしまう。その場合、その記述を削除しておく。また、使用するボリュームAPIを指定するvolume_api_class項目も追加しておく。ここでは、以下のように「nova.volume.cinder.API」を指定しておけばよい。

volume_api_class = nova.volume.cinder.API

Cinderの稼働テスト

最後に、Cinderの設定が正しく完了しているかどうかをcinderコマンドでテストしておこう。まず、以下のようにテスト実行用のユーザー名やパスワード、テナント名などを環境変数に設定しておく。

export OS_USERNAME=＜管理権限を持つユーザー名＞
export OS_PASSWORD=＜パスワード＞
export OS_TENANT_NAME=＜テナント名＞
export OS_AUTH_URL=http://＜keystoneが稼働しているホストのホスト名＞:5000/v2.0/
export OS_REGION_NAME=＜リージョン名＞

この状態で、cinder listコマンドを実行してエラーが出ないことを確認しておく。

# cinder list

続いて、cinder createコマンドで1GBのボリューム作成を実行する。

$ cinder create --display_name test 1
+---------------------+--------------------------------------+
| Property | Value |
+---------------------+--------------------------------------+
| attachments | [] |
| availability_zone | nova |
| created_at | 2013-02-12T10:57:15.107881 |
| display_description | None |
| display_name | test |
| id | 892d3d1d-8c65-4226-8ce9-3767464a9979 |
| metadata | {} |
| size | 1 |
| snapshot_id | None |
| status | creating |
| volume_type | None |
+---------------------+--------------------------------------+

もし正しく設定が完了していれば、cinder listコマンドで作成したボリュームが表示されるはずだ。

$ cinder list
+--------------------------------------+-----------+--------------+------+-------------+-------------+
| ID | Status | Display Name | Size | Volume Type | Attached to |
+--------------------------------------+-----------+--------------+------+-------------+-------------+
| 892d3d1d-8c65-4226-8ce9-3767464a9979 | available | test | 1 | None | |
+--------------------------------------+-----------+--------------+------+-------------+-------------+

ここで作成されたボリュームはLVMの論理ボリュームとして確保される。たとえばこの例の場合、lvscanコマンドを実行すると以下のように対応するボリュームのIDが付けられた論理ボリュームが作成されていることが確認できる。

# lvscan
ACTIVE '/dev/cinder-volumes/volume-892d3d1d-8c65-4226-8ce9-3767464a9979' [1.00 GiB] inherit

作成したボリュームは、cinder deleteコマンドで削除できる。

# cinder delete test

また、管理用ノードとして利用するホストからnova volume-createコマンドでストレージの作成や削除ができることも確認しておこう。

# nova volume-create --display-name test02 1
+---------------------+--------------------------------------+
| Property | Value |
+---------------------+--------------------------------------+
| attachments | [] |
| availability_zone | nova |
| created_at | 2013-02-13T10:09:21.966693 |
| display_description | None |
| display_name | test02 |
| id | 6f3778f1-21e8-4d9e-82e5-644c73a6f4e2 |
| metadata | {} |
| size | 1 |
| snapshot_id | None |
| status | creating |
| volume_type | None |
+---------------------+--------------------------------------+
# nova volume-list
+--------------------------------------+-----------+--------------+------+-------------+--------------------------------------+
| ID | Status | Display Name | Size | Volume Type | Attached to |
+--------------------------------------+-----------+--------------+------+-------------+--------------------------------------+
| 6f3778f1-21e8-4d9e-82e5-644c73a6f4e2 | available | test02 | 1 | None | |
+--------------------------------------+-----------+--------------+------+-------------+--------------------------------------+
# nova volume-delete test02
# nova volume-list

Cinderが提供するブロックストレージを仮想マシンインスタンスに接続する

作成したボリュームは、nova volume-attachコマンドで仮想マシンインスタンスに接続できる。nova volume-attachコマンドは以下のような引数を取る。

nova volume-attach ＜接続先インスタンス名もしくはID＞ ＜接続するボリュームのID＞ ＜接続先デバイス＞

接続先デバイスにはインスタンス内のデバイス名（「/dev/vdc」など）を指定する。「auto」を指定して、自動的に接続先を決定させることも可能だ。たとえば1GBのボリュームを作成し、「test01」というインスタンスに接続するには以下のようにする。

↓新たにボリュームを作成する
# nova volume-create --display-name test01 1
+---------------------+--------------------------------------+
| Property | Value |
+---------------------+--------------------------------------+
| attachments | [] |
| availability_zone | nova |
| created_at | 2013-02-12T15:26:57.808624 |
| display_description | None |
| display_name | test01 |
| id | 1ac5b7ee-116a-4352-8536-3b538bc2d1ed |
| metadata | {} |
| size | 1 |
| snapshot_id | None |
| status | creating |
| volume_type | None |
+---------------------+--------------------------------------+

↓作成したボリュームを確認する
# nova volume-list
+--------------------------------------+-----------+--------------+------+-------------+-------------+
| ID | Status | Display Name | Size | Volume Type | Attached to |
+--------------------------------------+-----------+--------------+------+-------------+-------------+
| 1ac5b7ee-116a-4352-8536-3b538bc2d1ed | available | test01 | 1 | None | |
+--------------------------------------+-----------+--------------+------+-------------+-------------+

↓稼働しているインスタンスを確認する
# nova list
+--------------------------------------+--------+--------+---------------------+
| ID | Name | Status | Networks |
+--------------------------------------+--------+--------+---------------------+
| 65b24d9e-bf84-4808-b382-07249a98d2fd | test01 | ACTIVE | priv_net01=10.0.1.3 |
+--------------------------------------+--------+--------+---------------------+

↓インスタンスにボリュームを接続する
# nova volume-attach test01 1ac5b7ee-116a-4352-8536-3b538bc2d1ed auto
+----------+--------------------------------------+
| Property | Value |
+----------+--------------------------------------+
| device | /dev/vdc |
| id | 1ac5b7ee-116a-4352-8536-3b538bc2d1ed |
| serverId | 65b24d9e-bf84-4808-b382-07249a98d2fd |
| volumeId | 1ac5b7ee-116a-4352-8536-3b538bc2d1ed |
+----------+--------------------------------------+

↓接続されているボリュームは「Status」が「in-use」になる
# nova volume-list
+--------------------------------------+--------+--------------+------+-------------+--------------------------------------+
| ID | Status | Display Name | Size | Volume Type | Attached to |
+--------------------------------------+--------+--------------+------+-------------+--------------------------------------+
| 1ac5b7ee-116a-4352-8536-3b538bc2d1ed | in-use | test01 | 1 | None | 65b24d9e-bf84-4808-b382-07249a98d2fd |
+--------------------------------------+--------+--------------+------+-------------+--------------------------------------+

なお、接続先デバイスとして「auto」を指定した場合、その接続先はnova volume-showコマンドで確認できる。

# nova volume-show test01
+---------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Property | Value |
+---------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| attachments | [{u'device': u'/dev/vdc', u'server_id': u'65b24d9e-bf84-4808-b382-07249a98d2fd', u'id': u'1ac5b7ee-116a-4352-8536-3b538bc2d1ed', u'volume_id': u'1ac5b7ee-116a-4352-8536-3b538bc2d1ed'}] |
| availability_zone | nova |
| created_at | 2013-02-12T15:26:57.000000 |
| display_description | None |
| display_name | test01 |
| id | 1ac5b7ee-116a-4352-8536-3b538bc2d1ed |
| metadata | {} |
| size | 1 |
| snapshot_id | None |
| status | in-use |
| volume_type | None |
+---------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

この場合、接続したボリュームは接続先インスタンスからは/dev/vdcというデバイスファイルを通じてアクセスできる。

$ ls /dev/vd*
/dev/vda /dev/vda1 /dev/vdb /dev/vdc

接続したボリュームをインスタンスから取り外すには、nova volume-detachコマンドを使用する。コマンドに与える引数は次のとおりだ。

nova volume-attach ＜接続先インスタンス名もしくはID＞ ＜取り外すボリュームのID＞

たとえば先の例の場合、以下のようにする。

# nova volume-detach test01 1ac5b7ee-116a-4352-8536-3b538bc2d1ed

また、Webブラウザ経由でアクセスできるGUI管理コンソール「OpenStack Dashboard（horizon）からの操作も可能だ。この場合、「プロジェクト」タブの「ボリューム」画面でボリュームの一覧表示や作成、削除といった操作を行える（図1）。

CinderのバックエンドストレージとしてNFSを利用する

ボリュームを格納するストレージとしてNFSで公開されているディレクトリを利用することもできる。この場合、ボリュームはNFSで公開されているディレクトリ中にディスクイメージファイルとして作成され、1つのボリュームが1つのファイルに対応する。また、仮想マシンインスタンスを稼働させるホストは公開されているディレクトリをNFS経由でマウントしてディスクイメージファイルにアクセスする。

設定ファイルの編集

バックエンドストレージにNFSを利用する場合でも、Cinderのインストールおよび設定については基本的な同じだ。ただし、/etc/cinder/cinder.confファイルについては下記の設定項目が追加で必要となる。

volume_driver = cinder.volume.nfs.NfsDriver
nfs_shares_config = /etc/cinder/shares.conf
nfs_mount_point_base = /var/lib/cinder/mnt

「volume_driver」項目はCinderがボリュームの管理に使用するドライバを指定するもので、NFSを利用する場合は「cinder.volume.nfs.NfsDriver」を指定しておく。また、「nfs_shares_config」では利用するNFS共有ディレクトリを記述する設定ファイルのパスを、「nfs_mount_point_base」ではNFS共有ディレクトリをマウントするディレクトリを指定する。この例では、設定ファイルとして「/etc/cinder/shares.conf」を、NFS共有ディレクトリのマウント先に「/var/lib/cinder/mnt」を指定している。

使用するNFS共有ディレクトリの設定

続いて、/etc/cinder/shares.confファイルを作成し、使用するNFS共有ディレクトリを「＜ホスト名＞:＜ディレクトリ＞」という形で記述しておく。たとえば192.168.100.21というホスト上の「/var/nfs/openstack-volumes」というディレクトリを使用する場合、以下のように記述する。

192.168.100.21:/var/nfs/openstack-volumes

ここで指定したNFS共有ディレクトリは仮想マシンを稼働させるホストからマウントできるよう設定されている必要がある。たとえば今回の例では、NFS共有ディレクトリを提供するホストのexportsファイルに下記のように記述し、同じネットワーク内のすべてのホストからアクセスできるように設定している。

/var/nfs/openstack-volumes 192.168.100.0/24(rw,all_squash,sync)

rootwrap.dの設定

前述のとおり、Cinderの各種サービスはsudoコマンドを利用して一部の操作をroot権限で実行する。root権限で実行されるコマンドについては、/usr/share/cinder/rootwrap/ディレクトリおよび/etc/cinder/rootwrap.d/ディレクトリ以下に配置されたファイルに記述されているのだが、EPELで提供されているopenstack-cinderパッケージの場合、NFSを利用するための一部の設定が不足している。そのため、下記の操作を行って設定を追加しておく必要がある。

まず、/etc/cinder/rootwrap.d/ディレクトリを作成する。

# mkdir /etc/cinder/rootwrap.d/

続いて、このディレクトリ内にvolume.filtersというファイルを作成し、次の内容を記述しておく。

[Filters]

# cinder/volume/nfs.py
stat: CommandFilter, /usr/bin/stat, root
mount: CommandFilter, /bin/mount, root
df: CommandFilter, /bin/df, root
truncate: CommandFilter, /usr/bin/truncate, root
chmod: CommandFilter, /bin/chmod, root
rm: CommandFilter, /bin/rm, root

また、念のためパーミッションの変更もしておこう。

# chgrp -R cinder rootwrap.d

以上でCinder側の設定は完了だ。なお、バックエンドストレージにNFSを利用する場合、仮想マシンを稼働させるホストが使用するNFS共有ディレクトリをマウントできる必要がある。そのため、適切にファイアウォールの設定も行っておこう。

Nova側の設定

CinderのバックエンドとしてNFSを利用する場合でも、Nova側の設定はLVMを利用する場合と基本的に同じだ。ただし、デフォルトの設定ではNFS用のドライバを読み込まない設定になっているため、nova.confに次の1行を追加しておく必要がある。

libvirt_volume_drivers = "iscsi=nova.virt.libvirt.volume.LibvirtISCSIVolumeDriver,local=nova.virt.libvirt.volume.LibvirtVolumeDriver,fake=nova.virt.libvirt.volume.LibvirtFakeVolumeDriver,rbd=nova.virt.libvirt.volume.LibvirtNetVolumeDriver,sheepdog=nova.virt.libvirt.volume.LibvirtNetVolumeDriver,nfs=nova.virt.libvirt.volume_nfs.NfsVolumeDriver"

以上で、novaコマンドを使ってボリュームを作成したり、仮想マシンインスタンスとボリュームの接続が可能になるはずだ。

今後はnova-volumeの代わりにCinderの利用が推奨となる

2012年の春にリリースされているOpenStackの新版（コードネーム「Grizzly」）でもCinderには大きな変更は加えられない模様だが、今後セキュアなアタッチ機能やバックアップAPIの提供、ボリュームのクローン機能、ボリュームのリサイズ機能、起動ボリュームのメタデータ保持といった機能の追加が検討されているようだ。

さらにOpenStackでは今後、nova-volumeの廃止が予定されており、ボリュームストレージサービスとしてはCinderを利用することが推奨となっている。そのため、新たにOpenStack環境を構築する際はCinderを利用するようにしておこう。