- 理論上，單個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社區的孵化項目