Red Hat Training

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

第 8 章 创建 overcloud 后执行的任务

本章介绍了在创建 overcloud 后需要执行的一些功能。

8.1. 创建 overcloud Tenant 网络

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

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

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

使用 neutron net-list 来确定创建的网络:

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

8.2. 创建 overcloud External 网络

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

使用原生的 VLAN

这个步骤假设 External 网络有一个专用的接口,或一个原生的 VLAN。

source overcloud,并在 Neutron 中创建一个 External 网络:

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

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

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

使用非原生的 VLAN

如果没有使用原生的 VLAN,使用以下命令把网络分配给一个 VLAN:

$ source ~/overcloudrc
$ openstack network create public --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 104
$ 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。

使用 neutron net-list 来确定创建的网络:

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

8.3. 创建额外的浮动 IP 地址网络

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

  • 在网络环境文件中,NeutronExternalNetworkBridge 被设置为 "''"
  • 在部署的过程中已映射了额外的网桥。例如,把一个名为 br-floating 的新网桥映射到 floating 物理网络:

    $ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e ~/templates/network-environment.yaml --neutron-bridge-mappings datacentre:br-ex,floating:br-floating

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

$ openstack network create ext-net --external --provider-physical-network floating --provider-network-type vlan --provider-segment 105
$ openstack network 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

8.4. 创建 overcloud 供应商网络

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

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

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

$ openstack network create provider_network --provider-physical-network datacentre --provider-network-type vlan --provider-segment 201 --share

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

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

$ openstack network 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

8.5. 验证 overcloud

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

运行 Integration Test Suite 之前

如果在 undercloud 上运行这个测试,请确保 undercloud 主机能够访问 overcloud 的内部 API 网络。例如,在 undercloud 主机上添加一个临时的 VLAN,用于使用 172.16.0.201/24 地址访问内部 API 网络 (ID: 201):

$ source ~/stackrc
$ sudo ovs-vsctl add-port br-ctlplane vlan201 tag=201 -- set interface vlan201 type=internal
$ 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
$ openstack role list
+----------------------------------+------------------+
| ID                               | Name             |
+----------------------------------+------------------+
| 6226a517204846d1a26d15aae1af208f | swiftoperator    |
| 7c7eb03955e545dd86bbfeb73692738b | heat_stack_owner |
+----------------------------------+------------------+

如果角色不存在,则创建它:

$ openstack role create heat_stack_owner

运行 Integration Test Suite 之后

在验证完成后,删除所有到 overcloud 的内部 API 的临时连接。在这个示例中,使用以下命令删除以前在 undercloud 中创建的 VLAN:

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

8.6. 隔离 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

Controller 节点为 director 支持的不同电源管理设备包括了一组隔离代理。这包括:

表 8.1. 隔离代理

设备

类型

fence_ipmilan

Intelligent Platform Management Interface (IPMI)

fence_idracfence_drac5

Dell Remote Access Controller (DRAC)

fence_ilo

Integrated Lights-Out (iLO)

fence_ucs

Cisco UCS - 如需了解更多信息,请参阅 Configuring Cisco Unified Computing System (UCS) Fencing on an OpenStack High Availability Environment

fence_xvmfence_virt

Libvirt 和 SSH

这一节的剩余部分会使用 IPMI 代理(fence_ipmilan)作为示例。

查看 Pacemaker 支持的完整 IPMI 选项列表:

$ sudo pcs stonith describe fence_ipmilan

每个节点都需要配置 IPMI 设备来控制电源管理。这包括为每个节点在 pacemaker 中添加一个 stonith 设备。在集群中使用以下命令:

注意

每个示例中的第二个命令保证了节点不会隔离自己。

对于 Controller 节点 0:

$ sudo pcs stonith create my-ipmilan-for-controller-0 fence_ipmilan pcmk_host_list=overcloud-controller-0 ipaddr=192.168.24.205 login=admin passwd=p@55w0rd! lanplus=1 cipher=1 op monitor interval=60s
$ sudo pcs constraint location my-ipmilan-for-controller-0 avoids overcloud-controller-0

对于 Controller 节点 1:

$ sudo pcs stonith create my-ipmilan-for-controller-1 fence_ipmilan pcmk_host_list=overcloud-controller-1 ipaddr=192.168.24.206 login=admin passwd=p@55w0rd! lanplus=1 cipher=1 op monitor interval=60s
$ sudo pcs constraint location my-ipmilan-for-controller-1 avoids overcloud-controller-1

对于 Controller 节点 2:

$ sudo pcs stonith create my-ipmilan-for-controller-2 fence_ipmilan pcmk_host_list=overcloud-controller-2 ipaddr=192.168.24.207 login=admin passwd=p@55w0rd! lanplus=1 cipher=1 op monitor interval=60s
$ sudo pcs constraint location my-ipmilan-for-controller-2 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

8.7. 修改 overcloud 环境

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

$ 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 选项添加它。例如:

$ 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

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

重要

建议您不要手动修改 overcloud 的配置,因为 director 可能会在以后覆盖这些修改。

8.8. 把虚拟机导入到 overcloud

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

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

$ openstack server image create instance_name --name image_name
$ openstack image save image_name --file exported_vm.qcow2

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

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

每个虚拟机磁盘都需要从存在的 OpenStack 环境中复制到新的 Red Hat OpenStack Platform。使用 QCOW 的快照将会丢掉它原始的层系统。

8.9. 从一个 overcloud Compute 节点中迁移虚拟机

在一些情况下,您可以在 overcloud 计算节点上执行维护操作。为了避免停机,请按照以下方法把计算节点上的虚拟机迁移到 overcloud 中的另一个计算节点。

所有计算节点都需要一个共享的 SSH,让每一个主机的 nova 用户在迁移过程中具有相应的访问权限。以下脚本在 undercloud 上创建 SSH 密钥,并将它复制到所有计算节点,然后设置适当的配置和权限:

#!/bin/bash

ssh-keygen -f ~/nova_rsa -t rsa -N ''

ALLCOMPUTES=$(openstack server list --name ".*compute.*" -c Networks -f csv --quote none | tail -n+2 | awk -F '=' '{ print $2 }')

for COMPUTE in $ALLCOMPUTES
do
  ssh heat-admin@$COMPUTE "sudo usermod -s /bin/bash nova"
  ssh heat-admin@$COMPUTE "sudo mkdir -p /var/lib/nova/.ssh"
  scp ~/nova* heat-admin@$COMPUTE:~/
  ssh heat-admin@$COMPUTE "sudo cp ~/nova_rsa /var/lib/nova/.ssh/id_rsa"
  ssh heat-admin@$COMPUTE "sudo cp ~/nova_rsa.pub /var/lib/nova/.ssh/id_rsa.pub"
  ssh heat-admin@$COMPUTE "sudo rm ~/nova_rsa*"
  ssh heat-admin@$COMPUTE "echo 'StrictHostKeyChecking no'|sudo tee -a /var/lib/nova/.ssh/config"
  ssh heat-admin@$COMPUTE "sudo cat /var/lib/nova/.ssh/id_rsa.pub|sudo tee -a /var/lib/nova/.ssh/authorized_keys"
  ssh heat-admin@$COMPUTE "sudo chown -R nova: /var/lib/nova/.ssh"
  ssh heat-admin@$COMPUTE "sudo su -c 'chmod 600 /var/lib/nova/.ssh/*' nova"
  ssh heat-admin@$COMPUTE "sudo chmod 700 /var/lib/nova/.ssh"
done

rm ~/nova_rsa*

运行此脚本后,请测试计算节点之间的 SSH 连接。从 undercloud 登录计算节点:

$ ssh heat-admin@192.0.1.10

切换到 nova 用户:

$ sudo su - nova

尝试以 nova 用户身份登录另一个计算节点:

$ ssh nova@192.0.1.11

返回到 director 节点,对 overcloudrc 执行 source 命令,并获取当前的 nova 服务列表:

$ source ~/stack/overcloudrc
$ openstack compute service list

在要迁移的节点上禁用 nova-compute 服务。

$ openstack compute service set [hostname] nova-compute --disable

这会防止新的虚拟机在它上面运行。

开始从节点迁移实例。以下命令可迁移一个实例:

$ openstack server migrate [server-name]

为您需要从已禁用计算节点迁移的每个实例运行此命令。

使用以下命令检索迁移过程的当前状态:

$ nova migration-list

当一个实例的迁移过程完成后,它在 nova 中的状态将变为 VERIFY_RESIZE。此时,您可以选择确认迁移已成功完成,或把它恢复到原来的状态。要确认迁移已成功完成,运行以下命令:

$ nova resize-confirm [server-name]

为具有 VERIFY_RESIZE 状态的每个实例运行此命令。

这会从一个主机上迁移所有实例。现在,您就可以在没有实例下线的情况下执行维护操作。要把主机返回到启用的状态,运行以下命令:

$ openstack compute service set [hostname] nova-compute --enable

8.10. 运行 Ansible 自动化

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

重要

动态清单工具仅包括 undercloud 以及默认的 controllercompute overcloud 节点。不支持其他角色。

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

$ souce ~/stackrc
$ tripleo-ansible-inventory --list

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

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

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

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

ansible [HOSTS] -i /bin/tripleo-ansible-inventory [OTHER OPTIONS]
  • [HOSTS] 更换为要使用的主机类型。例如:

    • controller,适用于所有 Controller 节点
    • compute,适用于所有 Compute 节点
    • overcloud,适用于所有 overcloud 子节点,例如 controllercompute
    • undercloud,适用于 undercloud
    • "*",适用于所有节点
  • [OTHER OPTIONS] 更换为额外的 Ansible 选项。以下是一些有用的选项:

    • --ssh-extra-args='-o StrictHostKeyChecking=no',用于跳过主机密钥检查确认操作。
    • -u [USER],用于更改执行 Ansible 自动化的 SSH 用户。默认的 overcloud SSH 用户由动态清单中的 ansible_ssh_user 参数自动定义。-u 选项会覆盖此参数。
    • -m [MODULE],使用特定的 Ansible 模块。默认为 command,用于执行 Linux 命令。
    • -a [MODULE_ARGS],为选定的模块定义参数。
重要

overcloud 上的 Ansible 自动化不属于标准 overcloud 堆栈范围之内。这表示后续执行的 openstack overcloud deploy 命令可能会覆盖 overcloud 节点上基于 Ansible 的 OpenStack Platform 服务配置。

8.11. 防止 overcloud 被删除

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

"stacks:delete": "rule:deny_stack_user"

把它改为:

"stacks:delete": "rule:deny_everybody"

保存这个文件。

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

8.12. 删除 overcloud

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

删除任何现有的 overcloud:

$ openstack stack delete overcloud

确认删除 overcloud:

$ openstack stack list

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

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