【51CTO.com原创稿件】云数据中心已经成为当下企业数据中心建设的主流，各类公共云、专有云和混合云技术轮番登场。开源的OpenStack作为最火热的企业云数据中心云平台管理框架，受到了企业的日益关注并且获得了大量的企业级应用实践，在产业互联网发展进程中占据了越来越多的份额。但是在实践中，由于OpenStack属于知识密集型的开源产品，在企业部署、使用和运维的过程中，往往会遇到各种挑战。
技术照进现实，企业级应用尚存难解之结
目前，OpenStack在企业应用过程中主要有五个问题：
1.产品化不足，无法完全满足企业用户的需求
OpenStack架构层面的设计倾向于做公共云服务，因此对于很多企业级的特性未考虑或者考虑不充分，同时开源产品自身产品化能力较低，只提供了基础功能可用；而商业环境中的各项应用往往要求其拥有更加完善的运维和运营能力。
这就导致很多企业通过简单的搭积木形式利用OpenStack和各种辅助开源产品在企业中推进部署，使得OpenStack在很多场景下无法为企业提供有效的持续化服务。
另一方面，OpenStack的设计初衷更加偏向解决“ToC”的需求，在实际企业应用中，部门管理、统一认证、权限控制、工单申请审批、操作审计、计量计费、云上云下计算资源和存储资源的管理和监控等强需求功能缺乏足够支撑。
2.OpenStack原生参考实现无法支持大规模网络
OpenStack Neutron参考实现的网络模型，通过在每个计算节点和网关节点上利用namespace来进行3层转发和DVR，在大规模集群时，命名空间会占用大量系统资源，同时命名空间的TCP/IP协议栈转发性能比流表效率低。此外在参考实现中，使用了大量的Agent（例如：neutron-openvswitch-agent ,dhcp-agent，l3agent），当集群规模很大时，大量的Agent参与的RPC会成为瓶颈，并且大量的Agent运维也成为管理瓶颈。
3.OpenStack对云平台运维人员要求较高，专业人才难寻
OpenStack应用日益广泛，但是初始交付OpenStack云平台后，后期的运维通常需要一个专门的OpenStack团队来维护，需要计算、存储、网络、硬件和软件等多个方面的专家来共同合作，才能保证OpenStack云平台的后续正常运转。而另一方面我们也能看到，目前OpenStack的人才可谓一将难求，相关人才的招聘和培养均需要花费大量的时间和资源，这样大部分企业用户很难自行培养组建出一支高水准、能力强的运维团队。
4.OpenStack中云化数据库商业化不足
企业业务中对关系型数据库的需求是不可或缺的，随着数据中心的云化，云化的多租户的数据库也成为必然，社区的数据库功能目前其成熟度和可运维程度距离实际的商用需求和使用还有一定的距离。
5.版本升级问题
诸如企业内OpenStack版本升级“困难”等非技术问题也亟待解决，OpenStack社区每半年会出一个新的版本，但是企业对业务稳定的要求远高于对版本的追求，每半年升级一次底层系统所带来的业务中断等问题，让企业更倾向于选择暂不升级。但当企业两年后甚至更长时候后升级平台， OpenStack已经更新了多个版本，容易造成无法升级的局面。
多角度出发，推动OpenStack技术与产品演进
OpenStack本身来说仅仅提供了基础的计算、存储和网络能力，但是在实际交付中，单纯的IAAS资源提供无法满足用户的业务价值需求，它需要做大量的周边工作，例如虚拟机/容器和数据的安全、虚拟机/容器和数据的灾备、数据的同步、与大数据系统的交互、与PaaS平台的配合，应用的弹性，VM/容器的自动弹性伸缩、提供成熟的云化关系型数据库、传统数据库的使用，以及和不能云化的资源互访等等，每一个需求都意味着大量的工作和知识领域的扩充，对提供云服务的厂商提出了更高的技术要求和架构设计要求。
在产品化和商业化方面，例如如何快速进行大规模部署，如何在大规模集群下保证管控节点、计算节点和网络节点的高性能和高可靠性，如何在发生各种故障时系统自动恢复和修复，如何实现OpenStack云数据中心云上和云下资源的监控、审计、告警、自动化或半自动化运维，如何进行OpenStack云数据中心的平滑扩容等等，对于大量云计算技术力量相对薄弱的企业来说，使用成熟的产品和服务，远比独立推动OpenStack的建设和部署更为有效。想把OpenStack用好、用到位，则必须通过相关厂家将其进行产品化开发，企业才能真正方便经济的使用起来。
以笔者所在的数梦工场研发与产品团队为例，团队成员大多拥有多年同客户共同探索数据中心核心场景需求和相关产品技术研发的经验，近年来针对OpenStack的企业级应用和产品化也进行了大量技术研究和深入开发，已可以为用户提供完整的计算、存储（块存储和对象存储）、网络（SDN）、云化关系型数据库、PaaS和灾备等服务，同时核心成员也积极参与到了OpenStack社区技术研发当中，最大程度贡献了自己的力量。
数梦工场OpenStack产品架构一览
1.深入参与社区OpenStack SDN技术研发
SDN技术框架
优化的网关架构
前文提到的业内解决Neutron问题的主要办法是使用SDN来进行虚拟网络和物理网络的管理，并通过OpenFlow流表形式指导转发，减少或不再使用各种Agent。但是目前常见SDN设计均采用首包上送控制集群进行处理，在大规模集群场景下，大量的首包上送会造成对控制集群的大流量冲击，同时控制集群的GC问题也会造成集群的不稳定，并且控制集群采用OpenFlow远程下发流表到各个计算节点和网络节点，又占用了大量的带内/带外带宽，所以在实际大规模集群中会遇到很多问题。
数梦工场SDN团队开发和实现了分层SDN控制器，有效的避免了上面常见SDN方案遇到的问题，有效的支持了大规模企业云数据中心的建设。它完全使用X86服务器作为云数据中心网络设备，传统交换机仅仅作为纯2层和3层转发，构建了极简的云数据中心，各种云网络服务可以快速实现和更新，网络服务更灵活。并且根据实际交付经验，细化了网关角色，更加适应企业级大规模数据中心网络需求。SDN团队在networking-ovn项目有一个核心Core成员，SDN团队成员为OVS、OVN、Networking-ovn贡献了大量的代码和修复了多个问题。
2.可以跨越OpenStack和阿里公共云的混合云弹性伸缩服务
随着企业互联网化的深入，企业的云上业务大并发突发访问成为常态，但是基于企业专有云成本等考虑，不可能按照峰值配置资源，而公共云就成为临时弹性资源的不二选择。
数梦工场团队基于Senlin项目开发了针对虚拟机和容器的跨云弹性伸缩能力。在大并发业务访问发生时，根据阈值优先在本地OpenStack云内弹性分配虚拟机或容器；当本地计算资源不足时，自动在阿里公共云进行弹性分配，满足企业突发流量的业务需求。
混合云弹性伸缩
3.OpenStack容器化，支持一键部署
OpenStack各个组件是一个非常好的微服务架构设计，各个服务间通过RestfulAPI交付，只要API兼容，各个组件间理论上可以独立升级。并且OpenStack各个组件运行基本上是无状态应用，配置和运行数据通过数据库存储，所以它进行Docker化是非常合适的。
目前数梦工场OpenStack组件全部Docker化，通过K8S进行管理，同时支持一键式白屏化大集群部署。
OpenStack容器化
OpenStack一键式自动部署
有人说技术的发展就是在翻越一个又一个山峰，OpenStack相比传统IT技术来说，在企业级应用中可以说才刚刚起步，仍有大量问题亟待找到更好的解决方案，也有大量的课题需要广大社区同仁和研发伙伴通过不断地“开脑洞”，来推动创新实践。比如是否能够通过在框架中增加调用流程链路跟踪能力来降低运维难度，或是将微服务的理念移植到产品当中，这些也许都会变成OpenStack在企业级应用乃至产业云应用的新引爆点。
【作者简介】
葛建壮，2005年开始从事数据通信行业，拥有多年网络设计和开发经验；作为架构师完整参与设计和交付了多款业内领先的SDN产品和NFV产品。2013年开始OpenStack相关研究，并持续关注和实践。2015年加盟数梦工场，目前担任数梦工场混合云产品线首席架构师，负责数梦工场混合云产品线的产品规划和设计工作。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
