第4章 デプロイ後の Bare Metal サービスの設定
本項では、デプロイ後のオーバークラウドの設定に必要な手順について説明します。
4.1. OpenStack Networking の設定
DHCP、PXE ブート、およびその他の必要な場合に OpenStack Networking が Bare Metal サービスと通信するように設定します。以下の手順では、ベアメタルのプロビジョニングに使用する単一のフラットなネットワークのユースケース向けに OpenStack Networking を設定します。この設定では、ML2 プラグインと Open vSwitch エージェントを使用します。flat
ネットワークのみがサポートされます。
この手順では、ベアメタルネットワークインターフェースを使用してブリッジを作成し、リモート接続をすべて破棄します。
以下の手順はすべて、root ユーザーとしてログインしている間、OpenStack Networking をホストするサーバーで実行する必要があります。
OpenStack Networking が Bare Metal サービスと通信するための設定
Identity に管理ユーザーとしてアクセスするためのシェルを設定します。
$ source ~/overcloudrc
ベアメタルインスタンスをプロビジョニングするためのフラットなネットワークを作成します。
$ openstack network create \ --provider-network-type flat \ --provider-physical-network baremetal \ --share NETWORK_NAME
NETWORK_NAME は、このネットワークの名前に置き換えます。仮想ネットワークの実装先となる物理ネットワークの名前 (この場合は
baremetal
) は、以前の手順で~/templates/network-environment.yaml
にNeutronBridgeMappings
パラメーターで設定されています。フラットネットワーク上にサブネットを作成します。
$ 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 アドレスに置き換えます。
ネットワークとサブネットをルーターに接続して、メタデータ要求が OpenStack Networking サービスによって処理されるようにします。
$ openstack router create ROUTER_NAME
ROUTER_NAME
は、ルーターの名前に置き換えます。このルーターに Bare Metal サブネットを追加します。
$ openstack router add subnet ROUTER_NAME BAREMETAL_SUBNET
ROUTER_NAME をルーターの名前に、BAREMETAL_SUBNET を以前のステップで作成したサブネットの ID または名前に、それぞれ置き換えます。これにより、
cloud-init
からのメタデータ要求に対応すると共に、ノードを設定することができます。Bare Metal サービスを実行しているコントローラー上のプロバイダーネットワークの UUID を指定して、クリーニングを設定します。
~/templates/ironic.yaml
parameter_defaults: ControllerExtraConfig: ironic::conductor::cleaning_network_uuid: UUID
UUID
は、以前のステップで作成されたベアメタルネットワークの UUID に置き換えます。UUID は、
openstack network show
で確認することができます。openstack network show NETWORK_NAME -f value -c id
注記ネットワークの UUID は、オーバークラウドの初回のデプロイメントが完了するまで利用できないので、この設定はデプロイ後に実行する必要があります。
-
「オーバークラウドのデプロイ」の説明に従って
openstack overcloud deploy
コマンドを実行し、オーバークラウドを再デプロイして変更を適用します。
4.2. ベアメタルフレーバーの作成
デプロイメントの一部として使用するフレーバーを作成する必要があります。このフレーバーの仕様 (メモリー、CPU、ディスク) はベアメタルノードが提供する仕様以下である必要があります。
Identity に管理ユーザーとしてアクセスするためのシェルを設定します。
$ source ~/overcloudrc
既存のフレーバーを一覧表示します。
$ openstack flavor list
Bare Metal サービス向けに新規フレーバーを作成します。
$ openstack flavor create \ --id auto --ram RAM \ --vcpus VCPU --disk DISK \ --property baremetal=true \ --public baremetal
RAM
はメモリー量、VCPU
は仮想 CPU 数、DISK
はディスクストレージの値に置き換えます。baremetal
プロパティーは、ベアメタルを仮想インスタンスと区別するために使用されます。指定したそれぞれの値を使用して新規フレーバーが作成されたことを確認します。
$ openstack flavor list
4.3. ベアメタルイメージの作成
デプロイメントには 2 セットのイメージが必要です。
-
デプロイイメージ は、Bare Metal サービスがベアメタルノードをブートしてユーザーイメージをベアメタルノードにコピーするのに使用されます。デプロイイメージは、
カーネル
イメージとramdisk
イメージで構成されます。 ユーザーイメージ は、ベアメタルノードにデプロイされるイメージです。ユーザーイメージにも
カーネル
イメージとramdisk
イメージが含まれますが、追加でメイン
イメージも含まれます。メインイメージは、ルートパーティションイメージまたは完全なディスクイメージのいずれかです。- 完全なディスクイメージ は、パーティションテーブルとブートローダーを含むイメージです。完全なディスクイメージを使用してデプロイされたノードはローカルブートをサポートするので、Bare Metal サービスはデプロイ後のノードのリブートは制御しません。
- ルートパーティションイメージ には、オペレーティングシステムのルートパーティションのみが含まれています。ルートパーティションを使用する場合には、デプロイイメージが Image サービスに読み込まれた後に、ノードのプロパティーにデプロイイメージをノードのブートイメージとして設定することができます。デプロイ後のノードのリブートでは、netboot を使用してユーザーイメージがプルダウンされます。
本項に記載する例では、ルートパーティションイメージを使用してベアメタルノードをプロビジョニングします。
4.3.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.3.2. ユーザーイメージの準備
最後に必要となるイメージは、ベアメタルノードにデプロイされるユーザーイメージです。ユーザーイメージには、カーネルイメージと ramdisk イメージに加えて、メインイメージが含まれます。
- カスタマーポータル (ログインが必要) から Red Hat Enterprise Linux KVM ゲストイメージをダウンロードします。
DIB_LOCAL_IMAGE をダウンロードしたイメージとして定義します。
$ export DIB_LOCAL_IMAGE=rhel-server-7.4-beta-1-x86_64-kvm.qcow2
diskimage-builder
ツールを使用してユーザーイメージを作成します。$ disk-image-create rhel7 baremetal -o rhel-image
これで kernel は
rhel-image.vmlinuz
として、初期 ramdisk はrhel-image.initrd
として抽出されます。イメージを 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.4. ベアメタルノードとしての物理マシンの追加
ベアメタルノードの登録には 2 つの方法があります。
- ノードの詳細情報を記載したインベントリーファイルを作成し、そのファイルを Bare Metal サービスにインポートしてからノードを利用できるようにします。
- 物理マシンをベアメタルノードとして登録してから、手動でハードウェア情報を追加し、各イーサネットの MAC アドレス用にポートを作成します。これらの手順は、overcloudrc ファイルが配置されている任意のノードで実行できます。
本項では、両方の方法について詳しく説明します。
物理マシンの登録後、新規リソースは Compute に直ぐには通知されません。これは、Compute のリソーストラッカーが定期的にしか同期していないためです。次の定期タスクが実行されると、変更が認識されるようになります。この値 scheduler_driver_task_period
は、/etc/nova/nova.conf で更新することができます。デフォルトの間隔は 60 秒です。
4.4.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>
は、Bare Metal コントローラーの IP アドレスに置き換えます。 -
<USER>
は、ユーザー名に置き換えます。 -
<PASSWORD>
は、パスワードに置き換えます。 -
<CPU_COUNT>
は、CPU の数に置き換えます。 -
<CPU_ARCHITECTURE>
は、CPU のアーキテクチャー種別に置き換えます。 -
<MEMORY>
は、メモリー容量 (MiB 単位) に置き換えます。 -
<ROOT_DISK>
は、ルートディスクの容量 (GiB 単位) に置き換えます。 <MAC_ADDRESS>
は、PXE ブートで使用する NIC の MAC アドレスに置き換えます。マシンに複数のディスクがある場合に、含める必要があるのは
root_device
のみです。<SERIAL>
は、デプロイメントに使用するディスクのシリアル番号に置き換えます。
-
Identity を管理ユーザーとして使用するためのシェルを設定します。
$ source ~/overcloudrc
インベントリーファイルを ironic にインポートします。
$ openstack baremetal create overcloud-nodes.yaml
これで、ノードは
enroll
の状態となります。各ノードでデプロイカーネルとデプロイ ramdisk を指定して、利用できるようにします。$ openstack baremetal node set NODE_UUID \ --driver-info deploy_kernel=KERNEL_UUID \ --driver-info deploy_ramdisk=INITRAMFS_UUID
以下の値を置き換えてください。
- NODE_UUID は、ノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。
KERNEL_UUID は、Image サービスにアップロードした カーネル デプロイイメージの一意識別子に置き換えます。この値は以下のコマンドで確認します。
$ openstack image show bm-deploy-kernel -f value -c id
INITRAMFS_UUID は、Image サービスにアップロードした ramdisk イメージの一意識別子に置き換えます。この値は以下のコマンドで確認します。
$ openstack image show bm-deploy-ramdisk -f value -c id
ノードが正常に登録されたことを確認します。
$ openstack baremetal node list
ノードを登録した後にその状態が表示されるまで時間がかかる場合があります。
4.4.2. ベアメタルノードの手動登録
Identity を管理ユーザーとして使用するためのシェルを設定します。
$ source ~/overcloudrc
新しいノードを追加します。
$ openstack baremetal node create --driver pxe_impitool --name NAME
ノードを作成するには、ドライバー名を指定する必要があります。この例では
pxe_impitool
を使用しています。異なるドライバーを使用するには、IronicEnabledDrivers
パラメーターを設定してそのドライバーを有効化する必要があります。サポートされているドライバーについての詳しい情報は、「付録A Bare Metal のドライバー」を参照してください。重要ノードの一意識別子を書き留めておきます。
ノードのドライバーの情報を更新して、Bare Metal サービスがノードを管理できるようにします。
$ openstack baremetal node set NODE_UUID \ --driver_info PROPERTY=VALUE \ --driver_info PROPERTY=VALUE
以下の値を置き換えてください。
- NODE_UUID は、ノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。
- PROPERTY は、ironic driver-properties コマンドで返された必要なプロパティーに置き換えます。
- VALUE は、プロパティーの有効な値に置き換えます。
ノードドライバーのデプロイカーネルとデプロイ 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 イメージの一意識別子に置き換えます。
- INITRAMFS_UUID は、Image サービスにアップロードされた .initramfs イメージの一意識別子に置き換えます。
ノードのプロパティーを更新して、ノード上のハードウェアの仕様と一致するようにします。
$ 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 は、アーキテクチャー種別に置き換えます。
オプション: 初回のデプロイの後には、
ironic-conductor
から PXE を使用する代わりに、ノードのディスクにインストールされたローカルのブートローダーからリブートするようにノードを設定します。ノードのプロビジョニングに使用するフレーバーでも、ローカルブートの機能を設定する必要があります。ローカルブートを有効にするには、ノードのデプロイに使用するイメージに grub2 が含まれている必要があります。ローカルブートを以下のように設定します。$ openstack baremetal node set NODE_UUID \ --property capabilities="boot_option:local"
NODE_UUID は、ノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。
プロビジョニングネットワーク上の NIC の MAC アドレスを使用してポートを作成することにより、Bare Metal サービスにノードのネットワークカードを通知します。
$ openstack baremetal port create --node NODE_UUID MAC_ADDRESS
NODE_UUID は、ノードの一意識別子に置き換えます。MAC_ADDRESS は、PXE ブートに使用する NIC の MAC アドレスに置き換えます。
複数のディスクがある場合には、ルートデバイスのヒントを設定してください。これにより、デプロイメントに使用すべきディスクがデプロイ ramdisk に通知されます。
$ openstack baremetal node set NODE_UUID \ --property root_device={"PROPERTY": "VALUE"}
以下の値に置き換えてください。
- NODE_UUID は、ノードの一意識別子に置き換えます。もしくは、ノードの論理名を使用します。
PROPERTY と VALUE は、デプロイメントに使用するディスクの情報に置き換えます (例:
root_device='{"size": 128}'
)。以下のプロパティーがサポートされています。
-
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)。これは、永続デバイス名が付いたデバイスのみに使用してください。注記複数のプロパティーを指定する場合には、デバイスはそれらの全プロパティーと一致する必要があります。
ノードの設定を検証します。
$ 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.5. ホストアグリゲートを使用した物理マシンと仮想マシンのプロビジョニングの分離
OpenStack Compute は、ホストアグリゲートを使用してアベイラビリティーゾーンをパーティション分割し、特定の共有プロパティーが指定されたノードをグループ化します。インスタンスがプロビジョニングされると、Compute のスケジューラーがフレーバーのプロパティーをホストアグリゲートに割り当てられたプロパティーと比較して、インスタンスが正しいアグリゲート内の正しいホストに (物理マシン上または仮想マシンとして) プロビジョニングされたことを確認します。
以下の手順は、次の作業の方法を説明します。
-
baremetal
プロパティーをフレーバーに追加して、true
またはfalse
に設定する。 -
一致する
baremetal
プロパティーを設定して、ベアメタルホスト用とコンピュートノード用のホストアグリゲートを別々に作成する。1 つのアグリゲートでグループ化されたノードは、このプロパティーを継承します。
ホストアグリゲートの作成
ベアメタル用のフレーバーで
baremetal
プロパティーをtrue
に設定します。$ openstack flavor set baremetal --property baremetal=true
仮想インスタンスに使用するフレーバーで
baremetal
プロパティーをfalse
に設定します。$ openstack flavor set FLAVOR_NAME --property baremetal=false
baremetal-hosts
という名前のホストアグリゲートを作成します。$ openstack aggregate create --property baremetal=true baremetal-hosts
各コントローラーノードを
baremetal-hosts
アグリゲートに追加します。$ openstack aggregate add host baremetal-hosts HOSTNAME
注記NovaIronic
サービスでコンポーザブルロールを作成していた場合には、このサービスがあるノードをすべてbaremetal-hosts
アグリゲートに追加します。デフォルトでは、NovaIronic
サービスがあるのはコントローラーノードのみです。virtual-hosts
という名前のホストアグリゲートを作成します。$ openstack aggregate create --property baremetal=false virtual-hosts
各コンピュートノードを
virtual-hosts
アグリゲートに追加します。$ openstack aggregate add host virtual-hosts HOSTNAME
オーバークラウドのデプロイ時に以下の Compute フィルタースケジューラーを追加していなかった場合には、この時点で /etc/nova/nova.conf の
scheduler_default_filters
セクションの既存リストに追加します。AggregateInstanceExtraSpecsFilter