服务器虚拟化改变了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带你一起飞！