Red Hat Training

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

第 7 章 创建 Overcloud 后执行的任务

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

7.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 |
+-----------------------+-------------+--------------------------------------+

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

此命令还会将网络映射到 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 |
+-----------------------+-------------+--------------------------------------+

7.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

7.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

7.5. 验证 Overcloud

overcloud 使用 OpenStack Validation(tempest)工具集进行一组集成测试。以下步骤展示了如何使用此工具集验证 overcloud。如果从 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 Validation 之前,请确认 overcloud 中存在 heat_stack_owner 角色:

$ source ~/overcloudrc
$ openstack role list
+----------------------------------+------------------+
| ID                               | Name             |
+----------------------------------+------------------+
| 6226a517204846d1a26d15aae1af208f | swiftoperator    |
| 7c7eb03955e545dd86bbfeb73692738b | heat_stack_owner |
+----------------------------------+------------------+

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

$ openstack role create heat_stack_owner

安装验证工具集:

$ sudo yum install openstack-tempest

以上命令不会安装所需的 tempest 插件本身;因此,您必须手动安装(见下例)。插件集合视您的 OpenStack 安装而异。

$ sudo yum install python-glance-tests python-keystone-tests \
 python-horizon-tests-tempest python-neutron-tests \
 python-cinder-tests python-nova-tests python-swift-tests \
 python-ceilometer-tests python-gnocchi-tests python-aodh-tests

另外,也可使用以下命令查找所有已安装的 OpenStack 组件并且自动安装必要的插件。

$ sudo /usr/share/openstack-tempest-*/tools/install_test_packages.py

stack 用户的家目录中设置一个 tempest 目录,并复制一个本地版本的 Tempest 套件:

$ mkdir ~/tempest
$ cd ~/tempest
$ /usr/share/openstack-tempest-12.2.1/tools/configure-tempest-directory
注意

显示的 openstack-tempest 版本或有不同,具体视安装的 undercloud 版本而异。

这会创建一个本地版本的验证工具集。

在 overcloud 创建过程完成后,director 会创建一个名为 ~/tempest-deployer-input.conf 的文件。此文件会提供一组和您的 overcloud 相关的 Tempest 配置选项。运行以下命令来使用此文件配置 Tempest:

$ tools/config_tempest.py --deployer-input ~/tempest-deployer-input.conf --debug --create identity.uri $OS_AUTH_URL identity.admin_password $OS_PASSWORD --network-id d474fe1f-222d-4e32-9242-cd1fefe9c14b

$OS_AUTH_URL$OS_PASSWORD 这两个环境变量使用 overcloudrc 中设置的值。--network-id 是在 第 7.2 节 “创建 Overcloud External 网络” 中创建的外部网络的 UUID。

重要

这个配置脚本从 Tempest 测试中下载 Cirros 镜像。请确保这个目录可以直接访问互联网或通过代理服务器访问互联网。如果命令行操作需要通过代理进行,需要设置 http_proxy 环境变量。

使用以下命令运行整个 Tempest 测试:

$ tools/run-tests.sh
注意

完整运行整个 Tempest 测试可能会需要佷长时间。您可以使用 '.*smoke' 选项来只运行其中一部分的测试。

$ tools/run-tests.sh '.*smoke'

每项测试会针对 overcloud 运行,后续的输出会显示每一项测试及其结果。在相同目录中会产生一个包括更多测试信息的 tempest.log 文件。例如,输出结果可能会显示以下失败的测试:

{2} tempest.api.compute.servers.test_servers.ServersTestJSON.test_create_specify_keypair [18.305114s] ... FAILED

这会包括一个相关的、包括更多信息的日志条目。在日志中搜索使用冒号分隔的测试命名空间的最后两个部分。在这个示例中,搜索 ServersTestJSON:test_create_specify_keypair

$ grep "ServersTestJSON:test_create_specify_keypair" tempest.log -A 4
2016-03-17 14:49:31.123 10999 INFO tempest_lib.common.rest_client [req-a7a29a52-0a52-4232-9b57-c4f953280e2c ] Request (ServersTestJSON:test_create_specify_keypair): 500 POST http://192.168.201.69:8774/v2/2f8bef15b284456ba58d7b149935cbc8/os-keypairs 4.331s
2016-03-17 14:49:31.123 10999 DEBUG tempest_lib.common.rest_client [req-a7a29a52-0a52-4232-9b57-c4f953280e2c ] Request - Headers: {'Content-Type': 'application/json', 'Accept': 'application/json', 'X-Auth-Token': '<omitted>'}
        Body: {"keypair": {"name": "tempest-key-722237471"}}
    Response - Headers: {'status': '500', 'content-length': '128', 'x-compute-request-id': 'req-a7a29a52-0a52-4232-9b57-c4f953280e2c', 'connection': 'close', 'date': 'Thu, 17 Mar 2016 04:49:31 GMT', 'content-type': 'application/json; charset=UTF-8'}
        Body: {"computeFault": {"message": "The server has either erred or is incapable of performing the requested operation.", "code": 500}} _log_request_full /usr/lib/python2.7/site-packages/tempest_lib/common/rest_client.py:414
注意

使用 -A 4 选项会显示接下来的 4 行内容,它们通常是请求的 header 和 body,以及返回的 header 和 body。

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

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

7.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 支持的不同电源管理设备包括了一组隔离代理。这包括:

表 7.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.0.2.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.0.2.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.0.2.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

7.7. 修改 Overcloud 环境

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

$ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e ~/templates/network-environment.yaml -e ~/templates/storage-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

director 会在 heat 中检查 overcloud 栈,然后根据环境文件和 heat 模板更新栈中的每一项目。它不会重新创建 overcloud,而是更改现有的 overcloud。

如果需要包括一个新的环境文件,在 openstack overcloud deploy 命令中使用 -e 选项添加它。例如:

$ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e ~/templates/network-environment.yaml -e ~/templates/storage-environment.yaml -e ~/templates/new-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

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

重要

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

7.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 的快照将会丢掉它原始的层系统。

7.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

7.10. 防止 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,请把策略恢复为原先的值。

7.11. 删除 Overcloud

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

删除任何现有的 overcloud:

$ openstack stack delete overcloud

确认删除 overcloud:

$ openstack stack list

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

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