undercloud 是控制最终 OpenStack 平台环境（称为 overcloud）的配置、安装和管理的节点。undercloud 本身以容器的形式使用 OpenStack 平台组件来创建红帽称作 OpenStack Platform director 的工具组。这意味着，undercloud 从注册表来源拉取一组镜像容器，生成容器的配置，然后以容器的形式运行各项 OpenStack Platform 服务。因此，undercloud 提供一组容器化的服务集合，作为用于创建和管理 overcloud 的工具组。

undercloud 和 overcloud 都使用容器，它们使用相同的架构来拉取、配置和运行容器。这种架构依赖 OpenStack Orchestration 服务（称为 Heat）来置备和配置节点，通过 Ansible 来配置服务和容器。建议您对 Heat 和 Ansible 有一定的了解，这将有助于对问题进行故障排除。

undercloud 需要访问两个主要网络：

也就是说，undercloud 需要最少两张 1 Gbps 网卡。不过，建议为 Provisioning 网络流量使用 10 Gbps 接口，特别是在 overcloud 环境中置备大量节点时。

请注意：

在安装 undercloud 之前，有必要先确定环境的规模。要规划的因素包括：

undercloud 的 CPU和内存最低要求：

如果希望使用更大数量的 worker，您的 undercloud 将需要更多的 vCPU 和内存。请遵循以下建议：

对于 undercloud，建议的下限为根磁盘上提供有 100 GB 的可用磁盘空间。这包括：

安装和配置 undercloud 需要下列软件仓库。

安装 director 需要准备好以下几项：

undercloud 配置需要一些初始注册表配置来确定从何处获取镜像以及如何存储它们。以下过程演示了如何生成并定制准备容器镜像所需的环境文件。

这个用于准备容器的默认文件 (containers-prepare-parameter.yaml) 中含有 ContainerImagePrepare Heat 参数。此参数定义一个用于准备一系列镜像的策略列表：

parameter_defaults:
  ContainerImagePrepare:
  - (strategy one)
  - (strategy two)
  - (strategy three)
  ...

每一策略接受一组子参数，它们定义要使用哪些镜像以及如何对待它们。下表中列出了用于各项 ContainerImagePrepare 策略的子参数：

set 参数接受一组 key: value 定义。下表列出了这些键：

ContainerImagePrepare 的值是一个 YAML 列表。这意味着您可以指定多个条目。下例中包括了两个条目；在这个示例中，director 使用所有镜像的最新版本，但 nova-api 镜像除外，它使用标记为 14.0-44 的版本：

ContainerImagePrepare:
- tag_from_label: "{version}-{release}"
  push_destination: true
  excludes:
  - nova-api
  set:
    namespace: registry.access.redhat.com/rhosp14
    name_prefix: openstack-
    name_suffix: ''
    tag: latest
- push_destination: true
  includes:
  - nova-api
  set:
    namespace: registry.access.redhat.com/rhosp14
    tag: 14.0-44

includes 和 excludes 条目控制如何过滤各个条目的镜像。匹配 includes 策略的镜像的优先级高于 excludes 匹配项。镜像名称中必须包含相应的值，才能被视为匹配项。

执行 prepare 期间，可以修改镜像来进行必要的更改，然后立即使用这些更改进行部署。修改镜像的用例包括：

通过对各个需要修改的镜像调用 Ansible 角色来完成修改。角色会提取源镜像，进行请求的更改，然后标记结果。然后，prepare 命令会推送镜像，并设置指示已修改镜像的 heat 参数。

Ansible 角色 tripleo-modify-image 遵守必要的角色接口，为 modify 用例提供所需的行为。通过 ContainerImagePrepare 参数中的 modify 相关键来控制修改：

由 tripleo-modify-image 角色处理的不同用例通过将 tasks_from 变量设置为角色中所需的文件来选定。

在开发和测试用于修改镜像的 ContainerImagePrepare 条目时，建议您单独运行 prepare 以确认它的修改是否与预期相符：

sudo openstack tripleo container image prepare \
  -e ~/containers-prepare-parameter.yaml

以下条目将生成要在镜像中更新的所有软件包，但使用 undercloud 主机的 yum 软件仓库配置：

ContainerImagePrepare:
- push_destination: true
  ...
  modify_role: tripleo-modify-image
  modify_append_tag: "-updated"
  modify_vars:
    tasks_from: yum_update.yml
    compare_host_packages: true
    yum_repos_dir_path: /etc/yum.repos.d
  ...

可以安装一系列的 RPM 文件，这些文件可用于安装热修复补丁、本地软件包构建，或无法通过软件包仓库提供的软件包。例如，以下代码仅在 centos-binary-nova-compute 镜像中安装一些热修复补丁软件包：

ContainerImagePrepare:
- push_destination: true
  ...
  includes:
  - nova-compute
  modify_role: tripleo-modify-image
  modify_append_tag: "-hotfix"
  modify_vars:
    tasks_from: rpm_install.yml
    rpms_path: /home/stack/nova-hotfix-pkgs
  ...

为获得最大的灵活性，可以指定一个含有 Dockerfile 的目录来进行所需的修改。当角色被调用时，会生成 Dockerfile.modified，它将更改 FROM 指令并添加额外的 LABEL 指令。以下示例对 centos-binary-nova-compute 镜像运行自定义 Dockerfile：

ContainerImagePrepare:
- push_destination: true
  ...
  includes:
  - nova-compute
  modify_role: tripleo-modify-image
  modify_append_tag: "-hotfix"
  modify_vars:
    tasks_from: modify_image.yml
    modify_dir_path: /home/stack/nova-custom
  ...

后面提供了示例 /home/stack/nova-custom/Dockerfile。请注意，运行了任何 USER root 指令后，需要重新切换到原先镜像默认用户：

FROM docker.io/tripleomaster/centos-binary-nova-compute:latest

USER root

COPY customize.sh /tmp/
RUN /tmp/customize.sh

USER "nova"

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

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

以下是含有特定于 Satellite 的参数的示例环境文件：

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: true
    set:
      ceph_image: acme-production-myosp14-osp14_containers-rhceph-3-rhel7
      ceph_namespace: satellite.example.com:5000
      ceph_tag: latest
      name_prefix: acme-production-myosp14-osp14_containers-
      name_suffix: ''
      namespace: satellite.example.com:5000
      neutron_driver: null
      tag: latest
      ...
    tag_from_label: '{version}-{release}'

在创建 undercloud 和 overcloud 时使用此环境文件。

在安装 director 时，需要使用特定的设置来决定您的网络配置。这些设置存储在 stack 用户的主目录内的一个模板中，即 undercloud.conf。以下操作过程展示了如何基于这个默认模板来进行配置。

下方列出了可用于配置 undercloud.conf 文件的各种参数。

[ctlplane-subnet]
cidr = 192.168.24.0/24
dhcp_start = 192.168.24.5
dhcp_end = 192.168.24.24
inspection_iprange = 192.168.24.100,192.168.24.120
gateway = 192.168.24.1
masquerade = true

您可以根据自身环境所需来指定相应数量的置备网络。

请根据您的配置所需来修改上述参数的值。完成后，请保存文件。

以下操作过程旨在安装 director 并执行一些基本的安装后任务。

director 的安装已完成。您现在可以使用 director 的命令行工具了。

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

以下操作过程旨在展示如何获取并安装这些镜像。

如果您希望 overcloud 解析外部主机名，如 cdn.redhat.com，建议您在 overcloud 节点上设置名称服务器。对于没有进行网络隔离的标准 overcloud，名称服务器会使用 undercloud 的控制平面子网来定义。请按照以下过程操作，以定义环境的名称服务器。

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

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

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

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

规划环境中的网络拓扑结构和子网非常重要，这样您可以把角色和服务进行正确的映射，从而使它们可以互相进行正确的通信。Red Hat OpenStack Platform 使用 Openstack Networking (neutron) 服务，此服务可自主运行，并可管理基于软件的网络、静态和浮动 IP 地址以及 DHCP。

默认情况下，director 将节点配置为使用 Provisioning / Control Plane 进行连接。不过，可以将网络流量隔离到一系列的可组合网络，供您自定义和分配服务。

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

director 也提供一系列模板，来配置具有隔离的可组合网络的 NIC。默认的配置为：

您也可以创建自己的模板来映射特定的 NIC 配置。

在思考您的网络配置时，以下细微细节也很重要：

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

OpenStack 平台环境的安全性在一定程度上取决于网络的安全性。在您的网络环境中使用适当的安全性措施来确保可以正确地控制网络访问。例如：

如需了解更多与系统安全相关的信息，请参阅：

要部署高度可用的 overcloud，director 将配置多个 Controller、Compute 和 Storage 节点，并以单一集群的形式协同工作。出现节点故障时，根据故障的节点来触发自动隔离和重新生成流程。有关 overcloud 高可用性架构和服务的信息，请参阅 Understanding Red Hat OpenStack Platform High Availability。

您也可以通过 director 为 Compute 实例配置高可用性 (Instance HA)。这种机制可以在节点故障时在 Compute 节点上自动清空和重新生成实例。Instance HA 的要求与一般的 overcloud 要求相同，但您必须通过执行额外的步骤来准备部署环境。有关 Instance HA 工作方式和安装说明的信息，请参阅 High Availability for Compute Instances 指南。

Controller 节点用来托管 RHEL OpenStack 平台环境中的核心服务，如 Horizon 仪表板、后端数据库服务器、Keystone 认证和 High Availability 服务。

Compute 节点负责运行虚拟机实例。它们必须支持硬件虚拟化，并需要有足够的内存和磁盘空间来支持它们所运行的虚拟机。

Ceph Storage 节点负责在 Red Hat OpenStack Platform 环境中提供对象存储。

如需了解更多有关安装使用 Ceph Storage 集群的 overcloud 的信息，请参阅 Deploying an Overcloud with Containerized Red Hat Ceph 指南。

Object Storage 节点提供 overcloud 的对象存储层。Object Storage 代理安装在控制器节点上。存储层要求每一个裸机节点装有多个磁盘。

安装和配置 undercloud 需要下列软件仓库。

director 需要一个节点定义模板，这个模板由您手动创建。此文件采用 JSON 或 YAML 格式，其中包含节点的详细硬件和电源管理信息。

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

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

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

默认引导模式是传统 BIOS 模式。新式系统可能要求使用 UEFI 引导模式，而非传统 BIOS 模式。下列步骤可用来更改为 UEFI 模式。

一些节点可能会使用多个磁盘。这意味着 director 需要识别在置备过程中作为根磁盘的磁盘。在置备过程中，director 将 QCOW2 overcloud-full 镜像写入到根磁盘。

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

本例演示了如何使用序列号指定根设备。

在构建多云架构时，需要将特定于架构的角色添加到 roles_data.yaml 中。以下是一个同时包含 ComputePPC64LE 角色和默认角色的示例。如需与角色相关的信息，可参阅 Creating a Custom Role File 小节。

openstack overcloud roles generate \
    --roles-path /usr/share/openstack-tripleo-heat-templates/roles -o ~/templates/roles_data.yaml \
    Controller Compute ComputePPC64LE BlockStorage ObjectStorage CephStorage

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

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

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

下面几节演示如何为您的 overcloud 创建所需环境。

默认情况下，director 部署具有 1 个 Controller 节点和 1 个 Compute 节点的 overcloud，节点的类型是 baremetal。不过，这仅适用于概念验证部署。您可以通过指定不同的节点数目和类型来覆盖默认配置。对于小型生产环境，您可能要考虑至少 3 个 Controller 节点和 3 个 Compute 节点，并且分配特定的类型来确保使用适当的资源规格来创建节点。以下过程演示了如何创建名为 node-info.yaml 的环境文件，该文件用于存储节点数目和类型分配情况。

如果您的 undercloud 使用 TLS 且其 CA 不是公共信任的，您需要遵照此过程操作。undercloud 运行自己的证书颁发机构 (CA) 来进行 SSL 端点加密。要让 undercloud 端点可被部署中的其余部分访问，请将 overcloud 配置为信任 undercloud CA。

undercloud 中可以使用两种类型的自定义证书：

在 overcloud 部署期间，CA 证书会复制到各个 overcloud 节点，使它信任 undercloud 的 SSL 端点提供的加密。如需关于如何包含环境文件的更多信息，请参阅 第 6.12 节 “在 overcloud 部署中包括环境文件”。

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

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

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

(undercloud) $ openstack help overcloud deploy

某些命令行参数已过时或已弃用，它们的功能可以通过环境文件的 parameter_defaults 部分中所包含的 Heat 模板参数实现。下表将已弃用的参数与 Heat 模板中的等效参数对应了起来。

这些参数计划从未来的 Red Hat OpenStack Platform 版本中移除。

使用 -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 /home/stack/inject-trust-anchor-hiera.yaml
  -r /home/stack/templates/roles_data.yaml \

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

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

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

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

在执行 overcloud 部署操作前，先验证您的 Heat 模板和环境文件，确认是否存在任何错误。

一旦 overcloud 创建完毕，director 会提供为配置 overcloud 而执行的 Ansible play 的总结：

PLAY RECAP *************************************************************
overcloud-compute-0     : ok=160  changed=67   unreachable=0    failed=0
overcloud-controller-0  : ok=210  changed=93   unreachable=0    failed=0
undercloud              : ok=10   changed=7    unreachable=0    failed=0

Tuesday 15 October 2018  18:30:57 +1000 (0:00:00.107) 1:06:37.514 ******
========================================================================

director 还会提供用于访问 overcloud 的详细信息。

Ansible passed.
Overcloud configuration completed.
Overcloud Endpoint: http://192.168.24.113:5000
Overcloud Horizon Dashboard URL: http://192.168.24.113:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed

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 的步骤到此结束。有关创建后的功能，请参阅第 9 章 创建 overcloud 后执行的任务。

用户可以使用 undercloud.conf 文件中的 undercloud_public_host 参数所指定的 IP 地址来通过 SSL 访问 director 的 web UI。例如， undercloud 的公共 IP 地址为 192.168.24.2，则可以通过 https://192.168.24.2 来访问 UI。

web UI 会首先显示带有以下字段的登录界面：

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

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.3 节 “为节点添加标签以加入到配置集”>）。

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

标记一组节点：

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

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

3 Configure Roles and Assign Nodes 部分的右下角是 Manage Roles 图标。

单击该图标后，会显示一组卡片，它们分别代表着可添加到环境中的各种角色。要添加某个角色，请选中该角色右上角的复选框。

选好角色后，请单击 Save Changes。

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

要将节点分配到角色，请滚动到 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 计划后，您可以开始部署 overcloud。具体操作包括滚动到 6 Deploy 区域，并单击 Validate and Deploy。

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

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

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

等待 overcloud 部署完成。

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

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

通过 director UI 创建 overcloud 的步骤到此结束。如需了解创建后功能，请参阅第 9 章 创建 overcloud 后执行的任务。

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

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

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

如果 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 节点网络的情境提供额外配置。

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

在配置预置备的节点时，您需要将基于 Heat 的主机名映射到它们的实际主机名，以便 ansible-playbook 可以访问可解析的主机。请使用 HostnameMap 来映射这些值。

overcloud 部署使用来自 第 6.10 节 “部署命令” 的标准 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 \
  -e /home/stack/templates/hostname-map.yaml /
  -r /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-server-roles-data.yaml
  --overcloud-ssh-user stack \
  --overcloud-ssh-key ~/.ssh/id_rsa \
  [OTHER OPTIONS]

--overcloud-ssh-user 和 --overcloud-ssh-key 选项用于在配置阶段通过 SSH 连接每个 overcloud 节点，创建初始 tripleo-admin 用户，以及将 SSH 密钥注入 /home/tripleo-admin/.ssh/authorized_keys。要注入 SSH 密钥，用户可以使用 --overcloud-ssh-user 和 --overcloud-ssh-key（默认值为 ~/.ssh/id_rsa）为初始 SSH 连接指定凭证。为免泄露使用 --overcloud-ssh-key 指定的私钥，director 不会向任何 API 服务（如 Heat 或 MIstral）传递这个密钥，而且只有 director 的 openstack overcloud deploy 命令会用这个密钥为 tripleo-admin 用户启用访问权限。

一旦 overcloud 创建完毕，director 会提供为配置 overcloud 而执行的 Ansible play 的总结：

PLAY RECAP *************************************************************
overcloud-compute-0     : ok=160  changed=67   unreachable=0    failed=0
overcloud-controller-0  : ok=210  changed=93   unreachable=0    failed=0
undercloud              : ok=10   changed=7    unreachable=0    failed=0

Tuesday 15 October 2018  18:30:57 +1000 (0:00:00.107) 1:06:37.514 ******
========================================================================

director 还会提供用于访问 overcloud 的详细信息。

Ansible passed.
Overcloud configuration completed.
Overcloud Endpoint: http://192.168.24.113:5000
Overcloud Horizon Dashboard URL: http://192.168.24.113:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed

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

(undercloud) $ source ~/overcloudrc

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

(overcloud) $

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

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

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

扩展预置备节点的一般流程包括下列步骤：

在大多数缩放操作中，您必须获取节点的 UUID 值，以传递给 openstack overcloud node delete。要获取此 UUID，请列出供特定角色使用的资源：

$ openstack stack resource list overcloud -c physical_resource_id -c stack_name -n5 --filter type=OS::TripleO::<RoleName>Server

将上述命令中的 <RoleName> 替换为您要缩减的角色的实际名称。例如，对于 ComputeDeployedServer 角色：

$ openstack stack resource list overcloud -c physical_resource_id -c stack_name -n5 --filter type=OS::TripleO::ComputeDeployedServerServer

使用命令输出中的 stack_name 列来识别与各个节点相关的 UUID。stack_name 包含节点在 Heat 资源组中的索引的整数值。例如，在以下示例输出中：

+------------------------------------+----------------------------------+
| physical_resource_id               | stack_name                       |
+------------------------------------+----------------------------------+
| 294d4e4d-66a6-4e4e-9a8b-           | overcloud-ComputeDeployedServer- |
| 03ec80beda41                       | no7yfgnh3z7e-1-ytfqdeclwvcg      |
| d8de016d-                          | overcloud-ComputeDeployedServer- |
| 8ff9-4f29-bc63-21884619abe5        | no7yfgnh3z7e-0-p4vb3meacxwn      |
| 8c59f7b1-2675-42a9-ae2c-           | overcloud-ComputeDeployedServer- |
| 2de4a066f2a9                       | no7yfgnh3z7e-2-mmmaayxqnf3o      |
+------------------------------------+----------------------------------+

stack_name 列中的索引 0、1 或 2 对应于 Heat 资源组中的节点次序。将 physical_resource_id 列中的对应 UUID 值传递到 openstack overcloud node delete 命令。

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

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

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

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

通过预置备节点创建 overcloud 的流程到此结束。如需了解创建之后的功能，请参阅 第 9 章 创建 overcloud 后执行的任务。

要检查 overcloud 的部署状态，可使用 openstack overcloud status 命令。此命令的输出会报告所有部署步骤的结果。

OpenStack 平台在 undercloud 和 overcloud 节点上的容器中运行服务。在某些情况下，您可能需要控制主机上的单个服务。本节介绍了一些可在节点上运行以管理容器化服务的常用 docker 命令。如需更加全面地了解有关使用 docker 管理容器的信息，请参阅 Getting Started with Containers 指南中的“Working with Docker formatted containers”。

$ sudo docker ps

如果还要列出已停止或已失败的容器，请在命令中加入 --all 选项：

$ sudo docker ps --all

要列出容器镜像，请使用以下命令：

$ sudo docker images

$ sudo docker inspect keystone

$ sudo docker restart keystone

要停止容器化服务，请使用 docker stop 命令。例如，要停止 keystone 容器，请使用以下命令：

$ sudo docker stop keystone

要启动已停止的容器化服务，请使用 docker start 命令。例如，要启动 keystone 容器，请使用以下命令：

$ sudo docker start keystone

$ sudo docker logs keystone

$ sudo docker exec -it keystone /bin/bash

要以 root 用户的身份进入 keystone 容器的 shell，请使用以下命令：

$ sudo docker exec --user 0 -it <NAME OR ID> /bin/bash

要退出容器，请使用以下命令：

# exit

docker exec -ti -u swift swift_object_server swift-ring-builder /etc/swift/object.builder

如果您需要这些命令，请以 stack 用户身份将下列软件包安装到 undercloud 上，或者以 heat-admin 用户身份安装到 overcloud 上：

sudo yum install -y python-swift
sudo yum install -y python2-swiftclient

如需了解有关对 OpenStack 平台容器化服务进行故障诊断的信息，请参阅第 16.7.3 节 “容器化服务故障”。

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 池。另外，它对第 9.8 节 “验证 overcloud”中所述的验证测试也非常重要。

此命令还会将网络映射到 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 的流量传送到供应商网络。

本指南中的步骤假定您的安装中包含有类型 (flavor)。如果您还没有创建任何类型，请使用下列命令来创建一个基本的默认类型集合，它们具有一系列的存储和处理功能：

$ openstack flavor create m1.tiny --ram 512 --disk 0 --vcpus 1
$ openstack flavor create m1.smaller --ram 1024 --disk 0 --vcpus 1
$ openstack flavor create m1.small --ram 2048 --disk 10 --vcpus 1
$ openstack flavor create m1.medium --ram 3072 --disk 10 --vcpus 2
$ openstack flavor create m1.large --ram 8192 --disk 10 --vcpus 4
$ openstack flavor create m1.xlarge --ram 8192 --disk 10 --vcpus 8

使用 $ openstack flavor create --help 来进一步了解 openstack flavor create 命令。

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 命令。例如，如果根据 第 6.10 节 “部署命令” 创建了一个 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

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

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

如果您有一个已存在的 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

为了避免无意中使用 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。

Identity 服务 (keystone) 会使用基于令牌的系统来控制对其他 OpenStack 服务的访问。在运行了一定时间后，数据库中会积累大量未使用的令牌；默认的 cron 作业每天都会刷新令牌表。建议您对自己的环境进行监控并按需调整令牌刷新间隔。

对于 overcloud，可以使用 KeystoneCronToken 值来调整间隔。如需了解更多信息，请参阅 Overcloud Parameters 指南。

config-download 功能是 director 用于配置 overcloud 的方法。director 将 config-download 与 OpenStack Orchestration (heat) 和 OpenStack Workflow Service (mistral) 结合，来生成软件配置并将它应用到各个 overcloud 节点。虽然 Heat 会从 SoftwareDeployment 资源创建用来执行 overcloud 安装和配置的所有部署数据，但它不应用任何配置。Heat 仅通过其 API 提供配置数据。一旦 director 创建了堆栈，Mistral 工作流会通过查询 Heat API 来获取配置数据，生成一系列 Ansible playbook，然后将这些 Ansible playbook 应用到 overcloud。

作为结果，在运行 openstack overcloud deploy 命令时后会发生以下操作：

director 生成一组 Ansible playbook 以用于 config-download 过程。这些 playbook 存储在 /var/lib/mistral/ 下的工作目录中。此目录依据 overcloud 的名称来命名，默认为 overcloud。

工作目录中包含一组按照各个 overcloud 角色命名的子目录。这些子目录包含与 overcloud 角色中节点配置相关的所有任务。此外，也包含按照各个具体节点命名的其他子目录。这些子目录包含可应用到 overcloud 角色任务的节点相关变量。因此，工作目录中的 overcloud 角色采用下列结构：

─ /var/lib/mistral/overcloud
  |
  ├── Controller
  │   ├── overcloud-controller-0
  |   ├── overcloud-controller-1
  │   └── overcloud-controller-2
  ├── Compute
  │   ├── overcloud-compute-0
  |   ├── overcloud-compute-1
  │   └── overcloud-compute-2
  ...

每个工作目录也充当本地 Git 软件仓库，记录各个部署操作后的更改。这可帮助您跟踪各部署之间的配置更改。

OpenStack Workflow Service (mistral) 容器中的 mistral 用户拥有 /var/lib/mistral/ 工作目录中的所有文件。您可以向 undercloud 上的 stack 用户授予访问这个目录中所有文件的权限。这有助于在该目录中执行特定的操作。

在 config-download 过程中，Ansible 会在 undercloud 上的 config-download 工作目录中创建一个日志文件。

/var/lib/mistral/overcloud 中的工作目录包含所需的 playbook 和脚本，可直接与 ansible-playbook 交互。以下操作过程介绍了如何与这些文件交互。

config-download 工作目录充当本地 Git 软件仓库。每次运行部署操作时，director 会向工作目录添加一个包含相关更改的 Git 提交。这样，您可以通过执行 Git 操作来查看不同阶段的部署配置，并将配置与其他部署进行比较。

请注意工作目录的限制。例如，使用 Git 恢复到上一版本的 config-download 工作目录仅影响这个工作目录中的配置，而不会影响以下所列：

以下操作过程演示了如何使用 Git 来比较 config-download 工作目录的提交。

在某些情形中，您可能要在标准工作流之外生成自己的 config-download 文件。例如，您可能希望结合使用 --stack-only 选项和 openstack overcloud deploy 命令来生成 overcloud Heat 堆栈，从而能单独应用配置。以下操作过程演示了如何手动创建自己的 config-download 文件。

这为您提供必要的文件，以使用手动生成的 config-download 文件来执行配置。要执行部署 playbook，请运行 ansible-playbook 命令：

$ ansible-playbook \
  -i inventory.yaml \
  --private-key ~/.ssh/id_rsa \
  --become \
  ~/config-download/deploy_steps_playbook.yaml

要从此配置中手动生成 overcloudrc 文件，请运行以下命令：

$ openstack action execution run \
  --save-result \
  --run-sync \
  tripleo.deployment.overcloudrc \
  '{"container":"overcloud"}' \
  | jq -r '.["result"]["overcloudrc.v3"]' > overcloudrc.v3

以下是 config-download 工作目录中的重要顶层文件。

playbooks 使用标签任务来控制应用到 overcloud 的任务。将标签与 ansible-playbook CLI 参数 --tags 或 --skip-tags 结合使用，以控制要执行的任务。启用的标签有：

deploy_steps_playbook.yaml playbook 用于配置 overcloud。它将应用所有需要的软件配置，以根据 overcloud 部署计划部署完整的 overcloud。

本节总结这个 playbook 中使用的不同 Ansible play。本节中的 play 名称是 playbook 中使用的相同名称，也显示在 ansible-playbook 输出中。下方还显示了每个 play 中设置的 Ansible 标签。

现在，您可以继续执行常规的 overcloud 操作。

完成下列步骤，向 director 节点池添加更多节点。

完成以下步骤来扩展特定角色的 overcloud 节点，如 Compute 节点。

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

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

您可以使用 director 来替换 director 创建的集群中的 Ceph Storage 节点。相关说明可在 Deploying an Overcloud with Containerized Red Hat Ceph 指南中找到。

参考本节中的说明，了解如何在保持集群完整的同时替换 Object Storage 节点。本例涉及一个双节点 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: []

在尝试替换 overcloud 控制器节点前，务必要检查Red Hat OpenStack Platform环境的当前状态；此检查有助于避免在替换控制器节点的过程中出现混乱。参照以下初步检查列表，确定是否可以安全地执行控制器节点替换。在 undercloud 中执行这些检查的所有命令。

按照这个操作过程操作，从存储集群中删除 ceph-mon 守护进程。如果 Controller 节点正在运行 Ceph 监控器服务，请完成以下步骤以删除 ceph-mon 守护进程。这个操作过程假设 Controller 可供连接。

在替换旧节点前，您必须确保节点上不再运行 Pacemaker，然后将该节点从 Pacemaker 集群中删除。

要替换 Controller 节点，请确定您要替换的节点的索引。

完成下方的示例步骤，将 overcloud-controller-1 节点替换为 overcloud-controller-3 节点。overcloud-controller-3 节点的 ID 是 75b25e9a-948d-424a-9b3b-f0ef70a6eacf。

完成以下步骤，以删除旧的 Controller 节点，并将它替换为新的 Controller 节点。

完成节点替换后，执行以下步骤来完善 Controller 集群。

以下操作过程旨在重新引导 undercloud 节点。

以下操作过程旨在基于可组合角色重新引导 Controller 节点和独立节点，其中不包括 Compute 节点和 Ceph Storage 节点。

以下操作过程旨在重新引导一个由 Ceph Storage (OSD) 节点构成的集群。

以下操作过程旨在重新引导 Compute 节点。为确保最大限度地缩短 OpenStack 平台环境中的实例停机时间，这个操作过程还提供了有关从选定 Compute 节点迁移实例的说明。其中会涉及以下工作流：

要在 available 节点上执行一个内省操作，请将该节点设置为管理模式，然后执行该内省操作：

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

内省完成后，节点会变为 available 状态。

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

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

内省完成后，所有节点都会变为 available 状态。

网络内省会从网络交换机获取链路层发现协议 (LLDP) 数据。以下命令可显示某个节点上所有接口的某个 LLDP 信息子集，或显示某个节点和接口的全部信息。这对故障排除非常有用。director 默认会启用 LLDP 数据收集。

获取节点上的接口列表：

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

例如：

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

查看接口数据和交换机端口信息：

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

例如：

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

例如，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
    }
  ]
}

如果拥有异构硬件环境，您可以使用内省规则来分配凭证和远程管理凭证。例如，您可能需要单独的发现规则来处理使用 DRAC 的 Dell 节点：

与节点注册相关的问题通常是因为不正确的节点详情造成的。在这种情况下，使用带有正确节点数据的 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       |
+----------+------+---------------+-------------+-----------------+-------------+

当目标主机被分配了一个已在使用的 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 操作。例如，可能会需要扩展可用节点，或替换出现故障的节点。在执行这些操作时，可能会出现某些问题。本节就如何对出现失败的创建后操作进行诊断和故障排除提供一些建议。

$ sudo docker logs keystone

$ sudo docker inspect keystone

$ sudo docker inspect keystone | jq .[0].Mounts

$ sudo docker inspect --format='{{range .Config.Env}} -e "{{.}}" {{end}} {{range .Mounts}} -v {{.Source}}:{{.Destination}}{{if .Mode}}:{{.Mode}}{{end}}{{end}} -ti {{.Config.Image}}' keystone

$ OPTIONS=$( sudo docker inspect --format='{{range .Config.Env}} -e "{{.}}" {{end}} {{range .Mounts}} -v {{.Source}}:{{.Destination}}{{if .Mode}}:{{.Mode}}{{end}}{{end}} -ti {{.Config.Image}}' keystone )
$ sudo docker run --rm $OPTIONS /bin/bash

$ sudo docker exec -ti keystone <COMMAND>

$ sudo docker exec -ti keystone /openstack/healthcheck

$ sudo docker exec -ti keystone /bin/bash

$ sudo docker export keystone -o keystone.tar

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

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

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