我是供职于某中型互联网公司的一名网络架构师，作为工作近十年的网络架构师，近年来明显感觉到网络变革在不断加速。

言归正传，最近本人在工作上遇到点麻烦，主要是公司最近业务量上升非常快，这给我们部门带来的直接影响就是，很多业务部门人员向我们抱怨目前业务系统在使用中没有以前给力，对业务的处理明显慢了下来，另外，还反应网络质量也不好，在外面给客户演示系统明显不流畅，让他们在客户面前非常尴尬等等。

另外，我们部门负责维护的同事也在抱怨，说工作量越来越大，业务部门天天打电话投诉，有的反应系统卡顿、反应慢，还有的说APP出现白屏，甚至还有的直接说系统崩溃无法使用，搞的我们天天都在解决这些琐碎的问题，根本没有时间去对系统进行分析、优化和升级。

就在上周我们公司一个部门要做一次促销活动，需要临时上线一款应用，大家知道，一般对于这种业务，我们都是通过把原有业务系统中的一些功能分离出来，其实这项工作并不像想象中的那么轻松，但是业务部门很着急，说要在下周就上线，所以没办法，我们整个IT部门几乎是一周都在熬夜干这个事情，最后才勉强在上线前一天完成对系统的调整，其中的苦楚相信各位同行都深有体会吧。

好了，今天先吐槽到这吧~

编辑点评在目前企业IT系统中所暴露出来的系统响应慢，网络延时加大，系统不稳定等问题给业务人员带来很多不便。同时，系统难以隔离及管理，安全隐患逐渐增加，以及来自业务部门需求量的增加和对处理效率越来越严苛的要求，都给IT运维人员带来了更大的压力与挑战。

对于目前公司中IT系统所暴露出来的各种问题，作为网络架构师，我也不得不对这些问题进行一次比较系统性的梳理和分析，通过分析我从中发现了几个大的问题来源：
  ●  公司业务都处在同一张网络中，导致IT系统越来越庞杂，系统稳定性和安全性均越来越低。
  ●  在现有网络的扩展性不足，当大量业务上线后系统难堪重负，出现处理延时增加等不良现象。
  ●  现有网络的灵活性不能满足目前企业业务的发展需要，面对业务频繁上下线，对IT系统资源的利用率大打折扣。
  ●  对运维人员的维护压力越来越大，以往利用传统VLAN方式对业务系统进行隔离，无论从规模和效率上都很难适应当前业务快速发展的需要，而且一旦出现BUG，其稳定性和安全性很难保障。
  ●  目前网络的可视化程度不高，对很多流量难以实现更为精细的监控和管理，导致整个IT系统的可维护性不高，在追溯问题时往往花费大量人力物力，得不偿失。

编辑点评通过该架构师对其所处企业IT系统中所存问题的梳理和分析，我们不难发现，在其网络中主要存在有网络隔离不彻底，可扩展性差，网络灵活性低，可视化程度不足，网络运维管理效率低下等弊端，最终导致企业IT系统不能很好的支撑业务快速增长的需求。

经过之前我对系统问题的梳理，已经基本弄清系统中存在的几大问题。从这些问题带来的后果看，我们必须要对现有网络进行一次改造升级，才能满足未来几年公司业务发展的需求。但我们并不想推倒重来，而是想尽量结合当前相对比较成熟的商业化技术和方案结合，对我们现有IT架构进行一次比较大的升级改造。

因此，我们基于这样一种思路，经过整个团队数周的多方考察及调研，并与多个同行进行交流获知，目前市场中的SDN相关技术及方案比较契合我们企业对系统的要求。同时，我把对设备选型的基本要求罗列一下：

  ●  要能完美的解决网络隔离的问题。
  ●  要能够整体提高系统的灵活性和可扩展性。
  ●  在安全性和可维护方面要能够提供更高效率。
  ●  我们需要这类设备和方案必须具备定制化功能，能够给我们提供一定的二次开发空间，并且在售后的技术支持方面要比较到位。
  ●  我们还考虑该方案要有比较成熟的配套软件，方便日后我们对整个网络进行运维管理。
  ●  最后就是老生常谈的成本问题，因为我们的定位是升级改造，老板不想一次拿出太多预算，希望是一个循序渐进的过程来逐步对系统进行升级。

因此，我们将会结合以上这些诉求对当前市场中的SDN相关产品和解决方案进行一次基本的选型工作。（感谢大家的关注，敬请期待我的后续分享~）

编辑点评针对目前所处企业在对IT架构选型时的具体诉求，我们发现企业在对IT相关方案进行前期选型时，整体必须以企业目前及未来业务发展需要为基本出发点，目的是寻求一款真正适合企业自身业务发展的产品及解决方案。同时，我们认为企业并不需要把目光局限在某一家商业产品及方案上。而通过我们的观察发现，在很多情况下，企业应当选择一款后期技术支持及二次开发能力相对比较完善的产品及解决方案，以便更好地支撑未来的企业业务的运营及维护。

一个月前大家看到我们网络团队的苦恼，SDN是我们寻求的解决方案。其实不瞒大家说，两年前我们公司就构建了私有云平台，它是基于OpenStack构建的。所以，对于SDN也并非是"零"应用，云平台的上线让资源管理更加灵活。OpenStack的Neutron方案因其开放、灵活、层次模块化的架构设计，也让我们对于SDN有了多多少少的应用。例如通过引入OVS，降低了使用成本、提升了网络灵活性。
但是这种原生SDN方案仍然存在诸多不足：
  ●  Neutron想要独立抽象出一套一统江湖的高阶数据模型，在不同厂商对接上存在很多的技术间隙
  ●  Neutron提供的API相对原子级，缺乏对网络资源的统一灵活编排，现实应用需要对VPC相关资源进行编排管理
  ●  Neutron缺乏分级的网络资源管理能力以及对网络设备、Provider的管理，从而失去更好的调度分配能力
  ●  在业务特性上Neutron也跟企业应用存在定制化差异，比如企业的IPAM、对接CMDB、容量管理、运维监控等
  ●  ……
诸多的弊端，让我们不得不进行二次开发及自研，并引入商业SDN解决方案。

点评即使有开源方案，大多也只能是简单的SDN应用，想要契合自身业务，必不可少要进行二次开发，并且还要建立在有人才支撑的前提下，否则只有引入商业方案。

其实要搭建一套数据中心网络，首先是SDN的网络管理和控制平台，它是SDN的灵魂。对比市场上开源的方案如OpenDaylight、ONOS等，还是商业SDN控制器？我们最终选择基于OpenStack的Neutron二次开发，一是云平台建设之初有应用和开发的基础，二是因为目前网络中存在不少异构网络设备，开源兼容性强，而没有选择商用方案可能涉及到的兼容性挑战。

其次是Fabric层面，对于目前在运行的三个数据中心，我们不可能进行大规模改造，因为那样成本太高。所以在现有的物理网络架构上叠加虚拟的逻辑网络而不需要修改底层网络架构自然成为我们的选择，也就是Overlay方案。其实总结业界数据中心SDN方案从实现方式上可以分为两大类：基于软件Overlay方案、基于硬件Overlay方案，这里重点说一下我们的选型思考：

1、基于软件的Overlay方案：VxLan的卸载封装在KVM、VMware的主机OVS上实现，控制平面采用的是OpenFlow与SDN Controller对接，通过按需下发流表来完成报文的封装和转发。主要代表有VMware的NSX及同类商用解决方案、基于开源实现的一些方案。

  ●  优势：
      ○ 将网络延伸到了主机上，易于做更精细的网络管理、控制，如对VM的限速、基于VM的流量镜像、通过流表实现服务链功能；
      ○ 更精细、敏感的VM网络监控，更快速感知vport的Up/Down、迁移；
      ○ 网络功能的易于迭代，版本升级快捷影响面小，不依赖厂商网络硬件设备的版本升级。

  ●  劣势：
      ○ 基于OpenFlow+SDN Controller流表转发，不符合传统网工对网络的认识，接受度较低；
      ○ 集中式的控制平面SDN Controller还需要成熟的逃生方案，定位问题时主机、网络侧有交集，界面不够清晰；
      ○ OVS会占用部分计算资源。

2、基于硬件的Overlay方案：VxLan的卸载封装由TOR交换机实现，控制平面上也有自学习、OpenFlow、EVPN多种方式，现在比较火的是EVPN方案。整个控制平面还是由交换机通过路由协议来学习路由、MAC表项，SDN Controller更多承担业务编排配置下发的作用。主要代表是思科的ACI。

  ●  优势：
      ○ 采用分布式的控制平面，由网络设备通过扩展BGP来实现Overlay网络的路由、MAC信息的传递，易于被网工接受；
      ○ 对于主机托管、提供物理机服务有天然的优势；
      ○ 网络、主机分工界面清晰。

  ●  劣势：
      ○ 功能迭代依赖厂商软件版本，硬件交换机版本的升级周期较长，升级时需要考虑对业务中断的影响（需要完全支持ISSU升级）；
      ○ 分布式网关的转发模式对TOR交换机的表项规格是一个挑战。

其实这两种SDN路线业界也并无标准定式，基于自身业务和租户类型的考虑，目前我们主要采用了基于软件的Overlay方案。在跟同行的交流中，其实有不少企业采用此类方案。例如某运营商的云，这种方案可以随意在任意一个资源服务器中部署网元，增加、减少网元几乎零成本。

当然也有采用基于网络硬件的SDN解决方案，例如某游戏的企业，他们构建的SDN方案中，VPC、子网、路由、云网关都采用硬件实现。这种方式释放了部分计算资源，保证了系统性能。

再次，从长远来看，我们也希望利用SDN构建一系列如网络、安全等服务能力的资源池，这其中利用的是SDN管控和资源调度能力，进而给租户提供业务链产品服务。

点评SDN市场正处于快速成长中，方案与路线并无标准和定式，不同企业的选择也是基于自身业务、环境、人才的考虑，一定程度上SDN厂商和企业也在摸索中对SDN方案不断完善。

目前，我们公司开发了SDN的网络控制平台，它是公司私有云所有网络服务的入口，提供的网络服务包括Fabric服务、NF（网络功能）服务、增值服务三大部分。在SDN、VxLan技术的探索、生产实践方面，目前构建了采用OpenFlow+SDN Controller技术的软件Overlay网络，并将OVS+iptables结合起来实现DFW功能（东西向的访问控制），进而实现VPC内不同网络区域同样需要严格安全访问控制的要求。

正如上面说到某运营商云也是采用基于软件Overlay网络，原因很简单，之前他们将网络硬件设备一旦部署到资源池，便没有办法对它进行迁移，扩容上也只能通过采购硬件这种传统的升级方式完成。他们要解决的是网络灵活性问题，降低对硬件设备的依赖，不过性能问题也是目前面临的瓶颈，因为流媒体等大数据流开始出现在他们的网络流量中。目前正在验证各种性能加速方案，包括DPDK、FPGA等。

而那位游戏行业的同行之所以采用基于硬件的解决方案的原因也同样简单，软件方案开发周期长、人手少难以应对各种问题、生产环境不稳定、以及占用计算资源带来的性能挑战。所以基于开发成本、稳定性等原因，他们则选择了硬件方案，这里包括了不同厂家的硬件设备和驱动、第三方控制器、自身云平台业务系统等。

其实，对于硬件的Overlay方案目前我们也在进行POC，鉴于业务的特殊性，除了虚机托管，我们还有一些物理机的接入需求，这一块只能通过硬件网络Overlay解决，今年也会应用于生产环境。

点评SDN的管理控制平台是否自研和基于开源二次开发要结合自身研发能力和业务规模，商业方案需重点考虑异构兼容问题。从Ooverlay来看，现在基于硬件的Overlay方案是占上风的，从长远来看，在云的领域基于软件的Overaly是未来方向。

即使面临一些问题还有待解决，SDN的部署无论对于我们还是这些同行们来说，好处是明显的：

  ●  用户通过云平台快速搭建基础IT环境、应用的自动化部署满足了租户应用/App快速上线、迭代的需求。
  ●  网络资源实现SDN化，降低成本、提高网络灵活性并解除厂商锁定
  ●  建立NFV能力的资源池，通过SDN将数据流引到网络资源池中为客户提供相关的业务链产品
  ●  实现用户操作的全自动化和NFV网络资源动态的调度和扩展

同时，SDN技术的引入也对运维带来了新的要求，包括新增的监控对象、故障排查等。随着网络规模持续增长、传统监控手段失效，下期我们再重点说说云网环境下的网络运维。

点评SDN是对网络的革新，不少实践的用户虽然碰到各种不同的问题，但更多收益于它产生的价值，无论对于企业用户还是网络的从业者正在经历新一代网络的蜕变。