YY 游戏私有云平台实践

阅读数:3326 2016 年 1 月 12 日 17:23

编者按:YY 游戏的页游早在 2013 年就在云平台上运行,其 Cloud 1.0 已经支撑几十万的同时在线用户。日前,YY 游戏云平台进行了 Cloud 2.0 的改造,其主要目标是支撑端游,同时也将继续服务页游、手游的运营。

这次架构升级是一次完全重构——抛弃 OpenStack,网络、计算、存储业务都是自己实现。作为 YY 游戏云平台的负责人,风河在本文里主要描述了 YY 游戏需要建设一个什么样的云平台,以及如何建设这个云平台的。

YY 游戏的业务需求变迁

YY 游戏早在 2013 年就运行在云平台上。在开发云平台之前,游戏运营面临的问题是:

  • 页游开服快、密度大、周期短,导致运维变更频繁。

  • 传统开服、合服涉及大量的运维人工操作,例如安装服务器、配置网络、部署游戏、配置数据库等。

  • 用物理机开服,资源分配不合理,一个物理机上分配较多游戏进程,会导致风险过高;分配较少进程,又导致成本浪费。

  • 数据备份、监控、故障转移在传统模式下都成为挑战。

针对这些痛点,我们在 OpenStack 的基础上,开发了第一代云平台,即 Cloud 1.0。云平台上线后,资源管理更加灵活,在性能和成本之间取得良好均衡,并极大的增强了运维自动化能力。目前 Cloud 1.0 支撑了几十万同时在线的游戏用户,截至到 2015 年 12 月,YY 云平台接入游戏 50 多款,资源总数约 15,000 个。

如下是 Cloud 1.0 的基础架构,它包括云主机、云 DB、云存储、云缓存、云网关五大核心产品。用户可通过控制面板访问它们,也可通过 API 在应用程序里来调用它们。

YY游戏私有云平台实践

随着云平台规模越来越庞大,慢慢暴露了 OpenStack 的一些弱点,比如结构复杂、可靠性一般、扩展性弱,导致我们在云的可控性方面大为被动,从而产生了第二代云平台的需求。

那么我们需要一个什么样的云呢?首先,它是基于私有云。其次,这个私有云一定满足我们业务的特点,比如游戏行业与金融行业,业务特点截然不同。再次,这个云一定要可管理、可扩展、可控。对于一个平台服务,它存在性能短板、运行故障并不可怕,可怕的是出问题后用户无法跟踪和定位,从而失去可控性。

云平台架构的演进

在 Cloud 1.0 里,我们并没有实现租户网络,不同的游戏厂家都接入同一 Flat 网络,这对隐私和安全都不利。网络架构如下:

YY游戏私有云平台实践

上述图里,云网关是游戏平台里一个重要产品,请参考腾讯游戏的TGW 。简言之云网关有两个重要作用,一是收敛公网IP,节省IP 成本;二是集中安全防护,降低单个云主机被DDoS 的可能性。我们所有的云主机都只有内网IP,运行在云网关后面。除了云主机外,还有云DB、云缓存、云存储等配套产品,都是游戏服务需要的。

在 Cloud 2.0 里,重点解决租户网络(VPC)的实现问题。出于前面提到的原因,我们并不打算采用 OpenStack 的租户网络方案。在充分调研和学习的基础上,自主设计了一套基于硬件的解决方案,其中 VPC、子网、路由、云网关都采用硬件实现。架构图如下:

YY游戏私有云平台实践

我们看到图里标明了 3 个租户,实际上我们会有数 K 个租户,每个租户都有自己的虚拟私有网络,也就是租户网络(VPC)。每个 VPC 保持独立性,彼此隔离。我们采用 VxLAN 技术来实现 VPC,因为传统的 VLAN 有规模限制(4K),我们不能做一个将来无法扩展的平台。而 VxLAN 的 16M 规模可以充分满足需求。

VM 的数据包进入接入交换机(TOR)后,由 TOR 加上 VxLAN 头部,并进行转发。一般来说如果同一租户同一子网的数据包,由本地 TOR 直接转发到邻居 TOR。如果是同一个租户不同子网的数据包,先发给汇聚交换机,由汇聚交换机转发到下一个 TOR。汇聚交换机在这里充当 VxLAN 网关的角色,第一它负责 VxLAN 网络里不同子网间的路由;第二如果数据包需要离开 VxLAN,它会剥离 VxLAN 头部,将包转发给因特网网关。

数据包离开汇聚交换机后,到达网关就是普通的包。当然,由于我们支持多租户,每个租户的子网可能是重叠的,所以汇聚交换机和网关之间通信走 VRF。另外,我们的 VM 默认都没有公网 IP,所以需要网关兼具如下功能:

  • SNAT:VM 出到公网的数据包由网关根据 VRF 进行源地址转换。

  • DNAT:VM 的某个端口需要被外网访问,由网关根据端口进行目的地址转换。

  • Floating IP:少数 VM 需要一个独立的公网 IP,在网关上进行一对一的映射。

图里描述的接入交换机、汇聚交换机、网关都是独立的物理设备。但是,汇聚层和网关层也可以是 PC 服务器集群,既充当 VxLAN 网关,又实现 NAT 功能。

云平台架构选型与实现

VPC 的实现是 Cloud 2.0 与 1.0 的主要区别。在 1.0 里我们使用 OpenStack 的 Provider Networking 网络类型,它就是一个大的混合网络。随着规模的扩展,这种网络类型已经不能满足我们需求。所以 2.0 的建设重点是实现每个租户拥有独立的 VPC。比如用户 A,跟用户 B,拥有两个互不相通、彼此隔离的二层网络。用户 A 和 B 都可以自定义他们的网络地址段、路由、访问控制策略。关于 VPC 的架构借用 AWS 的一张图来描述:

YY游戏私有云平台实践

怎样实现 VPC

VPC 有很多种实现方式,既有软件的也有硬件的,有 VxLAN 类型也有 NvGRE 类型。我们在 Cloud 2.0 设计阶段综合考虑到性能、稳定性、开发成本、上线时间等因素,决定第一期采用基于硬件的 VxLAN 来实现 VPC。

在跟同行公司的交流中,我们得知业界在实现 VPC 时也有非硬件的解决方案。比如阿里云在 VSwitch 层面做了大量工作,用软件对流表隔离的方式来实现彼此独立的租户网络。这种方案比较灵活,对硬件设备的依赖少,不过开发周期长,在生产环境里不容易搞稳定,我们暂不考虑此方案。

VxLAN 网络由接入交换机和汇聚交换机组成,数据包在它们之间传输时,会带上 VxLAN 头部,从而隔离成一个个独立的二层网络。数据包在进入接入交换机之前,以及在离开汇聚交换机之后,都没有 VxLAN 头部,是普通的数据包。VxLAN 网络规模理论上可以达到 16M,也就是 16M 个 VPC 实现。当然,由于 VRF 数量有限,在实际中并不能产生这么多的 VPC,除非这些 VPC 都不需要访问公网。

图的下半部分,Hypervisor 代表计算节点的宿主机,它们接入独立的管理网络,这只是一个物理的二层网络,非虚拟网。管理网络里除了有宿主机外,还有控制器、管理数据库、分布式存储等。控制器的作用不言自明。分布式存储是 VM 运行的数据支撑层,我们的 VM 不管是操作系统自身,还是数据盘,都运行在分布式存储上。这样既保证数据安全,又满足云平台的特性,比如 VM 快速启动和迁移。

云平台包含三个关键部分:虚拟计算、虚拟网络、虚拟存储。这里面虚拟网络是基础,它的结构决定了整个云平台的实现架构。如果把虚拟网络搞定,那么虚拟计算、虚拟存储都问题不大,这也就是为什么在 Cloud 2.0 里,我们敢于抛弃 OpenStack 的原因。我们需要开发一套应用程序,完成对这三套底层系统的调用、调度、监控和反馈。而这套应用程序就是自己的云平台实现,它的架构参考如下:

YY游戏私有云平台实践

因为虚拟网络(又称软件定义网络、SDN)一直是我们的重点,所以本文谈的也基本围绕它进行。虚拟网络实现的本质是控制器的实现,控制器是虚拟网络的灵魂。VxLAN 网络里大量的数据交互,都需要控制器参与。

比如控制器要记录每个 VM 的虚拟 Mac,并下发到 TOR,这样 VM 在发起 ARP 查询时,TOR 才能进行 ARP 代答。再比如某个 VM 的网络请求进入到 TOR,TOR 需要查表才知道这个 VM 属于哪个 VxLAN。还有同一子网里数据包在不同 TOR 之间转发、以及不同子网数据包在 VxLAN 网关里的路由转发,都需要查控制器的表项来决定。

关于 SDN部分

SDN 控制器是目前非常热门的技术方向,有很多开源项目参与进来,但成熟的产品很少。它的开发工作量很大,华为公司研发敏捷控制器的部门就有一百多人。而我们的 Cloud 研发部门总共才十几个人,很难有精力搞一套自己的控制器,所以倾向于采取跟第三方公司合作的方式来完成。

我们期待的是一个简单的控制器北向接口,它完成 VPC、Subnet、Router、Port、Floating IP 等网络基本要素的管理,参考此说明。而控制器自身的实现方式,目前对我们来说不是特别重要。比如有的控制器北向接口就是 Neutron API,南向是自己实现的 Drive,这个也完全可以。

我们 VPC 的实现主要由硬件交换机驱动的 VxLAN 来完成。VPC 除了有内网,还需要跟外部通信,以及外部能访问 VPC 的服务,这些都使用硬件网络设备来实现。控制器要完成对这么多设备的串通联调,是一个非常大的挑战。

两个核心功能

除了 VPC 的实现,Cloud 2.0 还需要提供两个核心能力,一个是管理 API,一个是按需使用的计费能力。我们在 Cloud 1.0 里已提供了完整 API,可以实现对资源的创建和管理。2.0 里也一样,用户可以使用 API 来管理网络、服务器、数据库等云资源。对游戏厂家来说,这是他们自动化运维的基础。

  • 计费我们在 1.0 里做的不好,2.0 应该予以完美实现。用户的计费模型,纵轴是时间维度,横轴是容量或能力维度。容量包括内存大小、磁盘大小、带宽多少等,能力包括 CPU 计算性能、磁盘读写性能等。提供灵活的计费能力,按需使用,用多少算多少,无疑对我们客户具备更大的吸引力。这一点 Vultr 的平台做的非常好,我在使用它们按需计费的能力后深觉方便,就在最近把 Linode 上用了 5 年的云主机,迁移到了 Vultr。

  • 关于系统的扩展性,主要存在租户规模上。如果租户一直扩张,虽然内部 VPC 的 16M 规模可以充分满足,但是网关的 VRF 数量会面临不够。参考业界的解决方案,今后如果租户规模扩张到很大,我们也会考虑开发 PC 服务器集群的 VxLAN 网关,来代替目前的硬件网关方案。

  • 这个 VxLAN 网关实现了现在架构里的汇聚交换机和硬件网关的功能。VxLAN 网关在设备层面基于高性能转发架构,如 Intel 的 DPDK,实现 VxLAN Overlay 网络 L3 GW 功能;在控制层面是基于标准南向控制接口的 SDN 网元,支持的协议包括 Openflow+Netconf。架构上它是一个服务器集群,每个节点都能处理 VxLAN 封装、卸载、路由等功能,以及网络地址转换(NAT)。接入交换机的 VxLAN 数据包需要发给网关时,寻址方式可以在控制器里由预定义的策略决定。集群理论上支持无限的水平扩展,在保证性能的同时,保持了经济性。

  • 最后说到可控性,在 Cloud 1.0 里我们虽然使用了 OpenStack,却远没达到掌控自如的程度。OpenStack 庞大复杂,众多的组件、复杂的交互关系、以及并不太好的软件质量,让我们望而止步。所以在 2.0 里,我们的基本目标之一是可控。现在虚拟网络自主实现,虚拟计算和虚拟存储也有经过验证的可行方案,那么只需要业务层做好整合,整个系统就具备可控性。过去的云平台出了问题,难以发现原因,即使发现了也难以深层次跟踪问题。现在 Cloud 2.0 里所有调用和调度都自己实现,出问题后跟踪和分析能力要大为提升。

小结

我们的 Cloud 2.0 还在开发阶段,在实现过程中肯定还会遇到各种问题和困难。期待它上线后能改善现有的问题,带来更好的性能、扩展性和安全性。如果您对我们的技术方案有任何疑问或意见,欢迎跟我探讨。


感谢魏星对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入 InfoQ 读者交流群YY游戏私有云平台实践(已满),InfoQ 读者交流群(#2)YY游戏私有云平台实践)。

评论

发布