云网络技术总监张宇:金山云混合云网络架构

11月 29日消息，以 " 新技术 · 新架构 · 新网络 " 为主题的 "GNTC 全球网络技术大会 " 第二天，云和数据中心专场，云网络技术总监、金山云张宇发表了主题演讲。

▲云网络技术总监、金山云张宇

演讲实录如下：

做云计算首先是耐IDC或者耐资源的生意，金山云用了三年的时间做了资源上的积累，现在包括数据中心和服务器的数量，CDN的节点数，CDN的带宽，CDN节点数量都有非常好的积累。目前数据中心是以六个数据中心为主，国内是北京、上海，包括现在建的华南，国外以香港和美国，包括现在正在自建的新加坡节点和俄罗斯节点为主，CDN是覆盖了全国各省各个中大到大城市。从网络产品角度来讲，最底层是VBC，VBC里面包含虚拟机、云组机和云物理机，基于VBC衍生出了网络化的产品，包括NAT、VPN等。在这之上还有云解析，还有KIS。

混合云产品有哪些呢?公有云角度支持云主机和云物理机的混合，也包括专属云。同样云IDC也包括私有云解决方案，也可以保函用户自己的物理机托管服务，同时我们可以混合云互联产品做互联互通，同时还可以多云互联，包括和国内各大云厂商做一个互联的解决方案。从管理角度讲提供了多云互联的解决方案，最上层可以通过智能DNS做流量调度实现跨异地的高可用。

下面简单介绍一下和混合云相关的产品，一个是专线，专线的好处就是带宽大、延时低、用户独占、传输安全，同时具有高可用性。然后我们和各个POP点做了合作，用户接入专线的时候不一定接入机房，可以和POP点做就近的接入。

VPN专线比较好，但专线也比较贵，除了专线之外我们还提供VPN产品，通过VPN加密隧道实现传输，和客户IDC做互联互通。

下面介绍一下云物理机，也就是EPC产品。刚才提到一个特点，我们既可以部署虚拟机也可以部署物理机，这样对于用户来讲，他可以把自己一部分CPU密集型或者IO密集型的业务可以做到资源隔离，不和其他用户进行抢占，同样他可以部署云组机，能够享受弹性的好处。

专属云的产品是今年新推出的产品，我们内部叫它公有云上的私有云，作为用户来讲可以租宿主机，通过调度和控台进行定义，在宿主机上面如何部署物理机，包括迁移策略都可以定义。

前面都是介绍我们的产品，下面开始具体的介绍一下我们是怎么设计这套云虚拟化网络的。首先有四个设计原则：稳定性通过SLA保证;性能包含自研设备的性能，其次我们作为云服务厂商要提供给很多用户同等的服务能力，所以在用户侧的角度来讲，用户的QOS性能保障对我们来说也是性能保障的重要部分;可扩展性包括横向扩展、纵向扩展，包括我们都是多AZ的角度，我们也要考虑多AZ;灵活性云产品对于虚拟化是非常重要的，首先云网络需要支持云上各个产品之间的互联，包括存储产品、计算产品，包括IDS，大数据或者AID产品，同时我们要满足用户很多多样性的产品。在做的过程中发现很多场景不是一开始设计到的，而是用户给我们提出需求才想到。

最后尽量让云网络使用起来和物理网络没有差别，让用户可以进行修改达到直接上屏的目的。

最后实现方式，从实用技术方面我们实现了Vxlan技术，这是当前比较通用的技术，然后我们基于DPDK实现，然后我们用了分布式的方案，摒弃了集中式的。硬件的演进过程我们现在处在10G-25G变化的过程，到40G主要是网关，Network Function网关目前是从10G-40G的过渡，100G主要是针对与AI的场景。Smart NIC是可编程的网卡，我们希望通过它可以实现更高的性能提升。EVPN之前提到了，刚才说到我们包含云组机和云物理机。从具体的实现来看，首先以VPC为核心，通过自研的Network Function实现Service Chain，这个实现数字面，控制面实现配置的统一管理以及流量的路径配置，从实现思想上来看是典型的SDN+NF。

我们的实现包含三部分：Vrouter、NFMB、Controller，我们的云组机可以实现封闭VPC，但是对于用户来讲仅仅是提供封闭式的VPC远远不够，所以VPC需要与各个方向做个互联，所以Network Function实现的方向就是和VPC打通，实现各个方向和VPC互联。右边是和混合相关的互联产品，包括IDC，用户IDC和VPN专线，以及peer功能实现互联互通。

下面讲一下他们的具体实现，刚才讲我们有VM，也有BM。所以说我们的Vrouter有两种实现方式，对VM来讲大家比较好理解，实际上就是部署在每个计算节点。对于BM没有这一侧，我们可行性调研决定把Vrouter上移，同时用EVPN简化配置定量。

VM的Vrouter首先是分布式的，这点非常重要，因为相对于分布式还有一种部署方式是集中式的部署，就是我在网络上选一些Network节点，专门做转发，快速做的话网络游单点的问题还有性能瓶颈的问题，使用分布式的Vrouter就解决了这个问题，每个Vrouter主要关注宿主机上的流量转化就可以。其次为了提高Vrouter我也借助了一些特性，可以使2-3G的存储达到10G的存储。后面是Vrouter的演进过程，最初我们是内核版的Vrouter，后来我们演进了一版，当前的一版处在DPDK的版本，同时也有优化，提高了PTS能力。最终的方案是Smart NIC方案，我们希望能把Vrouter放在网卡硬件里面，能完全不占用计算节点CPU资源，同时能够给虚拟机提供接近于硬件的IO性能。

对于云物理机的Vrouter实现，刚才一直提到EVPN概念，EVPN是什么呢?顾名思义就是二层VPN协议。之所以选择EVPN是因为它的实现和我们VM的实现是非常相似的，采用它的方案对我们来说很自然，也是比较好融合。我们做了哪些工作呢?首先controller他们要有管控的能力，这个管控的能力是做一些基础配置的下发，里面所有相关的转发学习全都交给EVPN来做。在做MPBGP使用了常用的RR方式，同时我们对RR做了一个Monitor，一方面可以监控整个网络上路由的情况，第二方面可以通过Monitor注入路由，这样可以实现封闭的VPC。实现封闭的VPC对于用户来讲完全没有意义，所以我们在这个基础之上做了二次开发，使得能够支持我们LB、EIP、NAT专线等等网络产品，像使用云组机一样使用云物理机。

除了Vrouter，第二部分主要是NFMB，首先是X86全是基于DPDK来做的。演进的话当前处在40G的阶段，这个演进也是根据流量吞吐需求来做的。右边是Network Function的演进图，最初是在DPDK写一个Function，后来发现效率很低，就使用一些抽象的层，我们实现一些高性能网络的相关库，比如路由、VCL，还有查找的算法，这样的话我们的开发者就可以专注于Network Function这一层，最近的引进不仅支持多厂商，还要支持10G、40G。这张图比较直观的Network Function表现了作为VPC窗户的功能。前面讲到了Vrouter是分布式部署的，相对来讲Network Function是集群式部署，集群式部署相对是集中式部署的概念，为什么这样做呢?原因，一个是采用NFA方式，目前阶段对于延迟和吞吐，没有办法对用户做到非常好的QS保障，其次如果采用NFA压力比较大，因为要管理NFA生命周期，对他来讲实现压力比较大。最终我们考虑到这些方面选择了偏集中式部署的方式。同时为了做故障隔离尽量把Network Function做到功能隔离，这样比如说握有一个单独的功能故障不会受到牵连整体的影响。

最后介绍一下Controller，从这个架构图来看是非常类似的，第一个是API服务，下面是API Cluster，通过MQ的机制作之通信，下面根据功能划分，划分为三种。一个是物理的网络设置，一个是Vrouter，Network Function还实现了一个功能是分租互配置Network Function，因为前面讲到Network Function是集群式部署，它可扩展，当然扩展是有限的。每一个Network Function的及亲怎么办呢?我可以新建一个集群二，Controller可以到新建集群上面，这样就解决了ECMP扩展性的问题。

下面举两个例子是Controller怎么灵活组织的。

第一个例子，常见的混合云运营场景。用户VPC机器想和IDC机器做互联互通，Controller要知道管理哪些设备，他做相应的配置分发就能打通链度。

第二个场景和第一个差不多，但用户是访问内网服务S3，流量到了Network Function，这个有一个能就是能把不同的Network Function串联起来，对用户来讲制造一个比较灵活的访问路径的定义。

前面介绍了整个混合云VPCD架构，其他还在做的，有内部存储，使用RDMA。我们希望能够通过P4+交换机的方式实现Network Function，对我们来讲从吞吐和可靠性来讲都有质的费用。PCP和UDP的优化是用在VPN场景上的。另外Smart NIC看能不能用自己的场景丰富它的功能。我们做的一切尝试都是为了用户提供更好的混合云网络服务。