+86 135 410 16684 如果你在使用中有任何aws上云服务器维护问题,可以随时联系我们!AWSOK你最好的合作伙伴!Mon. - Fri. 10:00-22:00

关于AWS的游戏自动化运维部署方案

关于AWS的游戏自动化运维部署方案

关于AWS的游戏自动化运维部署方案

本篇文章主要是写工作中关于游戏如果基于AWS的平台进行自动化部署的内容,涉及到的AWS基础知识不会做详细说明,具体细节技术内容可以参考官方文档,因作 者本人一直从事在基于AWS平台部署游戏,经历了游戏在物理机上的时代到现在采用云平台时代,在采用云部署后,给运维带来的便利,个人感觉简直是一个时代 的跨越,之前采用物理机部署的方式的种种不便或无法解决的问题,在云平台上基本不存在,或者很容易的解决,所以云不仅仅是运维成本的降低,而是会让你的企 业充分发挥创造力,如果你的公司也在考虑是否选择云平台来部署你的游戏,而且还没有任何经验,那么这篇文章就是写给你的,讲解共分二个部分:

架构篇

在实际动手部署前,在白板上画出你在AWS上的游戏部署架构是重要的,它会让你清晰的知道你如何应用AWS提供的各个组件去为你产品部署服务,好的架构不但能使你产品部署简单稳定,更会让你产品的可扩展性增强,针对游戏来说一般要考虑的的因素有:

1、Region的选择

2、VPC的设置,一个VPN还是一个项目一个VPC

3、子网的划分,涉及容灾

4、EC2实例的网络设置,是否需要公网

5、如果涉及费用考虑,也要考虑购买预留实例的百分比

6、日志备份

7、用户角色设置

如果游戏规模小,部署的不太复杂,考虑以上因素基本是够了,如果用到DNS可以用 route53的,如果涉及到数据分析,可以考虑EMR。

以上每个考虑都要根据实际业务进行考虑,如果是用户是东南亚的国家,建议用日本节点,实际测试,日本节点要覆盖好些,从台湾ping 到日本和新加坡基本都是50m以上,但到了晚上新加坡延迟会到100ms以上,所以日本对东南亚覆盖补充,如果用户是韩国,节点也可以选择日本。

VPC我个人建议采用一个,主要是方面管理,虽然可以设置多个VPN,例如一个项目一个,即使打通了每个VPC之间的链路通讯,但后续管理成本还是比较高的。

子网建议要至少2个,而且在2个子网要在不同的可用区中,这样将来即使有一个可用区宕掉,也只会影响一部分用户,不会导致游戏全部无法访问以下是示意图,采用的aws官方图片:

default-vpc-diagram

关于ec2的网络设备,为安全考虑,如果ec2不需要有公网,建立的时候就不要创建带公网的环境,确保安全,如果开服的量太大,能上百台以上了,觉需要考虑预留实例的购买了,这个百分比不好去评估,得看实际业务情况和公司的策略。

日志备份选择s3存储,定期将日志推动到s3上,对数据分析可以自己搭建hadoop或采用EMR,用户角色根据具体运维人员的分工设置不同角色类型,建议按用户组进行划分。

 

操作篇

当构建好如何部署后操作是很快的,一般是几个小时就可以完成,具体操作不展开说了,我就将我实际操作中的一些细节描述下,帮助大家如何快速自动化完成部署:

1、建立每个游戏服角色镜像:这个操作会让你快速启动另一组服务器,例如你搭建完一组,共三台,游戏服1,游戏服2,游戏服3,调试完毕后,为每个 服做一个镜像,这样你就可以快速启动1组新服,很快就可以完成上百组服务器的配置,在需要开新服时,你基本5分钟就可以开一组,所以为每个不同角色的游戏 服留镜像是很有必要的,同时也可以使用跨区复制功能,快速在另一个region搭建新服,快速完成多region部署,这些工作通过api是可以做到完全 自动化的。

2、设置安全组,为每个游戏服建立一个标准的安全组,这样每个ec2实例都使用相同的模板,避免后续混乱,安全组可以按类别来区分,例如游戏端口,内网互通,特殊开通等描述来建立不同安全组,然后叠加到实例上。

3、如果你是通过信任完成对每台机器的控制,一般是可以这样操作,你创建一个实例做中控,登录实例生成公钥,将公钥放到游戏服镜像中,之后所以启动的镜像,都可以直接ssh登录了。

4、EC2故障,可以卸载磁盘,解绑IP,然后新建实例,重新挂载磁盘,绑定EIP。

5、不要为每一个用户创建密钥

6、账单数据同步到S3bucket中,下载下来,用脚本分析每个业务的费用情况,实时监控。

7、定期查看资源限制情况,保证开服时资源可以立刻分配。

8、用好工单,疑难问题提交工单解决,英文要够好,因为是用英文进行书面交流的。