Overlay网络与物理网络的关系

编者按:无论是云计算还是SDN都把注意力集中在数据中心网络的建设上,各种解决方案层出不穷,其中以VMware为代表的软件厂商提出Overlay网络方案后,为数据中心网络的发展提出了新的思路。那么Overlay是如何与物理网络相互依存的?

在以往IT建设中,硬件服务器上运行的是虚拟层的计算,物理网络为了与虚拟服务器对接,需要网络自己进行调整,以便和新的计算层对接(如图1所示)。

Overlay是在传统网络上虚拟出一个虚拟网络来,传统网络不需要在做任何适配,这样物理层网络只对应物理层的计算(物理机、虚拟化层管理网),虚拟的网络只对应虚拟计算(虚拟机的业务IP),如图2所示。

Overlay的技术路线,其实是从架构上对数据中心的建设模式进行了颠覆,对物理设备的要求降至最低,业务完全定义在层叠网络上。那么,这是否意味着将来数据中心使用Overlay网络不需要硬件支持而只需要软件定义就足够了呢?答案无疑是否定的。

以下讨论Overlay网络与物理网络的依存关系。由于VXLAN(Virtual eXtensible LAN)技术是当前最为主流的Overlay标准,以下VXLAN技术为代表进行具体描述。

1. 报文的封装与解封装

VXLAN的核心在于承载于物理网络上的隧道技术,这就意味着要对报文进行封装和解封装,因此需要硬件来加速处理。

在VXLAN网络中,用于建立VXLAN隧道的端点设备称为VTEP(VXLAN Tunneling End Point,VXLAN隧道终结点),封装和解封装在VTEP节点上进行。

在云数据中心,部分业务是不适合进行虚拟化的(如小机服务器,高性能数据库服务器),这些服务器会直接与物理交换机互联,而他们又必须与对应租户/业务的VXLAN网络互通,此时就必须要求与其互联的硬件交换机也能支持VXLAN协议,以接入VXLAN网络。

考虑到服务器接入的可以是虚拟交换机,也可以是物理交换机,因此存在三种不同的构建模式(如图3所示):其中网络Overlay方案中,所有终端均采用物理交换机作为VTEP节点;主机Overlay方案中,所有终端均采用虚拟交换机作为VTEP节点;混合Overlay方案中,既有物理交换机接入,又有虚拟交换机接入,且软件VTEP和硬件VTEP之间可以基于标准协议互通。

在网络Overlay方案和混合Overlay方案中,都需要有物理交换机设备支持VXLAN协议栈,并能与虚拟交换机构建的VTEP互通。由于在实际组网环境中,服务器种类很多,高吞吐高性能要求的业务一般都采用单独物理服务器甚至小机的硬件环境,而非虚拟化的x86服务器,这就没法使用vSwitch来接入VXLAN网络,只能让支持VXLAN的物理交换机来接入了。

2. 组播协议传播

VXLAN网络的MAC表与隧道终端的绑定关系要用组播协议传播,而大规格组播协议离不开物理网络设备的支持。

按照VXLAN的标准,每一个VTEP都需要了解其接入的终端MAC地址,同时还需要知道整网(该VXLAN实例中)其他VTEP下所有的终端MAC地址。只有这样,在本地的VTEP收到报文后需要转发时,才能根据目的MAC查询到需要送到远端的目的VTEP那里。

按照IETF中对VXLAN网络的定义,负责在网络中传播MAC地址和VTEP对应关系的机制,正是依托于物理网络中的组播协议。VTEP将本地的MAC地址表利用组播协议在整个组播中传播,从而使得整网中所有组播成员,也就是其他VTEP都知道本地的MAC地址表。当VTEP下的终端接入情况有所更改,如新增了MAC地址或者减少了MAC地址,也需要利用组播协议通知同一个实例下的所有VTEP。另外,当本地VTEP找不到目的MAC处于哪一个远端VTEP时,也需要发送组播报文来查找目的MAC主机所属的远端VTEP。

如图4所示,多个VTEP需要在整网中传递VTEP下MAC地址信息,逻辑传递路线如绿色虚线所示。由于需要进行逻辑上的Full-Mesh连接,连接逻辑线路会达到N平方量级,因此实际组网中,VXLAN利用了物理网络的组播组,在建立好的组播组中加入VXLAN中所有VTEP成员,传递VTEP变更信息。在多用户多业务情况下,组播组要求与VXLAN数量息息相关。由于VXLAN网络规模的不断拓展(最大可达到16M个VXLAN网络),所需要的组播条目数会不断增加,这实际上对于物理网络承载组播处理能力和规格提出了要求。

由于标准VXLAN架构下使用组播协议,对物理网络组播数规格要求较大,因此H3C VXLAN解决方案基于SDN架构,通过引入全网的SDN Controller来实现VXLAN的管理和维护,使得VTEP之间的信息可以通过Controller来进行反射(如图5所示)。这样,VTEP的MAC地址表映射关系不再通过组播向全网其他VTEP传达,而是统一上报给控制器,由控制器统一下发给需要接受此消息的其他VTEP,由具体的VTEP执行转发机制。

可见,在SDN架构下,硬件形态的VTEP需要能够支持集中控制器下发的业务控制信息,同时基于Openflow进行流表转发。而传统硬件交换机不能支持上述特性,必须由新硬件设备来执行和完成的。

3. VXLAN网络互通

在传统L2网络中,报文跨VLAN转发,需要借助三层设备来完成不同VLAN之间的互通问题。VXLAN网络与传统网络、以及VXLAN网络的互通,必须有网络设备的支持。

VXLAN网络框架中定义了两种网关单元。

VXLAN三层网关。用于终结VXLAN网络,将VXLAN报文转换成传统三层报文送至IP网络,适用于VXLAN网络内服务器与远端终端之间的三层互访;同时也用作不同VXLAN网络互通。如图6所示,当服务器访问外部网络时,VXLAN三层网关剥离对应VXLAN报文封装,送入IP网络;当外部终端访问VXLAN内的服务器时,VXLAN根据目的IP地址确定所属VXLAN及所属的VTEP,加上对应的VXLAN报文头封装进入VXLAN网络。VXLAN之间的互访流量与此类似,VXLAN网关剥离VXLAN报文头,并基于目的IP地址确定所属VXLAN及所属的VTEP,重新封装后送入另外的VXLAN网络。

VXLAN二层网关。用于终结VXLAN网络,将VXLAN报文转换成对应的传统二层网络送到传统以太网络,适用于VXLAN网络内服务器与远端终端或远端服务器的二层互联。如在不同网络中做虚拟机迁移时,当业务需要传统网络中服务器与VXLAN网络中服务器在同一个二层中,此时需要使用VXLAN二层网关打通VXLAN网络和二层网络。如图7所示,VXLAN 10网络中的服务器要和IP网络中VLAN100的业务二层互通,此时就需要通过VXLAN的二层网关进行互联。VXLAN10的报文进入IP网络的流量,剥掉VXLAN的报文头,根据VXLAN的标签查询对应的VLAN网络(此处对应的是VLAN100),并据此在二层报文中加入VLAN的802.1Q报文送入IP网络;相反VLAN100的业务流量进入VXLAN也需要根据VLAN获知对应的VXLAN网络编号,根据目的MAC获知远端VTEP的IP地址,基于以上信息进行VXLAN封装后送入对应的VXLAN网络。

可见,无论是二层还是三层网关,均涉及到查表转发、VXLAN报文的解封装和封装操作。从转发效率和执行性能来看,都只能在物理网络设备上实现,并且传统设备无法支持,必须通过新的硬件形式来实现。

结束语

Overlay由于其简单、一致的解决问题方法,加上重新定义的网络可以进行软件定义,已经成为数据中心网络最炙手可热的技术方案。然而,它并不是一张完全由软件定义的网络,Overlay网络解决方案必定是一种软硬结合的方案,无论是从接入层VTEP混合组网的组网要求、组播或SDN控制层协议的支持,还是VXLAN网络与传统网络的互通来看,都需要硬件积极的配合和参与,必须构建在坚实和先进的物理网络架构基础上。

本文来源于SDNLAB,可点击此阅读原文。如果您对本文感兴趣,可参与以下互动方式与作者近距离交流。另外我们门户网站也有大型企业招聘平台,里面有很多优质的岗位,有意者请点击招聘查看详情。

如果您对本文感兴趣,可参与以下互动方式与作者近距离交流。

(1) 微博(http://weibo.com/sdnlab/

(2) 微信(账号:SDNLAB)

(3) QQ群

SDN研究群(214146842)

OpenDaylight研究群(194240432)

时间: 2024-12-29 13:59:08

Overlay网络与物理网络的关系的相关文章

Overlay对数据中心网络的改进

编者按:Overlay网络方案就是通过在现有网络上叠加一个软件定义的逻辑网络,最大程度的保留原有网络,通过定义其上的逻辑网络,实现业务逻辑,从而解决原有数据中心的网络问题,极大的节省传统用户投资.本文是<Overlay网络与物理网络的关系>的前传,帮助你了解一些关于overlay的基础概念. 云心网络设备随Overlay解决方案会发生什么变化?我们将在本期和下期文章里,力图回答这些问计算大潮将数据中心的网络建设推至聚光灯下,各种解决方案和各种技术标准不断涌现.以VMware为代表的软件厂商提出

cloudstack给已有zone加入物理网络

默认情况下,假设zone建立完后.cloudstack是不提供加入物理网络接口的. 基础架构- 域 - 物理网络 以下仅仅有我们创建zone的时候加入的物理网络 假设想在这个基础上加入一个物理网络是没有提供UI接口的. 假设想在已经建立好的物理网络基础上加入一个物理网络,那么能够通过系统提供的api加入. 1. 将zone 禁用 在基础架构 域里面选中 我们要操作的zone 点击禁用 2. 到全局设置 将apiport打开 在全局设置搜索api ,找到 integration.api.port

cloudstack给已有zone添加物理网络

默认情况下,如果zone建立完后,cloudstack是不提供添加物理网络接口的. 基础架构- 域 - 物理网络 下面只有我们创建zone的时候添加的物理网络 如果想在这个基础上添加一个物理网络是没有提供UI接口的. 如果想在已经建立好的物理网络基础上添加一个物理网络,那么可以通过系统提供的api添加. 1. 将zone 禁用 在基础架构 域里面选中 我们要操作的zone 点击禁用 2. 到全局设置 将api端口打开 在全局设置搜索api ,找到 integration.api.port 将默认

SDN理解:数据中心物理网络

- 目录 - 云数据中心流量类型 - NSX整体网络结构 - 管理网络(API网络) - 租户网络 - 外联网络 - 存储网络 - openstack整体网络结构 - 管理网络:(上图中蓝线) - 外部网络:(上图中黑线) - 存储网络:(图中红线) - 租户网络:(图中红线) 目录 除去我们上一节提到的cisco 的ACI是与思科封闭,自成一体的SDN解决方案以外,大部分SDN的解决方案的重点都不在硬件设备上.常见SDN解决方案的目的都是尽量在现有的成熟交换机或者标准白牌openflow的交换

Android网络之HttpUrlConnection和Socket关系解析

多年以前Android的网络请求只有Apache开源的HttpClient和JDK的HttpUrlConnection,近几年随着OkHttp的流行Android在高版本的SDK中加入了OkHttp.但在Android官方文档中推荐使用HttpUrlConnection并且其会一直被维护,所以在学习Android网络相关的知识时我们队HttpUrlConnection要有足够的了解.... 前几天因为时间的关系只画了图 HttpUrlConnection和Socket的关系图 ,本来说好的第二天

VMware 桥接 Bridge 复制物理网络连接状态

https://zhidao.baidu.com/question/535593443.html 意思就是说,VM上使用的是虚拟的网卡,也就是说VM虚拟机上的网卡不是真实存在的,而桥接还有其他的网路链接方式,都是必须存在网卡的.复制物理网卡连接状态,就是说把你指定的.本机的.真是网卡的状态信息复制给虚拟机的虚拟网卡,比如说你的本机真是网卡链接到了家用路由器的LAN口上,获得到了DHCP分配的地址,那么你的虚拟网卡就好像和真是网卡接入了同一台交换机中,也可以获得DHCP分配到的地址. http:/

centos7 docker宿主机配置桥接物理网络终极实战

1.停止docker daemon,并删除docker0 systemctl stop docker.service ip link set dev docker0 down brctl delbr docker0 2.创建桥接物理网络: 2.1.思路整理 (1)新建br0桥接网络,brctl show可以查看(需安装bridge-utils) (2)将宿主机物理网卡IP.掩码.网关.dns(或者dhcp)配置到br0上 (3)删除宿主机物理网卡IP.掩码.网关.dns(或者dhcp)配置 (4

docker 实战---多台物理主机的联网,容器桥接到物理网络拓扑图(四)

很多朋友说上一篇中对网络的描述不够清楚,感谢热心的群友彩笔程序员: 提供了他理解的图,在这里贴一下: 我自己也补画了一副多台机器互联的图,欢迎大家留言讨论: 主机A和主机B的网卡一都连着物理交换机的同一个vlan 101,这样网桥一和网桥三就相当于在同一个物理网络中了,而容器一.容器三.容器四也在同一物理网络中了,他们之间可以相互通信. 主机A上的网卡二连接了vlan102 桥接网桥二,它不与其他物理主机和容器相通.

Tungsten Fabric架构解析丨TF如何连接到物理网络

Hi!这里是Tungsten Fabric架构解析内容的第九篇,介绍TF如何连接到物理网络.Tungsten Fabric架构解析系列文章,由TF中文社区为你呈现,旨在帮助初入TF社区的朋友答疑解惑.我们将系统介绍TF有哪些特点.如何运作.如何收集/分析/部署.如何编排.如何连接到物理网络等话题. 在任何一个数据中心中,都需要一些VM访问外部IP地址,并且数据中心外部的用户,也需要通过公共IP地址访问某些VM.为此,Tungsten Fabric提供了几种实现方法: V P N 连接到启用BGP