《云数据中心网络与SDN：技术架构与实现》——2.5.5　集群与分布式

2.5.5　集群与分布式

可用性对于任何的商用系统来说都是首要的考虑因素，对于SDN控制器也不例外。通过集群机制来保证同构SDN控制器间的高可用，已经成为业界的共识。集群，就是为一个SDN控制器部署多个实例，让它们彼此之间进行主备或者负载均衡。实现集群有两个关键的技术：一是虚拟IP，让这些不同的实例在逻辑上对业务表现为同一个SDN控制器；二是集群间通信，使得网络数据能够在多实例间进行同步。

虚拟IP主要是通过在多实例间部署负载均衡器来解决，并不属于控制器本身的设计范畴。而集群间通信机制的设计对于控制器来说就至关重要了，对于一个SDN控制器而言，集群的设计最能体现该控制器的商用能力。目前有很多开源的框架可以作为控制器实现集群的基础，来帮助进行选主以及数据的同步。有一些控制器出于定制化的原因，会选择自己来重做集群的架构，这导致不同控制器的集群实际跑起来的效果差别很大，很多号称可以商用的控制器在主节点挂掉时还会出现多主甚至无主的情况。

集群是必要的，但是它的引入会带来另外一些让人头疼的问题。集群中各个实例在物理上是分散开来的，彼此之间数据的同步依赖于底层网络进行通信。相比之下，单机中多个进程间是被框在一个机器内部的，彼此之间是通过IPC机制进行通信的。由于底层网络相比于IPC机制是非常“不靠谱”的：IPC通信的结果一般来说只有成功和失败，而网络通信还会出现“超时”这种让人摸不着头脑的结果，这会对系统的设计造成很多头疼的问题。考虑这么一个例子，A通过网上银行向B转账，不过由于网络环境太差，账户系统发起的几次尝试都失败了，最后提示A请求超时。此时A也不知道钱到底转出去没有，于是只能查自己账户，或给B打电话确认。如果钱还能找着，那么还好；如果转账的金额“跑丢”了，那么就麻烦了。“钱跑丢了”这件事似乎在生活中很难遇到，但实际上银行的系统在处理转账这个请求时，都是经过严格的设计的，稍有不慎就会导致很多麻烦甚至经济纠纷。

上述现象属于分布式事务中普遍存在的数据一致性问题。根据著名的CAP定理，在强制要求系统分区以实现高可用的前提下，所要求的数据一致性越高，在并发性能上付出的代价就会越高。其中的逻辑简单描述如下：要想系统具备高可用性，数据就要复制出多个副本，放到其他节点上进行备份。写入操作如果使得数据发生变化，那么新的数据就需要在各个副本间进行同步。为了保证写过之后在各个副本中读到的都是新的数据，那么在执行同步时写入操作就必须选择等待。

由于分区对于集群来说是必选的，那么就无法兼得良好的数据一致性和业务的高并发。集群要根据自身所承载业务的特征在两者之间进行选择。数据一致性的强度可分为3种，由弱到强分别为Weak、Eventually和Strong。Weak是指当新的数据被成功写入后，读操作可能成功也可能失败。Eventually是指当新的数据被成功写入后，有可能暂时是读不出来的，但过了一段时间之后一定能被读出来。Strong是指新数据一旦成功写入，是一定可以被立即读出来的。Weak对于集群来说通常是不可接受的，一般只在Eventually和Strong间进行选择。Strong在数据一致性上是优于Eventually的，但代价是成功写入数据需要等待的时间较长，集群处理并发性业务的性能会受到影响。相反，如果选择了Eventually，那么集群处理并发性业务的性能会很强，不过其数据一致性就会比较弱，常常会出现写进去了但读错了的情况。

网络在本质上可以看作一个超大的集群。传统网络中，IGP和BGP主要处理的数据是路由表，由于对分区的要求非常高，它们在设计中都选择了Eventually的数据一致性。不过，对于SDN控制器而言，它所要处理的数据不仅仅局限于路由，因此在数据一致性的选择上也不存在必然的倾向，需要根据数据背后的实际业务需求进行数据一致性的选型。对于通用的SDN控制器来说，应该具备为不同的业务提供不同的数据一致性的能力。

为了保证高可用，数据一致性与并发的性能之间只能取折中，而折中的程度与数据副本在集群中的分布密度是相关的。通常数据副本的分布有两种方式：第一种是镜像，即把新写入数据的副本复制到集群所有的节点上；第二种是分片，即副本仅会被复制到一部分节点中。镜像方式下，为了实现Strong级别的一致性，同步需要发生在数据所在的原始与所有其他节点间，性能的损失很大。分片方式下，为实现Strong级别的一致性，同步仅需要发生在数据所在的原始与少数目标节点间，性能的损失很小。不过，这并不意味着分片方式就要好于镜像方式，因为副本数量的减少，不可避免地要损失一部分可用性。

另外，SDN控制器不仅要通过北向接口对业务，对设备一侧还要操作着五花八门的南向协议。不同的南向协议在集群的实现上区别很大，甚至对于同一个协议内部的不同控制信令来说，集群的具体实现机制也需要具体地去考虑。因此，相比于传统IT业务系统的集群而言，SDN控制器集群的实现难度通常会更高一些，甚至现有的一些面向商用的SDN系统在集群上的表现都不尽如人意，甚至在运行集群后性能还会有所下降，这也是目前制约着SDN大规模落地最重要的因素之一。

分布式和集群的区别在于，分布式是将不同的功能分散到不同的节点上去，各个节点彼此之间通过协作来交付业务，而集群中各个节点的数据、功能都是一样的，彼此之间只是做主备或者负载均衡。相比于集群，分布式在节点物理位置的组织上不受任何限制，节点间的逻辑耦合关系也比较松散，能够支持更好的可扩展性和可用性。

SDN控制器是否需要设计为进行分布式系统？就目前来看，集群基本上就可以满足SDN控制器的要求。不过，控制器上的功能未来会越来越丰富，主要包括业务开通、管理配置、实时控制和数据分析这四类，而这四类功能的软件实现架构以及对于服务器硬件性能的要求是很不一样的，彼此之间对通信时延的要求也不高，是可以考虑进行分布式设计的，将不同类别的功能进行分散，然后同一类的功能内部再进行集群。不过，如果做成了分布式的，这意味着控制平面所面临的后期运维问题将和传统的分布式网络面临的是一样的，控制平面一旦出现问题，故障排查将变得非常困难。