《云数据中心网络与SDN:技术架构与实现》——3.3.4 可视化

举报
华章计算机 发表于 2019/06/06 14:47:56 2019/06/06
【摘要】 本书摘自《云数据中心网络与SDN: 技术架构与实现》——书中第3章,第3.3.4节,作者是张晨。

3.3.4 可视化

传统数据中心里,网络运维一直是件“很痛”的事情。网络是数据中心正常运转的基础,网络状态正常时对业务是透明的,一旦网络出了问题,很多技术团队就会找上门来。小至服务器分不到IP、Web访问迟缓,大至数据库连接不稳定,甚至业务的大面积瘫痪,网络运维人员不得不独自对着大量的网络设备进行故障的排查。尽管网络设计已经想尽了一切办法去缩小故障域,但是一个小问题的排查很可能需要花上几个小时的时间,稍有不慎,一条配置出了错,还有可能引发更为严重的问题。有时候花了几个小时去排查网络,但最后发现问题根本就不是出在网络上。在人们的印象中,网络总是“最不靠谱”的,出了问题首先归因于网络也是人之常情。

云数据中心里,虚拟机的数量和网络的规模数倍于传统数据中心,再加上业务对于敏捷性和高可用的要求,网络运维如果不能变得更为智能、自动化,那么一旦发生网络故障,云中的业务可能会受到毁灭性的打击。而且,虚拟交换机的引入会使得网络故障的排查变得更加困难,一方面管理的边界从物理网络延伸进了服务器,另一方面也对网络运维人员的技能提出了新的要求。

传统的网管其实一直就定位于简化网络的运维,不过由于网络一直不够开放,各大厂商设备网管接口区别巨大,网管能采集上来的数据很多,但是难以进行有效的整合,基本上就是出了问题进行告警,并不具备故障的分析、定位和自动纠错的能力。SDN提出后,网络变得更加标准、开放,控制器通过全局的网络视图就能将部分运维的功能自动化。全局视图的形成依赖于控制器的可视化能力,而可视化能力主要包括网络可视化和流量可视化两个方面。

1.网络可视化

网络可视化又可分为网元可视化和组网可视化。网元可视化要求控制器能够与设备进行交互,采集设备的运行时数据,如电源、背板、CPU、内存等基础硬件的状态,Up/Down、收发包速率、丢包率等端口状态,以及MAC表、BGP表等转发表项的状态。另外,控制器作为SDN中最为关键的网元,其自身的状态、性能、异常记录和管理日志也需要进行全面的维护。

和传统网管做网元可视化的目的不同,SDN控制器采集到设备运行时的数据,会将其用于控制的反馈和优化,比如通过buffer当前的载荷情况来优化传输路径,因此对数据采集接口的实时性要求较高。SNMP的通用性较强,但是Polling的效率低,Push的功能弱,无法实现实时数据的采集。NETCONF普遍被看作SNMP的代替者,但实际上其优势在于事务性的配置,在监测和可视化方面相比SNMP并没有明显的优势,尽管通过Subscribe/Notification对Push模型进行了增强,但是由于采用了XML的数据格式,因此在序列化/反序列化性能上存在着明显的瓶颈,同样无法胜任对实时性要求较高的场景。至于OpenFlow/OVSDB,由于二者对于设备的资源建模侧重于转发方面,对设备本身缺乏足够的描述能力,因此并不适合做网元的可视化。目前,业界正在推动采用gRPC来传输实时数据。gRPC采用ProtoBuffer作为数据格式,序列化/反序列化的性能很高,对于Push模型的支持也更好。因此,gRPC已被普遍视为实现Telemetry数据采集的标准传输技术,各个主流厂商的设备和一些SDN控制器都已经对gRPC提供了支持。

组网可视化要求SDN控制器能够全面地了解网络的物理结构和逻辑结构。网络的物理结构主要就是指拓扑。拓扑发现有两种思路:一种是由控制器集中式地进行探测和计算,在这种方式下,控制器能够主动地参与到拓扑发现中,但是控制器上的处理压力较大。另一种是由设备运行分布式的协议获取拓扑,然后再以某种方式将拓扑告知控制器,在这种方式下,控制器只能被动学习拓扑,但是控制器上的处理压力得以减小。网络的逻辑结构主要是指IP编址和路由,对于虚拟化环境而言,还包括租户标识的分配、虚拟机的位置分布、虚拟机间的通信策略、虚拟机间通信所走的路径等。对于网络中任何一个虚拟机或者任何一个IP地址,SDN控制器应该可以明确地指出其所在的服务器;对于网络中任意两个虚拟机或者任何两个IP地址,SDN控制器应该明确知道二者是否可以进行通信,如果可以通信,应该明确两者之间通信的逐跳的路径。这不仅要求控制器能够衔接起南北向接口提供的信息,还需要将Overlay和Underlay进行关联。当底层网络中存在ECMP时,控制器需要对哈希算法的结果进行预判,或者通过探针来探测Underlay中真实的转发路径。

2.流量可视化

网络可视化关注的是网络本身,而流量可视化关注的是用户使用网络的行为,如大象流统计、分类流量统计、流量分时走势等。理论上来说,上述功能都可以通过SDN控制器集中式地实现,但是考虑到流量的数据量级,往往需要通过部署独立的流量分析软件来实现。有很多的商用/开源的产品可供选择,这些软件将处理的结果反馈给SDN控制器,有助于实现更为精准的网络控制与优化。

“流”层面的分析可使用传统的NetFlow、sFlow来实现,设备会对流量进行采样和统计,然后将结果返回给相应的分析软件,这种实现方式中交换机/路由器直接参与到了流量的分析中。gRPC同样可以用于流量的可视化,可以根据五元组或者其他特征来对流量进行实现采集与推送,实现实时的Telemetry。不过“流”仅关注的是L2~L4的特征,如果要看到应用层面的特征,就需要通过部署深度包检测(Deep Packet Inspection,DPI)来实现了。DPI的部署思路有两种:一种是在每个服务器上部署一个专门用于DPI的虚拟机,通过vSwitch将本地的一些流量镜像到这个虚拟机上。这种方式对vSwitch要求较低,但是需要为每个服务器额外维护一个虚拟机。另一种思路是直接在vSwitch中集成DPI的引擎,这种方式不需要额外的虚拟机,但是对vSwitch的要求非常高。在一般情况下,会采用第一种思路来部署DPI,但DPI的使用需要占用服务器上大量的计算资源,会在一定程度上影响服务器承载虚拟机的能力。

如果想要对流量进行更深层次的分析,如安全威胁诊断或用户行为跟踪,就需要借助专业的分析软件来进行处理了,此时交换机/路由器主要负责将流量镜像并导入专业的分析软件中,而并不直接参与流量的分析。导入的方式分为带内和带外两种,带内方式镜像流量与业务流量共存于一张网络中,这就需要SDN控制器对它们进行区分,并对镜像流量进行适当的引导。带内方式的优点是组网简单,缺点是镜像流量会占用业务流量的带宽,需要配合QoS来实现业务流量与镜像流量的隔离。相反,带外方式中镜像流量会有独立的网络进行传输,带外方式的优点是镜像流量不会占用业务流量的带宽,缺点是独立组网会带来额外的成本。

对于政府、电信和金融几类行业的数据中心来说,流量可视化的需求非常强烈,能够接受独立为镜像流量组网的成本,因此可以选择通过带外方式进行流量的导出。此类网络的设计既可以选择传统的方式,也可以选择SDN。使用SDN的好处在于可以方便地模拟NPB(Network Packet Broker)设备的功能,通过对镜像流量进行汇聚、分类、过滤、负载均衡等操作,将流量有针对性地导出到合适的流量分析软件上,能够有效地提高流量分析软件的工作效率。继网络虚拟化之后,NPB很有可能成为SDN的另一个杀手级应用。

做好了上述的可视化工作,就能够得到网络/流量的当前状态和历史数据,这些数据是海量的、细碎的,但是其中蕴含着巨大的价值,为网络的排障和优化提供了基础。网络常见的故障包括网络拥塞、设备/链路故障、路由黑洞/环路/震荡等。通过将这些故障的定位和成因分析返回给控制器的控制逻辑,即可对部分故障进行自动的修复,以实现闭环的自动化运维。进一步地,可以结合大数据和机器学习对原始的数据进行处理,以呈现出更为有价值的信息,比如通过大数据分析出攻击的发生,并反馈给SDN控制器丢弃嫌疑流量,或者通过机器学习分析出用户应用的行为模式,增强网络对于所承载的应用的理解,有针对性地优化资源在应用间的分配。


【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。