多openstack集群管理和nova-cell使用
3.2.2 Openstack Tricircle方案 11
多openstack部署
1引言
1.1编写目的
一个openstack系统，当计算规模不断扩大的时候，就会出现很多性能的问题，比如队列性能下降，比如数据库性能下降等。
另外面对多个不同的数据中心，每一个数据中心部署一个openstack的时候，就会出现怎么管理多个数据的问题。
本文档就会主要讨论下这两种情况下的具体解决方案
2总体设计
2.1整体架构
2.1.1 单openstack节点性能问题解决方案
-
nova-cell v1 方案
-
nova-cell v2 方案
2.1.2 多openstack节点性能问题解决方案
-
region多个openstack独立公用keystone
-
cascade方案的多openstack管理
-
Tricircle组件实现多个openstack 统一管理
3详细设计
3.1单openstack扩容管理
3.1.1 nova-cell 原理
一般情况下 nova需要依赖一个逻辑的的数据库和消息队列来进行组件之间的相互交换，这就会给整个系统的扩容和灾难迁移带来困难。而数据库和消息队列正在成为openstack扩展的瓶颈。尤其是消息队列，伴随着集群规模的扩展，其性能下降尤其明显。通常当集群规模扩展到200个节点，一个消息可能要十几秒后才会响应，集群的整体性能大大下降。针对nova的这个问题，提出了nova-cell的概念，这个概念的提出主要是把计算节点分成更多个更小的单元，每一个单元都有自己的数据库和消息队列。
nova-cell 的发展过程中出现过v1版本和v2版本，其中v1版本的被接受情况一致不理想，v2版本是基于v1的教训，提出的一个权限的架构，不过可惜的是v2版本的代码至少也要等到N版本才会发布，所以现在还暂时只能使用v1版本的nova-cell组件
3.2.1 nova-cell v1 使用
使用
nova-cell采用树状结构来组织管理各个cell之间的关系，会有一个专门的组件叫nova-cell来进行消息沟通。各个cell之间现在只支持消息队列来进行交互同步。有两种类型的nova-cell
-
api 类型的nova-cell 节点，也有称之为top cell的。里面会安装有 database、mq、nova-cells、nova-api、keystone
-
compute类型的nova-cell 节点，也称之为child cell。里面会安装有 database、mq、nova-cells、nova-scheduler、nova-compute、nova-conductor
nova-cells 组件主要是负责cell之间的消息通信和创建vm的时候选择cell。这个组件是每个cell必须要安装的。cell的调度和vm的调度是不同的。nova-cells 首先选择一个cell，一旦这个cell被选上后，当创建vm的请求到达这个cell后，cell中的nova-scheduler会继续原来的调度过程发送到具体的某个计算节点上。
缺点
v1版本的nova-cell存在很多的问题主要是：
-
不支持安全组、主机集合、可用域、特定的调度算法
-
一个nova-cells需要做两件事情的调度，既有内部的也有各个cell之间的
-
资源竞争问题
-
一直没有推动起来，导致该模块成熟度低，使用率低
-
如果之前没使用nova-cell。重新准备使用nova-cell会比较困难
-
并且最顶层的那个top cell 还是无法扩展，仍然存在问题
-
各个层之间的数据复制
3.2.2 nova-cell v2 使用
使用
为了避免v1的问题，v2一开始就提出了几个明确的目标
-
数据只可以放在一处
nova-api cell 中使用新的数据库和以往不同，并且存放公共的数据，cells、vm、computes 之间的映射数据也存放在nova-api cell中
-
公共数据越少越好
nova-api cell 防止mapping数据，其他vm的大量数据都放在具体的cell内，避免当重新添加一个cell的时候大量的数据复制
-
全力支持nova-cell
nova全面支持nova-cell，在N版之后，默认就会使用nova-cell 而不是可选安装了，并且支持所有的功能，没有功能受到限制，另外还有一个默认的cell0，用来处理其他cell节点不能处理的请求
最新的v2结构已经不是树状的了，而且没有了nova-cells这个组件
主要使用过程如下图：
缺点
最快也要N版本才可以使用v2版本，而且很多的功能还在开发：
-
支持neutron的全部功能
-
支持多cell 个人理解就是 cell的ha
-
更多的调度控制
-
v1到v2的升级工具
3.2多openstack节点管理
3.2.1 region管理openstack
原理
region主要是为了区分地理位置上分开的两个openstack节点，用户可以选择离自己更近的region来使用里面的资源。每一个region都是一个单独的openstack 部署环境，region之间完全隔离，但是多个regions之间共享同一个keystone 和 dashboard
优点
-
部署简单，keystone中直接指明不同region就可以实现
-
逻辑概念清晰，并且已经在生产中大量的使用
缺点
-
openstack 节点之间相互隔离，不能互访
3.2.2 Openstack cascading方案
openstack cascading 方案的主要架构图：
原理
cascading openstack 屏蔽了底层的多个openstack节点，对外只体现出有一个 openstack节点，可以实现对多个openstack的集成，和openstack规模的随意扩展。比如一个跨地域跨数据中心的云中存放有上千万级的vm在运行，那么就特别适合多个openstack的统一管理
从架构图上可以看出：
-
最上层的openstack节点，暴露出标准的 openstack api，这个openstack节点被称为cacading openstack，主要是提供api、调度和编排管理下面的openstack节点，管理下面的子openstack节点也是使用 标准的openstack api
-
下层的openstack节点，也被称之为cascaded openstack。主要负责创建虚拟机、存储卷、网络等资源。
-
每一个cascaded openstack 在cascading openstack 里面都表现为一个可用域，并且对用户是不可见的
openstack cascading方案又被称为 " openstack管理openstack " ,cascading多个openstack节点以后，用户只需要访问一个api 的endpoint就可以实现把用户的虚拟机创建分布在多个openstack上面，对用户而言 cascading openstack就相当于是一个虚拟的 region ，而多个后端的openstack 在用户看来就是多个 available zones 可用域。可以形象的把 cascading openstack 比如我们经常说的openstack 控制节点，把下面的多个openstack比如 openstack的计算节点。
技术实现上主要是使用了openstack的driver机制：
如上图的 红色表现部分，原来的nova 对接的 driver 现在替换成了下层的openstack nova-api组件，类似的还有 neutron 的plugin 替换成了下层的 neutron-api ，其他组件也是类似。当然这中间需要有一个proxy 来实现上层的nova 请求 proxy到 底层的 nova-api，类似的neutron 也需要一个 network proxy 来实现上层的neutron-api请求能转发到下层的openstack neutron-api中，类似下面的实现图：
可以看到 cascading openstack 和 下面的cascaded openstack之间有一大片的黄色 proxy:
-
Nova-proxy 类似之前nova中的 kvm driver或者 VMwaredriver，不过现在对接的是另一个openstack 的nova
-
Cinder-proxy 类似之前的cinder-volume driver 现在的后端存储用的是另一个openstack
-
L2-proxy 类似之前的ovs-agent
-
L3-proxy 类似之前的dvr l3-agent，不过使用的是后端的neutron
-
Fw-proxy、lb-proxy、vpn-proxy
这些proxy就是刚才原理中说的实现 上层的组件通过 driver 来使用下面的opentack的 driver实现。具体的实现代码可以在github上找到：
https://github.com/openstack/tricircle/tree/stable/fortest
偶
官方号称：
-
只有大概1万5千行代码实现了openstack cascading方案
优点
-
官方号称最大支持100个数据中心、1百万个compute、1百万个vm
-
可以集成多个openstack环境，甚至非openstack环境，比如搭建混合云
-
屏蔽底层，统一的api，共用网络、flavor、镜像等资源
-
能实现在两个云之间来回的迁移，甚至是不同的云之间用v2v工具实现
-
网络可以自动实现大二层和3层之间的跨多个云互通
缺点
-
网络方面主要还是依赖 vxlan、mpls 等类似的封包协议来实现跨地域的互通
-
华为只在一个东京的poc项目中使用过，其他项目暂时未发现有人使用
-
由于neutron cascade使用了provide network，而horizon上面只有管理员支持，但是参数不是我们想要的，所以创建网络只能用cli 命令创建
-
现在只支持到J版本
-
L2层多openstack互通，目前只支持vxlan,并且只支持vm之间的点对点通信，l2网络通过l2 GW来减少arp风暴
-
Cascading openstack 的api 管理属于有状态的请求，所以扩展会不方便
安装
-
不带glance cascade的安装部署图
- 带 glance cascade的安装部署图
3.2.2 Openstack Tricircle方案
原理
当openstack cascading 方案发展的时候，社区就决定把这一部分实现逻辑单独拿出来，并新开了一个项目就是Tricircle，可以说Tricircle就是openstack cascading的加强版
所以Tricircle的原理和cascading基本相同，主要实现原理如下图：
和cascading的主要区别是：
- 多个openstack可以属于一个可用域
- 每一个openstack被称之为一个pod
- 上层的openstack也是通过 openstack api和底层openstack互通
- Tricircle使用 stateless 机制，更利于扩展节点
- 实现机制Tricircle 更加类似 nova-cell的机制，不过nova-cell是只扩展了nova，而Tricircle则是所有的组件都进行了扩展
也是使用原来 openstack中的 driver机制来实现 上层的openstack管理下层的openstack
不过是这次的driver 不叫 proxy 了而是叫做 api-gw比如：
场景
-
边界云部署
无论哪个城市的上传视频都到固定的集中节点，会造成性能下降和流量的浪费
正确的应该如下图：
使用就近原则，某个城市的只上传到本地的云中，后期云之间可以进行同步等操作
-
灵活的服务链
跨多个云的灵活的服务链功能
优点
-
多个openstack节点的集成可能会造成api调用的性能的下降，Tricircle因此提出了使用异步的XJob来进行api的请求响应
-
无状态的api调用，支持混合云部署
安装
Tricircle项目可以在github上找到：https://github.com/openstack/tricircle
代码结构如下图：
可以使用 pip方式来安装，主要的安装可以参考：
https://github.com/openstack/tricircle/blob/master/doc/source/installation.rst
4综述
总结上面的几个方案可以有如下的结论：
-
针对单个openstack我们可以使用nova-cell组件来只是提供nova的扩容，也就是实现nova使用的mq和database扩容，其中nova-cell v1版本一直在社区代码中包含，但是实现上有问题，为了避免这些问题，并且强制推广nova-cell的概念，社区又提出了nova-cell v2的概念，并且要求N版本以后必须强制使用，只可惜M版本的时候还没用正式release
-
针对多个openstack的集成，可以分为两个类别
-
多个openstack只共用dashboard和keystone，其他组件全部相互独立，这个就是大家熟悉的region的概念，十分成熟，horizon也支持
-
另一个类别是多个openstack 被屏蔽到下层，而上层单独有一个负责api路由的逻辑openstack节点，用户只会用这个逻辑的openstack 控制节点来管理底层所有的openstack节点，而且底层的openstack节点可以是不同的版本，甚至不一定是openstack，而这个功能前期被称作openstack cascading，发展到后来作为了一个独立的项目叫Tricircle，两个项目比较起来无论是代码上还是成熟度、还是社区支持都是Tricircle好点
