6.3. 使用情景 3：使用 CLI 创建一个带有 Ceph 节点的高级 Overcloud

这个使用情景会创建一个带有 Red Hat Ceph Storage 节点的大型企业级 OpenStack Platform 环境。这个使用情景中的 Overcloud 包括 9 个节点：
  • 3 个带有高可用性的 Controller 节点
  • 3 个 Compute 节点
  • 带有 3 个 Red Hat Ceph Storage 节点的集群
所有机器都是使用 IPMI 进行管理的裸机。这个使用情景展示了 director 创建一个可以在今后进行扩展的、生产级别的 Red Hat Enterprise Linux OpenStack Platform 环境的能力。它同时展示了通过命令行工具实现的 director 的一些高级功能，包括用于角色匹配的自动健康检查工具（Automated Health Check Tools）和高级的网络分离功能。

流程

  1. 在 director 中创建一个节点定义模板并注册空白节点。
  2. 检查所有节点的硬件并创建基准数据。
  3. 使用自动健康检查（Automated Health Check，简称 AHC）工具定义策略来自动使用标签把节点标记为不同的角色。
  4. 创建 flavor 并通过添加标签把它们标记为角色。
  5. 创建 director 的默认 Heat 模板的一个副本。
  6. 创建 Heat 模板来分离所有网络。
  7. 使用默认的 Heat 模板和额外的网络分离模板创建 Overcloud 环境。
  8. 为高可用性集群中的每个 Controller 节点添加隔离（fencing）信息。

配置要求

  • 第 3 章 安装 Undercloud 中创建的 director 节点
  • 9 个裸机。这些系统需要满足 Controller 节点、Compute 节点和 Ceph Storage 节点对配置的要求。请参阅以下内容：
    因为 director 会把 Red Hat Enterprise Linux 7 镜像复制到每个节点，因此这些节点当前不需要操作系统。
  • Provisioning 网络的一个网络连接（被配置为一个原生 VLAM）。所有节点必须都连接到这个网络，并需要满足 第 2.3 节 “网络要求” 中的要求。在这个示例中，我们使用 192.0.2.0/24 作为 Provisioning 子网，分配的 IP 地址信息如下：

    表 6.3. Provisioning 网络 IP 分配信息

    节点名
    IP 地址
    MAC 地址
    IPMI IP 地址
    director
    192.0.2.1
    aa:aa:aa:aa:aa:aa
    Controller 1
    DHCP
    b1:b1:b1:b1:b1:b1
    192.0.2.205
    Controller 2
    DHCP
    b2:b2:b2:b2:b2:b2
    192.0.2.206
    Controller 3
    DHCP
    b3:b3:b3:b3:b3:b3
    192.0.2.207
    Compute 1
    DHCP
    c1:c1:c1:c1:c1:c1
    192.0.2.208
    Compute 2
    DHCP
    c2:c2:c2:c2:c2:c2
    192.0.2.209
    Compute 3
    DHCP
    c3:c3:c3:c3:c3:c3
    192.0.2.210
    Ceph 1
    DHCP
    d1:d1:d1:d1:d1:d1
    192.0.2.211
    Ceph 2
    DHCP
    d2:d2:d2:d2:d2:d2
    192.0.2.212
    Ceph 3
    DHCP
    d3:d3:d3:d3:d3:d3
    192.0.2.213
  • 每个 Overcloud 节点使用剩下的两个网络接口组成网络绑定来处理标记 VLAN（tagged VLAN）中的网络。这个绑定使用以下网络设置：

    表 6.4. 网络子网和 VLAN 分配

    网络类型
    子网
    VLAN
    Internal API
    172.16.0.0/24
    201
    Tenant
    172.17.0.0/24
    202
    Storage
    172.18.0.0/24
    203
    Storage Management
    172.19.0.0/24
    204
    External / Floating IP
    10.1.1.0/24
    100

6.3.1. 为高级 Overcloud 注册节点

在本节中，我们创建一个节点定义模板。这个文件（instackenv.json）是一个 JSON 格式的文件，它包括了环境中的 9 个节点的硬件信息和电源管理信息。例如： 
{
    "nodes":[
        {
            "mac":[
                "b1:b1:b1:b1:b1:b1"
            ],
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.0.2.205"
        },
        {
            "mac":[
                "b2:b2:b2:b2:b2:b2"
            ],
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.0.2.206"
        },
        {
            "mac":[
                "b3:b3:b3:b3:b3:b3"
            ],
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.0.2.207"
        },
        {
            "mac":[
                "c1:c1:c1:c1:c1:c1"
            ],
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.0.2.208"
        },
        {
            "mac":[
                "c2:c2:c2:c2:c2:c2"
            ],
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.0.2.209"
        },
        {
            "mac":[
                "c3:c3:c3:c3:c3:c3"
            ],
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.0.2.210"
        },
        {
            "mac":[
                "d1:d1:d1:d1:d1:d1"
            ],
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.0.2.211"
        },
        {
            "mac":[
                "d2:d2:d2:d2:d2:d2"
            ],
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.0.2.212"
        },
        {
            "mac":[
                "d3:d3:d3:d3:d3:d3"
            ],
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.0.2.213"
        }
    ]
}
这个模板使用以下属性：
mac
节点上的网络接口的 MAC 地址列表。只为每个系统的 Provisioning NIC 使用 MAC 地址。
cpu
节点上的 CPU 数量。
memory
内存大小（以 MB 为单位）。
disk
硬盘的大小（以 GB 为单位）。
arch
系统架构。
pm_type
使用的电源管理驱动。在这个示例中使用 IPMI 驱动（pxe_ipmitool）。
pm_user, pm_password
IPMI 的用户名和密码。
pm_addr
IPMI 设备的 IP 地址。

注意

如需了解更多与所支持的电源管理类型和选项相关的信息，请参阅 附录 B, 电源管理驱动。
在创建完模板后，把这个文件保存到 stack 用户的家目录（/home/stack/instackenv.json），然后把它导入到 director。使用以下命令： 
$ openstack baremetal import --json ~/instackenv.json
这会导入模板，并把模板中的每个节点注册到 director。
为所有节点分配内核和 ramdisk 镜像： 
$ openstack baremetal configure boot
现在，节点已在 director 中注册并被配置。使用以下命令可以在 CLI 中查看这些节点的列表： 
$ openstack baremetal list

6.3.2. 检查节点硬件

在注册节点后，需要检查每个节点的硬件。在这个使用情景中，还会使用 AHC 工具创建基准数据（benchmark）。AHC 会自动通过标签把节点标记为不同的实施档案。这些档案标签把节点和 flavor 相匹配，从而把相关的 flavor 分配给实施角色。

重要

如需使用创建基准数据的功能，则需要在初始配置 director 时把 discovery_runbench 选项设置为“true"（请参阅 第 3.7 节 “配置 director”）。
如果您在安装 director 后需要启用基准数据功能，需要编辑 /httpboot/discoverd.ipxe，把 RUNBENCH 内核参数设置为 1。
运行以下命令检查每个节点的属性： 
$ openstack baremetal introspection bulk start

重要

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

6.3.3. 使用自动健康检查（Automated Health Check，简称 AHC）工具自动为节点加标签

在发现操作完成对基准数据的测试后，您可以产生一组报告来识别并隔离 Overcloud 中那些性能较低或不稳定的节点。本节介绍了如何创建这些报告，以及如何创建策略来自动通过为节点添加标签来为它们分配角色。
使用以下命令安装 AHC 工具程序： 
$ sudo yum install -y ahc-tools
这个软件包有两个工具程序：
  • ahc-report：提供基准数据测试的报告。
  • ahc-match：根据策略，通过为节点加标签来为节点指定角色。

重要

这些工具需要在 /etc/ahc-tools/ahc-tools.conf 文件中设置的 Ironic 和 Swift 的凭证信息。它们同 /etc/ironic-discoverd/discoverd.conf 中的凭证信息相同。使用以下命令为 /etc/ahc-tools/ahc-tools.conf 添加相关信息： 
$ sudo -i
# sed 's/\[discoverd/\[ironic/' /etc/ironic-discoverd/discoverd.conf > /etc/ahc-tools/ahc-tools.conf
# chmod 0600 /etc/ahc-tools/ahc-tools.conf
# exit

6.3.3.1. ahc-report

ahc-report 脚本会产生多个与您的节点相关的报告。要查看报告的全部，使用 --full 选项。 
$ ahc-report --full
ahc-report 还可以被用来专注于一个报告的特定部分。例如，使用 --categories 可以根据节点的硬件（处理器、网卡、固件、内存和其它硬件控制器）进行分类。这还会把具有相似硬件档案的节点进行分组。例如，在示例中的两个节点的 Processors 项会和以下类似： 
######################
##### Processors #####
2 identical systems :
[u'7F8831F1-0D81-464E-A767-7577DF49AAA5', u'7884BC95-6EF8-4447-BDE5-D19561718B29']
[(u'cpu', u'logical', u'number', u'4'),
 (u'cpu', u'physical', u'number', u'4'),
 (u'cpu',
  u'physical_0',
  u'flags',
  u'fpu fpu_exception wp de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx x86-64 rep_good nopl pni cx16 hypervisor lahf_lm'),
 (u'cpu', u'physical_0', u'frequency', u'2000000000'),
 (u'cpu', u'physical_0', u'physid', u'0'),
 (u'cpu', u'physical_0', u'product', u'Intel(R) Xeon(TM) CPU       E3-1271v3 @ 3.6GHz'),
 (u'cpu', u'physical_0', u'vendor', u'GenuineIntel'),
 (u'cpu',
  u'physical_1',
  u'flags',
  u'fpu fpu_exception wp de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx x86-64 rep_good nopl pni cx16 hypervisor lahf_lm'),
 (u'cpu', u'physical_0', u'frequency', u'2000000000'),
 (u'cpu', u'physical_0', u'physid', u'0'),
 (u'cpu', u'physical_0', u'product', u'Intel(R) Xeon(TM) CPU       E3-1271v3 @ 3.6GHz'),
 (u'cpu', u'physical_0', u'vendor', u'GenuineIntel')
 ...
 ]
ahc-report 工具还可以识别在您的节点数据中的“局外者（outliers）”。使用 --outliers 选项来启用这个功能： 
$ ahc-report --outliers

Group 0 : Checking logical disks perf
standalone_randread_4k_KBps   : INFO    : sda   : Group performance : min=45296.00, mean=53604.67, max=67923.00, stddev=12453.21
standalone_randread_4k_KBps   : ERROR   : sda   : Group's variance is too important :   23.23% of 53604.67 whereas limit is set to 15.00%
standalone_randread_4k_KBps   : ERROR   : sda   : Group performance : UNSTABLE
standalone_read_1M_IOps       : INFO    : sda   : Group performance : min= 1199.00, mean= 1259.00, max= 1357.00, stddev=   85.58
standalone_read_1M_IOps       : INFO    : sda   : Group performance = 1259.00   : CONSISTENT
standalone_randread_4k_IOps   : INFO    : sda   : Group performance : min=11320.00, mean=13397.33, max=16977.00, stddev= 3113.39
standalone_randread_4k_IOps   : ERROR   : sda   : Group's variance is too important :   23.24% of 13397.33 whereas limit is set to 15.00%
standalone_randread_4k_IOps   : ERROR   : sda   : Group performance : UNSTABLE
standalone_read_1M_KBps       : INFO    : sda   : Group performance : min=1231155.00, mean=1292799.67, max=1393152.00, stddev=87661.11
standalone_read_1M_KBps       : INFO    : sda   : Group performance = 1292799.67   : CONSISTENT

...
在以上的示例中，因为所有节点的标准偏差高于所允许的阈值，所以 ahc-report 把 standalone_randread_4k_KBps 和 standalone_randread_4k_IOps 磁盘数据标记为“unstable（不稳定）”。当有两个节点的磁盘数据传输率显著不同时，就会出现这个情况。
在您的节点数据中找到“局外者（outliers）”非常有用，因为您可以把更加适合的任务分配给高性能节点。例如，有更好磁盘数据传输率的节点适合作为存储节点，而有更好内存性能的节点则适合作为 Compute 节点。当获得了每个节点的硬件性能数据后，就可以创建一组策略，并使用 ahc-match 命令把节点设为特定的角色。

6.3.3.2. ahc-match

ahc-match 命令会对 Overcloud 计划应用一组策略来帮助把节点设置为特定角色。在使用这个命令前，创建一组匹配节点和角色的策略。
ahc-tools 软件包会安装 /etc/ahc-tools/edeploy 下的一组策略文件。包括：
  • state - 声明文件，它声明了每个角色的节点数量。
  • compute.specs、 controller.specs - 匹配 Compute 节点和 Controller 节点的策略文件。
声明文件
state 文件包括了每个角色所具有的节点数量信息。默认的配置文件会显示： 
[('control', '1'), ('compute', '*')]
这代表 ahc-match 分配一个 Contorller 节点和任意数量的 Compute 节点。在本使用情景中，编辑这个文件： 
[('control', '3'), ('ceph-storage', '3'), ('compute', '*')]
这会匹配 3 个 Controller 节点、3 个 Red Hat Ceph Storage 节点和没有数量限制的 Compute 节点。
策略文件
compute.specs 和 controller.specs 文件分别列出了相关角色的分配规则。这个文件的内容以数组形式出现，例如： 
[
 ('cpu', 'logical', 'number', 'ge(2)'),
 ('disk', '$disk', 'size', 'gt(4)'),
 ('network', '$eth', 'ipv4', 'network(192.0.2.0/24)'),
 ('memory', 'total', 'size', 'ge(4294967296)'),
]
这提供了一个根据硬件参数定义分配规则的方法。如需了解详细的信息，请参阅 附录 C, AHC 工具程序参数。
这个策略文件还包括一组帮助函数来匹配值的范围。这些函数包括：
  • network() - 指定网络中的网络接口。
  • gt()、ge() - 大于（或等于）。
  • lt()、le() - 低于（或等于）。
  • in() - 匹配的项包括在特定集合中。
  • regexp() - 使用正则表达式进行匹配。
  • or()、and()、not() - 布尔函数。or() 和 and() 使用两个参数，not() 带有一个参数。
例如，在这个使用情景中，使用 第 6.3.3.1 节 “ahc-report” 中的 standalone_randread_4k_KBps 和 standalone_randread_4k_IOps 的值来把 Controller 角色的分配限制为磁盘访问速率高于平均值的节点。规则如下： 
[
 ('disk', '$disk', 'standalone_randread_4k_KBps', 'gt(53604)'),
 ('disk', '$disk', 'standalone_randread_4k_IOps', 'gt(13397)')
]
您也可以为其它角色创建额外的策略档案。例如，专门为 Red Hat Ceph Storage 设置一个 ceph-storage.spec 档案。确保这些新文件（不带扩展）包括在 state 文件中。
运行匹配工具
在定义完规则后，运行 ahc-match 工具来分配您的节点。 
$ sudo ahc-match
这会把所有节点匹配到 /etc/ahc-tools/edeploy/state 中定义的角色。当一个节点匹配一个角色时，ahc-match 在 Ironic 中把角色添加到节点作为一个能力（capability）。 
$ ironic node-show b73fb5fa-1a2c-49c6-b38e-8de41e3c0532 | grep properties -A2
| properties    | {u'memory_mb': u'6144', u'cpu_arch': u'x86_64', u'local_gb': u'40',      |
|               | u'cpus': u'4', u'capabilities': u'profile:control,boot_option:local'}    |
| instance_uuid | None                                                                     |
director 使用每个节点中的 profile 标签来匹配具有相同标签的角色和 flavor。

6.3.4. 创建硬件档案

director 还需要为注册的节点提供一组硬件档案或 flavor。在这个使用情景中，分别为 Compute、Controller 和 Ceph Storage 节点创建一个档案： 
$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 control
$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 compute
$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 ceph-storage
这会为节点创建 3 个 flavor。另外还为每个 flavor 设置额外的属性。 
$ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="compute" compute
$ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="control" control
$ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="ceph-storage" ceph-storage
capabilities:boot_option 为 flavor 设置了引导模式，capabilities:profile 定义了使用的档案。

6.3.5. 使用默认的 Overcloud Heat 模板

当创建 Overcloud 时，director 使用保存在数据库中的一个计划，这个计划是基于一组 Heat 模板的。但是，也可以把标准的 Heat 模板复制到一个本地的目录中，然后使用它们来创建 Overcloud。使用这个方法可以对 Overcloud 的特定部分进行定制。
在这个使用情景中。我们使用复制到本地的模板，并对它进行定制来包括 Ceph Storage 磁盘的结构。
Overcloud 的默认 Heat 模板位于 /usr/share/openstack-tripleo-heat-templates。对于这个使用情景，我们把这些模板复制到 stack 用户的家目录中： 
$ cp -r /usr/share/openstack-tripleo-heat-templates ~/templates/my-overcloud
这会创建 Overcloud Heat 模板的一个克隆。在运行 openstack overcloud deploy 时，我们使用了 --templates 选项来指定本地的模板目录。

注意

如果没有为 --templates 选项设置值，director 会使用默认的模板目录（/usr/share/openstack-tripleo-heat-templates）。

6.3.6. 创建 Ceph Storage

本节介绍了使用 director 安装并配置 Red Hat Ceph Storage 来与 OpenStack 一起使用的方法。这个安装和配置过程是基于 Heat 模板和 Puppet 配置的。
Overcloud 镜像中已经包括了 Ceph Storage 软件和所需的 Puppet 模块，使用它们可以在 Controller 集群中自动配置 Ceph OSD 节点和 Ceph Monitor。复制到您的家目录中的 Overcloud 模板集合（请参阅 第 6.3.5 节 “使用默认的 Overcloud Heat 模板”）包括了以下和 Ceph Storage 配置相关的文件：
  • puppet/ceph-storage-puppet.yaml - 用来编配 Ceph Storage 节点、Ceph Storage 节点与 Overcloud 的集成以及它们的 Puppet 配置的 Heat 模板。
  • puppet/manifest/overcloud_cephstorage.pp - 用来为 Ceph Storage 节点配置基本环境，并在 Overcloud 镜像中应用 Ceph Puppet 模块的 Puppet manifest。
  • puppet/hieradata/ceph.yaml - 传递给 Ceph Storage 节点上的 Puppet 配置的 Puppet hiera 数据。
  • puppet/ceph-storage-post-puppet.yaml - 用来编配 Ceph Storage 节点后配置操作的 Heat 模板。
  • puppet/ceph-cluster-config.yaml - 用来在 Controller 节点上编配 Ceph Monitor 的 Heat 模板。
Ceph Storage 集群需要一些小的配置，特别是在 Ceph Storage 节点上的磁盘结构。为了传递这些信息，需要编辑 puppet/hieradata/ceph.yaml，使用 ceph::profile::params::osds 参数把相关的 journal 分区和磁盘进行映射。例如，一个带有 4 个磁盘的 Ceph 节点可以有以下结构：
  • /dev/sda - 包括 Overcloud 镜像的 root 磁盘
  • /dev/sdb - 包括 journal 分区的磁盘
  • /dev/sdc 和 /dev/sdd - OSD 磁盘
对于这个示例，puppet/hieradata/ceph.yaml 可能包括以下内容： 
ceph::profile::params::osds:
    '/dev/sdc':
        journal: '/dev/sdb1'
    '/dev/sdd':
        journal: '/dev/sdb2'
根据您对存储的需求（包括 journal 的大小和池的默认设置），修改 puppet/hieradata/ceph.yaml 中的相关参数。
在进行完相关修改后，保存 puppet/hieradata/ceph.yaml 文件。当实施 Overcloud 时，Ceph Storage 节点将会使用相关的磁盘映射和自定义设置。

6.3.7. 把所有网络分离到 VLAN

director 提供了配置分离 overcloud 网络的方法。这意味着，Overcloud 环境把不同类型的网络数据分离到不同的网络，从而可以把特定的网络数据分配给特定的网络接口或接口绑定。在配置完分离的网络后，director 会配置 OpenStack 服务来使用分离的网络。如果没有配置分离的网络，所有服务都会在 Provisioning 网络中运行。
在这个使用情景中，所有服务都使用分离的网络：
  • 网络 1 - Provisioning
  • 网络 2 - Internal API
  • 网络 3 - Tenant Networks
  • 网络 4 - Storage
  • 网络 5 - Storage Management
  • 网络 6 - External
以下小节介绍了如何创建 Heat 模板来分离所有网络类型。

6.3.7.1. 创建自定义接口模板

Overcloud 网络配置需要一组网络接口模板。您可以对这些模板进行定制来基于角色对节点进行配置。这些模板是 YAML 格式的标准 Heat 模板（请参阅 第 5 章 了解 Heat 模板）。director 包括了一组模板实例以供参考：
  • /usr/share/openstack-tripleo-heat-templates/network/config/single-nic-vlans - 这个目录中包括了基于角色的、带有 VLAN 配置的单独 NIC 的模板。
  • /usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans - 这个目录中包括了基于角色的、绑定 NIC 配置的模板。
对于高级 Overcloud 用户情景，我们使用默认的绑定 NIC 示例配置作为基础。把默认的配置目录复制到 stack 用户的家目录，并命名为 nic-configs。 
$ cp -r /usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans ~/templates/nic-configs
这会创建一组本地的 Heat 模板，它们为每个角色定义了一个绑定的网络接口配置。每个模板都包括标准的 parameters、resources 和 output 项。这里，我们只编辑 resources 项，每个 resources 以以下内容开始： 
resources:
  OsNetConfigImpl:
    type: OS::Heat::StructuredConfig
    properties:
      group: os-apply-config
      config:
        os_net_config:
          network_config:
这会创建一个对 os-apply-config 命令和 os-net-config 子命令的请求来为一个节点配置网络属性。network_config 项中包括了自定义的接口配置，这些配置以类型的形式进行组织，它们包括：
interface
定义一个单独网络接口。这个配置指定了每个接口需要使用实际的接口名（"eth0"、"eth1"、"enp0s25"）还是使用接口编号（"nic1"、"nic2"、"nic3"）。 
            - type: interface
              name: nic2
vlan
定义一个 VLAN。使用从 parameters 项中传递来的 VLAN ID 和子网。 
            - type: vlan
              vlan_id: {get_param: ExternalNetworkVlanID}
              addresses:
                - ip_netmask: {get_param: ExternalIpSubnet}
ovs_bond
定义 Open vSwitch 中的绑定。一个绑定会把两个 interfaces 组合在一起来起到冗余和增加带宽的目的。 
            - type: ovs_bond
              name: bond1
              members:
              - type: interface
                name: nic2
              - type: interface
                name: nic3
ovs_bridge
在 Open vSwitch 中定义网桥。网桥把多个 interface、bond 和 vlan 对象连接在一起。 
            - type: ovs_bridge
              name: {get_input: bridge_name}
              members:
                - type: ovs_bond
                  name: bond1
                  members:
                    - type: interface
                      name: nic2
                      primary: true
                    - type: interface
                      name: nic3
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: ExternalNetworkVlanID}
                  addresses:
                    - ip_netmask: {get_param: ExternalIpSubnet}
如需了解更详细的信息，请参阅 附录 D, 网络接口参数。
对于这个高级使用情景，我们使用默认的绑定节点配置。例如，templates/nic-configs/controller.yaml 模板使用以下 network_config 设置： 
          network_config:
            - type: ovs_bridge
              name: {get_input: bridge_name}
              members:
                - type: ovs_bond
                  name: bond1
                  ovs_options: {get_param: BondInterfaceOvsOptions}
                  members:
                    - type: interface
                      name: nic2
                      primary: true
                    - type: interface
                      name: nic3
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: ExternalNetworkVlanID}
                  addresses:
                    - ip_netmask: {get_param: ExternalIpSubnet}
                  routes:
                    - ip_netmask: 0.0.0.0/0
                      next_hop: {get_param: ExternalInterfaceDefaultRoute}
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: InternalApiNetworkVlanID}
                  addresses:
                  - ip_netmask: {get_param: InternalApiIpSubnet}
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: StorageNetworkVlanID}
                  addresses:
                  - ip_netmask: {get_param: StorageIpSubnet}
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: StorageMgmtNetworkVlanID}
                  addresses:
                  - ip_netmask: {get_param: StorageMgmtIpSubnet}
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: TenantNetworkVlanID}
                  addresses:
                  - ip_netmask: {get_param: TenantIpSubnet}
这个模板定义了一个网桥（通常是名为 br-ex 的外部网桥），并创建了一个由两个编号的接口（nic2 和 nic3）组成的一个名为 bond1 的绑定接口。这个网络还包括了一组加标签的 VLAN（tagged VLAN）设备，并使用 bond1 作为父设备。
附录 E, 网络接口模板示例 中包括了更多网络接口模板示例。
请注意，许多参数使用了 get_param 功能。我们在一个针对于我们的网络所创建的一个环境文件中定义它们。

重要

禁用没有使用的接口来避免不必要的默认路由和网络回路。例如： 
- type: interface
  name: nic1
  use_dhcp: true
确定从所有 ovs_bridge 设备上删除了这些接口。

6.3.7.2. 创建一个高级的 Overcloud 网络环境模板

网络环境文件是一个 Heat 环境文件，它描述了 Overcloud 的网络环境，并指向在前一节中提到的网络接口配置模板。我们在定义网络 IP 地址范围的同时还定义了子网和 VLAN。我们需要根据本地环境对这些值进行定制。
这个使用情景使用以下网络环境文件（被保存为 /home/stack/templates/network-environment.yaml）： 
resource_registry:
  OS::TripleO::BlockStorage::Net::SoftwareConfig: /home/stack/templates/nic-configs/cinder-storage.yaml
  OS::TripleO::Compute::Net::SoftwareConfig: /home/stack/templates/nic-configs/compute.yaml
  OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/templates/nic-configs/controller.yaml
  OS::TripleO::ObjectStorage::Net::SoftwareConfig: /home/stack/templates/nic-configs/swift-storage.yaml
  OS::TripleO::CephStorage::Net::SoftwareConfig: /home/stack/templates/nic-configs/ceph-storage.yaml

parameter_defaults:
  InternalApiNetCidr: 172.16.0.0/24
  TenantNetCidr: 172.17.0.0/24
  StorageNetCidr: 172.18.0.0/24
  StorageMgmtNetCidr: 172.19.0.0/24
  ExternalNetCidr: 10.1.1.0/24
  InternalApiAllocationPools: [{'start': '172.16.0.10', 'end': '172.16.0.200'}]
  TenantAllocationPools: [{'start': '172.17.0.10', 'end': '172.17.0.200'}]
  StorageAllocationPools: [{'start': '172.18.0.10', 'end': '172.18.0.200'}]
  StorageMgmtAllocationPools: [{'start': '172.19.0.10', 'end': '172.19.0.200'}]
  # Leave room for floating IPs in the External allocation pool
  ExternalAllocationPools: [{'start': '10.1.1.10', 'end': '10.1.1.50'}]
  InternalApiNetworkVlanID: 201
  StorageNetworkVlanID: 202
  StorageMgmtNetworkVlanID: 203
  TenantNetworkVlanID: 204
  ExternalNetworkVlanID: 100
  # Set to the router gateway on the external network
  ExternalInterfaceDefaultRoute: 10.1.1.1
  # Set to "br-ex" if using floating IPs on native VLAN on bridge br-ex
  NeutronExternalNetworkBridge: default: "''"
  # Customize bonding options if required
  BondInterfaceOvsOptions:
    "bond_mode=balance-tcp lacp=active other-config:lacp-fallback-ab=true"
resource_registry 项包括了到每个节点角色的网络接口模板的连接。
parameter_defaults 项包括了一组参数，它们被用来定义每个网络类型的网络选项。如需获得这些参数的详细信息，请参阅 附录 F, 网络环境选项。

重要

NeutronExternalNetworkBridge 参数在创建一个基于计划的 Overcloud 时需要是 parameter_defaults 项的一般分。这是因为计划处理参数的方式。如果创建一个基于计划的 Overcloud（如在基本 Overcloud 使用情景中的 Overcloud），这个参数需要是 Controller-1::NeutronExternalNetworkBridge，并被放置在 parameters 项中。请参阅 第 6.2.5.2 节 “创建一个基本 Overcloud 网络环境模板” 来了解它们的不同。
这个使用情景定义了每个网络的选项。所有网络类型都使用一个单独的 VLAN 和子网。这意味着这里没有任何网络使用 Provisioning 网络。

重要

由于资源可用性的问题，在创建 Overcloud 后改变网络配置可能会出现配置问题。例如，一个用户在网络分离模板中修改了一个网络的子网范围，因为这个资源可能已在使用，重新配置操作会失败。

6.3.7.3. 把 OpenStack 服务分配到分离的网络

每个 OpenStack 服务都会被分配到资源注册表中的一个默认网络类型。这些服务然后会和网络类型所分配的网络中的一个 IP 地址相绑定。虽然 OpenStack 服务在这些网络中被分开，实际的物理网络数量可能会和网络环境文件中所定义的不同。您可以通过在您的网络环境文件（/home/stack/templates/network-environment.yaml）中定义一个新的网络映射来把 OpenStack 服务重新分配给不同的网络类型。ServiceNetMap 参数决定了每个服务所使用的网络类型。
例如，可以通过修改以下内容来把 Storage Management 网络服务分配到 Storage Network： 
...

parameters:

  ServiceNetMap:
    NeutronTenantNetwork: tenant
    CeilometerApiNetwork: internal_api
    MongoDbNetwork: internal_api
    CinderApiNetwork: internal_api
    CinderIscsiNetwork: storage
    GlanceApiNetwork: storage
    GlanceRegistryNetwork: internal_api
    KeystoneAdminApiNetwork: internal_api
    KeystonePublicApiNetwork: internal_api
    NeutronApiNetwork: internal_api
    HeatApiNetwork: internal_api
    NovaApiNetwork: internal_api
    NovaMetadataNetwork: internal_api
    NovaVncProxyNetwork: internal_api
    SwiftMgmtNetwork: storage_mgmt
    SwiftProxyNetwork: storage
    HorizonNetwork: internal_api
    MemcachedNetwork: internal_api
    RabbitMqNetwork: internal_api
    RedisNetwork: internal_api
    MysqlNetwork: internal_api
    CephClusterNetwork: storage_mgmt
    CephPublicNetwork: storage
把这些参数改为 storage 会把这些服务放置到 Storage 网络而不是 Storage Management 网络。这意味着，您只需要为 Storage 网络定义一组 parameter_defaults，而不是 Storage Management 网络。

6.3.8. 创建高级 Overcloud

创建 OpenStack 环境的最后一个阶段是运行相关的命令来创建它。我们所使用的命令选项会创建 3 个 Controller 节点、3 个 Compute 节点和 3 个 Ceph Storage 节点。我们同时还使用 第 6.3.5 节 “使用默认的 Overcloud Heat 模板” 中的 Heat 模板堆栈。
运行以下命令来开始高级 Overcloud 的创建： 
$ openstack overcloud deploy --templates ~/templates/my-overcloud -e ~/templates/my-overcloud/environments/network-isolation.yaml -e ~/templates/network-environment.yaml --control-scale 3 --compute-scale 3 --ceph-storage-scale 3 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --ntp-server pool.ntp.org --neutron-network-type vxlan --neutron-tunnel-types vxlan
这个命令包括以下的额外选项：
  • --templates ~/templates/my-overcloud - 通过一组自定义的 Heat 模板，而不是 director 存储的计划来创建 Overcloud。
  • -e ~/templates/my-overcloud/environments/network-isolation.yaml - -e 选项为 Overcloud 计划添加了一个额外的环境文件。在这里，它是一个初始化网络分离配置的环境文件。
  • -e ~/templates/network-environment.yaml - -e 选项为 Overcloud 计划添加了一个环境文件。在这里，它是在 第 6.3.7.2 节 “创建一个高级的 Overcloud 网络环境模板” 中创建的网络环境文件。
  • --control-scale 3 - 把 Controller 节点扩展到 3 个。
  • --compute-scale 3 - 把 Compute 节点扩展到 3 个。
  • --ceph-storage-scale 3 - 把 Ceph Storage 节点扩展到 3 个。
  • --control-flavor control - 为 Controller 节点使用一个特定的 flavor。
  • --compute-flavor compute - 为 Compute 节点使用一个特定的 flavor。
  • --ceph-storage-flavor ceph-storage - 为 Ceph Storage 节点使用一个特定的 flavor。
  • --ntp-server pool.ntp.org - 使用一个 NTP 服务器进行时间同步。这可以保持 Controller 节点集群的同步。
  • --neutron-network-type vxlan - 在 Overcloud 中使用虚拟可扩展 LAN（Virtual Extensible LAN，简称 VXLAN）作为 Neutron 网络。
  • --neutron-network-type vxlan - 在 Overcloud 中使用虚拟可扩展 LAN（Virtual Extensible LAN，简称 VXLAN）作为 Neutron 通道（tunneling）。

注意

运行以下命令可以获得完整的选项列表： 
$ openstack help overcloud deploy
附录 G, 实施参数 包括了其它参数示例。
Overcloud 创建过程开始，director 会部署您的节点。这个过程需要一些时间完成。要查看 Overcloud 创建的状态，在另外一个终端窗口中以 stack 用户身份运行： 
$ source ~/stackrc                # Initializes the stack user to use the CLI commands
$ heat stack-list --show-nested
heat stack-list --show-nested 命令会显示创建 Overcloud 的当前状态。

重要

请注意，这里使用了 -e 选项为 Overcloud 添加了环境文件。director 需要为 第 7 章 创建 Overcloud 后执行的任务 中的特定功能使用这些环境文件。

6.3.9. 访问高级 Overcloud

director 产生一个脚本来配置和帮助验证 Overcloud 和 director 主机间的通讯。director 把这个文件保存为 stack 用户家目录的 overcloudrc 文件。运行以下命令来使用这个文件： 
$ source ~/overcloudrc
这会加载从 director 主机的 CLI 访问 Overcloud 所需的环境变量。要返回 director 主机的原来的环境，运行以下命令： 
$ source ~/stackrc

6.3.10. 隔离 Controller 节点

隔离（fencing）就是把一个节点和集群中的其它节点进行隔离来保护整个集群和它的资源。如果没有隔离功能，一个有问题的节点可能会导致集群中的数据被破坏。
director 使用一个名为 Pacemaker 的工具来为 Controller 节点提供高可用性集群。Pacemaker 使用 STONITH（Shoot-The-Other-Node-In-The-Head）进程来隔离有问题的节点。在默认情况下，STONITH 在集群中被禁用，您需要手工配置来使 Pacemaker 可以控制集群中的每个节点的电源管理。

注意

使用 director 上的 stack 用户以 heat-admin 用户登录到每个节点。Overcloud 会自动把 stack 用户的 SSH 密钥复制到每个节点的 heat-admin。
运行 pcs status 验证您有一个正在运行的集群： 
$ sudo pcs status
Cluster name: openstackHA
Last updated: Wed Jun 24 12:40:27 2015
Last change: Wed Jun 24 11:36:18 2015
Stack: corosync
Current DC: lb-c1a2 (2) - partition with quorum
Version: 1.1.12-a14efad
3 Nodes configured
141 Resources configured
使用 pcs property show 验证 stonith 被禁用： 
$ sudo pcs property show
Cluster Properties:
 cluster-infrastructure: corosync
 cluster-name: openstackHA
 dc-version: 1.1.12-a14efad
 have-watchdog: false
 stonith-enabled: false
查看 Pacemaker 支持的完整 IPMI 选项列表： 
$ sudo pcs stonith describe fence_ipmilan
每个节点都需要配置 IPMI 设备来控制电源管理。这包括为每个节点在 pacemaker 中添加一个 stonith 设备。在集群中使用以下命令：
对于 Controller 节点 1： 
$ sudo pcs stonith create my-ipmilan-for-controller01 fence_ipmilan pcmk_host_list=overcloud-controller-0 ipaddr=192.0.2.205 login=admin passwd=p@55w0rd! lanplus=1 cipher=1 op monitor interval=60s
$ sudo pcs constraint location my-ipmilan-for-controller01 avoids overcloud-controller-0
对于 Controller 节点 2： 
$ sudo pcs stonith create my-ipmilan-for-controller02 fence_ipmilan pcmk_host_list=overcloud-controller-1 ipaddr=192.0.2.206 login=admin passwd=p@55w0rd! lanplus=1 cipher=1 op monitor interval=60s
$ sudo pcs constraint location my-ipmilan-for-controller02 avoids overcloud-controller-1
对于 Controller 节点 3： 
$ sudo pcs stonith create my-ipmilan-for-controller03 fence_ipmilan pcmk_host_list=overcloud-controller-2 ipaddr=192.0.2.206 login=admin passwd=p@55w0rd! lanplus=1 cipher=1 op monitor interval=60s
$ sudo pcs constraint location my-ipmilan-for-controller03 avoids overcloud-controller-2

注意

每个示例中的第二个命令保证了节点不会隔离自己。
运行以下命令来设置所有 stonith 资源： 
$ sudo pcs stonith show
运行以下命令来查看一个特定的 stonith 资源： 
$ sudo pcs stonith show [stonith-name]
最后，把 stonith 属性设置为 true 来启用隔离功能： 
$ sudo pcs property set stonith-enabled=true
验证属性： 
$ sudo pcs property show

6.3.11. 完成高级 Overcloud

这包括创建高级 Overcloud。如需了解更多创建后的功能，请参阅 第 7 章 创建 Overcloud 后执行的任务。