Red Hat Training

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

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

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

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

流程

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

配置要求

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

    表 6.1. Provisioning 网络 IP 分配信息

    节点名

    IP 地址

    MAC 地址

    IPMI IP 地址

    Director

    192.168.24.1

    aa:aa:aa:aa:aa:aa

    不需要

    Controller

    DHCP

    bb:bb:bb:bb:bb:bb

    192.168.24.205

    Compute

    DHCP

    cc:cc:cc:cc:cc:cc

    192.168.24.206

  • 所有其他网络类型使用 Provisioning 网络来提供 OpenStack 服务。不过,您可以为其他网络流量类型创建额外的网络。
  • 容器镜像的来源。有关如何生成包含容器镜像来源的环境文件的说明,请参阅第 5 章 配置容器镜像源

6.1. 为 overcloud 注册节点

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

{
    "nodes":[
        {
            "mac":[
                "bb:bb:bb:bb:bb:bb"
            ],
            "name":"node01",
            "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"
            ],
            "name":"node02",
            "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"
        }
    ]
}

这个模板使用以下属性:

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

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

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

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

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

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

(undercloud) $ openstack baremetal node list

6.2. 检查节点硬件

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

注意

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

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

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

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

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

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

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

执行单个节点内省

要在 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                                                                                                  |
+--------------------------------------+------------------------------------------------------------------------------------------------------------------------+

获取硬件内省详细信息

Bare Metal 服务的硬件检查额外功能 (inspection_extras) 会默认启用,以获取硬件详细信息。您可以使用这些硬件详细信息来配置 overcloud。如需了解有关 undercloud.conf 文件中的 inspection_extras 参数的详细信息,请参阅 Configuring the Director

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

  • RAM(单位为 KB)
  • 物理 CPU 内核数和同级线程数
  • 和 NUMA 节点关联的 NIC

使用 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
    }
  ]
}

6.3. 自动发现裸机节点

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

配置要求

  • 所有 overcloud 节点必须将其 BMC 配置为可由 director 通过 IPMI 进行访问。
  • 所有 overcloud 节点必须配置为可通过连接到 undercloud 控制层网络的 NIC 进行 PXE 引导。

启用自动发现

  1. undercloud.conf 中可启用裸机自动发现:

    enable_node_discovery = True
    discovery_default_driver = pxe_ipmitool
    • enable_node_discovery - 启用之后,任何使用 PXE 来引导内省虚拟内存盘的节点都将在 ironic 中注册。
    • discovery_default_driver - 设置所发现的节点要使用的驱动。例如,pxe_ipmitool
  2. 将您的 IPMI 凭证添加到 ironic:

    1. 将您的 IPMI 凭证添加到名为 ipmi-credentials.json 的文件。您需要替换本例中的用户名和密码值以适应您的环境:

      [
          {
              "description": "Set default IPMI credentials",
              "conditions": [
                  {"op": "eq", "field": "data://auto_discovered", "value": true}
              ],
              "actions": [
                  {"action": "set-attribute", "path": "driver_info/ipmi_username",
                   "value": "SampleUsername"},
                  {"action": "set-attribute", "path": "driver_info/ipmi_password",
                   "value": "RedactedSecurePassword"},
                  {"action": "set-attribute", "path": "driver_info/ipmi_address",
                   "value": "{data[inventory][bmc_address]}"}
              ]
          }
      ]
  3. 将 IPMI 凭证文件导入 ironic:

    $ openstack baremetal introspection rule import ipmi-credentials.json

测试自动发现

  1. 打开所需节点。
  2. 运行 openstack baremetal node list。应该看到新节点以 enrolled 状态列出:

    $ openstack baremetal node list
    +--------------------------------------+------+---------------+-------------+--------------------+-------------+
    | UUID                                 | Name | Instance UUID | Power State | Provisioning State | Maintenance |
    +--------------------------------------+------+---------------+-------------+--------------------+-------------+
    | c6e63aec-e5ba-4d63-8d37-bd57628258e8 | None | None          | power off   | enroll             | False       |
    | 0362b7b2-5b9c-4113-92e1-0b34a2535d9b | None | None          | power off   | enroll             | False       |
    +--------------------------------------+------+---------------+-------------+--------------------+-------------+
  3. 为各个节点设置资源类:

    $ for NODE in `openstack baremetal node list -c UUID -f value` ; do openstack baremetal node set $NODE --resource-class baremetal ; done
  4. 为各个节点配置内核和 ramdisk:

    $ for NODE in `openstack baremetal node list -c UUID -f value` ; do openstack baremetal node manage $NODE ; done
    $ openstack overcloud node configure --all-manageable
  5. 将所有节点设置为 available:

    $ for NODE in `openstack baremetal node list -c UUID -f value` ; do openstack baremetal node provide $NODE ; done

使用规则发现不同供应商的硬件

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

  1. 创建名为 dell-drac-rules.json 的文件,并包含以下内容。您需要替换本例中的用户名和密码值以适应您的环境:

    [
        {
            "description": "Set default IPMI credentials",
            "conditions": [
                {"op": "eq", "field": "data://auto_discovered", "value": true},
                {"op": "ne", "field": "data://inventory.system_vendor.manufacturer",
                 "value": "Dell Inc."}
            ],
            "actions": [
                {"action": "set-attribute", "path": "driver_info/ipmi_username",
                 "value": "SampleUsername"},
                {"action": "set-attribute", "path": "driver_info/ipmi_password",
                 "value": "RedactedSecurePassword"},
                {"action": "set-attribute", "path": "driver_info/ipmi_address",
                 "value": "{data[inventory][bmc_address]}"}
            ]
        },
        {
            "description": "Set the vendor driver for Dell hardware",
            "conditions": [
                {"op": "eq", "field": "data://auto_discovered", "value": true},
                {"op": "eq", "field": "data://inventory.system_vendor.manufacturer",
                 "value": "Dell Inc."}
            ],
            "actions": [
                {"action": "set-attribute", "path": "driver", "value": "idrac"},
                {"action": "set-attribute", "path": "driver_info/drac_username",
                 "value": "SampleUsername"},
                {"action": "set-attribute", "path": "driver_info/drac_password",
                 "value": "RedactedSecurePassword"},
                {"action": "set-attribute", "path": "driver_info/drac_address",
                 "value": "{data[inventory][bmc_address]}"}
            ]
        }
    ]
  2. 将规则导入 ironic:

    $ openstack baremetal introspection rule import dell-drac-rules.json

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

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

类型描述

角色

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

类型

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

配置集

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

节点

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

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

注意

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

为了通过添加标签把节点标记为特定的配置集,把 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:computeprofile:control 选项会把节点标记为相关的配置集。

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

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

(undercloud) $ openstack overcloud profiles list

自定义角色配置集

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

(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

6.5. 为节点定义 Root Disk

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

以下几个属性可帮助 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 来设置其他设备的根磁盘,因为此值在节点引导时可能会改变。

在本例中,使用磁盘的序列号指定根设备来部署 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
注意

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

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

6.6. 使用环境文件自定义 Overcloud

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

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

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

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

重要

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

6.7. 使用 CLI 工具创建 overcloud

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

警告

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

设置 overcloud 参数

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

表 6.2. 部署参数

参数描述

--templates [TEMPLATES]

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

--stack STACK

创建或更新的栈的名称

-t [TIMEOUT]--timeout [TIMEOUT]

部署超时时间(分钟)

--libvirt-type [LIBVIRT_TYPE]

hypervisor 使用的虚拟类型

--ntp-server [NTP_SERVER]

网络时间协议 (NTP) 服务器用于同步时间。您也可以在逗号分隔列表中指定多个 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]

用于注册的激活码。

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

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

参数描述Heat 模板参数

--control-scale

扩展的 Controller 节点数量

ControllerCount

--compute-scale

扩展的 Compute 节点数量

ComputeCount

--ceph-storage-scale

扩展的 Ceph 节点数量

CephStorageCount

--block-storage-scale

扩展的 Cinder 节点数量

BlockStorageCount

--swift-storage-scale

扩展的 Swift 节点数量

ObjectStorageCount

--control-flavor

Controller 节点使用的 flavor

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 版本中移除。

注意

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

(undercloud) $ openstack help overcloud deploy

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

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

  • 每个角色及其类型的节点数量。包含此信息对于创建 overcloud 至关重要。
  • 容器化 OpenStack 服务的容器镜像位置。它会指向使用 第 5 章 配置容器镜像源 中的某个选项来创建的文件。
  • 任何网络隔离文件,首先是 heat 模板集合中的初始化文件 (environments/network-isolation.yaml),然后是您自定义的 NIC 配置文件,最后是任何额外的网络配置。
  • 任何外部的负载平衡环境文件。
  • 任何存储环境文件,如 Ceph Storage、NFS、iSCSI 等。
  • 任何用于 Red Hat 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 /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
  -e /home/stack/templates/network-environment.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
  -e /home/stack/templates/ceph-custom-config.yaml \
  --ntp-server pool.ntp.org \

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

--templates
/usr/share/openstack-tripleo-heat-templates 中的 Heat 模板集合为基础来创建 overcloud
-e /home/stack/templates/node-info.yaml

添加环境文件,定义每个角色要使用多少个节点以及哪些类型。例如:

parameter_defaults:
  OvercloudControllerFlavor: control
  OvercloudComputeFlavor: compute
  OvercloudCephStorageFlavor: ceph-storage
  ControllerCount: 3
  ComputeCount: 3
  CephStorageCount: 3
-e /home/stack/templates/overcloud_images.yaml
添加包含容器镜像来源的环境文件。请参阅第 5 章 配置容器镜像源,以了解更多信息。
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml

添加环境文件以初始化 overcloud 部署中的网络隔离。

注意

network-isolation.j2.yaml 是这个模板的 Jinja2 版本。openstack overcloud deploy 命令会将 Jinja2 模板提供给纯文本 YAML 文件。这意味着,在运行 openstack overcloud deploy 命令时,需要纳入接受提供的 YAML文件的名称(在这个案例中,该名称为 network-isolation.yaml)。

-e /home/stack/templates/network-environment.yaml
添加环境文件以自定义网络隔离。
-e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml
添加环境文件以启用 Ceph Storage 服务。
-e /home/stack/templates/ceph-custom-config.yaml
添加环境文件以自定义 Ceph Storage 配置。
--ntp-server pool.ntp.org
使用一个 NTP 服务器进行时间同步。为了保持 Controller 节点集群的同步需要这样做。

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

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

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

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

包含环境文件目录

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

(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

使用一个应答文件

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

templates
要使用的 Heat 核心模板集。它用于替代 --templates 命令行选项。
environments
要包含的环境文件列表。它用于替代 --environment-file (-e) 命令行选项。

例如,应答文件可能包含以下内容:

templates: /usr/share/openstack-tripleo-heat-templates/
environments:
  - ~/templates/00-node-info.yaml
  - ~/templates/10-network-isolation.yaml
  - ~/templates/20-network-environment.yaml
  - ~/templates/30-storage-environment.yaml
  - ~/templates/40-rhel-registration.yaml

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

(undercloud) $ openstack overcloud deploy --answers-file ~/answers.yaml

6.9. 管理 overcloud 计划

作为 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
注意

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

6.10. 验证 overcloud 模板和计划

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

创建一个呈现的模板

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

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

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

6.11. 监控 overcloud 的创建过程

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

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

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

6.12. 访问 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

6.13. 完成 overcloud 的创建

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