暴雪说，因为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/