YY游戏私有云平台实践 (转自InfoQ )

 

做者 风河 发布于 2016年1月13日 | 讨论

 

编者按：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在应用程序里来调用它们。

随着云平台规模愈来愈庞大，慢慢暴露了OpenStack的一些弱点，好比结构复杂、可靠性通常、扩展性弱，致使咱们在云的可控性方面大为被动，从而产生了第二代云平台的需求。

那么咱们须要一个什么样的云呢？首先，它是基于私有云。其次，这个私有云必定知足咱们业务的特色，好比游戏行业与金融行业，业务特色大相径庭。再次，这个云必定要可管理、可扩展、可控。对于一个平台服务，它存在性能短板、运行故障并不可怕，可怕的是出问题后用户没法跟踪和定位，从而失去可控性。

云平台架构的演进

在Cloud 1.0里，咱们并无实现租户网络，不一样的游戏厂家都接入同一Flat网络，这对隐私和安全都不利。网络架构以下：

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

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

咱们看到图里标明了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的一张图来描述：

怎样实现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的缘由。咱们须要开发一套应用程序，完成对这三套底层系统的调用、调度、监控和反馈。而这套应用程序就是本身的云平台实现，它的架构参考以下：

由于虚拟网络（又称软件定义网络、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还在开发阶段，在实现过程当中确定还会遇到各类问题和困难。期待它上线后能改善现有的问题，带来更好的性能、扩展性和安全性。若是您对咱们的技术方案有任何疑问或