OpenStack大规模部署详解

作者简介：付广平，云极星创研发工程师。

0.前言

今年的2月22日，OpenStack发布了15个版本Ocata。

走过了7年的发展岁月的OpenStack已经成为了云计算领域中最火热的项目之一，并逐渐成为IaaS的事实标准，私有云项目的部署首选。OpenStack社区可能自己都没有想到其发展会如此之迅速，部署规模如此之大，以至于最开始对大规模OpenStack集群的部署支持以及持续可扩展性似乎并没有考虑完备。

众所周知，OpenStack每一个项目都会有数据库的访问以及消息队列的使用，而数据库和消息队列是整个OpenStack扩展的瓶颈。尤其是消息队列，伴随着集群规模的扩展，其性能下降是非常明显的。通常情况下，当集群规模扩展到200个节点，一个消息可能要在十几秒后才会响应，集群的整体性能大大下降[1]，英国电信主管Peter Willis声称一个独立OpenStack集群只能最多管理500个计算节点[2]。

当处理大规模问题时，我们自然会想到分而治之策略，其思想是将一个规模为N的问题分解为K个规模较小的子问题，这些子问题相互独立且与原问题性质相同，解决了子问题就能解决原问题。社区提出的多Region、多Cells以及Cascading等方案都是基于分而治之策略，但它们又有所区别，主要体现在分治的层次不一样，多Region和Cascading方案思想都是将一个大的集群划分为一个个小集群，每个小集群几乎是一个完整的OpenStack环境，然后通过一定的策略把小集群统一管理起来，从而实现使用OpenStack来管理大规模的数据中心。在Grizzly版本引入的Nova Cells概念，其思想是将不同的计算资源划分为一个个的Cell，每个Cell都使用独立的消息队列和数据库服务，从而解决了数据库和消息队列的瓶颈问题，实现了规模的可扩展性。遗憾的是，目前社区还没有一个非常完美的OpenStack大规模部署方案，以上提到的方案都存在各自的优点和缺点，实际部署时应根据物理资源的分布情况、用户资源需求等因素综合选择。本文接下来将谈谈OpenStack大规模部署问题，讨论前面提到的各个方案的优缺点以及分别适用的场景。

1.单集群优化策略

1.1 使用独立的数据库和消息队列

前面提到限制OpenStack规模增长的最主要因素之一就是由于数据库和消息队列的性能瓶颈，因此如果能够有效减轻数据库以及消息队列的负载，理论上就能继续增长节点数量。各个服务使用独立的数据库以及消息队列显然能够有效减小数据库和消息队列的负载。在实践中发现，以下服务建议使用独立的数据库以及消息队列:

• Keystone: 用户以及其它API服务的认证都必须经过Keystone组件，每次Token验证都需要访问数据库，随着服务的增多以及规模的增大，数据库的压力将会越来越大，造成Keystone的性能下降，拖垮其它所有服务的API响应。因此为Keystone组件配置专门的数据库服务，保证服务的高性能。
• Ceilometer：Ceilometer是一个资源巨耗型服务，在收集消息和事件时会发送大量的消息到队列中，并频繁写入数据库。为了不影响其它服务的性能，Ceilometer通常都搭配专有的数据库服务和消息队列。
• Nova: OpenStack最活跃的主体就是虚拟机，而虚拟机的管理都是由Nova负责的。几乎所有对虚拟机的操作都需要通过消息队列发起RPC请求，因此Nova是队列的高生产者和高消费者，当集群规模大时，需要使用独立的消息队列来支撑海量消息的快速传递。
• Neutron：Neutron管理的资源非常多，包括网络、子网、路由、Port等，数据库和消息队列访问都十分频繁，并且数据量还较大，使用的独立的数据库服务和消息队列既能提高Neutron本身的服务性能，又能避免影响其它服务的性能。

1.2 使用Fernet Token

前面提到每当OpenStack API收到用户请求时都需要向Keystone验证该Token是否有效，Token是直接保存在数据库中的，增长速率非常快，每次验证都需要查询数据库，并且Token不会自动清理而越积越多，导致查询的性能越来越慢，Keystone验证Token的响应时间会越来越长。所有的OpenStack服务都需要通过Keystone服务完成认证，Keystone的性能下降，将导致其它所有的服务性能下降，因此保证Keystone服务的快速响应至关重要。除此之外，如果部署了多Keystone节点，还需要所有的节点同步Token，可能出现同步延迟而导致服务异常。为此社区在Kilo版本引入了Fernet Token，与UUID Token以及PKI Token不同的是它是基于对称加密技术对Token加密，只需要拥有相同加密解密文件，就可以对Token进行验证，不需要持久化Token，也就无需存在数据库中，避免了对数据库的IO访问，创建Token的速度相对UUID Token要快，不过验证Token则相对要慢些[3]。因此在大规模OpenStack集群中建议使用Fernet Token代替传统的Token方案。

以上优化策略能够一定程度上减少消息队列和数据库的访问，从而增大节点部署规模，但其实并没有根本解决扩展问题，随着部署规模的增长，总会达到瓶颈，理论上不可能支持无限扩展。

2.多Region方案

OpenStack支持将集群划分为不同的Region，所有的Regino除了共享Keystone、Horizon、Swift服务，每个Region都是一个完整的OpenStack环境，其架构如下：

部署时只需要部署一套公共的Keystone和Horizon服务，其它服务按照单Region方式部署即可，通过Endpoint指定Region。用户在请求任何资源时必须指定具体的区域。采用这种方式能够把分布在不同的区域的资源统一管理起来，各个区域之间可以采取不同的部署架构甚至不同的版本。其优点如下：

• 部署简单，每个区域部署几乎不需要额外的配置，并且区域很容易实现横向扩展。
• 故障域隔离，各个区域之间互不影响。
• 灵活自由，各个区域可以使用不同的架构、存储、网络。

但该方案也存在明显的不足：

• 各个区域之间完全隔离，彼此之间不能共享资源。比如在Region A创建的Volume，不能挂载到Region B的虚拟机中。在Region A的资源，也不能分配到Region B中，可能出现Region负载不均衡问题。
• 各个区域之间完全独立，不支持跨区域迁移，其中一个区域集群发生故障，虚拟机不能疏散到另一个区域集群中。
• Keystone成为最主要的性能瓶颈，必须保证Keystone的可用性，否则将影响所有区域的服务。该问题可以通过部署多Keystone节点解决。

OpenStack多Region方案通过把一个大的集群划分为多个小集群统一管理起来，从而实现了大规模物理资源的统一管理，它特别适合跨数据中心并且分布在不同区域的场景，此时根据区域位置划分Region，比如北京和上海。而对于用户来说，还有以下好处:

• 用户能根据自己的位置选择离自己最近的区域，从而减少网络延迟,加快访问速度。
• 用户可以选择在不同的Region间实现异地容灾。当其中一个Region发生重大故障时，能够快速把业务迁移到另一个Region中。

但是需要注意的是，多Region本质就是同时部署了多套OpenStack环境，确切地说并没有解决单OpenStack集群的大规模部署问题。

3.OpenStack Cascading方案以及Trio2o项目

OpenStack Cascading方案[9]是由国内华为提出的用于支持场景包括10万主机、百万虚机、跨多DC的统一管理的大规模OpenStack集群部署。它采取的策略同样是分而治之，即把原来一个大的OpenStack集群拆分成多个小集群，并把拆分的小集群级联起来统一管理，其原理如图：

• 只有最顶层的OpenStack暴露标准OpenStack API给用户，其包含若干个子OpenStack集群。
• 底层的OpenStack负责实际的资源分配，但不暴露API给用户，而必须通过其之上的OpenStack调度。

用户请求资源时，首先向顶层OpenStack API发起请求，顶层的OpenStack会基于一定的调度策略选择底层的其中一个OpenStack，被选中的底层OpenStack负责实际的资源分配。

该方案号称支持跨多达100个DC，支持10万个计算节点部署规模，能同时运行100万个虚拟机[10]。但该方案目前仍处于开发和测试阶段，尚无公开的实际部署案例。目前该方案已经分离出两个独立的big-tent项目，一个是Tricircle，专门负责网络相关以及对接Neutron，另一个项目是Trio2o，为多Region OpenStack集群提供统一的API网关。

4.Nova Cells方案

前面提到的OpenStack多Region方案是基于OpenStack环境切分，它对用户可见而非透明的，并且单集群依然不具备支撑大规模的能力和横向扩展能力。而Nova Cells方案是针对服务级别划分的，其最终目标是实现单集群支撑大规模部署能力和具备灵活的扩展能力。Nova Cells方案是社区支持的方案，因此本文将重点介绍，并且会总结下在实际部署中遇到的问题。

4.1 Nova Cells架构和原理介绍

Nova Cells模块是OpenStack在G版本中引入的，其策略是将不同的计算资源划分成一个个Cell，并以树的形式组织，如图所示：

图2 Nova Cell架构<