Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

第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 サービスと通信するための設定

  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.yamlNeutronBridgeMappings パラメーターで設定されています。

  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 subnet ROUTER_NAME BAREMETAL_SUBNET

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

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 コマンドを実行し、オーバークラウドを再デプロイして変更を適用します。

    注記

    各コントローラーで ironic.conf を更新することによって、オーバークラウドの再デプロイを回避することが可能です。ただし、OpenStack director のインストール環境における ironic.conf ファイルの手動更新はサポートされていません。以下に記載する手順は便宜のためにのみ提供しています。

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

      cleaning_network = <None>
    2. 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、ディスク) はベアメタルノードが提供する仕様以下である必要があります。

  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 イメージが含まれます。

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

    $ export DIB_LOCAL_IMAGE=rhel-server-7.4-x86_64-kvm.qcow2
  3. diskimage-builder ツールを使用してユーザーイメージを作成します。

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

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

  4. イメージを 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 つの方法があります。

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

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

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

4.5.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 の状態となります。各ノードで 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
  5. ノードが正常に登録されたことを確認します。

    $ openstack baremetal node list

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

4.5.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: ディスクのシリアル番号
      • size: GiB 単位のデバイスサイズ (整数)
      • wwn: ストレージ一意識別子
      • wwn_with_extension: ベンダー拡張が末尾に付いたストレージ一意識別子
      • wwn_vendor_extension: ベンダーのストレージ一意識別子
      • rotational: 回転式デバイス (HDD) には true、そうでない場合は false (SSD)。(ブール値)
      • hctl: SCSI アドレス (ホスト、チャネル、ターゲット、LUN)。例: ‘1:0:0:0’
      • 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.6. ホストアグリゲートを使用した物理/仮想マシンのプロビジョニングの分離

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. virtual-hosts という名前のホストアグリゲートを作成します。

    $ openstack aggregate create --property baremetal=false virtual-hosts
  5. 各ベアメタルマシンを baremetal-hosts アグリゲートに追加します。

    $ openstack aggregate add host baremetal-hosts HOSTNAME
  6. 各コンピュートノードを virtual-hosts アグリゲートに追加します。

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

    AggregateInstanceExtraSpecsFilter