对于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项目是一种可能的解决方案。
解决OpenStack网络问题
当面临OpenStack可扩展性时，有更多的高级网络运维也都很困难。比如，连接虚拟网络的功能会变成噩梦。验证连接并不容易，在外部连接功能上，比如防火墙，则有可能会丢失链接。要想把一个新服务插入到服务链里也很困难;IT团队需要销毁服务链并且从头重新构建。
启动风暴——这个词来源于VDI里的boot风暴，如果连接断开随后修复时可能就会发生。重新连接数千个节点，使用缓慢的加密流程以及分发代理，需要花费大量的时间。
当面临OpenStack可扩展性时，这些来源于Nova，以及Keystone安全的网络问题，可能会成为瓶颈。小心调优Nova能够有效减少这样的问题，并且加速网络搭建的运维。比如，IT团队能够增加NOVA API和处理节点的数量来移除链接创建中的瓶颈。还可以使用OpenContrail来解决一些Neutron的问题，这是一个高效的，低消耗的分发网络服务的平台。
随着OpenStack组件的演化，OpenStack的可扩展性和其他挑战已经在持续升温。阅读博客和文章了解***状态，并且记住开源云的总体优势非常大，但是演进是一个大问题。
