《SDN架构与解析》由会员分享，可在线阅读，更多相关《SDN架构与解析（9页珍藏版）》请在金锄头文库上搜索。
1、.SDN 架构与解析：深度开放与融合长期以来， 网络技术总是以被动方式进展演变， 并且大量的技术革新都落地在网络设备本身，如带宽不断提升，从千兆到万兆、再到40G 和 100G;设备体系架构变化，也是为了性能地不断提升，从交换能力几十Gbps 提升到 T 级别以致 100T 级别;组网变化，网络设备的N:1 集群性质的虚拟化， 在一定围和一定规模上优化了网络架构， 简化了网络设计;大二层网络技术，通过消除环路因素，支持了虚拟化条件下的虚机大围二层扩散性计算。新的技术商用，总会引起设备的升级换代， 并且随着流量的巨大变化， 网络的部署与变更技术上越来越复杂，网络在应对流量变化上很难有良好的预期性
2、， 在当前方式下，一旦完成业务部署，效劳器通过网线连入网络，应用流量吞吐对网络的影响就难以控制、 网络的调整也就变得相当滞后。软件定义网络SDN(Software Defined Network)的出现和理念演进，开场改变网络被动性的现状，使网络具备较大灵活程度的 “定义能力;这种可定义性， 是网络主动 “处理流量而不仅仅是被动“承载流量，并使得网络与计算之间的关系不仅仅是 “对接，而是“交互。SDN 的思想集中表达在控制面与实体数据转发层面之间别离，这对网络交换机的工作方式产生了深远的影响。 高端用户原本就不满足于使用网络预先设定好的功能， 而是希望在自己的业务功能不断丰富变化的过程中， 能
3、够按照自身需求快速进展调整。 而在控制层面别离出来后，或者说控制层面可以开放出来， 更能实现虚拟化的灵活性， 使得用户能够进展程序编制， 那么基于应用与流量变化的快速响应， 便不需要完全依赖于设备供给商的长周期软硬件升级来完成。SDN 的思想是将更多的控制权交给网络使用者，除了设计部署、配置变更，还可以进展网络软件的重构， 使得新的技术验证可以先于商业化。 这种网络能够以抽象化的方式解决网络的复杂性问题， 解除了用户收支网络功能和特性的紧约束， 能够在更高层面研究和满足项业务需求。当前主流当前主流 SDNSDN 的概念探讨的概念探讨最经典的SDN架构描述是来自ONF(Open Network
4、Foundation)的SDN体系架构图(如图1 所示)。-.jz*.图 1 SDN 体系架构图 1 表达了 SDN 的分层解耦合概念，包括通用的根底硬件层、硬件抽象层、网络操作系统、上层应用。其中根底硬件与硬件抽象两层组成物理网络设备，也就是SDN 架构中的数据转发层面;网络操作系统与上层应用组成了控制层面。数据转发层面与控制层面之间以一种标准化的交互协议来解耦合，此协议当前为 OpenFlow。这种去耦合的架构，说明网络操作系统及网络应用(如路由控制协议等)不必运行在物理设备上， 而可以运行在外部系统(如X86 架构的效劳器)，从而实现网络控制的灵活可编程性。除了解耦合控制层面与数据转发层
5、面， SDN 还引入了集中控制的概念(如图 2 所示)。对于传统的设备，因为不同的硬件、供给商私有的软件，使得网络本身相对封闭，只能通过标准的互通协议与计算设备配合运行。 网络中所有设备的自身系统都是相对孤立和分散的， 网络控制分布在所有设备中，网络变更复杂、工作量大，并且因为设备异构， 管理上兼容性很差，不同设备的功能与配置差异极大;同时网络功能的修改或演进，会涉及到全网的升级与更新。而在 SDN 的开放架构下，一定围的网络(或称 SDN 域)，由集中统一的控制逻辑单元来实施管理，由此解决了网络量设备分散独立运行管理的问题，使得网络的设计、 部署、运维、管理在一个控制点完成， 而底层网络差异
6、性也因为解耦合的架构得到了消除。 集中控制在网络中引入了 SDN 区别于传统网络架构的角色SDN Controller，也就是运行 SDN 网络操作系统并控制所有网络节点的控制单元。SDN 能够提供网络应用的接口，在此根底上按照业务需求进展软件设计与编程，并且是在SDN Controller 上加载，从而使得全网迅速升级新的网络功能，而不必再对每个网元节点进展独立操作。-.jz*.图 2 封闭式网络与开放网络分层解耦合架构中采用了OpenFlow 的协议来别离网络的控制与转发层，图3 是来自斯坦福的一图说明 OpenFlow 的解耦模型。图 3 OpenFlow 协议工作模式网络设备(图 3
7、中OpenFlowSwitch)由标准的网络硬件和支持OpenFlow代理的软件构成。OpenFlow 定义的网络硬件，不是传统的交换模式，而是以一种流表的方式来进展数据的转发处理，非常类似于当前交换机使用的TCAM 对数据流的分类与控制行为，每一个网络中的流均由流表中的规那么来控制处理，可以到达极精细的粒度。OpenFlow 协议定义了一种通用的数据平面描述语言， 设备上的 OpenFlow 代理软件通过与 OpenFlow Controller 建立平安加密(如 SSL 通信机制)通信隧道来承受对设备的控制转发指令。所有的流表指令均被定义成标准规， 通过 Controller 与代理之间的
8、加密协议可靠传递。 Controller 上运行的各种网络应用，均被转换成OpenFlow“指令集下发，从而易于实现标准化的模式，这使得OpenFlow成为 SDN 架构下的重要技术。OpenFlow 以一种比拟理想的形式定义了网络设备的供给方式，但这种定义使得网络不是一个平滑升级和演进，而是一个颠覆性的更新，现有网络不能通过OpenFlow 来升级，而是需要被完全替换。同时，OpenFlow 设备是一种流表转发，也需要新的体系架构来设计网络芯片，虽然现有 TCAM 技术能支持 OpenFlow 的特性，但是功能不完备、大TCAM 表项设备极其昂贵。因此，当前的OpenFlow 设备，根本是在
9、传统网络根底上支持 OpenFlow 协议，规格受限的初期产品。OpenFlow 的设计思路表达了 SDN 架构，但是，这种思路只表达了集中控制的优势， 对于网络的运维管理并没有深入考虑， 管理通信如何采用 OpenFlow 并与正常业务流的别离， 是否-.jz*.覆盖替代还是与传统 SNMP/NETCONF 的管理方式，集中的OpenFlow Controller 与分散的OpenFlow 网络设备之间采取一种如何的管理方式更优，还需要OpenFlow 本身的技术不断实践来印证。OpenFlow 在协议定义上还不完善，针对已有网络特性的定义还在补充变化，容变更会不断持续，并逐步形成不同的技术
10、版本，这使得软件和硬件在配套兼容上存在较大的问题，这也是 OpenFlow 作为 SDN 协议的在网络应用覆盖不全方面的严重缺乏。H3C SDNH3C SDN 总体架构与策略总体架构与策略2.1 H3C SDN2.1 H3C SDN 总体架构与策略总体架构与策略H3C 在基于全网端到端的总体网络架构上，将会交付一个逐步开展丰富的SDN 产品与解决方案集。(如图 4 所示)H3C SDN 当前提供三大方案集：基于 Controller/Agent 的 SDN 全套网络交付、基于 Open API 的网络平台开放接口、基于OAA 的自定义网络平台。在这三大方案集成根底上， 构建一个标准化深度开放、
11、 用户应用可融合的 NPaaS(Network Platform asa Service)网络平台即效劳的 SDN 体系，既具备H3C 已有的优势网络技术方案，又能在各种层次融合与扩展用户自制化网络应用。图 4 H3C SDN 总体架构-.jz*.2.22.2 基于基于 Controller/AgentController/Agent 的的 SDNSDN 全套网络交付全套网络交付在上述 SDN 根本体系架构定义的框架下， H3C 提供与此一致的方案架构。 如图 5 所示，H3C 将在同一 SDN 的架构下，除了支持标准化的OpenFlow 协议，并提供基于H3C 自身成熟技术的自有协议 RIP
12、CRIPC(Remote IPC)。图 5 Controller/Agent 的 SDN 网络H3C 将提供标准化的系列化 Controller 部件， 能够以 OpenFlow 协议进展 OpenFlow 设备的集中控制，对上层提供灵活的开放接口， 以满足各种网络应用的调用需求。 在当前网络产品逐步集成 OpenFlow 特性，满足初始 OpenFlow 网络部署需求，并逐步丰富OpenFlow 的产品组成，如图 6 左图构建了整体 OpenFlow 的 SDN 网络。针对 H3C 优势技术 IRF 的进一步强化，基于Controller/Agent 架构，以 H3C RIPCRIPC的协议
13、实现了 VCF 的技术，如图 6 右图所示，使用多台 S5820V2 组成的 IRF 构造体工作为网络的 Controller 角色，下联多台 S5120HI。-.jz*.图 6 H3C SDN 网络的两种实现VCF 采用 SDN 架构的 N:1 网络虚拟化，不仅将多台同一网络层面的设备整合，也将另一层次的设备整合， 整个网络运行如同一台大型框式设备， 运行管理各种操作均被虚拟化在一台大型设备。所有的控制、设备管理均在 S5820V2 的 IRF 组上，其它的 S5120HI 运行为线卡模式。 在这种 SDN 架构下， H3C 的 RIPC 协议消除了 OpenFlow 协议在效率与管理上的缺
14、乏，并有效继承了 H3C ware 平台的原有 IRF 优势。2.32.3 基于基于 Open APIOpen API 的网络平台的网络平台SDN 最重要的网络需可编程性，即用户可以在自身业务变化的情况下，根据需要自行软件开发，这种需求的核心是网络要有灵活开放的接口提供给用户的编程实现。H3C 实现了多层化的 Open API 方案(如图 7 所示)。根底设备层面可以提供深度的SDK 级标准化 VCC 网络应用(VCC: Virtual putingContainer 虚拟计算容器)， 并提供高级XML的访问操作NETCONF标准接口体系， OpenFlow也是设备层面提供的一种标准接口模式;
15、设备控制层面(SDN Controller)，作为网络操作系统，标准化的接口依据 Controller 的不同实现，对外可提供 VCC、REST/SOAP、NETCONF、OpenFlow 等。Open API 与 H3C 系统(ware/iMC)部集成(Integrated)API(如 RIPC)相辅相成，构建差异的SDN 架构，并在不同层次形成自有系统及对外开放与标准化，使得不同用户的可编程与应用变化性需求得以满足。-.jz*.图 7 H3C 多层化的 Open API在 Open API 接口中，REST/SOAP 是常规的高层协议编程接口，NETCONF 是网络设备上新兴的 XML 语
16、言编程接口，OpenFlow 是 SDN 的一种协议，以上均是通用化的技术实现，VCC 那么是 H3C 在长期网络软件技术积累过程中形成的一种更为底层的标准化实现。wareV7 是基于 Linux 核实现的新一代云计算网络操作系统， 当前的架构， 基于类 POSIX的 Linux 接口及扩展形成一套开放的 SDK，H3C 提供了含 SDK 的接口描述、调用库、编译环境等完备的编程环境，使得用户可以使用C/C+以几乎完全等同于 Linux 系统下的环境进展自己的网络应用程序软件开发，而wareV7 那么为用户的软件运行提供了一个完整的系统环境，如图 8 所示。图 8 VCC 运行-.jz*.在
17、VCC 环境中， 用户程序包可独立加载到设备上运行， 软件可以不连续业务升级。 wareV7 提供接口给用户，软件设计可以一定程度上访问底层硬件，对 路由、MAC 等硬件表项进展操作， 或者设备的配置变更及相应状态监控等， 同时还可以利用 ware V7 现有的特性来辅助实现用户业务，从而实现用户软件定义网络的真正需求。2.42.4 基于基于 OAAOAA 的自定义网络平台的自定义网络平台早期，H3C 提出了开放应用架构(Open Application Architecture)的网络模型，即在 H3C的网络设备中提供具有计算能力的线卡， 用户可以在其上开发自己的特殊应用， 并通过 H3C的
18、 OAA 关联协议与网络进展数据交互。基于 SDN 的架构思路，H3C 演绎了更灵活的用户化网络设计，实现的OAA 新的业务模式，可以方便用户灵活实现自定义的网络功能。在OAA 根底上，提出了两种开放式的接口模型，如图 9 所示。图 9 左图，显示了一种全松耦合的OAA 架构。针对用户任意形态运行的网络业务，可能是在效劳器上的计算业务(如流量监控分析、 数据旁路挖掘)，也可能是专用的业务设备(如防火墙、IPS、加密机、 数据压缩机)，用户设备可以支持标准的OpenFlow 协议，即可与 H3C网络进展通信， 在 OpenFlow 协议中传输业务指令， 对需要处理的网络流量进展镜像、 牵引、封装
19、、 定向等操作， 将清晰定义的数据流以适宜的方式导引到用户的计算设备进展自定义处理。这种方案的本质是，借助SDN 的模型，将用户的数据处理设备运行为SDN Controller方式，而对特定业务流进展处理。图 9 右图，显示了一种紧耦合的OAA 架构，其中分两种模式：模式一，用户自设计提供高性能计算单元子卡，H3C 提供 OAA 的线卡底板，两者以开放的标准化电气接口连接器相连，用户计算单元与网络之间依然通过标准的OpenFlow 方式进展网络流量的引流操作，而软件、硬件均由用户自身根据业务需求来设计;模式二，H3C 提供了整体的 OAA 线卡，用户基于 H3C 的硬件来开发自己的软件， 在协议上仍然采用OpenFlow 的方式进展特定数据处理。-.jz*.图 9 基于 OAA 的自定义网络平台完毕语完毕语SDN 是一个广泛的网络体系架构，需要通过灵活开放的构造来实现用户需求，H3C 的技术模式，是在不同的网络层面、 不同的体系架构上均可提供用户需要的接口与业务环境， 同时H3C 本身也提供基于 SDN 的用户网络应用。-.jz*
