探索 OpenStack 之(8):Neutron 深入探索之 OVS + GRE 之 完整网络流程 篇

前两篇博文分别研究了Compute节点和Neutron节点内部的网络架构。本文通过一些典型流程案例来分析具体网络流程过程。

0. 环境

学习OpenStack之(7):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)所收到的请求及其回复:

[email protected]:/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节点也需要扩展。

时间: 2024-11-09 03:20:15

探索 OpenStack 之(8):Neutron 深入探索之 OVS + GRE 之 完整网络流程 篇的相关文章

学习OpenStack之(7):Neutron 深入学习之 OVS + GRE 之 Neutron节点篇

0. 测试环境 硬件环境:还是使用四节点OpenStack部署环境,参见 http://www.cnblogs.com/sammyliu/p/4190843.html OpenStack配置: tenant:三个tenant:demo,tenant-one,tenant-two network:三个tenanet公用public network,每个tenant拥有自己的subnet,都有一个router连接自己的subnet到public net 虚机:三个虚机,tenant-one一个,te

Neutron 理解 (3): Open vSwitch + GRE/VxLAN 组网 [Netruon Open vSwitch + GRE/VxLAN Virutal Network]

学习 Neutron 系列文章: (1)Neutron 所实现的虚拟化网络 (2)Neutron OpenvSwitch + VLAN 虚拟网络 (3)Neutron OpenvSwitch + GRE/VxLAN 虚拟网络 (4)Neutron L3 agent (5)TBD 目前,OpenStack Neutron 支持使用两种隧道网络技术 通用路由封装(GRE) 和 VxLAN 来实现虚拟的二层网络.这两种技术大致看起来非常相似,都是需要使用 OpenStack 在计算和网络节点上建立隧道

探索 OpenStack 之(13):研究 Keystone

Keystone 是 OpenStack Identity Service 的项目名称.本文就试着尽可能深入地研究 Keystone. 1. Keystone 的功能 做为 OpenStack 云系统的入口,Keystone 提供了云系统入口所需要的许多功能: (1). 用户身份验证:系统得知道用户是不是合法的用户.为此,Keystone 需要对 user 进行管理和保存:管理用户相关的 tenant.role.group 和 domain等:用户 credential 的存放.验证.令牌管理等

[转载]OpenStack OVS GRE/VXLAN网络

  学习或者使用OpenStack普遍有这样的现象:50%的时间花费在了网络部分:30%的时间花费在了存储方面:20%的时间花费在了计算方面.OpenStack网络是不得不逾越的鸿沟,接下来我们一起尝试努力穿越这个沟壑吧……J 主要参考: RDO官网对GRE网络的分析: http://openstack.redhat.com/Networking_in_too_much_detail OpenStack网络出错处理的一般步骤: http://docs.openstack.org/trunk/op

Ubuntu 12.04 Server OpenStack Havana多节点(OVS+GRE)安装

1.需求 节点角色 NICs 控制节点 eth0(10.10.10.51)eth1(192.168.100.51) 网络节点 eth0(10.10.10.52)eth1(10.20.20.52)eth2(192.168.100.52) 计算结点 eth0(10.10.10.53)eth1(10.20.20.53) 注意1:你总是可以使用dpkg -s <packagename>确认你是用的是Havana版本 注意2:这个是当前网络架构 2.控制节点 2.1.准备Ubuntu 安装好Ubuntu

OpenStack OVS GRE/VXLAN

https://www.jianshu.com/p/0b52de73a4b3 OpenStack OVS GRE/VXLAN网络 学习或者使用OpenStack普遍有这样的现象:50%的时间花费在了网络部分:30%的时间花费在了存储方面:20%的时间花费在了计算方面.OpenStack网络是不得不逾越的鸿沟,接下来我们一起尝试努力穿越这个沟壑吧……J 主要参考: RDO官网对GRE网络的分析: http://openstack.redhat.com/Networking_in_too_much_

深度探索 OpenStack Neutron:BGP(1) 【转载】

3.4 BGP 原文地址:http://mp.weixin.qq.com/s?src=3&timestamp=1500043305&ver=1&signature=XwiIVVLHaVK5kzRNQKR1dkOzl1DR375P-R9g998sGTpT8WF20P9REPkYOfS85KOlI2h8RnHL3jvJvFu6gu*CNceX8Ky1iJXeGkX1NGYyMFruvBNS1XsJUv3RHgtEpGEIdMN4UZfKkUcdQQ6b9ZbvkqUaAcyanc3bh

探索 OpenStack 之(16):计量模块 Ceilometer

0. 背景 0.1 为什么要有 Ceilometer? 通常云,特别是公有云在计费方面有三个层次: 计量 (Metering): 收集资源的使用数据,其数据信息主要包括:使用对象(what), 使用者(who), 使用时间(when)和 用量(how much). 计费 (Rating):将资源使用数据按照商务规则转化为可计费项目并计算费用 结算 (Billing):收钱开票 Ceilometer 的目标是 计量 Metering 方面,为上层的计费.结算或者监控应用提供统一的资源使用数据收集功

探索 OpenStack 之(9):深入块存储服务Cinder (Part 1)

继研究了Neutron之后,继续Nova的外围研究之旅.本站是研究块存储服务Cinder. 0.验证环境 环境包括: 1.一个controller节点,运行nova-api, nova-scheduler, cinder-api, cinder-scheduler, mysql, rabbitmq 2.一个Nova compute节点,运行一个虚机 3.三个cinder volume节点,每个节点使用LVMISCSIDriver来使用本地存储 4. 创建一个volume type,设置 volu