第 6 章 使用 CLI 工具配置基本的 overcloud


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

6.1. 为 overcloud 注册节点

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

步骤

  1. 创建一个模板来列出您的节点。例如,采用 JSON 格式的模板可能如下方所示:

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

    或者,YAML 格式的类似节点模板可能如下方所示:

    nodes:
      - mac:
          - "bb:bb:bb:bb:bb:bb"
        name: "node01"
        cpu: 4
        memory: 6144
        disk: 40
        arch: "x86_64"
        pm_type: "ipmi"
        pm_user: "admin"
        pm_password: "p@55w0rd!"
        pm_addr: "192.168.24.205"
      - mac:
          - cc:cc:cc:cc:cc:cc
        name: "node02"
        cpu: 4
        memory: 6144
        disk: 40
        arch: "x86_64"
        pm_type: "ipmi"
        pm_user: "admin"
        pm_password: "p@55w0rd!"
        pm_addr: "192.168.24.206"
    Copy to Clipboard Toggle word wrap

    这个模板使用以下属性:

    name
    节点的逻辑名称。
    pm_type

    要使用的电源管理驱动程序。本例中使用 IPMI 驱动程序 (ipmi),这是首选的电源管理驱动程序。

    注意

    IPMI 是首选的受支持电源管理驱动程序。如需更多受支持的电源管理类型及其选项,请参阅 附录 B, 电源管理驱动。如果这些电源管理驱动程序不能正常工作,请将 IPMI 用于电源管理。

    pm_user; pm_password
    IPMI 的用户名和密码。
    pm_addr
    IPMI 设备的 IP 地址。
    mac
    (可选)节点上网络接口的 MAC 地址列表。对于每个系统的 Provisioning NIC,只使用 MAC 地址。
    cpu
    节点上的 CPU 数量。(可选)
    memory
    以 MB 为单位的内存大小。(可选)
    disk
    以 GB 为单位的硬盘的大小。(可选)
    arch

    系统架构。(可选)

    重要

    在构建多架构云时,arch 键是必需的,用于区分使用 x86_64ppc64le 架构的节点。

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

    $ source ~/stackrc
    (undercloud) $ openstack overcloud node import ~/nodes.json
    Copy to Clipboard Toggle word wrap

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

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

    (undercloud) $ openstack baremetal node list
    Copy to Clipboard Toggle word wrap

6.2. 检查节点的硬件

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

步骤

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

    (undercloud) $ openstack overcloud node introspect --all-manageable --provide
    Copy to Clipboard Toggle word wrap
    • --all-manageable 选项仅内省处于受管理状态的节点。本例中为所有节点。
    • --provide 选项会在内省后将所有节点重置为 available 状态。
  2. 在一个单独的终端窗口中运行以下命令来监测内省的进程:

    (undercloud) $ sudo journalctl -l -u openstack-ironic-inspector -u openstack-ironic-inspector-dnsmasq -u openstack-ironic-conductor -f
    Copy to Clipboard Toggle word wrap
    重要

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

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

6.3. 为节点添加标签以加入到配置集

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

Expand
类型描述

角色

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

类型

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

配置集

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

节点

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

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

步骤

  1. 为了通过添加标签把节点标记为特定的配置集,把 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
    Copy to Clipboard Toggle word wrap

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

    这些命令还设置 boot_option:local 参数,该参数用于定义每个节点的引导方式。

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

    (undercloud) $ openstack overcloud profiles list
    Copy to Clipboard Toggle word wrap

6.4. 设置 UEFI 引导模式

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

步骤

  1. undercloud.conf 文件中设置下列参数:

    ipxe_enabled = True
    inspection_enable_uefi = True
    Copy to Clipboard Toggle word wrap
  2. 保存此文件并执行 undercloud 安装:

    $ openstack undercloud install
    Copy to Clipboard Toggle word wrap

    等待安装脚本完成。

  3. 将每个注册节点的引导模式设置为 uefi。例如,要在 capabilities 属性中添加或替换现有的 boot_mode 参数,可运行以下命令:

    $ NODE=<NODE NAME OR ID> ; openstack baremetal node set --property capabilities="boot_mode:uefi,$(openstack baremetal node show $NODE -f json -c properties | jq -r .properties.capabilities | sed "s/boot_mode:[^,]*,//g")" $NODE
    Copy to Clipboard Toggle word wrap
    注意

    检查是否保留了 profileboot_option 功能。

    +

    $ openstack baremetal node show r530-12 -f json -c properties | jq -r .properties.capabilities
    Copy to Clipboard Toggle word wrap
  4. 将各个类型的引导模式设为 uefi

    $ openstack flavor set --property capabilities:boot_mode='uefi' control
    Copy to Clipboard Toggle word wrap

6.5. 为节点定义根磁盘

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

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

  • model(字符串):设备 ID。
  • vendor(字符串):设备厂商。
  • serial(字符串):磁盘序列号。
  • hctl(字符串):SCSI 的 Host:Channel:Target:Lun。
  • size(整数):设备的大小(以 GB 为单位)。
  • wwn(字符串):唯一的存储 ID。
  • wwn_with_extension(字符串):唯一存储 ID 附加厂商扩展名。
  • wwn_vendor_extension(字符串):唯一厂商存储标识符。
  • rotational(布尔值):旋转磁盘设备为 true (HDD),否则为 false (SSD)。
  • name(字符串):设备名称,例如:/dev/sdb1。
重要

只对有固定名称的设备才使用 name。不要使用 name 来设置其他设备的根磁盘,因为此值在节点引导时可能会改变。

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

步骤

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

    (undercloud) $ openstack baremetal introspection data save 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 | jq ".inventory.disks"
    Copy to Clipboard Toggle word wrap

    例如,一个节点的数据可能会显示 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"
      }
    ]
    Copy to Clipboard Toggle word wrap
  2. 本例演示了如何将根设备设置为磁盘 2,该磁盘的序列号为 61866da04f380d001ea4e13c12e36ad6。这需要更改节点定义的 root_device 参数:

    (undercloud) $ openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
    Copy to Clipboard Toggle word wrap
    注意

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

6.6. 创建特定于架构的角色

在构建多云架构时,需要将特定于架构的角色添加到 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
Copy to Clipboard Toggle word wrap

6.7. 环境文件

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

  • 每个角色及其类型的节点数量。包含此信息对于创建 overcloud 至关重要。
  • 容器化 OpenStack 服务的容器镜像位置。
  • 任何网络隔离文件,首先是 heat 模板集合中的初始化文件 (environments/network-isolation.yaml),然后是您自定义的 NIC 配置文件,最后是任何额外的网络配置。
  • 任何外部的负载平衡环境文件。
  • 任何存储环境文件,如 Ceph Storage、NFS、iSCSI 等。
  • 任何用于红帽 CDN 或 Satellite 注册的环境文件。
  • 任何其它自定义环境文件。

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

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

重要

一个基本的 overcloud 会使用本地 LVM 存储作为块存储,这种配置不受支持。建议您使用外部存储解决方案(如 Red Hat Ceph Storage)来实现块存储。

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

6.8. 创建定义节点数目和类型的环境文件

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

步骤

  1. 创建一个 node-info.yaml 文件,保存在 /home/stack/templates/ 目录下:

    (undercloud) $ touch /home/stack/templates/node-info.yaml
    Copy to Clipboard Toggle word wrap
  2. 编辑这个文件,使其包含您需要的节点数目和类型。本例部署 3 个 Controller 节点、3 个 Compute 节点和 3 个Ceph Storage 节点。

    parameter_defaults:
      OvercloudControllerFlavor: control
      OvercloudComputeFlavor: compute
      ControllerCount: 3
      ComputeCount: 3
    Copy to Clipboard Toggle word wrap

6.9. 创建 undercloud CA 信任的环境文件

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

注意

为了让这种方法凑效,您的 overcloud 节点需要指向 undercloud 的公开端点的网络路径。依赖于脊叶型网络的部署可能需要应用这种配置。

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

  • 用户提供的证书 - 当您自行提供证书时,会应用此定义。证书可能来自于您自己的 CA,也可能是自签名的。这通过使用 undercloud_service_certificate 选项来传递。在这种情形中,您需要信任自签名证书或者信任其 CA(取决于您的部署)。
  • 自动生成的证书 - 当您通过 certmonger 生成使用自己的本地 CA 的证书时,会应用此定义。这通过 generate_service_certificate 选项来启用。在这种情形中,会存在一个 CA 证书 (/etc/pki/ca-trust/source/anchors/cm-local-ca.pem),以及供 undercloud 的 HAProxy 实例使用的服务器证书。要向 OpenStack 出示证书,您需要将 CA 添加到 inject-trust-anchor-hiera.yaml 文件中。

步骤

本例中使用了位于 /home/stack/ca.crt.pem 的一个自签名证书。如果您使用自动生成的证书,请改为使用 /etc/pki/ca-trust/source/anchors/cm-local-ca.pem

  1. 打开证书文件,仅复制证书部分。不要包括其密钥:

    $ vi /home/stack/ca.crt.pem
    Copy to Clipboard Toggle word wrap

    您需要的证书部分与下方简写的示例类似:

    -----BEGIN CERTIFICATE-----
    MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV
    BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBwwHUmFsZWlnaDEQMA4GA1UECgwH
    UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBAMMCzE5Mi4xNjguMC4yMB4XDTE3
    -----END CERTIFICATE-----
    Copy to Clipboard Toggle word wrap
  2. 创建一个名为 /home/stack/inject-trust-anchor-hiera.yaml 的 YAML 文件,其包含下列内容以及您从 PEM 文件复制而来的证书:

    parameter_defaults:
      CAMap:
        ...
        undercloud-ca:
          content: |
            -----BEGIN CERTIFICATE-----
            MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV
            BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBwwHUmFsZWlnaDEQMA4GA1UECgwH
            UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBAMMCzE5Mi4xNjguMC4yMB4XDTE3
            -----END CERTIFICATE-----
    Copy to Clipboard Toggle word wrap
    注意

    证书字符串必须采用 PEM 格式。

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

6.10. 部署命令

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

警告

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

6.11. 部署命令选项

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

Expand
表 6.1. 部署命令选项
参数描述

--templates [TEMPLATES]

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

--stack STACK

创建或更新的栈的名称

-t [TIMEOUT]--timeout [TIMEOUT]

部署超时时间(分钟)

--libvirt-type [LIBVIRT_TYPE]

hypervisor 使用的虚拟类型

--ntp-server [NTP_SERVER]

网络时间协议 (NTP) 服务器用于同步时间。您也可以在逗号分隔列表中指定多个 NTP 服务器,例如:--ntp-server 0.centos.pool.org,1.centos.pool.org。对于高可用性集群部署,重要的是各个控制器始终引用同一时间源。但请注意,通常的环境可能已经指定了符合公认规范的 NTP 时间源。

--no-proxy [NO_PROXY]

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

--overcloud-ssh-user OVERCLOUD_SSH_USER

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

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

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

--environment-directory

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

--validation-errors-nonfatal

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

--validation-warnings-fatal

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

--dry-run

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

--skip-postconfig

跳过 overcloud 部署后配置。

--force-postconfig

强制进行 overcloud 部署后配置。

--skip-deploy-identifier

跳过生成 DeployIdentifier 参数的唯一标识符。软件配置部署步骤仅当配置发生实际更改时才会触发。使用此选项要非常谨慎,仅当您确信不需要运行软件配置(如扩展某些角色)时方可使用。

--answers-file ANSWERS_FILE

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

--rhel-reg

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

--reg-method

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

--reg-org [REG_ORG]

用于注册的组织。

--reg-force

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

--reg-sat-url [REG_SAT_URL]

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

--reg-activation-key [REG_ACTIVATION_KEY]

用于注册的激活码。

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

(undercloud) $ openstack help overcloud deploy
Copy to Clipboard Toggle word wrap

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

Expand
表 6.2. 将被弃用的 CLI 参数映射到 Heat 模板参数
参数描述Heat 模板参数

--control-scale

扩展的 Controller 节点数量

ControllerCount

--compute-scale

扩展的 Compute 节点数量

ComputeCount

--ceph-storage-scale

扩展的 Ceph 节点数量

CephStorageCount

--block-storage-scale

扩展的 Cinder 节点数量

BlockStorageCount

--swift-storage-scale

扩展的 Swift 节点数量

ObjectStorageCount

--control-flavor

Controller 节点使用的 flavor

OvercloudControllerFlavor

--compute-flavor

Compute 节点使用的 flavor

overcloudComputeFlavor

--ceph-storage-flavor

Ceph 节点使用的 flavor

overcloudCephStorageFlavor

--block-storage-flavor

Cinder 节点使用的 flavor

overcloudBlockStorageFlavor

--swift-storage-flavor

Swift 存储节点使用的 flavor

overcloudSwiftStorageFlavor

--neutron-flat-networks

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

NeutronFlatNetworks

--neutron-physical-bridge

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

HypervisorNeutronPhysicalBridge

--neutron-bridge-mappings

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

NeutronBridgeMappings

--neutron-public-interface

定义网络节点的 br-ex 中的网桥接口

NeutronPublicInterface

--neutron-network-type

neutron 的租户网络类型

NeutronNetworkType

--neutron-tunnel-types

Neutron 租户网络的隧道类型。使用逗号分隔的字符串可以指定多个值

NeutronTunnelTypes

--neutron-tunnel-id-ranges

可以用来进行租户网络分配的 GRE 隧道 ID 的范围

NeutronTunnelIdRanges

--neutron-vni-ranges

可以用来进行租户网络分配的 VXLAN VNI ID 范围

NeutronVniRanges

--neutron-network-vlan-ranges

支持的 Neutron ML2 和 Open vSwitch VLAN 映射范围。默认是在 datacentre 物理网络中允许任何 VLAN

NeutronNetworkVLANRanges

--neutron-mechanism-drivers

neutron 租户网络的机制驱动。默认值是 "openvswitch"。使用逗号分隔的字符串可以指定多个值

NeutronMechanismDrivers

--neutron-disable-tunneling

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

无参数映射。

--validation-errors-fatal

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

未进行参数映射

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

6.12. 在 overcloud 部署中包括环境文件

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

  • 每个角色及其类型的节点数量。包含此信息对于创建 overcloud 至关重要。
  • 容器化 OpenStack 服务的容器镜像位置。
  • 任何网络隔离文件,首先是 heat 模板集合中的初始化文件 (environments/network-isolation.yaml),然后是您自定义的 NIC 配置文件,最后是任何额外的网络配置。
  • 任何外部的负载平衡环境文件。
  • 任何存储环境文件,如 Ceph Storage、NFS、iSCSI 等。
  • 任何用于红帽 CDN 或 Satellite 注册的环境文件。
  • 任何其它自定义环境文件。

使用 -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 \
Copy to Clipboard Toggle word wrap

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

--templates
/usr/share/openstack-tripleo-heat-templates 中的 Heat 模板集合为基础来创建 overcloud
-e /home/stack/templates/node-info.yaml
添加环境文件以定义每种角色有多少个节点以及使用哪些类型。
-e /home/stack/templates/overcloud_images.yaml
添加包含容器镜像源的环境文件。
-e /home/stack/inject-trust-anchor-hiera.yaml
添加用于在 undercloud 中安装自定义证书的环境文件。
-r /home/stack/templates/roles_data.yaml
(可选)如果使用自定义角色或启用多架构云,这是生成的角色数据。如需更多信息,请参阅 第 6.6 节 “创建特定于架构的角色”

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

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

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

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

6.13. 在部署前验证 overcloud 配置

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

步骤

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

    $ cd /usr/share/openstack-tripleo-heat-templates
    $ ./tools/process-templates.py -o ~/overcloud-validation
    Copy to Clipboard Toggle word wrap
  2. 使用下列命令来验证模板语法:

    (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]
    Copy to Clipboard Toggle word wrap

    验证过程需要 overcloud-resource-registry-puppet.yaml 环境文件包括针对于 overcloud 的资源。使用 -e 选项为这个命令添加其他额外的环境文件。此外,还需包含 --show-nested 选项,以解析来自嵌套模板的参数。

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

6.14. Overcloud 部署输出

一旦 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 ******
========================================================================
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

6.15. 访问 overcloud

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

(undercloud) $ source ~/overcloudrc
Copy to Clipboard Toggle word wrap

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

(overcloud) $
Copy to Clipboard Toggle word wrap

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

(overcloud) $ source ~/stackrc
(undercloud) $
Copy to Clipboard Toggle word wrap

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

(undercloud) $ openstack server list
Copy to Clipboard Toggle word wrap

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

(undercloud) $ ssh heat-admin@192.168.24.23
Copy to Clipboard Toggle word wrap

6.16. 后续步骤

使用命令行工具创建 overcloud 的步骤到此结束。有关创建后的功能,请参阅第 9 章 创建 overcloud 后执行的任务

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat