Fork me on GitHub

谈谈openstack部署规模问题

 

  • 理论上,单个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社区的孵化项目

 

posted @ 2015-08-04 23:44  落崖惊风  阅读(4892)  评论(0编辑  收藏  举报