基于SDN,NFV的服务感知网络架构下篇

简介:

本篇文章是继《基于SDN,NFV的服务感知网络架构上篇》对DPI进行进一步的深入解析,分析了在SDN中可能出现的三种部署情况,对第4-7层的业务需求以及业务感知网络架构作了一个深入的介绍。

基于SDN,NFV的服务感知网络架构下篇

在SDN网络中部署DPI

SDN架构包括四个或者更多的层次,包括业务流层,业务应用层,控制层和节点层。下图表示了DPI在用于流量整形、用户分析、QoE和网络安全时可能被嵌入的三个层,仅举几例。这些部署方案允许DPI信息在网络内共享,这样只要进行一次应用识别即可,从而节省了CPU和能耗。统一的DPI简化了管理,因为所有的设备对信息流会共享一个“相似的观点”。拥有提供DPI服务的基础设施最主要的好处是,应用程序开发者不再需要把DPI合并—没有必要推倒重来。

DPI capacity scales up and out with Qosmos ixEngine

三种可能的部署情况:

业务应用层

DPI软件可以相对轻松地被嵌入到业务应用层。然而一些应用程序的重新设计可能需要尽可能减小由于漫长的通信路径造成潜在瓶颈的影响。比如,一些信息流必须通过由节点到SDN控制器再到运行DPI引擎的应用程序这样的路径。信息流被识别后,应用程序发送策略规则到节点引导信息流的流动,所以通常情况下只有一小部分的流量从节点发送到应用程序网络。考虑到可能有延迟,这种DPI部署最好用于时效性不强的应用程序,如分析功能。

控制层

DPI软件可以部署在SDN控制器中,它可以将网络智能应用于自己的控制服务,或者通过北向接口的API发送到网络应用层。节点(例如交换机,网络设备)处理流发送的第一个非空包到SDN控制器用于L4-L7分析,可能使用了OpenFlow协议的一些扩展功能,后文会继续讨论。把DPI放置在控制器中避免了节点带来的成本增长;但是,部分信息流(可能低于10%)必须被转发,从节点到控制器,这可能导致可扩展性和性能的一些问题。一个分布式控制器架构的设计可以最大限度地减少这些问题。

节点层

网络节点也可以运行DPI软件,识别应用程序ID和元数据后,它们还可以:

直接应用预先定义的策略

将此信息发送到SDN控制器或网络应用程序,然后接受策略或规则。

当SDN控制器作为提取信息的接受者,它可以在与网络应用以某种形式对话之后指示节点应用特定的策略。在这之后的所有同一类型的信息流就不需要再被DPI分析了。与其他选择相比,在节点层执行DPI最小化了等待时间,但这种方法也是最昂贵的,因为它需要最大量的DPI实例在网络中。将来,DPI的实例数量可以通过标记或者传送端至端信息的方式来减少,如在最近的IETF草案通过加入网络服务报头(NSH)建议的增强建议。另外还有一些解决方法设想使用标记/标签,配置通道等。

OpenFlow的扩展需要L4-L7设备

OpenFlow作为SDN南向协议,用以携带交换机和SDN控制器之间每条信息流中提取的元数据。这个附加的L4-L7智能将扩展到现有OpenFlow协议中,超越用户可配置的n元组的形式。这些新的“L4-L7的DPI”字段可能成为通用格式,被所有的交换机,控制器和应用程序运用。

这可以在OpenFlow协议中引入的类型—长度—值元素实现,用以支持可选信息的编码,如以下字段。

规则:识别协议、应用程序(App ID)和元数据

操作:诸如丢弃数据包,封装和转发数据包给控制器,或者转发数据包到端口

统计:其中包括计算的元数据,HTTP主机名,HTTP cookie,和供应商特定属性(VSA)

下图展示了应用程序ID、元数据字段和操作如何添加到OpenFlow协议中。

OpenFlow could be extended to better support DPI technology

业务感知网络架构

运营商部署基于SDN和NFV的网络可以利用DPI实现的网络智能来提供新的服务并且可以更好地管理带宽。DPI通过帮助运营商识别和监管他们开展的广泛服务和应用,为运营商针对他们的网络提供更多的控制权。通过计算和DPI技术,这都是可以实现的。DPI将使控制器和应用程序做出更明智的决定,为网络运营商节省成本,增加创收机会。


作者:何妍 

来源:51CTO

相关文章
|
7月前
|
消息中间件 负载均衡 中间件
⚡ 构建真正的高性能即时通讯服务:基于 Netty 集群的架构设计与实现
本文介绍了如何基于 Netty 构建分布式即时通讯集群。随着用户量增长,单体架构面临性能瓶颈,文章对比了三种集群方案:Nginx 负载均衡、注册中心服务发现与基于 ZooKeeper 的消息路由架构。最终选择第三种方案,通过 ZooKeeper 实现服务注册发现与消息路由,并结合 RabbitMQ 支持跨服务器消息广播。文中还详细讲解了 ZooKeeper 搭建、Netty 集群改造、动态端口分配、服务注册、负载均衡及消息广播的实现,构建了一个高可用、可水平扩展的即时通讯系统。
877 0
|
运维 监控 负载均衡
动态服务管理平台:驱动微服务架构的高效引擎
动态服务管理平台:驱动微服务架构的高效引擎
295 17
|
7月前
|
文字识别 运维 监控
架构解密|一步步打造高可用的 JOCR OCR 识别服务
本文深入解析了JOCR OCR识别服务的高可用架构设计,涵盖从用户上传、智能调度、核心识别到容错监控的完整链路,助力打造高性能、低成本的工业级OCR服务。
339 0
架构解密|一步步打造高可用的 JOCR OCR 识别服务
|
运维 监控 负载均衡
探索微服务架构下的服务治理:动态服务管理平台深度解析
探索微服务架构下的服务治理:动态服务管理平台深度解析
|
运维 监控 安全
探索微服务架构下的服务治理:动态服务管理平台的力量
探索微服务架构下的服务治理:动态服务管理平台的力量
|
Cloud Native Java API
聊聊从单体到微服务架构服务演化过程
本文介绍了从单体应用到微服务再到云原生架构的演进过程。单体应用虽易于搭建和部署,但难以局部更新;面向服务架构(SOA)通过模块化和服务总线提升了组件复用性和分布式部署能力;微服务则进一步实现了服务的独立开发与部署,提高了灵活性;云原生架构则利用容器化、微服务和自动化工具,实现了应用在动态环境中的弹性扩展与高效管理。这一演进体现了软件架构向着更灵活、更高效的方向发展。
|
存储 Linux KVM
Proxmox VE (PVE) 主要架构和重要服务介绍
Proxmox VE (PVE) 是一款开源的虚拟化平台,它基于 KVM (Kernel-based Virtual Machine) 和 LXC (Linux Containers) 技术,支持虚拟机和容器的运行。PVE 还提供高可用集群管理、软件定义存储、备份和恢复以及网络管理等企业级功能。
4095 7
|
11月前
|
消息中间件 人工智能 监控
文生图架构设计原来如此简单之分布式服务
想象一下,当成千上万的用户同时要求AI画图,如何公平高效地处理这些请求?文生图/图生图大模型的架构设计看似复杂,实则遵循简单而有效的原则:合理排队、分工明确、防患未然。
444 14
文生图架构设计原来如此简单之分布式服务
|
机器学习/深度学习 自然语言处理 计算机视觉
RT-DETR改进策略【Backbone/主干网络】| CVPR 2024 替换骨干网络为 RMT,增强空间信息的感知能力
RT-DETR改进策略【Backbone/主干网络】| CVPR 2024 替换骨干网络为 RMT,增强空间信息的感知能力
540 13
RT-DETR改进策略【Backbone/主干网络】| CVPR 2024 替换骨干网络为 RMT,增强空间信息的感知能力
|
存储 JavaScript 开发工具
基于HarmonyOS 5.0(NEXT)与SpringCloud架构的跨平台应用开发与服务集成研究【实战】
本次的.HarmonyOS Next ,ArkTS语言,HarmonyOS的元服务和DevEco Studio 开发工具,为开发者提供了构建现代化、轻量化、高性能应用的便捷方式。这些技术和工具将帮助开发者更好地适应未来的智能设备和服务提供方式。
基于HarmonyOS 5.0(NEXT)与SpringCloud架构的跨平台应用开发与服务集成研究【实战】

热门文章

最新文章