《云数据中心网络与SDN：技术架构与实现》——2.5　回归软件本源——从N到D再到S

2.5　回归软件本源——从N到D再到S

说到SDN，人们最常联想到的有这么几个词，OpenFlow、数据中心虚拟化、广域网优化。从最开始的喊口号到前几年讨论场景，目前SDN已经开始真正地沉淀技术，商业上也进入了加速落地的阶段。或者也可以这么说，SDN近十年的发展逐步经历了从理解网络需求（Networking）到完善南向协议（Defined），再到打造健壮系统（Software）的过程。

在SDN的框架下，或者说在软件的世界里，实现大部分现有的网络功能都不会是一件太复杂的事情。抛开分布式协议的枷锁后，网络的创新再也不用等IEEE/IETF这些标准组织慢吞吞地输出文档了，用户对网络的需求会普遍转向个性化的定制和敏捷的交付，是时候从厂商主导的传统网络思维转向为用户按需提供网络服务的云计算思维了。

控制器是SDN向用户交付的主要产品，既然控制器在网络功能的实现方面足够灵活，那么SDN控制器的扩展性、可用性与性能往往会超越接口协议和网络业务本身，成为决定SDN能否商用的核心因素。因此，如何构建起一套可扩展、高可用的SDN控制器，才是推动SDN真正走向大规模落地的关键。

2.5.1　模块管理

长久以来，垂直一体化的行业特性使得网络技术的集合变得无比庞杂。虽然有标准协议的规范，但是各大厂商的产品之间，甚至同一厂商不同的产品线之间的设计区别都很大，跨厂商难于互通一直是用户的一块心病，这也导致了更为显著的厂商锁定现象。SDN除了能够提升业务敏捷度以外，用户同时还希望SDN能够帮助他们摆脱对于厂商的依赖，从而在谈判桌上拿到更多的话语权。除了肩负着驱动异构网络设备的重任以外，SDN控制器还要承载各式各样的网络基础服务的运行。因此，SDN控制器的目标应定位于在网络基础服务和设备驱动间构建起一个可扩展的、通用的网络控制平台。

早期的一些轻量级的开源SDN控制器，如Floodlight、POX和RYU等，用户都需要在启动前把需要加载的模块在配置文件中事先指定好，或者在启动的命令行中指定模块。在控制器运行过程中，如果希望启动另外一个模块，需要把控制器关掉后修改配置文件重启，或者在启动命令行中指定新的参数。而且加入一个服务出错了，那么整个控制器也就挂掉了。

上述问题在生产环境中显然是不可接受的，因此OpenDaylight和ONOS在设计之初都采用了OSGi（面向Java的动态模型系统）的框架。在这类框架下，SDN控制器中只保留少数的用于平台管理的核心模块，而将各种网络基础服务和设备驱动看作可插拔的外围模块，这些模块可以动态地加载/卸载到SDN控制器的核心中，各个模块间能够实现良好的隔离。这样的好处在于，新的SDN服务的部署、测试或者上线，并不需要对控制器进行停机升级，以保证现有服务的可用性。如果新的SDN服务的运行出现了问题，通常也不会影响到其他现有服务的工作。相比于Java在企业级应用框架方面不可比拟的优势，C/C++/Python在SDN控制器领域都暂时落在了下风。