第6章 CLI ツールを使用した基本的なオーバークラウドの設定

本章では、CLI ツールを使用した OpenStack Platform 環境の基本的な設定手順を説明します。基本設定のオーバークラウドには、カスタムの機能は含まれていませんが、『オーバークラウドの高度なカスタマイズ』ガイドに記載の手順に従って、この基本的なオーバークラウドに高度な設定オプションを追加して、仕様に合わせてカスタマイズすることができます。

本章の例では、すべてのノードが電源管理に IPMI を使用したベアメタルシステムとなっています。電源管理の種別およびそのオプションに関する詳細は、「付録B 電源管理ドライバー」を参照してください。

ワークフロー

  1. ノード定義のテンプレートを作成して director で空のノードを登録します。
  2. 全ノードのハードウェアを検査します。
  3. ロールにノードをタグ付けします。
  4. 追加のノードプロパティーを定義します。

要件

  • 4章アンダークラウドのインストール」で作成した director ノード
  • ノードに使用するベアメタルマシンのセット。必要なノード数は、作成予定のオーバークラウドのタイプにより異なります (オーバークラウドロールに関する情報は「ノードのデプロイメントロールのプランニング」を参照してください)。これらのマシンは、各ノード種別の要件セットに従う必要があります。これらの要件については、「オーバークラウドの要件」を参照してください。これらのノードにはオペレーティングシステムは必要ありません。director が Red Hat Enterprise Linux 7 のイメージを各ノードにコピーします。
  • ネイティブ VLAN として設定したプロビジョニングネットワーク用のネットワーク接続 1 つ。全ノードは、このネイティブに接続して、「ネットワーク要件」で設定した要件に準拠する必要があります。この章の例では、以下の IP アドレスの割り当てで、プロビジョニングサブネットとして 192.168.24.0/24 を使用します。

    表6.1 プロビジョニングネットワークの IP 割り当て

    ノード名

    IP アドレス

    MAC アドレス

    IPMI IP アドレス

    director

    192.168.24.1

    aa:aa:aa:aa:aa:aa

    不要

    コントローラー

    定義済みの DHCP

    bb:bb:bb:bb:bb:bb

    192.168.24.205

    Compute

    定義済みの DHCP

    cc:cc:cc:cc:cc:cc

    192.168.24.206

  • その他のネットワーク種別はすべて、OpenStack サービスにプロビジョニングネットワークを使用しますが、ネットワークトラフィックの他のタイプに追加でネットワークを作成することができます。
  • コンテナーイメージのソース。コンテナーイメージのソースを含む環境ファイルの生成方法については、「5章コンテナーレジストリー情報の設定」を参照してください。

6.1. オーバークラウドへのノードの登録

director では、手動で作成したノード定義のテンプレートが必要です。このファイル (instackenv.json) は、JSON 形式のファイルを使用して、ノードのハードウェアおよび電源管理の情報が含まれます。たとえば、2 つのノードを登録するテンプレートは、以下のようになります。

{
    "nodes":[
        {
            "mac":[
                "bb:bb:bb:bb:bb:bb"
            ],
            "name":"node01",
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.168.24.205"
        },
        {
            "mac":[
                "cc:cc:cc:cc:cc:cc"
            ],
            "name":"node02",
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.168.24.206"
        }
    ]
}

このテンプレートでは、以下の属性を使用します。

name
ノードの論理名
pm_type
使用する電源管理ドライバー。この例では IPMI ドライバーを使用します (pxe_ipmitool)。
pm_user; pm_password
IPMI のユーザー名およびパスワード
pm_addr
IPMI デバイスの IP アドレス
mac
(オプション) ノード上のネットワークインターフェースの MAC アドレス一覧。各システムのプロビジョニング NIC の MAC アドレスのみを使用します。
cpu
(オプション) ノード上の CPU 数
memory
(オプション) メモリーサイズ (MB)
disk
(オプション) ハードディスクのサイズ (GB)
arch
(オプション) システムアーキテクチャー
注記

電源管理の種別およびそのオプションに関する詳細は、「付録B 電源管理ドライバー」を参照してください。

テンプレートの作成後に、stack ユーザーのホームディレクトリー (/home/stack/instackenv.json) にファイルを保存して、以下のコマンドを使用して director にインポートします。

$ source ~/stackrc
(undercloud) $ openstack overcloud node import ~/instackenv.json

このコマンドでテンプレートをインポートして、テンプレートから director に各ノードを登録します。

ノードを登録して設定が完了した後に、CLI でこれらのノードの一覧を表示します。

(undercloud) $ openstack baremetal node list

6.2. ノードのハードウェアの検査

director は各ノードでイントロスペクションプロセスを実行することができます。このプロセスを実行すると、各ノードが PXE を介してイントロスペクションエージェントを起動します。このエージェントは、ノードからハードウェアのデータを収集して、director に送り返します。次に director は、director 上で実行中の OpenStack Object Storage (swift) サービスにこのイントロスペクションデータを保管します。director は、プロファイルのタグ付け、ベンチマーキング、ルートディスクの手動割り当てなど、さまざまな目的でハードウェア情報を使用します。

注記

ポリシーファイルを作成して、イントロスペクションの直後にノードをプロファイルに自動でタグ付けすることも可能です。ポリシーファイルを作成してイントロスペクションプロセスに組み入れる方法に関する詳しい情報は、「付録E プロファイルの自動タグ付け」を参照してください。または、「プロファイルへのノードのタグ付け」に記載の手順に従って、ノードをプロファイルに手動でタグ付けすることもできます。

以下のコマンドを実行して、各ノードのハードウェア属性を検証します。

(undercloud) $ openstack overcloud node introspect --all-manageable --provide
  • --all-manageable オプションは、管理状態のノードのみをイントロスペクションします。上記の例では、すべてのノードが対象です。
  • --provide オプションは、イントロスペクション後に全ノードを available の状態にします。

別のターミナルウィンドウで以下のコマンドを使用してイントロスペクションの進捗状況をモニタリングします。

(undercloud) $ sudo journalctl -l -u openstack-ironic-inspector -u openstack-ironic-inspector-dnsmasq -u openstack-ironic-conductor -f
重要

このプロセスが最後まで実行されて正常に終了したことを確認してください。ベアメタルの場合には、通常 15 分ほどかかります。

イントロスペクション完了後には、すべてのノードが available の状態に変わります。

ノードイントロスペクションの個別実行

available の状態のノードで個別にイントロスペクションを実行するには、ノードを管理モードに設定して、イントロスペクションを実行します。

(undercloud) $ openstack baremetal node manage [NODE UUID]
(undercloud) $ openstack overcloud node introspect [NODE UUID] --provide

イントロスペクションが完了すると、ノードは available の状態に変わります。

初回のイントロスペクション後のノードイントロスペクションの実行

--provide オプションを指定したので、初回のイントロスペクションの後には、全ノードが available の状態に入るはずです。初回のイントロスペクション後に全ノードにイントロスペクションを実行するには、すべてのノードを manageable の状態にして、一括のイントロスペクションコマンドを実行します。

(undercloud) $ for node in $(openstack baremetal node list --fields uuid -f value) ; do openstack baremetal node manage $node ; done
(undercloud) $ openstack overcloud node introspect --all-manageable --provide

イントロスペクション完了後には、すべてのノードが available の状態に変わります。

ネットワークイントロスペクションの実行によるインターフェース情報の取得

ネットワークイントロスペクションにより、Link Layer Discovery Protocol (LLDP) データがネットワークスイッチから取得されます。以下のコマンドにより、ノード上の全インターフェースに関する LLDP 情報のサブセット、または特定のノードおよびインターフェースに関するすべての情報が表示されます。この情報は、トラブルシューティングに役立ちます。director では、デフォルトで LLDP データ収集が有効になっています。

ノード上のインターフェースのリストを取得するには、以下のコマンドを実行します。

(undercloud) $ openstack baremetal introspection interface list [NODE UUID]

例:

(undercloud) $ openstack baremetal introspection interface list c89397b7-a326-41a0-907d-79f8b86c7cd9
+-----------+-------------------+------------------------+-------------------+----------------+
| Interface | MAC Address       | Switch Port VLAN IDs   | Switch Chassis ID | Switch Port ID |
+-----------+-------------------+------------------------+-------------------+----------------+
| p2p2      | 00:0a:f7:79:93:19 | [103, 102, 18, 20, 42] | 64:64:9b:31:12:00 | 510            |
| p2p1      | 00:0a:f7:79:93:18 | [101]                  | 64:64:9b:31:12:00 | 507            |
| em1       | c8:1f:66:c7:e8:2f | [162]                  | 08:81:f4:a6:b3:80 | 515            |
| em2       | c8:1f:66:c7:e8:30 | [182, 183]             | 08:81:f4:a6:b3:80 | 559            |
+-----------+-------------------+------------------------+-------------------+----------------+

インターフェースのデータおよびスイッチポートの情報を表示するには、以下のコマンドを実行します。

(undercloud) $ openstack baremetal introspection interface show [NODE UUID] [INTERFACE]

例:

(undercloud) $ openstack baremetal introspection interface show c89397b7-a326-41a0-907d-79f8b86c7cd9 p2p1
+--------------------------------------+------------------------------------------------------------------------------------------------------------------------+
| Field                                | Value                                                                                                                  |
+--------------------------------------+------------------------------------------------------------------------------------------------------------------------+
| interface                            | p2p1                                                                                                                   |
| mac                                  | 00:0a:f7:79:93:18                                                                                                      |
| node_ident                           | c89397b7-a326-41a0-907d-79f8b86c7cd9                                                                                   |
| switch_capabilities_enabled          | [u'Bridge', u'Router']                                                                                                 |
| switch_capabilities_support          | [u'Bridge', u'Router']                                                                                                 |
| switch_chassis_id                    | 64:64:9b:31:12:00                                                                                                      |
| switch_port_autonegotiation_enabled  | True                                                                                                                   |
| switch_port_autonegotiation_support  | True                                                                                                                   |
| switch_port_description              | ge-0/0/2.0                                                                                                             |
| switch_port_id                       | 507                                                                                                                    |
| switch_port_link_aggregation_enabled | False                                                                                                                  |
| switch_port_link_aggregation_id      | 0                                                                                                                      |
| switch_port_link_aggregation_support | True                                                                                                                   |
| switch_port_management_vlan_id       | None                                                                                                                   |
| switch_port_mau_type                 | Unknown                                                                                                                |
| switch_port_mtu                      | 1514                                                                                                                   |
| switch_port_physical_capabilities    | [u'1000BASE-T fdx', u'100BASE-TX fdx', u'100BASE-TX hdx', u'10BASE-T fdx', u'10BASE-T hdx', u'Asym and Sym PAUSE fdx'] |
| switch_port_protocol_vlan_enabled    | None                                                                                                                   |
| switch_port_protocol_vlan_ids        | None                                                                                                                   |
| switch_port_protocol_vlan_support    | None                                                                                                                   |
| switch_port_untagged_vlan_id         | 101                                                                                                                    |
| switch_port_vlan_ids                 | [101]                                                                                                                  |
| switch_port_vlans                    | [{u'name': u'RHOS13-PXE', u'id': 101}]                                                                                 |
| switch_protocol_identities           | None                                                                                                                   |
| switch_system_name                   | rhos-compute-node-sw1                                                                                                  |
+--------------------------------------+------------------------------------------------------------------------------------------------------------------------+

ハードウェアイントロスペクション情報の取得

Bare Metal サービスでは、ハードウェア検査時に追加のハードウェア情報を取得するためのパラメーター (inspection_extras) がデフォルトで有効になっています。これらのハードウェア情報を使って、オーバークラウドを設定することができます。undercloud.conf ファイルの inspection_extras パラメーターに関する詳細は、「director の設定」を参照してください。

たとえば、numa_topology コレクターは、このハードウェア inspection_extras の一部で、各 NUMA ノードに関する以下の情報が含まれます。

  • RAM (キロバイト単位)
  • 物理 CPU コアおよびそのシブリングスレッド
  • NUMA ノードに関連付けられた NIC

この情報を取得するには、ベアメタルノードの UUID を指定して、openstack baremetal introspection data save _UUID_ | jq .numa_topology コマンドを実行します。

取得されるベアメタルノードの NUMA 情報の例を、以下に示します。

{
  "cpus": [
    {
      "cpu": 1,
      "thread_siblings": [
        1,
        17
      ],
      "numa_node": 0
    },
    {
      "cpu": 2,
      "thread_siblings": [
        10,
        26
      ],
      "numa_node": 1
    },
    {
      "cpu": 0,
      "thread_siblings": [
        0,
        16
      ],
      "numa_node": 0
    },
    {
      "cpu": 5,
      "thread_siblings": [
        13,
        29
      ],
      "numa_node": 1
    },
    {
      "cpu": 7,
      "thread_siblings": [
        15,
        31
      ],
      "numa_node": 1
    },
    {
      "cpu": 7,
      "thread_siblings": [
        7,
        23
      ],
      "numa_node": 0
    },
    {
      "cpu": 1,
      "thread_siblings": [
        9,
        25
      ],
      "numa_node": 1
    },
    {
      "cpu": 6,
      "thread_siblings": [
        6,
        22
      ],
      "numa_node": 0
    },
    {
      "cpu": 3,
      "thread_siblings": [
        11,
        27
      ],
      "numa_node": 1
    },
    {
      "cpu": 5,
      "thread_siblings": [
        5,
        21
      ],
      "numa_node": 0
    },
    {
      "cpu": 4,
      "thread_siblings": [
        12,
        28
      ],
      "numa_node": 1
    },
    {
      "cpu": 4,
      "thread_siblings": [
        4,
        20
      ],
      "numa_node": 0
    },
    {
      "cpu": 0,
      "thread_siblings": [
        8,
        24
      ],
      "numa_node": 1
    },
    {
      "cpu": 6,
      "thread_siblings": [
        14,
        30
      ],
      "numa_node": 1
    },
    {
      "cpu": 3,
      "thread_siblings": [
        3,
        19
      ],
      "numa_node": 0
    },
    {
      "cpu": 2,
      "thread_siblings": [
        2,
        18
      ],
      "numa_node": 0
    }
  ],
  "ram": [
    {
      "size_kb": 66980172,
      "numa_node": 0
    },
    {
      "size_kb": 67108864,
      "numa_node": 1
    }
  ],
  "nics": [
    {
      "name": "ens3f1",
      "numa_node": 1
    },
    {
      "name": "ens3f0",
      "numa_node": 1
    },
    {
      "name": "ens2f0",
      "numa_node": 0
    },
    {
      "name": "ens2f1",
      "numa_node": 0
    },
    {
      "name": "ens1f1",
      "numa_node": 0
    },
    {
      "name": "ens1f0",
      "numa_node": 0
    },
    {
      "name": "eno4",
      "numa_node": 0
    },
    {
      "name": "eno1",
      "numa_node": 0
    },
    {
      "name": "eno3",
      "numa_node": 0
    },
    {
      "name": "eno2",
      "numa_node": 0
    }
  ]
}

6.3. ベアメタルノードの自動検出

auto-discovery を使用すると、最初に instackenv.json ファイルを作成せずに、アンダークラウドノードを登録してそのメタデータを生成することができます。この改善により、最初のノード情報取得に費す時間を短縮できます。たとえば、IPMI IP アドレスを照合し、その後に instackenv.json ファイルを作成する必要がなくなります。

要件

  • すべてのオーバークラウドノードの BMC が、IPMI を通じて director にアクセスできるように設定されていること
  • すべてのオーバークラウドノードが、アンダークラウドのコントロールプレーンネットワークに接続された NIC から PXE ブートするように設定されていること

自動検出の有効化

  1. undercloud.conf でベアメタルの自動検出を有効にします。

    enable_node_discovery = True
    discovery_default_driver = pxe_ipmitool
    • enable_node_discovery: 有効にすると、PXE を使ってイントロスペクション ramdisk をブートするすべてのノードが Ironic に登録されます。
    • discovery_default_driver: 検出されたノードに使用するドライバーを設定します。例: pxe_ipmitool
  2. IPMI の認証情報を Ironic に追加します。

    1. IPMI の認証情報を ipmi-credentials.json という名前のファイルに追加します。以下の例で使用しているユーザー名とパスワードの値は、お使いの環境に応じて置き換える必要があります。

      [
          {
              "description": "Set default IPMI credentials",
              "conditions": [
                  {"op": "eq", "field": "data://auto_discovered", "value": true}
              ],
              "actions": [
                  {"action": "set-attribute", "path": "driver_info/ipmi_username",
                   "value": "SampleUsername"},
                  {"action": "set-attribute", "path": "driver_info/ipmi_password",
                   "value": "RedactedSecurePassword"},
                  {"action": "set-attribute", "path": "driver_info/ipmi_address",
                   "value": "{data[inventory][bmc_address]}"}
              ]
          }
      ]
  3. IPMI の認証情報ファイルを Ironic にインポートします。

    $ openstack baremetal introspection rule import ipmi-credentials.json

自動検出のテスト

  1. 必要なノードの電源をオンにします。
  2. openstack baremetal node list を実行します。新しいノードが enroll の状態でリストに表示されるはずです。

    $ openstack baremetal node list
    +--------------------------------------+------+---------------+-------------+--------------------+-------------+
    | UUID                                 | Name | Instance UUID | Power State | Provisioning State | Maintenance |
    +--------------------------------------+------+---------------+-------------+--------------------+-------------+
    | c6e63aec-e5ba-4d63-8d37-bd57628258e8 | None | None          | power off   | enroll             | False       |
    | 0362b7b2-5b9c-4113-92e1-0b34a2535d9b | None | None          | power off   | enroll             | False       |
    +--------------------------------------+------+---------------+-------------+--------------------+-------------+
  3. 各ノードにリソースクラスを設定します。

    $ for NODE in `openstack baremetal node list -c UUID -f value` ; do openstack baremetal node set $NODE --resource-class baremetal ; done
  4. 各ノードにカーネルと ramdisk を設定します。

    $ for NODE in `openstack baremetal node list -c UUID -f value` ; do openstack baremetal node manage $NODE ; done
    $ openstack overcloud node configure --all-manageable
  5. 全ノードを利用可能な状態に設定します。

    $ for NODE in `openstack baremetal node list -c UUID -f value` ; do openstack baremetal node provide $NODE ; done

ルールを使用して異なるベンダーのハードウェアを検出する方法

異種のハードウェアが混在する環境では、イントロスペクションルールを使って、認証情報の割り当てやリモート管理を行うことができます。たとえば、DRAC を使用する Dell ノードを処理するには、別の検出ルールが必要になる場合があります。

  1. 以下の内容で、dell-drac-rules.json という名前のファイルを作成します。この例で使用しているユーザー名およびパスワードの値は、お使いの環境に応じて置き換える必要があります。

    [
        {
            "description": "Set default IPMI credentials",
            "conditions": [
                {"op": "eq", "field": "data://auto_discovered", "value": true},
                {"op": "ne", "field": "data://inventory.system_vendor.manufacturer",
                 "value": "Dell Inc."}
            ],
            "actions": [
                {"action": "set-attribute", "path": "driver_info/ipmi_username",
                 "value": "SampleUsername"},
                {"action": "set-attribute", "path": "driver_info/ipmi_password",
                 "value": "RedactedSecurePassword"},
                {"action": "set-attribute", "path": "driver_info/ipmi_address",
                 "value": "{data[inventory][bmc_address]}"}
            ]
        },
        {
            "description": "Set the vendor driver for Dell hardware",
            "conditions": [
                {"op": "eq", "field": "data://auto_discovered", "value": true},
                {"op": "eq", "field": "data://inventory.system_vendor.manufacturer",
                 "value": "Dell Inc."}
            ],
            "actions": [
                {"action": "set-attribute", "path": "driver", "value": "idrac"},
                {"action": "set-attribute", "path": "driver_info/drac_username",
                 "value": "SampleUsername"},
                {"action": "set-attribute", "path": "driver_info/drac_password",
                 "value": "RedactedSecurePassword"},
                {"action": "set-attribute", "path": "driver_info/drac_address",
                 "value": "{data[inventory][bmc_address]}"}
            ]
        }
    ]
  2. ルールを Ironic にインポートします。

    $ openstack baremetal introspection rule import dell-drac-rules.json

6.4. プロファイルへのノードのタグ付け

各ノードのハードウェアを登録、検査した後には、特定のプロファイルにノードをタグ付けします。このプロファイルタグにより、ノードがフレーバーに照合され、次にそのフレーバーがデプロイメントロールに割り当てられます。以下の例では、コントローラーノードのロール、フレーバー、プロファイル、ノード間の関係を示しています。

タイプ説明

ロール

Controller ロールはコントローラーノードの設定方法を定義します。

フレーバー

control フレーバーは、コントローラーとして使用するためにノードのハードウェアプロファイルを定義します。使用するノードを director が決定できるように、このフレーバーを Controller ロールに割り当てます。

プロファイル

control プロファイルは、control フレーバーに適用するタグで、このフレーバーに所属するノードを定義します。

ノード

また、各ノードに control プロファイルタグを適用して、control フレーバーにグループ化します。これにより、director が Controller ロールを使用してノードを設定します。

アンダークラウドのインストール時に、デフォルトプロファイルのフレーバー computecontrolswift-storageceph-storageblock-storage が作成され、大半の環境で変更なしに使用することができます。

注記

多くのノードでは、プロファイルの自動タグ付けを使用します。詳しい情報は、「付録E プロファイルの自動タグ付け」を参照してください。

特定のプロファイルにノードをタグ付けする場合には、各ノードの properties/capabilities パラメーターに profile オプションを追加します。たとえば、2 つのノードをタグ付けしてコントローラープロファイルとコンピュートプロファイルをそれぞれ使用するには、以下のコマンドを実行します。

(undercloud) $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13
(undercloud) $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0

profile:computeprofile:control オプションを追加することで、この 2 つのノードがそれぞれのプロファイルにタグ付けされます。

これらのコマンドは、各ノードのブート方法を定義する boot_option:local パラメーターも設定します。お使いのハードウェアによっては、boot_mode パラメーターを uefi に追加して、ノードが BIOS モードの代わりに UEFI を使用してブートするようにする必要がある場合もあります。詳しい情報は、「UEFI ブートモード」を参照してください。

ノードのタグ付けが完了した後には、割り当てたプロファイルまたはプロファイルの候補を確認します。

(undercloud) $ openstack overcloud profiles list

カスタムロールのプロファイル

カスタムロールを使用する場合には、これらの新規ロールに対応するために追加のフレーバーやプロファイルを作成する必要があるかもしれません。たとえば、Networker ロールの新規フレーバーを作成するには、以下のコマンドを実行します。

(undercloud) $ openstack flavor create --id auto --ram 4096 --disk 40 --vcpus 1 networker
(undercloud) $ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="networker" networker

この新規プロファイルにノードを割り当てます。

(undercloud) $ openstack baremetal node set --property capabilities='profile:networker,boot_option:local' dad05b82-0c74-40bf-9d12-193184bfc72d

6.5. ノードのルートディスクの定義

一部のノードは、複数のディスクを使用する場合があります。このため、director はプロビジョニング中に、ルートディスクに使用するディスクを特定する必要があります。

director がルートディスクを容易に特定できるようにするには、以下のようなプロパティーを使用することができます。

  • model (文字列): デバイスの ID
  • vendor (文字列): デバイスのベンダー
  • serial (文字列): ディスクのシリアル番号
  • hctl (文字列): SCSI のホスト:チャネル:ターゲット:Lun
  • size (整数):デバイスのサイズ (GB)
  • wwn (文字列): ストレージの一意識別子
  • wwn_with_extension (文字列): ベンダー拡張が末尾に付いたストレージの一意識別子
  • wwn_vendor_extension (文字列): ベンダーのストレージの一意識別子
  • rotational (ブール値): 回転式デバイス (HDD) には true、そうでない場合 (SSD) には false。
  • name (文字列): デバイス名 (例: /dev/sdb1)
重要

name は、永続デバイス名が付いたデバイスのみに使用します。name で他のデバイスのルートディスクを設定しないでください。この値は、ノードのブート時に変更される可能性があります。

以下の例では、root デバイスを特定するディスクのシリアル番号を使用して、オーバークラウドイメージをデプロイするドライブを指定します。

各ノードのハードウェアイントロスペクションからのディスク情報を確認します。以下のコマンドは、ノードからのディスク情報を表示します。

(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"
  }
]

以下の例では、ルートデバイスを、シリアル番号 61866da04f380d001ea4e13c12e36ad6 の disk 2 に設定します。そのためには、ノードの定義に root_device パラメーターを追加する必要があります。

(undercloud) $ openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
注記

各ノードの BIOS を設定して、選択したルートディスクからの起動が含まれるようにします。推奨のブート順は最初がネットワークブートで、次にルートディスクブートです。

これにより、director がルートディスクとして使用する特定のディスクを識別しやすくなります。オーバークラウドの作成の開始時には、director はこのノードをプロビジョニングして、オーバークラウドのイメージをこのディスクに書き込みます。

6.6. 環境ファイルを使用したオーバークラウドのカスタマイズ

アンダークラウドには、オーバークラウドの作成プランとして機能するさまざまな Heat テンプレートが含まれます。YAML フォーマットの環境ファイルを使って、オーバークラウドの特性をカスタマイズすることができます。このファイルで、コア Heat テンプレートコレクションのパラメーターおよびリソースを上書きします。必要に応じていくつでも環境ファイルを追加することができますが、後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順番は重要です。以下の一覧は、環境ファイルの順序の例です。

  • 各ロールおよびそのフレーバーごとのノード数。オーバークラウドを作成するには、この情報の追加は不可欠です。
  • コンテナー化された OpenStack サービスのコンテナーイメージの場所。このファイルは、「5章コンテナーレジストリー情報の設定」で説明したオプションのいずれかで作成されたものです。
  • 任意のネットワーク分離ファイル。Heat テンプレートコレクションの初期化ファイル (environments/network-isolation.yaml) から開始して、次にカスタムの NIC 設定ファイル、最後に追加のネットワーク設定の順番です。
  • 外部のロードバランシングの環境ファイル
  • Ceph Storage、NFS、iSCSI などのストレージ環境ファイル
  • Red Hat CDN または Satellite 登録用の環境ファイル
  • その他のカスタム環境ファイル

カスタム環境ファイルは、別のディレクトリーで管理することを推奨します (たとえば、templates ディレクトリー)。

『オーバークラウドの高度なカスタマイズ』ガイドを使用して、オーバークラウドの詳細機能をカスタマイズできます。

重要

基本的なオーバークラウドでは、ブロックストレージにローカルの LVM ストレージを使用しますが、この設定はサポートされません。ブロックストレージには、外部ストレージソリューション (Red Hat Ceph Storage 等) を使用することを推奨します。

6.7. CLI ツールを使用したオーバークラウドの作成

OpenStack 環境作成における最後の段階では、openstack overcloud deploy コマンドを実行して OpenStack 環境を作成します。このコマンドを実行する前に、キーオプションやカスタムの環境ファイルの追加方法を十分に理解しておく必要があります。

警告

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

オーバークラウドのパラメーター設定

以下の表では、openstack overcloud deploy コマンドを使用する際の追加パラメーターを一覧表示します。

表6.2 デプロイメントパラメーター

パラメーター説明

--templates [TEMPLATES]

デプロイする Heat テンプレートが格納されているディレクトリー。空欄にした場合には、コマンドはデフォルトのテンプレートの場所である /usr/share/openstack-tripleo-heat-templates/ を使用します。

--stack STACK

作成または更新するスタックの名前

-t [TIMEOUT], --timeout [TIMEOUT]

デプロイメントのタイムアウト (分単位)

--libvirt-type [LIBVIRT_TYPE]

ハイパーバイザーに使用する仮想化タイプ

--ntp-server [NTP_SERVER]

時刻の同期に使用する Network Time Protocol (NTP) サーバー。コンマ区切りリストで複数の NTP サーバーを指定することも可能です (例: --ntp-server 0.centos.pool.org,1.centos.pool.org)。高可用性クラスターのデプロイメントの場合には、コントローラーが一貫して同じタイムソースを参照することが必須となります。標準的な環境には、確立された慣行によって、NTP タイムソースがすでに指定されている可能性がある点に注意してください。

--no-proxy [NO_PROXY]

環境変数 no_proxy のカスタム値を定義します。これにより、プロキシー通信から特定のホスト名は除外されます。

--overcloud-ssh-user OVERCLOUD_SSH_USER

オーバークラウドノードにアクセスする SSH ユーザーを定義します。通常、SSH アクセスは heat-admin ユーザーで実行されます。

-e [EXTRA HEAT TEMPLATE], --extra-template [EXTRA HEAT TEMPLATE]

オーバークラウドデプロイメントに渡す追加の環境ファイル。複数回指定することが可能です。openstack overcloud deploy コマンドに渡す環境ファイルの順序が重要である点に注意してください。たとえば、逐次的に渡される各環境ファイルは、前の環境ファイルのパラメーターを上書きします。

--environment-directory

デプロイメントに追加する環境ファイルが格納されているディレクトリー。このコマンドは、これらの環境ファイルを最初に番号順、その後にアルファベット順で処理します。

--validation-errors-nonfatal

オーバークラウドの作成プロセスでは、デプロイメントの前に一連のチェックが行われます。このオプションは、デプロイメント前のチェックで何らかの致命的でないエラーが発生した場合に終了します。どのようなエラーが発生してもデプロイメントが失敗するので、このオプションを使用することを推奨します。

--validation-warnings-fatal

オーバークラウドの作成プロセスでは、デプロイメントの前に一連のチェックが行われます。このオプションは、デプロイメント前のチェックで何らかのクリティカルではない警告が発生した場合に終了します。

--dry-run

オーバークラウドに対する検証チェックを実行しますが、オーバークラウドを実際には作成しません。

--skip-postconfig

オーバークラウドのデプロイ後の設定を省略します。

--force-postconfig

オーバークラウドのデプロイ後の設定を強制的に行います。

--skip-deploy-identifier

DeployIdentifier パラメーターの一意の ID 生成を省略します。ソフトウェア設定のデプロイメントステップは、実際に設定が変更された場合にしか実行されません。このオプションの使用には注意が必要です。特定のロールをスケールアウトする時など、ソフトウェア設定の実行が明らかに不要な場合にしか使用しないでください。

--answers-file ANSWERS_FILE

引数とパラメーターが記載された YAML ファイルへのパス

--rhel-reg

カスタマーポータルまたは Satellite 6 にオーバークラウドノードを登録します。

--reg-method

オーバークラウドノードに使用する登録方法。Red Hat Satellite 6 または Red Hat Satellite 5 は satellite、カスタマーポータルは portal

--reg-org [REG_ORG]

登録に使用する組織

--reg-force

すでに登録済みでもシステムを登録します。

--reg-sat-url [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 6 サーバーの場合は、オーバークラウドは katello-ca-consumer-latest.noarch.rpm ファイルを取得して subscription-manager に登録し、katello-agent をインストールします。Red Hat Satellite 5 サーバーの場合にはオーバークラウドは RHN-ORG-TRUSTED-SSL-CERT ファイルを取得して rhnreg_ks に登録します。

--reg-activation-key [REG_ACTIVATION_KEY]

登録に使用するアクティベーションキー

環境ファイルの parameter_defaults セクションに追加する Heat テンプレートのパラメーターの使用が優先されるため、一部のコマンドラインパラメーターは古いか非推奨となっています。以下の表では、非推奨となったパラメーターと、それに相当する Heat テンプレートのパラメーターを対照しています。

表6.3 非推奨の CLI パラメーターと Heat テンプレートのパラメーターの対照表

パラメーター説明Heat テンプレートのパラメーター

--control-scale

スケールアウトするコントローラーノード数

ControllerCount

--compute-scale

スケールアウトするコンピュートノード数

ComputeCount

--ceph-storage-scale

スケールアウトする Ceph Storage ノードの数

CephStorageCount

--block-storage-scale

スケールアウトする Cinder ノード数

BlockStorageCount

--swift-storage-scale

スケールアウトする Swift ノード数

ObjectStorageCount

--control-flavor

コントローラーノードに使用するフレーバー

OvercloudControllerFlavor

--compute-flavor

コンピュートノードに使用するフレーバー

OvercloudComputeFlavor

--ceph-storage-flavor

Ceph Storage ノードに使用するフレーバー

OvercloudCephStorageFlavor

--block-storage-flavor

Cinder ノードに使用するフレーバー

OvercloudBlockStorageFlavor

--swift-storage-flavor

Swift Storage ノードに使用するフレーバー

OvercloudSwiftStorageFlavor

--neutron-flat-networks

フラットなネットワークが neutron プラグインで設定されるように定義します。外部ネットワークを作成ができるようにデフォルトは「datacentre」に設定されています。

NeutronFlatNetworks

--neutron-physical-bridge

各ハイパーバイザーで作成する Open vSwitch ブリッジ。デフォルト値は「br-ex」で、通常この値は変更する必要はないはずです。

HypervisorNeutronPhysicalBridge

--neutron-bridge-mappings

使用する論理ブリッジから物理ブリッジへのマッピング。ホスト (br-ex) の外部ブリッジを物理名 (datacentre) にマッピングするようにデフォルト設定されています。これは、デフォルトの Floating ネットワークに使用されます。

NeutronBridgeMappings

--neutron-public-interface

ネットワークノード向けにインターフェースを br-ex にブリッジするインターフェースを定義します。

NeutronPublicInterface

--neutron-network-type

Neutron のテナントネットワーク種別

NeutronNetworkType

--neutron-tunnel-types

neutron テナントネットワークのトンネリング種別。複数の値を指定するには、コンマ区切りの文字列を使用します。

NeutronTunnelTypes

--neutron-tunnel-id-ranges

テナントネットワークを割り当てに使用できる GRE トンネリングの ID 範囲

NeutronTunnelIdRanges

--neutron-vni-ranges

テナントネットワークを割り当てに使用できる VXLAN VNI の ID 範囲

NeutronVniRanges

--neutron-network-vlan-ranges

サポートされる Neutron ML2 および Open vSwitch VLAN マッピングの範囲。デフォルトでは、物理ネットワーク「datacentre」上の VLAN を許可するように設定されています。

NeutronNetworkVLANRanges

--neutron-mechanism-drivers

neutron テナントネットワークのメカニズムドライバー。デフォルトでは、「openvswitch」に設定されており、複数の値を指定するにはコンマ区切りの文字列を使用します。

NeutronMechanismDrivers

--neutron-disable-tunneling

VLAN で区切られたネットワークまたは neutron でのフラットネットワークを使用するためにトンネリングを無効化します。

パラメーターのマッピングなし

--validation-errors-fatal

オーバークラウドの作成プロセスでは、デプロイメントの前に一連のチェックが行われます。このオプションは、デプロイメント前のチェックで何らかの致命的なエラーが発生した場合に終了します。どのようなエラーが発生してもデプロイメントが失敗するので、このオプションを使用することを推奨します。

パラメーターのマッピングなし

これらのパラメーターは、Red Hat OpenStack Platform の今後のリリースで削除される予定です。

注記

オプションの完全一覧については、以下のコマンドを実行します。

(undercloud) $ openstack help overcloud deploy

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

オーバークラウドをカスタマイズするには、-e を指定して、環境ファイルを追加します。必要に応じていくつでも環境ファイルを追加することができますが、後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順番は重要です。以下の一覧は、環境ファイルの順序の例です。

  • 各ロールおよびそのフレーバーごとのノード数。オーバークラウドを作成するには、この情報の追加は不可欠です。
  • コンテナー化された OpenStack サービスのコンテナーイメージの場所。このファイルは、「5章コンテナーレジストリー情報の設定」で説明したオプションのいずれかで作成されたものです。
  • 任意のネットワーク分離ファイル。Heat テンプレートコレクションの初期化ファイル (environments/network-isolation.yaml) から開始して、次にカスタムの NIC 設定ファイル、最後に追加のネットワーク設定の順番です。
  • 外部のロードバランシングの環境ファイル
  • Ceph Storage、NFS、iSCSI などのストレージ環境ファイル
  • Red Hat CDN または Satellite 登録用の環境ファイル
  • その他のカスタム環境ファイル

-e オプションを使用してオーバークラウドに追加した環境ファイルはいずれも、オーバークラウドのスタック定義の一部となります。以下のコマンドは、追加するカスタム環境ファイルを使用してオーバークラウドの作成を開始する方法の一例です。

(undercloud) $ openstack overcloud deploy --templates \
  -e /home/stack/templates/node-info.yaml\
  -e /home/stack/templates/overcloud_images.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
  -e /home/stack/templates/network-environment.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
  -e /home/stack/templates/ceph-custom-config.yaml \
  --ntp-server pool.ntp.org \

このコマンドでは、以下の追加オプションも使用できます。

--templates
/usr/share/openstack-tripleo-heat-templates の Heat テンプレートコレクションをベースとして使用し、オーバークラウドを作成します。
-e /home/stack/templates/node-info.yaml

各ロールに使用するノード数とフレーバーを定義する環境ファイルを追加します。以下に例を示します。

parameter_defaults:
  OvercloudControllerFlavor: control
  OvercloudComputeFlavor: compute
  OvercloudCephStorageFlavor: ceph-storage
  ControllerCount: 3
  ComputeCount: 3
  CephStorageCount: 3
-e /home/stack/templates/overcloud_images.yaml
コンテナーイメージのソースが含まれる環境ファイルを追加します。詳細は、「5章コンテナーレジストリー情報の設定」を参照してください。
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml
オーバークラウドデプロイメントのネットワーク分離を初期化する環境ファイルを追加します。
-e /home/stack/templates/network-environment.yaml
ネットワーク分離をカスタマイズする環境ファイルを追加します。
-e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml
Ceph Storage サービスを有効化するための環境ファイルを追加します。
-e /home/stack/templates/ceph-custom-config.yaml
Ceph Storage の設定をカスタマイズするための環境ファイルを追加します。
--ntp-server pool.ntp.org
時刻の同期に NTP サーバーを使用します。コントローラーノードクラスターの同期を保つには、このオプションが必要です。

director は、「9章オーバークラウド作成後のタスクの実行」に記載の再デプロイおよびデプロイ後の機能にこれらの環境ファイルを必要とします。これらのファイルが含まれていない場合には、オーバークラウドが破損する可能性があります。

オーバークラウド設定を後で変更する予定の場合には、以下の作業を行う必要があります。

  1. カスタムの環境ファイルおよび Heat テンプレートのパラメーターを変更します。
  2. 同じ環境ファイルを指定してopenstack overcloud deploy コマンドを再度実行します。

オーバークラウドを手動で編集しても、director を使用してオーバークラウドスタックの更新を行う際に director の設定で上書きされてしまうので、設定は直接編集しないでください。

環境ファイルディレクトリーの追加

--environment-directory オプションを使用して、環境ファイルを格納しているディレクトリー全体を追加することも可能です。デプロイメントコマンドにより、このディレクトリー内の環境ファイルは、最初に番号順、その後にアルファベット順で処理されます。この方法を使用する場合には、ファイル名に数字のプレフィックスを使用することを推奨します。以下に例を示します。

(undercloud) $ ls -1 ~/templates
00-node-info.yaml
10-network-isolation.yaml
20-network-environment.yaml
30-storage-environment.yaml
40-rhel-registration.yaml

以下のデプロイメントコマンドを実行してディレクトリーを追加します。

(undercloud) $ openstack overcloud deploy --templates --environment-directory ~/templates

回答ファイルの使用

回答ファイルは、テンプレートおよび環境ファイルの追加を簡素化する YAML ファイルです。回答ファイルでは、以下のパラメーターを使用します。

テンプレート
使用するコア Heat テンプレートコレクション。これは、--templates のコマンドラインオプションの代わりとして機能します。
環境
追加する環境ファイルの一覧。これは、--environment-file (-e) のコマンドラインオプションの代わりとして機能します。

たとえば、回答ファイルには以下の内容を含めることができます。

templates: /usr/share/openstack-tripleo-heat-templates/
environments:
  - ~/templates/00-node-info.yaml
  - ~/templates/10-network-isolation.yaml
  - ~/templates/20-network-environment.yaml
  - ~/templates/30-storage-environment.yaml
  - ~/templates/40-rhel-registration.yaml

以下のデプロイメントコマンドを実行して回答ファイルを追加します。

(undercloud) $ openstack overcloud deploy --answers-file ~/answers.yaml

6.9. オーバークラウドプランの管理

openstack overcloud deploy コマンドを使用する代わりに、director を使用してインポートしたプランを管理することもできます。

新規プランを作成するには、以下のコマンドを stack ユーザーとして実行します。

(undercloud) $ openstack overcloud plan create --templates /usr/share/openstack-tripleo-heat-templates my-overcloud

このコマンドは、/usr/share/openstack-tripleo-heat-templates 内のコア Heat テンプレートコレクションからプランを作成します。director は、入力内容に基づいてプランに名前を指定します。この例では、my-overcloud という名前です。director は、この名前をオブジェクトストレージコンテナー、ワークフロー環境、オーバークラウドスタック名のラベルとして使用します。

以下のコマンドを使用して環境ファイルからパラメーターを追加します。

(undercloud) $ openstack overcloud parameters set my-overcloud ~/templates/my-environment.yaml

以下のコマンドを使用してプランをデプロイします。

(undercloud) $ openstack overcloud plan deploy my-overcloud

以下のコマンドを使用して既存のプランを削除します。

(undercloud) $ openstack overcloud plan delete my-overcloud
注記

openstack overcloud deploy コマンドは基本的に、これらのコマンドをすべて使用して既存のプランの削除、環境ファイルを使用した新規プランのアップロード、プランのデプロイを行います。

6.10. オーバークラウドのテンプレートおよびプランの検証

オーバークラウドの作成またはスタックの更新を実行する前に、Heat テンプレートと環境ファイルにエラーがないかどうかを検証します。

レンダリングされたテンプレートの作成

オーバークラウドのコア Heat テンプレートは、Jinja2 形式となっています。テンプレートを検証するには、以下のコマンドを使用して Jinja 2 のフォーマットなしでバージョンをレンダリングします。

(undercloud) $ openstack overcloud plan create --templates /usr/share/openstack-tripleo-heat-templates overcloud-validation
(undercloud) $ mkdir ~/overcloud-validation
(undercloud) $ cd ~/overcloud-validation
(undercloud) $ swift download overcloud-validation

その後の検証テストには ~/overcloud-validation のレンダリング済みテンプレートを使用します。

テンプレート構文の検証

以下のコマンドを使用して、テンプレート構文を検証します。

(undercloud) $ openstack orchestration template validate --show-nested --template ~/overcloud-validation/overcloud.yaml -e ~/overcloud-validation/overcloud-resource-registry-puppet.yaml -e [ENVIRONMENT FILE] -e [ENVIRONMENT FILE]
注記

検証には、overcloud-resource-registry-puppet.yaml の環境ファイルにオーバークラウド固有のリソースを含める必要があります。環境ファイルをさらに追加するには、このコマンドに -e オプションを使用してください。また、--show-nested オプションを追加して、ネストされたテンプレートからパラメーターを解決します。

このコマンドは、テンプレート内の構文エラーを特定します。テンプレートの構文の検証が正常に行われた場合には、出力には、作成されるオーバークラウドのテンプレートのプレビューが表示されます。

6.11. オーバークラウド作成の監視

オーバークラウドの作成プロセスが開始され、director によりノードがプロビジョニングされます。このプロセスは完了するまで多少時間がかかります。オーバークラウドの作成のステータスを確認するには、stack ユーザーとして別のターミナルを開き、以下のコマンドを実行します。

(undercloud) $ source ~/stackrc
(undercloud) $ openstack stack list --nested

openstack stack list --nested コマンドは、オーバークラウド作成の現在の段階を表示します。

6.12. オーバークラウドへのアクセス

director は、director ホストからオーバークラウドに対話するための設定を行い、認証をサポートするスクリプトを作成して、stack ユーザーのホームディレクトリーにこのファイル (overcloudrc) を保存します。このファイルを使用するには、以下のコマンドを実行します。

(undercloud) $ source ~/overcloudrc

これで、director のホストの CLI からオーバークラウドと対話するために必要な環境変数が読み込まれます。コマンドプロンプトが変わり、オーバークラウドと対話していることが示されます。

(overcloud) $

director のホストとの対話に戻るには、以下のコマンドを実行します。

(overcloud) $ source ~/stackrc
(undercloud) $

オーバークラウドの各ノードには、heat-admin と呼ばれるユーザーが含まれます。stack ユーザーには、各ノードに存在するこのユーザーに SSH 経由でアクセスすることができます。SSH でノードにアクセスするには、希望のノードの IP アドレスを特定します。

(undercloud) $ openstack server list

次に、heat-admin ユーザーとノードの IP アドレスを使用して、ノードに接続します。

(undercloud) $ ssh heat-admin@192.168.24.23

6.13. オーバークラウド作成の完了

これで、コマンドラインツールを使用したオーバークラウドの作成が完了しました。作成後の機能については、「9章オーバークラウド作成後のタスクの実行」を参照してください。


このページには機械翻訳が使用されている場合があります (詳細はこちら)。