《云数据中心网络与SDN：技术架构与实现》——2.4　集中式控制——与分布式的哲学之争

2.4　集中式控制——与分布式的哲学之争

转控分离与可编程都体现了SDN对于网络开放的愿景。除此之外，SDN还有一个衍生的特征是集中式控制，这两个特征的提出可以说都是对传统网络的深刻变革。对于开放性来说，技术实现上不是什么问题，但出于商业利益的考虑，对于究竟应该开放到什么程度的讨论往往是各执一词。而对于集中式控制，大家都承认这在特定的场景下是有商业价值的，但到底该如何实现集中式控制，它在技术上带来的新问题该如何解决，一时间也难于形成统一的业界标准。因此在笔者看来，SDN开放性的痛处在于重构行业的利益分配，而集中式的纠结则在于与分布式长久不衰的哲学之争。

集中式与分布式之争，其实是一个广泛而深刻的命题，小到家庭公司大到社会国家，每个文明系统的组织机制都会面临着在二者之间的抉择，管制带来的是效率与统一，而民主意味的是公平与稳定。管制与民主之间永远存在着博弈，最终势必会趋向于在系统的不同层面上形成不同的组织机制。

作为人类文明中数一数二的大型系统，通信网络的组织机制自然也摆脱不了集中式与分布式之间的争端。Internet的原型是ARPANET，ARPANET最初是美国国防部为军事战争设计的网络，考虑到军网对高可抗毁性的要求，因此基于分组无连接和分布式控制的IP得以发展。随着民用通信网络需求的出现，ARPANET演进为早期的Internet，IP同时要为Internet提供良好的可扩展性，因此IP延伸了分布式控制的思想，以OSPF和BGP为代表的路由协议进一步奠定了分布式控制在传统网络中的基础性地位。尽管如此，历史上实际上并不缺乏对于集中式的尝试，这不仅存在于学术界，比如ATM LANE中使用集中的服务器来做ARP解析以仿真Ethernet，PSTN的七号信令则通过专用的带外控制平面来建立、拆除电路连接，即使是在IP网络中，还是能够看到集中式的一些影子，比如BGP RR和OSPF DR/BDR通过在设备中选举特殊的角色来扮演局部网络中的集中控制点，比如SNMP通过对设备资源模型进行标准化以便在远端进行集中式管理，比如WLAN AC能够在带外对瘦AP的转发进行集中控制，等等。不过这些集中式技术，或者只是为了辅助分布式控制技术，或者只是为了简化网络管理，或者受限于场景和规模，都没有对分布式控制技术的地位产生本质上的影响。

随着互联网应用的爆炸式发展，连通性变成网络最基本的能力，人们开始转而关注网络连接的质量与灵活性，此时分布式控制无法感知网络状态，管理配置复杂的缺点开始显现出来。而集中式恰恰善于解决上述问题，但苦于难以找到合适的替代技术，因此只能采用打补丁的思路来对现网进行改良。在SDN被提出后，人们终于看到了使用集中式代替分布式的理论基础，学术界吹响了使用OpenFlow彻底代替传统网络的号角，创业界似乎普遍找到了“撬动地球的杠杆”，媒体也开始大规模为SDN造势。

然而，理想与现实之间总是存在着巨大的鸿沟。相比于复杂臃肿的传统网络，基于OpenFlow的网络设计确实是简单而且灵活的，非常适合用于小规模网络中的创新。但是由于集中式可扩展性差的老大难问题，另外考虑到传统网络的巨大存量无法直接废弃，因此业界的脚步远远没有跟上学术界吹响的“网络革命”号角，如何基于传统网络向SDN进行逐步的演进则成了业界更为务实的发展战略。

抛开复杂的市场因素，单纯地从技术角度来看，分布式控制带来的好处是稳定和可扩展，缺点是没有办法做到全局最优，相反集中式控制的优点是擅长全局的调度，不足之处在其可扩展性较差。因此，简单地评判二者孰优孰劣是有失偏颇的，客观性上必须要承认二者是互补的。综合考虑，一个好的SDN设计既需要高效率、易管理，又需要稳定和可扩展，这要求兼顾如下两个基础性原则（后续会分别详细讲解）。

1）控制与转发通道相分离，形成逻辑上的集中点，它掌握实时的网络全局视图，能够进行业务的自动部署以及网络的动态调优，并提供整网的单一管理入口。

2）需要为逻辑的集中点引入分布式协作能力，以提高SDN网络的可扩展性与可用性，并支持与传统网络的兼容与互通。

2.4.1　在功能上找到平衡点

先来说第1个基础性原则。

首先，“控制与转发通道相分离，形成逻辑上的集中点”，听起来简单但实际上是有很大的学问的，实际到了工程实现中会遇到很多问题，其中很多问题的答案至少目前还都是需要画问号的。传统的网络设备中控制和转发就是分离的，不过控制逻辑仍然分布在设备的盒子里。那么，要形成SDN的逻辑集中点，是不是一定要将控制功能从各个设备里拖出来？BGP RR和OSPF DR/BDR都是局部网络的集中控制点，但它们都是放在设备的盒子里的，如果开放了BGP RR和OSPF DR的控制权，这算不算是SDN？

其次，如果只拖出来管理功能，转发的控制能力仍然保留在设备盒子里，这算不算SDN？如果管理和控制功能都被拖出来，它们一定要放在一个物理实体中吗？管理功能都适合拖出来吗？比如OAM和LLDP。控制功能都适合拖出来吗？比如ARP/LACP和快速重路由。如果控制功能要拖出来，一定要拖FIB的控制出来吗？把RIB的控制拖出来算不算SDN？把逻辑从设备的盒子里拖出来后，逻辑的集中点怎么部署在网络里？带内，还是带外？如果把转发逻辑拖出来了，而且又要采用带内的部署方式，控制信令本身的转发怎么控制？

要回答上面的问题很不容易，因为不同的场景和需求决定着最终的设计。不过总的来说，还是有以下几点基本的参考原则的。

管理和控制功能可以放在一起实现，也可以分开实现，具体要看实际的研发能力和存量网络的状态。

控制信道的能力可能有必要进一步进行切割，一些交互密度高、时延敏感的能力是应该保留在设备中的，比如BFD和FRR。

大部分情况下，不要企图用控制信道来承载的业务流量的传输。

尽量使用预下发（Proactive）的方式进行控制，不得已使用触发式（Reactive）的控制方式时要考虑抑制控制信令风暴以及其他形式的控制器DDOS。

采用带内的部署方式时，要防止出现先有鸡还是先有蛋的问题。

最后，算不算是SDN的问题不在于集中式控制如何实现，因为它不是SDN最为本质的特征，只要是为网络开放出了某一层次的编程接口，都算是广义上的SDN。

从本书的后续章节可以看到，很多SDDCN的实现，尤其是OpenStack Neutron中的众多解决方案，它们将策略逻辑独立进行了逻辑上的集中式存储，而SDN的控制逻辑仍然被分散到了各个设备本地。其具体的实现放到后面再细谈，在这里先提出来只是为了说明：不同技术背景的团队所实现的SDN千差万别，千万不要狭隘地为技术扣帽子。

另外，“掌握实时的网络全局视图，能够进行业务的自动部署以及网络的动态调优”。网络全局视图的实时搜集是SDN最重要的支撑性技术之一，搜集的信息主要包括转发设备拓扑、终端的位置与网络参数、转发设备的资源状态，转发设备统计信息、流量统计信息等，搜集的手段多种多样，比如通过设计新的协议（如OpenFlow），或者直接通过现有的协议（如SNMP/sFlow/NetFlow），或者对现有协议进行扩展（如NETCONF、BGP-LS），也可以从专用的网管软件中获取处理后的数据。根据实时的网络全局视图，结合业务的需求，SDN控制器可以自动地部署业务，并能够动态地对网络进行调优，业务的部署主要是提供可靠的连接性和一致的策略，动态调优主要就是对网络路径进行重新规划，实现的方式同样多种多样（如OpenFlow/NETCONF/PCEP/BGP），不同的方式各有所长，读者可以回头再看看2.3节中的内容。

“提供整网的单一管理入口”，这一点技术上没有什么争议，但是要注意这个入口在不同场景中可能是不同的，这取决于用户的习惯。比如，各个网络厂商的SDN控制器都会提供自己的GUI/CLI，虽然适用于各个场景的网络管理，但是一旦对接了OpenStack，这个入口就会变成Horizon，毕竟人家才是云的Portal。当然，这也是从一般意义上来说的。对于一些大规模的网络，其网络运维方面的分工非常细致，那么将管理功能可以进一步进行分割，并为不同的分割单独不同的管理入口。