undercloud 是主要的 director 节点，它是由单一系统组成的一个 OpenStack 安装，并包括了部署和管理 OpenStack 环境 (overcloud) 所需的组件。undercloud 的组件具有多个功能：

overcloud 是一个通过 undercloud 创建的 Red Hat OpenStack Platform 环境，它包括了一组基于所要创建的 OpenStack Platform 环境的不同节点角色。undercloud 包括了一组默认的 overcloud 节点角色：

Red Hat OpenStack Platform director 使用一个 Controller 节点集群来为 OpenStack Platform 环境提供高可用性功能。director 在每个 Controller 节点上安装一组重复的组件，这种集群配置在单一 Controller 节点出现问题时，提供了一个故障转移的功能，从而在一定程度上为 OpenStack 用户提供了不间断的服务。

OpenStack Platform director 使用以下软件来管理 Controller 节点上的组件：

大型的机构通常需要使用 OpenStack 来为成千上万的客户端系统提供服务，而每个 OpenStack 客户端系统都会有自己对块存储资源的要求。在一个单一的节点上安装 glance (images)、cinder (volumes) 和/或 nova (compute) 来管理一个大型系统中的成千上万的客户系统将变得非常不现实。这个问题可以通过外部扩展 OpenStack 加以解决。

但是，在实际的环境中，仍然需要一个存储层的虚拟化解决方案来扩展 Red Hat OpenStack Platform 的存储层，使它可以支持 terabyte、petabyte 甚至 exabyte 数量级的存储要求。Red Hat Ceph Storage 提供了这样一个存储虚拟化层，它具有高可用性和高效性。虽然虚拟化可能会在牺牲系统性能的情况下实现，但是 Ceph 会把集群中的块设备镜像作为对象来处理，这意味着大型的 Ceph Block 设备镜像有比独立磁盘更好的性能。另外，Cept Block 设备还支持缓存、copy-on-write cloning 和 copy-on-read cloning 功能来提高性能。

如需了解更多与 Red Hat Ceph Storage 相关的信息，请参阅 Red Hat Ceph Storage。

请注意：

托管 director 的 undercloud 系统为 overcloud 中所有节点提供部署和管理服务。

$ yum install libvirt-client libvirt-daemon qemu-kvm libvirt-daemon-driver-qemu libvirt-daemon-kvm virt-install bridge-utils rsync

$ virt-install --name undercloud --memory=16384 --vcpus=4 --location /var/lib/libvirt/images/rhel-server-7.3-x86_64-dvd.iso --disk size=100 --network bridge=br-ex --network bridge=br-ctlplane --graphics=vnc --hvm --os-variant=rhel7

--initrd-inject=/root/ks.cfg --extra-args "ks=file:/ks.cfg"

$ virsh snapshot-create-as --domain undercloud --disk-only --atomic --quiesce

$ rsync --sparse -avh --progress /var/lib/libvirt/images/undercloud.qcow2 1.qcow2

$ virsh blockcommit undercloud vda --active --verbose --pivot

undercloud 主机最少需要两个网络：

以上为至少需要的网络数量。不过，director 可以将其他 Red Hat OpenStack Platform 网络流量隔离到其他网络。Red Hat OpenStack Platform 支持将物理接口和 tagged VLAN 用于网络隔离。

请注意：

以下小节详细介绍 overcloud 安装中各个系统和节点的要求。

undercloud 和 overcloud 都需要通过 Red Hat Content Delivery Network 或者 Red Hat Satellite 5 或 6 来访问红帽存储库。如果使用 Red Hat Satellite Server，请将所需的存储库与您的 OpenStack Platform 环境进行同步。请参考下方的 CDN 频道名列表：

director 为构建 overcloud 提供了多个默认的节点类型。这些节点类型是：

下表提供了几个不同的 overcloud 示例，以及每种情况中的节点数量。

此外，还需思考是否要将各个服务划分成不同的自定义角色。有关可组合角色架构的更多信息，请参阅 Advanced Overcloud Customization 指南中的 Chapter 8. Composable Roles and Services。

规划环境中的网络拓扑结构和子网非常重要，您需要把角色和服务进行正确的映射，从而使它们可以进行正确的通信。Red Hat OpenStack Platform 使用 neutron 网络服务，此服务可自主运行，并可管理基于软件的网络、静态和浮动 IP 地址以及 DHCP。budirector 在overcloud 环境的每个 Controller 节点上实施此服务。

Red Hat OpenStack Platform 把不同的服务映射到分配给环境中的不同子网的独立网络流量类型中。这些网络类型包括：

在典型的 Red Hat OpenStack Platform 安装中，网络类型的数量通常会超过物理网络链路的数量。为了可以把所有网络都连接到正确的主机，overcloud 使用 VLAN 标签（VLAN tagging）来为每个接口提供多个网络。大多数的网络都是相互分离的子网，但部分网络需要第 3 层网关来提供路由功能以便接入互联网或连接基础架构网络。

director 提供了一个为其中的 6 种网络流量类型映射到特定子网或 VLAN 的方法。这些流量类型包括：

所有没有被分配的网络都会被自动分配到和 Provisioning 网络相同的网络中。

下图显示了一个通过独立的 VLAN 进行分离的网络拓扑结构示例。每个 overcloud 节点都使用绑定的两个接口（nic2 和 nic3）来通过各自的 VLAN 提供网络功能。同时，所有 overcloud 节点都使用 nic1 并借助原生 VLAN 通过 Provisioning 网络跟 undercloud 进行通信。

下表提供了把网络流量映射到不同网络结构中的示例：

director 为 overcloud 环境提供不同的存储选项，它们包括：

director 的安装过程需要一个非 root 的用户来执行命令。使用以下命令创建一个名为 stack 的用户并设置密码：

[root@director ~]# useradd stack
[root@director ~]# passwd stack  # specify a password

进行以下操作以使这个用户使用 sudo 时不需要输入密码：

[root@director ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack
[root@director ~]# chmod 0440 /etc/sudoers.d/stack

切换到新的 stack 用户：

[root@director ~]# su - stack
[stack@director ~]$

使用 stack 用户继续安装的过程。

director 使用系统镜像和 Heat 模板来创建 overcloud 环境。为保持文件的有序性，我们推荐创建以下目录来组织镜像和模板文件：

[stack@director ~]$ mkdir ~/images
[stack@director ~]$ mkdir ~/templates

本指南中的其它部分会使用这两个目录来保存特定的文件。

director 的安装和配置过程需要一个完全限定域名（FQDN），这意味着您需要为 director 的主机设置主机名（hostname）。使用以下命令检查主机的主机名：

[stack@director ~]$ hostname    # Checks the base hostname
[stack@director ~]$ hostname -f # Checks the long hostname (FQDN)

如果需要，使用 hostnamectl 设置主机名：

[stack@director ~]$ sudo hostnamectl set-hostname manager.example.com
[stack@director ~]$ sudo hostnamectl set-hostname --transient manager.example.com

另外，director 还需要在/etc/hosts 文件中包括一个带有系统主机名的项。例如，系统名是 manager.example.com，/etc/hosts 则需要包括一个和以下类似的项：

127.0.0.1   manager.example.com manager localhost localhost.localdomain localhost4 localhost4.localdomain4

若要安装 Red Hat OpenStack Platform director，首先需要使用 Red Hat Subscription Manager 注册主机系统，并且订阅所需的频道。

这些仓库包括了安装 director 所需的软件包。

对系统上的软件进行一个更新来确保使用了最新的基本系统软件包：

[stack@director ~]$ sudo yum update -y
[stack@director ~]$ sudo reboot

现在，这个系统已经准备好可以进行 director 安装了。

使用以下命令安装 director 所需的命令行工具：

[stack@director ~]$ sudo yum install -y python-tripleoclient

这个命令会安装 director 所需的所有软件包。

如果要创建包含 Ceph Storage 节点的 overcloud，需要额外安装 ceph-ansible 软件包：

[stack@director ~]$ sudo yum install -y ceph-ansible

director 的安装过程需要特定的设置来决定您的网络配置。这些设置保存在 stack 用户的家目录中的一个模板中（undercloud.conf）。

红帽会提供一个基本的模板来帮助您设置安装所需的配置。把这个模板复制到 stack 用户的家目录中：

[stack@director ~]$ cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf

undercloud.conf 文件包含用于配置 undercloud 的设置。如果忽略或注释掉某个参数，undercloud 安装将使用默认值。

模板包括两部分：[DEFAULT] 和 [auth]。[DEFAULT] 部分包括以下参数：

[auth] 部分包含以下参数：

根据网络的具体情况修改这些参数的值。完成后，保存这个文件并运行以下命令：

[stack@director ~]$ openstack undercloud install

这会启动 director 的配置脚本。director 会安装额外的软件包，并把它的服务配置为和 undercloud.conf 中的设置相符合的情况。这个脚本会需要一些时间来完成。

完成后，配置脚本会产生两个文件：

此配置也会自动启用所有 OpenStack Platform 服务。使用以下命令检查已启用的服务：

[stack@director ~]$ sudo systemctl list-units openstack-*

运行以下命令初始化 stack 用户来使用命令行工具：

[stack@director ~]$ source ~/stackrc

提示信息现在指示，OpenStack 命令在对 undercloud 验证身份并执行命令；

(undercloud) [stack@director ~]$

您现在可以使用 director 的命令行工具了。

director 需要以下几个磁盘镜像来部署 overcloud 节点：

从 rhosp-director-images 和 rhosp-director-images-ipa 软件包中获得这些镜像：

(undercloud) [stack@director ~]$ sudo yum install rhosp-director-images rhosp-director-images-ipa

把压缩文件展开到 stack 用户的家目录下的 images 目录中（/home/stack/images）：

(undercloud) [stack@director ~]$ cd ~/images
(undercloud) [stack@director images]$ for i in /usr/share/rhosp-director-images/overcloud-full-latest-12.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-12.0.tar; do tar -xvf $i; done

把这些镜像导入到 director：

(undercloud) [stack@director images]$ openstack overcloud image upload --image-path /home/stack/images/

这会把 bm-deploy-kernel、bm-deploy-ramdisk、overcloud-full、overcloud-full-initrd 和 overcloud-full-vmlinuz 镜像上传到 director。部署操作和 overcloud 需要这些镜像。另外，此脚本还会在 director 的 PXE 服务器上安装内省镜像。

在 CLI 中查看镜像列表：

(undercloud) [stack@director images]$ openstack image list
+--------------------------------------+------------------------+
| ID                                   | Name                   |
+--------------------------------------+------------------------+
| 765a46af-4417-4592-91e5-a300ead3faf6 | bm-deploy-ramdisk      |
| 09b40e3d-0382-4925-a356-3a4b4f36b514 | bm-deploy-kernel       |
| ef793cd0-e65c-456a-a675-63cd57610bd5 | overcloud-full         |
| 9a51a6cb-4670-40de-b64b-b70f4dd44152 | overcloud-full-initrd  |
| 4f7e33f4-d617-47c1-b36f-cbe90f132e5d | overcloud-full-vmlinuz |
+--------------------------------------+------------------------+

这个列表没有显示内省 PXE 镜像。director 会把这些文件复制到 /httpboot。

(undercloud) [stack@director images]$ ls -l /httpboot
total 341460
-rwxr-xr-x. 1 root              root                5153184 Mar 31 06:58 agent.kernel
-rw-r--r--. 1 root              root              344491465 Mar 31 06:59 agent.ramdisk
-rw-r--r--. 1 ironic-inspector  ironic-inspector        337 Mar 31 06:23 inspector.ipxe

overcloud 节点需要名称服务器来提供 DNS 主机名解析。对于没有网络隔离的标准 overcloud，此名称服务器在 undercloud 的 neutron 子网中定义。使用以下命令定义环境的名称服务器：

(undercloud) [stack@director images]$ openstack subnet list
(undercloud) [stack@director images]$ openstack subnet set --dns-nameserver [nameserver1-ip] --dns-nameserver [nameserver2-ip] [subnet-uuid]

查看子网来验证名称解析服务器：

(undercloud) [stack@director images]$ openstack subnet show [subnet-uuid]
+-------------------+-----------------------------------------------+
| Field             | Value                                         |
+-------------------+-----------------------------------------------+
| ...               |                                               |
| dns_nameservers   | 8.8.8.8                                       |
| ...               |                                               |
+-------------------+-----------------------------------------------+

红帽提供了一个对 undercloud 主机以及 Red Hat OpenStack Platform director 的重要数据进行备份的方法。如需了解更多与 undercloud 备份相关的信息，请参阅 "Back Up and Restore the Director Undercloud" 指南。

undercloud 的配置到此结束。下一章将介绍基本的 overcloud 配置，包括注册节点和检查节点，并把它们标记为不同的节点角色。

红帽将 overcloud 容器镜像托管在 registry.access.redhat.com 中。从远程注册表提取镜像是最简单的方法，因为注册表已经建好，您只需知道要提取的镜像的 URL 和命名空间即可。但是在 overcloud 创建过程中，overcloud 节点都要从远程存储库提取镜像，这会堵塞外部连接。如果这造成问题，可采用以下方法之一：

要在 overcloud 部署中直接从 registry.access.redhat.com 提取镜像，需要有环境文件指定镜像参数。以下命令可自动创建该环境文件：

注册表配置现在已经完成。继续按照 第 6 章 使用 CLI 工具配置基本的 overcloud 要求 中的说明进行操作。

您可以在 undercloud 上配置本地注册表来保存 overcloud 容器镜像。这种方法从 registry.access.redhat.com 逐个提取每个镜像。而在 overcloud 创建过程中，overcloud 节点将从 undercloud 提取相关镜像。这会使容器镜像产生的网络流量保持在内部网络中，不会堵塞外部网络连接，从而加速部署过程。

要将镜像从 registry.access.redhat.com 提取到本地注册表，安以下过程操作：

注册表配置现在已经完成。继续按照 第 6 章 使用 CLI 工具配置基本的 overcloud 要求 中的说明进行操作。

Red Hat Satellite 6 提供了注册表同步功能。通过该功能可将多个镜像提取到 Satellite 服务器中，作为应用程序生命周期的一部分加以管理。Satellite 也可以作为注册表供其他启用容器功能的系统使用。如需了解更多有关管理容器镜像的详细信息，请参阅 Red Hat Satellite 6 Content Management Guide 中的 "Managing Container Images"。

以下操作过程示例中使用了 Red Hat Satellite 6 的 hammer 命令行工具和一个名为 ACME 的示例组织。请将该组织替换为您自己 Satellite 6 中的组织。

要将镜像从 registry.access.redhat.com 提取到本地注册表，安以下过程操作：

注册表配置现在已经完成。继续按照 第 6 章 使用 CLI 工具配置基本的 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"
        }
    ]
}

这个模板使用以下属性：

创建完模板后，将这个文件保存到 stack 用户的主目录 (/home/stack/instackenv.json)，然后使用以下命令将其导入到 director：

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

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

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

(undercloud) $ openstack baremetal node list

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

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

(undercloud) $ openstack overcloud node introspect --all-manageable --provide

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

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

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

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

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

(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

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

获取节点上的接口列表：

(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                                                                                                  |
+--------------------------------------+------------------------------------------------------------------------------------------------------------------------+

例如，numa_topology 收集程序就是这些硬件检查额外功能的一部分，包括每个 NUMA 节点的以下信息：

使用 openstack baremetal introspection data save _UUID_ | jq .numa_topology 命令并提供裸机节点的 UUID 以获取这些信息。

以下示例显示获取的裸机节点 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
    }
  ]
}

您可以使用 auto-discovery 来注册 undercloud 节点并生成它们的元数据，而无需首先创建 instackenv.json 文件。这种改进有助于缩短初始收集节点信息花费的时间，例如，这种方法无需核对 IPMI IP 地址并在随后创建 instackenv.json。

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

默认的配置文件类型 compute、control、swift-storage、ceph-storage 和 block-storage 会在 undercloud 的安装过程中创建，多数环境中可不经修改直接使用。

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

(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:compute 和 profile:control 选项会把节点标记为相关的配置集。

这些命令还会设置 boot_option:local 参数，其定义每个节点的引导方式。根据硬件具体情况，可能还需要将 boot_mode 参数设置为 uefi，使节点以 UEFI 模式而不是默认 BIOS 模式进行引导。如需了解更多信息，请参阅 第 D.2 节 “UEFI 引导模式”。

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

(undercloud) $ openstack overcloud profiles list

(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

一些节点可能会使用多个磁盘。这意味着 director 需要识别在置备过程中作为根磁盘的磁盘。

以下几个属性可帮助 director 识别根磁盘：

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

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

(undercloud) $ 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 参数：

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

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

undercloud 带有一组 Heat 模板，作为创建 overcloud 的方案。您可以使用环境文件来自定义 overcloud 的各个方面，这些文件是 YAML 格式的文件，其内容可覆盖核心 Heat 模板集合中的参数和资源。您可以根据需要纳入多个环境文件。但是，环境文件的顺序非常重要，因为后续环境文件中定义的参数和资源更为优先。以下列表是环境文件顺序的示例：

建议将自定义环境文件放在一个单独目录中，比如 templates 目录。

您可以按照 Advanced Overcloud Customization 指南来自定义 overcloud 的高级功能。

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

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

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

(undercloud) $ openstack help overcloud deploy

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

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

(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 /home/stack/templates/storage-environment.yaml \
  --ntp-server pool.ntp.org \

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

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

如果计划在以后修改 overcloud 配置，您应该：

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

(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

例如，应答文件可能包含以下内容：

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

作为 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 将这个名称用作对象存储容器、工作流环境以及 overcloud 堆栈名称的标签。

使用以下命令，从环境文件添加参数：

(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

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

(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 模板的预览。

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

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

openstack stack list --nested 命令可显示 overcloud 创建过程的当前阶段。

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

(undercloud) $ source ~/overcloudrc

这会加载所需的环境变量，以便通过 director 主机的 CLI 与 overcloud 进行交互。命令提示符的变化会显示当前状态：

(overcloud) $

要返回与 director 主机进行交互的状态，运行以下命令：

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

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

(undercloud) $ openstack server list

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

(undercloud) $ ssh heat-admin@192.168.24.23

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

用户通过 SSL 访问 director 的 Web UI。例如，如果 undercloud 的 IP 地址是 192.168.24.1，则用于访问 UI 的地址是 https://192.168.24.1。Web UI 首先将显示一个登录屏幕，屏幕中含有以下字段：

登录 UI 后，UI 将访问 OpenStack Identity Public API 并获取其他 Public API 服务的端点。这些服务包括：

UI 直接与这些 Public API 交互，所以您的客户端系统需要访问其端点。director 通过 SSL/TLS 加密路径在 Public VIP（undercloud.conf 文件中的 undercloud_public_host）展示这些端点。每个路径对应着相应服务。例如，https://192.168.24.2:443/keystone 对应着 OpenStack Identity Public API。

如果准备更改端点或使用不同的 IP 地址来访问端点，director UI 可从 /var/www/openstack-tripleo-ui/dist/tripleo_ui_config.js 文件中读取相应设置。此文件使用以下参数：

以下是 tripleo_ui_config.js 文件示例，其中 192.168.24.2 是 undercloud 的 Public VIP：

window.tripleOUiConfig = {
  'keystone': 'https://192.168.24.2:443/keystone/v2.0',
  'heat': 'https://192.168.24.2:443/heat/v1/%(tenant_id)s',
  'ironic': 'https://192.168.24.2:443/ironic',
  'mistral': 'https://192.168.24.2:443/mistral/v2',
  'swift': 'https://192.168.24.2:443/swift/v1/AUTH_%(tenant_id)s',
  'zaqar-websocket': 'wss://192.168.24.2:443/zaqar',
  "zaqar_default_queue": "tripleo",
  'excludedLanguages': [],
  'loggers': ["console","zaqar"]
};

UI 包含三大区域：

这些验证任务在部署期间的特定时点上自动运行，但您也可以手动运行。若要运行某项验证任务，可单击对应的 Play 按钮。单击各项验证任务的标题可运行该任务，或单击验证标题查看更多相关信息。

director UI 需要先加载计划，才能配置 overcloud。此计划通常是一个 Heat 模板集合，比如 undercloud 上的 /usr/share/openstack-tripleo-heat-templates。此外，您也可以根据自己的硬件和环境要求自定义计划。有关自定义 overcloud 的更多信息，请参阅 Advanced Overcloud Customization 指南。

计划中包含配置 overcloud 的四个主要步骤：

undercloud 安装和配置过程会自动上传计划。您也可以在 Web UI 中导入多个计划。单击 Plan 屏幕上的 All Plans 导航项。这将显示当前 Plans 列表。单击卡片可在多个计划之间切换。

单击 Import Plan 将出现窗口，要求提供以下信息：

如果需要复制 director 的 Heat 模板集到客户端机器，可以存档文件再复制它们：

$ cd /usr/share/openstack-tripleo-heat-templates/
$ tar -cf ~/overcloud.tar *
$ scp ~/overcloud.tar user@10.0.0.55:~/.

一旦 director UI 上传了计划，该计划就会显示在 Plans 列表中，此时您可以进行配置。只需单击您要选择的计划卡片即可。

配置 overcloud 节点的第一步是注册您的节点。您可以通过以下方式之一来开始注册节点：

这将显示 Register Nodes 窗口。

Director 需要一份要注册的节点列表，您可以通过以下两种方式之一来提供：

如下为手动注册时要提供的详细信息：

在输入节点信息后，请单击窗口底部的 Register Nodes。

Director 将注册节点。完成时，您可以使用 UI 来执行节点内省。

director 可以在每个节点上运行内省过程。此过程会使每个节点通过 PXE 引导一个内省代理。此代理从节点上收集硬件数据，并把信息发送回 director，director 把这些信息存储到运行于 director 上的 OpenStack Object Storage（swift）服务中。director 将这些硬件信息用于不同的目的，如进行配置文件标记、基准测试和手动分配根磁盘等。

若要启动内省过程：

内省过程完成时，选择 Provision State 为 manageable 的所有节点，再单击 Provide Nodes 按钮。等待 Provision State 更改为 available。

节点现在已做好标记和部署准备。

您可以为每个节点分配一组配置文件。每个配置文件分别对应相关的类型和角色（如需更多信息，请参阅 第 6.4 节 “为节点添加标签（tag）来标记为配置集”）。

Nodes 屏幕包含其他菜单切换，可提供额外的节点管理操作，比如 Tag Nodes。

标记一组节点：

Plan 屏幕中提供了一种方式，供您自定义上传的计划。在 2 Specify Deployment Configuration 下，单击 Edit Configuration 链接，修改您的基本 overcloud 配置。

这时将出现一个窗口，其包含两个主要选项卡：

注册并检查了每个节点的硬件之后，将它们分配给计划中的角色。

要将节点分配到角色，请滚动到 Plan 屏幕上的 3 Configure Roles and Assign Nodes 区域。每个角色都使用旋转器小工具将一定数量的节点分配给该角色。各角色可用的节点取决于在 第 7.6 节 “在 Web UI 中将节点标记到配置文件” 中标记过的节点。

这会改变每个角色的 *Count 参数。例如，如果将 Controller 角色的节点数量更改为 3，会将 ControllerCount 参数设置为 3。您也可以在部署配置的 Parameters 选项卡中查看并编辑这些计数值。如需更多信息，请参阅 第 7.7 节 “在 Web UI 中编辑 overcloud 计划参数”。

每个节点角色都会提供配置角色相关参数的方法。滚动到 Plan 屏幕上的 3 Configure Roles and Assign Nodes 角色。单击角色名称旁边的 Edit Role Parameters 图标（铅笔图标）。

此时将出现一个窗口，其中显示了两个主要选项卡：

配置了 overcloud 计划后，您可以开始部署 overcloud。具体操作包括滚动到 4 Deploy 区域，并单击 Validate and Deploy。

如果没有运行 undercloud 验证或未通过验证，屏幕中会显示警告消息。请确保您的 undercloud 主机满足相关的要求，然后再进行部署。

准备好部署时，请单击 Deploy。

UI 会定期监控 overcloud 的创建进度，并通过进度条来指示当前的进度百分比。单击View detailed information 链接，可显示 overcloud 中当前 OpenStack Orchestration 栈的日志。

等待 overcloud 部署完成。

在 overcloud 创建过程完成后，4 Deploy 区域显示当前的 overcloud 状态和以下详细信息：

使用以上信息来访问您的 overcloud。

通过 director UI 创建 overcloud 的步骤到此结束。如需了解创建后功能，请参阅???。

在本流程稍后的阶段，director 需要具备以 stack 用户的身份访问 overcloud 节点的 SSH 权限。

每个节点需要具备访问红帽订阅的权限。以下步骤显示了如何将每个节点注册到 Red Hat Content Delivery Network。对每个节点执行以下操作：

节点现在可供您的 overcloud 使用。

各预配置节点使用 OpenStack Orchestration (heat) 代理与 director 通讯。各节点上的代理对 director 轮询，获得针对各节点定制的元数据。该元数据允许代理配置各节点。

在各节点上为编配代理安装初始软件包：

[root@controller ~]# sudo yum -y install python-heat-agent*

如果 director 使用 SSL/TLS，那么预配置节点需要用于签署 director 的 SSL/TLS 证书的证书授权机构文件。如果使用您自己的证书授权机构，则在各 overcloud 节点上执行以下操作：

这可以确保 overcloud 节点能够通过 SSL/TLS 访问 director 的 Public API。

预配置 overcloud 节点使用标准 HTTP 请求从 director 获取元数据。这表示所有 overcloud 节点都需要 L3 权限来访问以下之一：

director 使用 Control Plane 网络来管理和配置标准 overcloud。对于具备预配置节点的 overcloud，您可能需要对网络配置做一些修改，以适应 director 与预配置节点通讯的方式。

创建标准 overcloud 期间，director 创建 OpenStack Networking (neutron) 端口，用于自动为 Provisioning / Control Plane 网络池上的 overcloud 节点分配 IP 地址。但是，这可能导致 director 为手动配置的节点分配不同的 IP 地址。在这种情况下，使用可预测的 IP 地址策略来强制 director 使用 Control Plane 上的预配置 IP 分配。

可预测 IP 策略的一个示例是使用 IP 地址分配如下的环境文件 (ctlplane-assignments.yaml)：

resource_registry:
  OS::TripleO::DeployedServer::ControlPlanePort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml

parameter_defaults:
  DeployedServerPortMap:
    controller-ctlplane:
      fixed_ips:
        - ip_address: 192.168.24.2
      subnets:
        - cidr: 24
    compute-ctlplane:
      fixed_ips:
        - ip_address: 192.168.24.3
      subnets:
        - cidr: 24

在本示例中，OS::TripleO::DeployedServer::ControlPlanePort 资源将一组参数传递至 director，并为预配置的节点定义 IP 分配。DeployedServerPortMap 参数定义与每个 overcloud 节点对应的 IP 地址和子网 CIDR。映射定义：

本章之后的步骤将生成的环境文件 (ctlplane-assignments.yaml) 用作 openstack overcloud deploy 命令的组成部分。

默认情况下，director 使用 Provisioning 网络作为 overcloud Control Plane。但是，如果此网络被隔离且不可路由，则节点在配置期间不能与 director 的内部 API 通讯。在这种情况下，您可能需要为节点指定一个单独的网络，并进行配置，以便通过公共 API 与 director 通讯。

对于此情境，有几个需要满足的要求：

本节中的示例使用了与主要情境不同的 IP 地址分配：

以下章节为需要单独的 overcloud 节点网络的情境提供额外配置。

您的 undercloud.conf 中的 hieradata_override 允许您指定用于 undercloud 配置的额外 Puppet hieradata。使用以下步骤修改与 OpenStack 编配相关的 hieradata：

这会使编配元数据服务器切换为使用 director 的公共 API 上的 URL。

resource_registry:
  OS::TripleO::DeployedServer::ControlPlanePort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml
  OS::TripleO::Network::Ports::ControlPlaneVipPort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml
  OS::TripleO::Network::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml 1

parameter_defaults:
  NeutronPublicInterface: eth1
  EC2MetadataIp: 192.168.100.1 2
  ControlPlaneDefaultRoute: 192.168.100.1
  DeployedServerPortMap:
    control_virtual_ip:
      fixed_ips:
        - ip_address: 192.168.100.1
      subnets:
        - cidr: 24
    controller0-ctlplane:
      fixed_ips:
        - ip_address: 192.168.100.2
      subnets:
        - cidr: 24
    compute0-ctlplane:
      fixed_ips:
        - ip_address: 192.168.100.3
      subnets:
        - cidr: 24

overcloud 部署使用来自 ??? 的标准 CLI 方法。对于预配置节点，该部署命令需要使用来自核心 Heat 模板集的一些额外选项和环境文件：

以下是一个 overcloud 部署命令命令，采用了针对预配置架构的特定环境文件：

$ source ~/stackrc
(undercloud) $ openstack overcloud deploy \
  [other arguments] \
  --disable-validations \
  -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-environment.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-bootstrap-environment-rhel.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-pacemaker-environment.yaml \
  -r /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-server-roles-data.yaml

由此开始 overcloud 配置。但是，当 overcloud 节点资源进入 CREATE_IN_PROGRESS 阶段时，部署堆栈暂停：

2017-01-14 13:25:13Z [overcloud.Compute.0.Compute]: CREATE_IN_PROGRESS  state changed
2017-01-14 13:25:14Z [overcloud.Controller.0.Controller]: CREATE_IN_PROGRESS  state changed

出现这种暂停是因为 director 等待 overcloud 节点上的编配代理来轮询元数据服务器。下一节将介绍如何配置节点以开始轮询元数据服务器。

部署目前正在进行，但会在进入 CREATE_IN_PROGRESS 阶段后暂停。下一步是在 overcloud 节点上配置编配代理，以便在 director 上轮询元数据服务器。可采用两种方式完成此操作：

[stack@director ~]$ source ~/stackrc

此外，该脚本也要求使用一些额外的环境变量来定义节点的角色及其 IP 地址。这些环境变量包括：

以下命令演示了如何设置这些环境变量：

(undercloud) $ export OVERCLOUD_ROLES="ControllerDeployedServer ComputeDeployedServer"
(undercloud) $ export ControllerDeployedServer_hosts="192.168.100.2"
(undercloud) $ export ComputeDeployedServer_hosts="192.168.100.3"

运行该脚本，在各 overcloud 节点上配置编配代理：

(undercloud) $ /usr/share/openstack-tripleo-heat-templates/deployed-server/scripts/get-occ-config.sh

该脚本完成以下操作：

脚本完成之后，overcloud 节点开始在 director 上轮询编配服务。堆栈部署继续进行。

[stack@director ~]$ source ~/stackrc
(undercloud) $ for STACK in $(openstack stack resource list -n5 --filter name=deployed-server -c stack_name -f value overcloud) ; do STACKID=$(echo $STACK | cut -d '-' -f2,4 --output-delimiter " ") ; echo "== Metadata URL for $STACKID ==" ; openstack stack resource metadata $STACK deployed-server | jq -r '.["os-collect-config"].request.metadata_url' ; echo ; done

这会显示堆栈名称和各节点的元数据 URL：

== Metadata URL for ControllerDeployedServer 0 ==
http://192.168.24.1:8080/v1/AUTH_6fce4e6019264a5b8283e7125f05b764/ov-edServer-ts6lr4tm5p44-deployed-server-td42md2tap4g/43d302fa-d4c2-40df-b3ac-624d6075ef27?temp_url_sig=58313e577a93de8f8d2367f8ce92dd7be7aac3a1&temp_url_expires=2147483586

== Metadata URL for ComputeDeployedServer 0 ==
http://192.168.24.1:8080/v1/AUTH_6fce4e6019264a5b8283e7125f05b764/ov-edServer-wdpk7upmz3eh-deployed-server-ghv7ptfikz2j/0a43e94b-fe02-427b-9bfe-71d2b7bb3126?temp_url_sig=8a50d8ed6502969f0063e79bb32592f4203a136e&temp_url_expires=2147483586

在各 overcloud 节点上：

在配置和重新启动之后，这些编配代理会轮询 director 的编配服务以获取 overcloud 配置。部署堆栈继续创建过程，各节点的堆栈最终变更为 CREATE_COMPLETE。

overcloud 配置过程开始。此过程需要一些时间完成。要查看 overcloud 创建的状态，请以 stack 用户身份打开另外一个终端并运行：

[stack@director ~]$ source ~/stackrc
(undercloud) $ heat stack-list --show-nested

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

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

(undercloud) $ source ~/overcloudrc

这会加载所需的环境变量，以便通过 director 主机的 CLI 与 overcloud 进行交互。命令提示符的变化会显示当前状态：

(overcloud) $

要返回与 director 主机进行交互的状态，运行以下命令：

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

扩展预配置节点的流程与???中的标准扩展流程类似。但是，添加新预配置节点的流程却不相同，这是因为预配置节点不从 OpenStack Bare Metal (ironic) 和 OpenStack Compute (nova) 使用标准注册和管理流程。

扩展节点的常规流程如下：

从堆栈中移除 overcloud 节点之后，关闭这些节点。在标准部署中，此功能由 director 的裸机服务管控。但是，使用预配置节点时，您应当手动关闭这些节点，或者使用各物理系统的电源管理控制功能。从堆栈中移除节点之后，如果您不关闭它们，它们可能保持运行，并作为 overcloud 环境的组成部分重新连接。

关闭已移除的节点之后，重新将它们部署到基础操作系统配置中，避免它们将来意外加入到 overcloud 中

使用与标准 overcloud 相同的流程，移除使用预配置节点的整个 overcloud。请参阅???了解更多详细信息。

移除 overcloud 之后，关闭所有节点，并将它们重新部署到基础操作系统配置中。

通过预配置节点创建 overcloud 的流程到此结束。如需了解创建之后的功能，请参阅???。

overcloud 需要为实例提供租户网络。对 overcloud 执行 source 命令并在 Neutron 中创建一个初始租户网络。例如：

$ source ~/overcloudrc
(overcloud) $ openstack network create default
(overcloud) $ openstack subnet create default --network default --gateway 172.20.1.1 --subnet-range 172.20.0.0/16

这会创建一个名为 default 的基本 Neutron 网络。overcloud 会使用内部 DHCP 机制从这个网络中自动分配 IP 地址。

确认所创建的网络：

(overcloud) $ openstack network list
+-----------------------+-------------+--------------------------------------+
| id                    | name        | subnets                              |
+-----------------------+-------------+--------------------------------------+
| 95fadaa1-5dda-4777... | default     | 7e060813-35c5-462c-a56a-1c6f8f4f332f |
+-----------------------+-------------+--------------------------------------+

您需要在 overcloud 上创建外部网络，以便您可以分配 IP 地址到实例。

source overcloud，并在 Neutron 中创建一个 External 网络：

$ source ~/overcloudrc
(overcloud) $ openstack network create public --external --provider-network-type flat --provider-physical-network datacentre
(overcloud) $ openstack subnet create public --network public --dhcp --allocation-pool start=10.1.1.51,end=10.1.1.250 --gateway 10.1.1.1 --subnet-range 10.1.1.0/24

在本例中，创建一个名为 public 的网络。overcloud 需要将这一特定名称用于默认的浮动 IP 池。另外，它对???中所述的验证测试也非常重要。

此命令还会将网络映射到 datacentre 物理网络。因此，datacentre 将映射到 br-ex 网桥。除非创建 overcloud 过程中使用了自定义 neutron 设置，否则此选项可保留默认设置。

$ source ~/overcloudrc
(overcloud) $ openstack network create public --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 104
(overcloud) $ openstack subnet create public --network public --dhcp --allocation-pool start=10.1.1.51,end=10.1.1.250 --gateway 10.1.1.1 --subnet-range 10.1.1.0/24

provider:segmentation_id 的值定义了要使用的 VLAN。在这个示例中，使用 104。

确认所创建的网络：

(overcloud) $ openstack network list
+-----------------------+-------------+--------------------------------------+
| id                    | name        | subnets                              |
+-----------------------+-------------+--------------------------------------+
| d474fe1f-222d-4e32... | public      | 01c5f621-1e0f-4b9d-9c30-7dc59592a52f |
+-----------------------+-------------+--------------------------------------+

只要满足以下条件，浮动 IP 网络可以使用任何网桥，而不只局限于 br-ex：

在创建 overcloud 后创建浮动 IP 网络：

$ source ~/overcloudrc
(overcloud) $ openstack network create ext-net --external --provider-physical-network floating --provider-network-type vlan --provider-segment 105
(overcloud) $ openstack subnet create ext-subnet --network ext-net --dhcp --allocation-pool start=10.1.2.51,end=10.1.2.250 --gateway 10.1.2.1 --subnet-range 10.1.2.0/24

供应商网络就是物理附加到位于部署的 overcloud 以外的网络。它可以是现有的基础架构网络，或是通过路由而非浮动 IP 为实例提供直接外部访问的网络。

在创建一个供应商网络时，可以使用网桥映射把它和一个物理网络相关联。这和创建浮动 IP 网络相似。您需要把供应商网络添加到 Controller 节点和 Compute 节点中，这是因为 Compute 节点会把虚拟机的虚拟网络接口直接附加到附加的网络接口上。

例如，供应商网络是 br-ex bridge 网桥上的一个 VLAN，使用以下命令在 VLAN 201 上添加一个供应商网络：

$ source ~/overcloudrc
(overcloud) $ openstack network create provider_network --provider-physical-network datacentre --provider-network-type vlan --provider-segment 201 --share

此命令会创建一个共享网络。另外，也可以指定租户，而不指定 --share。此网络只对特定的租户有效。如果将供应商网络标记为外部，则只有操作员可以在该网络上创建端口。

如果需要 neutron 为租户实例提供 DHCP 服务，则需要向供应商网络添加一个子网：

(overcloud) $ openstack subnet create provider-subnet --network  provider_network --dhcp --allocation-pool start=10.9.101.50,end=10.9.101.100 --gateway 10.9.101.254 --subnet-range 10.9.101.0/24

其他网络可能需要通过供应商网络访问外部。在这种情况下，可创建一个新的路由器，使其他网络可以通过供应商网络传送流量：

(overcloud) $ openstack router create external
(overcloud) $ openstack router set --external-gateway provider_network external

将其他网络添加到该路由器。例如，如果有一个子网名为 subnet1，可以使用以下命令将其添加到路由器：

(overcloud) $ openstack router add subnet external subnet1

这会将 subnet1 添加到路由表，并允许使用 subnet1 的流量传送到供应商网络。

overcloud 使用 OpenStack Integration Test Suite (tempest) 工具集来执行一系列集成测试。本节介绍运行集成测试的准备工作信息。有关使用 OpenStack Integration Test Suite 的完整说明，请参阅 OpenStack Integration Test Suite Guide。

$ source ~/stackrc
(undercloud) $ sudo ovs-vsctl add-port br-ctlplane vlan201 tag=201 -- set interface vlan201 type=internal
(undercloud) $ sudo ip l set dev vlan201 up; sudo ip addr add 172.16.0.201/24 dev vlan201

运行 OpenStack Integration Test Suite 之前，检查确认您的 overcloud 中具有 heat_stack_owner 角色：

$ source ~/overcloudrc
(overcloud) $ openstack role list
+----------------------------------+------------------+
| ID                               | Name             |
+----------------------------------+------------------+
| 6226a517204846d1a26d15aae1af208f | swiftoperator    |
| 7c7eb03955e545dd86bbfeb73692738b | heat_stack_owner |
+----------------------------------+------------------+

如果角色不存在，则创建它：

(overcloud) $ openstack role create heat_stack_owner

$ source ~/stackrc
(undercloud) $ sudo ovs-vsctl del-port vlan201

有些时候，您可能要修改 overcloud 来添加一些功能，或改变它的运行方式。要修改 overcloud，请在您的自定义环境文件和 Heat 模板中进行修改，然后从您的初始 overcloud 创建中重新运行 openstack overcloud deploy 命令。例如，如果根据 ??? 创建了一个 overcloud，您应该重新运行以下命令：

$ source ~/stackrc
(undercloud) $ 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

director 会在 heat 中检查 overcloud 栈，然后根据环境文件和 heat 模板更新栈中的每一项目。它不会重新创建 overcloud，而是更改现有的 overcloud。

如果需要包括一个新的环境文件，在 openstack overcloud deploy 命令中使用 -e 选项添加它。例如：

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

这包括从环境文件中读入到栈中的新参数和资源。

如果您有一个已存在的 OpenStack 环境，并希望把它的虚拟机迁移到 Red Hat OpenStack Platform 环境中，请进行以下操作。

为一个运行的服务器进行快照来创建一个新的镜像，然后下载这个镜像。

$ source ~/overcloudrc
(overcloud) $ openstack server image create instance_name --name image_name
(overcloud) $ openstack image save image_name --file exported_vm.qcow2

把导出的镜像上传到 overcloud，然后启动一个新实例。

(overcloud) $ openstack image create imported_image --file exported_vm.qcow2 --disk-format qcow2 --container-format bare
(overcloud) $ openstack server create  imported_instance --key-name default --flavor m1.demo --image imported_image --nic net-id=net_id

在某些情况下，您可能在某个 overcloud Compute 节点上执行维护操作。为了避免停机，可以将该 Compute 节点上的虚拟机迁移到 overcloud 中的另一个 Compute 节点上。

director 可配置所有 Compute 节点来执行安全的迁移。所有 Compute 节点还需要有共享的 SSH 密钥，以便每个主机的 nova 用户在迁移过程中能够访问其他 Compute 节点。director 使用 OS::TripleO::Services::NovaCompute 可组合服务来创建该密钥。该可组合服务是所有 Compute 角色默认包含的主要服务之一（请参阅 Advanced Overcloud Customization 中的 "Composable Services and Custom Roles"）。

如需迁移实例：

这就从 Compute 节点中迁移了所有实例。现在即可在该节点上执行维护，而无需让任何实例停机。要让 Compute 节点恢复启用状态，运行以下命令：

$ source ~/overcloudrc
(overcloud) $ openstack compute service set [hostname] nova-compute --enable

director 使您能够在 OpenStack Platform 环境中运行基于 Ansible 的自动化。director 使用 tripleo-ansible-inventory 命令在您的环境中生成动态的节点清单。

要查看动态的节点清单，请在 source stackrc 之后运行 tripleo-ansible-inventory 命令：

$ source ~/stackrc
(undercloud) $ tripleo-ansible-inventory --list

--list 选项提供与所有主机有关的详情。

此选项以 JSON 格式输出动态清单：

{"overcloud": {"children": ["controller", "compute"], "vars": {"ansible_ssh_user": "heat-admin"}}, "controller": ["192.168.24.2"], "undercloud": {"hosts": ["localhost"], "vars": {"overcloud_horizon_url": "http://192.168.24.4:80/dashboard", "overcloud_admin_password": "abcdefghijklm12345678", "ansible_connection": "local"}}, "compute": ["192.168.24.3"]}

要在您的环境中实施 Ansible playbook，请运行 ansible 命令，并使用 -i 选项包括动态清单工具的完整路径。例如：

(undercloud) $ ansible [HOSTS] -i /bin/tripleo-ansible-inventory [OTHER OPTIONS]

为了避免无意中使用 heat stack-delete overcloud 命令造成 overcloud 被删除，Heat 包括了一组策略来限制某些操作。打开 /etc/heat/policy.json 并找到以下参数：

"stacks:delete": "rule:deny_stack_user"

把它改为：

"stacks:delete": "rule:deny_everybody"

保存这个文件。

这会避免使用 heat 客户端删除 overcloud。若要允许删除 overcloud，请把策略恢复为原先的值。

在需要时，可以删除整个 overcloud。

删除任何现有的 overcloud：

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

确认删除 overcloud：

(undercloud) $ openstack stack list

删除操作会需要几分钟完成。

在删除操作完成后，请按照部署情景中的标准步骤来重新创建 overcloud。

为 director 的节点池添加更多节点，创建一个包括用来注册新节点信息的 JSON 文件（例如，newnodes.json）：

{
  "nodes":[
    {
        "mac":[
            "dd:dd:dd:dd:dd:dd"
        ],
        "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.207"
    },
    {
        "mac":[
            "ee:ee:ee:ee:ee:ee"
        ],
        "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.208"
    }
  ]
}

如需了解与这些参数相关的信息，请参阅 ???。

运行以下命令注册这些节点：

$ source ~/stackrc
(undercloud) $ openstack baremetal import --json newnodes.json

在注册完这些节点后，为它们启动内省进程。为每个新节点运行以下命令：

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

这会发现节点，并为它们创建硬件属性的基准数据。

在内省操作完成后，把新节点标记为相应的角色。例如，使用以下命令把节点标记为一个 Compute 节点：

(undercloud) $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' [NODE UUID]

设置部署时使用的引导镜像。找到 bm-deploy-kernel 和 bm-deploy-ramdisk 镜像的 UUID：

(undercloud) $ openstack image list
+--------------------------------------+------------------------+
| ID                                   | Name                   |
+--------------------------------------+------------------------+
| 09b40e3d-0382-4925-a356-3a4b4f36b514 | bm-deploy-kernel       |
| 765a46af-4417-4592-91e5-a300ead3faf6 | bm-deploy-ramdisk      |
| ef793cd0-e65c-456a-a675-63cd57610bd5 | overcloud-full         |
| 9a51a6cb-4670-40de-b64b-b70f4dd44152 | overcloud-full-initrd  |
| 4f7e33f4-d617-47c1-b36f-cbe90f132e5d | overcloud-full-vmlinuz |
+--------------------------------------+------------------------+

在新节点的 deploy_kernel 和 deploy_ramdisk 设置中使用这些 UUID：

(undercloud) $ openstack baremetal node set --driver-info deploy_kernel='09b40e3d-0382-4925-a356-3a4b4f36b514' [NODE UUID]
(undercloud) $ openstack baremetal node set --driver-info deploy_ramdisk='765a46af-4417-4592-91e5-a300ead3faf6' [NODE UUID]

若要扩展 overcloud，需要使用角色所需的节点数量，重新运行 openstack overcloud deploy。例如，扩展到 5 个计算节点：

(undercloud) $ openstack overcloud deploy --templates --compute-scale 5 [OTHER_OPTIONS]

这会更新整个 overcloud 栈。请注意，这只会更新栈，而不会删除 overcloud 或替换栈。

在某些情况下，您可能需要从 overcloud 中删除计算节点。例如，需要替换有问题的计算节点。

接下来，在 overcloud 中禁用节点的计算服务。这会停止在此节点上调度新的实例。

$ source ~/stack/overcloudrc
(overcloud) $ openstack compute service list
(overcloud) $ openstack compute service set [hostname] nova-compute --disable

切换回 undercloud：

(overcloud) $ source ~/stack/stackrc

若要删除 overcloud 节点，需要使用本地模板文件对 director 中的 overcloud 栈进行更新。首先，确定 overcloud 栈的 UUID：

(undercloud) $ openstack stack list

找到要被删除的节点的 UUID：

(undercloud) $ openstack server list

运行以下命令来从栈中删除节点，并相应地更新计划：

(undercloud) $ openstack overcloud node delete --stack [STACK_UUID] --templates -e [ENVIRONMENT_FILE] [NODE1_UUID] [NODE2_UUID] [NODE3_UUID]

最后，删除节点的 Compute 服务：

(undercloud) $ source ~/stack/overcloudrc
(overcloud) $ openstack compute service list
(overcloud) $ openstack compute service delete [service-id]

删除节点的 Open vSwitch 代理：

(overcloud) $ openstack network agent list
(overcloud) $ openstack network agent delete [openvswitch-agent-id]

现在，可以安全地把节点从 overcloud 中删除，并将它部署用于其他目的。

当一个 Compute 节点出现问题时，您可以使用一个正常的节点替换它。使用以下步骤替换 Compute 节点：

这个过程确保了替换节点的操作不会影响到任何实例的可用性。

在一些情况下，高可用性集群中的 Controller 节点可能会出现故障。在这种情况下，您需要把这个节点从集群中删除，并使用一个新 Controller 节点替换它。另外，还要保证节点可以和集群中的其它节点进行连接。

本节介绍了如何替换控制器节点。此过程包括运行 openstack overcloud deploy 命令来通过替换控制器节点的请求更新 overcloud。请注意，此过程不是完全自动的；在 overcloud 栈更新过程中，openstack overcloud deploy 命令会在某个时点上报告失败，overcloud 栈更新过程随之停止。这时，需要一些人工干预，然后 openstack overcloud deploy 进程才会继续。

(undercloud) $ openstack server list
+--------------------------------------+------------------------+
| ID                                   | Name                   |
+--------------------------------------+------------------------+
| 861408be-4027-4f53-87a6-cd3cf206ba7a | overcloud-compute-0    |
| 0966e9ae-f553-447a-9929-c4232432f718 | overcloud-compute-1    |
| 9c08fa65-b38c-4b2e-bd47-33870bff06c7 | overcloud-compute-2    |
| a7f0f5e1-e7ce-4513-ad2b-81146bc8c5af | overcloud-controller-0 |
| cfefaf60-8311-4bc3-9416-6a824a40a9ae | overcloud-controller-1 |
| 97a055d4-aefd-481c-82b7-4a5f384036d2 | overcloud-controller-2 |
+--------------------------------------+------------------------+

(undercloud) $ openstack baremetal node list
+--------------------------------------+------+--------------------------------------+
| UUID                                 | Name | Instance UUID                        |
+--------------------------------------+------+--------------------------------------+
| 36404147-7c8a-41e6-8c72-a6e90afc7584 | None | 7bee57cf-4a58-4eaf-b851-2a8bf6620e48 |
| 91eb9ac5-7d52-453c-a017-c0e3d823efd0 | None | None                                 |
| 75b25e9a-948d-424a-9b3b-f0ef70a6eacf | None | None                                 |
| 038727da-6a5c-425f-bd45-fda2f4bd145b | None | 763bfec2-9354-466a-ae65-2401c13e07e5 |
| dc2292e6-4056-46e0-8848-d6e96df1f55d | None | 2017b481-706f-44e1-852a-2ee857c303c4 |
| c7eadcea-e377-4392-9fc3-cf2b02b7ec29 | None | 5f73c7d7-4826-49a5-b6be-8bfd558f3b41 |
| da3a8d19-8a59-4e9d-923a-6a336fe10284 | None | cfefaf60-8311-4bc3-9416-6a824a40a9ae |
| 807cb6ce-6b94-4cd1-9969-5c47560c2eee | None | c07c13e6-a845-4791-9628-260110829c3a |
+--------------------------------------+------+--------------------------------------+

(undercloud) $ openstack baremetal node maintenance set da3a8d19-8a59-4e9d-923a-6a336fe10284

(undercloud) $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 75b25e9a-948d-424a-9b3b-f0ef70a6eacf

(undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs resource unmanage galera"

parameters:
  ControllerRemovalPolicies:
    [{'resource_list': ['1']}]

parameter_defaults:
  CorosyncSettleTries: 5

(undercloud) $ openstack overcloud deploy --templates --control-scale 3 -e ~/templates/remove-controller.yaml [OTHER OPTIONS]

(undercloud) $ openstack stack list --nested

$ source ~/stackrc
(undercloud) $ openstack overcloud deploy --templates --control-scale 3 [OTHER OPTIONS]

[heat-admin@overcloud-controller-0 ~]$ for i in $(sudo pcs property | grep overcloud-controller-0: | cut -d' ' -f 3- | tr  ' ' '\n' | grep role); do sudo pcs property set --node overcloud-controller-3 $i; done

[heat-admin@overcloud-controller-0 ~]$ sudo pcs status

[heat-admin@overcloud-controller-0 ~]$ exit

$ source ~/overcloudrc
(overcloud) $ neutron l3-agent-list-hosting-router r1

(overcloud) $ neutron agent-list | grep "neutron-l3-agent"

(overcloud) $ neutron l3-agent-router-add fd6b3d6e-7d8c-4e1a-831a-4ec1c9ebb965 r1
(overcloud) $ neutron l3-agent-router-remove b40020af-c6dd-4f7a-b426-eba7bac9dbc2 r1

(overcloud) $ neutron l3-agent-list-hosting-router r1

(overcloud) $ neutron agent-list -F id -F host | grep overcloud-controller-1
| ddae8e46-3e8e-4a1b-a8b3-c87f13c294eb | overcloud-controller-1.localdomain |
(overcloud) $ neutron agent-delete ddae8e46-3e8e-4a1b-a8b3-c87f13c294eb

[stack@director ~]$ source ~/overcloudrc
(overcloud) $ openstack compute service list --host overcloud-controller-1.localdomain

(overcloud) $ for SERVICE in $(openstack compute service list --host overcloud-controller-1.localdomain -f value -c ID) ; do openstack compute service delete $SERVICE ; done

director 提供了一个在 director 创建的集群中替换 Ceph Storage 节点的方法。相关说明可在 Red Hat Ceph Storage for the Overcloud 中找到。

本节介绍了如何在保持集群完整性的情况下替换 Object Storage 节点。在这个示例中，有一个带有 2 个节点 的 Object Storage 集群，它需要更换 overcloud-objectstorage-1 节点。我们需要添加一个额外的节点，然后移除 overcloud-objectstorage-1（实际上是替换它）。

director 从 overcloud 中删除对象存储节点，并更新 overcloud 中的其他节点来使删除生效。

您可以阻止 overcloud 节点获得更新的部署内容。这在某些情况下非常有用，比如，您准备扩展新节点，同时想阻止现有节点获得核心 Heat 集合中更新的参数集和资源。换句话说，列入黑名单的节点将完全不受栈操作的影响。

在环境文件中使用 DeploymentServerBlacklist 参数可创建黑名单。

parameter_defaults:
  DeploymentServerBlacklist:
    - overcloud-compute-0
    - overcloud-compute-1
    - overcloud-compute-2

将此环境文件纳入 openstack overcloud deploy 命令中。例如：

$ source ~/stackrc
(undercloud) $ openstack overcloud deploy --templates \
  -e server-blacklist.yaml \
  [OTHER OPTIONS]

Heat 会将列表中的任何服务器列入黑名单，阻止其获得更新的 Heat 部署内容。在栈操作完成后，黑名单中的服务器不会发生任何变化。您也可以在操作过程中关闭或停止 os-collect-config 代理。

parameter_defaults:
  DeploymentServerBlacklist: []

要重新引导 director 节点，请遵循此流程：

要重新引导 Controller 节点，请遵循此流程：

要重新引导 Ceph Storage 节点，请遵循此流程：

单独重新引导各 Compute 节点，确保您的 OpenStack Platform 环境中实例出现停机的时间为零。此操作涉及以下工作流：

列出所有的 Compute 节点及其 UUID：

$ source ~/stackrc
(undercloud) $ openstack server list --name compute

选择要重新引导的 Compute 节点，然后先按照以下流程迁移其实例：

按照以下流程，重新引导 Compute 节点

要重新引导 Object Storage 节点，请遵循此流程：

与节点注册相关的问题通常是因为不正确的节点详情造成的。在这种情况下，使用带有正确节点数据的 ironic 来解决相关的问题。以下是几个示例：

找到分配的端口 UUID：

$ source ~/stackrc
(undercloud) $ openstack baremetal port list --node [NODE UUID]

更新 MAC 地址：

(undercloud) $ openstack baremetal port set --address=[NEW MAC] [PORT UUID]

运行以下命令：

(undercloud) $ openstack baremetal node set --driver-info ipmi_address=[NEW IPMI ADDRESS] [NODE UUID]

內省（introspection）过程需要被正确完成。但是，如果发现 ramdisk 没有响应，ironic 的发现守护进程（ironic-inspector）会默认在一个小时后出现超时。在一些时候，这意味着发现 ramdisk 有问题，但通常情况下是因为不正确的环境配置，特别是 BIOS 引导设置。

以下是一些常见的不正确的环境配置情况，以及如果诊断和解决它们的建议。

$ source ~/stackrc
(undercloud) $ openstack baremetal node manage [NODE UUID]

当发现操作完成后，在进行部署前把状态改回到 AVAILABLE：

(undercloud) $ openstack baremetal node provide [NODE UUID]

$ source ~/stackrc
(undercloud) $ openstack baremetal introspection abort [NODE UUID]

您也可以等待操作过程出现超时。如有必要，将 /etc/ironic-inspector/inspector.conf 中的 timeout 设置更改为另一个时长（分钟）。

$ sudo systemctl list-units openstack-swift*

OpenStack Workflow（mistral）服务将多项 OpenStack 任务组合成工作流。Red Hat OpenStack Platform 使用一套这样的工作流来执行 CLI 和 Web UI 中的常见功能。其中包括裸机节点控制、验证、计划管理和 overcloud 部署。

例如，在运行 openstack overcloud deploy 命令时，OpenStack Workflow 服务执行两个工作流。第一个工作流上传部署计划：

Removing the current plan files
Uploading new plan files
Started Mistral Workflow. Execution ID: aef1e8c6-a862-42de-8bce-073744ed5e6b
Plan updated

第二个工作流启动 overcloud 部署：

Deploying templates in the directory /tmp/tripleoclient-LhRlHX/tripleo-heat-templates
Started Mistral Workflow. Execution ID: 97b64abe-d8fc-414a-837a-1380631c764d
2016-11-28 06:29:26Z [overcloud]: CREATE_IN_PROGRESS  Stack CREATE started
2016-11-28 06:29:26Z [overcloud.Networks]: CREATE_IN_PROGRESS  state changed
2016-11-28 06:29:26Z [overcloud.HeatAuthEncryptionKey]: CREATE_IN_PROGRESS  state changed
2016-11-28 06:29:26Z [overcloud.ServiceNetMap]: CREATE_IN_PROGRESS  state changed
...

$ source ~/stackrc
(undercloud) $ openstack workflow execution list | grep "ERROR"

获取已失败的工作流执行的 UUID（例如，dffa96b0-f679-4cd2-a490-4769a3825262）并查看执行信息及输出结果：

(undercloud) $ openstack workflow execution show dffa96b0-f679-4cd2-a490-4769a3825262
(undercloud) $ openstack workflow execution output show dffa96b0-f679-4cd2-a490-4769a3825262

通过这些可了解执行中失败的任务的相关信息。openstack workflow execution show 还显示执行时所用的工作流（例如，tripleo.plan_management.v1.publish_ui_logs_to_swift）。您可以使用以下命令查看完整的工作流定义：

(undercloud) $ openstack workflow definition show tripleo.plan_management.v1.publish_ui_logs_to_swift

这可用于辨别特定任务在工作流中的位置。

您也可以使用类似的命令语法查看操作执行及其结果：

(undercloud) $ openstack action execution list
(undercloud) $ openstack action execution show 8a68eba3-0fec-4b2a-adc9-5561b007e886
(undercloud) $ openstack action execution output show 8a68eba3-0fec-4b2a-adc9-5561b007e886

这可用于辨别导致问题的具体操作。

实施的过程可能会在 3 个层面出现问题：

如果 overcloud 的部署在以上任何层面中出现问题，可使用 OpenStack 客户端和服务日志文件来诊断失败的部署。

$ source ~/stackrc
(undercloud) $ openstack stack list --nested --property status=FAILED
+-----------------------+------------+--------------------+----------------------+
| id                    | stack_name | stack_status       | creation_time        |
+-----------------------+------------+--------------------+----------------------+
| 7e88af95-535c-4a55... | overcloud  | CREATE_FAILED      | 2015-04-06T17:57:16Z |
+-----------------------+------------+--------------------+----------------------+

$ source ~/stackrc
(undercloud) $ openstack baremetal node list

+----------+------+---------------+-------------+-----------------+-------------+
| UUID     | Name | Instance UUID | Power State | Provision State | Maintenance |
+----------+------+---------------+-------------+-----------------+-------------+
| f1e261...| None | None          | power off   | available       | False       |
| f0b8c1...| None | None          | power off   | available       | False       |
+----------+------+---------------+-------------+-----------------+-------------+

$ source ~/stackrc
(undercloud) $ openstack stack resource list overcloud --filter status=FAILED

(undercloud) $ openstack stack resource show overcloud [FAILED RESOURCE]

(undercloud) $ openstack server list

(undercloud) $ ssh heat-admin@192.168.24.14

[heat-admin@overcloud-controller-0 ~]$ sudo journalctl -u os-collect-config

(undercloud) $ openstack server list
(undercloud) $ openstack server show [SERVER ID]

当目标主机被分配了一个已在使用的 IP 地址时，发现和部署任务将会失败。为了避免这个问题，可以对 Provisioning 网络进行一个端口扫描，从而决定发现的 IP 范围和主机的 IP 范围是否可用。

在 undercloud 主机上执行以下步骤：

安装 nmap:

$ sudo yum install nmap

使用 nmap 命令扫描 IP 地址范围中的活动地址。这个示例会扫描 192.168.24.0/24 这个范围，使用 Provisioning 网络的 IP 子网值（使用 CIDR 位掩码符号 ）替换它：

$ sudo nmap -sn 192.168.24.0/24

检查 nmap 扫描的结果输出：

例如，您应该看到 undercloud 的 IP 地址，以及该子网中的任何其他主机。如果这些活跃的 IP 地址和 undercloud.conf 中指定的 IP 地址范围有冲突，则需要在内省或部署overcloud 节点前修改 IP 地址范围或释放一些 IP 地址。

$ sudo nmap -sn 192.168.24.0/24

Starting Nmap 6.40 ( http://nmap.org ) at 2015-10-02 15:14 EDT
Nmap scan report for 192.168.24.1
Host is up (0.00057s latency).
Nmap scan report for 192.168.24.2
Host is up (0.00048s latency).
Nmap scan report for 192.168.24.3
Host is up (0.00045s latency).
Nmap scan report for 192.168.24.5
Host is up (0.00040s latency).
Nmap scan report for 192.168.24.9
Host is up (0.00019s latency).
Nmap done: 256 IP addresses (5 hosts up) scanned in 2.45 seconds

在一些情况下，/var/log/nova/nova-conductor.log 包括了以下错误：

NoValidHost: No valid host was found. There are not enough hosts available.

这意味着 nova Scheduler 无法找到合适的裸机节点来引导新的实例。造成这个问题的原因通常是 nova 所期望的资源和 Ironic 通知给 Nova 的资源不匹配。检查以下内容：

在创建完 overcloud 后，可能还会需要在以后执行特定的 overcloud 操作。例如，可能会需要扩展可用节点，或替换出现故障的节点。在执行这些操作时，可能会出现某些问题。本节就如何对出现失败的创建后操作进行诊断和故障排除提供一些建议。

本节中提供的建议旨在帮助提高 undercloud 的性能。您可以根据自己的需要实施相关的建议。

如果您需要与红帽联系获得 OpenStack Platform 的产品支持，可能需要生成一份 sosreport。如需了解有关如何创建 sosreport 的更多信息，请参阅以下知识库文章：

在故障排除时，使用以下日志查找 undercloud 和 overcloud 的信息。