Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

第 5 章 使用 CLI 工具配置基本的 overcloud 要求

本章介绍使用 CLI 工具配置 OpenStack Platform 环境的基本步骤。overcloud 基本配置中不含任何自定义功能。但是,您可以参考 overcloud 高级自定义指南中的说明,添加高级配置选项到这一基本 overcloud 中,并按照您的具体规格进行自定义。

在本章使用的示例中,所有节点都是使用 IPMI 作为电源管理的裸机。如需了解关于其它支持的电源管理类型和它们的选项,请参阅 附录 B, 电源管理驱动

流程

  1. 在 director 中创建一个节点定义模板并注册空白节点。
  2. 检查所有节点的硬件。
  3. 为节点添加标签(tag)来标记为角色。
  4. 定义额外的节点属性

配置要求

  • ??? 中创建的 director 节点
  • 一组作为节点的裸机。所需的节点数量由您需要创建的 overcloud 类型所决定(请参阅 第 3.1 节 “规划节点的实施角色”)。这些机器需要满足每个节点类型对系统的要求。相关信息,请参阅 ???。这些节点不需要操作系统,director 会把一个 Red Hat Enterprise Linux 7 镜像复制到每个节点。
  • Provisioning 网络的一个网络连接(被配置为一个原生 VLAM)。所有节点必须都连接到这个网络,并需要满足 第 2.3 节 “网络要求” 中的要求。在本章的示例中,我们使用 192.168.24.0/24 作为 Provisioning 子网,分配的 IP 地址信息如下:

    表 5.1. Provisioning 网络 IP 分配信息

    节点名

    IP 地址

    MAC 地址

    IPMI IP 地址

    Director

    192.168.24.1

    aa:aa:aa:aa:aa:aa

    不需要

    Controller

    DHCP

    bb:bb:bb:bb:bb:bb

    192.168.24.205

    Compute

    DHCP

    cc:cc:cc:cc:cc:cc

    192.168.24.206

  • 所有其他网络类型使用 Provisioning 网络来提供 OpenStack 服务。不过,您可以为其他网络流量类型创建额外的网络。

5.1. 为 overcloud 注册节点

director 需要一个节点定义模板,您可以手动创建该模板。这个文件(instackenv.json)是一个 JSON 格式的文件,它包括了节点的详细硬件和电源管理信息。例如,注册两个节点的模板会和以下类似:

{
    "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.168.24.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.168.24.206"
        }
    ]
}

这个模板使用以下属性:

pm_type
使用的电源管理驱动。在这个示例中使用 IPMI 驱动(pxe_ipmitool)。
pm_user; pm_password
IPMI 的用户名和密码。
pm_addr
IPMI 设备的 IP 地址。
mac
(可选)节点上网络接口的 MAC 地址列表。对于每个系统的 Provisioning NIC,只使用 MAC 地址。
cpu
节点上的 CPU 数量。(可选)
memory
以 MB 为单位的内存大小。(可选)
disk
以 GB 为单位的硬盘的大小。(可选)
arch
系统架构。(可选)
注意

如需了解更多与所支持的电源管理类型和选项相关的信息,请参阅 附录 B, 电源管理驱动

在创建完模板后,把这个文件保存到 stack 用户的家目录(/home/stack/instackenv.json),然后把它导入到 director。使用以下命令:

$ openstack overcloud node import ~/instackenv.json

这会导入模板,并把模板中的每个节点注册到 director。

完成节点注册和配置之后,在 CLI 中查看这些节点的列表:

$ openstack baremetal node list

5.2. 检查节点硬件

director 可以在每个节点上运行内省进程。这个进程会使每个节点通过 PXE 引导一个内省代理。这个代理从节点上收集硬件数据,并把信息发送回 director,director 把这些信息保存在运行于 director 上的 OpenStack Object Storage (swift) 服务中。director 使用硬件信息用于不同目的,如进行 profile tagging、benchmarking、手工引导磁盘分配等。

注意

您也可以创建策略文件来在进行内省后自动把节点标记为(tag)配置集(profile)。如需了解更多与创建策略文件并把它们包括在内省过程中的信息,请参阅 附录 D, 自动配置集标记。获得,参阅 第 5.3 节 “为节点添加标签(tag)来标记为配置集” 中的内容把节点手工标记为配置集。

运行以下命令检查每个节点的属性:

$ openstack overcloud node introspect --all-manageable --provide
  • --all-manageable 选项仅内省处于受管理状态的节点。本例中为所有节点。
  • --provide 选项将所有节点在内省后重置为 active 状态。

在一个单独的终端窗口中运行以下命令来监测内省的进程:

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

确保这个过程成功完成。它可能需要 15 分钟来检查这些裸机节点。

内省完成后,所有节点变更为 active 状态。

执行单个节点内省

要在 active 节点上执行一个内省操作,请将节点设置为管理模式,然后执行内省操作:

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

内省完成后,节点变更为 active 状态。

在初始内省后执行节点内省操作

因为 --provide 选项的原因,所有节点在初始内省后都应进入 active 状态。要在初始内省后对所有节点执行内省操作,请将所有节点设置为 manageable 状态,然后运行批量内省命令

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

内省完成后,所有节点变更为 active 状态。

5.3. 为节点添加标签(tag)来标记为配置集

在注册并检查完每个节点的硬件后,需要为它们添加标签,加入特定的配置文件。这些配置文件标签会把节点和类型(flavor)相匹配,从而使类型分配到部署角色。下方的示例显示了 Controller 节点的角色、类型、配置文件和节点之间的关系:

类型描述

角色

Controller 角色定义了配置控制器节点的方式。

类型

control 类型定义了用作控制器的节点的硬件配置文件。将此类型分配给 Controller 角色,以便 director 能够决定使用哪些节点。

配置集

control 配置集是应用至 control 类型的标签。它定义了属于该类型的节点。

节点

您也对单个节点应用 control 配置集标签,这样会将这些节点分组至 control 类型,因此,director 会使用 Controller 角色来配置它们。

默认的配置文件类型 computecontrolswift-storageceph-storageblock-storage 会在 undercloud 的安装过程中创建,多数环境中可不经修改直接使用。

注意

如果有大量的节点,可以使用自动为配置集添加标签的功能。相关信息,请参阅 附录 D, 自动配置集标记

为了通过添加标签把节点标记为特定的配置集,把 profile 选项添加到每个节点的 properties/capabilities 参数中。例如,把环境中的两个节点分别标记为使用 controller 配置集和 compute 配置集,使用以下命令:

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

其中的 profile:computeprofile:control 选项会把节点标记为相关的配置集。

这些命令同时也设置了 boot_option:local 参数,它定义了每个节点的引导模式。

在标记完节点后,检查分配的配置集或可能的配置集:

$ openstack overcloud profiles list

自定义角色配置集

如果使用自定义角色,您可能需要额外创建类别和配置文件,以便容纳这些新角色。例如,运行以下命令,为 Networker 角色创建新类别:

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

分配采用这种新配置集的节点:

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

5.4. 为节点定义 Root Disk

一些节点可能会使用多个磁盘。这意味着,director 需要可以区分在 provisioning 时作为 root 磁盘使用的磁盘。以下的几个属性可以被用来帮助 director 区分 root 磁盘:

  • model(字符串):设备 ID。
  • vendor(字符串):设备厂商。
  • serial(字符串):磁盘序列号。
  • wwn(字符串):唯一的存储 ID。
  • hctl(字符串):SCSI 的 Host:Channel:Target:Lun。
  • size(整数):设备的大小(以 GB 为单位)。

在本例中,使用磁盘的序列号指定根设备来部署 overcloud 镜像。

通过对每个节点的硬盘执行内省,检查磁盘信息。以下命令显示了一个节点的磁盘信息:

$ openstack baremetal introspection data save 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 | jq ".inventory.disks"

例如,一个节点的数据可能会显示 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"
  }
]

在本例中,把根设备设置成磁盘 2(序列号为 61866da04f380d001ea4e13c12e36ad6)。这需要在节点定义中修改 root_device 参数:

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

这将帮助 director 识别特定的磁盘来用作根设备。当开始创建 overcloud 时,director 会部署这一节点,把 overcloud 镜像写入到这个磁盘。

注意

把每个节点的 BIOS 配置为包括从所选 root 磁盘引导。推荐的引导顺序是:网络引导,然后是 root 磁盘引导。

重要

不要使用 name 来指定 root 磁盘,因为这个值可能会在节点引导后改变。

5.5. 自定义 overcloud

undercloud 包含一组 Heat 模板,可充当 overcloud 的创建计划。您可以参照 overcloud 高级自定义指南,自定义 overcloud 的高级功能。

或者,您可以继续操作并部署基本的 overcloud。如需更多信息,请参阅???

重要

基本 overcloud 将本地 LVM 存储用作块存储,这不是受支持的配置。建议您使用外部存储解决方案来设置块存储。

5.6. 使用 CLI 工具创建 overcloud

创建 OpenStack 环境的最后一个环节是运行 openstack overcloud deploy 命令进行创建。在运行此命令前,您应当已经熟悉关键的选项,以及如何加入自定义环境文件。以下小节探讨 openstack overcloud deploy 命令以及与它相关的选项。

警告

不要以后台进程的形式运行 openstack overcloud deploy,因为这可能会造成在 overcloud 的创建过程中出现进程无法继续的问题。

设置 overcloud 参数

下表列出了 openstack overcloud deploy 命令的额外参数。

表 5.2. 部署参数

参数描述

--templates [TEMPLATES]

包括在部署过程中使用的 Heat 模板的目录。如果为空,命令会使用位于 /usr/share/openstack-tripleo-heat-templates/ 的默认模板。

--stack STACK

创建或更新的栈的名称

-t [TIMEOUT]--timeout [TIMEOUT]

部署超时时间(分钟)

--libvirt-type [LIBVIRT_TYPE]

hypervisor 使用的虚拟类型

--ntp-server [NTP_SERVER]

用来同步时间的 NTP 服务器

--no-proxy [NO_PROXY]

为环境变量 no_proxy 指定自定义值。这个环境变量被用来在代理通讯中排除特定的主机名。

--overcloud-ssh-user OVERCLOUD_SSH_USER

定义访问 overcloud 节点的 SSH 用户。SSH 访问通常使用 heat-admin 用户。

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

传递给 overcloud 部署的额外环境文件。此参数可以指定多次。请注意,传递到 openstack overcloud deploy 命令的环境文件顺序是非常重要的。例如,如果一个参数在多个环境文件中出现,则后续环境文件中的参数将覆盖前面文件中的同一参数。

--environment-directory

需要在部署中包括的环境文件所在的目录。这个命令会使用数字顺序而不是字母顺序处理这些环境文件。

--validation-errors-nonfatal

overcloud 在创建过程中会执行一组部署前检查。如果部署前检查出现任何非严重错误,则此选项会退出创建。我们推荐使用此选项,因为任何错误都有可能造成部署失败。

--validation-warnings-fatal

overcloud 在创建过程中会执行一组部署前检查。如果部署前检查出现任何非关键警告,则此选项会退出创建。

--dry-run

对 overcloud 进行验证检查,但不实际创建 overcloud。

--skip-postconfig

跳过 overcloud 部署后配置。

--force-postconfig

强制进行 overcloud 部署后配置。

--answers-file ANSWERS_FILE

到带有选项和参数的 YAML 文件的路径。

--rhel-reg

把 overcloud 节点注册到客户门户或 Satellite 6。

--reg-method

overcloud 节点的注册方法。satellite 代表 Red Hat Satellite 6 或 Red Hat Satellite 5,portal 代表客户门户。

--reg-org [REG_ORG]

用于注册的组织。

--reg-force

强制注册系统(即使已经注册过)。

--reg-sat-url [REG_SAT_URL]

注册 overcloud 节点的 Satellite 服务器的基本 URL。此参数需要使用 Satellite 的 HTTP URL 而不是 HTTPS URL。例如,http://satellite.example.com,而不是 https://satellite.example.com。overcloud 的创建过程会使用此 URL 来确定服务器是 Red Hat Satellite 5 还是 Red Hat Satellite 6 服务器。如果是 Red Hat Satellite 6 服务器,overcloud 会获取 katello-ca-consumer-latest.noarch.rpm 文件,使用 subscription-manager 进行注册,并安装 katello-agent。如果是 Red Hat Satellite 5 服务器,overcloud 会获取 RHN-ORG-TRUSTED-SSL-CERT 文件,并使用 rhnreg_ks 进行注册。

--reg-activation-key [REG_ACTIVATION_KEY]

用于注册的激活码。

某些命令行参数被弃用,以支持使用环境文件的 parameter_defaults 部分中包含的 Heat 模板参数。下表将被弃用的参数映射到 Heat 模板的等同参数。

表 5.3. 将被弃用的 CLI 参数映射到 Heat 模板参数

参数描述Heat 模板参数

--control-scale

扩展的 Controller 节点数量

ControllerCount

--compute-scale

扩展的 Compute 节点数量

ComputeCount

--ceph-storage-scale

扩展的 Ceph 节点数量

CephStorageCount

--block-storage-scale

扩展的 Cinder 节点数量

BlockStorageCount

--swift-storage-scale

扩展的 Swift 节点数量

ObjectStorageCount

--control-flavor

Controller 节点使用的 flavor

overcloudControlFlavor

--compute-flavor

Compute 节点使用的 flavor

overcloudComputeFlavor

--ceph-storage-flavor

Ceph 节点使用的 flavor

overcloudCephStorageFlavor

--block-storage-flavor

Cinder 节点使用的 flavor

overcloudBlockStorageFlavor

--swift-storage-flavor

Swift 存储节点使用的 flavor

overcloudSwiftStorageFlavor

--neutron-flat-networks

定义在 neutron 插件中配置的平面网络。默认是 "datacentre",允许外部网络创建

NeutronFlatNetworks

--neutron-physical-bridge

在每个虚拟机管理器上创建的 Open vSwitch 网桥。默认值是 "br-ex",一般情况下不需要修改它

HypervisorNeutronPhysicalBridge

--neutron-bridge-mappings

要使用的逻辑网络到物理网桥的映射。默认情况是把主机上的外部网桥(br-ex)映射到一个物理名(datacentre)。您可以使用它作为默认的浮动网络

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

禁用隧道功能以在 Neutron 中使用 VLAN 分段网络或平面网络

无参数映射。

--validation-errors-fatal

overcloud 在创建过程中会执行一组部署前检查。在使用这个选项时,如果部署前检查出现任何严重错误,则会退出创建。我们推荐使用此选项,因为任何错误都有可能造成部署失败。

未进行参数映射

这些参数预定会从未来的 Red Hat OpenStack Platform 版本中移除。

注意

运行以下命令获得选项的完整列表:

$ openstack help overcloud deploy

5.7. 在 overcloud 创建中包括环境文件

使用 -e 来包含用于自定义 overcloud 的环境文件。您可以根据需要包含多个环境文件。但是,环境文件的顺序非常重要,后续环境文件中定义的参数和资源会覆盖前面环境文件中定义的相同参数和资源。下表是环境文件顺序的一个示例:

  • 每个角色及其类型的节点数量。包含此信息对于创建 overcloud 至关重要。
  • 任何网络隔离文件(包括 Heat 模板集合中的 environments/network-isolation.yaml),然后是您的自定义 NIC 配置文件。
  • 任何外部的负载平衡环境文件。
  • 任何存储环境文件,如 Ceph Storage、NFS、iSCSI 等。
  • 任何用于 Red Hat CDN 或 Satellite 注册的环境文件。
  • 任何其它自定义环境文件。

使用 -e 选项添加的所有环境文件都会成为 overcloud 栈定义的一部分。下例中的命令演示如何启动包含有自定义环境文件的 overcloud 创建过程:

$ openstack overcloud deploy --templates \
  -e ~/templates/node-info.yaml\
  -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
  -e ~/templates/network-environment.yaml \
  -e ~/templates/storage-environment.yaml \
  --ntp-server pool.ntp.org \

这个命令包括以下的额外选项:

  • --templates - 使用 /usr/share/openstack-tripleo-heat-templates 中的 Heat 模板集合创建 overcloud。
  • -e ~/templates/node-info.yaml - -e 选项为 overcloud 部署添加了额外的环境文件。在此处,它是用来定义每个角色使用多少个节点和多少种类型的自定义环境文件。例如:

    parameter_defaults:
      overcloudControlFlavor: control
      overcloudComputeFlavor: compute
      overcloudCephStorageFlavor: ceph-storage
      ControllerCount: 3
      ComputeCount: 3
      CephStorageCount: 3
  • -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml - -e 选项为 overcloud 部署添加了额外的环境文件。在此处,它是对网络隔离配置进行初始化的环境文件。
  • -e ~/templates/network-environment.yaml - -e 选项添加额外的环境文件到 overcloud 部署中。在本例中,它是包含网络隔离自定义的网络环境文件。
  • -e ~/templates/storage-environment.yaml - -e 选项为 overcloud 部署添加了额外的环境文件。在此处,它是用来初始化存储配置的自定义环境文件。
  • --ntp-server pool.ntp.org - 使用一个 NTP 服务器进行时间同步。这可以保持 Controller 节点集群的同步。

director 需要这些环境文件来进行重新部署并使用部署后的功能(请参阅 ???)。没有正确包含这些文件可能会破坏您的 overcloud。

如果计划在以后修改 overcloud 配置,您应该:

  1. 修改定制环境文件和 Heat 模板中的参数
  2. 使用相同的环境文件再次运行 openstack overcloud deploy 命令

不要直接编辑 overcloud 的配置,因为在使用 director 对 overcloud 栈进行更新时,这种手动配置会被 director 的配置覆盖。

包含环境文件目录

您可以使用 --environment-directory 选项添加包含环境文件的完整目录。部署命令按照数字的顺序而不是字母顺序处理这个目录中的环境文件。因此,在使用这个方法时,推荐在文件名中包括一个数字前缀以排列其处理顺序。例如:

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

运行以下部署命令,以包含目录:

$ openstack overcloud deploy --templates --environment-directory ~/templates

使用一个应答文件

应答文件是 YAML 格式的文件,用于简化模板和环境文件的包含方式。应答文件使用以下参数:

templates
要使用的 Heat 核心模板集。它用于替代 --templates 命令行选项。
environments
要包含的环境文件列表。它用于替代 --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

运行下列部署命令,以包含应答文件:

$ openstack overcloud deploy --answers-file ~/answers.yaml

5.8. 管理 overcloud 计划

作为 openstack overcloud deploy 命令的一种替代,director 也可以管理导入的计划。

如要创建新计划,请以 stack 用户的身份运行以下命令:

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

这会从 /usr/share/openstack-tripleo-heat-templates 的 Heat 核心模板集创建一个计划。director 根据您的输入为计划命名。在本例中,名称即是 my-overcloud。director 将这个名称用作对象存储容器、工作流环境以及 overcloud 堆栈名称的标签。

使用以下命令,从环境文件添加参数:

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

使用以下命令,部署您的计划:

$ openstack overcloud plan deploy my-overcloud

使用以下命令,删除现有的计划:

$ openstack overcloud plan delete my-overcloud
注意

基本上,openstack overcloud deploy 命令使用所有这些命令来移除现有的计划,上传包含环境文件的新计划并部署该计划。

5.9. 验证 overcloud 模板和计划

创建 overcloud 或更新堆栈之前,先验证您的 Heat 模板和环境文件,确认是否存在任何错误。

创建一个呈现的模板

overcloud 的 Heat 核心模板采用 Jinja2 格式。要验证您的模板,请使用以下命令呈现未采用 Jinja2 格式的版本:

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

使用 ~/overcloud-validation 中的呈现模板执行后续的验证测试。

验证模板语法

使用下列命令来验证模板语法:

$ 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 环境文件包括针对于 overcloud 的资源。使用 -e 选项为这个命令添加其他额外的环境文件。此外,还需包含 --show-nested 选项,以解析来自嵌套模板的参数。

此命令可以确认模板中的任何语法错误。如果模板语法验证成功,输出会显示生成的 overcloud 模板的预览。

5.10. 监控 overcloud 的创建过程

overcloud 创建过程开始,director 部署您的节点。此过程需要一些时间完成。要查看 overcloud 创建的状态,请在另外一个终端中以 stack 用户身份运行:

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

heat stack-list --show-nested 命令会显示 overcloud 创建过程的当前状态。

5.11. 访问 overcloud

director 会生成脚本来配置和帮助认证 director 主机与 overcloud 的交互。director 将此文件保存为 stack 用户主目录的 overcloudrc 文件。运行以下命令来使用此文件:

$ source ~/overcloudrc

这会加载从 director 主机的 CLI 访问 overcloud 所需的环境变量。若要返回到与 director 主机交互,请运行以下命令:

$ source ~/stackrc

overcloud 中的每个节点还会包括一个名为 heat-admin 的用户。stack 用户有到每个节点上的此用户的 SSH 访问权限。要通过 SSH 访问某一节点,可查找相关节点的 IP 地址:

$ nova list

使用 heat-admin 用户和节点的 IP 地址连接到节点:

$ ssh heat-admin@192.168.24.23

5.12. 完成 overcloud 的创建

使用命令行工具创建 overcloud 的步骤到此结束。有关创建后的功能,请参阅???