暴雪说,因为OpenStack,扩展根本不是事儿了

暴雪娱乐是一家总部位于加州的软件公司,专注于创建和开发游戏。6月下旬,公司的两位工程领导者,Colin Cashin和Erik Andersson在OpenDev虚拟活动上与开源社区讨论了他们的云战略和扩展挑战,重点是大规模使用开放基础设施。             

暴雪采用多云策略。该公司使用来自亚马逊、谷歌和阿里巴巴的公共云,自2016年以来还拥有并运营着一个基于OpenStack的全球私有云平台。暴雪目前在OpenStack上有12000个计算节点分布在全球各地,甚至在去年一次跳过5个版本升级到Rocky。暴雪的团队也致力于为上游做出贡献。 

           

总的来说,暴雪看重的是简单性,通过解决四个主要的挑战来克服复杂性。             

挑战1:             

暴雪面临的第一个挑战是使用NUMA pinning的Nova调度。NUMA pinning确保访客虚拟机不会跨dual socket计算节点上的NUMA区域进行调度,从而避免CPU上过度订阅总线互连的tarversing惩罚。对于高性能的游戏服务器工作负载,这意味着玩家体验的天壤之别。

2016年,他们在暴雪的第一个FPS游戏Overwatch发布之前,决定在调度中实施NUMA pinning,以防止这些问题。这个决定引起了很多麻烦。NUMA调度成本高昂,需要召回Nova DB,影响了该进程的周转时间。在特别大的部署中,他们经常遇到调度失败的竞争情况,并最终通过配置优化来解决这个问题,将调度器的目标池从1个计算节点增加到20个。NUMA pinning的另一个副作用是中断实时迁移,这个障碍现在已经在Train的Nova版本中修复了。             

要点:对于大型环境,NUMA pinning应该以一种经过测试和控制的方式实现,并且在新版本中,使用NUMA配置文件的实时迁移是固定的。             

挑战2:             

接下来,Cashin和Andersson讨论了RabbitMQ的扩展。RabbitMQ是一个在OpenStack组件之间充当消息传递代理的工具,但是在暴雪的例子中,它被证明很容易被淹没。在出现问题时恢复服务(例如,数据中心中的大规模网络事件)似乎是最大的挑战,这是不容忽视的。为了解决这个问题,暴雪对RabbitMQ配置进行了调整,引入了扩展的连接超时,以允许较慢但更“优雅”的恢复。对Rabbit队列应用了额外的调优,以确保只有关键队列跨集群复制,并且队列在这些事件期间不会呈指数级增长。             

要点:RabbitMQ需要针对环境进行特别的调优。             

挑战3:             

Neutron扩展是暴雪的第三大障碍。由于某些OpenStack服务在同一个控制器主机上并置,暴雪经历了几次旷日持久的运维事故。暴雪团队在2019年修复了这个问题,当时他们决定通过将Neutron RPC worker迁移到虚拟机来水平扩展。迁移到VMs也解决了API和worker池的共同命运。此外,当元数据服务大规模地代理大量数据时,还存在一个压倒控制平面的问题。经过大量的研究和与社区的对话,暴雪能够将间隔时间延长到4~5分钟,并在正常运行期间将控制平面上的负载大幅降低了75%。             

要点:随着云规模的增长,Neutron的配置和部署应该仔细考虑。             

挑战4:             

最后是计算机组维护的问题。随着私有云大规模投入生产,有一种内部驱动力将更多的工作负载从裸机迁移到云上。在许多情况下,这意味着迁移发生在应用程序真正具备云感知能力之前。随着时间的推移,这严重影响了暴雪维护机组的能力。升级需要大量的劳动,而且没有规模。在过去的15个月里,暴雪的软件团队开发出了一个新产品Cloud Automated Maintenance,它可以实现机队的自动放空和升级。该产品使用Ironic来编排裸机和一个公共云式通知系统,所有这些都由生命周期信令实现自动化。

             

要点:OpenStack的内部租户对迁移能力有很高的期望,尤其是对于不太短暂的工作负载。此外,在进入生产前,准备好流程和/或系统来管理机组维护。             

未来,暴雪将继续精确定位并应对挑战,以尽可能大范围地消除复杂性。

原文链接:

https://superuser.openstack.org/articles/for-blizzard-entertainment-its-game-over-on-scaling-complexity/

你可能感兴趣的:(队列,人工智能,大数据,分布式,java)