码迷,mamicode.com
首页 > 其他好文 > 详细

OpenVirteX体系结构之操作与子系统(三)

时间:2015-01-30 17:09:17      阅读:189      评论:0      收藏:0      [点我收藏+]

标签:

SDNLAB独家译稿】接本系列上一篇《OpenVirteX体系结构之操作与子系统(二)》,本文翻译OpenVirteX第三章剩余部分。

技术分享

 

3.5 网络虚拟化

      在OVX中,虚拟化和去虚拟化是在虚拟层面与物理层面分界移动的逻辑动作,对于OpenFlow消息操作而言,这意味着一下几个步骤:

1.修改源和目的地网络地址;

2.OVXSwitch/ OVXPortPhysicalSwitch/ PhysicalPort的主机附着点转换到/

3.丢弃来自或发送到给定虚拟和物理网络拓扑中的无效点(主机、交换机)的消息。

源于物理和虚拟网络为主机(IP地址)和交换机(DPIDs和端口号)所使用的不同寻址方案。2逻辑上遵循1,由于主机的连接点也会根据网络视图有不同的命名。3用来隔离虚拟网络之间的流量。本节提供了这三个过程中发挥作用的各种机制的描述。

3.5.1 交换机表示转换

     在消息处理期间,虚拟化过程中的一个关键功能就是OVXSwitchPhysicalSwitch之间的转换。

OVXSwitch->PyhsicalSwitch(南向):

OVXSwitch拦截租户控制器发送的南向消息。查询目的PhysicalSwitch的方法有以下两种:

 ■通过入口OVXPortPhysicalSwitch通过映射到OVXPortPhysicalPort发现,该OVXPort通过消息中的端口字段发现,如:OFMatch结构中的in_port域。对于一个OVXBigSwitch来说,任何没有入端口的值都将被忽略。

 ■通过OVXMap查询:对于一个OVXSingleSwitch1:1的映射允许OVX通过租户IDphysicalSwitchMap上直接查询。

在每个OVXSwitch子类中实现的OVXSwitch.sendsouth()方法中查找。

PhysicalSwitch -> OVXSwitch (北向):

      反向查找过程开发了OVX如何定义租户网络和如何进行OpenFlow通信。

 

      租户网络:主机不能被连接到一个以上的OVXNetwork,主机可通过MAC地址作为唯一的标识。通过使用从OFMatch字段中得到的MAC地址,租户ID可以从OVXMapmacMap中取得。

      OpenFlow通信:OpenFlow针对同一次会话中的多条消息里的某些字段使用相同的值,OVX可使用新值来代替南向消息的cookieXIDbuffer id字段,或者当接收到相应的应答时(北向)可被映射成原本的状态。下一节将进一步讨论字段转换的过程。

3.5.2 OpenFlow字段转换—CookieBuffer IDXID

      OVX使用下列几种结构来保持字段翻译中使用的映射:

 ■XidTranslator [net.onrc.openvirtex.datapath] : LRULinkedHashMap<Integer, XidPair> xidMap

 ■OVXFlowTable [net.onrc.openvirtex.datapath] : ConcurrentHashMap<Long, OVXFlowMod> flowmodMap

 ■OVXSwitch : LRULinkedHashMap<Integer, OVXPacketIn> bufferMap

      XIDTranslator.XID值必须在每一个datapath内是唯一的。XIDTranslator使用OpenFlowXID来复用/解复用一个数据通路和多租户之间的通信。对于每个南向OVXMessageXIDTranslator

1.生成一个新的XID

2.创建一个XidPair来存储原来的XID和源OVXSwitch

3.xidMap中使用新的XID作为键来存储XidPair

 

4.给调用者返回新的XID

      XidTranslator.translate()实现以上的动作。调用者(PhysicalSwitch)用新的值来代替消息中的XID,这样一个datapath就仅有一个唯一的XID用于接收消息。对于北向消息,XIDTranslator

1.恢复给定消息的XIDXidPair

2.返回XidPair给调用者。

      发起会话的租户可以从XidPair中的OVXSwitch得以恢复这个相反的过程由XidTranslator.untranslate()实现。

      OVXFlowTable .OVXFlowTablemap形式存储新的流表项,该mapOVX生成的cookies作为key,对应的value是未被修改的OVXFlowMods,生成的Cookie用于编码源租户ID

技术分享

 

cookieCounter确保了OVXSwitchcookie的唯一性。具体地讲,当FlowMod增加流表时被OVXFlowMod.devirtualize()分配一个新的cookie,新cookie在流表中作为匹配机制,也就是说当OVX接收FlowRemoved时,必须删除条目,以保持与网络的状态的一致性。

      bufferMap.PacketIn/PacketOut引用同一个bufferID。在消息的转换过程中,需要将来自packet_inbuffer_id和生成的buffer_id存起来,当packet_out数据下发时,需要查找并转换。

技术分享

 

如上所示,所存储的PacketIn内容被用来逆转之前虚拟化过程中地址、端口以及bufferID的转换。接下来讨论地址虚拟化的机制。

3.5.3 地址虚拟化

3.5.3.1 综述

      OVX为每个主机创建虚拟地址(OVXIPAddress)和物理地址(PhysicalIPAddress)以避免租户流量之间存在地址空间冲突。虚拟地址在租户的OVXNetwork中是唯一的,而物理地址在整个物理网络中是唯一的。虚拟和物理IP地址之间转换可保证每个租户控制器依照其网络的编址方案(尽管可能与其他租户方案重叠)来处理流,并且datapath有能力识别不同租户的流量。

地址转换将datapath分成两组:

 ■边缘:含有主机挂载的datapath

 ■核心:datapath仅和其他datapath相连。

     边缘datapath用于重写IP地址。边缘交换机主要用于以下两个方面:

1. 对于网络侧的流量,nw_srcnw_dst字段进行OVXIPAddress值匹配,将OVXIPAddress重写成PhysicalIPAddress

2.对于来自主机侧的流量,匹配PhysicalIPAddress值,将PhysicalIPAddress重写成OVXIPAddress

 核心交换机依据PhysicalIPAddresses进行匹配和转发。

      OVX拦截并改变FlowMod以便将这些行为添加到datapath上。除了FlowMod, OVX也改变PacketInPacketOut——核心datapath只能“看见”PhysicalIPAddress值,控制器只能看见OVXIPAddres值。图3.6描述地址虚拟化的过程。表2表示一组由租户控制器发送到OVXOVXdatapath的可能FlowMod,以达到虚拟化。

技术分享

 

虚拟化过程流程如下:

a)PacketIn消息携带OVXIP值,未经修改发送到租户控制器;

b)相应的FlowMod匹配OVXIP,并将值重写为PhysicalIP

c)虚拟链路通过psw2映射回两跳路径;

d)目的地边缘的PacketIn与核心网络中的转换行为一致;

e)OVX下发与PhysicalIP匹配的FlowMod消息,并将它们重写回OVXIP

3.6 三个datapath的地址虚拟化过程,交换机标识的数字表示端口号。在租户网络和实际网络中,端口号可能不同,即使是准确的映射,如pws1vsw1。这里,h1开始发送数据包到h2OVX根据目标datapath相对于源和目的主机中的位置分别处理PacketIns(租户方向箭头)和FlowMods(网络方向箭头)。

技术分享

 

该行为的注意事项在ARP报文处理中介绍,具体见3.5.4节。 

3.5.3.2 实现

转换过程通过下列几个OVXMessage类实现:

PhysicalIPAddress -> OVXIPAddress:

 * OVXPacketIn

OVXIPAddress -> PhysicalIPAddress:

 * OVXPacketOut

 * OVXFlowMod

 * OVXActionNetworkLayerSource/Destination

3.73.83.9按顺序展示了OVXPacketInOVXPacketOutOVXFlowMod消息的虚拟化与去虚拟化过程。

技术分享

 

技术分享

技术分享

3.6 状态同步

3.6.1 组件状态协调(原文未完善)

3.6.2 错误升级

      OVX使用错误拦截来同步物理网络。网络中的错误,如端口、链路、交换机出现问题,将通过OFPortStatus消息发送到OVX上。目前OVX的实现期望PortStatus消息的OFPortReason字段携带具体原因值,如发生故障的交换机在该消息中携带原因值OFPPR_DELETE来发送。OVX将这些PortStatus消息作为   OVXPortStatus[net.onrc.openvirtex.messages]实例处理。

      OVXPortStatus消息的处理依赖于OVX的状态。在一个简单的案例中,只有端口、链路而没有租户网络的存在,PhysicalNetwork中的交换机将被除去。即使存在租户,在给定具有特定属性的虚拟拓扑结构的网络中,OVX也具有隐藏错误情况的能力。

 ■OVXBigSwitches网络:non-OVXPort中的端口故障与网络故障是相似的。BVS中的端口如果发生故障则可以在租户网络中完全隐藏,前提是:BVSOVXPorts之间存在替代路径,或者没有SwitchRoutes使用这些端口。

 ■冗余OVXLink:如果在OVXPort定义的OVXLink之间有多条链路是可用的,端口在一条路径失效的情况下可以通过故障转移到另一条路径。

      此外,未映射端口的故障将被简化到最简单的情况。图3.10显示了可以由OVX抑制的故障情形。

技术分享

 

      图3.10三种情况中的错误可以被抑制。左)PhysicalSwitches bc未映射到OVXNetwork,租户对于bc以及与它们相关的错误完全是无知的。中)多个物理路径映射到vs1vs2之间的OVXLink([a-b,b-d],[a-d],[a-c,c-d]),提供足够的备份路径,这样就不会有链路故障报告给租户,除非ad之间的所有路径均出现了故障,或者是PhysicalPorts映射到OVXPorts失败。右)整个PhysicalNetwork映射到一个BVScrossbarPhysicalLinks、端口和交换机的故障可能会被隐藏,除非ad之间的SwitchRoute用完了路径,或OVXPorts失败。

      OVXBigSwitchOVXLink灵活性在3.7节中讨论。顺便说一句,当发生下列情况时错误升级仅影响视图:

1)映射到OVXLinksSwitchRoutesOVXPorts

2)非弹性路径部分;

3)映射到OVXSwitch边缘端口。

      已删除的PhysicalPort的移除过程遵循3.2.3节的图3.3中所描述的依赖关系树,详情可查看《OpenVirteX体系结构之操作与子系统(一)》,完整的错误升级过程在OVXPortStatus.virtualize()中实现。

本文未完。。。。。。

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

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

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

技术分享

(2) 微信(账号SDNLAB)

技术分享

(3) QQ群

        SDN研究群(214146842)

        OpenDaylight研究群(194240432)

 

 

OpenVirteX体系结构之操作与子系统(三)

标签:

原文地址:http://www.cnblogs.com/SDNLAB123/p/4262551.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!