OpenStack Queens（& Pike）の新機能を試す（後編）
OpenStackの直近2つのリリース、PikeとQueensについてご紹介をいたします。
テクノロジーコラム
- 2018年06月04日公開
前編ではPikeの新機能をご紹介したところで時間切れとなりましたが、今回はいよいよQueensの新機能をご紹介したいと思います。
前編：/column/tec/openstack_queens_pike_1/
[Queensの新機能を試す]
1つのボリュームを複数のＶＭに同時にアタッチ
従来のOpenStackでは、1つのボリュームは1つのVMにしかアタッチができませんでした。
もしアタッチ済みのボリュームを別のVMに読み込ませたくなった場合、一度デタッチしてから、別VMにアタッチする必要がありました（もしくはゲストOS内でNFSサーバを起動するなどの方法もありますが）。
しかしQueensリリースからは、ボリュームのマルチアタッチフラグをTrueにすれば、同時に複数のVMにアタッチすることができるようになりました。
これによって、たとえば、2つのVMをAct/Standbyとして用意して両方に同一のボリュームをアタッチし、Act側が故障したときStandby側を即座に同じディスクにアクセスさせる......といった運用が可能となります（従来だと、NFSサーバを立ててディスク共有するか、Act側がダウンした際にボリュームデタッチ＆Standby側へのアタッチを行う......等のひと手間が必要でした）。
ただし、もちろん、複数のゲストOSから同一のディスクを参照するにあたって、取り扱いを誤るとボリューム内のファイルシステムを破壊し得るため、利用にあたっては十分に注意してください。
リリースノートにも、以下の通り、ゲストにて共有read/writeアクセスをサポートするファイルシステムを利用するのはユーザの責任である......と明記されています。
It is the responsibility of the user to use a proper filesystem in the guest that supports shared read/write access.
説明は以上として、実際に試してみたいと思います。
なお、今回はお試し利用ですので、ファイルシステムの整合性については考慮しておりません。本格的に利用する場合は、ご注意ください。
最初に、ボリュームを作成します。このとき、multi-attach属性を付与しています。
$ openstack volume create --multi-attach --size 1 multi-attach-test +---------------------+--------------------------------------+ | Field | Value | +---------------------+--------------------------------------+ | attachments | [] | | availability_zone | nova | | bootable | false | | consistencygroup_id | None | | created_at | 2018-04-25T01:23:55.000000 | | description | None | | encrypted | False | | id | 8f159f5b-85a3-4bf4-bc87-6259d8cfea63 | | multiattach | True | | name | multi-attach-test | | properties | | | replication_status | None | | size | 1 | | snapshot_id | None | | source_volid | None | | status | creating | | type | lvmdriver-1 | | updated_at | None | | user_id | fa717c0054d6482ab45fe2f2816cd161 | +---------------------+--------------------------------------+
ボリュームのステータスがavailableになったら、あらかじめ用意しておいた二つのVMに対して、作成したボリュームをアタッチします。
マルチアタッチを行う場合、Nova APIのマイクロバージョンは2.60以上を指定する必要があることに注意してください。
$ openstack server list +--------------------------------------+--------+--------+--------------------------------------------------------------------+--------------------------+---------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+--------+--------+--------------------------------------------------------------------+--------------------------+---------+ | 12928246-2ba7-4d57-b371-ba421bf38be7 | test-2 | ACTIVE | private=10.0.0.3, fdff:4af3:e907:0:f816:3eff:fe60:a0f, 172.24.4.12 | cirros-0.3.5-x86_64-disk | m1.tiny | | 42cc4c2b-36ae-4627-af65-9c919b2bc82a | test-1 | ACTIVE | private=10.0.0.4, fdff:4af3:e907:0:f816:3eff:fe5b:28f4, 172.24.4.6 | cirros-0.3.5-x86_64-disk | m1.tiny | +--------------------------------------+--------+--------+--------------------------------------------------------------------+--------------------------+---------+ $ openstack --os-compute-api-version 2.60 server add volume 42cc4c2b-36ae-4627-af65-9c919b2bc82a 8f159f5b-85a3-4bf4-bc87-6259d8cfea63 $ openstack --os-compute-api-version 2.60 server add volume 12928246-2ba7-4d57-b371-ba421bf38be7 8f159f5b-85a3-4bf4-bc87-6259d8cfea63
アタッチ処理が完了したあとにボリュームの詳細情報を確認すると......期待通り、「attachments」欄に、アタッチ先のVM二つが表示されています！
長くなるので省略しますが、「openstack server show」でVMの詳細情報を確認しても、「volumes_attached」欄に同一のボリュームIDが出力されました。
$ openstack volume show 8f159f5b-85a3-4bf4-bc87-6259d8cfea63
+------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| attachments | [{u'server_id': u'42cc4c2b-36ae-4627-af65-9c919b2bc82a', u'attachment_id': u'b6858876-0f40-4532-b354-9b811f65f96d', u'attached_at': u'2018-04-25T03:00:00.000000', u'host_name': u'honjo-devstack-2', u'volume_id': u'8f159f5b-85a3-4bf4-bc87-6259d8cfea63', u'device': u'/dev/vdb', u'id': u'8f159f5b-85a3-4bf4-bc87-6259d8cfea63'}, {u'server_id': u'12928246-2ba7-4d57-b371-ba421bf38be7', u'attachment_id': u'bd57daae-441f-47e9-978a-3e90b53408c4', u'attached_at': u'2018-04-25T03:01:08.000000', u'host_name': u'honjo-devstack-2', u'volume_id':u'8f159f5b-85a3-4bf4-bc87-6259d8cfea63', u'device': u'/dev/vdb', u'id': u'8f159f5b-85a3-4bf4-bc87-6259d8cfea63'}] |
| availability_zone | nova |
| bootable | false |
| consistencygroup_id | None |
| created_at | 2018-04-25T01:23:55.000000 |
| description | None |
| encrypted | False |
| id | 8f159f5b-85a3-4bf4-bc87-6259d8cfea63 |
| multiattach | True |
| name | multi-attach-test |
| os-vol-tenant-attr:tenant_id | 8358ab204b764e23804abe1fca449d5e |
| properties | attached_mode='rw' |
| replication_status | None |
| size | 1 |
| snapshot_id | None |
| source_volid | None |
| status | in-use |
| type | lvmdriver-1 |
| updated_at | 2018-04-25T03:01:09.000000 |
| user_id | fa717c0054d6482ab45fe2f2816cd161 |
+------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
これまた長くなってしまうので手順は省略しますが、上記2つのVMの片方にSSHログインしてボリュームをフォーマットし、ファイルを作成したところ、もう片方のVMからも作成したファイルが確認できました。
正しくマルチアタッチが出来ているようです。
本マルチアタッチ機能、頻繁に利用する機能ではないかもしれませんが、OpenStack上に冗長性のあるシステムを構築したい場合、選択肢の一つになると考えています。
注意点を把握したうえで、ご利用をご検討ください。
Cinderのサービス一覧APIでバックエンドの状態を確認する
これまでcinderのList All Cinder Services APIでは、各cinderプロセスの死活は確認できたのですが、ボリュームが実際に作成されるバックエンド（ストレージ）の状態は確認ができませんでした。
そのため、運用者はさまざまな方法でバックエンドの死活監視を工夫してきたはずです（定期的に小さなボリュームの作成・削除を繰り返す、ストレージの監視を独自に行う、など......）。
しかし、Queensから、嬉しいことにList All Cinder Services APIでバックエンドの死活状態も確認ができるようになりました。
ここでは実際にその様子を見てみたいと思います。
バックエンド状態を取得できるのはCinder API v3.49以降なので、実行時に指定をします。
（openstack CLIだとマイクロバージョン指定ができないようなので、cinder CLIを利用しています）
$ cinder --os-volume-api-version 3.49 service-list +------------------+------------------------------------+------+---------+-------+----------------------------+---------+-----------------+---------------+ | Binary | Host | Zone | Status | State | Updated_at | Cluster | Disabled Reason | Backend State | +------------------+------------------------------------+------+---------+-------+----------------------------+---------+-----------------+---------------+ | cinder-scheduler | honjo-devstack-machine | nova | enabled | up | 2018-04-18T06:07:11.000000 | - | - | | | cinder-volume | honjo-devstack-machine@lvmdriver-1 | nova | enabled | up | 2018-04-18T06:07:11.000000 | - | - | up | +------------------+------------------------------------+------+---------+-------+----------------------------+---------+-----------------+---------------+
右端にBackend Stateが出力されました！
現在はバックエンドが有効のためupのままですが、利用不能状態になっていればdownになります。
（なおcinder-schedulerはバックエンドを持ちませんので、値は空欄となっています）
ただ、このBackend State表示ですが、ドライバ側に実装がないと正しく機能しません。
Queensリリース時点では大部分のドライバが未対応のようですので、本機能を利用したい場合、ドライバの対応状況をご確認ください。
終わりに
OpenStackも17回目のリリースを迎え、ますます便利な機能が増えてきました。
NTTテクノクロスは今回のように最新版を追って、より良い設計や運用を追求しております。
また、同時にコミュニティでサポートが終了したバージョンのサポートも行っております。
（以下に示すように）幅広いソリューションをご用意しておりますので、OpenStackについて何かお困りのことがございましたら、是非お声掛けください。
■定額・回数制でOpenStackについて質問できるチケットサービス：
■OpenStackクラウド基盤の構築から運用までNTTテクノクロスにお任せしたままでご利用いただける、マネージドサービス：
製品ページ準備中です。概要は以下をご覧ください。
/column/tec/openstack_days_tokyo_2017_1/
そのほか、コンサルや通常の構築業務などのご相談も承っております。
本ページ下部の連絡先にお問い合わせください。
OpenStack のワードマークは、米国とその他の国における OpenStack Foundation の登録商標/サービスマークまたは商標/サービスマークのいずれかであり、 OpenStack Foundation の許諾の下に使用されています。
NTTテクノクロスは、OpenStack Foundation や OpenStack コミュニティの関連会社ではなく、公認や出資も受けていません。
その他会社名、製品名などの固有名詞は、一般に該当する会社もしくは組織の商標または登録商標です。
