对于云平台的隔离,我们一直使用的策略是VLAN,但是这种策略的问题很明显,就是VLAN只有12位,一共4096个,现在看来,是绝对不够使用的
一种方式是修改这个协议,这个其实比较难以实现,因为一旦一个协议形成后,很多设备就按照这个协议来了,如果随随便便的改,那么已经使用的设备怎么办呢?
一种是扩展,在原本包的基础上,扩展一个新的头,里面包含了区分租户的ID,外层的包的格式和传统的一样,依然兼容原本的格式,需要区分用户的地方,就用这个特殊的程序,处理这个特殊的包
这就和我们说的隧道理论一样,自驾游通过摆渡轮船到对岸的故事之中,扩展的头主要是用于加密,而现在我们的头用于区分用户
底层的物理设备组成的网络我们称为Underlay网络,虚拟机和云中的技术组成的网络称为Overlay网络,这是一种基于物理网络的虚拟化网络实现
我们就说一下Overlay的网络技术
GRE:
首先是GRE技术,全名是Generic Routing Encapsulation,是一种端对端的技术 IP-over-IP的隧道技术,将IP的封装在Gre中,外面加上了IP头,在隧道的一段封装数据包,并在通路上传输,在另一端进行解封装,可以认为Tunnel是一种虚拟的,点对点的,连接
在其中,GRE头中,前面32位一定会有,后面都是可选的,在前4位标识位中,标识后面有没有可选项,这有个很重要的key字段,是一个32位的字段,里面存放的就是区分用户的Tunnel ID,32位的,足够 用很久了
在下面的格式,用于网络虚拟化的GRE包头格式,称为NVGRE,预留了24位作为ID号,够用了
GRE,在使用过程中,还需要有一个地方需要封装和解封装GRE的包,这个地方往往是路由器和路由功能的Linux机器上
整体的传输过程可以简化为,有两个网段,两个路由器,中间要通过GRE隧道进行通信,当隧道建立后,会多出两个Tunnel端口,用于封包,解封包
1.主机A在左边的网络,Ip地址为192.168.1.102,需要访问的是主机B,主机B在右边的网络,IP地址为192.168.2.115,需要发一个包,源地址为192.168.1.102,目的地址为192.168.2.115,因为要跨网段访问,于是要过网关
2.在网关中,查看到要去左边的路由器,需要走一条GRE的隧道,从隧道的一段的网卡Tunnel0进入隧道
3.Tunnel隧道的端口上进行包的封装,在内部的IP头之外加上GRE头,对于NVGRE来讲,是MAC头之外加上外部的IP地址,也就是路由器的外网IP地址,源IP地址为172.17.10.10,目标IP为172.16.11.10,然后从E1的物理网卡发送到公共网络
4.在公共网络里面,沿着路由器一跳跳的走,全部都按照外网的IP进行跳转
5.当网络包到达对端的时候,要到达对端的Tunnel0,进行解封装,将外层的Ip头取出来,然后根据里面的网络包,根据路由表,从E3口转发出去到达服务器B
从Gre的技术性质来看,GRE通过了隧道的方式,很好的解决了VLAN ID不足的问题
但是,GRE有一些缺憾,首先是Tunnel的数量问题,GRE是一种点对点的隧道,如果有三个网络,就需要在每两个网络之间建立一个隧道,如果网络数目增多,建立的隧道数会指数性增长
其次是GRE不支持组播,当一个网络的一个虚拟机发出了一个广播帧,GRE会广播到所有和这个节点有隧道的节点
最后就是有很多的防火墙和三层网络设备没法去解析GRE,因此无法对GRE封装包去合适的过滤和负载均衡
VXLAN
第二种Overlay的技术叫做VXLAN,和三层外面套三层的GRE不同,VXLAN则是二层外面套一个VXLAN的头,里面包含的VXLANID为24位,也够用了,在VXLAN的头外面还封装了UDP IP和外层的MAC头
VXLAN作为扩展性协议,需要一个地方对VXLAN的包进行封装和解封装,这个功能点被称为VTEP
虚拟机网络的管家,每个物理机上都有一个VTEP,每个虚拟机启动的时候,都需要向这个VTEP管家注册,每个VTEP都需要知道自己上面注册了多少个虚拟机,每次虚拟机跨VTEP进行通信的时候,都需要通过VTEP代理,进行相对应的封装和解封装
和Gre端到端的隧道不同,VXLAN不是点到点的,而是支持通过组播来定位目标机器,而不一定是这一端发出,另一端接收
当一个VTEP启动的时候,需要通过IGMP协议,加入一个组播组,就好比加入一个微信群一样,所有发到这个邮件列表里面的邮件,或者发送到微信群里面的消息,大家都能收到,每当一个物理机上有虚拟机启动了,VTEP就知道了,有一个新的VM上线了
虚拟机1 2 3 属于一个用户的虚拟机,需要分配相同的VXLAN ID = 101,在云的界面上,可以知道他们的IP地址,于是虚拟机1可以ping虚拟机2
但是虚拟机1不知道虚拟机2的MAC地址,因此包没法发出去,要进行ARP的广播
因为虚拟机2和虚拟机1不在一个物理机上,所以当ARP请求到达VTEP1的时候,VTEP1知道,我这里有一个虚拟机,但是虚拟机2不受我管啊,需要知道MAC地址
VTEP1想,其利用IGMP加入了一个组织,或者说,加入了一个微信群,可以在里面@all一下,问一下,虚拟机2归谁管呢?于是VTEP1将ARP请求封装到VXLAN里面,组播出去
当然,在这个群里面,VTEP2和VTEP3都收到了消息,都会解开VXLAN里面看,里面是一个ARP
VTEP3在本地广播了半天,发现没人回,说明虚拟机不是自己管理的
VTEP2在本地广播了,发现虚拟机2回复了,说明虚拟机可以归自己管理,于是回复,MAC地址使我们,通过这次通信,VTEP2学到了,虚拟机1归VTEP1管理,以后要找虚拟机1的话,就去找VTEP1就可以了
VTEP2将ARP的回复封装到了VXLAN里面,直接发给VTEP1了,VTEP1也学到了,虚拟机2归VTEP2管理,以后找虚拟机2就去找VTEP2就可以了
然后这就相当于ARP走完了
有了GRE和VXLAN技术,可以解开VLAN的限制了,那么如何将这个技术融入云平台呢?
如果把云平台比作宿舍
可以把虚拟机比作自己单独的电脑,路由器和DHCP Server相当于家用路由器或者寝室长的电脑,外网网口访问互联网,所有的电脑都通过内网网口连接到一个交换机br0上,虚拟机想要访问公网,通过br0连接到路由器上,然后通过路由器转发到公网
但是假如,一个宿舍分为了三个宿舍,对应着上面,就是路由器单独在一台物理机上,但是其他的室友的VM在其他的物理机上,这样每个宿舍都是单独的一段
这样为了可以上网,需要在三个宿舍中间打通一个隧道,通过网线将三个宿舍的两个br0连接起来,让其他的室友的电脑和寝室长的电脑看起来还是在一个br0上,其实中间通过隧道中的网线做了转发
为什么要多一个br1的虚拟机呢,通过br1这一层将虚拟机之间的互联和物理机之间的互联隔离开来,中间的隧道建立在虚拟机之间,可以任意的设计
使用了OpenvSwtich之后,br0可以使用OpenvSwitch的Tunnel的功能和Flow功能
OpenvSwtich支持三种隧道GRE VXLAN Ipsec_GRE
使用OpenvSwtich之后,虚拟交换机相当于GRE和VXLAN封装的端点
三台物理机,每两台都有两台虚拟机,分别属于两个不同的用户,对应着每个VLAN的tag都不一样,这样不能互相通信,但是不同物理机上的相同用户,可以利用GRE进行连接
接下来,所有的Flow Table规则是设置在br1上,每个br1都有三个网卡,网卡1对内,网卡2 3对外
在Flow Table中
1.Table0是所有的流量入口,所有进入br1的流量,分为两种流量,一个是进入物理机的流量,一个是从物理机发出的流量
从port1进入的,都是发出去的流量,交给Table1处理
ovs-ofctl add-flow br1 “hard_timeout=0 idle_timeout=0 priority=1 in_port=1 actions=resubmit(,1)”
从port2 3进入的,都是进入物理机的流量,交给Table3处理
ovs-ofctl add-flow br1 “hard_timeout=0 idle_timeout=0 priority=1 in_port=2 actions=resubmit(,3)”
ovs-ofctl add-flow br1 “hard_timeout=0 idle_timeout=0 priority=1 in_port=3 actions=resubmit(,3)”
如果不是发出的,也不是流入的,就直接丢弃了
2.Table 1用于处理所有出去的网络包,分为两种情况,单播包和多播包
对于单播包,交给Table 20处理
ovs-ofctl add-flow br1 “hard_timeout=0 idle_timeout=0 priority=1 table=1 dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,20)”
对于多播包,交给Table 21处理
3.Table 2紧接着Table1的,如果不是单播,也不是多播,就直接丢弃
ovs-ofctl add-flow br1 “hard_timeout=0 idle_timeout=0 priority=0 table=2 actions=drop”
4.Table 3用于处理所有进来的网络包,需要将隧道Tunnel ID转换为VLAN ID
如果匹配不上Tunnel ID,就进行丢弃
ovs-ofctl add-flow br1 “hard_timeout=0 idle_timeout=0 priority=0 table=3 actions=drop”
如果匹配上了TunnelID,就转换为对应的VLAN ID,调到Table 10
ovs-ofctl add-flow br1 “hard_timeout=0 idle_timeout=0 priority=1 table=3 tun_id=0x1 actions=mod_vlan_vid:1,resubmit(,10)”
ovs-ofctl add-flow br1 “hard_timeout=0 idle_timeout=0 priority=1 table=3 tun_id=0x2 actions=mod_vlan_vid:2,resubmit(,10)”
5.对于进来的包,Table 10会进行MAC地址学习,这是一个二层交换机的事情,学习完了,从port1发出去
ovs-ofctl add-flow br1 “hard_timeout=0 idle_timeout=0 priority=1 table=10 actions=learn(table=20,priority=1,hard_timeout=300,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:0->NXM_OF_VLAN_TCI[],load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[],output:NXM_OF_IN_PORT[]),output:1”
Table 10用于学习MAC地址的,学习的结果放在Table20里面,Table 20被称为MAC learning table
NXM_OF_VLAN_TCI是VLAN tag,在MAClearning table中,每个entry都是针对某一个VLAN来说的,不同VLAN的learning table是分开的,在学习结果中,会标出这个entry是针对哪个VLAN的?
NXM_OF_ETH_DST[] = NXM_OF_ETH_SRC[]表示,当前包里面MAC Source Address会被放在学习结果的entry里的dl_dst里,因为每个交换机都是通过进入的网络包来学习的,某个MAC从某个port进来,交换机就应该记住,以后发往这个MAC的包都从这个port出去,因而源MAC地址被放在了目标的MAC地址汇总,这是为了发送
load:0->NXM_OF_VLAN_TCI[]表示,在Table20中,将包从物理机发出去的时候VLAN tag设置为0,学习完了,Table 20会有 actions = strip_vlan
load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[]意思是,在Table 20中,将包从物理机发出去的时候,设置Tunnel ID,进来时候多少,发出去就多少
output:NXM_OF_IN_PORT[]是发送给哪个port,比如从port2进来的,那么学习完了,Table20会有output2
所以如图所示,通过左边的MAC地址学习规则,学习到的结果就好像右边一样,这个结果会放在Table20里面是MAC Address Learning Table,如果不为空,就按照规则处理,如果为空,就说明没有学习过MAC,只能进行广播,交给Table 21处理
ovs-ofctl add-flow br1 “hard_timeout=0 idle_timeout=0 priority=0 table=20 actions=resubmit(,21)”
Table 21用于处理多播的包,
如果匹配不上VLAN ID,就默认丢弃
ovs-ofctl add-flow br1 “hard_timeout=0 idle_timeout=0 priority=0 table=21 actions=drop”
如果匹配上了VLAN ID,就将VLAN ID转换为Tunnel ID,从两个网卡 port2和port3发出去,进行多播
ovs-ofctl add-flow br1 “hard_timeout=0 idle_timeout=0 priority=1table=21dl_vlan=1 actions=strip_vlan,set_tunnel:0x1,output:2,output:3”
ovs-ofctl add-flow br1 “hard_timeout=0 idle_timeout=0 priority=1table=21dl_vlan=2 actions=strip_vlan,set_tunnel:0x2,output:2,output:3”
本章小结
1.对不同的用户的网络进行隔离,解决VLAN数目有限的问题 ,通过Overlay的方式,常用的有GRE和VXLAN
2.GRE是一种点对点的隧道模式,VXLAN支持组播的隧道模式,都要在某个Tunnel Endpoint进行封装和实现,实现跨物理机的互通
3.OpenvSwitch可以作为Tunnel Endpoint,设置流表的规则,将虚拟机网络和物理机网络进行隔离和转换
课后思考
1.VXLAN支持组播,但是如果虚拟机数目比较多,在Overlay网络里面,广播风暴还是很严重,怎么办?
2.基于虚拟机的云比较复杂,虚拟机的网卡,在物理网路哦转换层次比较多,有一种比虚拟机更加轻量级的云模式
overlay一般对广播的报文进行抑制和代理,然后将广播限制在接入设备的下面
很多时候,物理机可以提前知道对端的虚拟机的MAC地址,因此发起ARP请求的时候,不用广播全网,只需要本地返回就可以了,在OpenStack里面称为L2Population