[ English | Indonesia | Deutsch | 日本語 ]

ユーザーによる運用

このガイドは OpenStack の運用者向けです。ユーザー向けの膨大なリファレンスを目指すものではありません。しかし運用者として、クラウド設備を使用する方法について基本的な理解を持つべきです。本章は、基本的なユーザーの観点から OpenStack を見ていきます。ユーザーが必要とすることを理解する手助けになります。また、トラブルのチケットを受け取ったときに、ユーザーの問題またはサービスの問題のどちらかを判断する手助けになります。取り扱っている主な概念はイメージ、フレーバー、セキュリティグループ、ブロックストレージ、共有ファイルシステムストレージおよびインスタンスです。

イメージ

OpenStack のイメージはしばしば「仮想マシンテンプレート」と考えることができます。イメージは ISO イメージのような標準的なインストールメディアの場合もあります。基本的に、インスタンスを起動するために使用されるブート可能なファイルシステムを含みます。

イメージの追加

いくつかの構築済みイメージが存在します。簡単に Image service の中にインポートできます。追加する一般的なイメージは、非常に小さく、テスト目的に使用される CirrOS イメージです。このイメージを追加するには、単に次のようにします。

$ wget http://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img
$ openstack image create --file cirros-0.3.5-x86_64-disk.img \
  --public --container-format bare \
  --disk-format qcow2 "cirros image"

openstack image-create コマンドでは、イメージに指定できる多数のオプションが用意されています。たとえば、 --min-disk オプションは、特定の容量のルートディスクを必要とするイメージ (例: 大きな Windows イメージ) のために有用です。これらのオプションを表示するには、次のようにします:

$ openstack help image create

既存のイメージのプロパティを表示するために、以下のコマンドを実行します。

$ openstack image show IMAGE_NAME_OR_UUID

署名済みイメージの追加

To provide a chain of trust from an end user to the Image service, and the Image service to Compute, an end user can import signed images that can be initially verified in the Image service, and later verified in the Compute service. Appropriate Image service properties need to be set to enable this signature feature.

注釈

Prior to the steps below, an asymmetric keypair and certificate must be generated. In this example, these are called private_key.pem and new_cert.crt, respectively, and both reside in the current directory. Also note that the image in this example is cirros-0.3.5-x86_64-disk.img, but any image can be used.

以下の手順が、署名付きイメージのために使用される署名を作成するために必要になります。

1. アップロードするためのイメージの取得

   $ wget http://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img
   

2. 秘密鍵を使用したイメージ署名の作成

   注釈

   以下の暗黙的な値が、この例において署名を作成するために使用されます。

   • 署名のハッシュ方法 = SHA-256

   • 署名の鍵形式 = RSA-PSS

   注釈

   以下のオプションが現在サポートされます。

   • 署名のハッシュ方法: SHA-224、SHA-256、SHA-384、SHA-512

   • 署名の鍵形式: DSA、ECC_SECT571K1、ECC_SECT409K1、ECC_SECT571R1、ECC_SECT409R1、ECC_SECP521R1、ECC_SECP384R1、RSA-PSS

   イメージの署名を生成して、base64 形式に変換します。

   $ openssl dgst -sha256 -sign private_key.pem -sigopt rsa_padding_mode:pss \
     -out image-file.signature cirros-0.3.5-x86_64-disk.img
   $ base64 -w 0 image-file.signature > signature_64
   $ cat signature_64
   'c4br5f3FYQV6Nu20cRUSnx75R/VcW3diQdsUN2nhPw+UcQRDoGx92hwMgRxzFYeUyydRTWCcUS2ZLudPR9X7rM
   THFInA54Zj1TwEIbJTkHwlqbWBMU4+k5IUIjXxHO6RuH3Z5f/SlSt7ajsNVXaIclWqIw5YvEkgXTIEuDPE+C4='
   

   注釈

   • Image API v1 は、複数行のイメージプロパティーをサポートしないので、上の '-w 0' が必要になります。

   • Image API v2 は複数行のイメージプロパティーをサポートします。そのため、このオプションは v2 で必要がありませんが、まだ使用できます。

3. コンテキストの作成

   $ python
   >>> from keystoneclient.v3 import client
   >>> keystone_client = client.Client(username='demo',
                                       user_domain_name='Default',
                                       password='password',
                                       project_name='demo',
                                       auth_url='http://localhost:5000/v3')
   
   >>> from oslo_context import context
   >>> context = context.RequestContext(auth_token=keystone_client.auth_token,
                                        tenant=keystone_client.project_id)
   

4. 証明書を DER 形式でエンコードします

   >>> from cryptography import x509 as cryptography_x509
   >>> from cryptography.hazmat import backends
   >>> from cryptography.hazmat.primitives import serialization
   >>> with open("new_cert.crt", "rb") as cert_file:
   >>>      cert = cryptography_x509.load_pem_x509_certificate(
                     cert_file.read(),
                     backend=backends.default_backend()
                     )
   >>> certificate_der = cert.public_bytes(encoding=serialization.Encoding.DER)
   

5. 証明書を DER 形式で Castellan にアップロードします

   >>> from castellan.common.objects import x_509
   >>> from castellan import key_manager
   >>> castellan_cert = x_509.X509(certificate_der)
   >>> key_API = key_manager.API()
   >>> cert_uuid = key_API.store(context, castellan_cert)
   >>> cert_uuid
   u'62a33f41-f061-44ba-9a69-4fc247d3bfce'
   

6. 署名のメタデータを付けて、イメージをイメージサービスにアップロードします

   注釈

   以下の署名のプロパティーが使用されます。

   • img_signature は signature_64 という署名を使用します

   • img_signature_certificate_uuid は、上のセクション 5 にある cert_uuid の値を使用します

   • img_signature_hash_method は、上のセクション 2 にある SHA-256 と一致します

   • img_signature_key_type は、上のセクション 2 にある RSA-PSS と一致します

   $ . openrc demo
   $ export OS_IMAGE_API_VERSION=2
   $ openstack image create --property name=cirrosSignedImage_goodSignature \
     --property is-public=true --container-format bare --disk-format qcow2 \
     --property img_signature='c4br5f3FYQV6Nu20cRUSnx75R/VcW3diQdsUN2nhPw+UcQRDoGx92hwMgRxzFYeUyydRTWCcUS2ZLudPR9X7rMTHFInA54Zj1TwEIbJTkHwlqbWBMU4+k5IUIjXxHO6RuH3Z5fSlSt7ajsNVXaIclWqIw5YvEkgXTIEuDPE+C4=' \
     --property img_signature_certificate_uuid='62a33f41-f061-44ba-9a69-4fc247d3bfce' \
     --property img_signature_hash_method='SHA-256' \
     --property img_signature_key_type='RSA-PSS' < ~/cirros-0.3.5-x86_64-disk.img
   

   注釈

   イメージ署名の最大文字数は255です。

7. KeystoneのURLを確認します。

   注釈

   デフォルトのkeystoneの設定はkeystoneがローカルホストにあることを想定しています、またそれは http://localhost:5000/v3 を glance-api.conf と nova-api.conf のファイルで定義されるエンドポイントURLとして使用します。

   [barbican]
   auth_endpoint = http://localhost:5000/v3
   

   注釈

   If Keystone is located remotely instead, edit the glance-api.conf and nova.conf files. In the [barbican] section, configre the auth_endpoint option:

   [barbican]
   auth_endpoint = https://192.168.245.9:5000/v3
   

8. Compute が署名付きイメージを起動するとき、署名が検証されます。

   注釈

   まず nova-compute を以下の手順でアップデートする必要があります。

   • cryptsetup がきちんとインストールされ、pythin-barbicanclient Python パッケージがインストールされていることを確認してください。

   • /etc/nova/nova.conf を編集して、以下のコードブロックにあるエントリーを追加することにより、Key Manager サービスをセットアップします。

   • The flag verify_glance_signatures enables Compute to automatically validate signed instances prior to its launch. This validation feature is enabled when the value is set to TRUE

   [key_manager]
   api_class = castellan.key_manager.barbican_key_manager.BarbicanKeyManager
   [glance]
   verify_glance_signatures = TRUE
   

   注釈

   api_class [keymgr] は Newton で非推奨になります。これ以降のリリースには、含まれるべきではありません。

プロジェクト間のイメージの共有

マルチテナントクラウド環境において、ユーザーはときどき、自分のイメージやスナップショットを他のプロジェクトと共有したいことがあります。これは、イメージの所有者がコマンドラインから glance ツールを使用することによりできます。

以下のように、イメージやスナップショットを他のプロジェクトと共有します。

1. イメージの UUID を取得します。

   $ openstack image list
   

2. イメージを共有したいプロジェクトの UUID を取得します。これを宛先プロジェクトと呼びましょう。残念ながら、管理者以外は、これを実行するために openstack コマンドを使用できません。最も簡単な解決方法は、クラウドの管理者やその宛先プロジェクトのユーザーから UUID を教えてもらうことです。

3. 情報がそろったら、openstack image add project コマンドを実行します。

   $ openstack image add project IMAGE_NAME_OR_UUID PROJECT_NAME_OR_UUID
   

   例えば

   $ openstack image add project 733d1c44-a2ea-414b-aca7-69decf20d810 \
     771ed149ef7e4b2b88665cc1c98f77ca
   

4. You now need to act in the target project scope.

   注釈

   You will not see the shared image yet. Therefore the sharing needs to be accepted.

   To accept the sharing, you need to update the member status:

   $ glance member-update IMAGE_UUID PROJECT_UUID accepted
   

   例えば

   $ glance member-update 733d1c44-a2ea-414b-aca7-69decf20d810 \
     771ed149ef7e4b2b88665cc1c98f77ca accepted
   

   これで、プロジェクト 771ed149ef7e4b2b88665cc1c98f77ca がイメージ 733d1c44-a2ea-414b-aca7-69decf20d810 にアクセスできます。

   Tip

   You can explicitly ask for pending member status to view shared images not yet accepted:

   $ glance image-list --member-status pending
   

イメージの削除

イメージを削除する場合、次のようにします。

$ openstack image delete IMAGE_NAME_OR_UUID

注意

Generally, deleting an image does not affect instances or snapshots that were based on the image. However, some drivers may require the original image to be present to perform a migration. For example, XenAPI live-migrate will work fine if the image is deleted, but libvirt will fail.

他の CLI オプション

すべてのオプションは、次のように確認できます。

$ glance help

または コマンドラインインターフェースリファレンス 。

Image service とデータベース

Image サービスがデータベースに保存しない唯一のものは、イメージ自体です。Image サービスのデータベースは、主要なテーブルが 2 つあります。

• images

• image_properties

データベースと SQL クエリーを直接使うことで、イメージの独自のリストやレポートを得ることができます。一般には、推奨されませんが、技術的にはデータベース経由でイメージのプロパティを更新できます。

Image service のデータベースクエリーの例

興味深い例の一つは、イメージとそのイメージの所有者の表の表示内容を変更することです。これは、所有者のユニーク ID を表示するようにするだけで実現できます。この例はさらに一歩進め、所有者の読みやすい形式の名前を表示します:

mysql> select glance.images.id,
              glance.images.name, keystone.tenant.name, is_public from
              glance.images inner join keystone.tenant on
              glance.images.owner=keystone.tenant.id;

もう一つの例は、特定のイメージに関するすべてのプロパティを表示することです。

mysql> select name, value from
              image_properties where id = <image_id>

フレーバー

仮想ハードウェアのテンプレートは、OpenStack において「フレーバー」と呼ばれます。メモリー、ディスク、CPU コア数などを定義します。デフォルトインストールでは、5 つのフレーバーが存在します。

これらは管理ユーザーにより設定できます。nova-api サーバーにおいて /etc/nova/policy.json の compute_extension:flavormanage にあるアクセス制限を再定義することにより、この権限を他のユーザーに委譲することもできます。次のように、お使いのシステムで利用可能なフレーバーの一覧を取得できます。

$ openstack flavor list
+----+-----------+-------+------+-----------+-------+-----------+
| ID | Name      |   RAM | Disk | Ephemeral | VCPUs | Is Public |
+----+-----------+-------+------+-----------+-------+-----------+
| 1  | m1.tiny   |   512 |    1 |         0 |     1 | True      |
| 2  | m1.small  |  2048 |   20 |         0 |     1 | True      |
| 3  | m1.medium |  4096 |   40 |         0 |     2 | True      |
| 4  | m1.large  |  8192 |   80 |         0 |     4 | True      |
| 5  | m1.xlarge | 16384 |  160 |         0 |     8 | True      |
+----+-----------+-------+------+-----------+-------+-----------+

openstack flavor create コマンドにより、権限のあるユーザーが新しいフレーバーを作成できます。さらなるフレーバーの操作コマンドは、次のコマンドを用いて表示できます。

$ openstack help | grep flavor

フレーバーは、数多くのパラメーターを定義します。これにより、ユーザーが実行する仮想マシンの種類を選択できるようになります。ちょうど、物理サーバーを購入する場合と同じようなことです。表: フレーバーのパラメーター は、設定できる要素の一覧です。とくに extra_specs に注意してください。これは、メモリー、CPU、ディスクの容量以外にもかなり柔軟に、自由形式で特徴を定義するために使用できます。

表: フレーバーのパラメーター

カラム	説明
ID	フレーバー向けの一意な ID (整数や UUID)。
名前	慣習として xx.size_name などの内容を表す名前を使用しますが、必須ではありません。いくつかのサードパーティツールはその名称に依存しているかもしれません。
Memory_MB	メガバイト単位の仮想マシンメモリー。
ディスク	ギガバイト単位の仮想ルートディスク容量。これはベースイメージがコピーされる一時ディスクです。永続的なボリュームからブートするとき、これは使用されません。「0」という容量は特別な値で、一時ルートボリュームの容量としてベースイメージのネイティブ容量をそのまま使用することを意味します。
エフェメラル	二次的な一時データディスクの容量を指定します。これは空の、フォーマットされていないディスクです。インスタンスの生存期間だけ存在します。
スワップ	インスタンスに割り当てられるスワップ空間。これはオプションです。
仮想 CPU	インスタンスに存在する仮想 CPU 数。
RXTX_Factor	作成したサーバーが接続されたネットワークにおける定義と異なる帯域制限を持てるようにするプロパティ。これはオプションです。この要素はネットワークの rxtx_base プロパティの倍数です。既定の値は 1.0 です (つまり、接続されたネットワークと同じです)。
Is_Public	フレーバーがすべてのユーザーに利用可能であるか、プライベートであるかを示す論理値。プライベートなフレーバーは、現在のテナントをそれらに割り当てません。デフォルトは True です。
extra_specs	フレーバーを実行できるコンピュートノードに関する追加の制限。これはオプションです。これは、コンピュートノードにおいて対応するキーバリューペアとして実装され、コンピュートノードでの対応するキーバリューペアと一致するものでなければいけません。(GPU ハードウェアを持つコンピュートノードのみにおいて実行するフレーバーのように) 特別なリソースのようなものを実装するために使用できます。

プライベートフレーバー

ユーザーが、取り組んでいるプロジェクト向けに独自にチューニングした、カスタムフレーバーを必要とするかもしれません。例えば、ユーザーが 128 GB メモリーを必要とするかもしれません。前に記載したとおり、新しいフレーバーを作成する場合、ユーザーがカスタムフレーバーにアクセスできるでしょう。しかし、クラウドにある他のすべてのクラウドもアクセスできます。ときどき、この共有は好ましくありません。この場合、すべてのユーザーが 128 GB メモリーのフレーバーにアクセスでき、クラウドのリソースが非常に高速に容量不足になる可能性があります。これを防ぐために、nova flavor-access-add コマンドを使用して、カスタムフレーバーへのアクセスを制限できます。

$ nova flavor-access-add FLAVOR_ID PROJECT_ID

以下のように、フレーバーのアクセスリストを表示します。

$ nova flavor-access-list [--flavor FLAVOR_ID]

Tip

フレーバーへのアクセスが制限されると、明示的にアクセスを許可されたプロジェクト以外は、フレーバーを参照できなくなります。これには admin プロジェクトも含まれます。元のプロジェクトに加えて、きちんと admin プロジェクトを追加してください。

カスタムフレーバーとプライベートフレーバーに特別な数値範囲を割り当てることも有用です。UNIX 系システムでは、システムアカウント以外は通常 500 から始まります。同様の方法をカスタムフレーバーにも使用できます。これは、フレーバーがカスタムフレーバー、プライベートフレーバー、パブリックフレーバーであるかをクラウド全体で簡単に識別する役に立ちます。

どのように既存のフレーバーを変更しますか?

OpenStack dashboard は、既存のフレーバーを削除し、同じ名前の新しいものを作成することにより、フレーバーを変更する機能を模倣しています。

セキュリティグループ

OpenStack の新しいユーザーがよく経験する問題が、インスタンスを起動するときに適切なセキュリティグループを設定できず、その結果、ネットワーク経由でインスタンスにアクセスできないというものです。

セキュリティグループは、インスタンスのネットワークに適用される、IP フィルタールールの組です。それらはプロジェクト固有です。プロジェクトメンバーがそれらのグループの標準ルールを編集でき、新しいルールを追加できます。すべてのプロジェクトが "default" セキュリティグループを持ちます。他のセキュリティグループが定義されていないインスタンスには "default" セキュリティグループが適用されます。"default" セキュリティグループは、ルールを変更しない限り、すべての受信トラフィックを拒否します。

Tip

前の章で述べたとおり、セキュリティグループごとのルール数は quota_security_group_rules により制御されます。また、プロジェクトごとに許可されるセキュリティグループ数は quota_security_groups クォータにより制御されます。

セキュリティグループのエンドユーザー設定

現在のプロジェクトのセキュリティグループが、OpenStack dashboard の アクセスとセキュリティ にあります。既存のグループの詳細を表示するには、セキュリティグループの 編集 を選択します。自明ですが、この 編集 インターフェースから既存のグループを変更できます。新しいグループを作成するための セキュリティグループの作成 ボタンが、メインの アクセスとセキュリティ ページにあります。同等のコマンドラインを説明するとき、これらの項目において使用される用語について説明します。

openstack コマンドを用いたセットアップ方法

お使いの環境で Neutron を使用している場合、openstack コマンドを使用して、セキュリティグループを設定できます。以下のコマンドを使用して、作業しているプロジェクトのセキュリティグループの一覧を取得します。

$ openstack security group list
+------------------------+---------+------------------------+-------------------------+
| ID                     | Name    | Description            | Project                 |
+------------------------+---------+------------------------+-------------------------+
| 3bef30ed-442d-4cf1     | default | Default security group | 35e3820f7490493ca9e3a5e |
| -b84d-2ba50a395599     |         |                        | 685393298               |
| aaf1d0b7-98a0-41a3-ae1 | default | Default security group | 32e9707393c34364923edf8 |
| 6-a58b94503289         |         |                        | f5029cbfe               |
+------------------------+---------+------------------------+-------------------------+

セキュリティグループの詳細を表示する方法:

$ openstack security group show 3bef30ed-442d-4cf1-b84d-2ba50a395599
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field           | Value                                                                                                                                                                                  |
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| created_at      | 2016-11-08T21:55:19Z                                                                                                                                                                   |
| description     | Default security group                                                                                                                                                                 |
| id              | 3bef30ed-442d-4cf1-b84d-2ba50a395599                                                                                                                                                   |
| name            | default                                                                                                                                                                                |
| project_id      | 35e3820f7490493ca9e3a5e685393298                                                                                                                                                       |
| project_id      | 35e3820f7490493ca9e3a5e685393298                                                                                                                                                       |
| revision_number | 1                                                                                                                                                                                      |
| rules           | created_at='2016-11-08T21:55:19Z', direction='egress', ethertype='IPv6', id='1dca4cac-d4f2-46f5-b757-d53c01a87bdf', project_id='35e3820f7490493ca9e3a5e685393298',                     |
|                 | revision_number='1', updated_at='2016-11-08T21:55:19Z'                                                                                                                                 |
|                 | created_at='2016-11-08T21:55:19Z', direction='egress', ethertype='IPv4', id='2d83d6f2-424e-4b7c-b9c4-1ede89c00aab', project_id='35e3820f7490493ca9e3a5e685393298',                     |
|                 | revision_number='1', updated_at='2016-11-08T21:55:19Z'                                                                                                                                 |
|                 | created_at='2016-11-08T21:55:19Z', direction='ingress', ethertype='IPv4', id='62b7d1eb-b98d-4707-a29f-6df379afdbaa', project_id='35e3820f7490493ca9e3a5e685393298', remote_group_id    |
|                 | ='3bef30ed-442d-4cf1-b84d-2ba50a395599', revision_number='1', updated_at='2016-11-08T21:55:19Z'                                                                                        |
|                 | created_at='2016-11-08T21:55:19Z', direction='ingress', ethertype='IPv6', id='f0d4b8d6-32d4-4f93-813d-3ede9d698fbb', project_id='35e3820f7490493ca9e3a5e685393298', remote_group_id    |
|                 | ='3bef30ed-442d-4cf1-b84d-2ba50a395599', revision_number='1', updated_at='2016-11-08T21:55:19Z'                                                                                        |
| updated_at      | 2016-11-08T21:55:19Z                                                                                                                                                                   |
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

デフォルトは拒否なので、これらのルールはすべて「許可」形式のルールです。この例は、すべての IP から、すべてのプロトコルの範囲全体が許可されることを示しています。このセクションは、最も一般的なセキュリティーグループルールのパラメーターを説明します。

方向

セキュリティグループルールが適用される通信方向。有効な値は ingress と egress です。

remote_ip_prefix

この属性値は、IP パケットの送信元 IP アドレスとして、指定された IP プレフィックスと一致します。

プロトコル

セキュリティーグループルールによって突き合わせが行われるプロトコル。有効な値は、 null、tcp、udp、 icmp および icmpv6 です。

port_range_min

セキュリティグループルールに一致する、ポート番号の範囲の最小値。プロトコルが TCP や UDP の場合、この値は port_range_max 属性の値以下でなければいけません。プロトコルが ICMP あるいは ICMPv6 の場合、この値はそれぞれ ICMP あるいは ICMPv6 タイプでなければいけません。

port_range_max

セキュリティグループルールに一致する、ポート番号の範囲の最大値。port_range_min 属性が port_range_max 属性を制限します。プロトコルが ICMP または ICMPv6 の場合、この値はそれぞれ ICMP または ICMPv6 タイプでなければいけません。

ethertype

IPv4 または IPv6 である必要があります。CIDR 形式のアドレスが受信ルールまたは送信ルールに一致する必要があります。

新しいセキュリティグループを追加するとき、内容を表す簡潔な名前をつけるべきです。この名前はインスタンスの簡単な説明など、より長い説明フィールドが使用されないところで使用されます。インスタンスがセキュリティグループ http を使っているのを見れば、bobs_group や secgrp1 よりはずっと理解しやすいことでしょう。

この例は、インターネットのどこからでも Web 通信を許可するセキュリティグループを作成します。このグループを global_http と呼ぶことにします。許可されるものと許可されるところを要約した、明白で簡潔な名前になっています。コマンドラインから以下のようにします。

$ openstack security group create global_http --description "allow web traffic from the Internet"
Created a new security_group:
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field           | Value                                                                                                                                                                                  |
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| created_at      | 2016-11-10T16:09:18Z                                                                                                                                                                   |
| description     | allow web traffic from the Internet                                                                                                                                                    |
| headers         |                                                                                                                                                                                        |
| id              | 70675447-1b92-4102-a7ea-6a3ca99d2290                                                                                                                                                   |
| name            | global_http                                                                                                                                                                            |
| project_id      | 32e9707393c34364923edf8f5029cbfe                                                                                                                                                       |
| project_id      | 32e9707393c34364923edf8f5029cbfe                                                                                                                                                       |
| revision_number | 1                                                                                                                                                                                      |
| rules           | created_at='2016-11-10T16:09:18Z', direction='egress', ethertype='IPv4', id='e440b13a-e74f-4700-a36f-9ecc0de76612', project_id='32e9707393c34364923edf8f5029cbfe',                     |
|                 | revision_number='1', updated_at='2016-11-10T16:09:18Z'                                                                                                                                 |
|                 | created_at='2016-11-10T16:09:18Z', direction='egress', ethertype='IPv6', id='0debf8cb-9f1d-45e5-98db-ee169c0715fe', project_id='32e9707393c34364923edf8f5029cbfe',                     |
|                 | revision_number='1', updated_at='2016-11-10T16:09:18Z'                                                                                                                                 |
| updated_at      | 2016-11-10T16:09:18Z                                                                                                                                                                   |
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

作成後すぐでは、セキュリティグループは送信ルールのみを許可します。やりたいことを行うために、いくつかのルールを追加する必要があります。

$ openstack security group rule create --help
usage: openstack security group rule create [-h]
                                            [-f {json,shell,table,value,yaml}]
                                            [-c COLUMN]
                                            [--max-width <integer>]
                                            [--noindent] [--prefix PREFIX]
                                            [--remote-ip <ip-address> | --remote-group <group>]
                                            [--dst-port <port-range>]
                                            [--icmp-type <icmp-type>]
                                            [--icmp-code <icmp-code>]
                                            [--protocol <protocol>]
                                            [--ingress | --egress]
                                            [--ethertype <ethertype>]
                                            [--project <project>]
                                            [--project-domain <project-domain>]
                                            <group>

$ openstack security group rule create --ingress --ethertype IPv4 \
  --protocol tcp --remote-ip 0.0.0.0/0 global_http

Created a new security group rule:
+-------------------+--------------------------------------+
| Field             | Value                                |
+-------------------+--------------------------------------+
| created_at        | 2016-11-10T16:12:27Z                 |
| description       |                                      |
| direction         | ingress                              |
| ethertype         | IPv4                                 |
| headers           |                                      |
| id                | 694d30b1-1c4d-4bb8-acbe-7f1b3de2b20f |
| port_range_max    | None                                 |
| port_range_min    | None                                 |
| project_id        | 32e9707393c34364923edf8f5029cbfe     |
| project_id        | 32e9707393c34364923edf8f5029cbfe     |
| protocol          | tcp                                  |
| remote_group_id   | None                                 |
| remote_ip_prefix  | 0.0.0.0/0                            |
| revision_number   | 1                                    |
| security_group_id | 70675447-1b92-4102-a7ea-6a3ca99d2290 |
| updated_at        | 2016-11-10T16:12:27Z                 |
+-------------------+--------------------------------------+

新しく追加されたルールのみが出力されますが、この操作は追加操作です:

$ openstack security group show global_http
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field           | Value                                                                                                                                                                                  |
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| created_at      | 2016-11-10T16:09:18Z                                                                                                                                                                   |
| description     | allow web traffic from the Internet                                                                                                                                                    |
| id              | 70675447-1b92-4102-a7ea-6a3ca99d2290                                                                                                                                                   |
| name            | global_http                                                                                                                                                                            |
| project_id      | 32e9707393c34364923edf8f5029cbfe                                                                                                                                                       |
| project_id      | 32e9707393c34364923edf8f5029cbfe                                                                                                                                                       |
| revision_number | 2                                                                                                                                                                                      |
| rules           | created_at='2016-11-10T16:09:18Z', direction='egress', ethertype='IPv6', id='0debf8cb-9f1d-45e5-98db-ee169c0715fe', project_id='32e9707393c34364923edf8f5029cbfe',                     |
|                 | revision_number='1', updated_at='2016-11-10T16:09:18Z'                                                                                                                                 |
|                 | created_at='2016-11-10T16:12:27Z', direction='ingress', ethertype='IPv4', id='694d30b1-1c4d-4bb8-acbe-7f1b3de2b20f', project_id='32e9707393c34364923edf8f5029cbfe', protocol='tcp',    |
|                 | remote_ip_prefix='0.0.0.0/0', revision_number='1', updated_at='2016-11-10T16:12:27Z'                                                                                                   |
|                 | created_at='2016-11-10T16:09:18Z', direction='egress', ethertype='IPv4', id='e440b13a-e74f-4700-a36f-9ecc0de76612', project_id='32e9707393c34364923edf8f5029cbfe',                     |
|                 | revision_number='1', updated_at='2016-11-10T16:09:18Z'                                                                                                                                 |
| updated_at      | 2016-11-10T16:12:27Z                                                                                                                                                                   |
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

逆の操作が openstack security group rule delete です。セキュリティーグループのルールの ID を指定します。openstack security group delete を使用して、セキュリティグループ全体を削除できます。

インスタンスのクラスター向けにセキュリティグループのルールを作成するために、リモートグループを使用します。

リモートグループは許可されたソースの CIDR を動的に定義する方法です。ユーザーがリモートグループ (セキュリティグループ名) を指定します。これにより、指定されたリモートグループを使用する、ユーザーの他のインスタンスが動的にすべて選択されます。この動的な選択により、クラスターのそれぞれの新しいメンバーを許可する、個別のルールの必要性を軽減できます。

コードは、上の openstack security group rule create の例と似ています。RemoteGroup を使用するために、--remote-ip の代わりに --remote-group を指定します。例:

$ openstack security group rule create --ingress \
  --ethertype IPv4 --protocol tcp \
  --remote-group global_http cluster

"cluster" ルールにより、global-http グループを使用する他のすべてのインスタンスから SSH アクセスが許可されます。

Block Storage

OpenStack のボリュームは、インスタンスから接続および切断できる、永続的なブロックストレージデバイスです。ただし、一度に接続できるのは 1 インスタンスだけです。外部ハードディスクと似ています。ネットワークファイルシステムやオブジェクトストアがしているような共有ストレージは提供されません。ブロックデバイス上にファイルシステムを構築し、それをマウントするかどうかは、インスタンス内のオペレーティングシステムに任されます。

他のリムーバブルディスク技術と同じように、ディスクを取り外す前に、オペレーティングシステムがそのディスクを使用しないようにすることが重要です。Linux インスタンスにおいて、一般的にボリュームからマウントされているすべてのファイルシステムをアンマウントする必要があります。OpenStack Volume Service は、インスタンスから安全にボリュームを取り外すことができるかはわかりません。そのため、指示されたことを実行します。ボリュームに書き込み中にインスタンスからボリュームの切断を、ユーザーが Volume Service に指示すると、何らかのレベルのファイルシステム破損が起きる可能性があります。それだけでなく、デバイスを使用していたインスタンスの中のプロセスがエラーを起こす可能性もあります。

ブロックデバイスにアクセスするために、インスタンスのオペレーティングシステムにおいて必要となる手順に、OpenStack 固有の事項はありません。初めて使用するときにフォーマットが必要になる、デバイスを取り外すときに注意する、などが考えられます。固有の事項は、新しいボリュームを作成し、それらをインスタンスに接続および切断する方法です。これらの操作は、ダッシュボードの ボリューム ページからすべて実行できます。または、 openstack コマンドラインクライアントを使用します。

新しいボリュームを追加する際に必要なのは、名前とギガバイト単位のボリューム容量だけです。これらを ボリュームの作成 ウェブフォームに記入します。または、コマンドラインを使用します:

$ openstack volume create volume1 --size 10

これは 10 GB のボリュームを作成します。既存のボリュームの一覧を表示するには以下のようにします。それらが接続されているインスタンスがあれば、インスタンス情報も表示されます:

$ openstack volume list
+--------------------------------------+--------------+--------+------+-------------+
| ID                                   | Display Name | Status | Size | Attached to |
+--------------------------------------+--------------+--------+------+-------------+
| 6cf4114a-56b2-476b-acf7-7359d8334aa2 | volume1      | error  |   10 |             |
+--------------------------------------+--------------+--------+------+-------------+

OpenStack Block Storage では、ボリュームのスナップショットを作成することもできます。これはブロックレベルのスナップショットであることを覚えておいてください。これはクラッシュに対する一貫性があります。そのため、スナップショットが取得されるとき、ボリュームがインスタンスに接続されていないことが最良です。ボリュームが接続されたインスタンスにおいて使用されていなければ、次に良いです。ボリュームが高負荷にある場合、スナップショットによりファイルシステムの不整合が起こる可能性があります。実際、デフォルト設定では、Volume Service はイメージに接続されたボリュームのスナップショットを取得しません。ただし、強制的に実行することができます。ボリュームのスナップショットを取得するには、ダッシュボードの ボリューム ページにおいて、ボリューム名の隣にあるアクション項目から スナップショットの作成 を選択します。または、コマンドラインから次のようにします:

$ openstack help snapshot create
usage: openstack snapshot create [-h] [-f {json,shell,table,value,yaml}]
                                 [-c COLUMN] [--max-width <integer>]
                                 [--noindent] [--prefix PREFIX]
                                 [--name <name>] [--description <description>]
                                 [--force] [--property <key=value>]
                                 <volume>

Create new snapshot

positional arguments:
  <volume>              Volume to snapshot (name or ID)

optional arguments:
  -h, --help            show this help message and exit
  --name <name>         Name of the snapshot
  --description <description>
                        Description of the snapshot
  --force               Create a snapshot attached to an instance. Default is
                        False
  --property <key=value>
                        Set a property to this snapshot (repeat option to set
                        multiple properties)

output formatters:
  output formatter options

  -f {json,shell,table,value,yaml}, --format {json,shell,table,value,yaml}
                        the output format, defaults to table
  -c COLUMN, --column COLUMN
                        specify the column(s) to include, can be repeated

table formatter:
  --max-width <integer>
                        Maximum display width, <1 to disable. You can also use
                        the CLIFF_MAX_TERM_WIDTH environment variable, but the
                        parameter takes precedence.

json formatter:
  --noindent            whether to disable indenting the JSON

shell formatter:
  a format a UNIX shell can parse (variable="value")

  --prefix PREFIX       add a prefix to all variable names

注釈

Block Storage ボリュームの更新 (例えばリサイズや譲渡など) に関する詳細は、 OpenStack エンドユーザーガイド を参照してください。

ブロックストレージの作成エラー

ユーザーがボリュームを作成しようとし、すぐにエラー状態になれば、トラブル解決のために最適な方法は cinder ログファイルをボリュームの UUID で grep することです。まずクラウドコントローラーにあるログファイルを調べます。次に、ボリュームを作成しようとしたストレージノードのログファイルを調べます:

# grep 903b85d0-bacc-4855-a261-10843fc2d65b /var/log/cinder/*.log

Shared File Systems サービス

Similar to Block Storage, the Shared File System is a persistent storage, called share, that can be used in multi-tenant environments. Users create and mount a share as a remote file system on any machine that allows mounting shares, and has network access to share exporter. This share can then be used for storing, sharing, and exchanging files. The default configuration of the Shared File Systems service depends on the back-end driver the admin chooses when starting the Shared File Systems service. For more information about existing back-end drivers, see Share Backends of Shared File Systems service Developer Guide. For example, in case of OpenStack Block Storage based back-end is used, the Shared File Systems service cares about everything, including VMs, networking, keypairs, and security groups. Other configurations require more detailed knowledge of shares functionality to set up and tune specific parameters and modes of shares functioning.

共有はリモートでマウント可能なファイルシステムです、そのためユーザは共有を複数のホストにマウントでき、同時に複数ユーザによって複数ホストからアクセスすることができます。共有ファイルシステムサービスを用いて、共有により非常に多くのオペレーションを実施することができます。

• 共有の作成、更新、削除、強制削除

• 共有のアクセスルールの変更、共有状態のリセット

• 既存のユーザまたはテナントのクォータを表示します

• 共有ネットワークの作成

• 新しい共有種別の作成

• Perform operations with share snapshots: create, change name, create a share from a snapshot, delete

• 整合性グループの操作

• セキュリティサービスを指定する。

For more information on share management see Share management in OpenStack Manila Administrator Guide. As to Security services, you should remember that different drivers support different authentication methods, while generic driver does not support Security Services at all (see section Security services in OpenStack Manila Administrator Guide).

You can create a share in a network, list shares, and show information for, update, and delete a specified share. You can also create snapshots of shares (see Share snapshots in OpenStack Manila Administrator Guide).

There are default and specific share types that allow you to filter or choose back-ends before you create a share. Functions and behaviour of share type is similar to Block Storage volume type (see Share types in OpenStack Manila Administrator Guide).

To help users keep and restore their data, Shared File Systems service provides a mechanism to create and operate snapshots (see Share snapshots in OpenStack Manila Administrator Guide).

A security service stores configuration information for clients for authentication and authorization. Inside Manila a share network can be associated with up to three security types (for detailed information see Security services in OpenStack Manila Administrator Guide).

• LDAP

• Kerberos

• Microsoft Active Directory

Shared File Systems service differs from the principles implemented in Block Storage. Shared File Systems service can work in two modes:

• Without interaction with share networks, in so called "no share servers" mode.

• 共有ネットワークに接続する

Networking service is used by the Shared File Systems service to directly operate with share servers. For switching interaction with Networking service on, create a share specifying a share network. To use "share servers" mode even being out of OpenStack, a network plugin called StandaloneNetworkPlugin is used. In this case, provide network information in the configuration: IP range, network type, and segmentation ID. Also you can add security services to a share network (see section “Networking” in OpenStack Manila Administrator Guide).

The main idea of consistency groups is to enable you to create snapshots at the exact same point in time from multiple file system shares. Those snapshots can be then used for restoring all shares that were associated with the consistency group.

Shared File System storage allows administrators to set limits and quotas for specific tenants and users. Limits are the resource limitations that are allowed for each tenant or user. Limits consist of:

• レートリミット

• 絶対制限

Rate limits control the frequency at which users can issue specific API requests. Rate limits are configured by administrators in a config file. Also, administrator can specify quotas also known as max values of absolute limits per tenant. Whereas users can see only the amount of their consumed resources. Administrator can specify rate limits or quotas for the following resources:

• すべての共有のために利用可能な容量の合計

• 共有の最大数

• 共有ネットワークの最大数

• 共有のスナップショットの最大数

• すべてのスナップショットの合計数

• Type and number of API calls that can be made in a specific time interval

User can see his rate limits and absolute limits by running commands manila rate-limits and manila absolute-limits respectively. For more details on limits and quotas see Quotas and limits of "Share management" section of OpenStack Administrator Guide document.

このセクションは、主要な Shared File Systems サービスの機能を説明するために、いくつかの重要なユースケースを示します。

• 共有の作成

• 共有の運用

• 共有へのアクセス権の管理

• スナップショットの作成

• 共有ネットワークの作成

• 共有ネットワークの管理

注釈

Shared File Systems service cannot warn you beforehand if it is safe to write a specific large amount of data onto a certain share or to remove a consistency group if it has a number of shares assigned to it. In such a potentially erroneous situations, if a mistake happens, you can expect some error message or even failing of shares or consistency groups into an incorrect status. You can also expect some level of system corruption if a user tries to unmount an unmanaged share while a process is using it for data transfer.

共有の作成

このセクションでは、簡単な共有を作成するプロセスについて説明します。いつくかのステップから構成されます。

• 共有ファイルシステムサービスに適切な共有のタイプが定義されているかどうか確認してください。

• もしこのような共有のタイプが存在しない場合は、他のユーザが利用可能になる前にコマンド manila type-create を利用して作成する必要があります。

• 共有ネットワークを利用することはオプションになります。しかしもし必要とするのであれば、コマンド manila share-network-list を利用して、共有ファイルシステムで適切なネットワークが定義されているかどうかを確認してください。共有ネットワークの作成に関する情報は、このキャプターの下に記述されている 共有ネットワークの作成 を見てください。

• manila create を使用して、パブリック共有を作成します。

• 共有が正しく作成され、利用可能であることを確認します (共有の状態を確認し、エクスポートされている場所を確認します)。

Below is the same whole procedure described step by step and in more detail.

注釈

始める前に共有ファイルシステム・サービスがOpenStackクラスタにインストールされて利用可能になっているか確かめてください。

デフォルトでは、共有ファイルシステムサービスでは共有タイプはありません。ですので必要なものが既に作成されているかどうかを確認してください。

$ manila type-list
+------+--------+-----------+-----------+----------------------------------+----------------------+
| ID   | Name   | Visibility| is_default| required_extra_specs             | optional_extra_specs |
+------+--------+-----------+-----------+----------------------------------+----------------------+
| c0...| default| public    | YES       | driver_handles_share_servers:True| snapshot_support:True|
+------+--------+-----------+-----------+----------------------------------+----------------------+

もし共有タイプのリストが空もしくは必要なものが含まれていない場合、次のコマンドを利用して必要な共有タイプを作成してください。

$ manila type-create netapp1 False --is_public True

このコマンドは、次のパラメーターを持つパブリックな共有を作成します: name = netapp1, spec_driver_handles_share_servers = False

You can now create a public share with my_share_net network, default share type, NFS shared file systems protocol, and 1 GB size:

$ manila create nfs 1 --name "Share1" --description "My first share" \
  --share-type default --share-network my_share_net --metadata aim=testing --public
+-----------------------------+--------------------------------------+
| Property                    | Value                                |
+-----------------------------+--------------------------------------+
| status                      | creating                             |
| share_type_name             | default                              |
| description                 | My first share                       |
| availability_zone           | None                                 |
| share_network_id            | 9c187d23-7e1d-4d91-92d0-77ea4b9b9496 |
| share_server_id             | None                                 |
| host                        |                                      |
| access_rules_status         | active                               |
| snapshot_id                 | None                                 |
| is_public                   | True                                 |
| task_state                  | None                                 |
| snapshot_support            | True                                 |
| id                          | edd82179-587e-4a87-9601-f34b2ca47e5b |
| size                        | 1                                    |
| name                        | Share1                               |
| share_type                  | e031d5e9-f113-491a-843f-607128a5c649 |
| has_replicas                | False                                |
| replication_type            | None                                 |
| created_at                  | 2016-03-20T00:00:00.000000           |
| share_proto                 | NFS                                  |
| consistency_group_id        | None                                 |
| source_cgsnapshot_member_id | None                                 |
| project_id                  | e81908b1bfe8468abb4791eae0ef6dd9     |
| metadata                    | {u'aim': u'testing'}                 |
+-----------------------------+--------------------------------------+

共有が共有一覧にあることを確認して、正常に作成されたことを確認します。

$ manila list
+----+-------+-----+------------+-----------+-------------------------------+----------------------+
| ID | Name  | Size| Share Proto| Share Type| Export location               | Host                 |
+----+-------+-----+------------+-----------+-------------------------------+----------------------+
| a..| Share1| 1   | NFS        | c0086...  | 10.254.0.3:/shares/share-2d5..| manila@generic1#GEN..|
+----+-------+-----+------------+-----------+-------------------------------+----------------------+

Check the share status and see the share export location. After creation, the share status should become available:

$ manila show Share1
+-----------------------------+----------------------------------------------------------------------+
| Property                    | Value                                                                |
+-----------------------------+----------------------------------------------------------------------+
| status                      | available                                                            |
| share_type_name             | default                                                              |
| description                 | My first share                                                       |
| availability_zone           | nova                                                                 |
| share_network_id            | 9c187d23-7e1d-4d91-92d0-77ea4b9b9496                                 |
| export_locations            |                                                                      |
|                             | path = 10.254.0.3:/shares/share-18cb05be-eb69-4cb2-810f-91c75ef30f90 |
|                             | preferred = False                                                    |
|                             | is_admin_only = False                                                |
|                             | id = d6a82c0d-36b0-438b-bf34-63f3932ddf4e                            |
|                             | share_instance_id = 18cb05be-eb69-4cb2-810f-91c75ef30f90             |
|                             | path = 10.0.0.3:/shares/share-18cb05be-eb69-4cb2-810f-91c75ef30f90   |
|                             | preferred = False                                                    |
|                             | is_admin_only = True                                                 |
|                             | id = 51672666-06b8-4741-99ea-64f2286f52e2                            |
|                             | share_instance_id = 18cb05be-eb69-4cb2-810f-91c75ef30f90             |
| share_server_id             | ea8b3a93-ab41-475e-9df1-0f7d49b8fa54                                 |
| host                        | manila@generic1#GENERIC1                                             |
| access_rules_status         | active                                                               |
| snapshot_id                 | None                                                                 |
| is_public                   | True                                                                 |
| task_state                  | None                                                                 |
| snapshot_support            | True                                                                 |
| id                          | e7364bcc-3821-49bf-82d6-0c9f0276d4ce                                 |
| size                        | 1                                                                    |
| name                        | Share1                                                               |
| share_type                  | e031d5e9-f113-491a-843f-607128a5c649                                 |
| has_replicas                | False                                                                |
| replication_type            | None                                                                 |
| created_at                  | 2016-03-20T00:00:00.000000                                           |
| share_proto                 | NFS                                                                  |
| consistency_group_id        | None                                                                 |
| source_cgsnapshot_member_id | None                                                                 |
| project_id                  | e81908b1bfe8468abb4791eae0ef6dd9                                     |
| metadata                    | {u'aim': u'testing'}                                                 |
+-----------------------------+----------------------------------------------------------------------+

The value is_public defines the level of visibility for the share: whether other tenants can or cannot see the share. By default, the share is private. Now you can mount the created share like a remote file system and use it for your purposes.

注釈

See Share Management of “Shared File Systems” section of OpenStack Administrator Guide document for the details on share management operations.

共有へのアクセス権の管理

現在、共有をもっており、他のユーザのためにこの共有のアクセスをコントロールしたいと考えています。このためには、多くのステップと作業を実施する必要があります。共有へのアクセス管理を実施する前に、次の重要なパラメータに注意を払ってください。共有へのアクセスの許可もしくは拒否するために、次のいずれかのサポートされている共有アクセスレベルを指定します。

• rw: 読み書きアクセス。デフォルト。

• ro: 読み取り専用アクセス。

加えて、次のいずれかのサポートされている認証メソッドを指定する必要があります。

• ip: インスタンスの IP アドレスによりインスタンスを認証します。有効な形式は XX.XX.XX.XX または XX.XX.XX.XX/XX です。例えば 0.0.0.0/0 です。

• cert: TLS証明書によりインスタンスを認証します。IDENTKEYとしてTLS idを指定します。有効値は一般的な証明書の名前の長さである64字までの任意の文字列になります。文字列の重要性はその解釈に依存します。

• user: 特定のユーザまたはグループ名により認証します。有効な形式は、いくつかの特殊文字を含むアルファベットかつ4から32文字数になります。

注釈

アクセスルールなしで共有をマウントしてはいけません。これは、例外を引き起こす可能性があります。

IP アクセス形式と 10.254.0.4 IP アドレスを持つ共有へのアクセスを許可します。

$ manila access-allow Share1 ip 10.254.0.4 --access-level rw
+--------------+--------------------------------------+
| Property     | Value                                |
+--------------+--------------------------------------+
| share_id     | 7bcd888b-681b-4836-ac9c-c3add4e62537 |
| access_type  | ip                                   |
| access_to    | 10.254.0.4                           |
| access_level | rw                                   |
| state        | new                                  |
| id           | de715226-da00-4cfc-b1ab-c11f3393745e |
+--------------+--------------------------------------+

共有をマウントします。

$ sudo mount -v -t nfs 10.254.0.5:/shares/share-5789ddcf-35c9-4b64-a28a-7f6a4a574b6a /mnt/

そして、共有のマウントが成功したか、指定されたアクセスルールに従っているかどうかを確認してください。

$ manila access-list Share1
+--------------------------------------+-------------+------------+--------------+--------+
| id                                   | access type | access to  | access level | state  |
+--------------------------------------+-------------+------------+--------------+--------+
| 4f391c6b-fb4f-47f5-8b4b-88c5ec9d568a | user        | demo       | rw           | error  |
| de715226-da00-4cfc-b1ab-c11f3393745e | ip          | 10.254.0.4 | rw           | active |
+--------------------------------------+-------------+------------+--------------+--------+

注釈

異なる共有の機能は、異なる共有のドライバによってサポートされます。これらの例では、user and cert 認証メソッドをサポートしていない汎用（Cinder as a back-end）ドライバが使われていました。

Tip

異なるドライバによってサポートされている機能の詳細は、Manila開発者ガイドのドキュメントを参照してください Manila share features support mapping <https://docs.openstack.org/manila/latest/admin/index.html#supported-share-back-ends>

共有の管理

共有を使っている場合に実行するオペレーションとして、他にもいくつかの有用なオペレーションがあります。

共有の更新

共有の名前、ディスクリプションの更新、他のテナント向けのビジビリティレベル、を変更する場合は、このコマンドを使ってください。

$ manila update Share1 --description "My first share. Updated" --is-public False

更新された Share1 の属性を確認します。

$ manila show Share1
+-----------------------------+----------------------------------------------------------------------+
| Property                    | Value                                                                |
+-----------------------------+----------------------------------------------------------------------+
| status                      | available                                                            |
| share_type_name             | default                                                              |
| description                 | My first share. Updated                                              |
| availability_zone           | nova                                                                 |
| share_network_id            | 9c187d23-7e1d-4d91-92d0-77ea4b9b9496                                 |
| export_locations            |                                                                      |
|                             | path = 10.254.0.3:/shares/share-18cb05be-eb69-4cb2-810f-91c75ef30f90 |
|                             | preferred = False                                                    |
|                             | is_admin_only = False                                                |
|                             | id = d6a82c0d-36b0-438b-bf34-63f3932ddf4e                            |
|                             | share_instance_id = 18cb05be-eb69-4cb2-810f-91c75ef30f90             |
|                             | path = 10.0.0.3:/shares/share-18cb05be-eb69-4cb2-810f-91c75ef30f90   |
|                             | preferred = False                                                    |
|                             | is_admin_only = True                                                 |
|                             | id = 51672666-06b8-4741-99ea-64f2286f52e2                            |
|                             | share_instance_id = 18cb05be-eb69-4cb2-810f-91c75ef30f90             |
| share_server_id             | ea8b3a93-ab41-475e-9df1-0f7d49b8fa54                                 |
| host                        | manila@generic1#GENERIC1                                             |
| access_rules_status         | active                                                               |
| snapshot_id                 | None                                                                 |
| is_public                   | False                                                                |
| task_state                  | None                                                                 |
| snapshot_support            | True                                                                 |
| id                          | e7364bcc-3821-49bf-82d6-0c9f0276d4ce                                 |
| size                        | 1                                                                    |
| name                        | Share1                                                               |
| share_type                  | e031d5e9-f113-491a-843f-607128a5c649                                 |
| has_replicas                | False                                                                |
| replication_type            | None                                                                 |
| created_at                  | 2016-03-20T00:00:00.000000                                           |
| share_proto                 | NFS                                                                  |
| consistency_group_id        | None                                                                 |
| source_cgsnapshot_member_id | None                                                                 |
| project_id                  | e81908b1bfe8468abb4791eae0ef6dd9                                     |
| metadata                    | {u'aim': u'testing'}                                                 |
+-----------------------------+----------------------------------------------------------------------+

共有状態のリセット

時々、共有はエラーや状態遷移で固まって見えることがあります。権限を持たないユーザはこの状況を修正する適切なアクセス権限をもっていません。しかし、クラウド管理者権限のパーミッションをもっていれば、共有の状態をリセットするコマンドを利用して共有の状態をリセットできます。

$ manila reset-state [–state state] share_name

ここでの状態は、共有がどの状態にアサインされているかを示します。オプションとして、available, error, creating, deleting, error_deleting の状態があります。

実行後

$ manila reset-state Share2 --state deleting

共有の状態を確認します。

$ manila show Share2
+-----------------------------+-------------------------------------------+
| Property                    | Value                                     |
+-----------------------------+-------------------------------------------+
| status                      | deleting                                  |
| share_type_name             | default                                   |
| description                 | share from a snapshot.                    |
| availability_zone           | nova                                      |
| share_network_id            | 5c3cbabb-f4da-465f-bc7f-fadbe047b85a      |
| export_locations            | []                                        |
| share_server_id             | 41b7829d-7f6b-4c96-aea5-d106c2959961      |
| host                        | manila@generic1#GENERIC1                  |
| snapshot_id                 | 962e8126-35c3-47bb-8c00-f0ee37f42ddd      |
| is_public                   | False                                     |
| task_state                  | None                                      |
| snapshot_support            | True                                      |
| id                          | b6b0617c-ea51-4450-848e-e7cff69238c7      |
| size                        | 1                                         |
| name                        | Share2                                    |
| share_type                  | c0086582-30a6-4060-b096-a42ec9d66b86      |
| created_at                  | 2015-09-25T06:25:50.000000                |
| export_location             | 10.254.0.3:/shares/share-1dc2a471-3d47-...|
| share_proto                 | NFS                                       |
| consistency_group_id        | None                                      |
| source_cgsnapshot_member_id | None                                      |
| project_id                  | 20787a7ba11946adad976463b57d8a2f          |
| metadata                    | {u'source': u'snapshot'}                  |
+-----------------------------+-------------------------------------------+

共有の削除

共有が必要なくなった場合、manila delete share_name_or_ID のようにコマンドを使用して削除できます。

$ manila delete Share2

注釈

共有を作成している間コンシステンシーグループを指定した場合は、共有を削除するためにコンシステンシーグループの設定を設定する必要があります。

$ manila delete ba52454e-2ea3-47fa-a683-3176a01295e6 --consistency-group \
  ffee08d9-c86c-45e5-861e-175c731daca2

時々ある共有が状態の移行中にハングアップしているかのように見られます（例えば、``creating, deleting, managing, unmanaging, extending, and shrinking``のような状態です）。この場合、削除するためには manila force-delete share_name_or_ID コマンドと実行可能な権限が必要です。

$ manila force-delete b6b0617c-ea51-4450-848e-e7cff69238c7

Tip

他のケース、特徴、APIコマンドなどその他に関して詳細な情報がほしい場合には、OpenStack Administrator Guide Share Management <https://docs.openstack.org/admin-guide/shared-file-systems-share-management.html> の“Shared File Systems”セクションを御覧ください。

スナップショットの作成

Shared File Systems サービスは、ユーザーが自身のデータをリストアする支援をするために、スナップショットの機能を提供します。次のような manila snapshot-create コマンドを使用して、スナップショットを作成します。

$ manila snapshot-create Share1 --name Snapshot1 --description "Snapshot of Share1"
+-------------------+--------------------------------------+
| Property          | Value                                |
+-------------------+--------------------------------------+
| status            | creating                             |
| share_id          | e7364bcc-3821-49bf-82d6-0c9f0276d4ce |
| description       | Snapshot of Share1                   |
| created_at        | 2016-03-20T00:00:00.000000           |
| share_proto       | NFS                                  |
| provider_location | None                                 |
| id                | a96cf025-92d1-4012-abdd-bb0f29e5aa8f |
| size              | 1                                    |
| share_size        | 1                                    |
| name              | Snapshot1                            |
+-------------------+--------------------------------------+

次に、必要に応じて、作成されたスナップショットの名前と説明を更新します。

$ manila snapshot-rename Snapshot1 Snapshot_1 --description "Snapshot of Share1. Updated."

次のとおり実行して、スナップショットが利用できることを確認します。

$ manila snapshot-show Snapshot1
+-------------------+--------------------------------------+
| Property          | Value                                |
+-------------------+--------------------------------------+
| status            | available                            |
| share_id          | e7364bcc-3821-49bf-82d6-0c9f0276d4ce |
| description       | Snapshot of Share1                   |
| created_at        | 2016-03-30T10:53:19.000000           |
| share_proto       | NFS                                  |
| provider_location | 3ca7a3b2-9f9f-46af-906f-6a565bf8ee37 |
| id                | a96cf025-92d1-4012-abdd-bb0f29e5aa8f |
| size              | 1                                    |
| share_size        | 1                                    |
| name              | Snapshot1                            |
+-------------------+--------------------------------------+

Tip

スナップショットに関する詳細は、OpenStack Administrator Guide の Shared File Systems セクションにある Share Snapshots を参照してください。

共有ネットワークの作成

共有ネットワークをコントロールために、Shared File Systemsは自身で共有サーバを管理するためにネットワークサービスと対話する必要があります。選択したドライバがこのような対話を要求しているモードで動作している場合、共有を作成する際に共有ネットワークを指定する必要があります。共有を作成する際の情報は、このチャプタの始めの方の 共有の作成 にあります、既存の共有ネットワークのタイプを確認してください。

$ manila share-network-list
+--------------------------------------+--------------+
| id                                   | name         |
+--------------------------------------+--------------+
+--------------------------------------+--------------+

共有ネットワークのリストが空だったり欲しいネットワークが含まれていない場合、例えば、プライベートネットワークとサブネットワークをもった共有ネットワークを作ってみてください。

$ manila share-network-create --neutron-net-id 5ed5a854-21dc-4ed3-870a-117b7064eb21 \
  --neutron-subnet-id 74dcfb5a-b4d7-4855-86f5-a669729428dc --name my_share_net \
  --description "My first share network"
+-------------------+--------------------------------------+
| Property          | Value                                |
+-------------------+--------------------------------------+
| name              | my_share_net                         |
| segmentation_id   | None                                 |
| created_at        | 2015-09-24T12:06:32.602174           |
| neutron_subnet_id | 74dcfb5a-b4d7-4855-86f5-a669729428dc |
| updated_at        | None                                 |
| network_type      | None                                 |
| neutron_net_id    | 5ed5a854-21dc-4ed3-870a-117b7064eb21 |
| ip_version        | None                                 |
| nova_net_id       | None                                 |
| cidr              | None                                 |
| project_id        | 20787a7ba11946adad976463b57d8a2f     |
| id                | 5c3cbabb-f4da-465f-bc7f-fadbe047b85a |
| description       | My first share network               |
+-------------------+--------------------------------------+

segmentation_id, cidr, ip_version, network_type という共有の属性は、ネットワークプロバイダーにより指定された値に自動的に設定されます。

次にネットワークの一覧を要求して、ネットワークが正常に作成されたことを確認します。

$ manila share-network-list
+--------------------------------------+--------------+
| id                                   | name         |
+--------------------------------------+--------------+
| 5c3cbabb-f4da-465f-bc7f-fadbe047b85a | my_share_net |
+--------------------------------------+--------------+

最後に、これまでの本章に記載された「共有の作成」ユースケースを参照して、この共有ネットワークを使用する共有を作成します。

Tip

詳細は OpenStack Administrator Guide の Shared File Systems セクションにある Share Networks を参照してください。

共有ネットワークの管理

共有ネットワークを操作する役に立つ、有用なコマンドがいくつかあります。まずネットワークの一覧を確認します。

$ manila share-network-list
+--------------------------------------+--------------+
| id                                   | name         |
+--------------------------------------+--------------+
| 5c3cbabb-f4da-465f-bc7f-fadbe047b85a | my_share_net |
+--------------------------------------+--------------+

If you configured the back-end with driver_handles_share_servers = True (with the share servers) and had already some operations in the Shared File Systems service, you can see manila_service_network in the neutron list of networks. This network was created by the share driver for internal usage.

$ openstack network list
+--------------+------------------------+------------------------------------+
| ID           | Name                   | Subnets                            |
+--------------+------------------------+------------------------------------+
| 3b5a629a-e...| manila_service_network | 4f366100-50... 10.254.0.0/28       |
| bee7411d-d...| public                 | 884a6564-01... 2001:db8::/64       |
|              |                        | e6da81fa-55... 172.24.4.0/24       |
| 5ed5a854-2...| private                | 74dcfb5a-bd... 10.0.0.0/24         |
|              |                        | cc297be2-51... fd7d:177d:a48b::/64 |
+--------------+------------------------+------------------------------------+

network_type, segmentation_id 項目を含む、共有ネットワークに関する詳細を参照することもできます。

$ openstack network show manila_service_network
+---------------------------+--------------------------------------+
| Field                     | Value                                |
+---------------------------+--------------------------------------+
| admin_state_up            | True                                 |
| availability_zone_hints   |                                      |
| availability_zones        | nova                                 |
| created_at                | 2016-03-20T00:00:00                  |
| description               |                                      |
| id                        | ef5282ab-dbf9-4d47-91d4-b0cc9b164567 |
| ipv4_address_scope        |                                      |
| ipv6_address_scope        |                                      |
| mtu                       | 1450                                 |
| name                      | manila_service_network               |
| port_security_enabled     | True                                 |
| provider:network_type     | vxlan                                |
| provider:physical_network |                                      |
| provider:segmentation_id  | 1047                                 |
| router:external           | False                                |
| shared                    | False                                |
| status                    | ACTIVE                               |
| subnets                   | aba49c7d-c7eb-44b9-9c8f-f6112b05a2e0 |
| tags                      |                                      |
| tenant_id                 | f121b3ee03804266af2959e56671b24a     |
| updated_at                | 2016-03-20T00:00:00                  |
+---------------------------+--------------------------------------+

共有ネットワークにセキュリティサービスを追加および削除できます。

Tip

詳細は OpenStack Administrator Guide の Shared File Systems セクションにある Security Services を参照してください。

インスタンス

インスタンスは OpenStack クラウドの中で実行中の仮想マシンです。このセクションは、インスタンス、インスタンスが使用するイメージ、インスタンスのネットワークプロパティを扱うための方法について取り扱います。また、それらがデータベースでどのように表現されているかについて取り扱います。

インスタンスの起動

インスタンスを起動するには、イメージ、フレーバーおよび名前を選択する必要があります。名前は一意である必要がありませんが、名前が一意である限りは、多くのツールが UUID の代わりに名前を使用できるので、シンプルにできます。インスタンスの起動は、ダッシュボードにおいて、 インスタンス ページにある 起動 ボタン、または イメージ ページにある イメージ または スナップショット の隣にある インスタンスの起動 アクションから実行できます。

コマンドラインで、このようにします。

$ openstack server create --flavor FLAVOR --image IMAGE_NAME_OR_ID

指定できる多くのオプション項目があります。インスタンスを起動しようとする前に、このセクションを最後まで読んでください。しかし、これが今から説明する詳細の基本となるコマンドです。

ダッシュボードからインスタンスを削除するには、 インスタンス ページにおいてインスタンスの隣にある インスタンスの削除 アクションを選択します。

注釈

Mitaka 以前のリリースでは、同等の インスタンスの終了 操作を選択します。

コマンドラインから次のとおり実行します。

$ openstack server delete INSTANCE_ID

注意すべき大事な点は、インスタンスの電源オフは、OpenStack 的な意味でのインスタンスの終了ではないということです。

インスタンスの起動失敗

インスタンスの開始に失敗し、すぐにエラー状態になるならば、何が問題なのかを追跡するために、いくつかの異なる方法があります。いくつかの方法は通常のユーザーアクセスで実行でき、他の方法ではログサーバーやコンピュートノードへのアクセスが必要です。

ノードが起動に失敗する最も簡単な理由は、クォータ違反、またはスケジューラーがインスタンスを実行するのに適したコンピュートノードを見つけられなかった場合です。これらの場合、失敗したインスタンスに対して openstack server show を実行するとエラーが表示されます。

$ openstack server show test-instance
+--------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------+
| Field                                | Value                                                                                                                                 |
+--------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------+
| OS-DCF:diskConfig                    | AUTO                                                                                                                                  |
| OS-EXT-AZ:availability_zone          | nova                                                                                                                                  |
| OS-EXT-SRV-ATTR:host                 | None                                                                                                                                  |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | None                                                                                                                                  |
| OS-EXT-SRV-ATTR:instance_name        | instance-0000000a                                                                                                                     |
| OS-EXT-STS:power_state               | NOSTATE                                                                                                                               |
| OS-EXT-STS:task_state                | None                                                                                                                                  |
| OS-EXT-STS:vm_state                  | error                                                                                                                                 |
| OS-SRV-USG:launched_at               | None                                                                                                                                  |
| OS-SRV-USG:terminated_at             | None                                                                                                                                  |
| accessIPv4                           |                                                                                                                                       |
| accessIPv6                           |                                                                                                                                       |
| addresses                            |                                                                                                                                       |
| config_drive                         |                                                                                                                                       |
| created                              | 2016-11-23T07:51:53Z                                                                                                                  |
| fault                                | {u'message': u'Build of instance 6ec42311-a121-4887-aece-48fb93a4a098 aborted: Failed to allocate the network(s), not rescheduling.', |
|                                      | u'code': 500, u'details': u'  File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1779, in                          |
|                                      | _do_build_and_run_instance\n    filter_properties)\n  File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1960, in  |
|                                      | _build_and_run_instance\n    reason=msg)\n', u'created': u'2016-11-23T07:57:04Z'}                                                     |
| flavor                               | m1.tiny (1)                                                                                                                           |
| hostId                               |                                                                                                                                       |
| id                                   | 6ec42311-a121-4887-aece-48fb93a4a098                                                                                                  |
| image                                | cirros (9fef3b2d-c35d-4b61-bea8-09cc6dc41829)                                                                                         |
| key_name                             | None                                                                                                                                  |
| name                                 | test-instance                                                                                                                         |
| os-extended-volumes:volumes_attached | []                                                                                                                                    |
| project_id                           | 5669caad86a04256994cdf755df4d3c1                                                                                                      |
| properties                           |                                                                                                                                       |
| status                               | ERROR                                                                                                                                 |
| updated                              | 2016-11-23T07:57:04Z                                                                                                                  |
| user_id                              | c36cec73b0e44876a4478b1e6cd749bb                                                                                                      |
+--------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------+

この場合、fault メッセージに NoValidHost が表示されています。 NoValidHost はスケジューラーがインスタンスの要件を満たせなかったことを意味します。

openstack server show が十分な失敗の理由が表示されていない場合、そのインスタンスがスケジューリングされたコンピュートノードの nova-compute.log やスケジューラーホストの nova-scheduler.log を、インスタンスの UUID で検索するのが、より低レベルの問題を調査する良い出発点となります。

管理ユーザーとして openstack server show を使用すると、インスタンスがスケジュールされたコンピュートノードが hostId として表示されます。インスタンスがスケジュール中に失敗していれば、この項目が空白です。

インスタンス固有データの使用

インスタンス固有のデータには 2 種類あります。メタデータとユーザーデータです。

インスタンスメタデータ

Compute では、インスタンスのメタデータはインスタンスと関連付けられたキーバリューペアの集まりです。エンドユーザーがこれらのキーバリューペアを読み書きするために Compute API を使用するとき、Compute がインスタンスの生存期間中にインスタンスの内外からこれらを読み書きします。しかしながら、Amazon EC2 メタデータサービスと互換性のあるメタデータサービスを用いて、インスタンスに関連付けられたキーバリューペアをクエリーできません。

インスタンスのメタデータの場合、ユーザーが openstack keypair create コマンドを使用して SSH 鍵を生成および登録できます。

$ openstack keypair create mykey > mykey.pem

これにより、インスタンスと関連付けられる mykey という名前の鍵が生成されます。 mykey.pem というファイルが秘密鍵です。これは、 mykey 鍵が関連付けられたインスタンスに root アクセスできるので、安全な場所に保存すべきです。

このコマンドを使用して、既存の鍵を OpenStack に登録します。

$ openstack keypair create --public-key mykey.pub mykey

注釈

この鍵と関連付けられたインスタンスにアクセスするために、対応する秘密鍵を持つ必要があります。

起動時にインスタンスに鍵を関連付けるには、たとえば、コマンドラインに --key-name mykey を追加します。例えば、

$ openstack server create --image ubuntu-cloudimage --flavor 2 \
  --key-name mykey myimage

サーバーを起動するとき、他の実行中のインスタンスと区別しやすくするために、メタデータを追加することもできます。--property オプションをキーバリューペアとともに使用します。ここで、キーとバリューの両方の文字列を指定することができます。たとえば、説明とサーバーの作成者を追加できます。

$ openstack server create --image=test-image --flavor=1 \
  --property description='Small test image' smallimage

サーバーの情報を表示するとき、 metadata 行に含まれるメタデータを参照できます:

$ openstack server show smallimage

+--------------------------------------+----------------------------------------------------------+
| Field                                | Value                                                    |
+--------------------------------------+----------------------------------------------------------+
| OS-DCF:diskConfig                    | MANUAL                                                   |
| OS-EXT-AZ:availability_zone          | nova                                                     |
| OS-EXT-SRV-ATTR:host                 | rdo-newton.novalocal                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | rdo-newton.novalocal                                     |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000002                                        |
| OS-EXT-STS:power_state               | Running                                                  |
| OS-EXT-STS:task_state                | None                                                     |
| OS-EXT-STS:vm_state                  | active                                                   |
| OS-SRV-USG:launched_at               | 2016-12-07T11:20:08.000000                               |
| OS-SRV-USG:terminated_at             | None                                                     |
| accessIPv4                           |                                                          |
| accessIPv6                           |                                                          |
| addresses                            | public=172.24.4.227                                      |
| config_drive                         |                                                          |
| created                              | 2016-12-07T11:17:44Z                                     |
| flavor                               | m1.tiny (1)                                              |
| hostId                               | aca973d5b7981faaf8c713a0130713bbc1e64151be65c8dfb53039f7 |
| id                                   | 4f7c6b2c-f27e-4ccd-a606-6bfc9d7c0d91                     |
| image                                | cirros (01bcb649-45d7-4e3d-8a58-1fcc87816907)            |
| key_name                             | None                                                     |
| name                                 | smallimage                                               |
| os-extended-volumes:volumes_attached | []                                                       |
| progress                             | 0                                                        |
| project_id                           | 2daf82a578e9437cab396c888ff0ca57                         |
| properties                           | description='Small test image'                           |
| security_groups                      | [{u'name': u'default'}]                                  |
| status                               | ACTIVE                                                   |
| updated                              | 2016-12-07T11:20:08Z                                     |
| user_id                              | 8cbea24666ae49bbb8c1641f9b12d2d2                         |
+--------------------------------------+----------------------------------------------------------+

インスタンスのユーザーデータ

user-data 鍵は、メタデータサービス内の特別キーです。ゲストインスタンスにあるクラウド対応アプリケーションがアクセス可能なファイルを保持します。たとえば、 cloudinit は、Ubuntu 発祥のオープンソースパッケージですが、ほとんどのディストリビューションで利用可能です。このユーザーデータを使用するクラウドインスタンスの初期設定を処理します。

このユーザーデータは、ローカルマシンのファイルに保存され、 --user-data <user-data-file> フラグを用いてインスタンスの生成時に渡されます。

例えば

$ openstack server create --image ubuntu-cloudimage --flavor 1 \
  --user-data mydata.file mydatainstance

ユーザーデータとメタデータの違いを理解するために、インスタンスが起動する前に、ユーザーデータが作成されることに気づいてください。ユーザーデータは、インスタンスの実行時に、インスタンスの中からアクセスできます。設定、スクリプト、テナントが必要とするものを保存するために使用できます。

ファイルインジェクション

--file <dst-path=src-path> オプションを使用することにより、任意のローカルファイルを生成時にインスタンスのファイルシステムの中に置けます。5 ファイルまで保存できます。

例えば、何らかの理由で通常の SSH 鍵の注入ではなく、 special_authorized_keysfile という名前の特別な authorized_keys ファイルをインスタンスに置きたいと言うとします。この場合、以下のコマンドを使用できます:

$ openstack server create --image ubuntu-cloudimage --flavor 1  \
  --file /root/.ssh/authorized_keys=special_authorized_keysfile \
  authkeyinstance

セキュリティグループの割り当て

セキュリティグループは、前に記載したように、プロジェクトのデフォルトのセキュリティグループがより許可するよう変更されていない限り、インスタンスへのネットワーク通信を許可するために一般的に必要となります。

セキュリティグループの追加は、一般的にインスタンスの起動時に実行されます。ダッシュボードから起動するとき、これは インスタンスの起動 ダイアログの アクセスとセキュリティー タブにあります。

インスタンスを実行中にセキュリティグループを追加および削除することもできます。現在、コマンドラインツールからのみ利用可能です。例:

$ openstack server add security group SERVER SECURITY_GROUP_NAME_OR_ID

$ openstack server remove security group SERVER SECURITY_GROUP_NAME_OR_ID

Floating IP

Floating IP はクラウド全体で設定されますが、各プロジェクトはクォータにより Floating IP 数を制限されているでしょう。使用する前に中央プールからプロジェクトに確保する必要があります。一般的に、プロジェクトの管理者により行われます。ダッシュボードの アクセスとセキュリティー ページの Floating IP タブの Floating IP の確保 ボタンを使用して、Floating IP をプロジェクトに確保します。コマンドラインを使用することもできます。

$ openstack floating ip create NETWORK_NAME_OR_ID

一度確保すると、Floating IP を実行中のインスタンスに割り当てることができます。ダッシュボードでは、 アクセスとセキュリティ ページの Floating IP タブにある IP の隣にある、アクションドロップダウンから 割り当て を選択することにより実行できます。または、 インスタンス ページにおいて割り当てたいインスタンスの隣にある、リストからこれを選択することにより実行できます。逆の動作 Floating IP の割り当て解除 は アクセスとセキュリティ ページの Floating IP タブから実行できます。 インスタンス のページから利用できません。

以下のコマンドを使用して、コマンドラインからサーバーに Floating IP アドレスを関連付けまたは関連付け解除します。

$ openstack server add floating ip SERVER IP_ADDRESS

$ openstack server remove floating ip SERVER IP_ADDRESS

ブロックストレージの接続

ダッシュボードの ボリューム ページから、インスタンスにブロックストレージを接続できます。接続したいボリュームの隣にある 接続の編集 をクリックします。

このアクションをコマンドラインから実行するには、以下のコマンドを実行します

$ openstack server add volume SERVER VOLUME_NAME_OR_ID --device DEVICE

nova コマンドラインクライアントに以下のようにオプションを付けて、インスタンスの起動時にブロックデバイスのマッピングを指定することもできます。

--block-device-mapping <dev-name=mapping>

ブロックデバイスマッピングのフォーマットは <dev-name>=<id>:<type>:<size(GB)>:<delete-on-terminate> です。

dev-name

そのボリュームはシステムで /dev/dev_name に接続されます。

ID

起動するボリュームの ID。openstack volume list の出力に表示されます。

タイプ

ボリュームがスナップショットから作成されたことを意味する snap 、または snap 以外の何か (空文字列も有効) です。上の例では、ボリュームがスナップショットから作成されていません。そのため、この項目を以下の例において空白にしてあります。

size (GB)

ボリュームのギガバイト単位の容量。このフィールドを空欄にして、Compute サービスに容量を推定させるのが安全です。

delete-on-terminate

インスタンスが終了したときに、ボリュームが削除されるかどうかを指示する論理値です。真は True または 1 として指定できます。偽は False または 0 として指定できます。

以下のコマンドは、新しいインスタンスを起動して、同時にボリュームを接続します。ID 13 のボリュームが /dev/vdc として接続されます。これは、スナップショットではなく、容量を指定せず、インスタンスの削除時に一緒に削除されます。

$ openstack server create --image 4042220e-4f5e-4398-9054-39fbd75a5dd7 \
  --flavor 2 --key-name mykey --block-device-mapping vdc=13:::0 \
  boot-with-vol-test

ブート可能なファイルシステムイメージでブロックストレージを事前に準備していると、永続ブロックストレージからブートすることもできます。以下のコマンドは、指定したボリュームからイメージを起動します。前のコマンドに似ていますが、イメージが省略され、ボリュームが /dev/vda として接続されます。

$ openstack server create --flavor 2 --key-name mykey \
  --block-device-mapping vda=13:::0 boot-from-vol-test

詳細は OpenStack エンドユーザーガイド の「ボリュームからのインスタンスの起動」にある説明を参照してください。

通常通りイメージから起動し、ブロックストレージを接続するために、vda 以外のデバイスを対応付けます。 OpenStack エンドユーザーガイド に、インスタンスを起動して、それにボリュームを接続する方法、接続されたボリュームにイメージをコピーする方法が説明されています。

スナップショットの取得

OpenStack のスナップショット機能により、実行中のインスタンスから新しいイメージを作成することもできます。これは、ベースイメージをアップグレードするため、公開されているイメージをカスタマイズするために、非常に便利です。このように CLI を使用して、実行中のインスタンスをイメージにスナップショットをとります。

$ openstack image create IMAGE_NAME --volume VOLUME_NAME_OR_ID

ダッシュボードのインターフェースでは、スナップショットとイメージが両方とも イメージ のページに表示されるため、まぎらわしいかもしれません。しかしながら、インスタンスのスナップショットはイメージ です 。Image service に直接アップロードしたイメージと、スナップショットにより作成したイメージとの唯一の違いは、スナップショットにより作成されたイメージが glance データベースにおいて追加のプロパティを持つことです。これらのプロパティは image_properties テーブルで確認でき、次の項目を含みます:

名前	値
image_type	スナップショット
instance_uuid	<スナップショットされたインスタンスの UUID>
base_image_ref	<スナップショットされたインスタンスの元イメージの UUID>
image_location	スナップショット

ライブスナップショット

ライブスナップショットは、ユーザーが実行中の仮想マシンのスナップショットを一時停止なしで取得できる機能です。このスナップショットは単にディスクのみのスナップショットです。現在はインスタンスのスナップショットは停止時間なしで実行できます (QEMU 1.3+ と libvirt 1.0+ が使用されていることが前提です)。

注釈

libvirt バージョン 1.2.2 を使用している場合、ライブスナップショットの作成において、断続的な問題を経験するかもしれません。

問題が解決するまでは、libvirt のライブスナップショットを効果的に無効化するために、以下の設定を nova.conf に追加します。

[workarounds]
disable_libvirt_livesnapshot = True

Linux ゲストのスナップショットの整合性の保証

以下のセクションは、Sébastien Han さんの OpenStack: Perform Consistent Snapshots ブログ記事 からの引用です。

スナップショットは、ファイルシステムの状態をキャプチャーしますが、メモリーの状態をキャプチャーしません。そのため、スナップショットに期待するデータが含まれることを確実にするために、次のことを確実にする必要があります。

• 実行中のプログラムがコンテンツをディスクに書き込んだこと

• ファイルシステムが「ダーティー」バッファーを持たないこと: 「ダーティー」バッファーがあるとは、プログラムがディスクに書き込むためにコマンドを発行しましたが、オペレーティングシステムがまだ書き込みを完了していないことです。

(データベースのような) 重要なサービスがコンテンツをディスクに書き込んだことを保証するために、それらのアプリケーションのドキュメントを読んで、コンテンツをディスクに同期させるためにどのコマンドを発行する必要があるかを調べることを推奨します。ディスクに同期させるための方法がはっきり分からない場合、最も安全な方法は単にこれらの実行中のサービスを通常通り停止することです。

「ダーティー」バッファーの問題を解決するために、スナップショットの前に sync コマンドを使用することを推奨します。

# sync

sync を実行することにより、ダーティーバッファー (変更されたが、ディスクに書き込まれていないバッファー済みブロック) をディスクに書き込みます。

ファイルシステムが整合性を持つことを保証するためには、単に sync を実行するだけでは不十分です。 fsfreeze ツールを使用することを推奨します。これは、ファイルシステムに対する新規アクセスを停止し、スナップショットに適した安定したイメージをディスクに作成します。 fsfreeze は ext3, ext4 および XFS を含むいくつかのファイルシステムをサポートします。仮想マシンのインスタンスが Ubuntu において実行されていれば、 fsfreeze を取得するために util-linux パッケージをインストールします:

注釈

ベースとするスナップショットが LVM 経由で取得されている非常に一般的な場合、ファイルシステムのフリーズは、LVM により自動的に処理されます。

# apt-get install util-linux

お使いのオペレーティングシステムに利用可能なバージョンの fsfreeze がなければ、代わりに xfs_freeze を使用できます。これは Ubuntu の xfsprogs パッケージにおいて利用可能です。"xfs" という名前にもかかわらず、xfs_freeze は Linux カーネル 2.6.29 またはそれ以降を使用していれば ext3 や ext4 においても動作します。それは 2.6.29 において開始された仮想ファイルシステム (VFS) レベルで動作するためです。この xfs_freeze のバージョンは fsfreeze と同じ名前のコマンドライン引数をサポートします。

永続ブロックストレージのスナップショットを取得したい例を検討します。ゲストオペレーティングシステムにより /dev/vdb として認識され、 /mnt にマウントされているとします。fsfreeze コマンドが 2 つの引数を受け取ります:

-f

システムをフリーズします

-u

システムを解凍 (フリーズ解除) します

スナップショットの準備においてボリュームをフリーズするには、インスタンスの中で root として次のとおり実行します:

# fsfreeze -f /mnt

fsfreeze コマンドを実行する前に、 ファイルシステムをマウントする必要があります。

fsfreeze -f コマンドが発行された場合、ファイルシステム内で進行中のすべてのトランザクションが完了することが認められます。新規書き込みのシステムコールは停止されます。そして、ファイルシステムを変更する他のコールは停止されます。最も重要なこととしては、すべてのダーティーデータ、メタデータ、およびログ情報がディスクに書き込まれることです。

ボリュームがフリーズ状態になったら、ボリュームの読み書き命令が止まってしまうので、ボリュームの読み書きを行わないようにしてください。オペレーティングシステムがすべての I/O 操作を停止し、すべての I/O 試行がファイルシステムがフリーズ解除されるまで遅延させられます。

fsfreeze コマンドを発行すると、スナップショットを実行しても安全です。たとえば、インスタンスのボリュームが mon-volume という名前で、 mon-snapshot という名前のイメージにスナップショットを取得したければ、以下のとおり実行します:

$ openstack image create mon-snapshot --volume mon-volume

スナップショットの作成が終わったら、インスタンスの中で root として以下のコマンドを用いて、ファイルシステムをフリーズ解除できます。

# fsfreeze -u /mnt

ルートファイルシステムをバックアップしたければ、プロンプトがフリーズしてしますので、上のコマンドを単純に実行できません。代わりに、インスタンスの中で root として以下の 1 行を実行します。

# fsfreeze -f / && read x; fsfreeze -u /

このコマンドの後、お使いの端末から openstack image create を呼び出すことが一般的な慣習です。実行した後、インスタンスの中で Enter キーを押して、フリーズ解除します。もちろん、これを自動化できますが、少なくとも適切に同期できるようになるでしょう。

Windows ゲストのスナップショットの整合性の保証

Windows 仮想マシンの整合性あるスナップショットの取得は、Linux マシンのスナップショットの場合と同じようなものです。ただし、整合性バックアップを働かせるために、Windows 専用のサブコマンドと調整するための追加機能を必要とします。

Windows XP 以降は、従順なアプリケーションが動作中のファイルシステムで整合性のあるバックアップを取得できるようにするフレームワークを提供する Volume Shadow Copy Service (VSS) が含まれます。このフレームワークを使用するために、VSS リクエスターが、整合性バックアップを必要とすることを VSS サービスに対してシグナルを発行します。VSS サービスは、従順なアプリケーション (VSS ライターと言います) に通知して、これらのデータ処理を休止します。そして、VSS サービスがコピープロバイダーにスナップショットを作成するよう指示します。スナップショットが作成されると、VSS サービスが VSS ライターをフリーズ解除して、通常の I/O アクティビティーが再開されます。

QEMU は、KVM ハイパーバイザーにおいて動作しているゲストで実行できるゲストエージェントを提供しています。Windows 仮想マシンの場合、このゲストエージェントは、Windows VSS サービスと連携して、スナップショットの整合性を保証する流れを楽にします。この機能は QEMU 1.7 以降を必要とします。関連するゲストエージェントのコマンドは次のとおりです。

guest-file-flush

「ダーティー」バッファーをディスクに書き出します。Linux の sync 処理と似ています。

guest-fsfreeze

ディスクへの I/O を一時停止します。Linux の fsfreeze -f 処理と似ています。

guest-fsfreeze-thaw

ディスクへの I/O を再開します。Linux の fsfreeze -u 処理と似ています。

Windows 仮想マシンのスナップショットを取得する場合、以下のコマンドを連続して実行するスクリプト化できます。ファイルシステムをフラッシュする、ファイルシステムをフリーズする、ファイルシステムのスナップショットを取得する、ファイルシステムをフリーズ解除する。Linux 仮想マシンのワークフローと同じように、そのようなスクリプトを書くときに、注意して使用すべきです。エラー処理を徹底して、ファイルシステムがフリーズ状態のままにならないようにします。

データベースにあるインスタンス

インスタンスの情報が数多くのデータベースのテーブルに保存されますが、ユーザーのインスタンスに関連して参照する必要がありそうなテーブルは、instances テーブルです。

インスタンスのテーブルは、実行中および削除済みの両方のインスタンスに関連する情報のほとんどを保持しています。データベースで完全なリストを見ると、このテーブルには目が回るほどたくさんのフィールドがあることがわかります。以下に、クエリーを行おうとしている運用者にとって非常に有用なフィールドを挙げます。

• deleted フィールドは、インスタンスが削除されていると 1 がセットされます。削除されていなければ NULL です。このフィールドは、クエリーから削除済みインスタンスを除外するために重要です。

• uuid フィールドはインスタンスの UUID です。データベースにある他の表において外部キーとして使用されます。この ID は、インスタンスを一意に識別するために、ログ、ダッシュボードおよびコマンドラインツールにおいて表示されます。

• 外部キーはインスタンスの関連を見つけるために利用可能です。これらの中で最も有用なものは、 user_id および project_id です。これらは、インスタンスを起動したユーザー、およびそれが起動されたプロジェクトの UUID です。

• host フィールドは、どのコンピュートノードがインスタンスをホストしているかを示します。

• hostname フィールドは、インスタンスが起動したときのインスタンス名を保持します。display-name は、最初は hostname と同じですが、nova rename コマンドを使って再設定することができます。

多くの時刻関連のフィールドは、いつ状態の変化がインスタンスに起こったかを追跡する際に役に立ちます:

• created_at

• updated_at

• deleted_at

• scheduled_at

• launched_at

• terminated_at

グッドラック！

このセクションは、多くの OpenStack コマンドの中から、いくつかの最も有用なものを簡単に説明することを意図していました。膨大なリストは、 OpenStack 管理者ユーザーガイド を参照してください。ユーザーが幸せなままであり、あなたのハードワークに気づくことを願います。（さらなるハードワークは、次の章にページを進んでください。システムが直面する運用、メンテナンス、障害、デバッグについて議論しています。）