《云数据中心网络与SDN：技术架构与实现》——3.1.2　应用感知

3.1.2　应用感知

数据中心的建设是一个大型的系统工程，不考虑电力制冷以及人力上的开销，以每机架为单元，ToR的成本大概只能占到5%～8%，服务器的成本占比大约在25%～35%，而在软件方面所投入的成本，包括操作系统、虚拟化、应用以及管理软件，大概可以占据70%甚至更多。因此，与在电信运营商中的基础性地位不同，网络在数据中心内部应该被定位于业务与应用的辅助，如果让应用围着网络来转，显然就是本末倒置了。

虽然数据中心和电信运营商在网络设备厂商中通常是两条独立的产品线，不过数据中心网络架构的设计至今仍然没有摆脱“以网络为中心”的思路，虽然SDN为网络提供了可编程的能力，但就目前来看，SDN的API基本上都是为了业务的自动化而设计的，应用仍然只能Over the Top。大数据、人工智能等新型应用架构的逐步普及，对未来的数据中心网络将提出更高的要求，网络需要能够为这些应用保障一些严苛的SLA需求，如传输带宽、端到端时延和传输抖动，等等。因此，网络必须重新思考未来在数据中心的定位，SDN需要能够更为深刻地理解应用、更为细致地感知应用以及更为灵活地适应应用，使得应用真正能够实现“play with the network”，而非“play around the network”。

下面以Hadoop为例，看一看SDN为其能够为大数据提供哪些价值。Hadoop的架构是Multi-Stage的，先把数据分布式地存下来，一个Compute Job提出后会被拆分为多个Compute Task并分配给不同的节点，每个节点在本地完成一小部分Task的计算，最后将这些Task的计算结果汇总在一起，作为Job的最终结果进行返回。在Hadoop集群的实现中，分为Client、NameNode、DataNode、JobTracker和TaskTracker五种主要的角色，主要的工作流如下。

1）数据读取进来之后，Client将其分解为不同的Block，然后向NameNode发出请求以获得Block的存储位置。

2）NameNode为每个Block返回一组DataNode，并对此进行记录。

3）Client根据NameNode的返回结果，将Block写入相应的DataNode。

4）当Job被提出后，Client将Job通知给JobTracker，JobTracker会从NameNode处获取存储了相关Block的DataNode。

5）JobTrack将Job拆分为不同的Task（可分为MapTask和ReduceTask），将其发布给不同的TaskTracker进行执行，并对此进行记录。

6）MapTask对本地的数据进行处理，处理完成后将结果存在本地。

7）ReduceTask从JobTracker询问MapTask的执行状态，从已完成的MapTask所在的节点拉取Map的结果。

8）当所有的MapTask都完成后，ReduceTask得到所有的Map结果，并将它们合并为最终结果。

9）此时JobTracker将Job状态置为成功，Client读取最终结果。

以网络的视角来看上述过程：①将数据写入DataNode的过程需要高带宽；②NameNode、JobTracker和其他角色间交互的控制信令需要低时延；③Mapper和Reducer的数量通常是M∶N的（M>N），在Shuffle的过程中，可能会出现大量Many-to-Few的流量，需要能够处理TCP Incast的问题；④只有在所有Task都处理结束后Job才会完成，需要尽可能地缩短Reducer和Mapper间Shuffle流量的传输时间；⑤集群会同时通过处理多个Task/Job，网络中会存在大量的Mice Flow，需要能够处理MicroBurst的问题；⑥为了实现高可用，DataNode间会进行数据的备份，需要放置这种次要流量抢占上述工作流中流量的带宽。

针对上述过程进行优化，整体的目标是降低Job的Completion Time，网络需要能够将大数据流量与其他应用的流量区分开，并识别出大数据的不同流量，保障高带宽型和低延时型流量的QoS，降低次要流量的优先级。SDN控制器需要：

1）将上述理解嵌入到控制算法中；

2）与Hadoop建立接口，获取到集群中不同角色的位置分布信息；

3）获取网络的实时状态，如物理拓扑、链路带宽、拥塞率，等等。通过将角色的分布信息和网络实时状态输入到算法中，计算出优化后的路径并下发到网络当中，或者对当前路径中大数据流量的QoS进行保障。

解决Incast和MicroBurst的问题，只能从流量的源头来想办法，这需要Hadoop自身能够根据网络的状态去优化Block和Task的分布。因此，SDN控制器不仅需要从Hadoop处获得信息，也需要将网络的实时状态提供给Hadoop，比如Server-to-Server流量统计、Rack-to-Rack流量统计、拥塞发生点、端到端时延等，使得JobTracker和NameNode在进行调度时能够结合网络的实际状态来优化Block和Task的分布，优化Job Completion Time。

可以看到的是，针对应用来进行网络优化并不是一件很好做的事，因为不同应用的架构、流量模式和通信需求都不一样，目前仍然只能是case by case地去考虑。关于大数据优化的更多介绍，可以参考本书9.10节中的内容。另一个常见的场景是VDI，可以通过SDN来监测/防止启动风暴，以及保证IP Storage的传输带宽，来优化虚拟桌面的QoE。

不过，通过对流量进行采集，再结合大数据和机器学习等技术，便能分析出应用的行为模式。将这些行为模式告知SDN控制器，SDN控制器即可采取有效的优化措施，从而实现网络对于应用的动态感知与自适应。这种与其他工程领域间的交互能力，完全得益于SDN为网络所带来的开放性，是传统网络所不可能具备的。

另外，抛开以上的技术原因，SDN适合在云数据中心落地的基础还得益于数据中心网络的以下特征：

静态，网络拓扑和地址规划较为固定；

统一，设备类型相对单一，网络管理权限较为集中；

独立，通常不会用于传输过路流量，发生故障不会影响外部网络；

负担轻，设备和链路成本较低，数据中心新建时无需考虑存量设备。

经过多年的实践，目前业界已经广泛地认可了SDN对于云数据中心竞争力的提升，云数据中心已经成为SDN落地的主战场。因此，云数据中心的管理者们没有必要再怀疑SDN是否具有价值，而应该考虑的是如何量体裁衣，使SDN更为有效地为自身的业务和运维提供价值。