3G Eden
RSS前言
YY游戏Cloud 2.0的开发背景详见《YY游戏私有云平台实践》。在Cloud 2.0里，虚拟网络的架构和实现是重中之重，本文主要谈及网络设计部分。网络设计一个核心功能是实现租户网络（VPC），我们采用VxLAN技术来构建VPC。考虑到性能和稳定性，使用带SDN功能的硬件交换机来完成VXLAN的offload和routing。同时，游戏运营有特殊的业务需求，例如云网关功能。处于同样的考虑，采用硬件防火墙来实现云网关，包括南北向的NAT和Floating IP。在这个方案里，还支持不同VPC对共享数据区域的访问，也就是东西向的访问，同样使用硬件防火墙的NAT来实现。
在由客户端vSwitch、接入交换机、核心交换机、防火墙组成的虚拟网络里，数据流程跟传统网络没有太大的差别，但是数据结构非常不同。比如为了支持VPC，接入交换机要设置VNI（VXLAN网络标识），核心交换机上要配置VRF（虚拟路由器），防火墙上要开启vSys（虚拟子系统），它们处理的数据包不同于传统网络。而它们处理包的方式、转发路径，则取决于控制器的实现。在本文里，将对虚拟网络架构、数据转发流程、以及SDN控制器进行一个较为详细的描述。
虚拟网络架构
(点击放大图像)
这个架构的主要组成部分如下：
- SDN TOR：虚拟网接入交换机，负责VXLAN的封装和转发；
- SDN Core：虚拟网核心交换机，负责VXLAN的三层网关和路由；
- Firewall：防火墙，负责南北向的NAT网关，包括Floating IP；
- SDN Controller：SDN控制器，负责整个虚拟网络的配置管理；
- vSwitch：运行在计算节点上的虚拟交换机组件。
核心技术指标
在这个架构中需要实现的核心技术指标有：
- VXLAN功能offload到硬件交换机中实现；
- VPC内L2 VTEP，offload到SDN TOR；
- VPC内L3 VTEP，在接入侧offload到SDN TOR，在网关侧offload到Core Switch；
- VXLAN VNI和 VLAN 实现解耦，VLAN根据物理位置和VNI进行动态映射；
- NAT和VPN做在硬件防火墙；
- 每个Core Switch支持至少4K租户（取决于核心交换机能力），可以通过横向扩展，支持更多租户；
- 通过在vSwitch或者TOR上启用ARP代理，避免ARP广播到物理网络；
- 流表通过控制器预先下发，而不是通过动态学习；
- Floating IP使用硬件防火墙实现，提高转发性能；
- 除了虚拟机外，还支持物理机接入；
- 控制器支持运行时无缝动态增加、删除网元设备；
- 控制器和Agent不依赖OpenStack组件，可独立部署和实现；
- OVS和Agent运行的宿主机环境，稳定支持Ubuntu 14.04 LTS操作系统和对应的最新内核(linux-image-generic)。
SDN控制器
控制器架构
(点击放大图像)
云平台门户调用RiseCloud API，完成跟虚拟网络的对接。RiseCloud API是YY自己实现的、高度抽象的网络控制器接口。它北向是一套简单的API，类似于OpenStack的Neutron API；南向跟厂家设备、厂家控制器以及跟第三方控制器集成，共同完成对虚拟网络的管理。
控制器功能
- 交换机、物理服务器、VM、租户网络等信息映射关系管理。
- VM端口配置、ACL、QOS等。
- 租户网络配置管理，租户二层网络创建、删除、变更等。将VXLAN功能实现在TOR交换机上，并随资源变化能够动态进行更新。
- 三层路由转发功能，为每个租户创建三层路由vGW，可实现ACL、Routing、QOS等功能。在核心交换机上为每个租户创建一个VRF，通过VXLAN Routing实现租户路由转发。
- 南北网关功能，为每个租户实现一个南北向网关，可实现防火墙规则、NAT、PAT功能。通过专业硬件防火墙，为每个租户创建一个VR，实现地址管理、NAT规则等独立操作。
- 共享数据区域访问，为租户提供对共享数据区域访问（IP地址、端口访问）方式，通过防火墙PAT功能，按需进行动态地址和端口映射。
- 网络监控，监控交换机、物理服务器、虚拟机、虚拟端口、流量等信息，汇总至Controller进行统一呈现。
- 诊断分析，提供配置检查、内网发包诊断、租户内网数据抓包分析、按协议/应用/地址等进行流量分析功能。
数据转发面架构
数据转发架构图
(点击放大图像)
-
南北流量
如图所示，租户子网南北流量路径为：
ToR <–> VXLAN <–> 核心 <–> (GW1)防火墙 <–> NAT/PAT -
跨子网东西流量
如图所示，租户跨子网东西流量路径为：
ToR <–> VXLAN <–> (GW3)核心(GW3) <–> VXLAN <–> ToR -
跨机柜同子网流量
如图所示，租户跨机柜通子网流量路径为：
ToR <–> VXLAN <–> ToR -
共享数据访问流量
如图所示，租户共享数据访问流量路径为：
ToR <–> VXLAN <–> ToR <–> (GW2)防火墙 <–> PAT
注：以下网关类型分别为：
- GW1：南北网关
- GW2：资源区网关
- GW3：东西网关
L2流量转发过程
同TOR同hypervisor内同网段VM转发
主要利用Open vSwitch的流表进行转发，这时需要SDN控制器向Open vSwitch下发对应的流表。对于arp报文，需要匹配arp request从hypervisor和TOR连接的端口送出，将报文送到TOR上，由TOR的arp proxy代理完后发回来。arp reply匹配vlan + macda后，送到正确的VM上完成arp通信。数据报文匹配in_port + macsa完成tenant VM的识别后，送到另外一张L2转发流表，该流表匹配报文的macda后送到指定的VM完成数据报文通信。
同TOR不同hypervisor内同网段VM转发
主要利用Open vSwitch的流表和TOR fdb进行转发，这时需要SDN控制器向Open vSwitch下发对应的流表。对于arp报文，需要匹配arp request从hypervisor和TOR连接的端口送出，将报文送到TOR上，由TOR的arp proxy代理完后发回来。arp reply匹配vlan + macda后，送到正确的VM上完成arp通信。数据报文匹配in_port + macsa完成tenant VM的识别后，送到另外一张L2转发流表，该流表匹配报文的macda后送到hypervisor和TOR连接的端口。报文送到TOR后，根据fdb表完成二层数据转发，完成数据报文通信。
不同TOR不同hypervisor内同网段VM转发
主要利用Open vSwitch的流表和TOR tunnel offload、core switch fdb进行转发，这时需要SDN控制器向Open vSwitch下发对应的流表。对于arp报文，需要匹配arp request从hypervisor和TOR连接的端口送出，将报文送到TOR上，由TOR的arp proxy代理完后发回来。arp reply匹配vlan + macda后，送到正确的VM上完成arp通信。数据报文匹配in_port + macsa完成tenant VM的识别后，送到另外一张L2转发流表，该流表匹配报文的macda后送到hypervisor和TOR连接的端口。报文送到TOR后，根据下发vlan 和vni的对应关系，封VXLAN报文送到core switch，在core switch上根据fdb表转发VXLAN报文，送到对端TOR上完成数据通信。
L3流量转发过程
(点击放大图像)
主要利用Open vSwitch的流表和TOR tunnel offload进行转发，这时需要SDN控制器向Open vSwitch下发对应的流表。对于ARP报文，需要匹配ARP request从hypervisor和TOR连接的端口送出，将报文送到TOR上，由TOR的ARP proxy代理完后发回来。ARP reply匹配VLAN + macda后，送到正确的VM上完成ARP通信。数据报文匹配in_port + macsa完成tenant VM的识别后，送到另外一张L2转发流表，该流表匹配报文的macda=core switch mac后，送到hypervisor和TOR连接的端口。报文送到TOR后，根据下发VLAN和VNI的对应关系，封VXLAN报文送到core switch。core switch收到VXLAN报文后，根据报文里的VNI信息，找到对应的VRF信息（一个VRF对应于一个虚拟路由器），查找相应的路由（看core switch支持情况，32位主机路由还是网段路由），将对端网段VNI信息再封成VXLAN报文送出。TOR上解封装后，翻译VNI和VLAN的映射关系，送到hypervisor上查流表进行转发。
总结
YY游戏Cloud 2.0建设是一项全新的尝试，我们让不同厂家的硬件设备和驱动、第三方控制器、YY自己的RiseCloud控制器、YY云平台业务系统有机的整合起来，组成一个高性能、高可靠的虚拟网络系统。在这个过程中所取得的成功经验和失败的教训，我们也乐于分享，期望对国内企业的私有云建设有所帮助。同时感谢合作厂家包括华为、H3C、云杉在技术方案、测试设备等方面对我们的大力支持。
如果您在SDN、QEMU/KVM、Ceph、Libvirt任何一项有长足的经验，都欢迎与我们联系：me@fenghe.org，YY游戏云平台欢迎各路有志之士加盟。
