7.2. ベアメタルオーバークラウドノードのプロビジョニング

Red Hat OpenStack Platform (RHOSP) 環境を設定するには、次のタスクを実行する必要があります。

  1. オーバークラウドのベアメタルノードを登録します。
  2. ベアメタルノードのハードウェアのインベントリーをディレクターに提供します。
  3. ノード定義ファイルで、ベアメタルノードの数量、属性、およびネットワークレイアウトを設定します。
  4. ベアメタルノードに、指定のノードとこのノードを合致させるリソースクラスを割り当てます。

プロファイルを一致させてオーバークラウドノードを指定するなど、追加のオプションのタスクを実行することもできます。

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

ディレクターには、ノードのハードウェアと電源管理の詳細を指定するノード定義テンプレートが必要です。このテンプレートは、JSON 形式の nodes.json または YAML 形式の nodes.yaml で作成できます。

手順

  1. ノードをリスト表示する 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
    ノードの論理名
    ポート

    特定の 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 アドレス
  2. テンプレートのフォーマットと構文を確認します。

    $ source ~/stackrc
    (undercloud)$ openstack overcloud node import --validate-only ~/nodes.json
  3. テンプレートファイルをstack ユーザーのホームディレクトリー (/home/stack/nodes.json) に保存します。
  4. テンプレートを director にインポートして、各ノードをテンプレートから director に登録します。

    (undercloud)$ openstack overcloud node import ~/nodes.json
  5. ノードの登録および設定が完了するまで待ちます。完了したら、ノードが 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 アドレスごとにポートを作成できます。

ヒント

自動イントロスペクションの代わりに、ベアメタルノードのハードウェア情報をディレクターに手動で提供できます。詳細は、ベアメタルノードのハードウェア情報の手動設定 を参照してください。

前提条件

  • オーバークラウドのベアメタルノードを登録しました。

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. stackrc アンダークラウド認証情報ファイルを入手します。

    $ source ~/stackrc
  3. pre-introspection 検証グループを実行して、プリイントロスペクションの要件を確認します。

    (undercloud)$ validation run --group pre-introspection \
     --inventory <inventory_file>
    • <inventory_file> ファイルを Ansible インベントリーファイルの名前および場所に置き換えます (例: ~/tripleo-deploy/undercloud/tripleo-ansible-inventory.yaml)。

      注記

      検証を実行すると、出力の Reasons 列は 79 文字に制限されます。検証結果を完全に表示するには、検証ログファイルを表示します。

  4. 検証レポートの結果を確認します。
  5. オプション: 特定の検証からの詳細な出力を確認します。

    (undercloud)$ validation history get --full <UUID>
    • <UUID> は、確認するレポートの特定の検証の UUID に置き換えます。

      重要

      検証結果が FAILED であっても、Red Hat OpenStack Platform のデプロイや実行が妨げられることはありません。ただし、FAILED の検証結果は、実稼働環境で問題が発生する可能性があることを意味します。

  6. 各ノードのハードウェア属性を検証します。すべてのノードまたは特定のノードのハードウェア属性を検査できます。

    • すべてのノードのハードウェア属性を検査します。

      (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 に置き換えます。
  7. 別のターミナルウィンドウで、イントロスペクションの進捗ログを監視します。

    (undercloud)$ sudo tail -f /var/log/containers/ironic-inspector/ironic-inspector.log
    重要

    イントロスペクションプロセスが完了するまで実行されていることを確認します。イントロスペクションは通常、ベアメタルノードの場合 15 分かかります。ただし、イントロスペクションネットワークのサイズが正しくないと、時間がかかる可能性があり、イントロスペクションが失敗する可能性があります。

  8. オプション: 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 を設定しました。詳細は、オーバークラウドノードの登録 を参照してください。

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. stackrc アンダークラウド認証情報ファイルを入手します。

    $ source ~/stackrc
  3. ノードドライバーのデプロイカーネルとデプロイ 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) に置き換えます。
  4. ノードの属性を更新して、ノード上のハードウェアの仕様と一致するようにします。

    (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> は、アーキテクチャータイプに置き換えます。
  5. オプション: 各ノードの IPMI 暗号スイートを指定します。

    (undercloud)$ openstack baremetal node set <node> \
     --driver-info ipmi_cipher_suite=<version>
    • <node> をベアメタルノードの ID に置き換えてください。
    • <version> は、ノードで使用する暗号スイートのバージョンに置き換えます。以下の有効な値のいずれかに設定します。

      • 3 - ノードは SHA1 暗号スイートで AES-128 を使用します。
      • 17 - ノードは SHA256 暗号スイートで AES-128 を使用します。
  6. オプション: 複数のディスクがある場合は、ルートデバイスのヒントを設定して、デプロイメントに使用するディスクをデプロイ 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)。このプロパティーは、永続デバイス名が付いたデバイスにのみ使用してください。

        注記

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

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

    (undercloud)$ openstack baremetal port create --node <node_uuid> <mac_address>
    • <node_uuid> をベアメタルノードの一意の ID に置き換えます。
    • <mac_address> は、PXE ブートに使用する NIC の MAC アドレスに置き換えます。
  8. ノードの設定を検証します。

    (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 など、ノード定義ファイルで設定したノード仕様が含まれています。オーバークラウドをデプロイする際に、このファイルをデプロイメントコマンドに追加します。プロビジョニングプロセスでは、ノード定義ファイル内の各ノードまたはロールに対して定義されたすべてのネットワークのポートリソースもプロビジョニングされます。

前提条件

手順

  1. source コマンドで stackrc アンダークラウド認証情報ファイルを読み込みます。

    $ source ~/stackrc
  2. overcloud-baremetal-deploy.yaml ノード定義ファイルを作成し、プロビジョニングするロールごとにノード数を定義します。たとえば、3 つのコントローラーノードと 3 つのコンピュートノードをプロビジョニングするには、以下の設定を overcloud-baremetal-deploy.yaml ファイルに追加します。

    - name: Controller
      count: 3
    - name: Compute
      count: 3
  3. オプション: 予測ノード配置を設定します。たとえば、以下の設定を使用すると、3 つのコントローラーノードがノード node00node01、および node02 に、3 つのコンピュートノードがノード node04node05、および 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
  4. オプション: デフォルトでは、プロビジョニングプロセスは 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

  5. ロールのすべてのノードのネットワークレイアウト、または特定のノードのネットワークレイアウトを定義します。

    特定のノード

    次の例では、特定のコントローラーノードのネットワークをプロビジョニングし、予測可能な 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 テンプレートを作成できます。
  6. オプション: デフォルトのディスクパーティションサイズが要件を満たさない場合は、ディスクパーティションサイズの割り当てを設定します。たとえば、/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> を、ログファイルに割り当てるディスクのサイズに置き換えます。
  7. Object Storage サービス (swift) とディスク全体のオーバークラウドイメージ overcloud-hardened-uefi-full を使用する場合に、ディスクのサイズと /var および /srv のストレージ要件に基づいて /srv パーティションのサイズを設定する必要があります。詳細は、Object Storage サービスのディスクパーティション全体の設定 を参照してください。
  8. オプション: カスタムリソースクラスまたはプロファイル機能を使用して、オーバークラウドノードを特定のロールに指定します。詳細は、リソースクラスを一致させることによるオーバークラウドノードのロールの指定 および プロファイルを一致させることによるオーバークラウドノードのロールの指定 を参照してください。
  9. ノードに割り当てるその他の属性を定義します。ノード定義ファイルでノード属性を設定するために使用できるプロパティーについて詳しくは、ベアメタルノードのプロビジョニング属性 を参照してください。ノード定義ファイルの例は、ノード定義ファイルの例 を参照してください。
  10. オーバークラウドノードをプロビジョニングします。

    (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 にネットワーク定義を提供します。
    • <deployment_file> は、デプロイメントコマンドに含めるために生成する heat 環境ファイルの名前に置き換えます (例 :/home/stack/templates/overcloud-baremetal-deployed.yaml)
    • <node_definition_file> は、ノード定義ファイルの名前 (overcloud-baremetal-deploy.yaml など) に置き換えます。
  11. 別のターミナルでプロビジョニングの進捗を監視します。

    (undercloud)$ watch openstack baremetal node list
    • プロビジョニングが成功すると、ノードの状態が available から active に変わります。
    • ノードのハードウェアまたはネットワーク設定の障害が原因でノードのプロビジョニングが失敗した場合は、プロビジョニング手順を再度実行する前に、失敗したノードを削除できます。詳細については、障害が発生したベアメタルノードをノード定義ファイルから削除する を参照してください。
  12. metalsmith ツールを使用して、割り当てやポートなどを含むノードの統合ビューを取得します。

    (undercloud)$ metalsmith list
  13. ノードとホスト名の関連付けを確認します。

    (undercloud)$ openstack baremetal allocation list

7.2.4. ベアメタルノードのプロビジョニング属性

次の表を使用して、ノード属性を設定するために使用できるプロパティーと、openstack baremetal node provision コマンドでベアメタルノードをプロビジョニングするときに使用できる値を理解してください。

  • ロールのプロパティー: ロールのプロパティーを使用して、各ロールを定義します。
  • 各ロールのデフォルトプロパティーとインスタンスプロパティー: デフォルトプロパティーまたはインスタンスプロパティーを使用して、使用可能なノードのプールからノードを割り当てるための選択基準を指定し、ベアメタルノードの属性とネットワーク設定プロパティーを設定します。

ベアメタル定義ファイルの作成に関する詳細は、オーバークラウドのベアメタルノードのプロビジョニング を参照してください。

表7.1 ロールのプロパティー

プロパティー

name

ロール名 (必須)

count

このロール用にプロビジョニングするノード数。デフォルト値は 1 です。

defaults

instances エントリープロパティーのデフォルト値のディクショナリー。instances エントリーのプロパティーは、defaults パラメーターで指定したデフォルトを上書きします。

instances

特定のノードの属性を指定するために使用可能な値のディクショナリー。インスタンス パラメーターでサポートされているプロパティーの詳細は、 defaultsinstances プロパティー を参照してください。定義されるノードの数は、count パラメーターの値を超えてはなりません。

hostname_format

このロールのデフォルトのホスト名形式を上書きします。デフォルトで生成されるホスト名は、オーバークラウドのスタック名、ロール、および増分インデックス (すべて小文字) から派生します。たとえば、Controller ロールのデフォルト形式は、%stackname%-controller-%index% です。Compute ロールだけは、ロール名のルールに従いません。Compute のデフォルトの形式は、%stackname%-novacompute-%index% です。

ansible_playbooks

Ansible Playbook と Ansible 変数の値のディクショナリー。Playbook は、ノードをプロビジョニングしてから、かつノードのネットワークを設定する前に、ロールインスタンスに対して実行されます。Ansible Playbook の指定の詳細は、ansible_playbooks プロパティー を参照してください。

表7.2 defaultsinstances のプロパティー

プロパティー

hostname

(instances のみ) instance プロパティーが適用されるノードのホスト名を指定します。ホスト名は、hostname_format プロパティーから派生します。カスタムホスト名を使用できます。

name

(instances のみ) プロビジョニングするノードの名前。

image

ノードにプロビジョニングするイメージの詳細。サポート対象の image プロパティーについては、image プロパティー を参照してください。

capabilities

ノードのケイパビリティーを照合する際の選択基準

config_drive

ノードに渡された設定ドライブにデータと初回起動コマンドを追加します。詳細は、config_drive プロパティー を参照してください。

注記

初回起動時に実行する必要がある設定には、config_drive のみを使用してください。他のすべてのカスタム設定については、Ansible Playbook を作成し、ansible_playbooks プロパティーを使用して、ノードのプロビジョニング後にロールインスタンスに対して Playbook を実行します。

管理

インスタンスを metalsmith でプロビジョニングするには、true (デフォルト) に設定します。インスタンスを事前プロビジョニング済みとして処理するには、false に設定します。

networks

インスタンスネットワークを表すディクショナリーのリスト。ネットワーク属性の設定の詳細については、network プロパティー を参照してください。

network_config

ロールまたはインスタンスのネットワーク設定ファイルへのリンク。ネットワーク設定ファイルへのリンクの設定の詳細は、network_config プロパティー を参照してください。

profile

プロファイルマッチングの選択基準。詳細は、プロファイルを照合することによるオーバークラウドノードへのロール指定 を参照してください。

provisioned

ノードをプロビジョニングするには、true (デフォルト) に設定します。ノードのプロビジョニングを解除するには、false に設定します。詳細は、ベアメタルノードのスケールダウン を参照してください。

resource_class

ノードのリソースクラスを照合する際の選択基準。デフォルト値は baremetal です。詳細は、リソースクラスを一致させることによるオーバークラウドノードのロールの指定 を参照してください。

root_size_gb

ルートパーティションのサイズ (GiB 単位)。デフォルト値は 49 です。

swap_size_mb

スワップパーティションのサイズ (MiB 単位)

traits

ノード特性を照合する際の選択基準としての特性のリスト

表7.3 image プロパティー

プロパティー

href

ノードにプロビジョニングするルートパーティションまたはディスクイメージ全体の URL を指定します。サポートされている URL スキーム: file://http://、および https://

注記

file:// URL スキームを使用してイメージのローカル URL を指定する場合、イメージパスは /var/lib/ironic/images/ ディレクトリーを指している必要があります。これは、/var/lib/ironic/images がアンダークラウドから ironic-conductor コンテナーにバインドマウントされ、明示的にイメージを提供するためです。

checksum

ルートパーティションまたはディスクイメージ全体の MD5 チェックサムを指定します。href が URL の場合は必須です。

kernel

カーネルイメージのイメージ参照または URL を指定します。パーティションイメージに対してのみ、この属性を使用します。

ramdisk

RAM ディスクイメージのイメージ参照または URL を指定します。パーティションイメージに対してのみ、この属性を使用します。

表7.4 network プロパティー

プロパティー

fixed_ip

このネットワークに使用する特定の IP アドレス

network

ネットワークポートを作成するネットワーク。

subnet

ネットワークポートを作成するサブネット。

port

新しいポートを作成する代わりに使用する既存のポート。

vif

プロビジョニングネットワーク (ctlplane) で true に設定して、ネットワークを仮想インターフェイス (VIF) として接続します。VIF 添付ファイルなしでネットワーキングサービス API リソースを作成するには、false に設定します。

表7.5 network_config プロパティー

プロパティー

template

ノードのネットワーク設定を適用するときに使用する Ansible J2 NIC 設定テンプレートを指定します。NIC テンプレートの設定については、オーバークラウドネットワークの設定 を参照してください。

physical_bridge_name

外部ネットワークにアクセスするために作成する OVS ブリッジの名前。デフォルトのブリッジ名は br-ex です。

public_interface_name

パブリックブリッジに追加するインターフェイスの名前を指定します。デフォルトのインターフェイスは nic1 です。

network_config_update

更新時にネットワーク設定の変更を適用するには、true に設定します。デフォルトでは無効になっています。

net_config_data_lookup

各ノードまたはノードグループの NIC マッピング設定 os-net-config を指定します。

default_route_network

デフォルトルートに使用するネットワーク。デフォルトのルートネットワークは ctlplane です。

networks_skip_config

ノードのネットワークを設定するときにスキップするネットワークのリスト。

dns_search_domains

resolv.conf に追加する DNS 検索ドメインのリスト (優先順位順)。

bond_interface_ovs_options

結合インターフェイスに使用する OVS オプションまたは結合オプション。たとえば、OVS のボンディングの場合は lacp=active および bond_mode=balance-slb、Linux のボンディングの場合は mode=4 です。

num_dpdk_interface_rx_queues

DPDK ボンドまたは DPDK ポートに必要な RX キューの数を指定します。

表7.6 config_drive プロパティー

プロパティー

cloud_config

ノードの起動時に実行するタスクの cloud-init クラウド設定データのディクショナリー。たとえば、初回起動時にカスタムネームサーバーを resolve.conf ファイルに書き込むには、以下の cloud_configconfig_drive プロパティーに追加します。

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

meta_data

config-drive cloud-init メタデータに含める追加のメタデータ。メタデータは、ロール名 (public_keysuuidnamehostname、および instance-type) で生成されたメタデータセットに追加されます。Cloud-init は、このメタデータをインスタンスデータとして利用できるようにします。

表7.7 ansible_playbooks プロパティー

プロパティー

Playbook

ロール定義 YAML ファイルに相対的な、Ansible Playbook へのパス。

extra_vars

Playbook の実行時に設定する追加の Ansible 変数。次の構文を使用して、追加の変数を指定します。

ansible_playbooks:
  - playbook: a_playbook.yaml
    extra_vars:
      param1: value1
      param2: value2

たとえば、ディスク全体のオーバークラウドイメージ overcloud-hardened-uefi-full.qcow2 でデプロイされた任意のノードの LVM ボリュームを拡張するには、以下の別の変数を Playbook プロパティーに追加します。

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 を参照してください。
  • ノードのハードウェア障害が原因で、ベアメタルノードのプロビジョニングが失敗しました。

手順

  1. source コマンドで stackrc アンダークラウド認証情報ファイルを読み込みます。

    $ source ~/stackrc
  2. overcloud-baremetal-deploy.yaml ノード定義ファイルを開きます。
  3. ノードが割り当てられているロールの count パラメーターを減らします。たとえば、以下の設定は、ObjectStorage ロールのカウントパラメーターを更新して、ObjectStorage 専用のノード数が 3 に減ったことを反映します。

    - name: ObjectStorage
      count: 3
  4. ロールの instances 属性でまだ定義されていない場合は、スタックから削除するノードの hostnamename を定義します。
  5. 削除するノードに属性 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
  6. ベアメタルノードのプロビジョニングを解除します。

    (undercloud)$ openstack overcloud node unprovision \
     --stack <stack> \
     --network-ports \
     /home/stack/templates/overcloud-baremetal-deploy.yaml
    • <stack> を、ベアメタルノードがプロビジョニングされるスタックの名前に置き換えます。指定しない場合、デフォルトは overcloud です。
  7. オーバークラウドノードをプロビジョニングして、デプロイメントコマンドに含める 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 のリソースクラスが割り当てられます。

注記

ノードのプロビジョニング後にノードに割り当てられたリソースクラスを変更するには、スケールダウン手順を使用してノードのプロビジョニングを解除してから、スケールアップ手順を使用して、新しいリソースクラスの割り当てでノードを再プロビジョニングする必要があります。詳細は、オーバークラウドノードのスケーリング を参照してください。

前提条件

  • 現在、オーバークラウド用のベアメタルノードの初期プロビジョニング手順を行っている。

手順

  1. カスタムリソースクラスを持つロールに指定する各ベアメタルノードを割り当てます。

    (undercloud)$ openstack baremetal node set \
     --resource-class <resource_class> <node>
    • <resource_class> は、リソースクラスの名前 (baremetal.CPU-PINNING など) に置き換えます。
    • <node> をベアメタルノードの ID に置き換えてください。
  2. まだ定義されていない場合は、overcloud-baremetal-deploy.yaml ファイルにロールを追加します。
  3. ロールのノードに割り当てるリソースクラスを指定します。

    - name: <role>
      count: 1
      defaults:
        resource_class: <resource_class>
    • <role> をロールの名前に置き換えます。
    • <resource_class> は、手順 1 で指定したリソースクラスの名前に置き換えます。
  4. オーバークラウドのベアメタルノードのプロビジョニング に戻り、プロビジョニングプロセスを完了します。

7.2.7. プロファイルを一致させることによるオーバークラウドノードのロールの指定

プロファイル機能を使用して、オーバークラウドノードを特定のロールに指定できます。プロファイルは、ノードの機能をデプロイメントロールと照合します。

ヒント

イントロスペクションルールを使用して、自動プロファイル割り当てを実行することもできます。詳しくは、プロファイルの自動タグ付けの設定 を参照してください。

注記

ノードのプロビジョニング後にノードに割り当てられたプロファイルを変更するには、スケールダウン手順を使用してノードのプロビジョニングを解除してから、スケールアップ手順を使用して、新しいプロファイルの割り当てでノードを再プロビジョニングする必要があります。詳細は、オーバークラウドノードのスケーリング を参照してください。

前提条件

  • 現在、オーバークラウド用のベアメタルノードの初期プロビジョニング手順を行っている。

手順

  1. 新しいノード機能を追加するたびに、既存のノード機能が上書きされます。したがって、再設定するには、登録済みの各ノードの既存の機能を取得する必要があります。

    $ openstack baremetal node show <node> \
     -f json -c properties | jq -r .properties.capabilities
  2. ノードの既存の機能に profile:<profile> を追加して、ロールプロファイルに一致させる各ベアメタルノードにプロファイル機能を割り当てます。

    (undercloud)$ openstack baremetal node set  <node> \
     --property capabilities="profile:<profile>,<capability_1>,...,<capability_n>"
    • <node> は、ベアメタルノードの名前または ID に置き換えます。
    • <profile> は、ロールプロファイルに一致するプロファイルの名前に置き換えます。
    • <capability_1> および <capability_n> までのすべての機能は、手順 1 で取得した各機能に置き換えます。
  3. まだ定義されていない場合は、overcloud-baremetal-deploy.yaml ファイルにロールを追加します。
  4. ロールのノードに割り当てるプロファイルを定義します。

    - name: <role>
      count: 1
      defaults:
        profile: <profile>
    • <role> をロールの名前に置き換えます。
    • <profile> は、ノードの機能に一致するプロファイルの名前に置き換えます。
  5. オーバークラウドのベアメタルノードのプロビジョニング に戻り、プロビジョニングプロセスを完了します。

7.2.8. Object Storage サービスのディスクパーティション全体の設定

ディスクイメージ全体である overcloud-hardened-uefi-full は、個別のボリュームに分割されます。デフォルトでは、ディスク全体のオーバークラウドイメージでデプロイされたノードの /var パーティションは、ディスクが完全に割り当てられるまで自動的に増加します。Object Storage サービス (swift) を使用する場合は、ディスクのサイズと /var および /srv のストレージ要件に基づいて /srv パーティションのサイズを設定します。

前提条件

  • 現在、オーバークラウド用のベアメタルノードの初期プロビジョニング手順を行っている。

手順

  1. 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%
  2. オーバークラウドのベアメタルノードのプロビジョニング に戻り、プロビジョニングプロセスを完了します。

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) で利用可能でなければなりません。
  • クリーニングおよびプロビジョニング用ネットワーク

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. stackrc アンダークラウド認証情報ファイルを入手します。

    $ source ~/stackrc
  3. Bare Metal Provisioning サービスの起動インターフェイスを redfish-virtual-media に設定します。

    (undercloud)$ openstack baremetal node set --boot-interface redfish-virtual-media <node>
    • <node> はノード名に置き換えてください。
  4. ESP イメージを定義します。

    (undercloud)$ openstack baremetal node set --driver-info bootloader=<esp> <node>
    • <esp> を Image サービス (glance) イメージの UUID または ESP イメージの URL に置き換えます。
    • <node> はノード名に置き換えてください。
  5. ベアメタルノードにポートを作成し、そのポートをベアメタルノード上の 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 は、複数のディスク設定でルートディスクを識別する必要があります。オーバークラウドイメージは、プロビジョニングプロセス中にルートディスクに書き込まれます。

ハードウェアプロパティーは、ルートディスクを識別するために使用されます。ルートディスクの識別に使用できるプロパティーの詳細は、ルートディスクを識別するプロパティー を参照してください。

手順

  1. 各ノードのハードウェアイントロスペクションからのディスク情報を確認します。

    (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"
        }
      ]
  2. 一意のハードウェアプロパティーを使用して、ノードのルートディスクを設定します。

    (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

  3. 最初にネットワークから起動し、次にルートディスクから起動するように、各ノードの 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 ボンディングの作成 を参照してください。

手順

  1. overcloud-baremetal-deploy.yaml ファイルを開きます。
  2. 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.qcow2
      - 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.qcow2
      instances:
      - hostname: overcloud-ceph-0
        name: node00
      - hostname: overcloud-ceph-1
        name: node01
      - hostname: overcloud-ceph-2
        name: node02

  3. roles_data.yaml ロール定義ファイルで、rhsm_enforce パラメーターを False に設定します。

    rhsm_enforce: False
  4. プロビジョニングコマンドを実行します。

    (undercloud)$ openstack overcloud node provision \
    --stack stack \
    --output /home/stack/templates/overcloud-baremetal-deployed.yaml \
    /home/stack/templates/overcloud-baremetal-deploy.yaml
  5. overcloud-baremetal-deployed.yaml 環境ファイルを openstack overcloud deploy コマンドに渡します。