| 毫无疑问，OpenStack项目确实拥有强劲的发展动力，而且各种类型及规模的企业用户正在考虑这款开源软件是否适合自己。OpenStack在最近一段时期以内牢牢抓住了关注者的眼球，但就当前而言它还没能成为大型企业真正信赖的常规技术方案。不过话说回来，很多技术人员正在努力推动其实际普及，也有相当部分的拥护者坚信它代表着云计算的未来。
有时候大家可能忽略了，OpenStack还只是一个年仅四岁的新兴项目，而且就在最近十二到十八个月当中才真正趋于成熟——具体数字取决于大家选择的时间划分线。这一切都需要时间来完成，而且如果大家从采纳曲线、社区规模以及项目适用范围等角度审视，就会发现OpenStack的发展轨迹要比当初Linux冲击数据中心领域的势头更为强劲。 理由非常简单：Linux的出现让开源软件拥有了可靠的运行环境，而由此衍生的一大批数据库、中间件以及应用程序开发工具则进一步巩固了其市场地位。相比之下，OpenStack等于站在了Linux这位巨人的肩膀之上，这也正是如今任何一家超大规模数据中心运营商（除了微软的Azure）以及大部分互联网新兴企业所作出的选择。 在本周于乔治亚州亚特兰大举办的OpenStack峰会上，OpenStack基金会列出了一长串主流企业的名头，其中包括富国银行、AT&T、迪士尼、Digital Film Tree、索尼以及PayPal/eBay等等，它们都曾讨论过打算如何在自家基础设施当中部署OpenStack方案。这些大型企业几乎都表示在运行OpenStack的过程中掌握到不少技巧，并学会如何将其纳入到自家业务流程当中;不过他们并没有谈到其使用OpenStack技术的具体方式。当然，这是上市公司在处理公关事务时的惯例。 也就是说，如果OpenStack社区无法确切掌握企业用户部署该软件并将其融入基础设施的实际方式，那么他们将无法有针对性地在软件发行版中推出功能与特性。因此在过去的几个发行版本中，该开源项目的掌控者OpenStack基金会完成了对客户群体的调查。eBay公司的JC Martin、前维基百科成员Ryan Lane（他如今已经加入一家名为Lyft的新兴企业）以及CERN（即欧洲核子研究中心）的Tim Bell共同负责数据收集并对这些来自社区调查的信息进行匿名化处理。 此次最新调查的汇总结果于本届峰会上得到公开，他们表示目前OpenStack项目的客户群体仍然由概念验证以及云测试/开发人员占据主导——这种情况与当初服务器虚拟化技术刚刚登陆X86架构时非常相似。服务器虚拟化技术在大约十年前才正式得到广泛认可，而如今则已经成为标准化处理方式。当然，这并不是说OpenStack技术完全未能在规模化部署层面取得进展。 事实上作为与美国宇航局地位对等的OpenStack项目联合创始方，Rackspace公司就曾在2010年7月将这套开源技术引入业务环境、旨在构建起一套专门面向其托管及云操作体系的控制系统。自那时至今，一系列以OpenStack为基础的生产系统被建立起来，而这一阵营还在不断扩大;不过部署规模的拓展速度确实不像社区发展那么迅猛，以提供OpenStack技术支持或者将OpenStack打包构成广泛或深入产品为收益来源的企业在这方面可能体会得最为透彻。 最近公布的这项调查恰好赶上了将于今年秋季发布的OpenStack发行版“Juno”正式开始研发，调查共涉及1780名受访者，涵盖总计506个OpenStack部署项目。来自美国与加拿大的OpenStack云项目共占据195个席位，欧洲为143个、亚洲则为107个。就全局情况来看，云开发与测试项目共有210个，云概念验证项目为218个，真正用于管理实际工作负载的生产性云项目则为209个。 当然，这显然并未反映世界上全部现有OpenStack云项目。就在本周早些时候，红帽公司虚拟化与OpenStack业务总经理Radhesh Balakrishnan在接受采访时指出，该公司所实施的OpenStack生产方案保持着“健康的两位数”用户规模增幅。他同时补充称，以概念验证为目的的部署数量则以“三位数”速度增长。Canonical公司自三年前开始将OpenStack嵌入至其Ubuntu Server 11.04版本当中，Ubuntu Linux项目创始人Mark Shuttleworth还在本次OpenStack峰会上告诉我们，Canonical公司在生产与PoC方案的普及率方面比红帽高出一个量级。 通过调查结果，大家还会看到Ubuntu Server目前已经成为OpenStack项目中最受欢迎的Linux系统版本。这一方面是因为OpenStack实施尚处于早期阶段，另一方面则是因为它能够以自动化方式简化OpenStack云的部署与管理流程。 我们的猜测是，目前技术业界中的概念验证型OpenStack云项目应该达到数千个，而真正作为生产环境的云方案数量也应该突破一千个。当然这仅仅是估计，由于OpenStack的开源属性以及数十种不同的使用方式，没人能确切衡量项目的真实数量。顺带一提，数千套生产型OpenStack云在数量级上与全球大型超级计算机集群与生产级Hadoop集群处在同一水平。
正如大家在上图中所见，与其它任何一款开源软件的发展轨迹类似，OpenStack生产系统能够发展的最大动力分别来自避免供应商锁定、节约资金、提高运营效率以及坚持开放标准。 总体而言，生产型OpenStack云在规模上要比测试/开发云更大一些，而且这两类方案又要比使用OpenStack进行概念验证的云体系更大。当然，项目大小与企业业务（即计算与存储工作负载）以及自身规模（通常表现为用户数量以及营收总额）紧密相关，因此单凭这一点还很难对整体趋势作出准确把握——毕竟小公司眼中的大型云环境在巨头厂商面前只能算毛毛雨。另外，生产型云体系往往倾向于采用旧版本OpenStack运行其上，其中一部分还必须要为那些尚未正式发布的OpenStack集群元素提升升级。目前OpenStack社区正在积极解决这些问题，但这是一项长期任务、恐怕在短时间内无法彻底得到好转。 根据OpenStack基金会收集到的数据，生产型云项目在规模上仍然相当有限，不过大家也不能将此视为最终结论——毕竟即使是参与到调查中的受访者也没有确切提供其项目的原始数据，甚至出于匿名性考虑而对数据有所保留——仍有不少企业拒绝公开与其项目相关的详细信息。
一般来说，主流生产云项目的节点数量一般在50个以下、计算核心数量则不超过100个，不过大家通过上图可以看到，少数生产型OpenStack云项目拥有数百甚至上千个节点、计算核心数量也在数千乃至数万之间。 如果姑且忽略那些并未使用对象存储机制或者拒绝公布相关细节的客户，那么就目前而言OpenStack生产型云项目所包含的对象数据一般低于10万个。当然，也有一些云项目拥有上亿个存储对象，但这只能算是特例。在块存储方面，这一结论也同样有效。大部分生产型云项目的块存储容量在100TB以下，少数项目则率先将其推进到了PB级别。 正如大家预期的那样，OpenStack也为超大规模数据中心运营商准备了与Puppet及Chef类似的配置管理工具，此外该项目还准备了一系更其它工具、旨在进一步帮助客户完成OpenStack云的设置工作：
再将目光转向虚拟机管理程序方面，作为目前Canonical与红帽为OpenStack选定的标准搭档、双方心目中理想Linux-OpenStack组合的构成元素，KVM在诸多选项中无疑最具吸引力。有趣的是，VMware的ESXi、LXC容器以及Docker容器在概念验证型云项目中的人气要远高于生产环境，这可能为我们带来了另一项值得关注的参考指标。 就在本次OpenStack峰会上，众多企业讨论了自身如何利用OpenStack技术对各种类型与规格下的物理及虚拟设备进行管理。举例来说，在长期运行流程中，企业用户可以保持ESXi的运作而不必使用VMware的vCloud。这能为他们回避大量虚拟机转换所带来的技术困扰，并借此实际成本节约。微软的Hyper-V也是同理，OpenStack同样可以对其加以控制。对于那些同时使用三大主流虚拟机管理程序的企业用户——例如一家需要在内部环境中分别建立Linux与Windows应用程序开发团队的大型企业——来说，OpenStack的出现能够将原本彼此孤立的业务流程转化为一整套混合环境。 为了将虚拟机管理程序与OpenStack接驳在一处，必要的网络驱动程序自然也是种类繁多、不一而足。在此之一，Open vSwitch的流行程度最高，甚至俨然有些OpenStack标准配备的意思。不过尽管如此，生产云项目中的网络方案在多样性方面还是要远远超过虚拟机管理程序。 无论大家是否相信，已经有人宣布在生产项目中成功运行了OpenStack的Austin初始版本——Lane表示他本人对此是绝不相信的。作为该版本下辖的三个子版本，代号分别为Bexar、Cactus以及Diablo的三套发行版也取得了不错的使用率。 作为第一款可用版本，Essex仍然活跃在61个云项目当中，而于2012年发布的Folsom则占据64台设备，接下来的是在一年前OpenStack真正获得市场关注时登场的Grizzly版本、它出现在84台设备之上。去年秋季面世的Havana版本占据42个云项目，而就在一个月前刚刚诞生的Icehouse版本也已经拥有五位支持者。有趣的是，有26个云项目没有等待正式版本发布而选择了自主进行技术更新。
在新近出炉的这份OpenStack调查报告中，我们还发现了另一种值得关注的现象，即仍有一部分客户在使用能够让OpenStack与Amazon Web Services中EC2计算与S3对象存储服务相兼容的API。具体来讲，目前有87个云项目使用EC2 API，另有54个云项目使用S3 API。除此之外，另有一些客户在使用开放云计算接口（简称OCCI）API，不过目前还没有将谷歌计算引擎的API引入项目的先例。 思杰公司放弃早期OpenStack研发成果、转而收购Cloud.com并将CloudStack作为Apache项目加以开源的理由之一是，Rackspace坚持认为与AWS保持兼容不应作为OpenStack项目发展过程中的主要任务。 通过调查可以看到，思杰选择的AWS兼容之路还是受到了包括Eucalyptus Systems在内的其它厂商的认同，后者推出的同名云控制器希望尽可能多地克隆AWS服务、并借此构建起一套规模较小的新兴项目。OpenStack决定寻求属于自己的发展道路，根据自己的判断处理问题，这当然有其可取之处。然而必须强调的是，对AWS的兼容性在很多企业用户眼中仍是一项不容忽略的重要优势。 |
