杨鑫,吴之南,钱松荣
基于Macvlan的docker容器网络架构
杨鑫,吴之南,钱松荣
摘 要:基于Mesos及docker的大数据平台是构建私有云的主流方案之一。但是绑定到宿主机同一网络端口的不同docker容器之间会产生端口冲突的问题。通过Macvlan给docker容器分配独立的虚拟网卡,每个docker容器都能拥有自己的IP地址,从而解决端口冲突问题。经过实验得出,基于Macvlan的docker网络隔离技术不仅可以以相对便捷的方式解决 Mesos集群中docker网络端口冲突问题,并且几乎没有网络带宽损耗。
关键词:docker;Macvlan;Mesos;网络命名空间;网络隔离;端口冲突;
随着互联网数据规模与计算规模的不断扩大,分布式系统的构建也在高速发展之中。目前主流的分布式资源调度管理系统为Hadoop Yarn和Mesos[1][2]。由于Mesos对于docker的良好支持,利用docker容器封装服务并交由Mesos统一调度管理是构建基于Mesos的大数据服务的可靠解决方案[3]。但是当Mesos在集群的某一节点上部署多个对外提供网络服务但网络端口相同的docker容器时就会产生网络端口冲突问题,导致无法提供正常的网络服务。因此需要研究新的docker网络构建方式来满足基于Mesos的大数据服务。通过对docker及Macvlan网络机制的研究,在构建基于Mesos 和docker的大数据平台时,提供合理高效的docker网络隔离方案。
docker让应用程序布署在软件容器下的工作可以自动化进行,借此在Linux操作系统上,提供一个额外的软件抽象层,以及操作系统层虚拟化的自动管理机制。docker利用Linux核心(kernel)中的资源分离机制,例如cgroups,以及Linux核心命名空间(namespace),来建立独立的软件容器(containers)。
1.1 网络命名空间
docker[4]利用了多种Linux内核特性,其中之一是命名空间。docker利用命名空间来提供独立的工作空间即容器。当运行容器时,docker为容器创建一组命名空间。这提供了一层隔离:容器的每一部分都运行在其自己的命名空间中并且没有权限离开自己的命名空间。docker用到的一些命名空间有进程(PID)命名空间,网络(net)命名空间,进程间通信(ipc)命名空间,挂载(mnt)命名空间,分时系统(uts)命名空间等。针对docker网络端口冲突问题,需要结合网络命名空间来进一步研究解决。
1.2 默认网络配置方式
docker启动后会在宿主机上创建虚拟网卡docker0,并在宿主机上的私有地址中随机选择未使用的网络地址和子网分配给docker0。docker0是一个虚拟以太网桥,自动在与其相连接的网卡间转发数据包。这样可以使docker容器与宿主机和其他容器通信。具体方式是当docker容器运行时会创建一对网卡,类似管道的两端,发送到一端的数据包会在另一端被接收。一端会成为容器的默认网卡(eth0),另一端以唯一的名称类似vethAQI2QT置于宿主机的网络命名空间里。通过把所有位于宿主机网络命名空间一端的网卡与docker0网桥绑定,docker可以创建一个用以在宿主机与所有docker间共享的虚拟子网。
所以当docker容器需要对外提供网络服务时,需要把提供服务的网络端口映射到宿主机的某一端口上。因此宿主机的某一端口不能同时被多个容器端口所映射。当多个docker容器需要向宿主机所在的局域网提供某一个相同端口的网络服务时,就会产生网络端口冲突的问题。
为了解决docker网络端口冲突问题,本文提出了基于Macvlan的docker网络隔离方案。
2.1 Macvlan简介
传统意义上,网卡是工作在数据链路层的网络设备,由唯一的MAC地址标识。所以每块网卡只能绑定一个MAC地址,但是可以分配多个网络层的IP地址。而Macvlan[5]可以基于物理网卡创建多个虚拟网卡。和物理网卡相同,每个虚拟网卡都拥有唯一的MAC地址,并且可以分配多个IP地址。因此利用Macvlan,可以在单块物理网卡的情况下,绑定多个MAC地址,针对每个MAC地址分配相应的IP地址。
2.2 网络隔离原理
对于某一宿主机上的多个docker容器,可以通过Macvlan在docker容器各自的网络命名空间中添加不同的虚拟网卡,由于容器间拥有各自独立的网络协议栈,所以可以在给虚拟网卡分配MAC地址之后分配属于宿主机所在局域网的可用IP地址。通过这一方式,在网络层上,每个docker容器和宿主机都成为局域网中可以互相访问的对等网络节点,拥有独立的IP地址。所以宿主机上的不同docker容器可以提供相同网络端口的网络服务而不会互相冲突。
通过上文的原理分析,从理论上得出基于Macvlan的docekr网络隔离方式可以有效的解决docker网络端口冲突的问题。因此,需要进一步在基于Mesos及docker的大数据平台上进行实验测试,通过结果分析来验可行性和性能。
3.1 测试环境
实验的Mesos集群由3台Mesos主节点(Mesos-master)和19台Mesos从节点(Mesos-slave)组成。3台主节点组成zookeeper,操作系统为CentOS7。Mesos集群中的docker 由Marathon框架部署。在部署时通过设定Marathon部署方式,使得docker镜像均匀的分配到集群中的各个节点上。Mesos集群的局域网IP地址由DHCP服务器统一分配。每台主机进行网络性能测试的物理网卡带宽为10GB。
本实验使用Iperf测试网络性能,Iperf在进行网络测试时分为两部分,分别为服务器端和客户端。默认情况下客户端连接到服务器端并通过记录所发送数据包的传输速率来测定网络性能,每一个客户端只能连接到唯一的服务器端。
3.2 docker网络设置方式
本实验中基于Macvlan的docker容器网络隔离配置流程如图1所示:
当通过Mesos的资源调度在某一宿主机上启动docker容器后,系统分别在宿主机和docker容器内启动相关的程序完成网络设置任务。
首先,会在宿主机中新建Macvlan虚拟网卡,并把该虚拟网卡添加到docker容器的网络命名空间中。接着系统激活该虚拟网卡并给该虚拟网卡添加MAC地址。之后通过DHCP服务给该虚拟网卡添加IP地址。由于以上流程需要一定的时间,因此在最终虚拟网卡获得IP地址之前,docker容器内部需要先启动程序检测网卡的状态。以确保在网卡已经添加并拥有MAC地址和IP地址后才进行接下来的网络性能测试。
3.3 网络测试方案
上一节详细叙述了docker网络隔离的构建方式。在此基础上需要对这一网络隔离方式进行针对性的网络性能测试。本实验采用Iperf工具进行网络性能测试。
在本实验的测试方案如表1所示:
表1 网络性能测试方案
共有3套测试方案。在方案一和方案二中,均只有一个Iperf服务器端,客户端也都为N,即表示Iperf客户端从1个到128个,共进行10次不同Iperf客户端数量的网络测试。而一、二两个方案的差别仅在于测试类型上。测试类型分为UNIQUE和RANDOM两种,UNIQUE表示Iperf服务器端与其相连接的Iperf客户端不会在同一台Mesos从节点上。RANDOM则表示不限制相连接的Iperf服务器端和Iperf客户端是否在同一台Mesos从节点上,由系统随机分配。方案三表示在Iperf客户端数量为128个的情况下,分别对Iperf服务器端数量为M,即从2个到64个共9中情况进行网络性能测试。3种测试方案的架构模型如图2-图4所示:
图2 方案一架构模型示例
图3 方案二架构模型示例
图4 方案三架构模型示例
3.4 结果分析
方案一用于测试基于Macvlan的docker网络隔离方式对网络带宽的损耗情况,测试结果如图5所示:
图5 方案一测试结果
由于所有Iperf客户端都连接到同一个且唯一一个Iperf服务器,并且为UNIQUE模式。所以在方案一中,对于不同n值的实验,均有一台Mesos-slave只运行唯一的Iperf服务器端,所有Iperf客户端均运行在其他15台Mesos-slave中。从Iperf网络测试统计结果可以得出,随着Iperf客户端数量N的增加,基于Macvlan的docker网络隔离方式不会对网络带宽产生明显的损耗,无损的达到了原始带宽的网络性能。
方案二模拟单租户情况下的实际网络环境,测试结果如图6所示:
图6 方案一测试结果
Iperf客户端和唯一的Iperf服务器端由marathon框架自动随机部署到集群中。有测试结果可以看出,当N不大于16时,由于Mesos-slave总数为19台,所以每个Iperf服务器端和客户端能够分配到单独的一台Mesos-slave,所以此时与方案一相同。当N超过Mesos-slave总数时,Iperf服务器端和客户端会处于同一节点。所以该节点的Iperf客户端不会通过外部网络与Iperf服务器端通信,所以传输速率会远高于网络传输带宽,从而达到更好的通信性能。
方案三模拟多租户情况下网络的最坏情况,测试结果如图7所示:
图7 方案一测试结果
即Iperf服务器端均不会和与其相连接的Iperf客户端处于同一节点中,因此Iperf测试的流量均由网卡传输而不会直接通过本机传输影响网络测试结果。在实验一中得出基于Macvlan的docker网络隔离方式能有效的利用物理网卡带宽,达到近乎无损的网络性能在实验三中同样得以体现。而多租户情况下网络的最坏情况也能充分利用物理网卡现有的网络带宽。
在构建基于Mesos的分布式私有云系统时,利用docker容器封装云服务部署在集群中有着普遍的使用场景。但是同一宿主机上的docker容器间可能会发生网络端口冲突的问题。本文提出了基于Macvlan的docekr网络隔离方式。由于无需主动维护路由表等对各个集群节点的复杂配置方式,所以这一解决方案十分便捷。另一方面,由多个场景的实验可以得出,本方案不会对网络性能产生明显的损耗,充分利用了物理网卡的网络带宽。因此,基于Macvlan的docker网络隔离方式在解决了网络端口冲突的问题同时,具有便捷、高效、稳定的特性,是针对构建基于docker的Mesos私有云系统的理想解决方案。
参考文献
[1] Vavilapalli V K, Murthy A C, Douglas C, et al. Apache hadoop yarn: Yet another resource negotiator[C]//Procee -dings of the 4th annual Symposium on Cloud Computing. ACM, 2013: 5.
[2] Tabaa Y, Medouri A, Tetouan M. Towards a next generation of scientific computing in the cloud[J]. International Journal of Computer Science, 2012, 9(6): 177-183.
[3] .Stubbs J, Moreira W, Dooley R. Distributed Systems of M icroservices Using Docker and Serfnode[C]//Science Gateways (IWSG), 2015 7th International Workshop on. IEEE, 2015: 34-39.
[4] Bernstein D. Containers and cloud: From lxc to docker to kubernetes[J]. IEEE Cloud Computing, 2014 (3): 81-84.
[5] .Jeffree A, Congdon P, Haddock S. Media Access Control (MAC) Bridges and Virtual Bridge Local Area Networks[J]. The Institute of Electrical and Electronics Engineers, Inc., ISBN, 978-0.
Docker Container Network Architecture Base on M acvlan
Yang Xin, Wu Zhinan, Qian Songrong
(College of Information Science and Engineering, Fudan University, Shanghai 200433, China)
Abstract:Big data platform based on Mesos and docker is one of the popular scheme to construct private cloud. But network port conflict exists among ports of different docker containers, which are all binding to the same network port on the same host. But this problem can be solved by Macvlan, Macvlan can allocate each Docker container one unique virtual network interface, so that each container w ill own one unique IP address that is diffdrent from others. And investigating through this experiment, this network isolation technology of docker based on Macvlan can solve the problem of docker network port conflict in Mesos cluster conveniently and fast, w ith nearly no lost of network bandw idth.
Key words:Docker; Macvlan; Mesos; Network Namespace; Network Isolation; Network Port Conflict
中图分类号:TP393.1
文献标志码:A
文章编号:1007-757X(2016)05-0058-03
作者简介:杨 鑫(1990-),男,浙江,复旦大学通信科学与工程系,硕士研究生,研究方向:网络与数据通信;上海,200433吴之南(1991-),男,上海,复旦大学通信科学与工程系,硕士研究生,研究方向:网络与数据通信;上海,200433钱松荣(1967-),男,上海,复旦大学通信科学与工程系,教授,研究方向:网络与数据通信;上海,200433
收稿日期:(2015.11.16)