文章首发于我的公众号「Linux云计算网络」,欢迎关注,第一时间掌握技术干货!

本文讲解 Linux 的零拷贝技术,我在「云计算技能图谱」中说过,云计算是一门很庞大的技术学科,融合了很多技术,Linux 算是比较基础的技术,所以,学好 Linux 对于云计算的学习会有比较大的帮助。

本文借鉴并总结了几种比较常见的 Linux 下的零拷贝技术,相关的引用链接见文后,大家如果觉得本文总结得太抽象,可以转到链接看详细解释。

为什么需要零拷贝


传统的 Linux 系统的标准 I/O 接口(read、write)是基于数据拷贝的,也就是数据都是 copy_to_user 或者 copy_from_user,这样做的好处是,通过中间缓存的机制,减少磁盘 I/O 的操作,但是坏处也很明显,大量数据的拷贝,用户态和内核态的频繁切换,会消耗大量的 CPU 资源,严重影响数据传输的性能,有数据表明,在Linux内核协议栈中,这个拷贝的耗时甚至占到了数据包整个处理流程的57.1%。

什么是零拷贝


零拷贝就是这个问题的一个解决方案,通过尽量避免拷贝操作来缓解 CPU 的压力。Linux 下常见的零拷贝技术可以分为两大类:一是针对特定场景,去掉不必要的拷贝;二是去优化整个拷贝的过程。由此看来,零拷贝并没有真正做到“0”拷贝,它更多是一种思想,很多的零拷贝技术都是基于这个思想去做的优化。

零拷贝的几种方法


原始数据拷贝操作


在介绍之前,先看看 Linux 原始的数据拷贝操作是怎样的。如下图,假如一个应用需要从某个磁盘文件中读取内容通过网络发出去,像这样:

1
2
3
while((n = read(diskfd, buf, BUF_SIZE)) > 0)

write(sockfd, buf , n);

那么整个过程就需要经历:1)read 将数据从磁盘文件通过 DMA 等方式拷贝到内核开辟的缓冲区;2)数据从内核缓冲区复制到用户态缓冲区;3)write 将数据从用户态缓冲区复制到内核协议栈开辟的 socket 缓冲区;4)数据从 socket 缓冲区通过 DMA 拷贝到网卡上发出去。

可见,整个过程发生了至少四次数据拷贝,其中两次是 DMA 与硬件通讯来完成,CPU 不直接参与,去掉这两次,仍然有两次 CPU 数据拷贝操作。

方法一:用户态直接 I/O


这种方法可以使应用程序或者运行在用户态下的库函数直接访问硬件设备,数据直接跨过内核进行传输,内核在整个数据传输过程除了会进行必要的虚拟存储配置工作之外,不参与其他任何工作,这种方式能够直接绕过内核,极大提高了性能。

缺陷:

1)这种方法只能适用于那些不需要内核缓冲区处理的应用程序,这些应用程序通常在进程地址空间有自己的数据缓存机制,称为自缓存应用程序,如数据库管理系统就是一个代表。

2)这种方法直接操作磁盘 I/O,由于 CPU 和磁盘 I/O 之间的执行时间差距,会造成资源的浪费,解决这个问题需要和异步 I/O 结合使用。

方法二:mmap


这种方法,使用 mmap 来代替 read,可以减少一次拷贝操作,如下:

1
2
3
buf = mmap(diskfd, len);

write(sockfd, buf, len);

应用程序调用 mmap ,磁盘文件中的数据通过 DMA 拷贝到内核缓冲区,接着操作系统会将这个缓冲区与应用程序共享,这样就不用往用户空间拷贝。应用程序调用write ,操作系统直接将数据从内核缓冲区拷贝到 socket 缓冲区,最后再通过 DMA 拷贝到网卡发出去。

缺陷:

1)mmap 隐藏着一个陷阱,当 mmap 一个文件时,如果这个文件被另一个进程所截获,那么 write 系统调用会因为访问非法地址被 SIGBUS 信号终止,SIGBUS 默认会杀死进程并产生一个 coredump,如果服务器被这样终止了,那损失就可能不小了。

解决这个问题通常使用文件的租借锁:首先为文件申请一个租借锁,当其他进程想要截断这个文件时,内核会发送一个实时的 RT_SIGNAL_LEASE 信号,告诉当前进程有进程在试图破坏文件,这样 write 在被 SIGBUS 杀死之前,会被中断,返回已经写入的字节数,并设置 errno 为 success。

通常的做法是在 mmap 之前加锁,操作完之后解锁:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
if(fcntl(diskfd, F_SETSIG, RT_SIGNAL_LEASE) == -1) {

perror("kernel lease set signal");

return -1;

}

/* l_type can be F_RDLCK F_WRLCK 加锁*/

/* l_type can be F_UNLCK 解锁*/

if(fcntl(diskfd, F_SETLEASE, l_type)){

perror("kernel lease set type");

return -1;

}

方法三:sendfile


从Linux 2.1版内核开始,Linux引入了sendfile,也能减少一次拷贝。

1
2
3
#include<sys/sendfile.h>

ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);

sendfile 是只发生在内核态的数据传输接口,没有用户态的参与,自然避免了用户态数据拷贝。它指定在 in_fd 和 out_fd 之间传输数据,其中,它规定 in_fd 指向的文件必须是可以 mmap 的,out_fd 必须指向一个套接字,也就是规定数据只能从文件传输到套接字,反之则不行。sendfile 不存在像 mmap 时文件被截获的情况,它自带异常处理机制。

缺陷:

1)只能适用于那些不需要用户态处理的应用程序。

方法四:DMA 辅助的 sendfile


常规 sendfile 还有一次内核态的拷贝操作,能不能也把这次拷贝给去掉呢?

答案就是这种 DMA 辅助的 sendfile。

这种方法借助硬件的帮助,在数据从内核缓冲区到 socket 缓冲区这一步操作上,并不是拷贝数据,而是拷贝缓冲区描述符,待完成后,DMA 引擎直接将数据从内核缓冲区拷贝到协议引擎中去,避免了最后一次拷贝。

缺陷:

1)除了3.4 中的缺陷,还需要硬件以及驱动程序支持。

2)只适用于将数据从文件拷贝到套接字上。

方法五:splice


splice 去掉 sendfile 的使用范围限制,可以用于任意两个文件描述符中传输数据。

1
2
3
4
5
#define _GNU_SOURCE         /* See feature_test_macros(7) */

#include <fcntl.h>

ssize_t splice(int fd_in, loff_t *off_in, int fd_out, loff_t *off_out, size_t len, unsigned int flags);

但是 splice 也有局限,它使用了 Linux 的管道缓冲机制,所以,它的两个文件描述符参数中至少有一个必须是管道设备。

splice 提供了一种流控制的机制,通过预先定义的水印(watermark)来阻塞写请求,有实验表明,利用这种方法将数据从一个磁盘传输到另外一个磁盘会增加 30%-70% 的吞吐量,CPU负责也会减少一半。

缺陷:

1)同样只适用于不需要用户态处理的程序

2)传输描述符至少有一个是管道设备。

方法六:写时复制


在某些情况下,内核缓冲区可能被多个进程所共享,如果某个进程想要这个共享区进行 write 操作,由于 write 不提供任何的锁操作,那么就会对共享区中的数据造成破坏,写时复制就是 Linux 引入来保护数据的。

写时复制,就是当多个进程共享同一块数据时,如果其中一个进程需要对这份数据进行修改,那么就需要将其拷贝到自己的进程地址空间中,这样做并不影响其他进程对这块数据的操作,每个进程要修改的时候才会进行拷贝,所以叫写时拷贝。这种方法在某种程度上能够降低系统开销,如果某个进程永远不会对所访问的数据进行更改,那么也就永远不需要拷贝。

缺陷:

需要 MMU 的支持,MMU 需要知道进程地址空间中哪些页面是只读的,当需要往这些页面写数据时,发出一个异常给操作系统内核,内核会分配新的存储空间来供写入的需求。

方法七:缓冲区共享


这种方法完全改写 I/O 操作,因为传统 I/O 接口都是基于数据拷贝的,要避免拷贝,就去掉原先的那套接口,重新改写,所以这种方法是比较全面的零拷贝技术,目前比较成熟的一个方案是最先在 Solaris 上实现的 fbuf (Fast Buffer,快速缓冲区)。

Fbuf 的思想是每个进程都维护着一个缓冲区池,这个缓冲区池能被同时映射到程序地址空间和内核地址空间,内核和用户共享这个缓冲区池,这样就避免了拷贝。

缺陷:

1)管理共享缓冲区池需要应用程序、网络软件、以及设备驱动程序之间的紧密合作

2)改写 API ,尚处于试验阶段。

高性能网络 I/O 框架——netmap


Netmap 基于共享内存的思想,是一个高性能收发原始数据包的框架,由Luigi Rizzo 等人开发完成,其包含了内核模块以及用户态库函数。其目标是,不修改现有操作系统软件以及不需要特殊硬件支持,实现用户态和网卡之间数据包的高性能传递。

在 Netmap 框架下,内核拥有数据包池,发送环\接收环上的数据包不需要动态申请,有数据到达网卡时,当有数据到达后,直接从数据包池中取出一个数据包,然后将数据放入此数据包中,再将数据包的描述符放入接收环中。内核中的数据包池,通过 mmap 技术映射到用户空间。用户态程序最终通过 netmap_if 获取接收发送环 netmap_ring,进行数据包的获取发送。

总结:


1、零拷贝本质上体现了一种优化的思想

2、直接 I/O,mmap,sendfile,DMA sendfile,splice,缓冲区共享,写时复制……

参考:


(1)Linux 中的零拷贝技术,第 1 部分
https://www.ibm.com/developerworks/cn/linux/l-cn-zerocopy1/index.html
(2)Linux 中的零拷贝技术,第 2 部分
https://www.ibm.com/developerworks/cn/linux/l-cn-zerocopy2/
(3)Netmap 原理
http://www.tuicool.com/articles/MnIRbuU

PS:文章未经我允许,不得转载,否则后果自负。

–END–

欢迎扫👇的二维码关注我的微信公众号,后台回复「m」,可以获取往期所有技术博文推送,更多资料回复下列关键字获取。

文章首发我的公众号「Linux云计算网络」,欢迎关注,第一时间掌握技术干货!

在前文「从 Bridge 到 OVS」中,我们已经对 OVS 进行了一番探索。本文决定从 OVS 的整体架构到各个组件都进行一个详细的介绍。

OVS 架构


OVS 是产品级的虚拟交换机,大量应用在生产环境中,支撑整个数据中心虚拟网络的运转。OVS 基于 SDN 的思想,将整个核心架构分为控制面和数据面,数据面负责数据的交换工作,控制面实现交换策略,指导数据面工作。

从整体上看,OVS 可以划分为三大块,管理面、数据面和控制面。

数据面就是以用户态的 ovs-vswitchd 和内核态的 datapath 为主的转发模块,以及与之相关联的数据库模块 ovsdb-server,控制面主要是由 ovs-ofctl 模块负责,基于 OpenFlow 协议与数据面进行交互。而管理面则是由 OVS 提供的各种工具来负责,这些工具的提供也是为了方便用户对底层各个模块的控制管理,提高用户体验。下面就对这些工具进行一个逐一的阐述。

ovs-ofctl: 这个是控制面的模块,但本质上它也是一个管理工具,主要是基于 OpenFlow 协议对 OpenFlow 交换机进行监控和管理,通过它可以显示一个 OpenFlow 交换机的当前状态,包括功能、配置和表中的项。使用时,有很多参数,我们可以通过 ovs-ofctl –help 查看。

常用命令:

1
2
3
4
5
ovs-ofctl show switch-name :输出交换机信息,包括其流量表和端口信息。

ovs-ofctl dump-ports switch-name:输出交换机的端口统计信息,包括收发包、丢包、错误包等数量。

ovs-ofctl add-flow switch-name:为交换机配置流策略。

ovs-dpctl: 用来配置交换机的内核模块 datapath,它可以创建,修改和删除 datapath,一般,单个机器上的 datapath 有 256 条(0-255)。一条 datapath 对应一个虚拟网络设备。该工具还可以统计每条 datapath 上的设备通过的流量,打印流的信息等,更过参数通过 ovs-dpctl –help 查看。

常用命令:

1
2
3
4
5
ovs-dpctl show :显示所有 datapath 的基本信息。

ovs-dpctl dump-dps :显示所有 datapath 的名字。

ovs-dpctl dump-flows DP :显示一条 datapath DP 上的流信息。

ovs-appctl: 查询和控制运行中的 OVS 守护进程,包括 ovs-switchd,datapath,OpenFlow 控制器等,兼具 ovs-ofctl、ovs-dpctl 的功能,是一个非常强大的命令。ovs-vswitchd 等进程启动之后就以一个守护进程的形式运行,为了能够很好的让用户控制这些进程,就有了这个命令。详细可以 ovs-appctl –help 查看。

ovs-vsctl: 查询和更新 ovs-vswitchd 的配置,这也是一个很强大的命令,网桥、端口、协议等相关的命令都由它来完成。此外,还负责和 ovsdb-server 相关的数据库操作。

常用命令:

1
2
3
ovs-vsctl show :显示主机上已有的网桥及端口信息。

ovs-vsctl add-br br0:添加网桥 br0。

ovsdb-client: 访问 ovsdb-server 的客户端程序,通过 ovsdb-server 执行一些数据库操作。

常用命令:

1
2
3
ovsdb-client dump:用来查看ovsdb内容。

ovsdb-client transact :用来执行一条类 sql。

ovsdb-tool: 和 ovsdb-client 要借助 ovsdb-server 才能进行相关数据库操作不同,ovsdb-tool 可以直接操作数据库。

OVS 源码结构


OVS 源码结构中,主要包含以下几个主要的模块,数据交换逻辑在 vswitchd 和 datapath 中实现,vswitchd 是最核心的模块,OpenFlow 的相关逻辑都在 vswitchd 中实现,datapath 则不是必须的模块。ovsdb 用于存储 vswitch 本身的配置信息,如端口、拓扑、规则等。控制面部分采用的是 OVS 自家实现的 OVN,和其他控制器相比,OVN 对 OVS 和 OpenStack 有更好的兼容性和性能。

从图中可以看出 OVS 的分层结构,最上层 vswitchd 主要与 ovsdb 通信,做配置下发和更新等,中间层是 ofproto ,用于和 OpenFlow 控制器通信,并基于下层的 ofproto provider 提供的接口,完成具体的设备操作和流表操作等工作。

dpif 层实现对流表的操作。

netdev 层实现了对网络设备(如 Ethernet)的抽象,基于 netdev provider 接口实现多种不同平台的设备,如 Linux 内核的 system, tap, internal 等,dpdk 系的 vhost, vhost-user 等,以及隧道相关的 gre, vxlan 等。

数据转发流程


通过一个例子来看看 OVS 中数据包是如何进行转发的。

1)ovs 的 datapath 接收到从 ovs 连接的某个网络端口发来的数据包,从数据包中提取源/目的 IP、源/目的 MAC、端口等信息。

2)ovs 在内核态查看流表结构(通过 hash),如果命中,则快速转发。

3)如果没有命中,内核态不知道如何处置这个数据包,所以,通过 netlink upcall 机制从内核态通知用户态,发送给 ovs-vswitchd 组件处理。

4)ovs-vswitchd 查询用户态精确流表和模糊流表,如果还不命中,在 SDN 控制器接入的情况下,经过 OpenFlow 协议,通告给控制器,由控制器处理。

5)如果模糊命中, ovs-vswitchd 会同时刷新用户态精确流表和内核态精确流表,如果精确命中,则只更新内核态流表。

6)刷新后,重新把该数据包注入给内核态 datapath 模块处理。

7)datapath 重新发起选路,查询内核流表,匹配;报文转发,结束。
总结

OVS 为了方便用户操作,提供了很多管理工具,我们平常在使用过程中只需记住每个工具的作用,具体的命令可以使用 -h 或 –help 查看。

PS:文章未经我允许,不得转载,否则后果自负。

–END–

欢迎扫👇的二维码关注我的微信公众号,后台回复「m」,可以获取往期所有技术博文推送,更多资料回复下列关键字获取。

文章首发我的公众号「Linux云计算网络」,欢迎关注,第一时间掌握技术干货!

和物理网络一样,虚拟网络要通信,必须借助一些交换设备来转发数据。因此,对于网络虚拟化来说,交换设备的虚拟化是很关键的一环。

上文「网络虚拟化」已经大致介绍了 Linux 内核为了满足网络虚拟化的要求,实现了一套虚拟交换设备——Bridge。本文重点介绍下 Bridge 的加强版——Open vSwitch(OVS),并从 Bridge 过渡到 OVS 的缘由讲起,让大家有个全面的认识。

借助 Linux Bridge 功能,同主机或跨主机的虚拟机之间能够轻松实现通信,也能够让虚拟机访问到外网,这就是我们所熟知的桥接模式,一般在装 VMware 虚拟机或者 VirtualBox 虚拟机的时候,都会提示我们要选择哪种模式,常用的两种模式是桥接和 NAT。

NAT 也很好理解,可以简单理解为当虚拟机启用了 NAT 模式之后,宿主机便通过 DHCP 为其生成可以访问外网的 IP,当 VM 访问外网的时候,就可以用该 IP 访问,其实就是宿主机为其做了地址转换。更详细的内容请自行搜索了解。

物理交换机有个重要的功能,就是虚拟局域网(VLAN),是对局域网(LAN)的软件化升级。一般,两台计算机通过一台交换机连接在一起就构成了一个 LAN。

一个 LAN 表示一个广播域,这意味着这个 LAN 中的任何节点发的数据包,其他节点都能收到,这有两个问题,一个是容易形成广播风暴,造成网络拥塞,另一个是广播包无法隔离,比如节点 B 不想接收节点 A 的包,但节点 A 强行要发,这就有点说不过去了。

解决这个问题的方案就是 VLAN,VLAN 能够对广播包进行有效隔离,它的做法是从软件上将交换机的端口虚拟出多个子端口,用 tag 来标记,相当于将交换机的端口划分多个 LAN,同一个 LAN 中的节点发出的数据包打上本 LAN 的 tag,这样,其他 LAN 中的节点就无法收到包,达到隔离的目的。

Bridge 本身是支持 VLAN 功能的,如下图所示,通过配置,Bridge 可以将一个物理网卡设备 eth0 划分成两个子设备 eth0.10,eth0.20,分别挂到 Bridge 虚拟出的两个 VLAN 上,VLAN id 分别为 VLAN 10 和 VLAN 20。同样,两个 VM 的虚拟网卡设备 vnet0 和 vnet 1 也分别挂到相应的 VLAN 上。这样配好的最终效果就是 VM1 不能和 VM2 通信了,达到了隔离。

Linux Bridge + VLAN 便可以构成一个和物理交换机具备相同功能的虚拟交换机了。对于网络虚拟化来说,Bridge 已经能够很好地充当交换设备的角色了。

但是为什么还有很多厂商都在做自己的虚拟交换机,比如比较流行的有 VMware virtual switch、Cisco Nexus 1000V,以及 Open vSwitch。究其原因,主要有以下几点(我们重点关注 OVS):

1) 方便网络管理与监控。OVS 的引入,可以方便管理员对整套云环境中的网络状态和数据流量进行监控,比如可以分析网络中流淌的数据包是来自哪个 VM、哪个 OS 及哪个用户,这些都可以借助 OVS 提供的工具来达到。

2) 加速数据包的寻路与转发。相比 Bridge 单纯的基于 MAC 地址学习的转发规则,OVS 引入流缓存的机制,可以加快数据包的转发效率。

3) 基于 SDN 控制面与数据面分离的思想。上面两点其实都跟这一点有关,OVS 控制面负责流表的学习与下发,具体的转发动作则有数据面来完成。可扩展性强。

4) 隧道协议支持。Bridge 只支持 VxLAN,OVS 支持 gre/vxlan/IPsec 等。

5) 适用于 Xen、KVM、VirtualBox、VMware 等多种 Hypervisors。

……

除此之外,OVS 还有很多高级特性,详情可以查阅官网自行了解。

下面简单看下 OVS 的整体架构,如下图所示,OVS 在 Linux 用户态和内核态都实现了相应的模块,用户态主要组件有数据库服务 ovsdb-server 和守护进程 ovs-vswitchd。内核态中实现了 datapath 模块。

其中, ovs-vswitchd 和 datapath 共同构成了 OVS 的数据面,控制面由 controller 模块来完成,controller 一般表示的是 OpenFlow 控制器,在 OVS 中,它可以借由第三方来完成,只要支持 OpenFlow 协议即可。

这里额外提一点,很多的一些产品级的虚拟交换机都是自身集成了控制器,比如 Cisco 1000V 的 Virtual Supervisor Manager(VSM),VMware 的分布式交换机中的 vCenter,而 OVS 是把这个事交由第三方去做,这么做的意义还是比较大的,可以让自己的产品很好地融入到各种解决方案中。

OpenFlow


OpenFlow 是控制面和数据面通信的一套协议,我们常常把支持 OpenFlow 协议的交换机称为 OpenFlow 交换机,控制器称为 OpenFlow 控制器,业界比较知名的 OpenFlow 控制器有 OpenDaylight、ONOS 等。

OpenFlow 是一个独立的完整的流表协议,不依赖于 OVS,OVS 只是支持 OpenFlow 协议,有了支持,就可以使用 OpenFlow 控制器来管理 OVS 中的流表。OpenFlow 不仅仅支持虚拟交换机,某些硬件交换机也支持 OpenFlow 协议。

ovs-vswitchd


ovs-vswitchd 是 OVS 的核心组件,它和内核模块 datapath 共同构成了 OVS 的数据面。它使用 OpenFlow 协议与 OpenFlow 控制器通信,使用 OVSDB 协议与 ovsdb-server 通信,使用 netlink 和 datapath 内核模块通信。

ovsdb-server


ovsdb-server 是 OVS 轻量级的数据库服务,用于整个 OVS 的配置信息,包括接口、交换内容、VLAN 等,ovs-vswitchd 根据这些配置信息工作。

OpenFlow 控制器


OpenFlow 控制器可以通过 OpenFlow 协议连接到任何支持 OpenFlow 的交换机,比如 OVS 。控制器通过向交换机下发流表规则来控制数据流向。

Kernel Datapath


datapath 内核模块和 ovs-vswitchd 是相互协作工作的,datapath 负责具体的收发包,而 ovs-vswitchd 通过 controller 下发的流表规则指导 datapath 如何转发包。

举个例子,datapath 从主机物理网卡 NIC 或者 VM 的 虚拟网卡 vNIC 收到包,如果是第一次收到包,datapath 不知道怎么处理这个包,于是将其丢给 ovs-vswitchd , ovs-vswitchd 决定该如何处理这个包之后又丢给 datapath,datapath 根据 ovs-vswitchd 的指示执行相应的动作,是丢弃还是从哪个口传出去。同时,ovs-vswitchd 会让 datapath 缓存好这个包的动作,下次再来就可以直接执行动作。

如果不是第一次收到包,就是按照之前缓存好的动作执行,这样极大地提高了数据处理的速度。

本文先对 OVS 有个初步印象,下文再详细介绍 OVS 的其他组件。

PS:文章未经我允许,不得转载,否则后果自负。

–END–

欢迎扫👇的二维码关注我的微信公众号,后台回复「m」,可以获取往期所有技术博文推送,更多资料回复下列关键字获取。

文章首发我的公众号「Linux云计算网络」,欢迎关注,第一时间掌握技术干货!

网络虚拟化相对计算、存储虚拟化来说是比较抽象的,以我们在学校书本上学的那点网络知识来理解网络虚拟化可能是不够的。

在我们的印象中,网络就是由各种网络设备(如交换机、路由器)相连组成的一个网状结构,世界上的任何两个人都可以通过网络建立起连接。

带着这样一种思路去理解网络虚拟化可能会感觉云里雾里——这样一个庞大的网络如何实现虚拟化?

其实,网络虚拟化更多关注的是数据中心网络、主机网络这样比较「细粒度」的网络,所谓细粒度,是相对来说的,是深入到某一台物理主机之上的网络结构来谈的。

如果把传统的网络看作「宏观网络」的话,那网络虚拟化关注的就是「微观网络」。网络虚拟化的目的,是要节省物理主机的网卡设备资源。从资源这个角度去理解,可能会比较好理解一点。

传统网络架构


在传统网络环境中,一台物理主机包含一个或多个网卡(NIC),要实现与其他物理主机之间的通信,需要通过自身的 NIC 连接到外部的网络设施,如交换机上,如下图所示。


传统网络(图片来源于网络,侵权必删)

这种架构下,为了对应用进行隔离,往往是将一个应用部署在一台物理设备上,这样会存在两个问题,1)是某些应用大部分情况可能处于空闲状态,2)是当应用增多的时候,只能通过增加物理设备来解决扩展性问题。不管怎么样,这种架构都会对物理资源造成极大的浪费。

虚拟化网络架构


为了解决这个问题,可以借助虚拟化技术对一台物理资源进行抽象,将一张物理网卡虚拟成多张虚拟网卡(vNIC),通过虚拟机来隔离不同的应用。

这样对于上面的问题 1),可以利用虚拟化层 Hypervisor 的调度技术,将资源从空闲的应用上调度到繁忙的应用上,达到资源的合理利用;针对问题 2),可以根据物理设备的资源使用情况进行横向扩容,除非设备资源已经用尽,否则没有必要新增设备。这种架构如下所示。


虚拟化网络(图片来源于网络,侵权必删)

其中虚拟机与虚拟机之间的通信,由虚拟交换机完成,虚拟网卡和虚拟交换机之间的链路也是虚拟的链路,整个主机内部构成了一个虚拟的网络,如果虚拟机之间涉及到三层的网络包转发,则又由另外一个角色——虚拟路由器来完成。

一般,这一整套虚拟网络的模块都可以独立出去,由第三方来完成,如其中比较出名的一个解决方案就是 Open vSwitch(OVS)。

OVS 的优势在于它基于 SDN 的设计原则,方便虚拟机集群的控制与管理,另外就是它分布式的特性,可以「透明」地实现跨主机之间的虚拟机通信,如下是跨主机启用 OVS 通信的图示。


分布式虚拟交换机(图片来源于网络,侵权必删)

总结下来,网络虚拟化主要解决的是虚拟机构成的网络通信问题,完成的是各种网络设备的虚拟化,如网卡、交换设备、路由设备等。

Linux 下网络设备虚拟化的几种形式


为了完成虚拟机在同主机和跨主机之间的通信,需要借助某种“桥梁”来完成用户态到内核态(Guest 到 Host)的数据传输,这种桥梁的角色就是由虚拟的网络设备来完成,上面介绍了一个第三方的开源方案——OVS,它其实是一个融合了各种虚拟网络设备的集大成者,是一个产品级的解决方案。

但 Linux 本身由于虚拟化技术的演进,也集成了一些虚拟网络设备的解决方案,主要有以下几种:

(1)TAP/TUN/VETH


TAP/TUN 是 Linux 内核实现的一对虚拟网络设备,TAP 工作在二层,TUN 工作在三层。Linux 内核通过 TAP/TUN 设备向绑定该设备的用户空间程序发送数据,反之,用户空间程序也可以像操作物理网络设备那样,向 TAP/TUN 设备发送数据。

基于 TAP 驱动,即可实现虚拟机 vNIC 的功能,虚拟机的每个 vNIC 都与一个 TAP 设备相连,vNIC 之于 TAP 就如同 NIC 之于 eth。

当一个 TAP 设备被创建时,在 Linux 设备文件目录下会生成一个对应的字符设备文件,用户程序可以像打开一个普通文件一样对这个文件进行读写。

比如,当对这个 TAP 文件执行 write 操作时,相当于 TAP 设备收到了数据,并请求内核接受它,内核收到数据后将根据网络配置进行后续处理,处理过程类似于普通物理网卡从外界收到数据。当用户程序执行 read 请求时,相当于向内核查询 TAP 设备是否有数据要发送,有的话则发送,从而完成 TAP 设备的数据发送。

TUN 则属于网络中三层的概念,数据收发过程和 TAP 是类似的,只不过它要指定一段 IPv4 地址或 IPv6 地址,并描述其相关的配置信息,其数据处理过程也是类似于普通物理网卡收到三层 IP 报文数据。

VETH 设备总是成对出现,一端连着内核协议栈,另一端连着另一个设备,一个设备收到内核发送的数据后,会发送到另一个设备上去,这种设备通常用于容器中两个 namespace 之间的通信。

(2)Bridge


Bridge 也是 Linux 内核实现的一个工作在二层的虚拟网络设备,但不同于 TAP/TUN 这种单端口的设备,Bridge 实现为多端口,本质上是一个虚拟交换机,具备和物理交换机类似的功能。

Bridge 可以绑定其他 Linux 网络设备作为从设备,并将这些从设备虚拟化为端口,当一个从设备被绑定到 Bridge 上时,就相当于真实网络中的交换机端口上插入了一根连有终端的网线。

如下图所示,Bridge 设备 br0 绑定了实际设备 eth0 和 虚拟设备设备 tap0/tap1,当这些从设备接收到数据时,会发送给 br0 ,br0 会根据 MAC 地址与端口的映射关系进行转发。


Bridge 与 TAP/TUN 的关系

因为 Bridge 工作在二层,所以绑定到它上面的从设备 eth0、tap0、tap1 均不需要设 IP,但是需要为 br0 设置 IP,因为对于上层路由器来说,这些设备位于同一个子网,需要一个统一的 IP 将其加入路由表中。

这里有人可能会有疑问,Bridge 不是工作在二层吗,为什么会有 IP 的说法?其实 Bridge 虽然工作在二层,但它只是 Linux 网络设备抽象的一种,能设 IP 也不足为奇。

对于实际设备 eth0 来说,本来它是有自己的 IP 的,但是绑定到 br0 之后,其 IP 就生效了,就和 br0 共享一个 IP 网段了,在设路由表的时候,就需要将 br0 设为目标网段的地址。

总结


传统网络架构到虚拟化的网络架构,可以看作是宏观网络到微观网络的过渡

TAP/TUN/VETH、Bridge 这些虚拟的网络设备是 Linux 为了实现网络虚拟化而实现的网络设备模块,很多的云开源项目的网络功能都是基于这些技术做的,比如 Neutron、Docker network 等。

OVS 是一个开源的成熟的产品级分布式虚拟交换机,基于 SDN 的思想,被大量应用在生产环境中。

PS:文章未经我允许,不得转载,否则后果自负。

–END–

欢迎扫👇的二维码关注我的微信公众号,后台回复「m」,可以获取往期所有技术博文推送,更多资料回复下列关键字获取。

文章首发我的公众号「Linux云计算网络」,欢迎关注,第一时间掌握技术干货!

没错,这个标题就是个标题党,目的就是为了让你点进来看看。

2017 年是人工智能元年,我们也能看到各大互联网公司对于人工智能的大布局。但人工智能再怎么牛逼,别忘了它的底层基础设施是什么,没错,就是云计算,少了云计算的底层支撑,人工智能也只能活在书本里。虽然说云计算经过这么多年的沉淀,技术总体上来说已经比较成熟,但有一门技术仍然呈现欣欣向荣之势,未来发展仍有无限可能。

它就是以 docker 为首的容器技术。

不知道大家关注最近这两天的 KubeCon 2017 北美峰会没有,会上提得最多的也是容器技术,其中最大的新闻莫过于 OpenStack 基金会发布了最新开源容器项目 Kata Containers。看到这个消息,我的第一反应是「为啥最近容器圈的动作这么多」。

我们把时间拉回到 11 月底的中国开源年会上,当时阿里正式开源了自家自研容器项目 Pouch。再把时间拉到差不多两个月前(10月17日)的 DockerCon EU 2017 大会上,彼时 docker 官方宣布全面支持 kubernates。类似这样大大小小的动作,在 2017 年还发生了很多,这一切的动作都在说明容器的重要性,未来的可期待指数可以说不亚于人工智能。

下面简单介绍下 Kata 和阿里的 Pouch 到底是个怎样的角色,我也仅限于网络上各种资讯的了解,信息传达难免会有失误,如果大家觉得有问题可以留言指出。

Kata Containers 是什么


Kata 官方宣称这是同时兼具容器的速度和虚拟机安全的全新容器解决方案,旨在将虚拟机的安全优势与容器的速度和可管理性统一起来,其建立在 Intel 的 Clear Containers 技术和 Hyper 的 runV 虚拟机管理程序运行时基础之上。

Kata 的特点是什么?总体来讲,Kata 解决的是容器的安全问题。众所周知,当前容器技术旨在实现在一个虚拟机之上运行多个用户的、多个应用的容器实例,不同实例之间共享同一个虚拟机操作系统内核并采用 Namespaces 来隔离,但这种方式很难保证各实例彼此之间的完全隔离,存在安全隐患。

Kata 的解决方案是意图为每个容器实例提供一个专属的、高度轻量化的虚拟机操作系统内核来解决这个问题。让某一个用户的、一个应用的一个或多个容器实例单独跑在这个专属的虚拟机内核之上,这样不同用户、不同应用之间都是使用独占的虚拟机,不会共享同一个操作系统内核,这样就确保了安全性。

另外还有一点值得注意的是,Kata 的设计初衷强调了能够无缝、便捷的与 OpenStack 和 Kubernetes 集成的能力,这为 OpenStack 、Kubernetes 和 Container 更好的融合铺平了道路。

更详细的内容可以访问:

http://www/katacontainers.io/
https://github.com/hyperhq/runv

Pouch 是什么


相比 Kata,阿里的 Pouch 就没那么新鲜了,只不过是换了个马甲而已。

为什么这么说,因为 Pouch 并不是全新的容器解决方案,而是已经在阿里内部经过千锤百炼的老牌容器技术 t4。2011 年,Linux 内核的 namespace、cgroup 等技术开始成熟,LXC 等容器运行时技术也在同期诞生,阿里作为一家技术公司,在当时便基于 LXC 自研了自己的容器技术 t4,并以产品的形式给内部提供服务。

t4 就是 Pouch 的前身,从时间节点上看,t4 面世比 docker 要早两年,但 t4 有很多问题没有解决,譬如说没有镜像机制。2013 年,docker 横空出世,其带有镜像创新的容器技术,似一阵飓风,所到之处,国内外无不叫好,阿里也不例外,便在现有技术体系结构的基础上融入了 docker 的镜像技术,慢慢打磨,演变成今天的 Pouch。

Pouch 针对自身的业务场景对镜像的下载和分发进行了创新。由于阿里的业务体量庞大,集群规模数以万计,这就会存在一个问题就是镜像的下载和分发效率会很低,所以针对此,阿里在 Pouch 中集成了一个镜像分发工具蜻蜓(Dragonfly),蜻蜓基于智能 P2P 技术的文件分发系统,解决了大规模文件分发场景下分发耗时、成功率低、带宽浪费等难题。

Pouch 的架构主要考虑到两个方面,一方面是如何对接容器编排系统,另一方面是如何加强容器运行时,第一点让 Pouch 有了对外可扩展的能力,譬如可以原生支持 Kubernetes 等编排系统。第二点可以增加 Pouch 对虚拟机和容器的统一管理,让其适应更多的业务场景。

更详细的内容可以访问:

https://github.com/alibaba/pouch

总结


从几种举动中,我们可以看出,未来容器发展具有两大重要方向,分别是容器编排技术和容器的安全加强。这些都是在寻求一种更好的、更有效率的方式来为上层的业务提供更可靠、更安全的支撑。

PS:文章未经我允许,不得转载,否则后果自负。

–END–

欢迎扫👇的二维码关注我的微信公众号,后台回复「m」,可以获取往期所有技术博文推送,更多资料回复下列关键字获取。