在前几期中，我们讨论了在linux环境下，利用io虚拟化技术可以为虚拟机添加完全虚拟或半虚拟的网卡或磁盘，也可以将物理设备直通给虚拟机，还可以将支持sr-iov的网卡等设备进行一虚多，并将这些虚拟化的设备分配给虚拟机使用。
然而，我们遇到了一个问题：如果为宿主机上的虚拟机添加了SR-IOV的网卡，虚拟机将直接向外发送数据包，而不会经过宿主机的vSwitch。在云计算场景中，当虚拟机进入Overlay(VPC)时，需要利用硬件交换机进行Overlay隧道的封装和解封装，这在大型公有云的场景中是不合适的。(这个问题的原因将在以后详细讨论，此处暂不赘述)。
因此，我们需要其他方法来实现虚拟机在云端的网络互通。
由于Linux的虚拟化网络体系本身较为复杂，我们需要花一些时间来初步了解Linux网络虚拟化的基本概念。
在前文中，我们介绍了，在Linux下，每个虚拟机至少需要一个网卡与外部通信，最常见的连接方式是将这些虚拟网卡连接到一个虚拟交换机上，如下图所示：
图中，vNIC是虚拟网卡，vSwitch是虚拟交换机。在这个网络中，所有虚拟机对外的通信需要经过虚拟防火墙，虚拟防火墙对内的端口连接在虚拟交换机上，而对外的端口连接到另一个虚拟交换机，这个虚拟交换机的另一个接口连接到外部物理网络。
在运行着Linux的宿主机中，实现这么一个复杂的网络时，操作系统内部实际上发生了什么呢？
我们知道，在Linux中，如果希望让应用程序通过网络收发数据，需要调用socket接口，得到socket的文件描述符(fd)后，利用read和write实现数据的收发。socket的类型可以自定义为udp，tcp或raw ip，如下图所示：
图中，Socket是内核与用户的分界线，用户态应用程序通过socket api调用操作系统内核。
Linux为了实现网络的虚拟化，为应用程序提供了一个后门，这个后门叫做TUN/TAP。我们先以TUN为例来看一下TUN的使用方法：
如图，在系统内添加一个设备tunX后，应用程序可以将/dev/tunX作为通往Linux网络协议栈的后门，可以直接抽取来自协议栈的三层报文，或向协议栈注入三层报文。
如下图所示：
应用程序对/dev/tunX设备进行读取时，可以读取到三层数据包的内容，但无法读取二层头。如果期望获取二层以太网头，需要使用另一种虚拟网络设备，称为TAP。
利用TUN或TAP，可以将数据包封装进入自定义的隧道，如下图所示：
如图，红色箭头代表来自真正应用程序的流量，payload通过操作系统socket API，进入协议栈被依次封装上UDP，IP和以太网包头。另一个APP通过TUN，从内核取出这个数据包(不包含以太网二层头)，进行加工后再通过UDP Socket发出去。这样，最终被发到线路上的数据包就成了一个有着外层头的隧道数据包。
阿里云-虚拟数字人
阿里云-虚拟数字人是什么？ …
2 查看详情 
如果我们期望封装后的数据包是GRE隧道(内层为三层，外层为RAW IP)，可以使用RAW Socket。如果期望封装后的数据包是VXLAN隧道(内层为带有以太网数据包头的二层数据包)，则应当使用TAP设备从内核接管数据流，并使用UDP Socket封装。
如果有两台虚拟机需要通信，我们可以为它们各分配一个TAP，并且让这两个TAP加入一个VETH对：
图中，两个VM的VNIC是利用virtio实现的前端设备，它们的后端是QEMU的两个TAP。在Hypervisor上通过VETH Pair把两个TAP连在一起，就可以让两个虚拟机互通了。
但是，这样的方案有两个问题：
无法扩展。由于将TAP互联的VETH Pair是点对点的，如果有3个虚拟机需要互通，每个虚拟机上就需要2个vNIC连接到另外两个虚拟机。当虚拟机个数为X时，总共需要X (X-1) / 2个，此种O(N*N)复杂度是不可接受的。无法与外部网络连接。由于TAP本身只能与宿主机的其他TAP互通，这个网络只能存在于宿主机内部。如何解决这两个问题呢？
虽然在Linux中，VM，TAP，VETH Pair等都是软件实现的虚拟设备，但只要没有忘记设计网络的初心，会发现，在Linux下或其他环境中的虚拟化网络，与最初经典的网络，其本质是别无二致的。
因此，工程师们秉承初心，想到了经典的计算机网络理论中，从全连接网络转化为行星网络的简化方法，利用Linux虚拟化网络设备——bridge来实现多个虚拟机之间的互通以及虚拟机网络与宿主机网络的互通。
Linux bridge实际上是一个网桥，也可以称之为一个软件实现的二层交换机。
如图，Linux下的bridge可以绑定多个从设备，从逻辑上等同于物理世界中的交换机的端口插入了网线。图中三个VM上的vNIC各自对应的TAP被绑定到bridge上，同时物理网卡也被绑定到了bridge上。只要打开宿主机上的软转发功能，并将物理网卡设定为混杂模式(promiscuous mode，指允许网卡接受目的MAC地址不是自身MAC地址的数据包)，多个VM之间就可以通信了。
Linux网桥是虚拟化系统中原生的虚拟机互通方案，RHEV(Redhat Enterprise Virtuliazation)4.2及以前的版本中，只支持这种方案。
但是，Linux网桥用于大规模云计算场景中，有着一些绕不过去的问题：
由于Linux网桥运行在内核中，对网桥的二次开发需要修改内核模块；无法应用DPDK对Linux网桥进行加速；无法支持来自SDN控制器的统一控制和监测；这些问题是怎么样解决的呢？
请看下期。
以上就是云计算与虚拟化硬核技术内幕 (14) —— 不忘初心，删繁就简的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/473033.html
微信扫一扫 
支付宝扫一扫 
