《云数据中心网络与SDN：技术架构与实现》——2.4.2　在扩展性和可用性上找到平衡点

2.4.2　在扩展性和可用性上找到平衡点

再来说第2个基础性原则。

“需要为逻辑的集中点引入分布式协作机制，以提高SDN网络的可扩展性与可用性，并支持与传统网络的互通”。实际上，不只是传统网络中用到了分布式控制技术，任何大规模的IT业务系统都需要通过分布式技术来保证可扩展与高可用。当然，前面曾简单地分析了传统网络中分布式路由技术存在的一些不足，为了能够对网络进行全局化和自动灵活的控制，需要将各个设备中的逻辑提取出来（或者提取一部分），形成一个逻辑上集中的网络控制点。不过，SDN作为一个整体的系统，总需要有一部分来保证扩展性和可用性。因此，逻辑上的集中点并不意味着SDN控制器就是“孤家寡人”，实际上控制平面仍然需要通过分布式协作机制来实现。

这乍一听起来似乎有些荒唐，不是说SDN要解决分布式的缺点吗？难道这些缺点从转发设备中抽离出来，然后转移到控制平面就不存在了吗？虽然有些不好理解，但是这个问题的答案通常是Yes。这是因为，各个SDN控制器掌握着自己控制的本地网络中所有的实时状态（这些信息是在传统的分布式路由协议中各个设备所无法获得的），大家互通一下有无，每个控制器上就有了全局的网络实时状态。可是，控制器间的分布式协作不可避免地要带来时延，A控制器本地网络的实时状态信息转给B不会产生滞后吗？这个确实没办法从根本上进行避免，但所幸SDN控制器在数量上要比转发设备少1～2个数量级，因此大体上来说控制器间分布式协作所产生的开销，对实时性信息造成的滞后效应，是在可接受的范围之内的。

控制平面的分布式协作机制，根据面向的场景不同，分为以下4种实现形式。在对几种形式进行介绍和讨论之前，需要先澄清笔者对于“SDN东西向协议”这一概念的理解 —— “SDN东西向协议就是运行在异构SDN控制器间的接口协议，用来同步异构SDN控制器中的网络信息”，这里的异构既可以指不同厂家的SDN控制器，也可以指同一厂家不同的SDN控制器。一些容易产生误解的地方在于，有人把同一厂家的定位于不同层次的控制器间的协议理解为“SDN南向协议”，也有人把SDN控制器和传统路由器的通信理解为“SDN东西向协议”。在此做上述概念的澄清，没有哪个对哪个错之分，只是为了方便读者对下面的内容进行理解。

同构控制器的不同实例间运行集群机制，保证SDN的可用性。

异构SDN控制器间运行东西向协议，保证SDN的可扩展性。

SDN和传统网络的兼容与互通，可能需要SDN控制器模拟传统的分布式L2/L3协议。

以上三种场景的任意组合，需根据实际情况结合集群、东西向协议和传统的分布式路由协议对控制平面进行设计。

单域内的集群早就成了业界的共识，各个商用的SDN控制器和OpenDaylight/ONOS两个开源控制器平台都实现了自己的集群机制。集群的问题本质上是软件设计的问题，这个问题不在本节的讨论范围之内，下一节会对此进行详细的介绍。这里值得注意的是，即使已经具备了相当可观的高可用性，由于一些不可控因素，控制器集群仍然可能会出现问题，这就需要为转发设备设置一定的逃生机制，以避免大规模的控制器瘫痪造成的业务转发中断。

跨异构控制器的东西向协议，尤其是跨厂商控制器的东西向协议，对于行业未来的发展是至关重要的。尽管如此，这件事情目前推进得还比较缓慢，因为这里涉及太多的技术风险与利益互博。对于厂商来说，自家SDN控制器的未来都生死未卜，目前很难有动力去推动东西向协议的标准化，顶多是在自家的多个异构控制器间简单地互通一下而已，笔者个人理解这实际落地的可能性不大，更多是厂商为了进行市场推广的而已。IETF和IEEE实际上是厂商在主导的，对SDN需不需要控制器这个事情一直都是闪烁其词，更不会愿意花大力气来推控制器互通的标准。ONF在推广OpenFlow的心力上都不是很充足，暂时也没有看到对东西向协议有任何的想法。总而言之，大家对于东西向协议都是“叫好不叫座”，于是就出现了上面的“三不管”状态。学术界中倒是有一些尝试，或者基于层次化的控制平面设计，或者基于水平对等的模型来设计控制平面，不过这件事情由学术界来做实际的效果肯定不会太好，业界对此类论文还没有任何的实质反应。

可对接多厂商控制器这件事是一定要做的，尤其是对于运营商这种大体量的网络，否则用户还是得绑定在一家厂商的产品上，这和原来的景象并无二致。要做成这件事，实际上还有另外一个思路，就是在各厂商控制器的上面再做一层编排器，由编排器来规范接口，然后各个厂家控制器去做适配。换了个说法之后，这事做起来就要容易多了，厂商只能选择积极跟进，否则只能面临被淘汰的命运。云这块已经有了OpenStack，运营商稍稍落后，不过大家现在也都把这件事想明白了，目前正在积极地推进ONAP的发展。云提供商和运营商自己做编排器还有一个好处，就是可以把控住业务的入口，毕竟自家的业务还是自己最熟络，把业务交给设备厂商去做，一来不合适，二来也很容易受到制约。编排器通常被看作业务平面而非控制平面，但从架构上来看编排器会作为系统最顶层的集中点，至于编排器自身还要不要分级，就看用户自身的实际需要了，这块属于纯IT问题，争议要小得多。

SDN和传统网络的兼容与互通，和南向协议的选择有很大的关系。对于NETCONF/BGP/PCEP这些广义上的SDN，实际上是可以很好地工作在传统网络的框架下的。而OpenFlow网络和传统网络的互通，目前业界仍然在不断地进行着尝试。这是一个比较大的议题，涉及软硬件不同层面的问题，下面的内容只针对于控制平面的设计思路。以一个简单却比较典型的互通场景为例，该场景中SDN和传统网络覆盖着不同地域的设备，只通过边缘的设备进行互联，此时要求SDN控制器能够和传统网络进行分布式信令的交互。如果传统网络在与SDN互联端口上运行的是L2，那么控制平面就需要模拟MAC Learning/VLAN/xSTP/等二层逻辑；如果运行的是L3，那么控制平面上就需要模拟ISIS/OSPF/BGP等三层协议。

具体的技术实现上，主要有两种思路：第一种思路是直接把L2/L3的控制逻辑作为SDN APP运行在控制器上，由控制器直接与传统设备进行传统控制信令（如STP、OSPF、BGP等）的交互，互通SDN域与传统网络的控制信息，然后控制器做一些协议上的转换（类似于传统网络中路由重分布的概念），将传统网络的控制信息通过南向接口下发给SDN域内的转发设备。第二种思路是在控制器外面独立运行一个协议栈（如Quagga、BIRD等），专门负责与传统网络互通路由，然后控制器与协议栈间再互通控制信息，与前一种的区别在于，SDN控制器不再需要实现复杂的路由逻辑，可以通过一些私有的接口（或者简化版的路由逻辑）来访问协议栈的数据库，这种方式可以有效地减轻控制器端的开发压力。两种实现中，都有一个需要注意的问题：控制信令在网络中的通信路径，如果采用In-Band的部署方式，要把负责控制信令转发的OpenFlow流表写好；如果采用Out-of-Band的部署方式，控制器在注入路由时要注意下一跳的问题，防止路由器把流量直接引向控制器。

分布式与集中式，在SDN领域仍然会是一个长期争论的话题。既然没有绝对的好与坏，那么解决问题的精髓就在于平衡。Juniper内部流传着一句很精辟的话，作为上述内容的一个小结，希望能够引发大家更为深入的思考，摆脱对技术的争执，在工程上找到最适合自己的SDN。

“Centralized what you can，distributed what you must.  If something can be centralized, and there are no physical or functional constraints, centralize it; otherwise, it should be left distributed.”