Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

第4章 デプロイ後の Bare Metal サービスの設定

本項では、デプロイ後のオーバークラウドの設定に必要な手順について説明します。

4.1. OpenStack Networking の設定
リンクのコピー

DHCP、PXE ブート、およびその他の必要な場合に OpenStack Networking が Bare Metal サービスと通信するように設定します。ベアメタルネットワークを設定するには、2 とおりの方法があります。

  • Ironic Conductor サービス用にフラットなベアメタルネットワークを使用する。このネットワークは、コントロールプレーンネットワーク上の Ironic サービスにルーティングする必要があります。
  • カスタムのコンポーザブルネットワークを使用して、オーバークラウドに Ironic サービスを実装する。

本項の手順に従って、ベアメタルマシンのプロビジョニングに使用する単一のフラットなネットワーク向けに OpenStack Networking を設定する、あるいは未使用の分離ネットワークまたはフラットネットワークに依存しない新たなコンポーザブルネットワークを設定します。この設定では、ML2 プラグインと Open vSwitch エージェントを使用します。

以下の手順に記載するすべてのステップを、OpenStack Networking サービスをホストするサーバーに root ユーザーとしてログインして実行します。

  1. Identity に管理ユーザーとしてアクセスするためのシェルを設定します。 

    $ source ~/overcloudrc

  2. ベアメタルインスタンスをプロビジョニングするためのフラットなネットワークを作成します。 

    $ openstack network create \
  --provider-network-type flat \
  --provider-physical-network baremetal \
  --share NETWORK_NAME

    NETWORK_NAME はこのネットワークの名前に置き換えます。仮想ネットワークの実装先となる物理ネットワークの名前 (この場合は baremetal) は以前の手順で ~/templates/network-environment.yaml に NeutronBridgeMappings パラメーターで設定されています。

  3. フラットネットワーク上にサブネットを作成します。 

    $ 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 アドレスに置き換えます。

  4. ネットワークとサブネット用のルーターを作成して、OpenStack Networking サービスがメタデータ要求に応答するようにします。 

    $ openstack router create ROUTER_NAME

    ROUTER_NAME はルーターの名前に置き換えます。

  5. ネットワークを新たなルーターに接続します。 

    $ openstack router add network ROUTER_NAME NETWORK

    ROUTER_NAME をルーターの名前に、NETWORK を以前ステップで作成したネットワークの ID または名前に、それぞれ置き換えます。

  6. サブネットを新たなルーターに接続します。 

    $ openstack router add subnet ROUTER_NAME BAREMETAL_SUBNET

    ROUTER_NAME をルーターの名前に、BAREMETAL_SUBNET を以前ステップで作成したサブネットの ID または名前に、それぞれ置き換えます。これにより、cloud-init からのメタデータ要求に応答することができ、ノードを設定することができます。

  1. デプロイメント時に作成する OcProvisioning ネットワークと一致する VLAN ID で、VLAN ネットワークを作成します。クリーニングネットワークのデフォルト名と一致するように、新規ネットワークの名前を provisioning と設定します。 

    (overcloud) [stack@host01 ~]$ openstack network create \
  --share \
  --provider-network-type vlan \
  --provider-physical-network datacentre \
  --provider-segment 205 provisioning

    オーバークラウドネットワークの名前が provisioning ではない場合にはコントローラーにログオンし、以下のコマンドを実行して名前を変更し、ネットワークを再起動します。 

    heat-admin@overcloud-controller-0 ~]$ sudo vi /var/lib/config-data/puppet-generated/ironic/etc/ironic/ironic.conf
     
    heat-admin@overcloud-controller-0 ~]$ sudo docker restart ironic_conductor

4.2. ノードのクリーニングの設定
リンクのコピー

デフォルトでは、ベアメタルサービスは、ノードのクリーニングに provisioning という名前のネットワークを使用するように設定されます。ただし、OpenStack Networking ではネットワーク名は一意ではないので、テナントが同じ名前を使用してネットワークを作成して Bare Metal サービスとの競合が発生する可能性があります。このため、ネットワーク名の代わりにネットワークの UUID を使用することを推奨します。

  1. Bare Metal サービスを実行しているコントローラー上のプロバイダーネットワークの UUID を指定してクリーニングを設定します。

    ~/templates/ironic.yaml 

    parameter_defaults:
    IronicCleaningNetwork: UUID

    UUID は、以前のステップで作成されたベアメタルネットワークの UUID に置き換えます。

    UUID は、openstack network show で確認することができます。 

    openstack network show NETWORK_NAME -f value -c id
    注記

    ネットワークの UUID は、オーバークラウドの初回のデプロイメントが完了するまで利用できないので、この設定はデプロイ後に実行する必要があります。

  2. 「オーバークラウドのデプロイ」の説明に従って openstack overcloud deploy コマンドを実行し、オーバークラウドを再デプロイして変更を適用します。

  3. 以下の行をコメント解除して、<None> をベアメタルネットワークの UUID に置き換えます。 

    cleaning_network = <None>

  4. 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 baremetal node clean UUID \
    --clean-steps [{"interface": "deploy", "step": "erase_devices_metadata"}]

full クリーニングを開始するには、以下のコマンドを実行します。 

$ openstack baremetal node clean UUID \
    --clean-steps [{"interface": "deploy", "step": "erase_devices"}]

UUID は、クリーニングするノードの UUID に置き換えてください。

クリーニングが正常に完了すると、ノードの状態は manageable に戻ります。状態が clean failed の場合には、last_error のフィールドで失敗の原因を確認してください。

4.3. ベアメタル用のフレーバーの作成
リンクのコピー

デプロイメントの一部として使用するフレーバーを作成する必要があります。このフレーバーの仕様 (メモリー、CPU、ディスク) はベアメタルノードが提供する仕様以下である必要があります。

  1. Identity に管理ユーザーとしてアクセスするためのシェルを設定します。 

    $ source ~/overcloudrc

  2. 既存のフレーバーを一覧表示します。 

    $ openstack flavor list

  3. Bare Metal サービス向けに新規フレーバーを作成します。 

    $ openstack flavor create \
  --id auto --ram RAM \
  --vcpus VCPU --disk DISK \
  --property baremetal=true \
  --public baremetal

    RAM はメモリー量、VCPU は仮想 CPU 数、DISK はディスクストレージの値に置き換えます。baremetal プロパティーは、ベアメタルを仮想インスタンスと区別するために使用されます。

  4. 指定したそれぞれの値を使用して新規フレーバーが作成されたことを確認します。 

    $ 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 イメージが含まれます。これらのパッケージをダウンロードしてインストールするには、初めにすべてのディスクイメージの環境変数を要件に合わせて設定する必要があります。

4.4.2.1. ディスクイメージの環境変数
リンクのコピー

ディスクイメージの構築プロセスとして、director にはベースイメージと、新規オーバークラウドイメージのパッケージを取得するための登録情報が必要です。これらの属性は、以下に示す Linux の環境変数を使用して定義します。

注記

イメージの構築プロセスにより、イメージは一時的に Red Hat サブスクリプションに登録され、システムがイメージの構築プロセスを完了すると登録を解除します。

ディスクイメージを構築するには、Linux の環境変数をお使いの環境と要件に応じて設定します。

DIB_LOCAL_IMAGE
ディスクイメージ全体のベースに使用するローカルイメージを設定します。
REG_ACTIVATION_KEY
登録プロセスにおいて、ログイン情報の代わりにアクティベーションキーを使用します。
REG_AUTO_ATTACH
最も互換性のあるサブスクリプションを自動的にアタッチするかどうかを定義します。
REG_BASE_URL
イメージのパッケージが含まれるコンテンツ配信サーバーのベース URL。カスタマーポータルサブスクリプション管理のデフォルトのプロセスでは https://cdn.redhat.com を使用します。Red Hat Satellite 6 サーバーを使用している場合は、このパラメーターをお使いの Satellite サーバーのベース URL に設定します。
REG_ENVIRONMENT
1 つの組織内の 1 つの環境に登録します。
REG_METHOD
登録の方法を設定します。Red Hat カスタマーポータルに登録するには portal を使用します。Red Hat Satellite 6 で登録するには、satellite を使用します。
REG_ORG
イメージを登録する組織
REG_POOL_ID
製品のサブスクリプション情報のプール ID
REG_PASSWORD
イメージを登録するユーザーアカウントのパスワードを指定します。
REG_REPOS
リポジトリー名のコンマ区切り文字列。この文字列の各リポジトリーは subscription-manager で有効化されます。
REG_SERVER_URL
使用するサブスクリプションサービスのホスト名を指定します。Red Hat カスタマーポータルの場合のデフォルトは subscription.rhn.redhat.com です。Red Hat Satellite 6 サーバーを使用する場合は、このパラメーターをお使いの Satellite サーバーのホスト名に設定します。
REG_USER
イメージを登録するアカウントのユーザー名を指定します。

4.4.3. ユーザーイメージのインストール
リンクのコピー

  1. カスタマーポータル (ログインが必要) から Red Hat Enterprise Linux KVM ゲストイメージをダウンロードします。

  2. DIB_LOCAL_IMAGE をダウンロードしたイメージとして定義します。 

    $ export DIB_LOCAL_IMAGE=rhel-server-7.4-x86_64-kvm.qcow2

  3. 登録情報を設定します。Red Hat カスタマーポータルを使用する場合には、以下の情報を設定する必要があります。 

    $ export REG_USER='USER_NAME'
$ export REG_PASSWORD='PASSWORD'
$ export REG_AUTO_ATTACH=true
$ export REG_METHOD=portal
$ export https_proxy='IP_address:port' (if applicable)
$ export http_proxy='IP_address:port' (if applicable)

    Red Hat Satellite を使用する場合には、以下の情報を設定する必要があります。 

    $ export REG_USER='USER_NAME'
$ export REG_PASSWORD='PASSWORD'
$ export REG_SAT_URL='<SATELLITE URL>'
$ export REG_ORG='<SATELLITE ORG>'
$ export REG_ENV='<SATELLITE ENV>'
$ export REG_METHOD=<METHOD>

    オフラインのリポジトリーがある場合には、DIB_YUM_REPO_CONF をローカルリポジトリーの設定として定義することができます。 

    $ export DIB_YUM_REPO_CONF=<path-to-local-repository-config-file>

  4. diskimage-builder ツールを使用してユーザーイメージを作成します。 

    $ disk-image-create rhel7 baremetal -o rhel-image

    これで kernel は rhel-image.vmlinuz として、初期 ramdisk は rhel-image.initrd として抽出されます。

  5. イメージを 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. デプロイプロセスの概要
リンクのコピー

プロビジョニングプロセスでは、デプロイインターフェースが重要な役割を果たします。デプロイインターフェースはデプロイメントをオーケストレーションし、イメージをターゲットのディスクに転送するメカニズムを定義します。

前提条件

  • ironic-conductor を実行する Bare Metal サービスノードに設定された依存関係パッケージ
  • OpenStack Compute (nova) が Bare Metal サービスのエンドポイントを使用するように設定されていること。
  • 利用可能なハードウェア用にフレーバーが作成され、nova が正しいフレーバーから新規ノードを起動すること。

  • Glance で以下のイメージが利用可能であること。

    • bm-deploy-kernel
    • bm-deploy-ramdisk
    • user-image
    • user-image-vmlinuz
    • user-image-initrd
  • Ironic API サービスに登録するためのハードウェア

ワークフロー

標準的なデプロイプロセスを理解するためのワークフローを、以下の例に示します。使用する ironic ドライバーインターフェースによって、ステップの一部が異なる場合があります。

  1. Nova スケジューラーが Nova API からブートインスタンスのリクエストを受け取る。
  2. Nova スケジューラーが該当するハイパーバイザーを識別し、ターゲットの物理ノードを識別する。
  3. Nova Compute マネージャーが選択したハイパーバイザーのリソースを要求する。
  4. Nova のブートリクエストが指定するネットワークインターフェースに基づき、Nova Compute マネージャーがバインド前のテナント仮想インターフェース (VIF) を Networking サービスに作成する。

  5. Nova Compute が Nova Compute の仮想レイヤーから driver.spawn を呼び出し、必要なすべての情報が含まれる子タスクを作成する。子タスク作成プロセス中、仮想ドライバーは以下のステップを完了します。

    1. デプロイイメージ、インスタンスの UUID、要求された能力、およびフレーバーの特性に関する情報で、ターゲットの ironic ノードを更新する。
    2. ironic API をコールして、ターゲットノードの電源およびデプロイインターフェースを検証する。
    3. VIF をノードにアタッチする。それぞれの neutron ポートは、任意の ironic ポートまたはグループにアタッチすることができます。ポートグループがポートに優先します。
    4. コンフィグドライブを生成する。
  6. Nova ironic 仮想ドライバーが、Ironic API を使用してベアメタルノードに対応する Ironic conductor にデプロイ要求を発行する。
  7. 仮想インターフェースが接続され、PXE/TFTP オプションを設定するために Neutron API が DHCP を更新する。
  8. ironic ノードのブートインターフェースが (i)PXE 設定を準備し、デプロイカーネルおよび ramdisk をキャッシュする。
  9. ironic ノードの管理インターフェースがコマンドを発行し、ノードのネットワークブートを有効にする。
  10. 必要に応じて、ironic ノードのデプロイインターフェースがインスタンスイメージ、カーネル、および ramdisk をキャッシュする。
  11. ironic ノードの電源インターフェースがノードに電源投入を指示する。
  12. ノードがデプロイ ramdisk を起動する。
  13. iSCSI デプロイメントの場合には、conductor が iSCSI 経由でイメージを物理ノードにコピーする。直接デプロイメントの場合には、デプロイ ramdisk が一時 URL からイメージをダウンロードする。この URL は、Swift API と互換性のあるオブジェクトストアまたは HTTP の URL でなければなりません。
  14. ノードのブートインターフェースがインスタンスイメージを参照するように PXE 設定を切り替え、ramdisk エージェントにノードのソフトパワーオフを指示する。ソフトパワーオフに失敗した場合には、ベアメタルノードの電源は IPMI/BMC により切断されます。
  15. デプロイインターフェースがネットワークインターフェースにすべてのプロビジョニングポートの削除を指示し、テナントポートをノードにバインドし、ノードの電源を投入する。

これで、新規ベアメタルノードのプロビジョニングの状態が active になります。

4.5.1. 直接デプロイインターフェースの設定
リンクのコピー

iSCSI デプロイインターフェースがデフォルトのデプロイインターフェースです。ただし、直接デプロイインターフェースを有効にして、イメージを HTTP の保管場所からターゲットディスクにダウンロードすることができます。

注記

オーバークラウドノードのメモリー tmpfs には、少なくとも 6 GB の RAM が必要です。

手順

  1. カスタム環境ファイル /home/stack/undercloud_custom_env.yaml を作成または変更して、IronicDefaultDeployInterface を指定します。 

    parameter_defaults:
  IronicDefaultDeployInterface: direct

iscsi を使用するようにノードを登録する場合には、IronicDefaultDeployInterface パラメーターに iscsi の値を含める必要があります。 

parameter_defaults:
  IronicDefaultDeployInterface: direct,iscsi

  1. カスタム環境ファイルを undercloud.conf ファイルの DEFAULT セクションに追加します。 

    custom_env_files = /home/stack/undercloud_custom_env.yaml

  2. アンダークラウドのインストールを実施します。 

    $ openstack undercloud install

ノードの作成または更新時に、デプロイインターフェースを指定することもできます。

+ 

$ openstack baremetal node create --driver ipmi --deploy-interface direct
$ openstack baremetal node set <NODE> --deploy-interface direct

4.6. ベアメタルノードとしての物理マシンの追加
リンクのコピー

ベアメタルノードの登録には 2 つの方法があります。

  1. ノードの詳細情報を記載したインベントリーファイルを作成し、そのファイルを Bare Metal サービスにインポートしてからノードを利用できるようにします。
  2. 物理ノードをベアメタルノードとして登録してから、手動でハードウェア情報を追加し、各イーサネットの MAC アドレス用にポートを作成します。これらのステップは、overcloudrc ファイルが配置されている任意のノードで実行することができます。

本項では、両メソッドについて詳しく説明します。

物理マシンを登録した後には、新規リソースは Compute に直ちに通知されます。これは、Compute のリソーストラッカーが定期的に同期しているためです。次の定期タスクが実行されると変更が表示されるようになります。この値 scheduler_driver_task_period は /etc/nova/nova.conf で更新することができます。デフォルトの間隔は 60 秒です。

4.6.1. インベントリーファイルを使用したベアメタルノードの登録
リンクのコピー

  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> は、デプロイメントに使用するディスクのシリアル番号に置き換えます。

  2. Identity を管理ユーザーとして使用するためのシェルを設定します。 

    $ source ~/overcloudrc

  3. インベントリーファイルを ironic にインポートします。 

    $ openstack baremetal create overcloud-nodes.yaml
  4. これで、ノードは enroll の状態となります。

  5. 各ノードでデプロイカーネルとデプロイ 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

  6. ノードのプロビジョニング状態を available に設定します。 

    $ openstack baremetal node manage _NODE_UUID_
$ openstack baremetal node provide _NODE_UUID_

    ノードのクリーニングを有効にしている場合には、Bare Metal サービスがノードをクリーニングします。

  7. ノードが正常に登録されたことを確認します。 

    $ openstack baremetal node list

    ノードを登録した後にその状態が表示されるまで時間がかかる場合があります。

4.6.2. ベアメタルノードの手動登録
リンクのコピー

  1. Identity を管理ユーザーとして使用するためのシェルを設定します。 

    $ source ~/overcloudrc

  2. 新規ノードを追加します。 

    $ openstack baremetal node create --driver pxe_impitool --name NAME

    ノードを作成するには、ドライバー名を指定する必要があります。この例では pxe_impitool を使用しています。異なるドライバーを使用するには、IronicEnabledDrivers パラメーターを設定してそのドライバーを有効化する必要があります。サポートされているドライバーについての詳しい情報は、「付録A Bare Metal のドライバー」を参照してください。

    重要

    ノードの一意識別子を書き留めておきます。

  3. ノードのドライバーの情報を更新して、Bare Metal サービスがノードを管理できるようにします。 

    $ openstack baremetal node set NODE_UUID \
  --driver_info PROPERTY=VALUE \
  --driver_info PROPERTY=VALUE

    以下の値を置き換えてください。

    • NODE_UUID は、ノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。
    • PROPERTY は、ironic driver-properties コマンドで返された必要なプロパティーに置き換えます。
    • VALUE は、プロパティーの有効な値に置き換えます。

  4. ノードドライバーのデプロイカーネルとデプロイ 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 イメージの一意識別子に置き換えます。

  5. ノードのプロパティーを更新して、ノード上のハードウェアの仕様と一致するようにします。 

    $ 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 はアーキテクチャータイプに置き換えます。

  6. オプション: ノードを設定して、初回のデプロイの後には、ironic-conductor から PXE を使用する代わりに、そのノードのディスクにインストールされたローカルのブートローダーからリブートするようにします。ノードのプロビジョニングに使用するフレーバーでも、ローカルブートの機能を設定する必要があります。ローカルブートを有効にするには、ノードのデプロイに使用するイメージに grub2 が含まれる必要があります。ローカルブートを以下のように設定します。 

    $ openstack baremetal node set NODE_UUID \
  --property capabilities="boot_option:local"

    NODE_UUID は、ノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。

  7. プロビジョニングネットワーク上の NIC の MAC アドレスを使用してポートを作成することにより、Bare Metal サービスにノードのネットワークカードを通知します。 

    $ openstack baremetal port create --node NODE_UUID MAC_ADDRESS

    NODE_UUID は、ノードの一意識別子に置き換えます。MAC_ADDRESS は、PXE ブートに使用する NIC の MAC アドレスに置き換えます。

  8. 複数のディスクがある場合には、ルートデバイスのヒントを設定してください。これにより、デプロイメントに使用すべきディスクが 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)。これは、永続デバイス名が付いたデバイスのみに使用してください。

        注記

        複数のプロパティーを指定する場合には、デバイスはそれらの全プロパティーと一致する必要があります。

  9. ノードの設定を検証します。 

    $ 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.7. ホストアグリゲートを使用した物理/仮想マシンのプロビジョニングの分離
リンクのコピー

OpenStack Compute は、ホストアグリゲートを使用してアベイラビリティーゾーンをパーティション分割し、特定の共通プロパティーが指定されたノードをグループ化します。インスタンスがプロビジョニングされると、Compute のスケジューラーがフレーバーのプロパティーをホストアグリゲートに割り当てられたプロパティーと比較して、インスタンスが正しいアグリゲート内の正しいホストに (物理マシン上または仮想マシンとして) プロビジョニングされたことを確認します。

以下の手順は、次の作業の方法を説明します。

  • baremetal プロパティーをフレーバーに追加して、true または false に設定します。
  • ベアメタルホスト用とコンピュートノード用にホストアグリゲートを別々に作成し、baremetal プロパティーが一致するようにします。1 つのアグリゲートでグループ化されたノードは、このプロパティーを継承します。

ホストアグリゲートの作成

  1. ベアメタル用のフレーバーで baremetal プロパティーを true に設定します。 

    $ openstack flavor set baremetal --property baremetal=true

  2. 仮想インスタンスに使用するフレーバーには baremetal プロパティーを false に設定します。 

    $ openstack flavor set FLAVOR_NAME --property baremetal=false

  3. baremetal-hosts という名前のホストアグリゲートを作成します。 

    $ openstack aggregate create --property baremetal=true baremetal-hosts

  4. 各コントローラーノードを baremetal-hosts アグリゲートに追加します。 

    $ openstack aggregate add host baremetal-hosts HOSTNAME
    注記

    NovaIronic サービスでコンポーザブルロールを作成した場合には、このサービスのあるノードをすべて baremetal-hosts アグリゲートに追加します。デフォルトでは、NovaIronic サービスがあるのはコントローラーノードのみです。

  5. virtual-hosts という名前のホストアグリゲートを作成します。 

    $ openstack aggregate create --property baremetal=false virtual-hosts

  6. 各コンピュートノードを virtual-hosts アグリゲートに追加します。 

    $ openstack aggregate add host virtual-hosts HOSTNAME

  7. オーバークラウドのデプロイ時に以下の Compute フィルタースケジューラーを追加していなかった場合には、この時点で /etc/nova/nova.conf の scheduler_default_filters 下に追加してください。 

    AggregateInstanceExtraSpecsFilter
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hatトップに戻る