对于OpenStack用户来说，随着开源云平台的持续演进，可扩展性仍然是一个大问题。Openstack的目标是启用并且运维大规模的云集群，但是在实现这一愿景的过程中，仍然有一些不足之处。通常来说，在小型测试沙箱里正常工作的东西要想超越早期生产环境并且进入大规模运维时都会遇到很多的困难。

增加Openstack的可扩展性并不容易。对于初学者，很多针对Openstack的供应商的插件和工具都不是可扩展的，而其他一些供应商能够提供有助于可扩展性的合适工具，但是同时会引入供应商锁死的风险。

分解OpenStack可扩展性难题

网络似乎是OpenStack可扩展性问题的核心所在，OpenStack的Neutron模块仅能够扩展到30个左右的节点。公有云上的竞争对手已经能够在数千台服务器上运行成千上万台VM，这一限制对于考虑OpenStack的企业客户而言是能不能继续OpenStack方案的关键点。

Neutron问题的一部分在于OpenStack Nove核心模块所支持的网络模型。该模型限制了集群规模，并且给构建和销毁VLAN增加了延时。这样的结果对于沙箱来说足够好，但是对于生产环境所需的扩展能力就是个大问题。

一些OpenStack的合作伙伴，包括Mirantis 和 Hewlett Packard Enterprise，已经提出了一些可能的方案。但是软件定义网络承诺将软件价值添加到廉价的，使用普通硬件的白盒交换机上也是刚刚面世，提供了和Mirantis以及其他OpenStack合作伙伴竞争的解决方案。

如果你想购买更加复杂的平台，比如供应商管理的OpenStack版本，一定要确保这个供应商有能力在很多服务器机架上扩展网络。

垂直自扩展，或者使用更多VM——使用OpenStack Heat模块进行扩展时也有很多问题。Ceilometer模块监控VM里的工作负载，并且触发Heat自动扩展或者调整VM的个数。不幸的是，有很多OpenStack的版本，还有更多的专有工具，并且在很多情况下，都丢失了一些主流模块。通常没有Ceilometer，而是使用自定义的监控引擎。OpenStack的广泛用例几乎可以保证这样的交互一定有很多问题。这里唯一的解决方案是耐心，等到Ceilometer更大范围部署之时。

负载均衡也有类似的问题。Neutron作为服务提供负载均衡，Heat全面支持这一点。但是，一些版本，没有这个特性，需要考虑其他方案。GitHub上的开源的HAProxy项目是一种可能的解决方案。