从传统网络架构到SDN化演进方案

合集下载

VSA和SDS:两种SDN网络安全架构的研究

VSA和SDS:两种SDN网络安全架构的研究

VSA和SDS:两种SDN网络安全架构的研究软件定义网络SDN(Software Defined Networking)的软件编程特性和开放性带来很多新的安全挑战.也给网络安全带来了挑战和机遇.本文提出了两种演进的SDN网络安全架构:虚拟化安全设(Virtualized Security Appliance)和软件定义安全(Software Defined Security),给出了两种架构的建设要点,并以常规网络入侵、拒绝服务攻击和高级持续威胁等三类典型攻击场景分析了相应的工作原理,以防火墙为例演示了两种架构下的实现,测试表明两种结构在云计算中心环境中性能上是可行的,并且SDN数据和控制分离的特性使防火墙可用更少的代码实现.1.引言随着互联网和数据中心规模的迅速发展,尤其是在虚拟化技术的冲击下,运营商和大型数据中心的运营者遇到越来越多的挑战,例如:网络设备没有开放接口,很难实现运维活动的自动化,难以降低运营成本;依赖网络设备供应商的响应,无法满足业务部门快速变化的业务需求;网络设备之间的互操作性不好,容易导致供应商锁定;网络规模很难快速扩容和降容(Scale UP/DOWN);由于网络IP地址和物理位置绑定,很难做业务迁移;传统路由策略太复杂,很难管理,容易失控等等。

软件定义网络SDN( Software Defined Networking)的提出为解决以上大型数据中心的运营问题提供了可能的解决方案,因此虽然SDN还存在许多技术问题没有解决,但己有大量云计算中心、运营商及相关厂家的进行了SDN的实践。

软件定义网络(SDN)通过控制器实现网络的可编程。

SDN架构具备三个核心特征:1)控制平面和数据平面相互分离,2)智能和状态在逻辑上集中,3)底层网络基础设施从应用中抽象了出来。

近年来学术界和工业界将软件定义网络的思想进行了进一步扩展,出现了软件定义的计算、存储等,并被统称为软件定义的环境川,其主要特点是将计算、网络、存储等从底层异构的硬件中抽象出来,成为可由软件定义的资源,使原来独立、难以互通的控制组件构成统一的控制平面,通过对底层基础设施的可编程能力,实现基于策略的、自动化的集中管理和控制。

云数据中心网络与SDN:技术架构与实现

云数据中心网络与SDN:技术架构与实现

云数据中⼼⽹络与SDN:技术架构与实现云数据中⼼⽹络与SDN:技术架构与实现技术审校本书赞誉1 云数据中⼼⽹络演进1.1 传统的3-Tier架构1.2 设备“多虚⼀”——虚拟机框1.2.1 Cisco VSS1.2.2 Juniper VC与H3C IRF1.3 ⾼级STP欺骗——跨设备链路聚合1.3.1 Cisco vPC1.3.2 Juniper MC-LAG和Arista M-LAG1.4 变⾰3-Tier——向Leaf-Spine演进1.5 初识⼤⼆层1.6 插叙——虚拟机的接⼊1.6.1 VEB1.6.2 Cisco VN-TAG1.6.3 VEPA1.6.4 VEB性能优化1.7 消除STP——Underlay L2MP1.7.1 TRILL1.7.2 SPB1.8 Cisco私有的⼤⼆层——FabricPath1.8.1 整体设计1.8.2 控制与转发过程分析1.8.3 其他技术细节1.9 Juniper私有的⼤⼆层——QFabric1.9.1 整体设计1.9.2 集中式的控制机制1.9.3 控制与转发过程分析1.10 Brocade私有的⼤⼆层——VCS1.10.1 整体设计1.10.2 控制与转发过程分析1.10.3 其他技术细节1.11 跨越数据中⼼的⼆层——DCI优化1.11.1 Cisco OTV1.11.2 HUAWEI EVN与H3C EVI1.12 端到端的⼆层——NVo3的崛起1.12.1 VxLAN1.12.2 NvGRE1.12.3 STT1.12.4 Geneve1.13 新时代的开启——SDN⼊场1.14 Overlay最新技术——EVPN1.14.1 传统⽹络对SDN的反击1.14.2 组⽹与数据模型1.14.3 控制信令的设计1.15 Underlay最新技术——Segment Routing1.15.1 SID与Label1.15.2 控制与转发机制1.15.3 SDN2.0?1.16 本章⼩结2 杂谈SDN2.1 SDN与传统⽹络——新概念下的⽼问题2.2 转控分离——⽩盒的曙光2.2.1 芯⽚级开放2.2.2 操作系统级开放2.2.3 应⽤级开放2.2.4 机箱级开放2.2.5 ⽩盒的“通”与“痛”2.3 ⽹络可编程——百家争鸣2.3.1 芯⽚可编程2.3.2 FIB可编程2.3.3 RIB可编程2.3.4 设备配置可编程2.3.5 设备OS和控制器可编程2.3.6 业务可编程2.4 集中式控制——与分布式的哲学之争2.4.1 在功能上找到平衡点2.4.2 在扩展性和可⽤性上找到平衡点2.5 回归软件本源——从N到D再到S2.5.1 模块管理2.5.2 模块间通信2.5.3 接⼝协议适配2.5.4 数据库2.5.5 集群与分布式2.5.6 容器与微服务2.6 本章⼩结3 SDDCN概述3.1 需求3.1.1 ⾃动化与集中式控制3.1.2 应⽤感知3.2 整体架构3.2.1 实现形态3.2.2 功能设计3.3 关键技术3.3.1 ⽹络边缘3.3.2 ⽹络传输3.3.3 服务链3.3.4 可视化3.3.5 安全3.3.6 ⾼可⽤3.4 本章⼩结4 商⽤SDDCN解决⽅案4.1 VMware NSX4.1.1 从NVP到NSX4.1.2 NVP控制平⾯设计4.1.3 NVP数据平⾯设计4.1.4 NVP转发过程分析4.1.5 NSX-V整体架构4.1.6 NSX-V管理平⾯设计4.1.7 NSX-V控制平⾯设计4.1.8 NSX-V数据平⾯设计4.1.9 NSX-V转发过程分析4.1.10 NSX-MH与NSX-T4.2 Cisco ACI4.2.1 整体架构4.2.2 管理与控制平⾯设计4.2.3 数据平⾯设计4.2.4 转发过程分析4.2.5 议ACI与SDN4.3 Cisco VTS4.3.1 整体架构4.3.2 管理与控制平⾯设计4.3.3 数据平⾯设计4.4 Juniper Contrail4.4.1 整体架构4.4.2 管理与控制平⾯设计4.4.3 数据平⾯设计4.4.4 转发过程分析4.5 Nuage VCS4.5.1 整体架构4.5.2 管理平⾯设计4.5.3 控制平⾯设计4.5.4 数据平⾯设计4.6 Arista EOS与CloudVison 4.6.1 整体架构4.6.2 管理与控制平⾯设计4.6.3 数据平⾯设计4.7 HUAWEI AC-DCN4.7.1 整体架构4.7.2 管理平⾯设计4.7.3 控制平⾯设计4.7.4 数据平⾯设计4.8 Bigswitch BCF与BMF 4.8.1 整体架构4.8.2 BCF控制平⾯设计4.8.3 BMF控制平⾯设计4.8.4 数据平⾯设计4.9 Midokura Midonet4.9.1 整体架构4.9.2 控制平⾯设计4.9.3 数据平⾯设计4.10 PLUMgrid ONS4.10.1 整体架构4.10.2 数据平⾯设计4.10.3 控制平⾯设计4.10.4 转发过程分析4.11 Plexxi Switch与Control 4.11.1 整体架构4.11.2 数据平⾯设计4.11.3 控制平⾯设计4.12 Pluribus4.12.1 Server Switch设计4.12.2 Netvisor设计4.12.3 再议数据中⼼SDN4.13 本章⼩结5 开源SDDCN:OpenStack Neutron的设计与实现5.1 ⽹络基础5.1.1 ⽹络结构与⽹络类型5.1.2 VLAN⽹络类型中流量的处理5.2 软件架构5.2.1 分布式组件5.2.2 Core Plugin与Service Plugin5.3 WSGI与RPC的实现5.3.1 Neutron Server的WSGI5.3.2 Neutron Plugin与Neutron Agent间的RPC5.4 虚拟机启动过程中⽹络的相关实现5.4.1 虚拟机的启动流程5.4.2 Nova请求Port资源5.4.3 Neutron⽣成Port资源5.4.4 Neutron将Port相关信息通知给DHCP Agent5.4.5 DHCP Agent将Port相关信息通知给DHCP Server5.4.6 Nova拉起虚拟机并通过相应的Port接⼊⽹络5.5 OVS Agent的实现5.5.1 ⽹桥的初始化5.5.2 使能RPC5.6 OVS Agent对Overlay L2的处理5.6.1 标准转发机制5.6.2 arp_responder5.6.3 l2_population5.7 OVS Agent对Overlay L3的处理5.7.1 标准转发机制5.7.2 DVR对东西向流量的处理5.7.3 DVR对南北向流量的处理5.8 Security-Group与FWaaS5.8.1 Neutron-Security-Group5.8.2 FWaaS v15.8.3 FWaaS v25.9 LBaaS5.9.1 LBaaS v15.9.2 LBaaS v25.9.3 Octavia5.10 TaaS5.11 SFC5.12 L2-Gateway5.13 Dynamic Routing5.14 VPNaaS5.15 Networking-BGPVPN与BagPipe5.15.1 Networking-BGPVPN5.15.2 BagPipe5.16 DragonFlow5.17 OVN5.18 本章⼩结6 开源SDDCN:OpenDaylight相关项⽬的设计与实现6.1 架构分析6.1.1 AD-SAL架构6.1.2 MD-SAL架构6.1.3 YANG和YANG-Tools6.1.4 MD-SAL的内部设计6.1.5 MD-SAL的集群机制6.1.6 其他6.2 OpenFlow的⽰例实现6.2.1 OF交换机的上线6.2.2 l2switch获得PacketIn6.2.3 l2switch下发PacketOut和FlowMod6.3 OpenStack Networking-ODL6.3.1 v16.3.2 v26.4 Neutron-Northbound的实现6.4.1 对接Networking-ODL6.4.2 RESTful请求的处理⽰例6.5 Netvirt简介6.5.1 OVSDB-Netvirt和VPNService的合并6.5.2 Genius6.6 Netvirt-OVSDB-Neutron的实现6.6.1 net-virt分⽀6.6.2 net-virt-providers分⽀6.7 Netvirt-VPNService的实现6.7.1 elanmanager6.7.2 vpnmanager6.8 SFC的实现6.8.1 sfc-openflow-renderer分⽀6.8.2 sfc-scf-openflow分⽀6.9 VTN Manager的实现6.9.1 neutron分⽀6.9.2 implementation分⽀6.10 本章⼩结7 开源SDDCN:ONOS相关项⽬的设计与实现7.1 架构分析7.1.1 分层架构7.1.2 分层架构的实现7.1.3 模块的开发7.1.4 分层架构存在的问题7.1.5 数据存储与集群7.1.6 其他7.2 OpenFlow的⽰例实现7.2.1 OF交换机的上线7.2.2 fwd获得PacketIn7.2.3 fwd下发PacketOut和FlowMod7.3 ONOSFW的实现7.3.1 vtnmgr分⽀7.3.2 sfcmgr分⽀7.4 SONA的实现7.4.1 openstacknode分⽀7.4.2 openstacknetworking分⽀7.5 CORD简介7.5.1 R-CORD的架构7.5.2 R-CORD的控制与转发机制7.6 本章⼩结8 学术界相关研究8.1 拓扑8.1.1 FatTree8.1.2 VL28.1.3 DCell8.1.4 FiConn8.1.5 BCube8.1.6 MDCube8.1.7 CamCube8.2 路由8.2.1 Seattle8.2.2 FatTree8.2.3 VL28.2.4 PortLand8.2.5 SecondNet8.2.6 SiBF8.2.7 SPAIN8.2.8 WCMP8.2.9 OF-based DLB8.2.10 Flowlet与CONGA 8.2.11 Hedera8.2.12 DevoFlow8.2.13 MicroTE8.2.14 Mahout8.2.15 F108.2.16 DDC8.2.17 SlickFlow8.2.18 COXCast8.2.19 Avalanche8.3 虚拟化8.3.1 NetLord8.3.2 FlowN8.3.3 FlowVisor8.3.4 ADVisor8.3.5 VeRTIGO8.3.6 OpenVirteX8.3.7 CoVisor8.4 服务链8.4.1 pSwitch8.4.2 FlowTags8.4.3 Simple8.4.4 StEERING8.4.5 OpenSCaaS8.4.6 SPFRI8.5 服务质量8.5.1 NetShare8.5.2 Seawall8.5.3 GateKeeper8.5.4 ElasticSwitch8.5.5 SecondNet8.5.6 Oktopus8.6 传输层优化8.6.1 MPTCP8.6.5 Fastpass8.6.6 OpenTCP8.6.7 vCC8.7 测量与分析8.7.1 Pingmesh8.7.2 OpenNetMon8.7.3 FlowSense8.7.4 Dream8.7.5 OpenSample8.7.6 Planck8.7.7 OpenSketch8.8 安全8.8.1 SOM8.8.2 FloodGuard8.8.3 TopoGuard8.8.4 FortNox8.8.5 AVANT GUARD8.8.6 OF-RHM8.8.7 Fresco8.9 ⾼可⽤8.9.1 ElastiCon8.9.2 Ravana8.9.3 BFD for OpenFlow8.9.4 In-Band Control Recovery8.9.5 OF-based SLB8.9.6 Anata8.9.7 Duet8.10 ⼤数据优化8.10.1 BASS8.10.2 OFScheduler8.10.3 Phurti8.10.4 Application-Aware Networking 8.10.5 CoFlow8.11 本章⼩结9 番外——容器⽹络9.1 容器⽹络概述9.2 容器⽹络模型9.2.1 接⼊⽅式9.2.2 跨主机通信9.2.3 通⽤数据模型9.3 Docker⽹络9.3.1 docker09.3.2 pipework9.3.3 libnetwork9.4 Kubernetes⽹络9.4.1 基于POD的组⽹模型9.4.2 Service VIP机制9.5 第三⽅组⽹⽅案9.5.1 Flannel9.5.2 Weave9.6 Neutron⽹络与容器的对接9.7 本章⼩结10 番外——异构⽹络与融合10.1 融合以太⽹基础10.1.1 PFC10.1.2 ETS10.1.3 QCN10.1.4 DCBX10.2 存储⽹络及其融合10.2.1 FC的协议栈10.2.2 FC的控制与转发机制10.2.3 FCoE的控制与转发机制10.2.4 昙花⼀现的SDSAN10.3 ⾼性能计算⽹络及其融合10.3.1 InfiniBand的协议栈10.3.2 InfiniBand的控制与转发机制10.3.3 RoCE与RoCEv210.4 本章⼩结思维导图防⽌博客图床图⽚失效,防⽌图⽚源站外链:)思维导图在线编辑链接:。

未来网络架构与SDN

未来网络架构与SDN
控制平面:即SDN控制器,它是一个逻辑上的集中实体,主要负 责两个任务,一是将SDN应用层请求转换到SDN Datapath,二是 为SDN应用提供底层网络的抽象模型(状态或事件)。一个SDN 控制器包含北向接口代理(Northbound Interfaces Agent)、SDN 控制逻辑(Control Logic)以及控制数据平面接口驱动(CDPI Driver)3部分。SDN控制器只要求是逻辑上完整,因此它可以由 多个控制器实例协同组成,也可以是层级式的控制器集群;从地 理位置上讲,可是所有控制器实例在同一位置,也可以是多个实 例分散在不同的位置。
全社会的基础设施更新换代告诉我们不应推到重来,应该对网络核心层 进行平滑的革新,即演进。
三、SDN起源与关键技术
① 发展背景与里程碑
②SDN的定义 SDN(Software Defined Networking,软件定义网络)是一种 数据控制分离、软件可编程的新型网络体系架构,如下图所示。 它采用了集中式的控制平面和分布式的转发平面,两个平面相 互分离,控制平面利用控制——转发通信接口对转发平面上的 网络设备进行集中式的控制,并提供灵活的可编程能力。一般 我们将具备有这种特点的网络架构都认为是一种广义的SDN。
未来网络体系结构与SDN
南京邮电大学 武吉涛 2016.6.15
主要内容:
◎网络体系结构 ◎"互联网+"时代当前体系结构面临的挑战 ◎SDN起源与关键技术 ◎SDN的发展现状与发展趋势 ◎SDN参各层及协议的集合,它是网络及 其部件所应完成功能的精确定义,与其它大多数设计一样, 网络体系结构必须满足一定的需求: 网络体系结构同建筑一样,是人工设计并用来服务于人的, 必须满足一定的需求; 不是所有的需求都能满足,而是必须满足1-2个主要需求, 再尽力满足其它次要需求; 不同的设计目标会导致不同的体系结构; 不同的目标优先级可以导致不同的设计;

传统数据中心向SDN数据中心迁移方案

传统数据中心向SDN数据中心迁移方案

传统数据中心向SDN数据中心迁移方案在当今数字化快速发展的时代,数据中心的作用日益凸显。

随着业务需求的不断增长和技术的不断进步,传统数据中心在灵活性、可扩展性和管理效率等方面逐渐显露出局限性。

软件定义网络(SDN)作为一种创新的网络架构,为数据中心带来了更高的灵活性、自动化和智能性。

因此,将传统数据中心迁移到 SDN 数据中心成为了许多企业和组织的重要战略决策。

一、传统数据中心的局限性传统数据中心通常采用基于硬件的网络架构,网络设备之间的连接和配置相对固定。

这导致了以下几个方面的问题:1、缺乏灵活性:在传统网络中,添加、删除或修改网络资源需要对物理设备进行手动配置,这一过程耗时且容易出错,难以快速适应业务的动态变化。

2、可扩展性受限:当业务规模增长时,传统网络的扩展往往需要大规模的硬件升级和复杂的布线工作,成本高昂且周期长。

3、管理复杂:由于网络设备的分散管理和复杂的配置,使得网络的监控、故障排查和优化变得困难,增加了运维成本和管理风险。

二、SDN 数据中心的优势相比之下,SDN 数据中心具有以下显著优势:1、集中控制和管理:SDN 通过将控制平面与数据平面分离,实现了网络的集中控制和管理。

管理员可以通过一个统一的控制器对整个网络进行策略制定和配置管理,大大提高了管理效率。

2、灵活性和可编程性:SDN 允许通过软件编程来定义网络行为和策略,可以快速响应业务需求的变化,实现网络资源的动态分配和调整。

3、优化的流量调度:SDN 控制器能够根据实时的网络流量情况,智能地进行流量调度,提高网络的性能和资源利用率。

4、更好的可扩展性:在 SDN 架构下,新的网络设备可以轻松地集成到现有网络中,通过软件定义的方式实现扩展,无需大规模的硬件改动。

三、迁移前的准备工作在开始迁移之前,需要进行充分的准备工作,包括:1、评估现有网络架构和业务需求:详细了解传统数据中心的网络拓扑、设备配置、应用系统和业务流量模式,确定迁移的目标和需求。

SDN新网络解决方案ppt课件

SDN新网络解决方案ppt课件

Self Defined Network
可扩展 可交付
Software Defined Network
可编程
Service Defined Network
新网络技术
VXLAN NVGRE STT
定义:网络虚拟化,也 称Overlay网络,对物 理网络进行隧道叠加, 逻辑划分成虚拟网络分 片,满足基于租户的个 性化需求
最终目标:
业务部署(应用/终端)与位置无关; 对设备无命令行的手工配置,自动
开放

位址分离@IP地址与位置解耦合
传统网络
核心
A
C
汇聚 接入
10.10.0.0/16 网段
10.11.0.0/16 网段
园区控制器
ADCampus网 络
A C
Overl ay
10.10.1.1010.10.1.2010.11.1.1100.11.1.20
SDN新网络解决方案
目录
新网络新技术 H3C SDN产品体系 H3C NFV产品架构 H3C 新网络解决方案
新网络解决方案案例
IT 建设模式进入 新阶段
分散管理
精细管理
服务器 存储
融合架构 云
PCs
网络
传统IT
移动化 大数据 新IT
新IT对网络提出了新的要求-软件化、可定义、自适应 -SDN
SDN发展趋势
Leaf
Leaf
Servi ce
SLeervaifc Seervic
e
Thir
Leaf
d Part
y
vSwitc
h
北向接口: 采用标准的REST API接口实 现与虚拟化管理平台、云平 台、网络管理平台、上级 SDN控制器、应用管理平台 等第三方系统集成 采用Java API支持第三方 SDN APP

SDN、NFV及未来网络架构演进

SDN、NFV及未来网络架构演进

Domain 2.0 UDNC
? Rack Based Computer ? Rack Based Computer with dedicated Storage ? Platform Network Integration ? vLoad Balancer/v Firewall
2014 2014/2015
M/SMSC
All IP
Fixed Access with 3G/LTE (Blackbox)
EPC DPI
BRAS
CG-NAT
PE GGSN
DHCP DNS
PCRF UDB
网络域
软硬件解耦
Small Cells HetNet OS + Hypervisor COTS HW WiFi Coverage MPLS/SDN/Optical
增强网络价值
敏捷、弹性和动态的生命周 期管理 使能新兴业务和 App 安全、性能和可靠性 创造新商业模式和开发者机 会
架构和技术方向
NFV :软硬件解耦 SDN :控制面和转发面分离 NFV 和 SDN 协同,使能实时的网络
通过优化的 WAN 网络集成分布式的云
Domain 2.0 架构为先 , 支撑商业与生态建设目标
Model
DCAE
Product Inventory Service Inventory Resource Inventory Service & Network Control
… …
Prototype Deploy
向内部开发者 , 外部 第三方开放
Resource APIs Traditional Virtual Network Network
软硬件解耦

城域网BRAS向SDN演进的方法及步骤探索

城域网BRAS向SDN演进的方法及步骤探索

城域网BRAS向SDN演进的方法及步骤探索缪伟;黄鹏【摘要】近年来,SDN以燎原之势迅猛发展,重新定义了网络架构及业务模型,提出了运营集约、资源统一、网络开放的发展思路。

分析了目前城域网在网络建设、业务承载和维护管理上存在的问题和不足,从保护投资、业务保障、建设和维护成本等方面考虑,提出分3个阶段引入SDN的具体方案。

鉴于SDN目前标准和产业链尚未成熟,而且将涉及组织、运营、流程乃至产业链的重构,建议在引入时要以具体需求为导向,不宜盲目开展网络部署。

%In recent years,SDN is developed in an unstoppable way,the network architecture and service model are redefined,and the idea of developing intensiveoperation,uniform resource and network opening is put forward. Firstly,it analyzes the problems and deficiencies on the networkconstruction,service carrying and maintenance management,and puts forward the concrete scheme of introducing SDN in three stages from the aspects of protecting investment,business security,construction and maintenance costs. At the same time,the current standard and the industry chain is not yet mature,and wil involve the orga-nization,operation,process and even the industrial chain of reconstruction,and final y proposes thatthe introduction of SDN takes the specific needs as the guide,network deployment should not be blindly carried out.【期刊名称】《邮电设计技术》【年(卷),期】2016(000)002【总页数】6页(P78-83)【关键词】城域网;BRAS;SDN;NFV;vBRAS;阶段化【作者】缪伟;黄鹏【作者单位】中国电信股份有限公司江西分公司,江西南昌330002;江西省邮电规划设计院有限公司,江西南昌330002【正文语种】中文【中图分类】TN919.21关键词:城域网;BRAS;SDN;NFV;vBRAS;阶段化In recent years,SDN is developed in an unstoppable way,the network architecture and service model are redefined,and the idea of developing intensive operation,uniform resource and network opening is put forward.Firstly,it analyzes the problems and deficiencies on the network construction,service carrying and maintenance management,and puts forward the concrete scheme of introducing SDN in three stages from the aspects of protecting investment,business security,construction and maintenance costs.At the same time,the current standard and the industry chain is not yet mature,and will involve the organization,operation,process and even the industrial chain of reconstruction,and finally proposes that the introduction of SDN takes the specific needs as the guide,network deployment should not be blindly carried out. Keywords:MAN;BRAS;SDN;NFV;vBRAS;Stage自从SDN面世以来,就被视为继云计算后又一IT革命。

从传统网络架构到SDN化演进方案

从传统网络架构到SDN化演进方案

从传统网络架构到SDN化演进方案甜橙金融数据中心演进之路前言:网络世界每一次技术变革都需要大量时间来验证,虽然更多的技术达人对于新技术的接受能力在不断提高,但新技术的普及和应用依然需要花费大量时间。

企业在发展过程中缩减预算的需求不断扩大,企业员工则通过自动化的维护平台设施来简化操作步骤,而网络世界的争论点主要集中在如何从使软件定义网络与网络虚拟化的新架构代替传统以太网架构。

STP架构网络的替代品Fabrics具有可扩展、高带宽的架构。

对于SDN来说,SDN可能不像一个产品,更像一种架构。

首先我们来看一下SDN与传统网络架构的区别:一、传统数据中心网络架构逐渐落伍在传统的大型数据中心,网络通常是三层结构。

架构模型包含了以下三层:∙Access Layer(接入层):接入层位与网络的最底层,负责所有终端设备的接入工作,并确保各终端设备可以通过网络进行数据包的传递。

∙Aggregation Layer(汇聚层):汇聚层位于接入层和核心层之间。

该层可以通过实现ACL 等其他过滤器来提供区域的定义。

∙Core Layer(核心层):又被称为网络的骨干。

该层的网络设备为所有的数据包包提供高速转发,通过L3路由网络将各个区域进行连接,保证各区域内部终端设备的路由可达。

一般情况下,传统网络还存在着一些优点:∙精确的过滤器/策略创建和应用:由于区域、终端地址网段明确,可以精细控制网络策略,保证流量的安全。

∙稳定的网络:区域的明确划分,网络设备的稳定架构,使网络更具有稳定性。

∙广播域的有效控制:由于三层架构中间采用L3模式设计,有效控制广播域的大小。

传统网络架构虽然稳定,但随着技术的不断发展,应用不断的多元化以及对业务的高冗余化的需求,暴露出了一些传统网络的弊端。

随着公司的发展,传统网络架构渐渐开始无法跟上步伐,逐渐出现了以下问题:1业务流量模型不清晰随着网络的发展、各种新技术的产生,数据中心内部、服务器之间协同处理、计算,导致由东向西的流量逐渐增大,超过了由南向北的流量。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

从传统网络架构到SDN化演进方案甜橙金融数据中心演进之路前言:网络世界每一次技术变革都需要大量时间来验证,虽然更多的技术达人对于新技术的接受能力在不断提高,但新技术的普及和应用依然需要花费大量时间。

企业在发展过程中缩减预算的需求不断扩大,企业员工则通过自动化的维护平台设施来简化操作步骤,而网络世界的争论点主要集中在如何从使软件定义网络与网络虚拟化的新架构代替传统以太网架构。

STP架构网络的替代品Fabrics具有可扩展、高带宽的架构。

对于SDN来说,SDN可能不像一个产品,更像一种架构。

首先我们来看一下SDN与传统网络架构的区别:一、传统数据中心网络架构逐渐落伍在传统的大型数据中心,网络通常是三层结构。

架构模型包含了以下三层:∙Access Layer(接入层):接入层位与网络的最底层,负责所有终端设备的接入工作,并确保各终端设备可以通过网络进行数据包的传递。

∙Aggregation Layer(汇聚层):汇聚层位于接入层和核心层之间。

该层可以通过实现ACL 等其他过滤器来提供区域的定义。

∙Core Layer(核心层):又被称为网络的骨干。

该层的网络设备为所有的数据包包提供高速转发,通过L3路由网络将各个区域进行连接,保证各区域内部终端设备的路由可达。

一般情况下,传统网络还存在着一些优点:∙精确的过滤器/策略创建和应用:由于区域、终端地址网段明确,可以精细控制网络策略,保证流量的安全。

∙稳定的网络:区域的明确划分,网络设备的稳定架构,使网络更具有稳定性。

∙广播域的有效控制:由于三层架构中间采用L3模式设计,有效控制广播域的大小。

传统网络架构虽然稳定,但随着技术的不断发展,应用不断的多元化以及对业务的高冗余化的需求,暴露出了一些传统网络的弊端。

随着公司的发展,传统网络架构渐渐开始无法跟上步伐,逐渐出现了以下问题:1业务流量模型不清晰随着网络的发展、各种新技术的产生,数据中心内部、服务器之间协同处理、计算,导致由东向西的流量逐渐增大,超过了由南向北的流量。

而传统三层架构服务器间交换,都要过三层核心,多层转发,增大了网络的延迟,还浪费了核心宝贵的资源。

与此同时,我们将业务拆分成多个模块,并部署在不同的区域中,由于应用的不断发展,模块的数量越来越多,模块之间的调用越来越频繁,可能一次完整的应用流程需要经历数十个模块,模块之间的频繁调用大大消耗了网络设备的资源。

2横向扩展能力不足传统数据中心使用STP技术,虽然上联多根链路,但都是主备关系,仅有一根链路能跑流量,无法承载数据中心日益增长的业务。

尽管后续使用了有相关的Ethernet Channel、堆叠、VSS等技术,来达到链路冗余的需求,但是堆叠、Ethernet Channel不可能无限地进行扩展。

3广播域过于庞大随着业务的发展,计算资源被池化。

为了使得计算资源可以任意分配,需要一个巨大的二层网络架构。

整个数据中心网络都是多个L2广播域,这样,服务器可以在规定的区域地点创建、迁移,而不需要对IP地址或者默认网关做修改。

不断地业务扩展,造就了一个巨大的二层广播域,一旦出现一点问题就造成巨大的网络问题,导致业务中断,业务的高可用性就无法保证。

4计算资源无法快速上线随着业务的不断发展,计算资源的虚拟化。

当需要进行虚拟资源部署时,严格安全防护的要求下,需要进行安全设备的策略开通。

从部署到正式上线使用之间的耗时会长达1小时之久。

无法满足在突发情况下,快速增加计算资源。

由于安全设备以及设备上联位置的限制,无法在任意的计算资源池中随意的创建、迁移;无法合理分配资源池的各种硬件资源,造成资源的分配不均衡。

一旦某资源池已达阈值,就无法继续计算资源的横向扩展。

5网络延时过大在使用传统网络架构时,每个业务模块都是一个烟囱结构,业务模块互相调用需要经过多个三层设备(平均需要经过6次物理设备)其中还可能包括防火墙等安全设备。

受限于设备的性能,网络架构的主备方案。

数据流量每经过一次设备都会增加一点延迟。

虽然每一次延时都是微乎其微,但是累计次数多了,对于业务来说这个延时可能就导致用户体检较差。

二、SDN网络带来的好处通过了解,我们深知自己的传统网络存在着一些问题,于是进行了各种技术可行性测试。

为了不断提升网络的承载能力,制定过多种方案,例如:传统网络的优化、当前网络的SDN化等。

最终在机房网络架构设计中,我们开始和思科进行了比较深度的合作。

目前,我们是全球第三个大规模采用了思科ACI网络技术的公司。

思科APIC(Application Policy Infrastructure Controller)是以应用为中心的基础架构(ACI)结构的自动化和管理的统一集中点,提供对所有节点信息的集中访问控制,优化应用的规模和性能,并支持在物理和虚拟资源之间进行灵活的应用配置。

管理员可通过APIC提供各种丰富的API接口对设备进行配置、管理、策略下发等操作行为;控制器则通过OpFlex协议将策略推送给ACI环境中的各个节点Leaf。

虽然APIC会将策略推送到各节点Leaf 上,但控制器并不参与任何流量的转发,所以即使发生有5台控制存在问题的极端情况下,网络层面的流量转发功能还是可以正常稳定地运行。

最终我们在南京节点完成了SDN网络的架设,并且通过上云的最终决战8小时,完成了业务的整体迁移。

虽然看起来这场战役惊心动魄,但我们的内心深处并没有太大波动,毕竟从开始POC到现在完成网络搭建,我们历经了1年时间的充足准备。

特别是在前期的POC期间,我们对于一个新技术的不断研究,夜以继日地不断测试各个应用场景,换来了一次成功的战役。

网络SDN化之后,我们解决了以前的一些问题,同时也提供了更人性化的管理方式。

下图是我们网络架构内部示意图:1业务流量的明确划分将原有业务划分从一个应用一个区域的划分方式,在使用SDN后,变更为一个服务体系作为一个区域进行划分(例如:APP区域、数据库区域、中间件区域等)。

在每个区域中划分多个Endpoint Group (以下简称EPG)来准确区分业务模块,更清晰地了解业务之间的访问关系。

2无限定的横向扩展在现有的SDN网络中,通过使用Anycast Gateway的方式将网关部署在各个Leaf节点上。

即使有新设备加入网络,无论处于任何区域,都可以准确的进入相对应逻辑位置。

3虚拟资源无限制的变更ACI,通过VM Networking与VCenter互相联动,并下发vNIC供虚拟机使用,虚拟机只需要选择对应虚拟网卡就可以进行业务上线。

同时各个虚拟机对应的EPG通过合约的形式开通策略。

在SDN 中所有相同业务都部署在同一个EPG中,所有策略的开通并不是基于IP地址来开通,只需要在不通的EPG之间开通策略即可,所以无需像传统网络进行IP对应的策略开放方式进行SDN网络策略开通。

虚拟化资源可以在任意宿主机上进行创建、迁移,没有任何的物理位置的限制。

4控制平面和转发平面解耦合在传统的网络交换设备中,控制平面和转发平面是紧密耦合的,被集成到单独的设备盒子中。

各个设备的的控制平面被分布到网络的各个节点上,很难对全网的网络情况有全局把控。

因此SDN网络一个重要的理念就是把每台单独网络设备中的控制平面从物理硬件中抽离出来,交给虚拟化的网络层处理,整个虚拟化的网络层加载在物理网络上,屏蔽底层物理转发设备的差异,在虚拟空间内重建整个网络。

这样一来,物理网络资源被整合成了网络资源池,如同服务器虚拟化技术把服务器资源转化为计算能力池一样,它使得网络资源的调用更加灵活、满足业务对网络资源的按需交付需求。

5集中化的网络控制将控制平面进行集中控制,中央控制器可以获取网络资源的全局信息并根据业务需要进行资源的全局调配和优化,如QOS、负载均衡功能等。

同时集中控制后,全网的网络设备都由中央控制器去管理,使得网络节点的部署以及维护更加敏捷。

由于集中化控制,ACI提供一个可视化的管理界面,通过界面中的评分以及错误,可以更有效的提供给运维工程师查找到问题的所在之处,提供一个快速定位的有效依据。

三、SDN架构的后期展望1跨厂商自动化联动思科提供了其他厂商的管理工具包供ACI使用,通过服务链(Service Chain)功能进行其他设备的配置推送。

未来整个网络的配置都可以通过ACI进行远程控制,无需通过繁琐的命令行进行配置。

即使对设备命令不熟悉的工程师也可以进行配置。

2自动化配置平台ACI提供丰富的API接口供第三方软件调用,建立一个自动化运维平台通过API接口进行ACI配置的推送、查看设备的运行状态实时体现。

可以完全掌握整个SDN的运行状况,准确及时地判断。

在问题将要发生时,得到及时的处理和解决,避免了最终解决问题已出,维护人员还未得到告警的窘相。

3各全面的网络监控在网路设备中进行流量抓取取样,通过报头分析网络中数据包的走向。

通过流量排序可以清晰的知道各个模块调用的次数,结合研发部门进行探讨,为优化网络、优化应用做一个准确的依据。

四、一些思考前面说了那么多思科ACI在架构以及后期使用过程中的体验,再联想起近期思科爆出的漏洞事件,最后想就自己的一些想法来谈谈思科Smart Install的远程代码执行漏洞:Smart Install功能是交换机在部署时配置和镜像管理功能,它可以自动换成初始化,新的交换机可以通过TFTP等协议自动加载操作系统镜像。

这就意味着在无配置的管理员的情况下启动交换机,当设备配置发生变化等情况,还可以提供配置备份的功能。

Smart Install Client默认开启TCP 4786端口,用来进行Smart Install功能。

当服务处理一段特殊的恶意信息,会发生交换机的缓冲区堆栈溢出,从而造成设备故障。

由于思科ACI通过控制器管理,无需额外的设备进行自动化配置等行为,故没有该漏洞。

相关文档
最新文档