为私有云结庐而做“隆中对”（下）

编者按：本文系 InfoQ 中文站向 ZStack 项目创始人张鑫的约稿。2015 年 4 月正式对外开源的 ZStack 项目宣称要解决在 OpenStack 中得不到解决的问题，并明确将项目目标指向目前前景似乎越来越不明朗的私有云市场。作为 ZStack 项目的架构师、CloudStack 的前开发人员，张鑫对于私有云——或者说 on-premise 的企业 IT——到底遇到了什么问题、此类服务到底应该怎么做，是如何构想的？本文将分享他对这个话题的思考。

写在前面：由于企业私有云市场迟迟未打开，近两年来已有多家 IaaS 企业被廉价收购甚至倒闭，业界已经开始出现一种质疑私有云是伪命题的声音。在此，作者想借 ZStack 发布的机会，梳理一下私有云的过去和现状，并展望一下它的未来。

私有云为什么还没有成功

我们知道私有云市场的四位先行者——Eucalyptus、CloudStack、OpenNebula 已渐渐淡出市场，OpenStack 虽然比较火爆但也迟迟打不开企业市场。作者认为造成这个结果的原因是，起步时过度依赖 Amazon EC2 模式，没有正视市场需求，以及没有按用户场景合理使用新技术。

上述几个 IaaS 软件在起步的初期，都没有什么前人的经验可以借鉴。没有人知道设计这么一个分布式的集成系统，面临的挑战在哪里，都有哪些坑要填。于是所有 IaaS 软件都处于一个在功能上模仿 Amazon EC2、在架构上自然生长的状态。由于当时市场空白较大，各家都急于上马 IaaS 项目，开发的推动力在于快速实现 EC2 的功能，在架构方面思考较少，为未来不同需求留下的架构冗余也不多。当整个 IaaS 软件发展到中后期，开发者们试图根据传统企业的真实需求进行架构变更时，才发现架构重构已经难以进行。

Eucalyptus 因为全面模仿 Amazon EC2 模式，其方案一直难以定制；而 CloudStack 虽然针对传统企业的差异需求进行了变更的尝试，但结果却是新版本软件越来越不稳定。OpenStack 则干脆主动忽视这一市场需求；OpenStack 社区本身就有很强的声音拒绝传统应用带来的需求。例如《Keep OpenStack Weird》一文就呼吁 OpenStack 拒绝为传统应用改变，而要求企业必须进化以开发出适应 OpenStack 的应用。Gartner 在文章《Why vendors can’t sell OpenStack to enterprises》就明确指出拒绝拥抱传统应用生态是 OpenStack 无法打开企业市场的一个重要原因。

IaaS 在公有云的蓬勃发展带动了相关领域的创新，SDN（软件定义网络）、SDS（软件定义存储）应运而生。的确，这些新技术的出现都是为了解决传统技术所面临的一些问题，但这些问题往往在公有云和大规模数据中心比较明显。例如公有云对网络隔离的需求，要求隔离技术能突破传统 VLAN 最多 4096 个的限制；存储技术要求能够实现分布式、多写备份以及动态扩容等。对于传统企业来说，这些技术往往既没必要也不稳定。当前一些私有云厂商，在向客户推荐解决方案时过分推销新技术，例如明明客户只需要传统的扁平网络，却硬要客户部署 SDN；明明客户对存储动态扩容没有需求，使用传统的 NFS + RAID 备份就已足够，却推荐客户部署分布式存储。客户项目上马后，在日常使用中长期遇到不稳定、难维护的问题，渐渐对私有云失去信心。OpenStack 社区蓬勃发展后涌入的大量硬件厂商，从自身利益出发提交了很多兼容性不好的代码，造成 OpenStack 某些核心组件不稳定（例如 Neutron），也在一定程度上加剧了客户对私有云的不信任。

私有云未来应该怎么做

对于未来私有云的发展，作者认为关键在于：开发出能拥抱传统应用生态的商业模式，专注于用户场景，控制软件投入风险，向上融合走整体解决方案路线。

1、开发出能拥抱传统应用生态的商业模式

要想打开传统企业市场，私有云厂商要正视已是既成事实的传统应用生态。虽然未来的企业应用必将进化成亲和现代 IaaS 架构的云应用，但在此之前，我们不得不兼顾企业已在传统应用上的投入。兼顾的方法是在虚拟化方面学习 VMWare，在网络模式和上层服务向 Amazon 靠拢。VMWare 凭借多年来在企业虚拟化方面的积累，开发出了很多满足传统应用需求的功能，例如在管理上以虚拟机为中心、虚拟机高可靠、专有资源配置等。私有云提供商的 IaaS 软件要么开发出类似功能，要么直接集成 VMWare 作为虚拟化解决方案。在网络方面，Amazon 的很多网络功能已经成为云计算领域的事实标准，例如 VPC、EIP、Security Group、ELB 等都广受用户欢迎。私有云 IaaS 软件要将这些服务进行整合，以实现传统应用的各个网络场景。此外，由于全世界的公有云几乎都遵循 Amazon EC2 模式，在网络上靠拢 Amazon 能够很容易帮助客户搭建混合云（hybrid cloud），打通用户在公有云和私有云中的业务。最后，Amazon 很多 IaaS 之上的功能例如 Auto scaling、CloudFormation、CloudWatch 等都是解决用户痛点的创新，私有云 IaaS 需要能够提供类似的功能。

2、专注于用户场景

专注于用户场景要求私有云提供商从用户的应用场景出发，推荐符合用户需求的解决方案，一切以稳定优先。以网络为例，无论是 SDN 还是传统技术，最后面对的还是 OSI 的 7 层模型。在 IaaS 层面就是 L2 隔离，L3 子网加路由，L4~L7 应用层协议，应用场景是非常明确的。对于企业用户，可能只需要数目有限的私有网络，那我们就可以推荐用传统的 VLAN 来进行隔离；对于一些服务提供商，要求网络拓扑能够灵活按需变化，那我们就可以推荐使用 SDN 来实现路由。又例如存储，企业用户的场景往往是容量可以预估，稳定性可靠性要求高，那我们就可以推荐成熟的、基于传统协议的商业存储；如果面对的是服务提供商，数据量可能会爆炸增长的，那我们就应该推出类似于 Ceph 这样的分布式存储。

3、控制软件投入风险

IaaS 软件是集成技术，必然会引来各种第三方厂商要求进行集成。私有云提供商要对自家 IaaS 软件在这方面的投入进行控制，不能沦为第三方厂商的集成器，把主要精力浪费在下层系统的集成中。愿意部署私有云的企业，往往都是有预算购买新硬件产品的。私有云提供商应该优先专注于集成最稳定、应用广泛的成熟产品，在向客户提供解决方案时，只推荐已验证过的第三方产品。并且要借助客户的力量，反推第三方厂商与自身集成。例如 CloudStack 中的很多硬件驱动就是其客户要求网络和存储厂商为 CloudStack 提供的。此外，要认识到在虚拟化、网络以及存储方面已经存在非常多的标准技术，而对标准技术的稳定集成已能够满足绝大多数企业客户的需求。

4、向上融合走整体解决方案路线

私有云的未来一定是向上层发展，实现 IaaS 和 PaaS 的融合。私有云的目的是为了将用户从基础架构中解脱出来，专注于业务创新。但在基础架构（IaaS）跟最终业务（application 或 SaaS）之间还有一层隔离，即软件的部署交付，目前人们称之为平台即服务（PaaS）。未来的私有云展现给用户的一定是一个最终平台，即不仅能够管理用户的基础架构，还能为用户部署和管理上层业务。我们不妨将 IaaS 和 PaaS 融合的平台看作是私有云的一个未来形态，如果说操作系统是传统软件的入口的话，那么未来企业软件的入口就是私有云。用户部署软件的方式将不再是到一个个操作系统里手动安装配置，而是软件商提交给用户的就是包含软件本身的操作系统镜像，通过支持私有云定义的接口，可以在镜像启动时导入下层基础设施信息，例如网络地址、网络磁盘路径以及软件配置信息，并且能在运行的过程中根据自身状态将数据反馈给 IaaS，实现基础设施层面的调整（例如启动更多的虚拟机）。目前已经有一些产品和项目在向这个方向努力，但都停留在跟 IaaS 第三方集成的层面上。由于 IaaS 本身不提供原生支持以及成熟度的问题，目前还没有好的解决方案。

总结

私有云要打开企业市场，不能再走早期单纯复制公有云的模式，而是要拥抱传统应用生态，走一条兼顾现实、着眼未来的道路，并最终向上发展，为企业 IT 架构提供一套完整的解决方案。

参考文章

1. 《Why OpenStack is different from other open source projects》
2. 《Keep OpenStack Weird》
3. 《Why vendors can’t sell OpenStack to enterprises》

作者简介

张鑫，2006 年加入 Intel 上海开源技术中心（OTC），从事开源虚拟机项目 XEN 的开发，为社区共享了多个功能，例如 XEN 中 E100 网卡模拟器，XEN/IA64 虚拟 BIOS 对 Windows 的支持等。同时也共享了大量 bug 修复的补丁。2010 年赴硅谷加入 Cloud.com（后被 Citrix 收购），从事 CloudStack 的开发工作，其间多次作为 CloudStack 代表参与客户私有云项目的设计和部署。在从 Citrix 退出后，和搭档一起创立 ZStack。

感谢杨赛对本文的策划,魏星对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群）。