Red Hat Training
A Red Hat training course is available for Red Hat OpenStack Platform
第6章 CLI ツールを使用した基本的なオーバークラウドの設定
本章では、CLI ツールを使用した OpenStack Platform 環境の基本的な設定手順を説明します。基本設定のオーバークラウドには、カスタムの機能は含まれていませんが、『オーバークラウドの高度なカスタマイズ』ガイドに記載の手順に従って、この基本的なオーバークラウドに高度な設定オプションを追加して、仕様に合わせてカスタマイズすることができます。
本章の例では、すべてのノードが電源管理に IPMI を使用したベアメタルシステムとなっています。電源管理の種別およびそのオプションに関する詳細は、「付録B 電源管理ドライバー」を参照してください。
ワークフロー
- ノード定義のテンプレートを作成して director で空のノードを登録します。
- 全ノードのハードウェアを検査します。
- ロールにノードをタグ付けします。
- 追加のノードプロパティーを定義します。
要件
- 「4章アンダークラウドのインストール」で作成した director ノード
- ノードに使用するベアメタルマシンのセット。必要なノード数は、作成予定のオーバークラウドのタイプにより異なります (オーバークラウドロールに関する情報は「ノードのデプロイメントロールのプランニング」を参照してください)。これらのマシンは、各ノード種別の要件セットに従う必要があります。これらの要件については、「オーバークラウドの要件」を参照してください。これらのノードにはオペレーティングシステムは必要ありません。director が Red Hat Enterprise Linux 7 のイメージを各ノードにコピーします。
ネイティブ VLAN として設定したプロビジョニングネットワーク用のネットワーク接続 1 つ。全ノードは、このネイティブに接続して、「ネットワーク要件」で設定した要件に準拠する必要があります。この章の例では、以下の IP アドレスの割り当てで、プロビジョニングサブネットとして 192.168.24.0/24 を使用します。
表6.1 プロビジョニングネットワークの IP 割り当て
ノード名
IP アドレス
MAC アドレス
IPMI IP アドレス
director
192.168.24.1
aa:aa:aa:aa:aa:aa
不要
コントローラー
定義済みの DHCP
bb:bb:bb:bb:bb:bb
192.168.24.205
Compute
定義済みの DHCP
cc:cc:cc:cc:cc:cc
192.168.24.206
- その他のネットワーク種別はすべて、OpenStack サービスにプロビジョニングネットワークを使用しますが、ネットワークトラフィックの他のタイプに追加でネットワークを作成することができます。
- コンテナーイメージのソース。コンテナーイメージのソースを含む環境ファイルの生成方法については、「5章コンテナーレジストリー情報の設定」を参照してください。
6.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.168.24.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.168.24.206" } ] }
このテンプレートでは、以下の属性を使用します。
- name
- ノードの論理名
- 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 にインポートします。
$ source ~/stackrc (undercloud) $ openstack overcloud node import ~/instackenv.json
このコマンドでテンプレートをインポートして、テンプレートから director に各ノードを登録します。
ノードを登録して設定が完了した後に、CLI でこれらのノードの一覧を表示します。
(undercloud) $ openstack baremetal node list
6.2. ノードのハードウェアの検査
director は各ノードでイントロスペクションプロセスを実行することができます。このプロセスを実行すると、各ノードが PXE を介してイントロスペクションエージェントを起動します。このエージェントは、ノードからハードウェアのデータを収集して、director に送り返します。次に director は、director 上で実行中の OpenStack Object Storage (swift) サービスにこのイントロスペクションデータを保管します。director は、プロファイルのタグ付け、ベンチマーキング、ルートディスクの手動割り当てなど、さまざまな目的でハードウェア情報を使用します。
ポリシーファイルを作成して、イントロスペクションの直後にノードをプロファイルに自動でタグ付けすることも可能です。ポリシーファイルを作成してイントロスペクションプロセスに組み入れる方法に関する詳しい情報は、「付録E プロファイルの自動タグ付け」を参照してください。または、「プロファイルへのノードのタグ付け」に記載の手順に従って、ノードをプロファイルに手動でタグ付けすることもできます。
以下のコマンドを実行して、各ノードのハードウェア属性を検証します。
(undercloud) $ openstack overcloud node introspect --all-manageable --provide
-
--all-manageable
オプションは、管理状態のノードのみをイントロスペクションします。上記の例では、すべてのノードが対象です。 -
--provide
オプションは、イントロスペクション後に全ノードをavailable
の状態にします。
別のターミナルウィンドウで以下のコマンドを使用してイントロスペクションの進捗状況をモニタリングします。
(undercloud) $ sudo journalctl -l -u openstack-ironic-inspector -u openstack-ironic-inspector-dnsmasq -u openstack-ironic-conductor -f
このプロセスが最後まで実行されて正常に終了したことを確認してください。ベアメタルの場合には、通常 15 分ほどかかります。
イントロスペクション完了後には、すべてのノードが available
の状態に変わります。
ノードイントロスペクションの個別実行
available
の状態のノードで個別にイントロスペクションを実行するには、ノードを管理モードに設定して、イントロスペクションを実行します。
(undercloud) $ openstack baremetal node manage [NODE UUID] (undercloud) $ openstack overcloud node introspect [NODE UUID] --provide
イントロスペクションが完了すると、ノードは available
の状態に変わります。
初回のイントロスペクション後のノードイントロスペクションの実行
--provide
オプションを指定したので、初回のイントロスペクションの後には、全ノードが available
の状態に入るはずです。初回のイントロスペクション後に全ノードにイントロスペクションを実行するには、すべてのノードを manageable
の状態にして、一括のイントロスペクションコマンドを実行します。
(undercloud) $ for node in $(openstack baremetal node list --fields uuid -f value) ; do openstack baremetal node manage $node ; done (undercloud) $ openstack overcloud node introspect --all-manageable --provide
イントロスペクション完了後には、すべてのノードが available
の状態に変わります。
ネットワークイントロスペクションの実行によるインターフェース情報の取得
ネットワークイントロスペクションにより、Link Layer Discovery Protocol (LLDP) データがネットワークスイッチから取得されます。以下のコマンドにより、ノード上の全インターフェースに関する LLDP 情報のサブセット、または特定のノードおよびインターフェースに関するすべての情報が表示されます。この情報は、トラブルシューティングに役立ちます。director では、デフォルトで LLDP データ収集が有効になっています。
ノード上のインターフェースのリストを取得するには、以下のコマンドを実行します。
(undercloud) $ openstack baremetal introspection interface list [NODE UUID]
例:
(undercloud) $ openstack baremetal introspection interface list c89397b7-a326-41a0-907d-79f8b86c7cd9 +-----------+-------------------+------------------------+-------------------+----------------+ | Interface | MAC Address | Switch Port VLAN IDs | Switch Chassis ID | Switch Port ID | +-----------+-------------------+------------------------+-------------------+----------------+ | p2p2 | 00:0a:f7:79:93:19 | [103, 102, 18, 20, 42] | 64:64:9b:31:12:00 | 510 | | p2p1 | 00:0a:f7:79:93:18 | [101] | 64:64:9b:31:12:00 | 507 | | em1 | c8:1f:66:c7:e8:2f | [162] | 08:81:f4:a6:b3:80 | 515 | | em2 | c8:1f:66:c7:e8:30 | [182, 183] | 08:81:f4:a6:b3:80 | 559 | +-----------+-------------------+------------------------+-------------------+----------------+
インターフェースのデータおよびスイッチポートの情報を表示するには、以下のコマンドを実行します。
(undercloud) $ openstack baremetal introspection interface show [NODE UUID] [INTERFACE]
例:
(undercloud) $ openstack baremetal introspection interface show c89397b7-a326-41a0-907d-79f8b86c7cd9 p2p1 +--------------------------------------+------------------------------------------------------------------------------------------------------------------------+ | Field | Value | +--------------------------------------+------------------------------------------------------------------------------------------------------------------------+ | interface | p2p1 | | mac | 00:0a:f7:79:93:18 | | node_ident | c89397b7-a326-41a0-907d-79f8b86c7cd9 | | switch_capabilities_enabled | [u'Bridge', u'Router'] | | switch_capabilities_support | [u'Bridge', u'Router'] | | switch_chassis_id | 64:64:9b:31:12:00 | | switch_port_autonegotiation_enabled | True | | switch_port_autonegotiation_support | True | | switch_port_description | ge-0/0/2.0 | | switch_port_id | 507 | | switch_port_link_aggregation_enabled | False | | switch_port_link_aggregation_id | 0 | | switch_port_link_aggregation_support | True | | switch_port_management_vlan_id | None | | switch_port_mau_type | Unknown | | switch_port_mtu | 1514 | | switch_port_physical_capabilities | [u'1000BASE-T fdx', u'100BASE-TX fdx', u'100BASE-TX hdx', u'10BASE-T fdx', u'10BASE-T hdx', u'Asym and Sym PAUSE fdx'] | | switch_port_protocol_vlan_enabled | None | | switch_port_protocol_vlan_ids | None | | switch_port_protocol_vlan_support | None | | switch_port_untagged_vlan_id | 101 | | switch_port_vlan_ids | [101] | | switch_port_vlans | [{u'name': u'RHOS13-PXE', u'id': 101}] | | switch_protocol_identities | None | | switch_system_name | rhos-compute-node-sw1 | +--------------------------------------+------------------------------------------------------------------------------------------------------------------------+
ハードウェアイントロスペクション情報の取得
Bare Metal サービスでは、ハードウェア検査時に追加のハードウェア情報を取得するためのパラメーター (inspection_extras) がデフォルトで有効になっています。これらのハードウェア情報を使って、オーバークラウドを設定することができます。undercloud.conf
ファイルの inspection_extras パラメーターに関する詳細は、「director の設定」を参照してください。
たとえば、numa_topology コレクターは、このハードウェア inspection_extras の一部で、各 NUMA ノードに関する以下の情報が含まれます。
- RAM (キロバイト単位)
- 物理 CPU コアおよびそのシブリングスレッド
- NUMA ノードに関連付けられた NIC
この情報を取得するには、ベアメタルノードの UUID を指定して、openstack baremetal introspection data save _UUID_ | jq .numa_topology
コマンドを実行します。
取得されるベアメタルノードの NUMA 情報の例を、以下に示します。
{ "cpus": [ { "cpu": 1, "thread_siblings": [ 1, 17 ], "numa_node": 0 }, { "cpu": 2, "thread_siblings": [ 10, 26 ], "numa_node": 1 }, { "cpu": 0, "thread_siblings": [ 0, 16 ], "numa_node": 0 }, { "cpu": 5, "thread_siblings": [ 13, 29 ], "numa_node": 1 }, { "cpu": 7, "thread_siblings": [ 15, 31 ], "numa_node": 1 }, { "cpu": 7, "thread_siblings": [ 7, 23 ], "numa_node": 0 }, { "cpu": 1, "thread_siblings": [ 9, 25 ], "numa_node": 1 }, { "cpu": 6, "thread_siblings": [ 6, 22 ], "numa_node": 0 }, { "cpu": 3, "thread_siblings": [ 11, 27 ], "numa_node": 1 }, { "cpu": 5, "thread_siblings": [ 5, 21 ], "numa_node": 0 }, { "cpu": 4, "thread_siblings": [ 12, 28 ], "numa_node": 1 }, { "cpu": 4, "thread_siblings": [ 4, 20 ], "numa_node": 0 }, { "cpu": 0, "thread_siblings": [ 8, 24 ], "numa_node": 1 }, { "cpu": 6, "thread_siblings": [ 14, 30 ], "numa_node": 1 }, { "cpu": 3, "thread_siblings": [ 3, 19 ], "numa_node": 0 }, { "cpu": 2, "thread_siblings": [ 2, 18 ], "numa_node": 0 } ], "ram": [ { "size_kb": 66980172, "numa_node": 0 }, { "size_kb": 67108864, "numa_node": 1 } ], "nics": [ { "name": "ens3f1", "numa_node": 1 }, { "name": "ens3f0", "numa_node": 1 }, { "name": "ens2f0", "numa_node": 0 }, { "name": "ens2f1", "numa_node": 0 }, { "name": "ens1f1", "numa_node": 0 }, { "name": "ens1f0", "numa_node": 0 }, { "name": "eno4", "numa_node": 0 }, { "name": "eno1", "numa_node": 0 }, { "name": "eno3", "numa_node": 0 }, { "name": "eno2", "numa_node": 0 } ] }
6.3. ベアメタルノードの自動検出
auto-discovery を使用すると、最初に instackenv.json
ファイルを作成せずに、アンダークラウドノードを登録してそのメタデータを生成することができます。この改善により、最初のノード情報取得に費す時間を短縮できます。たとえば、IPMI IP アドレスを照合し、その後に instackenv.json
ファイルを作成する必要がなくなります。
要件
- すべてのオーバークラウドノードの BMC が、IPMI を通じて director にアクセスできるように設定されていること
- すべてのオーバークラウドノードが、アンダークラウドのコントロールプレーンネットワークに接続された NIC から PXE ブートするように設定されていること
自動検出の有効化
undercloud.conf
でベアメタルの自動検出を有効にします。enable_node_discovery = True discovery_default_driver = pxe_ipmitool
-
enable_node_discovery
: 有効にすると、PXE を使ってイントロスペクション ramdisk をブートするすべてのノードが Ironic に登録されます。 -
discovery_default_driver
: 検出されたノードに使用するドライバーを設定します。例:pxe_ipmitool
-
IPMI の認証情報を Ironic に追加します。
IPMI の認証情報を
ipmi-credentials.json
という名前のファイルに追加します。以下の例で使用しているユーザー名とパスワードの値は、お使いの環境に応じて置き換える必要があります。[ { "description": "Set default IPMI credentials", "conditions": [ {"op": "eq", "field": "data://auto_discovered", "value": true} ], "actions": [ {"action": "set-attribute", "path": "driver_info/ipmi_username", "value": "SampleUsername"}, {"action": "set-attribute", "path": "driver_info/ipmi_password", "value": "RedactedSecurePassword"}, {"action": "set-attribute", "path": "driver_info/ipmi_address", "value": "{data[inventory][bmc_address]}"} ] } ]
IPMI の認証情報ファイルを Ironic にインポートします。
$ openstack baremetal introspection rule import ipmi-credentials.json
自動検出のテスト
- 必要なノードの電源をオンにします。
openstack baremetal node list
を実行します。新しいノードがenroll
の状態でリストに表示されるはずです。$ openstack baremetal node list +--------------------------------------+------+---------------+-------------+--------------------+-------------+ | UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance | +--------------------------------------+------+---------------+-------------+--------------------+-------------+ | c6e63aec-e5ba-4d63-8d37-bd57628258e8 | None | None | power off | enroll | False | | 0362b7b2-5b9c-4113-92e1-0b34a2535d9b | None | None | power off | enroll | False | +--------------------------------------+------+---------------+-------------+--------------------+-------------+
各ノードにリソースクラスを設定します。
$ for NODE in `openstack baremetal node list -c UUID -f value` ; do openstack baremetal node set $NODE --resource-class baremetal ; done
各ノードにカーネルと ramdisk を設定します。
$ for NODE in `openstack baremetal node list -c UUID -f value` ; do openstack baremetal node manage $NODE ; done $ openstack overcloud node configure --all-manageable
全ノードを利用可能な状態に設定します。
$ for NODE in `openstack baremetal node list -c UUID -f value` ; do openstack baremetal node provide $NODE ; done
ルールを使用して異なるベンダーのハードウェアを検出する方法
異種のハードウェアが混在する環境では、イントロスペクションルールを使って、認証情報の割り当てやリモート管理を行うことができます。たとえば、DRAC を使用する Dell ノードを処理するには、別の検出ルールが必要になる場合があります。
以下の内容で、
dell-drac-rules.json
という名前のファイルを作成します。この例で使用しているユーザー名およびパスワードの値は、お使いの環境に応じて置き換える必要があります。[ { "description": "Set default IPMI credentials", "conditions": [ {"op": "eq", "field": "data://auto_discovered", "value": true}, {"op": "ne", "field": "data://inventory.system_vendor.manufacturer", "value": "Dell Inc."} ], "actions": [ {"action": "set-attribute", "path": "driver_info/ipmi_username", "value": "SampleUsername"}, {"action": "set-attribute", "path": "driver_info/ipmi_password", "value": "RedactedSecurePassword"}, {"action": "set-attribute", "path": "driver_info/ipmi_address", "value": "{data[inventory][bmc_address]}"} ] }, { "description": "Set the vendor driver for Dell hardware", "conditions": [ {"op": "eq", "field": "data://auto_discovered", "value": true}, {"op": "eq", "field": "data://inventory.system_vendor.manufacturer", "value": "Dell Inc."} ], "actions": [ {"action": "set-attribute", "path": "driver", "value": "idrac"}, {"action": "set-attribute", "path": "driver_info/drac_username", "value": "SampleUsername"}, {"action": "set-attribute", "path": "driver_info/drac_password", "value": "RedactedSecurePassword"}, {"action": "set-attribute", "path": "driver_info/drac_address", "value": "{data[inventory][bmc_address]}"} ] } ]
ルールを Ironic にインポートします。
$ openstack baremetal introspection rule import dell-drac-rules.json
6.4. プロファイルへのノードのタグ付け
各ノードのハードウェアを登録、検査した後には、特定のプロファイルにノードをタグ付けします。このプロファイルタグにより、ノードがフレーバーに照合され、次にそのフレーバーがデプロイメントロールに割り当てられます。以下の例では、コントローラーノードのロール、フレーバー、プロファイル、ノード間の関係を示しています。
タイプ | 説明 |
---|---|
ロール |
|
フレーバー |
|
プロファイル |
|
ノード |
また、各ノードに |
アンダークラウドのインストール時に、デフォルトプロファイルのフレーバー compute
、control
、swift-storage
、ceph-storage
、block-storage
が作成され、大半の環境で変更なしに使用することができます。
多くのノードでは、プロファイルの自動タグ付けを使用します。詳しい情報は、「付録E プロファイルの自動タグ付け」を参照してください。
特定のプロファイルにノードをタグ付けする場合には、各ノードの properties/capabilities
パラメーターに profile
オプションを追加します。たとえば、2 つのノードをタグ付けしてコントローラープロファイルとコンピュートプロファイルをそれぞれ使用するには、以下のコマンドを実行します。
(undercloud) $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13 (undercloud) $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
profile:compute
と profile:control
オプションを追加することで、この 2 つのノードがそれぞれのプロファイルにタグ付けされます。
これらのコマンドは、各ノードのブート方法を定義する boot_option:local
パラメーターも設定します。お使いのハードウェアによっては、boot_mode
パラメーターを uefi
に追加して、ノードが BIOS モードの代わりに UEFI を使用してブートするようにする必要がある場合もあります。詳しい情報は、「UEFI ブートモード」を参照してください。
ノードのタグ付けが完了した後には、割り当てたプロファイルまたはプロファイルの候補を確認します。
(undercloud) $ openstack overcloud profiles list
カスタムロールのプロファイル
カスタムロールを使用する場合には、これらの新規ロールに対応するために追加のフレーバーやプロファイルを作成する必要があるかもしれません。たとえば、Networker ロールの新規フレーバーを作成するには、以下のコマンドを実行します。
(undercloud) $ openstack flavor create --id auto --ram 4096 --disk 40 --vcpus 1 networker (undercloud) $ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="networker" networker
この新規プロファイルにノードを割り当てます。
(undercloud) $ openstack baremetal node set --property capabilities='profile:networker,boot_option:local' dad05b82-0c74-40bf-9d12-193184bfc72d
6.5. ノードのルートディスクの定義
一部のノードは、複数のディスクを使用する場合があります。このため、director はプロビジョニング中に、ルートディスクに使用するディスクを特定する必要があります。
director がルートディスクを容易に特定できるようにするには、以下のようなプロパティーを使用することができます。
-
model
(文字列): デバイスの ID -
vendor
(文字列): デバイスのベンダー -
serial
(文字列): ディスクのシリアル番号 -
hctl
(文字列): SCSI のホスト:チャネル:ターゲット:Lun -
size
(整数):デバイスのサイズ (GB) -
wwn
(文字列): ストレージの一意識別子 -
wwn_with_extension
(文字列): ベンダー拡張が末尾に付いたストレージの一意識別子 -
wwn_vendor_extension
(文字列): ベンダーのストレージの一意識別子 -
rotational
(ブール値): 回転式デバイス (HDD) には true、そうでない場合 (SSD) には false。 -
name
(文字列): デバイス名 (例: /dev/sdb1)
name
は、永続デバイス名が付いたデバイスのみに使用します。name
で他のデバイスのルートディスクを設定しないでください。この値は、ノードのブート時に変更される可能性があります。
以下の例では、root デバイスを特定するディスクのシリアル番号を使用して、オーバークラウドイメージをデプロイするドライブを指定します。
各ノードのハードウェアイントロスペクションからのディスク情報を確認します。以下のコマンドは、ノードからのディスク情報を表示します。
(undercloud) $ 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
パラメーターを追加する必要があります。
(undercloud) $ openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
各ノードの BIOS を設定して、選択したルートディスクからの起動が含まれるようにします。推奨のブート順は最初がネットワークブートで、次にルートディスクブートです。
これにより、director がルートディスクとして使用する特定のディスクを識別しやすくなります。オーバークラウドの作成の開始時には、director はこのノードをプロビジョニングして、オーバークラウドのイメージをこのディスクに書き込みます。
6.6. 環境ファイルを使用したオーバークラウドのカスタマイズ
アンダークラウドには、オーバークラウドの作成プランとして機能するさまざまな Heat テンプレートが含まれます。YAML フォーマットの環境ファイルを使って、オーバークラウドの特性をカスタマイズすることができます。このファイルで、コア Heat テンプレートコレクションのパラメーターおよびリソースを上書きします。必要に応じていくつでも環境ファイルを追加することができますが、後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順番は重要です。以下の一覧は、環境ファイルの順序の例です。
- 各ロールおよびそのフレーバーごとのノード数。オーバークラウドを作成するには、この情報の追加は不可欠です。
- コンテナー化された OpenStack サービスのコンテナーイメージの場所。このファイルは、「5章コンテナーレジストリー情報の設定」で説明したオプションのいずれかで作成されたものです。
-
任意のネットワーク分離ファイル。Heat テンプレートコレクションの初期化ファイル (
environments/network-isolation.yaml
) から開始して、次にカスタムの NIC 設定ファイル、最後に追加のネットワーク設定の順番です。 - 外部のロードバランシングの環境ファイル
- Ceph Storage、NFS、iSCSI などのストレージ環境ファイル
- Red Hat CDN または Satellite 登録用の環境ファイル
- その他のカスタム環境ファイル
カスタム環境ファイルは、別のディレクトリーで管理することを推奨します (たとえば、templates
ディレクトリー)。
『オーバークラウドの高度なカスタマイズ』ガイドを使用して、オーバークラウドの詳細機能をカスタマイズできます。
基本的なオーバークラウドでは、ブロックストレージにローカルの LVM ストレージを使用しますが、この設定はサポートされません。ブロックストレージには、外部ストレージソリューション (Red Hat Ceph Storage 等) を使用することを推奨します。
6.7. CLI ツールを使用したオーバークラウドの作成
OpenStack 環境作成における最後の段階では、openstack overcloud deploy
コマンドを実行して OpenStack 環境を作成します。このコマンドを実行する前に、キーオプションやカスタムの環境ファイルの追加方法を十分に理解しておく必要があります。
バックグラウンドプロセスとして openstack overcloud deploy
を実行しないでください。バックグラウンドのプロセスとして開始された場合にはオーバークラウドの作成は途中で停止してしまう可能性があります。
オーバークラウドのパラメーター設定
以下の表では、openstack overcloud deploy
コマンドを使用する際の追加パラメーターを一覧表示します。
表6.2 デプロイメントパラメーター
パラメーター | 説明 |
---|---|
|
デプロイする Heat テンプレートが格納されているディレクトリー。空欄にした場合には、コマンドはデフォルトのテンプレートの場所である |
|
作成または更新するスタックの名前 |
|
デプロイメントのタイムアウト (分単位) |
|
ハイパーバイザーに使用する仮想化タイプ |
|
時刻の同期に使用する Network Time Protocol (NTP) サーバー。コンマ区切りリストで複数の NTP サーバーを指定することも可能です (例: |
|
環境変数 no_proxy のカスタム値を定義します。これにより、プロキシー通信から特定のホスト名は除外されます。 |
|
オーバークラウドノードにアクセスする SSH ユーザーを定義します。通常、SSH アクセスは |
|
オーバークラウドデプロイメントに渡す追加の環境ファイル。複数回指定することが可能です。 |
|
デプロイメントに追加する環境ファイルが格納されているディレクトリー。このコマンドは、これらの環境ファイルを最初に番号順、その後にアルファベット順で処理します。 |
|
オーバークラウドの作成プロセスでは、デプロイメントの前に一連のチェックが行われます。このオプションは、デプロイメント前のチェックで何らかの致命的でないエラーが発生した場合に終了します。どのようなエラーが発生してもデプロイメントが失敗するので、このオプションを使用することを推奨します。 |
|
オーバークラウドの作成プロセスでは、デプロイメントの前に一連のチェックが行われます。このオプションは、デプロイメント前のチェックで何らかのクリティカルではない警告が発生した場合に終了します。 |
|
オーバークラウドに対する検証チェックを実行しますが、オーバークラウドを実際には作成しません。 |
|
オーバークラウドのデプロイ後の設定を省略します。 |
|
オーバークラウドのデプロイ後の設定を強制的に行います。 |
|
|
|
引数とパラメーターが記載された YAML ファイルへのパス |
|
カスタマーポータルまたは Satellite 6 にオーバークラウドノードを登録します。 |
|
オーバークラウドノードに使用する登録方法。Red Hat Satellite 6 または Red Hat Satellite 5 は |
|
登録に使用する組織 |
|
すでに登録済みでもシステムを登録します。 |
|
オーバークラウドノードを登録する 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 サーバーの場合は、オーバークラウドは |
|
登録に使用するアクティベーションキー |
環境ファイルの parameter_defaults
セクションに追加する Heat テンプレートのパラメーターの使用が優先されるため、一部のコマンドラインパラメーターは古いか非推奨となっています。以下の表では、非推奨となったパラメーターと、それに相当する Heat テンプレートのパラメーターを対照しています。
表6.3 非推奨の CLI パラメーターと Heat テンプレートのパラメーターの対照表
パラメーター | 説明 | Heat テンプレートのパラメーター |
---|---|---|
|
スケールアウトするコントローラーノード数 |
|
|
スケールアウトするコンピュートノード数 |
|
|
スケールアウトする Ceph Storage ノードの数 |
|
|
スケールアウトする Cinder ノード数 |
|
|
スケールアウトする Swift ノード数 |
|
|
コントローラーノードに使用するフレーバー |
|
|
コンピュートノードに使用するフレーバー |
|
|
Ceph Storage ノードに使用するフレーバー |
|
|
Cinder ノードに使用するフレーバー |
|
|
Swift Storage ノードに使用するフレーバー |
|
|
フラットなネットワークが neutron プラグインで設定されるように定義します。外部ネットワークを作成ができるようにデフォルトは「datacentre」に設定されています。 |
|
|
各ハイパーバイザーで作成する Open vSwitch ブリッジ。デフォルト値は「br-ex」で、通常この値は変更する必要はないはずです。 |
|
|
使用する論理ブリッジから物理ブリッジへのマッピング。ホスト (br-ex) の外部ブリッジを物理名 (datacentre) にマッピングするようにデフォルト設定されています。これは、デフォルトの Floating ネットワークに使用されます。 |
|
|
ネットワークノード向けにインターフェースを br-ex にブリッジするインターフェースを定義します。 |
|
|
Neutron のテナントネットワーク種別 |
|
|
neutron テナントネットワークのトンネリング種別。複数の値を指定するには、コンマ区切りの文字列を使用します。 |
|
|
テナントネットワークを割り当てに使用できる GRE トンネリングの ID 範囲 |
|
|
テナントネットワークを割り当てに使用できる VXLAN VNI の ID 範囲 |
|
|
サポートされる Neutron ML2 および Open vSwitch VLAN マッピングの範囲。デフォルトでは、物理ネットワーク「datacentre」上の VLAN を許可するように設定されています。 |
|
|
neutron テナントネットワークのメカニズムドライバー。デフォルトでは、「openvswitch」に設定されており、複数の値を指定するにはコンマ区切りの文字列を使用します。 |
|
|
VLAN で区切られたネットワークまたは neutron でのフラットネットワークを使用するためにトンネリングを無効化します。 |
パラメーターのマッピングなし |
|
オーバークラウドの作成プロセスでは、デプロイメントの前に一連のチェックが行われます。このオプションは、デプロイメント前のチェックで何らかの致命的なエラーが発生した場合に終了します。どのようなエラーが発生してもデプロイメントが失敗するので、このオプションを使用することを推奨します。 |
パラメーターのマッピングなし |
これらのパラメーターは、Red Hat OpenStack Platform の今後のリリースで削除される予定です。
オプションの完全一覧については、以下のコマンドを実行します。
(undercloud) $ openstack help overcloud deploy
6.8. オーバークラウド作成時の環境ファイルの追加
オーバークラウドをカスタマイズするには、-e
を指定して、環境ファイルを追加します。必要に応じていくつでも環境ファイルを追加することができますが、後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順番は重要です。以下の一覧は、環境ファイルの順序の例です。
- 各ロールおよびそのフレーバーごとのノード数。オーバークラウドを作成するには、この情報の追加は不可欠です。
- コンテナー化された OpenStack サービスのコンテナーイメージの場所。このファイルは、「5章コンテナーレジストリー情報の設定」で説明したオプションのいずれかで作成されたものです。
-
任意のネットワーク分離ファイル。Heat テンプレートコレクションの初期化ファイル (
environments/network-isolation.yaml
) から開始して、次にカスタムの NIC 設定ファイル、最後に追加のネットワーク設定の順番です。 - 外部のロードバランシングの環境ファイル
- Ceph Storage、NFS、iSCSI などのストレージ環境ファイル
- Red Hat CDN または Satellite 登録用の環境ファイル
- その他のカスタム環境ファイル
-e
オプションを使用してオーバークラウドに追加した環境ファイルはいずれも、オーバークラウドのスタック定義の一部となります。以下のコマンドは、追加するカスタム環境ファイルを使用してオーバークラウドの作成を開始する方法の一例です。
(undercloud) $ openstack overcloud deploy --templates \ -e /home/stack/templates/node-info.yaml\ -e /home/stack/templates/overcloud_images.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /home/stack/templates/network-environment.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \ -e /home/stack/templates/ceph-custom-config.yaml \ --ntp-server pool.ntp.org \
このコマンドでは、以下の追加オプションも使用できます。
- --templates
-
/usr/share/openstack-tripleo-heat-templates
の Heat テンプレートコレクションをベースとして使用し、オーバークラウドを作成します。 - -e /home/stack/templates/node-info.yaml
各ロールに使用するノード数とフレーバーを定義する環境ファイルを追加します。以下に例を示します。
parameter_defaults: OvercloudControllerFlavor: control OvercloudComputeFlavor: compute OvercloudCephStorageFlavor: ceph-storage ControllerCount: 3 ComputeCount: 3 CephStorageCount: 3
- -e /home/stack/templates/overcloud_images.yaml
- コンテナーイメージのソースが含まれる環境ファイルを追加します。詳細は、「5章コンテナーレジストリー情報の設定」を参照してください。
- -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml
- オーバークラウドデプロイメントのネットワーク分離を初期化する環境ファイルを追加します。
- -e /home/stack/templates/network-environment.yaml
- ネットワーク分離をカスタマイズする環境ファイルを追加します。
- -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml
- Ceph Storage サービスを有効化するための環境ファイルを追加します。
- -e /home/stack/templates/ceph-custom-config.yaml
- Ceph Storage の設定をカスタマイズするための環境ファイルを追加します。
- --ntp-server pool.ntp.org
- 時刻の同期に NTP サーバーを使用します。コントローラーノードクラスターの同期を保つには、このオプションが必要です。
director は、「9章オーバークラウド作成後のタスクの実行」に記載の再デプロイおよびデプロイ後の機能にこれらの環境ファイルを必要とします。これらのファイルが含まれていない場合には、オーバークラウドが破損する可能性があります。
オーバークラウド設定を後で変更する予定の場合には、以下の作業を行う必要があります。
- カスタムの環境ファイルおよび Heat テンプレートのパラメーターを変更します。
-
同じ環境ファイルを指定して
openstack overcloud deploy
コマンドを再度実行します。
オーバークラウドを手動で編集しても、director を使用してオーバークラウドスタックの更新を行う際に director の設定で上書きされてしまうので、設定は直接編集しないでください。
環境ファイルディレクトリーの追加
--environment-directory
オプションを使用して、環境ファイルを格納しているディレクトリー全体を追加することも可能です。デプロイメントコマンドにより、このディレクトリー内の環境ファイルは、最初に番号順、その後にアルファベット順で処理されます。この方法を使用する場合には、ファイル名に数字のプレフィックスを使用することを推奨します。以下に例を示します。
(undercloud) $ ls -1 ~/templates 00-node-info.yaml 10-network-isolation.yaml 20-network-environment.yaml 30-storage-environment.yaml 40-rhel-registration.yaml
以下のデプロイメントコマンドを実行してディレクトリーを追加します。
(undercloud) $ 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
以下のデプロイメントコマンドを実行して回答ファイルを追加します。
(undercloud) $ openstack overcloud deploy --answers-file ~/answers.yaml
6.9. オーバークラウドプランの管理
openstack overcloud deploy
コマンドを使用する代わりに、director を使用してインポートしたプランを管理することもできます。
新規プランを作成するには、以下のコマンドを stack
ユーザーとして実行します。
(undercloud) $ openstack overcloud plan create --templates /usr/share/openstack-tripleo-heat-templates my-overcloud
このコマンドは、/usr/share/openstack-tripleo-heat-templates
内のコア Heat テンプレートコレクションからプランを作成します。director は、入力内容に基づいてプランに名前を指定します。この例では、my-overcloud
という名前です。director は、この名前をオブジェクトストレージコンテナー、ワークフロー環境、オーバークラウドスタック名のラベルとして使用します。
以下のコマンドを使用して環境ファイルからパラメーターを追加します。
(undercloud) $ openstack overcloud parameters set my-overcloud ~/templates/my-environment.yaml
以下のコマンドを使用してプランをデプロイします。
(undercloud) $ openstack overcloud plan deploy my-overcloud
以下のコマンドを使用して既存のプランを削除します。
(undercloud) $ openstack overcloud plan delete my-overcloud
openstack overcloud deploy
コマンドは基本的に、これらのコマンドをすべて使用して既存のプランの削除、環境ファイルを使用した新規プランのアップロード、プランのデプロイを行います。
6.10. オーバークラウドのテンプレートおよびプランの検証
オーバークラウドの作成またはスタックの更新を実行する前に、Heat テンプレートと環境ファイルにエラーがないかどうかを検証します。
レンダリングされたテンプレートの作成
オーバークラウドのコア Heat テンプレートは、Jinja2 形式となっています。テンプレートを検証するには、以下のコマンドを使用して Jinja 2 のフォーマットなしでバージョンをレンダリングします。
(undercloud) $ openstack overcloud plan create --templates /usr/share/openstack-tripleo-heat-templates overcloud-validation (undercloud) $ mkdir ~/overcloud-validation (undercloud) $ cd ~/overcloud-validation (undercloud) $ swift download overcloud-validation
その後の検証テストには ~/overcloud-validation
のレンダリング済みテンプレートを使用します。
テンプレート構文の検証
以下のコマンドを使用して、テンプレート構文を検証します。
(undercloud) $ 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
オプションを追加して、ネストされたテンプレートからパラメーターを解決します。
このコマンドは、テンプレート内の構文エラーを特定します。テンプレートの構文の検証が正常に行われた場合には、出力には、作成されるオーバークラウドのテンプレートのプレビューが表示されます。
6.11. オーバークラウド作成の監視
オーバークラウドの作成プロセスが開始され、director によりノードがプロビジョニングされます。このプロセスは完了するまで多少時間がかかります。オーバークラウドの作成のステータスを確認するには、stack
ユーザーとして別のターミナルを開き、以下のコマンドを実行します。
(undercloud) $ source ~/stackrc (undercloud) $ openstack stack list --nested
openstack stack list --nested
コマンドは、オーバークラウド作成の現在の段階を表示します。
6.12. オーバークラウドへのアクセス
director は、director ホストからオーバークラウドに対話するための設定を行い、認証をサポートするスクリプトを作成して、stack
ユーザーのホームディレクトリーにこのファイル (overcloudrc
) を保存します。このファイルを使用するには、以下のコマンドを実行します。
(undercloud) $ source ~/overcloudrc
これで、director のホストの CLI からオーバークラウドと対話するために必要な環境変数が読み込まれます。コマンドプロンプトが変わり、オーバークラウドと対話していることが示されます。
(overcloud) $
director のホストとの対話に戻るには、以下のコマンドを実行します。
(overcloud) $ source ~/stackrc (undercloud) $
オーバークラウドの各ノードには、heat-admin
と呼ばれるユーザーが含まれます。stack
ユーザーには、各ノードに存在するこのユーザーに SSH 経由でアクセスすることができます。SSH でノードにアクセスするには、希望のノードの IP アドレスを特定します。
(undercloud) $ openstack server list
次に、heat-admin
ユーザーとノードの IP アドレスを使用して、ノードに接続します。
(undercloud) $ ssh heat-admin@192.168.24.23
6.13. オーバークラウド作成の完了
これで、コマンドラインツールを使用したオーバークラウドの作成が完了しました。作成後の機能については、「9章オーバークラウド作成後のタスクの実行」を参照してください。