YY为什么放弃OpenStack?YY游戏使用云平台的经验及云计算随想

Posted 2021-04-24 云技术实践

1、为什么放弃OpenStack

YY游戏第一代云平台完全基于OpenStack构建。计算服务使用Nova和KVM，网络服务使用Neutron和Provider Network，没有使用分布式块存储服务。Cloud 1.0出现过一些问题，但也承载了数款游戏的运行，其中不乏峰值流量很高的游戏。促使我们远离OpenStack的原因，主要还在于这个系统不成熟、不稳定、扩展性差。

从全局来看，OpenStack存在的问题包括：

• 项目庞大复杂，过多的模块、扩展、功能让这个产品很难部署使用，出错时也难以调试。

• 发布质量一般。目前是按时间周期发布，每个版本的维护时间过短，且旧版本不支持无缝升级到新版本。整个项目不太注重生产环境的可用性。

• 项目的代码量仍然在持续增长，但是不注重代码质量和功能完整性。很多部分实现的功能成为遗留代码。

• 可控性差，对运维的素质要求非常高。

如下是我们在生产环境中面临的具体问题：

• 由于Neutron租户网络存在l3-agent瓶颈，无法实现生产环境可用的租户隔离网络。

• Metadata服务存在明显的性能问题。Metadata 服务网络结构复杂，容易导致VM创建或者重启失败。

• 直到IceHouse版本，仍然不能在线无缝升级。升级不方便加上旧版本的维护时间短，不适合生产环境大规模使用。

• 授权体系一直是软肋。默认的policy.json不安全，也不支持全局动态配置权限。

自身的Bug影响稳定性，上游社区不重视。已知的Bug包括：

• Keystone性能Bug。

• Neutron定时任务执行稍有异常就清空OVS配置。

• Neutron DHCP 服务器（Dnsmasq）性能问题。

• 在某些情况下，动态迁移（Live Migration）不支持按Region迁移。

• 动态迁移的实现没有考虑超时和网络不通时如何进行恢复。

这些原因的存在，促使我们最终下定决心开发第二代云平台，从零开始打造一套适合自己的企业私有云系统。

2、Cloud 2.0研发思路

典型的云计算平台包括三个核心部分：虚拟计算、虚拟存储和虚拟网络。

• 虚拟计算通过内核虚拟化方式，将计算资源如CPU、内存等虚拟成若干个独立子系统，从而提高资源利用效率。

• 虚拟存储将传统的硬件存储作为服务抽象出来，云主机以网络方式挂载，可以按需使用，并具备高性能、高可用性、弹性伸缩的特点。

• 虚拟网络将大的物理网络虚拟成若干个独立的逻辑二层网络，彼此隔离，每个逻辑网络又可以再划分为三层子网，从而实现虚拟私有云（VPC）。

上述三个部分，虚拟计算和虚拟存储都有相对成熟的解决方案，前者用libvirt/KVM可以实现，后者典型的有Ceph分布式存储。而虚拟网络的实现，虽然市场上有很多软件、硬件方案，但并没有达成统一标准，成熟度不高。而且每个业务公司的需求不同，虚拟网络在架构、设备、控制器方面的需求都不同，定制化程度比较高。但虚拟网络又是整个云平台的核心基础，没有虚拟网络支持，无法实现VPC，云的意义就不大。

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

图2-1  YY游戏Cloud 2.0云网络基本架构示意图

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

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

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

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

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

图2-2  AWS VPC架构示意图

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

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

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

因为虚拟网络是我们前期设计的重点，所以本节也基本围绕它来进行讲解。虚拟网络的本质是控制器的实现，控制器是虚拟网络的灵魂。VXLAN网络中大量的数据交互，都需要控制器参与。

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

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

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

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

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

计费我们在Cloud 1.0里做得不好，Cloud 2.0应该予以完美实现。用户的计费模型里，纵轴是时间维度，横轴是容量或能力维度。容量包括内存大小、磁盘大小、带宽多少等，能力包括CPU计算性能、磁盘读写性能等。提供灵活的计费能力，按需使用，用多少算多少，对客户无疑具有更大的吸引力。

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

最后说说可控性。在Cloud 1.0中虽然使用了OpenStack，但却远没达到掌控自如的程度。OpenStack庞大复杂，众多的组件、复杂的交互关系，以及并不太好的软件质量，让我们望而止步。所以在Cloud 2.0中，我们的基本目标之一是可控。

现在，虚拟网络自主实现，以及虚拟计算和虚拟存储，都有经过验证的可行方案，只需要业务层做好整合，整个系统就具备可控性。过去的云平台出了问题，难以发现原因，即使发现了也难以深层次跟踪问题。而在Cloud 2.0中所有调用和调度都自己实现，出问题后跟踪和分析能力得到大大提升。

3、发展规划：基于云的VDC实现

内部IT基础资源云端化是当前互联网行业的主要趋势。云平台将资源管理抽象出来，比如云主机、云DB等，以服务的方式提供给用户，按需使用，从而带来更大的灵活性与经济性。YY游戏早已建立面向内部业务使用的云平台，例如升龙部署系统[1]。

随着主机、DB、缓存、存储等独立服务抽象出来，必然需要一个大的容器，将这些个体服务整合成一个整体。这个容器就是VDC，即虚拟数据中心。在传统IT环境中，主机、DB、缓存、存储服务器都位于物理DC（数据中心）中。在云端化进一步发展后，物理DC也将抽象出来，形成VDC，在更高的层次上为用户提供基础服务能力。

VDC带来的收益包括：

• 安全。每个VDC彼此隔离，一个VDC中的安全问题，不会影响到其他VDC。比如某台主机被黑，黑客难以渗透到这台主机所在VDC之外的其他VDC。

• 灵活。VDC中的每个资源，甚至包括VDC自身，都以服务的方式提供，用户可以通过控制面板或者API的方式来使用这些资源。相比物理DC，其存在极大的灵活性。

• 经济。VDC中的资源按需使用，对成本管控无疑有利。

• 易管理。对于大而杂的物理DC而言，最大的问题是容量管理。每个物理DC中都混合了多个业务，在统计它们的容量时很头痛。而VDC与项目挂钩，每个项目使用一个独立的VDC，在容量管理方面就容易很多。可以统计出历史容量报表，并根据业务发展趋势（PCU、DAU等）自动做好容量规划。容量管理对象包括CPU、内存、磁盘、带宽等。

VDC内部资源包括各个抽象化的具体服务，如云主机、云DB等，如图2-3所示。

图2-3  VDC的服务组件

这些抽象化的个体服务位于虚拟私有网络中，用户接入VDC后，访问它们就如同在物理DC里一样方便。第三方管理服务，比如部署系统、研发管理系统、监控系统、QA系统都实例化运行，在每个VDC中发挥作用。升龙部署系统有点类似于AWS的OpsWorks，是一个综合部署与运维平台。

VDC的发展趋势必然是跨物理DC。在分布于各地的物理DC基础上，抽象出面向用户的VDC服务。而用户甚至无须关注物理DC的分布，只需要按正常方式使用VDC资源，由VDC自身来保证服务的架构、性能、扩展性，如图2-4所示。

图2-4  VDC在物理DC基础上提供更灵活的服务能力

用户的项目或者项目组接入专属的VDC。VDC之间彼此隔离，并不能直接通信，如果需要通信可以走VPN隧道连接。位于办公室的用户，也可以通过VPN的方式接入生产网VDC。在YY游戏云平台上，每款游戏都接入一个独立的VDC。

随着技术的发展，物理DC的硬件条件，包括空调、电力、安防、监控等，也可以逐步抽象成服务，为用户的VDC提供更完善的基础服务。在不久的将来，互联网公司的VDC发展将全面取代物理DC，以实现更加灵活、

---

[1]   升龙部署系统介绍：

     http://blog.dnsbed.com/archives/958

本文节选自YY游戏云平台组新书《自主实现SDN虚拟网络与企业私有云》第二章，本书已经在各大图书平台有售。

相关阅读:

交流 分享 提升