阶段 3:规模扩大¶
《扩展之旅》的第三阶段是规模扩大。
在规模下监控您的集群时,您会发现它在一个集群内达到了扩展限制。但并非绝望!您可以采取一些措施来提高单个集群的处理能力,而无需诉诸设置更复杂的部署配置。本页旨在帮助您解答这些问题。
一旦您完成了该阶段,就可以进入扩展之旅的下一阶段:规模扩展。
常见问题解答¶
问:清理数据库中已删除的条目有点麻烦。有没有我可以用来帮助我的工具?
答:OVH 开发的 OSarchiver 工具可以帮助您:请参阅 https://github.com/ovh/osarchiver/。我们正在努力使其作为 OSops 工具的一部分进行上游维护。
问:典型的 OpenStack 集群可以包含多少个计算节点?
答:很难给这个问题一个确定的答案,因为它取决于每个计算节点的性能以及云中的使用模式(变化的幅度、超额订阅、I/O 与 CPU……)。答案范围从 100 个节点(在节点密度高且变化大的情况下)到 2,000 个节点(节点简单且工作负载持续时间较长的情况)。
问:拥有过多计算节点的集群的典型问题是什么?
答:控制平面的负载(数据库/RabbitMQ)会大大增加,并成为瓶颈。高密度节点更容易遇到 Neutron 扩展问题。“突发”负载更难管理(例如,重新启动所有 neutron agent 或 nova computes 会给控制平面带来很大的压力)。最后但并非最不重要的一点是,故障域会变得更大。
问:一旦达到限制,可以采取哪些措施来提高限制?
答:建议包括为 neutron 相关的队列创建单独的 RabbitMQ 集群(如果您使用的是 ml2/ovs、ml2/linux-bridge 或 ml2/sriov-nic-agent),或使用 ovs 的 python 绑定。
问:您如何决定添加一个新的控制平面节点?
答:如果您发现某个服务的 rabbitmq 队列不断堆积,通常意味着需要向这些服务添加更多的控制平面工作进程来消耗队列。
资源¶
精选的 扩展故事,随着我们收集它们
内部消息传递评估
数据库评估
扩展 Neutron:https://www.youtube.com/watch?v=5WL47L1P5kE (https://www.slideshare.net/moreirabelmiro/evolution-of-openstack-networking-at-cern)
扩展 Nova/Ironic:https://techblog.web.cern.ch/techblog/post/nova-ironic-at-scale/
调度性能:https://techblog.web.cern.ch/techblog/post/scheduling-optimizations/
全局扩展:https://openstack.org/summit/barcelona-2016/summit-schedule/events/15977/chasing-1000-nodes-scale
该阶段的其他 SIG 工作¶
收集扩展故事
在 扩展故事 上整理它们