总体而言，生产型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的三套发行版也取得了不错的使用率。 |
