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）