封闭与开放，隔绝与融合，固守与自由，疑惑与坚定...... 一切都在猛烈地奔突着。在短暂的7年左右的时间里，OpenStack开源云操作系统与闭源商业软件，从竞争到对立，由对立趋缓和，终于，自缓和至融合。云计算启蒙及其技术发展的巨流在激荡和撞击中剧烈地沉浮，正在凝结和聚合成为信息时代最为波澜壮阔的一幕。

未知与挑战

OpenStack是开源的云计算操作系统，近年来，随着云计算概念的逐渐普及和企业业务创新的迫切需求，云计算技术得到了大面积的推广和应用，OpenStack也逐渐为人们所熟知。相应地，在构建云平台的实践活动中，OpenStack也被越来越多地被引入到企业的云计算环境中，成为IT基础设施架构的重要支柱。

在很大程度上，云计算平台已经或即将是企业IT基础设施架构的核心，其最根本的特征是成熟、稳定和高效。反观OpenStack技术，则具有开源技术的典型特点，即：在整体发展上是遵循着循序渐进和逐步演进的规律，而在具体技术细节上则处于高速推进和急剧变化之中。正是由于这样的独特背景和现状，OpenStack在企业的落地是充满未知性又极富挑战性的一项工作，既要充分开掘OpenStack的创新能力并应用于具体实践，又要研究、理解并牢牢把控住稳定和剧变之间的矛盾和冲突。

由此，在OpenStack落地应用于企业IT基础设施架构的过程中，必须充分地对其必要性进行分析和评估，进而对其具体建设方法作出与客观条件相适应的判断和抉择，最终，以开放和务实的精神去制定可操作的推进流程并予以具体实施。

可以肯定的是，由于企业IT基础设施架构的根本特征，OpenStack的落地应用必然是一个稳扎稳打的推进过程。

现实必要性

诚然，IT技术是业务创新发展的驱动力，但这并不足以回答“为什么要用OpenStack？”。实际上，更为具体的问题是：企业用户引入OpenStack技术去构建云计算平台，其内在的现实必要性又是什么？

总体而言，企业客户在这个问题上具有如下的高度共识：

（1）灵活敏捷的IT底层技术，必然会相应地带来业务上的灵活敏捷；

（2）基于开源架构，融合了最新技术的开源平台具有良好的可伸缩性，可以灵活地进行调整以适应业务的变化；

（3）避免被闭源商业软件产商“绑住”；

（4）采用开源技术构建云平台，可以极大地节省投入到IT基础设施的成本；

（5）极大地提升IT基础设施的执行效率

在这些现实必要性的作用下，企业用户对OpenStack具有极高的期望，而且，这些期望也具有高度一致性：

（1）统一的整体性的云操作系统；

（2）一套具有良好整合性和互操作性的服务组件；

（3）与用户现有的硬件、软件和公有云可进行互操作

令人遗憾的是，企业用户的这些期望至少在目前是落空的，或者说，客户根本就不应该有这样的期望，因为OpenStack不会成为统一的整体性的云操作系统，这也就决定了其它两个期望也是无法实现的。

通用的OpenStack?

其实，客户就是想要一个通用的OpenStack，但是，这个愿望是无法实现的：通用的OpenStack，以前没有过，现在没有，以后也不会有。

实际上，先把对灵活性和敏捷性的要求放在一边，用户最想要的还是两点：降低成本和从闭源商业软件中解套，这是用户寻找通用的OpenStack的根本原因。

通用的OpenStack实际上就是指：

（1）纯正的“官方”OpenStack版本，很容易安装；

（2）安装后保持默认设置就可以使用的OpenStack，同时，有易于使用的图形化界面，根据实际需求，很轻松就能修改相关配置；

（3）不会涉及任何商用收费服务的OpenStack

坦率地说，这种通用的OpenStack恐怕永远也不会出现，因为这与OpenStack的原生属性和生长方式相悖离。

最接近于用户期望的是：纯正的“官方”OpenStack（也就是原生的社区版）是可以自由地从OpenStack官方网站下载的，然而，即便是试验性质的安装也必须具备较强的技术能力，遑论应用于实际的生产环境。

仅仅是为了让OpenStack运行起来，就要进行大量的设置工作，保持默认设置是无法工作的，而且，OpenStack有500多个设置项，大多数的设置只能在字符界面里以手工输入命令的方式完成。

除非最终用户具有将OpenStack自如运用的技术能力，否则，将构建云平台的工作交给专业的OpenStack产商（包括供应商和系统集成商）就是必然的选择。供应商提供专业的OpenStack商务发行版，这是经过专业技术优化的OpenStack版本，易于安装、升级和使用；系统集成商提供专业的OpenStack规划设计、安装部署、知识传递和日常运维等各项服务。当然，这是要支付相关费用的，是标准的商用收费服务。

自主建设还是引入产商？

通用的OpenStack并不存在，因此，想要独立自主地去建设基于OpenStack的云计算平台，是极具挑战性的。这与一个人赤手空拳去独立组装一辆新车所面临的困难大致相当：没有组装必备的工具，你得自己购买；只有画得很潦草的组装图纸，你得弄清细节后再去尝试；面对几万个零部件，你至少得找几个内行人来帮你，而这可是一笔不小的开支。等到终于把车组装完成，还有可能开出几米就抛锚了......

从OpenStack官网上下载“纯正”的社区版OpenStack，使其运行在生产环境中，需要克服巨大的技术障碍才能实现，是非常复杂的过程。没有自动化的安装流程，几乎所有的安装步骤都要用键盘输入去完成；安装完成后，想要升级成新版本OpenStack非常困难，还很有可能造成现有环境的崩溃；除了参与OpenStack社区的技术交流外，很难得到及时有效的技术支持，耗时耗力可能还是无法解决问题。

大型企业当然可以组建专门的技术队伍去做这项工作，只要付出足够的人力和代价，自主地掌控OpenStack技术并非绝不可能，这样，就可以按照实际需要及时地进行技术调整，也不会被某个闭源商业软件产商所“绑定”。只是，投入极大，等同于创建专业的OpenStack产商。

如果选择引入专业的OpenStack产商，可以在很短时间内就完成落地建设过程并提供给业务使用。这正如购买从专业生产线上已经组装好的汽车，可以立即投入到正常使用之中。

一方面，在专业技术力量的支持下，规划设计和具体实施部署的过程变得迅捷而流畅，建成后，基于OpenStack商业发行版的日常操作简便而高效，而技术支持和售后运维等各项重要事务都能得到专业级的服务支撑。另一方面，也必须看到，以企业既有的评价标准衡量，引入OpenStack专业产商，除了要支付不菲的商业费用外，仍有被产商“绑住”之虞，只不过，是被OpenStack开源软件服务产商“绑住”。

那么，对企业用户而言，究竟应该何去何从？

何谓“被绑住”？

引入OpenStack就不会“被绑住”，这是极端错误的观念。

对一般规模的企业而言，想要引入“纯正”的社区版OpenStack加以改造并应用于生产环境，存在着难以逾越的技术障碍，最后的结局不是被OpenStack“绑住”，而是被OpenStack拒绝；

大规模企业如果要组建专业技术队伍进行自主研发，由于涉及软件、硬件、存储、网络和安全等领域，必将面临着巨大的资源投入和难以预料的前景，一旦陷入技术泥淖，就不仅仅是被“绑住”，而是被OpenStack“困住”，鉴于此，源自理性分析的望而却步就会是必然的选择。

如前文所述，引入OpenStack专业产商，以企业既有的评价标准去衡量，又何尝不是“被绑住”了？然而，如果换一种开放的思维去看待这个选择，那不是“被绑住”，而是企业构建IT基础设施架构的一种常见方式，是正常形态的外包。

不仅如此，还应该进一步认识到，在生产环境中，必须以是否能充分推动业务发展的需要为最重要的准绳，根据实际情况，将开源软件和闭源商业软件有机地组合在一起，一味地拒绝闭源商业软件也是矫枉过正的。

要想以全新的思维去分析研究、引入和应用OpenStack开源云操作系统，就必须认清当前的技术发展趋势，对OpenStack落地应用的实际案例进行充分的研究，抛弃一些陈旧的固有观念，以全新的开放态度和理念去迎接新的云计算技术。

应该清醒地看到，一方面，OpenStack确实有广阔的发展前景，另一方面，全面掌控“纯正”的社区版OpenStack需要极大的投入，即便是AT&T、德国大众、沃尔玛等大型公司也需要引入专业的OpenStack产商才能顺利完成技术落地实施和全面推广。OpenStack的落地应用实践已经证明并且还将继续证明：“术业有专攻”，不同的企业有各自专注的领域，如果引入专业队伍有利于企业的IT基础设施建设，进而极大地促进企业自身业务的创新和发展，那就应该坚决地予以施行。

大道至简

确切地说，OpenStack是一个为公共云和私有云的构建与管理提供可靠软件平台的开源项目。它其实并不是单一的软件，而是一个整体性的框架，是一个由若干组件构成的可用于构建公有云和私有云的基础框架。

2015年，在OpenStack的Liberty版本的发行周期里，“大帐篷(Big Tent)”模式被正式推出，这个模式把OpenStck的项目分类，其中，包括了6个Core Services（核心项目）、13个Optional Services（可选服务）和许多正处于活跃状态的其它项目。

OpenStack的核心服务如下：

可选服务包括如下13个服务：

经常与OpenStack环境紧密集成的一个常用组件是Ceph存储系统。Ceph是一个开源的分布式存储系统，在单一的存储平台上，可以处理所有类型的数据存储，即：提供对象存储、块存储和文件系统的存储机制。Ceph具有高扩展性（可达到PB级），还提供高容错性和高一致性的数据冗余机制。

如此众多的服务组件，令人目不暇接，每一个都新奇而有趣，而且都有很强的实用性，极具吸引力，企业用户很可能会陷入贪大求全的泥潭之中而不能自拔。比如，尽管在实际上并不需要，但是想尝试和体验一下“数据库即服务”，可能就会迷恋于Trove组件却无暇提升核心服务的质量。然而，过于复杂的IT基础设施架构会空自耗费宝贵的系统资源，选择超载必将会导致决策瘫痪，因为，企业用户在面对大量的服务组件时，已经无法辨别与其自身业务密切相关的部分。

在OpenStack落地应用上，必须秉持“大道至简”的基本原则去选取必要的组件，将精力集中在核心服务上（比如：计算服务、存储服务和网络服务），具体而微地去分析理解企业自身的特定需求，以“实用、够用、好用”为标准，在保证简洁和高效的前提下构建基于OpenStack的云计算平台。

“大道至简”的基本原则落实于具体的实践中，就是：采用最简单清晰的技术架构，从最基本的服务组件集（比如：计算服务，对象存储服务，或者，计算+对象存储）开始，在实践中逐步总结，不断提高自身对OpenStack的理解。同时，在使用中不断确认新的需求，充分评估和分析能满足新需求的服务组件，在合适的时机，再将之投入到生产环境的正式运行中。

结硬寨、打呆仗

晚清重臣曾国藩一生打仗的原则是“结硬寨、打呆仗”。每到一地，湘军就埋头挖壕和筑墙，营寨扎得坚若磐石，谓之“硬寨”；打仗的时候，也是逐个城池攻取，谓之“呆仗”。然而，就是这样稳扎稳打的“硬寨”和“呆仗”，在军事上取得了极大的成功。

企业用户在推进OpenStack落地应用时，就必须有“结硬寨”的硬功夫和“打呆仗”的拙功夫，踏踏实实地学习、调研、分析、试验、推进和推广，只有这样，才能使得企业的IT基础设施架构稳若磐石，发挥承载和推进业务创新力的核心作用。

以下的分步流程是为全面评估OpenStack产商并最终确定最佳入选者而设置的，立足于步步为营的稳步推进，“结”的是“硬寨”，“打”的是“呆仗”：

（1）首先，企业应该确定负责推进OpenStack落地应用的团队负责人；

（2）在互联网上全面搜索并认真研读OpenStack的各类介绍文档、规划设计和实施方法论；

（3）团队负责人下载DevStack（DevStack是OpenStack的开发版本的部署工具，可快速地部署OpenStack的开发环境），将其安装在一个最简单的环境中，对照技术资料，完成若干技术任务，从中体验OpenStack的设计理念；

（4）团队负责人对OpenStack有了基本理解后，应该着手组建企业项目团队；

（5）组织企业项目团队的成员协同工作，构建一个简单的OpenStack PoC环境（至多5台物理服务器），并在此PoC环境中不断地演练，深入地理解OpenStack的核心服务和可选服务等基本概念；

（6）如果条件允许，可引入专业的IT咨询人员，高度参与企业项目团队的具体工作，指导整体规划设计和系统集成等流程，保证项目建设过程中整体方向的正确，同时，在此过程中，完成面向企业项目团队成员的知识转移；

（7）设计一整套合理的评估机制和流程，确保对OpenStack产商进行评估的可信度；

（8）充分开展调研工作，弄清当前OpenStack市场的现状，在评估机制和流程的有效作用下，在国内外的几家OpenStack产商中选择入围者；

（9）在企业内部开展调研工作，梳理和分析各方需求和建议，整理出需求说明书，交予各入围的OpenStack产商；

（10）评估各OpenStack产商的技术方案，在条件允许的情况下，给出特定的技术任务，限定时间甚至限定地点，要求各OpenStack产商各自独立完成并展示实现效果；

（11）对各OpenStack产商的技术方案和完成技术任务的情况进行全面而细致的评估，给出技术评估结果；

（12）将技术评估结果交予采购部门，并与采购部门充分协商：尽可能向集供应商和系统集成商两种角色为一体的OpenStack产商倾斜；同时，为保证承建方在项目建设期间的资源投入，坚决杜绝开出不合理低价的OpenStack产商入选；

（13）确定入选的OpenStack产商，企业项目团队与之协同工作，共同完成项目的详细推进计划；

（14）企业项目团队和OpenStack产商项目团队共同推进项目的顺利完成。

一条界破青山色

OpenStack，信息时代弯弓上的这支响箭，呼啸着射入IT基础设施的群山之中，在千仞岩壁上凿出涓涓溪流，汇集成倾泻而下的瀑布，似白练般镶嵌于青山之上。

OpenStack不是固有秩序的颠覆者，而是企业现有IT生态环境的积极参与者和建设者。“一条界破青山色”，青山苍翠依然，却又平添了白练于其间飞舞灵动，两者交相融合，构成了一幅更加壮美的云计算画卷。