简介招商银行SDN网络实践完整讲解资料以PDF形式呈现共1个文件压缩包大小3.4MB。内容面向金融行业网络架构师、IT运维人员及对SDN落地方案感兴趣的读者系统梳理了招商银行自2012年跟踪SDN技术到2015年在科兴园区实施SDN网络的完整历程。资料核心包括从高可用性、灵活性、智能化、自动化四个维度阐述新一代IT基础架构方向对比Cisco、VMware、H3C、Juniper等厂商方案详细展示科兴园区SDN整体逻辑架构控制层、基础资源层、管理层和物理拓扑Spine-Leaf组网、IRF2、VCFC控制器以及Overlay网络、安全服务链、OpenFlow流表等关键实践。读者可从中了解银行业如何将SDN用于提升业务部署速度、实现网络自动化编排与统一管控并获得对金融行业云化网络改造极具参考价值的落地经验。目前该资料已有106人学习下载适合作为金融科技与网络技术研究的一手案例。1. SDN网络实践招商银行科兴园区从研究到生产的四年路径SDN软件定义网络在金融行业讨论了很多年真正敢把生产级网络完整交出去的银行并不多招商银行是其中走得比较靠前的一家。这份《招商银行SDN网络实践》资料来自平湖数据中心经理钟祝君的技术分享完整记录了招行从2012年跟踪SDN技术、2013年做可行性分析、2014年测试四家主流厂商方案到2015年在新建科兴园区落地SDN网络的全过程。它回答了一个核心问题当控制平面和转发平面分离之后银行的业务部署、资源调度与安全策略下发到底能快到什么程度。这份资料不是纯理论教材而是带着真实选型决策和落地细节的工程样本适合正在调研SDN/Overlay落地的网络架构师、运维负责人和金融行业IT人员值得反复拆解。2. 为什么是SDN从招行信息化底子到四层价值闭环2.1 招行的信息化家底容灾双活与统一管理并非一日之功要理解招行为什么敢上SDN先得看它此前的信息化建设到了什么程度。资料里列举了六项基础工作完成数据中心服务能力成熟度标准制定完成主机系统的异地容灾建设业务可以在2分钟内一键切换实现所有应用系统的异地双活、部分数据库的异地双活完成IT基础架构的高可用性设计重要业务系统双区接入全行所有业务系统和信息平台统一管理启动金融云建设IaaS和PaaS平台逐步完善。这六件事放在银行行业里含金量很高。异地容灾加一键切换说明业务连续性已经有了基本盘双活意味着两套数据中心都在承担生产流量而不是一套运行一套空转双区接入则是网络层的冗余设计相当于把传统主备模式升级为双活接入。这些基础意味着招行在做SDN改造之前已经对「网络不能成为单点」这件事有了一套成熟的治理方法。同时IaaS和PaaS平台的建设为SDN的落地提供了软件生态的土壤——没有云平台的编排能力SDN控制器就少了一半的用武之地。有了这个底子再看SDN就完全是另一个视角——不是把自己从一个稳定架构换到陌生架构而是在已有的高可用体系之上补上「灵活性」和「自动化」两块短板。这是很多银行不敢碰SDN而招行敢碰的核心区别。如果你的机构容灾双活还没做完我的建议是先别急着上SDN。SDN解决的是灵活调度和自动化运维问题不是容灾问题底子不稳时引入新变量翻车概率会翻倍。招行在资料里提出了新一代IT基础架构建设的六个方向整体架构的可靠、网络资源的冗余、应用系统的容灾以及资源按需分配、服务随需而动、监管无处不在。前三个属于基线后三个是目标。SDN在其中承担的角色非常清晰——它帮助实现资源灵活调度、网络弹性扩展、架构平滑升级、业务流程自动化、资源部署自动化、运维管理自动化直接打通「目标」这一层。2.2 SDN对传统网络的四个改变解耦、可编程与业务驱动资料里对SDN的定义非常简洁通过软件的方式重新定义网络架构和管理模式。再往下拆就是四个改变。第一个改变是网络资源与上层应用平台通过SDN关联实现由业务驱动的网络架构。传统网络里业务要开一个专区网络管理员要手动配置VLAN、路由、ACL应用和网络是两拨人、两套节奏SDN环境下业务侧提出需求云平台向SDN控制器要资源控制器下发给底层设备网络跟着业务走而不是业务等网络。第二个改变是SDN控制器掌控全网信息灵活快速地响应业务需求变化。所有交换机的状态都汇总到控制器全网拓扑一张图哪条链路拥塞、哪个VTEP负载高控制器全局可见。有了这个全局视图后面讲的流量调度、路径选择才有依据传统网络里靠工程师登设备看状态的做法在这里被完全替代。第三个改变是网络具备可编程能力实现网络管理和控制的自动化。这里的「可编程」不是指给网络设备写代码而是策略的生成、下发、回收都可以通过控制器的开放接口完成不用登到每台设备上敲命令行。自动化、智能化由此展开。第四个改变就是SDN最核心的控制层与转发层解耦合。传统交换机里控制与转发绑在一起SDN把控制逻辑上收到控制器转发设备只负责按流表转发。解耦之后底层转发设备可以标准化部署网络不再绑定单一厂商的私有协议这也是后面科兴园区能够搭建标准化Spine-Leaf模型的原因。这四个改变不是并列的四个功能而是一条逻辑链解耦是前提可编程是手段控制器全局视图是支撑业务驱动是最终目的。在设计SDN改造方案时建议先对照这条链自查缺了哪一环方案的价值都会打折扣。2.3 招行的期望清单三张表拆解流量调度与自动化需求在测试厂商方案之前招行先写了一份期望清单也就是「SDN网络要满足什么要求」这份清单直接决定了后续的选型判断标准。我把核心内容整理成一张表期望方向具体内容落地点网络流量灵活调度流量可视化、内部流量调度、出口流量调度流量路径计算、链路负载感知网络资源自动化部署资源自动化部署、策略自动化跟随、服务按需分配云平台与SDN控制器联动网络统一管理控制物理、虚拟网络统一监控、云平台统一管控管理层与控制层架构这张表里有几个细节值得注意。流量调度分为内部和出口两个方向内部调度面向VxLAN Fabric内部VTEP之间的流量出口调度面向SDN网络与传统网络之间的流量。两者的处理逻辑完全不同招行在需求阶段就拆开了而不是笼统写一句「支持流量调度」这为后来流量路径计算的具体实现打下了需求基础。策略自动化跟随这一条对应的是虚拟机创建、迁移、销毁时安全策略的自动生成与回收。虚拟化环境下虚拟机在物理服务器之间漂移是常态如果策略是手工绑定到物理端口虚拟机一迁移策略就丢失业务直接中断。招行把这个需求写进期望清单说明在设计阶段就已经意识到了虚拟化引入的安全管理新问题。统一管理控制则明确了物理加虚拟都要管不只是管Overlay不管Underlay。物理网络的状态、链路、设备虚拟网络的VxLAN、vSwitch、安全组必须在同一个平台上呈现。很多SDN方案只做虚拟网络一层Underlay成了黑匣子招行的要求从一开始就排除了这类方案。在价值侧招行把SDN带来的收益总结为四点提升速度、灵活调度、优化效率、统一管理。提升速度对应业务部署和需求响应灵活调度对应网络可编程和资源接口优化效率对应资源利用率和IT成本控制统一管理对应全局掌控和云平台调度。这四点与期望清单一一对应是先定义问题再验证方案而不是拿着厂商方案反过来找需求。对正在选型的团队来说我一般建议把这份期望清单直接转成测试用例表每个「期望方向」对应两到三个可观测的验收指标比如「策略自动化跟随」就对应三条用例新建VM验证策略自动下发、迁移VM验证策略跟随、删除VM验证策略自动回收这样选型测试才不会变成厂商演示。3. 从研究到落地科兴园区SDN网络的选型、架构与协议拆解3.1 四年决策路径从技术跟踪到生产落地的完整链条招行的SDN探索节奏非常清晰四个节点恰好对应四种不同性质的投入阶段年份工作内容目标技术跟踪2012对SDN相关技术进行跟踪研究理解技术边界判断前景可行性分析2013对引入SDN技术进行可行性分析判断是否适合银行业务场景方案测试2014对业界主流SDN方案和产品进行测试分析筛选可用厂商与方案生产实践2015新建科兴园区SDN网络在真实环境验证落地2014年的厂商调研覆盖了Cisco、VMware、H3C、Juniper、华为、Big Switch、Arista、博科八家。最终只对Cisco、VMware、H3C、Juniper四家做了测试筛选标准是「是否具备测试条件」。这个细节在银行选型里非常真实并不是说另外四家做得不好而是当时的测试环境、人员技能、方案完整度未必能满足银行的测试要求。Big Switch和Arista在国内金融行业的本地服务团队、文档体系、与OpenStack的对接成熟度当时都有明显短板华为和博科更多是硬件层面的厂商控制层软件化程度在当时的方案里不够突出。最终选定的四家里H3C以VCFC控制器加云平台的整套方案胜出与科兴园区最终采用H3CloudVCFC的架构完全对应。提示银行选型有个隐性标准厂商能否在本地提供持续的技术支持和测试支撑。SDN不是买一批交换机就完事控制器、云平台、网络设备三方联调往往要持续数月本地化支持能力在这一步就会被筛掉。测试阶段重点关注四个维度快速部署、网络监控、功能完整性和方案适应性。快速部署看的是从控制器上线到第一批VxLAN网络跑通需要多久网络监控看的是物理和虚拟两层拓扑在平台上是否真实可观测功能则对照2.3节的期望清单逐条过适应性看的是与非虚拟化服务器、传统网络边界的对接能力。这套测试框架对今天做SDN选型依然有参考价值。3.2 逻辑架构云平台、SDN控制器与Overlay的三层协同科兴园区SDN网络的逻辑架构可以拆成三个层面管理层、控制层与基础资源层。管理层包含用户Portal和云平台H3Cloud负责接收业务需求、编排资源、向上层应用提供网络服务。控制层是VCFC控制器集群掌控VxLAN Fabric的全网状态通过OpenFlowOVSDB、OpenFlowNetConf两类协议通道向转发设备下发指令。基础资源层包括Spine交换机、Leaf交换机、虚拟化服务器上的vSwitch、L3网关以及接入传统网络的边界点承担实际报文转发。这套架构最值得注意的一点是「云平台SDNOverlay」的组合方式。云平台是入口面向业务侧租户提需求、分配IP、部署虚拟机SDN控制器是大脑面向网络侧把云平台的意图翻译成流表或配置下发给设备Overlay网络是载体用VxLAN封装虚拟网络让业务IP与物理位置解耦。三个层面各司其职没有谁替代谁也没有谁是附属品。控制层与转发层之间OpenFlow负责下发流表OVSDB负责管理vSwitch的数据库配置NetConf负责交换机上的网络配置。换言之整个Fabric里的vSwitch和物理交换机全部被纳入控制器的管理范围没有一台设备是游离在外的手工配置黑匣子。这个「全量纳管」的设计理念是后续流量调度、策略自动化跟随能够成立的前提。如果底层还有设备不受控制器管理SDN的自动化能力就会在这台设备上断掉。3.3 Spine-Leaf物理组网与IRF2纯三层Underlay的可靠性设计物理拓扑比逻辑架构更能看出一个方案的真实水平。科兴园区SDN网络采用两台Spine交换机、多台Leaf交换机的对称架构Spine之间通过IRF2堆叠成虚拟集群Leaf设备做了同样处理。Underlay运行OSPF动态路由整个物理层是纯三层网络没有二层环路。资料中物理拓扑图上标注的SDN-125X、SDN-SRV、SDN-68-1等设备角色区分得很清楚SDN-125X对应Spine/Leaf转发设备SDN-SRV对应计算节点SDN-68-1对应接入边界读者看原图时可以先按这个角色关系对照。纯三层物理网络带来的第一个好处是去掉STP生成树的包袱。传统园区网络的核心痛点之一就是二层环路链路冗余成本高、收敛慢、故障时容易出广播风暴。Spine-Leaf模型下Spine之间不做二层互通Leaf与每台Spine三层互联流量永远走最短路径网络扩容时横向增加Leaf即可不用改动Spine侧配置。第二个好处是IRF2堆叠后的管理面收敛。两台设备堆叠成一台逻辑设备管理IP只有一个OSPF邻居只有一个故障切换由堆叠协议完成对上层完全透明。这对后续日常运维很友好——不需要逐台设备去看状态控制器和云平台统一下发。第三个细节是SDN网络采用独立物理设备部署与传统网络通过静态路由实现互通。SDN网络和招行传统网络在物理上隔离只有边界路由器上一条静态路由级别的连接。这样既避免VxLAN报文在传统网络设备里传播导致旧设备故障也避免了两套网络的策略互相干扰。这个设计在后面避坑部分还要展开说。3.4 协议分工OpenFlow、OVSDB、NetConf与VxLAN各管什么科兴园区网络里实际涉及五类协议很多资料把它们混在一起讲这里单独拆开协议类型职责对应设备OpenFlow南向协议下发流表控制数据转发路径控制器与vSwitch/LeafOVSDB南向协议管理vSwitch配置维护OVS数据库控制器与vSwitchNetConf南向协议下发物理设备运行配置控制器与Leaf/RouterOSPF路由协议Underlay三层路由保证物理连通Spine与Leaf之间VxLANOverlay封装虚拟网络封装实现位置解耦Leaf与vSwitch的VTEPOpenFlow管的是「这条流的路径怎么走」OVSDB管的是「vSwitch的端口、隧道、数据库怎么配」NetConf管的是「物理交换机的业务配置怎么下发」三者粒度不同但必须协同。理解这套协议的边界对后续排障非常重要——流量不通时先判断是流表没下发OpenFlow的问题还是隧道配置错误OVSDB的问题还是物理交换机接口配置缺了NetConf的问题定位效率会高很多。Overlay层面服务器上的vSwitch作为VTEP负责VxLAN封装和解封装Leaf设备也承担VTEP角色成为虚拟网络与三层物理网络的桥接点。虚拟机的流量先在Overlay内按业务逻辑转发出虚拟网络时才通过L3网关进入物理路由域。这种两级VTEP的设计让科兴园区同时支持虚拟化服务器和非虚拟化服务器接入Overlay——非虚拟化服务器通过NIC直连Leaf的VTEP同样能进入VxLAN Fabric。这一点对金融行业大量存量物理机的现状非常关键。4. 避坑指南SDN落地中的四类典型问题与处理思路4.1 新老网络互通独立部署加静态路由为什么更省心现象部分团队做SDN改造时采用新旧设备混合组网让SDN控制器把传统交换机也纳管进来结果VxLAN报文在传统设备之间转发时频繁丢包传统设备的ACL策略不停地告警、误拦。原因传统网络设备不认识VxLAN封装Overlay网络的二层语义在物理网络上并不存在同时旧设备的ACL策略会命中VxLAN控制报文产生大量无效告警两边运维团队互相怀疑。解决招行的做法是SDN网络采用独立物理设备部署与传统网络通过静态路由实现互通。新老网络物理隔离只在边界做路由级互联从根上避免VxLAN报文进入传统设备。这个思路在金融生产环境里非常实用不要追求一套网络大融合物理隔离加边界路由反而让两边都能保持自己原有的运维方式。从我个人的经验看SDN改造最容易出问题的恰恰不是SDN本身而是新旧两个网络的交接区。Overlay网络边界、网关位置、路由发布方式这三个点如果不提前定死联调阶段会消耗掉一半时间。招行选择静态路由而非动态路由协议互通也是考虑到SDN网络内部已经跑OSPF边界再跑一个动态协议会引入不必要的路由震荡风险。4.2 Overlay安全盲区物理防火墙为什么看不见东西向流量现象SDN网络上线后原有物理防火墙的日志里几乎看不到Overlay内部的流量。安全团队以为流量根本没经过防火墙实际上所有虚拟机之间的东西向流量都已经走了VxLAN封装物理设备根本拆不开。原因物理安全设备部署在物理网络的关键路径上但Overlay网络报文经过VxLAN封装之后外层看到的源和目的地址是VTEP的IP真实的虚拟机IP被封装在VxLAN头里。物理设备拆不开封装自然看不到真实流量内容更谈不上过滤和审计。解决招行在计算节点的vSwitch上内嵌分布式防火墙同时把NFV虚拟安全设备vFW组成安全资源池由SDN控制器统一编排。vSwitch嵌入式防火墙解决东西向流量在计算节点内部已经被封装、传统设备看不见的问题NFV安全资源池解决南北向流量穿过安全设备时无法识别Overlay报文的问题。服务链机制还允许业务自定义流量经过安全节点的顺序比物理拓扑上硬插一台防火墙灵活得多。这里补一句NFV安全资源池里的vFW一定是标准化镜像支持弹性扩展。业务量上来之后加虚拟机就行不用改物理拓扑这正是NFV相比物理安全设备的本质优势。招行在资料里强调了vSwitch内嵌防火墙和NFV资源池分别解决了主机的边界模糊和物理设备无法识别Overlay报文两个问题这两句话值得在方案设计时反复对照。4.3 安全策略跟不上虚拟机漂移一个虚拟化时代的必然坑现象虚拟机从一台物理服务器迁移到另一台后原来针对它的安全策略全部失效业务访问异常或直接被拦排查半天发现是策略没跟上。原因传统网络的安全策略通常绑定在物理端口或VLAN上虚拟机迁移后物理接入点改变策略绑定关系就断了。Overlay网络里虚拟机IP可以不变但VTEP变了策略如果不能感知VTEP变化就会丢失。解决招行在云管理平台层面实现了安全策略的自动化跟随——策略伴随虚拟机的创建自动生成和下发VM迁到哪台物理服务器策略就下到那台服务器的vSwitch上。这个机制依赖OpenFlow流表模式vSwitch上的策略以流表形式存在控制器根据虚拟机位置变化动态更新流表全程不需要人工参与。这个坑几乎是虚拟化环境里跑Overlay网络的必然问题无论用哪家方案。我一般建议在方案测试阶段就把「虚拟机迁移加策略跟随」作为必测用例不要等上线之后再验证。测的时候注意两点一是迁移后新旧VTEP是否同时存在这会造成短暂的双活窗口二是安全策略下发的时序是否跟得上VM启动的过程这两点往往是偶发故障的来源。4.4 流量不均衡链路Cost、负载阈值与路径切换的调参经验现象SDN Fabric里部分链路利用率长期超过80%另一些长期低于10%业务时好时坏用户投诉频繁。原因很多Overlay方案的默认路径计算只考虑静态Cost值链路不中断就一直走老路。负载均衡只做到流级别一旦多条大流被哈希到同一条链路就会长期拥挤控制器不会主动调整。解决招行的流量调度机制综合链路负载、Cost值、带宽比三个维度做路径计算。当某条链路的负载达到预设阈值云管理平台显示告警并把链路标红管理员可以修改流量调度策略把需要调度的流量重新调整到新路径上。整个流程是「感知—告警—人工确认—策略调整」不是全自动的这在生产环境里反而是优点——避免控制器自动切换引发不可控的路径震荡。实操层面有三个参数要提前想清楚。一是阈值设多高链路负载阈值我建议先设70%太高等于是摆设太低天天弹窗二是流量调度的粒度是流级别还是应用级别粒度越细调度越灵活但控制器计算压力越大三是路径切换后留一段观察窗口确认新路径的带宽与延迟表现而不是切完就完事。招行的做法是先标红、再人工调整这种保守策略在金融行业非常合理。5. 进阶验证把科兴园区的SDN打法迁移到自己的环境5.1 最小化复现用两三台物理机验证一套SDN子集想验证招行这套SDN方案在你的环境里是否可行不需要照搬整套科兴园区一个最小化复现就够了。先准备两台物理机一台跑VCFC控制器和云平台一台跑虚拟化Hypervisor并部署vSwitch两台机器之间用一台支持VxLAN的交换机互联。这个规模可以验证的核心点包括Overlay网络能不能正常建立、vSwitch上的分布式防火墙策略能不能跟随VM创建自动下发、VTEP之间能不能完成VxLAN封装和解封装。测试时先把云平台、控制器、vSwitch的版本对齐再把Underlay的OSPF跑通最后才是创建VxLAN网络和虚拟机。这个顺序不能乱Underlay不通就谈不上Overlay。我在做类似验证时习惯在每步之后用抓包确认报文类型——区分VxLAN标志位和正常的IP报文能快速定位是封装问题还是路由问题。5.2 检查清单落地后必做的五个验证动作不管规模大小照看这五件事就能判断SDN方案是否真正落地成功验证项操作预期结果流表下发查看控制器上流表条目数与虚拟机数量匹配策略跟随迁移一台VM到另一台物理机策略自动迁移无中断流量可视化云平台查看链路利用率曲线能看到每条链路实时数据阈值告警人为压满一条链路带宽平台标红并弹出告警新老网络互通从传统网络ping通Overlay内的VM静态路由路径稳定最后一个动作是流量调度演练压满一条链路观察平台是否标红调整策略后确认流量切到备用路径再观察两分钟确认新路径稳定。这组演练做完基本可以证明方案在运维层面是可控的。从那以后我做任何网络架构改造都强制自己先写需求清单、再画现状图、把新老边界画清楚最后才是选型和实施。SDN也好其他技术也好顺序对了坑就少一半。希望帮到你。本文还有配套的精品资源点击获取