第4章 デプロイ後の Bare Metal サービスの設定
本項では、デプロイ後のオーバークラウドの設定に必要な手順について説明します。
4.1. OpenStack Networking の設定
DHCP、PXE ブート、およびその他の必要な場合に OpenStack Networking が Bare Metal サービスと通信するように設定します。以下の手順では、ベアメタルマシンのをプロビジョニングに使用する単一のフラットなネットワークのユースケース向けに OpenStack Networking を設定します。 この設定では、ML2 プラグインと Open vSwitch エージェントを使用します。flat ネットワークのみがサポートされています。
以下の手順では、ベアメタルネットワークのインターフェースを使用してブリッジを作成し、リモートの接続をすべて切断します。
以下の手順に記載するステップはすべて、OpenStack Networking をホストするサーバーに root ユーザーとしてログインして実行する必要があります。
OpenStack Networking が Bare Metal サービスと通信するための設定
Identity に管理ユーザーとしてアクセスするためのシェルを設定します。
$ source ~/overcloudrc
ベアメタルインスタンスをプロビジョニングするためのフラットなネットワークを作成します。
$ openstack network create \ --provider-network-type flat \ --provider-physical-network baremetal \ --share NETWORK_NAME
NETWORK_NAME はこのネットワークの名前に置き換えます。仮想ネットワークの実装先となる物理ネットワークの名前 (この場合は
baremetal) は以前の手順で~/templates/network-environment.yamlにNeutronBridgeMappingsパラメーターで設定されています。フラットネットワーク上にサブネットを作成します。
$ openstack subnet create \ --network NETWORK_NAME \ --subnet-range NETWORK_CIDR \ --ip-version 4 \ --gateway GATEWAY_IP \ --allocation-pool start=START_IP,end=END_IP \ --dhcp SUBNET_NAME
以下の値を置き換えてください。
- SUBNET_NAME はサブネットの名前に置き換えます。
- NETWORK_NAME は、以前のステップで作成済みのプロビジョニングネットワークの名前に置き換えます。
- NETWORK_CIDR は、サブネットが示す IP アドレスブロックの Classless Inter-Domain Routing (CIDR) 表記に置き換えます。 START_IP で始まり END_IP で終る範囲で指定する IP アドレスブロックは、NETWORK_CIDR で指定されている IP アドレスブロックの範囲内に入る必要があります。
- GATEWAY_IP は新しいサブネットのゲートウェイとして機能するルーターインターフェースの IP アドレスまたはホスト名に置き換えます。このアドレスは、 NETWORK_CIDR で指定されている IP アドレスブロック内で、かつ START_IP で始まり END_IP で終わる範囲で指定されている IP アドレスブロック外である必要があります。
- START_IP は、Floating IP アドレスの割り当て元となる新規サブネット内の IP アドレス範囲の開始アドレスを示す IP アドレスに置き換えます。
- END_IP は、Floating IP アドレスの割り当て元となる新規サブネット内の IP アドレス範囲の終了アドレスを示す IP アドレスに置き換えます。
ネットワークとサブネットをルーターに接続して、メタデータ要求が OpenStack Networking サービスによって応答されるようにします。
$ openstack router create ROUTER_NAMEROUTER_NAMEはルーターの名前に置き換えます。ベアメタルのサブネットをこのルーターに追加します。
$ openstack router add subnet ROUTER_NAME BAREMETAL_SUBNET
ROUTER_NAME は、ルーターの名前に、BAREMETAL_SUBNET は以前に作成した ID またはサブネット名に置き換えます。これにより、
cloud-initからのメタデータ要求に応答することができます。
4.2. ノードのクリーニングの設定
デフォルトでは、ベアメタルサービスは、ノードのクリーニングに provisioning という名前のネットワークを使用するように設定されます。ただし、OpenStack Networking ではネットワーク名は一意ではないので、テナントが同じ名前を使用してネットワークを作成して Bare Metal サービスとの競合が発生する可能性があります。このため、ネットワーク名の代わりにネットワークの UUID を使用することを推奨します。
Bare Metal サービスを実行しているコントローラー上のプロバイダーネットワークの UUID を指定してクリーニングを設定します。
~/templates/ironic.yamlparameter_defaults: IronicCleaningNetwork: UUIDUUID は、以前のステップで作成されたベアメタルネットワークの UUID に置き換えます。
UUID は、
openstack network showで確認することができます。openstack network show NETWORK_NAME -f value -c id注記ネットワークの UUID は、オーバークラウドの初回のデプロイメントが完了するまで利用できないので、この設定はデプロイ後に実行する必要があります。
「オーバークラウドのデプロイ」の説明に従って
openstack overcloud deployコマンドを実行し、オーバークラウドを再デプロイして変更を適用します。注記各コントローラーで
ironic.confを更新することによって、オーバークラウドの再デプロイを回避することが可能です。ただし、OpenStack director のインストール環境におけるironic.confファイルの手動更新はサポートされていません。以下に記載する手順は便宜のためにのみ提供しています。以下の行をコメント解除して、
<None>をベアメタルネットワークの UUID に置き換えます。cleaning_network = <None>
Bare Metal サービスを再起動します。
# systemctl restart openstack-ironic-conductor.service
openstack overcloud deployコマンドでオーバークラウドを再デプロイすると、手動で加えていた変更はすべて元に戻るので、openstack overcloud deployを次回使用する前には、(前のステップで説明した) クリーニングの設定を~/templates/ironic.yamlに必ず追加してください。
4.2.1. 手動によるノードのクリーニング
ノードのクリーニングを手動で開始するには、そのノードが manageable の状態である必要があります。
ノードのクリーニングには 2 つのモードがあります。
メタデータのみのクリーニング: 対象のノード上の全ディスクからパーティションを削除します。この方法は、より高速なクリーンサイクルですが、パーティションテーブルのみが削除されるので、セキュリティーレベルはより低くなります。このモードは、信頼済みのテナント環境でのみ使用してください。
完全なクリーニング: ATA のセキュアな削除を使用するか、細断処理を行って、全ディスクから全データを削除します。処理が完了するには数時間かかる場合があります。
metadata のクリーニングを開始するには、以下のコマンドを実行します。
$ openstack workflow execution create manual_cleaning \
'{"node_uuid": "UUID", "clean_steps": [{"step": \
"erase_devices_metadata", "interface": "deploy"}]}'
full クリーニングを開始するには、以下のコマンドを実行します。
$ openstack workflow execution create manual_cleaning \
'{"node_uuid": "UUID", "clean_steps": [{"step": \
"erase_devices", "interface": "deploy"}]}'
manual_cleaning はワークフロー名です。UUID は、クリーニングするノードの UUID に置き換えてください。
クリーニングが正常に完了すると、ノードの状態は manageable に戻ります。状態が clean failed の場合には、last_error のフィールドで失敗の原因を確認してください。
4.3. ベアメタル用のフレーバーの作成
デプロイメントの一部として使用するフレーバーを作成する必要があります。このフレーバーの仕様 (メモリー、CPU、ディスク) はベアメタルノードが提供する仕様以下である必要があります。
Identity に管理ユーザーとしてアクセスするためのシェルを設定します。
$ source ~/overcloudrc
既存のフレーバーを一覧表示します。
$ openstack flavor list
Bare Metal サービス向けに新規フレーバーを作成します。
$ openstack flavor create \ --id auto --ram RAM \ --vcpus VCPU --disk DISK \ --property baremetal=true \ --public baremetal
RAMはメモリー量、VCPUは仮想 CPU 数、DISKはディスクストレージの値に置き換えます。baremetalプロパティーは、ベアメタルを仮想インスタンスと区別するために使用されます。指定したそれぞれの値を使用して新規フレーバーが作成されたことを確認します。
$ openstack flavor list
4.4. ベアメタルイメージの作成
デプロイメントには 2 セットのイメージが必要です。
-
デプロイイメージ は、Bare Metal サービスがベアメタルノードをブートしてユーザーイメージをベアメタルノードにコピーするのに使用されます。デプロイイメージは、
kernelイメージとramdiskで構成されます。 ユーザーイメージ は、ベアメタルノードにデプロイされるイメージです。ユーザーイメージにも
kernelイメージとramdiskイメージが含まれますが、追加でmainイメージも含まれます。メインイメージは、ルートパーティションイメージまたはディスク全体のイメージのいずれかです。- ディスク全体のイメージ は、パーティションテーブルとブートローダーが含まれたイメージです。ディスク全体のイメージを使用してデプロイされたノードはローカルブートをサポートするので、Bare Metal サービスはデプロイ後のノードのリブートは制御しません。
- ルートパーティションイメージ には、オペレーティングシステムのルートパーティションのみが含まれています。ルートパーティションを使用する場合には、デプロイイメージが Image サービスに読み込まれた後に、ノードのプロパティーにデプロイイメージをノードのブートイメージとして設定することができます。デプロイ後のノードのリブートでは netboot を使用してユーザーイメージをダウンロードします。
本項に記載する例では、ルートパーティションイメージを使用してベアメタルノードをプロビジョニングします。
4.4.1. デプロイイメージの準備
アンダークラウドでオーバークラウドをデプロイする際には、デプロイイメージはすでに使用されているので、作成する必要はありません。デプロイイメージは、以下に示したように、kernel イメージと ramdisk イメージの 2 つのイメージで構成されます。
ironic-python-agent.kernel ironic-python-agent.initramfs
これらのイメージは、削除してしまったり、別の場所でアンパックしたりしていない限りは、多くの場合、ホームディレクトリーにあります。 ホームディレクトリーにない場合でも、rhosp-director-images-ipa パッケージがインストールされているので、これらのイメージは /usr/share/rhosp-director-images/ironic-python-agent*.tar ファイル内にあります。
イメージを抽出して Image サービスにアップロードします。
$ openstack image create \ --container-format aki \ --disk-format aki \ --public \ --file ./ironic-python-agent.kernel bm-deploy-kernel $ openstack image create \ --container-format ari \ --disk-format ari \ --public \ --file ./ironic-python-agent.initramfs bm-deploy-ramdisk
4.4.2. ユーザーイメージの準備
最後に必要となるイメージは、ベアメタルノードにデプロイされるユーザーイメージです。ユーザーイメージには kernel と ramdisk に加えて、main イメージが含まれます。
- カスタマーポータル (ログインが必要) から Red Hat Enterprise Linux KVM ゲストイメージをダウンロードします。
DIB_LOCAL_IMAGE をダウンロードしたイメージとして定義します。
$ export DIB_LOCAL_IMAGE=rhel-server-7.4-x86_64-kvm.qcow2
diskimage-builderツールを使用してユーザーイメージを作成します。$ disk-image-create rhel7 baremetal -o rhel-image
これで kernel は
rhel-image.vmlinuzとして、初期 ramdisk はrhel-image.initrdとして抽出されます。イメージを Image サービスにアップロードします。
$ KERNEL_ID=$(openstack image create \ --file rhel-image.vmlinuz --public \ --container-format aki --disk-format aki \ -f value -c id rhel-image.vmlinuz) $ RAMDISK_ID=$(openstack image create \ --file rhel-image.initrd --public \ --container-format ari --disk-format ari \ -f value -c id rhel-image.initrd) $ openstack image create \ --file rhel-image.qcow2 --public \ --container-format bare \ --disk-format qcow2 \ --property kernel_id=$KERNEL_ID \ --property ramdisk_id=$RAMDISK_ID \ rhel-image
4.5. ベアメタルノードとしての物理マシンの追加
ベアメタルノードの登録には 2 つの方法があります。
- ノードの詳細情報を記載したインベントリーファイルを作成し、そのファイルを Bare Metal サービスにインポートしてからノードを利用できるようにします。
- 物理ノードをベアメタルノードとして登録してから、手動でハードウェア情報を追加し、各イーサネットの MAC アドレス用にポートを作成します。これらのステップは、overcloudrc ファイルが配置されている任意のノードで実行することができます。
本項では、両メソッドについて詳しく説明します。
物理マシンを登録した後には、新規リソースは Compute に直ちに通知されます。これは、Compute のリソーストラッカーが定期的に同期しているためです。次の定期タスクが実行されると変更が表示されるようになります。この値 scheduler_driver_task_period は /etc/nova/nova.conf で更新することができます。デフォルトの間隔は 60 秒です。
4.5.1. インベントリーファイルを使用したベアメタルノードの登録
ノードの詳細情報を記載した
overcloud-nodes.yamlを作成します。1 つのファイルで複数のノードを登録することが可能です。nodes: - name: node0 driver: pxe_ipmitool driver_info: ipmi_address: <IPMI_IP> ipmi_username: <USER> ipmi_password: <PASSWORD> properties: cpus: <CPU_COUNT> cpu_arch: <CPU_ARCHITECTURE> memory_mb: <MEMORY> local_gb: <ROOT_DISK> root_device: serial: <SERIAL> ports: - address: <PXE_NIC_MAC>以下の値を置き換えてください。
-
<IPMI_IP>はベアメタルコントローラーのアドレスに置き換えます。 -
<USER>はユーザー名に置き換えます。 -
<PASSWORD>はパスワードに置き換えます。 -
<CPU_COUNT>は CPU の数に置き換えます。 -
<CPU_ARCHITECTURE>は CPU のアーキテクチャータイプに置き換えます。 -
<MEMORY>はメモリー容量 (MiB 単位) に置き換えます。 -
<ROOT_DISK>はルートディスクの容量 (GiB 単位) に置き換えます。 <MAC_ADDRESS>は PXE ブートで使用する NIC の MAC アドレスに置き換えます。マシンに複数のディスクがある場合に、含める必要があるのは
root_deviceのみです。<SERIAL>は、デプロイメントに使用するディスクのシリアル番号に置き換えます。
-
Identity を管理ユーザーとして使用するためのシェルを設定します。
$ source ~/overcloudrc
インベントリーファイルを ironic にインポートします。
$ openstack baremetal create overcloud-nodes.yaml
ノードはこれで
enrollの状態となります。各ノードで deploy kernel とdeploy ramdisk を指定して、利用可能な状態にします。$ openstack baremetal node set NODE_UUID \ --driver-info deploy_kernel=KERNEL_UUID \ --driver-info deploy_ramdisk=INITRAMFS_UUID
以下の値を置き換えてください。
- NODE_UUID は、ノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。
KERNEL_UUID は、Image サービスにアップロードした kernel デプロイイメージの一意識別子に置き換えます。この値は以下のコマンドで確認します。
$ openstack image show bm-deploy-kernel -f value -c id
INITRAMFS_UUID は、Image サービスにアップロードした ramdisk イメージの一意識別子に置き換えます。この値は以下のコマンドで確認します。
$ openstack image show bm-deploy-ramdisk -f value -c id
ノードが正常に登録されたことを確認します。
$ openstack baremetal node list
ノードを登録した後にその状態が表示されるまで時間がかかる場合があります。
4.5.2. ベアメタルノードの手動登録
Identity を管理ユーザーとして使用するためのシェルを設定します。
$ source ~/overcloudrc
新規ノードを追加します。
$ openstack baremetal node create --driver pxe_impitool --name NAMEノードを作成するには、ドライバー名を指定する必要があります。この例では
pxe_impitoolを使用しています。異なるドライバーを使用するには、IronicEnabledDriversパラメーターを設定してそのドライバーを有効化する必要があります。サポートされているドライバーについての詳しい情報は、「付録A Bare Metal のドライバー」を参照してください。重要ノードの一意識別子を書き留めておきます。
ノードのドライバーの情報を更新して、Bare Metal サービスがノードを管理できるようにします。
$ openstack baremetal node set NODE_UUID \ --driver_info PROPERTY=VALUE \ --driver_info PROPERTY=VALUE
以下の値を置き換えてください。
- NODE_UUID は、ノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。
- PROPERTY は、ironic driver-properties コマンドで返された必要なプロパティーに置き換えます。
- VALUE は、プロパティーの有効な値に置き換えます。
ノードドライバーのデプロイカーネルとデプロイ RAM ディスクを指定します。
$ openstack baremetal node set NODE_UUID \ --driver-info deploy_kernel=KERNEL_UUID \ --driver-info deploy_ramdisk=INITRAMFS_UUID
以下の値を置き換えてください。
- NODE_UUID は、ノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。
- KERNEL_UUID は、Image サービスにアップロードされた .kernel イメージの一意識別子に置き換えます。
- INITRAMFS_UUID は、Image サービスにアップロードされた .initramfs イメージの一意識別子に置き換えます。
ノードのプロパティーを更新して、ノード上のハードウェアの仕様と一致するようにします。
$ openstack baremetal node set NODE_UUID \ --property cpus=CPU \ --property memory_mb=RAM_MB \ --property local_gb=DISK_GB \ --property cpu_arch=ARCH
以下の値を置き換えてください。
- NODE_UUID は、ノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。
- CPU は CPU の数に置き換えます。
- RAM_MB はメモリー (MB 単位) に置き換えます。
- DISK_GB はディスクのサイズ (GB 単位) に置き換えます。
- ARCH はアーキテクチャータイプに置き換えます。
オプション: ノードを設定して、初回のデプロイの後には、
ironic-conductorから PXE を使用する代わりに、そのノードのディスクにインストールされたローカルのブートローダーからリブートするようにします。ノードのプロビジョニングに使用するフレーバーでも、ローカルブートの機能を設定する必要があります。ローカルブートを有効にするには、ノードのデプロイに使用するイメージに grub2 が含まれる必要があります。ローカルブートを以下のように設定します。$ openstack baremetal node set NODE_UUID \ --property capabilities="boot_option:local"NODE_UUID は、ノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。
プロビジョニングネットワーク上の NIC の MAC アドレスを使用してポートを作成することにより、Bare Metal サービスにノードのネットワークカードを通知します。
$ openstack baremetal port create --node NODE_UUID MAC_ADDRESS
NODE_UUID は、ノードの一意識別子に置き換えます。MAC_ADDRESS は、PXE ブートに使用する NIC の MAC アドレスに置き換えます。
複数のディスクがある場合には、ルートデバイスのヒントを設定してください。これにより、デプロイメントに使用すべきディスクが deploy ramdisk に通知されます。
$ openstack baremetal node set NODE_UUID \ --property root_device={"PROPERTY": "VALUE"}
以下の値に置き換えてください。
- NODE_UUID は、ノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。
PROPERTY と VALUE は、デプロイメントに使用するディスクの情報に置き換えます (例:
root_device='{"size": 128}')。以下のプロパティーがサポートされています。
-
model(文字列): デバイスの識別子 -
vendor(文字列): デバイスのベンダー -
serial(文字列): ディスクのシリアル番号 -
hctl(文字列): SCSI 向けのホスト:チャネル:ターゲット:Lun -
size(整数):デバイスのサイズ (GB) -
wwn(文字列): ストレージの一意識別子 -
wwn_with_extension(文字列): ベンダー拡張が末尾に付いたストレージの一意識別子 -
wwn_vendor_extension(文字列): ベンダーのストレージの一意識別子 -
rotational(ブール値): 回転式デバイス (HDD) には true、そうでない場合 (SSD) には false。 name: デバイス名 (例: /dev/sdb1)。これは、永続デバイス名が付いたデバイスのみに使用してください。注記複数のプロパティーを指定する場合には、デバイスはそれらの全プロパティーと一致する必要があります。
-
ノードの設定を検証します。
$ openstack baremetal node validate NODE_UUID +------------+--------+---------------------------------------------+ | Interface | Result | Reason | +------------+--------+---------------------------------------------+ | boot | False | Cannot validate image information for node | | | | a02178db-1550-4244-a2b7-d7035c743a9b | | | | because one or more parameters are missing | | | | from its instance_info. Missing are: | | | | ['ramdisk', 'kernel', 'image_source'] | | console | None | not supported | | deploy | False | Cannot validate image information for node | | | | a02178db-1550-4244-a2b7-d7035c743a9b | | | | because one or more parameters are missing | | | | from its instance_info. Missing are: | | | | ['ramdisk', 'kernel', 'image_source'] | | inspect | None | not supported | | management | True | | | network | True | | | power | True | | | raid | True | | | storage | True | | +------------+--------+---------------------------------------------+NODE_UUID は、ノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。上記のコマンドの出力には、各インターフェースが
TrueまたはNoneのいずれかと報告されるはずです。Noneとマークされたインターフェースは、設定していないか、ドライバーがサポートしていないインターフェースです。注記「ramdisk」、「kernel」、「image_source」のパラメーターが指定されていないことが原因となって、インターフェースでエラーが発生する場合があります。Compute サービスは、デプロイメントプロセスの最初に未指定のパラメーターを設定するので、この結果は問題ありません。
4.6. ホストアグリゲートを使用した物理/仮想マシンのプロビジョニングの分離
OpenStack Compute は、ホストアグリゲートを使用してアベイラビリティーゾーンをパーティション分割し、特定の共通プロパティーが指定されたノードをグループ化します。インスタンスがプロビジョニングされると、Compute のスケジューラーがフレーバーのプロパティーをホストアグリゲートに割り当てられたプロパティーと比較して、インスタンスが正しいアグリゲート内の正しいホストに (物理マシン上または仮想マシンとして) プロビジョニングされたことを確認します。
以下の手順は、次の作業の方法を説明します。
-
baremetalプロパティーをフレーバーに追加して、trueまたはfalseに設定します。 -
ベアメタルホスト用とコンピュートノード用にホストアグリゲートを別々に作成し、
baremetalプロパティーが一致するようにします。1 つのアグリゲートでグループ化されたノードは、このプロパティーを継承します。
ホストアグリゲートの作成
ベアメタル用のフレーバーで
baremetalプロパティーをtrueに設定します。$ openstack flavor set baremetal --property baremetal=true
仮想インスタンスに使用するフレーバーには
baremetalプロパティーをfalseに設定します。$ openstack flavor set FLAVOR_NAME --property baremetal=falsebaremetal-hostsという名前のホストアグリゲートを作成します。$ openstack aggregate create --property baremetal=true baremetal-hosts
各コントローラーノードを
baremetal-hostsアグリゲートに追加します。$ openstack aggregate add host baremetal-hosts HOSTNAME注記NovaIronicサービスでコンポーザブルロールを作成した場合には、このサービスのあるノードをすべてbaremetal-hostsアグリゲートに追加します。デフォルトでは、NovaIronicサービスがあるのはコントローラーノードのみです。virtual-hostsという名前のホストアグリゲートを作成します。$ openstack aggregate create --property baremetal=false virtual-hosts
各コンピュートノードを
virtual-hostsアグリゲートに追加します。$ openstack aggregate add host virtual-hosts HOSTNAMEオーバークラウドのデプロイ時に以下の Compute フィルタースケジューラーを追加していなかった場合には、この時点で /etc/nova/nova.conf の
scheduler_default_filters下に追加してください。AggregateInstanceExtraSpecsFilter

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.