ストレージガイド

Red Hat OpenStack Platform 8

OpenStack での永続ストレージの理解、使用、管理

OpenStack Documentation Team

rhos-docs@redhat.com

法律上の通知

The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

概要

本ガイドでは、Red Hat OpenStack Platform 環境における永続ストレージの使用/管理手順について詳しく説明します。また、各永続ストレージの種別に対応する OpenStack サービスの設定および管理の手順も記載しています。

前書き

Red Hat OpenStack Platform は、Red Hat Enterprise Linux をベースとして、プライベートまたはパブリックの Infrastructure-as-a-Service (IaaS) クラウドを構築するための基盤を提供します。これにより、スケーラビリティーが極めて高く、耐障害性に優れたプラットフォームをクラウド対応のワークロード開発にご利用いただくことができます。

本ガイドは、永続ストレージの作成と管理の手順を説明します。OpenStack では、永続ストレージは主に 3 つのサービスで提供されます。

Block Storage (openstack-cinder)
Object Storage (openstack-swift)
Shared File System Storage (openstack-manila)。現在はテクノロジープレビュー機能となっています。

これらのサービスは、異なる種別の永続ストレージを提供します。それぞれのストレージは、異なるユースケースで独自の利点があります。本ガイドでは、一般的なエンタープライズストレージ要件に対する各ストレージの適合性について説明します。

OpenStack Dashboard またはコマンドラインクライアントを使用してクラウドストレージの管理を行うことができます。大半の手順は、これらのいずれかの方法を使用することができますが、一部の高度な手順はコマンドラインのみで実行可能となっています。本ガイドでは、可能な場合には Dashboard を使用する手順を記載しています。

注記

Red Hat OpenStack Platform の全ドキュメントスイートは Red Hat Enterprise Linux OpenStack Platform の製品ドキュメントで参照してください。

第1章 OpenStack での永続ストレージの概要

OpenStack は、一時ストレージと永続ストレージの 2 種類を認識します。一時ストレージは、特定の Compute インスタンスにのみ関連付けられるストレージです。インスタンスが終了されると、一時ストレージも終了します。この種別のストレージは、インスタンスのオペレーティングシステムの保存など、ランタイム時の基本的要件に対応する際に役立ちます。

一方、永続ストレージは、実行中のインスタンスからは独立して存続 (永続) するように設計されています。このストレージは、別のインスタンスまたは有効期間を超えた特定のインスタンスが再利用する必要のあるデータに使用されます。OpenStack は以下の種別の永続ストレージを使用します。

ボリューム

OpenStack Block Storage サービス (openstack-cinder) は、ボリューム を使用してブロックストレージデバイスにユーザーがアクセスできるようにします。一時ストレージを汎用の永続ストレージで拡張するために、インスタンスにボリュームを接続することができます。ボリュームは、任意でインスタンスからデタッチすることも、再度接続することもできます。接続したインスタンス経由でないと、ボリュームにはアクセスできません。

ボリュームには、バックアップやスナップショットを使用することで冗長性と災害復旧機能も備わっています。さらに、ボリュームを暗号化できるため、セキュリティーが強化されます。ボリュームに関する情報は、『2章Block Storage とボリューム』を参照してください。

注記

一時ストレージは絶対に使用しないように、インスタンスを設定することも可能です。このような場合は、Block Storage サービスによりボリュームにイメージが書き込まれ、そのボリュームはインスタンスのブータブル root ボリュームとして利用することができます。

コンテナー

OpenStack Object Storage サービス (openstack-swift) は、メデイアファイル、大容量のデータセット、ディスクイメージなど、静的データやバイナリー オブジェクト を保存するために使用する完全に分散されたストレージソリューションを提供します。Object Storage サービスは、コンテナー を使用してこれらのオブジェクトを整理します。

ボリュームのコンテンツにはインスタンス経由でしかアクセスできませんが、コンテナーの中のオブジェクトは Object Storage REST API 経由でアクセスすることができます。そのため、クラウド内にあるほぼすべてのサービスが、Object Storage サービスをリポジトリーとして使用することができます。たとえば、Data Processing サービス (openstack-sahara) は、Object Storage サービスから直接、そのバイナリー、データ入力、データ出力、テンプレートをすべて管理できます。

共有

OpenStack Shared File System サービス (openstack-manila) は、リモートにある共有可能なファイルシステムまたは共有を簡単にプロビジョニングする手段を提供します。共有により、クラウド内のテナントがオープンにストレージを共有できるため、共有を複数のインスタンスにより同時に消費することができます。

重要

本リリースでは、OpenStack Shared File System は テクノロジープレビュー として提供されているため、Red Hat では全面的にはサポートしていません。これは、テスト目的のみでご利用いただく機能で、実稼働環境にデプロイすべきではありません。テクノロジープレビューについての詳しい情報は「Scope of Coverage Details」を参照してください。

各ストレージの種別は、特定のストレージ要件に対応するために設計されています。コンテナーは、幅広いアクセスに対応できるように設計されているため、全ストレージ種別において最高レベルのスループット、アクセス、フォールトトレランスが備えられています。コンテナーは主にサービスへの使用を対象としています。

一方で、ボリュームは主にインスタンスの消費に使用されます。ボリュームは、コンテナーと同じレベルのアクセスやパフォーマンスには対応しにくくなっていますが、コンテナーに比べ、機能セットが幅広く、ネイティブのセキュリティー機能も多くなっています。この点では、共有はボリュームとよく似ていますが、共有は複数のインスタンスにより消費可能である点が異なります。

以下のセクションは、固有のストレージ基準という切り口で、各ストレージ種別のアーキテクチャーおよび機能セットを詳しく説明しています。

1.1. スケーラビリティーおよびバックエンド

一般的に、クラスターストレージソリューションは、バックエンドのスケーラビリティーが高くなっています。Red Hat Ceph を Block Storage のバックエンドとして使用する場合は、Ceph OSD (Object Storage Daemon) ノードをさらに追加することで、ストレージの容量および冗長性をスケーリングできます。Block Storage も Object Storage サービスも、バックエンドとして使用する Red Hat Ceph をサポートします。

Block Storage サービスは、個別のバックエンドとして複数のストレージソリューションを使用することができます。バックエンドレベルでは、バックエンドを追加してサービスを再起動することで、容量をスケーリングすることができます。Block Storage サービスは、数多くのサポートバックエンドソリューションをサポートしており、その一部には追加のスケーラビリティー機能が備えられています。

デフォルトでは、Object Storage サービスは設定済みの ストレージノード を使用しており、空き容量がある分だけ使用することができます。Object Storage サービスは、XFS および ext4 ファイルシステムをサポートし、いずれのサービスもスケーリングして、下層にあるブロックストレージで利用可能な容量を消費することができます。また、ストレージデバイスをストレージノードに追加して、容量をスケーリングすることも可能です。

Shared File System サービスは、別の ストレージプール からのストレージでバッキングされる共有をプロビジョニングします。一般的にはサードパーティーのバックエンドサービスが管理するこのプールは、共有にファイルシステムレベルでのストレージを提供します。OpenStack Shared File System サービスでは NetApp をサポートしており、事前作成済みのボリューム (プロビジョニングした共有でストレージとして使用可能) のストレージプールを使用するように設定できます。このデプロイメントでは、プールにボリュームを追加してスケーリングを行います。

1.2. アクセシビリティーと管理

ボリュームは、インスタンス経由でのみ消費され、1 回に 1 つのインスタンスにしか接続できず、またそのインスタンス内にしかマウントできません。ボリュームのスナップショットを作成して、クローンを作成する際や以前の状態にボリュームを復元する際に使用することができます (「冗長性および災害復旧」を参照)。新規ボリュームを作成する際にこれらの設定を簡単に呼び出すことができるようにボリュームの各種設定 (例: サイズおよびバックエンド) を集めた ボリューム種別 を、Block Storage サービスでは作成することも可能です。これらの種別はさらに QoS スペックに関連付けて、ユーザー向けに異なるストレージ階層を作成することができます。

ボリュームと同様に、共有はインスタンスにより消費されますが、共有はインスタンス内に直接マウントすることができ、ダッシュボードまたは CLI 経由で接続する必要がありません。共有は、同時に複数のインスタンスによりマウントすることができます。Shared File System サービスは、共有のスナップショットやクローン作成もサポートしており、(ボリューム種別のように) 設定を集めた 共有の種別 を作成することも可能です。

コンテナー内のオブジェクトは、API 経由でアクセスすることができ、クラウド内のインスタンスやサービスからもアクセスすることができるようになるため、サービスのオブジェクトリポジトリーとして理想的です。たとえば、Image サービス (openstack-glance) は Object Storage サービスで管理するコンテナーにイメージを保存することができます。

1.3. セキュリティー

Block Storage サービスは、ボリュームの暗号化 を使用して基本的なデータセキュリティーを確保します。これにより、静的キーでボリューム種別を暗号化するように設定でき、このキーは設定したボリュームの種別から作成したボリュームすべてを暗号化する際に使用することができます。詳細は「静的キーを使用したボリュームの暗号化」を参照します。

一方で、オブジェクトとコンテナーのセキュリティーは、サービスおよびノードレベルで設定されます。Object Storage サービスでは、コンテナーとオブジェクトに対するネイティブの暗号化はなく、Object Storage サービスによりクラウド内のアクセス性の優先順位が付けられるため、オブジェクトデータの保護はクラウドのネットワークセキュリティーにのみ依存します。

Shared File System サービスでは、インスタンスの IP アドレス、ユーザー/グループ、または TLS 証明書別にアクセス制限することで共有のセキュリティーを確保することができます。さらに、一部の Shared File System サービスのデプロイメントは、別の 共有サービス が備えられているため、共有ネットワークと共有間の関係を管理することができます。共有サーバーによっては追加のネットワークセキュリティーをサポートする (または必要とする) 場合があります。たとえば、CIFS 共有サーバーでは LDAP、Active Directory または Kerberos 認証サービスのデプロイメントが必要です。

1.4. 冗長性および災害復旧

Block Storage サービスには、ボリュームのバックアップと復旧機能があり、ユーザーストレージの基本的な災害復旧を行います。バックアップで、ボリュームのコンテンツを保護することができます。それに加え、サービスはクローン作成以外にスナップショットもサポートしており、以前の状態にボリュームを復元する際に役立ちます。

マルチバックエンドの環境では、バックエンド間でボリュームを移行することも可能です。この機能は、メンテナンスでバックエンドをオフラインにする必要がある場合に役立ちます。バックアップは通常、データが保護できるように、ソースのボリュームとは別のストレージバックエンドに保存されます。ただし、スナップショットはソースのボリュームに依存するため、この方法を用いることはできません。

最後に、Block Storage サービスには ボリュームの複製 機能も備えられているため、ボリューム間でコンテンツを複製するように設定して、基本的な冗長性を提供することができます。

注記

ボリュームの複製は、特定のサードパーティーのバックエンド、およびそれに適したドライバーを使用することでのみ利用可能です。

Object Storage サービスには、バックアップ機能がないため、すべてのバックアップはファイルシステムまたはノードレベルで行う必要がります。ただし、このサービスにはより強力な冗長機能とフォールトトレランスが備えられており、Object Storage サービスの最も基本的なデプロイメントでさえ、複数回オブジェクトを複製します。dm-multipath などのフェイルオーバー機能を使用して冗長性を強化することができます。

Shared File System サービスは、共有に対するバックアップ機能が含まれていませんが、スナップショットを作成してクローンを作成したり、復元したりすることができます。

第2章 Block Storage とボリューム

Block Storage サービス (openstack-cinder) は、全ボリュームの管理タスク、セキュリティー、スケジューリング、全体を管理します。Compute インスタンスでは、永続ストレージとしてボリュームが主に使用されます。

2.1. バックエンド

デフォルトでは、Block Storage サービスは、ボリュームのリポジトリーとして LVM バックエンドを使用します。このバックエンドは、テスト環境に適していますが、Enterprise 環境にはより堅牢なバックエンドをデプロイすることを推奨します。

この環境に Red Hat OpenStack Platform をデプロイする際は director を使用することを推奨します。director を使用することで、Block Storage サービス (拡張でバックエンドも含む) など、各サービスが正しく設定されるようにします。director には、複数のバックエンド設定が統合されています。

Red Hat OpenStack Platform は、Block Storage バックエンドとして Red Hat Ceph および NFS をサポートします。各デプロイメントの方法は、『director のインストールと使用方法』を参照してください。特に以下のセクションを参照してください。

「Ceph Storage」 (概要)、「Ceph Storage ノードの要件」 (要件)、『オーバークラウド向けの Red Hat Ceph Storage』 (デプロイメントの説明)
「NFS ストレージの設定」

サードパーティーのストレージプロバイダー

Block Storage サービスをサポート対象のサードパーティー製ストレージアプライアンスを使用するように設定することも可能です。director には、以下が簡単にデプロイされるように、必要なコンポーネントが含まれています。

Dell EqualLogic
Dell Storage Center
NetApp (サポート対象のアプライアンス)

Fujitsu ETERNUS もバックエンドとしてサポートされていますが、director にはまだ統合されていません。カスタム (統合されていない) バックエンドをデプロイする方法は、『Custom Block Storage Back End Deployment Guide』を参照してください。

サポートされるバックエンドアプライアンスとドライバーの完全な一覧は「Component, Plug-In, and Driver Support in RHEL OpenStack Platform」を参照してください。

2.2. Block Storage サービスの管理

以下の手順では、Block Storage サービスをニーズに合わせて設定する方法を説明します。以下の手順はすべて管理者権限が必要です。

2.2.1. ボリューム種別へのボリューム設定の関連付け

OpenStack では、ボリューム種別を作成することができ、種別に関連付けられた設定を適用することができます。そのため、ボリュームの作成時 (「ボリュームの作成」) や作成後にも (「ボリューム種別の変更」) これらの設定を適用することができます。たとえば、以下のような関連付けが可能です。

ボリュームの暗号化/非暗号化 (「ボリューム種別の暗号化設定」)
ボリュームが使用するバックエンド (「ボリュームを作成するバックエンドの指定」および「バックエンド間での移行」)
Quality-of-Service (QoS) スペック

設定は、「追加スペック」と呼ばれるキーと値のペアを使用してボリューム種別に関連付けられます。ボリュームの作成時にボリューム種別を指定する際には、Block Storage のスケジューラーがこれらのキーと値のペアを設定として適用します。また、複数のキーと値のペアを同じボリューム種別に関連付けることができます。

ボリューム種別は、異なるユーザーにストレージ階層を使用できるようにする機能をします。特定のパフォーマンス、耐障害性、およびその他の設定をキーと値のペアとしてボリューム種別に関連付けることにより、階層固有の設定を異なるボリューム種別にマップすることができます。マップされた階層固有の設定は、ボリュームの作成時に対応するボリューム種別を指定することによって適用が可能です。

注記

利用可能な追加スペックやサポートされている追加スペックは、ボリュームのドライバーにより異なります。有効な追加スペックの一覧については、ボリュームドライバーのマニュアルを参照してください。

2.2.1.1. ホストドライバーの機能一覧

利用可能な追加スペックやサポートされている追加スペックは、バックエンドのドライバーにより異なります。有効な追加スペックの一覧については、ボリュームドライバーのマニュアルを参照してください。

または、Block Storage ホストに直接クエリーを送信して、そのドライバーがサポートしている、明確に定義された標準の追加スペックを確認することができます。コマンドラインから、Block Storage サービスをホストするノードにログインしてから、以下のコマンドを実行します。

# cinder service-list

このコマンドは、各 Block Storage サービス (cinder-backup、cinder-scheduler、cinder-volume) のホストが含まれる一覧を返します。たとえば以下のとおりです。

+------------------+---------------------------+------+---------
|      Binary      |            Host           | Zone |  Status ...
+------------------+---------------------------+------+---------
|  cinder-backup   |   localhost.localdomain   | nova | enabled ...
| cinder-scheduler |   localhost.localdomain   | nova | enabled ...
|  cinder-volume   | localhost.localdomain@lvm | nova | enabled ...
+------------------+---------------------------+------+---------

Block Storage サービスのドライバーの機能を表示するには (これによりサポートされる追加スペックを判断)、以下のコマンドを実行します。

# cinder get-capabilities VOLSVCHOST

VOLSVCHOST は cinder-volume のホストの完全な名前に置き換えます。以下に例を示します。

# cinder get-capabilities localhost.localdomain@lvm
    +---------------------+-----------------------------------------+
    |     Volume stats    |                        Value            |
    +---------------------+-----------------------------------------+
    |     description     |                         None            |
    |     display_name    |                         None            |
    |    driver_version   |                        3.0.0            |
    |      namespace      | OS::Storage::Capabilities::localhost.loc...
    |      pool_name      |                         None            |
    |   storage_protocol  |                        iSCSI            |
    |     vendor_name     |                     Open Source         |
    |      visibility     |                         None            |
    | volume_backend_name |                         lvm             |
    +---------------------+-----------------------------------------+
    +--------------------+------------------------------------------+
    | Backend properties |                        Value             |
    +--------------------+------------------------------------------+
    |    compression     |      {u'type': u'boolean', u'description'...
    |        qos         |              {u'type': u'boolean', u'des ...
    |    replication     |      {u'type': u'boolean', u'description'...
    | thin_provisioning  | {u'type': u'boolean', u'description': u'S...
    +--------------------+------------------------------------------+

Backend properties の列には設定可能な追加スペックキーの一覧が、Value の列には、backend properties に対する有効な値が表示されます。

2.2.1.2. ボリューム種別の作成と設定

Dashboard に管理ユーザーとしてログインして 管理 > ボリューム > ボリューム種別 を選択します。
ボリューム種別の作成 をクリックします。
名前フィールドにボリューム種別の名前を入力します。
ボリューム種別の作成 をクリックします。ボリューム種別 の表に新しい種別が表示されます。
ボリューム種別の 追加スペックの表示 のアクションを選択します。
作成をクリックしてキーと値を指定します。キーと値のペアは有効である必要があります。有効でない場合には、ボリュームの作成時にそのボリューム種別を指定するとエラーが発生してしまいます。
作成をクリックします。関連づけられた設定 (キー/値のペア) が 追加スペック の表に表示されます。

デフォルトでは、すべてのボリューム種別が OpenStack の全テナントにアクセス可能です。アクセスが制限されたボリューム種別を作成する必要がある場合は、CLI から作成する必要があります。手順については「プライベートのボリューム種別の作成と設定」を参照してください。

注記

QoS スペックをボリューム種別に関連付けることも可能です。詳しい説明は、「QoS スペックとボリューム種別の関連付け」を参照してください。

2.2.1.3. ボリューム種別の編集

Dashboard に管理ユーザーとしてログインして 管理 > ボリューム > ボリューム種別 を選択します。
ボリューム種別 の表で、ボリューム種別の 追加スペックの表示 のアクションを選択します。
このページの 追加スペック 表では、以下のような操作を行うことができます。
- ボリューム種別への新規設定の追加。これには、作成をクリックして、ボリューム種別に対して、関連付ける新規設定のキー/値ペアを指定します。
- ボリューム種別に関連付けられている既存の設定の編集。これには、設定の編集アクションを選択します。
- ボリューム種別に関連付けられている既存の設定の削除。これには、追加スペックのチェックボックスを選択して、このダイアログ画面と次の画面で 追加スペックの削除 をクリックします。

2.2.1.4. ボリューム種別の削除

ボリューム種別を削除するには、ボリューム種別 の表でそのボリューム種別のチェックボックスを選択して ボリューム種別の削除 をクリックします。

2.2.1.5. プライベートのボリューム種別の作成と設定

デフォルトでは、すべてのボリューム種別が全テナントに対して表示されます。ボリューム種別の作成中に、プライベート に指定すると、この設定をオーバーライドすることができます。そのためには、その種別の Is_Public フラグを False に設定する必要があります。

プライベートのボリューム種別は、特定のボリューム設定に対するアクセスを制限するのに役立ちます。これは通常は、特定のテナントのみが使用可能とする必要のある設定です。たとえば、テスト中の新規バックエンドや超ハイパフォーマンスの設定などが例としてあげられます。

プライベートのボリューム種別を作成するには、以下のコマンドを実行します。

# cinder --os-volume-api-version 2 type-create --is-public false VTYPE

+ VTYPE は、プライベートのボリューム種別の名前に置き換えます。

デフォルトでは、プライベートのボリューム種別は、作成者のみがアクセス可能ですが、admin ユーザーは、以下のコマンドを使用するとプライベートのボリューム種別を特定/表示することができます。

# cinder --os-volume-api-version 2 type-list --all

このコマンドは、パブリックとプライベートの両方のボリューム種別を一覧表示します。一覧には、各ボリューム種別の名前と ID も表示されます。ボリューム種別にアクセスするには、そのボリューム種別の ID が必要となります。

プライベートのボリューム種別へのアクセスは、テナントレベルで許可されます。テナントがプライベートのボリューム種別にアクセスできるようにするには、以下のコマンドを実行します。

# cinder --os-volume-api-version 2 type-access-add --volume-type VTYPEID --project-id TENANTID

上記の設定で、

VTYPEID は、プライベートのボリューム種別の ID に置き換えます。
TENANTID は、VTYPEID へのアクセスを許可するプロジェクト/テナントの ID に置き換えます。

プライベートのボリューム種別にアクセス可能なテナントを確認するには、以下のコマンドを実行します。

# cinder --os-volume-api-version 2 type-access-list --volume-type VTYPE

プライベートのボリューム種別のアクセスリストからテナントを削除するには、以下のコマンドを実行します。

# cinder --os-volume-api-version 2 type-access-remove --volume-type VTYPE --project-id TENANTID

注記

プライベートのボリューム種別へのアクセスは、デフォルトでは管理権限のあるユーザーのみが作成、表示、設定することが可能です。

2.2.2. Block Storage サービスの内部テナントの作成および設定

Block Storage 機能 (例: Image-Volume キャッシュ) の一部では、内部テナント の設定を必要とします。Block Storage サービスは、このテナントを使用して、通常のユーザーに公開する必要のないブロックストレージアイテムを管理します。このようなアイテムの例として、頻繁にボリュームをクローン作成したり、ボリュームの一時コピーを移行したりするためにキャッシュされたイメージなどが挙げられます。

内部テナントを設定するには、まず cinder-internal という名前の一般テナントとユーザーを作成します。これには、コントローラーノードにログインして以下のコマンドを実行します。

# keystone tenant-create --name cinder-internal --enabled true --description "Block Storage Internal Tenant"
    +-------------+----------------------------------+
    |   Property  |              Value               |
    +-------------+----------------------------------+
    | description |  Block Storage Internal Tenant   |
    |   enabled   |               True               |
    |      id     | cb91e1fe446a45628bb2b139d7dccaef |
    |     name    |         cinder-internal          |
    +-------------+----------------------------------+
# keystone user-create --name cinder-internal
    +----------+----------------------------------+
    | Property |              Value               |
    +----------+----------------------------------+
    |  email   |                                  |
    | enabled  |               True               |
    |    id    | 84e9672c64f041d6bfa7a930f558d946 |
    |   name   |         cinder-internal          |
    | username |         cinder-internal          |
    +----------+----------------------------------+

テナントおよびユーザーを作成すると、それぞれの ID が表示される点に注意してください。Block Storage サービスがテナントとユーザーの両方を内部テナントとして使用するように、それらの ID を指定して設定します。この操作を行うには、各 Block Storage ノードで以下のコマンドを実行します。

# openstack-config --set /etc/cinder/cinder.conf DEFAULT cinder_internal_tenant_project_id TENANTID
# openstack-config --set /etc/cinder/cinder.conf DEFAULT cinder_internal_tenant_user_id USERID

TENANTID と USERID は、keystone で作成したテナントとユーザーの各 ID に置き換えます。たとえば、上記で表示された ID を使用した例は以下のとおりです。

# openstack-config --set /etc/cinder/cinder.conf DEFAULT cinder_internal_tenant_project_id cb91e1fe446a45628bb2b139d7dccaef
# openstack-config --set /etc/cinder/cinder.conf DEFAULT cinder_internal_tenant_user_id 84e9672c64f041d6bfa7a930f558d946

2.2.3. Image-Volume キャッシュの設定および有効化

Block Storage サービスには、任意の Image-Volume キャッシュ が含まれており、イメージからボリュームを作成する際にこのキャッシュを使用できます。このキャッシュは、頻繁に使用するイメージからボリュームを作成する際の時間を短縮するように設計されています。イメージからボリュームを作成する方法は「ボリュームの作成」を参照してください。

Image-Volume のキャッシュを有効化すると、ボリュームの初回作成時にベースとなったイメージのコピーが保存されます。この保存されたイメージは、Block Storage バックエンドのローカルにキャッシュされ、次回このイメージを使用してボリュームを作成する際のパフォーマンス向上に役立ちます。Image-Volume キャッシュは、サイズ (GB)、イメージ数、または両方を指定して上限を設定することができます。

Image-Volume キャッシュは、複数のバックエンドでサポートされます。サードパーティーのバックエンドを使用する場合は、Image-Volume キャッシュサポートに関する情報については、サードパーティーのドキュメントを参照してください。

注記

Image-Volume キャッシュでは、内部テナント を Block Storage サービスに設定する必要があります。方法は、「Block Storage サービスの内部テナントの作成および設定」を参照してください。

Block Storage ノードで Image-Volume キャッシュを有効化して設定するには、以下のコマンドを実行します。

# openstack-config --set /etc/cinder/cinder.conf DEFAULT image_volume_cache_enabled = True

デフォルトでは、Image-Volume キャッシュサイズはバックエンドによってのみ制限されます。最大サイズ (MAXSIZE、GB 単位) を設定するには、以下のコマンドを実行します。

# openstack-config --set /etc/cinder/cinder.conf DEFAULT image_volume_cache_max_size_gb = MAXSIZE

または、イメージの最大数を設定することもできます (MAXNUMBER)。設定するには、以下のコマンドを実行します。

# openstack-config --set /etc/cinder/cinder.conf DEFAULT image_volume_cache_max_count = MAXNUMBER

Block Storage サービスのデータベースは、タイムスタンプを使用して、キャッシュされた各イメージの最終使用日時をトラッキングします。MAXSIZE と MAXNUMBER のいずれか一方または両方が設定されている場合は、Block Storage サービスは必要に応じてキャッシュされたイメージを削除し、新たにイメージをキャッシュするためのスペースを解放します。Image-Volume キャッシュが上限に達すると、最も古いタイムスタンプが付いたキャッシュイメージが最初に削除されます。

Image-Volume のキャッシュを設定した後に、Block Storage サービスを再起動します。

# openstack-service restart cinder

2.2.4. QoS スペックの使用

複数のパフォーマンス設定を単一の Quality-of-Service の仕様 (QoS スペック) にマップすることができます。これにより、ユーザータイプ別のパフォーマンス階層を提供することができます。

パフォーマンス設定はキーと値のペアとして QoS スペックにマップされます。これは、ボリュームの設定がボリューム種別に関連付けられる方法と似ていますが、QoS スペックの場合は以下の面でボリューム種別の場合とは異なります。

QoS スペックは、ディスクの読み取り/書き込み操作を制限するなどのパフォーマンス設定を適用するのに使用されます。利用可能かつサポートされているパフォーマンス設定はストレージドライバーによって異なります。
バックエンドがサポートしている QoS スペックを確認するには、そのバックエンドデバイスのボリュームドライバーのマニュアルを参照してください。
ボリューム種別はボリュームに直接適用されるのに対して QoS スペックは直接適用されるのではなく、ボリューム種別に関連付けられます。また、ボリュームの作成時にボリューム種別を指定すると、そのボリューム種別に関連付けられた QoS スペックにマップされたパフォーマンス設定も適用されます。

2.2.4.1. QoS スペックの作成と設定

管理者は、「QoS スペック」の表で QoS スペックの作成および設定を行うことができます。同じ QoS スペックには、複数のキー/値のペアを関連づけることができます。

Dashboard に管理ユーザーとしてログインして 管理 > ボリューム > ボリューム種別 を選択します。
QoS スペック の表で QoS スペックの作成 をクリックします。
QoS スペック の名前を入力します。

使用者 フィールドで、QoS ポリシーを適用する先を指定します。

表2.1 使用者のタイプ

タイプ	説明
`back-end`	QoS ポリシーが Block Storage バックエンドに適用されます。
`front-end`	QoS ポリシーが Compute に適用されます。
`両方`	QoS ポリシーが Block Storage と Compute の両方に適用されます。

作成をクリックします。新規 QoS スペックが QoS スペック の表に表示されるはずです。
QoS スペック の表で、新規スペックの スペックの管理 アクションを選択します。
作成をクリックしてキーと値を指定します。キーと値のペアは有効である必要があります。有効でない場合には、ボリュームの作成時に、この QoS スペックに関連付けられたボリューム種別を指定するとエラーが発生してしまいます。
作成をクリックします。関連づけられた設定 (キー/値のペア) が キーと値のペア の表に表示されます。

2.2.4.2. QoS スペックとボリューム種別の関連付け

管理者は、ボリューム種別 の表で QoS スペックを既存のボリューム種別に関連付ける事ができます。

Dashboard に管理者としてログインして 管理 > ボリューム > ボリューム種別 を選択します。
ボリューム種別 の表で、その種別の QoS スペックの関連付けの管理 のアクションを選択します。
関連付ける QoS スペック のリストから QoS スペックを選択します。
割り当て をクリックします。選択した QoS スペックが、編集したボリューム種別の QoS スペックの関連付け のコラムに表示されるようになります。

2.2.4.3. ボリューム種別からの QoS スペックの関連付け解除

Dashboard に管理者としてログインして 管理 > ボリューム > ボリューム種別 を選択します。
ボリューム種別 の表で、その種別の QoS スペックの関連付けの管理 のアクションを選択します。
「関連付ける QoS スペック」のリストからなしを選択します。
割り当て をクリックします。選択した QoS スペックは、編集したボリューム種別の QoS スペックの関連付け のコラムに表示されなくなります。

2.2.5. 静的キーを使用したボリュームの暗号化

ボリュームの暗号化は、ボリュームのバックエンドのセキュリティーを侵害されたり、完全に盗難されたりした場合に、基本的なデータ保護を提供します。暗号化ボリュームの内容は、特定のキーを使用しなければ読み取ることはできません。インスタンスが暗号化ボリュームを使用するためには、Compute サービスと Block Storage サービスの両方で同じキーを使用するように設定する必要があります。また、暗号化を使用する固有のボリューム種別を作成することや、暗号化されたボリューム種別を使用して作成された全ボリュームを作成することも可能です。

本項では、OpenStack デプロイメントで暗号化ボリュームに単一のキーを使用するように設定する方法を説明します。

重要

現在、ボリュームの暗号化はブロックデバイスでバッキングされているボリュームでのみサポートされます。ネットワークが接続されたボリュームの暗号化 (RBD) またはファイルベースのボリューム (NFS など) はまだサポートされていません。

2.2.5.1. 静的キーの設定

基本的なボリュームの暗号化を実装する第 1 のステップは、静的キーの設定です。このキーは 16 進数の文字列にする必要があります。これは Block Storage ボリュームサービス (openstack-cinder-volume) と全 Compute サービス (openstack-nova-compute) によって使用されます。両サービスがこのキーを使用するように設定するには、両サービスのそれぞれの設定ファイルの [keymgr] セクションで fixed_key 値としてキーを設定します。

コマンドラインから、openstack-cinder-volume をホストしているノードに、root としてログインします。
静的キーを設定します。
```
# openstack-config --set /etc/cinder/cinder.conf keymgr fixed_key HEX_KEY
```
HEX_KEY は、16桁の英数字の 16 進数キー (例: 04d6b077d60e323711b37813b3a68a71) に置き換えます。
以下のように openssl コマンドを使用してキーを生成します。
```
# openssl rand -hex 16
04d6b077d60e323711b37813b3a68a71
```
注記
この値はセキュアでなければなりません。
Block Storage ボリュームサービスを再起動します。
```
# openstack-service restart cinder-volume
```
次に、openstack-nova-compute をホストするノードにログインして、同じ静的キーを設定します。
```
# openstack-config --set /etc/nova/nova.conf keymgr fixed_key HEX_KEY
```
注記
複数のコンピュートノード (openstack-nova-compute をホストする複数のノード) を使用している場合には、同じ静的キーを各ノードの /etc/nova/nova.conf に設定する必要があります。
Compute サービスを再起動します。
```
# openstack-service restart nova-compute
```
注記
同様に、複数のコンピュートノードに静的キーを設定した場合には、各ノードで openstack-nova-compute サービスを再起動する必要があります。

この時点で、Compute サービスと Block Storage サービスの両方で同じ静的キーを使用してボリュームの暗号化/暗号化解除できるようになりました。つまり、新規インスタンスは静的キー (HEX_KEY) で暗号化したボリュームを使用できます。

2.2.5.2. ボリューム種別の暗号化設定

「静的キーの設定」の手順に従って設定した静的キーを使用して暗号化ボリュームを作成するには、暗号化されたボリューム種別 が必要です。ボリューム種別を暗号化設定するには、対象のボリューム種別が使用すべきプロバイダークラス、暗号、キーサイズを指定する必要があります。これには、以下のコマンドを実行します。

# cinder encryption-type-create --cipher aes-xts-plain64 --key_size BITSIZE --control_location front-end VOLTYPE nova.volume.encryptors.luks.LuksEncryptor

上記の設定で、

BITSIZE はキーのサイズに置き換えます (例: 512 ビットキーの場合は 512)。
VOLTYPE は暗号化するボリューム種別名に置き換えます。

上記のコマンドにより、nova.volume.encryptors.luks.LuksEncryptor プロバイダークラス、aes-xts-plain64 の暗号が設定されます。本リリースでは、ボリュームの暗号化でサポートされている設定はクラス/暗号のみです。

暗号化されたボリューム種別が設定されると、暗号化ボリュームを自動で呼び出すことができます。ボリューム種別の作成に関する情報は、「ボリューム種別の作成と設定」を参照してください。具体的には、ボリュームの作成 ウィンドウの種別のドロップダウンリストから暗号化されたボリューム種別を選択します (「ボリュームの基本的な使用方法と設定」を参照)。

プロジェクト > コンピュート > ボリューム のボリュームの下の 暗号化 で Yes をクリックすると、暗号化に関するメタデータを表示することができます。

2.2.6. ボリュームを複数のバックエンドに割り当てる方法の設定

Block Storage サービスが複数のバックエンドを使用するように設定されている場合には、設定済みのボリューム種別を使用して、ボリュームの作成先を指定することができます。詳しくは、「ボリュームを作成するバックエンドの指定」を参照してください。

ボリュームの作成時にバックエンドを指定していない場合には、Block Storage サービスにより、自動的に選択されます。Block Storage は、最初に定義したバックエンドをデフォルトとして設定します。このバックエンドは、容量がなくなるまで使用されます。容量がなくなった時点で、Block Storage は 2 番目に定義されたバックエンドをデフォルトに設定し、その容量がなくなるとさらに次のバックエンドがデフォルトに設定されるようになっています。

このメカニズムが必要な条件を満たさない場合には、フィルタースケジューラーを使用して、Block Storage がバックエンドを選択する方法を制御することができます。このスケジューラーは、以下の例に示したような異なるフィルターを使用して適切なバックエンドをトリアージすることができます。

AvailabilityZoneFilter: 要求されたボリュームのアベイラビリティーゾーン要件を満たさないバックエンドを除外します。
CapacityFilter: ボリュームを収容するのに十分な容量のあるバックエンドのみを選択します。
CapabilitiesFilter: ボリュームで指定した設定に対応可能なバックエンドのみを選択します。

フィルタースケジューラーは、以下の手順で設定します。

FilterScheduler を有効化します。

# openstack-config --set /etc/cinder/cinder.conf DEFAULT scheduler_driver cinder.scheduler.filter_scheduler.FilterScheduler

アクティブにする必要のあるフィルターを設定します。

# openstack-config --set /etc/cinder/cinder.conf DEFAULT scheduler_default_filters AvailabilityZoneFilter,CapacityFilter,CapabilitiesFilter

スケジューラーが適切なバックエンドを選択する方法を設定します。
- スケジューラーが、空き容量の最も大きなバックエンドを常に選択するようにするには、以下のコマンドを実行します。
```
# openstack-config --set /etc/cinder/cinder.conf DEFAULT scheduler_default_weighers AllocatedCapacityWeigher
# openstack-config --set /etc/cinder/cinder.conf DEFAULT allocated_capacity_weight_multiplier -1.0
```
- スケジューラーが、すべての適切なバックエンドの中から無作為に選択するようにするには、以下のコマンドを実行します。
```
# openstack-config --set /etc/cinder/cinder.conf DEFAULT scheduler_default_weighers ChanceWeigher
```
Block Storage スケジューラーを再起動して、設定を適用します。
```
# openstack-service restart openstack-cinder-scheduler
```

2.2.7. バックアップの管理

以下のセクションでは、Block Storage サービスでのボリュームのバックアップ設定をカスタマイズする方法を説明します。

2.2.7.1. テナントのバックアップクォータの表示と変更

大半のテナントストレージクォータ (ボリューム、ボリュームのストレージ、スナップショットの数) とは異なり、バックアップクォータは現在のところ、Dashboard では編集できません。

バックアップクォータは、コマンドラインインターフェース (cinder quota-update コマンド) でのみ編集することができます。

特定のテナント(TENANTNAME) のストレージクォータを確認するには、以下のコマンドを実行します。

# cinder quota-show TENANTNAME

特定のテナントで作成可能なバックアップの最大数 (MAXNUM) を更新するには、以下のコマンドを実行します。

# cinder quota-update --backups MAXNUM TENANTNAME

特定のテナント内の全バックアップの最大合計容量 (MAXGB) を更新するには、以下のコマンドを実行します。

# cinder quota-update --backup-gigabytes MAXGB TENANTNAME

特定のテナントのストレージクォータの使用状況を確認するには、以下のコマンドを実行します。

# cinder quota-usage TENANTNAME

2.2.7.2. Dashboard を使用したボリュームバックアップ管理の有効化

Dashboard を使用してボリュームの作成、表示、削除、復元ができるようになりました。これらの操作を実行するには、プロジェクト > コンピュート > ボリューム > ボリュームバックアップ タブを開いてください。

ただし、ボリュームバックアップ タブは、デフォルトでは有効化されません。有効にするには、Dashboard を適切に設定する必要があります。

/etc/openstack-dashboard/local_settings を開きます。

以下の設定を検索します。

OPENSTACK_CINDER_FEATURES = {
    'enable_backup': False,
}

この設定を以下のように変更します。

OPENSTACK_CINDER_FEATURES = {
    'enable_backup': True,
}

httpd サービスを再実行して、Dashboard を再起動します。
```
# systemctl restart httpd.service
```

2.2.7.3. バックアップリポジトリーとしての NFS 共有の設定

デフォルトでは、Block Storage サービスは Object Storage サービスをバックアップリポジトリーとして使用しますが、 Block Storage サービスが Object Storage サービスの代わりに既存の NFS 共有をバックアップリポジトリーとして使用するように設定することが可能です。この設定は、以下の手順に従って行います。

バックアップサービス (openstack-cinder-backup) をホストしているノードに、管理権限のあるユーザーとしてログインします。
Block Storage サービスが NFS バックアップドライバー (cinder.backup.drivers.nfs) を使用するように設定します。
```
# openstack-config --set /etc/cinder/cinder.conf DEFAULT backup_driver cinder.backup.drivers.nfs
```
バックアップリポジトリーとして使用する NFS 共有の詳細を設定します。
```
# openstack-config --set /etc/cinder/cinder.conf DEFAULT backup_share NFSHOST:PATH
```
上記の設定で、
- NFSHOST は、NFS サーバーの IP アドレスまたはホスト名に置き換えます。
- PATH は、NFSHOST 上の NFS 共有の絶対パスに置き換えます。
NFS 共有のマウントオプション設定を指定するには、以下のコマンドを実行します。
```
# openstack-config --set /etc/cinder/cinder.conf DEFAULT backup_mount_options NFSMOUNTOPTS
```
NFSMOUNTOPTS には、NFS マウントオプションのコンマ区切りの一覧を指定します (例: rw,sync)。サポートされているマウントオプションについての詳しい情報は、nfs および mount の man ページを参照してください。
Block Storage バックアップサービスを再起動して、変更を適用します。
```
# systemctl restart openstack-cinder-backup.service
```

2.2.7.3.1. 異なるバックアップファイルサイズの設定

バックアップサービスのバックアップするファイルのサイズは、最大 バックアップファイルサイズ を上限としています。ボリュームのバックアップがこの値を超える場合には、作成されるバックアップは複数のチャンクに分割されます。デフォルトのバックアップファイルサイズは 1.8 GB です。

異なるバックアップファイルサイズを設定するには、以下のコマンドを実行します。

# openstack-config --set /etc/cinder/cinder.conf DEFAULT backup_file_size SIZE

SIZE は指定するファイルサイズ (バイト単位) に置き換えます。Block Storage バックアップサービスを再起動して、変更を適用します。

# systemctl restart openstack-cinder-backup.service

2.3. ボリュームの基本的な使用方法と設定

以下の手順では、基本的なエンドユーザー向けのボリューム管理方法について説明します。これらの手順には管理者の権限は必要ありません。

2.3.1. ボリュームの作成

Dashboard で プロジェクト > コンピュート > ボリューム を選択します。

ボリュームの作成 をクリックして、以下のフィールドを編集します。

フィールド	説明
ボリューム名	ボリュームの名前
説明	ボリュームの簡単な説明 (オプション)
タイプ	オプションのボリューム種別 (「ボリューム種別へのボリューム設定の関連付け」を参照) 複数の Block Storage バックエンドがある場合には、このフィールドを使用して特定のバックエンドを選択します。詳しくは、「ボリュームを作成するバックエンドの指定」を参照してください。
容量 (GB)	ボリュームの容量 (ギガバイト単位)
アベイラビリティーゾーン	アベイラビリティーゾーン (論理サーバーグループ) は、ホストアグリゲートと併せて、OpenStack 内のリソースを分離する一般的な方法です。アベイラビリティーゾーンは、インストール中に定義されます。アベイラビリティーゾーンとホストについてのさらに詳しい説明は、Red Hat OpenStack Platform から『インスタンスおよびイメージガイド』の「ホストアグリゲートの管理」を参照してください。

ボリュームソース を指定します。

ソース	説明
ソースの指定なし (空のボリューム)	ボリュームは空となり、ファイルシステムやパーティションテーブルは含まれません。
スナップショット	既存のスナップショットをボリュームソースとして使用します。このオプションを選択すると、「スナップショットをソースとして使用する」の一覧が新たに表示され、スナップショットを選択できるようになります。ボリュームのスナップショットについての詳しい情報は、「ボリュームスナップショットの作成、使用、削除」を参照してください。
イメージ	既存のイメージをボリュームソースとして使用します。このオプションを選択すると、「イメージをソースとして使用する」の一覧が新たに表示され、イメージを選択できるようになります。
ボリューム	既存のボリュームをボリュームソースとして使用します。このオプションを選択すると、「ボリュームをソースとして使用する」の一覧が新たに表示され、ボリュームを選択できるようになります。

ボリュームの作成 をクリックします。ボリュームが作成されると、ボリューム の表に名前が表示されます。

後ほどボリュームの種別を変更することも可能です。詳しくは「ボリューム種別の変更」を参照してください。

2.3.2. ボリュームを作成するバックエンドの指定

複数の Block Storage バックエンドが設定された場合には、必ず、バックエンドごとにボリューム種別を作成する必要があります。その種別を使用して、作成したボリュームに、どのバックエンドを使用すべきかを指定することができます。ボリューム種別の詳しい情報は、「ボリューム種別へのボリューム設定の関連付け」を参照してください。

ボリュームの作成時にバックエンドを指定するには「種別」のドロップダウンリストから適切なボリューム種別を選択します (「ボリュームの作成」を参照)。

ボリュームの作成時にバックエンドを指定しない場合には、Block Storage サービスにより自動的に選択されます。デフォルトでは、このサービスは、最も空き容量の多いバックエンドを選択します。また、Block Storage サービスが利用可能な全バックエンドから無作為に選択するように設定することも可能です。詳しくは「ボリュームを複数のバックエンドに割り当てる方法の設定」を参照してください。

2.3.3. ボリュームの名前と説明の編集

Dashboard で プロジェクト > コンピュート > ボリューム を選択します。
対象のボリュームの ボリュームの編集 ボタンをクリックします。
必要に応じて、ボリュームの名前または説明を編集します。
ボリュームの編集 をクリックして、変更を保存します。

注記

暗号化ボリュームを作成するには、最初にボリュームの暗号化専用に設定されたボリューム種別を使用する必要があります。また、Compute サービスと Block Storage サービスの両方で、同じ静的キーを使用するように設定しておく必要があります。ボリュームの暗号化に必要な設定の方法についての説明は、「静的キーを使用したボリュームの暗号化」を参照してください。

2.3.4. ボリュームの削除

Dashboard で プロジェクト > コンピュート > ボリューム を選択します。
ボリューム の表で、削除するボリュームを選択します。
ボリュームの削除 をクリックします。

注記

スナップショットが存在する場合には、ボリュームは削除できません。スナップショットの削除手順については、「ボリュームスナップショットの作成、使用、削除」を参照してください。

2.3.5. インスタンスへのボリュームの接続と切断

インスタンスの永続ストレージにボリュームを使用することができます。ボリュームは、1 度に 1 つのインスタンスにしか接続できません。インスタンスに関する詳しい情報は、Red Hat OpenStack Platform から、『インスタンスおよびイメージガイド』の「インスタンスの管理」を参照してください。

2.3.5.1. インスタンスへのボリュームの接続

Dashboard で プロジェクト > コンピュート > ボリューム を選択します。
対象のボリュームの 接続の編集 アクションを選択します。ボリュームがインスタンスに接続されていない場合には、インスタンスへの接続 のドロップダウンリストが表示されます。
インスタンスへの接続 の一覧から、ボリュームの接続先となるインスタンスを選択します。
ボリュームの接続 をクリックします。

2.3.5.2. インスタンスからのボリュームの切断

Dashboard で プロジェクト > コンピュート > ボリューム を選択します。
対象のボリュームの 接続の管理 アクションを選択します。ボリュームがインスタンスに接続されている場合には、そのインスタンスの名前が 接続状況 の表に表示されます。
このダイアログ画面と次の画面で ボリュームの切断 をクリックします。

2.3.6. ボリュームの読み取り専用設定

1 つのボリュームでコンテンツを編集できないようにして、複数のユーザーに共有アクセスを許可することができます。そのためには、以下のコマンドを実行して、ボリュームを read-only に設定します。

# cinder readonly-mode-update VOLUME true

VOLUME は、ターゲットボリュームの ID に置き換えます。

読み取り専用ボリュームを読み取り/書き込み可能に戻すには、以下のコマンドを実行します。

# cinder readonly-mode-update VOLUME false

2.3.7. ボリュームの所有者の変更

ボリュームの所有者を変更するには、ボリュームの譲渡を行います。ボリュームの譲渡は、ボリュームの所有者が開始し、ボリュームの新しい所有者が譲渡を承認すると、そのボリュームの所有権の変更が完了します。

2.3.7.1. コマンドラインを使用したボリュームの譲渡

コマンドラインから、ボリュームの現在の所有者としてログインします。
利用可能なボリュームを一覧表示します。
```
# cinder list
```

以下のコマンドを実行して、ボリュームの譲渡を開始します。

# cinder transfer-create VOLUME

VOLUME は譲渡するボリュームの名前または ID に置き換えます。

  +------------+--------------------------------------+
  |  Property  |                Value                 |
  +------------+--------------------------------------+
  |  auth_key  |           f03bf51ce7ead189           |
  | created_at |      2014-12-08T03:46:31.884066      |
  |     id     | 3f5dc551-c675-4205-a13a-d30f88527490 |
  |    name    |                 None                 |
  | volume_id  | bcf7d015-4843-464c-880d-7376851ca728 |
  +------------+--------------------------------------+

cinder transfer-create コマンドはボリュームの所有権を消去し、譲渡用の id と auth_key を作成します。この値は別のユーザーに渡すことができます。受け取ったユーザーは、その値を使用して譲渡を承認し、ボリュームの新しい所有者となります。

新規ユーザーがボリュームの所有権を宣言できる状態となりました。所有権を宣言するには、ユーザーは最初にコマンドラインからログインして以下のコマンドを実行する必要があります。
```
# cinder transfer-accept TRANSFERID TRANSFERKEY
```
TRANSFERID と TRANSFERKEY はそれぞれ、cinder transfer-create で返された id と auth_key の値に置き換えます。以下に例を示します。
```
# cinder transfer-accept 3f5dc551-c675-4205-a13a-d30f88527490 f03bf51ce7ead189
```

注記

利用可能なボリュームの譲渡をすべて表示するには、以下のコマンドを実行します。

# cinder transfer-list

2.3.7.2. ダッシュボードを使用したボリュームの譲渡

Dashboard を使用したボリューム譲渡の作成

Dashboard にボリュームの所有者としてログインして プロジェクト > ボリューム を選択します。
譲渡するボリュームの アクション のコラムで、 譲渡の作成 を選択します。
ボリュームの譲渡の作成 ダイアログボックスで、譲渡名を入力して ボリュームの譲渡の作成 をクリックします。
ボリュームの譲渡が作成され、ボリュームの譲渡 の画面で 譲渡 ID と 認証キー を取得して譲渡先のプロジェクトに送信することができます。
注記
認証キーは ボリュームの譲渡 の画面にしか表示されません。この認証キーをなくした場合には、譲渡をキャンセルし、別の譲渡を作成して新たな認証キーを生成する必要があります。
ボリュームの譲渡 の画面を閉じて、ボリュームの一覧に戻ります。
譲渡先のプロジェクトが譲渡を受理するまで、ボリュームのステータスは awaiting-transfer と表示されます。

Dashboard を使用したボリューム譲渡の受理

Dashboard にボリュームの譲渡先としてログインして プロジェクト > ボリューム を選択します。
譲渡の受理 をクリックします。
ボリュームの譲渡の受理 のダイアログボックスで、ボリュームの所有者から受け取った 譲渡 ID と 認証キー を入力して、ボリュームの譲渡の受理 をクリックします。
譲渡先のプロジェクトのボリューム一覧に、そのボリュームが表示されるようになります。

2.3.8. ボリュームスナップショットの作成、使用、削除

ボリュームのスナップショットを作成することによって、ある特定の時点のボリュームの状態を保持することができます。そのスナップショットを使用して、新規ボリュームをクローン作成することが可能です。

注記

ボリュームのバックアップはスナップショットとは異なります。バックアップはボリューム内のデータを保持するのに対して、スナップショットはある特定の時点におけるボリュームの状態を保持します。また、スナップショットが存在している場合にはボリュームを削除することはできません。ボリュームのバックアップはデータ損失を防ぐ目的で使用されるのに対してスナップショットはクローン作成を円滑に行う目的で使用されます。

このため、スナップショットのバックエンドは、クローン作成中のレイテンシーを最小限に抑えるように、通常ボリュームのバックエンドと同じ場所に配置されます。一方、バックアップのリポジトリーは通常、一般的なエンタープライズデプロイメント内の別の場所に配置されます (例: 異なるノード、物理ストレージ、あるいは別の地理的ロケーションの場合もあり)。これは、ボリュームのバックエンドが一切ダメージを受けないように保護することを目的とします。

ボリュームのバックアップについての詳しい情報は、「ボリュームのバックアップと復元」を参照してください。

ボリュームのスナップショットの作成手順

Dashboard で プロジェクト > コンピュート > ボリューム を選択します。
対象のボリュームの スナップショットの作成 アクションを選択します。
作成するスナップショッットの スナップショット名 を指定して ボリュームのスナップショットの作成 をクリックします。ボリュームのスナップショット タブに全スナップショットが表示されます。

ボリュームのスナップショット の表にスナップショットが表示されたら、そのスナップショットから新規ボリュームをクローン作成することができます。この操作を行うには、対象のボリュームの ボリュームの作成 アクションを選択します。ボリュームの作成に関する詳しい説明は、「ボリュームの作成」を参照してください。

スナップショットを削除するには、ボリュームスナップショットの削除 アクションを選択します。

OpenStack デプロイメントで Red Hat Ceph バックエンドを使用している場合には、「Red Hat Ceph バックエンドにおけるスナップショットの保護と保護解除」でスナップショットのセキュリティーとトラブルシューティングについての詳しい情報を参照してください。

2.3.8.1. Red Hat Ceph バックエンドにおけるスナップショットの保護と保護解除

Red Hat Ceph を OpenStack デプロイメントのバックエンドとして使用する場合には、そのバックエンドでスナップショットの保護を設定することができます。OpenStack で (Dashboard または cinder snapshot-delete コマンドを使用して) 保護されているスナップショットの削除を試みると、操作は失敗します。

このようなエラーが発生した場合には、最初に Red Hat Ceph バックエンドでスナップショットを 保護解除 に設定すると、OpenStack で通常通りに削除することができるようになるはずです。

関連する手順については、「Protecting a Snapshot」および「Unprotecting a Snapshot」を参照してください。

2.3.9. Image サービスにボリュームをアップロードする手順

イメージとして既存のボリュームを Image サービスに直接アップロードすることができます。これには、以下の手順を実行してください。

Dashboard で プロジェクト > コンピュート > ボリューム を選択します。
対象のボリュームの イメージにアップロード アクションを選択します。
ボリュームの イメージ名 を指定して、一覧から ディスク形式 を選択します。
アップロード をクリックします。QEMU ディスクイメージのユーティリティーにより、指定した名前を使用して、選択した形式で新規イメージがアップロードされます。

アップロードしたイメージを表示するには、プロジェクト > コンピュート > イメージ を選択します。新しいイメージが イメージ の表に表示されます。イメージの使用方法や設定方法に関する情報は、Red Hat OpenStack Platform から『インスタンスおよびイメージガイド』の「イメージの管理」を参照してください。

2.3.10. ボリューム種別の変更

ボリューム種別の変更 は、ボリューム種別 (およびその設定) を既存のボリュームに適用するプロセスです。ボリューム種別に関する情報は「ボリューム種別へのボリューム設定の関連付け」を参照してください。

既存のボリューム種別の有無に拘らず、ボリューム種別は変更できます。いずれの場合も、ボリューム種別の追加スペックがボリュームに適用できる場合のみ、ボリューム種別の変更は成功します。これは、事前定義の設定を適用する際や、ストレージの属性を既存のボリュームに適用する際に役立ちます。以下に例を示します。

異なるのバックエンドへボリュームを移行する場合 (「バックエンド間での移行」)
ボリュームのストレージクラス/層を変更する場合

管理者権限のないユーザーは、自分が所有するボリューム種別しか変更できません。ボリューム種別を変更するには、以下のステップを実行します。

Dashboard で プロジェクト > コンピュート > ボリューム を選択します。
移行するボリュームの アクション のコラムで、ボリューム種別の変更 を選択します。
ボリューム種別の変更 ダイアログで、種別のドロップダウンリストから新しいバックエンドを定義する、移行先のボリューム種別を選択します。
注記
別のバックエンドにボリュームを移行する場合は、移行ポリシー のドロップダウンリストから 要求時 を選択します。詳しい情報は「バックエンド間での移行」を参照してください。
ボリューム種別の変更 をクリックして移行を開始します。

2.4. ボリュームの高度な設定

以下の手順では、ボリュームの高度な管理方法について説明します。

2.4.1. ボリュームのバックアップと復元

ボリュームのバックアップは、ボリュームのコンテンツの永続的なコピーです。ボリュームのバックアップは通常オブジェクトストアとして作成されるため、デフォルトでは、Object Storage サービスで管理されますが、バックアップに異なるリポジトリーを設定することができます。OpenStack は、バックアップ用のバックエンドのオプションとして Red Hat Ceph、NFS をサポートしています。

ボリュームのバックアップの作成時には、バックアップのメタデータはすべて Block Storage サービスのデータベースに保管されます。cinder ユーティリティーはこのメタデータを使用して、バックアップからボリュームを復元します。このため、データベースの致命的なデータ損失から回復する際には、バックアップからボリュームを復元する前に Block Storage サービスのデータベースを復元する必要があります。これは、元のボリュームのバックアップのメタデータがすべて完全な状態で Block Storage サービスのデータベースが復元されることも前提としています。

データベースの致命的なデータ損失が発生した際にボリュームのバックアップのサブセットのみを保護するように設定する場合は、バックアップのメタデータをエクスポートすることも可能です。メタデータをエクスポートすると、エクスポートしたデータを後で Block Storage のデータベースに再度インポートしてボリュームのバックアップを通常のように復元することができます。

注記

ボリュームのスナップショットに関する詳しい情報は、「ボリュームスナップショットの作成、使用、削除」を参照してください。

2.4.1.1. ボリュームの完全バックアップの作成

ボリュームをバックアップするには、cinder backup-create コマンドを使用します。デフォルトでは、このコマンドは、ボリュームの完全バックアップを作成します。ボリュームに既存のバックアップがある場合には、完全バックアップの代わりに、増分バックアップの作成を選択することができます (詳しくは「ボリュームの増分バックアップの作成」を参照)。

ボリュームのバックアップを作成できるのは、そのボリュームにアクセス可能なユーザーなので、管理権限があるユーザーは、ボリュームを誰が所有しているかにかかわらず、任意のボリュームのバックアップを作成できることになります。詳しい説明は、「admin としてのボリュームのバックアップ作成」を参照してください。

バックアップするボリュームの ID または 表示名 を確認します。
```
# cinder list
```

以下のコマンドを実行して、ボリュームをバックアップします。

# cinder backup-create VOLUME

VOLUME の箇所は、バックアップするボリュームの ID または 表示名 に置き換えます。以下に例を示します。

  +-----------+--------------------------------------+
  |  Property |                Value                 |
  +-----------+--------------------------------------+
  |     id    | e9d15fc7-eeae-4ca4-aa72-d52536dc551d |
  |    name   |                 None                 |
  | volume_id | 5f75430a-abff-4cc7-b74e-f808234fa6c5 |
  +-----------+--------------------------------------+

注記

作成されるバックアップの volume_id は、ソースボリュームの ID と全く同じになります。

以下のコマンドを実行して、ボリュームのバックアップ作成が完了したことを確認します。
```
# cinder backup-list
```
バックアップエントリーの ステータス が available に変わったら、ボリュームのバックアップ作成は完了です。

この時点で、ボリュームのバックアップのメタデータをエクスポートして保管することもできます。これにより、Block Storage データベースで致命的なデータ損失が発生した場合でも、ボリュームのバックアップを復元することができます。以下のコマンドを実行します。

# cinder --os-volume-api-version 2 backup-export BACKUPID

BACKUPID はボリュームのバックアップの ID または名前に置き換えます。

+----------------+------------------------------------------+
|    Property    |                Value                     |
+----------------+------------------------------------------+
| backup_service |     cinder.backup.drivers.swift          |
|   backup_url   | eyJzdGF0dXMiOiAiYXZhaWxhYmxlIiwgIm9iam...|
|                | ...4NS02ZmY4MzBhZWYwNWUiLCAic2l6ZSI6IDF9 |
+----------------+------------------------------------------+

ボリュームのバックアップのメタデータは backup_service と backup_url の値で構成されます。

2.4.1.1.1. admin としてのボリュームのバックアップ作成

管理者権限のあるユーザー (例: デフォルトの admin アカウントなど) は、OpenStack で管理されている任意のボリュームをバックアップすることができます。admin ユーザーが、admin 以外のユーザーの所有するボリュームをバックアップする場合には、そのボリュームの所有者からはバックアップはデフォルトでは表示されないように設定されます。

また、admin ユーザーとしてバックアップしたボリュームを、特定のテナントが利用できるようにすることも可能です。そのためには、以下のコマンドを実行します。

# cinder --os-auth-url KEYSTONEURL --os-tenant-name TENANTNAME --os-username USERNAME --os-password PASSWD backup-create VOLUME

上記の設定で、

TENANTNAME は、バックアップを利用できるテナントの名前に置き換えます。
USERNAME と PASSWD は、TENANTNAME 内のユーザーのユーザー名とパスワードに置き換えます。
VOLUME は、バックアップするボリュームの名前または ID に置き換えます。
KEYSTONEURL は、Identity サービスの URL エンドポイントに置き換えます (通常は http://IP:5000/v2 の形式。IP は Identity サービスホストの IP アドレス)。

この操作を実行する場合は、作成されるバックアップの容量は、admin テナントではなく、TENANTNAME のクォータに対して加算されます。

2.4.1.2. ボリュームの増分バックアップの作成

デフォルトでは、cinder backup-create コマンドを実行すると、ボリュームの完全バックアップが作成されますが、ボリュームに既存のバックアップがある場合には、増分バックアップを作成することが可能です。

増分バックアップは、前回のバックアップ (完全または増分バックアップ) 以降に加えられた変更をキャプチャーします。ボリュームの完全バックアップを何度も定期的に行うと、時間の経過とともにボリュームの容量が拡大されて、リソースを集中的に使用することになります。この点に関しては、増分バックアップの場合には、一定期間の変更のみをキャプチャーして、リソースの使用を最小限に抑えることができます。

増分バックアップを作成するには、--incremental オプションを使用します。

# cinder backup-create VOLUME --incremental

VOLUME の箇所は、バックアップするボリュームの ID または 表示名 に置き換えます。

注記

増分バックアップがすでに作成されている場合には、ベースとなっている完全バックアップを削除することはできません。また、完全バックアップに複数の増分バックアップがある場合、削除できるのは、最新の増分バックアップのみとなります。

増分バックアップは、NFS および Object Storage のバックアップリポジトリーで完全にサポートされています。 Ceph のバックアップリポジトリーでも増分バックアップはサポートされていますが、ボリュームも Ceph バックエンド上で保管されている場合のみとなります。

2.4.1.3. Block Storage データベースでデータ損失が発生した後の復元

通常、Block Storage のデータベースのデータ損失が発生すると、ボリュームのバックアップを復元できなくなります。これは、Block Storage データベースにボリュームのバックアップサービス (openstack-cinder-backup) で必要とされるメタデータが含まれているためです。このメタデータは backup_service と backup_url の値で構成され、ボリュームのバックアップ作成後に (「ボリュームの完全バックアップの作成」に記載した手順に従って) エクスポートすることができます。

メタデータをエクスポートして保管した場合には、新しい Block Storage データベースにインポートすることができます (これにより、ボリュームのバックアップを復元することができます)。

管理者権限を持つユーザーとして以下のコマンドを実行します。

# cinder --os-volume-api-version 2 backup-import backup_service backup_url

backup_service および backup_url は、エクスポートしたメタデータに置き換えます。たとえば、「ボリュームの完全バックアップの作成」でエクスポートしたメタデータを使用します。

# cinder --os-volume-api-version 2 backup-import cinder.backup.drivers.swift eyJzdGF0dXMi...c2l6ZSI6IDF9
+----------+--------------------------------------+
| Property |                Value                 |
+----------+--------------------------------------+
|    id    | 77951e2f-4aff-4365-8c64-f833802eaa43 |
|   name   |                 None                 |
+----------+--------------------------------------+

メタデータが Block Storage サービスのデータベースにインポートされたら、通常のようにボリュームを復元することができます (「バックアップからのボリュームの復元」を参照)。

2.4.1.4. バックアップからのボリュームの復元

使用するボリュームバックエンドの ID を確認します。
```
# cinder backup-list
```
Volume ID は、復元するボリュームの ID と一致する必要があります。
ボリュームのバックアップを復元します。
```
# cinder backup-restore BACKUP_ID
```
BACKUP_ID は使用するボリュームのバックアップ ID に置き換えます。
バックアップが必要なくなった場合には、削除します。
```
# cinder backup-delete BACKUP_ID
```

2.4.2. ボリュームの移行

Block Storage サービスでは、ホストまたはバックエンドの間でボリュームを移行することができます。現在使用中 (インスタンスに接続されている) ボリュームを移行することができますが、スナップショットがあるボリュームは移行できません。

ホスト間でボリュームを移行する際には、いずれのホストも同じバックエンドに配置する必要があります。これには以下のステップを実行します。

Dashboard で 管理 > ボリューム を選択します。
移行するボリュームの アクション のコラムで、ボリュームの管理 を選択します。
ボリュームの管理 ダイアログでは、移行先ホスト ドロップダウンリストからボリュームを移行する先のホストを選択します。
注記
ホストの移行でドライバーの最適化をスキップするには、強制ホストコピー のチェックボックスを選択します。
移行をクリックして移行を開始します。

2.4.2.1. バックエンド間での移行

バックエンド間でボリュームを移行するには ボリューム種別の変更 を行う必要があります。つまり。新規バックエンドを移行するには、以下が前提となります。

新規バックエンドは、別の 移行先のボリューム種別 の 追加スペック として指定する必要があります。
移行先のボリューム種別に定義された、その他の追加スペックは、ボリュームの移行元のボリューム種別と互換性がなければなりません。

詳細は「ボリューム種別へのボリューム設定の関連付け」と「ボリュームを作成するバックエンドの指定」を参照してください。

追加スペックとしてバックエンドを定義する場合は、キーとして volume_backend_name を使用します。これに対応する値は、Block Storage の設定ファイル (/etc/cinder/cinder.conf) に定義されているように、バックエンドの名前になります。このファイルでは、各バックエンドは独自のセクションに定義され、対応の名前は volume_backend_name のパラメーターに設定されています。

移行先のボリューム種別にバックエンドを定義すると、ボリューム種別の変更 でバックエンドにボリュームを移行することができます。この際には、移行先のボリューム種別をボリュームに再適用し、それにより新しいバックエンドの設定が適用されます。方法は「ボリューム種別の変更」を参照してください。

以下の手順に従って設定します。

Dashboard で プロジェクト > コンピュート > ボリューム を選択します。
移行するボリュームの アクション のコラムで、ボリューム種別の変更 を選択します。
ボリューム種別の変更 ダイアログで、種別のドロップダウンリストから新しいバックエンドを定義する、移行先のボリューム種別を選択します。
移行ポリシー から 要求時 を選択します。
ボリューム種別の変更 をクリックして移行を開始します。

第3章 Object Storage およびコンテナー

OpenStack Object Storage (openstack-swift) は、コンテナー内にオブジェクト (データ) を格納します。コンテナーとは、ファイルシステムにおけるディレクトリーと似ています。ただし、入れ子にはできません。コンテナーは、あらゆるタイプの非構造化データを格納する簡単な方法をユーザーに提供します。たとえば、オブジェクトには写真、テキストファイル、イメージなどが含まれます。格納されるオブジェクトは暗号化や圧縮はされません。

3.1. Object Storage サービスの管理

以下の手順では、Object Storage サービスをニーズに合わせてさらにカスタマイズする方法について説明します。

3.1.1. Object Storage サービスの Erasure Code

Erasure coding (EC) は、データの断片化、拡張、冗長データによる暗号化、別の場所やストレージメディアセットでの保存の際にデータを保護する方法です。EC は、従来のレプリケーションより小さいストレージボリュームを使用して、必要とされる耐久性を取得します。レプリケーションファクターが 3 のものと比較すると、注意深くデプロイメントを行うことで、50％の節約が実現できます。ただし、ワークロードによっては、Erasure Coding がパフォーマンスに悪影響を与える可能性があります。

Red Hat OpenStack Platform 8 リリースには、Object Storage サービス向けの Erasure Coding サポートがテクノロジープレビューとして利用できます。テクノロジープレビューとして提供されている機能のサポート範囲についての詳しい情報は、https://access.redhat.com/support/offerings/techpreview/ を参照してください。

Erasure Coding は、Object Storage Service 向けにストレージポリシーとしてサポートされます。ストレージポリシーにより複数のオブジェクトリングを作成することでさまざまな目的のクラスターをセグメント化できます。Red Hat は、Erasure Coding およびレプリケーションストレージポリシーで使用するデバイスを分割することを推奨します。これにより、クラスターの動きをより簡単に分析することができます。

選択する方向性は、Erasure Coding ポリシーのデプロイの理由により異なります。主な検討事項は以下のとおりです。

既存のインフラストラクチャーのレイアウト
専用の Erasure Coding ノード (または Erasure Coding デバイス)の追加コスト
目的とする使用モデル

3.1.1.1. Erasure Coding の設定

Erause Coding ポリシーを使用するには、swift.conf ファイルで Erasure Coding ポリシーを定義して、関連のオブジェクトリングを作成、設定します。Erasure Coding ポリシーの設定方法例は、以下のとおりです。

[storage-policy:2]
name = ec104
policy_type = erasure_coding
ec_type = jerasure_rs_vand
ec_num_data_fragments = 10
ec_num_parity_fragments = 4
ec_object_segment_size = 1048576

以下の表では、ストレージポリシーの用語を説明しています。

用語	説明
name	標準のストレージポリシーのパラメーター
policy_type	この値を erasure_coding に設定して、Erasure Coding ポリシーであることを指定します。
ec_type	この値は、選択した PyECLib バックエンドの利用可能なオプションに合わせて設定します。これは、使用する Erasure Coding スキームを指定します。たとえば、ここで示すオプションでは、Vandermonde Reed-Solomon の暗号化を選択していますが、flat_xor_hd_3 のオプションは Flat-XOR ベースの HD の組み合わせコードを選択します。完全な詳細は、PyECLib を参照してください。
ec_num_data_fragments	データを構成するフラグメントの合計数
ec_num_parity_fragments	パリティーを構成するフラグメントの合計数
ec_object_segment_size	セグメントをエンコーダー/デコーダーにフィードする前に増やすデータのバッファー量。デフォルト値は 1048576 です。

PyECLib がオブジェクトを暗号化する際には、N 個のフラグメントに分割します。設定時に、フラグメントのうち何個がデータで、何個がパリティーであるかを知っておくことが重要です。上記の例では、PyECLib はオブジェクトを 14 個のフラグメントに分割して、そのうち、実際のオブジェクトデータは 10 個で、パリティーデータは 4 個 (計算は ec_type に左右される) です。このような設定では、システムは、ディスクの障害は 4 回分までであればデータの損失なしで済みます。その他に一般的に使用される設定は 4+2 (データフラグメント 4 個とパリティーフラグメント 2 個) または 8+3 (データフラグメント 8 個とパリティーフラグメント 3 個) です。

注記

ポリシーをデプロイして、そのポリシーでオブジェクトを作成した後にはこれらの設定オプションの変更はできない点にご注意ください。設定の変更が望ましい場合には、新規ポリシーを作成して、データを新しいコンテナーに移行します。ただし、定義が済むと、ポリシーのインデックスは破棄できません。ポリシーを終了する場合には、ポリシーを無効にすることはできますが、削除はできません。基本的に、以前のポリシーが残っていてもパフォーマンスへの影響はありませんが、若干、管理の負担が出てきます。

3.1.1.2. オブジェクトストレージリングの設定

オブジェクトストレージは、リング と呼ばれるデータ構造を使用して、パーティション領域をクラスターに分散します。このパーティション領域は、Object Storage サービスのレプリケーションシステムの中核となります。これにより、Object Storage サービスが迅速かつ簡単にクラスター内の各パーティションを同期できるようになります。Swift のコンポーネントがデータと対話する必要がある場合には、ローカルでリング内を素早く検索して、各レプリカに使用可能なパーティションを見つけます。

Object Storage サービスにはすでに 3 つのリングがあり、各種データが格納されています。リングは、アカウント情報に 1 つ、(アカウント内のオブジェクトを整理するのに役立つ) コンテナーに 1 つ、オブジェクトのレプリカに 1 つあります。Erasure Code をサポートするために、Erasure Code のチャンクを格納するために作成された追加のリングがあります。

たとえば、典型的なレプリケーションリングを作成するには、以下のコマンドを使用します。

swift-ring-builder object-1.builder create 10 3 1

3 は、レプリカの数です。

以下のように、Erasure Coding のオブジェクトリングを作成するには、レプリカの数の部分にフラグメントの数を指定する必要があります。

swift-ring-builder object-1.builder create 10 14 1

14 は、データフラグメント 10 とパリティーフラグメント 4 (10+4) を合わせた設定です。

Erasure Coding ポリシーのオブジェクトリングで使用するデバイスを決定する際には、パフォーマンスの影響を考慮します。デプロイメントの前の設定に対して、テスト環境でパフォーマンスのベンチマーキングを実行することを推奨します。swift.conf で Erasure Coding のポリシーを設定してオブジェクトリングを作成した後には、指定のポリシー名でコンテナーを作成して通常通りに対話することで、アプリケーションでの Erasure Coding の使用準備が整います。

3.1.2. Image サービスのバックエンドとしてのオブジェクトストレージの設定

デフォルトでは、OpenStack の Image サービスは、イメージおよびインスタンスのスナップショットを /var/lib/glance/images/ のローカルのファイルシステムに保存します。または、(可能な場合には) Image サービスが Object Storage サービスにイメージとスナップショットを保存するように設定することも可能です。

この設定には、以下の手順を実行します。

root として Image サービスを実行中のノード (Identity も実行するコントローラーノード) にログインし、OpenStack の認証情報 (これは通常 openrc という名前のファイル) を読み込みます。
```
# source ~/openrc
```
Image サービスが admin ロールを持つ service テナントの一部であることを確認します。
```
# keystone user-role-list --user glance --tenant service
```
返されたロールの 1 つは、admin でなければなりません。

/etc/glance/glance.conf ファイルを開き、以下の行をコメントアウトします。

##### DEFAULT OPTIONS #####
#default_store = file
#filesystem_store_datadir = /var/lib/glance/images/

同じファイル内で DEFAULT OPTIONS のセクションに以下の行を追加します。
```
default_store = swift
swift_store_auth_address = http://KEYSTONEIP:35357/v2.0/
swift_store_user = service:glance
swift_store_key = ADMINPW
swift_store_create_container_on_put = True
```
上記の設定で、
- KEYSTONEIP は、Identity サービスの IP アドレスに置き換えてください。
- ADMINPW は、/etc/glance/glance-api.conf ファイルの管理者パスワードの値に置き換えてください。

Image サービスを再起動して変更を適用します。

# systemctl restart openstack-glance-api
# systemctl restart openstack-glance-registry

この時点から、(Dashboard または glance 経由) Image サービスにアップロードされたイメージは glance という名前の Object Storage コンテナーに保存されるはずです。このコンテナーは、サービスアカウントに存在します。

新規作成イメージが Image サービスに保存されたことを確認するには、以下のコマンドを実行します。

# ls /var/lib/glance/images

Dashboard または glance image-list により、イメージがアクティブな状態であることが報告されたら、以下のコマンドを実行してイメージがオブジェクトストレージにあるかどうかを確認できます。

# swift --os-auth-url http://KEYSTONEIP:5000/v2.0 --os-tenant-name service --os-username glance --os-password ADMINPW list glance

3.2. 基本的なコンテナー管理

擬似フォルダーは、オブジェクトを格納することができる論理デバイスで、入れ子が可能となっているので、整理がしやすくなります。たとえば、画像を保管する Images フォルダーや、ビデオを保管する Media フォルダーなどを作成することができます。

各プロジェクトに 1 つまたは複数のコンテナーを作成することができます。また、各コンテナーには、1 つまたは複数の擬似フォルダーを作成することができます。

3.2.1. コンテナーの作成

Dashboard で プロジェクト > オブジェクトストア > コンテナー を選択します。
コンテナーの作成 をクリックします。

コンテナー名 を指定して、コンテナーアクセス フィールドで以下のいずれかのオプションを選択します。

タイプ	説明
`プライベート`	現在のプロジェクトでユーザーに対してアクセスを制限します。
`パブリック`	パブリックの URL を使用して API アクセスを全員に許可します。ただし、Dashboard では、プロジェクトユーザーには、他のプロジェクトのパブリックコンテナーおよびデータは表示されません。

コンテナーの作成 をクリックします。

3.2.2. コンテナー用の擬似フォルダーの作成

Dashboard で プロジェクト > オブジェクトストア > コンテナー を選択します。
擬似フォルダーを追加するコンテナーの名前をクリックします。
疑似フォルダーの作成 をクリックします。
疑似フォルダー名 フィールドに名前を指定し、作成をクリックします。

3.2.3. コンテナーの削除

Dashboard で プロジェクト > オブジェクトストア > コンテナー を選択します。
コンテナー のセクションの一覧を参照して全オブジェクトが削除済みであることを確認します (「オブジェクトの削除」を参照)。
対象のコンテナーの矢印メニューで コンテナーの削除 を選択します。
コンテナーの削除 をクリックして、コンテナーを削除する操作を確定します。

3.2.4. オブジェクトのアップロード

実際のファイルをアップロードしない場合でも、オブジェクトは (プレースホルダーとして) 作成され、後でファイルをアップロードする際に使用することができます。

Dashboard で プロジェクト > オブジェクトストア > コンテナー を選択します。
アップロードしたオブジェクトの配置先となるコンテナーの名前をクリックします。そのコンテナーに擬似フォルダーがすでに存在している場合には、擬似フォルダーの名前をクリックすることもできます。
ファイルをブラウズしてオブジェクトのアップロード をクリックします。
オブジェクト名 フィールドに名前を指定します。
- 擬似フォルダーはスラッシュ (/) の記号を使用して指定することができます (例: Images/myImage.jpg)。指定したフォルダーがまだ存在していない場合には、オブジェクトのアップロード時に作成されます。
- その場所 (オブジェクトがすでに存在している場所) に一意ではない名前は、そのオブジェクトの以前のコンテンツを上書きします。
オブジェクトのアップロード をクリックします。

3.2.5. オブジェクトのコピー

Dashboard で プロジェクト > オブジェクトストア > コンテナー を選択します。
オブジェクトのコンテナーまたはフォルダーの名前をクリックします (オブジェクトを表示します)。
オブジェクトのアップロード をクリックします。
コピーするファイルを参照し、矢印メニューで コピー を選択します。

以下の項目を設定します。

フィールド	説明
宛先コンテナー	新規プロジェクトの宛先コンテナー
パス	宛先コンテナーの擬似フォルダー。フォルダーが存在しない場合は、作成されます。
宛先オブジェクト名	新規オブジェクト名。その場所に一意ではない名前を使用した場合 (そのオブジェクトがすでに存在している場合) には、そのオブジェクトの以前のコンテンツが上書きされます。

オブジェクトのコピー をクリックします。

3.2.6. オブジェクトの削除

Dashboard で プロジェクト > オブジェクトストア > コンテナー を選択します。
一覧を参照して対象のオブジェクトを特定し、矢印メニューで オブジェクトの削除 を選択します。
オブジェクトの削除 をクリックして、オブジェクトを削除する操作を確定します。

第4章ファイル共有

重要

OpenStack Shared File System サービス (openstack-manila) は、複数のインスタンスで消費可能な共有ファイルシステムを簡単にプロビジョニングするための手段を提供します。以前は、OpenStack のユーザーは、インスタンスにマウントする前に共有ファイルシステムを手動でデプロイする必要がありました。一方で、Shared File System サービスでは、事前設定済みのストレージプールから共有を簡単にプロビジョニングして、セキュアにマウントする準備を整えることができます。次に、ニーズを満たすためこのプールを個別に管理、スケーリングすることができます。

OpenStack Shared File System サービスでは、管理者は OpenStack Block Storage サービスで ボリューム種別 を使用するのと同じ方法で、異なる種別のシェアの設定を定義することができます。さらに、Shared File System サービスは、プロビジョニングした共有のアクセス、セキュリティー、スナップショットを管理する手段を提供します。

現在、Shared File System サービスは手動でしかデプロイできません。Shared File System サービスの手動でのデプロイ方法は、「Shared File System サービスのインストール (テクノロジープレビュー)」を参照してください。

4.1. 共有の作成、管理

以下のセクションは、「Shared File System サービスのインストール (テクノロジープレビュー)」と「OpenStack Shared File System Service (Manila)」の説明に従って Shared File System サービスを手動でデプロイ済みであることを前提とします。そのため、この時点で、共有に NetApp ドライバー (manila.share.drivers.netapp.common.NetAppDriver) を使用する必要があります。

このドライバーでは、以下の操作を実行できるはずです。

共有を作成、削除します。
共有へのアクセスを許可 (読み取り/書き込み) または拒否します。

共有を作成する前に、共有のタイプ を先に作成してください。通常、このステップは、「定義済みのバックエンドの共有タイプの作成」に記載の Shared File System サービスのデプロイメントの一部です。

以下の手順は、NetApp のバックエンドが次の条件を満たしていることを前提としています。

NetApp という名前の共有タイプで呼び出しができること
NFS 共有プロトコルをサポートしていること

4.2. 共有の作成

共有を作成するには、Shared File System サービスのホストにログインして、以下のコマンドを実行します。

# manila create --share-type SHARETYPE --name SHARENAME PROTO GB

上記の設定で、

SHARETYPE は、指定の共有タイプに関連する設定を適用します。
SHARENAME は、共有名に置き換えます。
PROTO は、使用する共有プロトコルに置き換えます。
GB は、共有のサイズ (GB) に置き換えます。

たとえば、NetApp を使用して share-00 と言う名前の 1 GB の NFS 共有を作成するには、以下のコマンドを実行します。

# manila create --share-type netapp --name share-00 nfs 10
 +-------------------+--------------------------------------+
 | Property          | Value                                |
 +-------------------+--------------------------------------+
 | status            | creating                             |
 | description       | None                                 |
 | availability_zone | nova                                 |
 | share_network_id  | None                                 |
 | export_locations  | []                                   |
 | share_server_id   | None                                 |
 | host              | None                                 |
 | snapshot_id       | None                                 |
 | is_public         | False                                |
 | id                | d760eee8-1d91-48c4-8f9a-ad07072e17a2 |
 | size              | 10                                   |
 | name              | share-01                             |
 | share_type        | 8245657b-ab9e-4db1-8224-451c32d6b5ea |
 | created_at        | 2015-09-29T16:27:54.092272           |
 | export_location   | None                                 |
 | share_proto       | NFS                                  |
 | project_id        | a19dc7ec562c4ed48cea58d22eb0d3c7     |
 | metadata          | {}                                   |
 +-------------------+--------------------------------------+

4.3. 共有とエクスポートの情報の一覧表示

共有が正常に作成されたことを確認するには、以下のコマンドを実行します。

# manila list
 +--------------------------------------+----------+-----+-----------+
 | ID                                   | Name     | ... | Status    ...
 +--------------------------------------+----------+-----+-----------+
 | d760eee8-1d91-48c4-8f9a-ad07072e17a2 | share-01 | ... | available ...
 +--------------------------------------+----------+-----+-----------+

manila list コマンドは、共有の export location も表示します。

 +-------------------------------------------------------------+
 | Export location                                             ...
 +-------------------------------------------------------------+
 | 10.70.37.46:/manila-nfs-volume-01/share-d760eee8-1d91-...
 +-------------------------------------------------------------+

この情報は後ほど、共有をマウントする際に使用します (「インスタンスへの共有のマウント」)。

4.4. 共有に対するアクセス権の付与

インスタンスに共有をマウントする前に、インスタンスが共有にアクセスできるようにする必要があります。

# manila access-allow SHAREID IDENT IDENTKEY

上記の設定で、

SHAREID は、「共有の作成」で作成した共有の ID に置き換えます。
IDENT は、File Share サービスは共有ユーザーまたはインスタンスの認証に使用する手法に置き換えます。
IDENTKEY は、IDENT にどの認証の手法を選択するかにより異なります。
- cert: この手法は、TLS 証明書でインスタンスを認証するのに使用します。
- user: これはユーザーまたはグループ名で認証するのに使用します。
- ip: IP アドレスでインスタンスを認証するのに使用します。

たとえば、インスタンス (IP 10.70.36.85 として識別される) に読み取り/書き込みアクセス権を付与するには、以下のコマンドを実行します。

# manila access-allow d760eee8-1d91-48c4-8f9a-ad07072e17a2 ip 10.70.36.85
 +--------------+--------------------------------------+
 | Property     | Value                                |
 +--------------+--------------------------------------+
 | share_id     | d760eee8-1d91-48c4-8f9a-ad07072e17a2 |
 | deleted      | False                                |
 | created_at   | 2015-09-29T16:35:33.862114           |
 | updated_at   | None                                 |
 | access_type  | ip                                   |
 | access_to    | 10.70.36.85                          |
 | access_level | rw                                   |
 | state        | new                                  |
 | deleted_at   | None                                 |
 | id           | b4e990d7-e9d1-4801-bcbe-a860fc1401d1 |
 +--------------+--------------------------------------+

共有へのアクセスには、b4e990d7-e9d1-4801-bcbe-a860fc1401d1 という独自の ID (ACCESSID) が指定されていることに注目してください。

正常にアクセス設定が行われたことを確認するには、以下のコマンドを実行します。

# manila access-list d760eee8-1d91-48c4-8f9a-ad07072e17a2
 +---------------------------+-----------+-----------+--------------+
 | id                        |access type|access to  | access level ...
 +---------------------------+-----------+-----------+--------------+
 |b4e990d7-e9d1-4801-bcbe-...|ip         |10.70.36.85| rw           ...
 +---------------------------+-----------+-----------+--------------+

4.5. インスタンスへの共有のマウント

インスタンスを認証するように共有を設定した後に、共有をマウントすることができます。たとえば、「共有の作成」からの共有を、「共有に対するアクセス権の付与」からのインスタンスの /mnt にマウントするには、通常通りにインスタンスにログインしてマウントします。

# ssh root@10.70.36.85
# mount -t nfs -o vers=3 10.70.37.46:/manila-nfs-volume-01/share-d760eee8-1d91-48c4-8f9a-ad07072e17a2 /mnt

共有のエクスポート情報を表示する方法については、「共有とエクスポートの情報の一覧表示」を参照してください。

インスタンス内からボリュームをマウントする際には、このマウントポイントで共有に書き込みができるかどうかを確認します。

4.6. 共有へのアクセスの取り消し

以前に付与したアクセス権を取り消すには、共有へのアクセス権を削除する必要があります。

# manila access-deny SHAREID ACCESSID

たとえば、先ほど「共有に対するアクセス権の付与」で付与したアクセス権を取り消すには、以下のコマンドを実行します。

# manila access-list d760eee8-1d91-48c4-8f9a-ad07072e17a2
 +---------------------------+-----------+-----------+--------------+
 | id                        |access type|access to  | access level ...
 +---------------------------+-----------+-----------+--------------+
 |b4e990d7-e9d1-4801-bcbe-...|ip         |10.70.36.85| rw           ...
 +---------------------------+-----------+-----------+--------------+
# manila access-deny d760eee8-1d91-48c4-8f9a-ad07072e17a2 b4e990d7-e9d1-4801-bcbe-a860fc1401d1

この時点で、インスタンスはマウントした共有を使用することができなくなります。

4.7. 共有の削除

共有を削除するには以下のコマンドを実行します。

# manila delete SHAREID

例:

# manila delete d760eee8-1d91-48c4-8f9a-ad07072e17a2

ストレージガイド

OpenStack での永続ストレージの理解、使用、管理

OpenStack Documentation Team

法律上の通知

前書き

第1章 OpenStack での永続ストレージの概要

1.1. スケーラビリティーおよびバックエンド

1.2. アクセシビリティーと管理

1.3. セキュリティー

1.4. 冗長性および災害復旧

第2章 Block Storage とボリューム

2.1. バックエンド

2.2. Block Storage サービスの管理

2.2.1. ボリューム種別へのボリューム設定の関連付け

2.2.1.1. ホストドライバーの機能一覧

2.2.1.2. ボリューム種別の作成と設定

2.2.1.3. ボリューム種別の編集

2.2.1.4. ボリューム種別の削除

2.2.1.5. プライベートのボリューム種別の作成と設定

2.2.2. Block Storage サービスの内部テナントの作成および設定

2.2.3. Image-Volume キャッシュの設定および有効化

2.2.4. QoS スペックの使用

2.2.4.1. QoS スペックの作成と設定

2.2.4.2. QoS スペックとボリューム種別の関連付け

2.2.4.3. ボリューム種別からの QoS スペックの関連付け解除

2.2.5. 静的キーを使用したボリュームの暗号化

2.2.5.1. 静的キーの設定

2.2.5.2. ボリューム種別の暗号化設定

2.2.6. ボリュームを複数のバックエンドに割り当てる方法の設定

2.2.7. バックアップの管理

2.2.7.1. テナントのバックアップクォータの表示と変更

2.2.7.2. Dashboard を使用したボリュームバックアップ管理の有効化

2.2.7.3. バックアップリポジトリーとしての NFS 共有の設定

2.2.7.3.1. 異なるバックアップファイルサイズの設定

2.3. ボリュームの基本的な使用方法と設定

2.3.1. ボリュームの作成

2.3.2. ボリュームを作成するバックエンドの指定

2.3.3. ボリュームの名前と説明の編集

2.3.4. ボリュームの削除

2.3.5. インスタンスへのボリュームの接続と切断

2.3.5.1. インスタンスへのボリュームの接続

2.3.5.2. インスタンスからのボリュームの切断

2.3.6. ボリュームの読み取り専用設定

2.3.7. ボリュームの所有者の変更

2.3.7.1. コマンドラインを使用したボリュームの譲渡

2.3.7.2. ダッシュボードを使用したボリュームの譲渡

2.3.8. ボリュームスナップショットの作成、使用、削除

2.3.8.1. Red Hat Ceph バックエンドにおけるスナップショットの保護と保護解除

2.3.9. Image サービスにボリュームをアップロードする手順

2.3.10. ボリューム種別の変更

2.4. ボリュームの高度な設定

2.4.1. ボリュームのバックアップと復元

2.4.1.1. ボリュームの完全バックアップの作成

2.4.1.1.1. admin としてのボリュームのバックアップ作成

2.4.1.2. ボリュームの増分バックアップの作成

2.4.1.3. Block Storage データベースでデータ損失が発生した後の復元

2.4.1.4. バックアップからのボリュームの復元

2.4.2. ボリュームの移行

2.4.2.1. バックエンド間での移行

第3章 Object Storage およびコンテナー

3.1. Object Storage サービスの管理

3.1.1. Object Storage サービスの Erasure Code

3.1.1.1. Erasure Coding の設定

3.1.1.2. オブジェクトストレージリングの設定

3.1.2. Image サービスのバックエンドとしてのオブジェクトストレージの設定

3.2. 基本的なコンテナー管理

3.2.1. コンテナーの作成

3.2.2. コンテナー用の擬似フォルダーの作成

3.2.3. コンテナーの削除

3.2.4. オブジェクトのアップロード

3.2.5. オブジェクトのコピー

3.2.6. オブジェクトの削除

第4章 ファイル共有

4.1. 共有の作成、管理

4.2. 共有の作成

4.3. 共有とエクスポートの情報の一覧表示

4.4. 共有に対するアクセス権の付与

4.5. インスタンスへの共有のマウント

4.6. 共有へのアクセスの取り消し

4.7. 共有の削除

第4章ファイル共有