Red Hat Training

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

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

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

9.1. 管理容器化服务

Overcloud 会以容器的形式来运行大部分的 OpenStack Platform 服务。在某些情况下,您可能需要控制主机上的单个服务。本节介绍了一些可在 overcloud 节点上运行以管理容器化服务的常用 docker 命令。如需更加全面地了解有关使用 docker 管理容器的信息,请参阅 Getting Started with Containers 指南中的“Working with Docker formatted containers”

注意

在运行这些命令之前,请先检查您是否已登录 overcloud 节点且未在 undercloud 上运行这些命令。

列出容器和镜像

要列出正在运行的容器,请使用以下命令:

$ sudo docker ps

如果还要列出已停止或已失败的容器,请在命令中加入 --all 选项:

$ sudo docker ps --all

要列出容器镜像,请使用以下命令:

$ sudo docker images

检查容器属性

要查看容器或容器镜像的属性,请使用 docker inspect 命令。例如,要检查 keystone 容器,请使用以下命令:

$ sudo docker inspect keystone

管理基本容器操作

要重启容器化服务,请使用 docker restart 命令。例如,要重启 keystone 容器,请使用以下命令:

$ sudo docker restart keystone

要停止容器化服务,请使用 docker stop 命令。例如,要停止 keystone 容器,请使用以下命令:

$ sudo docker stop keystone

要启动已停止的容器化服务,请使用 docker start 命令。例如,要启动 keystone 容器,请使用以下命令:

$ sudo docker start keystone
注意

在重启容器后,针对其中的服务配置文件所做的所有更改都会恢复。这是因为容器会基于节点的本地文件系统上的 /var/lib/config-data/puppet-generated/ 中所含的文件,来重新生成服务配置。例如,如果您编辑了 keystone 容器中的 /etc/keystone/keystone.conf,并重启了该容器,则该容器会使用节点的本地文件系统上的 /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf 来重新生成配置,以覆盖重启之前在该容器中所做的所有更改。

监控容器

要查看容器化服务的日志,请使用 docker logs 命令。例如,要查看 keystone 容器的日志,请使用以下命令:

$ sudo docker logs keystone

访问容器

要进入容器化服务的 shell,请使用 docker exec 命令启动 /bin/bash。例如,要进入 keystone 容器的 shell,请使用以下命令:

$ sudo docker exec -it keystone /bin/bash

要以 root 用户的身份进入 keystone 容器的 shell,请使用以下命令:

$ sudo docker exec --user 0 -it <NAME OR ID> /bin/bash

要退出容器,请使用以下命令:

# exit

如需了解有关对 OpenStack Platform 容器化服务进行故障诊断的信息,请参阅第 13.7.3 节 “容器化服务故障”

9.2. 创建 overcloud Tenant 网络

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

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

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

确认所创建的网络:

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

9.3. 创建 overcloud External 网络

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

使用原生的 VLAN

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

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

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

确认所创建的网络:

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

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

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

  • 在网络环境文件中,NeutronExternalNetworkBridge 被设置为 "''"
  • 在部署的过程中已映射了额外的网桥。例如,要将名为 br-floating 的新网桥映射到 floating 物理网络,请在环境文件中使用以下内容:

    parameter_defaults:
      NeutronBridgeMappings: "datacentre:br-ex,floating:br-floating"

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

$ source ~/overcloudrc
(overcloud) $ openstack network create ext-net --external --provider-physical-network floating --provider-network-type vlan --provider-segment 105
(overcloud) $ openstack subnet 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

9.5. 创建 overcloud 供应商网络

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

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

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

$ source ~/overcloudrc
(overcloud) $ openstack network create provider_network --provider-physical-network datacentre --provider-network-type vlan --provider-segment 201 --share

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

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

(overcloud) $ openstack subnet 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

其他网络可能需要通过供应商网络访问外部。在这种情况下,可创建一个新的路由器,使其他网络可以通过供应商网络传送流量:

(overcloud) $ openstack router create external
(overcloud) $ openstack router set --external-gateway provider_network external

将其他网络添加到该路由器。例如,如果有一个子网名为 subnet1,可以使用以下命令将其添加到路由器:

(overcloud) $ openstack router add subnet external subnet1

这会将 subnet1 添加到路由表,并允许使用 subnet1 的流量传送到供应商网络。

9.6. 验证 overcloud

Overcloud 会使用 OpenStack Integration Test Suite (tempest) 工具集来执行一系列集成测试。本节介绍了如何为运行集成测试做好准备。有关使用 OpenStack Integration Test Suite 的完整说明,请参阅 OpenStack Integration Test Suite Guide

运行 Integration Test Suite 之前

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

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

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

(overcloud) $ openstack role create heat_stack_owner

运行 Integration Test Suite 之后

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

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

9.7. 修改 overcloud 环境

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

$ source ~/stackrc
(undercloud) $ 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 选项添加它。例如:

$ source ~/stackrc
(undercloud) $ 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 可能会在以后覆盖这些修改。

9.8. 运行动态清单脚本

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

步骤

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

    $ source ~/stackrc
    (undercloud) $ 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"]}
  2. 要在您的环境中实施 Ansible playbook,请运行 ansible 命令,并使用 -i 选项包括动态清单工具的完整路径。例如:

    (undercloud) $ 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 服务配置。

9.9. 把虚拟机导入到 overcloud

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

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

$ source ~/overcloudrc
(overcloud) $ openstack server image create instance_name --name image_name
(overcloud) $ openstack image save image_name --file exported_vm.qcow2

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

(overcloud) $ openstack image create imported_image --file exported_vm.qcow2 --disk-format qcow2 --container-format bare
(overcloud) $ 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 的快照将会丢掉它原始的层系统。

9.10. 从 Compute 节点中迁移实例

在某些情况下,您可能在某个 overcloud Compute 节点上执行维护操作。为了避免停机,可以将该 Compute 节点上的虚拟机迁移到 overcloud 中的另一个 Compute 节点上。

director 可配置所有 Compute 节点来执行安全的迁移。所有 Compute 节点还需要有共享的 SSH 密钥,以便每个主机的 nova 用户在迁移过程中能够访问其他 Compute 节点。director 会使用 OS::TripleO::Services::NovaCompute 可组合服务来创建该密钥。该可组合服务是所有 Compute 角色默认包含的主要服务之一(请参阅 Advanced Overcloud Customization 中的“Composable Services and Custom Roles”)。

步骤

  1. 从 undercloud 中选择一个 Compute 节点,然后将其禁用:

    $ source ~/overcloudrc
    (overcloud) $ openstack compute service list
    (overcloud) $ openstack compute service set [hostname] nova-compute --disable
  2. 列出 Compute 节点上的所有实例:

    (overcloud) $ openstack server list --host [hostname] --all-projects
  3. 使用以下命令之一迁移实例:

    1. 将实例迁移至您选择的特定主机:

      (overcloud) $ openstack server migrate [instance-id] --live [target-host]--wait
    2. nova-scheduler 自动选择目标主机:

      (overcloud) $ nova live-migration [instance-id]
    3. 一次性实时迁移所有实例:

      $ nova host-evacuate-live [hostname]
      注意

      nova 命令可能会引发一些弃用警告,这些警告信息可以被安全忽略。

  4. 稍等片刻,直至迁移完成。
  5. 确认迁移成功完成:

    (overcloud) $ openstack server list --host [hostname] --all-projects
  6. 继续迁移实例,直到所选 Compute 节点中不剩任何实例。

这就从 Compute 节点中迁移了所有实例。现在即可在该节点上执行维护,而无需让任何实例停机。要让 Compute 节点恢复启用状态,运行以下命令:

$ source ~/overcloudrc
(overcloud) $ openstack compute service set [hostname] nova-compute --enable

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

9.12. 删除 overcloud

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

删除任何现有的 overcloud:

$ source ~/stackrc
(undercloud) $ openstack overcloud delete overcloud

确认删除 overcloud:

(undercloud) $ openstack stack list

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

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

9.13. 检查令牌刷新间隔

Identity 服务 (keystone) 会使用基于令牌的系统来控制对其他 OpenStack 服务的访问。在运行了一定时间后,数据库中会积累大量未使用的令牌;默认的 cron 作业每天都会刷新令牌表。建议您对自己的环境进行监控并按需调整令牌刷新间隔。

对于 overcloud,可以使用 KeystoneCronToken 值来调整间隔。如需了解更多信息,请参阅 Overcloud Parameters 指南。