OpenStack商用开放性和定制化的七颗龙珠

作者：北京小武 2015-12-31 10:45:00

云计算

OpenStack 由于OpenStack各个组件成熟度不一、底层Driver技术完善度不同，特别是Neutron，所以任何基于OpenStack玩云计算的厂家，都面临一个问题：在日新月异的OpenStack开源代码下，如何发布自己稳定的发行版并通过快速迭代跟上社区的步伐?

OpenStack是一个开源云计算管理平台(确切来说是平台框架)，现在很多厂商都基于OpenStack来结合相应Linux操作系统(CentOS、SUSE或Ubuntu等)来做公有云或私有云的云计算操作系统，比如华为、海云捷讯、UnitedStack、九州云等;当然每个厂商做法不同，比如Redhat的RDO完全开源，而且其云计算管理平台的投入不仅仅是OpenStack。

由于OpenStack各个组件成熟度不一、底层Driver技术完善度不同，特别是Neutron，所以任何基于OpenStack玩云计算的厂家，都面临一个问题：在日新月异的OpenStack开源代码下，如何发布自己稳定的发行版并通过快速迭代跟上社区的步伐?

软件开源码和硬件开架构确实是最近技术界的趋势，非常有利于技术共享和积累传播，也为初学者提供了大量的细节资料，从而在开源基础上构建生态圈来打破私有封闭性;但是大家不得不面临的一个问题是，开源的实现相当一部分源码考虑的是可行性及Demo级别的实现(当然也有一些实现非常优良)，达到商用级别通常需要内部加固和优化;即对于OpenStack而言都需要在保持OpenStack开放性的同时，不断增强底层实现;那么就会面临发行版和开源社区版本有很多不一致的地方，这个是否破坏了OpenStack的开放性哪?

首先客户为什么需要云计算平台有开放的架构哪?和SDN非常类似，因为云平台涉及存储、计算和网络等等硬件设备的选型及采购，每一家云平台的搭建过程厂商都是一个集成商角色，无论其自己是否能对云平台所需的硬件设备和软件工具来自产满足，云平台的开放性便于其不断的特性叠加或升级;而当云平台厂商需要购买大量硬件设备或软件工具搭建云平台时，不希望这些被一家提供商控制，而是在整体架构解耦的条件下将每个模块拆分而分别多个提供商竞标，这样来降低总体成本和对特定厂商的依赖性。

那么这里还要区分下开放性是什么，开放性应是通过标准的API和文档说明等手段，让周边生态圈能很容易构建，这个和开源有很大的不同;这点和网络中使用网络协议来使得不同厂商的交换机能够互通和兼容是一致的(举个例子，现在Neutron中用Vxlan做隔离时，Vxlan协议RFC中UDP的DPort标准值使用4789，但是并不是强制的而是可以配置选择的，Neutron中通过 vxlan_udp_port配置项来生效，对OpenvSwitch控制)，SDN的特点之一也是有开发的北向接口和标准的南向接口，说白了也是要SDN及其网元有开放性。换句话说，OpenStack只是通过Plugin/Driver的方式提供了一个整体解耦的架构，但是其底层实现需要各家厂商自己选择、优化甚至重新实现，这个也是OpenStack提供这种架构的初衷，以及得到这么多厂商和开源爱好者支持的很大一个原因，虽然开源社区也提供了基础的实现，不过目的多是体现思想和趋势方面的东西。

所以OpenStack开放性个人认为若能够保证这种解耦的框架和一致的北向接口，对于OpenStack的开放性即便是有了保证，而无需和社区实现保持一致;实话而言，任何一家厂商都没有办法与社区发布的相应版本实现保持完全一致，这个也是没有必要的。而厂商对OpenStack的优化有着非常大的意义，下面通过优化手段来具体谈下相应作用的理解：

第一，OpenStack运行稳定的基础是服务器操作系统，所以必须有一种稳定的操作系统来对OpenStack的运行提供保障;任何一家OpenStack厂商都要选择一种操作系统来集成，操作系统现在基本都是某种Linux发布版，而优化则主要是计算节点针对Hypervisor层、网络节点主要针对协议栈等对Linux Kernel进行选型，并不断升级其Patch或新特性来加固;

第二，OpenStack整体框架的优化是其可用性方面的基础，主要包括OpenStack管理面和控制面的性能和高可用方面的优化，这方面为OpenStack的商用稳定性及大规模可扩展等提供了必要性;

第三，使用稳定且成熟的Plugin和底层Driver实现，为OpenStack的底层提供了有效的集成，尤其是Neutron的现状来看，必须要进行大量的优化和加固才能商用，包括Iptables的性能、L3 router的性能及高可用、OpenvSwitch等，例如Dvr等特性很多厂商都还没有使用;必须为Neutron提供可商用的底层Driver实现，才能Hold住网络的高可用和高性能，包括集成SDN架构、Driver用硬件网元实现相应的网络功能等;

第四，第三方工具或平台的集成，一方面包括底层实现各种特性的辅助工具比如多种虚拟化资源池融合、统计和计费平台集成等，网络方面还包括Haproxy、防DDos攻击设备、安全防护等方面集成等，都为OpenStack的商用保驾护航;而对客户而言(尤其是私有云)则是流程IT的集成，包括其已有的审批流程和工单系统等;

第五，OpenStack商用平台必须有不断的合并Patch和新特性的能力，来保持OpenStack的安全性和稳定性，并不断满足用户的新需求;这点和Linux的发行版类似，Linux的内核厂商除了对其内核编译优化外，也提供不断的补丁升级等维护服务;

第六，OpenStack的运行必须与传统DC内的监控及运维向结合，才能让云平台运维人员对OpenStack良好的运维能力;OpenStack的复杂性对传统的运维人员来说是个压力，对运维人员的技能有较高的要求，如何将已有的工具尽快结合或开发新的适用工具，是运维人员对OpenStack云平台运维需要回答的问题;从Devops角度讲，也是运维人员将已有云平台工具快速复制部署，为实现运算稳定运营提供了重要保障;

第七，OpenStack的部署升级需要通过专业的工具来保证其平滑性，是上线业务对云平台的诉求;现在公有云或私有云的规模越来越大，部署时不通过专业的工具，非常容易出错，以及后续的升级也是很困难;

所以从上面七点(为什么是七点，因为集齐七龙珠有神龙)意义上说，OpenStack 保持标准API北向(可以适当扩展补充但需兼容)、稳定的架构框架和持续集成能力，是对OpenStack商用落地很多客户提出的要求。

而那些非开源的云计算操作平台或云计算操作系统(典型的有UCloud/AWS/阿里云等，其他国内知名云计算厂商的公有云和私有云大多是基于OpenStack)，如果是北向API等能够保持足够开放性，也并不会对其生态圈构建有太大的技术妨碍;只是当大家都关注OpenStack并为其做嫁衣时，会没有精力再投入到其他云平台上而已。

【本文来源：KVM虚拟化实践微信公众号】