第 1 章 架构示例

第 1 章 架构示例

想要理解 OpenStack 所能提供的强大功能,最好从那些被证明有效并在生产环境中测试过的基础架构开始学起。我们提供了基于两种基本操作系统(Ubuntu 和 Red Hat Enterprise Linux)和网络架构的示例。这两种示例还有其他区别,但是你需要了解每种情形下做决策的注意事项,以及它们在特定环境下能够良好运行的理论依据。

由于高度可配置的 OpenStack 具有很多不同的后端和网络配置选项,因此我们很难在文档中描述所有的 OpenStack 部署方式。因此,这本指南定义了一些架构示例以简化文档工作,也为本书划定了范畴。这两种架构示例当前都被用于生产环境并向用户提供服务。

 同往常一样,如果你在学习这些架构的过程中遇到了不理解的词汇,请查阅书后的术语表。

1.1 架构示例:传统网络模型(nova)

本架构示例已从 Grizzly 升级到了 Havana 版本,在生产环境中测试过,多个公共 IP 地址可以分配给多个实例。在本节之后,你可以看到使用 OpenStack 网络服务(neutron)的那种示例架构。每一种架构都提供了高可用性,这意味着如果有节点宕机,其他具有同样配置的节点可以接手它的任务,持续提供服务。

1.1.1 概述

对于计算资源而言,你所能建造的最简单的计算架构包含一个云控制器和多个计算节点。最简单的对象存储架构包含五个节点:一个用于验证用户并且传递请求给 API,剩下的四个用于存储本身,提供足够的彼此之间的同步能力来保证一致性。本架构示例并不强求特定的节点数量,而是向你阐述采用此种架构的思考和种种考量,以及此种架构的特性。

1. 组件

组件

说明

OpenStack 版本

Havana

主机操作系统

Ubuntu 12.04 LTS 或者Red Hat Enterprise Linux 6.5,包括其衍生版,如CentOS 和Scientific Linux

OpenStack 包存储库

Ubuntu Cloud Archive(http://opsgui.de/NPHp7s)或者RDO(http://opsgui.de/1eLCZcm)*

超级管理程序(hypervisor)

KVM

数据库

MySQL *

消息队列

Ubuntu 下的RabbitMQ;Red Hat Enterprise Linux 及其衍生版下的Qpid

网络服务

nova-network

网络管理器

FlatDHCP

nova-network 还是multi-host

multi-host *

镜像服务(glance)后端

文件

身份服务(keystone)驱动

SQL

块存储服务(cinder)后端

LVM/iSCSI

动态迁移后端

使用 NFS 的共享存储 *

对象存储

OpenStack 对象存储(swift)

星号(*)标记表示架构示例与默认安装的设置有所区别,我们会在后面对这些区别进行解释。

本指南中的架构示例支持以下 OpenStack 特性,这些特征是可选择的。

  • 控制面板 你可能想要提供一个控制面板,但是你的用户也许仅对 API 访问更感兴趣。

  • 块存储 如果你的用户只需要计算节点上的临时性存储,那么就没必要提供块存储。

  • 浮动 IP 地址 浮动 IP 是公共 IP 地址,你可以把地址从预先定义好的地址池中取出,并在虚拟机启动时分配给它们。只要实例启动,浮动 IP 地址就可以确保公共 IP 地址是可用的。并非每个组织都能够为上千个实例提供上千个公共浮动 IP 地址,因此这个特性是可选的。

  • 动态迁移 如果你需要将运行中的虚拟机实例从一台主机迁移到另外一台,而且不希望服务中断,那么需要启用动态迁移功能,但这个也是可选的。

  • 对象存储 如果你没有多余的硬件用于 OpenStack 对象存储所需的同步和冗余,那么可以选择将机器镜像存储在文件系统内,而非对象存储中。

2. 基本原理

本架构示例基于 OpenStack Havana 版本当前默认的功能,并增强了稳定性。我们相信当前很多在生产环境中运行 OpenStack 的云系统都会做类似的选择。

首先你需要选择运行在所有物理节点上的操作系统。多种 Linux 发行版支持 OpenStack,我们使用 Ubuntu 12.04 LTS(长期支持版本)。这也是开发社区主要使用的发行版,相较于其他发行版而言,它有着完善的功能和明确的未来支持计划。

我们不建议你使用 Ubuntu 默认的 OpenStack 安装包,而建议使用 Ubuntu Cloud Archive(http://opsgui.de/NPHp7s)。Cloud Archive 是 Canonical 公司支持的软件包仓库,它能让你在 Ubuntu 12.04 版本的条件下升级到 OpenStack 的未来版本。

KVM 是 Ubuntu 选择的超级管理程序组件——就服务支持而言,KVM 和 Ubuntu 是一对很好的组合,并且 KVM 受到了 OpenStack 开发社区的广泛关注(本书的作者们也主要使用 KVM)。它有着完善的功能,许可免费且不受限制。

MySQL 有着和上面类似的走向。尽管最近它的所有权发生了变更,此数据库仍旧是久经考验且文档完善的 OpenStack 使用“伴侣”。我们弃用了其默认的数据库 SQLite,因为 SQLite 并不是供生产使用的数据库。

选择 RabbitMQ 而非 OpenStack 支持的其他 AMQP 兼容型产品,例如 ZeroMQ 和 Qpid,是因为它易于使用且在生产环境中得到了广泛测试。它也是支持 OpenStack 计算服务中单元(cell)功能的唯一选择。作为系统中的固有组件,我们建议将 RabbitMQ 组成集群,鉴于其内在特性做到这点很容易。

如前所述,OpenStack 计算的网络有多种选择。我们推荐 FlatDHCP 并且使用 Multi-Host 的网络模型来实现高可用性,在每个 OpenStack 计算主机上运行一个 nova-network 守护进程。此种强大的机制确保网络中断能够被隔离在独立的计算主机中,且可以直接使用硬件网关。

动态迁移是通过共享存储的方式来实现的,使用 NFS 作为分布式文件系统。

要知道对于很多小规模的部署,如果对象存储仅仅用来存放虚拟机镜像的话是很浪费的。我们选择了 OpenStack 镜像服务(Glance)里的文件后端。如果你的云系统使用了对象存储,那么很容易把它加作后端。

身份服务(keystone)我们采用了 SQL 后端,而非其他的方式,如 LDAP。这个后端易于安装且十分健壮。我们认为很多软件安装都希望绑定已有的目录服务,并且提醒要准确理解一系列可用的选项(http://opsgui.de/1eLCZJr)。

块存储(cinder)通过 LVM/iSCSI 插件原生安装在外部存储节点上。大多数块存储服务插件都绑定了特定的供应商产品和安装启用服务,仅限于使用那些硬件平台的用户所用,但 LVM/iSCSI 是建立在通用硬件上面的,而且健壮而稳定。

虽然即便没有 OpenStack Dashboard,云系统也一样可以运行,但是我们认为它是必不可少的组件。不仅为了让用户可以与云交互,而且对于运维人员来讲它也是趁手的工具。另外,使用了 Django 的控制面板扩展起来会十分容易。

3. 为何不使用OpenStack网络服务(neutron)

本架构示例并未使用 OpenStack 网络服务(neutron),因为它尚未支持多主机网络,而且我们的组织机构(大学、政府)已经获得了大量的公共 IPv4 地址。

4. 为何使用多主机网络

在 OpenStack 的默认部署中,有单个 nova-network 服务在云系统中运行(通常在云控制器上),它向访客实例提供了网络地址转换(NAT)、DHCP 和 DNS 等服务。如果这个运行 nova-network 服务的单节点宕机了,你就无法访问客机实例,而实例也就无法访问因特网。当过多的网络流量流入和流出云系统时,这个运行了 nova-network 的单节点就成了一个瓶颈。

 多主机(http://opsgui.de/NPHqbu)是网络配置的一种高可用选项,此种方式下 nova-network 服务在每个计算节点上运行,而非仅在单个节点上运行。

1.1.2 详细描述

本参考架构包含多个计算节点、一个云控制器、一个外部 NFS 存储服务器作为实例存储,以及一个 OpenStack 块存储服务器作为卷存储。一个网络时间服务(Network Time Protocol,网络时间协议,简写为 NTP)用于同步所有节点上的时间。多主机模式下的 FlatDHCPManager 用于网络连接。下页的这张逻辑示意图展示了此架构示例中各节点上运行了哪些服务。

云控制器运行了以下服务:控制面板;API 服务;数据库(MySQL);一个消息队列服务器(RabbitMQ);用于挑选计算资源的调度器(nova-scheduler);身份服务(keystone、nova-consoleauth);镜像服务(glance-apiglance-registry);访客的控制台访问服务和块存储服务,包括存储资源的调度器(cinder-apicinder-scheduler)。

{%}

计算节点就是那些拥有计算资源的节点。在我们的架构示例中,计算节点运行了以下服务:超级管理程序(KVM)、libvirt(超级管理程序的驱动,它能够实现节点间的动态迁移)、nova-computenova-api-metadata(一般仅在多主机模式下运行的时候使用,它能够检索实例特有的元数据)、nova-vncproxynova-network

网络中包含两个交换机,其中一个用于管理功能或私网流量,另外一个用于包括浮动 IP 地址在内的公共访问。这样的话,云控制器和计算节点就需要两块网卡。OpenStack 的块存储和 NFS 存储服务器只需要访问私网,因此需要一块网卡。但是如果可能的话,我们建议在捆绑配置条件下使用多块网卡。Flat IP 经过 NAT 转换后的浮动 IP 地址可以直接通过因特网访问。我们可以基于下图来理解网络通信的情况。

{%}

1.1.3 可选的扩展

你可以按照下面的方法扩展本参考架构:

  • 添加额外的云控制器(参见第 11 章);

  • 添加 OpenStack 存储服务(基于你所选择的发行版本,请参见前言中所说《OpenStack 安装指南》中的对象存储章节);

  • 添加额外的 OpenStack 块存储主机(参见第 11 章)。

1.2 架构示例:OpenStack网络服务

本章提供的架构示例在高可用环境中使用了 OpenStack 网络服务,也称为 Neutron 项目。

1.2.1 概述

一个高可用的环境允许你对其进行水平扩展,或者在节点故障的时候让云系统依旧可以运行。本架构示例基于 OpenStack Havana 版本的当前默认功能,并在高可用方面做了加强。

1. 组件

组件

说明

OpenStack 版本

Havana

主机操作系统

Red Hat Enterprise Linux 6.5

OpenStack 软件包存储库

Red Hat Distributed OpenStack(RDO,https://repos.fedorapeople.org/repos/openstack/

超级管理程序(hypervisor)

KVM

数据库

MySQL

消息队列

Qpid

网络服务

OpenStack 网络服务

租户网络隔离

VLAN

镜像服务(glance)后端

GlusterFS

身份服务(keystone)驱动

SQL

块存储服务(Cinder)后端

GlusterFS

2. 基本原理

本架构示例基于 OpenStack Havana 版本当前默认的功能,并在高可用方面做了加强。这个架构当前在内部的 Red Hat OpenStack 云系统中使用,用于运行托管和共享服务,具备高可用特性。

本架构的组件选择基于以下理由。

  • Red Hat企业版Linux(Red Hat Enterprise Linux)

    你必须选择一套能在所有物理节点上运行的操作系统。本架构示例基于 Red Hat 企业版 Linux,后者可靠并具备长期支持,经过了认证的测试以及系统强化。企业客户现在如果要使用 OpenStack,基本上都需要这些特性。

  • RDO

    用 Red Hat 分布式 OpenStack(Red Hat Distributed OpenStack)包可以让你轻松下载最新的用于 Red Hat 企业版 Linux 平台的 OpenStack 发行版。

  • KVM

    KVM 是 Red Hat 企业版 Linux 支持的超级管理程序(已经包含在发行版中)。它有着完善的功能,许可免费且不受限制。

  • MySQL

    MySQL 用作 OpenStack 环境下所有的数据库后端。MySQL 是 Red Hat 企业版 Linux 发行版支持的数据库(已经包含在发行版中);此开源数据库扩展性好,并且在处理内存方面做得不错。

  • Qpid

    Apache Qpid 百分百兼容高级消息队列协议标准,并且它的代理对 C++ 和 Java 都可用。

  • OpenStack网络服务

    OpenStack 网络服务提供了高级的网络功能,包括 2 层(L2)网络隔离和供应商网络。

  • VLAN

    使用虚拟局域网来实现广播控制、安全和物理层透明。如果需要,你还可以使用 VXLAN 来扩展地址空间。

  • GlusterFS

    GlusterFS 提供了可扩展的存储。随着环境的成长,你可以持续添加存储节点(而不必受到像那些昂贵的存储阵列一类的限制)。

1.2.2 详细描述

1. 节点类型

本节详细介绍了构成 OpenStack 环境的不同节点。一个节点就是一台配备一个操作系统的 物理机器,其上运行着特定的软件栈。表 1-1 提供了节点描述和规格。

表1-1:节点类型

类型

说明

硬件示例

控制器节点

控制器节点负责运行 OpenStack 环境所需的管理软件服务。这些节点如下。
• 向用户提供访问用的前端,并向 OpenStack 中的其他组件通信提供 API 服务
• 以高可用的方式运行着一系列服务,利用 Pacemaker 和 HAProxy 来提供虚拟 IP 地址,并实现负载均衡功能,这样所有的控制节点都可以被使用到
• 提供高可用的“基础设施”服务,如 MySQL 和 Qpid,它们支持所有的服务
• 通过主机上运行的服务提供所谓的“持久性存储”。持久性存储由存储节点支持其可靠性
请参见图 1-3

硬件类型:Dell R620
CPU:2 × Intel® Xeon® CPU E5-2620 0 @ 2.00 GHz
内存: 32 GB
磁盘: 2 × 300 GB 10000 RPM SAS 磁盘
网络:2 × 10 G 网络端口

计算节点

计算节点运行 OpenStack 中的虚拟机实例。它们:
• 运行操作实例所需的最低限度的服务;
• 虚拟机使用节点上的本地存储,因此节点故障时无法进行虚拟机迁移和实例恢复
请参见图 1-4

硬件类型:Dell R620
CPU:2 × Intel® Xeon® CPU E5-2650 0 @ 2.00 GHz
内存: 128 GB
磁盘: 2 × 600 GB 10000 RPM SAS 磁盘
网络:4 × 10 G 网络端口(用于将来的试验扩展)

存储节点

存储节点存放着环境所需的所有数据,包括镜像服务库中的磁盘镜像,以及由块存储服务器创建的持久性存储卷。存储节点使用 GlusterFS 技术来保证数据的高可用性和扩展性
请参见图 1-6

硬件类型: Dell R720xd
CPU:2 × Intel® Xeon® CPU E5-2620 0 @ 2.00 GHz
内存: 64 GB
磁盘: 2 × 500 GB 7200 RPM SAS 磁盘 + 24 × 600 GB 10000 RPM SAS 磁盘
Raid 控制器:PERC H710P 集成RAID 控制器,1 GB 非易失性缓存
网络:2 × 10 G 网络端口

网络节点

在创建公有、私有网络,或者将虚拟机上行接入到外部网络时,网络节点负责所有虚拟网络相关的工作:
• 为在 OpenStack 上运行的实例构建准入、准出点
• 运行环境中所有的网络服务,但不包含网络 API 服务(此服务在控制器节点上运行)
请参见图 1-5

硬件类型: Dell R620
CPU:2 × Intel® Xeon® CPU E5-2620 0 @ 2.00 GHz
内存: 32 GB
磁盘: 2 × 300 GB 10000 RPM SAS 磁盘
网络:5 × 10 G 网络端口

工具节点

工具节点仅限内部管理人员使用,提供一系列基本的系统管理功能,能够让环境启动和运行,并且维护硬件、操作系统和其上运行的软件
这些节点运行的服务包括:预备、配置、管理、监控,或者 GlusterFS 管理软件。一般这些虚拟机都有备份,但是它们并不需要扩展

硬件类型: Dell R620
CPU:2 × Intel® Xeon® CPU E5-2620 0 @ 2.00 GHz
内存: 32 GB
磁盘: 2 × 500 GB 7200 RPM SAS 磁盘
网络:2 × 10 G 网络端口

2. 网络布局

环境中所有硬件的管理设备都需要接入到网络(例如硬件节点的 Dell iDrac7 设备,还有网络交换机的管理接口)。在硬件故障诊断和恢复时,网络仅限于被内部人员访问。

OpenStack 内部网络 这个网络用于 OpenStack 管理功能和通信,包括分配物理节点(pxetftpkickstart)所需要的服务,各种 Openstack 节点类型之间通过 OpenStack API 和消息通信(例如 nova-computekeystone 通信或者 cinder-volumenova-api 通信)时所产生的流量,以及通过 Gluster 协议将数据存储到下面的存储层所产生的流量。在此网络中,所有物理节点都至少需要留一个网络接口(一般是 eth0)用于此网络。此网络仅能通过 22 号端口(用于 ssh 访问以管理虚拟机)上的其他虚拟局域网进行访问。

公共网络 本网络包含以下部分。

  • 控制器节点(终端用户用来访问 OpenStack 服务)上用于公开访问接口的 IP 地址。

  • 一系列公共可路由的 IPv4 网络地址,供 OpenStack 网络服务的浮动 IP 地址使用。访问 IPv4 地址时你可能受到限制;不过,我们并不需要大范围的 IPv4 地址。

  • 在 OpenStack 中创建的私网路由器。

此网络与控制器节点相连接,这样用户就可以访问 OpenStack 接口,并连接到网络节点来为虚拟机提供公共可路由的通信功能。此网络也连接到了工具虚拟机上,这样任何一款需要公共访问的工具服务(例如系统监控)都能够被访问到。

虚拟机通信网络 这是一个不可公共路由的封闭网络,可作为私人的内部网络用于 OpenStack 虚拟机之间的网络通信,以及虚拟机和向公共网络提供 l3 路由的网络节点之间的通信(包括连接回虚拟机的浮动 IP 地址)。因为这是一个封闭网络,我们使用一个不同于其他的地址空间来划清界限。只有计算节点和 OpenStack 网络服务节点需要连接到此网络。

3. 节点间的连接

以下部分详细描述了节点是如何连接到不同网络中的(参见“网络布局”),以及把节点连接到网络中时其他的注意事项(例如做网卡捆绑)。

初始化部署 最开始,为了降低部署的复杂性并节约时间,连接设置应该确保简单和明确。图 1-1 所示的部署中,所有计算节点都使用 1 × 10 G 连接,同时也在一些适当的节点上利用绑定来实现性能最大化。

{%}

图 1-1:基本节点部署方式

性能最大化连接 如果基本布局中的网络性能无法满足要求,你可以参看图 1-2,环境中的所有节点均使用 2 × 10 G 网络连接,同时为存储层提供了更多的网络带宽。

{%}

图 1-2:高性能节点部署方式

4. 节点示意图

接下来的示意图(图 1-3~ 图 1-6)包含了有关不同节点类型的逻辑信息,显示了哪些服务运行其上以及它们是如何彼此进行交互的。示意图也阐释了这些服务是如何获得可用性和扩展能力的。

{%}

图 1-3:控制器节点

{%}

图 1-4:计算节点

{%}

图 1-5 :网络节点

{%}

图 1-6 :存储节点

1.2.3 组件配置示例

表 1-2 和表 1-3 介绍了第三方组件和 OpenStack 组件的配置示例,以及相关注意事项。

表1-2:第三方组件配置

组件

调优

可用性

扩展性

MySQL

binlog-format = row

双主复制。但是两者不能同时使用。复制使所有节点尽可能接近最新(但是复制的异步性意味着完全一致的状态是不可能的)。只有通过Pacemaker虚拟 IP 才能连接数据库,这样可以避免双主复制的大部分问题

未充分考虑扩展性。一旦 MySQL 服务器的负载增长到需要考虑扩展性,就要为了扩展能力重新考量,这时可以使用多主或主从设置

Qpid

maxconnections=1000 workerthreads=20 connectionbacklog=10,使用 SASL-BASIC 认证的 sasl 安全性

Qpid 作为一项资源添加到在控制器节点上运行的 Pacemaker 软件中,并位于控制器节点上。这样确保了同一时间只有一个 Qpid 实例在运行,而携带了 Pacemaker 虚拟IP 的节点将总是运行 Qpid 的节点

未充分考虑扩展性。但是为了实现扩展性和可用性,Qpid 可以转变成在所有控制器节点上运行,并从 Pacemaker 中移除

HAProxy

maxconn 3000

HAProxy 是一个软件第 7 层负载均衡器,用于所有集群环境下的OpenStack API 组件前端,它还可以做 SSL 终结器。HAProxy 可配置于控制器节点上,并作为一项资源添加到在控制器节点上运行的 Pacemaker 软件中。这样确保了同一时间只有一个 HAProxy 实例在运行,而携带了 Pacemaker 虚拟IP的节点将总是运行 HAProxy 的节点

未考虑扩展性。HAProxy 的性能开销很小,对于 OpenStack 这种级别的工作负载,单实例就具有足够的扩展性。如果需要额外的扩展能力,可以在多份 HAProxy 的前面放置 keepalived 软件或者其他 4 层负载均衡器

Memcached

MAXCONN="8192" CACHE SIZE="30457"

Memcached 是一款快速的内存键值缓存软件,OpenStack 组件用它来缓存数据和提升性能。Memcached 运行在所有控制器节点上,以此确保即便一个失效,其他 Memcached 实例依旧可用

未考虑扩展性。单Memcached 对于所需的工作负载就已经足够。如果需要额外的扩展能力,可以在Memcached(在原始的 tcp 模式下)前面部署 HAProxy,利用多Memcached实例实现扩展性,但是这样做可能会引起缓存一致性问题

Pacemaker

配置以使用 corosynccman 作为集群通信的栈/群管理器,使用双节点集群

Pacemaker 是一款集群软件,用以确保在控制器和网络节点上运行的服务的可用性:
• 由于 Pacemaker 是集群软件,软件本身就可以利用 corosynccman 来处理自己的高可用性
• 如果使用 GlusterFS 的原生客户端,就无需虚拟IP,因为初始连接后客户端就知晓所有节点的情况,因此客户端会自动绕过故障节点
• 如果使用 NFS 或者 SMB 适配器,你就需要一个虚拟 IP 来挂载 GlusterFS 卷

如果需要集群识别更多的节点,Pacemaker 最多可以扩展到 64 个节点

GlusterFS

对于所有卷,都启用了 glusterfs 的性能概况集“virt”,并以双节点复制模式设置卷

Glusterfs 是一款集群文件系统,在存储节点上运行,在环境中提供持久性可扩展的数据存储。因为所有 gluster 连接都使用了 gluster 原生的挂载点,gluster 实例本身就提供了可用性和故障转移功能

GlusterFS 存储的扩展能力可以通过添加更多的存储卷来实现

表1-3:OpenStack组件配置

组件

节点类型

调优

可用性

扩展性

控制面板(horizon)

控制器节点

配置以使用 Memcached 作为会话存储,启用 neutron 支持
can_set_mount_point = False

控制面板在所有的控制器节点上运行,一旦发生节点故障,保证至少有一个实例可用。它也安置在 HAProxy 后面,当软件发生故障后者就会发现并绕过故障的实例传送请求

控制面板在所有的控制器节点上运行,这样就可以通过添加控制器节点的方式来进行扩展。添加更多节点后,由 HAProxy 确保其扩展能力

身份服务(keystone)

控制器节点

使用 Memcached 作为缓存,使用 PKI 作为令牌

身份认证服务在所有控制器节点上运行,一旦发生节点故障,保证至少有一个实例可用。身份认证服务也安置在 HAProxy 的后面,当软件发生故障就会发现并绕过故障的实例传送请求

身份认证服务在所有的控制器节点上运行,这样就可以通过添加控制器节点的方式来扩展。添加更多节点后,由 HAProxy 确保其扩展能力

镜像服务(glance)

控制器节点

使用 /var/lib/glance/images GlusterFS 的原生挂载点来挂载存储层的卷

镜像服务在所有的控制器节点上运行,一旦发生节点故障,保证至少有一个实例可用。镜像服务也安置在 HAProxy 的后面,当软件发生故障后者就会发现并绕过故障的实例传送请求

镜像服务在所有的控制器节点上运行,这样就可以通过添加控制器节点的方式来进行扩展。添加更多节点后,由 HAProxy 确保其扩展能力

计算服务(nova)

控制器节点、计算节点

配置以使用 Qpid,qpid_heartbeat = 10,配置以使用 Memcached 作为缓存,配置以使用 libvirtneutron
配置 nova-consoleauth,以使用 Memcached 作为会话管理器(这样它就可以拥有多份副本并在负载均衡器中运行)

nova API、调度器(scheduler)、对象存储(objectstore)、证书(cert)、consoleauth、conductor 和 vncproxy 等服务都在所有的控制器节点上运行,一旦发生节点故障,保证至少有一个实例可用。计算也安置在 HAProxy 的后面,当软件发生故障后者就会发现并绕过故障的实例传送请求
计算服务(compute)和连接器服务(conductor)运行在计算节点上,也是这些节点仅需运行的服务,因此这些服务的可用性就与节点的可用性紧密结合在一起。只要计算节点运行正常,其上所需的服务也就可以运行

nova API、调度器(scheduler)、对象存储(objectstore)、证书(cert)、consoleauth、conductor 和 vncproxy 等服务在所有控制器节点上运行,这样就可以通过添加控制器节点的方式来更行扩展。添加更多节点后,由 HAProxy 确保其扩展能力。运行在计算节点上的服务(compute、conductor)的扩展能力,随着节点数目的增长而线性增长

块存储(cinder)

控制器节点

配置以使用Qpid,qpid_heartbeat = 10,配置以使用存储层的一个 Gluster 卷作为块存储的后端,使用 Gluster 的原生客户端

块存储API、调度器(scheduler)以及卷(volume)服务都在所有控制器节点上运行,一旦发生节点故障,保证至少有一个实例可用。块存储也安置在 HAProxy 的后面,当软件发生故障后者就会发现并绕过故障的实例传送请求

块存储API、调度器和卷服务在所有的控制器节点上运行,这样就可以通过添加控制器节点的方式来进行扩展。添加更多节点后,由 HAProxy 确保其扩展能力

OpenStack 网络服务(neutron)

控制器节点、计算节点、网络节点

配置以使用Qpid,qpid_heartbeat = 10,启用内核命名空间支持,tenant_network_type = vlanallow_overlapping_ips = truetenant_network_type = vlanbridge_uplinks = brex:em2bridge_mappings = physnet1:br-ex

OpenStack 网络服务运行在所有的控制器节点上,一旦发生节点故障,保证至少有一个实例可用。也安置在HAProxy的后面,当软件发生故障后者就会发现并绕过故障的实例传送请求
OpenStack 网络服务的ovsagentl3-agent-dhcp-agentmetadata-agent 服务运行在网络节点上,它们是 Pacemaker 内的 lsb 资源。这意味着一旦发生网络节点故障,服务依旧可以在其他节点上保持运行。最后,ovs-agent 服务运行在所有的计算节点上,一旦发生计算节点故障,其他节点可以使用其上运行的服务副本继续起作用

OpenStack 网络服务器的服务在所有控制器节点上运行,因此可以通过添加控制器节点的方式进行扩展。HAProxy 也保证了更多节点的加入时的 OpenStack 扩展性。目前,OpenStack 网络服务不支持在网络节点上运行的服务的扩展性,因此不在考虑之列。一份服务的副本足以处理好工作负载。运行在计算节点上的 ovs-agent 的扩展性,必要时可以通过添加更多计算节点来获得

1.3 关于架构的最后几句话

在有如此多的注意事项和可用选项的情况下,我们希望可以为你的 OpenStack 探索之旅提供几种清晰且成熟的路径。如果你希望看到更多的方案,请查阅本书的附录 A 和 “OpenStack 安装指南”(http://opsgui.de/NPFTC8),或者“OpenStack 用户案例”页面(http://opsgui.de/1eLAAhX)。

目录