从1.0的OpenStack到2.0的自研，YY 私有云建设历程|附音频

大家好，我是来自虎牙信息的刘亚丹，简单介绍下自己，当前任职虎牙信息，9年的互联网运维经历，最近几年主要的工作都在私有的 IaaS 和 PaaS 平台建设和运维管理上，基于这些经历，去年参与了团队的书籍《自主实现 SDN 虚拟网络和企业私有云》的编写，这本书主要是把我们这些年在 IaaS 私有云平台建设和运营的经验，教训的总结。今天给大家带来分享主题是《YY 私有云建设历程》，希望今天的分享，对于正在从事或者想要进行私有云建设的企业，在参考借鉴 OpenStack的之外，有一个新的参考。

现场调查下：有多少朋友自己的公司以及构建或者准备构建私有云的？BAT 公司除外

需求背景：分享下我们为什么需要私有云

建设历程：分享下我们云平台基于 OpenStack 1.0版本的主要架构和功能，遇到的问题，基于这些问题和经验，如何重新选型，建设一个新的云平台。

虚拟网络实践方案：分享下 YY2.0平台基于硬件实现 SDN 网络的整体流程和方案，在控制平面和转发平面分离的具体实践方案，以及转发平面上，东西向和南北向流量转发的整体流程。

集成方案：最后分享下，基于前面的网络选型，2.0版本云平台对计算，网络，存储集成的整体架构。

YY 游戏推出私有云 IaaS 平台，是完全基于自身的业务需要出发的。

规模性：在09年-14年，YY 游戏平台的页游运营平台发展很快，我们需要为页游运行提供大量的服务器资源，一款好的页游，可能需要上千台的服务器。

页游的特点是开服快，生命周期短，非 CPU 密集型。我们发现，我们经常为一些游戏业务紧急采购服务，但提供的出去的很多物理CPU资源利用率不高，而我们资源回收效率不高。页游服务器的资源利用率在开服前几天较高，之后CPU利用率都会比较低。

公司内部的 web 类业务发展需要：随着 X86服务器硬件计算能力和内存的不断升级，单个服务器的性能也越来越强，服务器利用率不高，而通过单机部署多个应用，不利于管理，通过虚拟化，我们制定一套 web 业务部署标准，通过我们上层的 PaaS 平台，将单个 VM，只部署一个应用，实现应用资源的快速分配，通过引导开发进行无状态的程序设计，实现 web 应用的弹性伸缩，提高资源的利用率和运维效率，提升业务质量。

云计算发展大势所趋：13年的时候，云计算的理念也开始在国内很多企业逐渐被接受。我们调研，以及对比业界其他的游戏平台，都在采用虚拟化支持游戏业务，因此，我们希望推出自己的私有 IaaS 云平台，来满足业务发展，通过规模效应，提升资源的交付效率，资源利用率以及资源的回收效率，降低游戏运营的整体成本。

1.0平台，提供云主机，云网关，云DB，云缓存，云 CDN，云监控，云存储这些功能，满足了业务交付的基础环境，其中云主机是完全基于 OpenStack 实现了。

云主机的网络实现上，采用的是 provider network 的 flat + vlan模式。在具体表现为：公网模式：flat 网络，公网电信，联通 ，内网 IP 绑定在 VM 上,这和我们常见的双线机房物理机模式完全一致。这里面在实现上，H 版本我们通过 neutron 的扩展插件来实现的。在 I 版本后，通过关联 IP 来实现。

云网关模式： VM ，不带公网 IP，VM 上仅绑定内网 IP，使用的 flat+vlan tag 的模式。

云网关采用的技术实现是 LVS+NAT，每个游戏区服对应LVS VIP一个端口。

这个平台上，我们曾经有月流水过亿，同时在线十几万用户的页游运行在上面。

OpenStack的优势：

架构理念先进，通过核心的 MQ 通信，异步解耦，提供了非常灵活的 API,,使各个组件可以灵活的开发和功能扩展。OpenStack极大地加速了技术选型的过程，并带来了丰富的应用、社区资源以及技术人才。

这样一个基于 OpenStack 的私有云平台，随着规模的增长，暴露了越来越多的问题，使我们在运营中，遇到很大挑战。

具体体现在：

稳定性方面：架构组件复杂，底层软件的稳定性难以保证，我们曾经遇到，升级 OVS 内核版本的时候，导致 ARP 冲突，网络泛洪的问题。各个组件的代码质量不高，小问题较多，比如 metadata 服务不稳定，导致 VM 创建失败。

可维护性方面：OpenStack 是安装部署复杂众所周知，安装成功一套 OpenStack 单机环境，即使借助官方提供的脚本onestack.sh，一旦配置失败，调试难度非常大，对运维人员素质要求非常高。另外，缺失平滑升级的方案，是作为产品化不成熟的重大问题，我们的生产环境存在3个版本（H,I,K）。

扩展性方面：比如使用 Tenant network 的时，L3-Agent 是明显的性能瓶颈而且没有高可用解决方案，同时最新的 DVR 分布式虚拟路由功能也还处于测试阶段。而随着规模增大，大概到300台宿主机的时候，dnsmasq 和 keystone 的性能也出现瓶颈。我们当时压测，请求keystone 服务响应获取 token，每秒的并发能力不到30个，性能非常差，最终我们通过分析源码，定位到在认证 token 的过程中，使用了一个无必要的分布式锁，造成请求阻塞，最终通过注销这一段代码， 性能提升了十倍以上。

以上这些问题，导致云平台1.0的运维难度越来越大，迫使我们思考，应该提供一个什么样的云平台。

在Cloud 2.0中，重点解决租户私有网络（VPC）的实现问题以及云平台可控性。

Ø 以开源软件为基础，自主研发为核心，专业厂商为关键补充

m 虚拟计算：采用相对比较成熟的 KVM内核虚拟化方案

m 虚拟存储：将传统的硬件存储作为服务抽象出来，云主机以网络方式挂载，可以按需使用，并具备高性能、高可用性、弹性伸缩的特点。采用 Ceph，相对来说比较成熟。

m 虚拟网络：实现虚拟私有云（VPC）

虚拟网络选型：出于前面提到的原因，我们并不打算采用OpenStack的租户网络方案。在充分调研和学习的基础上，我们设计了一套基于硬件的解决方案，其中VPC、子网、路由、云网关都采用专用网络硬件来实现。

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

云平台控制台，抛弃组件复杂的 OpenStack，全新设计一套云管理平台，实现对计算，网络，存储的调度，包括权限认证和授权管理。这一块在1.0的建设中，我们已经积累了很多的经验。

虚拟网络的本质是控制器的实现，控制器是虚拟网络的灵魂。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，南向接口是自己实现的驱动，这也完全可以。

这张图，介绍下基于硬件的 VXLAN 网络和集中式的组合网关的 VPC 网络架构，在东西向流量处理和南北向流量处理的流程

VTEP: VTEP是VXLAN隧道端点，用于 VXLAN报文的封装和解封装。VTEP与物理网络相连，分配有物理网络的 IP地址，该地址与虚拟网络无关。VXLAN报文中源IP地址为本节点的VTEP地址，VXLAN报文中目的IP地址为对端节点的VTEP地址，一对VTEP地址就对应着一个VXLAN隧道。

VNI: VXLAN网络标识（VNI）类似于VLAN ID，用于区分VXLAN段，不同VXLAN段的虚拟机不能直接进行二层通信。一个VNI表示一个租户，即使多个终端用户属于同一个 VNI，也表示一个租户。VNI由24比特组成，支持多达16M（(2^24-1)/1024^2）的租户.

我们从坐下方的红色区域开始，红色区域是位于同一宿主机下的，属于同一个 VPC 下的两个 VM 。假如，这两个 VM 需要进行数据交换，VM 的数据发出后，会打上 vlan tag，然后上送到接入层交换机，这是个混合交换机，然后查看 openflow 流表项，确认其访问的对端 VM 位于同一交换机，直接将数据包转发到对端 VM 的端口，然后对端 VM 经过 hv，送到 VM

假如是夸接入交换机的场景，那么这个时候，接入层交换机将对此数据报文进行 VXLAN 报文封装，增加一个 UDP和 VNI 的信息，然后通过传统的以太网，上送到核心层的 VTEP，核心层的 VSI, 虚拟交换机，会解开这个 VXLAN 报文，找到目标 VM 对应的 VTEP，然后继续进行 VXLAN 封装，并将此报文发送到对应的接入层交换机，进入到对端的接入层交换机后，同样进行封装，还原成原始的数据报文，然后将数据包发送到目标 VM 的端口上，最终夸交换机的 VM 收到了数据。如果是夸子网的访问，这种场景下还需要通过 Vrouter 来进行路由。

如果是 VM 访问公网，会涉及到 VXLAN的解封装和 防火墙的SNAT。数据包进入到核心交换机后，Vrouter 发现这个包是访问的外部网络，则将此报文上送到虚拟防火墙，虚拟防火墙将数据包的源地址进行转换，修改为 VM 的默认出口 IP，或者如果这个 VIP 有独立的 IP，也就是 floatingIP，则修改为对应的 FloatingIP地址。当数据报文从目标服务器返回数据时，则相应的在虚拟防火墙上做目标地址转换，并进入到核心交换机，然后通过 VTEP 进行 VXLAN 的网络包封装，最终通过 VTEP 找到对应的接入层交换机，最终把数据发送回 VM。

上面这张图，展示了云平台在创建 VM 上，与各层组件组件的整体交互流程。

比如，新建一个 VPC 网络，云平台会下发指令到 SDN 南向接口，比如创建二层网元（vPort），创建三层网元(vRouter)， 创建 FW(NAT,FloatingIP)等等。控制器接受到指令后，将对各层的网络设备进行操作，然后返回结果到云平台。比如控制器下发指令到接入层交换机，配置 VXLAN，以及VXLAN映射 VNI 的配置。云控制台与宿主机交互，创建配置 OpenVSwitch，配置 VM 相关配置。

整体模型

分为3个网络，数据网络，管理网络和 Ceph 内网

数据网络：承载 VPC 网络，利用 VXLAN 虚拟化技术构建叠加网络。

管理网络：组件内部通信，存储集群数据访问

Ceph 内网：用于 ceph 集群内部通信。

数据网络-架构简单描述：

Ø SDN Hybrid Switch构

Ø Controller集群集中控制

Ø 采用核心层-接入层结构

Ø 核心 Switch：采用CLOS架构核心交换机，多级多平面无阻塞交换架构，双机高可用热部署

Ø 接入层：40GE 双归接入

Ø 防火墙：旁挂核心 Switch，采用主-被部署

管理网络-架构简单描述：

Ø 通用L3 Switch构建

Ø 采用核心层-接入层结构

n  10GE接入

n  40GE汇聚

Ø 与Data net共用核心交换机，核心交换机用作数据中心出口设备

Ø 接入层 Switch使用40GE双归接入核心 Switch

三套方案，都可以实现我们的 VPC 网络需求。

最终选择处于性能，稳定性，成本，上线时间要求等因素，最终我们选择了 H3C的整体方案。

计算，存储，网络集成

在 OpenStack 上，计算节点的网络结构非常复杂，层级非常深，这个对性能和稳定性都有影响。这种架构设计是因为 Neutron 网络保持足够的灵活性，可以支持 flat，vlan，gre 等等模式。

在2.0版本中，计算节点的网络结构非常简单，只用了 openvswitch 组件，功能上只用来打上 tag，没有用到流表等功能。这样的架构，对计算节点的性能和稳定性都带来很大好处。

存储选型 ceph，分布式存储，理论上具备高可用，可扩展的能力。在 VM 迁移上，比起本地硬盘模式，速度更快，可实现秒级迁移。在性能上，我们经过ace 对比，不断调优，性能上达到公有云 SATA 硬盘的水平。

同时，我们仍旧提供了基于本地硬盘的模式，提供 VPC 内的 MySQL 实例服务。在 VM 启动上，metadata 通过VM 挂载网络硬盘到本地的 CD-ROM，clouinit读取启动所需要的元数据启动，包括，主机名，监控配置等等。

在云主机创建流程中，对虚拟网络的操作主要涉及vPort的创建。主要过程如下：

在创建虚拟机vPort之前，首先必须创建租户和虚拟网络的Network、Subnet，然后创建或者更新VLAN-VXLAN映射关系，并且VLAN-VXLAN映射已经绑定到接入网元VTEP设备。

在创建虚拟机vPort时，指定IP地址和MAC地址。

控制器收到虚拟机发送的ARP报文后，在控制器上创建ARP表，根据IP地址查找北向创建的vPort，并上线对应的vPort。

控制器上vPort上线后，给所有VTEP下发该vPort MAC地址的OpenFlow流表，打通了虚拟二层网络转发。另外，给网关资源下发该vPort IP 地址的OpenFlow流表，打通了三层网络路由。

• 上线和迭代

• 部分业务测试

• 功能，稳定性磨合

• 关键组件质量保障

• 集中式网关的性能，稳定性

• 集群性能,稳定性,容量保障

另外，我们团队出版的这本书，详细描述了我们实践的构成，各个章节都具有很强的实践性，其中，在虚拟网络章节，包括从原理，到组网，接线图，都有详细描述，可以说是目前市面上，关于私有云建设非常具有参考价值的书籍，如果现场有同学感兴趣，我们的出版社小伙伴现场签售，感谢大家支持。