Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

カスタム Block Storage バックエンドのデプロイメントガイド

Red Hat OpenStack Platform 8

Red Hat OpenStack Platform オーバークラウドでのカスタム Block Storage バックエンドのデプロイメントガイド

OpenStack Documentation Team

概要

このドキュメントでは、Red Hat OpenStack Platform 8 オーバークラウドに Block Storage サービス用に統合されていないカスタムバックエンドをデプロイする方法について説明します。

第1章 はじめに
リンクのコピー

Red Hat OpenStack Platform director は、完全な OpenStack 環境のインストールおよび管理を行うためのツールセットです。director は、主に OpenStack プロジェクト TripleO (OpenStack-on-OpenStack)をベースとしています。director の主な目的は、最小限の手動設定で、機能的なエンタープライズグレードの OpenStack デプロイメントを完全にオーケストレーションすることです。OpenStack の個々のコンポーネントを手動で設定する際に固有の問題の多くに対処するのに役立ちます。

director が提供する最終結果の OpenStack デプロイメントは、オーバークラウド と呼ばれ ます。オーバークラウドは、Block Storage を含むエンドユーザーにサービスを提供するすべてのコンポーネントを格納します。本ガイドでは、カスタムのバックエンドをオーバークラウドの Block Storage サービスにデプロイする方法について説明します。

このドキュメントは、Block Storage サービスを 手動で 設定する際に管理者の知識を活用することを目的としています。OpenStack のテストデプロイメント（たとえば、Packstack を使用）では、このサービスを設定するには、そのホストノードの /etc/cinder/cinder.conf を編集する必要があります。そのファイルの Block Storage 設定のほとんどは、他の場所でより詳細に文書化されています。このドキュメントでは、カスタムバックエンド をアタッチするために同じ設定をオーバークラウドに適用する方法を説明します。

警告

この手順は、一部のユースケースでテストされています。最初に、計画したデプロイメントを実稼働環境以外の環境でテストするようにしてください。不明な点は Red Hat サポートにお問い合わせください。

1.1. カスタムバックエンド
リンクのコピー

本書の目的上、カスタムバックエンドは、Red Hat OpenStack Platform director にまだ完全に統合されていないストレージサーバー/適用または設定として定義されます。サポートされている一部の Block Storage バックエンドは、すでに Director に統合されています。つまり、事前設定された Director ファイルはすでに追加設定なしで提供されています。これらのファイルを使用して、統合バックエンドを設定し、オーバークラウドにデプロイできます。統合されたバックエンドの例には、Red Hat Ceph と、Dell EqualLogic、Dell Storage Center、および NetApp アプライアンスのシングルバックエンド設定が含まれます。

また、すでに Director に統合されている一部のストレージアプライアンスは、単一インスタンスのバックエンドのみをサポートします。たとえば、Dell EqualLogic 用の事前設定された Director ファイルは、単一のバックエンドのデプロイメントのみを許可します。このアプライアンスの複数のバックエンドインスタンスをデプロイするには、このドキュメントで説明されているように、カスタム設定が必要です。

ノードの /etc/cinder/cinder.conf を直接編集して Block Storage サービスを手動で設定することは可能ですが、適切にオーケストレーションされたオーバークラウドの更新で、director によりすべての設定が上書きされます。したがって、Block Storage バックエンドのデプロイに推奨される方法は、director を使用することです。バックエンド設定がすでに完全に統合されている場合は、パッケージ化された環境ファイルを編集して呼び出すだけです。

ただし、カスタムバックエンドでは、独自の 環境ファイル を作成する必要があります。このドキュメントには、独自のデプロイメント用に編集できるアノテーション付きのサンプル、つまり /home/stack/templates/custom-env.yaml が含まれています。このサンプルファイルは、2 つの NetApp バックエンドを使用するように Block Storage サービスを設定するのに適しています。

1.2. 要件
リンクのコピー

Block Storage とデプロイするバックエンドを手動で設定する以前の知識を除き、本書では以下を前提としています。

  • サードパーティーのバックエンドアプライアンスを使用している場合は、ストレージリポジトリーとして適切に設定されている必要があります。
  • director の インストールと使用 の指示に従って、director からオーバークラウドがすでにデプロイされている。
  • 昇格した特権を持つアカウントのユーザー名およびパスワードを所有している。オーバークラウドのデプロイ用に作成されたものと同じアカウントを使用できる。Creating a Director Installation User では、この目的のために stack ユーザーを作成して使用します。
  • /etc/cinder/cinder.conf で、Block Storage バックエンドに必要な結果の設定をすでにマッピングしている。これにより、そのすべてが director を介した計画された設定のオーケストレーションになります。

第2章 プロセスの説明
リンクのコピー

Block Storage サービスの設定は /etc/cinder/cinder.conf に保存されます。これらの設定には、バックエンド定義 が含まれます。Block Storage サービスで使用できる（またはサポートされている）サードパーティーのバックエンドのほとんどは、/etc/cinder/cinder.conf 設定の編集を含むセットアップ手順を提供します。1章はじめに で述べたように、これにより、Block Storage サービスが設定されます。ただし、これらの設定は今後のオーバークラウドの更新で上書きされます。

いずれにせよ、/etc/cinder/cinder.conf による手動設定に関するドキュメントは、オーバークラウドのデプロイメントでも役に立ちます。結局、director は Heat を介して同じ設定を /etc/cinder/cinder.conf に適用し ます。そのため、バックエンド設定を計画するには、次のことが必要です。

  • 必要な Block Storage バックエンド設定を綿密に計画し、
  • この設定の結果の /etc/cinder/cinder.conf ファイルをマッピングします。

結果の /etc/cinder/cinder.conf ファイルをマッピングしたら、バックエンド設定をオーケストレーションする環境ファイルを作成します。環境ファイル では、サンプルファイル /home/stack/templates/custom-env.yaml を使用して、この手順をより詳細に説明します。環境ファイルを手元に用意しておくと、今後のオーバークラウドの更新後もバックエンド設定が維持されるようになります。

第3章 環境ファイルの作成
リンクのコピー

環境ファイルには、定義する各バックエンドの設定が含まれます。また、カスタムバックエンドのデプロイメントに関連するその他の設定も含まれます。環境ファイルについての詳細は、director の インストールと使用 ガイドの 環境ファイル を参照してください。

以下の環境ファイルは、netapp1 および netapp2 の 2 つの NetApp バックエンドを定義します。

/home/stack/templates/custom-env.yaml

parameters: #
1 

  CinderEnableIscsiBackend: false
  CinderEnableRbdBackend: false
  CinderEnableNfsBackend: false
  NovaEnableRbdBackend: false
  GlanceBackend: file #
2 


parameter_defaults:
  controllerExtraConfig: #
3 

    cinder::config::cinder_config:
        netapp1/volume_driver: #
4 

            value: cinder.volume.drivers.netapp.common.NetAppDriver
        netapp1/netapp_storage_family:
            value: ontap_7mode
        netapp1/netapp_storage_protocol:
            value: iscsi
        netapp1/netapp_server_hostname:
            value: 10.35.64.11
        netapp1/netapp_server_port:
            value: 80
        netapp1/netapp_login:
            value: root
        netapp1/netapp_password:
            value: 123456
        netapp1/volume_backend_name:
            value: netapp_1
        netapp2/volume_driver: #
5 

            value: cinder.volume.drivers.netapp.common.NetAppDriver #
6 

        netapp2/netapp_storage_family:
            value: ontap_7mode
        netapp2/netapp_storage_protocol:
            value: iscsi
        netapp2/netapp_server_hostname:
            value: 10.35.64.11
        netapp2/netapp_server_port:
            value: 80
        netapp2/netapp_login:
            value: root
        netapp2/netapp_password:
            value: 123456
        netapp2/volume_backend_name:
            value: netapp_2
    cinder_user_enabled_backends: ['netapp1','netapp2'] #
7
Copy to Clipboard Toggle word wrap

1
以下のパラメーターは false に設定されているため、不要な他のバックエンドタイプを無効にします。
  • CinderEnableIscsiBackend: 他の iSCSI バックエンド。
  • CinderEnableRbdBackend: Red Hat Ceph
  • CinderEnableNfsBackend: NFS
  • NovaEnableRbdBackend: 一時 Red Hat Ceph ストレージ。
2
GlanceBackend パラメーターは、Image サービスがイメージを保存するために使用するものを設定します。以下の値を使用できます。
  • file: 各コントローラーノードの /var/lib/glance/images にイメージを保存します。
  • Swift: イメージストレージに Object Storage サービスを使用します。
  • Cinder: イメージストレージに Block Storage サービスを使用します。
3
ControllerExtraConfig は、すべてのコントローラーノードに適用されるカスタム設定を定義します。cinder::config::cinder_config クラスは、設定を Block Storage (cinder)サービスに適用する必要があることを意味します。これは、バックエンド設定が最終的に各コントローラーノードの /etc/cinder/cinder.conf ファイルで終了することを意味します。
4
netapp1/volume_driver および netapp2/volume_driver 設定は、section/setting の構文に準拠します。Block Storage サービスでは、各バックエンドは /etc/cinder/cinder.conf の独自のセクションで定義されます。netapp1 接頭辞を使用する各設定は、新しい netapp1] バックエンドセクションで定義されます。
5
同様に、netapp2 設定は別の netapp2] セクションで定義されます。
6
値 の接頭辞は、前述の設定の値を定義します。
7
cinder_user_enabled_backends クラスは、カスタムバックエンドを設定して有効にします。名前が示すように、このクラスはユーザー対応のバックエンドにのみ使用する必要があります。具体的には、cinder::config::cinder_config クラスで定義されているクラスです。

cinder_user_enabled_backends を使用して、director を介してネイティブに有効にできるバックエンドを一覧表示しないでください。サポートされている NetApp アプライアンスまたは Dell アプライアンスには、Red Hat Ceph、NFS、および単一のバックエンドが含まれます。たとえば、Red Hat Ceph バックエンドも有効にする場合は、cinder_user_enabled_backends にリストしないでください。CinderEnableRbdBackend: true を使用して有効にします。

注記

OpenStack Block Storage 用の Red Hat Ceph バックエンドの定義に関する詳細は、オーバークラウド向けの Red Hat Ceph Storage を参照してください。

] では、環境ファイル xref:envfile[/home/stack/templates/custom-env.yaml を使用してカスタムバックエンドのデプロイメントを調整する方法 を説明します。/home/stack/templates/custom-env.yaml から /etc/cinder/cinder.conf の設定を確認するには、「サンプル環境ファイルから得られる設定」 を参照してください。

第4章 設定済みのバックエンドのデプロイ
リンクのコピー

/home/stack/templates/ に custom-env.yaml ファイルを作成したら、stack ユーザーとしてログインします。次に、次を実行してカスタムバックエンド設定をデプロイします。 

$ openstack overcloud deploy --templates -e /home/stack/templates/custom-env.yaml
Copy to Clipboard Toggle word wrap
重要

オーバークラウドの作成時に追加の環境ファイルを渡した場合には、予定外の変更がオーバークラウドに加えられないように、ここで -e オプションを使用して環境ファイルを再度渡します。

詳細は、オーバークラウドの スケーリング および オーバークラウドの 更新 を参照してください。

director がオーケストレーションを完了したら、バックエンドをテストします。手順については 5章設定したバックエンドのテスト を参照してください。

第5章 設定したバックエンドのテスト
リンクのコピー

バックエンドをオーバークラウドにデプロイしたら、そこにボリュームを正常に作成できるかどうかをテストします。これを実行するには、最初に必要な環境変数を読み込む必要があります。これらの変数は、デフォルトで /home/stack/overcloudrc に定義されています。

これらの変数をロードするには、stack ユーザーとして次のコマンドを実行します。 

$ source /home/stack/overcloudrc
Copy to Clipboard Toggle word wrap
注記

詳細は、基本的なオーバークラウドへのアクセス を 参照してください。

次に、バックエンドごとに ボリューム種別 を作成します。stack ユーザーとしてオーバークラウドのコントローラーノードにログインし、以下のコマンドを実行します。 

$ cinder type-create backend1
$ cinder type-create backend2
Copy to Clipboard Toggle word wrap

これらのコマンドにより、xref:envfile の cinder::config::cinder_config クラスで定義されるバックエンドごとに 1 つずつ、ボリュームタイプ backend1 および backend2 が作成されます。

最後に、各ボリュームタイプを、xref:envfile の cinder_user_enabled_backends クラスで有効にしたバックエンドの volume_backend_name にマッピングします。以下のコマンドは、ボリュームタイプ backend1 を netapp1 に、backend2 を netapp2 にマッピングします。 

$ cinder type-key backend1 set volume_backend_name=netapp1
$ cinder type-key backend2 set volume_backend_name=netapp2
Copy to Clipboard Toggle word wrap

この時点で、各バックエンドをテストする準備が整いたはずです。起動するには、backend1 のボリュームタイプを呼び出して、netapp1 バックエンドに netapp_volume_1 という名前の 1 GB のボリュームを作成します。 

$ cinder create --volume-type backend1 --display_name netappvolume_1 1
Copy to Clipboard Toggle word wrap

同様に、backend2 のボリュームタイプを呼び出して、netapp2 バックエンド上に同様のボリュームを作成します。 

$ cinder create --volume-type backend2 --display_name netappvolume_2 1
Copy to Clipboard Toggle word wrap

付録A 付録
リンクのコピー

A.1. stack ユーザー
リンクのコピー

Director Installation User の作成 セクションは、stack という名前のユーザーを作成するようにリーダーに指示します。このユーザーは、オーバークラウドのデプロイに使用されます。スタックアカウントを使用して、バックエンドのデプロイ（] のデプロイメントや、オーバークラウドにアクセスするために必要な環境変数の読み込み(xref:test[)など、昇格した権限を必要とするコマンドを実行できます。

Director のインストールおよび使用方法 の手順に従うと、stack ユーザーがすでに存在します。そのため、必要に応じて使用すると便利です。

A.2. サンプル環境ファイルから得られる設定
リンクのコピー

xref:envfile の環境ファイルは、Block Storage サービスが 2 つの NetApp バックエンドを使用するように設定します。以下のスニペットには、関連する設定が表示されます。 

enabled_backends = netapp1,netapp2

[netapp1]
volume_backend_name=netapp_1
volume_driver=cinder.volume.drivers.netapp.common.NetAppDriver
netapp_login=root
netapp_storage_protocol=iscsi
netapp_password=123456
netapp_storage_family=ontap_7mode
netapp_server_port=80
netapp_server_hostname=10.35.64.11

[netapp2]
volume_backend_name=netapp_2
volume_driver=cinder.volume.drivers.netapp.common.NetAppDriver
netapp_login=root
netapp_storage_protocol=iscsi
netapp_password=123456
netapp_storage_family=ontap_7mode
netapp_server_port=80
netapp_server_hostname=10.35.64.11
Copy to Clipboard Toggle word wrap

法律上の通知
リンクのコピー

Copyright © 2025 Red Hat, Inc.
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, the Red Hat 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 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 logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat