第5章 CLI ツールでの基本的なオーバークラウド要件の設定

本章では、CLI ツールを使用した OpenStack Platform 環境の基本的な設定手順を説明します。基本設定のオーバークラウドには、カスタムの機能は含まれていませんが、基本的なオーバークラウドに高度な設定オプションを追加してから、『オーバークラウドの高度なカスタマイズ』ガイドに記載の手順に従って、仕様に合わせてカスタマイズすることができます。

本章の例では、すべてのノードが電源管理に IPMI を使用したベアメタルシステムとなっています。電源管理の種別およびそのオプションに関する詳細は、「付録B 電源管理ドライバー」を参照してください。

ワークフロー

  1. ノード定義のテンプレートを作成して director で空のノードを登録します。
  2. 全ノードのハードウェアを検査します。
  3. ロールにノードをタグ付けします。
  4. 追加のノードプロパティーを定義します。

要件

  • 4章アンダークラウドのインストール」で作成した director ノード
  • ノードに使用するベアメタルマシンのセット。必要なノード数は、作成予定のオーバークラウドのタイプにより異なります (オーバークラウドロールに関する情報は「ノードのデプロイメントロールのプランニング」を参照してください)。これらのマシンは、各ノード種別の要件セットに従う必要があります。これらの要件については、「オーバークラウドの要件」を参照してください。これらのノードにはオペレーティングシステムは必要ありません。director が Red Hat Enterprise Linux 7 のイメージを各ノードにコピーします。
  • ネイティブ VLAN として設定したプロビジョニングネットワーク用のネットワーク接続 1 つ。全ノードは、このネイティブに接続して、「ネットワーク要件」で設定した要件に準拠する必要があります。この章の例では、以下の IP アドレスの割り当てで、プロビジョニングサブネットとして 192.0.2.0/24 を使用します。

    表5.1 プロビジョニングネットワークの IP 割り当て

    ノード名

    IP アドレス

    MAC アドレス

    IPMI IP アドレス

    director

    192.0.2.1

    aa:aa:aa:aa:aa:aa

    不要

    コントローラー

    定義済みの DHCP

    bb:bb:bb:bb:bb:bb

    192.0.2.205

    Compute

    定義済みの DHCP

    cc:cc:cc:cc:cc:cc

    192.0.2.206

  • その他のネットワーク種別はすべて、OpenStack サービスにプロビジョニングネットワークを使用しますが、ネットワークトラフィックの他のタイプに追加でネットワークを作成することができます。

5.1. オーバークラウドへのノードの登録

director では、手動で作成したノード定義のテンプレートが必要です。このファイル (instackenv.json) は、JSON 形式のファイルを使用して、ノードのハードウェアおよび電源管理の情報が含まれます。たとえば、2 つのノードを登録するテンプレートは、以下のようになります。

{
    "nodes":[
        {
            "mac":[
                "bb:bb:bb:bb:bb:bb"
            ],
            "name":"node01",
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.0.2.205"
        },
        {
            "mac":[
                "cc:cc:cc:cc:cc:cc"
            ],
            "name":"node02",
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.0.2.206"
        }
    ]
}

このテンプレートでは、以下の属性を使用します。

名前
ノードの論理名
pm_type
使用する電源管理ドライバー。この例では IPMI ドライバーを使用します (pxe_ipmitool)。
pm_user; pm_password
IPMI のユーザー名およびパスワード
pm_addr
IPMI デバイスの IP アドレス
mac
(オプション) ノード上のネットワークインターフェースの MAC アドレス一覧。各システムのプロビジョニング NIC の MAC アドレスのみを使用します。
cpu
(オプション) ノード上の CPU 数
memory
(オプション) メモリーサイズ (MB)
disk
(オプション) ハードディスクのサイズ (GB)
arch
(オプション) システムアーキテクチャー
注記

電源管理の種別およびそのオプションに関する詳細は、「付録B 電源管理ドライバー」を参照してください。

テンプレートの作成後に、stack ユーザーのホームディレクトリー (/home/stack/instackenv.json) にファイルを保存して、以下のコマンドを使用して director にインポートします。

$ openstack overcloud node import ~/instackenv.json

このコマンドでテンプレートをインポートして、テンプレートから director に各ノードを登録します。

ノードを登録して設定が完了した後に、CLI でそれらのノードの一覧を表示します。

$ openstack baremetal node list

5.2. ノードのハードウェアの検査

director は各ノードでイントロスペクションプロセスを実行することができます。このプロセスを実行すると、各ノードが PXE を介してイントロスペクションエージェントを起動します。このエージェントは、ノードからハードウェアのデータを収集して、director に送り返します。次に director は、director 上で実行中の OpenStack Object Storage (swift) サービスにこのイントロスペクションデータを保管します。director は、プロファイルのタグ付け、ベンチマーキング、ルートディスクの手動割り当てなど、さまざまな目的でハードウェア情報を使用します。

注記

ポリシーファイルを作成して、イントロスペクションの直後にノードをプロファイルに自動でタグ付けすることも可能です。ポリシーファイルを作成してイントロスペクションプロセスに組み入れる方法に関する詳しい情報は、「付録E プロファイルの自動タグ付け」を参照してください。または、「プロファイルへのノードのタグ付け」に記載の手順に従って、ノードをプロファイルに手動でタグ付けすることもできます。

管理状態に全ノードを設定します。

$ for node in $(openstack baremetal node list -c UUID -f value) ; do openstack baremetal node manage $node ; done

以下のコマンドを実行して、各ノードのハードウェア属性を検証します。

$ openstack overcloud node introspect --all-manageable --provide
  • --all-manageable オプションは、管理状態のノードのみをイントロスペクションします。上記の例では、すべてのノードが対象です。
  • --provide オプションは、イントロスペクション後に全ノードをアクティブな状態にします。

別のターミナルウィンドウで以下のコマンドを使用してイントロスペクションの進捗状況をモニタリングします。

$ sudo journalctl -l -u openstack-ironic-inspector -u openstack-ironic-inspector-dnsmasq -u openstack-ironic-conductor -f
重要

このプロセスが最後まで実行されて正常に終了したことを確認してください。ベアメタルの場合には、通常 15 分ほどかかります。

または、各ノードに 1 回ずつ個別にイントロスペクションを実行します。ノードを管理モードに切り替えて、イントロスペクションを実行してから、管理モードから元に戻します。

$ openstack baremetal node manage [NODE UUID]
$ openstack overcloud node introspect [NODE UUID] --provide

5.3. プロファイルへのノードのタグ付け

各ノードのハードウェアを登録、検査した後には、特定のプロファイルにノードをタグ付けします。このプロファイルタグにより、ノードがフレーバーに照合され、次にそのフレーバーがデプロイメントロールに割り当てられます。以下の例では、コントローラーノードのロール、フレーバー、プロファイル、ノード間の関係を示しています。

タイプ説明

ロール

Controller ロールはコントローラーノードの設定方法を定義します。

フレーバー

control フレーバーは、コントローラーとして使用するためにノードのハードウェアプロファイルを定義します。使用するノードを director が決定できるように、このフレーバーを Controller ロールに割り当てます。

プロファイル

control プロファイルは、control フレーバーに適用するタグで、このフレーバーに所属するノードを定義します。

ノード

また、各ノードに control プロファイルタグを適用して、control フレーバーにグループ化します。これにより、director が Controller ロールを使用してノードを設定します。

アンダークラウドのインストール時に、デフォルトプロファイルのフレーバー computecontrolswift-storageceph-storageblock-storage が作成され、大半の環境で変更なしに使用することができます。

注記

多くのノードでは、プロファイルの自動タグ付けを使用します。詳しい情報は、「付録E プロファイルの自動タグ付け」を参照してください。

特定のプロファイルにノードをタグ付けする場合には、各ノードの properties/capabilities パラメーターに profile オプションを追加します。たとえば、2 つのノードをタグ付けしてコントローラープロファイルとコンピュートプロファイルをそれぞれ使用するには、以下のコマンドを実行します。

$ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13
$ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0

profile:computeprofile:control オプションを追加することで、この 2 つのノードがそれぞれのプロファイルにタグ付けされます。

これらのコマンドは、各ノードのブート方法を定義する boot_option:local パラメーターも設定します。お使いのハードウェアによっては、boot_mode パラメーターを uefi に追加して、ノードが BIOS モードの代わりに UEFI を使用してブートするようにする必要がある場合もあります。詳しい情報は、「UEFI ブートモード」を参照してください。

ノードのタグ付けが完了した後には、割り当てたプロファイルまたはプロファイルの候補を確認します。

$ openstack overcloud profiles list

カスタムロールのプロファイル

カスタムロールを使用する場合には、これらの新規ロールに対応するために追加のフレーバーやプロファイルを作成する必要があるかもしれません。たとえば、Networker ロールの新規フレーバーを作成するには、以下のコマンドを実行します。

$ openstack flavor create --id auto --ram 4096 --disk 40 --vcpus 1 networker
$ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="networker" networker

この新規プロファイルにノードを割り当てます。

$ openstack baremetal node set --property capabilities='profile:networker,boot_option:local' dad05b82-0c74-40bf-9d12-193184bfc72d

5.4. ノードのルートディスクの定義

一部のノードは、複数のディスクを使用する場合があります。このため、 director はプロビジョニング中に、ルートディスクに使用するディスクを特定する必要があります。director がルートディスクを容易に特定できるようにするには、以下のようなプロパティーを使用することができます。

  • model (文字列): デバイスの ID
  • vendor (文字列): デバイスのベンダー
  • serial (文字列): ディスクのシリアル番号
  • hctl (文字列): SCSI のホスト:チャネル:ターゲット:Lun
  • size (整数):デバイスのサイズ (GB)
  • wwn (文字列): 一意のストレージ ID
  • wwn_with_extension (文字列): ベンダー拡張が末尾に付いたストレージの一意識別子
  • wwn_vendor_extension (文字列): ベンダーのストレージの一意識別子
  • rotational (ブール値): 回転式デバイス (HDD) には true、そうでない場合 (SSD) には false。
  • name: デバイス名 (例: /dev/sdb1)。これは、永続デバイス名が付いたデバイスのみに使用してください。

以下の例では、ディスクのシリアルナンバーの使用して、オーバークラウドイメージをデプロイするルートディスクを指定する方法を説明します。

各ノードのハードウェアイントロスペクションからのディスク情報を確認します。以下のコマンドは、ノードからのディスク情報を表示します。

$ openstack baremetal introspection data save 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 | jq ".inventory.disks"

たとえば、1 つのノードのデータで 3 つのディスクが表示される場合があります。

[
  {
    "size": 299439751168,
    "rotational": true,
    "vendor": "DELL",
    "name": "/dev/sda",
    "wwn_vendor_extension": "0x1ea4dcc412a9632b",
    "wwn_with_extension": "0x61866da04f3807001ea4dcc412a9632b",
    "model": "PERC H330 Mini",
    "wwn": "0x61866da04f380700",
    "serial": "61866da04f3807001ea4dcc412a9632b"
  }
  {
    "size": 299439751168,
    "rotational": true,
    "vendor": "DELL",
    "name": "/dev/sdb",
    "wwn_vendor_extension": "0x1ea4e13c12e36ad6",
    "wwn_with_extension": "0x61866da04f380d001ea4e13c12e36ad6",
    "model": "PERC H330 Mini",
    "wwn": "0x61866da04f380d00",
    "serial": "61866da04f380d001ea4e13c12e36ad6"
  }
  {
    "size": 299439751168,
    "rotational": true,
    "vendor": "DELL",
    "name": "/dev/sdc",
    "wwn_vendor_extension": "0x1ea4e31e121cfb45",
    "wwn_with_extension": "0x61866da04f37fc001ea4e31e121cfb45",
    "model": "PERC H330 Mini",
    "wwn": "0x61866da04f37fc00",
    "serial": "61866da04f37fc001ea4e31e121cfb45"
  }
]

以下の例では、ルートデバイスを、シリアル番号 61866da04f380d001ea4e13c12e36ad6 の disk 2 に設定します。そのためには、ノードの定義に root_device パラメーターを追加する必要があります。

$ openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0

これにより、director がルートディスクとして使用する特定のディスクを識別しやすくなります。オーバークラウドの作成の開始時には、director はこのノードをプロビジョニングして、オーバークラウドのイメージをこのディスクに書き込みます。

注記

各ノードの BIOS を設定して、選択したルートディスクからの起動が含まれるようにします。推奨のブート順は最初がネットワークブートで、次にルートディスクブートです。

重要

name でルートディスクを設定しないでください。この値は、ノードブート時に変更される可能性があります。

5.5. オーバークラウドのカスタマイズ

アンダークラウドには、オーバークラウドの作成プランとして機能する Heat テンプレートセットが含まれます。『オーバークラウドの高度なカスタマイズ』ガイドを使用して、オーバークラウドの詳細機能をカスタマイズできます。

カスタマイズを使用しない場合には、継続して基本的なオーバークラウドをデプロイすることができます。詳しい情報は「CLI ツールでのオーバークラウドの作成」を参照してください。

重要

基本的なオーバークラウドでは、ブロックストレージにローカルの LVM ストレージを使用しますが、この設定はサポートされません。ブロックストレージには、外部ストレージソリューションを使用することを推奨します。

5.6. CLI ツールでのオーバークラウドの作成

OpenStack 環境作成における最後の段階では、openstack overcloud deploy コマンドを実行して OpenStack 環境を作成します。このコマンドを実行する前には、キーのオプションやカスタムの環境ファイルの追加方法を十分に理解しておく必要があります。以下のセクションでは、openstack overcloud deploy コマンドと、それに関連するオプションについて説明します。

警告

バックグラウンドプロセスとして openstack overcloud deploy を実行しないでください。バックグラウンドのプロセスとして開始された場合にはオーバークラウドの作成は途中で停止してしまう可能性があります。

オーバークラウドのパラメーター設定

以下の表では、openstack overcloud deploy コマンドを使用する際の追加パラメーターを一覧表示します。

表5.2 デプロイメントパラメーター

パラメーター説明

--templates [TEMPLATES]

デプロイする Heat テンプレートが格納されているディレクトリー。空欄にした場合には、コマンドはデフォルトのテンプレートの場所である /usr/share/openstack-tripleo-heat-templates/ を使用します。

--stack STACK

作成または更新するスタックの名前

-t [TIMEOUT], --timeout [TIMEOUT]

デプロイメントのタイムアウト (分単位)

--libvirt-type [LIBVIRT_TYPE]

ハイパーバイザーに使用する仮想化タイプ

--ntp-server [NTP_SERVER]

時刻の同期に使用する Network Time Protocol (NTP) サーバー。コンマ区切りリストで複数の NTP サーバーを指定することも可能です (例: --ntp-server 0.centos.pool.org,1.centos.pool.org)。高可用性クラスターのデプロイメントの場合には、コントローラーが一貫して同じタイムソースを参照することが必須となります。標準的な環境には、確立された慣行によって、NTP タイムソースがすでに指定されている可能性がある点に注意してください。

--no-proxy [NO_PROXY]

環境変数 no_proxy のカスタム値を定義します。これにより、プロキシー通信からの特定のドメイン拡張子は除外されます。

--overcloud-ssh-user OVERCLOUD_SSH_USER

オーバークラウドノードにアクセスする SSH ユーザーを定義します。通常、SSH アクセスは heat-admin ユーザーで実行されます。

-e [EXTRA HEAT TEMPLATE], --extra-template [EXTRA HEAT TEMPLATE]

オーバークラウドデプロイメントに渡す追加の環境ファイル。複数回指定することが可能です。openstack overcloud deploy コマンドに渡す環境ファイルの順序が重要である点に注意してください。たとえば、逐次的に渡される各環境ファイルは、前の環境ファイルのパラメーターを上書きします。

--environment-directory

デプロイメントに追加する環境ファイルが格納されているディレクトリー。このコマンドは、これらの環境ファイルを最初に番号順、その後にアルファベット順で処理します。

--validation-errors-nonfatal

オーバークラウドの作成プロセスでは、デプロイメントの前に一連のチェックが行われます。このオプションは、デプロイメント前のチェックで何らかの致命的でないエラーが発生した場合に終了します。どのようなエラーが発生してもデプロイメントが失敗するので、このオプションを使用することを推奨します。

--validation-warnings-fatal

オーバークラウドの作成プロセスでは、デプロイメントの前に一連のチェックが行われます。このオプションは、デプロイメント前のチェックで何らかのクリティカルではない警告が発生した場合に終了します。

--dry-run

オーバークラウドに対する検証チェックを実行しますが、オーバークラウドを実際には作成しません。

--skip-postconfig

オーバークラウドのデプロイ後の設定を省略します。

--force-postconfig

オーバークラウドのデプロイ後の設定を強制的に行います。

--answers-file ANSWERS_FILE

引数とパラメーターが記載された YAML ファイルへのパス

--rhel-reg

カスタマーポータルまたは Satellite 6 にオーバークラウドノードを登録します。

--reg-method

オーバークラウドノードに使用する登録方法。Red Hat Satellite 6 または Red Hat Satellite 5 は satellite、カスタマーポータルは portal です。

--reg-org [REG_ORG]

登録に使用する組織

--reg-force

すでに登録済みでもシステムを登録します。

--reg-sat-url [REG_SAT_URL]

オーバークラウドノードを登録する Satellite サーバーのベース URL。このパラメーターには、HTTPS URL ではなく、Satellite の HTTP URL を使用します。たとえば、https://satellite.example.com ではなく http://satellite.example.com を使用します。オーバークラウドの作成プロセスではこの URL を使用して、どのサーバーが Red Hat Satellite 5 または Red Hat Satellite 6 サーバーであるかを判断します。Red Hat Satellite 6 サーバーの場合は、オーバークラウドは katello-ca-consumer-latest.noarch.rpm ファイルを取得して subscription-manager に登録し、katello-agent をインストールします。Red Hat Satellite 5 サーバーの場合はオーバークラウドは、RHN-ORG-TRUSTED-SSL-CERT ファイルを取得して rhnreg_ks に登録します。

--reg-activation-key [REG_ACTIVATION_KEY]

登録に使用するアクティベーションキー

環境ファイルの parameter_defaults セクションに追加する Heat テンプレートのパラメーターの使用が優先されるため、一部のコマンドラインパラメーターは古いか非推奨となっています。以下の表では、非推奨となったパラメーターと、それに相当する Heat テンプレートのパラメーターを対照しています。

表5.3 非推奨の CLI パラメーターと Heat テンプレートのパラメーターの対照表

パラメーター説明Heat テンプレートのパラメーター

--control-scale

スケールアウトするコントローラーノード数

ControllerCount

--compute-scale

スケールアウトするコンピュートノード数

ComputeCount

--ceph-storage-scale

スケールアウトする Ceph Storage ノードの数

CephStorageCount

--block-storage-scale

スケールアウトする Cinder ノード数

BlockStorageCount

--swift-storage-scale

スケールアウトする Swift ノード数

ObjectStorageCount

--control-flavor

コントローラーノードに使用するフレーバー

OvercloudControlFlavor

--compute-flavor

コンピュートノードに使用するフレーバー

OvercloudComputeFlavor

--ceph-storage-flavor

Ceph Storage ノードに使用するフレーバー

OvercloudCephStorageFlavor

--block-storage-flavor

Cinder ノードに使用するフレーバー

OvercloudBlockStorageFlavor

--swift-storage-flavor

Swift Storage ノードに使用するフレーバー

OvercloudSwiftStorageFlavor

--neutron-flat-networks

フラットなネットワークが neutron プラグインで設定されるように定義します。外部ネットワークを作成ができるようにデフォルトは「datacentre」に設定されています。

NeutronFlatNetworks

--neutron-physical-bridge

各ハイパーバイザーで作成する Open vSwitch ブリッジ。デフォルト値は「br-ex」で、通常この値は変更する必要はないはずです。

HypervisorNeutronPhysicalBridge

--neutron-bridge-mappings

使用する論理ブリッジから物理ブリッジへのマッピング。ホスト (br-ex) の外部ブリッジを物理名 (datacentre) にマッピングするようにデフォルト設定されています。これは、デフォルトの Floating ネットワークに使用されます。

NeutronBridgeMappings

--neutron-public-interface

ネットワークノード向けにインターフェースを br-ex にブリッジするインターフェースを定義します。

NeutronPublicInterface

--neutron-network-type

Neutron のテナントネットワーク種別

NeutronNetworkType

--neutron-tunnel-types

neutron テナントネットワークのトンネリング種別。複数の値を指定するには、コンマ区切りの文字列を使用します。

NeutronTunnelTypes

--neutron-tunnel-id-ranges

テナントネットワークを割り当てに使用できる GRE トンネリングの ID 範囲

NeutronTunnelIdRanges

--neutron-vni-ranges

テナントネットワークを割り当てに使用できる VXLAN VNI の ID 範囲

NeutronVniRanges

--neutron-network-vlan-ranges

サポートされる Neutron ML2 および Open vSwitch VLAN マッピングの範囲。デフォルトでは、物理ネットワーク「datacentre」上の VLAN を許可するように設定されています。

NeutronNetworkVLANRanges

--neutron-mechanism-drivers

neutron テナントネットワークのメカニズムドライバー。デフォルトでは、「openvswitch」に設定されており、複数の値を指定するにはコンマ区切りの文字列を使用します。

NeutronMechanismDrivers

--neutron-disable-tunneling

VLAN で区切られたネットワークまたは neutron でのフラットネットワークを使用するためにトンネリングを無効化します。

パラメーターのマッピングなし

--validation-errors-fatal

オーバークラウドの作成プロセスでは、デプロイメントの前に一連のチェックが行われます。このオプションは、デプロイメント前のチェックで何らかの致命的なエラーが発生した場合に終了します。どのようなエラーが発生してもデプロイメントが失敗するので、このオプションを使用することを推奨します。

パラメーターのマッピングなし

これらのパラメーターは、Red Hat OpenStack Platform の今後のリリースで削除される予定です。

注記

オプションの完全一覧については、以下のコマンドを実行します。

$ openstack help overcloud deploy

5.7. オーバークラウド作成時の環境ファイルの追加

オーバークラウドをカスタマイズするには、-e を指定して、環境ファイルを追加します。必要に応じていくつでも環境ファイルを追加することができますが、後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順番は重要です。以下の一覧は、環境ファイルの順序の例です。

  • 各ロールおよびそのフレーバーごとのノード数。オーバークラウドを作成するには、この情報の追加は不可欠です。
  • 任意のネットワーク分離ファイル。Heat テンプレートコレクションの初期化ファイル (environments/network-isolation.yaml) から開始して、次にカスタムの NIC 設定ファイル、最後に追加のネットワーク設定の順番です。
  • 外部のロードバランシングの環境ファイル
  • Ceph Storage、NFS、iSCSI などのストレージ環境ファイル
  • Red Hat CDN または Satellite 登録用の環境ファイル
  • その他のカスタム環境ファイル

-e オプションを使用してオーバークラウドに追加した環境ファイルはいずれも、オーバークラウドのスタック定義の一部となります。以下のコマンドは、追加するカスタム環境ファイルを使用してオーバークラウドの作成を開始する方法の一例です。

$ openstack overcloud deploy --templates \
  -e ~/templates/node-info.yaml\
  -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
  -e ~/templates/network-environment.yaml \
  -e ~/templates/storage-environment.yaml \
  --ntp-server pool.ntp.org \

このコマンドでは、以下の追加オプションも使用できます。

  • --templates: /usr/share/openstack-tripleo-heat-templates の Heat テンプレートコレクションを使用してオーバークラウドを作成します。
  • -e ~/templates/node-info.yaml: -e オプションは、オーバークラウドデプロイメントに別の環境ファイルを追加します。この場合は、各ロールに使用するノード数とフレーバーを定義するカスタムの環境ファイルです。以下に例を示します。

    parameter_defaults:
      OvercloudControlFlavor: control
      OvercloudComputeFlavor: compute
      OvercloudCephStorageFlavor: ceph-storage
      ControllerCount: 3
      ComputeCount: 3
      CephStorageCount: 3
  • -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml: -e オプションは、オーバークラウドデプロイメントに別の環境ファイルを追加します。この場合は、ネットワーク分離の設定を初期化する環境ファイルです。
  • -e ~/templates/network-environment.yaml: -e オプションは、オーバークラウドデプロイメントに別の環境ファイルを追加します。今回は、ネットワーク分離のカスタマイズが含まれるネットワーク環境ファイルです。
  • -e ~/templates/storage-environment.yaml: -e オプションは、オーバークラウドデプロイメントに別の環境ファイルを追加します。この場合は、ストレージの設定を初期化する環境ファイルです。
  • --ntp-server pool.ntp.org: 時刻の同期に NTP サーバーを使用します。これは、コントローラーノードクラスターの同期を保つ際に便利です。

director は、「7章オーバークラウド作成後のタスクの実行」に記載の再デプロイおよびデプロイ後の機能にこれらの環境ファイルを必要とします。これらのファイルが含まれていない場合には、オーバークラウドが破損する可能性があります。

オーバークラウド設定を後で変更する予定の場合には、以下の作業を行う必要があります。

  1. カスタムの環境ファイルおよび Heat テンプレートのパラメーターを変更します。
  2. 同じ環境ファイルを指定してopenstack overcloud deploy コマンドを再度実行します。

オーバークラウドを手動で編集しても、director を使用してオーバークラウドスタックの更新を行う際に director の設定で上書きされてしまうので、設定は直接編集しないでください。

環境ファイルディレクトリーの追加

--environment-directory オプションを使用して、環境ファイルを格納しているディレクトリー全体を追加することも可能です。デプロイメントコマンドにより、このディレクトリー内の環境ファイルは、最初に番号順、その後にアルファベット順で処理されます。この方法を使用する場合には、ファイル名に数字のプレフィックスを使用することを推奨します。以下に例を示します。

$ ls -1 ~/templates
00-node-info.yaml
10-network-isolation.yaml
20-network-environment.yaml
30-storage-environment.yaml
40-rhel-registration.yaml

以下のデプロイメントコマンドを実行してディレクトリーを追加します。

$ openstack overcloud deploy --templates --environment-directory ~/templates

回答ファイルの使用

回答ファイルは、テンプレートおよび環境ファイルの追加を簡素化する YAML ファイルです。回答ファイルでは、以下のパラメーターを使用します。

テンプレート
使用するコア Heat テンプレートコレクション。これは、--templates のコマンドラインオプションの代わりとして機能します。
環境
追加する環境ファイルの一覧。これは、--environment-file (-e) のコマンドラインオプションの代わりとして機能します。

たとえば、回答ファイルには以下の内容を含めることができます。

templates: /usr/share/openstack-tripleo-heat-templates/
environments:
  - ~/templates/00-node-info.yaml
  - ~/templates/10-network-isolation.yaml
  - ~/templates/20-network-environment.yaml
  - ~/templates/30-storage-environment.yaml
  - ~/templates/40-rhel-registration.yaml

以下のデプロイメントコマンドを実行して回答ファイルを追加します。

$ openstack overcloud deploy --answers-file ~/answers.yaml

5.8. オーバークラウドプランの管理

openstack overcloud deploy コマンドを使用する代わりに、director を使用してインポートしたプランを管理することもできます。

新規プランを作成するには、以下のコマンドを stack ユーザーとして実行します。

$ openstack overcloud plan create --templates /usr/share/openstack-tripleo-heat-templates my-overcloud

このコマンドは、/usr/share/openstack-tripleo-heat-templates 内のコア Heat テンプレートコレクションからプランを作成します。director は、入力内容に基づいてプランに名前を指定します。この例では、my-overcloud という名前です。director は、この名前をオブジェクトストレージコンテナー、ワークフロー環境、オーバークラウドスタック名のラベルとして使用します。

以下のコマンドを使用して環境ファイルからパラメーターを追加します。

$ openstack overcloud parameters set my-overcloud ~/templates/my-environment.yaml

以下のコマンドを使用してプランをデプロイします。

$ openstack overcloud plan deploy my-overcloud

以下のコマンドを使用して既存のプランを削除します。

$ openstack overcloud plan delete my-overcloud
注記

openstack overcloud deploy コマンドは基本的に、これらのコマンドをすべて使用して既存のプランの削除、環境ファイルを使用した新規プランのアップロード、プランのデプロイを行います。

5.9. オーバークラウドのテンプレートおよびプランの検証

オーバークラウドの作成またはスタックの更新を実行する前に、Heat テンプレートと環境ファイルにエラーがないかどうかを検証します。

レンダリングされたテンプレートの作成

オーバークラウドのコア Heat テンプレートは、Jinja2 形式となっています。テンプレートを検証するには、以下のコマンドを使用して Jinja 2 のフォーマットなしでバージョンをレンダリングします。

$ openstack overcloud plan create --templates /usr/share/openstack-tripleo-heat-templates overcloud-validation
$ mkdir ~/overcloud-validation
$ cd ~/overcloud-validation
$ swift download overcloud-validation

その後の検証テストには ~/overcloud-validation のレンダリング済みテンプレートを使用します。

テンプレート構文の検証

以下のコマンドを使用して、テンプレート構文を検証します。

$ openstack orchestration template validate --show-nested --template ~/overcloud-validation/overcloud.yaml -e ~/overcloud-validation/overcloud-resource-registry-puppet.yaml -e [ENVIRONMENT FILE] -e [ENVIRONMENT FILE]
注記

検証には、overcloud-resource-registry-puppet.yaml の環境ファイルにオーバークラウド固有のリソースを含める必要があります。環境ファイルをさらに追加するには、このコマンドに -e オプションを使用してください。また、--show-nested オプションを追加して、ネストされたテンプレートからパラメーターを解決します。

このコマンドは、テンプレート内の構文エラーを特定します。テンプレートの構文の検証が正常に行われた場合には、出力には、作成されるオーバークラウドのテンプレートのプレビューが表示されます。

5.10. オーバークラウド作成の監視

オーバークラウドの作成プロセスが開始され、director によりノードがプロビジョニングされます。このプロセスは完了するまで多少時間がかかります。オーバークラウドの作成のステータスを確認するには、stack ユーザーとして別のターミナルを開き、以下のコマンドを実行します。

$ source ~/stackrc
$ openstack stack list --nested

openstack stack list --nested コマンドは、オーバークラウド作成の現在の段階を表示します。

5.11. オーバークラウドへのアクセス

director は、director ホストからオーバークラウドに対話するための設定を行い、認証をサポートするスクリプトを作成して、stack ユーザーのホームディレクトリーにこのファイル (overcloudrc) を保存します。このファイルを使用するには、以下のコマンドを実行します。

$ source ~/overcloudrc

これで、director のホストの CLI からオーバークラウドと対話するために必要な環境変数が読み込まれます。director のホストとの対話に戻るには、以下のコマンドを実行します。

$ source ~/stackrc

オーバークラウドの各ノードには、heat-admin と呼ばれるユーザーが含まれます。stack ユーザーには、各ノードに存在するこのユーザーに SSH 経由でアクセスすることができます。SSH でノードにアクセスするには、希望のノードの IP アドレスを特定します。

$ nova list

次に、heat-admin ユーザーとノードの IP アドレスを使用して、ノードに接続します。

$ ssh heat-admin@192.0.2.23

5.12. オーバークラウド作成の完了

これで、コマンドラインツールを使用したオーバークラウドの作成が完了しました。作成後の機能については、「7章オーバークラウド作成後のタスクの実行」を参照してください。


このページには機械翻訳が使用されている場合があります (詳細はこちら)。