服务器虚拟化改变了 IT 运营方式，随之而来的是越来越多的网络被虚拟化。
当今，几乎所有的 IT 基础架构都在朝云的方向发展。在基础架构中，服务器和存储虚拟化已经发展的比较成熟，作为基础架构中的虚拟网络，为了迎合云计算和互联网发展的需求，迎来了新的挑战，UCloud 虚拟网络平台负责人徐亮对此进行了梳理。
徐亮，UCloud 虚拟网络平台负责人，公司首位 5 级技术专家。先后任职于上海贝尔、腾讯，有超过 18 年电信与互联网行业研发管理经验。加入 UCloud 后主要负责云平台网络架构，包括 UXR 网络解耦、网络产品架构升级、虚拟网络架构升级等。
网络虚拟化与 SDN
网络虚拟化是一个历史比较悠久的概念，普遍认为最初的网络虚拟化是起源于 VLAN。网络虚拟化让一个物理网络能够支持多个逻辑网络。虚拟化保留了网络设计中原有的层次结构、数据通道和所能提供的服务，使得最终用户的体验和独享物理网络一样。因此带来了三大优势：帮助更好的利用网络资源，平摊被过度使用的资源上的通信量；无需部署专用物理架构就可以实现一些隔离操作，提高网络安全性；合并端口，以提高网络的利用率和性能。
SDN（Software-defined Networking）是将网络设备的控制平面（control plane）从数据平面（data plane）中分离，改用软件的方式实现，即软件定义网络。SDN 可使网络管理员在不变更硬件设备的前提下，以中央控制的方式用程序重新规划网络，为控制网络流量提供了新方案，也为核心网络和应用创新提供了良好平台，成为网络虚拟化发展的有力推动者。
云计算给网络虚拟化带来新挑战
首先，云计算，特别是公有云，需要网络虚拟化提供多租户和 VPC 的能力。 VPC（Virtual Private Cloud）允许不同租户甚至同一租户的网络地址重叠，广播域独立，必然导致对网络虚拟化的需求。最早的网络虚拟化是 VLAN 协议，但 VLAN 协议中的 VID 只有 12 个 bit，仅支持 4094 个虚拟网络，在公有云的环境下是远远不够的。这就促使公有云厂商纷纷引入 Overlay 技术解决这一问题。从早期的 NVGRE 到现在比较主流的 VxLAN，和比较新的 GENEVE，都支持 24 bits（16M）的租户 ID，满足了公有云的需求。
其次，云计算需要 SDN 帮助提供灵活、弹性的控制面。 传统网络中大多使用硬件设备，如果新增了一个租户，去配置硬件设备是一件比较困难的事情，因为每家配置都是不同的。但是如果用计算的方式，通过软件可以在不触及物理网络设备的情况下，动态的去修改网络配置，从而使网络虚拟化能够像计算一样轻松、快速、动态。
举个例子来说明：当租户 VPC-100 下的一台 VM10.10.12.34 要访问同子网下的另一个 IP 10.10.56.78 时，首先需要通过 ARP 协议去获得 10.10.56.78 的 MAC 地址。当这个 ARP 请求报文到达宿主机的 vSwitch 上时，由于 VPC 的存在 IP 地址可能被不同租户复用，所以首先必须要识别出该 ARP 请求来自 VPC-100，才能识别出这个 ARP 报文请求的是 VPC-100 下的 IP 10.10.56.78. 由于 Overlay 网络不支持广播，所以需要知道该子网下所有 VM 所在的宿主机在哪里，才能够把这个 ARP 请求加上 Overlay 封装送到目的宿主机上。当然如果 vSwitch 了解 VPC-100 的 10.10.56.78 的 MAC 是 52:54:12:34:56:78，也可以采用 ARP 代答技术，直接返回 ARP 响应。所有的这一切都不是依赖网络设备自动完成，而是通过 SDN 用软件控制实现的。
除此之外，Overlay 给物理网络也带来了非常大的复杂度，硬件的支持非常慢。徐亮在此举例为据：最流行的万兆网卡芯片 Intel 82599 不支持任何 Overlay 协议的卸载，直到今年 Mellanox 的网卡才开始逐步支持 VxLAN 的 TSO 卸载。而交换机芯片用了 5 年的时间才支持 VxLAN 协议，其他 Overlay 协议仍然没有交换机芯片支持，导致 Overlay 网络的性能长期低于物理网络。
UCloud 虚拟网络发展历程
在 2012 年 UCloud 成立之初，虚拟网络就是 IaaS 的一个核心组件，当时采用 EBTables 和 IPTables 的组合来实现租户隔离。但是 UCloud 的团队很快发现这个技术方案不足以向客户提供安全、稳定的服务。
于是从 2013 年开始，UCloud 的虚拟网络开始采用 SDN 技术实现租户隔离，也就是 VPC(Virtual Private Cloud)。同年年底，UCloud 意识到客户在使用云主机的同时也有使用物理机（bare metal）的需求，所以率先采用盛科的 SDN 交换机，推出了和公有云网络互通物理云主机产品。
2015 年，随着客户业务的快速发展，硬件 SDN 交换机 OpenFlow 流表有限的条目已经不足以支撑物理云主机的需求。UCloud 迅速开发了采用 DPDK 技术的服务器集群来替代硬件 SDN 交换机。随后更多的 DPDK 网关作为 OVS 的补充出现在 UCloud 的虚拟网络中，为客户提供更快速的虚拟网络。
从 2017 年开始，随着 25G 网络的发展，UCloud 开始研发基于硬件卸载的虚拟网络方案。最后确认下来的方向是可编程交换机和智能网卡两者同时推进。
在控制面流表管理方面主要有两种方案，被动触发方式和主动推送方式。被动触发方式是传统的 OpenFlow 流表管理方式，在收到报文时首先检查是否本地有流表命中，如果没有，则通过 OpenFlow Packet-in 消息发送给 Controller 处理，Controller 下发新的流表处理此类型报文。主动推送方式则是在网络拓扑发生变化的时候主动将变化的流表推送到转发面。
早期，UCloud 以被动触发方式为主。其优势在于实现简单，但缺点是首包会有延迟，且控制面受用户行为影响大，可能会有很多突发情况。针对首包延迟问题，UCloud 采用主动模拟用户对外发送报文的方式触发流表下发，达到类似主动推送的效果。针对控制面突发较多的问题，采用本地 Controller 先对 Packet-in 消息进行去重、限流后再发给远程 Controller 的方式进行规避。
在大量引入 DPDK 网关后，UCloud 也在使用主动推送方式。其优势在于有效消除首包延迟，且控制面压力更可控，不影响转发面。但主动推送方式存在的问题是，如果虚拟网络规模很大的时候，推送的范围就会很大，可能会造成推送时间过长而导致网络变化无法实时生效。
针对以上问题，目前 UCloud 也在探索两者结合的一些新方法。
UCloud 虚拟网络的挑战及解决方案
虚拟网络领域经过近 10 年的演进仍然处于一个快速发展变化、百家争鸣的阶段，同时也给 UCloud 虚拟网络团队带来了很多挑战。
转发面的挑战与解决方案
一、网卡性能大幅从 1G 提升到 10G、25G、100G 带来的性能挑战
网络性能的提升速度，已经超过了 CPU 性能提升的速度，这是一大挑战。UCloud 目前主要采用硬件卸载的方式来解决，包括可编程交换机和智能网卡。
可编程 P4 交换机方案
2017 年第四季度，UCloud 开始预研 Barefoot 的支持 P4 的可编程交换机（Tofino 芯片），发现 P4 and Barefoot Tofino 能够很好地满足需求。P4 and Barefoot Tofino 的优点主要有：
与 DPDK 相比，有更高的转发性能。DPDK 基本上用网卡的方式，单机 10G 或者 25G 的性能。对于可编程交换机来说，起步就是 8T 到 6.5T 的性能，相对于 DPDK 在性能上是几十倍甚至接近一百倍的提升。而且交换机的时延更低，它的单根网线支持 100G，基本上可以避免单线被拥塞的效果。
交换机的转发性能是很稳定的，并且是可以预期的，而 DPDK 的转发性能随业务模型可能会发生变化。
与其他硬件交换机相比，可编程 P4 交换机更开放。可编程能力强，可以定制转发面整个处理包的 p4lang。可编程 P4 交换机可以完美解决 Ethernet Over GRE 和 Flow Based Tunneling 的问题。用 P4 语言写程序，比用 DPDK 的 C 语言写程序更简单，开发效率更高。可编程 P4 交换机基本上采用 gRPC 的接口进行远程的管理，操作系统采用 Open Network Linux（基于 Debian），这使交换机更像一个传统的服务器。另外相对于其他交换机，可编程 P4 交换机有一个生态圈，有 P4 Runtime、Stratum 这样的开源社区，更好的促进交换机的发展。
目前 UCloud 采用 P4 可编程交换机完成了一个新增的核心 Gateway 的开发和测试工作，已经开始部署和灰度上线。
智能网卡方案
同期，在计算节点上，UCloud 也在探索如何解决 25G 网络带来的性能挑战。
在 VMware 主宰虚拟化的早期阶段，通过 VLAN 实现租户隔离，通过 SRIOV 的方式将硬件网卡虚拟化成多张虚拟网卡供虚拟机使用，是非常成熟而高效的解决方案。采用 SRIOV 的方式，虚拟机可以获得物理网卡 95% 以上的 PPS 性能。但 12 位的 VLAN 只能支持最大 4094 个租户，并不能满足公有云的需求，而二层的组网方式也不适合公有云的大规模数据中心。几乎所有的公有云都是采用的 Overlay 的解决方案。而 Overlay 的方案相对 VLAN 要复杂很多，大多数新一代非智能网卡的 ASIC 芯片目前仅可以完成 VXLAN 的封装和解封装工作，但虚拟机所在的宿主机地址信息需要控制面提供，使得 SRIOV 技术在 Overlay 的网络里完全无用武之地。
基于 DPDK 的 vSwitch 方案对比基于 Linux Kernel 的 vSwitch，在报文转发性能上提升了几倍。通过 DPDK 的 Vhost Library，VM 的网络报文可以通过 Virtio 虚拟网卡，以 Zero Copy 的方式到达宿主机上的 vSwitch 进行处理。宿主机上的 vSwitch 根据控制面信息了解目的 MAC 或者 IP 所在的宿主机信息，然后加上 Overlay 封装高速转发。但代价是绝大多数网卡只能支持 Busy Poll 的 DPDK 工作方式，无论虚拟机当前的 PPS 是多少，DPDK 都会占用固定的 CPU Cores，而这部分计算资源原本在闲时是可以出售的。
而智能网卡（SmartNIC）的目标就是将网络转发所占用的宿主机计算资源释放出来，从而达到降低 TCO 的目标。目前智能网卡的实现百花齐放，例如：AWS 采用基于通用 ARM 的众核方案、AZure 采用基于 FPGA 的方案、华为云采用基于专用网络处理器（NP）的方案、阿里云采用基于可编程 ASIC 芯片的方案。就目前来看各个方案各有优势，并没有特别突出一统天下的方案。
基于通用 ARM、MIPS 的众核方案，简单将原来跑在宿主机上的 vSwitch 移植到网卡上，既可以支持 Linux Kernel 也可以支持 DPDK，从而达到释放宿主机计算资源的目的。其他基于 FPGA、NP 和可编程 ASIC 的方案，大多在网卡上维护一个快速转发路径（FastPath），当收到报文后，首先检查是否在 FastPath 已经缓存了该类报文的处理规则，如果找到，则直接按照规则执行动作，否则就转发到 SlowPath 去处理。而这个 SlowPath 可以是 DPDK，也可以是 Linux Kernel。因此，FastPath 最重要的是看是否支持足够多的 Action，以及自定义 Action 的可扩展性。SlowPath 和 FastPath 通信除了各厂商的私有接口外，也有标准的 TC Offload 接口和 DPDK 提供的 RTE Flows 接口。
智能网卡几乎都可以采用 SRIOV 的方式接入虚拟机。VF 支持的队列个数也非常重要，只有支持多队列的 VF，才能够通过 RSS 充分发挥出虚拟机的多核优势，从而达到较高的网络处理性能。整合 FastPath 和 SRIOV，智能网卡也能够使虚拟机的网络性能接近物理网卡。
但阻碍 SmartNIC 采用 SRIOV 方式的一大原因就是虚拟机热迁移（Live-Migration），SRIOV 方式虚拟机直接管理 VF，这导致无法 Live-Migration。Live-Migration 的问题较传统的解决方案是通过 VF 和 Virtio Bind 的方式来规避，在正常工作的时候，使用 VF 进行高性能转发，在 Live-Migration 前热拔出 VF 网卡无缝切换到 Virtio 网卡工作，在 Live-Migration 完成后再热插入 VF 网卡。
显而易见，在 Live-Migration 过程中使用 Virtio 网卡会造成网络性能下降，使得 Live-Migration 需要选择闲时进行。Intel 提出 vhost data path acceleration（vDPA）技术，在 VF 上兼容 Virtio，从而更好地支持 Live-Migration。同时 Virtio 1.1 规范的推出使得网卡硬件兼容 Virtio 更加容易。
目前 UCloud 基于 SRIOV 支持热迁移的高性能 25G 智能网卡正在内测阶段，即将上线。
二、有状态服务（如：安全组）引入带来的性能挑战
UCloud 希望能够通过智能网卡来卸载有状态业务，例如：防火墙、NAT 和安全组。有状态业务要求实现连接追踪（Connection Track）。新建连接需要在 FastPath 插入新规则，这要求非常高的规则更新速度。每个连接都需要在 FastPath 维护一条规则，这对内存提出了非常高的要求。连接的状态变化需要在 FastPath 和 SlowPath 间同步，TCP 的状态变化时还需要检查 SEQ。
目前 UCloud 在测试一些商用的 SmartNIC，智能网卡对有状态业务的支持正在越来越好，有望在不久的将来，能够提供足够成熟的有状态业务解决方案。
控制面挑战与轻量级 ServiceMesh 方案
虚拟化的优势很明显：可以提高服务器、计算及网络容量的使用效率，减少资金投入。但同时，虚拟化也给负责管理虚拟网络的数据中心人员带来了新的挑战。
SDN 的控制面需要在每台计算节点上部署，本质上就是一个超大规模（x 万节点）的分布式系统。它面临的问题也和常规分布式系统一样，需要解决 CAP 问题、可扩展性问题等等。为了降低变更的影响范围，UCloud 也逐步开始进行微服务改造。同时更好地实现按用户灰度发布，因此引入了轻量级 ServiceMesh 架构。
轻量级 ServiceMesh 是基于 Envoy 和 Istio Pilot 的 Istio 变种方案。Istio 是一个非常优秀 ServiceMesh 方案，UCloud 团队对 Istio 的流量管理功能非常满意，同时通过评测也能够接受 Envoy 的性能开销。
但是 UCloud 目前并没有采用 K8S，事实上，UCloud 所开发的 IaaS 控制面程序，本身就和 K8S 的功能类似。并且，UCloud 有大量的既有服务。K8S 的网络方案比较复杂，且性能堪忧，再通过 IPTables 来透明引流确实是雪上加霜，给未来的运维、Trouble-Shooting 带来了很高的复杂度。目前 UCloud 主要使用 gRPC 和 HTTP，但仍有数据库服务等业务不适合跑在 K8S 中，而 K8S 的网络方案需要能够兼容现有的数据库等业务。
经过对 Istio 代码的预研之后，UCloud 最终选择了将 Pilot 从 Istio 中剥离出来，脱离 K8S 运行的轻量级 ServiceMesh 方案。在 Istio 中 Pilot 是作为 Envoy 的控制面提供集中式流量管理功能的模块，这是实现灰度发布必不可少的功能，事实上也是 ServiceMesh 的核心功能。Mixer 提供的访问策略和控制，Istio-Auth 提供安全认证功能，相对来说在 UCloud 的内网环境下，都可以裁剪掉。
而得益于 Pilot 的良好设计，很容易实现 ETCD Platform，从 ETCD 获取 Service 和 Service Instance 信息。UCloud 重写了 Pilott 的 main.go，保留了 Pilot 的 model、proxy 和 proxy/envoy 模块，删除其他的 Platform 仅保留新增的 ETCD Platform。
最后在保留完整的 Istio DSL 支持的同时，得到了完全脱离 K8S 运行和编译的 Pilot。同时将 Pilot 和 ETCD gRPC naming and discovery 做了深度整合，自动剔除没有在线的 ServiceEntry。
在脱离 K8S 后，仍然需要采用 Sidecar 的部署方式。UCloud 采用 container 的方式打包和部署微服务，但采用 Host 的网络方式，简化了和现存服务的网络通信方式。同时利用 docker-compose 模拟 K8S 的 POD，管理服务间的依赖。通过实现一个简单的服务管理、版本管理、集群管理、路由策略管理层，为集群中的每台 Node（VM 或物理服务器）生成 docker-compose 配置文件，实现每台 Node 的服务部署和管理。
最后针对 HTTP 1.0、HTTP 2.0 和 gRPC 的 RPC 方式，采用显式代理而不是 IPTables 透明引流和 Envoy 集成。如果服务中配置了 Envoy 的 Proxy Port，则通过 Envoy 接入 ServiceMesh；如果配置是 IP 地址和端口，则直连这个地址；如果配置的是域名且没有配置 Envoy 的 Proxy 则自动采用 ETCD gRPC naming and discovery 的方式去发现远端服务。
最终，UCloud 轻松利用 Pilot 和 Envoy 实现了按用户灰度发布，目前该 ServiceMesh 框架已经在 UCloud 多个项目中使用。
后记
加入 UCloud 虚拟网络团队三年多，徐亮深刻地认识到这个领域百家争鸣，仍然在快速变化中。但“Software is eating the network”这个趋势始终清晰可见。从最早的 SDN、软件 vSwitch 到智能网卡、可编程交换机，软件在网络中的作用越来越重要。
“同时密切关注网络和软件两个领域的发展，消化吸收符合自身需求的新技术，才能够跟上 UCloud 用户的发展，为客户提供稳定的服务，提供符合客户需求的、易用和低成本的产品。”徐亮总结道。
阅读这篇文章的你，对徐亮大牛有什么问题要问吗？欢迎留言，大 U 帮你找答案！你也可以微信添加“云计算总动员”公众号，在那里，大 U 带你一起飞！