Language:
Format:

第6章オーバークラウドのインストール

Red Hat Enterprise Linux OpenStack Platform director を設定して、アンダークラウドのインストールが完了しました。本章では、director を使用してオーバークラウドの環境を作成します。ユーザーのレベルに対応するように、オーバークラウド作成手順は、2 種のインストールシナリオに分けています。シナリオごとに、複雑度と記載内容が異なります。

表6.1 シナリオの概要

シナリオ	レベル	トピック
基本オーバークラウド	中	CLI ツールの使用、ノードの登録、手動でのノードのタグ付け、基本的なネットワークの分離、プランベースのオーバークラウドの作成
高度なオーバークラウド	高	CLI ツールの使用、ノードの登録、ハードウェアをベースにしたノードの自動タグ付け、Ceph Storage の設定、高度なネットの分離、オーバークラウドの作成、高可用性のフェンシング設定

6.1. 基本シナリオ: NFS ストレージを使用する小規模なオーバークラウドの作成

このシナリオでは、小規模なエンタープライズレベルの OpenStack Platform 環境を構築します。この環境は、オーバークラウド内の 2 つのノード (コントローラーノード 1 つとコンピュートノード 1 つ) で構成されます。いずれのマシンも、電源管理に IPMI を使用するベアメタルシステムです。このシナリオは、コマンドラインツールに焦点をあて、コンピュートノードを後でスケーリングすることが可能な小規模な実稼動レベルの Red Hat Enterprise Linux OpenStack Platform 環境を構築する director の機能について実例をあげて説明することを目的としています。

ワークフロー

ノード定義のテンプレートを作成して director で空のノードを登録します。
全ノードのハードウェアを検証します。
手動でロールにノードをタグ付けします。
フレーバーを作成してロールにタグ付けします。
Heat テンプレートを作成して外部ネットワークを分離します。
デフォルトの Heat テンプレートコレクションと追加のネットワーク分離テンプレートを使用してオーバークラウド環境を作成します。

要件

「3章アンダークラウドのインストール」で作成した director ノード
ベアメタルマシン 2 台。これらのマシンは、コントローラーノードおよびコンピュートノードに設定された要件に準拠する必要があります。要件については以下を参照してください。
- 「コントローラーノードの要件」
- 「コンピュートノードの要件」
director により Red Hat Enterprise Linux 7 のイメージが各ノードにコピーされるため、これらのノードではオペレーティングシステムは必要ありません。

ネイティブ VLAN として設定したプロビジョニングネットワーク用のネットワーク接続 1 つ。全ノードは、このネイティブに接続して、「ネットワーク要件」で設定した要件に準拠する必要があります。この例では、以下の IP アドレスの割り当てで、プロビジョニングサブネットとして 192.0.2.0/24 を使用します。

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

ノード名	IP アドレス	MAC アドレス	IPMI IP アドレス
director	192.0.2.1	aa:aa:aa:aa:aa:aa
コントローラー	定義済みの DHCP	bb:bb:bb:bb:bb:bb	192.0.2.205
コンピュート	定義済みの DHCP	cc:cc:cc:cc:cc:cc	192.0.2.206

外部ネットワークのネットワーク接続 1 つ。コントローラーノードはすべて、このネットワークに接続する必要があります。今回の例では、外部ネットワークには 10.1.1.0/24 を使用します。
その他のネットワーク種別はすべて、OpenStack サービスにプロビジョニングネットワークを使用します。
このシナリオでは、プロビジョニングネットワーク上の別のサーバーで NFS 共有も使用します。このサーバーの IP アドレスは 192.0.2.230 です。

6.1.1. 基本オーバークラウドへのノードの登録

本項では、ノード定義のテンプレートを作成します。このファイル (instackenv.json) は JSON ファイル形式で、2 つのノードのハードウェアおよび電源管理の詳細が含まれます。

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

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":[
                "bb:bb:bb:bb:bb:bb"
            ],
            "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":[
                "cc:cc:cc:cc:cc:cc"
            ],
            "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"
        }
    ]
}

注記

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

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

$ openstack baremetal import --json ~/instackenv.json

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

カーネルと ramdisk イメージを全ノードに割り当てます。

$ openstack baremetal configure boot

director でのノードの登録および設定が完了しました。以下のコマンドを使用して、CLI でこれらのノードの一覧を表示します。

$ openstack baremetal list

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

ノードの登録後には、各ノードのハードウェア属性を検証します。各ノードのハードウェア属性を検証するには、以下のコマンドを実行します。

$ openstack baremetal introspection bulk start

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

$ sudo journalctl -l -u openstack-ironic-discoverd -u openstack-ironic-discoverd-dnsmasq -u openstack-ironic-conductor -f

重要

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

または、各ノードに 1 回ずつ個別にイントロスペクションを実行します。ノードをメンテナンスモードに切り替えて、イントロスペクションを実行してから、メンテナンスモードから元に戻します

$ ironic node-set-maintenance [NODE UUID] true
$ openstack baremetal introspection start [NODE UUID]
$ ironic node-set-maintenance [NODE UUID] false

6.1.3. ノードの手動でのタグ付け

各ノードのハードウェアを登録して検証した後には、個別のプロファイルにタグ付けします。これらのプロファイルタグは、ノードからフレーバーに対して照合され、そのフレーバーはデプロイメントロールに割り当てられます。基本デプロイメントのシナリオでは、ノードが 2 つしかないため、手動でタグ付けします。ノード数が多い場合は、高度なデプロイメントのシナリオにある Automated Health Check (AHC) ツールを使用します。Automated Health Check (AHC) ツールに関する詳細は、「Automated Health Check (AHC) ツールを使用したノードの自動タグ付け」を参照してください。

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

$ ironic node-update 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13 add properties/capabilities='profile:compute,boot_option:local'
$ ironic node-update 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 add properties/capabilities='profile:control,boot_option:local'

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

またこのコマンドは、各ノードのブードモードを定義する boot_option:local パラメーターを設定します。

重要

director は現在、UEFI ブートモードはサポートしていません。

6.1.4. 基本シナリオのフレーバーの作成

director には、登録ノードのハードウェアプロファイルまたはフレーバーのセットが必要です。このシナリオでは、コンピュートノードとコントローラーノードごとにプロファイルを作成します。

$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 control
$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 compute

これにより、ノードに 2 つのフレーバー (control と compute) が作成されました。また、各フレーバーに追加のプロパティーを設定します。

$ 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

capabilities:boot_option はフレーバーのブートモードを設定し、capabilities:profile は使用するプロファイルを定義します。これにより、「ノードの手動でのタグ付け」でタグ付けされた対象の各ノード上にある同じタグにリンクされます。

重要

使用していないロールにも baremetal というデフォルトのフレーバーが必要です。このフレーバーがない場合には作成します。

$ openstack flavor create --id auto --ram 4096 --disk 40 --vcpus 1 baremetal

6.1.5. NFS ストレージの設定

本項では、NFS 共有を使用するオーバークラウドの設定について説明します。インストールおよび設定のプロセスは、Heat テンプレートコレクション内の既存の環境ファイルの変更がベースとなります。

Heat テンプレートコレクションの /usr/share/openstack-tripleo-heat-templates/environments/ には一連の環境ファイルが格納されています。これらは、director で作成したオーバークラウドでサポートされている一部の機能のカスタム設定に役立つ環境テンプレートです。これには、ストレージ設定に有用な環境ファイルが含まれます。このファイルは、/usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml に配置されています。このファイルを stack ユーザーのテンプレートディレクトリーにコピーしてください。

$ cp /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml ~/templates/.

この環境ファイルには、OpenStack のブロックストレージおよびイメージストレージのコンポーネントの異なるストレージオプションを設定するのに役立つ複数のパラメーターが記載されています。この例では、オーバークラウドが NFS 共有を使用するように設定します。以下のパラメーターを変更してください。

CinderEnableIscsiBackend: iSCSI バックエンドを有効にするパラメーター。false に設定してください。
CinderEnableRbdBackend: Ceph Storage バックエンドを有効にするパラメーター。false に設定してください。
CinderEnableNfsBackend: NFS バックエンドを有効にするパラメーター。true に設定してください。
NovaEnableRbdBackend: Nova エフェメラルストレージ用に Ceph Storage を有効にするパラメーター。false に設定します。
GlanceBackend: Glance に使用するバックエンドを定義するパラメーター。イメージ用にファイルベースストレージを使用するには file に設定してください。オーバークラウドは、Glance 用にマウントされた NFS 共有にこれらのファイルを保存します。
CinderNfsMountOptions: ボリュームストレージ用の NFS マウントオプション
CinderNfsServers: ボリュームストレージ用にマウントする NFS 共有 (例: 192.168.122.1:/export/cinder)
GlanceFilePcmkManage: イメージストレージ用の共有を管理するための Pacemaker を有効にするパラメーター。無効に設定されている場合には、オーバークラウドはコントローラーノードのファイルシステムにイメージを保管します。true に設定してください。
GlanceFilePcmkFstype: Pacemaker がイメージストレージ用に使用するファイルシステムの種別を定義するパラメーター。nfs に設定します。
GlanceFilePcmkDevice: イメージストレージをマウントするための NFS 共有 (例: 192.168.122.1:/export/glance)
GlanceFilePcmkOptions: イメージストレージ用の NFS マウントオプション

環境ファイルのオプションは、以下の例のようになるはずです。

parameters:
  CinderEnableIscsiBackend: false
  CinderEnableRbdBackend: false
  CinderEnableNfsBackend: true
  NovaEnableRbdBackend: false
  GlanceBackend: 'file'

  CinderNfsMountOptions: 'rw,sync'
  CinderNfsServers: '192.0.2.230:/cinder'

  GlanceFilePcmkManage: true
  GlanceFilePcmkFstype: 'nfs'
  GlanceFilePcmkDevice: '192.0.2.230:/glance'
  GlanceFilePcmkOptions: 'rw,sync,context=system_u:object_r:glance_var_lib_t:s0'

重要

Glance が /var/lib ディレクトリーにアクセスできるようにするには、GlanceFilePcmkOptions パラメーターに context=system_u:object_r:glance_var_lib_t:s0 と記載します。この SELinux コンテキストがない場合には、Glance はマウントポイントへの書き込みに失敗することになります。

これらのパラメーターは、Heat テンプレートコレクションの一部として統合されます。このように設定することにより、Cinder と Glance が使用するための 2 つの NFS マウントポイントが作成されます。

このファイルを保存して、オーバークラウドの作成に含まれるようにします。

6.1.6. 外部ネットワークの分離

director は、分離したオーバークラウドネットワークを設定する方法を提供します。つまり、オーバークラウド環境はネットワークトラフィック種別を異なるネットワークに分離して、個別のネットワークインターフェースまたはボンディングにネットワークトラフィックを割り当てます。分離ネットワークワークを設定した後に、director は OpenStack サービスが分離ネットワークを使用するように設定します。分離ネットワークが設定されていない場合には、サービスはすべて、プロビジョニングネットワーク上で実行されます。

このシナリオでは、2 つの分離ネットワークを使用します。

ネットワーク 1: プロビジョニングネットワーク。内部 API、ストレージ、ストレージ管理、テナントネットワークもこのネットワークを使用します。
ネットワーク 2: 外部ネットワーク。このネットワークは、オーバークラウドの外部に接続する専用インターフェースを使用します。

以下の項では、Heat テンプレートを作成して残りのサービスから外部ネットワークを分離する方法を説明します。その他のネットワーク設定例は、「付録F ネットワークインターフェースのテンプレート例」を参照してください。

6.1.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 の設定サンプルを使用します。デフォルトの設定ディレクトリーを nic-configs として、stack ユーザーのホームディレクトリーにコピーします。

$ cp -r /usr/share/openstack-tripleo-heat-templates/network/config/single-nic-vlans ~/templates/nic-configs

このコマンドによりローカルの Heat テンプレートが作成され、このテンプレートで外部ネットワークが使用する単一ネットワークインターフェース設定を定義します。各テンプレートには、標準の parameters、resources、output が含まれます。今回のシナリオでは、resources セクションのみを編集します。各 resources セクションは、以下のように開始されます。

resources:
  OsNetConfigImpl:
    type: OS::Heat::StructuredConfig
    properties:
      group: os-apply-config
      config:
        os_net_config:
          network_config:

このコマンドでは、os-apply-config コマンドと os-net-config サブコマンドがノードのネットワークプロパティーを設定するように要求が作成されます。network_config セクションには、種別順に並べられたカスタムのインターフェース設定が含まれます。これらの種別には以下が含まれます。

interface

単一のネットワークインターフェースを定義します。この設定では、実際のインターフェース名 (eth0、eth1、enp0s25) または番号付きのインターフェース (nic1、nic2、nic3) を使用して各インターフェースを定義します。

            - type: interface
              name: nic2

vlan

VLAN を定義します。parameters セクションから渡された VLAN ID およびサブネットを使用します。

            - type: vlan
              vlan_id: {get_param: ExternalNetworkVlanID}
              addresses:
                - ip_netmask: {get_param: ExternalIpSubnet}

ovs_bond

Open vSwitch のボンディングを定義します。ボンディングでは、2 つ以上の interfaces を結合して、冗長性や帯域幅を向上させます。

            - type: ovs_bond
              name: bond1
              members:
              - type: interface
                name: nic2
              - type: interface
                name: nic3

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}

各アイテムの完全なパラメーター一覧については「付録E ネットワークインターフェースのパラメーター」を参照してください。

基本シナリオでは、外部ネットワークを nic2 に移動するように、各インターフェーステンプレートを変更します。これにより、各ノードの 2 番目のネットワークインターフェースが外部ネットワークに使用されるようになります。たとえば、templates/nic-configs/controller.yaml のテンプレートは以下のようになります。

          network_config:
            - type: ovs_bridge
              name: {get_input: bridge_name}
              use_dhcp: true
              members:
                - type: interface
                  name: nic1
                  # force the MAC address of the bridge to this interface
                  primary: true
                - type: vlan
                  vlan_id: {get_param: InternalApiNetworkVlanID}
                  addresses:
                    - ip_netmask: {get_param: InternalApiIpSubnet}
                - type: vlan
                  vlan_id: {get_param: StorageNetworkVlanID}
                  addresses:
                    - ip_netmask: {get_param: StorageIpSubnet}
                - type: vlan
                  vlan_id: {get_param: StorageMgmtNetworkVlanID}
                  addresses:
                    - ip_netmask: {get_param: StorageMgmtIpSubnet}
                - type: vlan
                  vlan_id: {get_param: TenantNetworkVlanID}
                  addresses:
                    - ip_netmask: {get_param: TenantIpSubnet}
            - type: interface
              name: nic2
              addresses:
                - ip_netmask: {get_param: ExternalIpSubnet}
              routes:
                - ip_netmask: 0.0.0.0/0
                  next_hop: {get_param: ExternalInterfaceDefaultRoute}

上記の例においては、新規インターフェース (nic2) を作成して外部ネットワークアドレスを再割り当てし、新規インターフェースにルーティングします。

ネットワークインターフェーステンプレートの他のサンプルについては「付録F ネットワークインターフェースのテンプレート例」を参照してください。

これらのパラメーターの多くは get_param 関数を使用する点に注意してください。これらのパラメーターは、使用するネットワーク専用に作成した環境ファイルで定義します。

重要

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

- type: interface
  name: nic4
  use_dhcp: false
  defroute: false

6.1.6.2. 基本オーバークラウドのネットワーク環境のテンプレート

ネットワーク環境ファイルでは、オーバークラウドのネットワーク環境を記述し、前のセクションのネットワークインターフェース設定ファイルを参照します。IP アドレス範囲と合わせてネットワークのサブネットを定義します。また、これらの値をローカルの環境用にカスタマイズします。

このシナリオでは、/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:
  ExternalNetCidr: 10.1.1.0/24
  ExternalAllocationPools: [{'start': '10.1.1.2', 'end': '10.1.1.50'}]
  ExternalNetworkVlanID: 100
  # 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"]
  # Set to "br-ex" if using floating IPs on native VLAN on bridge br-ex
  NeutronExternalNetworkBridge: "''"

resource_registry セクションには、各ノードロールのネットワークインターフェーステンプレートへのリンクが含まれます。ExternalAllocationPools パラメーターは狭い範囲の IP アドレスしか定義しません。これは、別の範囲の IP アドレスを後ほど定義できるようにするためです。

parameter_defaults セクションには、各ネットワーク種別のネットワークオプションを定義するパラメーター一覧が含まれます。これらのオプションについての詳しい参考情報は「付録G ネットワーク環境のオプション」を参照してください。

外部ネットワークは、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 に配置し、作成後にオーバークラウドを設定してそのネットワークを使用するようにします。

このセクションは、外部ネットワークのオプションを定義するだけです。その他のトラフィック種別は、プロビジョニングネットワークに自動的に割り当てられます。

重要

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

6.1.7. 基本オーバークラウドの作成

OpenStack 環境の最後の段階として、環境作成に必要とされるコマンドを実行します。デフォルトプランでは、コントローラーノードとコンピュートノードが 1 つずつインストールされます。

注記

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 /home/stack/templates/network-environment.yaml -e /home/stack/templates/storage-environment.yaml --control-flavor control --compute-flavor compute --ntp-server pool.ntp.org --neutron-network-type vxlan --neutron-tunnel-types vxlan

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

--templates: /usr/share/openstack-tripleo-heat-templates にある Heat テンプレートコレクションを使用してオーバークラウドを作成します。
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml: -e オプションはオーバークラウドプランに別の環境ファイルを追加します。この場合、これはネットワーク分離の設定を初期化する環境ファイルです。
-e /home/stack/templates/network-environment.yaml: -e オプションはオーバークラウドプランに別の環境ファイルを追加します。この場合は「基本オーバークラウドのネットワーク環境のテンプレート」で作成したネットワーク環境ファイルです。
-e /home/stack/templates/storage-environment.yaml: -e のオプションにより、オーバークラウドプランに環境ファイルが追加されます。上記の例では、「NFS ストレージの設定」で作成したストレージの環境ファイルを指定しています。
--control-flavor control: 対象のコントローラーノードに特定のフレーバーを使用します。
--compute-flavor compute: 対象のコンピュートノードに特定のフレーバーを使用します。
--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

パラメーターの例は「付録I デプロイメントパラメーター」も参照してください。

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

$ source ~/stackrc                # Initializes the stack user to use the CLI commands
$ heat stack-list --show-nested

heat stack-list --show-nested コマンドは、オーバークラウド作成の現在のステージを表示します。

警告

-e オプションを使用してオーバークラウドに追加した環境ファイルはいずれも、オーバークラウドのスタック定義の一部となります。director は、「7章オーバークラウド作成後のタスクの実行」に記載の再デプロイおよびデプロイ後の機能にこれらの環境ファイルを必要とします。これらのファイルが含まれていない場合には、オーバークラウドが破損することになる場合があります。

オーバークラウドの設定を後で変更する予定がある場合は、カスタム環境ファイルと Heat テンプレートのパラメーターを変更し、openstack overcloud deploy のコマンドを再度実行します。オーバークラウドを手動で編集しても、director を使用してオーバークラウドスタックの更新を行う際に director の設定で上書きされてしまうので、設定は直接編集しないでください。

警告

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

6.1.8. 基本オーバークラウドへのアクセス

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

$ source ~/overcloudrc

これにより、director ホストの CLI からオーバークラウドと対話するために必要な環境変数が読み込まれます。director ホストとの対話に戻るには、以下のコマンドを実行します。

$ source ~/stackrc

6.1.9. 基本オーバークラウドの完了

これで基本オーバークラウドの作成が完了しました。作成後の機能については、「7章オーバークラウド作成後のタスクの実行」を参照してください。

Select Your Language

第6章オーバークラウドのインストール

6.1. 基本シナリオ: NFS ストレージを使用する小規模なオーバークラウドの作成

6.1.1. 基本オーバークラウドへのノードの登録

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

6.1.3. ノードの手動でのタグ付け

6.1.4. 基本シナリオのフレーバーの作成

6.1.5. NFS ストレージの設定

6.1.6. 外部ネットワークの分離

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

6.1.6.2. 基本オーバークラウドのネットワーク環境のテンプレート

6.1.7. 基本オーバークラウドの作成

6.1.8. 基本オーバークラウドへのアクセス

6.1.9. 基本オーバークラウドの完了

Quick Links

Help

Site Info

Related Sites

About

Red Hat legal and privacy links

Red Hat legal and privacy links

Language and Page Formatting Options

第6章 オーバークラウドのインストール

6.1. 基本シナリオ: NFS ストレージを使用する小規模なオーバークラウドの作成

6.1.1. 基本オーバークラウドへのノードの登録

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

6.1.3. ノードの手動でのタグ付け

6.1.4. 基本シナリオのフレーバーの作成

6.1.5. NFS ストレージの設定

6.1.6. 外部ネットワークの分離

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

6.1.6.2. 基本オーバークラウドのネットワーク環境のテンプレート

6.1.7. 基本オーバークラウドの作成

6.1.8. 基本オーバークラウドへのアクセス

6.1.9. 基本オーバークラウドの完了

Quick Links

Help

Site Info

Related Sites

Systems Status

About

Red Hat legal and privacy links

Red Hat legal and privacy links

第6章オーバークラウドのインストール