(转)Openstack Cascading和Nova Cell

Openstack是看着AWS成长起来的，这点毋庸置疑；所以AWS大规模商用已成事实的情况下，Openstack也需要从架构和产品实现上进行优化，以满足大规模商用的要求。从已有的实现来看其中两种方式值得借鉴：华为推出的Openstack级联方案和社区已有的Cell方案。在上海11月21号的Openstack Meeting up中华为高级架构师黄登辉的分享里也提及，华为公有云使用了级联架构。其中Cell方案（https://wiki.openstack.org/wiki/Blueprint-nova-compute-cells，http://comstud.com/GrizzlyCells.pdf）是从Openstack的G release版提出的新模块，Openstack级联方案(https://wiki.openstack.org/wiki/OpenStack_cascading_solution)提出时间稍晚，但更有优势。

Cell从其BP简单来说实现主要是通过根Cell（API-Cell）的Nova-API为整个Openstack的Nova-API，其他子Cell（ Child-Cell ）没有Nova-API服务，二者都有独立的AMQP Broker、Database、nova-cells等服务，全局服务有Keytone和Glance；Cell提出的背景有这么几点：

第一，Openstack的主机规模（主要是计算节点的数目，因为当时网络和存储分别还是Nova-network和Nova-volume，Neutron之后才出现）超过几百台后（英国电信主管声称只能管理约500个计算节点）在管理性能上就遇到了大的瓶颈，主要是MessageQueue使用RPC导致的，这点也反映了Openstack初期架构设计的“着急”（当然，这些不仅仅体现在RPC上，后续网络组件Neutron的管理协议更是体现了Openstack初期开源重实现不重商用的短板，但也反映了Openstack注重的是这种解耦式的架构和易集成平台，而不是底层确切的技术实现，所以也得到了尽可能多厂商的参与和支持）；

第二，上一点也提及当时版本还是G版，即当时网络和存储分别还是Nova-network和Nova-volume，并没有独立的组件，所以如果解决了Nova的管理瓶颈，也基本解决了网络和存储的管理瓶颈；所以推出Cell方式被支持是可以理解的；

第三，Nova有了层级概念后，其上层选择下层的调度算法应该多种多样，以满足客户多种场景的需求，但是这点Nova的调度算法当时还不是很丰富；

图1  Cell 架构示意图

级联架构提出的时候Openstack的基础组件基本都已完善，所以对于现在的Openstack考虑比较全面些，对重要的Openstack组件比如Nova、Cinder、Neutron、Glance以及Ceilometer等的处理都有考虑；Openstack级联支持规模场景包括10万主机、百万虚机等，真真实实的大规模部署。

图2 级联架构示意图

但Openstack的级联初衷解决的不是规模问题，而是跨多DC的多OS统一管理问题，这个需求是非常常见的，因为通常的云平台厂商部署时，会考虑多个多Openstack来考虑客户业务部署（比如灾备、CDN等），有这类需求的客户华为遇见很多。当然多个Openstack可以通过一个管理端来分别对多个Openstack通过北向API进行管理，但是这个管理端不仅无法整体协调管理资源（比如Neutron中Network的大二层部署无法被这种形式支持，只能每个Openstack一个Network，虚拟机无法直接L2互通，形成不了VPC），而且还破坏了Openstack的生态圈和API统一性，并且也导致无法将后续不断发展的社区特性或组件叠加到云平台上，包括Heat、Magnum等。

如果整套Openstack通过几个Cell共享存储Cinder和大二层网络Neutron打通，功能都是没有问题，但是多DC情形下的RPC通信会给运维、管理和Troubleshooting等带来问题；那么Cascading相比Cell到底有什么优势？

第一，级联架构适用于较多组件大规模部署时解决管理性能瓶颈；上文也提及，Cell只针对Nova做了实现，随着Neutron和Cinder等组组件从Nova中独立出来，已经不再适用Cell了，社区也暂时没有看到这方面的进展；所以如果用Cell实现大规模商用，Neutron和Cinder等组件的管理将成为性能瓶颈；而级联架构考虑了基本所有重要组件的级联架构，实现了整体管理性能的瓶颈突破；数据转发面将每个被级联层划分成一个L2的广播域，通过Underlay的L3打通不同的被级联层，实现大二层互联；而且每个被级联层Openstack也是一个故障隔离域，便于运维和定位问题；

第二，级联架构适用于混合云架构；按照公有云比如HWS平台作为公有云、而客户厂家自己是私有云的场景，可以将自己的私有云作为被级联层接入到华为的HWS平台（即HWS平台作为级联层），这样可以实现通过公有云平台来管理的混合云架构；

第三，级联场景适用多种云平台的异构云架构；上述第二点里提及的混合云场景中，客户的私有云作为被级联层可以是不用Openstack来实现的云平台，甚至可以是基于AWS或阿里云等厂家的云平台，从而实现异构云做跨厂商、跨云平台的整体管理解决方案；

第四，级联场景适合不同版本的Openstack的架构；基于Openstack的公有云或私有云管理平台，整体升级和版本兼容性成为可持续性的一个运维点，而级联模式下，被级联层的Openstack版本可以不同，甚至不同级联层的Nova的虚拟化资源可以是不同的虚拟化技术（比如KVM、ESXi、XEN、Hyper-v等等），而Neutron的底层网络实现也可以基于不同的底层网元或管理方式，甚至在不同的被级联Neutron对接不同的SDN Controller，从而实现更为开放的集成模式，更适于多加厂商的参与；

第五，级联架构具备更好的可升级性；由于Openstack级联架构具备良好的异构性，所以在Openstack升级的时候，可以对不同被级联层逐步升级，从而实现不影响业务的正常运行；所以Openstack级联技术架构下，基于Openstack的云平台具备良好的可升级性；

第六，级联架构具备更好的可扩展性；在单Openstack（没有使用Openstack级联场景）对底层服务器进行扩展除了规模有限制外，也需要导致Openstack管理节点的感知，从而存在潜在的风险；而使用级联技术时，先对被级联层进行部署完毕，甚至进行充分的测试后，再连接到级联层进行被管理，从这点来说，Openstack的级联技术更容易横向规模扩展，包括跨DC管理多个Region等，结合多AZ技术实现超大规模云主机的云平台。

当然Openstack级联实现也有些不足的地方，比如实现稍微复杂则需要云平台厂商技术人员有相应水平的技术能力，代码实现也需要更多的优化；所以不上规模的Openstack使用级联似乎性价比没有Cell高；而Cell的能力经过优化到1K台左右则会遇到明显的管理性能瓶颈，这点是不容置疑的，而不经过优化的Openstack云平台性能瓶颈更甚；当然一个私有云1K台物理机亦是不小的规模，但对于大规模公有云，还远远不够且需要更多的优化，而Openstack的级联则提供了一种选择，因为1K台物理机规模在Openstack级联模式下只是一个被级联层Openstack的规模（被级联层使用Cell方式也是一个值得考虑的场景）。

总体来看Openstack的现有实现版本，Cell只是局部的优化方式，而Openstack级联则是解决管理层性能方面的整体架构解决方案，且可商用；而结合社区来看Neutron中的Dragonflow/OVN等提出，已有在解决Neutron管理性能方面因素的考虑，而Dragonflow亦是由华为开源社区团队贡献的，如果后续实现Openstack级联和Dragonflow很好的结合，那么必定是华为对Openstack开源社区的又一重大贡献。

作者：李俊武 华为云计算网络架构和设计部

https://wiki.openstack.org/wiki/OpenStack_cascading_solution