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

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

3.5网络虚拟化

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

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

2.从OVXSwitch/ OVXPort和PhysicalSwitch/ PhysicalPort的主机附着点转换到/;

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

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

3.5.1交换机表示转换

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

OVXSwitch->PyhsicalSwitch(南向):

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

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

■通过OVXMap查询:对于一个OVXSingleSwitch,1:1的映射允许OVX通过租户ID在physicalSwitchMap上直接查询。

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

PhysicalSwitch -> OVXSwitch (北向):

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

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

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

3.5.2 OpenFlow字段转换—Cookie,Buffer ID,XID

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

■XidTranslator [net.onrc.openvirtex.datapath] : LRULinkedHashMap xidMap

■OVXFlowTable [net.onrc.openvirtex.datapath] : ConcurrentHashMap flowmodMap

■OVXSwitch : LRULinkedHashMap bufferMap

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

1.生成一个新的XID;

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

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

4.给调用者返回新的XID。

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

1.恢复给定消息的XID的XidPair;

2.返回XidPair给调用者。

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

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

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

bufferMap.PacketIn/PacketOut引用同一个bufferID。在消息的转换过程中,需要将来自packet_in的buffer_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_src和nw_dst字段进行OVXIPAddress值匹配,将OVXIPAddress重写成PhysicalIPAddress;

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

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

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


虚拟化过程流程如下:

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

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

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

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

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

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

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

3.5.3.2实现

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

PhysicalIPAddress -> OVXIPAddress:

* OVXPacketIn

OVXIPAddress -> PhysicalIPAddress:

* OVXPacketOut

* OVXFlowMod

* OVXActionNetworkLayerSource/Destination

图3.7、3.8、3.9按顺序展示了OVXPacketIn、OVXPacketOut、OVXFlowMod消息的虚拟化与去虚拟化过程。

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中的端口如果发生故障则可以在租户网络中完全隐藏,前提是:BVS的OVXPorts之间存在替代路径,或者没有SwitchRoutes使用这些端口。

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

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

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

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

(1)映射到OVXLinks和SwitchRoutes的OVXPorts;

(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)

推荐阅读更多精彩内容