Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

6.2. 高度なシナリオ: Ceph Storage ノードを使用する大型のオーバークラウドの作成

このシナリオでは、Red Hat Ceph Storage ノードを利用する大規模なエンタープライズレベルの OpenStack Platform 環境を作成します。本シナリオでは、オーバークラウド内で 9 つのノードを使用します。
  • 高可用性のコントローラーノード x 3
  • コンピュートノード x 3
  • クラスター内の Red Hat Ceph Storage ノード x 3
マシンはすべて、電源管理に IPMI を使用するベアメタルシステムです。このシナリオでは、今後コンピュートノードのスケーリングが可能な、実稼動レベルの Red Hat Enterprise Linux OpenStack Platform 環境を作成する director の機能を紹介することが目的です。また、本シナリオではコマンドラインツールを使用して、Automated Health Check ツールを用いたロール照合や高度なネットワーク分離など、director の高度な機能の一部を紹介します。

ワークフロー

  1. ノード定義のテンプレートを作成して director で空のノードを登録します。
  2. 全ノードのハードウェアおよびベンチマークを検証します。
  3. Automated Health Check (AHC) ツールを使用して自動的にノードをロールにタグ付けするポリシーを定義します。
  4. フレーバーを作成してロールにタグ付けします。
  5. 環境ファイルを使用して、Ceph Storage を設定します。
  6. Heat テンプレートを作成して全ネットワークを分離します。
  7. デフォルトの Heat テンプレートコレクションと追加のネットワーク分離テンプレートを使用してオーバークラウド環境を作成します。
  8. 高可用性クラスター内の各コントローラーノードに関するフェンシング情報を追加します。

要件

  • 「3章アンダークラウドのインストール」で作成した director ノード
  • ベアメタルマシン 9 台。これらのマシンは、コントローラーノード、コンピュートノード、Ceph Storage ノードに設定された要件に準拠する必要があります。要件については以下を参照してください。
    director により Red Hat Enterprise Linux 7 のイメージが各ノードにコピーされるため、これらのノードではオペレーティングシステムは必要ありません。
  • ネイティブ VLAN として設定したプロビジョニングネットワーク用のネットワーク接続 1 つ。全ノードは、このネイティブに接続して、「ネットワーク要件」で設定した要件に準拠する必要があります。この例では、以下の IP アドレスの割り当てで、プロビジョニングサブネットとして 192.0.2.0/24 を使用します。
    表6.3 プロビジョニングネットワークの IP 割り当て
    ノード名
    IP アドレス
    MAC アドレス
    IPMI IP アドレス
    director
    192.0.2.1
    aa:aa:aa:aa:aa:aa
    コントローラー 1
    定義済みの DHCP
    b1:b1:b1:b1:b1:b1
    192.0.2.205
    コントローラー 2
    定義済みの DHCP
    b2:b2:b2:b2:b2:b2
    192.0.2.206
    コントローラー 3
    定義済みの DHCP
    b3:b3:b3:b3:b3:b3
    192.0.2.207
    コンピュート 1
    定義済みの DHCP
    c1:c1:c1:c1:c1:c1
    192.0.2.208
    コンピュート 2
    定義済みの DHCP
    c2:c2:c2:c2:c2:c2
    192.0.2.209
    コンピュート 3
    定義済みの DHCP
    c3:c3:c3:c3:c3:c3
    192.0.2.210
    Ceph 1
    定義済みの DHCP
    d1:d1:d1:d1:d1:d1
    192.0.2.211
    Ceph 2
    定義済みの DHCP
    d2:d2:d2:d2:d2:d2
    192.0.2.212
    Ceph 3
    定義済みの DHCP
    d3:d3:d3:d3:d3:d3
    192.0.2.213
  • 各オーバークラウドノードは、タグ付けられた VLAN でネットワークを提供するために、ボンディング内の残りのネットワークインターフェース 2 つを使用します。以下のネットワーク割り当ては、このボンディングに適用されます。
    表6.4 ネットワークサブネットおよび VLAN 割り当て
    ネットワーク種別
    サブネット
    VLAN
    内部 API
    172.16.0.0/24
    201
    テナント
    172.17.0.0/24
    202
    ストレージ
    172.18.0.0/24
    203
    ストレージ管理
    172.19.0.0/24
    204
    外部 / Floating IP
    10.1.1.0/24
    100

6.2.1. 高度なオーバークラウドのノード登録

本項では、ノード定義のテンプレートを作成します。このファイル (instackenv.json) は JSON ファイル形式で、9 つのノードのハードウェアおよび電源管理の詳細が含まれます。
このテンプレートでは、以下の属性を使用します。
mac
ノード上のネットワークインターフェースの MAC アドレス一覧。各システムのプロビジョニング NIC の MAC アドレスのみを使用します。
pm_type
使用する電源管理ドライバー。この例では IPMI ドライバーを使用します (pxe_ipmitool)。
pm_user, pm_password
IPMI のユーザー名およびパスワード
pm_addr
IPMI デバイスの IP アドレス
cpu
ノード上の CPU 数
memory
メモリーサイズ (MB)
disk
ハードディスクのサイズ (GB)
arch
システムアーキテクチャー
例: 
{
    "nodes":[
        {
            "mac":[
                "b1:b1:b1:b1:b1:b1"
            ],
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "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":"pxe_ipmitool",
            "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":"pxe_ipmitool",
            "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":"pxe_ipmitool",
            "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":"pxe_ipmitool",
            "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":"pxe_ipmitool",
            "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":"pxe_ipmitool",
            "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":"pxe_ipmitool",
            "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":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.0.2.213"
        }
    ]
}
Copy to Clipboard

注記

電源管理の種別およびそのオプションに関する詳細は、「付録C 電源管理ドライバー」を参照してください。
テンプレートの作成後に、stack ユーザーのホームディレクトリー (instackenv.json) にファイルを保存してから、director にインポートします。これには、以下のコマンドを実行します。 
$ openstack baremetal import --json ~/instackenv.json
Copy to Clipboard
このコマンドでテンプレートをインポートして、テンプレートから director に各ノードを登録します。
カーネルと ramdisk イメージを全ノードに割り当てます。 
$ openstack baremetal configure boot
Copy to Clipboard
director でのノードの登録および設定が完了しました。以下のコマンドを使用して、CLI でこれらのノードの一覧を表示します。 
$ openstack baremetal list
Copy to Clipboard

6.2.2. ノードのハードウェアの検証

ノードの登録後には、各ノードのハードウェア属性を検証します。このシナリオでは、Automated Health Check (AHC) ツールで使用するノードを基準に従って評価し、その情報をデプロイメントプロファイルにノードを自動的にタグ付けする際に使用します。これらのプロファイルタグにより、ノードがフレーバーに対して照合され、そのフレーバーはデプロイメントロールに割り当てられます。

重要

ベンチマーク機能を利用するには、最初に director の設定の際に、discovery_runbench オプションを true に設定する必要があります (「director の設定」 を参照)。
director のインストール後にベンチマーク機能を有効化する必要がある場合には、/httpboot/discoverd.ipxe を編集して RUNBENCH カーネルパラメーターを 1 に設定します。
以下のコマンドを実行して、各ノードのハードウェア属性を検証します。 
$ openstack baremetal introspection bulk start
Copy to Clipboard
別のターミナルウィンドウで以下のコマンドを使用してイントロスペクションの進捗状況をモニタリングします。 
$ sudo journalctl -l -u openstack-ironic-discoverd -u openstack-ironic-discoverd-dnsmasq -u openstack-ironic-conductor -f
Copy to Clipboard

重要

このプロセスが最後まで実行されて正常に終了したことを確認してください。ベアメタルの場合には、通常 15 分ほどかかります。
または、各ノードに 1 回ずつ個別にイントロスペクションを実行します。ノードをメンテナンスモードに切り替えて、イントロスペクションを実行してから、メンテナンスモードから元に戻します 
$ ironic node-set-maintenance [NODE UUID] true
$ openstack baremetal introspection start [NODE UUID]
$ ironic node-set-maintenance [NODE UUID] false
Copy to Clipboard

6.2.3. Automated Health Check (AHC) ツールを使用したノードの自動タグ付け

検出プロセスでベンチマークテストが完了したら、一連のレポートを生成して、低パフォーマンスまたは不安定なノードを特定して、オーバークラウドで使用されないように分離します。本項では、これらのレポートの生成方法を検証してポリシーを作成し、特定のロールにノードを自動的にタグ付けします。
下記のコマンドを使用して、以下の Automated Health Check (AHC) ツールをインストールします。 
$ sudo yum install -y ahc-tools
Copy to Clipboard
このパッケージには 2 つのツールが含まれます。
  • ahc-report: ベンチマークテストからのレポートを提供します。
  • ahc-match: ポリシーに応じて、ノードを特定のロールにタグ付けします。

重要

これらのツールでは、/etc/ahc-tools/ahc-tools.conf ファイルで設定した Ironic と Swift の認証情報が必要になります。認証情報は、/etc/ironic-discoverd/discoverd.conf と同じです。以下のコマンドを使用して、設定ファイルをコピーして /etc/ahc-tools/ahc-tools.conf にカスタマイズします。 
$ sudo -i
# mkdir /etc/ahc-tools
# sed 's/\[discoverd/\[ironic/' /etc/ironic-discoverd/discoverd.conf > /etc/ahc-tools/ahc-tools.conf
# chmod 0600 /etc/ahc-tools/ahc-tools.conf
# exit
Copy to Clipboard

6.2.3.1. ahc-report

ahc-report のスクリプトは、ノードに関するさまざまなレポートを作成します。完全なレポートを表示するには --full オプションを使用します。 
$ sudo ahc-report --full
Copy to Clipboard
ahc-report コマンドは、レポートの特定の場所にフォーカスすることも可能です。たとえば、--categories を使用して、ハードウェア別にノードを分類することができます (プロセッサー、ネットワークインターフェース、ファームウェア、メモリー、さまざまなハードウェアコントローラー)。またこのコマンドは、同様のハードウェアプロファイルのノードをグループ化します。たとえば、2 つのサンプルノードの Processors セクションは以下のような一覧になります。 
######################
##### Processors #####
2 identical systems :
[u'7F8831F1-0D81-464E-A767-7577DF49AAA5', u'7884BC95-6EF8-4447-BDE5-D19561718B29']
[(u'cpu', u'logical', u'number', u'4'),
 (u'cpu', u'physical', u'number', u'4'),
 (u'cpu',
  u'physical_0',
  u'flags',
  u'fpu fpu_exception wp de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx x86-64 rep_good nopl pni cx16 hypervisor lahf_lm'),
 (u'cpu', u'physical_0', u'frequency', u'2000000000'),
 (u'cpu', u'physical_0', u'physid', u'0'),
 (u'cpu', u'physical_0', u'product', u'Intel(R) Xeon(TM) CPU       E3-1271v3 @ 3.6GHz'),
 (u'cpu', u'physical_0', u'vendor', u'GenuineIntel'),
 (u'cpu',
  u'physical_1',
  u'flags',
  u'fpu fpu_exception wp de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx x86-64 rep_good nopl pni cx16 hypervisor lahf_lm'),
 (u'cpu', u'physical_0', u'frequency', u'2000000000'),
 (u'cpu', u'physical_0', u'physid', u'0'),
 (u'cpu', u'physical_0', u'product', u'Intel(R) Xeon(TM) CPU       E3-1271v3 @ 3.6GHz'),
 (u'cpu', u'physical_0', u'vendor', u'GenuineIntel')
 ...
 ]
Copy to Clipboard
ahc-report ツールもノードコレクションの外れ値を特定します。--outliers スイッチを使用して、この機能を有効化します。 
$ sudo ahc-report --outliers

Group 0 : Checking logical disks perf
standalone_randread_4k_KBps   : INFO    : sda   : Group performance : min=45296.00, mean=53604.67, max=67923.00, stddev=12453.21
standalone_randread_4k_KBps   : ERROR   : sda   : Group's variance is too important :   23.23% of 53604.67 whereas limit is set to 15.00%
standalone_randread_4k_KBps   : ERROR   : sda   : Group performance : UNSTABLE
standalone_read_1M_IOps       : INFO    : sda   : Group performance : min= 1199.00, mean= 1259.00, max= 1357.00, stddev=   85.58
standalone_read_1M_IOps       : INFO    : sda   : Group performance = 1259.00   : CONSISTENT
standalone_randread_4k_IOps   : INFO    : sda   : Group performance : min=11320.00, mean=13397.33, max=16977.00, stddev= 3113.39
standalone_randread_4k_IOps   : ERROR   : sda   : Group's variance is too important :   23.24% of 13397.33 whereas limit is set to 15.00%
standalone_randread_4k_IOps   : ERROR   : sda   : Group performance : UNSTABLE
standalone_read_1M_KBps       : INFO    : sda   : Group performance : min=1231155.00, mean=1292799.67, max=1393152.00, stddev=87661.11
standalone_read_1M_KBps       : INFO    : sda   : Group performance = 1292799.67   : CONSISTENT

...
Copy to Clipboard
上記の例では ahc-report は、全ノードの標準偏差が許容可能な閾値よりも高いため、standalone_randread_4k_KBps および standalone_randread_4k_IOps のディスクメトリックを不安定としてマークしました。この例では、2 つのノードのディスク転送速度が大きく違う場合に、このような結果になる可能性があります。
ノードコレクションの外れ値を特定すると、高パフォーマンスのノードをより適切なタスクに割り当てることができるので役立ちます。たとえば、ディスク転送速度の高いノードは、より優れたストレージノードになり、メモリーのパフォーマンスが高いノードはコンピュートノードにより適しています。各ノードのハードウェアパフォーマンスを特定したら、ポリシーのセットを作成して、ahc-match コマンドを使用してノードに特定のロールを割り当てます。

6.2.3.2. ahc-match

ahc-match コマンドは、ノードを特定のロールに割り当てられるように、オーバークラウドプランにポリシーセットを適用します。このコマンドを使用する前に、適切なノードとロールを照合するポリシーセットを作成します。
ahc-tools パッケージは、/etc/ahc-tools/edeploy に、以下のような一連のポリシーファイルをインストールします。
  • state: 各ロールのノード数を記載する状態ファイル
  • compute.specs、control.specs: コンピュートノードとコントローラーノードを照合するポリシーファイル
  • compute.cmdb.sample および control.cmdb.sample: Sample Configuration Management Database (CMDB) ファイル。RAID および BIOS の ready-state 設定 (Dell DRAC のみ) のためのキー/値の設定値が含まれます。
状態ファイル
state ファイルは、各ロールのノード数を指定します。デフォルトの設定ファイルは以下のとおりです。 
[('control', '1'), ('compute', '*')]
Copy to Clipboard
これは、ahc-match により 1 つのコントローラーノードと任意数のコンピュートノードが割り当てられます。このシナリオでは、このファイルを以下のように編集します。 
[('control', '3'), ('ceph-storage', '3'), ('compute', '*')]
Copy to Clipboard
これにより、コントローラーノード 3 つ、Red Hat Ceph Storage ノード 3 つ、無限数のコンピュートノードが割り当てられます。
ポリシーファイル
compute.specs および control.specs ファイルは、対象ロールごとに割り当てルールを一覧表示します。ファイルの内容は、以下の例のようなタプル形式です。 
[
 ('cpu', 'logical', 'number', 'ge(2)'),
 ('disk', '$disk', 'size', 'gt(4)'),
 ('network', '$eth', 'ipv4', 'network(192.0.2.0/24)'),
 ('memory', 'total', 'size', 'ge(4294967296)'),
]
Copy to Clipboard
これは、ハードウェアのパラメーターに基づいた割り当てルールを定義する方法を提供します。利用可能なパラメーターの完全なリファレンスは、「付録D Automated Health Check (AHC) ツールのパラメーター」を参照してください。
また、このポリシーファイルは、値の範囲を照合する場合もヘルパー関数を使用します。これらの関数は以下のとおりです。
  • network(): 指定のネットワーク内にあるネットワークインターフェース
  • gt()、ge(): 指定値以上
  • lt()、le(): 指定値以下
  • in(): 照合するアイテムは指定のセットに含まれる必要があります。
  • regexp(): 正規表現に一致するもの
  • or()、and()、not(): Boolean 関数。or()、and() に指定可能なパラメーターは 2 つ、not() のパラメーターは 1 つです。
たとえば、このシナリオでは、「ahc-report」 からの standalone_randread_4k_KBps と standalone_randread_4k_IOps の値を使用して、平均よりもディスクアクセス速度が早いノードだけにコントローラーロールを制限します。各値のルールは、以下のとおりです。 
[
 ('disk', '$disk', 'standalone_randread_4k_KBps', 'gt(53604)'),
 ('disk', '$disk', 'standalone_randread_4k_IOps', 'gt(13397)')
]
Copy to Clipboard
他のロールに追加のポリシープロファイルを作成することも可能です。たとえば、Red Hat Ceph Storage 専用の ceph-storage.spec プロファイルを作成します。これらのファイル名 (拡張子なし) は state ファイルに含まれるようにします。
ready-state のファイル (Dell DRAC のみ)
ready-state 設定により、デプロイメントに向けたベアメタルリソースの準備を行います。 これには、事前設定済みプロファイル用の BIOS および RAID の設定が含まれます。
BIOS の設定を定義するには、bios_settings キーの各設定とターゲット値を定義する JSON タプルを定義します。以下に例を示します。 
[
  {
    'bios_settings': {'ProcVirtualization': 'Enabled', 'ProcCores': 4}
  }
]
Copy to Clipboard
RAID の設定は、次の 2 つの方法で定義します。
  • 物理ディスク ID を一覧表示する方法: controller、size_gb、raid_level、physical_disks の属性を使用して物理ディスク ID の一覧を指定します。controller には、DRAC によって割り当てられる RAID コントローラーの FQDD を指定する必要があります。同様に、physical_disks の一覧には、DRAC カードによって割り当てられる物理ディスクの FQDD の一覧を指定する必要があります。 
    [
  {
    'logical_disks': [
      {'controller': 'RAID.Integrated.1-1',
        'size_gb': 100,
        'physical_disks': [
          'Disk.Bay.0:Enclosure.Internal.0-1:RAID.Integrated.1-1',
          'Disk.Bay.1:Enclosure.Internal.0-1:RAID.Integrated.1-1',
          'Disk.Bay.2:Enclosure.Internal.0-1:RAID.Integrated.1-1'],
        'raid_level': '5'},
    ]
  }
]
    Copy to Clipboard
  • Ironic により物理ディスクを RAID ボリュームに割り当てる方法: controller、size_gb、raid_level、number_of_physical_disks の属性が必要となります。controller には、DRAC カードによって割り当てられる RAID コントローラーの FQDD を指定する必要があります。 
    [
  {
    'logical_disks': [
      {'controller': 'RAID.Integrated.1-1',
        'size_gb': 50,
        'raid_level': '1',
        'number_of_physical_disks': 2},
    ]
  }
]
    Copy to Clipboard
照合ツールの実行
ルールを定義した後には、ahc-match ツールを実行してノードを割り当てます。 
$ sudo ahc-match
Copy to Clipboard
このコマンドは、全ノードを /etc/ahc-tools/edeploy/state に定義したロールと照合します。ノードがロールに一致する場合は、ahc-match により、Ironic でノードにロールが 1 つのケイパビリティーとして追加されます。 
$ ironic node-show b73fb5fa-1a2c-49c6-b38e-8de41e3c0532 | grep properties -A2
| properties    | {u'memory_mb': u'6144', u'cpu_arch': u'x86_64', u'local_gb': u'40',      |
|               | u'cpus': u'4', u'capabilities': u'profile:control,boot_option:local'}    |
| instance_uuid | None                                                                     |
Copy to Clipboard
director は、各ノードに付いたこの profile タグを使用して、同じタグを持つロールとフレーバーを照合します。
RAID と BIOS の ready-state 設定を行った場合には、以下のコマンドを実行して、各ノードでこれらを設定します。 
$ instack-ironic-deployment --configure-nodes
Copy to Clipboard

6.2.4. ハードウェアプロファイルの作成

director には、登録ノードのハードウェアプロファイルまたはフレーバーのセットが必要です。このシナリオでは、コンピュートノードとコントローラーノード、Ceph Storage ノードごとにプロファイルを作成します。 
$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 control
$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 compute
$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 ceph-storage
Copy to Clipboard

重要

このシナリオの 3 つのフレーバーの値は、例示のみを目的としています。実際の値には、AHC ツールで特定したハードウェアの仕様を使用してください。
これにより、ノードに 3 つのフレーバーが作成されます。また、各フレーバーに追加のプロパティーも設定します。 
$ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="compute" compute
$ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="control" control
$ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="ceph-storage" ceph-storage
Copy to Clipboard
capabilities:boot_option はフレーバーのブートモードを設定し、capabilities:profile は使用するプロファイルを定義します。

重要

使用していないロールにも baremetal というデフォルトのフレーバーが必要です。このフレーバーがない場合には作成します。 
$ openstack flavor create --id auto --ram 4096 --disk 40 --vcpus 1 baremetal
Copy to Clipboard

6.2.5. Ceph Storage の設定

本項では、OpenStack で使用するために director を使用して Red Hat Ceph Storage をインストール/設定する方法を説明します。このインストール/設定プロセスは、Heat テンプレートと Puppet 設定の組み合わせをベースにしています。
オーバークラウドのイメージにはすでに、コントローラークラスターに Ceph OSD ノードと Ceph Monitor の両方を自動で設定する Ceph Storage ソフトウェアと必要な Puppet モジュールが含まれています。オーバークラウドの Heat テンプレートコレクションには、Ceph Storage の設定を有効にするための設定も含まれています。
Ceph Storage クラスターには、特に Ceph Storage ノード上のディスクレイアウトなどのマイナーな設定が必要となる場合があります。この情報を渡すには、storage-environment.yaml 環境ファイルを stack ユーザーの templates ディレクトリーにコピーしてください。 
$ cp /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml ~/templates/.
Copy to Clipboard
storage-environment.yaml のコピーで、以下のオプションを修正します。
CinderEnableIscsiBackend
iSCSI バックエンドを有効にするパラメーター。false に設定してください。
CinderEnableRbdBackend
Ceph Storage バックエンドを有効にするパラメーター。true に設定してください。
CinderEnableNfsBackend
NFS バックエンドを有効にするパラメーター。false に設定してください。
NovaEnableRbdBackend
Nova エフェメラルストレージ用に Ceph Storage を有効にするパラメーター。true に設定します。
GlanceBackend
Glance で使用するバックエンドを定義します。イメージに Ceph Storage を使用するには、rbd に設定します。

注記

storage-environment.yaml には、Heat を直接使用して Ceph Storage を設定するためのオプションも含まれています。ただし、director はこれらのノードを作成して、このシナリオでは、自動的に設定値を定義するので、これらのオプションは必要ありません。
以下の内容を含む追加のセクションをこの環境ファイルに追加します。 
parameter_defaults:
  ExtraConfig:
    ceph::profile::params::osds:
Copy to Clipboard
これにより、オーバークラウドに Hiera データがさらに追加されます。このデータは、Puppet の設定に使用されます。詳しくは、「Puppet 設定データのカスタマイズ」を参照してください。
ceph::profile::params::osds パラメーターを使用して、関連するジャーナルのパーティションとディスクをマッピングします。たとえば、ディスクが 4 つある Ceph ノードは、以下のように割り当てることができます。
  • /dev/sda: オーバークラウドのイメージを含む root ディスク
  • /dev/sdb: ディスクにはジャーナルのパーティションが含まれます。これは通常、システムパフォーマンスの向上に役立つソリッドステートドライブ (SSD) です。
  • /dev/sdc および /dev/sdd: OSD ディスク
この例では、マッピングには以下をが含むことができます。 
    ceph::profile::params::osds:
      '/dev/sdc':
        journal: '/dev/sdb'
      '/dev/sdd':
        journal: '/dev/sdb'
Copy to Clipboard
ジャーナル用に別のディスクを使用しない場合には、OSD ディスクに併置されているジャーナルを使用します。journal パラメーターには空の値を渡します。 
    ceph::profile::params::osds:
        '/dev/sdb': {}
        '/dev/sdc': {}
        '/dev/sdd': {}
Copy to Clipboard
storage-environment.yaml ファイルのオプションは、以下の例のように設定されるはずです。 
parameters:
  CinderEnableIscsiBackend: false
  CinderEnableRbdBackend: true
  CinderEnableNfsBackend: false
  NovaEnableRbdBackend: true

parameter_defaults:
  ExtraConfig:
    ceph::profile::params::osds:
      '/dev/sdc':
        journal: '/dev/sdb'
      '/dev/sdd':
        journal: '/dev/sdb'
Copy to Clipboard
変更が完了したら、storage-environment.yaml を保存して、オーバークラウドのデプロイ時に Ceph Storage ノードにディスクマッピングとカスタム設定が使用されるようにします。また、デプロイメント内にこのファイルを追加して、ストレージに必要な設定が開始されるようにします。

重要

Ceph Storage OSD のディスクはパーティション分割せず、GPT ディスクラベルを付ける必要があります。このラベルも、カスタマイズの前に設定します。たとえば、Ceph Storage ホストとなるマシンで以下のコマンドを実行して、ディスクまたはパーティションの GPT ディスクラベルを作成します。 
# parted [device] mklabel gpt
Copy to Clipboard

6.2.6. VLAN への全ネットワークの分離

director は、分離したオーバークラウドネットワークを設定する方法を提供します。つまり、オーバークラウド環境はネットワークトラフィック種別を異なるネットワークに分離して、個別のネットワークインターフェースまたはボンディングにネットワークトラフィックを割り当てます。分離ネットワークワークを設定した後に、director は OpenStack サービスが分離ネットワークを使用するように設定します。分離ネットワークが設定されていない場合には、サービスはすべて、プロビジョニングネットワーク上で実行されます。
このシナリオでは、サービスごとに別のネットワークを使用します。
  • ネットワーク 1: プロビジョニング
  • ネットワーク 2: 内部 API
  • ネットワーク 3: テナントネットワーク
  • ネットワーク 4: ストレージ
  • ネットワーク 5: ストレージ管理
  • ネットワーク 6: 外部、Floating IP (オーバークラウドの作成後にマッピング)
以下の項では、Heat テンプレートを作成してすべてのネットワーク種別を分離する方法を説明します。その他のネットワーク設定例は、「付録F ネットワークインターフェースのテンプレート例」を参照してください。

6.2.6.1. カスタムのインターフェーステンプレートの作成

オーバークラウドのネットワーク設定には、ネットワークインターフェースのテンプレートセットが必要です。これらのテンプレートをカスタマイズして、ロールごとにノードのインターフェースを設定します。このテンプレートは YAML 形式の標準の Heat テンプレート (「5章Heat テンプレートについての理解」を参照) で、director にはすぐに使用開始できるように、テンプレートサンプルが含まれています。
  • /usr/share/openstack-tripleo-heat-templates/network/config/single-nic-vlans: このディレクトリーには、ロールごとに VLAN が設定された単一 NIC のテンプレートが含まれます。
  • /usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans: このディレクトリーには、ロール別のボンディング NIC 設定のテンプレートが含まれます。
高度なオーバークラウドのシナリオでは、デフォルトのボンディング NIC の設定サンプルをベースとして使用します。/usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans にあるバージョンをコピーします。 
$ cp -r /usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans ~/templates/nic-configs
Copy to Clipboard
このコマンドによりローカルの Heat テンプレートが作成され、このテンプレートで各ロールのボンディングネットワークインターフェース設定を定義します。各テンプレートには、標準の parameters、resources、output が含まれます。今回のシナリオでは、resources セクションのみを編集します。各 resources セクションは、以下のように開始されます。 
resources:
  OsNetConfigImpl:
    type: OS::Heat::StructuredConfig
    properties:
      group: os-apply-config
      config:
        os_net_config:
          network_config:
Copy to Clipboard
このコマンドでは、os-apply-config コマンドと os-net-config サブコマンドがノードのネットワークプロパティーを設定するように要求が作成されます。network_config セクションには、種別順に並べられたカスタムのインターフェース設定が含まれます。これらの種別には以下が含まれます。
interface
単一のネットワークインターフェースを定義します。この設定では、実際のインターフェース名 (eth0、eth1、enp0s25) または番号付きのインターフェース (nic1、nic2、nic3) を使用して各インターフェースを定義します。 
            - type: interface
              name: nic2
Copy to Clipboard
vlan
VLAN を定義します。parameters セクションから渡された VLAN ID およびサブネットを使用します。 
            - type: vlan
              vlan_id: {get_param: ExternalNetworkVlanID}
              addresses:
                - ip_netmask: {get_param: ExternalIpSubnet}
Copy to Clipboard
ovs_bond
Open vSwitch のボンディングを定義します。ボンディングでは、2 つ以上の interfaces を結合して、冗長性や帯域幅を向上させます。 
            - type: ovs_bond
              name: bond1
              members:
              - type: interface
                name: nic2
              - type: interface
                name: nic3
Copy to Clipboard
ovs_bridge
Open vSwitch のブリッジを定義します。ブリッジは、複数の interface、bond、vlan オブジェクトを接続します。 
            - type: ovs_bridge
              name: {get_input: bridge_name}
              members:
                - type: ovs_bond
                  name: bond1
                  members:
                    - type: interface
                      name: nic2
                      primary: true
                    - type: interface
                      name: nic3
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: ExternalNetworkVlanID}
                  addresses:
                    - ip_netmask: {get_param: ExternalIpSubnet}
Copy to Clipboard
linux_bridge
Linux ブリッジを定義します。Open vSwitch ブリッジと同様に、このブリッジは、複数の interface、bond、vlan オブジェクトを接続します。 
              - type: linux_bridge
                name: bridge1
                members:
                - type: interface
                  name: nic1
                  primary: true
              - type: vlan
                device: bridge1
                vlan_id: {get_param: ExternalNetworkVlanID}
                addresses:
                  - ip_netmask: {get_param: ExternalIpSubnet}
Copy to Clipboard
各アイテムの完全なパラメーター一覧については「付録E ネットワークインターフェースのパラメーター」を参照してください。
高度なシナリオでは、デフォルトのボンディングインターフェース設定を使用します。たとえば /home/stack/templates/nic-configs/controller.yaml テンプレートは以下の network_config を使用します。 
          network_config:
            - type: interface
              name: nic1
              use_dhcp: false
              addresses:
                - ip_netmask:
                    list_join:
                      - '/'
                      - - {get_param: ControlPlaneIp}
                        - {get_param: ControlPlaneSubnetCidr}
              routes:
                - ip_netmask: 169.254.169.254/32
                  next_hop: {get_param: EC2MetadataIp}

            - type: ovs_bridge
              name: {get_input: bridge_name}
              dns_servers: {get_param: DnsServers}
              members:
                - type: ovs_bond
                  name: bond1
                  ovs_options: {get_param: BondInterfaceOvsOptions}
                  members:
                    - type: interface
                      name: nic2
                      primary: true
                    - type: interface
                      name: nic3
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: ExternalNetworkVlanID}
                  addresses:
                    - ip_netmask: {get_param: ExternalIpSubnet}
                  routes:
                    - ip_netmask: 0.0.0.0/0
                      next_hop: {get_param: ExternalInterfaceDefaultRoute}
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: InternalApiNetworkVlanID}
                  addresses:
                  - ip_netmask: {get_param: InternalApiIpSubnet}
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: StorageNetworkVlanID}
                  addresses:
                  - ip_netmask: {get_param: StorageIpSubnet}
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: StorageMgmtNetworkVlanID}
                  addresses:
                  - ip_netmask: {get_param: StorageMgmtIpSubnet}
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: TenantNetworkVlanID}
                  addresses:
                  - ip_netmask: {get_param: TenantIpSubnet}
Copy to Clipboard
このテンプレートは、ブリッジ (通常 br-ex という名前の外部ブリッジ) を定義し、nic2 と nic3 の 2 つの番号付きインターフェースから、bond1 と呼ばれるボンディングインターフェースを作成します。ブリッジにはタグ付けされた VLAN デバイスの番号が含まれており、bond1 を親デバイスとして使用します。
ネットワークインターフェーステンプレートの他のサンプルについては「付録F ネットワークインターフェースのテンプレート例」を参照してください。
これらのパラメーターの多くは get_param 関数を使用する点に注意してください。これらのパラメーターは、使用するネットワーク専用に作成した環境ファイルで定義します。

重要

使用していないインターフェースは、不要なデフォルトルートとネットワークループの原因となる可能性があります。たとえば、テンプレートにはネットワークインターフェース (nic4) が含まれる可能性があり、このインターフェースは OpenStack のサービス用の IP 割り当てを使用しませんが、DHCP やデフォルトルートを使用します。ネットワークの競合を回避するには、使用済みのインターフェースを ovs_bridge デバイスから削除し、DHCP とデフォルトのルート設定を無効にします。 
- type: interface
  name: nic4
  use_dhcp: false
  defroute: false
Copy to Clipboard

6.2.6.2. 高度なオーバークラウドのネットワーク環境ファイルの作成

ネットワーク環境ファイルは Heat の環境ファイルで、オーバークラウドのネットワーク環境を記述し、前のセクションのネットワークインターフェース設定テンプレートを参照します。IP アドレス範囲と合わせてネットワークのサブネットおよび VLAN を定義します。また、これらの値をローカルの環境用にカスタマイズします。
このシナリオでは、/home/stack/templates/network-environment.yaml で保存した下記のネットワーク環境ファイルを使用します。 
resource_registry:
  OS::TripleO::BlockStorage::Net::SoftwareConfig: /home/stack/templates/nic-configs/cinder-storage.yaml
  OS::TripleO::Compute::Net::SoftwareConfig: /home/stack/templates/nic-configs/compute.yaml
  OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/templates/nic-configs/controller.yaml
  OS::TripleO::ObjectStorage::Net::SoftwareConfig: /home/stack/templates/nic-configs/swift-storage.yaml
  OS::TripleO::CephStorage::Net::SoftwareConfig: /home/stack/templates/nic-configs/ceph-storage.yaml

parameter_defaults:
  InternalApiNetCidr: 172.16.0.0/24
  TenantNetCidr: 172.17.0.0/24
  StorageNetCidr: 172.18.0.0/24
  StorageMgmtNetCidr: 172.19.0.0/24
  ExternalNetCidr: 10.1.1.0/24
  InternalApiAllocationPools: [{'start': '172.16.0.10', 'end': '172.16.0.200'}]
  TenantAllocationPools: [{'start': '172.17.0.10', 'end': '172.17.0.200'}]
  StorageAllocationPools: [{'start': '172.18.0.10', 'end': '172.18.0.200'}]
  StorageMgmtAllocationPools: [{'start': '172.19.0.10', 'end': '172.19.0.200'}]
  # Leave room for floating IPs in the External allocation pool
  ExternalAllocationPools: [{'start': '10.1.1.10', 'end': '10.1.1.50'}]
  # Set to the router gateway on the external network
  ExternalInterfaceDefaultRoute: 10.1.1.1
  # Gateway router for the provisioning network (or Undercloud IP)
  ControlPlaneDefaultRoute: 192.0.2.254
  # The IP address of the EC2 metadata server. Generally the IP of the Undercloud
  EC2MetadataIp: 192.0.2.1
  # Define the DNS servers (maximum 2) for the overcloud nodes
  DnsServers: ["8.8.8.8","8.8.4.4"]
  InternalApiNetworkVlanID: 201
  StorageNetworkVlanID: 202
  StorageMgmtNetworkVlanID: 203
  TenantNetworkVlanID: 204
  ExternalNetworkVlanID: 100
  # Set to "br-ex" if using floating IPs on native VLAN on bridge br-ex
  NeutronExternalNetworkBridge: "''"
  # Customize bonding options if required
  BondInterfaceOvsOptions:
    "bond_mode=balance-slb"
Copy to Clipboard
resource_registry セクションには、各ノードロールのネットワークインターフェーステンプレートへのリンクが含まれます。
parameter_defaults セクションには、各ネットワーク種別のネットワークオプションを定義するパラメーター一覧が含まれます。これらのオプションについての詳しい参考情報は「付録G ネットワーク環境のオプション」を参照してください。
このシナリオでは、各ネットワークのオプションを定義します。すべてのネットワークの種別で、ホストと仮想 IP への IP アドレス割り当てに使われた個別の VLAN とサブネットを使用します。上記の例では、内部 API ネットワークの割り当てプールは、172.16.0.10 から開始し、172.16.0.200 で終了し、VLAN 201を使用します。これにより、静的な仮想 IP は 172.16.0.10 から 172.16.0.200 までの範囲内で割り当てられる一方で、環境では VLAN 201 が使用されます。
外部ネットワークは、Horizon Dashboard とパブリック API をホストします。クラウドの管理と Floating IP の両方に外部ネットワークを使用する場合には、仮想マシンインスタンス用の Floating IP として IP アドレスのプールを使用する余裕があることを確認します。本ガイドの例では、10.1.1.10 から 10.1.1.50 までの IP アドレスのみを外部ネットワークに割り当て、10.1.1.51 以上は Floating IP アドレスに自由に使用できます。または、Floating IP ネットワークを別の VLAN に配置し、作成後にオーバークラウドを設定してそのネットワークを使用するようにします。
BondInterfaceOvsOptions オプションは、nic2 および nic3 を使用するボンディングインターフェースのオプションを提供します。ボンディングオプションについての詳しい情報は、「付録H ボンディングオプション」を参照してください。

重要

オーバークラウドの作成後にネットワーク設定を変更すると、リソースの可用性が原因で設定に問題が発生する可能性があります。たとえば、ネットワーク分離テンプレートでネットワークのサブネット範囲を変更した場合に、サブネットがすでに使用されているため、再設定が失敗してしまう可能性があります。

6.2.6.3. OpenStack サービスの分離ネットワークへの割り当て

各 OpenStack サービスは、リソースレジストリーでデフォルトのネットワーク種別に割り当てられます。これらのサービスは、そのネットワーク種別に割り当てられたネットワーク内の IP アドレスにバインドされます。OpenStack サービスはこれらのネットワークに分割されますが、実際の物理ネットワーク数はネットワーク環境ファイルに定義されている数と異なる可能性があります。ネットワーク環境ファイル (/home/stack/templates/network-environment.yaml) で新たにネットワークマッピングを定義することで、OpenStack サービスを異なるネットワーク種別に再割り当てすることができます。ServiceNetMap パラメーターにより、各サービスに使用するネットワーク種別が決定されます。
たとえば、ハイライトしたセクションを変更することで、ストレージ管理ネットワークサービスをストレージネットワークに再割り当てすることができます。 
...

parameter_defaults:

  ServiceNetMap:
    NeutronTenantNetwork: tenant
    CeilometerApiNetwork: internal_api
    MongoDbNetwork: internal_api
    CinderApiNetwork: internal_api
    CinderIscsiNetwork: storage
    GlanceApiNetwork: storage
    GlanceRegistryNetwork: internal_api
    KeystoneAdminApiNetwork: internal_api
    KeystonePublicApiNetwork: internal_api
    NeutronApiNetwork: internal_api
    HeatApiNetwork: internal_api
    NovaApiNetwork: internal_api
    NovaMetadataNetwork: internal_api
    NovaVncProxyNetwork: internal_api
    SwiftMgmtNetwork: storage_mgmt
    SwiftProxyNetwork: storage
    HorizonNetwork: internal_api
    MemcachedNetwork: internal_api
    RabbitMqNetwork: internal_api
    RedisNetwork: internal_api
    MysqlNetwork: internal_api
    CephClusterNetwork: storage_mgmt
    CephPublicNetwork: storage
    # Define which network will be used for hostname resolution
    ControllerHostnameResolveNetwork: internal_api
    ComputeHostnameResolveNetwork: internal_api
    BlockStorageHostnameResolveNetwork: internal_api
    ObjectStorageHostnameResolveNetwork: internal_api
    CephStorageHostnameResolveNetwork: storage
Copy to Clipboard
これらのパラメーターを storage に変更すると、対象のサービスがストレージ管理ネットワークではなく、ストレージネットワークに割り当てられます。つまり、ストレージ管理ネットワークではなくストレージネットワークに parameter_defaults セットを定義するだけで結構です。

6.2.7. オーバークラウドの SSL/TLS の有効化

デフォルトでは、オーバークラウドはサービスに対して暗号化されていないエンドポイントを使用します。これは、オーバークラウドの設定には、パブリック API エンドポイントの SSL/TLS を有効化するために追加の環境ファイルが必要という意味です。
このプロセスには、パブリック API のエンドポイントを定義するネットワークの分離が必要です。ネットワークの分離に関する説明は、「VLAN への全ネットワークの分離」を参照してください。
秘密鍵と認証局からの証明書が作成されていることを確認します。有効な SSL/TLS 鍵および認証局ファイルの作成に関する情報は、「付録B SSL/TLS 証明書の設定」を参照してください。

SSL/TLS の有効化

Heat テンプレートコレクションから enable-tls.yaml の環境ファイルをコピーします。 
$ cp -r /usr/share/openstack-tripleo-heat-templates/environments/enable-tls.yaml ~/templates/.
Copy to Clipboard
このファイルを編集して、下記のパラメーターに以下の変更を加えます。

parameter_defaults:

SSLCertificate:
証明書ファイルのコンテンツを SSLCertificate パラメーターにコピーします。以下に例を示します。 
parameter_defaults:
    SSLCertificate: |
      -----BEGIN CERTIFICATE-----
      MIIDgzCCAmugAwIBAgIJAKk46qw6ncJaMA0GCSqGSIb3DQEBCwUAMFgxCzAJBgNV
      ...
      sFW3S2roS4X0Af/kSSD8mlBBTFTCMBAj6rtLBKLaQbIxEpIzrgvp
      -----END CERTIFICATE-----
Copy to Clipboard

重要

この認証局のコンテンツで、新しく追加する行は、すべて同じレベルにインデントする必要があります。
SSLKey:
以下のように、秘密鍵の内容を SSLKey パラメーターにコピーします。 
parameter_defaults:
    ...
    SSLKey: |
      -----BEGIN RSA PRIVATE KEY-----
      MIIEowIBAAKCAQEAqVw8lnQ9RbeI1EdLN5PJP0lVO9hkJZnGP6qb6wtYUoy1bVP7
      ...
      ctlKn3rAAdyumi4JDjESAXHIKFjJNOLrBmpQyES4XpZUC7yhqPaU
      -----END RSA PRIVATE KEY-----
Copy to Clipboard

重要

この秘密鍵のコンテンツにおいて、新しく追加する行はすべて同じ ID レベルに指定する必要があります。
EndpointMap:
EndpointMap には、HTTPS および HTTP 通信を使用したサービスのマッピングが含まれます。SSL 通信に DNS を使用する場合は、このセクションをデフォルト設定のままにしておいてください。ただし、SSL 証明書の共通名に IP アドレスを使用する場合は (「付録B SSL/TLS 証明書の設定」参照)、CLOUDNAME のインスタンスをすべて IP_ADDRESS に置き換えてください。これには以下のコマンドを使用してください。 
  $ sed -i 's/CLOUDNAME/IP_ADDRESS/' ~/templates/enable-tls.yaml
Copy to Clipboard

重要

IP_ADDRESS または CLOUDNAME は、実際の値に置き換えないでください。Heat により、オーバークラウドの作成時にこれらの変数が適切な値に置き換えられます。

resource_registry:

OS::TripleO::NodeTLSData:
OS::TripleO::NodeTLSData: のリソース URL を絶対 URL に変更します。 
resource_registry:
  OS::TripleO::NodeTLSData: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/tls/tls-cert-inject.yaml
Copy to Clipboard

ルート証明書の注入

自己署名証明書を使用する場合または、証明書の署名者がオーバークラウドのイメージにあるデフォルトのトラストストアに含まれない場合には、証明書をオーバークラウドのイメージに注入します。Heat テンプレートコレクションから inject-trust-anchor.yaml 環境ファイルをコピーします。 
$ cp -r /usr/share/openstack-tripleo-heat-templates/environments/inject-trust-anchor.yaml ~/templates/.
Copy to Clipboard
このファイルを編集して、下記のパラメーターに以下の変更を加えます。

parameter_defaults:

SSLRootCertificate:
SSLRootCertificate パラメーターにルート認証局ファイルの内容をコピーします。以下に例を示します。 
parameter_defaults:
    SSLRootCertificate: |
      -----BEGIN CERTIFICATE-----
      MIIDgzCCAmugAwIBAgIJAKk46qw6ncJaMA0GCSqGSIb3DQEBCwUAMFgxCzAJBgNV
      ...
      sFW3S2roS4X0Af/kSSD8mlBBTFTCMBAj6rtLBKLaQbIxEpIzrgvp
      -----END CERTIFICATE-----
Copy to Clipboard

重要

この認証局のコンテンツで、新しく追加する行は、すべて同じレベルにインデントする必要があります。

resource_registry:

OS::TripleO::NodeTLSCAData:
OS::TripleO::NodeTLSCAData: のリソース URL を絶対 URL に変更します。 
  resource_registry:
    OS::TripleO::NodeTLSCAData: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/tls/ca-inject.yaml
Copy to Clipboard

DNS エンドポイントの設定

DNS ホスト名を使用して SSL/TLS でオーバークラウドにアクセスする場合は、新しい環境ファイル (~/templates/cloudname.yaml) を作成して、オーバークラウドのエンドポイントのホスト名を定義します。以下のパラメーターを使用してください。

parameter_defaults:

CloudName:
オーバークラウドエンドポイントの DNS ホスト名
DnsServers:
使用する DNS サーバー一覧。設定済みの DNS サーバーには、パブリック API の IP アドレスに一致する設定済みの CloudName へのエントリーが含まれていなければなりません。
このファイルの内容の例は以下のとおりです。 
parameter_defaults:
  CloudName: overcloud.example.com
  DnsServers: ["10.0.0.1"]
Copy to Clipboard

オーバークラウド作成時の環境ファイルの追加

「高度なオーバークラウドの作成」に記載のデプロイメントのコマンド (openstack overcloud deploy) は、-e オプションを使用して環境ファイルを追加します。以下の順番にこのセクションから環境ファイルを追加します。
  • SSL/TLS を有効化する環境ファイル (enable-tls.yaml)
  • DNS ホスト名を設定する環境ファイル (cloudname.yaml)
  • ルート認証局を注入する環境ファイル (inject-trust-anchor.yaml)
例: 
$ openstack overcloud deploy --templates [...] -e /home/stack/templates/enable-tls.yaml -e ~/templates/cloudname.yaml -e ~/templates/inject-trust-anchor.yaml
Copy to Clipboard

6.2.8. オーバークラウドの登録

オーバークラウドは、Red Hat コンテンツ配信ネットワーク、Red Hat Satellite 5 または 6 サーバーにノードを登録する方法を提供します。これは、環境ファイルまたはコマンドラインのいずれかを使用して実行することができます。

方法 1: コマンドライン

デプロイメントのコマンド (openstack overcloud deploy) は、一連のオプションを使用して登録情報を定義します。「付録I デプロイメントパラメーター」の表には、これらのオプションと説明についてまとめています。これらのオプションは、「高度なオーバークラウドの作成」でデプロイメントのコマンドを実行する時に追加してください。以下に例を示します。 
# openstack overcloud deploy --templates --rhel-reg --reg-method satellite --reg-sat-url http://example.satellite.com  --reg-org MyOrg --reg-activation-key MyKey --reg-force [...]
Copy to Clipboard

方法 2: 環境ファイル

登録ファイルを Heat テンプレートコレクションからコピーします。 
$ cp -r /usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration ~/templates/.
Copy to Clipboard
~/templates/rhel-registration/environment-rhel-registration.yaml を編集し、登録の方法と詳細に応じて以下の値を変更します。
rhel_reg_method
登録の方法を選択します。portal、satellite、disable のいずれかです。
rhel_reg_type
登録するユニットの種別。system として登録するには空欄のままにします。
rhel_reg_auto_attach
互換性のあるサブスクリプションをこのシステムに自動的にアタッチします。true に設定して有効にするか、false に設定して無効にします。
rhel_reg_service_level
自動アタッチメントに使用するサービスレベル
rhel_reg_release
このパラメーターを使用して、自動アタッチメント用のリリースバージョンを設定します。Red Hat Subscription Manager からのデフォルトを使用するには、空欄のままにします。
rhel_reg_pool_id
使用するサブスクリプションプール ID。サブスクリプションを自動でアタッチしない場合に使用します。
rhel_reg_sat_url
オーバークラウドノードを登録する Satellite サーバーのベース URL。このパラメーターには、HTTPS URL ではなく、Satellite の HTTP URL を使用します。たとえば、https://satellite.example.com ではなく http://satellite.example.com を使用します。オーバークラウドの作成プロセスではこの URL を使用して、どのサーバーが Red Hat Satellite 5 または Red Hat Satellite 6 サーバーであるかを判断します。Red Hat Satellite 5 サーバーの場合は、オーバークラウドは katello-ca-consumer-latest.noarch.rpm ファイルを取得して subscription-manager に登録し、katello-agent をインストールします。Red Hat Satellite 6 サーバーの場合はオーバークラウドは RHN-ORG-TRUSTED-SSL-CERT ファイルを取得して rhnreg_ks に登録します。
rhel_reg_server_url
使用するサブスクリプションサービスのホスト名を指定します。デフォルトは、カスタマーポータルのサブスクリプション管理、subscription.rhn.redhat.com です。このオプションを使用しない場合、システムはカスタマーポータルのサブスクリプション管理に登録されます。サブスクリプションサーバーの URL は、https://hostname:port/prefix の形式を使用します。
rhel_reg_base_url
更新を受信するためのコンテンツ配信サーバーのホスト名を指定します。デフォルトは https://cdn.redhat.com です。Satellite 6 は独自のコンテンツをホストするため、URL は Satellite 6 で登録されているシステムに使用する必要があります。コンテンツのベース URL は https://hostname:port/prefix の形式を使用します。
rhel_reg_org
登録に使用する組織
rhel_reg_environment
選択した組織内で使用する環境
rhel_reg_repos
有効化するリポジトリーのコンマ区切りリスト
rhel_reg_activation_key
登録に使用するアクティベーションキー
rhel_reg_user, rhel_reg_password
登録用のユーザー名およびパスワード。可能な場合には、登録用のアクティベーションキーを使用します。
rhel_reg_machine_name
マシン名。ノードのホスト名を使用するには、空欄のままにします。
rhel_reg_force
登録のオプションを強制するには true に設定します (例:ノードの再登録時など)。
「高度なオーバークラウドの作成」に記載のデプロイメントのコマンド (openstack overcloud deploy) は、-e オプションを使用して環境ファイルを追加します。~/templates/rhel-registration/environment-rhel-registration.yaml と ~/templates/rhel-registration/rhel-registration-resource-registry.yaml の両方を追加します。以下に例を示します。 
$ openstack overcloud deploy --templates [...] -e /home/stack/templates/rhel-registration/environment-rhel-registration.yaml -e /home/stack/templates/rhel-registration/rhel-registration-resource-registry.yaml
Copy to Clipboard

重要

登録は、OS::TripleO::NodeExtraConfig Heat リソースにように設定されます。これは、このリソースを登録のみに使用できることを意味します。詳しくは、「オーバークラウドの設定前のカスタマイズ」を参照してください。

6.2.9. 高度なオーバークラウドの作成

OpenStack 環境の最後の段階として、環境作成に必要とされるコマンドを実行します。このコマンドを使用して、3 つのコントローラーノード、3 つのコンピュートノード、3 つの Ceph Storage ノードをインストールします。

注記

Red Hat カスタマーポータルには、オーバークラウド作成前の設定検証に役立つラボがあります。このラボは、https://access.redhat.com/labs/ospec/ で利用できます。ラボについての説明は、https://access.redhat.com/labsinfo/ospec に記載されています。
以下のコマンドを実行して、高度なオーバークラウドの作成を開始します。 
$ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e ~/templates/network-environment.yaml -e ~/templates/storage-environment.yaml --control-scale 3 --compute-scale 3 --ceph-storage-scale 3 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --ntp-server pool.ntp.org --neutron-network-type vxlan --neutron-tunnel-types vxlan
Copy to Clipboard
このコマンドでは、以下の追加オプションも使用できます。
  • --templates: /usr/share/openstack-tripleo-heat-templates の Heat テンプレートコレクションを使用してオーバークラウドを作成します。
  • -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml: -e オプションは、オーバークラウドデプロイメントに別の環境ファイルを追加します。この場合は、ネットワーク分離の設定を初期化する環境ファイルです。
  • -e ~/templates/network-environment.yaml: -e オプションはオーバークラウドデプロイメントに別の環境ファイルを追加します。この場合は、「高度なオーバークラウドのネットワーク環境ファイルの作成」で作成したネットワーク環境ファイルです。
  • -e ~/templates/storage-environment.yaml: -e オプションはオーバークラウドデプロイメントに別の環境ファイルを追加します。この場合は、ストレージの設定を初期化する環境ファイルです。
  • --control-scale 3: コントローラーノードを 3 つにスケーリングします。
  • --compute-scale 3: コンピュートノードを 3 つにスケーリングします。
  • --ceph-storage-scale 3: Ceph Storage ノードを 3 つにスケーリングします。
  • --control-flavor control: 対象のコントローラーノードに特定のフレーバーを使用します。
  • --compute-flavor compute: 対象のコンピュートノードに特定のフレーバーを使用します。
  • --ceph-storage-flavor ceph-storage: Ceph Storage ノードに特定のフレーバーを使用します。
  • --ntp-server pool.ntp.org: 時刻の同期に NTP サーバーを使用します。これは、コントローラーノードクラスターの同期を保つ際に便利です。
  • --neutron-network-type vxlan: オーバークラウドの Neutron ネットワークに Virtual Extensible LAN (VXLAN) を使用します。
  • --neutron-tunnel-types vxlan - オーバークラウドの Neutron トンネリングに Virtual Extensible LAN (VXLAN) を使用します。

注記

オプションの完全な一覧を表示するには、以下を実行します。 
$ openstack help overcloud deploy
Copy to Clipboard
また、パラメーターの例については「付録I デプロイメントパラメーター」、登録の詳細については「オーバークラウドの登録」も参照してください。
オーバークラウドの作成プロセスが開始され、director によりノードがプロビジョニングされます。このプロセスは完了するまで多少時間がかかります。オーバークラウドの作成のステータスを確認するには、stack ユーザーとして別のターミナルを開き、以下を実行します。 
$ source ~/stackrc                # Initializes the stack user to use the CLI commands
$ heat stack-list --show-nested
Copy to Clipboard
heat stack-list --show-nested コマンドは、オーバークラウド作成の現在のステージを表示します。

警告

-e オプションを使用してオーバークラウドに追加した環境ファイルはいずれも、オーバークラウドのスタック定義の一部となります。director は、「7章オーバークラウド作成後のタスクの実行」に記載の再デプロイおよびデプロイ後の機能にこれらの環境ファイルを必要とします。これらのファイルが含まれていない場合には、オーバークラウドが破損することになる場合があります。
オーバークラウドの設定を後で変更する予定がある場合は、カスタム環境ファイルと Heat テンプレートのパラメーターを変更し、openstack overcloud deploy のコマンドを再度実行します。オーバークラウドを手動で編集しても、director を使用してオーバークラウドスタックの更新を行う際に director の設定で上書きされてしまうので、設定は直接編集しないでください。
後で使用および変更するために、最初のデプロイメントコマンドを保存しておきます。たとえば、deploy-overcloud.sh という名前のスクリプトファイルでデプロイメントコマンドを保存するには、以下のように編集します。 
#!/bin/bash
openstack overcloud deploy --templates \
  -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
  -e ~/templates/network-environment.yaml \
  -e ~/templates/storage-environment.yaml \
  -t 150 \
  --control-scale 3 \
  --compute-scale 3 \
  --ceph-storage-scale 3 \
  --swift-storage-scale 0 \
  --block-storage-scale 0 \
  --compute-flavor compute \
  --control-flavor control \
  --ceph-storage-flavor ceph-storage \
  --swift-storage-flavor swift-storage \
  --block-storage-flavor block-storage \
  --ntp-server pool.ntp.org \
  --neutron-network-type vxlan \
  --neutron-tunnel-types vxlan \
  --libvirt-type qemu
Copy to Clipboard
これにより、将来オーバークラウドに変更を加えたり、スケーリングしたりする際に使用するオーバークラウドのデプロイメントコマンドのパラメーターと環境ファイルが保持されるので、今後オーバークラウドをカスタマイズする際にこのスクリプトを編集して再度実行することができます。

警告

バックグラウンドプロセスとして openstack overcloud deploy を実行しないでください。バックグラウンドのプロセスとして開始された場合にはオーバークラウドの作成は途中で停止してしまう可能性があります。

6.2.10. 高度なオーバークラウドへのアクセス

director は、director ホストからオーバークラウドに対話するための設定を行い、認証をサポートするスクリプトを作成して、stack ユーザーのホームディレクトリーにこのファイル (overcloudrc) を保存します。このファイルを使用するには、以下のコマンドを実行します。 
$ source ~/overcloudrc
Copy to Clipboard
これにより、director ホストの CLI からオーバークラウドと対話するために必要な環境変数が読み込まれます。director ホストとの対話に戻るには、以下のコマンドを実行します。 
$ source ~/stackrc
Copy to Clipboard

6.2.11. コンピュートノードのフェンシング

フェンシングとは、クラスターとそのリソースを保護するためにノードを分離するプロセスのことです。フェンシングがないと、問題のあるノードが原因でクラスター内のデータが破損する可能性があります。
director は、Pacemaker と呼ばれるツールを使用して、高可用性のコントローラーノードクラスターを提供します。Pacemaker は、問題のあるノードをフェンシングするのに役立つ STONITH (Shoot-The-Other-Node-In-The-Head) というプロセスを使用します。デフォルトでは、STONITH はお使いのクラスター上では無効化されているため、Pacemaker がクラスター内の各ノードの電源管理を制御できるように手動で設定する必要があります。

注記

director 上の stack ユーザーから、heat-admin ユーザーとして各ノードにログインします。オーバークラウドを作成すると自動的に stack ユーザーの SSH キーが各ノードの heat-admin にコピーされます。
pcs status を使用して、クラスターが実行していることを確認します。 
$ sudo pcs status
Cluster name: openstackHA
Last updated: Wed Jun 24 12:40:27 2015
Last change: Wed Jun 24 11:36:18 2015
Stack: corosync
Current DC: lb-c1a2 (2) - partition with quorum
Version: 1.1.12-a14efad
3 Nodes configured
141 Resources configured
Copy to Clipboard
pcs property show で、STONITH が無効化されていることを確認します。 
$ sudo pcs property show
Cluster Properties:
 cluster-infrastructure: corosync
 cluster-name: openstackHA
 dc-version: 1.1.12-a14efad
 have-watchdog: false
 stonith-enabled: false
Copy to Clipboard
コントローラーノードには、director がサポートするさまざまな電源管理デバイス用のフェンシングエージェントのセットが実装されています。これには、以下が含まれます。
表6.5 フェンスエージェント
デバイス
種別
fence_ipmilan
Intelligent Platform Management Interface (IPMI)
fence_idrac、fence_drac5
Dell Remote Access Controller (DRAC)
fence_ilo
Integrated Lights-Out (iLO)
fence_ucs
Cisco UCS: 詳しい情報は 「Configuring Cisco Unified Computing System (UCS) Fencing on an OpenStack High Availability Environment」 の記事を参照してください。
fence_xvm、fence_virt
Libvirt と SSH
本項ではこれ以降、IPMI エージェント (fence_ipmilan) を例として使用します。
Pacemaker がサポートする IPMI オプションの完全一覧を表示します。 
$ sudo pcs stonith describe fence_ipmilan
Copy to Clipboard
各ノードには、電源管理を制御する IPMI デバイスの設定が必要です。これには、各ノードの Pacemaker に stonith デバイスを追加する必要があります。クラスターに以下のコマンドを実行します。

注記

各例の 2 番目のコマンドは、ノードが自らをフェンシングするかどうかを尋ねないようにします。
コントローラーノード 1 の場合: 
$ sudo pcs stonith create my-ipmilan-for-controller01 fence_ipmilan pcmk_host_list=overcloud-controller-0 ipaddr=192.0.2.205 login=admin passwd=p@55w0rd! lanplus=1 cipher=1 op monitor interval=60s
$ sudo pcs constraint location my-ipmilan-for-controller01 avoids overcloud-controller-0
Copy to Clipboard
コントローラーノード 2 の場合: 
$ sudo pcs stonith create my-ipmilan-for-controller02 fence_ipmilan pcmk_host_list=overcloud-controller-1 ipaddr=192.0.2.206 login=admin passwd=p@55w0rd! lanplus=1 cipher=1 op monitor interval=60s
$ sudo pcs constraint location my-ipmilan-for-controller02 avoids overcloud-controller-1
Copy to Clipboard
コントローラーノード 3 の場合: 
$ sudo pcs stonith create my-ipmilan-for-controller03 fence_ipmilan pcmk_host_list=overcloud-controller-2 ipaddr=192.0.2.207 login=admin passwd=p@55w0rd! lanplus=1 cipher=1 op monitor interval=60s
$ sudo pcs constraint location my-ipmilan-for-controller03 avoids overcloud-controller-2
Copy to Clipboard
以下のコマンドを実行して、すべての STONITH リソースを表示します。 
$ sudo pcs stonith show
Copy to Clipboard
以下のコマンドを実行して、特定の STONITH リソースを表示します。 
$ sudo pcs stonith show [stonith-name]
Copy to Clipboard
最後に、stonith プロパティーを true に設定して、フェンシングを有効にします。 
$ sudo pcs property set stonith-enabled=true
Copy to Clipboard
プロパティーを確認します。 
$ sudo pcs property show
Copy to Clipboard

6.2.12. 高度なオーバークラウドの完了

これで高度なオーバークラウドの作成が完了しました。作成後の機能については、「7章オーバークラウド作成後のタスクの実行」を参照してください。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat