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 と通信するための設定
Identity に管理ユーザーとしてアクセスするためのシェルを設定します。
# source ~stack/overcloudrc
ベアメタルインスタンスをプロビジョニングするためのフラットなネットワークを作成します。
# neutron net-create --tenant-id TENANT_ID sharednet1 --shared \ --provider:network_type flat --provider:physical_network PHYSNET
TENANT_ID はネットワークを作成するテナントの一意識別子に、PHYSNET は物理ネットワークの名前に置き換えます。
フラットネットワーク上にサブネットを作成します。
# 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 アドレスに置き換えます。
ネットワークとサブネットをルーターに接続して、メタデータ要求が OpenStack Networking サービスによって応答されるようにします。
# neutron router-create ROUTER_NAME
ROUTER_NAME
はルーターの名前に置き換えます。ベアメタルのサブネットにこのルーターをインターフェースとして追加します。
# neutron router-interface-add ROUTER_NAME BAREMETAL_SUBNET
ROUTER_NAME は、ルーターの名前に、
BAREMETAL_SUBNET
は以前に作成した ID またはサブネット名に置き換えます。これにより、cloud-init
からのメタデータ要求に応答することができます。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 に置き換えます。
Bare Metal Provisioning サービスを再起動します。
# systemctl restart openstack-ironic-conductor.service
2.1.2. Bare Metal Provisioning フレーバーの作成
デプロイメントの一部として使用するフレーバーを作成する必要があります。このフレーバーの仕様 (メモリー、CPU、ディスク) はベアメタルノードが提供する仕様以下である必要があります。
Identity に管理ユーザーとしてアクセスするためのシェルを設定します。
# source ~stack/overcloudrc
既存のフレーバーを一覧表示します。
# openstack flavor list
Bare Metal Provisioning サービス向けに新規フレーバーを作成します。
# openstack flavor create --id auto --ram RAM --vcpus VCPU --disk DISK --public baremetal
RAM
は RAM のメモリーに、VCPU
は仮想 CPU 数に、DISK
はディスクストレージの値に置き換えます。指定したそれぞれの値を使用して新規フレーバーが作成されたことを確認します。
# 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
ファイルのセクションをコピーして、必要に応じて変更します。
overcloudrc
ファイルを読み込んで、.json
ファイルをインポートします。# source ~stack/overcloudrc # openstack baremetal import --json ./baremetal.json
Bare Metal Provisioning サービス内のベアメタルノードの
driver_info
セクションのdeploy_kernel
とdeploy_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 プロキシーの設定
Identity に管理ユーザーとしてアクセスするためのシェルを設定します。
# source ~stack/overcloudrc
ベアメタルノードドライバーが HTTP または HTTPS を使用するための設定
# openstack baremetal node set NODE_UUID \ --driver_info image_https_proxy=HTTPS://PROXYIP:PORT
この例では、HTTPS プロトコルを使用します。HTTPS の代わりに HTTP を使用する場合には、
driverinfo/image_http_proxy
パラメーターを指定してください。イメージが要求された時に、Bare Metal Provisioning が Object Storage のキャッシュ済み一時 URL を再使用するように設定します。
# openstack-config --set /etc/ironic/ironic.conf glance swift_temp_url_cache_enabled=true
プロキシーサーバーは、URL のクエリーの部分に基づいて、要求が生成される度に毎回変更されるクエリーパラメーターが含まれている場合には、同じイメージには新規キャッシュエントリーを作成しません。
生成された 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 の値以上である必要があります。
ハードウェアに対して、ダウンロードを開始するまでの遅延時間 (秒単位) を設定します。
# 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
ハードウェア検査の設定
- PXE ブートを使用したベアメタルシステムの検出に使用する Ironic Python Agent の kernel と ramdisk のイメージを取得します。これらのイメージは、https://access.redhat.com/downloads/content/191/ver=9/rhel---7/9/x86_64/product-software で Ironic Python Agent Image for RHOSP director 9.0 というラベルの付いた TAR アーカイブで提供されています。この TAR アーカイブをダウンロードして、そこからイメージファイル (ironic-python-agent.kernel および ironic-python-agent.initramfs) を抽出してから、それらを TFTP サーバーの /tftpboot ディレクトリーにコピーしてください。
ハードウェア検査をホストするサーバーで Red Hat OpenStack Platform 9 director for RHEL 7 (RPMs) チャンネルを有効にします。
# subscription-manager repos --enable=rhel-7-server-openstack-9-director-rpms
openstack-ironic-inspector パッケージをインストールします。
# yum install openstack-ironic-inspector
ironic.conf ファイルで検査を有効にします。
# openstack-config --set /etc/ironic/ironic.conf \ inspector enabled True
ハードウェア検査サービスを別のサーバーでホストする場合には、コンダクターサービスをホストするサーバーでその URL を設定します。
# openstack-config --set /etc/ironic/ironic.conf \ inspector service_url http://INSPECTOR_IP:5050
INSPECTOR_IP はハードウェア検査をホストするサーバーのホスト名または IP アドレスに置き換えます。
ハードウェア検査サービスに認証情報を提供します。
# 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 との認証で使用するパスワードに置き換えます。
オプションで、ハードウェア検査が RAM ディスクのログを保管するように設定します。
# openstack-config --set /etc/ironic-inspector/inspector.conf \ processing ramdisk_logs_dir /var/log/ironic-inspector/ramdisk
オプションで、複数のローカルディスクを使用するベアメタルマシンでブロックデバイスを収集してルートデバイスを公開する追加のデータ処理プラグインを有効にします。
ramdisk_error
、root_disk_selection
、scheduler
、validate_interfaces
はデフォルトで有効化され、無効にすべきではありません。以下のコマンドを実行して、root_device_hint
を一覧に追加します。# openstack-config --set /etc/ironic-inspector/inspector.conf \ processing processing_hooks '$default_processing_hooks,root_device_hint'
初期
ironic inspector
データベースを生成します。# ironic-inspector-dbsync --config-file /etc/ironic-inspector/inspector.conf upgrade
inspector データベースファイルを更新して、ironic-inspector が所有するようにします。
# chown ironic-inspector /var/lib/ironic-inspector/inspector.sqlite
テキストエディターで /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 アドレスに置き換えます。
syslinux bootloader
をtftp
ディレクトリーにコピーします。# cp /usr/share/syslinux/pxelinux.0 /tftpboot/pxelinux.0
オプションで、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 との認証で使用するパスワードに置き換えます。
テキストエディターで /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
までのテキストは、一行に記載する必要がある点に注意してください。/tftpboot/ ディレクトリーおよびそのファイルのセキュリティーコンテキストをリセットします。
# restorecon -R /tftpboot/
このステップでは、ディレクトリーに正しい SELinux セキュリティーラベルが設定され、dnsmasq サービスがディレクトリーにアクセスできることを確認します。
ハードウェア検査サービスと 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 ユーザーとしてログインして実行する必要があります。
ハードウェア検査を使用してノードを追加する方法
Identity を管理ユーザーとして使用するためのシェルを設定します。
# source ~/keystonerc_admin
新規ノードを追加します。
# ironic node-create -d DRIVER_NAME
DRIVER_NAME は、Bare Metal Provisioning がこのノードのプロビジョニングに使用するドライバーの名前に置き換えます。このドライバーは、/etc/ironic/ironic.conf ファイルで有効にしておく必要があります。ノードを作成するには、少なくともドライバーの名前を指定する必要があります。
重要ノードの一意識別子を書き留めておきます。
ノードは論理名または UUID で参照することができます。オプションで、ノードに論理名を割り当てます。
# ironic node-update NODE_UUID add name=NAME
NODE_UUID は、ノードの一意識別子に置き換えます。NAME は、ノードの論理名に置き換えます。
ドライバーが必要とするノードの情報を確認してから、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 は、プロパティーの有効な値に置き換えます。
ノードドライバーのデプロイカーネルとデプロイ 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 イメージの一意識別子に置き換えます。
ノードを設定して、初回のデプロイの後には、PXE や仮想メディアの代わりに、そのノードのディスクにインストールされたローカルのブートローダーからリブートするようにします。ノードのプロビジョニングに使用するフレーバーでも、ローカルブートの機能を設定する必要があります。ローカルブートを有効にするには、ノードのデプロイに使用するイメージに grub2 が含まれる必要があります。ローカルブートを以下のように設定します。
# ironic node-update NODE_UUID add \ properties/capabilities="boot_option:local"
NODE_UUID は、ノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。
ベアメタルノードを
manageable
状態に切り替えます。# ironic node-set-provision-state NODE_UUID manage
NODE_UUID は、ノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。
検査を開始します。
# openstack baremetal introspection start NODE_UUID --discoverd-url http://overcloud IP:5050
-
NODE_UUID はノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。ノードをプロビジョニングする前に、ノードの検出および検査プロセスは完了するまで実行する必要があります。ノードの検査のステータスを確認するには、ironic node-list を実行して
Provision State
の箇所を探します。検査が正常に完了すると、ノードはavailable
の状態になります。 -
overcloud IP は ironic.conf で以前設定した
service_url
の値に置き換えます。
-
NODE_UUID はノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。ノードをプロビジョニングする前に、ノードの検出および検査プロセスは完了するまで実行する必要があります。ノードの検査のステータスを確認するには、ironic node-list を実行して
ノードの設定を検証します。
# 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 ユーザーとしてログインして実行する必要があります。
ハードウェア検査を使用せずにノードを追加する方法
Identity を管理ユーザーとして使用するためのシェルを設定します。
# source ~/keystonerc_admin
新規ノードを追加します。
# ironic node-create -d DRIVER_NAME
DRIVER_NAME は、Bare Metal Provisioning がこのノードのプロビジョニングに使用するドライバーの名前に置き換えます。このドライバーは、/etc/ironic/ironic.conf ファイルで有効にしておく必要があります。ノードを作成するには、少なくともドライバーの名前を指定する必要があります。
重要ノードの一意識別子を書き留めておきます。
ノードは論理名または UUID で参照することができます。オプションで、ノードに論理名を割り当てます。
# ironic node-update NODE_UUID add name=NAME
NODE_UUID は、ノードの一意識別子に置き換えます。NAME は、ノードの論理名に置き換えます。
ドライバーが必要とするノードの情報を確認してから、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 は、プロパティーの有効な値に置き換えます。
ノードドライバーのデプロイカーネルとデプロイ 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 イメージの一意識別子に置き換えます。
ノードのプロパティーを更新して、ノード上のハードウェアの仕様と一致するようにします。
# 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 は使用するアーキテクチャーのタイプに置き換えます。
ノードを設定して、初回のデプロイの後には、PXE や仮想メディアの代わりに、そのノードのディスクにインストールされたローカルのブートローダーからリブートするようにします。ノードのプロビジョニングに使用するフレーバーでも、ローカルブートの機能を設定する必要があります。ローカルブートを有効にするには、ノードのデプロイに使用するイメージに grub2 が含まれる必要があります。ローカルブートを以下のように設定します。
# ironic node-update NODE_UUID add \ properties/capabilities="boot_option:local"
NODE_UUID は、ノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。
Bare Metal Provisioning にノードのネットワークインターフェースカードの情報を提供します。各 NIC の MAC アドレスでポートを作成します。
# ironic port-create -n NODE_UUID -a MAC_ADDRESS
NODE_UUID は、ノードの一意識別子に置き換えます。MAC_ADDRESS は、ノード上の NIC の MAC アドレスに置き換えます。
ノードの設定を検証します。
# 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 サービスのクリーニングネットワークを設定するには、以下の手順に従ってください。
Identity に管理ユーザーとしてアクセスするためのシェルを設定します。
# source ~stack/overcloudrc
Bare Metal Provisioning がベアメタルサーバーのクリーニングに使用するネットワークの UUID を特定します。
# openstack network list
neutron net-list
の出力の id フィールドから UUID を選択します。/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 に置き換えます。
Bare Metal Provisioning サービスを再起動します。
# systemctl restart openstack-ironic-conductor
手動クリーニングの設定
ベアメタルサーバーが管理可能な状態であることを確認します。
# ironic node-set-provision-state NODE_ID manage
NODE_ID はベアメタルサーバーの UUID またはノード名に置き換えます。
ベアメタルサーバーをクリーニングの状態に切り替えてクリーニングのステップを実行します。
# 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 単位)
注記: ノードの |
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 の比較) |
|
等しい |
|
等しくない | |
|
より大きいか等しい | |
|
より大きい | |
|
より小さいか等しい | |
|
より小さい | |
|
サブ文字列 | |
コレクション |
|
コレクションに含まれる全要素 |
|
それらのいずれか 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 向けのホストアグリゲートの作成
デフォルトの
nova
アベイラビリティーゾーンでbaremetal
用のホストアグリゲートを作成します。# nova aggregate-create baremetal nova
アグリゲートに追加されたホストに
hypervisor_type=ironic
プロパティーを割り当てるbaremetal
アグリゲート上のメタデータを設定します。# nova aggregate-set-metadata baremetal hypervisor_type=ironic
openstack-nova-compute ノードを Bare Metal Provisioning ドライバーとともに
baremetal
アグリゲートに追加します。# nova aggregate-add-host baremetal COMPUTE_HOSTNAME
COMPUTE_HOSTNAME は、openstack-nova-compute サービスをホストするシステムのホスト名に置き換えます。Bare Metal Provisioning の全要求を処理するには、専用のコンピュートホストを 1 台使用するべきです。
プロビジョニング用に作成したフレーバー (1 つまたは複数) に
ironic
のハイパーバイザーのプロパティーを追加します。# nova flavor-key FLAVOR_NAME set hypervisor_type="ironic"
FLAVOR_NAME はフレーバー名に置き換えます。
/etc/nova/nova.conf の
scheduler_default_filters
の下にある既存の一覧に以下の Compute フィルタースケジューラーを追加します。AggregateInstanceExtraSpecsFilter
このフィルターは、ホストアグリゲートに割り当てられたキーと値のペアを Compute のスケジューラーが確実に処理するようにします。
2.5. SSH と virsh を使用した Bare Metal Provisioning のテスト例
単一の物理ホストで、ベアメタルノードとして機能する 2 つの仮想マシン上にインスタンスをデプロイして、Bare Metal Provisioning の設定をテストします。両仮想マシンは libvirt と virsh を使用して仮想化されます。
この 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
と呼びます。
仮想ベアメタルノードの作成
- libvirt ホストから仮想マシンマネージャーにアクセスします。
以下の設定で仮想マシンを 2 つ作成します。
- 1 x 仮想 CPU
- 2048 MB のメモリー
- ネットワークブート (PXE)
- 20 GB のストレージ
-
ネットワークソース:
ホストデバイス eth0: macvtap
、ソースモード:Bridge
。macvtap を選択すると、仮想マシンはホストのイーサネットネットワークインターフェースを共有します。このように設定すると、Bare Metal Provisioning ノードは仮想ノードに直接アクセスすることが可能となります。
- 両仮想マシンをシャットダウンします。
2.5.2. SSH キーペアの作成
Bare Metal Provisioning ノードが libvirt ホストに接続できるようにする SSH キーペアを作成します。
SSH キーペアの作成
Bare Metal Provisioning ノードで、SSH キーを作成します。
# ssh-keygen -t rsa -b 2048 -C "user@domain.com" -f ./virtkey
user@domain.com は、このキーを特定するメールアドレスまたはその他のコメントに置き換えます。コマンドがパスフレーズの入力を要求したら、パスフレーズは入力せずに Enter を押して次に進みます。このコマンドにより、秘密鍵 (virtkey) と公開鍵 (virtkey.pub) の 2 つのファイルが作成されます。
公開鍵の内容を libvirt ホストの root ユーザーの /root/.ssh/authorized_keys ファイルにコピーします。
# ssh-copy-id -i virtkey root@LIBVIRT_HOST
LIBVIRT_HOST は libvirt ホストの IP アドレスまたはホスト名に置き換えます。
秘密鍵 (virtkey) は、ノードの登録時に使用されます。
2.5.3. ベアメタルノードとしての仮想ノードの追加
インスタンスをプロビジョニングする仮想マシンをノードとして追加します。以下の例では、ドライバーの詳細は手動で指定し、ノードの詳細はハードウェア検査を使用して検出します。ノードの詳細は、ノード別に手動で追加することも可能です。詳しくは、「手動によるノードの追加」を参照してください。
仮想ノードをベアメタルノードとして追加する手順
Bare Metal Provisioning コンダクターサービスノードで、
pxe_ssh
ドライバーを有効にします。# openstack-config --set /etc/ironic/ironic.conf \ DEFAULT enabled_drivers pxe_ssh
pxe_ssh
を既存のドライバーの一覧に追加する場合には、ファイルを開いて、enabled_drivers
に記載されているリストにドライバーをコンマ区切りで追加します。Identity を管理ユーザーとして使用するためのシェルを設定します。
# source ~/keystonerc_admin
最初のノードを追加して、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_PATH は
virtkey
SSH 秘密鍵ファイルの絶対パスに置き換えます。 - LIBVIRT_HOST_IP は、libvirt ホストの IP アドレスまたはホスト名に置き換えます。
- KERNEL_UUID は、Image サービスにアップロードされた .kernel イメージの一意識別子に置き換えます。
- INITRAMFS_UUID は、Image サービスにアップロードされた .initramfs イメージの一意識別子に置き換えます。
-
VIRTKEY_FILE_PATH は
-
上記と同じコマンドで、
Node1
をNode2
に置き換えて実行し、2 番目のノードを追加します。 ノードを設定して、初回のデプロイの後には、PXE や仮想メディアの代わりに、そのノードのディスクにインストールされたローカルのブートローダーからリブートするようにします。ノードのプロビジョニングに使用するフレーバーでも、ローカルブートの機能を設定しておく必要があります。ローカルブートを有効にするには、ノードのデプロイに使用するイメージに grub2 が含まれる必要があります。ローカルブートを以下のように設定します。
# ironic node-update Node1 add \ properties/capabilities="boot_option:local" # ironic node-update Node2 add \ properties/capabilities="boot_option:local"
ノードを管理可能な状態に切り替えます。
# ironic node-set-provision-state Node1 manage # ironic node-set-provision-state Node2 manage
ノードに対する検査を開始します。
# ironic node-set-provision-state Node1 inspect # ironic node-set-provision-state Node2 inspect
ノードをプロビジョニングする前に、ノードの検出および検査プロセスは完了するまで実行する必要があります。ノードの検査のステータスを確認するには、ironic node-list を実行して
Provision State
の箇所を探します。検査が正常に完了すると、ノードはavailable
の状態になります。ノードの設定を検証します。
# 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
とマークされたインターフェースは、設定していないか、ドライバーがサポートしていないインターフェースです。- ノードの追加が正常に完了したら、「3章ベアメタルインスタンスの起動」の手順に従って 2 つのノードを起動します。