中南民族大学原有核心网络于2014年按照双活特性改造完成，核心交换机分布在校内相距1KM的两座数据中心机房，以vrrp和port-channel协议在逻辑上构成一个整体，上行至运营商的互联网出口，下行至各个楼宇的汇聚交换均双万兆链路以动态LACP连接到两座机房的核心交换机，也就是说的对端设备都“认为”核心交换是一台设备，以期在核心拓扑中出现任意单点、单链路故障，甚至单机房停止，都能在用户无感知下连续运行，继而在工作时间从容的处理突发的问题。

图1 原有双活核心校园网拓扑

　　在图1这个拓扑中，防火墙是整个拓扑的“中枢”，上端是校园网与互联网的边界，下端连接数据中心与网络中心两个核心区域。核心交换以下保持汇聚、接入的三层网络结构 ，用户以DHCP获取仅限校内访问的IPv4地址后，通过L2TP校园网认证获取IPv4/IPv6地址，即通过BRAS整合有线、无线为一张网双栈准出到互联网，继而实现校内和互联网均同一入口接入校园网。正如“月有阴晴圆缺”，双活核心拓扑解决了连续可用性并适用于学校应用和运维的同时，也带来了伸缩性等问题。

　　一、新兴的SDN技术实践

　　1.暂时割舍一些特性

　　我们对SDN规划方案寄予的厚望，一方面来源于对技术了解的不够深入，另一方面也来源于对产品的过于乐观，在收到样机后的开展的模拟测试结果不得不割舍几个特性。

　　（1）无法进行堆叠

　　一般来说，堆叠主要解决交换机数量扩充和逻辑上一台设备的整体性，而所用样机的产品定位，主要是超融合、边缘接入和小规模私有云，现有接口已经是48*10G+6*100G的高密度，可以满足大多数场景需求，虽然可以设计100G业务口实现堆叠，但目前主流云数据中心采用的leaf-spine结构天然解决了端口扩展和整体性的问题，在高密度的场景中，堆叠也容易成为性能瓶颈，故而并未设计堆叠。从OpenFLOW的角度来看，交换机都只是转发资源，多台交换机的管理复杂度也是控制器层面所承担的。

　　由于堆叠特性的缺失，两台SDN交换机在两个机房也就成了两个孤立的设备，因为控制器软件的成熟度还远不如SDN交换机硬件，这对网络的逻辑结构产生了影响，相应的双活、容灾的策略和机制也要随之调整。

　　（2）不支持802.3ad

　　IEEE 802.3ad是执行链路聚合的标准协议，在普通交换机里非常普遍，然而样机并不支持，这一方面影响双核心交换双链路上行接入，更不用说运营商双链路基于堆叠跨机房的接入，这一特性的缺失意味着必须有过渡和折衷的方案。

　　（3）不记录会话状态

　　正如普通交换机对流量的处置是有进有出，既不做NAT也不记录会话状态，纯OpenFLOW交换机也不做会话状态的处理，因为这是属于控制器的分工，纯OpenFLOW交换机也不支持会话状态的处理，而控制器若要实现会话状态的管控，则需要付出巨大的性能开销，以及控制器结合交换机的定制开发。

　　2.分步骤实施

　　正如双活网络的部署期望有故障发生时能在白天更从容的处置，从原有网络到SDN的割接也尽力做到用户的无感知。

　　（1）双活到单活

　　第一阶段的准备工作是将原有网络的关键配置进行梳理，重点是理清各种情况下的流量走向，并将双活置为单机房运行的单活模式，以便在另一个机房将SDN上线前所需的准备做好，特别是SDN一端新接防火墙涉及原有防护策略迁移和一些辅助功能的停用。

　　（2）单SDN割接

　　当另一个机房的SDN物理连接和流表等配置准备就绪，割接动作实质是在原单活的上下联设备将路由改到SDN一端，修改路由的时间仅仅数秒，割接的时间可以选择在线人数较少的周末，这样也能立即观察到用户访问和数据中心等其它区域是否存在问题，便于快速处理和回退。单SDN运行既可能存在单点故障，也存在SDN交换机和控制器成熟度带来的潜在问题，因此这一过渡的单活阶段在改造期间存在的时间需要尽可能缩短。

　　（3）按需导流

　　单SDN割接成功，形式上看起来旁路的防火墙已经属于将指定流量导入的服务链模式，防火墙在逻辑上仍是串接在网络中。接下来再选取指定的流量用于镜像分析、缓存加速以及串接测试设备则变得轻松简单。按需考验着SDN对网络可扩展性的能力是否达到了想象中的灵活。

　　（4）主备机制

　　将不同网络区域相互之间的访问进行组合，指定每一种互访的组合主从分别通过哪一台SDN交换机，“主”表明的是默认走向，“从”发生在检测到“主”发生情况就切换。

　　检测机制运行在控制器上，受限于控制器APP开发的深度，目前仅能以端口状态的up/down作为判断条件实现切换的触发，若能进一步参考路由可达性、负载、服务可用性等多维度因素实现智能化的分析与自动切换才是更为理想的落地。

　　（5）持续迭代

　　改造进行到此并不是结束，在生产网络中实测了仍在演进中的技术并不能简单用行或不行来说SDN，在现有组网中，流量可视化分析是相比改造前最容易实现管理创新的发力点，同时，安全运维所强调的监控、日志、自动化运维等议题也有了更进一步探索的空间。

　　3.刷新经验

　　在生产网络上做如此大的调整动作，没有现成的经验可取，虽然做了一定的“充分准备”，总还有很多新的“没想到”在等着。

　　（1）当前的控制器采用物理服务器承载，并未关联和开发太多的APP应用，主体是OpenDayLight开源的框架和接口，因此对服务器的性能要求并不高，但服务器的稳定性还是需要保障的；

　　（2）SDN交换机带外管理承载与控制器的连接，比一般带外管理更为重要，该接口不管是与控制器直连，还是连接同一个交换机，都难免发生控制器与交换机失联的情况，因此在SDN交换机选型时，要特别注意“失联”后的流表保持以及重启后的流表保持，能够减少意外情况下的SDN的“大脑空白”导致的全网中断；

　　（3）SDN交换机与各网络区域互联，OpenFLOW接口并不具备配置IP地址特性，类似互联地址的配置，需要在SDN交换机与对端交换机以绑定MAC地址的方式，实现二层的互通，这在改造之初是完全没想到的；

　　（4）习惯了子网掩码和静态路由的配置命令，校内IP路由的条目虽多，也从未感觉繁琐，但在OpenFLOW流表作为路由的替换下，需要人为计算转发的优先级，是个费神又容易出错的环节。

　　二、一些思考

　　SDN的实际部署进度比最初的计划推迟了很久，这在很大程度上是因为控制器在扩展性、API接口等方面的特性与实际的需求还存在较大的滞后。除此之外，改造后的物理拓扑会看到所有设备和区域都是相连接的，如果目标网络要求隔离，虽然逻辑上会比传统网络断开的更为彻底，但与某些安全制度要求还是存在抵触的，也需要在规划中有所割舍，但仅仅是以“超级汇聚”的方式部署，就足以看到SDN诸多令人心悦的改进和提升，也让我们对未来的发展充满想象。

　　1.运维和开发的相辅相成

　　近些年来，越来越的运维场景与程序开发的联系越来越紧密，运维人员已不仅要擅于操作每一个工具，也要掌握和精通几个编程语言来提高运维效率，SDN的改造实施和持续运维也离不开开发的支持。

　　2.SDN开发不是做控制器

　　传统交换机的控制器是按照大家都默认一致的既定规则和方式进行转发，SDN开放的是对控制器进行自定义的能力，一方面是对设备全局流量的掌控，另一方面则是通过接口进行能力输出。因此，SDN的应用开发并不等同于控制器开发，单纯做控制器已经在传统交换机中做到相当成熟了，图2为SDN应用开发示意图。

图2 SDN应用开发示意

　　控制器为APP提供相关的流量、状态、计数等必要的信息，APP不仅从日志系统、监控系统、流量分析系统等获取运行信息，还可以从防火墙、WAF、IPS等安全设备获取信息，APP综合各方面的数据和状态可以创造很多新的联动场景，实现很多过去无法想象或实现的能力，APP在其中就是智慧的“基因”，对控制器下发相应功能的流表，按需实现攻击防护、故障转移、流量优化的功能，既APP的开发即围绕网络又超然于网络。

　　3.基于SDN的数据中心

　　SDN的概念出现至今，实际应用和讨论最多的是SDWAN和SDDC两大场景。SDWAN逐渐在大型企业的分支网络中生根落地，高校的网络规模和业务复杂度远不及企业应用场景，SDWAN应用鲜有提及。SDDC在高校应用场景的关注度和熟悉度要远高于SDWAN，这其中不乏一些商业产品的推波助澜，即使高校数据中心的应用规模有限，叶脊(leaf-spine)网络架构已经越来越多的得到认可，图3为Leaf-Spine架构示意图。

图3 叶脊结构示意图

　　leaf-spine二层结构相比传统三层架构，在SDN加持下的优势也更为明显，主要表现在：（1）节省资源，leaf-spine拓扑只有二层结构，数据中心部署需要的交换机相应减少；

　　（2）降低延迟，每一个leaf节点和另一个leaf之间少则一跳，多则两跳，越是规模大的组网结构，减少延迟和等待的效果越明显；（3）多链路传输，leaf与spine有多条链路，spine越多，leaf可用路径越多，这对改善数据中心东西向传输是非常显著的。

　　SDN的发展不是一蹴而就的，在技术迭代眨眼翻篇的IT时代，在现网用起来了才是最终的评判标准。有人消极的说SDN已经死了，但我们相信SDN作为一个概念不会消亡，SDN在提高网络元素可编程性，和降低对专用硬件依赖性的方面，会成为我们现在看不见的未来。

　　（作者：高杰欣 张淼，单位为中南民族大学现代教育技术中心）

点图进专题>>2019高校信息化创新实践方案展示