Menu Close

Red Hat Training

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

第2章 Bare Metal デプロイメントの設定

OpenStack 環境でのベアメタルデプロイメントが可能となるように Bare Metal Provisioning、Image service、および Compute を設定します。以下の項では、ベアメタルノードのデプロイを正常に実行するのに必要な追加の設定ステップについて説明します。

2.1. Bare Metal Provisioning サービス用の OpenStack 設定の作成

2.1.1. OpenStack Networking 構成の設定

OpenStack Networking が DHCP、PXE ブートおよびその他の必要な場合に Bare Metal Provisioning と通信するように設定します。以下の手順では、単一のフラットなネットワークをベアメタルにプロビジョニングするユースケースで OpenStack Networking を設定します。この設定には ML2 プラグインと Open vSwitch エージェントを使用します。

プロビジョニングに使用するネットワークインターフェースは、OpenStack Networking ノード上でリモート接続に使用しているネットワークインターフェースとは別であることを確認してください。この手順では、ベアメタルプロビジョニングネットワーク用のインターフェースを使用するブリッジを作成し、リモート接続を解除します。

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

OpenStack Networking が Bare Metal Provisioning と通信するための設定

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

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

    # neutron net-create --tenant-id TENANT_ID sharednet1 --shared \
    --provider:network_type flat --provider:physical_network PHYSNET

    TENANT_ID はネットワークを作成するテナントの一意識別子に、PHYSNET は物理ネットワークの名前に置き換えます。

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

    # neutron subnet-create sharednet1 NETWORK_CIDR --name SUBNET_NAME \
    --ip-version 4 --gateway GATEWAY_IP --allocation-pool \
    start=START_IP,end=END_IP --enable-dhcp

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

    • NETWORK_CIDR は、サブネットが示す IP アドレスブロックの Classless Inter-Domain Routing (CIDR) 表記に置き換えます。 START_IP で始まり END_IP で終る範囲で指定する IP アドレスブロックは、NETWORK_CIDR で指定されている IP アドレスブロックの範囲内に入る必要があります。
    • SUBNET_NAME はサブネットの名前に置き換えます。
    • 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 サービスによって応答されるようにします。

    # neutron router-create ROUTER_NAME

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

  5. ベアメタルのサブネットにこのルーターをインターフェースとして追加します。

    # neutron router-interface-add ROUTER_NAME BAREMETAL_SUBNET

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

  6. Bare Metal Provisioning サービスを実行するコンピュートノード上の /etc/ironic/ironic.conf ファイルを更新して、クリーニングサービスに同じネットワークを使用するようにします。Bare Metal Provisioning を実行しているコンピュートノードにログインして、以下のコマンドを root ユーザーとして実行します。

    # openstack-config --set /etc/ironic/ironic.conf neutron cleaning_network_uuid NETWORK_UUID

    NETWORK_UUID は、前のステップで作成したベアメタルプロビジョニングネットワークの ID に置き換えます。

  7. Bare Metal Provisioning サービスを再起動します。

    # systemctl restart openstack-ironic-conductor.service

2.1.2. Bare Metal Provisioning フレーバーの作成

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

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

    # source ~stack/overcloudrc
  2. 既存のフレーバーを一覧表示します。

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

    # openstack flavor create --id auto --ram RAM --vcpus VCPU --disk DISK --public baremetal

    RAM は RAM のメモリーに、VCPU は仮想 CPU 数に、DISK はディスクストレージの値に置き換えます。

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

    # openstack flavor list

2.1.3. ベアメタルイメージの作成

Bare Metal Provisioning は、ディスク全体のイメージまたはルートパーティションのイメージのデプロイをサポートしています。ディスク全体のイメージにはパーティションテーブル、カーネルイメージ、最終のユーザーイメージが含まれます。ルートパーティションイメージには OS のルートパーティションが含まれ、ベアメタルノードが最終のユーザーイメージのブートに使用する kernel および ramdisk イメージが必要です。サポートされているベアメタルエージェントドライバーはすべて、ディスク全体のイメージまたはルートパーティションのイメージをデプロイすることができます。

ディスク全体のイメージには、パーティションテーブル、ブートローダー、ユーザーイメージが含まれたイメージが 1 つ必要です。ディスク全体のイメージを使用してデプロイしたノードはローカルブートをサポートするので、Bare Metal Provisioning はデプロイ後の再起動は制御しません。

ルートパーティションのデプロイメントには、deploy イメージと user イメージの 2 セットのイメージが必要です。Bare Metal Provisioning は deploy イメージを使用してノードを起動し、user イメージをベアメタルノードにコピーします。deploy イメージが Image サービスに読み込まれた後には、ベアメタルノードのプロパティーを使用して deploy イメージをベアメタルノードに関連付けて、そのノードが deploy イメージを使用するように設定することができます。その後のノードの再起動にはネットブートが使用されて、user イメージがダウンロードされます。

本項には、ルートパーティションイメージを使用して、ベアメタルノードをプロビジョニングする例を記載しています。ディスク全体のイメージのデプロイメントの場合は、「Windows 全体のイメージの作成」を参照してください。パーティションベースのデプロイメントの場合は、アンダークラウドがオーバークラウドをデプロイした際に deploy イメージはすでに使用されているので、作成する必要はありませんdeploy イメージは、以下に示すように、kernel イメージと ramdisk イメージの 2 つで構成されます。

ironic-python-agent.kernel
ironic-python-agent.initramfs

rhosp-director-images-ipa パッケージをインストール済みの場合には、これらのイメージは、/usr/share/rhosp-director-images/ironic-python-agent*.el7ost.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

最終的に必要なイメージは、Bare Metal Provisioning ノードに実際にデプロイされるイメージです。たとえば、cloud-init がすでにあるので、Red Hat Enterprise Linux KVM イメージをダウンロードすることができます。

Image サービスへのイメージのアップロード

# openstack image create --container-format bare --disk-format qcow2  --property kernel_id=DEPLOY_KERNEL_ID \
--property ramdisk_id=DEPLOY_RAMDISK_ID --public --file ./IMAGE_FILE rhel

DEPLOY_KERNEL_ID が Image サービスにアップロードされた deploy-kernel イメージに関連付けられている UUID に置き換えます。DEPLOY_RAMDISK_ID は、Image サービスにアップロードされた deploy-ramdisk に関連付けられたUUID に置き換えます。これらの UUID を確認するには、openstack image list を使用してください。

2.1.4. Bare Metal Provisioning サービスへの Bare Metal Provisioning ノードの追加

Bare Metal Provisioning ノードを Bare Metal Provisioning サービスに追加するには、クラウドをインスタンス化するのに使用された instackenv.json ファイルのセクションをコピーして、必要に応じて変更します。

  1. overcloudrc ファイルを読み込んで、.json ファイルをインポートします。

    # source ~stack/overcloudrc
    # openstack baremetal import --json ./baremetal.json
  2. Bare Metal Provisioning サービス内のベアメタルノードの driver_info セクションの deploy_kerneldeploy_ramdisk を指定して、そのノードが初期ブートイメージとしてデプロイ済みのイメージを使用するように設定します。

    # ironic node-update NODE_UUID add driver_info/deploy_kernel=DEPLOY_KERNEL_ID driver_info/deploy_ramdisk=DEPLOY_RAMDISK_ID

NODE_UUID は、ベアメタルノードの UUID に置き換えます。この値は、director ノードで ironic node-list コマンドを実行すると取得することができます。DEPLOY_KERNEL_ID は deploy kernel イメージの ID に置き換えます。この値は、director ノード上で glance image-list コマンドを実行すると取得することができます。DEPLOY_RAMDISK_ID は deploy ramdisk イメージの ID に置き換えます。この値は、director ノード上で glance image-list コマンドを実行すると取得することができます。

2.1.5. Image デプロイメント向けのプロキシーサービス

オプションで、ベアメタルノードが Object Storage で HTTP または HTTPS プロキシーサービスを使用してベアメタルノードにイメージをダウンロードするように設定することが可能です。これにより、ベアメタルノードと同じ物理ネットワークセグメント内にイメージをキャッシュして、全体的なネットワークトラフィックを削減し、デプロイメント時間を短縮することができます。

作業を開始する前に

以下の点を追加で考慮した上で、プロキシーサーバーを設定します。

  • 要求された URL に含まれているクエリーの場合でも、コンテンツのキャッシュを使用します。
  • キャッシュの最大サイズを大きくして、イメージのサイズが収まるようにします。
注記

イメージに機密情報が含まれていない場合にのみ、プロキシーサーバーが暗号化なしでイメージを保管するようにします。

Image プロキシーの設定

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

    # source ~stack/overcloudrc
  2. ベアメタルノードドライバーが HTTP または HTTPS を使用するための設定

    # openstack baremetal node set NODE_UUID \
       --driver_info image_https_proxy=HTTPS://PROXYIP:PORT

    この例では、HTTPS プロトコルを使用します。HTTPS の代わりに HTTP を使用する場合には、driverinfo/image_http_proxy パラメーターを指定してください。

  3. イメージが要求された時に、Bare Metal Provisioning が Object Storage のキャッシュ済み一時 URL を再使用するように設定します。

    # openstack-config --set /etc/ironic/ironic.conf glance swift_temp_url_cache_enabled=true

    プロキシーサーバーは、URL のクエリーの部分に基づいて、要求が生成される度に毎回変更されるクエリーパラメーターが含まれている場合には、同じイメージには新規キャッシュエントリーを作成しません。

  4. 生成された URL の有効期間を (秒単位で) 設定します。

    # openstack-config --set /etc/ironic/ironic.conf glance swift_temp_url_duration=DURATION

    Object Storage サービスの一時 URL のキャッシュからは、有効期限が切れていないイメージリンクのみが返されます。swift_temp_url_duration=1200 と設定した場合には、新しいイメージはプロキシーサーバーによって 20分後にキャッシュされます。このオプションの値は、 swift_temp_url_expected_download_start_delay の値以上である必要があります。

  5. ハードウェアに対して、ダウンロードを開始するまでの遅延時間 (秒単位) を設定します。

    # openstack-config --set /etc/ironic/ironic.conf glance swift_temp_url_expected_download_start_delay=DELAY

    DELAY には、デプロイが要求 (一時 URL が生成) されてから、その URL を使用してイメージがベアメタルにダウンロードされるまでの遅延時間を設定します。この遅延時間により、ramdisk を起動してからイメージのダウンロードを開始することができます。この値により、イメージのダウンロード開始時にキャッシュされたエントリーが引き続き有効な状態となるかどうかが決定します。

2.1.6. Bare Metal Provisioning ノードのデプロイ

nova boot コマンドを使用して Bare Metal Provisioning ノードをデプロイします。

# nova  boot --image BAREMETAL_USER_IMAGE --flavor BAREMETAL_FLAVOR --nic net-id=IRONIC_NETWORK_ID --key default MACHINE_HOSTNAME

BAREMETAL_USER_IMAGE は Image サービスにアップロードされたイメージに、BAREMETAL_FLAVOR はそのベアメタルデプロイメント用のフレーバーに、IRONIC_NETWORK_ID は OpenStack Networking 内のベアメタルプロビジョニングネットワークの ID に、MACHINE_HOSTNAME はデプロイ後のマシンのホスト名に置き換えます。

2.2. ハードウェア検査の設定

ハードウェア検査により、Bare Metal Provisioning はノード上のハードウェア情報を検出することができます。検査は、検出したイーサネットの MAC アドレスも作成します。または、各ノードにハードウェア情報を手動で追加することが可能です。詳しくは、「手動によるノードの追加」を参照してください。以下の手順に記載するステップはすべて、Bare Metal Provisioning コンダクターサービスをホストするサーバーで root ユーザーとしてログインして実行する必要があります。

ハードウェア検査は、以下のドライバーを使用するインバンドでサポートされます。

  • pxe_drac
  • pxe_ipmitool
  • pxe_ssh
  • pxe_amt

ハードウェア検査の設定

  1. PXE ブートを使用したベアメタルシステムの検出に使用する Ironic Python Agent の kernel と ramdisk のイメージを取得します。これらのイメージは、https://access.redhat.com/downloads/content/191/ver=9/rhel---7/9/x86_64/product-softwareIronic Python Agent Image for RHOSP director 9.0 というラベルの付いた TAR アーカイブで提供されています。この TAR アーカイブをダウンロードして、そこからイメージファイル (ironic-python-agent.kernel および ironic-python-agent.initramfs) を抽出してから、それらを TFTP サーバーの /tftpboot ディレクトリーにコピーしてください。
  2. ハードウェア検査をホストするサーバーで Red Hat OpenStack Platform 9 director for RHEL 7 (RPMs) チャンネルを有効にします。

    # subscription-manager repos --enable=rhel-7-server-openstack-9-director-rpms
  3. openstack-ironic-inspector パッケージをインストールします。

    # yum install openstack-ironic-inspector
  4. ironic.conf ファイルで検査を有効にします。

    # openstack-config --set /etc/ironic/ironic.conf \
       inspector enabled True
  5. ハードウェア検査サービスを別のサーバーでホストする場合には、コンダクターサービスをホストするサーバーでその URL を設定します。

    # openstack-config --set /etc/ironic/ironic.conf \
       inspector service_url http://INSPECTOR_IP:5050

    INSPECTOR_IP はハードウェア検査をホストするサーバーのホスト名または IP アドレスに置き換えます。

  6. ハードウェア検査サービスに認証情報を提供します。

    # openstack-config --set /etc/ironic-inspector/inspector.conf \
       keystone_authtoken identity_uri http://IDENTITY_IP:35357
    # openstack-config --set /etc/ironic-inspector/inspector.conf \
       keystone_authtoken auth_uri http://IDENTITY_IP:5000/v2.0
    # openstack-config --set /etc/ironic-inspector/inspector.conf \
       keystone_authtoken admin_user ironic
    # openstack-config --set /etc/ironic-inspector/inspector.conf \
       keystone_authtoken admin_password PASSWORD
    # openstack-config --set /etc/ironic-inspector/inspector.conf \
       keystone_authtoken admin_tenant_name services
    # openstack-config --set /etc/ironic-inspector/inspector.conf \
       ironic os_auth_url http://IDENTITY_IP:5000/v2.0
    # openstack-config --set /etc/ironic-inspector/inspector.conf \
       ironic os_username ironic
    # openstack-config --set /etc/ironic-inspector/inspector.conf \
       ironic os_password PASSWORD
    # openstack-config --set /etc/ironic-inspector/inspector.conf \
       ironic os_tenant_name service
    # openstack-config --set /etc/ironic-inspector/inspector.conf \
       firewall dnsmasq_interface br-ironic
    # openstack-config --set /etc/ironic-inspector/inspector.conf \
       database connection sqlite:////var/lib/ironic-inspector/inspector.sqlite

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

    • IDENTITY_IP は Identity サーバーの IP アドレスまたはホスト名に置き換えます。
    • PASSWORD は、Bare Metal Provisioning が Identity との認証で使用するパスワードに置き換えます。
  7. オプションで、ハードウェア検査が RAM ディスクのログを保管するように設定します。

    # openstack-config --set /etc/ironic-inspector/inspector.conf \
    processing ramdisk_logs_dir /var/log/ironic-inspector/ramdisk
  8. オプションで、複数のローカルディスクを使用するベアメタルマシンでブロックデバイスを収集してルートデバイスを公開する追加のデータ処理プラグインを有効にします。ramdisk_errorroot_disk_selectionschedulervalidate_interfaces はデフォルトで有効化され、無効にすべきではありません。以下のコマンドを実行して、root_device_hint を一覧に追加します。

    # openstack-config --set /etc/ironic-inspector/inspector.conf \
    processing processing_hooks '$default_processing_hooks,root_device_hint'
  9. 初期 ironic inspector データベースを生成します。

    # ironic-inspector-dbsync --config-file /etc/ironic-inspector/inspector.conf upgrade
  10. inspector データベースファイルを更新して、ironic-inspector が所有するようにします。

    # chown ironic-inspector /var/lib/ironic-inspector/inspector.sqlite
  11. テキストエディターで /etc/ironic-inspector/dnsmasq.conf ファイルを開き、以下に示す PXE ブート設定を openstack-ironic-inspector-dnsmasq サービスに設定します。

    port=0
    interface=br-ironic
    bind-interfaces
    dhcp-range=START_IP,END_IP
    enable-tftp
    tftp-root=/tftpboot
    dhcp-boot=pxelinux.0

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

    • INTERFACE はプロビジョニングネットワークインターフェースの名前に置き換えます。
    • START_IP は、Floating IP アドレスを割り当てる元となる IP アドレス範囲の開始アドレスを示す IP アドレスに置き換えます。
    • END_IP は、Floating IP アドレスを割り当てる元となる IP アドレス範囲の終了アドレスを示す IP アドレスに置き換えます。
  12. syslinux bootloadertftp ディレクトリーにコピーします。

    # cp /usr/share/syslinux/pxelinux.0 /tftpboot/pxelinux.0
  13. オプションで、swift section of the /etc/ironic-inspector/inspector.conf ファイルの swift セクションに、メタデータを保管するためのハードウェア検査サービスを設定することができます。

    [swift]
    username = ironic
    password = PASSWORD
    tenant_name = service
    os_auth_url = http://IDENTITY_IP:5000/v2.0

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

    • IDENTITY_IP は Identity サーバーの IP アドレスまたはホスト名に置き換えます。
    • PASSWORD は、Bare Metal Provisioning が Identity との認証で使用するパスワードに置き換えます。
  14. テキストエディターで /tftpboot/pxelinux.cfg/default ファイルを開き、以下のオプションを設定します。

    default discover
    
    label discover
    kernel ironic-python-agent.kernel
    append initrd=ironic-python-agent.initramfs \
    ipa-inspection-callback-url=http://INSPECTOR_IP:5050/v1/continue
    ipa-api-url=http://IRONIC_API_IP:6385
    
    ipappend 3

    INSPECTOR_IP はハードウェア検査をホストするサーバーのホスト名または IP アドレスに置き換えます。上記のブロックに \ で示したように、append から /continue までのテキストは、一行に記載する必要がある点に注意してください。

  15. /tftpboot/ ディレクトリーおよびそのファイルのセキュリティーコンテキストをリセットします。

    # restorecon -R /tftpboot/

    このステップでは、ディレクトリーに正しい SELinux セキュリティーラベルが設定され、dnsmasq サービスがディレクトリーにアクセスできることを確認します。

  16. ハードウェア検査サービスと dnsmasq サービスを起動して、ブート時に開始するように設定します。

    # systemctl start openstack-ironic-inspector.service
    # systemctl enable openstack-ironic-inspector.service
    # systemctl start openstack-ironic-inspector-dnsmasq.service
    # systemctl enable openstack-ironic-inspector-dnsmasq.service

    ハードウェア検査は、Bare Metal Provisioning に登録された後に、ノードで使用することができます。

2.3. ベアメタルノードとしての物理マシンの追加

インスタンスをプロビジョニングする物理マシンをノードとして追加し、Compute に対して利用可能なハードウェアが表示されることを確認します。Compute のリソーストラッカーは一定の時間間隔で同期するので、新規リソースは Compute に即時には通知されません。変更は次の定期タスクが実行された後に表示されるようになります。この値 (scheduler_driver_task_period) は、/etc/nova/nova.conf で更新することができます。デフォルトの間隔は 60 秒です。

システムがベアメタルノードとして登録されると、ハードウェアの詳細は、ハードウェア検査を使用して検出するか、手動で追加することができます。

2.3.1. ハードウェア検査を使用したノードの追加

物理マシンをベアメタルノードとして登録してから、openstack-ironic-inspector を使用してノードのハードウェア情報を検出し、各イーサネット MAC アドレス用にポートを作成します。以下の手順に記載するステップはすべて、Bare Metal Provisioning コンダクターサービスをホストするサーバーに root ユーザーとしてログインして実行する必要があります。

ハードウェア検査を使用してノードを追加する方法

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

    # source ~/keystonerc_admin
  2. 新規ノードを追加します。

    # ironic node-create -d DRIVER_NAME

    DRIVER_NAME は、Bare Metal Provisioning がこのノードのプロビジョニングに使用するドライバーの名前に置き換えます。このドライバーは、/etc/ironic/ironic.conf ファイルで有効にしておく必要があります。ノードを作成するには、少なくともドライバーの名前を指定する必要があります。

    重要

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

  3. ノードは論理名または UUID で参照することができます。オプションで、ノードに論理名を割り当てます。

    # ironic node-update NODE_UUID add name=NAME

    NODE_UUID は、ノードの一意識別子に置き換えます。NAME は、ノードの論理名に置き換えます。

  4. ドライバーが必要とするノードの情報を確認してから、Bare Metal Provisioning がノードを管理するようにノードドライバーの情報を更新します。

    # ironic driver-properties DRIVER_NAME
    # ironic node-update NODE_UUID add \
       driver_info/PROPERTY=VALUE \
       driver_info/PROPERTY=VALUE

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

    • DRIVER_NAME は、プロパティーを表示するドライバーの名前に置き換えます。この情報は、/etc/ironic/ironic.conf ファイルでドライバーを有効にしていなければ返されません。
    • NODE_UUID は、ノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。
    • PROPERTY は、ironic driver-properties コマンドで返された必要なプロパティーに置き換えます。
    • VALUE は、プロパティーの有効な値に置き換えます。
  5. ノードドライバーのデプロイカーネルとデプロイ RAM ディスクを指定します。

    # ironic node-update NODE_UUID add \
      driver_info/deploy_kernel=KERNEL_UUID \
      driver_info/deploy_ramdisk=INITRAMFS_UUID

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

    • NODE_UUID は、ノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。
    • KERNEL_UUID は、Image サービスにアップロードされた .kernel イメージの一意識別子に置き換えます。
    • INITRAMFS_UUID は、Image サービスにアップロードされた .initramfs イメージの一意識別子に置き換えます。
  6. ノードを設定して、初回のデプロイの後には、PXE や仮想メディアの代わりに、そのノードのディスクにインストールされたローカルのブートローダーからリブートするようにします。ノードのプロビジョニングに使用するフレーバーでも、ローカルブートの機能を設定する必要があります。ローカルブートを有効にするには、ノードのデプロイに使用するイメージに grub2 が含まれる必要があります。ローカルブートを以下のように設定します。

    # ironic node-update NODE_UUID add \
       properties/capabilities="boot_option:local"

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

  7. ベアメタルノードを manageable 状態に切り替えます。

    # ironic node-set-provision-state NODE_UUID manage

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

  8. 検査を開始します。

    # openstack baremetal introspection start NODE_UUID --discoverd-url http://overcloud IP:5050
    • NODE_UUID はノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。ノードをプロビジョニングする前に、ノードの検出および検査プロセスは完了するまで実行する必要があります。ノードの検査のステータスを確認するには、ironic node-list を実行して Provision State の箇所を探します。検査が正常に完了すると、ノードは available の状態になります。
    • overcloud IPironic.conf で以前設定した service_url の値に置き換えます。
  9. ノードの設定を検証します。

    # ironic node-validate NODE_UUID
    +------------+--------+----------------------------+
    | Interface  | Result | Reason                     |
    +------------+--------+----------------------------+
    | console    | None   | not supported              |
    | deploy     | True   |                            |
    | inspect    | True   |                            |
    | management | True   |                            |
    | power      | True   |                            |
    +------------+--------+----------------------------+

    NODE_UUID は、ノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。上記のコマンドの出力には、各インターフェースが True または None のいずれかと報告されるはずです。None とマークされたインターフェースは、設定していないか、ドライバーがサポートしていないインターフェースです。

2.3.2. 手動によるノードの追加

物理マシンをベアメタルノードとして登録してから、ノードのハードウェア情報を追加し、各イーサネット MAC アドレス用にポートを作成します。以下の手順に記載するステップはすべて、Bare Metal Provisioning コンダクターサービスをホストするサーバーに root ユーザーとしてログインして実行する必要があります。

ハードウェア検査を使用せずにノードを追加する方法

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

    # source ~/keystonerc_admin
  2. 新規ノードを追加します。

    # ironic node-create -d DRIVER_NAME

    DRIVER_NAME は、Bare Metal Provisioning がこのノードのプロビジョニングに使用するドライバーの名前に置き換えます。このドライバーは、/etc/ironic/ironic.conf ファイルで有効にしておく必要があります。ノードを作成するには、少なくともドライバーの名前を指定する必要があります。

    重要

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

  3. ノードは論理名または UUID で参照することができます。オプションで、ノードに論理名を割り当てます。

    # ironic node-update NODE_UUID add name=NAME

    NODE_UUID は、ノードの一意識別子に置き換えます。NAME は、ノードの論理名に置き換えます。

  4. ドライバーが必要とするノードの情報を確認してから、Bare Metal Provisioning がノードを管理するようにノードドライバーの情報を更新します。

    # ironic driver-properties DRIVER_NAME
    # ironic node-update NODE_UUID add \
       driver_info/PROPERTY=VALUE \
       driver_info/PROPERTY=VALUE

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

    • DRIVER_NAME は、プロパティーを表示するドライバーの名前に置き換えます。この情報は、/etc/ironic/ironic.conf ファイルでドライバーを有効にしていなければ返されません。
    • NODE_UUID は、ノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。
    • PROPERTY は、ironic driver-properties コマンドで返された必要なプロパティーに置き換えます。
    • VALUE は、プロパティーの有効な値に置き換えます。
  5. ノードドライバーのデプロイカーネルとデプロイ RAM ディスクを指定します。

    # ironic node-update NODE_UUID add \
      driver_info/deploy_kernel=KERNEL_UUID \
      driver_info/deploy_ramdisk=INITRAMFS_UUID

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

    • NODE_UUID は、ノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。
    • KERNEL_UUID は、Image サービスにアップロードされた .kernel イメージの一意識別子に置き換えます。
    • INITRAMFS_UUID は、Image サービスにアップロードされた .initramfs イメージの一意識別子に置き換えます。
  6. ノードのプロパティーを更新して、ノード上のハードウェアの仕様と一致するようにします。

    # ironic node-update NODE_UUID add \
       properties/cpus=CPU \
       properties/memory_mb=RAM_MB \
       properties/local_gb=DISK_GB \
       properties/cpu_arch=ARCH

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

    • NODE_UUID は、ノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。
    • CPU は、使用する CPU 数に置き換えます。
    • RAM_MB は、使用するメモリー (MB 単位) に置き換えます。
    • DISK_GB は、使用するディスクサイズ (GB 単位) に置き換えます。
    • ARCH は使用するアーキテクチャーのタイプに置き換えます。
  7. ノードを設定して、初回のデプロイの後には、PXE や仮想メディアの代わりに、そのノードのディスクにインストールされたローカルのブートローダーからリブートするようにします。ノードのプロビジョニングに使用するフレーバーでも、ローカルブートの機能を設定する必要があります。ローカルブートを有効にするには、ノードのデプロイに使用するイメージに grub2 が含まれる必要があります。ローカルブートを以下のように設定します。

    # ironic node-update NODE_UUID add \
       properties/capabilities="boot_option:local"

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

  8. Bare Metal Provisioning にノードのネットワークインターフェースカードの情報を提供します。各 NIC の MAC アドレスでポートを作成します。

    # ironic port-create -n NODE_UUID -a MAC_ADDRESS

    NODE_UUID は、ノードの一意識別子に置き換えます。MAC_ADDRESS は、ノード上の NIC の MAC アドレスに置き換えます。

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

    # ironic node-validate NODE_UUID
    +------------+--------+----------------------------+
    | Interface  | Result | Reason                     |
    +------------+--------+----------------------------+
    | console    | None   | not supported              |
    | deploy     | True   |                            |
    | inspect    | None   | not supported              |
    | management | True   |                            |
    | power      | True   |                            |
    +------------+--------+----------------------------+

    NODE_UUID は、ノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。上記のコマンドの出力には、各インターフェースが True または None のいずれかと報告されるはずです。None とマークされたインターフェースは、設定していないか、ドライバーがサポートしていないインターフェースです。

2.3.3. 手動によるノードのクリーニングの設定

ベアメタルサーバーの初めてプロビジョニングされる時や、そのサーバーがワークロードから解放された後に再プロビジョニングされる時には、Bare Metal Provisioning がそのサーバーを自動的にクリーニングして、そのサーバーが別のワークロードに対応する準備を整えることができます。また、サーバーが管理可能な状態の時には、手動のクリーニングサイクルを開始することも可能です。手動のクリーニングサイクルは、長時間実行されるタスクや破壊的なタスクに役立ちます。ベアメタルサーバー特定のクリーニングステップを設定することができます。

クリーニングネットワークの設定

Bare Metal Provisioning はクリーニングネットワークを使用して、ベアメタルサーバーのインバンドのクリーニングステップを提供します。このクリーニングネットワークには別のネットワークを作成するか、プロビジョニングネットワークを使用することができます。

Bare Metal Provisioning サービスのクリーニングネットワークを設定するには、以下の手順に従ってください。

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

    # source ~stack/overcloudrc
  2. Bare Metal Provisioning がベアメタルサーバーのクリーニングに使用するネットワークの UUID を特定します。

    # openstack network list

    neutron net-list の出力の id フィールドから UUID を選択します。

  3. /etc/ironic/ironic.conf ファイルの cleaning_network_uuid をクリーニングネットワークの UUID に設定します。

    # openstack-config --set /etc/ironic/ironic.conf neutron cleaning_network_uuid CLEANING_NETWORK_UUID

    CLEANING_NETWORK_UUID は、以前のステップで取得したネットワークの id に置き換えます。

  4. Bare Metal Provisioning サービスを再起動します。

    # systemctl restart openstack-ironic-conductor

手動クリーニングの設定

  1. ベアメタルサーバーが管理可能な状態であることを確認します。

    # ironic node-set-provision-state NODE_ID manage

    NODE_ID はベアメタルサーバーの UUID またはノード名に置き換えます。

  2. ベアメタルサーバーをクリーニングの状態に切り替えてクリーニングのステップを実行します。

    # ironic node-set-provision-state NODE_ID clean --clean-steps CLEAN_STEPS

    NODE_ID は、ベアメタルサーバーの UUID またはノード名に置き換えます。CLEAN_STEPS は JSON 形式のクリーニングステップまたはクリーニングステップが記載されたファイルへのパスに置き換えるか、標準入力から直接置き換えます。

     '[{"interface": "deploy", "step": "erase_devices"}]'

詳しくは、「OpenStack - Node Cleaning」を参照してください。

2.3.4. ベアメタルノード上で優先するルートディスクの指定

deploy ramdisk がベアメタル上でブートする際には、Bare Metal Provisioning が最初に検出するディスクが root デバイス (イメージが保存されるデバイス) となります。ベアメタルノードに SATA、SCSI、または IDE ディスクコントローラーが複数ある場合には、対応するディスクデバイスが追加される順序は任意で、再起動するたびに変更される場合があります。たとえば、/dev/sda および /dev/sdb は起動するたびに切り替わるので、ベアメタルノードがデプロイされる度に Bare Metal Provisioning が異なるディスクを選択することになります。

ディスクのヒントを使用すると、deploy ramdisk にヒントを渡して、Bare Metal Provisioning がイメージをデプロイする先のディスクを指定することができます。以下の表には、ベアメタル上で優先する root ディスクを選択するのに使用するヒントをまとめています。

表2.1 ディスクのヒント

ヒント説明

model

(STRING):

ディスクデバイスの識別子

vendor

(STRING):

ディスクデバイスのベンダー

serial

(STRING):

ディスクデバイスのシリアル番号

size

(INT):

ディスクデバイスのサイズ (GB 単位)

注記: ノードの local_gb プロパティーは、パーティショニングを考慮に入れて、実際のディスクサイズよりも 1 GB 少ない値に設定されることが多くあります。ただし、この場合には size は実際のサイズにすべきです。たとえば、128 GB のディスク local_gb は 127 ですが、size ヒントは 128 です。

wwn

(STRING):

ストレージ一意識別子

wwn_with_extension

(STRING):

ベンダー拡張が末尾に付いたストレージ一意識別子

wwn_vendor_extension

(STRING):

ベンダーのストレージ一意識別子

name

(STRING):

デバイス名 (例: /dev/md0)

警告: ルートデバイスヒント名は一定の名前が付いたデバイス (例: RAID ボリューム) のみを使用すべきです。SATA、SCSI、IDE ディスクコントローラーを使用すると、Linux 内でデバイスノードが任意の順序で追加されて、/dev/sda や /dev/sdb などのデバイスがブート時に切り替わってしまうので、これらのディスクコントローラーは使用しないでください。詳しくは、「永続的な命名」を参照してください。

1 つのベアメタルノードに 1 つまたは複数のディスクデバイスヒントがある場合は、ノードのプロパティーを root_device キーで更新します。以下に例を示します。

# ironic node-update <node-uuid> add properties/root_device='{"wwn": "0x4000cca77fc4dba1"}'

この例では、指定した WWN 値と等しい wwn が設定されたディスクデバイスを Bare Metal Provisioning が選択することを保証します。

ヒントには、値の文字列の最初に演算子を付けることができます。演算子が指定されていない場合には、デフォルトは == (数値) と s== (文字列の値) です。

表2.2 サポートされている演算子

演算子説明

数値

=

等しいかより大きい (>= と同等)

==

等しい

!=

等しくない

>=

より大きいか等しい

>

より大きい

<=

より小さいか等しい

<

より小さい

文字列 (python の比較)

s==

等しい

s!=

等しくない

s>=

より大きいか等しい

s>

より大きい

s<=

より小さいか等しい

s<

より小さい

<in>

サブ文字列

コレクション

<all-in>

コレクションに含まれる全要素

<or>

それらのいずれか 1 つを検索

以下の例は、ベアメタルノードのプロパティーを更新して特定のディスクを選択する方法を示しています。

  • 60 GB より大きいか等しい非回転 (SSD)ディスクを検索します。
# ironic node-update <node-uuid> add properties/root_device='{"size": ">= 60", "rotational": false}'
  • Samsung または Winsys ディスクを検索します。
# ironic node-update <node-uuid> add properties/root_device='{"vendor": "<or> samsung <or> winsys"}'
注記

複数のヒントが指定されている場合には、ディスクデバイスはそれらのヒントをすべて満たす必要があります。

2.4. ホストアグリゲートを使用した物理/仮想マシンのプロビジョニングの分離

ホストアグリゲートは、OpenStack Compute がアベイラビリティーゾーンを分割して、共通する特定のプロパティーでノードをグループ化するのに使用します。キーと値のペアは、ホストアグリゲートとインスタンスのフレーバーの両方で設定され、これらのプロパティーを定義します。インスタンスのプロビジョニング時には、Compute のスケジューラーがフレーバー上のキーと値のペアをホストアグリゲートに割り当てられたキーと値のペアと比較し、物理マシン上または openstack-nova-compute ノード上の仮想マシンとして、インスタンスが正しいアグリゲート内かつ正しいホスト上にプロビジョニングされるようにします。

Red Hat OpenStack Platform 環境がベアメタルマシンと仮想マシンの両方をプロビジョニングするように設定されている場合には、ホストアグリゲートを使用してインスタンスが物理マシンまたは仮想マシンとして起動するように指示します。 以下の手順では、ベアメタルホスト用のホストアグリゲートを作成し、ホストの種別を baremetal に指定してキーと値のペアを追加します。このアグリゲートに分類されたベアメタルノードはいずれも、このキーと値のペアを継承します。同じキーと値のペアは、その後にインスタンスのプロビジョニングに使用されるフレーバーに追加されます。

ベアメタルのプロビジョニングに使用するイメージ (1 つまたは複数) が hypervisor_type=ironic プロパティーを設定して Image サービスにアップロードされた場合には、スケジューラーもスケジューリングの決定でそのキーと値のペアを使用します。イメージのプロパティーが適用されなかった場合に有効なスケジューリングを行うようにするには、イメージプロパティーの設定に加えて、ホストアグリゲートを追加で設定します。イメージのビルド/アップロードについての詳しい情報は、「ベアメタルイメージの作成」を参照してください。

Bare Metal Provisioning 向けのホストアグリゲートの作成

  1. デフォルトの nova アベイラビリティーゾーンで baremetal 用のホストアグリゲートを作成します。

    # nova aggregate-create baremetal nova
  2. アグリゲートに追加されたホストに hypervisor_type=ironic プロパティーを割り当てる baremetal アグリゲート上のメタデータを設定します。

    # nova aggregate-set-metadata baremetal hypervisor_type=ironic
  3. openstack-nova-compute ノードを Bare Metal Provisioning ドライバーとともに baremetal アグリゲートに追加します。

    # nova aggregate-add-host baremetal COMPUTE_HOSTNAME

    COMPUTE_HOSTNAME は、openstack-nova-compute サービスをホストするシステムのホスト名に置き換えます。Bare Metal Provisioning の全要求を処理するには、専用のコンピュートホストを 1 台使用するべきです。

  4. プロビジョニング用に作成したフレーバー (1 つまたは複数) に ironic のハイパーバイザーのプロパティーを追加します。

    # nova flavor-key FLAVOR_NAME set hypervisor_type="ironic"

    FLAVOR_NAME はフレーバー名に置き換えます。

  5. /etc/nova/nova.confscheduler_default_filters の下にある既存の一覧に以下の Compute フィルタースケジューラーを追加します。

    AggregateInstanceExtraSpecsFilter

    このフィルターは、ホストアグリゲートに割り当てられたキーと値のペアを Compute のスケジューラーが確実に処理するようにします。

2.5. SSH と virsh を使用した Bare Metal Provisioning のテスト例

単一の物理ホストで、ベアメタルノードとして機能する 2 つの仮想マシン上にインスタンスをデプロイして、Bare Metal Provisioning の設定をテストします。両仮想マシンは libvirtvirsh を使用して仮想化されます。

重要

この SSH ドライバーは、検証および評価のみを目的としており、Red Hat OpenStack Platform のエンタープライズ環境には推奨されません。

このシナリオには以下のリソースが必要です。

  • Bare Metal Provisioning をオーバークラウドノード上に設定した Red Hat OpenStack Platform 環境を 1 つ。本ガイドの全ステップを完了しておく必要があります。
  • Red Hat Enterprise Linux 7.2 と libvirt 仮想化ツールをインストール済みのベアメタルマシンを 1 つ。このシステムは、仮想ベアメタルノードが属するホストとして機能します。
  • Bare Metal Provisioning ノードと、仮想ベアメタルノードが属するホストとの間のネットワーク接続を 1 つ。このネットワークはベアメタルプロビジョニングネットワークとして機能します。

2.5.1. 仮想ベアメタルノードの作成

テストシナリオでベアメタルノードとして機能する仮想マシンを 2 つ作成します。 ノードは Node1 および Node2 と呼びます。

仮想ベアメタルノードの作成

  1. libvirt ホストから仮想マシンマネージャーにアクセスします。
  2. 以下の設定で仮想マシンを 2 つ作成します。

    • 1 x 仮想 CPU
    • 2048 MB のメモリー
    • ネットワークブート (PXE)
    • 20 GB のストレージ
    • ネットワークソース: ホストデバイス eth0: macvtapソースモード: Bridge。macvtap を選択すると、仮想マシンはホストのイーサネットネットワークインターフェースを共有します。このように設定すると、Bare Metal Provisioning ノードは仮想ノードに直接アクセスすることが可能となります。
  3. 両仮想マシンをシャットダウンします。

2.5.2. SSH キーペアの作成

Bare Metal Provisioning ノードが libvirt ホストに接続できるようにする SSH キーペアを作成します。

SSH キーペアの作成

  1. Bare Metal Provisioning ノードで、SSH キーを作成します。

    # ssh-keygen -t rsa -b 2048 -C "user@domain.com" -f ./virtkey

    user@domain.com は、このキーを特定するメールアドレスまたはその他のコメントに置き換えます。コマンドがパスフレーズの入力を要求したら、パスフレーズは入力せずに Enter を押して次に進みます。このコマンドにより、秘密鍵 (virtkey) と公開鍵 (virtkey.pub) の 2 つのファイルが作成されます。

  2. 公開鍵の内容を libvirt ホストの root ユーザーの /root/.ssh/authorized_keys ファイルにコピーします。

    # ssh-copy-id -i virtkey root@LIBVIRT_HOST

    LIBVIRT_HOSTlibvirt ホストの IP アドレスまたはホスト名に置き換えます。

秘密鍵 (virtkey) は、ノードの登録時に使用されます。

2.5.3. ベアメタルノードとしての仮想ノードの追加

インスタンスをプロビジョニングする仮想マシンをノードとして追加します。以下の例では、ドライバーの詳細は手動で指定し、ノードの詳細はハードウェア検査を使用して検出します。ノードの詳細は、ノード別に手動で追加することも可能です。詳しくは、「手動によるノードの追加」を参照してください。

仮想ノードをベアメタルノードとして追加する手順

  1. Bare Metal Provisioning コンダクターサービスノードで、pxe_ssh ドライバーを有効にします。

    # openstack-config --set /etc/ironic/ironic.conf \
       DEFAULT enabled_drivers pxe_ssh

    pxe_ssh を既存のドライバーの一覧に追加する場合には、ファイルを開いて、enabled_drivers に記載されているリストにドライバーをコンマ区切りで追加します。

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

    # source ~/keystonerc_admin
  3. 最初のノードを追加して、libvirt ホストの SSH 情報を登録します。

    # ironic node-create -d pxe_ssh -n Node1 \
       -i ssh_virt_type=virsh \
       -i ssh_username=root \
       -i ssh_key_filename=VIRTKEY_FILE_PATH \
       -i ssh_address=LIBVIRT_HOST_IP \
       -i deploy_kernel=KERNEL_UUID \
       -i deploy_ramdisk=INITRAMFS_UUID

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

    • VIRTKEY_FILE_PATHvirtkey SSH 秘密鍵ファイルの絶対パスに置き換えます。
    • LIBVIRT_HOST_IP は、libvirt ホストの IP アドレスまたはホスト名に置き換えます。
    • KERNEL_UUID は、Image サービスにアップロードされた .kernel イメージの一意識別子に置き換えます。
    • INITRAMFS_UUID は、Image サービスにアップロードされた .initramfs イメージの一意識別子に置き換えます。
  4. 上記と同じコマンドで、 Node1Node2 に置き換えて実行し、2 番目のノードを追加します。
  5. ノードを設定して、初回のデプロイの後には、PXE や仮想メディアの代わりに、そのノードのディスクにインストールされたローカルのブートローダーからリブートするようにします。ノードのプロビジョニングに使用するフレーバーでも、ローカルブートの機能を設定しておく必要があります。ローカルブートを有効にするには、ノードのデプロイに使用するイメージに grub2 が含まれる必要があります。ローカルブートを以下のように設定します。

    # ironic node-update Node1 add \
       properties/capabilities="boot_option:local"
    # ironic node-update Node2 add \
       properties/capabilities="boot_option:local"
  6. ノードを管理可能な状態に切り替えます。

    # ironic node-set-provision-state Node1 manage
    # ironic node-set-provision-state Node2 manage
  7. ノードに対する検査を開始します。

    # ironic node-set-provision-state Node1 inspect
    # ironic node-set-provision-state Node2 inspect

    ノードをプロビジョニングする前に、ノードの検出および検査プロセスは完了するまで実行する必要があります。ノードの検査のステータスを確認するには、ironic node-list を実行して Provision State の箇所を探します。検査が正常に完了すると、ノードは available の状態になります。

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

    # ironic node-validate Node1
    # ironic node-validate Node2
    +------------+--------+----------------------------+
    | Interface  | Result | Reason                     |
    +------------+--------+----------------------------+
    | console    | None   | not supported              |
    | deploy     | True   |                            |
    | inspect    | True   |                            |
    | management | True   |                            |
    | power      | True   |                            |
    +------------+--------+----------------------------+

    上記のコマンドの出力には、各インターフェースが True または None と報告されるはずです。None とマークされたインターフェースは、設定していないか、ドライバーがサポートしていないインターフェースです。

  9. ノードの追加が正常に完了したら、「3章ベアメタルインスタンスの起動」の手順に従って 2 つのノードを起動します。