7.2. ベアメタルオーバークラウドノードのプロビジョニング
Red Hat OpenStack Platform (RHOSP) 環境を設定するには、次のタスクを実行する必要があります。
- オーバークラウドのベアメタルノードを登録します。
- ベアメタルノードのハードウェアのインベントリーをディレクターに提供します。
- ノード定義ファイルで、ベアメタルノードの数量、属性、およびネットワークレイアウトを設定します。
- ベアメタルノードに、指定のノードとこのノードを合致させるリソースクラスを割り当てます。
プロファイルを一致させてオーバークラウドノードを指定するなど、追加のオプションのタスクを実行することもできます。
7.2.1. オーバークラウドノードの登録
ディレクターには、ノードのハードウェアと電源管理の詳細を指定するノード定義テンプレートが必要です。このテンプレートは、JSON 形式の nodes.json
または YAML 形式の nodes.yaml
で作成できます。
手順
ノードをリスト表示する
nodes.json
またはnodes.yaml
という名前のテンプレートを作成します。以下の例に示す JSON および YAML テンプレートを使用して、ノード定義のテンプレートを設定する方法を説明します。JSON テンプレートの例
{ "nodes": [{ "name": "node01", "ports": [{ "address": "aa:aa:aa:aa:aa:aa", "physical_network": "ctlplane", "local_link_connection": { "switch_id": "52:54:00:00:00:00", "port_id": "p0" } }], "cpu": "4", "memory": "6144", "disk": "40", "arch": "x86_64", "pm_type": "ipmi", "pm_user": "admin", "pm_password": "p@55w0rd!", "pm_addr": "192.168.24.205" }, { "name": "node02", "ports": [{ "address": "bb:bb:bb:bb:bb:bb", "physical_network": "ctlplane", "local_link_connection": { "switch_id": "52:54:00:00:00:00", "port_id": "p0" } }], "cpu": "4", "memory": "6144", "disk": "40", "arch": "x86_64", "pm_type": "ipmi", "pm_user": "admin", "pm_password": "p@55w0rd!", "pm_addr": "192.168.24.206" }] }
YAML テンプレートの例
nodes: - name: "node01" ports: - address: "aa:aa:aa:aa:aa:aa" physical_network: ctlplane local_link_connection: switch_id: "52:54:00:00:00:00" port_id: p0 cpu: 4 memory: 6144 disk: 40 arch: "x86_64" pm_type: "ipmi" pm_user: "admin" pm_password: "p@55w0rd!" pm_addr: "192.168.24.205" - name: "node02" ports: - address: "bb:bb:bb:bb:bb:bb" physical_network: ctlplane local_link_connection: switch_id: "52:54:00:00:00:00" port_id: p0 cpu: 4 memory: 6144 disk: 40 arch: "x86_64" pm_type: "ipmi" pm_user: "admin" pm_password: "p@55w0rd!" pm_addr: "192.168.24.206"
このテンプレートには、以下の属性が含まれます。
- name
- ノードの論理名
- ports
特定の IPMI デバイスにアクセスするためのポート次の任意のポート属性を定義できます。
-
address
: ノード上のネットワークインターフェイスの MAC アドレス。各システムのプロビジョニング NIC の MAC アドレスのみを使用します。 -
physical_network
: プロビジョニング NIC に接続されている物理ネットワーク。 -
local_link_connection
: IPv6 プロビジョニングを使用し、イントロスペクション中に LLDP がローカルリンク接続を正しく反映しない場合は、local_link_connection
パラメーターのswitch_id
およびport_id
フィールドにダミーのデータを含める必要があります。偽のデータを含める方法の詳細は、director イントロスペクションを使用したベアメタルノードのハードウェア情報の収集 を参照してください。
-
- cpu
- (オプション) ノード上の CPU 数
- memory
- (オプション) メモリーサイズ (MB 単位)
- disk
- (オプション) ハードディスクのサイズ (GB 単位)
- arch
- (オプション) システムアーキテクチャー
- pm_type
使用する電源管理ドライバー。この例では IPMI ドライバー (
ipmi
) を使用しています。注記IPMI が推奨されるサポート対象電源管理ドライバーです。サポートされている電源管理の種類とそのオプションの詳細は、電源管理ドライバー を参照してください。それらの電源管理ドライバーが想定どおりに機能しない場合には、電源管理に IPMI を使用してください。
- pm_user、pm_password
- IPMI のユーザー名およびパスワード
- pm_addr
- IPMI デバイスの IP アドレス
テンプレートのフォーマットと構文を確認します。
$ source ~/stackrc (undercloud)$ openstack overcloud node import --validate-only ~/nodes.json
-
テンプレートファイルを
stack
ユーザーのホームディレクトリー (/home/stack/nodes.json
) に保存します。 テンプレートを director にインポートして、各ノードをテンプレートから director に登録します。
(undercloud)$ openstack overcloud node import ~/nodes.json
ノードの登録および設定が完了するまで待ちます。完了したら、ノードが director に正しく登録されていることを確認します。
(undercloud)$ openstack baremetal node list
7.2.2. ベアメタルノードハードウェアのインベントリーの作成
ディレクターは、プロファイルのタグ付け、ベンチマーク、および手動のルートディスク割り当てのために、Red Hat OpenStack Platform (RHOSP) デプロイメント内のノードのハードウェアインベントリーを必要とします。
次のいずれかの方法を使用して、ハードウェアインベントリーをディレクターに提供できます。
- Automatic: 各ノードからハードウェア情報を収集するディレクターのイントロスペクションプロセスを使用できます。このプロセスは、各ノードでイントロスペクションエージェントを起動します。イントロスペクションエージェントは、ノードからハードウェアのデータを収集し、そのデータを director に送り返します。Director は、ハードウェアデータを OpenStack 内部データベースに保存します。
- Manual: 各ベアメタルマシンの基本的なハードウェアインベントリーを手動で設定できます。このインベントリーは、ベアメタルプロビジョニングサービス (ironic) に保存され、ベアメタルマシンの管理とデプロイに使用されます。
ディレクターの自動イントロスペクションプロセスには、ベアメタルプロビジョニングサービスポートを手動で設定する方法に比べて、次の利点があります。
-
イントロスペクションは、接続されているすべてのポートをハードウェア情報に記録します。これには、
nodes.yaml
でまだ設定されていない場合に PXE ブートに使用するポートも含まれます。 -
イントロスペクションは、属性が LLDP を使用して検出可能である場合、各ポートの
local_link_connection
属性を設定します。手動による方法を使用する場合は、ノードを登録するときに各ポートにlocal_link_connection
を設定する必要があります。 -
イントロスペクションは、スパイン/リーフ型または DCN のアーキテクチャーをデプロイするときに、ベアメタルプロビジョニングサービスポートの
physical_network
属性を設定します。
7.2.2.1. ディレクターのイントロスペクションを使用してベアメタルノードのハードウェア情報を収集する
物理マシンをベアメタルノードとして登録した後、ディレクターイントロスペクションを使用して、ハードウェアの詳細を自動的に追加し、イーサネット MAC アドレスごとにポートを作成できます。
自動イントロスペクションの代わりに、ベアメタルノードのハードウェア情報をディレクターに手動で提供できます。詳細は、ベアメタルノードのハードウェア情報の手動設定 を参照してください。
前提条件
- オーバークラウドのベアメタルノードを登録しました。
手順
-
アンダークラウドホストに
stack
ユーザーとしてログインします。 stackrc
アンダークラウド認証情報ファイルを入手します。$ source ~/stackrc
pre-introspection 検証グループを実行して、プリイントロスペクションの要件を確認します。
(undercloud)$ validation run --group pre-introspection \ --inventory <inventory_file>
<inventory_file>
ファイルを Ansible インベントリーファイルの名前および場所に置き換えます (例:~/tripleo-deploy/undercloud/tripleo-ansible-inventory.yaml
)。注記検証を実行すると、出力の
Reasons
列は 79 文字に制限されます。検証結果を完全に表示するには、検証ログファイルを表示します。
- 検証レポートの結果を確認します。
オプション: 特定の検証からの詳細な出力を確認します。
(undercloud)$ validation history get --full <UUID>
<UUID>
は、確認するレポートの特定の検証の UUID に置き換えます。重要検証結果が
FAILED
であっても、Red Hat OpenStack Platform のデプロイや実行が妨げられることはありません。ただし、FAILED
の検証結果は、実稼働環境で問題が発生する可能性があることを意味します。
各ノードのハードウェア属性を検証します。すべてのノードまたは特定のノードのハードウェア属性を検査できます。
すべてのノードのハードウェア属性を検査します。
(undercloud)$ openstack overcloud node introspect --all-manageable --provide
-
--all-manageable
オプションを使用して、管理状態にあるノードのみをイントロスペクションします。ここでは、すべてのノードが管理状態にあります。 -
--provide
オプションを使用して、イントロスペクション後に全ノードをavailable
の状態に再設定します。
-
特定のノードのハードウェア属性を検査します。
(undercloud)$ openstack overcloud node introspect --provide <node1> [node2] [noden]
-
--provide
オプションを使用して、イントロスペクション後に指定されたすべてのノードをavailable
状態にリセットします。 -
<node1>
、[node2]
、および[noden]
までのすべてのノードを、イントロスペクションする各ノードの UUID に置き換えます。
-
別のターミナルウィンドウで、イントロスペクションの進捗ログを監視します。
(undercloud)$ sudo tail -f /var/log/containers/ironic-inspector/ironic-inspector.log
重要イントロスペクションプロセスが完了するまで実行されていることを確認します。イントロスペクションは通常、ベアメタルノードの場合 15 分かかります。ただし、イントロスペクションネットワークのサイズが正しくないと、時間がかかる可能性があり、イントロスペクションが失敗する可能性があります。
オプション: IPv6 を介したベアメタルプロビジョニング用にアンダークラウドを設定した場合は、LLDP がベアメタルプロビジョニングサービス (ironic) ポートの
local_link_connection
を設定していることも確認する必要があります。$ openstack baremetal port list --long -c UUID -c "Node UUID" -c "Local Link Connection"
ベアメタルノードのポートに対して Local Link Connection フィールドが空の場合、
local_link_connection
値に偽のデータを手動で入力する必要があります。次の例では、偽のスイッチ ID を52:54:00:00:00:00
に設定し、偽のポート ID をp0
に設定します。$ openstack baremetal port set <port_uuid> \ --local-link-connection switch_id=52:54:00:00:00:00 \ --local-link-connection port_id=p0
ローカルリンク接続フィールドにダミーのデータが含まれていることを確認します。
$ openstack baremetal port list --long -c UUID -c "Node UUID" -c "Local Link Connection"
イントロスペクション完了後には、すべてのノードが available
の状態に変わります。
7.2.2.2. ベアメタルノードのハードウェア情報を手動で設定する
物理マシンをベアメタルノードとして登録した後、ハードウェアの詳細を手動で追加し、イーサネット MAC アドレスごとにベアメタルポートを作成できます。オーバークラウドをデプロイする前に、少なくとも 1 つのベアメタルポートを作成する必要があります。
手動イントロスペクションの代わりに、自動ディレクターイントロスペクションプロセスを使用して、ベアメタルノードのハードウェア情報を収集できます。詳細は、director イントロスペクションを使用したベアメタルノードのハードウェア情報の収集 を参照してください。
前提条件
- オーバークラウドのベアメタルノードを登録しました。
-
nodes.json
の登録済みノードの各ポートにlocal_link_connection
を設定しました。詳細は、オーバークラウドノードの登録 を参照してください。
手順
-
アンダークラウドホストに
stack
ユーザーとしてログインします。 stackrc
アンダークラウド認証情報ファイルを入手します。$ source ~/stackrc
ノードドライバーのデプロイカーネルとデプロイ ramdisk を指定します。
(undercloud)$ openstack baremetal node set <node> \ --driver-info deploy_kernel=<kernel_file> \ --driver-info deploy_ramdisk=<initramfs_file>
-
<node>
をベアメタルノードの ID に置き換えてください。 -
<kernel_file>
を.kernel
イメージへのパス (例:file:///var/lib/ironic/httpboot/agent.kernel
) に置き換えます。 -
<initramfs_file>
は、.initramfs
イメージへのパス (例:file:///var/lib/ironic/httpboot/agent.ramdisk
) に置き換えます。
-
ノードの属性を更新して、ノード上のハードウェアの仕様と一致するようにします。
(undercloud)$ openstack baremetal node set <node> \ --property cpus=<cpu> \ --property memory_mb=<ram> \ --property local_gb=<disk> \ --property cpu_arch=<arch>
-
<node>
をベアメタルノードの ID に置き換えてください。 -
<cpu>
は、CPU の数に置き換えます。 -
<ram>
を MB 単位の RAM に置き換えます。 -
<disk>
を GB 単位のディスクサイズに置き換えます。 -
<arch>
は、アーキテクチャータイプに置き換えます。
-
オプション: 各ノードの IPMI 暗号スイートを指定します。
(undercloud)$ openstack baremetal node set <node> \ --driver-info ipmi_cipher_suite=<version>
-
<node>
をベアメタルノードの ID に置き換えてください。 <version>
は、ノードで使用する暗号スイートのバージョンに置き換えます。以下の有効な値のいずれかに設定します。-
3
- ノードは SHA1 暗号スイートで AES-128 を使用します。 -
17
- ノードは SHA256 暗号スイートで AES-128 を使用します。
-
-
オプション: 複数のディスクがある場合は、ルートデバイスのヒントを設定して、デプロイメントに使用するディスクをデプロイ ramdisk に通知します。
(undercloud)$ openstack baremetal node set <node> \ --property root_device='{"<property>": "<value>"}'
-
<node>
をベアメタルノードの ID に置き換えてください。 <property>
と<value>
は、デプロイメントに使用するディスクの詳細に置き換えます (例:root_device='{"size": "128"}'
)。RHOSP は、次のプロパティーをサポートしています。
-
model
(文字列): デバイスの ID -
vendor
(文字列): デバイスのベンダー -
serial
(文字列): ディスクのシリアル番号 -
hctl
(文字列): SCSI のホスト、チャンネル、ターゲット、Lun -
size
(整数): デバイスのサイズ (GB 単位) -
wwn
(文字列): 一意のストレージ ID -
wwn_with_extension
(文字列): ベンダー拡張子を追加した一意のストレージ ID -
wwn_vendor_extension
(文字列): 一意のベンダーストレージ ID -
rotational
(ブール値): 回転式デバイス (HDD) には true、そうでない場合 (SSD) には false name
(文字列): デバイス名 (例: /dev/sdb1)。このプロパティーは、永続デバイス名が付いたデバイスにのみ使用してください。注記複数のプロパティーを指定する場合には、デバイスはそれらの全プロパティーと一致する必要があります。
-
-
プロビジョニングネットワーク上の NIC の MAC アドレスを使用してポートを作成することにより、Bare Metal Provisioning サービスにノードのネットワークカードを通知します。
(undercloud)$ openstack baremetal port create --node <node_uuid> <mac_address>
-
<node_uuid>
をベアメタルノードの一意の ID に置き換えます。 -
<mac_address>
は、PXE ブートに使用する NIC の MAC アドレスに置き換えます。
-
ノードの設定を検証します。
(undercloud)$ openstack baremetal node validate <node>
------------
-----------------------------------------------------
| Interface | Result | Reason |------------
-----------------------------------------------------
| bios | True | | | boot | True | | | console | True | | | deploy | False | Node 229f0c3d-354a-4dab-9a88-ebd318249ad6 | | | | failed to validate deploy image info. | | | | Some parameters were missing. Missing are:| | | | [instance_info.image_source] | | inspect | True | | | management | True | | | network | True | | | power | True | | | raid | True | | | rescue | True | | | storage | True | |------------
-----------------------------------------------------
有効出力の
Result
は、次のことを示しています。-
False
: インターフェイスは検証に失敗しました。instance_info.image_source
パラメーターが欠落していることが理由に含まれている場合には、プロビジョニング中に入力されたことが原因である可能性があり、この時点では設定されていません。ディスクイメージ全体を使用している場合は、検証にパスするためにimage_source
を設定するだけでよい場合があります。 -
True
: インターフェイスは検証にパスしました。 -
None
: インターフェイスはドライバーでサポートされていません。
-
7.2.3. オーバークラウドのベアメタルノードのプロビジョニング
ベアメタルノードをプロビジョニングするには、デプロイするベアメタルノードの数と属性を YAML 形式のノード定義ファイルで定義し、これらのノードにオーバークラウドロールを割り当てます。ノードのネットワークレイアウトも定義します。
プロビジョニングプロセスにより、ノード定義ファイルから Heat 環境ファイルが作成されます。この Heat 環境ファイルには、ノード数、予測ノード配置、カスタムイメージ、カスタム NIC など、ノード定義ファイルで設定したノード仕様が含まれています。オーバークラウドをデプロイする際に、このファイルをデプロイメントコマンドに追加します。プロビジョニングプロセスでは、ノード定義ファイル内の各ノードまたはロールに対して定義されたすべてのネットワークのポートリソースもプロビジョニングされます。
前提条件
- アンダークラウドがインストールされます。詳細は、Installing director を参照してください。
- ベアメタルノードは登録とイントロスペクトが行われ、プロビジョニングとデプロイメントに使用できます。詳細は、Registering nodes for the overcloud と ベアメタルノードハードウェアのインベントリー作成 を参照してください。
手順
source コマンドで
stackrc
アンダークラウド認証情報ファイルを読み込みます。$ source ~/stackrc
overcloud-baremetal-deploy.yaml
ノード定義ファイルを作成し、プロビジョニングするロールごとにノード数を定義します。たとえば、3 つのコントローラーノードと 3 つのコンピュートノードをプロビジョニングするには、以下の設定をovercloud-baremetal-deploy.yaml
ファイルに追加します。- name: Controller count: 3 - name: Compute count: 3
オプション: 予測ノード配置を設定します。たとえば、以下の設定を使用すると、3 つのコントローラーノードがノード
node00
、node01
、およびnode02
に、3 つのコンピュートノードがノードnode04
、node05
、およびnode06
に、それぞれプロビジョニングされます。- name: Controller count: 3 instances: - hostname: overcloud-controller-0 name: node00 - hostname: overcloud-controller-1 name: node01 - hostname: overcloud-controller-2 name: node02 - name: Compute count: 3 instances: - hostname: overcloud-novacompute-0 name: node04 - hostname: overcloud-novacompute-1 name: node05 - hostname: overcloud-novacompute-2 name: node06
オプション: デフォルトでは、プロビジョニングプロセスは
overcloud-hardened-uefi-full.qcow2
イメージを使用します。イメージのローカル URL またはリモート URL を指定することで、特定のノードで使用されるイメージ、またはロールのすべてのノードで使用されるイメージを変更できます。次の例では、イメージをローカル QCOW2 イメージに変更します。特定のノード
- name: Controller count: 3 instances: - hostname: overcloud-controller-0 name: node00 image: href: file:///var/lib/ironic/images/overcloud-custom.qcow2 - hostname: overcloud-controller-1 name: node01 image: href: file:///var/lib/ironic/images/overcloud-full-custom.qcow2 - hostname: overcloud-controller-2 name: node02 image: href: file:///var/lib/ironic/images/overcloud-full-custom.qcow2
ロールのすべてのノード
- name: Controller count: 3 defaults: image: href: file:///var/lib/ironic/images/overcloud-custom.qcow2 instances: - hostname: overcloud-controller-0 name: node00 - hostname: overcloud-controller-1 name: node01 - hostname: overcloud-controller-2 name: node02
ロールのすべてのノードのネットワークレイアウト、または特定のノードのネットワークレイアウトを定義します。
特定のノード
次の例では、特定のコントローラーノードのネットワークをプロビジョニングし、予測可能な IP を Internal API ネットワークのノードに割り当てます。
- name: Controller count: 3 defaults: network_config: template: /home/stack/templates/nic-config/myController.j2 default_route_network: - external instances: - hostname: overcloud-controller-0 name: node00 networks: - network: ctlplane vif: true - network: external subnet: external_subnet - network: internal_api subnet: internal_api_subnet01 fixed_ip: 172.21.11.100 - network: storage subnet: storage_subnet01 - network: storage_mgmt subnet: storage_mgmt_subnet01 - network: tenant subnet: tenant_subnet01
ロールのすべてのノード
次の例では、コントローラーロールとコンピューティングロールのネットワークをプロビジョニングします。
- name: Controller count: 3 defaults: networks: - network: ctlplane vif: true - network: external subnet: external_subnet - network: internal_api subnet: internal_api_subnet01 - network: storage subnet: storage_subnet01 - network: storage_mgmt subnet: storage_mgmt_subnet01 - network: tenant subnet: tenant_subnet01 network_config: template: /home/stack/templates/nic-config/myController.j2 1 default_route_network: - external - name: Compute count: 3 defaults: networks: - network: ctlplane vif: true - network: internal_api subnet: internal_api_subnet02 - network: tenant subnet: tenant_subnet02 - network: storage subnet: storage_subnet02 network_config: template: /home/stack/templates/nic-config/myCompute.j2
- 1
/usr/share/ansible/roles/tripleo_network_config/templates
にあるサンプル NIC テンプレートを使用して、ローカル環境ファイルディレクトリーに独自の NIC テンプレートを作成できます。
オプション: デフォルトのディスクパーティションサイズが要件を満たさない場合は、ディスクパーティションサイズの割り当てを設定します。たとえば、
/var/log
パーティションのデフォルトのパーティションサイズは 10 GB です。ログストレージおよび保存要件を考慮して、10 GB が要件を満たすかどうかを判断してください。ログストレージ用に割り当てられたディスクサイズを増やす必要がある場合は、次の設定をノード定義ファイルに追加して、デフォルトをオーバーライドします。ansible_playbooks: - playbook: /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-growvols.yaml extra_vars: role_growvols_args: default: /=8GB /tmp=1GB /var/log=<log_size>GB /var/log/audit=2GB /home=1GB /var=100%
-
<log_size>
を、ログファイルに割り当てるディスクのサイズに置き換えます。
-
-
Object Storage サービス (swift) とディスク全体のオーバークラウドイメージ
overcloud-hardened-uefi-full
を使用する場合に、ディスクのサイズと/var
および/srv
のストレージ要件に基づいて/srv
パーティションのサイズを設定する必要があります。詳細は、Object Storage サービスのディスクパーティション全体の設定 を参照してください。 - オプション: カスタムリソースクラスまたはプロファイル機能を使用して、オーバークラウドノードを特定のロールに指定します。詳細は、リソースクラスを一致させることによるオーバークラウドノードのロールの指定 および プロファイルを一致させることによるオーバークラウドノードのロールの指定 を参照してください。
- ノードに割り当てるその他の属性を定義します。ノード定義ファイルでノード属性を設定するために使用できるプロパティーについて詳しくは、ベアメタルノードのプロビジョニング属性 を参照してください。ノード定義ファイルの例は、ノード定義ファイルの例 を参照してください。
オーバークラウドノードをプロビジョニングします。
(undercloud)$ openstack overcloud node provision \ [--templates <templates_directory> \] --stack <stack> \ --network-config \ --output <deployment_file> \ /home/stack/templates/<node_definition_file>
-
オプション:
--templates
オプションを含めて、/usr/share/openstack-tripleo-heat-templates
にあるデフォルトテンプレートの代わりに独自のテンプレートを使用します。<templates_directory>
は、テンプレートを含むディレクトリーへのパスに置き換えます。 -
<stack>
を、ベアメタルノードがプロビジョニングされるスタックの名前に置き換えます。指定しない場合、デフォルトはovercloud
です。 -
--network-config
オプションの引数を含めて、cli-overcloud-node-network-config.yaml
Ansible Playbook にネットワーク定義を提供します。Playbookcli-overcloud-node-network-config.yaml
は、os-net-config
ツールを使用して、デプロイされたノードにネットワーク設定を適用します。--network-config
を使用してネットワークを定義をしない場合は、network-environment.yaml
ファイルで{{role.name}}NetworkConfigTemplate
パラメーターを設定する必要があります。設定しない場合は、デフォルトのネットワーク定義が使用されます。 -
<deployment_file>
は、デプロイメントコマンドに含めるために生成する heat 環境ファイルの名前に置き換えます (例:/home/stack/templates/overcloud-baremetal-deployed.yaml)
。 -
<node_definition_file>
は、ノード定義ファイルの名前 (overcloud-baremetal-deploy.yaml
など) に置き換えます。
-
オプション:
別のターミナルでプロビジョニングの進捗を監視します。
(undercloud)$ watch openstack baremetal node list
-
プロビジョニングが成功すると、ノードの状態が
available
からactive
に変わります。 - ノードのハードウェアまたはネットワーク設定の障害が原因でノードのプロビジョニングが失敗した場合は、プロビジョニング手順を再度実行する前に、失敗したノードを削除できます。詳細は、障害が発生したベアメタルノードをノード定義ファイルから削除する を参照してください。
-
プロビジョニングが成功すると、ノードの状態が
metalsmith
ツールを使用して、割り当てやポートなどを含むノードの統合ビューを取得します。(undercloud)$ metalsmith list
ノードとホスト名の関連付けを確認します。
(undercloud)$ openstack baremetal allocation list
次のステップ
7.2.4. ベアメタルノードのプロビジョニング属性
次の表を使用して、ノード属性を設定するために使用できるプロパティーと、openstack baremetal node provision
コマンドでベアメタルノードをプロビジョニングするときに使用できる値を理解してください。
- ロールのプロパティー: ロールのプロパティーを使用して、各ロールを定義します。
- 各ロールのデフォルトプロパティーとインスタンスプロパティー: デフォルトプロパティーまたはインスタンスプロパティーを使用して、使用可能なノードのプールからノードを割り当てるための選択基準を指定し、ベアメタルノードの属性とネットワーク設定プロパティーを設定します。
ベアメタル定義ファイルの作成に関する詳細は、オーバークラウドのベアメタルノードのプロビジョニング を参照してください。
プロパティー | Value |
---|---|
| ロール名 (必須) |
|
このロール用にプロビジョニングするノード数。デフォルト値は |
|
|
|
特定のノードの属性を指定するために使用可能な値のディクショナリー。 |
|
このロールのデフォルトのホスト名形式を上書きします。デフォルトで生成されるホスト名は、オーバークラウドのスタック名、ロール、および増分インデックス (すべて小文字) から派生します。たとえば、Controller ロールのデフォルト形式は、 |
|
Ansible Playbook と Ansible 変数の値のディクショナリー。Playbook は、ノードをプロビジョニングしてから、かつノードのネットワークを設定する前に、ロールインスタンスに対して実行されます。Ansible Playbook の指定の詳細は、 |
プロパティー | Value |
---|---|
|
( |
|
( |
|
ノードにプロビジョニングするイメージの詳細。サポート対象の |
| ノードのケイパビリティーを照合する際の選択基準 |
|
ノードに渡された設定ドライブにデータと初回起動コマンドを追加します。詳細は、 注記
初回起動時に実行する必要がある設定には、 |
|
インスタンスを metalsmith でプロビジョニングするには、 |
|
インスタンスネットワークを表すディクショナリーのリスト。ネットワーク属性の設定の詳細は、 |
|
ロールまたはインスタンスのネットワーク設定ファイルへのリンク。ネットワーク設定ファイルへのリンクの設定の詳細は、 |
| プロファイルマッチングの選択基準。詳細は、プロファイルを照合することによるオーバークラウドノードへのロール指定 を参照してください。 |
|
ノードをプロビジョニングするには、 |
|
ノードのリソースクラスを照合する際の選択基準。デフォルト値は |
|
ルートパーティションのサイズ (GiB 単位)。デフォルト値は |
| スワップパーティションのサイズ (MiB 単位) |
| ノード特性を照合する際の選択基準としての特性のリスト |
プロパティー | Value |
---|---|
|
ノードにプロビジョニングするルートパーティションまたはディスクイメージ全体の URL を指定します。サポートされている URL スキーム: 注記
|
|
ルートパーティションまたはディスクイメージ全体の MD5 チェックサムを指定します。 |
| カーネルイメージのイメージ参照または URL を指定します。パーティションイメージに対してのみ、この属性を使用します。 |
| RAM ディスクイメージのイメージ参照または URL を指定します。パーティションイメージに対してのみ、この属性を使用します。 |
プロパティー | Value |
---|---|
| このネットワークに使用する特定の IP アドレス |
| ネットワークポートを作成するネットワーク。 |
| ネットワークポートを作成するサブネット。 |
| 新しいポートを作成する代わりに使用する既存のポート。 |
|
プロビジョニングネットワーク ( |
プロパティー | Value |
---|---|
| ノードのネットワーク設定を適用するときに使用する Ansible J2 NIC 設定テンプレートを指定します。NIC テンプレートの設定については、オーバークラウドネットワークの設定 を参照してください。 |
|
外部ネットワークにアクセスするために作成する OVS ブリッジの名前。デフォルトのブリッジ名は |
|
パブリックブリッジに追加するインターフェイスの名前を指定します。デフォルトのインターフェイスは |
|
更新時にネットワーク設定の変更を適用するには、 |
|
各ノードまたはノードグループの NIC マッピング設定 |
|
デフォルトルートに使用するネットワーク。デフォルトのルートネットワークは |
| ノードのネットワークを設定するときにスキップするネットワークのリスト。 |
|
|
|
結合インターフェイスに使用する OVS オプションまたは結合オプション。たとえば、OVS のボンディングの場合は |
| DPDK ボンドまたは DPDK ポートに必要な RX キューの数を指定します。 |
プロパティー | Value |
---|---|
|
ノードの起動時に実行するタスクの config_drive: cloud_config: manage_resolv_conf: true resolv_conf: nameservers: - 8.8.8.8 - 8.8.4.4 searchdomains: - abc.example.com - xyz.example.com domain: example.com sortlist: - 10.0.0.1/255 - 10.0.0.2 options: rotate: true timeout: 1 |
|
config-drive |
プロパティー | Value |
---|---|
| ロール定義 YAML ファイルに相対的な、Ansible Playbook へのパス。 |
| Playbook の実行時に設定する追加の Ansible 変数。次の構文を使用して、追加の変数を指定します。 ansible_playbooks: - playbook: a_playbook.yaml extra_vars: param1: value1 param2: value2
たとえば、ディスク全体のオーバークラウドイメージ ansible_playbooks: - playbook: /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-growvols.yaml extra_vars: role_growvols_args: default: /=8GB /tmp=1GB /var/log=10GB /var/log/audit=2GB /home=1GB /var=100% Controller: /=8GB /tmp=1GB /var/log=10GB /var/log/audit=2GB /home=1GB /srv=50GB /var=100% |
7.2.5. 障害が発生したベアメタルノードをノード定義ファイルから削除する
ノードのハードウェアまたはネットワーク設定の障害が原因でノードのプロビジョニングが失敗した場合は、プロビジョニング手順を再度実行する前に、失敗したノードを削除できます。プロビジョニング中に失敗したベアメタルノードを削除するには、ノード定義ファイルでスタックから削除するノードにタグを付け、動作中のベアメタルノードをプロビジョニングする前にノードのプロビジョニングを解除します。
前提条件
- アンダークラウドがインストールされます。詳細は、Installing director を参照してください。
- ノードのハードウェア障害が原因で、ベアメタルノードのプロビジョニングが失敗しました。
手順
source コマンドで
stackrc
アンダークラウド認証情報ファイルを読み込みます。$ source ~/stackrc
-
overcloud-baremetal-deploy.yaml
ノード定義ファイルを開きます。 ノードが割り当てられているロールの
count
パラメーターを減らします。たとえば、以下の設定は、ObjectStorage
ロールのカウントパラメーターを更新して、ObjectStorage
専用のノード数が 3 に減ったことを反映します。- name: ObjectStorage count: 3
-
ロールの
instances
属性でまだ定義されていない場合は、スタックから削除するノードのhostname
とname
を定義します。 削除するノードに属性
provisioned: false
を追加します。たとえば、スタックからノードovercloud-objectstorage-1
を削除するには、overcloud-baremetal-deploy.yaml
ファイルに以下のスニペットを追加します。- name: ObjectStorage count: 3 instances: - hostname: overcloud-objectstorage-0 name: node00 - hostname: overcloud-objectstorage-1 name: node01 # Removed from cluster due to disk failure provisioned: false - hostname: overcloud-objectstorage-2 name: node02 - hostname: overcloud-objectstorage-3 name: node03
ベアメタルノードのプロビジョニングを解除します。
(undercloud)$ openstack overcloud node unprovision \ --stack <stack> \ --network-ports \ /home/stack/templates/overcloud-baremetal-deploy.yaml
-
<stack>
を、ベアメタルノードがプロビジョニングされるスタックの名前に置き換えます。指定しない場合、デフォルトはovercloud
です。
-
オーバークラウドノードをプロビジョニングして、デプロイメントコマンドに含める heat 環境ファイルを更新して生成します。
(undercloud)$ openstack overcloud node provision \ --stack <stack> \ --output <deployment_file> \ /home/stack/templates/overcloud-baremetal-deploy.yaml
-
<deployment_file>
は、デプロイメントコマンドに含めるために生成する heat 環境ファイルの名前に置き換えます (例:/home/stack/templates/overcloud-baremetal-deployed.yaml)
。
-
7.2.6. リソースクラスを一致させることによるオーバークラウドノードのロールの指定
カスタムリソースクラスを使用して、オーバークラウドノードを特定のロールに指定できます。リソースクラスは、ノードとデプロイロールを照合します。デフォルトでは、すべてのノードに baremetal
のリソースクラスが割り当てられます。
ノードのプロビジョニング後にノードに割り当てられたリソースクラスを変更するには、スケールダウン手順を使用してノードのプロビジョニングを解除してから、スケールアップ手順を使用して、新しいリソースクラスの割り当てでノードを再プロビジョニングする必要があります。詳細は、オーバークラウドノードのスケーリング を参照してください。
前提条件
- 現在、オーバークラウド用のベアメタルノードの初期プロビジョニング手順を行っている。
手順
カスタムリソースクラスを持つロールに指定する各ベアメタルノードを割り当てます。
(undercloud)$ openstack baremetal node set \ --resource-class <resource_class> <node>
-
<resource_class>
は、リソースクラスの名前 (baremetal.CPU-PINNING
など) に置き換えます。 -
<node>
をベアメタルノードの ID に置き換えてください。
-
-
まだ定義されていない場合は、
overcloud-baremetal-deploy.yaml
ファイルにロールを追加します。 ロールのノードに割り当てるリソースクラスを指定します。
- name: <role> count: 1 defaults: resource_class: <resource_class>
-
<role>
をロールの名前に置き換えます。 -
<resource_class>
は、手順 1 で指定したリソースクラスの名前に置き換えます。
-
- オーバークラウドのベアメタルノードのプロビジョニング に戻り、プロビジョニングプロセスを完了します。
7.2.7. プロファイルを一致させることによるオーバークラウドノードのロールの指定
プロファイル機能を使用して、オーバークラウドノードを特定のロールに指定できます。プロファイルは、ノードの機能をデプロイメントロールと照合します。
イントロスペクションルールを使用して、自動プロファイル割り当てを実行することもできます。詳しくは、プロファイルの自動タグ付けの設定 を参照してください。
ノードのプロビジョニング後にノードに割り当てられたプロファイルを変更するには、スケールダウン手順を使用してノードのプロビジョニングを解除してから、スケールアップ手順を使用して、新しいプロファイルの割り当てでノードを再プロビジョニングする必要があります。詳細は、オーバークラウドノードのスケーリング を参照してください。
前提条件
- 現在、オーバークラウド用のベアメタルノードの初期プロビジョニング手順を行っている。
手順
新しいノード機能を追加するたびに、既存のノード機能が上書きされます。したがって、再設定するには、登録済みの各ノードの既存の機能を取得する必要があります。
$ openstack baremetal node show <node> \ -f json -c properties | jq -r .properties.capabilities
ノードの既存の機能に
profile:<profile>
を追加して、ロールプロファイルに一致させる各ベアメタルノードにプロファイル機能を割り当てます。(undercloud)$ openstack baremetal node set <node> \ --property capabilities="profile:<profile>,<capability_1>,...,<capability_n>"
-
<node>
は、ベアメタルノードの名前または ID に置き換えます。 -
<profile>
は、ロールプロファイルに一致するプロファイルの名前に置き換えます。 -
<capability_1>
および<capability_n>
までのすべての機能は、手順 1 で取得した各機能に置き換えます。
-
-
まだ定義されていない場合は、
overcloud-baremetal-deploy.yaml
ファイルにロールを追加します。 ロールのノードに割り当てるプロファイルを定義します。
- name: <role> count: 1 defaults: profile: <profile>
-
<role>
をロールの名前に置き換えます。 -
<profile>
は、ノードの機能に一致するプロファイルの名前に置き換えます。
-
- オーバークラウドのベアメタルノードのプロビジョニング に戻り、プロビジョニングプロセスを完了します。
7.2.8. Object Storage サービスのディスクパーティション全体の設定
ディスクイメージ全体である overcloud-hardened-uefi-full
は、個別のボリュームに分割されます。デフォルトでは、ディスク全体のオーバークラウドイメージでデプロイされたノードの /var
パーティションは、ディスクが完全に割り当てられるまで自動的に増加します。Object Storage サービス (swift) を使用する場合は、ディスクのサイズと /var
および /srv
のストレージ要件に基づいて /srv
パーティションのサイズを設定します。
前提条件
- 現在、オーバークラウド用のベアメタルノードの初期プロビジョニング手順を行っている。
手順
overcloud-baremetal-deploy.yaml
ノード定義ファイルの Ansible playbook 定義で、追加の Ansible 変数としてrole_growvols_args
を使用して、/srv
および/var
パーティションを設定します。/srv
または/var
のいずれかを GB 単位の絶対サイズに設定し、もう一方を 100% に設定して、残りのディスク領域を消費します。次の設定例では、
/srv
をコントローラーノードにデプロイされた Object Storage サービスの絶対サイズに、/var
を 100% に設定して、残りのディスク領域を消費します。ansible_playbooks: - playbook: /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-growvols.yaml extra_vars: role_growvols_args: default: /=8GB /tmp=1GB /var/log=10GB /var/log/audit=2GB /home=1GB /var=100% Controller: /=8GB /tmp=1GB /var/log=10GB /var/log/audit=2GB /home=1GB /srv=50GB /var=100%
以下の設定例では、
/var
を絶対サイズに、/srv
を 100% に設定して、Object Storage サービスの Object Storage ノードの残りのディスクスペースを消費します。ansible_playbooks: - playbook: /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-growvols.yaml extra_vars: role_growvols_args: default: /=8GB /tmp=1GB /var/log=10GB /var/log/audit=2GB /home=1GB /var=100% ObjectStorage: /=8GB /tmp=1GB /var/log=10GB /var/log/audit=2GB /home=1GB /var=10GB /srv=100%
- オーバークラウドのベアメタルノードのプロビジョニング に戻り、プロビジョニングプロセスを完了します。
7.2.9. ノード定義ファイルの例
次のノード定義ファイルの例では、3 つのコントローラーノードと 3 つのコンピュートノードの予測ノード配置と、それらが使用するデフォルトネットワークを定義しています。この例は、リソースクラスまたはノード機能プロファイルの照合に基づいて指定されたノードが含まれるカスタムロールを定義する方法も示しています。
- name: Controller count: 3 defaults: image: href: file:///var/lib/ironic/images/overcloud-custom.qcow2 networks: - network: ctlplane vif: true - network: external subnet: external_subnet - network: internal_api subnet: internal_api_subnet01 - network: storage subnet: storage_subnet01 - network: storagemgmt subnet: storage_mgmt_subnet01 - network: tenant subnet: tenant_subnet01 network_config: template: /home/stack/templates/nic-config/myController.j2 default_route_network: - external profile: nodeCapability instances: - hostname: overcloud-controller-0 name: node00 - hostname: overcloud-controller-1 name: node01 - hostname: overcloud-controller-2 name: node02 - name: Compute count: 3 defaults: networks: - network: ctlplane vif: true - network: internal_api subnet: internal_api_subnet02 - network: tenant subnet: tenant_subnet02 - network: storage subnet: storage_subnet02 network_config: template: /home/stack/templates/nic-config/myCompute.j2 resource_class: baremetal.COMPUTE instances: - hostname: overcloud-novacompute-0 name: node04 - hostname: overcloud-novacompute-1 name: node05 - hostname: overcloud-novacompute-2 name: node06
7.2.10. 仮想メディアブートの有効化
この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能です。実稼働環境にはデプロイしないでください。テクノロジープレビュー機能の詳細は、対象範囲の詳細 を参照してください。
Redfish 仮想メディアブートを使用して、ノードの Baseboard Management Controller (BMC) にブートイメージを提供することができます。これにより、BMC はイメージを仮想ドライブのいずれかに挿入することができます。その後、ノードは仮想ドライブからイメージに存在するオペレーティングシステムにブートすることができます。
Redfish ハードウェア種別は、仮想メディアを通じたデプロイ、レスキュー、およびユーザーの各イメージのブートに対応しています。Bare Metal Provisioning サービス (ironic) は、ノードのデプロイメント時に、ノードに関連付けられたカーネルイメージおよび ramdisk イメージを使用して、UEFI または BIOS ブートモード用のブート可能 ISO イメージをビルドします。仮想メディアブートの主な利点は、PXE の TFTP イメージ転送フェーズを排除し、HTTP GET 等の方法を使用することができる点です。
仮想メディアを通じて redfish
ハードウェア種別のノードをブートするには、ブートインターフェイスを redfish-virtual-media
に設定し、EFI システムパーティション (ESP) イメージを定義します。続いて、登録したノードが Redfish 仮想メディアブートを使用するように設定します。
前提条件
-
undercloud.conf
ファイルのenabled_hardware_types
パラメーターで、Redfish ドライバーが有効化されている。 - ベアメタルノードが登録されている。
- Image サービス (glance) に IPA およびインスタンスイメージがある。
- UEFI ノードの場合、EFI システムパーティション (ESP) イメージも Image サービス (glance) で利用可能でなければなりません。
- クリーニングおよびプロビジョニング用ネットワーク
手順
-
アンダークラウドホストに
stack
ユーザーとしてログインします。 stackrc
アンダークラウド認証情報ファイルを入手します。$ source ~/stackrc
Bare Metal Provisioning サービスの起動インターフェイスを
redfish-virtual-media
に設定します。(undercloud)$ openstack baremetal node set --boot-interface redfish-virtual-media <node>
-
<node>
はノード名に置き換えてください。
-
ESP イメージを定義します。
(undercloud)$ openstack baremetal node set --driver-info bootloader=<esp> <node>
-
<esp>
を Image サービス (glance) イメージの UUID または ESP イメージの URL に置き換えます。 -
<node>
はノード名に置き換えてください。
-
ベアメタルノードにポートを作成し、そのポートをベアメタルノード上の NIC の MAC アドレスに関連付けます。
(undercloud)$ openstack baremetal port create --pxe-enabled True \ --node <node_uuid> <mac_address>
-
<node_uuid>
をベアメタルノードの UUID に置き換えます。 -
<mac_address>
をベアメタルノードの NIC の MAC アドレスに置き換えます。
-
7.2.11. マルチディスク Ceph クラスターのルートディスクの定義
Ceph Storage ノードは通常、複数のディスクを使用します。Director は、複数のディスク設定でルートディスクを識別する必要があります。オーバークラウドイメージは、プロビジョニングプロセス中にルートディスクに書き込まれます。
ハードウェアプロパティーは、ルートディスクを識別するために使用されます。ルートディスクの識別に使用できるプロパティーの詳細は、ルートディスクを識別するプロパティー を参照してください。
手順
各ノードのハードウェアイントロスペクションからのディスク情報を確認します。
(undercloud)$ openstack baremetal introspection data save <node_uuid> --file <output_file_name>
-
<node_uuid>
をノードの UUID に置き換えます。 <output_file_name>
を、ノードイントロスペクションの出力を含むファイルの名前に置き換えます。たとえば、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" } ]
-
一意のハードウェアプロパティーを使用して、ノードのルートディスクを設定します。
(undercloud)$ openstack baremetal node set --property root_device='{<property_value>}' <node-uuid>
-
<property_value>
を、ルートディスクの設定に使用するイントロスペクションデータからの一意のハードウェアプロパティー値に置き換えます。 <node_uuid>
をノードの UUID に置き換えます。注記一意のハードウェアプロパティーは、ディスクを一意に識別するハードウェアイントロスペクションステップからの任意のプロパティーです。たとえば、次のコマンドは、ディスクのシリアル番号を使用してルートディスクを設定します。
(undercloud)$ openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
-
- 最初にネットワークから起動し、次にルートディスクから起動するように、各ノードの BIOS を設定します。
director は、ルートディスクとして使用する特定のディスクを把握します。openstack overcloud node provision
コマンドを実行すると、director はオーバークラウドをプロビジョニングし、ルートディスクにオーバークラウドのイメージを書き込みます。
7.2.12. ルートディスクを識別するプロパティー
以下の属性を定義すると、director がルートディスクを特定するのに役立ちます。
-
model
(文字列): デバイスの ID -
vendor
(文字列): デバイスのベンダー -
serial
(文字列): ディスクのシリアル番号 -
hctl
(文字列): SCSI のホスト、チャンネル、ターゲット、Lun -
size
(整数): デバイスのサイズ (GB 単位) -
wwn
(文字列): 一意のストレージ ID -
wwn_with_extension
(文字列): ベンダー拡張子を追加した一意のストレージ ID -
wwn_vendor_extension
(文字列): 一意のベンダーストレージ ID -
rotational
(ブール値): 回転式デバイス (HDD) には true、そうでない場合 (SSD) には false -
name
(文字列): デバイス名 (例: /dev/sdb1)
永続的な名前を持つデバイスには name
プロパティーを使用します。ノードの起動時に値が変更される可能性があるため、name
プロパティーを使用して永続的な名前を持たないデバイスのルートディスクを設定しないでください。
7.2.13. overcloud-minimal イメージの使用による Red Hat サブスクリプションエンタイトルメントの使用回避
Red Hat OpenStack Platform (RHOSP) デプロイメントのデフォルトイメージは overcloud-hardened-uefi-full.qcow2
です。overcloud-hardened-uefi-full.qcow2
イメージは、有効な Red Hat OpenStack Platform (RHOSP) サブスクリプションを使用します。サブスクリプションのエンタイトルメントを消費したくない場合は overcloud-minimal
イメージを使用して、有償の Red Hat サブスクリプションが限度に達するのを回避できます。これは、たとえば Ceph デーモンのみでノードをプロビジョニングする場合や、他の OpenStack サービスを実行したくないベアオペレーティングシステム (OS) をプロビジョニングする場合に役立ちます。overcloud-minimal
イメージの取得方法に関する詳細は、オーバークラウドノードのイメージの取得 を参照してください。
overcloud-minimal
イメージでは、標準の Linux ブリッジのみサポートされます。overcloud-minimal
イメージでは、Open vSwitch (OVS) はサポートされません。OVS は、Red Hat OpenStack Platform サブスクリプションエンタイトルメントを必要とする OpenStack サービスだからです。Ceph Storage ノードをデプロイするのに OVS は必要ありません。ovs_bond
を使用してボンディングを定義する代わりに、linux_bond
を使用します。linux_bond
の詳細は、Linux ボンディングの作成 を参照してください。
手順
overcloud-minimal
イメージと関連するカーネルおよび RAM ディスクをアンダークラウドの/var/lib/ironic/images/
にアップロードします。以下はファイルのアップロードの例です。
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ./images/ --os-image-name overcloud-minimal.qcow2 --update-existing --image-type os Image "file:///var/lib/ironic/images/overcloud-minimal.vmlinuz" was copied. +---------------------------------------------------------+-------------------+----------+ | Path | Name | Size | +---------------------------------------------------------+-------------------+----------+ | file:///var/lib/ironic/images/overcloud-minimal.vmlinuz | overcloud-minimal | 12190232 | +---------------------------------------------------------+-------------------+----------+ Image "file:///var/lib/ironic/images/overcloud-minimal.initrd" was copied. +--------------------------------------------------------+-------------------+----------+ | Path | Name | Size | +--------------------------------------------------------+-------------------+----------+ | file:///var/lib/ironic/images/overcloud-minimal.initrd | overcloud-minimal | 82284184 | +--------------------------------------------------------+-------------------+----------+ Image "file:///var/lib/ironic/images/overcloud-minimal.raw" was copied. +-----------------------------------------------------+-------------------+------------+ | Path | Name | Size | +-----------------------------------------------------+-------------------+------------+ | file:///var/lib/ironic/images/overcloud-minimal.raw | overcloud-minimal | 3242131456 | +-----------------------------------------------------+-------------------+------------+
-
overcloud-baremetal-deploy.yaml
ファイルを開きます。 overcloud-minimal
イメージを使用するノードのimage
プロパティーを追加または更新します。特定のノードまたはロールのすべてのノードでイメージをovercloud-minimal
に設定できます。特定のノード
- name: Ceph count: 3 instances: - hostname: overcloud-ceph-0 name: node00 image: href: 'file:///var/lib/ironic/images/overcloud-minimal.raw' kernel: 'file:///var/lib/ironic/images/overcloud-minimal.vmlinuz' ramdisk: 'file:///var/lib/ironic/images/overcloud-minimal.initrd' - hostname: overcloud-ceph-1 name: node01 image: href: file:///var/lib/ironic/images/overcloud-full-custom.qcow2 - hostname: overcloud-ceph-2 name: node02 image: href: file:///var/lib/ironic/images/overcloud-full-custom.qcow2
ロールのすべてのノード
- name: Ceph count: 3 defaults: image: href: 'file:///var/lib/ironic/images/overcloud-minimal.raw' kernel: 'file:///var/lib/ironic/images/overcloud-minimal.vmlinuz' ramdisk: 'file:///var/lib/ironic/images/overcloud-minimal.initrd' instances: - hostname: overcloud-ceph-0 name: node00 - hostname: overcloud-ceph-1 name: node01 - hostname: overcloud-ceph-2 name: node02
roles_data.yaml
ロール定義ファイルで、rhsm_enforce
パラメーターをFalse
に設定します。rhsm_enforce: False
プロビジョニングコマンドを実行します。
(undercloud)$ openstack overcloud node provision \ --stack stack \ --output /home/stack/templates/overcloud-baremetal-deployed.yaml \ /home/stack/templates/overcloud-baremetal-deploy.yaml
-
overcloud-baremetal-deployed.yaml
環境ファイルをopenstack overcloud deploy
コマンドに渡します。