商用SDDCN解决方案

商用SDDCN解决方案

摘要

以2012年VMWare收购Nicira为标志，SDN在数据中心落地的旗号正式吹响，众多创业公司开始进行相关的技术创新，各大厂商也着手在产品与市场上进行布局。经过5年左右时间的发展，商用SDDCN已经度过了早期的探索阶段，目前正处在从先锋客户试水转向大规模商用的关键节点上。

Nicira公司是SDN骨灰级选手，推出了OpenFlow和OVS，该公司的三位最主要创始人Martin Casado、Nick McKeown和Scott Shenker是业界公认的SDN惦记着。他们所提出的NVP所选的技术架构让人眼前一亮，使用Overlay构建纯软件的虚拟化网络，SDN只负责网络边缘的控制，而不会对现有网络产生任何影响，可以说是现有数据中心网络向SDN演进的最佳形态。

几种方案

在VMWare和Cisco的大战中，VMWare最终笑到最后，拿下了Nicira公司，基于其提出的NVP方案的原型推出了自己的SDN网络虚拟化平台NSX，高调进军数据中心网络市场，也宣告着放弃了与Cisco在网络领域的合作。NSX-V将NVP的技术特征嫁接到了VDS上，将其网络罗虚拟化与服务器虚拟化的产品共同交付。

NVP

图1 NVP的两层控制架构

如图1所示，NVP的控制平面分为两层，在上面负责和业务打交道的是Logical Controller，在下面负责和设备打交道的是Physical Controller。Provider通过CLI/GUI/RESTful API指定租户的逻辑拓普信息，Logical Controller接收并且存储逻辑拓普信息，并根据声明式语言nlog自动将其转化成为逻辑转发流表（universal flows）。universal flows对应的是租户层面的逻辑转发资源，如logical port id、logical datapath等，是物理资源无关的。Logical Controller通过RPC将universal flows下发给Physical Controller。Physical Controller中存着逻辑转发资源与物理转发资源间的映射关系，如vNIC和Transport Node的IP的对应关系等，它会根据这些映射关系将universal flows转换为physical flows/configuration，然后通过OpenFlow Nicira Extension/OVSDB发送给设备，以指导设备的转发。

为了实现控制平面的高可用性，logical controller和physical controller均采用分布式集群进行Master/hot Standby部署，使用ZooKeeper来进行leader选举、全局logical network id的分配以及RESTful API的信息配置。为了保证策略在分布式集群中的一致性，NVP对API的执行采用了严格的时序同步。另外，NVP还为配置信息设计了快照机制，方便进行回滚。

数据平面设计

NVP的转发设备就是OVS，也成Transport Node，通过OpenFlow Nicira Extension和OVSDB与Physical Controller Cluster进行通信，每个Transport Node都会指定一个Master Controller和多个Slave Controller。Transport Node进一步分为三类，Hypervisor，Service Node和Gateway。
Hypervisor连接着VM，Service Node负责集中地处理广播和组播流量，Gateway负责连接VM与物理主机。图2为NVP的数据平面结构。

图2 NVP数据平面结构

Transport Node间的通信建立在隧道的基础上，隧道封装默认采用Nicira私有的STT。STT采用无状态的TCP包头进行快速的分片/重组，从而允许VM上的应用产生巨型TCP负载，以提高端到端应用的通信效率。同事，NVP也提供了对VxLAN和GRE封装的支持。

为了实现数据平面的高可用性，Service Node和Gateway均采用集群式的部署。Service Node集群中只能与1个Gateway建立隧道以连接到物理网络，这是为了防止因物理网络中运行的MAC自学习而在多个Gateway之间产生环路。为了实现Gateway的主备，Gateway间通过CFM监测彼此的状态，并采用轻量级的leader选举算法，为每个L2 segment 选举出活动的Gateway，与各个Hypervisor 间建立隧道。另外，主备Gateway间进行切换时，物理网络是不会进行路径切换的，因此很可能会出现路由黑洞。解决这个问题需要在Gateway上运行特殊的机制以更新物理网络上的MAC Table；或者由新选举出来的主Gateway发送所有VM的免费ARP通告，或者所有的Gateway参与物理网络的STP选举，由新选举出来的主Gateway发送TCN来出发物理网络上的更新。

**NVP转发过程分析 **

NVP的转发采用了Proaltive的模式，因此其转发过程分为两个阶段：第一阶段是控制平面对全局转发信息的学习和分发；第二个阶段是数据包在datapath上的处理。

图3 控制器学习并分发全局信息

第一阶段如图3所示，其中（1）是Hypervisor/Gateway将MAC地址/vNIC的情况通过OVSDB告知控制平面。（2）是控制平面接收Provider提供的租户信息。（3）是控制平面结合（1）和（2）的输入，通过nlog产生流表并下发给Hypervisor、Service Node和Gateway。

图4 在OVS中进行逻辑转发和隧道封装

第二阶段如图4所示，当VM的数据包从vNIC进入OVS，首先第一级流表会根据vNIC所属的租户并为其标记metadata，然后根据metadata将数据包送到相应的流水线中继续进行匹配。流水线的后续匹配过程将完成对数据包的L2/L3处理，最终会根据egress流表中的逻辑对包进行转发。

对于单播流量，若目的地在同一个host中，则直接转给目的VM的vNIC；若目的地在另外的host中或者物理网络中，则需要封装隧道转发给相应的Hypervisor或者Gateway。对于广播/组播流量，则需要选择一个Service Node，封装相应的隧道交由该Service Node进行赋值，以免占用源Hypervisor上过多的CPU。注意，logical datapath上转发的决策完全发生在源Hypervisor上，决策的结果会放在隧道的header中，目的Hypervisor/Service Node/Gateway只需要根据隧道header中的相关字段将数据包直接转发给相应的vNIC/NIC即可。

NSX-V

NSX-V架构有待后续更新