OpenStack大规模部署详解_openstack大规模部署资源-CSDN文库

105 浏览量 2021-01-27 13:34:40 上传评论收藏 559KB PDF 举报

资源详情

资源评论

资源推荐

OpenStack大规模部署详解大规模部署详解

0.前言

2018的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环境，其架构如下：

本内容试读结束，登录后可阅读更多

下载后可阅读完整内容，剩余7页未读，立即下载

评论0

内容反馈

weixin_38694674

粉丝: 6
资源: 972

最新资源

资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！点击此处反馈

feedback-tip