正文
在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头部，将包转发给因特网网关。
数据包离开汇聚交换机后，到达网关就是普通的包。当然，由于支持多租户，每个租户的子网可能是重叠的，所以汇聚交换机和网关之间的通信走VRF。另外，VM默认都没有公网IP地址，所以需要网关兼具如下功能。
-
SNAT：从VM到公网的数据包由网关根据VRF进行源地址转换。
-
DNAT：VM的某个端口需要被外网访问，由网关根据端口进行目的地址转换。
-
Floating IP：少数VM需要一个独立的公网IP地址，在网关上进行一对一的映射。
图2-1中描述的接入交换机、汇聚交换机、网关都是独立的物理设备。但是，汇聚层和网关层也可以是PC服务器集群，既充当VXLAN网关，又实现NAT功能。
VPC的实现是Cloud 2.0与1.0的主要区别。在Cloud 1.0中我们使用OpenStack的Provider Network网络类型，它就是一个大的混合网络。随着规模的扩展，这种网络类型已经不能满足需求。所以Cloud 2.0的建设重点是实现每个租户拥有独立的VPC。比如用户A和B，拥有两个互不相通、彼此隔离的二层网络。用户A和B都可以自定义他们的网络地址段、路由、访问控制策略。关于VPC的架构，借用如图2-2所示AWS的一张图来描述。
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的原因。我们需要开发一套应用程序，完成对这三个核心系统的调用、调度、监控和反馈。而这套应用程序就是自己的云平台实现。
