探索 OpenStack 之（6）：Neutron 深入探索之 OVS + GRE 之 完整网络流程 篇

问题导读
1、Neutron 深入学习之 OVS + GRE 之 Neutron怎么搭建 ？
2、Neutron常见的案例有哪些？
3、GRE/OVS/Neutron的有哪些结论？






前两篇博文分别研究了Compute节点和Neutron节点内部的网络架构。本文通过一些典型流程案例来分析具体网络流程过程。
1. 环境
同 学习OpenStack之（5）：Neutron 深入学习之 OVS + GRE 之 Neutron节点篇 中所使用的环境。

简单总结一下：

Compute 节点上由Neutron-OVS-Agent负责：

• br-int：每个虚机都通过一个Linux brige连到该OVS桥上
• br-tun：转化网络packet中的VLAN ID 和 Tunnel ID
• GRE tunnel：虚拟GRE通道
  

Neutron节点上：

• br-tun/br-int：同Compute节点，由Neutron-OVS-Agent负责
• br-ex：连接物理网卡，用于和外网通信
• Network namespace：用于tenant 网络DHCP服务的qDHCP由Neutron-DHCP-Agent负责，和用于网络间routing的qRouter由Neutron-L3-Agent负责
  

2. 几个典型流程案例



2.1 流程1： 同一个host上同一个子网内虚机之间的通信过程


因为br-int是个虚拟的二层交换机，所以同一个host上的同一个子网内的虚机之间的通信只是经过 br-int 桥，不需要经过 br-tun 桥。如下图中红线所示：

2.2 流程2： 不同主机上同一个子网内的虚机之间的通信过程

过程：

1. 从左边的虚机1出发的packet，经过Linux bridge到达br-int，被打上 VLAN ID Tag

2. 到达br-tun，将VLAN ID转化为Tunnel ID，从GRE Tunnel 发出，到达另一个compute节点

3. 在另一个compute节点上经过相反的过程，到达右边的虚机

注：本配置待不久之后的实验验证。

2.3 流程3： 虚机访问外网

1. Packet离开虚机，经过Linux bridge， 到达br-int，打上 VLAN ID Tag

2. 达到 br-tun，将 VLAN ID转化为 Tunnel ID

3. 从物理网卡进入GRE通道

4. 从GRE通道达到 Neutron 节点的网卡

5. 达到跟物理网卡相连的br-tun，将 Tunnel ID 转化为 VLAN ID

6. 达到 br-int，再达到 router，router的NAT 表 将 fixed IP 地址 转化为 floatiing IP 地址，再被route 到br-ex

7. 从br-ex相连的物理网卡上出去到外网

外网IP访问虚机是个相反的过程。

2.4 流程4：虚机发送DHCP请求

过程：

1. 虚机的packet -> br-int -> br-tun -> GRE Tunnel -> eth2 ------>eth2->br-tun->br-int->qDHCP

2. qDHCP返回其fixed IP地址，原路返回

例如：在虚机（IP为10.0.22.202）启动过程中，DHCP Server （10.0.22.201）所收到的请求及其回复：

root@network:/home/s1# ip netns exec qdhcp-d24963da-5221-481e-adf5-fe033d6e0b4e tcpdump

listening on tap15865c29-9b, link-type EN10MB (Ethernet), capture size 65535 bytes //dnsmasq在此TAP设备上监听
07:16:56.686349 IP (tos 0x0, ttl 64, id 41569, offset 0, flags [DF], proto UDP (17), length 287)
    10.0.22.202.bootpc > 10.0.22.201.bootps: [udp sum ok] BOOTP/DHCP, Request from fa:16:3e:19:65:62 (oui Unknown), length 259, xid 0xab1b9011, secs 118, Flags [none] (0x0000)
   Client-IP 10.0.22.202 //虚机eth0的IP地址
   Client-Ethernet-Address fa:16:3e:19:65:62 (oui Unknown)
   Vendor-rfc1048 Extensions
     Magic Cookie 0x63825363
     DHCP-Message Option 53, length 1: Release
     Client-ID Option 61, length 7: ether fa:16:3e:19:65:62 //虚机eth0的Mac地址
     Server-ID Option 54, length 4: 10.0.22.201 //DHCP Server IP地址
复制代码

2.5 不同tenant内虚机之间的通信
Neutron Tenant网络是为tenant中的虚机之间的通信。如果需要不同tenant内的虚机之间通信，需要在两个subnet之间增加Neutron路由。
3. 关于GRE/OVS/Neutron的一些快速结论
1. GRE 可以隔离广播风暴，不需要交换机配置chunk口， 解决了vlan id个数限制，3层隧道技术可以实现跨机房部署，但它是点对点技术，每两个点之间都需要有一个隧道，对于4层的端口资源是一种浪费；同时，在IP头中增加Tunnel ID，势必减少vm的mtu值，同样大小的数据，需要更多的ip包来传，传输效率有影响。

2. OVS：可以针对每个vm做流量限制、流量监控、数据包分析，同时可以引入OpenFlow，使控制逻辑和物理交换相分离，并且sdn controller可以实现vxlan的跨机房大二层通信，但是可能性能是个潜在问题。
3. Neutron的优点：
       （1）提供REST API
       （2）Neutron 把部分传统网络管理的功能推到了租户方，租户通过它可以创建一个自己专属的虚拟网络及其子网，创建路由器等，在虚拟网络功能的帮助下，基础物理网络就可以向外提供额外的网络服务了，比如租户完全可以创建一个属于自己的类似于数据中心网络的虚拟网络。Neutron 提供了比较完善的多租户环境下的虚拟网络模型以及 API。像部署物理网络一样，使用 Neutron 创建虚拟网络时也需要做一些基本的规划和设计。
4. Neutron的可能问题：
    （1）单点故障：Neutron节点做为network的中心控制节点，很容易导致单点故障。生产环境中HA应该是必须有的。
    （2）性能降低：network traffic经过太多的层次，latency增加。
     （3）可扩展性不够：当Compute 节点快速增加的时候，Neutron节点也需要扩展。



相关内容：

学习OpenStack之 (1)：安装devstack

学习OpenStack之 (2)：Cinder LVM 配置

学习OpenStack之 (3)：Devstack Screen 使用技巧

学习OpenStack之（4）：在Mac上部署Juno版本OpenStack 四节点环境

学习OpenStack之（5）：Neutron 深入学习之 OVS + GRE 之 Compute node 篇

探索 OpenStack 之（6）：Neutron 深入探索之 OVS + GRE 之 完整网络流程 篇

探索 OpenStack 之（7）：深入块存储服务Cinder （功能篇）


探索 OpenStack 之（8）：深入镜像服务Glance

探索 OpenStack 之（9）：cinder-api Service 启动过程分析 以及 WSGI / Paste dep

探索 OpenStack 之（10）：cinder-api Service 处理 HTTP Request 的过程分析

探索 OpenStack 之（11）：研究 Keystone