本节书摘来自异步社区《网络管理：计费与性能管理策略》一书中的第1章，第1.1节，作者【美】Benoit Claise, CCIE#2868 , Ralf Wolter，更多章节内容可以访问云栖社区“异步社区”公众号查看
1.1 记账与性能管理的定义及其相互关系
网络管理：计费与性能管理策略
要说明记账与性能管理之间的相似性和差异性，首先需要对这两个术语进行解释。不幸的是，还没有针对记账的统一标准定义，这也就导致有时候不同的组织会给出不同的定义。下面列举的是用于描述记账的相对常用的定义。要说明的是，本节阐述的是纯粹的理论，本书的目标是要为记账和性能管理提出一种广泛而综合的观念，之所以先从纯理论上进行阐述，也正是基于这样的考虑。
1.1.1 记账管理的定义
在对记账管理的通用定义进行搜寻时，你将会发现有多种定义同时存在，其中没有任何一种定义能够完全地概括所有的应用。这听上去可能会让人很惊讶，但是在过去，记账并没有引起人们的足够重视，出现这样的情况还是可以理解的。本书笔者决定首先将各种不同流派的定义列举出来，以便帮助理解问题的根源。接下来，作者将会提出自己对记账管理的定义，该定义也会贯穿全书。本小节将要研究ITU（http://www.itu.int/home/index.html）、电信管理论坛（TMF，http://www.tmforum.org）以及因特网工程任务小组（IETF，http://www.ietf.org）对记账管理的定义。
1． ITU-T的定义（M.3400和X.700，OSI网络管理职责的定义）
记账管理可以通过对OSIE[开放系统互连环境]资源的使用来建立费用清单，并且同样可以通过这些资源来确定成本花费。记账管理包括如下功能：
将成本花费和资源消耗通知给用户；
可以设置记账限制以及将使用的资源与花费计划进行关联；
如果存在多种资源同时为了完成一个给定通信目标而被调用的话，可以将成本花费与之进行关联。
2． TMF的定义
TMF根据ITU-T对于记账的定义（M.3400），在增强的电信运作蓝图（eTOM）中提出了对于记账的附加细节（见商业流程框架，文档GB921）。
在TMF的eTOM中，执行、保证和记账（FAB）模型决定了在保证和记账之间“网络数据管理”组件的位置。（网络数据管理：该流程包含了对有用数据、网络信息技术事件的收集，以及用于网络性能和流量分析数据的收集。在服务管理层面，这些数据同样还可以被作为用于记账（计费和折扣计算）流程的输入信息，当然这要根据具体的服务及其体系结构。）第3章将会更为详细地对FAB模型进行解释。
注释：
大部分TMF的文档对于TMF成员来说都是可以免费获取的。非会员可以在TMF的网站http://www.tmforum.org上进行购买。
3． IETF的定义
在因特网标准草案（RFC）2975，记账管理介绍中，给出了如下对记账的定义：对资源消耗信息的收集是为了进行性能和趋势分析、成本分配、审计以及计费。记账管理需要对资源的消耗进行量化、定价和分配，并且还要在适当的部门之间进行沟通。
正如前面的定义中叙述的，对于记账管理来说，根本没有一种统一通用的定义。ITU-T主要考虑资源使用量的计费，这也正是每个服务提供商最主要的需求，但是我们认为该定义的局限性很大。尽管IETF的定义仅存在于RFC中而未被用于标准，但这和我们认为的“记账管理”几乎是一致的。为了不受众多定义及其各自局限性的干扰，我们决定自己对其进行定义。
本书使用记账管理这个术语来描述以下流程：
在网络设备中收集有用的数据记录；
不受约束地对设备生成的数据进行预处理（如过滤、取样、集中）；
将这些数据从设备输出到一台集中服务器；
在集中服务器上对这些数据进行处理（如过滤、取样、集中、复制）；
将有用的记录转换成一种通用的格式，以便可以被高层应用（如性能、SLA、故障、安全、记账、设计等）使用，中止进程。
图1-3描述了多种应用对记账管理的使用。注意，不同层面的功能与在记录生成和处理（诸如数据收集、输出和集中）之间的区别，还要注意将会使用这些记录的应用。
通常会将记账与计费联系起来，因为在词典（韦氏词典）中，是如下描述记账的特点的。
“用于记录和概括商业以及财政事务，并且对其结果进行分析、检查和报告。”
在这个定义中丝毫没有提及到“计费”这个术语，但是却间接地将记账关联到计费上去了。然而，在我们的观念中，记账和计费是不同的，因为计费仅仅是记账的多种应用中的一种而已。
1.1.2 定义性能管理
尽管如前所述，还没有一种统一通用的定义用于记账管理，但是性能管理至少在各种不同的定义之间有很多相似之处。和介绍记账定义一样，本书从研究ITU-T以及TMF对性能管理的定义开始。但要注意的是，IETF的RFC中并没有针对性能管理的定义。最后，将会给出作者自己的定义，该定义同样也会在全书中贯穿使用。
1． ITU-T的定义（M.3400和X.700，OSI网络管理职责的定义）
性能管理根据电信设备及网络效力或网络组件的行为提供评估和报告，它的角色是收集和分析统计数据用于对网络效力、网络组件或设备的监控和纠错，并且对设计、采购、维护和质量测定提供帮助。
性能管理提供以下功能：
收集统计信息；
维护和检查系统历史状态日志；
在真实和模拟环境中确定系统性能；
通过改变系统的运行模式来引导性能管理行为。
2． TMF定义
TMF从全网稳定的角度来定义性能管理和SLA管理。网络的稳定进程负责执行前瞻以及运行中的维护，以确保服务提供商到客户之间通路的持续性，同时还要保证SLA或服务质量（QoS）的实施级别。它不间断地查看资源状态，并通过性能监控来预见性地检测可能的故障，同时还会收集运行数据信息并进行分析，确定潜在的故障，在不影响客户的情况下将这些故障解决掉。该进程管理着SLA，并且将服务性能报告给客户。相关的文档是TMF 701，性能报告的概念和定义，TMF GB917，SLA管理手册；都参阅了ITU M.3010以及eTOM的FAB模型。根据TMF的定义，性能收集也是网络数据管理进程中的一部分。
“这个进程包括了对有用数据的收集、网络和信息技术事件信息的收集，其目的是进行网络性能和流量分析。”
正如你从这些定义中所看到，性能管理还没有一个统一的分类。ITU-T的定义主要考虑的是电信、网络设备的行为和效力，但是该定义的局限性太大，因为它没有涉及到运行在网络前端服务的监管。TMF的定义主张的是服务等级管理的细节，但只是简单地提了一下网络组件监控的必要性。为了将这些定义中细微的差异进行中和，我们给出了我们自己的定义。
现在，我们已经可以区别性能监控和性能管理了。
性能监控收集设备、网络以及服务相关的因素，然后通过图形化用户接口、日志文件等方式将这些记录报告出来。性能管理凌驾于这些数据收集之上，主动将这些信息更进一步地通告给管理员，并且在需要的时候对设备进行配置变更。SLA中的数据收集就是这样的一个例子。性能监控和记账只是对数据进行收集，然后在某个集中点将这些数据储存起来。性能管理将会分析这些数据，并且将其与预先定义好的门限值以及服务水平进行比较。一旦违背了服务级别，性能管理就会生成一块故障令牌，用于应用纠错或对设备进行配置变更。例如，它将会过滤掉尽最大努力传输的流量或提高承诺接入速率，等等。
本书使用这个术语来描述以下流程。
（1）性能监控——基于以下的原因，在设备层面进行网络活动信息的收集：
设备相关的性能监控；
网络性能监控；
服务性能监控。
监控的基本任务单元包括：
一种可用的监控方式；
响应时间报告；
监控的消耗（链路、设备、CPU、网络、服务等）；
确保所收集数据的精确性；
检查服务质量参数；
数据集中。
（2）数据分析——基准和报告。
数据分析的基本任务单元包括：
网络和设备流量的特性以及分析的作用；
性能；
例外；
分析能力；
基准；
流量预估。
（3）性能管理——监控只关心网络中的活动，但是管理可以变更设备配置。一般所说的性能管理，表示调整配置来提高网络性能以及进行流量处理（门限值定义、性能设计等）。
管理的基本任务单元包括：
确保满足SLA和服务等级（CoS）的策略及其保证；
定义门限值；
向高级别应用发送通告；
调整配置；
质量保证。
图1-4描述了性能管理的结构，在将其与记账的结构进行比较的时候，可以看到很多的相似之处，但同时也有区别，下一小节将讨论两者的异同。记账只涉及被动的收集方法，而性能管理还可以运用主动的度量手段。在该环境中，我们向网络中人工注入流量，看看网络是如何进行处理的。
对性能管理的定义只是部分地混合了对设备和服务的管理。对性能管理更细致的定义应该确定以下3种子类：
特定设备的性能管理；
以网络为中心的运行管理；
服务管理。
特定设备的性能管理以一种孤立的模式看待设备。设备的状态差不多都是二元的：要么工作正常，要么就是有故障发生。在网络组件层面定义了门限值之后，性能监控同样可以被认为是二元的。比如说，如果CPU使用率在5%~80%之间被视为正常的话，链路的使用率就应该小于90%，同时接口错误率不应该超过1%。因此，根据预先定义的门限值是否超出来判断状态是正常还是异常。
以网络为中心的性能管理将关注点扩大到了网络的边缘到边缘观点。尽管从单个设备来看，所有的设备都是正常的，但是整个网络的性能可能会因为双工的不匹配、生成树错误、路由环路等问题而受到影响。
服务管理将管理级别提高到网络连通性之上。有些服务可能相对比较简单，比如域名服务器（DNS）；也可能比较复杂，比如事务处理数据库系统。无论简单还是复杂，用户都希望服务是可用的，并且响应时间是可预计的。服务层面的性能监控除了包括服务监控之外，还需要有管理的功能，以便万一出现故障的时候对服务组建进行修改和变更。
1.1.3 记账和性能之间的关系
本小节讨论记账管理和性能管理之间的相似性和差异性。通过在一些标准定义中的反映，我们看到了性能和记账之间密不可分的关系。尽管有一些定义的描述略有不同（如FCAPS模型），但是基本理念是非常相近的。作为一项非常有意义的研究，TMF将这两个类别结合到了一起。
这两者都要对有用的数据进行收集，这些数据随后可能被应用到相同的应用中去，如监控、基准、安全分析等等。诸如简单网络管理协议（SNMP）计数器之类的一些技术可以分配给性能，也可以分配给记账，关于这些技术到底属于这两者中的哪一类别的纯理论性讨论将会持续很长时间。
记账和性能监控是非常重要的信息来源，这不仅仅是为了进行性能管理，还可以用于安全管理——这是另一个常见的类别。安全管理应用可以输入这些收集来的流量信息，分析不同类型的协议，以及分析在源和目的地之间的流量类型，等等。将一种数据流与已定义好的基准进行比较，就可以标识出异常的情况或新的流量类型。此外，同样的应用还可以通过性能监控收集详细的信息，如CPU的使用率。在实际环境中，两者的结合很可能会是用来确定安全攻击的一种非常强大的工具。通过安全实例来说明性能监控和记账的好处所在是最合适不过的了。每一种问题自身的征兆（异常的流量或很高的CPU使用率）从本质上说也许并不显眼，但是如果将所有的征兆都集合起来的话，就很容易说明网络所处的危险环境了。
从整个网络的角度来看，性能会考虑诸如网络负载、设备负载、吞吐量、链路容量、不同的流量类型、丢包率、拥塞之类的细节，而记账则将这些有用的数据收集起来。
对于记账和性能监控，信息收集的间隔是需要分别考虑的因素。性能分析的数据收集进程需要在门限值超出的时候立即通知管理员，因此这种情况下我们通常需要实时地信息收集。除了像预付费这样的情况之外，用于计费的记账数据收集并没有实时的需求。
历史的确是一个很好分析参数。但是以计费为目的的记账收集并不需要维护历史数据，因为这是计费应用的工作。另一方面，性能管理需要历史数据来分析是否有异常情况发生，同时还能进行趋势分析。
在这两者间，监控设备使用率的行为也是不相同的。设备健康状况监控对于性能监控来说是至关重要的一部分，然而记账管理关心的是有用的信息记录。我们将通过下面的例子来说明这个问题。假设有一个普通的网络环境，其流量负载适中，现在用户在没有通知管理员的情况下自行安装了一个“感兴趣的”软件。例如，某人安装了一个监控工具，并且开始用它来发现网络中的设备。尽管强烈推荐对设备的接入需要安全性，并且要用私密的SNMP字符串来代替缺省的“public”和“private”，但是有时候这些建议并没有得到采纳。如果此时安全限制（如访问控制列表[ACL]）也没有实施的话，用户就可以获得网络以及设备相关的详细信息。如果用户的监控工具收集因特网边缘路由器的路由表的话，情况将是非常严重的。例如，要从RAM为64MB的Cisco 2600路由器中获取4000条路由条目，需要花费25分钟的时间，并且要花费掉30%左右的CPU资源。单独的一种记账应用根本就不能发现这种问题，因为该问题不会涉及到流量的传输，但是事实上，设备资源正在被消耗。性能监控应用可以立即发现这个问题，并且能够将它报告给某个故障应用。这个简单的例子不仅说明了性能和故障管理之间密不可分的关系，同时还说明了无论是记账管理还是性能管理都无法独立地用作一种高效的网络管理解决方案。
另外一种情况就是链路的错误配置。假设在两台路由器之间的逻辑链路是三条平行链路，用作干线。基于故障排查的原因，管理员将其中的两条链路断开后，故障得到了解决。然而，假设之后他仅将两条断开链路中的一条恢复使用，那么就只能提供所需带宽的2/3。流量仍然会被传输，记账记录还是会生成，但是这两条可用链路使用率的增加只能通过性能管理工具才能被标识出来。
这就使得“故障”报告成了另一种在记账管理和性能管理之间的差异。在第一个例子中，性能管理应用可以发送通告给故障应用，并且可以通过在设备上配置ACP来停止对SNMP信息进行未授权的收集。在第二个例子中，性能管理工具可以自动地将第三条链路激活，并且将这一信息通告给管理员。记账管理应用不会对设备健康状态信息进行收集，如CUP使用率，所以自然也不会关心例子中的问题了。性能管理和故障管理之间密切的关系在一些出版的读物中都是作为主题来研究的。
监控过程是主动还是被动是各种监控手段之间最基本的区别。记账管理总是被动的，而性能管理可以是被动的，也可以是主动的。
被动监控模式通过运行度量来收集性能数据信息。从简单的接口计数器到一些诸如远程监控（RMON）嗅探之类的专用应用都是使用这种模式。被动模式需要监控目的地为某台设备的一些或所有报文。如果并不是所有的报文都被收集，而只是检查其中一部分的话，就叫做取样。在某些环境中，比如测量双向通信的响应时间，实施被动模式可能会比较复杂，这是因为请求报文和响应报文之间需要进行关联。举例来说，应用相应时间（ART）管理信息库（MIB）是RMON 2标准的扩展。ART用于测量应用数据流中请求/响应报文序列之间的延迟，如HTTP或FTP的数据流，但是ART只能对使用众所周知TCP端口的应用进行监控。若要提供端到端的测量，需要同时在客户端和服务器端使用ART嗅探。Cisco在网络分析模型（NAM）中部署ART MIB。
被动监控模式的好处在于不会对网络中的数据流量形成干扰，所以测量的结果基本上没有误差。这个好处也可能是一个限制，因为被动模式的先决条件是要有网络活动。举例来说，通过对流量的监控可以发现有一门电话机出于活动状态，但是当没有产生任何流量的时候，如何辨别这门电话是正常的还是有故障，这种情况下，最好的办法是发送测试流量给电话，然后监控结果，或者让这门电话规律性地发送保持存活报文。但是主动监控模式会人为地向网络注入流量来测量性能参数，比如可用性、响应时间、网络回程时间、延迟、延迟抖动、重传、丢包率等。主动模式简单地提高了可测量性，因为只需要对已经生成的流量进行分析。Cisco IP SLA就是一种主动监控模式。关于IP SLA更多的细节，请参阅第11章。
通过实践证明，目前最好的方法是将主动和被动模式相结合，因为它们可以相互补充。
正如前所述，它们之间既存在共性也存在差异，但是在大多数情况下，将记账管理和性能管理相结合是有好处的。让我们仔细分析一下下面的情景：网络操作员同时实施了性能管理和记账管理，两者都对设备进行有用数据的收集，并且储存于不同的集中服务器。各自收集的数据集相互独立，不过都是有用的。如果想要降低测量的误差，可以对详细的记录（记账管理）和基本的SNMP计数器（性能管理）进行收集，然后将其结果进行比较。这样做可以提高测量的准确性。
图1-5显示了不同网络管理的组件。
总的来说，我们推荐将性能管理和记账管理、故障管理和安全管理结合使用，以便构建完整的网络管理解决方案。
1.1.4 辅助的解决方案
这些范例很清晰地回答了“哪种情况适用哪种模型？”这个问题，而不是“为什么需要记账管理或性能管理？”。后者，也是最为重要的问题也可以理解为“进行数据收集的目的是什么？”。当管理员通过严密的方法区分安全管理、服务等级管理、计费等的时候，很自然地就将记账和性能管理贯穿到了整个体系结构中。
为了进行总结，我们要对性能监控和记账管理为其他各种管理应用收集有用的输入数据进行强调。性能管理就是从性能监控和记账中获利的一个管理类别，当然它还可以主动地进行网络变更以及自身行为的变更。它们之间是相关的，因为如果没有性能监控，就无法无障碍地操作网络。没有记账，几乎就不能确定导致瓶颈的原因，而性能管理则可以测定运行中的能耗。通常网络监控在这两个类别中都存在（请参阅1.2.1节）。所以，对记账管理和性能管理中的任何数据收集工作来说，网络监控这个术语是非常普通的。图1-6显示了这两个类别的交叠。
既然我们已经清楚地定义了记账管理、性能监控和性能管理，那么接下来我们可以更为深入地了解一下网络设计者和管理员如何完成这些类别的工作。
