- 理论上，单个openstack已设计成可水平扩展的系统，只要数据库足够快，消息总线足够多资源等，一个openstack系统可管理上千台物理服务器是没有问题的。
- 但是单个openstack规模大了之后，潜在的风险也就增加了。系统故障时解决问题变的更加复杂，而且用户不希望发生大面积瘫机事件。另外，还要解决arp广播报文风暴问题和l2pop问题。而且规模越大，性能越低，包括数据库、消息的处理。
- 故可以采用openstack级联方式。限制用户在每个被级联的openstack里只能部署1024台物理服务器（约一万台VM）。这样，不用对DB与MQ进行专门的优化操作即可达到一定的规模性能。另外，每个被级联的openstack都可以维护不同的虚拟化方案，例如KVM、Xen、VMware等。
- Cell方案与级联的比较：Cell只局限于Nova，对于neutron、cinder等其他模块没有考虑扩展性和多数据中心场景。当时Cell的网络也是基于nova-network来做的，当Neutron从Nova中分离出来后，Cell的功能并没有延伸出来。另外，Cells之间是通过RPC消息通信，Cells的维护升级定位都较为麻烦，且一个Cell坏了，被管理的子Cells全部无法管理，子Cells没有Cli或者Restful接口可以提供管理，沦为孤岛。而级联的核心优势就两层标准的Openstack API，在一个松耦合多Openstack的云上面提供了一层标准的Openstack。即使级联层的Openstack故障了，被级联层的Openstack仍旧能通过标准的API正常工作。
https://wiki.openstack.org/wiki/OpenStack_cascading_solution OpenStack cascading solution ，huawei在Openstack社区的孵化项目