Red Hat Training

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

第 3 章 规划您的 overcloud

以下一节提供了与规划您的 Red Hat OpenStack Platform 环境中的各个环境相关的信息。这包括定义节点角色、规划您的网络拓扑结构和存储。

3.1. 规划节点的实施角色

director 为构建 overcloud 提供了多个默认的节点类型。这些节点类型是:

Controller

提供用于控制环境的关键服务。它包括仪表板服务 (horizon)、认证服务 (keystone)、镜像存储服务 (glance)、联网服务 (neutron)、编配服务 (heat) 以及高可用性服务。一个 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 服务提供外部对象存储的主机。这个实施角色是可选的。

下表提供了几个不同的 overcloud 示例,以及每种情况中的节点数量。

表 3.1. 节点部署

 

Controller

Compute

Ceph-Storage

Swift-Storage

Cinder-Storage

总计

小型 overcloud

1

1

-

-

-

2

中型 overcloud

1

3

-

-

-

4

带有额外对象存储和块存储的中型 overcloud

1

3

-

1

1

6

带有高可用性功能的中型 overcloud

3

3

-

-

-

6

带有高可用性和 Ceph 存储的中型 overcloud

3

3

3

-

-

9

此外,还需思考是否要将各个服务划分成不同的自定义角色。有关可组合角色架构的更多信息,请参阅 Advanced Overcloud Customization 指南中的“Composable Services and Custom Roles”

3.2. 规划网络

规划环境中的网络拓扑结构和子网非常重要,您需要把角色和服务进行正确的映射,从而使它们可以进行正确的通信。Red Hat OpenStack Platform 使用 neutron 网络服务,此服务可自主运行,并可管理基于软件的网络、静态和浮动 IP 地址以及 DHCP。budirector 在overcloud 环境的每个 Controller 节点上实施此服务。

Red Hat OpenStack Platform 把不同的服务映射到分配给环境中的不同子网的独立网络流量类型中。这些网络类型包括:

表 3.2. 网络类型分配

网络类型

描述

用于

IPMI

用于节点电源管理的网络。此网络在安装 undercloud 之前预先定义。

所有节点

Provisioning / Control Plane

director 使用此网络类型来通过 PXE 引导实施新的节点,并编配在 overcloud 裸机服务器上进行的 OpenStack Platform 安装。此网络在安装 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 地址相关联。如果在一个与外部网络隔离的 VLAN 中托管浮动 IP,您可以把浮动 IP VLAN 中继到控制器节点,并在 overcloud 创建后通过 Neutron 添加 VLAN。这为创建多个浮动 IP 网络并附加到多个网桥提供了途径。VLAN 会被中继,但不会配置为接口。相反,neutron 会为每个浮动 IP 网络在所选的网桥上创建一个带有 VLAN 分段 ID 的 OVS 端口。

Controller

Management

提供与系统管理相关的功能,如 SSH 访问、DNS 流量和 NTP 流量。这个网络也作为非 Controller 节点的一个网关。

所有节点

在典型的 Red Hat OpenStack Platform 安装中,网络类型的数量通常会超过物理网络链路的数量。为了可以把所有网络都连接到正确的主机,overcloud 使用 VLAN 标签(VLAN tagging)来为每个接口提供多个网络。大多数的网络都是相互分离的子网,但部分网络需要第 3 层网关来提供路由功能以便接入互联网或连接基础架构网络。

注意

我们推荐,即使在部署时使用了禁用隧道功能的 neutron VLAN,您最好仍然部署一个项目网络(利用 GRE 或 VXLAN 进行隧道连接)。这只需要在部署时进行一些微小的自定义,便可为以后使用网络隧道功能实现工具网络或虚拟化网络留下选择余地。您仍然需要使用 VLAN 创建租户网络,但同时也可为特殊用途网络创建 VXLAN 隧道,而不需要消耗租户 VLAN。VXLAN 功能可以添加到带有租户 VLAN 的部署中,而租户 VLAN 却无法在不对系统运行造成干扰的情况下添加到现有的 overcloud 中。

director 提供了一个为其中的 6 种网络流量类型映射到特定子网或 VLAN 的方法。这些流量类型包括:

  • Internal API
  • Storage
  • Storage Management
  • Tenant
  • External
  • Management

所有没有被分配的网络都会被自动分配到和 Provisioning 网络相同的网络中。

下图显示了一个通过独立的 VLAN 进行分离的网络拓扑结构示例。每个 overcloud 节点都使用绑定的两个接口(nic2nic3)来通过各自的 VLAN 提供网络功能。同时,所有 overcloud 节点都使用 nic1 并借助原生 VLAN 通过 Provisioning 网络跟 undercloud 进行通信。

使用绑定接口的 VLAN 拓扑示例

下表提供了把网络流量映射到不同网络结构中的示例:

表 3.3. 网络映射

 

映射

接口总数

VLAN 总数

带有外部连接的平面网络

网络 1 - Provisioning、Internal API、Storage、Storage Management、Tenant Networks

网络 2 - 外部、浮动 IP(在 overcloud 创建后进行映射)

2

2

隔离的网络

Network 1 - Provisioning

Network 2 - Internal API

Network 3 - Tenant Network

Network 4 - Storage

Network 5 - Storage Management

Network 6 - Storage Management

网络 7 - 外部、浮动 IP(在 overcloud 创建后进行映射)

3(包括 2 个绑定接口)

7

3.3. 规划存储

注意

如果在使用任何驱动程序或后端类型的后端 cinder-volume 的客户机实例上使用 LVM,则会出现与性能、卷可见性和卷可用性有关的问题。这些问题可利用 LVM 过滤器来解决。有关更多信息,请参考 Storage Guide 中的 2.1 Back Ends 部分以及 KCS 文章 3213311“Using LVM on a cinder volume exposes the data to the compute host”。

director 为 overcloud 环境提供不同的存储选项,它们包括:

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 中引导每个虚拟机,而不用使用 cinder,这可以使您在实时迁移时更容易地执行维护操作。例如,如果您的 hypervisor 出现问题,它还可以方便地触发 nova evacuate,从而使在其它地方运行虚拟机的过程几乎可以“无缝”地实现。

    重要

    如果您想在 Ceph 中引导虚拟机(使用临时后端或从卷引导),glance 镜像的格式必须是 RAW。Ceph 不支持使用其他镜像格式(如 QCOW2 或 VMDK)来托管虚拟机磁盘。

如需了解更详细的信息,请参阅Red Hat Ceph Storage 架构指南

Swift 存储节点
director 会创建外部对象存储节点。当您需要扩展或替换 overcloud 环境中的控制器节点,同时需要在一个高可用性集群外保留对象存储时,这将非常有用。