第2章 オーバークラウドデプロイメント用の Ceph Storage ノードの準備
このシナリオのすべてのノードは、電源管理に IPMI を使用したベアメタルシステムです。director は Red Hat Enterprise Linux 8 イメージを各ノードにコピーするため、これらのノードにはオペレーティングシステムは必要ありません。また、これらのノード上の Ceph Storage サービスはコンテナー化されています。イントロスペクションおよびプロビジョニングのプロセスの間、director はプロビジョニングネットワークを介して各ノードと通信します。すべてのノードは、ネイティブの VLAN を通じてこのネットワークに接続されます。
2.1. Ceph Storage ノードのディスクのクリーニング
Ceph Storage OSD およびジャーナルのパーティションには GPT ディスクラベルが必要です。これは、Ceph OSD サービスをインストールする前に Ceph Storage 上の追加のディスクを GPT に変換する必要があることを意味します。director が GPT ラベルをディスクに設定できるようにするには、ディスクからすべてのメタデータを削除する必要があります。
以下の設定をお使いの /home/stack/undercloud.conf
ファイルに追加すると、director がデフォルトでディスクのメタデータをすべて削除するように設定できます。
clean_nodes=true
このオプションでは、Bare Metal Provisioning サービスが追加のステップを実行してノードを起動し、ノードが available
に設定されるたびにディスクのクリーニングを実行します。このプロセスでは、初回のイントロスペクションが終了して、各デプロイメントが開始する前に電源サイクルがもう 1 つ追加されます。Bare Metal Provisioning サービスは wipefs --force --all
コマンドを使用してクリーニングを実行します。
このオプションを設定したら、openstack undercloud install
コマンドを実行して、この設定変更を有効にします。
wipefs --force --all
コマンドにより、ディスク上の全データおよびメタデータが削除されますが、Secure Erase は実行されません。Secure Erase には非常に長い時間がかかります。
2.2. ノードの登録
ノードインベントリーファイル (instackenv.json
) を JSON 形式で director にインポートし、director がノードと通信できるようにします。このインベントリーファイルには、director がノードを登録するのに使用できるハードウェアおよび電源管理の情報が含まれています。
{ "nodes":[ { "mac":[ "b1:b1:b1:b1:b1:b1" ], "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.0.2.205" }, { "mac":[ "b2:b2:b2:b2:b2:b2" ], "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.0.2.206" }, { "mac":[ "b3:b3:b3:b3:b3:b3" ], "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.0.2.207" }, { "mac":[ "c1:c1:c1:c1:c1:c1" ], "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.0.2.208" }, { "mac":[ "c2:c2:c2:c2:c2:c2" ], "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.0.2.209" }, { "mac":[ "c3:c3:c3:c3:c3:c3" ], "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.0.2.210" }, { "mac":[ "d1:d1:d1:d1:d1:d1" ], "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.0.2.211" }, { "mac":[ "d2:d2:d2:d2:d2:d2" ], "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.0.2.212" }, { "mac":[ "d3:d3:d3:d3:d3:d3" ], "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.0.2.213" } ] }
手順
-
インベントリーファイルを作成したら、そのファイルを stack ユーザーのホームディレクトリーに保存します (
/home/stack/instackenv.json
)。 stack ユーザーを初期化し、続いて
instackenv.json
インベントリーファイルを director にインポートします。$ source ~/stackrc $ openstack overcloud node import ~/instackenv.json
openstack overcloud node import
コマンドは、インベントリーファイルをインポートし、各ノードを director に登録します。カーネルと ramdisk イメージを各ノードに割り当てます。
$ openstack overcloud node configure <node>
- 結果
- director でのノードの登録、設定が完了しました。
2.3. Ceph Storage のデプロイメント前の検証
オーバークラウドのデプロイメントが失敗しないようにするには、必要なパッケージがサーバーに存在することを確認します。
2.3.1. ceph-ansible パッケージバージョンの確認
アンダークラウドには Ansible ベースの検証が含まれ、これを実行してオーバークラウドをデプロイする前に潜在的な問題を特定することができます。これらの検証は、典型的な問題が発生する前にそれらを特定し、オーバークラウドのデプロイメントの失敗を回避するのに役立ちます。
手順
ceph-ansible
パッケージの修正バージョンがインストールされていることを確認してください。
$ ansible-playbook -i /usr/bin/tripleo-ansible-inventory /usr/share/openstack-tripleo-validations/validations/ceph-ansible-installed.yaml
2.3.2. 事前にプロビジョニングされたノード用のパッケージの確認
Ceph は、特定のパッケージセットを持つオーバークラウドノードにのみサービスを提供することができます。事前にプロビジョニングされたノードを使用する場合には、これらのパッケージが存在することを確認することができます。
事前にプロビジョニングされたノードの詳細は、「事前にプロビジョニングされたノードを使用した基本的なオーバークラウドの設定」を参照してください。
手順
サーバーに必要なパッケージが含まれていることを確認します。
ansible-playbook -i /usr/bin/tripleo-ansible-inventory /usr/share/openstack-tripleo-validations/validations/ceph-dependencies-installed.yaml
2.4. 手動によるプロファイルへのノードのタグ付け
各ノードの登録後、ハードウェアを検査して、ノードを特定のプロファイルにタグ付けする必要があります。プロファイルタグを使用してノードをフレーバーに照合してから、フレーバーをデプロイメントロールに割り当てます。
手順
ハードウェアのイントロスペクションをトリガーして、各ノードのハードウェア属性を取得します。
$ openstack overcloud node introspect --all-manageable --provide
-
--all-manageable
オプションを使用して、管理状態にあるノードのみをイントロスペクションします。ここでは、すべてのノードが管理状態にあります。 --provide
オプションは、イントロスペクション後に全ノードをactive
の状態にリセットします。重要このプロセスが正常に完了したことを確認します。ベアメタルノードの場合には、通常 15 分ほどかかります。
-
ノード一覧を取得して UUID を識別します。
$ openstack baremetal node list
各ノードの
properties/capabilities
パラメーターに profile オプションを追加して、ノードを特定のプロファイルに手動でタグ付けします。profile
オプションを追加すると、適切なプロファイルにノードをタグ付けします。注記手動でのタグ付けの代わりに、Automated Health Check (AHC) ツールを使用し、ベンチマークデータに基づいて、多数のノードに自動でタグ付けします。
たとえば、標準的なデプロイメントには、
control
、compute
、およびceph-storage
の 3 つのプロファイルが含まれます。以下のコマンドを実行して、3 つのノードを各プロファイルにタグ付けします。$ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 6faba1a9-e2d8-4b7c-95a2-c7fbdc12129a $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 6faba1a9-e2d8-4b7c-95a2-c7fbdc12129a $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 484587b2-b3b3-40d5-925b-a26a2fa3036f $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' d010460b-38f2-4800-9cc4-d69f0d067efe $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' d930e613-3e14-44b9-8240-4f3559801ea6 $ openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 484587b2-b3b3-40d5-925b-a26a2fa3036f $ openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' d010460b-38f2-4800-9cc4-d69f0d067efe $ openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' d930e613-3e14-44b9-8240-4f3559801ea6
Ceph MON サービスおよび Ceph MDS サービス用のノードのタグ付けに使用できる新しいカスタムプロファイルを設定することも可能です。詳しくは、「3章専用ノード上での Ceph サービスのデプロイ」を参照してください。
2.5. マルチディスククラスターのルートディスクの定義
ノードで複数のディスクが使用されている場合には、director はプロビジョニング時にルートディスクを特定する必要があります。たとえば、ほとんどの Ceph Storage ノードでは、複数のディスクが使用されます。デフォルトのプロビジョニングプロセスでは、director はルートディスクにオーバークラウドイメージを書き込みます。
以下のプロパティーを定義すると、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
を使用しないでください。この値は、ノードのブート時に変更される可能性があります。
シリアル番号を使用してルートデバイスを指定するには、以下の手順を実施します。
手順
各ノードのハードウェアイントロスペクションからのディスク情報を確認します。以下のコマンドを実行して、ノードのディスク情報を表示します。
(undercloud) $ openstack baremetal introspection data save 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 | jq ".inventory.disks"
たとえば、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" } ]
openstack baremetal node set --property root_device=
を入力して、ノードのルートディスクを設定します。ルートディスクを定義するのに最も適切なハードウェア属性値を指定します。(undercloud) $ openstack baremetal node set --property root_device=’{“serial”:”<serial_number>”}' <node-uuid>
たとえば、ルートデバイスをシリアル番号が
61866da04f380d001ea4e13c12e36ad6
の disk 2 に設定するには、以下のコマンドを入力します。(undercloud) $ openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
各ノードの BIOS を設定して、選択したルートディスクからの起動を含めるようにします。最初にネットワークからのブートを試み、次にルートディスクからのブートを試みるように、ブート順序を設定します。
director は、ルートディスクとして使用する特定のディスクを把握します。openstack overcloud deploy
コマンドを実行すると、director はオーバークラウドをプロビジョニングし、ルートディスクにオーバークラウドのイメージを書き込みます。
2.6. overcloud-minimal イメージの使用による Red Hat サブスクリプションエンタイトルメントの使用回避
デフォルトでは、プロビジョニングプロセス中 director はルートディスクに QCOW2 overcloud-full
イメージを書き込みます。overcloud-full
イメージには、有効な Red Hat サブスクリプションが使用されます。ただし、overcloud-minimal
イメージを使用して、たとえばベア OS をプロビジョニングすることもできます。この場合、他の OpenStack サービスは使用されないので、サブスクリプションエンタイトルメントは消費されません。
この典型的なユースケースは、Ceph デーモンのみを持つノードをプロビジョニングする場合です。この場合や類似のユースケースでは、overcloud-minimal
イメージのオプションを使用して、有償の Red Hat サブスクリプションが限度に達するのを避けることができます。overcloud-minimal
イメージの取得方法についての情報は、「オーバークラウドノードのイメージの取得」を参照してください。
Red Hat OpenStack Platform のサブスクリプションには Open vSwitch (OVS) が含まれますが、overcloud-minimal
イメージを使用する場合には、OVS 等のコアサービスは利用できません。Ceph Storage ノードをデプロイするのに OVS は必要ありません。'ovs_bond' を使用してボンディングを定義する代わりに、'linux_bond' を使用します。linux_bond
の詳細は、『Advanced Overcloud Customization』の「Linux bonding options」を参照してください。
手順
overcloud-minimal
イメージを使用するように director を設定するには、以下のイメージ定義を含む環境ファイルを作成します。parameter_defaults: <roleName>Image: overcloud-minimal
<roleName>
をロール名に置き換え、ロール名にImage
を追加します。Ceph Storage ノードのovercloud-minimal
イメージの例を以下に示します。parameter_defaults: CephStorageImage: overcloud-minimal
-
この環境ファイルを
openstack overcloud deploy
コマンドに渡します。
overcloud-minimal
イメージでは、標準の Linux ブリッジしかサポートされません。OVS は Red Hat OpenStack Platform のサブスクリプションエンタイトルメントが必要な OpenStack サービスなので、このイメージでは OVS はサポートされません。