OpenStack大规模部署详解 _虚拟

作者简介：付广平，云极星创研发工程师。
0.前言
今年的2月22日，发布了15个版本Ocata 。
走过了7年的发展岁月的已经成为了云计算领域中最火热的项目之一，并逐渐成为IaaS的事实标准，私有云项目的部署首选。社区可能自己都没有想到其发展会如此之迅速，部署规模如此之大，以至于最开始对大规模集群的部署支持以及持续可扩展性似乎并没有考虑完备。
众所周知，每一个项目都会有数据库的访问以及消息队列的使用，而数据库和消息队列是整个扩展的瓶颈。尤其是消息队列，伴随着集群规模的扩展，其性能下降是非常明显的。通常情况下，当集群规模扩展到200个节点，一个消息可能要在十几秒后才会响应，集群的整体性能大大下降[1]，英国电信主管Peter 声称一个独立集群只能最多管理500个计算节点[2] 。
当处理大规模问题时，我们自然会想到分而治之策略，其思想是将一个规模为N的问题分解为K个规模较小的子问题，这些子问题相互独立且与原问题性质相同，解决了子问题就能解决原问题。社区提出的多、多Cells以及等方案都是基于分而治之策略，但它们又有所区别，主要体现在分治的层次不一样，多和方案思想都是将一个大的集群划分为一个个小集群，每个小集群几乎是一个完整的环境，然后通过一定的策略把小集群统一管理起来，从而实现使用来管理大规模的数据中心。在版本引入的Nova Cells概念，其思想是将不同的计算资源划分为一个个的Cell，每个Cell都使用独立的消息队列和数据库服务，从而解决了数据库和消息队列的瓶颈问题，实现了规模的可扩展性。遗憾的是，目前社区还没有一个非常完美的大规模部署方案，以上提到的方案都存在各自的优点和缺点，实际部署时应根据物理资源的分布情况、用户资源需求等因素综合选择。本文接下来将谈谈大规模部署问题，讨论前面提到的各个方案的优缺点以及分别适用的场景。
1.单集群优化策略 1.1 使用独立的数据库和消息队列
前面提到限制规模增长的最主要因素之一就是由于数据库和消息队列的性能瓶颈，因此如果能够有效减轻数据库以及消息队列的负载，理论上就能继续增长节点数量。各个服务使用独立的数据库以及消息队列显然能够有效减小数据库和消息队列的负载。在实践中发现，以下服务建议使用独立的数据库以及消息队列:
1.2 使用 Token
前面提到每当 API收到用户请求时都需要向验证该Token是否有效，Token是直接保存在数据库中的，增长速率非常快，每次验证都需要查询数据库，并且Token不会自动清理而越积越多，导致查询的性能越来越慢，验证Token的响应时间会越来越长。所有的服务都需要通过服务完成认证，的性能下降，将导致其它所有的服务性能下降，因此保证服务的快速响应至关重要。除此之外，如果部署了多节点，还需要所有的节点同步Token，可能出现同步延迟而导致服务异常。为此社区在Kilo版本引入了 Token，与UUID Token以及PKI Token不同的是它是基于对称加密技术对Token加密，只需要拥有相同加密解密文件，就可以对Token进行验证，不需要持久化Token，也就无需存在数据库中，避免了对数据库的IO访问，创建Token的速度相对UUID Token要快，不过验证Token则相对要慢些[3] 。因此在大规模集群中建议使用 Token代替传统的Token方案。
以上优化策略能够一定程度上减少消息队列和数据库的访问，从而增大节点部署规模，但其实并没有根本解决扩展问题，随着部署规模的增长，总会达到瓶颈，理论上不可能支持无限扩展。
2.多方案