该篇文章系SDN实战团微信群组织的线上技术分享整理而成，本次由地球@某某老师给我们带来关于SDN在企业网、企业DC中的应用分享。
嘉宾介绍
--------------------------------------------------------------------------
地球@某某，SDN方面的从业者，接触SDN是从2008年开始的，确切的说是接触OpenFlow，因为当时还没有SDN这个词。从2009年到现在一直从事和SDN相关的开发工作，主要负责SDN控制器、解决方案开发的架构和一部分PM的工作。
分享正文
--------------------------------------------------------------------------
相信大家对SDN都有或多或少的了解，在这节省时间，关于SDN的历史和概要就不做详细介绍了，网上有大量相关知识和信息。今天主要想结合实际案例谈一谈SDN在企业网和企业级DC中的应用。由于分享的内容有点多，又因为大家都是行内人士，所以我可能会倾向使用high-context的表达方式，如果大家有不清楚的地方过会再一起讨论。
很多人都该知道，想让客户导入新的网络技术实在不是一件容易的事。因为对于大多是传统企业来说包括网络在内的IT系统都是非直接盈利的。对于非直接盈利的项目投资业是往往被排在盈利项目之后的。很多经营者的思维都是对现有这些东西物尽其用。因为使用新系统技术不仅需要投资，还会带来相应的系统使用风险和磨合期的附加损失。这说白了就是一个信赖关系的问题。所以想要把东西推销出去，就必须让客户能够切身实地的看到你的东西的价值和效率。要达到这个目的有很多的做法，个人认为的效果比较应该是下面这样的。
PPT说明＜Demo(PoC)＜其他公司的商用实例＜自公司的实用体验
我们的做法是首先通过把自己公司的网络SDN化，产生相应的商用实例和经验。自己的东西自己说的这好那好的，自己不去用是没法说服客户的。然后找些有长期信赖关系的客户，通过帮助他们导入SDN，得到更可信更有效的商用实例和解决方案。再通过提供灵活可分解、基于模块的分层架构把整体SDN解决方案分解成局部的solution package。这样允许客户循序渐进逐步导入SDN环境。因为可以实现局部SDN化，既可以降低客户的初期投资的风险，放低SDN导入的门槛，也可以让客户确确实实的体验SDN所带来的快感，从而让他们欲罢不能的去实现全网的SDN化。
接下来说一下局部SDN化的话题。从物理拓扑布局来分的话，一般分为以下几种导入模式。
1.插件导入模式
2.边缘SDN化导入模式
3.核心SDN化导入模式
4.透过导入模式
5.边缘overlay导入模式
插件导入模式
插件导入模式指的是在企业LAN和WAN之间导入SDN环境。主要用途有两个。一个是用来把分散部署的FW、LB、IDS/IPS等等这些设备集约化，共有化。并通过SDN实现这些服务的动态按需配给，进而减低对设备配置吞吐量的要求，提高其利用率。另一个是通过和网络监控设备联合和管控WAN出口设备来提高WAN的带宽利用率。
边缘SDN化导入模式
边缘SDN化导入模式顾名思义，指的是把收容服务器、客户端的边缘网络进行SDN化。这种模式允许企业原来的网络和SDN网络并存，可以让企业在原有的网络环境的基础上局部导入SDN进行效果验证。
核心SDN化导入模式
核心SDN化导入模式是把网络中核心路由部分的网络使用SDN来实现，核心路由功能可以通过控制器和SDN交换机实现的虚拟路由器来完成，也可以通过SDN控制器控制物理或者虚拟路由器实体来实现。
透过导入模式
透过导入模式，单从名称上来看或许有点不得其解，严格说来不能算是一个单独的模式。在逐步导入SDN的时候会出现SDN网络和原有网络共存的情况，原网络和SDN网络可能会被相互隔离。透过模式可以使SDN对特定的流(可配置)透明，这样保证局部SDN化对原有网络造成的影响可以控制。既即使导入了SDN环境，对于不需要适用SDN的部分也可以把SDN网络对其完全透明化，关于这部分的原有配置也不需要做任何改变。
边缘overlay导入模式
边缘overlay导入模式，熟悉的人很多。指的就是通过在虚拟环境中导入虚拟交换机，并由SDN控制器控制虚拟交换机来实现网络控制，这种方式的主要应有领域是使用虚拟环境的大型DC。
我们的SDN化从开始做到现在也积累了几百个商用案例了，应用遍布传统企业，IT公司，政府，银行，医院，便利店，通信，云等方方面面的领域。下面说几个SDN解决方案场景，也是应该是大家比较兴趣的地方。
安全
首先是安全。随着近年来信息攻击手段的不断的进化，安全对企业的压力越来越大。企业需要对流入流出的全流量进行检测。这就需要引入吞吐量更高价格也更贵的安全设备。并且安全设备的功能被越来越细分化，针对不同的攻击选择正确的设备比较困难。使用插件导入模式在DMZ导入SDN环境，然后对出入的流量进行监控，控制器根据流量特征做智能判断把流量自动分配给相应的安全设备。这样在保证了安全级别的同时也提高了设备利用率并降低了对设备吞吐量的要求，进而减少安全支出。简单的说就是使用low end的设备或者就是虚拟安全设备来堆各种安全功能，哪种功能需要多少就堆多少，不够了可以scale out再加。
比如说防DDos，防D一直是安全中的一个重要的话题，由于DDos攻击手段的多样化和攻击工具的普及，DDos对企业网络的威胁越来越大。企业的防D设备一般是要对流量全部进行检测，这样不仅需要高价的防D设备也会导致网络传输性能下降。导入SDN后可以通过流量变化来定位可疑流量，然后把可疑流量引入到防D设备进行进一步确认。对于确认是攻击的流量进行清洗并通过SDN控制器在SDN网络入口处把攻击流量废弃掉。如果有SDWAN环境的话，也可以通过SDN控制器实施BHR/RTBH等策略，对于正常流量可以重新引回到原路径进行正常的通信交互。这样不但降低了设备要求，由于是按需进行流量监测和清洗还可以保证正常流量的网络传输性能不被影响。这个场景主要应用于企业DC内网或者企业LAN。
网络设备集约化
网络设备集约化，这个大家也都很熟悉，刚才在说明插件导入模式的时候也提到过。说来就是物理设备的集约化，虚拟设备池化。其实这个应该是NV和企业级NFV/SC（Service chaining）的领域,SDN只是通过集中控制流量路径使其实现的更为灵活和简单。
个人认为网络设备在Cloud环境无论是从VMware的NSX还是从OpenStack的Neutron来看都有向Micro segmentation发展的趋势，不过从实际应用来看在企业的场景中还是倾向于集约化和池化。大多数大型企业都有这个需求，我记得有一个大型的食品加工公司，有很多分公司。各个分公司都有自己的FW这些设备，设计和设备维护也都是委托的不同的厂商。运维费用每年要近10万美金，配置变更也需要很长的lead time。导入SDN后，通过集约这些设备提供简单的可视化操作界面，不仅配置变更的lead time缩短一大截，年运维人工费用也减少了一半。
WAN
由于SP的WAN带宽收费都比较狠，包括DCI通信的企业WAN费用一直是比较烧钱的。某著名搜索公司，2013年美国和日本之间大约一万公里的距离，年流量15TB左右，WAN带宽使用费用要3-4亿美金，后来通过使用SDN听说省了不少。一般如果WAN采用Active-backup冗长的话Backup的WAN就会一直被空着，比较浪费。单单使用像ISDN的一些按实际使用流量收费的WAN做backup的方法只适合流量比较小的情况，而且这些服务也呈逐渐边缘化，消失的趋势。
SP的WAN带宽契约一般是需要按照峰值时的最大传输量来决定的，这就造成了有很多时间一部分带宽都是空闲的。并且伴随着DC或者Branch site的增加会需要增加WAN口，这样的话Burst traffic故障的发生几率和排错难度都会增大。通过插件模式导入SDN解决方案可以实现WAN口的双活，多活，可以把多个低SLA的WAN口捆绑成一个口，在部分情况下可以使用其来代替高SLA大带宽的高价WAN口。
在WAN口多活的同时，SDN可以通过和网络监控系统联合去感知网络流量，延迟的变化，据此去分配WAN口和带宽。使用者也可以通过SDN控制器提供的task scheduling功能来制定不同时间，不同情况下所要执行的网络任务。比如在中午，下午休息时间可以把出Internet流量的QoS配置带宽加大，再比如到了晚间或者休息日可以自动允许数据备份这些批处理流量走高速的WAN口。
我个人一直认为SDWAN是SDN的一个非常重要的应用场景，实际需求也很大，但是做好很不容易，技术上的坑很多。不过看过PoC的客户的态度基本上感觉是非常渴望，只要能保证商用要求就一定会买的样子。
网络虚拟化
可能大家看到的最多的SDN应用就是在Cloud环境中利用SDN实现的伴随着网络虚拟化的网络资源动态供应，当然也有包括针对hosting/housing服务的应用。基本上无论是ODL，ONOS，OVX，Midonet这些OSS控制器，还是NSX，ACI这些商用解决方案都提供虚拟网和高抽象度的操作接口。并且也都提供以WebAPI为主的控制接口与上层的Cloud orchestrator对接。
其实网络虚拟化在一般的企业网中的需求也很高，主要的对象是那些结构变化频繁的企业或者组织。比如某医院，各个科都使用的是特定厂商的医疗器械，考虑到国内外的接入安全问题，这个医院把每个科的LAN都物理隔离了，造成网络很复杂。特别是在各个科之间调动医疗器械的时候网络配置更改很麻烦还容易出错，lead time也很长。医院通过使用SDN实现的虚拟租户网解决方案不仅完全隔离了各个科的LAN环境，还可以使用SDN控制器的操作接口（GUI/CLI）很迅速的完成器材调度时的网络配置变更，用于网络配置的人工费减少到了原有的20%。还有像某些研发中心的需求就更明显了，基本上都是工程指向型的组织结构，每当一个课题或者工程开始和结束的时候都需要构筑网络或者解体网络，SDN的解决方案可以说帮了他们大忙了。还有像电视台，一些政府机关都有相应需求，在此就不以一一细说了。
这个场景主要使用的是全网SDN化或者边缘SDN化导入模式。在全网SDN化的环境下还可以通过虚拟租户网和网络设备集约实现把分散管理的各个部门的网络统一管理，统一配置，以节省运维开支，降低安全风险。虚拟网的Admin权限可以按部门提供，这样可以保证各个部门对自己部门网络的自由配置权。
BCP/DR
BCP/DR有两个重要指标，RPO（Recovery Point Objective）和RTO（Recovery Time Objective）。很容易理解RPO和RTO越小的方案灾害发生时损失的数据越少，业务回复的也越快。想要达到这个目标就需要架构WAC（Wide Area Cluster）。要搞这个东西是很费钱的，要搞BIA，设计整套的适合自己的BCP/DR方案，还要做整体（按需也可以是一部分）的系统和DC设备的冗长化，提供大量数据备份的WAN带宽，这对于大多企业来说都是很大的一笔财务负担。如果不想做好的Backup DC只是放着备份的话还需要导入专用软件和人才实现多活DC。使用SDN配合GSLB的话可以简单的实现多活DC，还能通过SDN控制器细粒度的调节流向各个DC中虚拟服务器的流量实现更灵活的多DC负载均衡。
企业网中SDN的应用还有很多，上面所述只是我个人认为的一些经典场景。SDN已经进入幻灭期，相信它将会逐渐通过复苏期走入成熟期。希望能有更多脚踏实地的厂家和务实的同行关注SDN。不光是在企业网，在Carrier/SP、 IDC、光通信、PTN等领域一起来挖掘SDN的应用价值，推动网络技术发展，把这块蛋糕越做越大。
Q&A
Q：不过端口状态也不能决定是否有链路
A：端口状态也会检测，不过端口即使是up的，LLDP断掉的话也需要判断链路断了。因为有时候LLDP需要通过l2 tunnel过wan，link status不能保证过wan的虚拟l2链路是通的还是断的。
Q：在没有多级流表的情况下，有什么方法可以压缩？
A：可以在把flow entry的path group化上做做文章。
Q：你说多个分支机构都有自己的FW，通过集约化让他们共享，他们都分散在不同地方，怎么共享？
A：各地site的设备都集约到head quarter，通过head quarter统一下策略，site的流量都是通过head quarter走的。
Q：控制器和网络是如何保持状态一致性呢？要定时对账么？
A：对，正常情况下有barrier，可以保证flow 下去。如果出现secure channel断掉或者控制器自己failover的话就需要audit。就是你说的对账。
Q：lldp bypass具体是个什么概念
A：就是比如你随便连台Linux的两个口到OpenFlow Switch上，然后LLDP正常是不会被forwarding的。你可以把LLDP从一个口转到另一个口，或者另一个OFS。这样就会让使控制器认为通过你的Linux有条链路，然后你能想干啥就干啥了。
Q：可能大家看到的最多的SDN应用就是在Cloud环境中利用SDN实现的伴随着网络虚拟化的网络资源动态供应，当然也有包括针对hosting/housing服务的应用。"Housing"是指
A：Housing是指服务器都是由客户自己提供，DC只提供电源供给，网络，服务器监控，数据备份等基础服务。
Q："个人认为网络设备在Cloud环境无论是从VMware的NSX还是从OpenStack的Neutron来看都有倾向Micro segmentation发展的趋势，不过从实际应用来看在企业的case中还是倾向于集约化和池化。" ---- 这里 Micro Seg的颗粒度和集约化池化有矛盾吗？没完全理解这句。
A：有些矛盾，MS要达到的是每个服务器，虚拟机尽量占有独立设备，虚拟的也可以。集约化没有这个需求。
Q：前段时间看到联通的宣传稿，一个宣传点就是根据带宽日历对汇聚网的lsp做时间调度，前段时间看onos也有bandwidth calendaring. 我大概想了一下，这种应用是否需要ted也扩展增加时间的维度？地球老师讲的wan中一个例子是否类似？
A：按你描述的来看应该是类似的，ONOS的这个Bandwidth calendaring我还不太了解，有时间会学习下。
--------------------------------------------------------------------------
SDN实战团微信群由Brocade中国区CTO张宇峰领衔组织创立，携手SDN Lab以及海内外SDN/NFV/云计算产学研生态系统相关领域实战技术牛，每周都会组织定向的技术及业界动态分享，欢迎感兴趣的同学加微信：eigenswing，进群参与，您有想听的话题可以给我们留言。