虚拟网络中可视性平面提高性能和安全性

软件定义网络(SDN)和网络功能虚拟化(NFV)可以带来很多好处,但增加网络抽象层是有代价的:对物理层链路的流量的可视性。

同时,越来越快的网络也加剧了这一挑战,因为现在几乎没有网络监控、管理或安全工具可以在40Gbps或100Gbps运行。网络数据包中转(NPB),也被称为网络可视性控制器,它可以通过捕捉、过滤、聚合和优化流量来解决这个挑战。这可以使1Gbps和10Gbps性能管理和安全系统在40/100Gbps网络运行。但这些物理NPB能否有效在虚拟网络基础设施运行?并且,NPB功能本身是否可以虚拟化以用于软件定义网络中的“白盒”交换机吗?

第一个问题的答案取决于用于创建虚拟网络流量的工具和协议的要求。很多网络和应用性能管理及安全工具需要从物理链路的总流量隔离个别流量或会话。

为了适应这一需求,NPB一直支持各种网络分段、封装和隧道协议,例如虚拟局域网、多协议标签交换和GPRS隧道协议。但比这些协议(特别是协议生态系统不断发展)更重要的是能够在2层网络到7层网络检测和识别数据包,还有可以灵活地配置和编程NPB来剥离和切片数据包以优化监控应用程序,以及支持新兴协议,例如VXLAN。

NPB必须还支持其他方法以提供对虚拟化基础设施中流量的可视性。例如,思科和VMware虚拟交换机让应用编程接口(API)可用于虚拟镜像或SPAN端口。主机服务器内的vSwitch将流量从虚拟SPAN端口导向物理监控基础设施,从而在单个高性能带外可视性平面或监控架构提供物理和虚拟网络可视性。

这种配置不仅不需要用于网络监控的虚拟机,而且还不需要任何主机资源,这是完全无代理的方法,不会占用管理程序的额外负载。但这种配置的缺点是,当vSwitch超载时,数据包时间戳变得不精确,即使虚拟SPAN端口负载明显小于在混杂模式运行vSwitch。监管有此限制,虚拟SPAN功能确实可以提高虚拟应用程序(完全在虚拟交换机内)间流量的可视性。

使用单独物理元素(例如管理NIC)从虚拟SPAN端口导向流量可以避免纯软件做法的两个额外的问题:不能确保全面的可视性,因为这是使用尽力传输来跨网络流量的相同端口转发复制流量;以及通用路由封装(GRE)来分离复制流量会导致大型数据包的碎片,因为必须遵守网络的最大传输单元(MTU)。

由于虚拟网络作为到物理网络的辅助或者覆盖,同样重要的是提供物理链路层可视性,特别是对于性能管理和安全工具。现在NPB可以很好地处理这些需求,对于SDN和NFV,这些相同的要求将继续存在。

对于虚拟化NPB功能本身的第二个问题,开放网络基金会(ONF)在2014年3月推出了Sample Tap应用程序,而OpenFlow 1.4版本已经包括一个用例,用于使用类似NPB的功能来配置交换机。

ONF承认其Sample Tap并不是用于在生产网络中发挥作用,而是作为一种教学工具来帮助程序员利用OpenFlow和OpenDaylight。NPB的配置和控制被虚拟化作为这项工作的一部分,而专门的NPB或者在“白盒”硬件中运行的简装NPB则可以处理对流量的实时线速复制和转发。

供应商和一些用户,特别是运营商和大型企业,需要考虑的问题是,构建自己的监控系统是否更具成本效益。部署示例应用程序完全不同于部署矩阵交换机或部署商品交换机平台用于生产网络——尤其是运行40Gbps或100Gbps的网络。

就目前而言,基于交换机的监控系统有局限性,并需要进行显著的业务变更。基于交换机的系统需要NPB来支持精确时间戳或高级功能,例如流量感知负载均衡和优化。这些功能可以帮助让1/10Gbps工具有效地在40/100Gbps网络运作。即使交换机性能提高,矩阵交换机将继续在单独的硬件运作以保持所有监控流量不在生产网络。

通过利用两层部署,即基本虚拟可视性层聚合端口和转发流量到高级层来提供更深入的可视性、流量疏导和/或更高的性能,企业可以直接从虚拟主机捕捉更多流量。

与此同时,基于交换机的监控系统和专用NPB将会变得越来越开放,超越SDN协议和网络虚拟化标签,并暴露自己的API。这种分层的原因在于,专用NPB更符合成本效益,因为他们不需要另外的软件开发人员,或者需要摒弃网络架构,而部署新的但未必更有效的架构。

最后,很显然的是,网络解决方案需要接受迁移到SDN和NFV作为降低资本支出和运营费用的方法。在迁移过程中,新方法需要能够提高性能和成本效益,而不需要转移这些支出到软件开发团队,而不需要昂贵的新的运营模式,或者部署新的硬件和软件仅仅是复制可视性平面的一部分。

网络数据包代理创建的可视性平面现在是新的更高效运营模式的一部分,其本身必须也能够像生产网络一样适应网络虚拟化。出于这个原因,NPB应该成为SDN和NFV规划的组成部分,其中可视性平面在虚拟化基础设施中利用API来为基本用例提供成本效益解决方案,同时提高硬件加速的使用来实现高级功能、安全和高性能部署。

原文发布于微信公众号 - SDNLAB(SDNLAB)

原文发表时间:2014-11-17

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏编程

前端开发的中年危机

最近一年前端也在飞速发展着, 很多前端(比如我)感觉有时候就会莫名其妙的冒出各种不明觉厉的概念: redux刚看了一点, 突然不知道哪来的mobx, rxjs...

2307
来自专栏程序员互动联盟

微信为啥能同时支持这么多人在线?

微信——腾讯战略级产品,创造移动互联网增速记录,10个月5000万手机用户,433天之内完成用户数从零到一亿的增长过程,千万级用户同时在线,摇一摇每天次数过亿....

4964
来自专栏云计算D1net

移动云应用的开发与管理

云计算与移动性这两大技术的交叉必然是炙热异常的,而这也是应用程序开发人员和规划人员所面临的一大挑战。因为移动应用程序更具自发性和个性化,所以它们成为了云计算支持...

44910
来自专栏ImportSource

CI漫谈

持续集成(CI)在软件开发中是一个流行的技术,特别是伴随着微服务以及devops,这个名词被吵得更火了,在各种大会上人们都会谈到他们自己是怎么玩的,而且持续集成...

2895
来自专栏原创1

百度智能运维的技术演进之路

随着大数据、人工智能、云计算技术的日渐成熟和飞速发展,传统的运维技术和解决方案已经不能满足需求,智能运维已成为运维的热点领域。同时,为了满足大流量、用户高质量体...

2670
来自专栏DevOps时代的专栏

DevOps 与技术雷达

? 关于 Kubernetes Kubernetes 现在是当仁不让的首选容器编排平台,在技术雷达中,也将其标记为采用。社区也发展出很多 Kubernete...

2568
来自专栏Golang语言社区

如何让服务器从30台缩减到2台的:从Ruby迁移到Go语言

我们开发第一版的IronWorker已经是3年前的事了,是用Ruby写的,API基于Rails开发。我们没用多久就发展成了相当大的规模,很快我们就触及到了Rub...

39515
来自专栏Android 开发者

[译] 更好的数据,更明智的决策:Google Play Console 和 Firebase 帮你分析你的用户

作者:Tom Grinsted(Google Play Console 的产品经理)和 Tamzin Taylor(Google Play 西欧区应用及游戏部主...

2142
来自专栏跨界架构师

[译文]Domain Driven Design Reference(五)—— 为战略设计的上下文映射

  两个组之间的关系是“上游”小组的行为影响“下游”小组的项目成功。但下游的行为并不会显著影响上游项目。(例如,如果两个城市沿着同一条河流,上游城市的污染主要影...

742
来自专栏数据派THU

【数据蒋堂】报表的数据计算层

来源:数据蒋堂 作者:蒋步星 本文长度为1600字,建议阅读4分钟 本文从四个方面分析独立计算层的优势。 [导读]我们在上一期【数据蒋堂】报表应用的三层结构一文...

2096

扫码关注云+社区

领取腾讯云代金券