パートナーのソリューションの統合
OpenStack Platform 環境における認定済みのサードパーティー製ソフトウェアおよびハードウェアの統合
概要
第1章 はじめに リンクのコピーリンクがクリップボードにコピーされました!
本書は、Red Hat OpenStack Platform のパートナーが OpenStack Platform 環境のインストールやデプロイメントライフサイクルの管理に使用するツールとして、Red Hat OpenStack Platform director を使用してソリューションを統合する作業を支援するために作成されました。director を使用して統合することで、パートナーの技術をシームレスに導入することができます。リソースの最適化、デプロイメントにかかる時間の短縮、ライフサイクル管理コストの削減など、幅広い利点を見出すことができます。
今後、OpenStack Platform director を使用した統合は、既存のエンタープライズ管理システムおよびプロセスとの充実した統合を提供するための強固な対策の 1 つとなります。director の機能は将来、Red Hat の製品ポートフォリオ内の CloudForms などのツールによって統合/使用されるようになり、サービスデプロイメント管理のより多くのプロセスをグラフィカルユーザーインターフェースで実行できるようになる見通しです。
1.1. パートナーのソリューション統合に関する概要 リンクのコピーリンクがクリップボードにコピーされました!
本書は、パートナーがソフトウェアおよびハードウェアソリューションを Red Hat OpenStack Platform に統合するのを支援することを目的としています。この作業は、director でオーバークラウドの一部として設定する方法で行います。手順は、複数のセクションで構成されるワークフロー形式で記載しており、各セクションでは特定の統合タスクの実行方法について説明します。
- アーキテクチャー: オーバークラウドの作成や設定を実行する際に director が使用するテクノロジーの一部を検証します。
- オーバークラウドイメージ: director はオーバークラウド内の各ノードに、ノード種別の基盤として、ベースのイメージを書き込みます。このセクションでは、デプロイメント前にこれらのイメージを修正してドライバーやソフトウェアを追加できるようにする方法を説明します。これは、アップストリームに寄与する前にドライバーや設定をテストする際などに役立ちます。
- 設定: director は、主に Puppet モジュールを使用して、オーバークラウド上の各サービスを設定します。このセクションでは、Puppet モジュールがどのように機能し、オーバークラウドの設定にこの Puppet モジュールがどのように使用されるかを説明します。
- オーケストレーション: director は、Heat テンプレートセットを使用して、オーバークラウドを作成、設定します。これには、オーバークラウド設定の動作を変更するためのカスタムの環境ファイルや Heat テンプレートなども含まれる場合があります。このセクションでは、そのようなテンプレートを作成してオーバークラウドのカスタムの設定を有効化する方法について重点的に解説します。この操作には、本セクションの 1 つ前の章で説明している Puppet 設定の追加も必要です。
- 統合ポイント: director がデプロイするイメージには、必須の OpenStack のコンポーネントと設定用の Puppet モジュールセットが含まれます。このセクションでは、コンポーネントドライバーや Puppet モジュールを貢献するためのいくつかのアップストリームプロジェクトについて説明します。アップストリームに貢献されたコンポーネントやモジュールは、Red Hat が検証を行って、今後の Red Hat OpenStack Platform ディストリビューションに追加することができます。
- 実例: この章では、前の章で得た知識の集大成として、実際の認定済みベンダーが現在 director を使用してオーバークラウドにプロジェクトを統合している方法を実習します。ネットワークおよびストレージの実践的な例もいくつか記載しています。このセクションは、同じようなベンダーが自社製品を Red Hat OpenStack Platform のエコシステムに統合するのに役立ちます。
1.2. パートナーのソリューション統合の要件 リンクのコピーリンクがクリップボードにコピーされました!
director を使用して有意義な統合作業を完了させるには、複数の前提条件を満たす必要があります。これらの要件は、技術的な統合に限定されず、さまざまなレベルのパートナーソリューションの文書化も含まれます。これは、統合全体について完全な知識を共有して、Red Hat のエンジニアリングチーム、パートナーのマネージャー、サポート要員が効率的に作業をサポートできるようにすることが目的です。
最初の要件は、Red Hat OpenStack Platform ソリューションの認定に関連します。パートナーのソリューションを Red Hat OpenStack Platform director を使用して統合するには、まず Red Hat OpenStack Platform で認定される必要があります。
第2章 アーキテクチャー リンクのコピーリンクがクリップボードにコピーされました!
director には、OpenStack 環境自体の設定、デプロイ、管理にネイティブの OpenStack API を使用することを推奨します。つまり、director を使用した統合には、それらのネイティブ OpenStack API および補助コンポーネントとの統合が必要となることになります。このような API を使用する主な利点は、十分に文書化されていること、アップストリームで統合テストが幅広く行われていること、成熟していること、また OpenStack 基本知識を持つユーザーであればより簡単に director の機能の仕組みを理解できることなどです。また、OpenStack API を使用すると、director が自動的に OpenStack のコア機能拡張、セキュリティー修正プログラム、バグの修正を自動的に継承することになります。
Red Hat OpenStack Platform director は、完全な OpenStack 環境のインストールおよび管理を行うためのツールセットです。director は、主に OpenStack プロジェクト TripleO (「OpenStack-On-OpenStack」の略語) をベースとしてます。このプロジェクトは、OpenStack のコンポーネントを活用して、完全に機能する OpenStack 環境をインストールします。これには、OpenStack ノードとして使用するベアメタルシステムをプロビジョニング、制御する新しい OpenStack のコンポーネントが含まれます。
Red Hat OpenStack Platform director は、アンダークラウドとオーバークラウドという 2 つの主要な概念を使用します。この director 自体は、アンダークラウドとして知られている単一システムの OpenStack 環境を形成する OpenStack コンポーネントのサブセットで構成されています。アンダークラウドは、ワークロードを実行できるように実稼動レベルのクラウドを構築できる管理システムとして機能します。オーバークラウドとアンダークラウドに関する情報は、『director のインストールと使用方法』 ガイドを参照してください。
director には、オーバークラウド構成を構築するためのツール、ユーティリティー、テンプレートのサンプルが同梱されています。director は、設定データ、パラメーター、ネットワークトポロジーの情報を取得し、Ironic、Heat、Puppet などのコンポーネントとともにその情報を使用して、オーバークラウドのインストール環境をオーケストレーションします。
パートナーにはさまざまな異なる要件があります。director のアーキテクチャーを理解すると、統合の際にどのコンポーネントが重要となるかを理解するのに役立ちます。
2.1. コアコンポーネント リンクのコピーリンクがクリップボードにコピーされました!
本セクションでは、Red Hat OpenStack Platform director のコアコンポーネントをいくつか考察して、それらのコンポーネントがオーバークラウドの作成にどのように貢献するのかを説明します。
2.1.1. Ironic リンクのコピーリンクがクリップボードにコピーされました!
Ironic は、セルフサービスのプロビジョニングを使用してエンドユーザーに専用のベアメタルを提供します。director は、Ironic を使用してオーバークラウドのベアメタルハードウェアのライフサイクルを管理します。Ironic には、ベアメタルノードを定義するネイティブの API があります。director で OpenStack 環境をプロビジョニングする管理者は、特定のドライバーを使用して、Ironic にノードを登録する必要があります。ハードウェアの多くで Intelligent Platform Management Interface (IPMI) 電源管理機能がサポートされているため、IPMI が主要なサポートドライバーとなっていますが、Ironic には HP iLO、Cisco UCS または Dell DRAC などのベンダー固有のドライバーも含まれています。Ironic は、ノードの電源管理を制御し、イントロスペクションメカニズムを使用して、ハードウェアの情報や ファクト を収集します。director は、イントロスペクションプロセスから取得した情報を使用して、コントローラーノード、コンピュートノード、ストレージノードなど、さまざまな OpenStack 環境のロールとノードを照合します。たとえば、ディスクが 10 個あるノードが検出された場合は、ストレージノードとしてプロビジョニングされる可能性が高いです。
director でのハードウェアサポートを希望するパートナーは、Ironic のドライバーに対応している必要があります。
2.1.2. Heat リンクのコピーリンクがクリップボードにコピーされました!
Heat は、アプリケーションスタックのオーケストレーションエンジンとして機能します。これにより、組織では、クラウドにデプロイする前に特定のアプリケーションの要素を定義することができます。このプロセスでは、複数のインフラストラクチャーリソース (例: インスタンス、ネットワーク、ストレージボリューム、Elastic IP アドレスなど) や設定用のパラメーターセットなどが含まれるスタックテンプレートを作成します。Heat は、指定の依存関係チェーンをもとにこれらのリソースを作成して、リソースの可用性を監視し、必要に応じてスケーリングします。これらのテンプレートにより、アプリケーションスタックは移植可能となり、繰り返し実行して想定通りの結果を得られるようになります。
director は、ネイティブの OpenStack Heat API を使用して、オーバークラウドのデプロイに関連するリソースのプロビジョニングおよび管理を行います。これには、1 ノードロールあたりのプロビジョニングするノードの数、各ノードに設定するソフトウェアコンポーネント、それらのコンポーネントとノードの種別を director が設定する順序の定義などの詳細情報が含まれます。また director は、デプロイメントのトラブルシューティングやデプロイメント後の変更を容易に行うためにも Heat を使用します。
以下の例は、コントローラーノードのパラメーターを定義する Heat テンプレートのスニペットです。
Heat は、director に含まれるテンプレートで Ironic を呼び出してノードの電源を入れるなど、オーバークラウドの作成を簡素化します。標準の Heat ツールを使用して作成中のオーバークラウドのリソース (およびステータス) を表示することができます。たとえば、Heat ツールを使用して、ネスト化されたアプリケーションスタックとしてオーバークラウドを表示することができます。
Heat には、実稼動の OpenStack クラウドを宣言および作成するための幅広く強力な構文がありますが、事前にパートナーのソリューションとの統合に関する知識とスキルが必要です。パートナーのテクノロジーを統合するユースケースにはすべて、Heat のテンプレートが必要です。
2.1.3. Puppet リンクのコピーリンクがクリップボードにコピーされました!
Puppet は、設定管理および実行ツールで、このツールはマシンの最終的な状態を記述して、その状態を保持するメカニズムとして使用します。この最終的な状態は、Puppet マニフェストで定義します。Puppet では 2 つのモードをサポートします。
- マニフェスト形式の手順がローカルで実行されるスタンドアロンモード
- Puppet マスターと呼ばれる中央サーバーからマニフェストを取得するサーバーモード
管理者は、ノードに新しいマニフェストをアップロードしてローカルで実行するか、クライアント/サーバーモードで Puppet マスターで変更するかの 2 つの方法で変更を加えます。
Puppet は director のさまざまな場所で使用されています。
- アンダークラウドホストで Puppet をローカルで使用して、undercloud.conf に記述された設定に従ってパッケージのインストールや設定を行います。
- ベースのオーバークラウドイメージに openstack-puppet-modules パッケージを注入します。これらの Puppet モジュールは、デプロイメント後の設定に使用できます。デフォルトでは、すべての OpenStack サービスが含まれたイメージを作成して、各ノードに使用します。
- Heat 経由で追加の Puppet マニフェストとパラメーターをノードに渡して、オーバークラウドのデプロイメントの後にその設定を適用します。これには、ノードの種別に依存するサービスの有効化や起動、OpenStack の設定の適用などが含まれます。
ノードに Puppet hieradata を渡します。Puppet モジュールやマニフェストには、マニフェストの一貫性を確保するためのサイトやノード固有のパラメーターはありません。hieradata はパラメーター値の形式で機能し、Puppet モジュールをプッシュして、他のエリアで参照することができます。たとえば、マニフェスト内の MySQL パスワードを参照するには、この情報を hieradata として保存して、マニフェスト内でこの hieradata を参照します。
hieradata を表示します。
grep mysql_root_password hieradata.yaml # View the data in the hieradata file openstack::controller::mysql_root_password: ‘redhat123'
[root@localhost ~]# grep mysql_root_password hieradata.yaml # View the data in the hieradata file openstack::controller::mysql_root_password: ‘redhat123'Copy to Clipboard Copied! Toggle word wrap Toggle overflow Puppet マニフェストで hieradata を参照します。
grep mysql_root_password example.pp # Now referenced in the Puppet manifest mysql_root_password => hiera(‘openstack::controller::mysql_root_password')
[root@localhost ~]# grep mysql_root_password example.pp # Now referenced in the Puppet manifest mysql_root_password => hiera(‘openstack::controller::mysql_root_password')Copy to Clipboard Copied! Toggle word wrap Toggle overflow
パートナーが統合するサービスで、パッケージをインストールしたり、サービスを有効化したりする必要がある場合には、その要件を満たすための Puppet モジュールを作成することを検討してください。たとえば、現在の OpenStack Puppet モジュールを取得する方法に関する情報は、「OpenStack Puppet モジュールの取得」を参照してください。
2.1.4. TripleO および TripleO Heat テンプレート リンクのコピーリンクがクリップボードにコピーされました!
前述したように、director はアップストリームの TripleO プロジェクトをベースにしています。このプロジェクトは、以下の作業を行う OpenStack サービスセットを統合します。
- オーバークラウドイメージの保存 (Glance)
- オーバークラウドのオーケストレーション (Heat)
- ベアメタルマシンのプロビジョニング (Ironic)
TripleO には、Red Hat がサポートするオーバークラウド環境を定義する Heat テンプレートコレクションが含まれます。director は、Heat を使用してこのテンプレートコレクションを読み込み、オーバークラウドスタックをオーケストレーションします。また、Heat はこのようなコアの Heat テンプレートに含まれる特定のリソースに対してソフトウェア設定を起動します。このソフトウェア設定は通常、Bash スクリプトか Puppet マニフェストのいずれかです。
通常のソフトウェア設定は、主に 2 つの Heat リソースに依存します。
-
設定を定義するリソース (
OS::Heat::SoftwareConfig) -
ノードで設定を実装するリソース (
OS::Heat::SoftwareDeployment)
たとえば、Heat テンプレートコレクションでは、コンピュートノードのデプロイメント後のテンプレート (puppet/compute-post.yaml) に以下のセクションが含まれます。
ComputePuppetConfig リソースは、コンピュートノードの設定が含まれる Puppet マニフェスト (puppet/manifests/overcloud_compute.pp) を読み込みます。ComputePuppetDeployment リソースは、サービス一覧 (servers: {get_param: servers}) に ComputePuppetConfig からの設定を適用します。これは Heat の親テンプレートではコンピュートノードとして定義されます。Puppet が正常にマニフェストをすべて適用したかどうかにより、ノードは ComputePuppetDeployment の成功/失敗の報告を返します。
このソフトウェアの設定データフローは、director を使用してサードパーティーのソリューションを統合する方法を理解するのに重要です。本ガイドは、このデータフローを使用して、中核となる設定の前後に、オーバークラウドでカスタムの設定を追加する方法を説明します。カスタム設定の実装に使用するソフトウェアの設定データフローの例は、以下を参照してください。
第3章 オーバークラウドイメージ リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenStack Platform director は、オーバークラウドのイメージを提供します。このコレクションの QCOW イメージには、ベースのソフトウェアコンポーネントが含まれており、これらを統合してコンピュート、コントローラー、ストレージノードなどさまざまなオーバークラウドのロールを形成します。場合によっては、追加のコンポーネントをノードにインストールするなど、ニーズにあわせてオーバークラウドイメージの特定の機能を変更することもできます。
本ガイドでは、virt-customize ツールを使用して既存のコントローラーノードを増強するために既存のオーバークラウドイメージを変更する各種アクションについて説明します。たとえば、以下の手順を使用して、初期イメージには装備されていない ml2 プラグイン、Cinder バックエンド、監視エージェントを追加でインストールすることができます。
サードパーティー製のソフトウェアを追加するために変更を加えたオーバークラウドのイメージを使用中に発生した問題を Red Hat に報告する場合には、弊社の一般サードパーティーサポートポリシー (https://access.redhat.com/ja/articles/1409973) に従って、変更を加えていないイメージを使用した状態で問題を再現するように依頼する場合があります。
3.1. オーバークラウドイメージの取得 リンクのコピーリンクがクリップボードにコピーされました!
director では、オーバークラウドのノードをプロビジョニングする際に、複数のディスクが必要です。必要なディスクは以下のとおりです。
- イントロスペクションカーネルおよび ramdisk: PXE ブートでのベアメタルシステムのイントロスペクションに使用
- デプロイメントカーネルおよび ramdisk: システムのプロビジョニングおよびデプロイメントに使用
- オーバークラウドカーネル、ramdisk、完全なイメージ: ノードのハードディスクに書き込まれるベースのオーバークラウドシステム
rhosp-director-images および rhosp-director-images-ipa パッケージからこれらのイメージを取得します。
sudo yum install rhosp-director-images rhosp-director-images-ipa
$ sudo yum install rhosp-director-images rhosp-director-images-ipa
stack ユーザーのホーム (/home/stack/images) の images ディレクトリーにアーカイブを展開します。
cd ~/images for i in /usr/share/rhosp-director-images/overcloud-full-latest-9.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-9.0.tar; do tar -xvf $i; done
$ cd ~/images
$ for i in /usr/share/rhosp-director-images/overcloud-full-latest-9.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-9.0.tar; do tar -xvf $i; done
3.2. Initrd: 最初の Ramdisk の変更 リンクのコピーリンクがクリップボードにコピーされました!
場合によっては、内部の ramdisk を変更する必要がある可能性があります。たとえば、イントロスペクションまたはプロビジョニングプロセス中にノードをブートする際には、特定のドライバーを利用できるようにする必要がある場合があります。以下の手順では、最初の ramdisk を変更する方法を記載しています。オーバークラウドにおいては、これには以下のいずれかが含まれます。
-
イントロスペクション ramdisk:
ironic-python-agent.initramfs -
プロビジョニング ramdisk:
overcloud-full.initrd
以下の手順では、例として ironic-python-agent.initramfs ramdisk に追加の RPM パッケージを追加します。
stack ユーザーとしてログインして、ramdisk の一時ディレクトリーを作成します。
mkdir ipa-tmp cd ipa-tmp
$ mkdir ipa-tmp
$ cd ipa-tmp
skipcpio と 「cpio」コマンドを使用して、一時ディレクトリーに ramdisk を展開します。
/usr/lib/dracut/skipcpio ~/images/ironic-python-agent.initramfs | zcat | cpio -ivd | pax -r
$ /usr/lib/dracut/skipcpio ~/images/ironic-python-agent.initramfs | zcat | cpio -ivd | pax -r
展開したコンテンツに RPM パッケージをインストールします。
rpm2cpio ~/RPMs/python-proliantutils-2.1.7-1.el7ost.noarch.rpm | pax -r
$ rpm2cpio ~/RPMs/python-proliantutils-2.1.7-1.el7ost.noarch.rpm | pax -r
新規の ramdisk を再作成します。
find . 2>/dev/null | cpio --quiet -c -o | gzip -8 > ~/images/ironic-python-agent.initramfs
$ find . 2>/dev/null | cpio --quiet -c -o | gzip -8 > ~/images/ironic-python-agent.initramfs
ramdisk に新しいパッケージが存在することを確認します。
lsinitrd ~/images/ironic-python-agent.initramfs | grep proliant
$ lsinitrd ~/images/ironic-python-agent.initramfs | grep proliant
3.3. QCOW: director への virt-customize のインストール リンクのコピーリンクがクリップボードにコピーされました!
libguestfs-tools パッケージには virt-customize ツールが含まれます。rhel-7-server-rpms リポジトリーから libguestfs-tools をインストールします。
sudo yum install libguestfs-tools
$ sudo yum install libguestfs-tools
3.4. QCOW: オーバークラウドイメージの検査 リンクのコピーリンクがクリップボードにコピーされました!
overcloud-full.qcow2 のコンテンツを検査する必要がある場合があります。qemu-system-x86_64 コマンドを使用して仮想マシンインスタンスを作成します。
sudo qemu-system-x86_64 --kernel overcloud-full.vmlinuz --initrd overcloud-full.initrd -m 1024 --append root=/dev/sda --enable-kvm overcloud-full.qcow2
$ sudo qemu-system-x86_64 --kernel overcloud-full.vmlinuz --initrd overcloud-full.initrd -m 1024 --append root=/dev/sda --enable-kvm overcloud-full.qcow2
または、virt-manager で以下のブートオプションを使用します。
- カーネルのパス: /overcloud-full.vmlinuz
- initrd のパス: /overcloud-full.initrd
- Kernel の引数: root=/dev/sda
3.5. QCOW: root パスワードの設定 リンクのコピーリンクがクリップボードにコピーされました!
イメージで root ユーザーのパスワードを設定します。
virt-customize --selinux-relabel -a overcloud-full.qcow2 --root-password password:test [ 0.0] Examining the guest ... [ 18.0] Setting a random seed [ 18.0] Setting passwords [ 19.0] Finishing off
$ virt-customize --selinux-relabel -a overcloud-full.qcow2 --root-password password:test
[ 0.0] Examining the guest ...
[ 18.0] Setting a random seed
[ 18.0] Setting passwords
[ 19.0] Finishing off
これにより、管理者レベルのアクセス権限でコンソールを使用してノードにアクセスできるようになります。
3.6. QCOW: イメージの登録 リンクのコピーリンクがクリップボードにコピーされました!
イメージを一時的に登録して、カスタマイズに適切な Red Hat のリポジトリーを有効にします。
virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'subscription-manager register --username=[username] --password=[password]' [ 0.0] Examining the guest ... [ 10.0] Setting a random seed [ 10.0] Running: subscription-manager register --username=[username] --password=[password] [ 24.0] Finishing off
$ virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'subscription-manager register --username=[username] --password=[password]'
[ 0.0] Examining the guest ...
[ 10.0] Setting a random seed
[ 10.0] Running: subscription-manager register --username=[username] --password=[password]
[ 24.0] Finishing off
[username] および [password] は、お客様の Red Hat アカウントの情報に置き換えます。これで、イメージに対して以下のコマンドが実行されます。
subscription-manager register --username=[username] --password=[password]
subscription-manager register --username=[username] --password=[password]
このコマンドでは、Red Hat のコンテンツ配信ネットワークにオーバークラウドのイメージを登録します。
3.7. QCOW: サブスクリプションのアタッチと Red Hat リポジトリーの有効化 リンクのコピーリンクがクリップボードにコピーされました!
アカウントのサブスクリプションからプール ID の一覧を検索します。
sudo subscription-manager list
$ sudo subscription-manager list
サブスクリプションプール ID を選択して、その ID をイメージにアタッチします。
virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'subscription-manager attach --pool [subscription-pool]' [ 0.0] Examining the guest ... [ 12.0] Setting a random seed [ 12.0] Running: subscription-manager attach --pool [subscription-pool] [ 52.0] Finishing off
$ virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'subscription-manager attach --pool [subscription-pool]'
[ 0.0] Examining the guest ...
[ 12.0] Setting a random seed
[ 12.0] Running: subscription-manager attach --pool [subscription-pool]
[ 52.0] Finishing off
[subscription-pool] は選択したサブスクリプションプール ID に置き換えるようにしてください。これで、イメージに対して以下のコマンドが実行されます。
subscription-manager attach --pool [subscription-pool]
subscription-manager attach --pool [subscription-pool]
このコマンドではイメージにプールが追加され、以下のコマンドで Red Hat リポジトリーを有効化できるようになります。
subscription-manager repos --enable=[repo-id]
$ subscription-manager repos --enable=[repo-id]
3.8. QCOW: カスタムリポジトリーファイルのコピー リンクのコピーリンクがクリップボードにコピーされました!
サードパーティー製のソフトウェアをイメージに追加するには、追加のリポジトリーが必要です。たとえば、以下は、OpenDaylight リポジトリーの内容を使用する設定が含まれたリポジトリーファイルの例です。
リポジトリーファイルをイメージにコピーします。
virt-customize --selinux-relabel -a overcloud-full.qcow2 --upload opendaylight.repo:/etc/yum.repos.d/ [ 0.0] Examining the guest ... [ 12.0] Setting a random seed [ 12.0] Copying: opendaylight.repo to /etc/yum.repos.d/ [ 13.0] Finishing off
$ virt-customize --selinux-relabel -a overcloud-full.qcow2 --upload opendaylight.repo:/etc/yum.repos.d/
[ 0.0] Examining the guest ...
[ 12.0] Setting a random seed
[ 12.0] Copying: opendaylight.repo to /etc/yum.repos.d/
[ 13.0] Finishing off
--copy-in オプションは、リポジトリーファイルをオーバークラウドイメージの /etc/yum.repos.d/ にコピーします。
重要: Red Hat は、認定を受けていないベンダーからのソフトウェアに対するサポートは提供していません。インストールするソフトウェアがサポートされていることを、Red Hat のサポート担当者に確認してください。
3.9. QCOW: RPM のインストール リンクのコピーリンクがクリップボードにコピーされました!
virt-customize コマンドを使用して、イメージにパッケージをインストールします。
virt-customize --selinux-relabel -a overcloud-full.qcow2 --install opendaylight [ 0.0] Examining the guest ... [ 11.0] Setting a random seed [ 11.0] Installing packages: opendaylight [ 91.0] Finishing off
$ virt-customize --selinux-relabel -a overcloud-full.qcow2 --install opendaylight
[ 0.0] Examining the guest ...
[ 11.0] Setting a random seed
[ 11.0] Installing packages: opendaylight
[ 91.0] Finishing off
--install オプションを指定すると、インストールするパッケージを指定することができます。
3.10. QCOW: サブスクリプションプールの消去 リンクのコピーリンクがクリップボードにコピーされました!
必要なパッケージをインストールしてイメージをカスタマイズした後に、サブスクリプションを削除して、イメージの登録を解除します。
virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'subscription-manager remove --all' [ 0.0] Examining the guest ... [ 12.0] Setting a random seed [ 12.0] Running: subscription-manager remove --all [ 18.0] Finishing off
$ virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'subscription-manager remove --all'
[ 0.0] Examining the guest ...
[ 12.0] Setting a random seed
[ 12.0] Running: subscription-manager remove --all
[ 18.0] Finishing off
これで、イメージからサブスクリプションプールがすべて削除されます。
3.11. QCOW: イメージの登録解除 リンクのコピーリンクがクリップボードにコピーされました!
最後に、イメージの登録を解除します。これは、オーバークラウドのデプロイメントプロセスでイメージをノードにデプロイして、各ノードを個別で登録するためです。
virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'subscription-manager unregister' [ 0.0] Examining the guest ... [ 11.0] Setting a random seed [ 11.0] Running: subscription-manager unregister [ 17.0] Finishing off
$ virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'subscription-manager unregister'
[ 0.0] Examining the guest ...
[ 11.0] Setting a random seed
[ 11.0] Running: subscription-manager unregister
[ 17.0] Finishing off
3.12. director へのイメージのアップロード リンクのコピーリンクがクリップボードにコピーされました!
イメージの変更後には、director にアップロードします。stackrc ファイルを読み込み、コマンドラインから director にアクセスできるようにしてください。
source stackrc openstack overcloud image upload --image-path /home/stack/images/
$ source stackrc
$ openstack overcloud image upload --image-path /home/stack/images/
これにより、bm-deploy-kernel、bm-deploy-ramdisk、overcloud-full、overcloud-full-initrd、overcloud-full-vmlinuz のイメージが director にアップロードされます。これらは、デプロイメントとオーバークラウド用のイメージです。このスクリプトにより、director の PXE サーバーにあるイントロスペクションイメージがインストールされます。以下のコマンドを使用して CLI にイメージ一覧を表示します。
この一覧には、イントロスペクションの PXE イメージ (agent.*) は表示されません。director は、これらのファイルを /httpboot にコピーします。
第4章 設定 リンクのコピーリンクがクリップボードにコピーされました!
本章では、OpenStack Puppet モジュールに設定を追加する方法を考察します。これには、Puppet モジュール開発の基本指針も含まれます。
4.1. Puppet の基礎知識 リンクのコピーリンクがクリップボードにコピーされました!
次のセクションでは、Puppet の構文および Puppet のモジュールの構造を理解するのに役立つ基本事項を説明します。
4.1.1. Puppet モジュールの内容の検証 リンクのコピーリンクがクリップボードにコピーされました!
OpenStack モジュールに貢献する前に、Puppet モジュールを作成するコンポーネントについて理解する必要があります。
- マニフェスト
マニフェストとは、リソースセットおよび属性を定義するコードが含まれるファイルのことです。リソースは、システムの設定可能なコンポーネントです。リソースの例には、パッケージ、サービス、ファイル、ユーザー、グループ、SELinux 設定、SSH キー認証、 cron ジョブなどが挙げられます。マニフェストは、属性の key-value ペアのセットを使用して必要な各リソースを定義します。以下に例を示します。
package { 'httpd': ensure => installed, }package { 'httpd': ensure => installed, }Copy to Clipboard Copied! Toggle word wrap Toggle overflow この宣言では、httpd パッケージがインストールされているかどうかを確認します。されていない場合は、マニフェストにより yum が実行されて、httpd パッケージがインストールされます。マニフェストは、モジュールの manifest ディレクトリーに置かれています。また Puppet モジュールは、テストマニフェストのテストディレクトリーを使用します。これらのマニフェストを使用して、正式なマニフェストが含まれている特定のクラスをテストします。
- クラス
- クラスは、マニフェスト内の複数のリソースを統一するメソッドとして機能します。たとえば、HTTP サーバーをインストールして設定する場合には、HTTP サーバーパッケージをインストールするリソース、HTTP サーバーを設定するリソース、サーバーを起動または有効化するリソースの 3 つのリソースでクラスを作成します。また、他のモジュールからのクラスを参照して設定に適用することもできます。たとえば、Web サーバーも必要なアプリケーションを設定する必要がある場合に、上述した HTTP サーバーのクラスを参照することができます。
- 静的ファイル
モジュールには、システムの特定の場所に、Puppet がコピーできる静的ファイルが含まれます。これらの場所や、パーミッションなどのその他の属性は、マニフェストのファイルのリソース宣言で定義されます。
静的ファイルは、モジュールの files ディレクトリーに配置されています。
- テンプレート
設定ファイルにはカスタムのコンテンツが必要な場合があります。このような場合にユーザーは静的ファイルの代わりにテンプレートを使用します。静的ファイルと同じように、テンプレートはマニフェストで定義され、システム上の場所にコピーされます。相違点は、テンプレートでは Ruby 表現でカスタマイズのコンテンツや変数入力を定義することができる点です。たとえば、カスタマイズ可能なポートで httpd を設定する場合には、設定ファイルのテンプレートには以下が含まれます。
Listen <%= @httpd_port %>
Listen <%= @httpd_port %>Copy to Clipboard Copied! Toggle word wrap Toggle overflow この場合には、
httpd_port編集はこのテンプレートを参照するマニフェストに定義されています。テンプレートは、モジュールの templates ディレクトリーに配置されています。
- プラグイン
プラグインにより、Puppet のコア機能を拡張することができます。たとえば、プラグインを使用してカスタムファクト、カスタムリソース、または新機能を定義することができます。また、データベースの管理者が、PostgreSQL データベース向けのリソース種別を必要とする場合があります。プラグインを使用すると、データベース管理者は PostgreSQL のインストール後に新規データベースセットで PostgreSQL にデータを投入しやすくなり、PostgreSQL のインストールとその後のデータベース作成を確実に行う Puppet マニフェストのみを作成するだけで良くなります。
プラグインは、モジュールの lib ディレクトリーに配置されています。このディレクトリーには、プラグインのタイプに応じたサブディレクトリーセットが含まれます。以下に例を示します。
-
/lib/facter: カスタムファクトの場所 -
/lib/puppet/type: 属性の key-value ペアを記述するカスタムリソース種別の定義の場所 -
/lib/puppet/provider: リソースを制御するためのリソース種別の定義と併せて使用するカスタムリソースプロバイダーの場所 -
/lib/puppet/parser/functions: カスタム関数の場所
-
4.1.2. サービスのインストール リンクのコピーリンクがクリップボードにコピーされました!
一部のソフトウェアには、パッケージのインストールが必要です。これは、Puppet モジュールが実行可能な機能で、特定のパッケージの設定を定義するリソース定義を必要とします。
たとえば、mymodule モジュールを使用して httpd パッケージをインストールするには、mymodule モジュールの Puppet マニフェストに以下のコンテンツを追加します。
class mymodule::httpd {
package { 'httpd':
ensure => installed,
}
}
class mymodule::httpd {
package { 'httpd':
ensure => installed,
}
}
このコードは、httpd パッケージのリソース宣言を定義する httpd と呼ばれる mymodule サブクラスを定義します。ensure => installed の属性は、パッケージがインストールされているかどうかを確認するように Puppet に指示を出します。インストールされていない場合には、Puppet は yum を実行してパッケージをインストールします。
4.1.3. サービスの起動と有効化 リンクのコピーリンクがクリップボードにコピーされました!
パッケージのインストール後には、サービスを起動します。service と呼ばれる別のリソース宣言を使用します。これには、以下の内容が含まれるようにマニフェストを編集する必要があります。
これにより、以下の操作が実行されます。
-
ensure => running属性は、サービスが実行さているかどうかを確認します。実行されていない場合は Puppet により有効化されます。 -
enable => true属性は、システムの起動時にサービスが実行されるように設定します。 -
require => Package["httpd"]属性は、リソース宣言同士の順序関係を定義します。今回の場合は、httpd サービスが httpd パッケージのインストールの後に起動されるようにします。この属性により、サービスと関連のパッケージの間で依存関係が生まれます。
4.1.4. サービスの設定 リンクのコピーリンクがクリップボードにコピーされました!
上記の 2 つの手順では、Puppet を使用したサービスのインストールおよび有効化の方法を説明しましたが、サービスにカスタム設定を指定することもできます。本ガイドの例では、ポート 80 に Web ホストを設定するように、すでに /etc/httpd/conf/httpd.conf に HTTP サーバーのデフォルト設定が指定されています。このセクションでは、設定を追加して、ユーザー指定のポートに追加の Web ホストを設定します。
そのためには、HTTP 設定ファイルを保存するテンプレートファイルを使用します。これは、ユーザー定義のポートには、変数入力が必要なためです。モジュールの templates ディレクトリーに、以下の内容が含まれた myserver.conf.erb と呼ばれるファイルを追加します。
このテンプレートは、Apache Web 設定の標準構文に準拠します。唯一の相違点は、モジュールから変数を注入する際に Ruby のエスケープ文字が含まれる点です。たとえば、Web サーバーポートを指定するのに使用する httpd_port などです。
fqdn が追加されている点に注意してください。これは、システムの完全修飾ドメイン名を保存する変数で、システムファクト として知られています。システムファクトは、各該当システムの Puppet カタログを生成する前に各システムから取得します。Puppet は facter コマンドを使用して、これらのシステムファクトを収集します。また、これらのファクトの一覧を表示するには、facter を実行します。
このファイルを保存した後には、モジュールの Puppet マニフェストにリソースを追加します。
これにより、以下の操作が実行されます。
-
サーバー設定ファイル (
/etc/httpd/conf.d/myserver.conf) のファイルリソース宣言を追加します。このファイルのコンテンツは、以前に作成したmyserver.conf.erbテンプレートです。このファイルを追加する前に、httpdパッケージがインストールされていることも確認します。 -
2 番目のファイルリソース宣言を追加します。これにより、Web サーバーのディレクトリー (
/var/www/myserver) が作成されます。 -
notify => Service["httpd"]属性を使用して、設定ファイルと httpd サービスの間の関係も追加します。これにより、設定ファイルへの変更の有無がチェックされます。ファイルが変更された場合には、Puppet によりサービスが再起動されます。
4.2. OpenStack Puppet モジュールの取得 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenStack Platform は、Github の openstack グループから取得する正式な OpenStack Puppet モジュールを使用します。https://github.com/openstack に移動して、フィルターセクションで puppet を検索します。すべての Puppet モジュールには、puppet- の接頭辞が使用されます。
この例では、以下のコマンドを使用してクローン作成し、正式な OpenStack Block Storage (cinder) を検証します。
git clone https://github.com/openstack/puppet-cinder.git
$ git clone https://github.com/openstack/puppet-cinder.git
これにより、Cinder の Puppet モジュールのクローンを作成します。
4.3. Puppet モジュールの設定追加 リンクのコピーリンクがクリップボードにコピーされました!
OpenStack モジュールでは、主にコアサービスを設定します。モジュールの多くには、backends、agents または plugins として知られる追加のサービスを設定するための追加のマニフェストが含まれます。たとえば、cinder モジュールには backends と呼ばれるディレクトリーがあり、この中には NFS、iSCSI、Red Hat Ceph Storage など異なるストレージの設定オプションが含まれます。
たとえば、manifests/backends/nfs.pp ファイルには以下の設定が含まれます。
これにより、以下の操作が実行されます。
-
defineステートメントでは、cinder::backend::nfsと呼ばれる定義型が作成されます。定義型はクラスによく似ていますが、主な相違点は Puppet は定義型を複数回評価する点です。たとえば、複数の NFS バックエンドが必要なため、この設定では NFS 共有ごとに評価を複数回実行する必要があります。 -
次の数行では、設定内のパラメーターとそのデフォルト値を定義します。
cinder::backend::nfsの定義型に新しい値が渡された場合には、デフォルト値は上書きされます。 -
file関数は、ファイルの作成を呼び出すリソース宣言です。このファイルには、NFS 共有の一覧が含まれており、このファイルの名前はパラメーターで定義されます ($nfs_shares_config = '/etc/cinder/shares.conf')。以下は追加の属性です。 -
content属性は、$nfs_serversパラメーターを使用して一覧を作成します。 -
require属性は、cinderパッケージが確実にインストールされるようにします。 -
notify属性はcinder-volumeサービスにリセットするように指示を出します。 cinder_config関数は、モジュールのlib/puppet/ディレクトリーからプラグインを使用するリソース宣言です。このプラグインは/etc/cinder/cinder.confファイルに設定を追加します。このリソースのそれぞれの行により、cinder.confファイルの適切なセクションに設定オプションが追加されます。たとえば、$nameパラメーターがmynfsの場合には、属性は以下のようになります。"${name}/volume_backend_name": value => $volume_backend_name; "${name}/volume_driver": value => 'cinder.volume.drivers.nfs.NfsDriver'; "${name}/nfs_shares_config": value => $nfs_shares_config;"${name}/volume_backend_name": value => $volume_backend_name; "${name}/volume_driver": value => 'cinder.volume.drivers.nfs.NfsDriver'; "${name}/nfs_shares_config": value => $nfs_shares_config;Copy to Clipboard Copied! Toggle word wrap Toggle overflow 上記の属性により、
cinder.confのファイルに以下が追加されます。[mynfs] volume_backend_name=mynfs volume_driver=cinder.volume.drivers.nfs.NfsDriver nfs_shares_config=/etc/cinder/shares.conf
[mynfs] volume_backend_name=mynfs volume_driver=cinder.volume.drivers.nfs.NfsDriver nfs_shares_config=/etc/cinder/shares.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
create_resources関数は、ハッシュをリソースセットに変換します。この場合は、マニフェストにより$extra_optionsハッシュがバックエンドの追加設定オプションに変換されます。これは、マニフェストのコアパラメーターに含まれていない設定オプションを追加する柔軟な方法を提供します。
これにより、ハードウェアの OpenStack ドライバーを設定するマニフェストを追加することの重要性が分かります。マニフェストは、director がハードウェアに適した設定オプションを追加する簡単な方法を提供します。マニフェストは、director がハードウェアをオーバークラウドで使用できるように設定する際の統合ポイントの役割を果たします。
4.4. Puppet 設定への階層データの追加 リンクのコピーリンクがクリップボードにコピーされました!
Puppet には、Hiera と呼ばれるツールが含まれています。このツールはノード固有の設定を提供する key/value システムとして機能します。これらのキーと値は通常 /etc/puppet/hieradata に配置されています。/etc/puppet/hiera.yaml ファイルは、Puppet が hieradata ディレクトリーのファイルを読み込む順序を定義します。
オーバークラウドを設定する際には、Puppet はこのデータを使用して特定の Puppet クラスのデフォルト値を上書きします。たとえば、puppet-cinder にある cinder::backend::nfs の NFS のマウントオプションはデフォルトでは未定義になっています。
$nfs_mount_options = undef,
$nfs_mount_options = undef,
ただし、cinder::backend::nfs の定義する型を呼び出す独自のマニフェストを作成して、このオプションを Hiera データに置き換えることができます。
cinder::backend::nfs { $cinder_nfs_backend:
nfs_mount_options => hiera('cinder_nfs_mount_options'),
}
cinder::backend::nfs { $cinder_nfs_backend:
nfs_mount_options => hiera('cinder_nfs_mount_options'),
}
これは、nfs_mount_options パラメーターが cinder_nfs_mount_options キーから取得した Hiera データの値を使用することを意味します。
cinder_nfs_mount_options: rsize=8192,wsize=8192
cinder_nfs_mount_options: rsize=8192,wsize=8192
または、NFS 設定の全評価に適用されるように Hiera データを使用して cinder::backend::nfs::nfs_mount_options パラメーターを直接上書きすることができます。以下に例を示します。
cinder::backend::nfs::nfs_mount_options: rsize=8192,wsize=8192
cinder::backend::nfs::nfs_mount_options: rsize=8192,wsize=8192
上記の Heira データは cinder::backend::nfs の各評価上にあるこのパラメーターを上書きします。
第5章 オーケストレーション リンクのコピーリンクがクリップボードにコピーされました!
director は Heat Orchestration Template (HOT) をオーバークラウドデプロイメントプランのテンプレート形式として使用します。HOT 形式のテンプレートは多くの場合に、YAML 形式で表現されます。テンプレートの目的は、リソースごとの設定や Heat が作成するリソースコレクションであるスタックを定義して作成することです。リソースとは、OpenStack のオブジェクトで、コンピュートリソース、ネットワーク設定、セキュリティーグループ、スケーリングルール、カスタムリソースが含まれる場合があります。
本章では、独自のテンプレートファイルを作成できるように HOT 構文を理解するための基本を説明します。
5.1. Heat テンプレートの基礎知識 リンクのコピーリンクがクリップボードにコピーされました!
5.1.1. Heat テンプレートの理解 リンクのコピーリンクがクリップボードにコピーされました!
Heat テンプレートの構造には主に 3 つのセクションが含まれます。
Heat テンプレートの構造には主に 3 つのセクションが含まれます。
- Parameters
-
Prameters は Heat に渡される設定のことで、値を指定せずにパラメーターのデフォルト値やスタックをカスタマイズする方法を提供します。これらは、テンプレートの
parametersセクションで定義されます。 - Resources
-
Resources とはスタックの一部として作成/設定する固有のオブジェクトのことです。OpenStack には全コンポーネントに対応するコアのリソースセットが含まれています。これらの設定は、テンプレートの
resourcesセクションで定義されます。 - Output
-
Output は、スタックの作成後に Heat から渡される値です。これらの値には、Heat API またはクライアントツールを使用してアクセスすることができます。これらは、テンプレートの
outputセクションで定義されます。
以下に、基本的な Heat テンプレートの例を示します。
このテンプレートは、type: OS::Nova::Server のリソース種別を使用して、特定のフレーバー、イメージ、キーを指定した my_instance と呼ばれるインスタンスを作成します。このスタックは、My Cirros Instance という instance_name の値を返します。
Heat テンプレートは、利用可能な関数や使用する構文のバージョンを定義する heat_template_version パラメーターも必要とします。詳しい情報は Heat の正式なドキュメント を参照してください。
5.1.2. 環境ファイルの理解 リンクのコピーリンクがクリップボードにコピーされました!
環境ファイルとは、Heat テンプレートをカスタマイズする特別な種類のテンプレートです。このファイルは、3 つの主要な部分で構成されます。
- Parameters
-
これらは、テンプレートのパラメーターに適用する共通設定で、環境ファイルの
parametersセクションで定義します。 - Parameter Defaults
-
これらのパラメーターは、テンプレートのパラメーターのデフォルト値を変更します。これらの設定は、環境ファイルの
parameter_defaultsセクションで定義します。 - Resource Registry
-
このセクションでは、カスタムのリソース名と、他の Heat テンプレートへのリンクを定義します。これは実質的に、コアリソースコレクションに存在しないカスタムのリソースを作成する方法を提供します。この設定は、環境ファイルの
resource_registryセクションで定義されます。
以下に基本的な環境ファイルの例を示します。
このファイルにより、OS::Nova::Server::MyServer と呼ばれる新しいリソース種別が作成されます。myserver.yaml ファイルは、このリソース種別を実装する Heat テンプレートファイルで、このファイルでの設定が元の設定よりも優先されます。
5.2. デフォルトの director テンプレートの取得 リンクのコピーリンクがクリップボードにコピーされました!
director は、オーバークラウドを作成する Heat テンプレートコレクションを使用します。このコレクションは、openstack-tripleo-heat-templatesリポジトリーの Github にある openstack グループから入手できます。このテンプレートコレクションのクローンを取得するには、以下のコマンドを実行します。
git clone https://github.com/openstack/tripleo-heat-templates.git
$ git clone https://github.com/openstack/tripleo-heat-templates.git
このテンプレートコレクションの Red Hat 固有のバージョンは、openstack-tripleo-heat-template パッケージから取得できます。このパッケージは、コレクションを /usr/share/openstack-tripleo-heat-templates にインストールします。
このテンプレートコレクションには、多数の Heat テンプレートおよび環境ファイルが含まれますが、注意すべき主要なファイルは以下の 3 つです。
overcloud-without-mergepy.yaml- これはオーバークラウド環境を作成するために使用する主要なテンプレートファイルです。
overcloud-resource-registry-puppet.yaml- これは、オーバークラウド環境の作成に使用する主要な環境ファイルで、オーバークラウドイメージ上に保存される Puppet モジュールの設定セットを提供します。director により各ノードにオーバークラウドのイメージが書き込まれると、Heat は環境ファイルに登録されているリソースを使用して各ノードに Puppet の設定を開始します。
overcloud-resource-registry.yaml- これは、オーバークラウド環境の作成に使用する標準の環境ファイルです。overcloud-resource-registry-puppet.yaml は、このファイルをベースにしており、お使いの環境をカスタム設定する際に使用します。
director は、最初の 2 つのファイルを使用して、オーバークラウドの作成を開始します。このコレクション内にある他のファイルはすべて overcloud-resource-registry-puppet.yaml ファイルと子関係にあるか、独自の環境ファイルに関連する追加の機能を提供して、デプロイメントに追加できるようにします。
environments-
オーバークラウドの作成に使用可能な Heat 環境ファイルが追加で含まれます。これらの環境ファイルは、作成された OpenStack 環境の追加の機能を有効にします。たとえば、ディレクトリーには Cinder NetApp のバックエンドストレージ (
cinder-netapp-config.yaml) を有効にする環境ファイルが含まれています。 extraconfig-
追加の機能を有効化するために使用するテンプレート。たとえば、director が提供する
extraconfig/pre_deploy/rhel-registrationは、ノードの Red Hat Enterprise Linux オペレーティングシステムを Red Hat コンテンツ配信ネットワークまたは Red Hat Satelite サーバーに登録できるようにします。 firstboot-
ノードを最初に作成する際に director が使用する
first_bootスクリプトを提供します。 network- 分離ネットワークおよびポートを作成しやすくする Heat テンプレートセット
puppet-
大部分は Puppet を使用した設定によって動作するテンプレート。前述した
overcloud-resource-registry-puppet.yaml環境ファイルは、このディレクトリーのファイルを使用して、各ノードに Puppet の設定が適用されるようにします。 validation-scripts- すべてのデプロイメント設定に有用な検証スクリプトが含まれます。
この章では、director がオーバークラウドの作成のオーケストレーションに使用するテンプレートの概要を説明しました。次の複数のセクションでは、オーバークラウドのデプロイメントに追加可能なカスタムのテンプレートや環境ファイルを作成する方法を説明します。
5.3. 初回起動での設定のカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
director は、オーバークラウドの初期設定時に全ノードに設定を行うメカニズムを提供し、cloud-init でこの設定をアーカイブします。アーカイブした内容は、OS::TripleO::NodeUserData リソース種別を使用して呼び出すことが可能です。
以下の例は、全ノード上でカスタム IP アドレスを使用してネームサーバーを更新することを目的とします。まず基本的な Heat テンプレート (nameserver.yaml) を作成します。このテンプレートは、固有のネームサーバーが指定された各ノードの resolv.conf を追加するスクリプトを実行します。OS::TripleO::MultipartMime リソース種別を使用して、この設定スクリプトを送信します。
次に、OS::TripleO::NodeUserData リソース種別として Heat テンプレートを登録する環境ファイル (firstboot.yaml) を作成します。
resource_registry: OS::TripleO::NodeUserData: nameserver.yaml
resource_registry:
OS::TripleO::NodeUserData: nameserver.yaml
これにより、以下の操作が実行されます。
-
OS::TripleO::NodeUserDataは、コレクション内の他のテンプレートで使用する director ベースの Heat リソースで、全ノードに対して初回起動の設定を適用します。このリソースは、cloud-initで使用するデータを渡します。デフォルトのNodeUserDataは、空の値 (firstboot/userdata_default.yaml) を指定する Heat テンプレートを参照します。この例では、firstboot.yamlの環境ファイルは、このデフォルトを独自のnameserver.yamlファイルへの参照に置き換えます。 -
nameserver_configは、初回起動で実行する Bash スクリプトを定義します。OS::Heat::SoftwareConfigリソースは、適用する設定としてこれを定義します。 -
userdataは、OS::Heat::MultipartMimeリソースを使用して、nameserver_configから複数のパートからなる MIME メッセージに設定を変換します。 -
outputsでは、output パラメーターのOS::stack_idが提供され、userdataから MIME メッセージを呼び出している Heat テンプレート/リソースに渡します。
これにより、各ノードは初回起動時に以下の Bash スクリプトを実行します。
#!/bin/bash echo "nameserver 192.168.1.1" >> /etc/resolve.conf
#!/bin/bash
echo "nameserver 192.168.1.1" >> /etc/resolve.conf
この例では、Heat テンプレートがあるリソースから別のリソースに設定を渡して変更する方法を示しています。また、新規の Heat リソース登録または既存のリソース変更を行う環境ファイルの使用方法も説明します。
5.4. オーバークラウドを構成する前の設定のカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
オーバークラウドは、OpenStackコンポーネントのコア設定に Puppet を使用します。director は、初回のブートが完了してコア設定が開始する前に、カスタム設定を提供するリソースのセットを用意します。これには、以下のリソースが含まれます。
- OS::TripleO::ControllerExtraConfigPre
- Puppet のコア設定前にコントローラーノードに適用される追加の設定
- OS::TripleO::ComputeExtraConfigPre
- Puppet のコア設定前にコンピュートノードに適用される追加の設定
- OS::TripleO::CephStorageExtraConfigPre
- Puppet のコア設定前に CephStorage ノードに適用される追加の設定
- OS::TripleO::NodeExtraConfig
- Puppet のコア設定前に全ノードに適用される追加の設定
以下の例では、まず基本的な Heat テンプレート (/home/stack/templates/nameserver.yaml) を作成します。このテンプレートは、変数のネームサーバーが指定された各ノードの resolv.conf を追加するスクリプトを実行します。
servers パラメーターは、設定を適用するサーバー一覧で、親テンプレートにより提供されます。このパラメーターは、 すべての 事前設定テンプレートで必須です。
次に、OS::TripleO::NodeExtraConfig リソース種別として Heat テンプレートを登録する環境ファイル (/home/stack/templates/pre_config.yaml) を作成します。
resource_registry: OS::TripleO::NodeExtraConfig: nameserver.yaml parameter_defaults: nameserver_ip: 192.168.1.1
resource_registry:
OS::TripleO::NodeExtraConfig: nameserver.yaml
parameter_defaults:
nameserver_ip: 192.168.1.1
これにより、以下の操作が実行されます。
-
OS::TripleO::NodeExtraConfigは、Heat テンプレートコレクション内の設定テンプレートで使用する director ベースの Heat リソースです。このリソースは、*-puppet.yamlを使用して各ノード種別に設定を渡します。デフォルトのNodeExtraConfigは、空の値 (puppet/extraconfig/pre_deploy/default.yaml) を指定する Heat テンプレートを参照します。この例では、pre_config.yamlの環境ファイルは、このデフォルトを独自のnameserver.yamlファイルへの参照に置き換えます。 -
環境ファイルは、この環境の
parameter_defaultの値としてnameserver_ipを渡します。これは、ネームサーバーの IP アドレスを保存するパラメーターです。nameserver.yamlの Heat テンプレートは、parametersセクションで定義されているとおりに、このパラメーターを受け入れます。 -
このテンプレートは、
OS::Heat::SoftwareConfigを使用して設定リソースとしてExtraPreConfigを定義します。group: scriptプロパティーに注意してください。groupは、使用するソフトウェア設定ツールを定義します。このソフトウェア設定ツールは Heat のフックセットで入手できます。この場合は、scriptフックは、SoftwareConfigリソースでconfigとして定義される実行可能なスクリプトを実行します。 このスクリプト自体は、
/etc/resolve.confにネームサーバーの IP アドレスを追加します。str_replaceの属性に注意してください。これにより、templateセクションの変数をparamsセクションのパラメーターに置き換えることが可能となります。この場合は、NAMESERVER_IP をネームサーバーの IP アドレスに設定します。スクリプト内の同じ変数はこの IP アドレスに置き換えられ、その結果、スクリプトは以下のようになります。#!/bin/sh echo "nameserver 192.168.1.1" >> /etc/resolve.conf
#!/bin/sh echo "nameserver 192.168.1.1" >> /etc/resolve.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow ExtraPreDeploymentsはExtraPreConfig設定をノードにデプロイします。以下の点に注意してください。-
config属性は、Heat がどの設定が適用されるかを理解できるようにExtraPreConfigリソースを参照します。 -
servers属性は、overcloud-without-mergepy.yamlが渡すオーバークラウドのノードのマッピングを取得します。 -
actions属性は、設定を適用するタイミングを定義します。この場合は、オーバークラウドが作成された時にのみ設定を適用します。実行可能なアクションはCREATE、UPDATE、DELETE、SUSPENDおよびRESUMEです。
-
この例は、コアの設定の前に OS::Heat::SoftwareConfig と OS::Heat::SoftwareDeployments で設定を定義してデプロイする Heat テンプレートの作成方法を示します。また、環境ファイルでパラメーターを定義して、設定でテンプレートを渡す方法も示します。
5.5. オーバークラウド設定後の設定のカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
オーバークラウドの作成が完了してから、オーバークラウドの初回作成時または更新時に設定を追加する必要となる可能性があります。このような場合は、OS::TripleO::NodeExtraConfigPost リソースを使用して、標準の OS::Heat::SoftwareConfig 種別を使用した設定を適用します。これにより、メインのオーバークラウド設定が完了してから、追加の設定が適用されます。
以下の例では、まず基本的な Heat テンプレート (nameserver.yaml) を作成します。このテンプレートは、変数のネームサーバーが指定された各ノードの resolv.conf を追加するスクリプトを実行します。
servers パラメーターは、設定を適用するサーバー一覧で、親テンプレートにより提供されます (overcloud-without-mergepy.yaml)。このパラメーターは、 すべての OS::TripleO::NodeExtraConfigPost テンプレートで必須です。
次に、OS::TripleO::NodeExtraConfigPost リソース種別として Heat テンプレートを登録する環境ファイル (post_config.yaml) を作成します。
resource_registry: OS::TripleO::NodeExtraConfigPost: nameserver.yaml parameter_defaults: nameserver_ip: 192.168.1.1
resource_registry:
OS::TripleO::NodeExtraConfigPost: nameserver.yaml
parameter_defaults:
nameserver_ip: 192.168.1.1
これにより、以下の操作が実行されます。
-
OS::TripleO::NodeExtraConfigPostは、Heat テンプレートコレクション内の設定テンプレートで使用する director ベースの Heat リソースです。このリソースは、*-post.yamlを使用して各ノード種別に設定を渡します。デフォルトのNodeExtraConfigPostは、空の値 (extraconfig/post_deploy/default.yaml) を指定する Heat テンプレートを参照します。この例では、post_config.yamlの環境ファイルは、このデフォルトを独自のnameserver.yamlファイルへの参照に置き換えます。 -
環境ファイルは、この環境の
parameter_defaultの値としてnameserver_ipを渡します。これは、ネームサーバーの IP アドレスを保存するパラメーターです。nameserver.yamlの Heat テンプレートは、parametersセクションで定義されているとおりに、このパラメーターを受け入れます。 -
このテンプレートは、
OS::Heat::SoftwareConfigを使用して設定リソースとしてExtraConfigを定義します。group: scriptプロパティーに注意してください。groupは、使用するソフトウェア設定ツールを定義します。このソフトウェア設定ツールは Heat のフックセットで入手できます。この場合は、scriptフックは、SoftwareConfigリソースでconfigとして定義される実行可能なスクリプトを実行します。 このスクリプト自体は、
/etc/resolve.confにネームサーバーの IP アドレスを追加します。str_replaceの属性に注意してください。これにより、templateセクションの変数をparamsセクションのパラメーターに置き換えることが可能となります。この場合は、NAMESERVER_IP をネームサーバーの IP アドレスに設定します。スクリプト内の同じ変数はこの IP アドレスに置き換えられ、その結果、スクリプトは以下のようになります。#!/bin/sh echo "nameserver 192.168.1.1" >> /etc/resolve.conf
#!/bin/sh echo "nameserver 192.168.1.1" >> /etc/resolve.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow ExtraDeploymentsはExtraConfig設定をノードにデプロイします。以下の点に注意してください。-
config属性は、Heat がどの設定が適用されるかを理解できるようにExtraConfigリソースを参照します。 -
servers属性は、overcloud-without-mergepy.yamlが渡すオーバークラウドのノードのマッピングを取得します。 -
actions属性は、設定を適用するタイミングを定義します。この場合は、オーバークラウドが作成された時にのみ設定を適用します。実行可能なアクションはCREATE、UPDATE、DELETE、SUSPENDおよびRESUMEです。
-
この例は、OS::Heat::SoftwareConfig と OS::Heat::SoftwareDeployments で設定を定義してデプロイする Heat テンプレートの作成方法を示します。また、環境ファイルでパラメーターを定義して、設定でテンプレートを渡す方法も示します。
5.6. カスタムの Puppet 設定のオーバークラウドへの適用 リンクのコピーリンクがクリップボードにコピーされました!
これまで、新規バックエンドの設定を OpenStack Puppet モジュールに追加する方法を説明しました。このセクションでは、director が新規設定を適用する方法を説明します。
Heat テンプレートは、OS::Heat::SoftwareConfig リソースで Puppet 設定を適用可能なフックを提供します。このプロセスは、Bash スクリプトを追加して実行した方法に似ていますが、group: script フックを使用するのではなく、group: puppet フックを使用します。
たとえば、公式の Cinder Puppet モジュールを使用して NFS Cinder バックエンドを有効化する Puppet マニフェスト (example-puppet-manifest.pp) があるとします。
cinder::backend::nfs { 'mynfsserver':
nfs_servers => ['192.168.1.200:/storage'],
}
cinder::backend::nfs { 'mynfsserver':
nfs_servers => ['192.168.1.200:/storage'],
}
Puppet の設定は、cinder::backend::nfs の定義型を使用して新規リソースを作成します。Heat を使用してこのリソースを適用するには、Puppet マニフェストを実行する基本的な Heat テンプレート (puppet-config.yaml) を作成します。
次に、OS::TripleO::NodeExtraConfigPost リソース種別として Heat テンプレートを登録する環境ファイル (puppet_config.yaml) を作成します。
resource_registry: OS::TripleO::NodeExtraConfigPost: puppet_config.yaml
resource_registry:
OS::TripleO::NodeExtraConfigPost: puppet_config.yaml
この例は前項の script フックの例から SoftwareConfig と SoftwareDeployments を使用するのに似ていますが、以下の点が異なります。
-
puppetフックを実行するためにgroup: puppetを設定します。 -
config属性はget_file属性を使用して、追加の設定が含まれる Puppet マニフェストを参照します。 options属性には、Puppet 設定固有のオプションが含まれます。-
enable_hieraオプションは、Puppet 設定で Hiera データを使用できるようにします。 -
enable_facterオプションは、facterコマンドからシステムファクトを使用する Puppet 設定を有効にします。
-
この例では、Puppet マニフェストをオーバークラウドのソフトウェア設定の一部として追加する方法を示します。これにより、オーバークラウドのイメージで既存の Puppet モジュールから特定の設定クラスを適用する方法ができ、特定のソフトウェアやハードウェアを使用するようにオーバークラウドをカスタマイズしやすくなります。
5.7. オーバークラウドでの Hiera データの変更 リンクのコピーリンクがクリップボードにコピーされました!
前述したように、Puppet は Hiera ツールを使用して特定の変数にノード固有の値を指定します。これらのキーと値は通常、/etc/puppet/hieradata にあるファイルに保存されます。オーバークラウドでは、このディレクトリーには、カスタムパラメーターを追加する際に使用する、追加の Hiera ファイルのセットが含まれます。
director の Heat テンプレートコレクションにあるパラメーターセットを使用してこの Hiera データを渡します。これらのパラメーターは以下のとおりです。
- ExtraConfig
- 全ノードに追加する設定
- NovaComputeExtraConfig
- コンピュートノードに追加する設定
- controllerExtraConfig
- コントローラーノードに追加する設定
- BlockStorageExtraConfig
- ブロックストレージノードに追加する設定
- ObjectStorageExtraConfig
- オブジェクトストレージノードに追加する設定
- CephStorageExtraConfig
- Ceph ストレージノードに追加する設定
デプロイ後の設定プロセスに設定を追加するには、parameter_defaults セクションにこれらのパラメーターが記載された環境ファイルを作成します。たとえば、コンピュートホストに確保するメモリーを 1024 MB に増やすには、以下のように設定します。
parameter_defaults:
NovaComputeExtraConfig:
nova::compute::reserved_host_memory: 1024
parameter_defaults:
NovaComputeExtraConfig:
nova::compute::reserved_host_memory: 1024
これにより、コンピュートノードの /etc/puppet/hieradata ディレクトリーにあるカスタムの Hiera ファイルに nova::compute::reserved_host_memory: 1024 が追加されます。
5.8. オーバークラウドのデプロイメントへの環境ファイルの追加 リンクのコピーリンクがクリップボードにコピーされました!
カスタム設定に関連する環境ファイルセットを開発した後に、オーバークラウドにこれらのファイルを追加します。これには、-e オプションの後に環境ファイルを指定して openstack overcloud deploy コマンドを実行します。カスタマイズに必要な回数だけ、-e オプションを指定することができます。
openstack overcloud deploy --templates -e network-configuration.yaml -e storage-configuration.yaml -e first-boot.yaml
$ openstack overcloud deploy --templates -e network-configuration.yaml -e storage-configuration.yaml -e first-boot.yaml
環境ファイルは、順序通りにスタックされます。これは、主要な Heat テンプレートコレクションとこれまでの全環境ファイル両方の上に後続のファイルがスタックされることを意味します。この方法により、リソースの定義の上書きが可能となります。たとえば、オーバークラウドのデプロイメントにある全環境ファイルは NodeExtraConfigPost リソースを定義し、その後に Heat は最後の環境ファイルで定義した NodeExtraConfigPost を使用します。そのため、環境ファイルの順序は重要です。環境ファイルを正しく処理してスタックできるように、環境ファイルは順序付けるようにしてください。
-e オプションを使用してオーバークラウドに追加した環境ファイルはいずれも、オーバークラウドのスタック定義の一部となります。director は、再デプロイおよびデプロイ後の機能にこれらの環境ファイルを必要とします。これらのファイルが含まれていない場合には、オーバークラウドが破損する場合があります。
[[Integration Points]] == Integration Points
本章では、director の統合における具体的な統合ポイントを考察し、固有の OpenStack コンポーネントと director またはオーバークラウドの統合とそのコンポーネントの関係について記載します。このセクションに記載する内容は、OpenStack のすべての統合についての包括的な説明ではありませんが、ハードウェアおよびソフトウェアを Red Hat OpenStack Platform に統合する作業を開始するには十分な情報となるはずです。
5.9. Bare Metal Provisioning (Ironic) リンクのコピーリンクがクリップボードにコピーされました!
OpenStack Bare Metal Provisioning (Ironic) のコンポーネントは、director 内で使用され、ノードの電源状態を制御します。director はバックエンドドライバーのセットを使用して、固有のベアメタルの電源コントローラーとやりとりをします。これらのドライバーは、ハードウェアやベンダー固有の拡張や機能を有効化する際に重要です。最も一般的なドライバーは IPMI ドライバー (pxe_ipmitool) で、Intelligent Platform Management Interface (IPMI) をサポートするサーバーの電源状態を制御します。
Ironic との統合は、アップストリームの OpenStack コミュニティーから始まります。アップストリームで受け入れられた Ironic ドライバーは、コアの Red Hat OpenStack Platform 製品と director にデフォルトで自動的に含まれますが、認定要件によりサポートされない可能性があります。
機能が継続して確保されるように、ハードウェアドライバーは、常に統合テストを受ける必要があります。サードパーティー製のドライバーのテストおよび持続性に関する情報は、OpenStack コミュニティーページの Ironic Testing を参照してください。
アップストリームのリポジトリー:
アップストリームのブループリント:
- Launchpad: http://launchpad.net/ironic
Puppet モジュール:
Bugzilla コンポーネント:
- openstack-ironic
- python-ironicclient
- python-ironic-oscplugin
- openstack-ironic-discoverd
- openstack-puppet-modules
- openstack-tripleo-heat-templates
統合メモ:
-
アップストリームプロジェクトでは、
ironic/driversディレクトリーにドライバーが含まれます。 -
director は、JSON ファイルで定義されたノードをまとめて登録します。
os-cloud-configツール (https://github.com/openstack/os-cloud-config/) は、このファイルを解析して、ノード登録の詳細を判断して登録を実行します。これは、os-cloud-configツール、具体的にはnodes.pyファイルにはドライバーのサポートが必要です。 director は、Ironic を使用するように自動的に設定されます。つまり、Puppet 設定では、変更をほぼ加える必要はないということです。ただし、ドライバーに Ironic が含まれる場合には、お使いのドライバーを
/etc/ironic/ironic.confファイルに追加する必要があります。このファイルを編集してenabled_driversパラメーターを検索してください。以下に例を示します。enabled_drivers=pxe_ipmitool,pxe_ssh,pxe_drac
enabled_drivers=pxe_ipmitool,pxe_ssh,pxe_dracCopy to Clipboard Copied! Toggle word wrap Toggle overflow これにより、
driversディレクトリーからの指定のドライバーを Ironic が使用できるようになります。
5.10. Networking (Neutron) リンクのコピーリンクがクリップボードにコピーされました!
OpenStack Networking (Neutron) は、クラウド環境でネットワークアーキテクチャーを作成する機能を提供します。このプロジェクトは、Software Defined Networking (SDN) ベンダーの統合ポイントを複数提供します。この統合ポイントは通常 プラグイン または エージェント のカテゴリーに分類されます。
プラグイン では、既存の Neutron の機能を拡張およびカスタマイズすることができます。ベンダーは、プラグインを記述して、Neutron と認定済みのソフトウェアやハードウェアの間で相互運用性を確保することができます。多くのベンダーは、独自のドライバーを統合するためのモジュラーバックエンドを提供する、Neutron の Modular Layer 2 (ml2) プラグインのドライバーを開発することを目的にする必要があります。
エージェント では、固有のネットワーク機能が提供されます。主な Neutron サーバー (およびプラグイン) は、Neutron エージェントと通信します。既存の例には、DHCP、Layer 3 のサポート、ブリッジサポートが含まれます。
プラグインおよびエージェントは、以下のいずれかが可能です。
- OpenStack Platform ソリューションの一部としてディストリビューションに含める。
- OpenStack Platform のディストリビューションの後にオーバークラウドのイメージに追加する。
認定済みのハードウェアおよびソフトウェアを統合する方法を判断できるように、既存のプラグインおよびエージェントの機能を分析することを推奨します。特に、ml2 プラグインの一部としてドライバーをまず開発することを推奨します。
アップストリームのリポジトリー:
アップストリームのブループリント:
- Launchpad: http://launchpad.net/neutron
Puppet モジュール:
Bugzilla コンポーネント:
- openstack-neutron
- python-neutronclient
- openstack-puppet-modules
- openstack-tripleo-heat-templates
統合メモ:
アップストリームの
neutronプロジェクトには、複数の統合ポイントが含まれます。-
プラグインは
neutron/plugins/にあります。 -
ml2 プラグインドライバーは
neutron/plugins/ml2/drivers/にあります。 -
エージェントは
neutron/agents/にあります。
-
プラグインは
-
OpenStack Liberty リリース以降、ベンダー固有の ml2 プラグインの多くが
networking-で始まる独自のリポジトリーに移動されました。たとえば、Cisco 固有のプラグインは https://github.com/openstack/networking-cisco にあります。 puppet-neutronリポジトリーには、これらの統合の設定用に別のディレクトリーも含まれます。-
プラグイン設定は
manifests/plugins/にあります。 -
ml2 プラグインのドライバー設定は
manifests/plugins/ml2/にあります。 -
エージェントの設定は
manifests/agents/にあります。
-
プラグイン設定は
-
puppet-neutronリポジトリーには、設定関数のライブラリーが別途多数含まれています。たとえば、neutron_plugin_ml2ライブラリーは、ml2 プラグインの設定ファイルに属性を追加する関数を追加します。
5.11. Block Storage (Cinder) リンクのコピーリンクがクリップボードにコピーされました!
OpenStack Block Storage (Cinder) は、OpenStack がボリュームの作成に使用するブロックストレージデバイスと対話するための API を提供します。たとえば、Cinder はインスタンスの仮想ストレージデバイスや、異なるストレージハードウェアやプロトコルをサポートするドライバーのコアセットを提供します。コアのドライバーには、NFS、iSCSI、Red Hat Ceph Storage へのサポートを含むものもあります。ベンダーは、認定済みのハードウェアのサポートを追加するためにドライバーを含めることができます。
ベンダーの開発するドライバーおよび設定には、主に 2 つのオプションがあります。
- OpenStack Platform ソリューションの一部としてディストリビューションに含める。
- OpenStack Platform のディストリビューションの後にオーバークラウドのイメージに追加する。
認定済みのハードウェアおよびソフトウェアを統合する方法を判断できるように、既存のドライバーの機能を分析することを推奨します。
アップストリームのリポジトリー:
アップストリームのブループリント:
- Launchpad: http://launchpad.net/cinder
Puppet モジュール:
Bugzilla コンポーネント:
- openstack-cinder
- python-cinderclient
- openstack-puppet-modules
- openstack-tripleo-heat-templates
統合メモ:
-
アップストリームの
cinderリポジトリーではcinder/volume/drivers/にドライバーが含まれます。 puppet-cinderリポジトリーには、ドライバー設定の主要なディレクトリーが 2 つ含まれます。-
manifests/backendディレクトリーには、ドライバーの設定を行う定義型のセットが含まれます。 -
manifests/volumeディレクトリーには、デフォルトのブロックストレージデバイスを設定するクラスセットが含まれます。
-
-
puppet-cinderリポジトリーには、Cinder 設定ファイルに属性を追加するためのcinder_configと呼ばれるライブラリーが含まれます。
5.12. Image Storage (Glance) リンクのコピーリンクがクリップボードにコピーされました!
OpenStack Image Storage (Cinder) は、イメージのストレージを提供するストレージ種別と対話するための API を提供します。Glance は、ファイルのサポート、OpenStack Object Storage (Swift)、OpenStack Block Storage (Cinder)、Red Hat Ceph Storage など、異なるハードウェアおよびプロトコルをサポートするドライバーのコアセットを提供します。ベンダーは、認定済みのハードウェアのサポートを追加するためにドライバーを含めることができます。
アップストリームのリポジトリー:
OpenStack:
GitHub:
アップストリームのブループリント:
- Launchpad: http://launchpad.net/glance
Puppet モジュール:
Bugzilla コンポーネント:
- openstack-glance
- python-glanceclient
- openstack-puppet-modules
- openstack-tripleo-heat-templates
統合メモ:
- Glance は、イメージストレージを管理する統合ポイントを含む Cinder を使用できるため、ベンダー固有のドライバーを追加する必要はありません。
-
アップストリームの
glance_storeリポジトリーではglance_store/_driversにドライバーが含まれます。 -
puppet-glanceリポジトリーではmanifests/backendディレクトリーにドライバー設定が含まれます。 -
puppet-glanceリポジトリーには、Cinder 設定ファイルに属性を追加するためのglance_api_configと呼ばれるライブラリーが含まれます。
第6章 実例 リンクのコピーリンクがクリップボードにコピーされました!
本章では、Red Hat OpenStack Platform の一部としてベンダーのソリューションを統合する実例を取り上げて説明します。
6.1. Cisco Nexus 1000V リンクのコピーリンクがクリップボードにコピーされました!
Cisco Nexus 1000V は、仮想マシンアクセス用に設計されたネットワークスイッチです。また、VXLAN、ACL、IGMP スヌーピングを使用した高度なスイッチおよびセキュリティー機能を提供します。Cisco Nexus 1000V の ml2 ドライバーは networking-cisco リポジトリーに含まれており、Neutron サービスと共にインストールできます。
オーバークラウドのイメージには Neutron Puppet モジュール (puppet-neutron) が含まれており、このモジュールに、Neutron が Cisco Nexus 1000V を使用するように設定するためのクラス (neutron::plugins::ml2::cisco::nexus1000v) が含まれます。このクラスは、モジュールの manifests/plugins/ml2/cisco/nexus1000v.pp マニフェストに配置されています。このクラスは、デフォルトのパラメーターセットを使用しますが、このデフォルトパラメーターを上書きして neutron_plugin_ml2 ライブラリーを使用し、m2 プラグインが Cisco Nexus 1000V を使用するように設定することができます。
director の Heat テンプレートコレクションには、Cisco Nexus 1000V の Hiera データを設定するための環境ファイルと登録済みのテンプレートが含まれています。環境ファイルは、environments/cisco-n1kv-config.yaml に配置されており、以下のデフォルトの内容が含まれます。
resource_registry は、コントローラーとコンピュートノード (OS::TripleO::ControllerExtraConfigPre および OS::TripleO::ComputeExtraConfigPre) の事前設定リソースが puppet/extraconfig/pre_deploy/controller/cisco-n1kv.yaml を事前設定用のテンプレートとして使用するように設定します。parameter_defaults のセクションには、これらのリソースに渡すパラメーターの一部が含まれます。
デプロイメントにこの環境ファイルを追加すると Hiera データが定義され、設定中に Puppet が Neutron Puppet モジュールのパラメーターにこのデータを使用します。
Puppet 設定を実際に適用するのは、自動で開始されます。Heat テンプレートコレクションには、コントローラーとコンピュートノードを設定するコアの Puppet マニフェストセットが含まれます。これらのファイルには、Cisco Nexus 1000V Hiera データが設定されていることを検出するためのロジックが含まれます。デプロイメントに cisco-n1kv.yaml を含めることで、マニフェストに neutron::plugins::ml2::cisco::nexus1000v クラスと Cisco Nexus 1000V の VEM と VSM エージェントが追加されます。
これは、オーバークラウドが Cisco Nexus 1000V のみを使用するように設定するには以下のステップが必要であるという意味です。
environments/cisco-n1kv-config.yamlファイルを編集できるように、ローカルの場所にコピーします。cp /usr/share/openstack-tripleo-heat-templates/environments/cisco-n1kv-config.yaml ~/templates/.
$ cp /usr/share/openstack-tripleo-heat-templates/environments/cisco-n1kv-config.yaml ~/templates/.Copy to Clipboard Copied! Toggle word wrap Toggle overflow cisco-n1kv-config.yamlファイルを編集します。-
cisco-n1kv.yamlを参照する絶対パスを使用するようにresource_registeryセクションを変更します。 Cisco Nexus 1000V パラメーターを追加するように
parameter_defaultsセクションを変更します。参考としてcisco-n1kv.yamlを参照してください。例:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
デプロイメントに
cisco-n1kv-config.yamlファイルを追加します。openstack overcloud deploy --templates -e ~/templates/cisco-n1kv-config.yaml
$ openstack overcloud deploy --templates -e ~/templates/cisco-n1kv-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
これは、オーバークラウドの Hiera データの一部として Cisco Nexus 1000V 設定を定義します。次に、オーバークラウドはこの Hieradata を使用して、コアの設定中に Neutron の Nexus 1000V ml2 ドライバーを設定します。
このセクションでは、director が認定済みのベンダーからのネットワークコンポーネントとオーバークラウドの Neutron サービスを統合する方法について、実例を挙げて説明しました。
6.2. NetApp ストレージ リンクのコピーリンクがクリップボードにコピーされました!
NetApp は、OpenStack ストレージのコンポーネントに統合するソリューションを複数提供します。以下の例では、ブロックストレージのバックエンドを提供するためにどのように NetApp Storage と Cinder を統合するかを示します。
Cinder のドライバーは、プロジェクト自体に含まれており、GitHub https://github.com/openstack/cinder で公開されています。NetApp のドライバーは、リポジトリーの cinder/volume/drivers/netapp/ ディレクトリーに配置されています。これは、ドライバーが Red Hat OpenStack Platform に自動で追加されることを意味します。
NetApp の設定は、オーバークラウドのイメージにも含まれる Cinder の Puppet モジュール (puppet-cinder) の中にあります。この設定が含まれる Puppet モジュールのマニフェストは manifests/backend/netapp.pp に配置されています。このマニフェストは cinder_config ライブラリーを使用して、netapp の設定を Cinder 設定ファイルに追加します。
director の Heat テンプレートコレクションには、NetApp Storage バックエンドの Hiera データを設定するための環境ファイルと登録済みのテンプレートが含まれています。環境ファイルは、environments/cinder-netapp-config.yaml に配置されており、以下のデフォルトの内容が含まれます。
resource_registry は、コントローラーノード (OS::TripleO::ControllerExtraConfigPre) の事前設定リソースが puppet/extraconfig/pre_deploy/controller/cinder-netapp.yaml を事前設定用のテンプレートとして使用するように設定します。parameter_defaults のセクションには、これらのリソースに渡すパラメーターの一部が含まれます。
デプロイメントにこの環境ファイルを追加すると Hiera データが定義され、設定中に Puppet が Cinder Puppet モジュールのパラメーターにこのデータを使用します。
CinderEnableNetappBackend パラメーターにより、Puppet 設定の適用が実際に開始されるかが決まります。Heat テンプレートコレクションには、コントローラーノードを設定するコアの Puppet マニフェストセットが含まれます。これらのファイルには、cinder_enable_netapp_backend Hiera データが設定されているかどうかを検出するロジックが含まれます。Hiera データは、事前設定の CinderEnableNetappBackend パラメーターを使用して設定されます。デプロイメントに cinder-netapp-config.yaml を追加して CinderEnableNetappBackend: true をそのままにすると、コントローラーの Puppet マニフェストには cinder::backend::netapp クラスが追加され、環境ファイルからの Hiera データの値を渡します。
これは、オーバークラウドが NetApp Storage のみを使用するように設定するには以下のステップが必要であるという意味です。
environments/cinder-netapp-config.yamlファイルを編集できるように、ローカルの場所にコピーします。cp /usr/share/openstack-tripleo-heat-templates/environments/cinder-netapp-config.yaml ~/templates/.
$ cp /usr/share/openstack-tripleo-heat-templates/environments/cinder-netapp-config.yaml ~/templates/.Copy to Clipboard Copied! Toggle word wrap Toggle overflow cinder-netapp-config.yamlファイルを編集します。-
cinder-netapp.yamlを参照する絶対パスを使用するようにresource_registeryセクションを変更します。 NetApp パラメーターを追加するように
parameter_defaultsセクションを変更します。参考としてcinder-netapp.yamlを参照してください。例:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow CinderEnableNetappBackendはtrue設定のままにしておいてください。
-
デプロイメントに
cinder-netapp-config.yamlファイルを追加します。openstack overcloud deploy --templates -e ~/templates/cinder-netapp-config.yaml
$ openstack overcloud deploy --templates -e ~/templates/cinder-netapp-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
これは、オーバークラウドの Hiera データの一部として NetApp Storage 設定を定義します。次に、オーバークラウドはこの Hieradata を使用して、コアの設定中にCinder の NetApp バックエンドを設定します。
このセクションでは、director が認定済みのベンダーからのストレージコンポーネントとオーバークラウドの Cinder サービスを統合する方法について、実例を挙げて説明しました。