技术照进现实，OpenStack企业级应用的五大难解之结

开源的 OpenStack 作为最火热的企业云数据中心云平台管理框架，受到了企业的日益关注并且获得了大量的企业级应用实践，在产业互联网发展进程中占据了越来越多的份额。

但是在实践中，由于 OpenStack 属于知识密集型的开源产品，在企业部署、使用和运维的过程中，往往会遇到各种挑战。

技术照进现实，企业级应用尚存难解之结

目前，OpenStack 在企业应用过程中主要有五个问题：

产品化不足，无法完全满足企业用户的需求

OpenStack 架构层面的设计倾向于做公共云服务，因此对于很多企业级的特性未考虑或者考虑不充分，同时开源产品自身产品化能力较低，只提供了基础功能可用。而商业环境中的各项应用往往要求其拥有更加完善的运维和运营能力。

这就导致很多企业通过简单的搭积木形式利用 OpenStack 和各种辅助开源产品在企业中推进部署，使得 OpenStack 在很多场景下无法为企业提供有效的持续化服务。

另一方面，OpenStack 的设计初衷更加偏向解决“ToC”的需求，在实际企业应用中，部门管理、统一认证、权限控制、工单申请审批、操作审计、计量计费、云上云下计算资源和存储资源的管理和监控等强需求功能缺乏足够支撑。

OpenStack 原生参考实现无法支持大规模网络

OpenStack Neutron 参考实现的网络模型，通过在每个计算节点和网关节点上利用 namespace 来进行 3 层转发和 DVR，在大规模集群时，命名空间会占用大量系统资源，同时命名空间的 TCP / IP 协议栈转发性能比流表效率低。

此外在参考实现中，使用了大量的 Agent（例如：neutron-openvswitch-agent，dhcp-agent，l3agent），当集群规模很大时，大量的 Agent 参与的 RPC 会成为瓶颈，并且大量的 Agent 运维也成为管理瓶颈。

OpenStack 对云平台运维人员要求较高，专业人才难寻

OpenStack 应用日益广泛，但是初始交付 OpenStack 云平台后，后期的运维通常需要一个专门的 OpenStack 团队来维护，需要计算、存储、网络、硬件和软件等多个方面的专家来共同合作，才能保证 OpenStack 云平台的后续正常运转。

而另一方面我们也能看到，目前 OpenStack 的人才可谓一将难求，相关人才的招聘和培养均需要花费大量的时间和资源，这样大部分企业用户很难自行培养组建出一支高水准、能力强的运维团队。

OpenStack 中云化数据库商业化不足

企业业务中对关系型数据库的需求是不可或缺的，随着数据中心的云化，云化的多租户的数据库也成为必然，社区的数据库功能目前其成熟度和可运维程度距离实际的商用需求和使用还有一定的距离。

版本升级问题

诸如企业内 OpenStack 版本升级“困难”等非技术问题也亟待解决，OpenStack 社区每半年会出一个新的版本，但是企业对业务稳定的要求远高于对版本的追求，每半年升级一次底层系统所带来的业务中断等问题，让企业更倾向于选择暂不升级。

但当企业两年后甚至更长时候后升级平台， OpenStack 已经更新了多个版本，容易造成无法升级的局面。

多角度出发，推动 OpenStack 技术与产品演进

OpenStack 本身来说仅仅提供了基础的计算、存储和网络能力，但是在实际交付中，单纯的 IAAS 资源提供无法满足用户的业务价值需求，它需要做大量的周边工作。

例如，虚拟机/容器和数据的安全、虚拟机/容器和数据的灾备、数据的同步、与大数据系统的交互、与 PaaS 平台的配合，应用的弹性，VM/容器的自动弹性伸缩、提供成熟的云化关系型数据库、传统数据库的使用，以及和不能云化的资源互访等等。

每一个需求都意味着大量的工作和知识领域的扩充，对提供云服务的厂商提出了更高的技术要求和架构设计要求。

在产品化和商业化方面，例如如何快速进行大规模部署，如何在大规模集群下保证管控节点、计算节点和网络节点的高性能和高可靠性，如何在发生各种故障时系统自动恢复和修复，如何实现 OpenStack 云数据中心云上和云下资源的监控、审计、告警、自动化或半自动化运维，如何进行 OpenStack 云数据中心的平滑扩容等等。

对于大量云计算技术力量相对薄弱的企业来说，使用成熟的产品和服务，远比独立推动 OpenStack 的建设和部署更为有效，想把 OpenStack 用好、用到位，则必须通过相关厂家将其进行产品化开发，企业才能真正方便经济的使用起来。

以笔者所在的研发与产品团队为例，团队成员大多拥有多年同客户共同探索数据中心核心场景需求和相关产品技术研发的经验。

近年来针对 OpenStack 的企业级应用和产品化也进行了大量技术研究和深入开发，已可以为用户提供完整的计算、存储（块存储和对象存储）、网络（SDN）、云化关系型数据库、PaaS 和灾备等服务。

同时核心成员也积极参与到了 OpenStack 社区技术研发当中，最大程度贡献了自己的力量。

图1：数梦工场 OpenStack 产品架构一览

深入参与社区 OpenStack SDN 技术研发

图2：SDN 技术框架

图3：优化的网关架构

前文提到的业内解决 Neutron 问题的主要办法是使用 SDN 来进行虚拟网络和物理网络的管理，并通过 OpenFlow 流表形式指导转发，减少或不再使用各种 Agent。

但是目前常见 SDN 设计均采用首包上送控制集群进行处理，在大规模集群场景下，大量的首包上送会造成对控制集群的大流量冲击，同时控制集群的 GC 问题也会造成集群的不稳定。

并且控制集群采用 OpenFlow 远程下发流表到各个计算节点和网络节点，又占用了大量的带内/带外带宽，所以在实际大规模集群中会遇到很多问题。

我们 SDN 团队开发和实现了分层 SDN 控制器，有效的避免了上面常见 SDN 方案遇到的问题，有效的支持了大规模企业云数据中心的建设。

它完全使用 X86 服务器作为云数据中心网络设备，传统交换机仅仅作为纯 2 层和 3 层转发，构建了极简的云数据中心，各种云网络服务可以快速实现和更新，网络服务更灵活。

并且根据实际交付经验，细化了网关角色，更加适应企业级大规模数据中心网络需求。SDN 团队在 Networking-ovn 项目有一个核心 Core 成员，SDN 团队成员为 OVS、OVN、Networking-ovn 贡献了大量的代码和修复了多个问题。

可以跨越OpenStack和阿里公共云的混合云弹性伸缩服务

随着企业互联网化的深入，企业的云上业务大并发突发访问成为常态，但是基于企业专有云成本等考虑，不可能按照峰值配置资源，而公共云就成为临时弹性资源的不二选择。

我们团队基于 Senlin 项目开发了针对虚拟机和容器的跨云弹性伸缩能力。在大并发业务访问发生时，根据阈值优先在本地 OpenStack 云内弹性分配虚拟机或容器。

当本地计算资源不足时，自动在阿里公共云进行弹性分配，满足企业突发流量的业务需求。

图4：混合云弹性伸缩

OpenStack容器化，支持一键部署

OpenStack 各个组件是一个非常好的微服务架构设计，各个服务间通过 RestfulAPI 交付，只要 API 兼容，各个组件间理论上可以独立升级。

并且 OpenStack 各个组件运行基本上是无状态应用，配置和运行数据通过数据库存储，所以它进行 Docker 化是非常合适的。

目前我们 OpenStack 组件全部 Docker 化，通过 K8S 进行管理，同时支持一键式白屏化大集群部署。

图5：OpenStack 容器化

图6：OpenStack 一键式自动部署

有人说技术的发展就是在翻越一个又一个山峰，OpenStack 相比传统 IT 技术来说，在企业级应用中可以说才刚刚起步，仍有大量问题亟待找到更好的解决方案，也有大量的课题需要广大社区同仁和研发伙伴通过不断地“开脑洞”，来推动创新实践。

比如是否能够通过在框架中增加调用流程链路跟踪能力来降低运维难度，或是将微服务的理念移植到产品当中，这些也许都会变成 OpenStack 在企业级应用乃至产业云应用的新引爆点。

企业如何基于 OpenStack 构建云平台？更多 OpenStack 内容请查看“原文阅读”。

作者：葛建壮   数梦工场混合云产品线首席架构师

2005 年开始从事数据通信行业，拥有多年网络设计和开发经验。作为架构师完整参与设计和交付了多款业内领先的 SDN 产品和 NFV 产品。2013 年开始 OpenStack 相关研究，并持续关注和实践。2015 年加盟数梦工场，目前担任数梦工场混合云产品线首席架构师，负责数梦工场混合云产品线的产品规划和设计工作。

原文来自:51CTO技术栈

声明：所有来源为“聚合数据”的内容信息，未经本网许可，不得转载！如对内容有异议或投诉，请与我们联系。邮箱：marketing@think-land.com