《Cloud Native Data Center Network》读书笔记-9

第十一章 网络可视化

11.1 什么是可视化

可视化是操作员通过检查系统提供的输出来了解系统中发生了什么的一种方式。作为一个具体的例子，如果没有检查BGP进程的数据结构、包交换、状态机等，我们也可以使用设备上的显示bgp摘要命令来推断节点上BGP的整体状态。

网络操作人员目前想要去证明网络故障及其原因还是很困难的。

如果想要自动化，这还涉及到编写一个更复杂的程序，真正的现实是很多操作人员并不能将自动化真正的使用的很好。

最好列出失败会话以及失败原因的命令。这样可以避免检查日志或使用其他机制来识别故障的原因。

如果这个问题扩展到回答数万到数千个节点，您可以理解一个可视化良好的系统的目标。

监控会告诉你这个系统是否可以工作。可视化可以让您询问为什么它不工作。例如，监控可以告诉您一个BGP会话已关闭，但可视化可以帮助您回答原因。数据中心和现代应用程序架构足够大和复杂，足以留下许多未知的事物。

11.2 网络可视化的现状

SNMP——在大多数网络工作中可用于网络可观察性的工具的一个缩写。

11.2.1 SNMP的魅力

SNMP是最早开发的允许从远程系统收集数据的技术之一。在SNMP中，用于报告每个特性的数据模型——无论是接口统计信息、BGP信息，还是其他一些东西——都是由管理信息库(MIB)定义的。

每个接口在设备上都有一个唯一不变的数字。

SNMP也用一个拉模型定义，其中NMS拉信息而不是推动信息的设备。随着超大规模的路由器逐步成为市场主流，有很多信息需要检索。因此，如果您尝试过频繁地执行MIB，您有可能导致CPU超载，或者崩溃，或者饿死其他更高优先级的进程，如路由协议。这意味着监控会影响网络的稳定性。所以，需要控制协议间隔时间。

11.2.2 逐个设备的网络可视化研究方法

传统网络运营商们检查故障，会通过SSH进入不同设备里。使用ping和跟踪来确定问题的位置，网络运营商通常打开多个终端窗口，登录到某个设备或相邻的设备。然后，他们开始逐个检查每个路由器的配置和各种组件的状态，如路由表和路由协议状态，并试图隔离问题。涉及图形和SNMP警报，但是这样并没有帮助太快深入解决问题。

11.3 为什么网络很难实现可观察性？

因为路由器和交换机作为厂家设备，相对是封闭的，并不是一个开放的平台。计算节点是通用的平台，这意味着除了平台形式提供商之外的人，其他开发者也可以编写在平台上运行的软件。因此，计算节点可以通过提供多个工具，在监控方面进行创新。因为可视化信息的生成与其传输解耦，所以操作员可以以开发人员提供的任何方式收集信息，以适合操作员的方式将其打包，并使用当时合适的任何协议传输信息。但对于传统路由器交换机厂家来说，做到这点目前是不可能的。

11.4 数据中心网络中的可视化：特殊特性

困难

多路径

IP网络是在一个低密度连接的时代发展起来的。相比之下，数据中心是一个高度密集的网络。多路径是必须适用的一种方式。许多操作员使用ping来检查端点之间的连通性，但ping不会测试所有路径的可达性。因此，运营商必须改变他们寻找连接性的方式。很多常见的工具都不支持多路径的检测方式。

隧道承载

当部署网络虚拟化时，任何流行的跟踪器命令的实现都不能显示到达目标的多条路径。如果设备是单一厂家的，这些厂家可能会有能力提供相应的能力。所以无法以统一的方式查看网络路径，这使得最常见的网络故障排除工具更加难以使用。因此，使用标准的跟踪工具作为修复问题的方法是不现实的。

容器和微服务

微服务体系结构的出现使端点间更加短暂，也使微服务之间的通信更加重要。然而，今天的网络可视化工具介于计算和网络（和存储）之间，再加上容器的短寿命，使得网络管理员更难执行事后的分析。

自动化

网络自动化是云主机数据中心操作效率的一项基本技能。但代码也许也会出现错误，所以自动化所造成的错误可能会以更复杂的方式影响整个网络。因此，快速验证和排除问题的能力很重要。

固定形式交换机

Clos拓扑使网络可以完全使用一种（或最多几种）设备来构建。更多的设备需要管理，所以经典的一台台设备进行网络故障排除方法也不那么有效。即使是为了可视化，拥有简单的和固定的形式设备也有很多好处，但超越简单的监视是很重要的，因为设备的数量很大。

云原生数据中心更容易实现可视化的方式：

固定形式交换机

较小的机框意味着我们可以更频繁地轮询设备以获取信息，因为每个机框中要收集和报告的信息数量要少得多。拥有一种（或少量）设备，使部署遥测解决方案更加可行。

解耦

网络分解和云主机数据中心的要求提高了将构建交换机作为平台而不是设备的需求。因此，分解的交换机作为网络操作系统运行Linux，允许统一工具和收集某些类型的数据，如接口统计数据。“流媒体遥测”是当今网络中的一大大事。流媒体与上一代形成了对比，上一代以分钟间隔收集数据。

11.5 分解可视化

遥测，或数据收集存储：

收集的数据如何存储

监控

告警

数据分析和查询

11.6 遥测机制

遥测是指从位于中心位置的远程站点自动收集数据。遥测过程可分为什么（收集什么）、何时（收集时）以及传输方式（如何运输）。在今天的网络中，SNMP控制着所有问题的答案。收集的内容仅限于设备支持的SNMP数据模型。

11.6.1 我们收集什么？

度量和日志是我们知道我们需要收集的已被充分理解的结构。有关设备的状态信息，如转发表（MAC表、ARP/ND表、路由等。)，以及控制协议的状态都对收集都很有用。

例如，在网络中，链接是一个关键的资源。因此，监视接口上的接收包、传输包和字节计数决定利用率，下降和错误计数确定错误，缓冲区利用率决定饱和度。因此，这些参数决定了接口的使用指标。对于CPU、内存、温度等其他关键资源，也可以很容易地确定类似的措施。在路由中，您可以考虑对路由表的完整程度以及前缀的分布的度量，作为要收集的有用统计数据的示例。您还可以收集所有硬件表的状态，如ACL表、MAC表和隧道表，以监视它们的负荷情况。

在Clos拓扑中，当每个上行链上使用的带宽大致相同时，可以实现高容量。如果这种情况没有发生，这可能表明要么流哈希工作没有生效，或者有很多大象流最终被哈希到同一个链接上。您可以通过查看跨链接的数据包计数的比率来部分识别此情况。

延迟作为另一个重要的收集指标。据我所知，所有的大型云服务提供商都在测量整个网络的延迟，并使用这个延迟中的异常变化来检测问题。

使用sFlow的包捕获是另一种用于跟踪通过网络的流量的有用数据。

11.6.2 我们如何收集？

在确定了一组要收集有关数据的信息后，您需要确定如何收集这些数据。很长一段时间以来，SNMP一直是网络设备上唯一的答案。在计算节点上，集合和状态等工具早已流行了。但这两者都被普罗米修斯和ImpladxDB等新工具所取代。这些工具的流行也已经传播到网络设备上，在那里它们的使用被称为流媒体遥测的营销名称。像卡夫卡这样的大数据工具也越来越多地用于将数据从不同的端点流到收集器。

当涉及到日志记录时，最常见的模型是使用系统log将数据推送到重新移动的系统日志服务器。

在收集数据的机制上，一个流行的争论是拉模型还是推模型更好。很长一段时间以来，计算人员都专注于推送数据，而网络运营商则在拉动数据。随着普罗米修斯的出现，即使在计算人员中，拉力模型也很受欢迎。

轮询通常是不受欢迎，因为它往往是浪费的，并导致CPU忙于等待。

可以使用关键特性来衡量该系统的优缺点。以下是两个模型之间的主要区别：

及时监控

使用推送模型，代理可以在事件发生时立即将数据推送到收集器，从而允许及时发出警报和信息捕获。在拉出模型中，收集器只有在决定拉出信息时才知道一个事件。如果运行代理的系统发生灾难性故障，则甚至可能根本不会被捕获该事件，因为轮询来得太晚了。我认为，这是拉模型和推模型之间的核心区别。

需要代理

拉出模型可以设计为使用现有的传输和命令来拉出数据。例如，您可以使用系统中可用的RESTAPI，以所需的频率提取相关数据。通过推送，每个遥测解决方案都需要特定于nos的代理。考虑到网络设备的封闭性质，这一直是一个问题。但是网络解耦的出现使供应商开始解决这个问题。

做出改变是复杂的

如果需要更改数据收集的频率或所收集的内容，则必须触摸每个受影响的代理。在拉力模型中，收集器是唯一必须更改的收集器。例如，可以在收集器上添加新命令或更改命令中的字段被收集一次。当然，像SNMP甚至普罗米修斯这样的拉式解决方案也需要在代理端进行更改，所以这种差异在很大程度上特定于所使用的解决方案。

11.6.3 我们何时收集？

计算和网络应该以相同的频率收集数据——比目前在网络中常见的频率要频繁得多。如果较少的收集数据使得难以捕捉问题并很好地理解系统。但过频繁地收集数据也可能是不必要的。

11.6.4 存储数据

用于收集的模型通常决定了数据的存储方式。大多数工具都使用时间序列数据库。

11.7 对多个数据源的使用

网络操作员遇到两种不同的问题：一种是当通信失败时，另一种是当通信次优时。第一类是当A不能与B交谈时，而第二类是当A与B的通信非常慢且有损时。除此之外，能力规划还需要具有可视化。

无论是在网络中还是在任何一个端点A和B上，A不能与B交谈肯定是遇到不正确或不一致状态的结果。处理完全通信故障是一个复杂的过程，包括跨多个节点检查状态以跟踪问题。然而，在某些情况下，这个问题完全是由一根糟糕的电缆造成的。如果您检查了这些度量，并看到错误计数或下降计数在从A到B的任何路径上不断增加，那么您将能够判断问题。

A和B之间的次优通信同样可能是由于拥塞的链路或短暂但持久的路由循环。因此，检查拥塞链接的指标很重要，检查日志是否存在一些持久路由循环。

11.8 告警和仪表板

所有这些数据收集传统上都用于发出警报和构建仪表板。

告警包括主动通知操作员严重事件，希望在问题的影响变得广泛或灾难性之前。

告警是操作员的工具包中最弱的工具之一，告警太简单，告警不及时，告警重复太多，告警通知范围太广。

数据的另一个用途是构建分布式系统的仪表板。仪表板由图表组成，这些图表应该一眼显示系统是否有问题，以及关于如何查找问题来源的一些提示。通常，网络仪表板不同于应用程序监视仪表板，每个都由不同的团队负责。此外，每个不同的工具各自都有自己的仪表板。日志记录工具与收集统计数据的工具、进行数据包采样的工具等不同。