Red Hat Training
A Red Hat training course is available for Red Hat OpenStack Platform
director 的安装和使用
使用 Red Hat OpenStack Platform director 创建 OpenStack 云环境
摘要
第 1 章 简介
图 1.1. Undercloud 和 Overcloud 的基本结构
1.1. Undercloud
- 环境规划 - Undercloud 提供了为用户分配 Red Hat OpenStack Platform 角色(Compute、Controller 和不同的存储节点)的功能。
- 逻辑系统控制 - Undercloud 使用每个节点的智能平台管理界面(Platform Management Interface,简称 IPMI)来进行电源管理控制,并使用一个基于 PXE 的服务来发现硬件的属性来在每个节点上安装 OpenStack。通过这个功能,可以把裸机系统部署为 OpenStack 节点。
- 编配(Orchestration) - Undercloud 提供了一组 YAML 模板来创建一个 OpenStack 环境。
- OpenStack Dashboard(horizon) - director 的基于 web 的控制台。
- OpenStack Bare Metal(ironic)和 OpenStack Compute(nova) - 管理裸机节点。
- OpenStack Networking(neutron)和 Open vSwitch - 控制裸机节点的网络。
- OpenStack Image Server(glance) - 存储写到裸机上的镜像。
- OpenStack Orchestration(heat)和 Puppet - 提供对节点的编配功能,并在 director 把 Overcloud 镜像写入到磁盘后配置节点。
- OpenStack Telemetry(ceilometer) - 监控并采集数据。
- OpenStack Identity(keystone) - 提供 director 组件的验证和授权功能。
- MariaDB - director 的后台数据库。
- RabbitMQ - director 组件的消息队列。
1.2. Overcloud
- Controller(控制器) - 为 OpenStack 环境提供管理、网络和高可用性服务的节点。在一个理想的 OpenStack 环境中,推荐在一个高可用性集群中使用 3 个 Controller 节点。一个默认 Controller 节点包括以下组件:horizon、keystone、nova API、neutron server、Open vSwitch、glance、cinder volume、cinder API、swift storage、swift proxy、heat engine、heat API、ceilometer、MariaDB 和 RabbitMQ。Controller 还会使用 Pacemaker 和 Galera 来实现高可用性功能。
- Compute(计算) - 为 OpenStack 环境提供计算资源的节点。随着时间的推移,可以通过添加更多节点来扩展您的环境。一个默认的 Compute 节点包括以下组件:nova Compute、nova KVM、ceilometer agent 和 Open vSwitch
- Storage(存储) - 为 OpenStack 环境提供存储的节点。它可以包括以下节点:
- Ceph Storage 节点 - 用来组成存储集群,每个节点包括一个 Ceph Object Storage Daemon(OSD)。另外,director 会在实施 Ceph Storage 节点的 Controller 节点上安装 Ceph Monitor。
- Block storage(cinder)- 作为 HA Controller 节点的外部块存储。这类节点包括以下组件:cinder volume、ceilometer agent 和 Open vSwitch。
- Object storage(swift) - 作为 HA Controller 节点的外部对象存储。这类节点包括以下组件:cinder storage、ceilometer agent 和 Open vSwitch。
1.3. 高可用性
- Pacemaker - Pacemaker 是集群资源的管理者,它会管理并监控一个集群中所有节点上的 OpenStack 组件的可用性。
- HA Proxy(HA 代理) - 为集群提供负载平衡和代理服务。
- Galera - 提供在集群中复制 OpenStack Platform 数据库的服务。
- Memcached - 提供数据库缓存服务。
注意
1.4. Ceph 存储
第 2 章 要求
2.1. 环境配置要求
最小的配置要求
- 一个作为 Red Hat OpenStack Platform director 的主机
- 一个作为 Red Hat OpenStack Platform Compute 节点的主机
- 一个作为 Red Hat OpenStack Platform Controller 节点的主机
推荐的配置要求
- 一个作为 Red Hat OpenStack Platform director 的主机
- 3 个作为 Red Hat OpenStack Platform Compute 节点的主机
- 3 个作为一个集群中的 Red Hat OpenStack Platform Controller 节点的主机
- 3 个作为一个集群中的 Red Hat Ceph Storage 节点的主机
- 推荐所有主机都使用裸机系统。最起码,Compute 节点需要使用裸机系统。
- 因为 director 需要控制电源管理,所以全部 Overcloud 裸机系统都需要一个智能平台管理界面(IPMI)。
2.2. Undercloud 的配置要求
- 支持 Intel 64 或 AMD64 CPU 扩展的 8 核 64 位 x86 处理器。
- 最少 16GB 内存。
- 最少具有 40GB 可用磁盘空间。
- 最少两个 1 Gbps 网卡。但是,推荐使用 10 Gbps 网卡来作为
Provisioning
网络的接口,特别是您的 Overcloud 环境中有大量的节点。 - 安装 Red Hat Enterprise Linux 7.2 作为主机操作系统。
2.3. 网络要求
Provisioning 网络
- director 用来部署和管理 Overcloud 节点的私人网络。Provisioning 网络提供了 DHCP 和 PXE 引导功能来帮助发现在 Overcloud 中使用的主机。这个网络最好使用一个主干(trunk)接口中的原生 VLAN,这样 director 服务器就可以处理 PXE 引导和 DHCP 请求。另外,这个网络还被用来通过 IPMI 对所有 Overcloud 节点进行电源管理。External 网络
- 用来远程连接到所有节点的一个独立网络。连接到这个网络的接口需要一个可路由的 IP 地址(静态定义或通过一个外部 DHCP 服务动态分配)。
- 所有机器都需要最少两个网卡(NIC)。在一个典型的最小配置中,使用:
- 一个 NIC 用于 Provisioning 网络,另外一个 NIC 作为 External 网络。或
- 一个 NIC 在原生 VLAN 中用于 Provisioning 网络,另外一个 NIC 用于 tagged VLAN(使用子网处理不同的 Overcloud 网络类型)。
- 额外的物理 NIC 可以用来分离不同的网络、创建绑定的接口或协调 tagged VLAN 的网络数据。
- 如果使用 VLAN 分离网络流量类型,使用支持 802.1Q 标准的交换机来提供 tagged VLAN。
- 在 Overcloud 创建节点时,在所有 Overcloud 机器间使用一个名称指代 NIC。理想情况下,您应该在每个系统上对每个相关的网络都使用相同的 NIC 来避免混淆。例如,Provisioning 网络使用主(primary)NIC, OpenStack 服务使用从(secondary) NIC。
- 确保 Provisioning 网络的 NIC 和在 director 机器上用来进行远程连接的 NIC 不同。director 会使用 Provisioning NIC 创建一个网桥,它会忽略所有远程连接。在 director 系统上需要使用 External NIC 进行远程连接。
- Provisioning 网络需要一个与您的环境大小相匹配的 IP 范围。使用以下原则来决定包括在这个范围内的 IP 地址数量:
- 最少为每个连接到 Provisioning 网络的节点包括一个 IP。
- 如果有高可用性配置,则需要包括一个额外的 IP 地址来作为集群的虚拟 IP。
- 为扩展环境准备额外的 IP 地址。
注意
在 Provisioning 网络中需要避免重复的 IP 地址。相关信息,请参阅 第 11.5 节 “排除 Provisioning Network 中出现的 IP 地址冲突的问题”。注意
如需了解更多与配置您的 IP 地址使用的信息(如用于 storage、provider 和 tenant 网络),请参阅 the Networking Guide。 - 把所有 Overcloud 系统设置为使用 Provisioning NIC 进行 PXE 引导,并在 External NIC 以及系统的所有其它 NIC 上禁用 PXE 引导。另外,还需要确保 Provisioning NIC 的
PXE boot
设置位于引导顺序的最上面(在硬盘和 CD/DVD 驱动之前引导)。 - 所有 Overcloud 裸机系统都需要一个 IPMI 连接到 Provisioning 网络。director 需要使用它来控制每个节点的电源管理。
- 请记录下每个 Overcloud 系统的以下信息:Provisioning NIC 的 MAC 地址、IPMI NIC 的 IP 地址、IPMI 用户名和 IPMI 密码。在设置 Overcloud 节点时需要使用这些信息。
重要
- 使用网络分段(network segmentation)技术来控制网络数据并隔离敏感数据。扁平化网络(flat network)通常不是非常安全。
- 限制对服务和端口的访问。
- 使用适当的防火墙设置以及密码。
- 启用 SELinux。
2.4. Overcloud 的配置要求
2.4.1. Compute 节点的配置要求
- 处理器
- 支持带有 Intel 64 或 AMD64 CPU 扩展并启用了 Intel VT 硬件虚拟扩展的 64 位 x86 处理器。我们推荐所使用的处理器最少有 4 个内核。
- 内存
- 最少 6GB 内存。另外,还需要加上提供给虚拟机实例使用的内存。
- 磁盘空间
- 最少具有 40GB 可用磁盘空间。
- 网据接口卡
- 最少一个 1 Gbps 网络接口卡。但在生产环境中,推荐最少使用两个网块。额外的网卡可以组成绑定接口,或处理标记的 VLAN 网络(tagged VLAN)流量。
- 智能平台管理界面(Intelligent Platform Management Interface,简称 IPMI)
- 每个 Compute 节点需要服务器主板具有 IPMI 功能。
2.4.2. Controller 节点的要求
- 处理器
- 支持 Intel 64 或 AMD64 CPU 扩展的 64 位 x86 处理器。
- 内存
- 最少 6GB 内存。
- 磁盘空间
- 最少具有 40GB 可用磁盘空间。
- 网据接口卡
- 最少两个 1 Gbps 网络接口卡。额外的网卡可以组成绑定接口,或处理标记的 VLAN 网络(tagged VLAN)流量。
- 智能平台管理界面(Intelligent Platform Management Interface,简称 IPMI)
- 每个 Controller 节点需要服务器主板具有 IPMI 功能。
2.4.3. Ceph 存储节点的要求
- 处理器
- 支持 Intel 64 或 AMD64 CPU 扩展的 64 位 x86 处理器。
- 内存
- 所需的内存数量取决于存储空间的数量。理想情况下,每 1TB 硬盘空间需要最少 1GB 内存。
- 磁盘空间
- 所需的存储数量取决于内存空间的数量。理想情况下,每 1TB 硬盘空间需要最少 1GB 内存。
- 磁盘布局
- 推荐的 Red Hat Ceph Storage 节点配置需要和以下类似的磁盘布局:
/dev/sda
- root 磁盘。director 把主 Overcloud 镜像复制到这个磁盘。/dev/sdb
- journal 磁盘。这个磁盘被分为不同的分区来保存 Ceph OSD 的日志信息。例如,/dev/sdb1
、/dev/sdb2
、/dev/sdb3
等。 journal 磁盘通常需要是一个固态磁盘(SSD)来保证系统的性能。/dev/sdc
和后续 - OSD 磁盘。可以根据您的存储需要使用多个磁盘。
本文档包括了把您的 Ceph 存储磁盘映射到 director 的方法。 - 网络接口卡
- 最少一个 1 Gbps 网络接口卡。但在生产环境中,推荐最少使用两个网块。额外的网卡可以组成绑定接口,或处理标记的 VLAN 网络(tagged VLAN)流量。推荐为存储节点使用10 Gbps 接口,特别是所创建的 OpenStack Platform 环境需要处理大量网络数据时。
- 智能平台管理界面(Intelligent Platform Management Interface,简称 IPMI)
- 每个 Ceph 节点需要服务器主板具有 IPMI 功能。
重要
# parted [device] mklabel gpt
2.5. 软件仓库的要求
表 2.1. OpenStack Platform 软件仓库
名称
|
软件仓库
|
描述
|
---|---|---|
Red Hat Enterprise Linux 7 Server (RPMs)
| rhel-7-server-rpms
|
基本操作系统的软件仓库。
|
Red Hat Enterprise Linux 7 Server - Extras (RPMs)
| rhel-7-server-extras-rpms
|
包括 Red Hat OpenStack Platform 的依赖软件包。
|
Red Hat Enterprise Linux 7 Server - RH Common (RPMs)
| rhel-7-server-rh-common-rpms
|
包括部署和配置 Red Hat OpenStack Platform 的工具程序。
|
Red Hat Satellite Tools for RHEL 7 Server RPMs x86_64
| rhel-7-server-satellite-tools-6.1-rpms
|
使用 Red Hat Satellite 6 管理主机的工具。
|
Red Hat Enterprise Linux High Availability (for RHEL 7 Server) (RPMs)
| rhel-ha-for-rhel-7-server-rpms
|
Red Hat Enterprise Linux 的高可用性工具。用于 Controller 节点的高可用性功能。
|
Red Hat Enterprise Linux OpenStack Platform 8 director for RHEL 7 (RPMs)
| rhel-7-server-openstack-8-director-rpms
|
Red Hat OpenStack Platform director 软件仓库。
|
Red Hat Enterprise Linux OpenStack Platform 8 for RHEL 7 (RPMs)
| rhel-7-server-openstack-8-rpms
|
核心 Red Hat OpenStack Platform 软件仓库。
|
Red Hat Ceph Storage OSD 1.3 for Red Hat Enterprise Linux 7 Server (RPMs)
| rhel-7-server-rhceph-1.3-osd-rpms
|
(Ceph Storage 节点)Ceph Storage Object Storage 守护进程的软件仓库。在 Ceph Storage 节点上安装。
|
Red Hat Ceph Storage MON 1.3 for Red Hat Enterprise Linux 7 Server (RPMs)
| rhel-7-server-rhceph-1.3-mon-rpms
|
(Ceph Storage 节点)Ceph Storage Monitor 守护进程的软件仓库。在使用 Ceph Storage 节点的 OpenStack 环境的 Controller 节点上安装。
|
第 3 章 规划您的 Overcloud
3.1. 规划节点的实施角色
- Controller
- 为控制您的环境提供关键服务。它包括 dashboard 服务(horizon)、用户验证服务(keystone)、镜像存储服务(glance)、网络服务(neutron)和编配服务(heat),以及在使用多个 Controller 节点时的高可用性服务。一个基本的 Red Hat OpenStack Platform 环境中需要最少一个 Controller 节点。
- Compute
- 一个作为虚拟机监控程序(hypervisor)的物理服务器,它为环境中运行的虚拟机提供处理能力。一个基本的 Red Hat OpenStack Platform 环境中需要最少一个 Compute 节点。
- Ceph-Storage
- 提供 Red Hat Ceph Storage 的一个主机。额外的 Ceph Storage 主机可以在一个集群中扩展。这个实施角色是可选的。
- Cinder-Storage
- 为 OpenStack 的 cinder 服务提供外部块存储的主机。这个实施角色是可选的。
- Swift-Storage
- 为 OpenStack 的 Swift 服务提供外部对象存储的主机。这个实施角色是可选的。
表 3.1. 使用情景的节点部署角色
|
Controller
|
Compute
|
Ceph-Storage
|
Swift-Storage
|
Cinder-Storage
|
总计
|
---|---|---|---|---|---|---|
小型 Overcloud
|
1
|
1
|
-
|
-
|
-
|
2
|
中型 Overcloud
|
1
|
3
|
-
|
-
|
-
|
4
|
带有额外 Object 和 Block 存储的中型 Overcloud
|
1
|
3
|
-
|
1
|
1
|
6
|
带有高可用性功能的中型 Overcloud
|
3
|
3
|
-
|
-
|
-
|
6
|
带有高可用性和 Ceph 存储的中型 Overcloud
|
3
|
3
|
3
|
-
|
-
|
9
|
3.2. 规划网络
表 3.2. 网络类型分配
网络类型
|
描述
|
用于
|
---|---|---|
IPMI
|
节点电源管理的网络。这个网络在安装 Undercloud 前被预先定义。
|
所有节点
|
Provisioning
|
director 使用这个网络类型来通过 PXE 引导实施新的节点,并调配在 Overcloud 裸机服务器上进行的 OpenStack 安装。这个网络在安装 Undercloud 前被预先定义。
|
所有节点
|
Internal API
|
Internal API 网络被用来处理经过 API 、RPC 消息和数据库进行的 OpenStack 服务间的通讯。
|
Controller、Compute、Cinder Storage、Swift Storage
|
Tenant
|
Neutron 为每个租户提供自己的网络。这可以通过使用 VLAN 隔离(VLAN segregation,每个租户网络都是一个网络 VLAN)实现,也可以使用 VXLAN 或 GRE 通道(tunneling)实现。每个租户网络的网络数据会被相互隔离,并都有一个相关联的 IP 子网。通过网络命名空间,多个租户子网可以使用相同的地址。
|
Controller、Compute
|
Storage
|
块存储、NFS、iSCSI 和其它存储。在理想情况下,因为性能的原因,这个网络应该位于一个完全独立的网络交换环境中。
|
所有节点
|
Storage Management
|
OpenStack Object Storage(swift)使用这个网络来在相关的副本节点中同步数据项。代理服务(proxy service)在用户请求和底层的存储层间起到一个主机接口的作用。这个代理会接收用户的请求,并找到所需的副本来获得所需的数据。使用 Ceph 作为后端的服务会通过 Storage Management 网络进行连接,因为它们不会和 Ceph 直接进行交流,而是使用前端的服务。请注意,RBD 驱动是个例外,它会直接连接到 Ceph。
|
Controller、Ceph Storage、Cinder Storage、Swift Storage
|
External
|
运行 OpenStack Dashboard(horizon)来进行图形化的系统管理、OpenStack 服务的公共 API 以及对入站网络流量进行 SNAT 处理来把它们导向正确的目标。如果 external 网络使用私有 IP 地址(RFC-1918),还需要对来自于互联网的流量进行额外的 NAT 处理。
|
Controller
|
Floating IP
|
允许入站的网络流量到达相关实例,它使用 1 对 1 的 IP 地址映射把浮动 IP 地址和在租户网络中实际分配给实例的 IP 地址相关联。如果提供在一个与
External 分离的 VLAN 中的浮动 IP,您可以把 Floating IP VLAN trunk 到 Controller 节点,并在 Overcloud 创建后通过 Neutron 添加 VLAN。这意味着,创建多个 Floating IP 网络附加到多个网桥。VLAN 会被 trunk,但不会被配置为接口。neutron 会为每个 Floating IP 网络在所选的网桥上创建一个带有 VLAN 分段 ID 的 OVS 端口。
|
Controller
|
注意
- Internal API
- Storage
- Storage Management
- Tenant
- External
nic2
和 nic3
)的绑定来通过相关的 VLAN 提供网络功能。同时,所有 Overcloud 节点都使用 nic1
通过原生的 VLAN 来通过 Provisioning 网络和 Undercloud 进行通讯。
图 3.1. 使用绑定接口的 VLAN 拓扑结构示例
表 3.3. 网络映射
|
映射
|
接口总数
|
VLAN 总数
|
---|---|---|---|
带有外部连接的平面网络
|
网络 1 - Provisioning、Internal API、Storage、Storage Management、Tenant Networks
网络 2 - External、Floating IP(在 Overcloud 创建后进行映射)
|
2
|
2
|
隔离的网络
|
网络 1 - Provisioning
网络 2 - Internal API
网络 3 - Tenant Network
网络 4 - Storage
网络 5 - Storage Management
Network 6 - External 和 Floating IP(在创建 Overcloud 后被映射)
|
3(包括 2 个绑定接口)
|
6
|
3.3. 规划存储
- Ceph Storage 节点
- director 使用 Red Hat Ceph Storage 创建一组可扩展的存储节点。Overcloud 使用这些节点用于:
- 镜像 - Glance 管理虚拟机的镜像。镜像是不可变的,OpenStack 把镜像看做为二进制数据块,并根据它们的实际情况进行下载。您可以使用 glance 在一个 Ceph 块设备中存储镜像。
- 卷 - Cinder 卷是块设备。OpenStack 使用卷来引导虚拟机,或把卷附加到运行的虚拟机上。OpenStack 使用 Cinder 服务管理卷,您可以使用 Cinder,通过一个镜像的写时复制(copy-on-write,简称 COW) 克隆引导虚拟机。
- 客户端磁盘 - 客户端磁盘就是客户端(虚拟机)操作系统磁盘。在默认情况下,当使用 nova 引导虚拟机时,它的磁盘会以一个文件的形式出现在虚拟机监控程序(hypervisor)上,通常位于
/var/lib/nova/instances/<uuid>/
。现在,可以直接在 Ceph 中直接引导每个虚拟机,这可以使您在实时迁移时更容易地执行维护操作。例如,如果您的 hypervisor 出现问题,它还可以方便地触发nova evacuate
,从而使在其它地方运行虚拟机的过程几乎可以“无缝”地实现。
重要
Ceph 不支持提供 QCOW2 虚拟机磁盘。如果您需要在 Ceph 中引导虚拟机(临时后端或从卷引导),glance 镜像的格式必须是RAW
。如需了解更多信息,请参阅 Red Hat Ceph Storage Architecture Guide。 - Swift 存储节点
- director 会创建一个外部的对象存储节点。当您需要扩展或替换 Overcloud 环境中的 controller 节点,同时需要在一个高可用性集群外保留块存储时,这将非常有用。
第 4 章 安装 Undercloud
4.1. 创建 director 安装用户
stack
的用户并设置密码:
[root@director ~]# useradd stack [root@director ~]# passwd stack # specify a password
sudo
时不需要密码:
[root@director ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack [root@director ~]# chmod 0440 /etc/sudoers.d/stack
stack
用户:
[root@director ~]# su - stack [stack@director ~]$
stack
用户继续安装的过程。
4.2. 为模板和镜像创建目录
$ mkdir ~/images $ mkdir ~/templates
4.3. 为系统设置主机名
$ hostname # Checks the base hostname $ hostname -f # Checks the long hostname (FQDN)
hostnamectl
设置主机名:
$ sudo hostnamectl set-hostname manager.example.com $ sudo hostnamectl set-hostname --transient manager.example.com
/etc/hosts
文件中包括一个带有系统主机名和基本名的项。例如,您系统的名称是 manager.example.com
,/etc/hosts
则需要包括一个和以下类似的项:
127.0.0.1 manager.example.com manager localhost localhost.localdomain localhost4 localhost4.localdomain4
4.4. 注册系统
过程 4.1. 使用 Subscription Manager 订阅所需的频道
- 在 Content Delivery Network 中注册您的系统,在提示时输入您的客户门户网站(Customer Portal)的用户名和密码:
$ sudo subscription-manager register
- 找到 Red Hat OpenStack Platform director 所在的权利池。
$ sudo subscription-manager list --available --all
- 使用上个命令中获得的池 ID 添加 Red Hat OpenStack Platform 8 权利:
$ sudo subscription-manager attach --pool=pool_id
- 禁用所有默认的仓库,然后启用 Red Hat Enterprise Linux 仓库:
$ sudo subscription-manager repos --disable=* $ sudo subscription-manager repos --enable=rhel-7-server-rpms --enable=rhel-7-server-extras-rpms --enable=rhel-7-server-openstack-8-rpms --enable=rhel-7-server-openstack-8-director-rpms --enable rhel-7-server-rh-common-rpms
这些仓库包括了安装 director 所需的软件包。 - 对您系统上的软件进行一个更新来确保使用了最新的基本系统软件包:
$ sudo yum update -y $ sudo reboot
4.5. 安装 director 软件包
[stack@director ~]$ sudo yum install -y python-tripleoclient
4.6. 配置 director
stack
用户的家目录中的一个模板中(undercloud.conf
)。
stack
用户的家目录中:
$ cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf
- local_ip
- director 的 Provisioning NIC 的 IP 地址。它同时还是 director 用来作为它的 DHCP 和 PXE 引导服务的 IP 地址。除非您需要为 Provisioning 网络使用不同的子网(比如,因为默认值和存在的 IP 地址或环境中的其它子网冲突),请保留使用默认值
192.0.2.1/24
。 - network_gateway
- Overcloud 实例的网关。它是 Undercloud 主机,会把网络流量转发到 External 网络。除非您的 director 使用不同的 IP 地址,或直接使用一个外部网关,请保留使用默认的值(
192.0.2.1
)。注意
director 的配置脚本也可以使用相关的sysctl
内核参数自动启用 IP 转发功能。 - undercloud_public_vip
- director 的 Public API 的 IP 地址。使用 Provisioning 网络中的一个与其它任何 IP 地址或地址范围都不冲突的 IP 地址。例如,
192.0.2.2
。director 的配置会把这个 IP 地址附加到它的软件网桥上作为一个路由的 IP 地址(使用/32
网络掩码)。 - undercloud_admin_vip
- director 的 Admin API 的 IP 地址。使用 Provisioning 网络中的一个与其它任何 IP 地址或地址范围都不冲突的 IP 地址。例如,
192.0.2.3
。director 的配置会把这个 IP 地址附加到它的软件网桥上作为一个路由的 IP 地址(使用/32
网络掩码)。 - undercloud_service_certificate
- 用于 OpenStack SSL 通讯的证书的位置和文件名。最理想的情况是从一个信任的证书颁发机构获得这个证书。或者,您也可以根据 附录 A, SSL/TLS 证书配置 生成一个自签发的证书。另外,它还包括了为您的证书(无论是自签发证书还是从证书颁发机构获得的证书)设置上下文的方法。
- local_interface
- 指定 director 的 Provisioning NIC 的接口。它同时还是 director 用来作为它的 DHCP 和 PXE 引导服务的设备。把这个项的值改为您需要使用的值。使用
ip addr
命令可以查看连接了哪些设备。以下是一个ip addr
命令的结果输出示例:2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:75:24:09 brd ff:ff:ff:ff:ff:ff inet 192.168.122.178/24 brd 192.168.122.255 scope global dynamic eth0 valid_lft 3462sec preferred_lft 3462sec inet6 fe80::5054:ff:fe75:2409/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noop state DOWN link/ether 42:0b:c2:a5:c1:26 brd ff:ff:ff:ff:ff:ff
在这个例子中,External NIC 使用eth0
,Provisioning NIC 使用eth1
(当前没有被配置)。在这种情况下,把local_interface
设置为eth1
。配置脚本会把这个接口附加到一个自定义的网桥(由inspection_interface
参数定义)上。 - network_cidr
- director 用来管理 Overcloud 实例的网络,它是 Provisioning 网络。除非您的 Provisioning 网络使用了不同的子网,保留使用默认值(
192.0.2.0/24
)。 - masquerade_network
- 定义用于外部访问的网络伪装。这为 Provisioning 网络提供了一定程度的网络地址转换(network address translation,简称 NAT)功能,从而可以通过 director 实现外部访问。除非 Provisioning 网络使用了不同的子网,请保留使用默认的值(
192.0.2.0/24
)。 - dhcp_start, dhcp_end
- Overcloud 节点的 DHCP 分配范围的开始值和终止值。请确保这个范围可以为您的节点提供足够的 IP 地址。
- inspection_interface
- director 用来进行节点内省的网桥。这是 director 配置创建的一个自定义网桥。
LOCAL_INTERFACE
会附加到这个网桥。请保留使用默认的值(br-ctlplane
)。 - inspection_iprange
- 在 PXE 引导和部署过程中,director 内省服务使用的 IP 地址范围。使用逗号分隔范围的起始值和终止值。例如,
192.0.2.100,192.0.2.120
。请确保这个范围有足够的 IP 地址,并和dhcp_start
与dhcp_end
指定的范围不冲突。 - inspection_extras
- 指定在内省的过程中是否启用额外的硬件集合。在内省镜像中需要
python-hardware
或python-hardware-detect
软件包。 - inspection_runbench
- 在节点发现过程中运行一组基准数据。把它设置为
true
来启用这个功能。如果您需要在检查注册节点的硬件时执行基准数据分析操作,则需要使用这个参数。更详细的相关信息,请参阅 附录 C, 自动配置集标记。 - undercloud_debug
- 把 Undercloud 服务的日志级别设置为
DEBUG
。把它设为true
来启用它。 - enable_tempest
- 定义是否安装检查工具。默认设置是
false
,您可以把它设为true
。 - ipxe_deploy
- 定义使用 iPXE 还是标准的 PXE。默认值是
true
,这会使用 iPXE;设置为false
将使用标准的 PXE。如需了解更多相关信息,请参阅用户门户网站中的 "Changing from iPXE to PXE in Red Hat OpenStack Platform director"。 - store_events
- 定义是否在 Undercloud 的 Ceilometer 中保存事件信息。
- undercloud_db_password, undercloud_admin_token, undercloud_admin_password, undercloud_glance_password, 等等
- 剩下的参数用来定义 director 服务的访问信息。这些值不需要改变。如果
undercloud.conf
为空,director 的配置脚本会自动产生这些值。当配置脚本完成后,您可以获得所有这些值。
$ openstack undercloud install
undercloud.conf
中的设置相符合的情况。这个脚本会需要一些时间来完成。
undercloud-passwords.conf
- director 服务的所有密码列表。stackrc
- 用来访问 director 命令行工具的一组初始变量。
stack
用户来使用命令行工具:
$ source ~/stackrc
4.7. 为 Overcloud 节点获得镜像
- 一个内省内核和 ramdisk - 用于通过 PXE 引导进行裸机系统内省。
- 一个实施内核和 ramdisk - 用于系统部署和实施。
- 一个 Overcloud 内核、ramdisk 和完整镜像 - 写到节点硬盘中的一个基本的 Overcloud 系统。
rhosp-director-images
和 rhosp-director-images-ipa
软件包中获得这些镜像:
$ sudo yum install rhosp-director-images rhosp-director-images-ipa
stack
用户的家目录(/home/stack/images
)的 images
目录中:
$ cp /usr/share/rhosp-director-images/overcloud-full-latest-8.0.tar ~/images/. $ cp /usr/share/rhosp-director-images/ironic-python-agent-latest-8.0.tar ~/images/.
$ cd ~/images $ for tarfile in *.tar; do tar -xf $tarfile; done
$ openstack overcloud image upload --image-path /home/stack/images/
bm-deploy-kernel
、bm-deploy-ramdisk
、overcloud-full
、overcloud-full-initrd
和 overcloud-full-vmlinuz
镜像上传到 director。这些是部署以及 Overcloud 所需的镜像。这个脚本也会在 director 的 PXE 服务器上安装内省镜像。
$ openstack image list +--------------------------------------+------------------------+ | ID | Name | +--------------------------------------+------------------------+ | 765a46af-4417-4592-91e5-a300ead3faf6 | bm-deploy-ramdisk | | 09b40e3d-0382-4925-a356-3a4b4f36b514 | bm-deploy-kernel | | ef793cd0-e65c-456a-a675-63cd57610bd5 | overcloud-full | | 9a51a6cb-4670-40de-b64b-b70f4dd44152 | overcloud-full-initrd | | 4f7e33f4-d617-47c1-b36f-cbe90f132e5d | overcloud-full-vmlinuz | +--------------------------------------+------------------------+
discovery-ramdisk.*
)。director 会把这些文件复制到 /httpboot
。
[stack@host1 ~]$ ls -l /httpboot total 341460 -rwxr-xr-x. 1 root root 5153184 Mar 31 06:58 agent.kernel -rw-r--r--. 1 root root 344491465 Mar 31 06:59 agent.ramdisk -rw-r--r--. 1 root root 337 Mar 31 06:23 inspector.ipxe
4.8. 在 Undercloud 的 Neutron 子网中设置一个名称解析服务器
neutron
子网中定义。使用以下命令设置名称解析服务器:
$ neutron subnet-list $ neutron subnet-update [subnet-uuid] --dns-nameserver [nameserver-ip]
$ neutron subnet-show [subnet-uuid] +-------------------+-----------------------------------------------+ | Field | Value | +-------------------+-----------------------------------------------+ | ... | | | dns_nameservers | 8.8.8.8 | | ... | | +-------------------+-----------------------------------------------+
重要
DnsServer
参数。这包括在 第 6.2.2 节 “创建一个网络环境文件” 中的高级配置情景中。
4.9. 完成 Undercloud 的配置
第 5 章 配置基本 Overcloud 的要求
流程
- 在 director 中创建一个节点定义模板并注册空白节点。
- 检查所有节点的硬件。
- 为节点添加标签(tag)来标记为角色。
- 定义额外的节点属性
要求
- 第 4 章 安装 Undercloud 中创建的 director 节点
- 一组作为节点的裸机。所需的节点数量由您需要创建的 Overcloud 类型所决定(请参阅 第 3.1 节 “规划节点的实施角色”)。这些机器需要满足每个节点类型对系统的要求。相关信息,请参阅 第 2.4 节 “Overcloud 的配置要求”。这些节点不需要操作系统,director 会把一个 Red Hat Enterprise Linux 7 镜像复制到每个节点。
- Provisioning 网络的一个网络连接(被配置为一个原生 VLAM)。所有节点必须都连接到这个网络,并需要满足 第 2.3 节 “网络要求” 中的要求。在本章的示例中,我们使用 192.0.2.0/24 作为 Provisioning 子网,分配的 IP 地址信息如下:
表 5.1. Provisioning 网络 IP 分配信息
节点名IP 地址MAC 地址IPMI IP 地址Director192.0.2.1aa:aa:aa:aa:aa:aaControllerDHCPbb:bb:bb:bb:bb:bb192.0.2.205ComputeDHCPcc:cc:cc:cc:cc:cc192.0.2.206 - 所有其它网络类型使用 Provisioning 网络作为 OpenStack 服务。但是,您也可以为其它网络通讯类型创建额外的网络。相关信息,请参阅 第 6.2 节 “分离网络”。
5.1. 为 Overcloud 注册节点
instackenv.json
)是一个 JSON 格式的文件,它包括了环境中的节点的硬件信息和电源管理信息。例如,注册两个节点的模板会和以下类似:
{ "nodes":[ { "mac":[ "bb:bb:bb:bb:bb:bb" ], "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":[ "cc:cc:cc:cc:cc:cc" ], "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
- 节点上的网络接口的 MAC 地址列表。对于每个系统的 Provisioning NIC,只使用 MAC 地址。
- pm_type
- 使用的电源管理驱动。在这个示例中使用 IPMI 驱动(
pxe_ipmitool
)。 - pm_user, pm_password
- IPMI 的用户名和密码。
- pm_addr
- IPMI 设备的 IP 地址。
- cpu
- 节点上的 CPU 数量。(可选)
- memory
- 以 MB 为单位的内存大小。(可选)
- disk
- 以 GB 为单位的硬盘的大小。(可选)
- arch
- 系统架构。(可选)
注意
stack
用户的家目录(/home/stack/instackenv.json
),然后把它导入到 director。使用以下命令:
$ openstack baremetal import --json ~/instackenv.json
$ openstack baremetal configure boot
$ ironic node-list
5.2. 检查节点硬件
$ openstack baremetal introspection bulk start
$ sudo journalctl -l -u openstack-ironic-inspector -u openstack-ironic-inspector-dnsmasq -u openstack-ironic-conductor -f
重要
$ ironic node-set-maintenance [NODE UUID] true $ openstack baremetal introspection start [NODE UUID] $ ironic node-set-maintenance [NODE UUID] false
5.3. 为节点添加标签(tag)来标记为配置集
compute
、control
、swift-storage
、ceph-storage
和 block-storage
,在多数环境中,都可以在不经过修改的情况下使用它们。
注意
profile
选项添加到每个节点的 properties/capabilities
参数中。例如,把环境中的两个节点分别标记为使用 controller 配置集和 compute 配置集,使用以下命令:
$ ironic node-update 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13 add properties/capabilities='profile:compute,boot_option:local' $ ironic node-update 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 add properties/capabilities='profile:control,boot_option:local'
profile:compute
和 profile:control
选项会把节点标记为相关的配置集。
boot_option:local
参数,它定义了每个节点的引导模式。
$ openstack overcloud profiles list
5.4. 为节点定义 Root Disk
model
(字符串):设备 ID。vendor
(字符串):设备厂商。serial
(字符串):磁盘序列号。wwn
(字符串):唯一的存储 ID。hctl
(字符串):SCSI 的 Host:Channel:Target:Lun。size
(整数):设备的大小(以 GB 为单位)。
ironic node-show
命令,从 extra
项中找到块设备。例如,使用以下命令列出所有节点以及它们的块设备:
$ for uuid in `ironic node-list | awk '{print $2}'`; do echo "Node ID: $uuid"; ironic node-show $uuid | grep 'properties\|extra ' -A3; done
... Node ID: 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 | extra | {u'newly_discovered': u'true', u'block_devices': | | | {u'serials': [u'100000000', u'100000001', | | | u'100000002', u'100000003', u'100000004', | | | u'100000005', u'100000006', u'100000007', | -- | properties | {u'cpu_arch': u'x86_64', u'root_device': {u'serial': | | | u'100000005'}, u'cpus': u'16', u'capabilities': | | | u'profile:control,boot_option:local', | | | u'memory_mb': u'65536', u'local_gb': u'3725'} | ...
block_devices
参数标识的块设备,以及每个设备的序列号。root_device
当前的序列号被设置为 100000005。在这个示例中,把序列号为 100000000 的磁盘设置为 root 设备。这需要对 root_device
磁盘进行修改:
$ ironic node-update 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 add properties/root_device='{"serial": "100000000"}'
5.5. 完成基本配置
- 使用高级配置步骤对环境进行定制。如需了解更多相关信息,请参阅 第 6 章 为 Overcloud 配置高级的定制环境。
- 或部署一个基本的 Overcloud。如需了解更多相关信息,请参阅 第 7 章 创建 Overcloud。
重要
第 6 章 为 Overcloud 配置高级的定制环境
6.1. 了解 Heat 模板
6.1.1. Heat 模板
- 参数 - 一组传递给 heat 的参数,可以被用来自定义一个栈,并设置在没有传递值时相关参数所使用的默认值。这些参数在模板的
parameters
项中定义。 - 资源 - 一组作为栈的一部分需要创建和配置的对象。OpenStack 包括一组分布在所有组件中的资源,它们在模板的
resources
项中定义。 - 输出 - 一组在栈创建后传递给 heat 的值。您可以通过 heat API 或客户端工具程序来访问这些值。它们在模板的
output
项中定义。
heat_template_version: 2013-05-23 description: > A very basic Heat template. parameters: key_name: type: string default: lars description: Name of an existing key pair to use for the instance flavor: type: string description: Instance type for the instance to be created default: m1.small image: type: string default: cirros description: ID or name of the image to use for the instance resources: my_instance: type: OS::Nova::Server properties: name: My Cirros Instance image: { get_param: image } flavor: { get_param: flavor } key_name: { get_param: key_name } output: instance_name: description: Get the instance's name value: { get_attr: [ my_instance, name ] }
type: OS::Nova::Server
创建一个名为 my_instance
的实例,它具有特定的 flavor、镜像和关键字。这个栈会返回 instance_name
的值(My Cirros Instance
)。
$ heat stack-list --show-nested
6.1.2. 环境文件
- 资源注册表 - 它设置了自定义资源名,并连接到其它 heat 模板。这提供了一个创建没有存在于核心资源集合中的自定义资源的方法。它在环境文件的
resource_registry
项中设置。 - Parameters - 应用到高级别模板参数中的常规设置。例如,您有一个模板用来部署嵌套的栈,如资源注册表映射,这些参数只需要应用于高级别的模板,而不需要在嵌套的栈中进行应用。参数在环境文件中的
parameters
部分进行定义。 - Parameter Defaults - 这些参数会修改所有模板中的参数默认值。例如,您有一个模板用来部署嵌套的栈,如资源注册表映射,参数的默认值会应用到所有模板中。包括高级别的模板以及所有嵌套的资源。参数的默认值在环境文件的
parameter_defaults
项中定义。
重要
parameter_defaults
而不是 parameters
,这样可以使参数应用到 Overcloud 中的所有模板中。
resource_registry: OS::Nova::Server::MyServer: myserver.yaml parameter_defaults: NetworkName: my_network parameters: MyIP: 192.168.0.1
my_template.yaml
)创建一个栈时,可以包括这个环境文件(my_env.yaml
)。my_env.yaml
文件会创建一个名为 OS::Nova::Server::MyServer
的新资源类型。myserver.yaml
文件是一个 Heat 模板文件,它为这个资源类型提供了一个实施来覆盖内建的设置。您可以在 my_template.yaml
文件中包括 OS::Nova::Server::MyServer
资源。
MyIP
会只对和这个环境文件一起部署的主 Heat 模板应用一个参数。在这个示例中,它只应用于 my_template.yaml
中的参数。
NetworkName
会对主 Heat 模板(在这个示例中是 my_template.yaml
),以及与包括在主模板中的资源相关联的模板进行应用(在这个示例中,资源是 OS::Nova::Server::MyServer
,模板是 myserver.yaml
)。
6.1.3. 核心 Overcloud Heat 模板
/usr/share/openstack-tripleo-heat-templates
中。
overcloud.yaml
- 这是创建 Overcloud 环境所使用的主要模板。overcloud-resource-registry-puppet.yaml
- 这是创建 Overcloud 环境所使用的主要环境文件。它为 Puppet 模块提供了一组存储在 Overcloud 镜像中的配置。当 director 为每个节点写入 Overcloud 镜像后,Heat 将使用在环境文件中注册的资源来为每个节点进行配置。environments
- 一个包括了可以应用到 Overcloud 部署中的环境文件示例的目录。
6.2. 分离网络
- Network 1 - Provisioning
- Network 2 - Internal API
- Network 3 - Tenant Network
- Network 4 - Storage
- Network 5 - Storage Management
- Network 6 - External and Floating IP(在创建 Overcloud 后被映射)
表 6.1. 网络子网和 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
|
Management
|
172.20.0.0/24
|
205
|
External / Floating IP
|
10.1.1.0/24
|
100
|
6.2.1. 创建自定义接口模板
/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 配置的模板。/usr/share/openstack-tripleo-heat-templates/network/config/multiple-nics
- 这个目录包括了多 NIC 配置的模板,其中的每个角色都使用一个 NIC。/usr/share/openstack-tripleo-heat-templates/network/config/single-nic-linux-bridge-vlans
- 这个目录中包括了基于角色的、带有 VLAN 配置的单独 NIC 的模板,其中的 VLAN 使用 Linux 网桥而不是使用 Open vSwitch 网桥。
/usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans
。
$ cp -r /usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans ~/templates/nic-configs
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}
- linux_bridge
- 定义一个 Linux 网桥。Linux 网桥与 Open vSwitch 相似,把多个
interface
、bond
和vlan
对象连接在一起。- type: linux_bridge name: bridge1 addresses: - ip_netmask: list_join: - '/' - - {get_param: ControlPlaneIp} - {get_param: ControlPlaneSubnetCidr} members: - type: interface name: nic1 primary: true - type: vlan vlan_id: {get_param: ExternalNetworkVlanID} device: bridge1 addresses: - ip_netmask: {get_param: ExternalIpSubnet} routes: - ip_netmask: 0.0.0.0/0 default: true next_hop: {get_param: ExternalInterfaceDefaultRoute}
- linux_bond
- 定义一个 Linux 绑定。它和 Open vSwitch 绑定相似,把两个
interfaces
组合在一起来起到冗余和增加带宽的目的。- type: linux_bond name: bond1 members: - type: interface name: nic2 - type: interface name: nic3 bonding_options: "bond_mode=balance-tcp lacp=active other-config:lacp-fallback-ab=true"
/home/stack/templates/nic-configs/controller.yaml
模板使用以下 network_config
设置:
resources: OsNetConfigImpl: type: OS::Heat::StructuredConfig properties: group: os-apply-config config: os_net_config: network_config: - type: interface name: nic1 use_dhcp: false addresses: - ip_netmask: list_join: - '/' - - {get_param: ControlPlaneIp} - {get_param: ControlPlaneSubnetCidr} routes: - ip_netmask: 169.254.169.254/32 next_hop: {get_param: EC2MetadataIp} - type: ovs_bridge name: {get_input: bridge_name} dns_servers: {get_param: DnsServers} 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: - default: true 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} - type: vlan device: bond1 vlan_id: {get_param: ManagementNetworkVlanID} addresses: - ip_netmask: {get_param: ManagementIpSubnet}
注意
br-ex
的外部网桥),并创建了一个由两个编号的接口(nic2
和 nic3
)组成的一个名为 bond1
的绑定接口。这个网络还包括了一组加标签的 VLAN(tagged VLAN)设备,并使用 bond1
作为父设备。这个模板还包括了一个接口,它被用来连接回 director(nic1
)。
get_param
功能。您可以在一个针对于您的网络所创建的一个环境文件中定义它们。
重要
nic4
),它不使用任何为 OpenStack 服务分配的 IP, 但使用 DHCP 或默认的路由。为了避免网络冲突,从 ovs_bridge
设备中删除所有使用的接口,并禁用 DHCP 和默认路由设置:
- type: interface name: nic4 use_dhcp: false defroute: false
6.2.2. 创建一个网络环境文件
/usr/share/openstack-tripleo-heat-templates/network/config/
中的示例网络接口文件:
/usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml
- 在single-nic-vlans
网络接口目录中的、带有 VLAN 配置的单一 NIC 的环境文件。同时,还包括了用来禁用 External 网络的环境文件(net-single-nic-with-vlans-no-external.yaml
)和用来启用 IPv6 的环境文件(net-single-nic-with-vlans-v6.yaml
)。/usr/share/openstack-tripleo-heat-templates/environments/net-bond-with-vlans.yaml
- 在bond-with-vlans
网络接口目录中的、绑定的 NIC 配置的环境文件。同时,还包括了用来禁用 External 网络的环境文件(net-bond-with-vlans-no-external.yaml
)和用来启用 IPv6 的环境文件(net-bond-with-vlans-v6.yaml
)。/usr/share/openstack-tripleo-heat-templates/environments/net-multiple-nics.yaml
- 在multiple-nics
网络接口目录中的、多 NIC 配置的环境文件。同时,还包括用来启用 IPv6 的环境文件(net-multiple-nics-v6.yaml
)。/usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-linux-bridge-with-vlans.yaml
- 带有使用 Linux 网桥而不是 Open vSwitch 网桥的单一 NIC 配置的环境变量,这个 NIC 配置所在的目录是single-nic-linux-bridge-vlans
。
/usr/share/openstack-tripleo-heat-templates/environments/net-bond-with-vlans.yaml
文件版本。把这个文件复制到 stack 用户的 templates
目录中。
$ cp /usr/share/openstack-tripleo-heat-templates/environments/net-bond-with-vlans.yaml /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 StorageMgmtNetCidr: 172.19.0.0/24 ManagementNetCidr: 172.20.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'}] ManagementAllocationPools: [{'start': '172.20.0.10', 'end': '172.20.0.200'}] # Leave room for floating IPs in the External allocation pool ExternalAllocationPools: [{'start': '10.1.1.10', 'end': '10.1.1.50'}] # Set to the router gateway on the external network ExternalInterfaceDefaultRoute: 10.1.1.1 # Gateway router for the provisioning network (or Undercloud IP) ControlPlaneDefaultRoute: 192.0.2.254 # The IP address of the EC2 metadata server. Generally the IP of the Undercloud EC2MetadataIp: 192.0.2.1 # Define the DNS servers (maximum 2) for the overcloud nodes DnsServers: ["8.8.8.8","8.8.4.4"] InternalApiNetworkVlanID: 201 StorageNetworkVlanID: 202 StorageMgmtNetworkVlanID: 203 TenantNetworkVlanID: 204 ManagementNetworkVlanID: 205 ExternalNetworkVlanID: 100 # Set to "br-ex" if using floating IPs on native VLAN on bridge br-ex NeutronExternalNetworkBridge: "''" # Customize bonding options if required BondInterfaceOvsOptions: "bond_mode=balance-tcp"
resource_registry
的部分包括了到每个角色的自定义网络接口模板的链接。相关信息,请参阅 第 6.2.1 节 “创建自定义接口模板”。
parameter_defaults
项包括了一组参数,它们被用来定义每个网络类型的网络选项。如需获得这些参数的详细信息,请参阅 附录 F, 网络环境选项。
重要
6.2.3. 把 OpenStack 服务分配到分离的网络
/home/stack/templates/network-environment.yaml
)中定义一个新的网络映射来把 OpenStack 服务重新分配给不同的网络类型。ServiceNetMap
参数决定了每个服务所使用的网络类型。
parameter_defaults: ... 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 # Define which network will be used for hostname resolution ControllerHostnameResolveNetwork: internal_api ComputeHostnameResolveNetwork: internal_api BlockStorageHostnameResolveNetwork: internal_api ObjectStorageHostnameResolveNetwork: internal_api CephStorageHostnameResolveNetwork: storage ...
storage
会把这些服务放置到 Storage 网络而不是 Storage Management 网络。这意味着,您只需要为 Storage 网络定义一组 parameter_defaults
,而不是 Storage Management 网络。
6.2.4. 选择要部署的网络
resource_registry
项中的设置不需要修改。如果只需要其中列出的一部分网络,可以对网络列表进行修改。
注意
environments/network-isolation.yaml
,而是在网络环境文件中指定所有的网络和端口。
resource_registry: # This section is usually not modified, if in doubt stick to the defaults # TripleO overcloud networks OS::TripleO::Network::External: /usr/share/openstack-tripleo-heat-templates/network/external.yaml OS::TripleO::Network::InternalApi: /usr/share/openstack-tripleo-heat-templates/network/internal_api.yaml OS::TripleO::Network::StorageMgmt: /usr/share/openstack-tripleo-heat-templates/network/storage_mgmt.yaml OS::TripleO::Network::Storage: /usr/share/openstack-tripleo-heat-templates/network/storage.yaml OS::TripleO::Network::Tenant: /usr/share/openstack-tripleo-heat-templates/network/tenant.yaml # Port assignments for the VIPs OS::TripleO::Network::Ports::ExternalVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml OS::TripleO::Network::Ports::InternalApiVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml OS::TripleO::Network::Ports::StorageVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml OS::TripleO::Network::Ports::StorageMgmtVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt.yaml OS::TripleO::Network::Ports::TenantVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml OS::TripleO::Network::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/vip.yaml # Port assignments for the controller role OS::TripleO::Controller::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml OS::TripleO::Controller::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml OS::TripleO::Controller::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml OS::TripleO::Controller::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt.yaml OS::TripleO::Controller::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml # Port assignments for the compute role OS::TripleO::Compute::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml OS::TripleO::Compute::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml OS::TripleO::Compute::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml # Port assignments for the ceph storage role OS::TripleO::CephStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml OS::TripleO::CephStorage::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt.yaml # Port assignments for the swift storage role OS::TripleO::SwiftStorage::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml OS::TripleO::SwiftStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml OS::TripleO::SwiftStorage::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt.yaml # Port assignments for the block storage role OS::TripleO::BlockStorage::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml OS::TripleO::BlockStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml OS::TripleO::BlockStorage::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt.yaml
OS::TripleO::Network::*
资源的资源注册信息。在默认情况下,这些资源指向一个 noop.yaml
文件,它不会创建任何网络。通过把这些资源指向相关的 YAML 文件,就可以启用对这些网络的创建。
storage_mgmt.yaml
的指代都需要替换为指代到 noop.yaml
:
resource_registry: # This section is usually not modified, if in doubt stick to the defaults # TripleO overcloud networks OS::TripleO::Network::External: /usr/share/openstack-tripleo-heat-templates/network/external.yaml OS::TripleO::Network::InternalApi: /usr/share/openstack-tripleo-heat-templates/network/internal_api.yaml OS::TripleO::Network::StorageMgmt: /usr/share/openstack-tripleo-heat-templates/network/noop.yaml OS::TripleO::Network::Storage: /usr/share/openstack-tripleo-heat-templates/network/storage.yaml OS::TripleO::Network::Tenant: /usr/share/openstack-tripleo-heat-templates/network/tenant.yaml # Port assignments for the VIPs OS::TripleO::Network::Ports::ExternalVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml OS::TripleO::Network::Ports::InternalApiVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml OS::TripleO::Network::Ports::StorageVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml OS::TripleO::Network::Ports::StorageMgmtVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml OS::TripleO::Network::Ports::TenantVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml OS::TripleO::Network::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/vip.yaml # Port assignments for the controller role OS::TripleO::Controller::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml OS::TripleO::Controller::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml OS::TripleO::Controller::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml OS::TripleO::Controller::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml OS::TripleO::Controller::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml # Port assignments for the compute role OS::TripleO::Compute::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml OS::TripleO::Compute::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml OS::TripleO::Compute::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml # Port assignments for the ceph storage role OS::TripleO::CephStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml OS::TripleO::CephStorage::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml # Port assignments for the swift storage role OS::TripleO::SwiftStorage::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml OS::TripleO::SwiftStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml OS::TripleO::SwiftStorage::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml # Port assignments for the block storage role OS::TripleO::BlockStorage::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml OS::TripleO::BlockStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml OS::TripleO::BlockStorage::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml parameter_defaults: ServiceNetMap: NeutronTenantNetwork: tenant CeilometerApiNetwork: internal_api MongoDbNetwork: internal_api CinderApiNetwork: internal_api CinderIscsiNetwork: storage GlanceApiNetwork: storage GlanceRegistryNetwork: internal_api KeystoneAdminApiNetwork: ctlplane # Admin connection for Undercloud KeystonePublicApiNetwork: internal_api NeutronApiNetwork: internal_api HeatApiNetwork: internal_api NovaApiNetwork: internal_api NovaMetadataNetwork: internal_api NovaVncProxyNetwork: internal_api SwiftMgmtNetwork: storage # Changed from storage_mgmt SwiftProxyNetwork: storage HorizonNetwork: internal_api MemcachedNetwork: internal_api RabbitMqNetwork: internal_api RedisNetwork: internal_api MysqlNetwork: internal_api CephClusterNetwork: storage # Changed from storage_mgmt CephPublicNetwork: storage ControllerHostnameResolveNetwork: internal_api ComputeHostnameResolveNetwork: internal_api BlockStorageHostnameResolveNetwork: internal_api ObjectStorageHostnameResolveNetwork: internal_api CephStorageHostnameResolveNetwork: storage
noop.yaml
将不会创建任何网络或端口,因此,Storage Management 网络上的服务会被默认位于 Provisioning 网络中。通过 ServiceNetMap
,可以把 Storage Management 服务移到另外一个网络中(如 Storage network)。
6.3. 控制节点的位置
- 分配特定节点 ID,如
controller-0
、controller-1
等 - 设置自定义的主机名
- 设置特定的 IP 地址
6.3.1. 分配特定的节点 ID
controller-0
、controller-1
、novacompute-0
、novacompute-1
等等。
ironic node-update <id> replace properties/capabilities='node:controller-0,boot_option:local'
node:controller-0
分配给节点。使用连续的索引值来为所有节点进行分配(以 0 开始)。确定对于一个特定角色(Controller、Compute 以及每个存储角色)的所有节点都以同样形式进行标记(tag),否则 Nova 调度程序将无法正确匹配能力。
scheduler_hints_env.yaml
),它使用调度程序的 hint 来为每个节点匹配能力。例如:
parameter_defaults: ControllerSchedulerHints: 'capabilities:node': 'controller-%index%'
overcloud deploy command
中包括 scheduler_hints_env.yaml
环境文件。
ControllerSchedulerHints
用于 Controller 节点。NovaComputeSchedulerHints
用于 Compute 节点。BlockStorageSchedulerHints
用于 Block Storage 节点。ObjectStorageSchedulerHints
用于 Object Storage 节点。CephStorageSchedulerHints
用于 Ceph Storage 节点。
注意
baremetal
flavor,而不要使用针对于配置集匹配的 flavor(如 compute
、control
等)。
6.3.2. 自定义主机名
rack2-row12
来表示它所在的位置。
parameter_defaults: ControllerSchedulerHints: 'capabilities:node': 'controller-%index%' NovaComputeSchedulerHints: 'capabilities:node': 'novacompute-%index%' HostnameMap: overcloud-controller-0: overcloud-controller-prod-123-0 overcloud-controller-1: overcloud-controller-prod-456-0 overcloud-controller-2: overcloud-controller-prod-789-0 overcloud-novacompute-0: overcloud-novacompute-prod-abc-0
parameter_defaults
的部分中定义 HostnameMap
,使用 HostnameFormat
参数设置 head 定义的原始主机名的映射信息(如 overcloud-controller-0
),第二个值是那个节点的自定义主机名(如 overcloud-controller-prod-123-0
)。
6.3.3. 分配可预测的 IP
environments/ips-from-pool-all.yaml
环境文件,把这个文件复制到 stack
用户的 templates
目录中。
$ cp /usr/share/openstack-tripleo-heat-templates/environments/ips-from-pool-all.yaml ~/templates/.
ips-from-pool-all.yaml
文件包括两个主要部分。
resource_registry
用来覆盖默认设置。它们用来通知 director 在一个节点类型的指定端口上使用一个特定的 IP。修改每个资源来使用到代表它们的模板的绝对 URL。例如:
OS::TripleO::Controller::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external_from_pool.yaml OS::TripleO::Controller::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api_from_pool.yaml OS::TripleO::Controller::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_from_pool.yaml OS::TripleO::Controller::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt_from_pool.yaml OS::TripleO::Controller::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant_from_pool.yaml
resource_registry
项删除。
ControllerIPs
代表 Controller 节点。NovaComputeIPs
代表 Compute 节点。CephStorageIPs
代表 Ceph Storage 节点。BlockStorageIPs
代表 Block Storage 节点。SwiftStorageIPs
代表 Object Storage 节点。
CephStorageIPs: storage: - 172.16.1.100 - 172.16.1.101 - 172.16.1.102 storage_mgmt: - 172.16.3.100 - 172.16.3.101 - 172.16.3.102
internal_api
分配的地址位于 InternalApiAllocationPools
的范围之外,这会避免与每个网络所选 VIP 的冲突。同样,确定分配的 IP 地址与为外部负载平衡环境定义的 VIP 配置没有冲突(请参阅 第 6.5 节 “配置外部负载平衡”)。
openstack overcloud deploy
命令中包括这个环境文件。
6.4. 配置容器化的 Compute 节点
docker.yaml
- 配置容器化 Compute 节点的主要环境文件。docker-network.yaml
- 没有网络隔离的容器化 Compute 节点网络的环境文件。docker-network-isolation.yaml
- 使用网络隔离的容器化 Compute 节点的环境文件。
6.4.1. 容器化 Compute 环境文件(docker.yaml)
docker.yaml
是包括容器化 Compute 节点配置的主环境文件。它包括了 resource_registry
中的项:
resource_registry: OS::TripleO::ComputePostDeployment: ../docker/compute-post.yaml OS::TripleO::NodeUserData: ../docker/firstboot/install_docker_agents.yaml
- OS::TripleO::NodeUserData
- 在第一次引导时,提供一个使用自定义配置的 Heat 模板。在这种情况下,它会在第一次引导时在 Compute 节点上安装
openstack-heat-docker-agents
容器。这个容器提供了一组初始脚本来配置容器化 Compute 节点,以及 Heat hook 来和 director 进行通讯。 - OS::TripleO::ComputePostDeployment
- 提供一组 Compute 节点的后配置资源的 Heat 模板。这包括了一个软件配置资源,它为 Puppet 提供了一组
tags
:ComputePuppetConfig: type: OS::Heat::SoftwareConfig properties: group: puppet options: enable_hiera: True enable_facter: False tags: package,file,concat,file_line,nova_config,neutron_config,neutron_agent_ovs,neutron_plugin_ml2 inputs: - name: tripleo::packages::enable_install type: Boolean default: True outputs: - name: result config: get_file: ../puppet/manifests/overcloud_compute.pp
这些 tag 定义了 Puppet 模板来传递到openstack-heat-docker-agents
容器。
docker.yaml
文件包括了一个名为 NovaImage
的 parameter
,它会在配置 Compute 节点时使用一个不同的镜像(atomic-image
)替换标准的 overcloud-full
镜像。第 6.4.2 节 “上传 Atomic Host 镜像” 介绍了上传这个新镜像的方法。
docker.yaml
文件还包括了一个 parameter_defaults
部分,它定义了 Docker 的注册表以及 Compute 节点服务要使用的镜像。您可以修改这个部分来使用本地的注册表,而不使用默认的 registry.access.redhat.com
。如需了解配置一个本地注册表的信息,请参阅 第 6.4.3 节 “使用本地注册表”。
6.4.2. 上传 Atomic Host 镜像
atomic-image
)。这是因为,在 Overcloud 创建的 provisioning 阶段,Compute 节点需要这个镜像作为基础 OS。
stack
用户的家目录下的 images
子目录中。
stack
用户把镜像导入到 director。
$ glance image-create --name atomic-image --file ~/images/rhel-atomic-cloud-7.2-12.x86_64.qcow2 --disk-format qcow2 --container-format bare
$ glance image-list +--------------------------------------+------------------------+ | ID | Name | +--------------------------------------+------------------------+ | 27b5bad7-f8b2-4dd8-9f69-32dfe84644cf | atomic-image | | 08c116c6-8913-427b-b5b0-b55c18a01888 | bm-deploy-kernel | | aec4c104-0146-437b-a10b-8ebc351067b9 | bm-deploy-ramdisk | | 9012ce83-4c63-4cd7-a976-0c972be747cd | overcloud-full | | 376e95df-c1c1-4f2a-b5f3-93f639eb9972 | overcloud-full-initrd | | 0b5773eb-4c64-4086-9298-7f28606b68af | overcloud-full-vmlinuz | +--------------------------------------+------------------------+
6.4.3. 使用本地注册表
$ sudo docker pull registry.access.redhat.com/openstack-nova-compute:latest $ sudo docker pull registry.access.redhat.com/openstack-data:latest $ sudo docker pull registry.access.redhat.com/openstack-nova-libvirt:latest $ sudo docker pull registry.access.redhat.com/openstack-neutron-openvswitch-agent:latest $ sudo docker pull registry.access.redhat.com/openstack-openvswitch-vswitchd:latest $ sudo docker pull registry.access.redhat.com/openstack-openvswitch-db-server:latest $ sudo docker pull registry.access.redhat.com/openstack-heat-docker-agents:latest
$ sudo docker tag registry.access.redhat.com/openstack-nova-compute:latest localhost:8787/registry.access.redhat.com/openstack-nova-compute:latest $ sudo docker tag registry.access.redhat.com/openstack-data:latest localhost:8787/registry.access.redhat.com/openstack-data:latest $ sudo docker tag registry.access.redhat.com/openstack-nova-libvirt:latest localhost:8787/registry.access.redhat.com/openstack-nova-libvirt:latest $ sudo docker tag registry.access.redhat.com/openstack-neutron-openvswitch-agent:latest localhost:8787/registry.access.redhat.com/openstack-neutron-openvswitch-agent:latest $ sudo docker tag registry.access.redhat.com/openstack-openvswitch-vswitchd:latest localhost:8787/registry.access.redhat.com/openstack-openvswitch-vswitchd:latest $ sudo docker tag registry.access.redhat.com/openstack-openvswitch-db-server:latest localhost:8787/registry.access.redhat.com/openstack-openvswitch-db-server:latest $ sudo docker tag registry.access.redhat.com/openstack-heat-docker-agents:latest localhost:8787/registry.access.redhat.com/openstack-heat-docker-agents:latest
$ sudo docker push localhost:8787/registry.access.redhat.com/openstack-nova-compute:latest $ sudo docker push localhost:8787/registry.access.redhat.com/openstack-data:latest $ sudo docker push localhost:8787/registry.access.redhat.com/openstack-nova-libvirt:latest $ sudo docker push localhost:8787/registry.access.redhat.com/openstack-neutron-openvswitch-agent:latest $ sudo docker push localhost:8787/registry.access.redhat.com/openstack-openvswitch-vswitchd:latest $ sudo docker push localhost:8787/registry.access.redhat.com/openstack-openvswitch-db-server:latest $ sudo docker push localhost:8787/registry.access.redhat.com/openstack-heat-docker-agents:latest
templates
子目录中创建一个主 docker.yaml
环境文件:
$ cp /usr/share/openstack-tripleo-heat-templates/environments/docker.yaml ~/templates/.
resource_registry
来使用绝对 URL:
resource_registry: OS::TripleO::ComputePostDeployment: /usr/share/openstack-tripleo-heat-templates/docker/compute-post.yaml OS::TripleO::NodeUserData: /usr/share/openstack-tripleo-heat-templates/docker/firstboot/install_docker_agents.yaml
parameter_defaults
中的 DockerNamespace
设置为您的注册表的 URL。另外,还需要把 DockerNamespaceIsRegistry
设置为 true
。例如:
parameter_defaults: DockerNamespace: registry.example.com:8787/registry.access.redhat.com DockerNamespaceIsRegistry: true
6.4.4. 在 Overcloud 部署中包括环境文件
openstack overcloud deploy
命令中包括容器化 Compute 节点的主环境文件(docker.yaml
)和网络环境文件(docker-network.yaml
)。例如:
$ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/docker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/docker-network.yaml [OTHER OPTIONS] ...
docker-network-isolation.yaml
)。在 第 6.2 节 “分离网络” 介绍的网络分离文件前添加这些文件。例如:
openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/docker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/docker-network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml [OTHER OPTIONS] ...
6.5. 配置外部负载平衡
6.6. 配置 IPv6 网络
6.7. 配置 NFS 存储
/usr/share/openstack-tripleo-heat-templates/environments/
中,核心 heat 模板集合包括了一组环境文件。这些环境文件可以帮助对由 director 创建的 Overcloud 所支持的特定文件进行定制配置。其中,包括一个用来对存储进行配置的环境文件(/usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml
)。把这个文件复制到 stack
用户的模板目录中。
$ cp /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml ~/templates/.
- CinderEnableIscsiBackend
- 启用 iSCSI 后端。把它设置为
false
。 - CinderEnableRbdBackend
- 启用 Ceph 存储后台。把它设置为
false
。 - CinderEnableNfsBackend
- 启动 NFS 后端。把它设置为
true
。 - NovaEnableRbdBackend
- 为 Nova 临时存储(ephemeral storage)启用 Ceph 存储。把它设置为
false
。 - GlanceBackend
- 定义 Glance 的后端。把它设为
file
来为镜像使用基于文件的存储。Overcloud 会为 Glance 在一个挂载的 NFS 共享中存储这些文件。 - CinderNfsMountOptions
- 卷存储的 NFS 挂载选项。
- CinderNfsServers
- 为卷共享挂载的 NFS 共享。例如,
192.168.122.1:/export/cinder
。 - GlanceFilePcmkManage
- 为镜像存储启用 Pacemaker 来管理共享。如果被禁用,Overcloud 会把镜像存储在 Controller 节点的文件系统中。把它设置为
true
。 - GlanceFilePcmkFstype
- 定义 Pacemaker 用来进行镜像存储的文件系统类型。把它设为
nfs
。 - GlanceFilePcmkDevice
- 挂载的、用于镜像存储的 NFS 共享。例如:
192.168.122.1:/export/glance
。 - GlanceFilePcmkOptions
- 用于镜像存储的 NFS 挂载选项。
parameter_defaults: CinderEnableIscsiBackend: false CinderEnableRbdBackend: false CinderEnableNfsBackend: true NovaEnableRbdBackend: false GlanceBackend: 'file' CinderNfsMountOptions: 'rw,sync' CinderNfsServers: '192.0.2.230:/cinder' GlanceFilePcmkManage: true GlanceFilePcmkFstype: 'nfs' GlanceFilePcmkDevice: '192.0.2.230:/glance' GlanceFilePcmkOptions: 'rw,sync,context=system_u:object_r:glance_var_lib_t:s0'
重要
GlanceFilePcmkOptions
参数中包括 context=system_u:object_r:glance_var_lib_t:s0
允许 glance 访问 /var/lib
目录。如果没有这个 SELinux 设置,glance 将无法写挂载点。
6.8. 配置 Ceph 存储
- 创建一个带有自己的 Ceph Storage Cluster 的 Overcloud
- director 在创建 Overcloud 时可以创建一个 Ceph Storage Cluster。director 会创建一组使用 Ceph OSD 来存储数据的 Ceph Storage 节点。另外,director 还会在 Overcloud 的 Controller 节点上安装 Ceph Monitor 服务。这意味着,如果创建了一个带有 3 个高可用性 controller 节点的 Overcloud,Ceph Monitor 服务也会成为高可用性服务。
- 把一个已存在的 Ceph Storage 集成到 Overcloud
- 如果您已有一个 Ceph Storage Cluster,则可以在部署 Overcloud 的时候把它集成到 Overcloud。这意味着,您可以管理和扩展 Overcloud 配置以外的集群。
6.9. 配置第三方存储
- Dell Storage Center
- 部署一个单一的 Dell Storage Center 后台作为 Block Storage(cinder)服务。环境文件位于
/usr/share/openstack-tripleo-heat-templates/environments/cinder-dellsc-config.yaml
。如需了解更详细的配置信息,请参阅 Dell Storage Center Back End Guide。 - Dell EqualLogic
- 部署一个单独的 Dell EqualLogic 后台作为 Block Storage(cinder)服务。环境文件位于
/usr/share/openstack-tripleo-heat-templates/environments/cinder-eqlx-config.yaml
。如需了解详细的配置信息,请参阅 Dell EqualLogic Back End Guide。 - NetApp Block Storage
- 部署一个 NetApp storage appliance 作为 Block Storage(cinder)服务的后端。环境文件位于
/usr/share/openstack-tripleo-heat-templates/environments/cinder-dellsc-config.yaml/cinder-netapp-config.yaml
。如需了解详细的配置信息,请参阅 NetApp Block Storage Back End Guide。
6.10. 配置 Overcloud 时区
TimeZone
参数来配置 Overcloud 部署的时区。如果把 TimeZone
参数设为空,Overcloud 将会默认使用 UTC
时间。
Japan
,您可以查看 of /usr/share/zoneinfo 文件来找到适当的值:
$ ls /usr/share/zoneinfo/ Africa Asia Canada Cuba EST GB GMT-0 HST iso3166.tab Kwajalein MST NZ-CHAT posix right Turkey UTC Zulu America Atlantic CET EET EST5EDT GB-Eire GMT+0 Iceland Israel Libya MST7MDT Pacific posixrules ROC UCT WET Antarctica Australia Chile Egypt Etc GMT Greenwich Indian Jamaica MET Navajo Poland PRC ROK Universal W-SU Arctic Brazil CST6CDT Eire Europe GMT0 Hongkong Iran Japan Mexico NZ Portugal PST8PDT Singapore US zone.tab
Japan
是一个单独的时区文件,而 Africa
是一个目录,它包括了其它额外的时区文件:
$ ls /usr/share/zoneinfo/Africa/ Abidjan Algiers Bamako Bissau Bujumbura Ceuta Dar_es_Salaam El_Aaiun Harare Kampala Kinshasa Lome Lusaka Maseru Monrovia Niamey Porto-Novo Tripoli Accra Asmara Bangui Blantyre Cairo Conakry Djibouti Freetown Johannesburg Khartoum Lagos Luanda Malabo Mbabane Nairobi Nouakchott Sao_Tome Tunis Addis_Ababa Asmera Banjul Brazzaville Casablanca Dakar Douala Gaborone Juba Kigali Libreville Lubumbashi Maputo Mogadishu Ndjamena Ouagadougou Timbuktu Windhoek
Japan
:
parameter_defaults: TimeZone: 'Japan'
$ openstack overcloud deploy --templates -e timezone.yaml
6.11. 在 Overcloud 中启用 SSL/TLS
注意
启用 SSL/TLS
enable-tls.yaml
环境文件:
$ cp -r /usr/share/openstack-tripleo-heat-templates/environments/enable-tls.yaml ~/templates/.
parameter_defaults:
- SSLCertificate:
- 把证书文件的内容复制到
SSLCertificate
参数中。例如:parameter_defaults: SSLCertificate: | -----BEGIN CERTIFICATE----- MIIDgzCCAmugAwIBAgIJAKk46qw6ncJaMA0GCSqGSIb3DQEBCwUAMFgxCzAJBgNV ... sFW3S2roS4X0Af/kSSD8mlBBTFTCMBAj6rtLBKLaQbIxEpIzrgvp -----END CERTIFICATE-----
重要
证书授权内容中的所有新行都需要有相同的行缩进。 - SSLKey:
- 把私人密钥的内容复制到
SSLKey
参数。例如>parameter_defaults: ... SSLKey: | -----BEGIN RSA PRIVATE KEY----- MIIEowIBAAKCAQEAqVw8lnQ9RbeI1EdLN5PJP0lVO9hkJZnGP6qb6wtYUoy1bVP7 ... ctlKn3rAAdyumi4JDjESAXHIKFjJNOLrBmpQyES4XpZUC7yhqPaU -----END RSA PRIVATE KEY-----
重要
私人密钥的内容中的所有新行都需要有相同的行缩进。 - EndpointMap:
EndpointMap
包括了使用 HTTPS 和 HTTP 的服务的映射信息。如果 SSL 使用 DNS,不要修改这个部分的默认设置。但是,如果使用一个 IP 地址作为 SSL 证书的常规名(请参阅 附录 A, SSL/TLS 证书配置),使用IP_ADDRESS
替换所有CLOUDNAME
实例。运行以下命令:$ sed -i 's/CLOUDNAME/IP_ADDRESS/' ~/templates/enable-tls.yaml
重要
不要使用实际的值替换IP_ADDRESS
和CLOUDNAME
,Heat 会在 Overcloud 创建的过程中替换这些变量。
resource_registry:
- OS::TripleO::NodeTLSData:
- 把
OS::TripleO::NodeTLSData:
的资源 URL 改为一个绝对的 URL:resource_registry: OS::TripleO::NodeTLSData: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/tls/tls-cert-inject.yaml
注入一个 Root 证书
inject-trust-anchor.yaml
环境文件:
$ cp -r /usr/share/openstack-tripleo-heat-templates/environments/inject-trust-anchor.yaml ~/templates/.
parameter_defaults:
- SSLRootCertificate:
- 把 root 证书授权文件的内容复制到
SSLRootCertificate
参数。例如:parameter_defaults: SSLRootCertificate: | -----BEGIN CERTIFICATE----- MIIDgzCCAmugAwIBAgIJAKk46qw6ncJaMA0GCSqGSIb3DQEBCwUAMFgxCzAJBgNV ... sFW3S2roS4X0Af/kSSD8mlBBTFTCMBAj6rtLBKLaQbIxEpIzrgvp -----END CERTIFICATE-----
重要
证书授权内容中的所有新行都需要有相同的行缩进。
resource_registry:
- OS::TripleO::NodeTLSCAData:
- 把
OS::TripleO::NodeTLSCAData:
的资源 URL 改为一个绝对的 URL:resource_registry: OS::TripleO::NodeTLSCAData: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/tls/ca-inject.yaml
配置 DNS 端点
~/templates/cloudname.yaml
)来定义 Overcloud 端点的主机名。使用以下参数:
parameter_defaults:
- CloudName:
- Overcloud 端点的 DNS 主机名。
- DnsServers:
- 使用的 DNS 服务器列表。配置的 DNS 服务器需要包括一个配置的
CloudName
的项,它需要和 Public API 的 IP 地址相匹配。
parameter_defaults: CloudName: overcloud.example.com DnsServers: ["10.0.0.1"]
在 Overcloud 创建期间添加环境文件
- 启用 SSL/TLS 的环境文件(
enable-tls.yaml
) - 设置 DNS 主机名的环境文件(
cloudname.yaml
) - 注入 root 证书授权的环境文件(
inject-trust-anchor.yaml
)
$ openstack overcloud deploy --templates [...] -e /home/stack/templates/enable-tls.yaml -e ~/templates/cloudname.yaml -e ~/templates/inject-trust-anchor.yaml
6.12. 注册 Overcloud
方法 1 - 命令行
openstack overcloud deploy
)使用一组选项来定义您的注册详情。第 7.1 节 “设置 Overcloud 参数” 中的表格包括了这些选项以及它们的描述信息。使用 第 7 章 创建 Overcloud 中的部署命令时包括这些选项,例如:
# openstack overcloud deploy --templates --rhel-reg --reg-method satellite --reg-sat-url http://example.satellite.com --reg-org MyOrg --reg-activation-key MyKey --reg-force [...]
方法 2 - 环境文件
$ cp -r /usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration ~/templates/.
~/templates/rhel-registration/environment-rhel-registration.yaml
,根据您具体的注册情况和方法,修改以下值:
- rhel_reg_method
- 选择注册方法。可以是
portal
、satellite
或disable
。 - rhel_reg_type
- 注册的单元类型。如果注册为一个
system
,把它设为空 - rhel_reg_auto_attach
- 为系统自动附加兼容的订阅。如需启用这个功能,把它设置为
true
。 - rhel_reg_service_level
- 自动附加所使用的服务级别。
- rhel_reg_release
- 使用这个参数来为自动附加设置发行版本。如果设置为空,则使用从 Red Hat Subscription Manager 获得的默认值。
- rhel_reg_pool_id
- 使用的订阅池 ID。在没有使用自动附加功能时使用这个参数。
- rhel_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
进行注册。 - rhel_reg_server_url
- 订阅服务使用的主机名。默认是 Customer Portal Subscription Management(
subscription.rhn.redhat.com
)。如果这个选项没有被使用,系统会使用 Customer Portal Subscription Management 进行注册。订阅服务器 URL 的格式是https://hostname:port/prefix
。 - rhel_reg_base_url
- 获得系统更新的内容服务器的主机名,它的默认值是
https://cdn.redhat.com
。因为 Satellite 6 主机有它自己的内容,注册到 Satellite 6 的系统需要在这个参数中指定 URL。基本 URL 的格式是https://hostname:port/prefix
。 - rhel_reg_org
- 注册的机构
- rhel_reg_environment
- 在所选机构内使用的环境
- rhel_reg_repos
- 启用的软件仓库列表(以逗号分隔)。
- rhel_reg_activation_key
- 注册使用的激活码。
- rhel_reg_user, rhel_reg_password
- 注册的用户名和密码。如果可能,使用激活码进行注册。
- rhel_reg_machine_name
- 机器名。如果使用节点的主机名,把它设为空。
- rhel_reg_force
- 把它设置为
true
来强制使用您的注册选项。例如,重新注册节点。 - rhel_reg_sat_repo
- 包括 Red Hat Satellite 6 的管理工具程序(如
katello-agent
)的仓库。例如,rhel-7-server-satellite-tools-6.1-rpms
。
openstack overcloud deploy
)中使用 -e
选项来添加环境文件。添加 ~/templates/rhel-registration/environment-rhel-registration.yaml
和 ~/templates/rhel-registration/rhel-registration-resource-registry.yaml
。例如:
$ openstack overcloud deploy --templates [...] -e /home/stack/templates/rhel-registration/environment-rhel-registration.yaml -e /home/stack/templates/rhel-registration/rhel-registration-resource-registry.yaml
重要
OS::TripleO::NodeExtraConfig
Heat 资源。这意味着,您只能使用这个资源进行注册。如需了解更多信息,请参阅 第 6.14 节 “自定义 Overcloud 的预配置”。
6.13. 自定义第一次引导的配置
cloud-init
,您可以使用 OS::TripleO::NodeUserData
资源类型调用它。
/home/stack/templates/nameserver.yaml
),它运行一个脚本来为每个节点的 resolv.conf
添加一个特定的名称解析服务器(nameserver)。使用 OS::TripleO::MultipartMime
资源类型来发送配置脚本。
heat_template_version: 2014-10-16 description: > Extra hostname configuration resources: userdata: type: OS::Heat::MultipartMime properties: parts: - config: {get_resource: nameserver_config} nameserver_config: type: OS::Heat::SoftwareConfig properties: config: | #!/bin/bash echo "nameserver 192.168.1.1" >> /etc/resolv.conf outputs: OS::stack_id: value: {get_resource: userdata}
/home/stack/templates/firstboot.yaml
),它把您的 heat 模板注册为 OS::TripleO::NodeUserData
资源类型。
resource_registry: OS::TripleO::NodeUserData: /home/stack/templates/nameserver.yaml
$ openstack overcloud deploy --templates -e /home/stack/templates/firstboot.yaml
-e
把环境文件添加到 Overcloud 栈。
重要
OS::TripleO::NodeUserData
注册到一个 heat 模板。随后的使用会覆盖 heat 模板。
6.14. 自定义 Overcloud 的预配置
- OS::TripleO::ControllerExtraConfigPre
- 在核心 Puppet 配置前,应用到 Controller 节点上的额外配置。
- OS::TripleO::ComputeExtraConfigPre
- 在核心 Puppet 配置前,应用到 Controller 节点上的额外配置。
- OS::TripleO::CephStorageExtraConfigPre
- 在核心 Puppet 配置前,应用到 CephStorage 节点上的额外配置。
- OS::TripleO::NodeExtraConfig
- 在核心 Puppet 配置前,应用到所有节点角色上的额外配置。
/home/stack/templates/nameserver.yaml
),它运行一个脚本来为每个节点的 resolv.conf
添加一个不同的名称解析服务器(nameserver)。
heat_template_version: 2014-10-16 description: > Extra hostname configuration parameters: server: type: string nameserver_ip: type: string resources: ExtraPreConfig: type: OS::Heat::SoftwareConfig properties: group: script config: str_replace: template: | #!/bin/sh echo "nameserver _NAMESERVER_IP_" >> /etc/resolv.conf params: _NAMESERVER_IP_: {get_param: nameserver_ip} ExtraPreDeployment: type: OS::Heat::SoftwareDeployment properties: config: {get_resource: ExtraPreConfig} server: {get_param: server} actions: ['CREATE','UPDATE'] outputs: deploy_stdout: description: Deployment reference, used to trigger pre-deploy on changes value: {get_attr: [ExtraPreDeployment, deploy_stdout]}
重要
server
参数是应用配置的服务器列表,它由父模板提供。这个参数在所有预配置模板中都是必需的。
/home/stack/templates/pre_config.yaml
),它会把您的 heat 模板注册为 OS::TripleO::NodeExtraConfig
资源类型。
resource_registry: OS::TripleO::NodeExtraConfig: /home/stack/templates/nameserver.yaml parameter_defaults: nameserver_ip: 192.168.1.1
$ openstack overcloud deploy --templates -e /home/stack/templates/pre_config.yaml
重要
6.15. Overcloud 创建后的自定义配置
OS::TripleO::NodeExtraConfigPost
资源来应用使用标准的 OS::Heat::SoftwareConfig
类型的配置。这会在主 Overcloud 配置完成后应用额外的配置。
/home/stack/templates/nameserver.yaml
),它运行一个脚本来为每个节点的 resolv.conf
添加一个不同的名称解析服务器(nameserver)。
heat_template_version: 2014-10-16 description: > Extra hostname configuration parameters: servers: type: json nameserver_ip: type: string resources: ExtraConfig: type: OS::Heat::SoftwareConfig properties: group: script config: str_replace: template: | #!/bin/sh echo "nameserver _NAMESERVER_IP_" >> /etc/resolv.conf params: _NAMESERVER_IP_: {get_param: nameserver_ip} ExtraDeployments: type: OS::Heat::SoftwareDeployments properties: servers: {get_param: servers} config: {get_resource: ExtraConfig} actions: ['CREATE','UPDATE']
重要
servers
参数是应用配置的服务器列表,它由父模板提供。这个参数在所有 OS::TripleO::NodeExtraConfigPost
模板中都是必需的。
/home/stack/templates/post_config.yaml
),它把我们的 Heat 模板注册为 OS::TripleO::NodeExtraConfigPost:
资源类型。
resource_registry: OS::TripleO::NodeExtraConfigPost: /home/stack/templates/nameserver.yaml parameter_defaults: nameserver_ip: 192.168.1.1
$ openstack overcloud deploy --templates -e /home/stack/templates/post_config.yaml
重要
OS::TripleO::NodeExtraConfigPost
注册到一个 heat 模板。随后的使用会覆盖 heat 模板。
6.16. 自定义 Puppet 配置数据
- ExtraConfig
- 添加到所有节点的配置
- controllerExtraConfig
- 添加到所有 Controller 节点的配置。
- NovaComputeExtraConfig
- 添加到所有 Compute 节点的配置。
- BlockStorageExtraConfig
- 添加到所有 Block Storage 节点的配置。
- ObjectStorageExtraConfig
- 添加到所有 Object Storage 节点的配置。
- CephStorageExtraConfig
- 添加到所有 Ceph Storage 节点的配置。
parameter_defaults
的部分中包括这些参数的环境文件。例如,把 Compute 主机的保留内存增加到 1024 MB,把 VNC 的键盘输入设置为日语:
parameter_defaults: NovaComputeExtraConfig: nova::compute::reserved_host_memory: 1024 nova::compute::vnc_keymap: ja
openstack overcloud deploy
时包括这个环境文件。
重要
6.17. 应用自定义 Puppet 配置
motd
。这会首先创建一个 Heat 模板(/home/stack/templates/custom_puppet_config.yaml
)来启动 Puppet 配置。
heat_template_version: 2014-10-16 description: > Run Puppet extra configuration to set new MOTD parameters: servers: type: json resources: ExtraPuppetConfig: type: OS::Heat::SoftwareConfig properties: config: {get_file: motd.pp} group: puppet options: enable_hiera: True enable_facter: False ExtraPuppetDeployments: type: OS::Heat::SoftwareDeployments properties: config: {get_resource: ExtraPuppetConfig} servers: {get_param: servers}
/home/stack/templates/motd.pp
,并把它传递给节点进行配置。motd.pp
文件本身包括了我们的 Puppet 类来进行安装和配置 motd
。
/home/stack/templates/puppet_post_config.yaml
),它会把我们的 Heat 模板注册为 OS::TripleO::NodeExtraConfigPost:
资源类型。
resource_registry: OS::TripleO::NodeExtraConfigPost: /home/stack/templates/custom_puppet_config.yaml
$ openstack overcloud deploy --templates -e /home/stack/templates/puppet_post_config.yaml
motd.pp
中的配置应用到 Overcloud 的所有节点上。
6.18. 使用定制的核心 Heat 模板
/usr/share/openstack-tripleo-heat-templates
中的 heat 模板复制到 stack
用户的模板目录中:
$ cp -r /usr/share/openstack-tripleo-heat-templates ~/templates/my-overcloud
openstack overcloud deploy
时,我们使用了 --templates
选项来指定本地的模板目录。请参阅 第 7 章 创建 Overcloud。
注意
--templates
选项设置值,director 会使用默认的模板目录(/usr/share/openstack-tripleo-heat-templates
)。
重要
/usr/share/openstack-tripleo-heat-templates
中的原始版本的不同。红帽推荐使用以下章节中介绍的方法来进行配置,而不是直接修改 heat 模板集合:
git
)来记录对模板的改变。
第 7 章 创建 Overcloud
openstack overcloud deploy
命令进行创建。在运行这个命令前,您需要已经对关键的选项,以及如何包括自定义环境文件有所了解。本章将讨论 openstack overcloud deploy
命令以及与它相关的选项。
警告
openstack overcloud deploy
,因为这可能会造成在 Overcloud 的创建过程中出现进程无法继续的问题。
7.1. 设置 Overcloud 参数
openstack overcloud deploy
命令的额外参数。
表 7.1. 部署参数
参数
|
描述
|
示例
|
---|---|---|
--templates [TEMPLATES]
|
directory 包括 heat 模板进行部署。如果为空,命令会使用位于
/usr/share/openstack-tripleo-heat-templates/ 的默认模板。
|
~/templates/my-overcloud
|
-t [TIMEOUT], --timeout [TIMEOUT]
|
部署超时时间(分钟)
|
240
|
--control-scale [CONTROL_SCALE]
|
扩展的 Controller 节点数量
|
3
|
--compute-scale [COMPUTE_SCALE]
|
扩展的 Compute 节点数量
|
3
|
--ceph-storage-scale [CEPH_STORAGE_SCALE]
|
扩展的 Ceph 节点数量
|
3
|
--block-storage-scale [BLOCK_STORAGE_SCALE]
|
扩展的 Cinder 节点数量
|
3
|
--swift-storage-scale [SWIFT_STORAGE_SCALE]
|
扩展的 Swift 节点数量
|
3
|
--control-flavor [CONTROL_FLAVOR]
|
Controller 节点使用的 flavor
|
control
|
--compute-flavor [COMPUTE_FLAVOR]
|
Compute 节点使用的 flavor
|
compute
|
--ceph-storage-flavor [CEPH_STORAGE_FLAVOR]
|
Ceph 节点使用的 flavor
|
ceph-storage
|
--block-storage-flavor [BLOCK_STORAGE_FLAVOR]
|
Cinder 节点使用的 flavor
|
cinder-storage
|
--swift-storage-flavor [SWIFT_STORAGE_FLAVOR]
|
Swift 存储节点使用的 flavor
|
swift-storage
|
--neutron-flat-networks [NEUTRON_FLAT_NETWORKS]
|
定义在 neutron 插件中配置的平面网络(flat nework)。默认是 "datacentre",允许外部网络创建
|
datacentre
|
--neutron-physical-bridge [NEUTRON_PHYSICAL_BRIDGE]
|
在每个 hypervisor 上创建的 Open vSwitch 网桥。默认值是 "br-ex",一般情况下不需要修改它
|
br-ex
|
--neutron-bridge-mappings [NEUTRON_BRIDGE_MAPPINGS]
|
使用的物理网桥映射逻辑。默认情况是把主机上的外部网桥(br-ex)映射到一个物理名(datacentre)。您可以使用它作为默认的浮动网络(floating network)
|
datacentre:br-ex
|
--neutron-public-interface [NEUTRON_PUBLIC_INTERFACE]
|
定义网络节点的 br-ex 中的网桥接口
|
nic1, eth0
|
--hypervisor-neutron-public-interface [HYPERVISOR_NEUTRON_PUBLIC_INTERFACE]
|
指定在每个 hypervisor 上哪个接口被添加到网桥
|
nic1, eth0
|
--neutron-network-type [NEUTRON_NETWORK_TYPE]
|
Neutron 的租户网络类型
|
gre 或 vxlan
|
--neutron-tunnel-types [NEUTRON_TUNNEL_TYPES]
|
Neutron 租户网络的通道类型。使用逗号分隔的字符串可以指定多个值
|
'vxlan' 'gre,vxlan'
|
--neutron-tunnel-id-ranges [NEUTRON_TUNNEL_ID_RANGES]
|
可以用来进行租户网络分配的 GRE tunnel ID 的范围
|
1:1000
|
--neutron-vni-ranges [NEUTRON_VNI_RANGES]
|
可以用来进行租户网络分配的 VXLAN VNI ID 范围
|
1:1000
|
--neutron-disable-tunneling
|
禁用 tunneling 功能来在 Neutron 中使用 VLAN 分段网络或平面网络
| |
--neutron-network-vlan-ranges [NEUTRON_NETWORK_VLAN_RANGES]
|
支持的 Neutron ML2 和 Open vSwitch VLAN 映射范围。默认是在 'datacentre' 物理网络中允许任何 VLAN。
|
datacentre:1:1000
|
--neutron-mechanism-drivers [NEUTRON_MECHANISM_DRIVERS]
|
neutron 租户网络的驱动。默认值是 "openvswitch"。使用逗号分隔的字符串可以指定多个值
|
'openvswitch,l2population'
|
--libvirt-type [LIBVIRT_TYPE]
|
hypervisor 使用的虚拟类型
|
kvm,qemu
|
--ntp-server [NTP_SERVER]
|
用来同步时间的 NTP 服务器
|
pool.ntp.org
|
--cinder-lvm
|
Cinder 存储使用的 LVM iSCSI 驱动
| |
--tripleo-root [TRIPLEO_ROOT]
|
director 配置文件所在的目录。使用默认的值
| |
--nodes-json [NODES_JSON]
|
用来进行节点注册的原始 JSON 文件。director 会在创建完 Overcloud 后对这个文件进行一些修改。默认值是 instackenv.json
| |
--no-proxy [NO_PROXY]
|
为环境变量 no_proxy 指定自定义值。这个环境变量被用来在代理通讯中排除特定的域扩展。
| |
-O [OUTPUT DIR], --output-dir [OUTPUT DIR]
|
Tuskar 模板文件写入的目录。如果它不存在,则会被创建。如果没有指定,则会使用一个临时目录
|
~/templates/plan-templates
|
-e [EXTRA HEAT TEMPLATE], --extra-template [EXTRA HEAT TEMPLATE]
|
传递给 Overcloud 部署的额外环境文件。这个参数可以指定多次。请注意,传递到
openstack overcloud deploy 命令的环境文件顺序是非常重要的。例如,一个参数出现在一个环境文件中,当这个环境文件的后续环境文件中又出现了这个参数,则后续文件中的参数设置会覆盖前面文件中的设置。
|
-e ~/templates/my-config.yaml
|
--validation-errors-fatal
|
Overcloud 的创建过程会进行一个部署前的检查。当设置了这个选项时,如果部署前的检查出现任何错误,整个操作会退出。我们推荐使用这个参数,因为任何错误都有可能造成您的部署失败。
| |
--validation-warnings-fatal
|
Overcloud 的创建过程会进行一个部署前的检查。当设置了这个选项时,如果部署前的检查出现任何非关键性的警告,整个操作会退出。
| |
--rhel-reg
|
把 Overcloud 节点注册到客户门户网站或 Satellite 6
| |
--reg-method
|
overcloud 节点使用的注册方法
|
如果使用 Red Hat Satellite 6 或 Red Hat Satellite 5,设置为
satellite ;如果使用客户门户网站(Customer Portal),设置为 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]
|
用于注册的激活码
| |
注意
$ openstack help overcloud deploy
7.2. 在 Overcloud 创建中包括环境文件
-e
包括一个用来定制 Overcloud 的环境变量。您可以根据需要添加多个环境文件,但是,环境文件的顺序非常重要,后面的环境文件中定义的参数和资源会覆盖以前环境文件中定义的相同参数和资源。以下是环境文件顺序的一个示例:
- 所有网络分离文件,包括 heat 模板集合中的初始文件 -
environments/network-isolation.yaml
,然后是自定义的 NIC 配置文件。如需了解更多与网络分离相关的信息,请参阅 第 6.2 节 “分离网络”。 - 任何外部的负载平衡环境文件。
- 任何存储环境文件,如 Ceph Storage、NFS、iSCSI 等。
- 任何用于 Red Hat CDN 或 Satellite 注册的环境文件。
- 任何其它自定义环境文件。
警告
-e
选项加入的、成为您的 Overcloud 栈定义的一部分的环境文件。director 需要这些环境文件来进行重新部署,以及使用部署后的功能(请参阅 第 8 章 创建 Overcloud 后执行的任务)。没有正确包括这些文件可能会破坏您的 Overcloud。
openstack overcloud deploy
命令。不要直接编辑 Overcloud 的配置,因为在使用 director 对 Overcloud 栈进行更新时,手工修改的配置会被 director 的配置覆盖。
7.3. 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
--templates
- 使用/usr/share/openstack-tripleo-heat-templates
中的 Heat 模板集合创建 Overcloud。-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml
--e
选项为 Overcloud 部署添加了一个额外的环境文件。在这里,它是一个初始化网络分离配置的环境文件。-e ~/templates/network-environment.yaml
--e
选项为 Overcloud 部署添加了一个环境文件。在这里,它是在 第 6.2.2 节 “创建一个网络环境文件” 中创建的网络环境文件。-e ~/templates/storage-environment.yaml
--e
选项为 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)。
7.4. 监控 Overcloud 的创建
stack
用户身份运行:
$ source ~/stackrc # Initializes the stack user to use the CLI commands $ heat stack-list --show-nested
heat stack-list --show-nested
命令会显示创建 Overcloud 的当前状态。
7.5. 访问 Overcloud
stack
用户家目录的 overcloudrc
文件。运行以下命令来使用这个文件:
$ source ~/overcloudrc
$ source ~/stackrc
heat-admin
的用户。stack
用户有到每个节点上的这个用户的 SSH 访问权限。要通过 SSH 访问一个节点,找到相关节点的 IP 地址:
$ nova list
heat-admin
用户和节点的 IP 地址连接到节点:
$ ssh heat-admin@192.0.2.23
7.6. 完成 Overcloud 的创建
第 8 章 创建 Overcloud 后执行的任务
8.1. 创建 Overcloud Tenant 网络
overcloud
并在 Neutron 中创建一个初始的网络。例如:
$ source ~/overcloudrc $ neutron net-create default $ neutron subnet-create --name default --gateway 172.20.1.1 default 172.20.0.0/16
default
的基本 Neutron 网络。Overcloud 会使用一个内部的 DHCP 来从这个网络中自动分配 IP 地址。
neutron net-list
来确定创建的网络:
$ neutron net-list +-----------------------+-------------+----------------------------------------------------+ | id | name | subnets | +-----------------------+-------------+----------------------------------------------------+ | 95fadaa1-5dda-4777... | default | 7e060813-35c5-462c-a56a-1c6f8f4f332f 172.20.0.0/16 | +-----------------------+-------------+----------------------------------------------------+
8.2. 创建 Overcloud External 网络
使用原生的 VLAN
overcloud
,并在 Neutron 中创建一个 External 网络:
$ source ~/overcloudrc $ neutron net-create nova --router:external --provider:network_type flat --provider:physical_network datacentre $ neutron subnet-create --name nova --enable_dhcp=False --allocation-pool=start=10.1.1.51,end=10.1.1.250 --gateway=10.1.1.1 nova 10.1.1.0/24
nova
的网络。Overcloud 需要使用这个特定的名称来实现浮动 IP 地址池。另外,它对验证测试也非常重要(第 8.5 节 “验证 Overcloud”)。
datacenter
物理网络。作为一个默认的设置,datacenter
会被映射到 br-ex
网桥。如果在创建 Overcloud 时没有使用经过定制的 neutron 设置,这个选项就需要使用默认的设置。
使用非原生的 VLAN
$ source ~/overcloudrc $ neutron net-create nova --router:external --provider:network_type vlan --provider:physical_network datacentre --provider:segmentation_id 104 $ neutron subnet-create --name nova --enable_dhcp=False --allocation-pool=start=10.1.1.51,end=10.1.1.250 --gateway=10.1.1.1 nova 10.1.1.0/24
provider:segmentation_id
的值定义了要使用的 VLAN。在这个示例中,使用 104。
neutron net-list
来确定创建的网络:
$ neutron net-list +-----------------------+-------------+---------------------------------------------------+ | id | name | subnets | +-----------------------+-------------+---------------------------------------------------+ | d474fe1f-222d-4e32... | nova | 01c5f621-1e0f-4b9d-9c30-7dc59592a52f 10.1.1.0/24 | +-----------------------+-------------+---------------------------------------------------+
8.3. 创建额外的浮动 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 datacenter:br-ex,floating:br-floating
$ neutron net-create ext-net --router:external --provider:physical_network floating --provider:network_type vlan --provider:segmentation_id 105 $ neutron subnet-create --name ext-subnet --enable_dhcp=False --allocation-pool start=10.1.2.51,end=10.1.2.250 --gateway 10.1.2.1 ext-net 10.1.2.0/24
8.4. 创建 Overcloud 供应商网络
$ neutron net-create --provider:physical_network datacentre --provider:network_type vlan --provider:segmentation_id 201 --shared provider_network
$ neutron subnet-create --name provider-subnet --enable_dhcp=True --allocation-pool start=10.9.101.50,end=10.9.101.100 --gateway 10.9.101.254 provider_network 10.9.101.0/24
8.5. 验证 Overcloud
$ 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
heat_stack_owner
角色存在于 Overcloud:
$ source ~/overcloudrc $ openstack role list +----------------------------------+------------------+ | ID | Name | +----------------------------------+------------------+ | 6226a517204846d1a26d15aae1af208f | swiftoperator | | 7c7eb03955e545dd86bbfeb73692738b | heat_stack_owner | +----------------------------------+------------------+
$ keystone role-create --name heat_stack_owner
stack
用户的家目录中设置一个 tempest
目录,并安装一个本地版本的 Tempest 套件:
$ mkdir ~/tempest $ cd ~/tempest $ /usr/share/openstack-tempest-liberty/tools/configure-tempest-directory
~/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
是在 第 8.2 节 “创建 Overcloud External 网络” 中创建的外部网络的 UUID。
重要
http_proxy
环境变量。
$ tools/run-tests.sh
注意
'.*smoke'
选项来只运行其中一部分的测试。
$ tools/run-tests.sh '.*smoke'
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。
$ source ~/stackrc $ sudo ovs-vsctl del-port vlan201
8.6. 隔离 Controller 节点
注意
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
表 8.1. 隔离代理
设备
|
类型
|
---|---|
fence_ipmilan
|
Intelligent Platform Management Interface (IPMI)
|
fence_idrac , fence_drac5
|
Dell Remote Access Controller (DRAC)
|
fence_ilo
|
Integrated Lights-Out (iLO)
|
fence_ucs
| |
fence_xvm , fence_virt
|
Libvirt 和 SSH
|
fence_ipmilan
)作为示例。
$ sudo pcs stonith describe fence_ipmilan
stonith
设备。在集群中使用以下命令:
$ 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
$ 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
$ 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
注意
$ sudo pcs stonith show
$ sudo pcs stonith show [stonith-name]
stonith
属性设置为 true
来启用隔离功能:
$ sudo pcs property set stonith-enabled=true
$ sudo pcs property show
8.7. 修改 Overcloud 环境
openstack overcloud deploy
命令。例如,如果根据 第 7 章 创建 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
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
重要
8.8. 把虚拟机导入到 Overcloud
$ nova image-create instance_name image_name $ glance image-download image_name --file exported_vm.qcow2
$ glance image-create --name imported_image --file exported_vm.qcow2 --disk-format qcow2 --container-format bare $ nova boot --poll --key-name default --flavor m1.demo --image imported_image --nic net-id=net_id imported
重要
8.9. 从一个 Overcloud Compute 节点中迁移虚拟机
过程 8.1. 设置 Compute 节点的 SSH 密钥
nova
用户都可以在迁移的过程中访问这些节点。使用以下步骤在每个 Compute 节点上设置一个 SSH 密钥对。
- 创建一个 SSH 密钥:
$ ssh-keygen -t rsa -f nova_id_rsa
- 把 SSH 密钥复制到每个 Compute 节点上的
nova
用户的家目录中。 - 以
nova
用户登录到每个 Compute 节点,运行以下命令来设置密钥:NOVA_SSH=/var/lib/nova/.ssh mkdir ${NOVA_SSH} cp nova_id_rsa ${NOVA_SSH}/id_rsa chmod 600 ${NOVA_SSH}/id_rsa cp nova_id_rsa.pub ${NOVA_SSH}/id_rsa.pub cp nova_id_rsa.pub ${NOVA_SSH}/authorized_keys chown -R nova.nova ${NOVA_SSH} # enable login for nova user on compute hosts: usermod -s /bin/bash nova # add ssh keys of overcloud nodes into known hosts: ssh-keyscan -t rsa `os-apply-config --key hosts --type raw --key-default '' | awk '{print $1}'` >> /etc/ssh/ssh_known_hosts
过程 8.2. 从 Compute 节点上迁移虚拟机
- 在 director 上,source
overcloudrc
,并获得当前的 nova 服务列表:$ source ~/stack/overcloudrc $ nova service-list
- 在要迁移的节点上禁用
nova-compute
服务。$ nova service-disable [hostname] nova-compute
这会防止新的虚拟机在它上面运行。 - 开始把虚拟机从节点上迁移实例的过程:
$ nova host-servers-migrate [hostname]
- 使用以下命令可以查看迁移过程的当前状态:
$ nova migration-list
- 当每个实例的迁移过程完成后,它在 nova 中的状态将变为
VERIFY_RESIZE
。您将可以确认迁移已成功完成,或把它恢复到原来的状态。要确认进行迁移,使用以下命令:$ nova resize-confirm [server-name]
$ nova service-enable [hostname] nova-compute
8.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,把策略恢复为原来的值。
8.11. 删除 Overcloud
过程 8.3. 删除 Overcloud
- 删除一个存在的 Overcloud:
$ heat stack-delete overcloud
- 确认删除 Overcloud:
$ heat stack-list
删除操作会需要几分钟完成。
第 9 章 扩展 Overcloud
表 9.1. 每个节点类型的扩展支持
节点类型
|
扩充
|
缩小
|
备注
|
---|---|---|---|
Controller
|
N
|
N
| |
Compute
|
Y
|
Y
| |
Ceph 存储节点
|
Y
|
N
|
在初始创建的 Overcloud 中最少有一个 Ceph 存储节点。
|
Cinder 存储节点
|
N
|
N
| |
Swift 存储节点
|
N
|
N
| |
9.1. 增加 Compute 节点或 Ceph 存储节点
newnodes.json
):
{ "nodes":[ { "mac":[ "dd:dd:dd:dd:dd:dd" ], "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":[ "ee:ee:ee:ee:ee:ee" ], "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" }, ] }
$ openstack baremetal import --json newnodes.json
$ ironic node-list $ ironic node-set-maintenance [NODE UUID] true $ openstack baremetal introspection start [NODE UUID] $ ironic node-set-maintenance [NODE UUID] false
$ ironic node-update [NODE UUID] add properties/capabilities='profile:compute,boot_option:local'
bm-deploy-kernel
和 bm-deploy-ramdisk
镜像的 UUID:
$ glance image-list +--------------------------------------+------------------------+ | ID | Name | +--------------------------------------+------------------------+ | 09b40e3d-0382-4925-a356-3a4b4f36b514 | bm-deploy-kernel | | 765a46af-4417-4592-91e5-a300ead3faf6 | bm-deploy-ramdisk | | ef793cd0-e65c-456a-a675-63cd57610bd5 | overcloud-full | | 9a51a6cb-4670-40de-b64b-b70f4dd44152 | overcloud-full-initrd | | 4f7e33f4-d617-47c1-b36f-cbe90f132e5d | overcloud-full-vmlinuz | +--------------------------------------+------------------------+
deploy_kernel
和 deploy_ramdisk
设置中使用这些 UUID:
$ ironic node-update [NODE UUID] add driver_info/deploy_kernel='09b40e3d-0382-4925-a356-3a4b4f36b514' $ ironic node-update [NODE UUID] add driver_info/deploy_ramdisk='765a46af-4417-4592-91e5-a300ead3faf6'
openstack overcloud deploy
(使用新的节点数量)。例如,扩展到 5 个 Compute 节点:
$ openstack overcloud deploy --templates --compute-scale 5 [OTHER_OPTIONS]
重要
9.2. 删除 Compute 节点
重要
$ source ~/stack/overcloudrc $ nova service-list $ nova service-disable [hostname] nova-compute $ source ~/stack/stackrc
overcloud
栈进行更新。首先,找到 Overcloud 栈的 UUID:
$ heat stack-list
$ nova list
$ openstack overcloud node delete --stack [STACK_UUID] --templates -e [ENVIRONMENT_FILE] [NODE1_UUID] [NODE2_UUID] [NODE3_UUID]
重要
-e
或 --environment-file
选项再次传递它们来避免对 Overcloud 的不必要的改变。
$ source ~/stack/overcloudrc $ nova service-delete [service-id] $ source ~/stack/stackrc
9.3. 替换 Compute 节点
- 迁移 Compute 节点上的负载并关闭节点。详细信息,请参阅 第 8.9 节 “从一个 Overcloud Compute 节点中迁移虚拟机”。
- 从 Overcloud 中删除 Compute 节点。详细信息,请参阅 第 9.2 节 “删除 Compute 节点”。
- 添加新 Compute 节点扩展 Overcloud。详细信息,请参阅 第 9 章 扩展 Overcloud。
9.4. 替换 Controller 节点
重要
openstack overcloud deploy
命令来更新需要替换 controller 节点的 Overcloud。请注意,这个过程不是完全自动的,在 Overcloud 栈更新过程中,openstack overcloud deploy
命令会在某个阶段报告一个错误,Overcloud 栈更新的过程会随之停止。这时,需要一些人工的干预后,openstack overcloud deploy
进程才会继续。
nova list
输出中的实例名的一个后缀。
[stack@director ~]$ nova list +--------------------------------------+------------------------+ | ID | Name | +--------------------------------------+------------------------+ | 861408be-4027-4f53-87a6-cd3cf206ba7a | overcloud-compute-0 | | 0966e9ae-f553-447a-9929-c4232432f718 | overcloud-compute-1 | | 9c08fa65-b38c-4b2e-bd47-33870bff06c7 | overcloud-compute-2 | | a7f0f5e1-e7ce-4513-ad2b-81146bc8c5af | overcloud-controller-0 | | cfefaf60-8311-4bc3-9416-6a824a40a9ae | overcloud-controller-1 | | 97a055d4-aefd-481c-82b7-4a5f384036d2 | overcloud-controller-2 | +--------------------------------------+------------------------+
overcloud-controller-1
节点,并使用 overcloud-controller-3
替换它。首先,把节点设置为维护模式,从而使 director 不再关心故障节点。把 nova list
中的实例 ID 与 ironic node-list
中的节点 ID 相关联
[stack@director ~]$ ironic node-list +--------------------------------------+------+--------------------------------------+ | UUID | Name | Instance UUID | +--------------------------------------+------+--------------------------------------+ | 36404147-7c8a-41e6-8c72-a6e90afc7584 | None | 7bee57cf-4a58-4eaf-b851-2a8bf6620e48 | | 91eb9ac5-7d52-453c-a017-c0e3d823efd0 | None | None | | 75b25e9a-948d-424a-9b3b-f0ef70a6eacf | None | None | | 038727da-6a5c-425f-bd45-fda2f4bd145b | None | 763bfec2-9354-466a-ae65-2401c13e07e5 | | dc2292e6-4056-46e0-8848-d6e96df1f55d | None | 2017b481-706f-44e1-852a-2ee857c303c4 | | c7eadcea-e377-4392-9fc3-cf2b02b7ec29 | None | 5f73c7d7-4826-49a5-b6be-8bfd558f3b41 | | da3a8d19-8a59-4e9d-923a-6a336fe10284 | None | cfefaf60-8311-4bc3-9416-6a824a40a9ae | | 807cb6ce-6b94-4cd1-9969-5c47560c2eee | None | c07c13e6-a845-4791-9628-260110829c3a | +--------------------------------------+------+--------------------------------------+
[stack@director ~]$ ironic node-set-maintenance da3a8d19-8a59-4e9d-923a-6a336fe10284 true
control
配置集标记新节点。
[stack@director ~]$ ironic node-update 75b25e9a-948d-424a-9b3b-f0ef70a6eacf add properties/capabilities='profile:control,boot_option:local'
~/templates/remove-node.yaml
),它定义了要被删除的节点索引:
parameters: ControllerRemovalPolicies: [{'resource_list': ['1']}]
重要
overcloud-without-mergepy.yaml
文件:
bootstrap_nodeid: {get_attr: [Controller, resource.0.hostname]} bootstrap_nodeid_ip: {get_attr: [Controller, resource.0.ip_address]}
bootstrap_nodeid: {get_attr: [Controller, resource.1.hostname]} bootstrap_nodeid_ip: {get_attr: [Controller, resource.1.ip_address]}
remove-node.yaml
环境文件:
[stack@director ~]$ openstack overcloud deploy --templates --control-scale 3 -e ~/remove-node.yaml
重要
-e
或 --environment-file
选项再次传递它们来避免对 Overcloud 的不必要的手工改变。
remove-node.yaml
在这个实例中只需要一次。
[stack@director ~]$ heat stack-list --show-nested
UPDATE_FAILED
错误。这是因为一些 Puppet 模块不支持节点替换。此时,需要一些人工的干预。您需要执行以下操作:
- 以
heat-admin
的身份登录到其它节点中的一个。director 的stack
用户有一个访问heat-admin
用户的 SSH 密钥。 - 从集群中删除故障节点:
[heat-admin@overcloud-controller-0 ~]$ sudo crm_node -R overcloud-controller-1 --force
- 从 RabbitMQ 集群中删除故障节点:
[heat-admin@overcloud-controller-0 ~]$ sudo rabbitmqctl forget_cluster_node rabbit@overcloud-controller-1
- 从 MongoDB 中删除故障节点。首先,从其它任何节点上连接到 MongoDB:
[heat-admin@overcloud-controller-0 ~]$ mongo --host 192.168.0.23 MongoDB shell version: 2.6.9 connecting to: 192.168.0.23:27017/test Welcome to the MongoDB shell. For interactive help, type "help". For more comprehensive documentation, see http://docs.mongodb.org/ Questions? Try the support group http://groups.google.com/group/mongodb-user tripleo:SECONDARY>
检查 MongoDB 集群的状态:tripleo:SECONDARY> rs.status()
删除故障节点并退出:tripleo:SECONDARY> rs.remove('192.168.0.23:27017') tripleo:SECONDARY> exit
- 在 Galera 集群中更新节点列表:
[heat-admin@overcloud-controller-0 ~]$ sudo pcs resource update galera wsrep_cluster_address=gcomm://overcloud-controller-0,overcloud-controller-3,overcloud-controller-2
- 登录到每个 Controller 节点,从
/etc/corosync/corosync.conf
中删除故障节点并重启 Corosync。例如,从 Controller 节点 0 的配置中删除故障节点:[heat-admin@overcloud-controller-0 ~]$ sudo vi /etc/corosync/corosync.conf
删除包括故障节点(节点 1)的部分:node { ring0_addr: overcloud-controller-1 nodeid: 2 }
重新启动 Corosync:[heat-admin@overcloud-controller-0 ~]$ sudo systemctl restart corosync
在每个节点上完成这个操作。 - 在新节点上启动 Pacemaker 和 Corosync:
[heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster node add overcloud-controller-3 [heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster start overcloud-controller-3
- 在新节点上启动 keystone 服务。从其它节点上把
/etc/keystone
目录复制到 director 主机:[heat-admin@overcloud-controller-0 ~]$ sudo -i [root@overcloud-controller-0 ~]$ scp -r /etc/keystone stack@192.168.0.1:~/.
然后登录到新的 Controller 节点。从新节点中删除/etc/keystone
目录,从 director 主机上复制keystone
文件:[heat-admin@overcloud-controller-3 ~]$ sudo -i [root@overcloud-controller-3 ~]$ rm -rf /etc/keystone [root@overcloud-controller-3 ~]$ scp -r stack@192.168.0.1:~/keystone /etc/. [root@overcloud-controller-3 ~]$ chown -R keystone: /etc/keystone [root@overcloud-controller-3 ~]$ chown root /etc/keystone/logging.conf /etc/keystone/default_catalog.templates
编辑/etc/keystone/keystone.conf
,把admin_bind_host
和public_bind_host
参数设置为新 Controller 节点的 IP 地址。通过 Pacemaker 启用并重启 keystone 服务:[heat-admin@overcloud-controller-3 ~]$ sudo pcs resource enable openstack-keystone-clone overcloud-controller-3 [heat-admin@overcloud-controller-3 ~]$ sudo pcs resource cleanup openstack-keystone-clone overcloud-controller-3
[stack@director ~]$ openstack overcloud deploy --templates --control-scale 3 -e [ENVIRONMENT_FILE]
重要
-e
或 --environment-file
选项再次传递它们来避免对 Overcloud 的不必要的手工改变。
remove-node.yaml
不再需要。
[heat-admin@overcloud-controller-3 ~]$ sudo pcs resource enable openstack-keystone-clone overcloud-controller-3 [heat-admin@overcloud-controller-3 ~]$ sudo pcs resource cleanup openstack-keystone-clone overcloud-controller-3
[heat-admin@overcloud-controller-0 ~]$ sudo pcs resource cleanup neutron-server-clone [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource cleanup openstack-nova-api-clone [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource cleanup openstack-nova-consoleauth-clone [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource cleanup openstack-heat-engine-clone [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource cleanup openstack-cinder-api-clone [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource cleanup openstack-glance-registry-clone [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource cleanup httpd-clone
[heat-admin@overcloud-controller-0 ~]$ sudo pcs status
注意
pcs status
的输出中,使用以下命令把它删除:
[heat-admin@overcloud-controller-0 ~]$ sudo crm_node -R overcloud-controller-1 --force
9.5. 替换 Object 存储节点
- 更新带有新 Object 存储节点的 Overcloud,防止 Director 创建 ring 文件。
- 使用
swift-ring-builder
对节点手工添加或删除节点。
~/templates/swift-ring-prevent.yaml
):
parameter_defaults: SwiftRingBuild: false RingBuild: false ObjectStorageCount: 3
SwiftRingBuild
和 RingBuild
参数分别定义了 Overcloud 是否自动为 Object 存储和 Controller 节点自动构建 ring 文件。ObjectStorageCount
定义了在环境中有多少个 Object 存储节点。在这里,我们把节点数从 2 个扩展为 3 个。
openstack overcloud deploy
命令中包括 swift-ring-prevent.yaml
文件,以及 Overcloud 中的其它环境文件:
$ openstack overcloud deploy --templates [ENVIRONMENT_FILES] -e swift-ring-prevent.yaml
注意
$ sudo mkdir -p /srv/node/d1 $ sudo chown -R swift:swift /srv/node/d1
注意
heat-admin
用户身份登录到一个 Controller 节点,然后切换到超级用户(superuser)。例如,对于一个 IP 地址为 192.168.201.24 的 Controller 节点:
$ ssh heat-admin@192.168.201.24 $ sudo -i
/etc/swift/*.builder
文件从 Controller 节点复制到新的 Object 存储节点的 /etc/swift/
目录中。如果需要,把文件放到 director 主机上:
[root@overcloud-controller-0 ~]# scp /etc/swift/*.builder stack@192.1.2.1:~/.
[stack@director ~]$ scp ~/*.builder heat-admin@192.1.2.24:~/.
heat-admin
用户的身份登录到新的 Object 存储节点上,然后切换到超级用户。例如,对于 IP 地址为 192.168.201.29 的 Object 存储节点:
$ ssh heat-admin@192.168.201.29 $ sudo -i
/etc/swift
目录:
# cp /home/heat-admin/*.builder /etc/swift/.
# swift-ring-builder /etc/swift/account.builder add zX-IP:6002/d1 weight # swift-ring-builder /etc/swift/container.builder add zX-IP:6001/d1 weight # swift-ring-builder /etc/swift/object.builder add zX-IP:6000/d1 weight
- zX
- 使用代表特定区的一个整数替换 X(例如,Zone 1 的值为 1)。
- IP
- 帐号、容器和对象服务要监听的 IP 地址。这应该和每个存储节点的 IP 地址相匹配,特别是和
/etc/swift/object-server.conf
、/etc/swift/account-server.conf
和/etc/swift/container-server.conf
中的DEFAULT
部分中的bind_ip
的值相匹配。 - weight
- 表示一个设备和其它设备相比较的相对权重。它的值通常是 100。
注意
swift-ring-builder
命令来检查当前节点存在的值:
# swift-ring-builder /etc/swift/account.builder
# swift-ring-builder /etc/swift/account.builder remove IP # swift-ring-builder /etc/swift/container.builder remove IP # swift-ring-builder /etc/swift/object.builder remove IP
# swift-ring-builder /etc/swift/account.builder rebalance # swift-ring-builder /etc/swift/container.builder rebalance # swift-ring-builder /etc/swift/object.builder rebalance
/etc/swift/
内容的所有者设置改为 root
用户和 swift
组:
# chown -R root:swift /etc/swift
openstack-swift-proxy
服务:
# systemctl restart openstack-swift-proxy.service
/etc/swift/account.builder /etc/swift/account.ring.gz /etc/swift/container.builder /etc/swift/container.ring.gz /etc/swift/object.builder /etc/swift/object.ring.gz
/etc/swift/
目录中。如果需要,把文件放置到 director 主机:
[root@overcloud-objectstorage-2 swift]# scp *.builder stack@192.1.2.1:~/ [root@overcloud-objectstorage-2 swift]# scp *.ring.gz stack@192.1.2.1:~/
/etc/swift/
中。
/etc/swift/
内容的所有者设置改为 root
用户和 swift
组:
# chown -R root:swift /etc/swift
ObjectStorageCount
的值。在这个示例中,我们把它从 3 减为 2:
parameter_defaults: SwiftRingBuild: false RingBuild: false ObjectStorageCount: 2
remove-object-node.yaml
)来指定并删除旧的 Object 存储节点。在这个示例中,我们删除 overcloud-objectstorage-1
:
parameter_defaults: ObjectStorageRemovalPolicies: [{'resource_list': ['1']}]
$ openstack overcloud deploy --templates -e swift-ring-prevent.yaml -e remove-object-node.yaml ...
9.6. 替换 Ceph 存储节点
第 10 章 升级环境
- 更新 Red Hat OpenStack Platform director 软件包
- 更新 Red Hat OpenStack Platform director 上的 Overcloud 镜像
- 使用 Red Hat OpenStack Platform director 更新 Overcloud stack 和它的软件包
重要
10.1. 升级前需要注意的信息
- Red Hat OpenStack Platform director 的升级还是一个新功能,在对一个正在运行的生产环境进行升级前,需要对所有配置进行全面的测试。红帽已经测试了多种配置组合并作为 director 的标准选项。但是,由于用户配置的多样性,这些标准选项不可能覆盖所有情况。另外,如果标准部署中的配置已被修改过(手动修改或通过配置后的 hook),请在一个非生产环境中对升级进行测试。我们推荐您进行以下操作:
- 在开始进行升级操作前,备份 Undercloud 节点。如需了解与备份相关的信息,请参阅 Back Up and Restore Red Hat OpenStack Platform。
- 在对生产环境进行升级前,在一个测试环境中进行完整的升级测试。
- 如果您对升级的过程有疑问或需要帮助,请在进行升级前联系红帽以获得相关的帮助。
- 本节中介绍的升级过程只覆盖了通过 director 进行的系统定制,如果您在 director 以外对 Overcloud 的功能进行了定制,则需要先禁用这个功能、然后进行 Overcloud 升级,在升级完成后再重新启用这个功能。这意味着,这个定制的功能在整个升级过程中都无法使用。
- Red Hat OpenStack Platform director 8 可以管理 Red Hat OpenStack Platform 7 的特定 Overcloud 版本。相关信息,请参阅以下内容。
表 10.1. Red Hat OpenStack Platform director 8 支持列表
版本Overcloud 更新Overcloud 部署Overcloud 扩展Red Hat OpenStack Platform 77.0.4 以及更新版本7.0.4 以及更新版本7.0.4 以及更新版本Red Hat OpenStack Platform 8所有版本所有版本所有版本 - 在把 Undercloud 升级到 8 之前,用户最少需要把 Undercloud 和 Overcloud 分别更新到 7.3 和 7.4。director 8 不支持 Overcloud 7.0.4 以前的版本。
- 如果使用版本为 8 的 Undercloud 来管理版本为 7 的 Overcloud,使用
/usr/share/openstack-tripleo-heat-templates/kilo/
中的 Heat 模板集合。例如:$ openstack overcloud deploy -templates /usr/share/openstack-tripleo-heat-templates/kilo/ [OTHER_OPTIONS]
在/home/stack/tripleo-overcloud-passwords
文件中把 RabbitMQ 的密码设置为版本 7 的默认值:OVERCLOUD_RABBITMQ_PASSWORD=guest
- 如果使用一个环境文件用于 Satellite 注册(请参阅 第 6.12 节 “注册 Overcloud”),需要在环境文件中更新以下参数:
rhel_reg_repos
- 启用的 Overcloud 软件仓库,包括新的 Red Hat OpenStack Platform 8 软件仓库。rhel_reg_activation_key
- Red Hat OpenStack Platform 8 软件仓库的新激活码。rhel_reg_sat_repo
- 一个新的参数,它定义了包括 Red Hat Satellite 6 管理工具(如katello-agent
)的软件仓库。如果注册到 Red Hat Satellite 6,需要添加这个参数。
10.2. 更新 director 软件包
重要
重要
$ sudo subscription-manager repos --disable=rhel-7-server-openstack-7.0-rpms --disable=rhel-7-server-openstack-7.0-director-rpms $ sudo subscription-manager repos --enable=rhel-7-server-openstack-8-rpms --enable=rhel-7-server-openstack-8-director-rpms
yum
设置为使用最新的软件仓库。使用 yum
来更新 director:
$ sudo yum upgrade
yum update
运行完成后,以下 OpenStack 服务可能会失败。这是一个预期的结果。Undercloud 的升级命令会修正这些服务的配置。
# sudo cp server-cert.pem /etc/pki/ca-trust/source/anchors/ # sudo update-ca-trust extract
openstack underlcoud upgrade
命令来升级 Undercloud 环境。运行以下升级命令:
$ openstack undercloud upgrade
$ sudo systemctl list-units openstack-*
注意
openstack-keystone
服务的显示状态可能是失败,这是因为这个服务作为一个 WSGI 应用通过 httpd
运行。openstack-keystone
服务可以在更新完 director 软件包并运行 openstack undercloud upgrade
后被安全地禁用。
$ source ~/stackrc $ openstack server list $ ironic node-list $ heat stack-list
- 如果 Underclouds 使用 SSL,在升级的过程中,到 VIPs 的访问可能会断开。如果发生了这个问题,在 Undercloud 中重启
keepalived
服务:$ systemctl restart keepalived
- Undercloud 的
admin
用户可能会需要一个没有包括在 Red Hat OpenStack Platform 8 中的一个额外的角色(_member_
)。这个角色对于 Overcloud 的通讯非常重要。创建这个角色,并把它添加到admin
租户中的admin
用户上。$ keystone role-create --name _member_ $ keystone user-role-add --user admin --role _member_ --tenant admin
10.3. 更新 Overcloud 镜像
重要
rhosp-director-images
和 rhosp-director-images-ipa
软件包来获得这些新镜像:
$ sudo yum install rhosp-director-images rhosp-director-images-ipa
stack
用户的主目录的 images
目录中(/home/stack/images
)删除存在的镜像,然后拷入新的镜像:
$ rm -rf ~/images/* $ cp /usr/share/rhosp-director-images/overcloud-full-latest-8.0.tar ~/images/. $ cp /usr/share/rhosp-director-images/ironic-python-agent-latest-8.0.tar ~/images/.
$ cd ~/images $ for tarfile in *.tar; do tar -xf $tarfile; done
$ openstack overcloud image upload --update-existing --image-path ~/images/. $ openstack baremetal configure boot
$ openstack image list $ ls -l /httpboot
10.4. 升级 Overcloud
重要
重要
openstack overcloud deploy
命令来使升级过程以阶段的形式进行。在每次运行这个命令时,会包括不同的升级环境文件,以及已存在的环境文件。这些新的升级环境文件是:
major-upgrade-pacemaker-init.yaml
- 提供对升级的初始化功能。这包括在 Overcloud 的每个节点上更新 Red Hat OpenStack Platform 软件存储库,并为特定节点提供特殊的升级脚本。major-upgrade-pacemaker.yaml
- 对 Controller 节点进行升级。major-upgrade-pacemaker-converge.yaml
- Overcloud 升级的结束工作。
upgrade-non-controller.sh
脚本。这个脚本会在一个节点上更新软件包。
- 首先,从 Undercloud 中运行
openstack overcloud deploy
,并包括major-upgrade-pacemaker-init.yaml
环境文件。确保还包括了与您的环境相关的所有定制环境文件,如网络分离和存储。重要
如果 Red Hat OpenStack Platform 7 使用定制的 NIC 模板,把ManagementSubnetIp
参数添加到您的 NIC 模板的parameters
部分。例如:parameters: ManagementIpSubnet: # Only populated when including environments/network-management.yaml default: '' description: IP address/subnet on the management network type: string
以下是一个相关的openstack overcloud deploy
命令示例:$ openstack overcloud deploy --templates \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \ -e network_env.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-pacemaker-init.yaml
等待 Overcloud 使用新的环境文件配置进行更新已完成。 - director 包括了升级一个非 Controller 节点的脚本。首先,升级每个 Swift 节点:
$ nova list $ upgrade-non-controller.sh --upgrade [swift-uuid]
- 升级 Controller 节点。这涉及到包括另外一个环境文件(
major-upgrade-pacemaker.yaml
),它提供了对运行高可用性工具程序的 Controller 节点的升级。重新运行openstack overcloud deploy
来使用这个环境文件。确保还包括了与您的环境相关的所有定制环境文件,如网络分离和存储。$ openstack overcloud deploy --templates \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \ -e network_env.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-pacemaker.yaml
等待 Overcloud 使用新的环境文件配置进行更新已完成。重要
这一步会在 Controller 升级过程中禁用 Neutron 服务器和 L3 Agent。这意味着,在执行这一步的过程中,浮动 IP 地址无效。重要
如果 Overcloud 栈在这一步中出现问题,登录到一个 Controller 节点上,运行sudo pcs cluster start
,然后在 director 上重新运行openstack overcloud deploy
。 - 升级每个 Compute 节点。升级 Compute 节点也会使用
upgrade-non-controller.sh
脚本。但是,为了避免下线时间,我们建议禁止 Compute 节点运行新的虚拟机,并把已存在的虚拟机迁移到其它 Compute 节点上。如需更详细的信息,请参阅 第 8.9 节 “从一个 Overcloud Compute 节点中迁移虚拟机”。迁移完成后,运行升级命令:$ nova list $ upgrade-non-controller.sh --upgrade [compute-uuid]
升级完成后,使用以下命令重新启用 Compute 节点:$ nova list $ nova service-enable [hostname] nova-compute
- 升级每个 Ceph Storage 节点:
$ nova list $ upgrade-non-controller.sh --upgrade [ceph-uuid]
- 运行最终的升级命令。这需要在
openstack overcloud deploy
命令中包括另外一个环境文件(major-upgrade-pacemaker-converge.yaml
)。确保还包括了与您的环境相关的所有定制环境文件,如网络分离和存储。例如:$ openstack overcloud deploy --templates \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \ -e network_env.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-pacemaker-converge.yaml
等待 Overcloud 使用新的环境文件配置进行更新已完成。
- Compute 节点可能会报告一个带有
neutron-openvswitch-agent
的错误。如果发生了这种情况,登录到每个 Compute 节点并重启服务。例如:$ sudo systemctl restart neutron-openvswitch-agent
- 更新过程不会在 Overcloud 中自动重启任何节点。如果需要,在更新命令完成后手工进行重启。请确认单独重新引导了基于机器的节点(如 Ceph Storage 节点和 Controller 节点),并等待节点重新加入到集群中。对于 Ceph Storage 节点,使用
ceph health
进行检查,确保集群的状态为HEALTH OK
。对于 Controller 节点,使用pcs resource
进行检查,确保所有资源已为每个节点运行。 - 在某些情况下,重启 Controller 节点后,
Corosync
可能会在 IPv6 环境中启动失败。这是因为,Corosync 会在 Controller 节点配置静态 IPv6 地址前启动。如果出现这个问题,在 Controller 节点上手工重启 Corosync:$ sudo systemctl restart corosync
- 如果您在 Controller 节点上配置了隔离(fencing)功能,更新的过程可能会禁用它。当更新完成后,在一个 Controller 节点上重新启用隔离功能:
$ sudo pcs property set stonith-enabled=true
- 在下一次更新或扩展 Overcloud 栈时(例如,运行
openstack overcloud deploy
命令),您需要重新设置在 Overcloud 中触发软件包更新的标识符。在一个环境文件中添加一个空的UpdateIdentifier
参数,并在运行openstack overcloud deploy
命令时包括它。以下是这样一个环境文件的示例:parameter_defaults: UpdateIdentifier:
第 11 章 对 director 进行故障排除
/var/log
目录包括了许多常见 OpenStack Platform 组件的日志文件,以及标准 Red Hat Enterprise Linux 应用的日志文件。journald
服务为多个组件提供日志功能。ironic 使用两个单元:openstack-ironic-api
和openstack-ironic-conductor
。同样的,ironic-inspector
也使用两个单元:openstack-ironic-inspector
和openstack-ironic-inspector-dnsmasq
。以下是使用这个服务的示例:$ sudo journalctl -u openstack-ironic-inspector -u openstack-ironic-inspector-dnsmasq
ironic-inspector
还把 ramdisk 的日志保存在/var/log/ironic-inspector/ramdisk/
中(gz 压缩的 tar 文件)。它们的文件名中包括日期、时间和节点的 IPMI 地址。使用这些日志来对相关的服务进行诊断。
11.1. 对节点注册进行故障排除
ironic
来解决相关的问题。以下是几个示例:
过程 11.1. 修正一个不正确的 MAC 地址
- 找到分配的端口 UUID:
$ ironic node-port-list [NODE UUID]
- 更新 MAC 地址:
$ ironic port-update [PORT UUID] replace address=[NEW MAC]
过程 11.2. 修正一个不正确的 IPMI 地址
- 运行以下命令:
$ ironic node-update [NODE UUID] replace driver_info/ipmi_address=[NEW IPMI ADDRESS]
11.2. 对硬件內省的故障排除
ironic-inspector
)会默认在一个小时后出现超时。在一些时候,这意味着发现 ramdisk 有问题,但通常情况下是因为不正确的环境配置,特别是 BIOS 引导设置。
启动节点內省操作错误
baremetal introspection
命令,它是一个安全调用 Ironic 服务的命令。但是,如果直接使用 ironic-inspector
,它可能在发现状态是 AVAILABLE 的节点过程中出现问题。在进行发现操作前,把节点的状态改为 MANAGEABLE:
$ ironic node-set-provision-state [NODE UUID] manage
$ ironic node-set-provision-state [NODE UUID] provide
停止发现过程
ironic-inspector
没有提供一个直接停止发现过程的方法。我们推荐的方法是等待发现过程的超时发生。如果需要,可以修改 /etc/ironic-inspector/inspector.conf
中的 timeout
设置来设定一个新的超时时间(以分钟为单位)。
过程 11.3. 停止发现过程
- 把每个节点的电源状态改为 off:
$ ironic node-set-power-state [NODE UUID] off
- 删除
ironic-inspector
的缓存数据并重启它:$ rm /var/lib/ironic-inspector/inspector.sqlite $ sudo systemctl restart openstack-ironic-inspector
11.3. 对创建 Overcloud 进行故障排除
- 编配(heat 和 nova 服务)
- 裸机部署(ironic 服务)
- 实施后的配置(Puppet)
11.3.1. 编配
$ heat stack-list +-----------------------+------------+--------------------+----------------------+ | id | stack_name | stack_status | creation_time | +-----------------------+------------+--------------------+----------------------+ | 7e88af95-535c-4a55... | overcloud | CREATE_FAILED | 2015-04-06T17:57:16Z | +-----------------------+------------+--------------------+----------------------+
openstack overcloud deploy
后的错误信息。
11.3.2. 裸机部署
ironic
查看所有注册的节点和它们当前的状态:
$ ironic node-list +----------+------+---------------+-------------+-----------------+-------------+ | UUID | Name | Instance UUID | Power State | Provision State | Maintenance | +----------+------+---------------+-------------+-----------------+-------------+ | f1e261...| None | None | power off | available | False | | f0b8c1...| None | None | power off | available | False | +----------+------+---------------+-------------+-----------------+-------------+
- 在结果列表中检查 Provision State 和 Maintenance 栏中的数据。检查以下情况:
- 表为空,或比期望的节点要少
- Maintenance 被设置为 True
- Provision State 被设置为
manageable
这通常意味着问题是由注册或发现过程造成的。例如,如果 Maintenance 被自动设置为 True,这通常是因为节点使用了错误的电源管理凭证。 - 如果 Provision State 的值是
available
,这意味着问题发生在裸机部署开始前。 - 如果 Provision State 的值是
active
,Power State 的值是power on
,这意味着裸机部署已成功完成,所出现的问题发生在实施后的配置阶段。 - 如果一个节点的 Provision State 值是
wait call-back
,这意味着对这个节点的裸机部署还没有完成。等待这个状态改变;或连接到出现问题的节点的虚拟控制台上检查相关的输出。 - 如果 Provision State 的值是
error
或deploy failed
,则意味着对这个节点的裸机部署失败。检查裸机节点的详情:$ ironic node-show [NODE UUID]
查看包括错误描述信息的last_error
项。如果错误信息不明确,您可以查看相应的日志:$ sudo journalctl -u openstack-ironic-conductor -u openstack-ironic-api
- 如果您看到
wait timeout error
信息,节点的 Power State 值是power on
,连接到出现问题的节点的虚拟控制台上检查相关的输出。
11.3.3. 实施后的配置
过程 11.4. 诊断实施后的配置问题
- 列出 Overcloud 栈中的所有资源来找出哪个出现了问题:
$ heat resource-list overcloud
这会显示一个包括所有资源以及它们的状态的列表。查看带有CREATE_FAILED
的资源。 - 显示出问题的资源:
$ heat resource-show overcloud [FAILED RESOURCE]
查看resource_status_reason
项中的内容来帮助您进行诊断。 - 使用
nova
命令查看 Overcloud 节点的 IP 地址。$ nova list
以heat-admin
用户身份登录到一个实施的节点上。例如,栈资源列表显示一个 Controller 节点出现问题,您可以登录到那个 Controller 节点。heat-admin
用户有 sudo 访问权限。$ ssh heat-admin@192.0.2.14
- 检查
os-collect-config
日志找出可能造成故障的原因。$ sudo journalctl -u os-collect-config
- 在某些情况下,nova 的整个节点实施过程都失败。在这种情况下,一个 Overcloud 角色类型的
OS::Heat::ResourceGroup
会出错。使用nova
来查看问题。$ nova list $ nova show [SERVER ID]
多数常见错误会显示No valid host was found
错误信息,请参阅 第 11.6 节 “对 "No Valid Host Found" 错误进行故障排除” 来获得更多与排除这类错误相关的信息。在其它情况下,查看以下日志文件来进行进一步的故障排除:/var/log/nova/*
/var/log/heat/*
/var/log/ironic/*
- 使用 SOS 工具包来收集系统硬件和配置的信息。这些信息可被用于进行故障诊断和故障排除。技术支持和开发人员也可以通过 SOS 获得有用的信息。SOS 在 Undercloud 和 Overcloud 中都有用。运行以下命令安装
sos
软件包:$ sudo yum install sos
产生一个报告$ sudo sosreport --all-logs
11.4. 对升级过程中出现的故障进行排除
11.4.1. 升级 Undercloud
openstack undercloud upgrade
)运行失败时,按照以下建议查找造成问题的原因:
openstack undercloud upgrade
命令运行时会输出一个进程日志信息。当升级过程出现故障时,这个命令会在出现故障的地方停止。使用这个信息来帮助定位造成升级故障的原因。openstack undercloud upgrade
命令运行 Puppet 来配置 Undercloud 服务。这会在以下目录中产生有用的 Puppet 报告信息:/var/lib/puppet/state/last_run_report.yaml
- 为 Undercloud 产生的最新的 Puppet 报告。这个文件会包括失败的 Puppet 操作。/var/lib/puppet/state/last_run_summary.yaml
-last_run_report.yaml
文件的概述。/var/lib/puppet/reports
- Undercloud 的所有 Puppet 报告。
使用这些信息可以帮助找出造成升级故障的原因。- 检查失败的服务:
$ sudo systemctl -t service
如果有失败的服务,检查它们的相关日志。例如,如果openstack-ironic-api
运行失败,使用以下命令检查这个服务的日志:$ sudo journalctl -xe -u openstack-ironic-api $ sudo tail -n 50 /var/log/ironic/ironic-api.log
$ openstack undercloud upgrade
11.4.2. Overcloud 升级
- 检查 Heat 栈信息,找出带有
UPDATE_FAILED
状态的栈。运行以下命令:$ heat stack-list --show-nested | awk -F "|" '{ print $3,$4 }' | grep "UPDATE_FAILED" | column -t
检查失败的栈和它的模板来找出栈失败的原因:$ heat stack-show overcloud-Controller-qyoy54dyhrll-1-gtwy5bgta3np $ heat template-show overcloud-Controller-qyoy54dyhrll-1-gtwy5bgta3np
- 使用 第 11.3.3 节 “实施后的配置” 中提供的建议找出 Overcloud 后配置的问题,特别是运行失败的 Puppet。
- 检查 Pacemaker 是否在所有 Controller 节点上正确运行。如果需要,登录到一个 Controller 节点并重启 Controller 集群:
$ sudo pcs cluster start
如需了解更多与诊断 Pacemaker 问题相关的信息,请参阅 第 11.7.2 节 “Controller 服务失败”。
openstack overcloud deploy
命令。以下是升级过程中的第一个 openstack overcloud deploy
命令,它包括 major-upgrade-pacemaker-init.yaml
:
$ openstack overcloud deploy --templates \
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \
-e network_env.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-pacemaker-init.yaml
openstack overcloud deploy
会重试 Overcloud 栈的更新。
11.5. 排除 Provisioning Network 中出现的 IP 地址冲突的问题
过程 11.5. 找到被使用的 IP 地址
- 安装
nmap
:# yum install nmap
- 使用
nmap
命令扫描活跃的 IP 地址范围。这个示例会扫描192.0.2.0/24
这个范围,使用 Provisioning 网络的 IP 子网值(CIDR 格式)替换它:# nmap -sn 192.0.2.0/24
- 检查
nmap
扫描的结果输出:例如,您可以看到 Undercloud 的 IP 地址,以及在这个子网中的任何其它主机。如果这些活跃的 IP 地址和undercloud.conf
中指定的 IP 地址范围有冲突,则需要在内省或部署Overcloud 节点前修改 IP 地址范围或释放一些 IP 地址。# nmap -sn 192.0.2.0/24 Starting Nmap 6.40 ( http://nmap.org ) at 2015-10-02 15:14 EDT Nmap scan report for 192.0.2.1 Host is up (0.00057s latency). Nmap scan report for 192.0.2.2 Host is up (0.00048s latency). Nmap scan report for 192.0.2.3 Host is up (0.00045s latency). Nmap scan report for 192.0.2.5 Host is up (0.00040s latency). Nmap scan report for 192.0.2.9 Host is up (0.00019s latency). Nmap done: 256 IP addresses (5 hosts up) scanned in 2.45 seconds
11.6. 对 "No Valid Host Found" 错误进行故障排除
/var/log/nova/nova-conductor.log
包括了以下错误:
NoValidHost: No valid host was found. There are not enough hosts available.
- 确保內省可以成功完成。否则,检查每个节点都包括了需要的 ironic 节点属性。对于每个节点:
$ ironic node-show [NODE UUID]
检查properties
JSON 项中的cpus
、cpu_arch
、memory_mb
和local_gb
都有有效的值。 - 根据 ironic 节点属性检查使用的 nova flavor 没有超过特定数量:
$ nova flavor-show [FLAVOR NAME]
- 根据
ironic node-list
检查有足够状态为available
的节点。节点的状态为manageable
通常意味着內省操作失败。 - 使用
ironic node-list
检查没有处于维护模式的节点。当一个节点被自动变为维护模式时,通常意味着不正确的电源管理凭证。检查它们并删除维护模式:$ ironic node-set-maintenance [NODE UUID] off
- 如果您使用 AHC 工具程序来自动标记节点,请根据每个 flavor 和配置集来检查是否有足够的相关节点。检查
ironic node-show
输出中的properties
项的capabilities
值。例如,一个标记为 Compute 角色的节点应该包括profile:compute
。 - 在进行完內省操作后,从 ironic 为 nova 生成节点信息可能会需要一些时间来完成。director 的工具程序通常会把这个时间考虑进去。但是,如果您手工进行了一些操作,节点可能会在一个短时间内对 nova 无效。使用以下命令检查您的系统中的总资源:
$ nova hypervisor-stats
11.7. 在创建后对 Overcloud 进行故障排除
11.7.1. Overcloud 栈的修改
overcloud
栈时可能会出现问题。对栈进行修改可能包括:
- 扩展节点
- 删除节点
- 替换节点
overcloud
栈时需要遵循以下的一些建议。
Overcloud
heat 栈时出现的问题。特别是,使用以下命令帮助查找有问题的资源:
heat stack-list --show-nested
- 列出所有栈。
--show-nested
会显示所有子栈以及它们的父栈。这可以帮助判断栈在什么地方出现问题。 heat resource-list overcloud
- 列出
overcloud
栈中的所有资源,以及它们当前的状态。这可以帮助找出哪些资源造成了栈出现问题。您可以通过这些失败的资源追踪到 heat 模板集合和 Puppet 模块中的相关参数和配置。 heat event-list overcloud
- 以发生的时间顺序列出与
overcloud
栈相关的所有事件。这包括初始化事件、操作完成事件以及栈中所有失败的资源。这些信息可以帮助找出造成资源失败的原因。
11.7.2. Controller 服务失败
pcs
)是一个用来管理 Pacemaker 集群的工具程序。在集群的 Controller 节点上运行这个命令来执行配置和监控操作。在一个高可用性集群中,可以使用以下命令帮助对 Overcloud 服务进行故障排除:
pcs status
- 当前整个集群的状态概况信息,包括启用的资源、失败的资源和在线节点信息。
pcs resource show
- 显示资源列表,以及与它们相关的节点。
pcs resource disable [resource]
- 停止一个特定的资源。
pcs resource enable [resource]
- 启动一个特定的资源。
pcs cluster standby [node]
- 把节点设置为待机(standby)模式,使这个节点在集群中不再可用。这可以被用来在不影响集群运行的情况下对特定节点进行维护操作。
pcs cluster unstandby [node]
- 取消一个节点的待机模式。这个节点将可以重新在集群中使用。
/var/log/
中查看相关的组件日志文件。
11.7.3. Compute 服务失败
- 使用
systemd
的以下功能查看服务的状态:$ sudo systemctl status openstack-nova-compute.service
同样,使用以下命令查看服务的systemd
日志:$ sudo journalctl -u openstack-nova-compute.service
- Compute 节点的主日志文件是
/var/log/nova/nova-compute.log
。如果到 Compute 节点的通讯出现问题,从这个文件开始进行故障排除会是一个好的方法。 - 如果需要在 Compute 节点上进行维护工作,把主机上存在的实例迁移到另外一个可以正常工作的 Compute 节点上,然后禁用需要进行维护的节点。如需了解更多节点迁移的信息,请参阅 第 8.9 节 “从一个 Overcloud Compute 节点中迁移虚拟机”。
11.7.4. Ceph Storage 服务故障
11.8. 对 Undercloud 进行性能微调
- OpenStack Authentication 服务(
keystone
)使用一个基于令牌(token)的系统控制对其它 OpenStack 服务的访问。在运行了一定时间后,数据库中会积累大量不再使用的令牌。我们推荐创建一个 cronjob 来定期删除数据库中的令牌表。例如,在每天早上 4 点删除令牌表:0 04 * * * /bin/keystone-manage token_flush
- 在每次运行
openstack overcloud deploy
命令时,Heat 会把所有模板文件复制到它的数据库中的raw_template
表中。raw_template
表会包括过去所有的模板,并随着时间的推移变得非常大。您可以创建一个每日运行的 cronjob 来删除raw_templates
表中那些不再使用的、存在时间超过一天的模板:0 04 * * * /bin/heat-manage purge_deleted -g days 1
- 在一些时候,
openstack-heat-engine
和openstack-heat-api
服务可能会消耗大量资源。如果这个情况发生了,在/etc/heat/heat.conf
中设置max_resources_per_stack=-1
,然后重启 heat 服务:$ sudo systemctl restart openstack-heat-engine openstack-heat-api
- 在一些时候,director 可能没有足够的资源来执行并行的节点设置(默认是可以同时并行设置 10 个节点)。为了减少并行节点的数量,把
/etc/nova/nova.conf
中的max_concurrent_builds
参数设置为一个小于 10 的值,然后重启 nova 服务:$ sudo systemctl restart openstack-nova-api openstack-nova-scheduler
- 编辑
/etc/my.cnf.d/server.cnf
文件。可以用来微调的值包括:- max_connections
- 可以同时连接到数据库的连接数量。推荐的值是 4096。
- innodb_additional_mem_pool_size
- 数据库用来存储数据字典和其它内部数据结构的内存池的大小(以字节为单位)。它的默认值是 8M,对于 Undercloud,理想的值是 20M。
- innodb_buffer_pool_size
- 缓冲池(数据库用来缓存表和索引数据的内存区)的大小(以字节为单位)。它的默认值是 128M,对于 Undercloud,理想的值是 1000M。
- innodb_flush_log_at_trx_commit
- commit 操作对 ACID 原则的遵守,与高性能间的平衡控制。把它设置为 1。
- innodb_lock_wait_timeout
- 数据库交易在放弃等待行锁定前等待的时间长度(以秒为单位)。把它设置为 50。
- innodb_max_purge_lag
- 在 purge 操作滞后时,如何延迟 INSERT、UPDATE 和 DELETE 操作。把它设为 10000。
- innodb_thread_concurrency
- 并行操作系统线程的限制。理想情况下,为每个 CPU 和磁盘资源最少提供 2 个线程。例如,具有一个 4 核 CPU 和一个磁盘,则提供 10 个线程。
- 确保 heat 有足够的 worker 来执行 Overcloud 创建。通常情况下,这取决于 Undercloud 有多少个 CPU。为了手工设置 worker 的数量,编辑
/etc/heat/heat.conf
文件,把num_engine_workers
参数的值设置为所需的 worker 的数量(理想值是 4),然后重启 heat 引擎:$ sudo systemctl restart openstack-heat-engine
11.9. Undercloud 和 Overcloud 的重要日志
表 11.1. Undercloud 和 Overcloud 的重要日志
信息
|
Undercloud 或 Overcloud
|
日志位置
|
---|---|---|
一般的 director 服务
|
Undercloud
| /var/log/nova/*
/var/log/heat/*
/var/log/ironic/*
|
Introspection
|
Undercloud
| /var/log/ironic/*
/var/log/ironic-inspector/*
|
Provisioning
|
Undercloud
| /var/log/ironic/*
|
Cloud-Init 日志
|
Overcloud
| /var/log/cloud-init.log
|
Overcloud 配置(最后一次 Puppet 运行的概述)
|
Overcloud
| /var/lib/puppet/state/last_run_summary.yaml
|
Overcloud 配置(最后一次 Puppet 运行的报告)
|
Overcloud
| /var/lib/puppet/state/last_run_report.yaml
|
Overcloud 配置(所有 Puppet 报告)
|
Overcloud
| /var/lib/puppet/reports/overcloud-*/*
|
一般的 Overcloud 服务
|
Overcloud
| /var/log/ceilometer/*
/var/log/ceph/*
/var/log/cinder/*
/var/log/glance/*
/var/log/heat/*
/var/log/horizon/*
/var/log/httpd/*
/var/log/keystone/*
/var/log/libvirt/*
/var/log/neutron/*
/var/log/nova/*
/var/log/openvswitch/*
/var/log/rabbitmq/*
/var/log/redis/*
/var/log/swift/*
|
高可用性日志
|
Overcloud
| /var/log/pacemaker.log
|
附录 A. SSL/TLS 证书配置
[stack@host1 ~]$ cp /etc/pki/tls/openssl.cnf .
openssl.cnf
文件,把 SSL 参数设置为被 director 使用。一个包括相关参数的示例如下:
[req] distinguished_name = req_distinguished_name req_extensions = v3_req [req_distinguished_name] countryName = Country Name (2 letter code) countryName_default = AU stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = Queensland localityName = Locality Name (eg, city) localityName_default = Brisbane organizationalUnitName = Organizational Unit Name (eg, section) organizationalUnitName_default = Red Hat commonName = Common Name commonName_default = 192.168.0.1 commonName_max = 64 [ v3_req ] # Extensions to add to a certificate request basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment subjectAltName = @alt_names [alt_names] IP.1 = 192.168.0.1 DNS.1 = instack.localdomain DNS.2 = vip.localdomain
重要
commonName_default
设置为 Public API 的 IP 地址,或 FQDN:
- 对于 Undercloud,使用
undercloud.conf
中的undercloud_public_vip
参数。如果这个 IP 地址使用了一个 FQDN,则使用这个 FQDN。
- 对于 Overcloud,使用 Public API 的 IP 地址(您的网络分离环境文件中的
ExternalAllocationPools
参数的第一个地址)。如果这个 IP 地址使用了一个 FQDN,则使用这个 FQDN。
alt_names
部分包括相同的 Public API IP 地址作为 IP 项。如果还使用 DNS,在相同的部分包括服务器的主机名作为 DNS 项。如需了解更多与 openssl.cnf
相关的信息,请运行 man openssl.cnf
。
$ openssl genrsa -out server-key.pem 2048 $ openssl req -new -x509 -key server-key.pem -out server-cert.pem -days 3650 -config ~/openssl.cnf
对于 Undercloud:
$ cat server-cert.pem server-key.pem > undercloud.pem
重要
openssl req
命令会要求输入证书的一些详细信息,包括 Common Name。把 Common Name 设置为 Public API 的 IP 地址。openssl.cnf
文件会使用这个 IP 地址作为默认值。
undercloud.pem
文件来和 undercloud_service_certificate
选项一起使用。另外,这个文件还需要一个特殊的 SELinux context,从而使 HAProxy 工具可以读取它。请参照以下示例:
$ sudo mkdir /etc/pki/instack-certs $ sudo cp ~/undercloud.pem /etc/pki/instack-certs/. $ sudo semanage fcontext -a -t etc_t "/etc/pki/instack-certs(/.*)?" $ sudo restorecon -R /etc/pki/instack-certs
$ sudo cp server-cert.pem /etc/pki/ca-trust/source/anchors/ $ sudo update-ca-trust extract
对于 Overcloud:
enable-tls.yaml
文件一起使用证书。
附录 B. 电源管理驱动
B.1. Dell Remote Access Controller (DRAC)
- pm_type
- 把这个选项设置为
pxe_drac
。 - pm_user, pm_password
- DRAC 的用户名和密码。
- pm_addr
- DRAC 主机的 IP 地址。
B.2. Integrated Lights-Out (iLO)
- pm_type
- 把这个选项设置为
pxe_ilo
。 - pm_user, pm_password
- iLO 的用户名和密码。
- pm_addr
- iLO 接口的 IP 地址。
额外注记
- 编辑
/etc/ironic/ironic.conf
文件,把pxe_ilo
加入到enabled_drivers
选项来启用这个驱动。 - director 需要为 iLo 安装一组额外的工具程序。安装
python-proliantutils
软件包并重启openstack-ironic-conductor
服务:$ sudo yum install python-proliantutils $ sudo systemctl restart openstack-ironic-conductor.service
- 为了成功进行內省,HP 节点必须是 2015 的固件版本。director 已经经过测试可以使用固件版本为 1.85(May 13 2015)的节点。
B.3. iBoot
- pm_type
- 把这个选项设置为
pxe_iboot
。 - pm_user, pm_password
- iBoot 的用户名和密码。
- pm_addr
- iBoot 接口的 IP 地址。
- pm_relay_id(可选)
- iBoot 对于主机的中继 ID。默认值是 1。
- pm_port(可选)
- iBoot 端口。默认值是 9100。
额外注记
- 编辑
/etc/ironic/ironic.conf
文件,把pxe_iboot
加入到enabled_drivers
选项来启用这个驱动。
B.4. Cisco Unified Computing System(UCS)
- pm_type
- 把这个选项设置为
pxe_ucs
。 - pm_user, pm_password
- UCS 的用户名和密码。
- pm_addr
- UCS 接口的 IP 地址。
- pm_service_profile
- 使用的 UCS 服务配置集。通常的格式是
org-root/ls-[service_profile_name]
。例如:"pm_service_profile": "org-root/ls-Nova-1"
额外注记
- 编辑
/etc/ironic/ironic.conf
文件,把pxe_ucs
添加到enabled_drivers
选项来启用这个驱动。 - director 还需要为 UCS 安装一组额外的工具程序。安装
python-UcsSdk
软件包并重启openstack-ironic-conductor
服务:$ sudo yum install python-UcsSdk $ sudo systemctl restart openstack-ironic-conductor.service
B.5. Fujitsu Integrated Remote Management Controller (iRMC)
重要
- pm_type
- 把这个选项设置为
pxe_irmc
。 - pm_user, pm_password
- iRMC 接口的用户名和密码。
- pm_addr
- iRMC 接口的 IP 地址。
- pm_port(可选)
- iRMC 操作使用的端口。默认值是 443。
- pm_auth_method(可选)
- iRMC 操作的验证方法。使用
basic
或digest
。默认值是basic
- pm_client_timeout(可选)
- iRMC 操作的超时值(以秒为单位)。默认值是 60 秒。
- pm_sensor_method(可选)
- 获得感应器数据的方法。使用
ipmitool
或scci
。默认值是ipmitool
。
额外注记
- 编辑
/etc/ironic/ironic.conf
文件,把pxe_irmc
添加到enabled_drivers
选项来启用这个驱动。 - 如果使用 SCCI 作为获得感应器数据的方法,则 director 还需要安装一组额外的工具程序。安装
python-scciclient
软件包并重启openstack-ironic-conductor
服务:$ yum install python-scciclient $ sudo systemctl restart openstack-ironic-conductor.service
B.6. SSH 和 Virsh
重要
- pm_type
- 把这个选项设置为
pxe_ssh
。 - pm_user, pm_password
- SSH 的用户名和 SSH 私人密钥的内容。私人密钥的内容必须在一行中(其中的换行需要以
\n
替代)。例如:-----BEGIN RSA PRIVATE KEY-----\nMIIEogIBAAKCAQEA .... kk+WXt9Y=\n-----END RSA PRIVATE KEY-----
把 SSH 公共密钥添加到 libvirt 服务器的authorized_keys
集合中。 - pm_addr
- virsh 主机的 IP 地址。
额外注记
- 运行 libvirt 的服务器需要一个带有在
pm_password
属性中设置的公共密钥的 SSH 密钥对。 - 确保所选的
pm_user
可以完全访问 libvirt 环境。
B.7. Fake PXE 驱动
重要
- pm_type
- 把这个选项设置为
fake_pxe
。
额外注记
- 这个驱动不使用任何验证信息,因为它不控制电源管理。
- 编辑
/etc/ironic/ironic.conf
文件,把fake_pxe
添加到enabled_drivers
选项来启用这个驱动。 - 在节点上执行内省(introspection)操作时,运行完
openstack baremetal introspection bulk start
命令后需要手工启动节点。 - 在进行 Overcloud 部署时,使用
ironic node-list
命令检查节点的状态。当节点的状态由deploying
变为deploy wait-callback
后,手工启动这个节点。
附录 C. 自动配置集标记
rules.json
):
[ { "description": "Fail introspection for unexpected nodes", "conditions": [ {"op": "lt", "field": "memory_mb", "value": 4096} ], "actions": [ {"action": "fail", "message": "Memory too low, expected at least 4 GiB"} ] }, { "description": "Assign profile for object storage", "conditions": [ {"op": "ge", "field": "local_gb", "value": 1024} ], "actions": [ {"action": "set-capability", "name": "profile", "value": "swift-storage"} ] }, { "description": "Assign possible profiles for compute and controller", "conditions": [ {"op": "lt", "field": "local_gb", "value": 1024}, {"op": "ge", "field": "local_gb", "value": 40} ], "actions": [ {"action": "set-capability", "name": "compute_profile", "value": "1"}, {"action": "set-capability", "name": "control_profile", "value": "1"}, {"action": "set-capability", "name": "profile", "value": null} ] } ]
- 如果内存低于 4096 MiB,内省失败。通过使用这个规则可以排除那些不应该成为您的云环境组成部分的节点。
- 硬盘容量大于或等于 1 TiB 的节点会被无条件地分配 swift-storage 配置集。
- 硬盘容量在 1 TiB 和 40 GiB 间的节点可以作为 Compute 节点或 Controller 节点。我们分配了两个配置集(
compute_profile
和control_profile
)以便openstack overcloud profiles match
命令可以做最终的决定。另外,在这种情况下,还需要删除存在的配置集(如果不删除,存在的配置集会被优先使用)。
注意
配置集
总会覆盖存在的值。但是,[PROFILE]_profile
是一个例外,已存在配置集的节点会忽略它。
$ openstack baremetal introspection rule import /path/to/rules.json
$ openstack baremetal introspection bulk start
$ openstack overcloud profiles list
$ openstack baremetal introspection rule purge
附录 D. 网络接口参数
表 D.1. 接口选项
选项
|
默认值
|
描述
|
---|---|---|
name
| |
接口名称
|
use_dhcp
|
False
|
使用 DHCP 分配 IP 地址
|
use_dhcpv6
|
False
|
使用 DHCP 分配 v6 IP 地址
|
addresses
| |
分配给接口的 IP 地址序列
|
routes
| |
分配给接口的路由序列
|
mtu
|
1500
|
连接的最大传输单元(maximum transmission unit,简称 MTU)
|
primary
|
False
|
作为主接口的接口
|
defroute
|
True
|
使用这个接口作为默认路由
|
persist_mapping
|
False
|
写入设备别名设置,而不是写入系统名
|
dhclient_args
|
无
|
传递给 DHCP 客户端的参数
|
dns_servers
|
无
|
为这个接口使用的 DNS 服务器列表
|
表 D.2. VLAN 选项
选项
|
默认值
|
描述
|
---|---|---|
vlan_id
| |
VLAN ID
|
device
| |
附加 VLAN 的 VLAN 父设备。例如,使用这个参数把 VLAN 附加到一个绑定的接口设备。
|
use_dhcp
|
False
|
使用 DHCP 分配 IP 地址
|
use_dhcpv6
|
False
|
使用 DHCP 分配 v6 IP 地址
|
addresses
| |
分配给 VLAN 的 IP 地址序列
|
routes
| |
分配给 VLAN 的路由序列
|
mtu
|
1500
|
连接的最大传输单元(maximum transmission unit,简称 MTU)
|
primary
|
False
|
作为主接口的 VLAN
|
defroute
|
True
|
使用这个接口作为默认路由
|
persist_mapping
|
False
|
写入设备别名设置,而不是写入系统名
|
dhclient_args
|
无
|
传递给 DHCP 客户端的参数
|
dns_servers
|
无
|
为 VLAN 使用的 DNS 服务器列表
|
表 D.3. OVS 绑定选项
选项
|
默认值
|
描述
|
---|---|---|
name
| |
绑定名
|
use_dhcp
|
False
|
使用 DHCP 分配 IP 地址
|
use_dhcpv6
|
False
|
使用 DHCP 分配 v6 IP 地址
|
addresses
| |
分配给绑定的 IP 地址序列
|
routes
| |
分配给绑定的路由序列
|
mtu
|
1500
|
连接的最大传输单元(maximum transmission unit,简称 MTU)
|
primary
|
False
|
作为主接口的接口
|
members
| |
在绑定中使用的接口项序列
|
ovs_options
| |
在创建绑定时传递给 OVS 的一组选项
|
ovs_extra
| |
在绑定的网络配置文件中设置为 OVS_EXTRA 参数的一组选项
|
defroute
|
True
|
使用这个接口作为默认路由
|
persist_mapping
|
False
|
写入设备别名设置,而不是写入系统名
|
dhclient_args
|
无
|
传递给 DHCP 客户端的参数
|
dns_servers
|
无
|
为绑定使用的 DNS 服务器列表
|
表 D.4. OVS 网桥选项
选项
|
默认值
|
描述
|
---|---|---|
name
| |
网桥名
|
use_dhcp
|
False
|
使用 DHCP 分配 IP 地址
|
use_dhcpv6
|
False
|
使用 DHCP 分配 v6 IP 地址
|
addresses
| |
分配给网桥的 IP 地址序列
|
routes
| |
分配给网桥的路由序列
|
mtu
|
1500
|
连接的最大传输单元(maximum transmission unit,简称 MTU)
|
members
| |
在网桥中使用的一组接口、VLAN 和绑定项序列
|
ovs_options
| |
在创建网桥时传递给 OVS 的一组选项
|
ovs_extra
| |
在网桥的网络配置文件中设置为 OVS_EXTRA 参数的一组选项
|
defroute
|
True
|
使用这个接口作为默认路由
|
persist_mapping
|
False
|
写入设备别名设置,而不是写入系统名
|
dhclient_args
|
无
|
传递给 DHCP 客户端的参数
|
dns_servers
|
无
|
为网桥使用的 DNS 服务器列表
|
表 D.5. Linux 绑定选项
选项
|
默认值
|
描述
|
---|---|---|
name
| |
绑定名
|
use_dhcp
|
False
|
使用 DHCP 分配 IP 地址
|
use_dhcpv6
|
False
|
使用 DHCP 分配 v6 IP 地址
|
addresses
| |
分配给绑定的 IP 地址序列
|
routes
| |
分配给绑定的路由序列
|
mtu
|
1500
|
连接的最大传输单元(maximum transmission unit,简称 MTU)
|
primary
|
False
|
作为主接口的接口
|
members
| |
在绑定中使用的接口项序列
|
bonding_options
| |
在创建绑定时使用的一组选项
|
defroute
|
True
|
使用这个接口作为默认路由
|
persist_mapping
|
False
|
写入设备别名设置,而不是写入系统名
|
dhclient_args
|
无
|
传递给 DHCP 客户端的参数
|
dns_servers
|
无
|
为绑定使用的 DNS 服务器列表
|
表 D.6. Linux 网桥选项
选项
|
默认值
|
描述
|
---|---|---|
name
| |
网桥名
|
use_dhcp
|
False
|
使用 DHCP 分配 IP 地址
|
use_dhcpv6
|
False
|
使用 DHCP 分配 v6 IP 地址
|
addresses
| |
分配给网桥的 IP 地址序列
|
routes
| |
分配给网桥的路由序列
|
mtu
|
1500
|
连接的最大传输单元(maximum transmission unit,简称 MTU)
|
members
| |
在网桥中使用的一组接口、VLAN 和绑定项序列
|
defroute
|
True
|
使用这个接口作为默认路由
|
persist_mapping
|
False
|
写入设备别名设置,而不是写入系统名
|
dhclient_args
|
无
|
传递给 DHCP 客户端的参数
|
dns_servers
|
无
|
为网桥使用的 DNS 服务器列表
|
附录 E. 网络接口模板示例
E.1. 配置接口
network_config: # Add a DHCP infrastructure network to nic2 - type: interface name: nic2 use_dhcp: true - type: ovs_bridge name: br-bond members: - type: ovs_bond name: bond1 ovs_options: {get_param: BondInterfaceOvsOptions} members: # Modify bond NICs to use nic3 and nic4 - type: interface name: nic3 primary: true - type: interface name: nic4
nic1
、nic2
等)而不是使用接口名(如 eth0
、eno2
等)时,在一个角色中的主机网络接口不需要是完全相同的。例如,一个主机可能有接口 em1
和 em2
,而另外一个主机有接口 eno1
和 eno2
,您可以使用 nic1
和 nic2
来指代这两个主机的接口。
ethX
接口,如eth0
、eth1
等。这些通常是板上的内置接口。enoX
接口,如eno0
、eno1
等。这些通常是板上的内置接口。enX
接口,以字母顺序排序,如enp3s0
、enp3s1
、ens3
等。这些通常是额外附加的接口。
nic1
到 nic4
,并只在每个主机中的 4 个接口中连接网线。
E.2. 配置路由和默认路由
defroute=no
。
nic3
)作为默认的路由。使用以下 YAML 禁用另外一个 DHCP 接口(nic2
)上的路由:
# No default route on this DHCP interface - type: interface name: nic2 use_dhcp: true defroute: false # Instead use this DHCP interface as the default route - type: interface name: nic3 use_dhcp: true
注意
defroute
参数只会应用到通过 DHCP 获得的路由。
- type: vlan device: bond1 vlan_id: {get_param: InternalApiNetworkVlanID} addresses: - ip_netmask: {get_param: InternalApiIpSubnet} routes: - ip_netmask: 10.1.2.0/24 next_hop: 172.17.0.1
E.3. 为浮动 IP 使用原生 VLAN
br-int
,而不是直接使用 br-ex
。这种模式允许多个 Floating IP 网络使用 VLAN 或多个物理连接。
parameter_defaults
部分使用 NeutronExternalNetworkBridge
参数:
parameter_defaults: # Set to "br-ex" when using floating IPs on the native VLAN NeutronExternalNetworkBridge: "''"
br-ex
,除了可以用于 Horizon 仪表板和 Public API,External 网络还可以被用于 Floating IP。
E.4. 在一个主干接口上使用原生 VLAN
network_config: - type: ovs_bridge name: {get_input: bridge_name} dns_servers: {get_param: DnsServers} addresses: - ip_netmask: {get_param: ExternalIpSubnet} routes: - ip_netmask: 0.0.0.0/0 next_hop: {get_param: ExternalInterfaceDefaultRoute} members: - type: ovs_bond name: bond1 ovs_options: {get_param: BondInterfaceOvsOptions} members: - type: interface name: nic3 primary: true - type: interface name: nic4
注意
E.5. 配置大型帧
注意
- type: ovs_bond name: bond1 mtu: 9000 ovs_options: {get_param: BondInterfaceOvsOptions} members: - type: interface name: nic3 mtu: 9000 primary: true - type: interface name: nic4 mtu: 9000 # The external interface should stay at default - 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} # MTU 9000 for Internal API, Storage, and Storage Management - type: vlan device: bond1 mtu: 9000 vlan_id: {get_param: InternalApiNetworkVlanID} addresses: - ip_netmask: {get_param: InternalApiIpSubnet}
附录 F. 网络环境选项
表 F.1. 网络环境选项
参数
|
描述
|
示例
|
---|---|---|
InternalApiNetCidr
|
Internal API 网络的网络和子网
|
172.17.0.0/24
|
StorageNetCidr
|
Storage 网络的网络和子网
| |
StorageMgmtNetCidr
|
Storage Management 网络的网络和子网
| |
TenantNetCidr
|
Tenant 网络的网络和子网
| |
ExternalNetCidr
|
External 网络的网络和子网
| |
InternalApiAllocationPools
|
Internal API 网络的分配池(tuple 格式)
|
[{'start': '172.17.0.10', 'end': '172.17.0.200'}]
|
StorageAllocationPools
|
Storage 网络的分配池(tuple 格式)
| |
StorageMgmtAllocationPools
|
Storage Management 网络的分配池(tuple 格式)
| |
TenantAllocationPools
|
Tenant 网络的分配池(tuple 格式)
| |
ExternalAllocationPools
|
External 网络的分配池(tuple 格式)
| |
InternalApiNetworkVlanID
|
Internal API 网络的 VLAN ID
|
200
|
StorageNetworkVlanID
|
Storage 网络的 VLAN ID
| |
StorageMgmtNetworkVlanID
|
Storage Management 网络的 VLAN ID
| |
TenantNetworkVlanID
|
Tenant 网络的 VLAN ID
| |
ExternalNetworkVlanID
|
External 网络的 VLAN ID
| |
ExternalInterfaceDefaultRoute
|
External 网络的网关 IP 地址
|
10.1.2.1
|
ControlPlaneDefaultRoute
|
Provisioning 网络的网关路由(或 Undercloud IP)
|
ControlPlaneDefaultRoute: 192.0.2.254
|
ControlPlaneSubnetCidr
|
Provisioning 网络的网络和子网
|
ControlPlaneSubnetCidr: 192.0.2.0/24
|
EC2MetadataIp
|
EC2 元数据服务器的 IP 地址。通常情况下是 Undercloud 的 IP。
|
EC2MetadataIp: 192.0.2.1
|
DnsServers
|
为 Overcloud 节点定义 DNS 服务器。最多可以包括两个。
|
DnsServers: ["8.8.8.8","8.8.4.4"]
|
NeutronExternalNetworkBridge
|
定义 External 网络使用的网桥。如果使用网桥
br-ex 上的原生 VLAN 中的浮动 IP,则设置为 "br-ex" 。
|
NeutronExternalNetworkBridge: "br-ex"
|
BondInterfaceOvsOptions
|
绑定接口的选项
|
bond_mode=balance-tcp"
|
附录 G. 绑定选项
BondInterfaceOvsOptions: "bond_mode=balance-tcp"
重要
- type: linux_bond
name: bond1
members:
- type: interface
name: nic2
- type: interface
name: nic3
bonding_options: "bond_mode=balance-tcp lacp=active other-config:lacp-fallback-ab=true"
表 G.1. 绑定选项
bond_mode=balance-tcp
|
这个模式会在执行负载均衡时考虑第 2 层到第 4 层的数据。例如,目的地的 MAC 地址、IP 地址和 TCP 端口。另外,
balance-tcp 需要 LACP 在交换机上配置。这个模式和 Linux 绑定驱动所使用的 mode 4 绑定相似。因为 LACP 提供了最高级别的链接失败检测功能,并且会提供额外的关于绑定的诊断信息,所以在可能的情况下,推荐使用 balance-tcp 。
推荐的选项是为 LACP 配置
balance-tcp 。这个设置会尝试配置 LACP,当 LACP 无法和物理交换机进行通讯时,会切换到 active-backup 。
|
bond_mode=balance-slb
|
负载平衡操作是基于源 MAC 地址和输出的 VLAN 进行的,并在网络数据特性出现变化时进行定期的再平衡。带有
balance-slb 的绑定允许在不需要远程交换机支持的情况下进行一定形式的负载平衡操作。SLB 会把每个源 MAC 和 VLAN 对分配到一个链接,并通过这个链接从 MAC 和 VLAN 发送所有数据包。这个模式使用一个简单的基于 MAC 地址和 VLAN 号的哈希算法,并在网络数据特性出现变化时进行定期的再平衡。它与 Linux 绑定驱动所使用的 mode 2 绑定类似。这个模式会在交换机配置了绑定,但却没有配置使用 LACP (静态绑定而不是动态绑定)的情况下使用。
|
bond_mode=active-backup
|
这个模式提供了一个 active/standby 方式的故障转移功能 - 当 active 连接出现问题时,standy NIC 会恢复网络操作。这只需要在物理交换机上存在一个 MAC 地址。这种模式不需要任何特殊的交换机支持或配置,当连接到不同交换机时同样可以正常工作。这个模式不支持负载平衡。
|
lacp=[active|passive|off]
|
控制 LACP(Link Aggregation Control Protocol)操作。只有特定交换机才支持 LACP。如果您的交换机不支持 LACP,请使用
bond_mode=balance-slb 或 bond_mode=active-backup 。
不要在 LACP 中使用基于 OVS 的绑定,因为这个配置有问题,而且不被支持。可以使用 bond_mode=balance-slb 作为替代来实现相关的功能。另外,您仍然可以使用带有 Linux 绑定的 LACP:
|
other-config:lacp-fallback-ab=true
|
在交换机上把 LACP 设置为 bond_mode=active-backup 作为一个故障恢复。
|
other_config:lacp-time=[fast|slow]
|
把 LACP 的"心跳"设置设为 1 秒(fast)或 30 秒(slow)。默认值是 slow。
|
other_config:bond-detect-mode=[miimon|carrier]
|
把连接监测的间隔设置为 miimon heartbeat(miimon)或 monitor carrier(carrier)。默认值是 carrier。
|
other_config:bond-miimon-interval=100
|
如果使用 miimon,以毫秒为单位设置心跳间隔。
|
other_config:bond_updelay=1000
|
为了防止发生网络转移,一个连接必须处于活跃状态的时间(以毫秒为单位)
|
other_config:bond-rebalance-interval=10000
|
在绑定设备间再平衡网络数据的时间(以毫米为单位)。设为 0 禁用这个功能。
|
重要
附录 H. 修订历史
修订历史 | |||
---|---|---|---|
修订 8.0-0.1 | Sun Apr 24 2016 | Red Hat Localization Services | |
| |||
修订 8.0-0 | Tue Nov 24 2015 | Dan Macpherson | |
|