1.3 性能的目的
网络管理：计费与性能管理策略
本节专门讨论性能管理，描述了性能数据可以帮助进行更有效的管理网络的各种场景。
正如在前面讨论过的一样，“性能监控”这个术语可以有很广泛的理解。我们的定义包括了三个方面：设备、网络及服务。事实上，设备和网络的性能监控关系比较大（稍后我们会进行讲解），因此，我们将这两个方面统一到同一个小节中，而服务监控是我们需要独立说明的一个很宽泛的领域。本节将同时覆盖着两个部分，涉及所需的性能数据收集：基准和故障管理。
1.3.1 设备性能监控
对性能监控来说，最为明显的方面是直接相关于整个网络及网络中的设备。有时你会感觉网络很慢，这种感觉实际上是因为用户不能分辨到底是网络的性能还是服务器的性能。对于到底是服务器的问题还是客户跟服务器之间的连接性问题，通常网络管理员都不会很清楚。随之而来的结果是，首先通常是监控网络，以发现网络工作是否正常。这也许听上去很怪，但事实上这是大部分网络操作员的做法，除非发现了其他故障，否则肯定都认为是网络出了问题。
在最初的阶段，监控设备所在网络以及链路的可用性。可用性是通过网络对用户而言的可用性延迟来度量的，所以该可用性标识了网络组件的可靠性。另外一种说法是，可用性很可能是在任意时间点上网络执行力中的一个项目。
一个通用的公式如下：
可用性=MTBF /（MTBF + MTTR）
MTBF是故障出现的平均时间，用来说明在连续两次故障之间的时间间隔。MTTR是平均故障修复时间，用来回答“恢复故障用了多少时间？”这个问题。可用性通常都是以百分比的形式定义的，比如99%或者99.99999%。你可能会认为99%的可用性听上去已经非常不错了，但是从一年的时间来看，就表示有3.5天的故障时间。表1-7列出了这些数字代表的具体意思。
大部分的网络操作员都尝试实现99.9%~99.99%之间的可用性。从技术的角度上讲，可能更接近100%，但是像需要这样稳固的商业个案的价格都是非常昂贵的。贸易和银行的应用就是需要高可用性的实例，而email服务器就不需要。本书只是提出高可用性的一些通用定义，不会深入去探讨这些概念，但是我们建议读者通过一本书来对此进行深入的研究。Chris Oggerino所著的《高可用性网络基础》是一本不错的入门材料。
- 网络组件性能监控
在设备的角度上讲，我们主要关心设备“健康状况”数据，比如所有的吞吐量、每一个（子）接口的利用率、响应时间、CPU负载、内存消耗、错误等。网络设备性能的细节，比如接口使用率及错误情况都是由各种MIB提供的，像MIB-II（RFC 1213），接口组MIB[Interface-Group-MIB]（FRC 2863），以及TCP-MIB（RFC 2012）。
计算处理效率是和无效报文的数量相关的，它会测量网络中无错误的流量，然后将错误报文率与正确的报文进行比较。我们只测量入站处理效率，因为一台路由器或交换机不会有意地发送错误的报文。所需的参数是通过接口MIB（IF-MIB RFC 2863）提供的。
ifInErrors：“对于报文起源的接口而言，表示入站报文中包含错误的报文数量，这些报文会被阻止向高层协议传递。对于特征起源或固定长度接口而言，表示包含错误的入站传输单元数量，这些传输单元会被阻止向高层协议传递。”
ifInUcastPkts：“通过子层向更高（子）层传输的报文数量，这些报文在这一子层中不会添加组播或广播地址。”这些报文是单播报文。
ifInNUcastPkts：“通过子层向更高（子）层传输的报文数量，这些报文在这一子层中会被添加组播或广播地址。”这些报文是非单播报文（包括组播和广播流量）。
传输效率（%）= ∆ifInErrors * 100 / (∆ifInErrors + ∆ifInUcastPkts + ∆ifInNUcastPkt)
CISCO-IF-EXTENSION-MIB会添加诸如cieIfInFramingErrs（位移或成帧错误）、cieIfInOverrunErrs（接收方缓存溢出）、cieIfInRuntsErrs（报文太小）以及cieIfInGiantsErrs（报文太大）的细节。这些计数器可以用来进行深度错误分析，如果ifInErrors计数的数量很大，那么就需要对故障的根源进行判断。
注释：
MIB计数器单一的SNMP轮询是没有用的，只有两个轮询的交叉点才能提供相关的数据。
2. 系统和服务器性能监控
大部分对网络设备的推荐都适用于服务器监控。低级别和系统的操作性需要持续进行检查，以便可以及时标识出性能问题。除了检查这些细节之外，还需要对运行在服务器上的特定服务进行监控。以DNS服务为例，如果因为在同一个物理硬件中其他应用的运行故障导致逻辑服务（这里指的是DNS）变得很慢的话，通过PING请求来了解服务器的响应时间是否正常是不会让用户满意的。
在系统和服务器监控的环境中，我们需要对低级别服务监控和高级别服务监控进行区别。
低级别服务监控组件如下。
系统：硬件和操作系统（OS）
网络接口卡
CPU：全部和每一个系统进程
硬盘，磁盘簇
风扇
电源
温度
OS进程：检查是否处于运行状态；在需要的时候重启
系统正常运行时间
高级别服务监控组件如下。
应用进程：检查是否处于运行状态，在需要的时候重启
每种应用的服务器响应时间
可选：每种应用的服务质量，每种定义的CoS的监控资源（内存、CPU、网络带宽）
每种应用的正常运行时间
一种可实施的方法是通过Cisco IP SLA或Catalyst交换机的Cisco NAM卡来测量服务器性能。NAM作用于ART MIB，如果服务器群是连接到这台交换机上的话，那么它能够提供有用的性能统计数据。图1-23显示了ART MIB报告。第5章将对ART MIB的细节进行介绍。
1.3.2 网络性能监控
网络连通性和响应时间可以通过一些基本工具来进行监控，比如PING和TRACEROUTE，或者更高级的工具，像Ping-MIB、Cisco IP SLA、外部嗅探器，或者运行于PC或服务器上的监控应用。在测量网络连通性和响应时间的时候，我们建议管理员不仅要在网络设备之间进行监控，还要在服务器之间进行，这样可以避免在网络和服务器部门之间的相互指责。
在网络监控的环节中，我们要对应用测量出来的停机时间和用户经验性总结的停机时间进行区别。如果仅仅监控了网络及服务器的可用性，而没有监控实际的服务（运行在服务器之上），那么我们可以测量出100%的可用性，即使某服务的可用性不到90%。另外的一个环节是测量的间隔。如果性能监控应用只是在每5分钟对设备进行PING处理的话，即使在测量间隔中有很短的故障时间，测量的结果也会是100%。用户可能会经验性地遇到这些故障，而抱怨测量得不准确，尽管这个时候用户认为的和测量结果都是正确的。同样的问题会出现在晚上，用户很可能在睡觉，而不会关心网络，而同时服务器正在对故障进行监控。你可能已经可以想象服务级别定义和监控的巨大挑战了。
可用性仅仅是网络监控领域中的一个参数而已，还有以下其他相关的参数存在。
网络响应时间；
利用率（设备、网络）；
报文丢失率；
网络吞吐量/容量；
网络延迟；
延迟抖动（延迟变化）；
传输有效性。
1.3.3 服务监控
在开始的时候，我们对设备和网络层面进行监控，以确保基本的连通性。假设网络连通性和响应时间也被监控了，那么下一步就是监控网络中的服务了。现在是讨论服务级别的管理和服务级别协议概念的时候了。
从服务的角度上讲，这里有以下一些重要的参数需要监控。
服务可用性；
服务延迟；
报文丢失率；
延迟变化（抖动）；
语音中的平均评估结果（MOS）；
关键性能指标（KPI）；
关键质量指标（KQI）。
对于服务参数，比如KPI和KQI，一个很好的参考文献是电信管理论坛（TMF）的“SLA管理手册GB917”。
测量服务可用性需要对设备或应用进行显式测量，因为清晰地区别服务器和服务是非常有必要的。想象一台运行正常的（物理上的）服务器，同时在其上面运行的某种（逻辑上的）服务在没有任何通告的情况下被终止了，基于客户的监控应用可以生成特定应用的请求（比如SAP处理）来标识服务是否正常，响应时间如何。
我们简单地在1.3.1小节中的“系统和服务器性能监控”中讨论了这个问题。我们建议使用Cisco的NAM卡来连接响应时间（ART）MIB或Cisco IP SLA。IP SLA支持特定应用的嗅探操作，就像DNS/DHCP请求或web服务器响应时间一样。在IP中传输语音（VoIP）的环境中，IP SLA测量延迟变化（也被称为延迟抖动），该参数对于表示语音的质量来说是非常重要的。此外，它还会测量MOS。MOS是因特网电话的本质，因为它在电路的目的端数字化测量人发音的质量。
第3章将对服务的概念进行描述，这里仅简要地对其进行介绍。
服务：Merriam-Webster的通用定义描述为“一种支持公众需求的工具……”更具体地说，是跟IT相关的，我们定义的服务是一种提供网络连通性或网络功能性的一种能力，比如网络文件系统、网络信息服务（NIS）、域名称服务器（DNS）、DHCP、FTP、news、finger、NTP等。
服务级别：其定义是网络中某种特定级别的质量（与特定的度量值相关），其目的是为了让网络更具可预测性和可靠性。
服务级别协定（SLA）：在服务提供商和用户之间的契约，它描述了所能保证的网络或服务的性能登记。另一种方式的阐述是“SLA是服务质量的一种表现形式，它是用户和服务提供商之间的一种约定。”
服务级别管理：持续性地循环度量流量度量值，将这些度量值和规定的目标值（比如在性能中）进行比较，确保当前的服务级别能够达到或超过协议约定的服务级别。
1.3.4 基准
基准是对网络进行学习、收集相关信息并储存的方法，并可以根据后来的分析得出结果。通用的基准包括了网络的所有部分，比如连通性图表、资产细节、设备配置、软件版本、设备使用率、链路带宽等。基准的制定工作应该通过一个既定的基础进行，因为它在故障排查的时候帮助非常大，并且还能为网络规划和增强提供支持分析。它也是定义门限值的标准，可以帮助标识出当前网络中的故障以及预测将会可能的瓶颈。总的来说，基准的目的就是为网络创建一个知识库——当然还要及时更新。
基准制定工作包括以下内容。
收集设备的资产信息（物理上的及逻辑上的）。这可以通过SNMP或者直接通过命令行接口（CLI）进行收集，比如show version、show module、show run、show config all等。
在规定周期内收集统计（设备的、网络的以及服务相关的）。
撰写物理和逻辑网络的文档，创建网络拓扑图。
标识网络中的协议，包括如下项目。
以太、令牌环、ATM
路由（RIP、OSPF、EIGRP、BGP等）
传统语音到IP的封装（VoIP）
P电话
QoS（RSVP）
组播
MPLS/VPN
帧中继
DLSW
标识网络中的应用，包括如下项目。
web服务器
基于大型帧的应用（IBM SNA）
点到点的应用（Kazaa、Morpheus、Grokster、Gnutella、Skype等）
备份程序
即时消息
从性能基准的角度看，我们主要关心与性能相关的工作。
收集网络设备特定的细节信息：
CPU使用率；
内存细节（空闲的系统内存、flash总存储量、RAM等）
链路使用率；
每一个服务类别的流量；
丢弃的报文；
错误的报文。
收集与服务器及（可选）客户端相关的细节信息：
CPU使用率；
内存（主内存、虚拟内存）；
磁盘空间；
系统操作进程状态；
服务和应用进程状态。
收集与服务相关的信息：
回程时间；
报文丢失（延迟变化——抖动）；
MOS（如果应用的话）。
收集到的基准详细信息通常储存在数据库中，随后将生成相应的报告。下一步就是定义需要的报告。你需要哪一个级别的详细信息？需要定位到的级别尺度是多少？这些问题都可以通过查看特定类型的应用在定义的基准中生成的流量来获取答案。举例来说，你需要更精准的级别尺度来进行故障排查，而查看趋势则不需要。如果性能规划中包含了QoS，相应的QoS参数也需要收集，当然，如果数据只是收集来用于为每个部门计算开支的话，也就不需要了。根据不同的使用个案的需求，可以定义轮询间隔及数据收集的尺度。在基准的定义中，5分钟的间隔就足够了，也就是每5分钟对设备进行一次轮询。在大型的网络中，轮询可能会形成非常大的流量，可以通过创建不同的轮询组来避免该问题。（例如，轮询组相当于对核心设备的轮询每5分钟进行一次，而对分布层面的设备每10分钟进行一次，接入层面的设备每15分钟进行一次。）
随着时间的推移，你会意识到收集来的数据数量变得非常大，然后想要对较老的数据进行总结。这样做就是在要求数据精确度和存储性能好之间做了个折中。举例来说，可以将原来每5分钟的收集间隔修改为30分钟或60分钟。RFC 1857对进行数据收集的间隔提出了以下一些建议。
在24小时之后，收集数据的间隔应为15分钟。那么将原来每5分钟的数据取样变成了每15分钟，这样就可以降低33%的数据保有量；
在1个月之后，收集数据的间隔应为1小时。将原来14分钟的收集间隔变成1小时，可以降低25%的数据保有量；
在1年之后，收集数据的间隔应为1天。将24次每小时的数据收集变成一次，这样数据保有量就会有4.2%的降低。将每5分钟的收集和每1年的收集两者进行比较，降低的数据保有量应该是3424=288，换句话说，就是百分之0.35。
到这里为止，你已经从网络组件中收集到了性能统计数据，并且都将它们储存到了存档文件或数据库中了。下一小节将说明基准的定义是进行高效故障管理的基础。
1.3.5 故障管理
除了将性能与记账紧密关联之外，我们还要知道性能和故障管理之间紧密的关联。图1-5说明了这个问题，我们还将详细阐述其观念。性能监控的目的是从设备、网络、服务中收集统计数据，然后将这些数据以不同的方式展示给用户。性能管理对此步骤进行了扩展，包括能够积极地对网络进行修改来重新设置所期望的性能等级。注意，在识别背离和修正之间需要添加一个步骤——通告异常的故障应用。可能有人会说背离根本不是故障，但背离的确是某些形式的异常行为的标志，这些异常行为稍后将会被检查出来。在更高的级别上，我们可以区别两种不同的故障事件：
状态变化（设备、网络或服务失败，资源耗尽，或者重启）；
性能背离。
状态变化的通告会预先被设备发送出来。其结果是，状态的改变来源于应用（如网络映射、事件列表等）。从工作状态到停止工作的状态变化通常意味着资源耗尽，反之则说明，要么从一个故障中恢复要么激活某个备份进程。因此，相对于被分类到“性能背离”的事件，被分类到“状态变化”中的事件需要更多的关注。举例说明，当主DSL连接断开后，ISDN备份链路会被激活。假设DSL的连接存在一个翻动率，那么ISDN链路很可能会周期性地被计费，而直接导致每个月的费用增加。这就说明了故障管理系统设计的失败，因为只有每个月末的账单才能说明该故障的存在。
性能背离事件相对于故障管理来说跟性能管理的联系更紧密一些。从“正常”中剥离出背离是非常具有挑战性的，因为需要一些历史性的标志来定义在特定时间、特定网络中的“正常”。要完成该工作，就正如在前面小节讲到的一样，需要制定基准。如果当前的测量值超过或低于预先定义的门限值（也就是期望值），就会有性能事件被生成。
现在我们可以分析性能基准了，以便对网络中的流量有一个了解，以及为流量或应用的确保定义适当的门限值。门限值的定义指的是：当有如此的情况发生时，将会为流量类型或环境触发特定的进程，并且生成事件。
我们定义两种类别的门限值分别如下。
不连续的门限值——布尔理论的对象有两个值（是/否、真/假、0/1），这两个值定义了从一个状态向另一个状态的转换。
举例：链路连通/断开、接口处与工作状态/关闭、服务可用/不可用。布尔的操作要么是真，要么是假，这样可以很容易地进行关联。例如，
征兆：某特定服务不可用，并且到该服务器的物理链路为断开。
处理：在检查该服务之前先检查链路。
连续的门限值——应用连续的数据集合，还可以选择包含时间参数。在这种环境中，我们需要定义一个绝对或相对的门限值，并且在该值被违背的时候生成事件。
举例：在总流量中带有误码报文的数量所占的百分比。
门限值技术可以通过增加滞后功能进行增强，这样可以减少生成报文的数量。在这种环境中，当超过上限值的时候，只会有一个肯定的事件被通告出来，而后不会再通告事件，一直到降为较低的门限值，这个时候会通告一个否定的事件。这样就可以减少事件的数量，而并不会减少该级别相关的信息。
图1-24显示了一个响应时间的滞后功能，这是通过设置高门限值为100ms、低门限值为50ms来实现的。在这个范例中，在50~100ms之间的响应时间被认为是正常的，而超过100ms的响应时间被认为是危急的，并且会生成一个报警。在报警发生之后，这个状态保持在危急状态，直到响应时间降到50ms。你可以将高门限值和低门限值都设置为100ms，以便在响应时间降到100ms的时候马上获得通告，然而，这样做就放弃了滞后功能。
统计分析可以通过报表的形式形象化，用报表来标识正常和非正常的行为。一种比较好的实践方式是从“软的”或者较低的门限值开始设置，而不要将这个值设得太严格，这样可以避免报警风暴。门限值可以持续性地进行调整，随着时间的推移，调整的值会越来越接近正常行为，并且能够标识出异常。
可以在NMS系统中通过轮询设备性能数据来定义门限值，并将这些数据和门限值进行比较。也可以直接在设备层面上设置这些门限值，然后在门限值超出的时候预先通告给NMS应用。第一种方式是NMS架构中的经典解决方案，比如HP OpenView、IBM Tivoli、CA Unicenter等，可以发现及轮询网络中的所有设备。第二种方式要求在设备层面上更智能化，并且需要附加的资源（内存和CPU）。但是它能够帮助减少网络种网络管理的流量，因为在NMS服务器和所关注的设备之间只有状态轮询和事件会进行通告。RMON-MIB、事件MIB以及Cisco的IP SLA（CISCO-RTTMON-MIB）可以提供这样的功能。
哪些门限值和你的网络相关？几乎所有的网络管理员都在寻找一个通用的答案，但是他只能找到针对自身情况的答案。只有极少的通用门限值适用于所有的网络。因此，在大多数情况下，定义门限值是操作员的一项工作。举例来说，Cisco建议CPU的平均负载不应该超过60%，以便有足够的性能用于处理突发事件，如路由协议的重新计算。然而，你可能会让CPU“完全”被使用，因为你可能希望有更高的利用率，于是将其门限值定义到95%。最佳的实践推荐以一种更为保守的方法增加网络的可用性。
Cisco的路由器和交换机推荐的通用门限值如下：
5分钟内的CPU使用率≥60%（CISCO-PROCESS-MIB）；
空闲内存≥25%（CISCO-MEMORY-POOL-MIB）；
两个设备之间的平均回程事件≥150ms（CISCO-RTTMON-MIB）；
两个设备之间的延迟抖动≥10ms（CISCO-RTTMON-MIB）；
DNS响应时间≥2s（CISCO-RTTMON-MIB）；
DHCP请求时间≥10s（CISCO-RTTMON-MIB）。
随着性能基准的制定和定义的门限值的应用，我们将对更为熟悉的“背离正常”特性进行标识。该功能在性能基准收集中添加了“智能化”，这是通过长时间定义和分析网络性能度量值实现的。例如，如果标识链路使用率超过90%为临界状态，你还可以询问这种问题是什么时候出现的。星期一上午，当每一个用户都下载e-mail、更新病毒库或执行备份的时候，网络使用率非常高是很正常的，特别是从经济的角度上看。但是，如果同样的情况发生在星期六的晚上，那就需要多考虑考虑了。定义门限值的限制在于门限值都需要不断修正，很难及时地进行调整。还应该避免在同一步骤中同时定义多个门限值。在这种情况下，性能管理应用需要基于每小时及每天维护基准，持续性地将当前数据跟历史性数据进行比较。特定设备CPU的平均使用率定义为30%左右，如果当前CUP的使用率远远超过30%，或者远低于30%，“背离正常”功能就会生成报警，因为这两种可能都意味着有严重的问题。高CPU使用率说明网络中存在攻击，低CPU使用率说明网络中有配置错误。
下面4个步骤总结了故障管理中必需的工作。
步骤1：在核心设备和服务中定义门限值。
步骤2：预知未来的网络行为，标识出可能的问题区域以及瓶颈。
步骤3：开发一种假定分析方法来加速故障排查。
步骤4：部署一个变更控制进程，指明需要记录以及在将来需要实施的网络变更（维护窗口）。
注意：在记账和性能监控部分的陈述也可以用于相关的故障应用。