游戏停服维护更新一直是在线游戏的难题,这个过程会面临维护当天日新增减少等问题。目前,网易游戏在《一梦江湖》等几款大型游戏中实现了不停服维护,节省了用户时间、大幅度提高了运维效率。

如何做到不停服维护?不停服维护在运维上会带来哪些改变和升级?作为 SRE 该如何应对?1月20日,网易游戏高级运维经理Richard在2019网易游戏开发者峰会上,为大家分享了网易游戏半年来的积累的一些经验。

以下是分享实录:

我在这里要和大家分享的是游戏不停服维护运维实践。游戏维护是我工作以来一直无法回避的一个话题,游戏会面临维护当天日新增减少,维护当天日流水减少的问题。

以前游戏项目人员会从两方面出发:第一,挑选维护的时间;第二,缩短维护时间。项目人员需要在很不清醒的时间内(如凌晨四点)快速地完成操作,故障率就很容易升高。

业界有两种较为通用的不间断维护方案,一种是灰度更新,另一种是红蓝更新。但为什么一直以来我们没有用这两种方案,一是因为服务端的开发进度,二是因为在运维上存在资源利用率不足,成本有限,集群又过大的问题。

经过思考,维护时其实用户在线总数是不变的,也就是虽然需要两套环境,但计算资源总量不变。用一套的资源实现两个服务端。我们先尝试了在一个服务器上进程多开的方案。不过,实施起来还是有问题,很难将各种计费、周边分布端口、网络开关服都结合起来,与实际的运维体系也不匹配。

对比研究后,我们想通过docker虚拟化资源,宿主超卖的形式实现资源环境的隔离,宿主配置两套 docker 实例,运行 AB 服新两套服务端,这时用户下线后从旧服登出,再登录时即进入新服务器,一套资源即可实现红蓝服更新。

在确立了方案之后就开始进行了一系列的调研工作。包括 Docker 的性能测试、兼容性测试、K8S 集群的部署以及内部专用的 Image 管理平台搭建。整个过程都比较顺利。

但随着部署服务器规模的增长,我们遇到了第二个问题:虚拟网络设备增加导致的,网络拥塞。

因为时间紧任务重,开始时想通过最短平快的方式实现虚拟网络间的互通,于是采用了一个最简单的网络方案“Host Network”将游戏服务器的虚拟IP也配置成实体IP,并注入到主路由中。但这使得主路由的设备条目数比设计容量多了三倍。硬件设备不足以支撑虚拟网络设备,是否有比较好的解决方案哪?我们又调研了docker环境下较常的Calico 网络方案。

这是简化之后的网络图。这其中有几个模块:在宿主上的BGPClient,Felix,在网络集群内又多了Route Reflector和ETCD, 分别负责宿主路由表的更新以及将虚拟机路由通过 Reflector 注入到主路由。这种方法可以使虚拟机通过主路由进行通信。

但通过仔细对比可以发现,其实 Calico 方案只是把 hostnetwork 方案配置自动化了。由于还是通过物理设备进行虚拟设备的管理和通信,所以整个网络依然受物理设备的限制影响;另外因为项目及设备数量的增加,内网IP也面临耗尽问题。所以必须有一套凌驾于物理网络的虚拟网络方案(Overlay),因此我们也对比了 docker 下另一个虚拟网络方案:Flannel。

Flannel 是一套覆盖网络 Overlay network,通过上图可以看出,主要的实现原理是将数据包通过隧道方式进行再封装,从而实现虚拟网络数据在物理网络上的通信。虚拟网络的信息主要通过 ETCD 进行查询与互通。总体来说 Flannel 可以解决虚拟设备占用物理网络设备数的问题,但依然无法满足大规模部署要求。

总结来说我们在搭建大规模 docker 虚拟网络的时候遇到了这些问题:网络没有隔离,网关性能不足,物理网络无法承载虚拟网络冲击,没有与宿主网络配置隔离。结合内部需求,总结了几点对网络的要求:

首先是不需要改造现有物理网络,其次是需要高性能网关,并且可以扩展。可以支持VPC,支持IP漂移,支持docker 与私有云网络混布。

为支持上述需求,我们基于openflow 协议开发了一套自研的SDN方案(Gon)。在宿主机上引入了 OVS(Open vSwitch) 用于管理宿主机内所有虚拟网络设备,OVS模块通过集群中NVC(Network Virtualization Controller)模块基于 openflow 协议实现互通。

我们同时引入了两个弹性虚拟网关设备 IGW 与 BGW,对内外网流量进行分离管理。整套 SDN 方案可以做到全局流控。根据网络组同事的测试,目前整套SDN单网关支持10G BPS,80W PPS、500W连接数,虚拟网关可依据需求在线弹性扩容,支持VPC,支持 IP 复用、支持 docker 虚拟网络与私有云的混布。

经过一些列研发与测试,Gon SDN方案可以 较好满足内部的网络要求,在并且在虚拟网络内部通信中,能做到接近物理网络性能。

解决网络问题之后,整体测试顺利,实现方式也相对优雅。不过如上面提到的,我们是需要对宿主机进行超卖的。这并不符合 Docker 一般的使用习惯。在容器编排上,需要有一定的特殊调整。要求对于一个业务群组(10001),需要严格按照一个pod A和一个pod B同时出现在一台计算节点。不然无法实现维护期间集群内计算资源的复用。

基于需求的特殊性,除了使用 docker 常用的 podAffinity 外,还需要结合 nodeSelector 特性来完成容器亲和性操作。

我们给需要复用的集群资源打上集群标签,然后通过NodeSelector的特性,进行实例编排,之后运用PodAntiAffinity的特性,保证不会出现AA 或 BB 分配到同一个宿主的情况。可以实现AB服的运行要求。但依旧有很多待优化的问题,包括资源层和应用层耦合,方案的通用性低。

经历了一系列之后,我们终于完成了不停服维护。以下就是完成的效果,在维护的同时,是不影响玩家的正常游戏的,使玩家体验上升,据我了解,整个产品团队的工作满意度也有了比较大的提升,大家都不需要熬夜维护了。

除了不停服维护,基于 docker 虚拟化环境的特性我们也取得了其他一些收获:包括从物理网络变成VPC隔离,新服准备耗时缩短,故障节点可自愈,系统环境升级做到不耗时,资源调度API化。

 

总结

与大家回顾一下不停服维护运维方案的实现,包括对资源的复用、docker 下 SDN 的探讨以及特殊情况下容器编排的尝试。其实整个方案基于 docker 实现,但不是常见的 CICD,能够根据需求想到用法这一块是最难得的,而后的技术问题反而比较好解决。

作为技术人员尽量不要被固有思维禁锢想象力,要知道技术能落地到业务才能产生价值。

运维的工作也已经不再是传统的劳动力密集行业,更多的工程化业务,驱使技术人员不断深入基础环境与业务内容。我们需要与各个部门的高度协作,结合各自专业一同完成共同目标。


网易游戏内推及内部职业干货交流群,入群即可享受超多福利!!

入群方式:链接进入【网易互娱|校招知识储备&新游体验馆探营无限福利群】:https://jq.qq.com/?_wv=1027&k=5dJP4EB

还可以添加“网易游戏学院菌”微信号(NetEase_study)及时获取更多知识干货哦!

原文链接:https://blog.csdn.net/NetEase_Game/article/details/106714241

最后修改日期:2020年6月15日