JXCZT网络管理系统建设方案

1.背景

随着近年来XXXX业务要求的不断提升和对IT系统的快速建设，IT建设已经初具规模，业务开展也越来越依赖IT系统，IT系统和业务数据对XXXX的重要性越来越显现出来。

不论是5×8还是24×7运行的业务系统都对支撑它们的IT系统可用性提出了很高的要求，当服务器、应用系统越来越复杂的情况下，如何使用自动化的手段协助系统运维人员简化管理从而确保系统的高可用性对于XXXX的外部业务系统和内部协作系统都至关重要。

从上面两个角度入手，及时建立集中系统监控平台来确保网络、系统、应用等IT支撑资源的长期高可用性是非常有必要的。

单纯从管理出发是探讨完善系统管理的一个角度，XXXX的相关部门也从安全生产的角度对系统管理需要处理的问题以及对应的紧急程度进行了大体分类。从业务特性出发，一些系统的低效运行甚至中断将会引起整个业务工作的停顿，从而造成巨大的损失，例如业务系统、办公自动化系统等等；另外的一些系统，它们的短暂停顿对部分业务部分造成一定的影响，但是快速及时的恢复能够较大程度的弥补带来的损失。当然，系统监控和管理的目标是防患于未然，通过管理工具的使用和有效的管理机制，帮助整个IT系统能够长期稳定的运行；同时，当系统出现异常时，能够及时准确的告知相关人员，并提供有用信息帮助有效的介入和处理。

2.管理目标和总体需求

项目将建设一个综合信息系统管理平台，其管理对象是省数据中心和各个地市的重要IT对象，包括小型机、PC服务器、网络、数据库、中间件、应用等等。

系统要实现的功能包括：

功能模块	具体描述
网络拓扑管理	自动发现全网络的物理拓扑图，并能够自动更新拓扑图。图形化显示物理拓扑，直观清晰地显示全网所有骨干网络设备、子网和互联关系，支持VLAN、 OSPF、MPLS的拓扑。
网络性能检测	对网络设备、服务器、PC的端口出入流量、丢包、错包率、链路出入流量及丢包、错包率、Ping延时及丢包率、CPU、内存利用率做出全面的监控和分析
服务器监测	支持对Windows、Linux、UNIX操作系统，对主机系统的CPU、MEM利用率、网络端口流量、文件系统利用率、磁盘IO、应用进程服务情况、系统服务、服务器集群、操作系统及应用系统日志的监测
数据库监测	支持对ORACLE、SQLServer、Sybase等数据库的可用性、特定进程的状态和进程数、连接数、读写缓存命中率、死锁数量、回滚数、表空间和数据文件的大小、状态和使用率、FSFI碎片比率、数据库的非法会话
应用服务监测	对HTTP/HTTPS、SMTP/POP3、FTP、DNS、LDAP、Apache/IIS等中间件服务连接数、响应时间等性能的监测
配置管理	支持对网络设备的配置参数的备份策略及参数变更查看。
故障管理	通过Trap事件和轮询事件或者自定义事件对所监控的网络设备、物理链路、服务器、应用、中间件、数据库的告警和错误日志进行上传，并对故障和告警信息进行存档管理
告警事件管理	在自定义的阀值的基础上在全局物理网络拓扑图形上相应的设备和链路上实时显示告警记录信息，并将告警信息通过E-Mail、短信、报警等方式通知相关负责人
报表管理	能对全网流量分布、网络设备性能、主机性能（CPU，内存,磁盘等）端口的流量、速率、故障、告警等各种指标进行排名，提供饼图、柱状图、直方图、折状图等多种图形化显示方式。可通过全局物理拓扑视图进行所有监控信息的报表查阅，对单个设备的数据报表显示必须在同一视图窗口上显示其所有的监测数据、告警信息、事件信息。
角色管理	一级管理员可监控集团所有网络节点，二级管理员对指定的网络节点进行监控
网管工具	具有网络检测和远程工具对故障设备进行故障处理和诊断。
管理方式	简易操作、配置简单、监控信息分类直观、图文并茂、能够在全局物理拓扑视图上显示当前重要告警、故障事件信息，通过拓扑图可直接链接至告警、故障节点，并在一个的窗口中查看到该故障、告警节点、链路的全部监测信息
存储备份管理	实现省中心应用数据库的备份管理，实现市局数据备份的灾备

2.1.网络管理

XXXX的网络设备来源于多个设备供应商，包括核心交换和主要的路由设备。当前财政厅草的网络运维主要依赖手工维护；然而，由于网络规模较大，网络的异常通常表现为应用和系统的异常，因此，管理人员往往需要通过一段时间的分析判断，才能够定位到网络出现了何种问题。

对于这种情况，对网络提出了如下集中管理的要求：

l 网络拓扑管理

l 网络设备运行参数监测

l 故障报警管理

l 网络性能管理

l 网络数据行为分析

l 配置管理

2.2. 系统管理部分

系统和应用部分主要涉及的平台有AIX、Linux以及其它Unix操作系统和Windows，数据库包括Oracle、Sybase和SQL Server，应用中间件则包含IIS、Tomcat这样的轻型应用/Web服务器。

特别的，由于江西才听政的大部分应用是由供应商使用应用服务器进行开发的，因此，对监控工具的要求上也需要在发现问题的同时，帮助有效解决问题。因此，从时间范畴看，对于应用管理的需求，可以理解为对主机、数据库以及应用完整生命周期的有效综合管理。

2.3.数据备份部分

当前江西省财政厅的备份目标主要是信息中心的服务器，涉及的平台是Windows、Unix，涉及的应用包括文件服务器、Oracle数据库以及SQL Server数据库，并要求实现省中心和市局对现有环境数据备份以及市局的两级备份机制。

3. 总体设计方案

建立一套成熟、高效的系统管理体系是一个系统工程，需要逐步提高。这不仅仅是对技术的不断完善，也是对管理流程和人员技能的不断完善。

实现企业信息系统管理的第一步是构建IT系统管理基础设施，即建立完整的监控体系、集中的事件总线。这也是对XXXX来说最为直接的益处——通过集中监控系统的企业IT系统管理门户和集中事件管理界面能够让系统运维人员在单一的界面中快速而直接的了解分布在各处同时又纷繁复杂IT各对象的状况。

江西省财政厅的IT系统不同于银行、电信和企业，有其自有的特色，而IT运维上，从中心到各分部也呈现出专业IT运维人员少而精的特点，此次网络管理项目中，XXXX的IT管理团队明确提出了综合统一管理的思路，要求实现对网络、服务器系统、数据库、中间件及重要服务等对象进行统一的监控；从而有效的提高系统的整体运行效率和可用性。

此次管理监控的总体要求如下。

l 网络资源的实时状态

l 各种资源的实时状态：

l Unix服务器

l PC服务器

l Oracle、SQLServer数据库

l 应用性能管理相关的应用整断和优化，打通一线应用运维和后端应用开发的资源。

l 图形化的系统实时性能了解。

l 及时统一的报警平台。

l 管理数据的统计和报告。

l 实现集中的存储备份管理。

我们提出的解决方案中网络监控由TivoliNetcool产品家族实现，包括拓扑发现、设备关键性能参数监控、故障报警、配置管理。

系统/数据库/中间件/特定服务等目标监控由IBM Tivoli Monitoring (ITM)系列软件完成，负责硬件服务器系统（操作系统）、数据库系统、应用中间件的性能与可用性管理。

系统监控收集的数据保存在Tivoli数据仓库中，由报表分析系统生成各类统计报表。各类报警事件和各类日志集中到事件管理中心进行统一分析，它提供管理员日常维护的平台，主动通知管理员需要关注的问题。

对数据的保护需要紧密的结合应用数据的保护需求和对应的硬件构架。IBM以其得天独厚的优势，提供对主机和网络优秀的管理解决方案。针对备份管理需要和目前的IT环境，加之IBM多年在备份管理方面的经验、建议利用Tivoli Storage Manager(TSM)企业级备份软件和IBM LTO自动带库设备，对数据进行集中统一备份保护，提供完善的备份/恢复/归档/灾难备援解决方案。

整体系统管理方案包括如下产品：

网络管理：

n Tivoli Network ManagerEntry Edition

网络监控管理，包括Tivoli Netcool的ObjectServer、Probe、Precision、Report、Webtop等功能模块

n Tivoli Netcool ISM SNMPMonitor

网络设备性能管理工具，通过定制完成采集网络设备性能信息或模拟客户端进行服务测试的功能

系统管理：

n IBM Tivoli Monitoring (ITM)

系统管理平台及操作系统监控和管理

n IBM Tivoli Monitoring forDatabase

Oracle/SQL Server数据库性能监控和管理

n IBM TivoliComposite Application Manager for Web Resource

用于J2EE应用服务器的性能和监控管理

存储管理：

针对客户提出的分布式、多平台、多应用数据存储备份的集中存储、自动化管理要求，IBM提出了基于Tivoli数据存储/备份软件的相应解决方案：

n IBMTSM Extended Edition

操作系统数据备份模块

n IBMTSM for Database

数据库在线热备份模块

n IBMTSM for SAN

SAN环境下高速备份模块

整体的软硬件配置和方案能够很好的满足用户的当前环境，从而建立起高效可靠的集中备份系统。

4.解决方案架构

在本章节中，我们将根据对XXXX网络管理需求的理解并结合整体解决方案的设计思路进行XXXX网络管理的架构设计，我们将从整体的XXXX网络管理的总体框架出发，首先设计XXXX网络管理的蓝图，通过阶段性的设计，再设计到本阶段的架构说明。

4.1. 网络管理架构设计

在网络管理和IT服务管理的概念中，业内流行的主流管理架构模式有三种，即集中管理模型、分布管理模型以及集中分布管理模型，三者间互有不同，互有优势，我们推荐以下的系统架构：

集中管理模式: 即一个控制点，一个执行点

在XXXX的网络组织管理模式和未来的运行维护模式来看，我们认为现阶段以集中分布式管理模型较为合适。下面我们就这种模型进行阐述以供XXXX网络管理和运行维护管理领导参考。

根据与XXXX项目组的沟通，在本模式下，我们考虑在项目一期阶段实施集中分布管理模式，也就是说在XXXX信息中心建立网络管理平台和中心，管理XXXX所有网络资源，为各市局的网管数据采集，根据财政厅网管统一要求将所需网管数据过滤上传到财政厅网管中心，并在各分市局实现对本市局的网管功能，在财政厅网管中心完成各市局分级网管的角色定义和总控，各市局网管人员可本地管理，也可通过Web方式远程登录进行访问管理，各市局网管中心的管理角色由财政厅网管中心统一定义分配，并根据管理区域划分和权限设定不同的访问控制

在财政厅网管中心，建立管理XXXX网络的管理系统。所有管理功能和画面设计统一在财政厅网管中心实现并授权，而故障采集探针和网络性能流量和配置监控的Monitor根据设备分布特点可选择分布式部署，保证XXXX网络管理的高可靠性和高效率设计。

网络管理功能划分和授权，根据管理的对象的不同，管理组织和人员的分工，实现特性化的管理和特定管理策略。实现在不同区域定义不同的管理域，根据各管理域人力资源分布和管理分工，实现分布式的网络管理功能。

网络管理系统架构如下：

网络信息及各种信息流的各个流转的功能层次划分为四个部分：信息呈现、信息处理 （分析、压缩关联）、信息收集以及被管理对象。

4.1.1.被管理对象层

本项目的被管理对象从类型上分主要包括：设备、线路和协议。具体的管理对象及其管理内容可参见下表：

对象类型	管理对象	管理内容
设备	BRUNCH/INTERNET/PARTNER路由器	设备及重要端口的故障、性能管理
核心交换机/服务器群交换机	设备及重要端口的故障、性能管理
楼层汇聚交换机/楼层交换机	设备及重要端口的故障、性能管理
防火墙/IDS/VPN设备/WIRELESS	设备及重要端口的故障、性能管理
重要应用服务器接口	端口的故障管理
协议	HSRP/VRRP/VTP/STP/EIGRP/OSPF	故障管理
线路	SDH/宽带/ISDN/ADSL/卫星/DDN/MPLS VPN	线路故障、性能管理

4.1.2.信息收集

网络管理平台需要对被管理对象在性能、流量、故障、资产配置上进行信息的采集。

n 设备故障信息的采集通过NetcoolSyslog probe以及Multi-Thread Trapd probe完成。

n 实时性能信息的采集主要通过ISM 各种Moniter对设备、链路的性能信息的收集。

n 基于协议和IP等属性的实时流量流向数据的采集和分析主要通过USM Netflow Meter实现。

n 拓扑及网络资产配置信息的采集包括Precision IP实现。

通过Netcool对上述信息进行采集，并在采集层进行初步的压缩和过滤等处理，继而传送至Netcool ObjectServer及Oracle数据库进行后续的处理。

4.1.3.信息处理

针对已经进入Netcool ObjectServer和Oracle数据库的信息，按照信息的内在联系进行应用的关联规则，使得收集到的信息能够自动的进行管理处理，从而减少了人工干预，提高管理效率。

n 信息关联：对于出现的各类网络信息能够进行灵活关联，以减少相同或相关信息出现的频率，使得众多信息能够压缩、归纳成一个或少数几个能够反映问题实质的简单提示、告警信息；同时，信息定义应当简单直观、方便管理和查找，能够应付网络规模和信息数量的不断扩张。

n 告警信息解析：告警信息应当直观、易懂，而不是SNMP Polling或者Trap信息的简单展现，以便用户快速定位故障节点、故障端口以及端口连接的对象等。

n 告警等级的临时变更：如果用户对信息或告警信息已经确认，并且正在处理之中，那么反复出现的相同信息应当能够压缩或者临时降低告警级别。

n 条件信息等级：信息能够根据发生时间、发生次数设置不同的等级、产生不同的告警。

4.1.4.信息的呈现

信息的呈现分为实时的监控视图以及历史数据统计报表两类：

n 实时监控视图

根据权辖，按照不同类别的信息或管理域的不同，把信息进行分类通过webtop等实时呈现模块对相应的管理人员进行呈现，管理人员根据权辖集中统一的实时监控视图对被管理对象的状态进行监控；

n 统计报表

通过gateway程序送入到历史数据库进行保存。存放在历史数据库的数据，将根据报表的需求，进行对历史数据进行定期的统计和归档，从而满足管理人员对历史数据的报表需求。

A、报表定制和开发：对于常见类型的报表能够进行模板定制和反复使用，并且用户能够通过快速、简单修改形成新的报表。如果系统本身提供的报表功能远远不能满足需求，必须进行相应的报表开发工作。二次开发可由原厂商和具备相应资质的集成商完成。

B、报表展现：能够将网络节点的故障信息、性能数据、资产与拓扑信息通过图形进行展示，并且能够同时产生相应的数据表格，便于用户在掌握性能变化趋势和规律的同时掌握性能指标的准确读数。

C、报表输出：各类报表和数据不仅在网络监控系统内部进行展现，而且能够转换成通用格式输出和下载。

4.1.5.网络管理总体架构设计

网管软件产品建议部署在二台UNIX/Linux服务器和二台Intel 架构服务器上，一台UNIX核心服务器上负责对数据的处理；另外一台UNIX/Linux服务器负责历史数据的保存和呈现，二台Intel x86服务器用于财政厅及市局的网络数据采集和轮询。

4.1.6.产品模块部署分布

序号	硬件平台配置	系统平台	安装模块	用途
1	IBM小型机/PC Server 2CPU，4G内存	AIX5L / RedHat	ObjectServer	负责对财政厅网管信息及各级市局上报信息的处理
Gateway	负责将数据送入Oracle数据库
Webtop Server	负责向XXXX管理人员提供实时监控告警的提供
Precision IP	负责全网拓扑自动发现和网络资产数据的采集
2	IBM 小型机/PC Server 2CPU，2G内存	AIX 5L/ RedHat	Reporter Server	负责进行历史数据报表的分发和定制
Oracle DB Server	负责收集所有的事件数据和性能数据，并使用Oracle DB保存到数据库中，提供报表数据基础
3	PC Server	RedHat ES/AS 4 Linux	ISM ICMP Monitor	负责财政厅到市局网络链路质量的端到端监测
ISM SNMP Monitor	负责向指定设备进行性能信息的采集
Syslog Probe	负责网络设备Syslog信息的采集处理
5	PC Server	RedHat ES/AS 4 Linux	MTTrapd Probe	负责网络设备Trap信息的采集处理
Precision IP	负责网络拓扑自动发现和呈现

4.2.系统管理架构设计

鉴于系统管理需要在被管理节点上安装代理程序，监控产生的实时数据和历史数据上传会基于目前的XXXX的现有与各市局连接的专线(2M带宽)，为了不对日常的业务系统对带宽的占用尽可能小，建议系统管理部分的配置采用分布式的架构：即在财政厅信息中心和各市局分别建立监控服务器，安装响应的服务器端管理模块，每个监控服务器负责管理本地的监控代理；对于监控过程中产生的事件，可以通过EIF接口上传给财政厅信息中心集中部署的事件中心服务器，事件数据在财政厅信息中心集中网管平台的Object Server中集中进行事件处理和呈现。

Tivoli解决方案为三层次的管理架构，即ITM管理服务器（TEMS），门户服务器（TEPS）及被管理节点（Agent）。Tivoli的所有监控模块都安装在ITM管理服务器上，只是在被管理节点（Agent）上只安装单一的代理进程，管理策略在Tivoli管理服务器上定制，再分发到被管理节点（Agent）上，监控功能便自动执行，代理进程会在机器启动的同时启动，无需任何的人工干预。本方案中，ITM管理服务器，其它的被管节点只运行单一的代理进程。管理员在ITM服务器一端定制好所有的管理策略，再下发到被管理节点（Agent）上。

下图即为本方案中Tivoli产品逻辑结构图：

产品架构图说明如下：

1．Tivoli Enterprise Portal：TM提供了基于Java的客户端管理软件和Web管理界面，管理员可以通过Web浏览器，或者Java客户端软件登录到管理门户上实现相应的管理任务；

2．Tivoli Enterprise Portal Server：ITM管理门户服务器(TEPS) 集中展现管理数据，资源对象状态、告警信息和业务视图；

3．Tivoli Enterprise Monitoring Server：ITM管理服务器(TEMS)可以是层次性的架构，负责从监控代理收集数据。

4．Tivoli NetCool Objec Server：企业事件处理中心，负责搜集和处理所有事件。

5．Tivoli Monitor Agents：监控代理(Monitoring Agent)负责对相关资源进行监控管理，包括操作系统、数据库、中间件等。

6．Warehouse Agent:用于从监控代理或者TEMS上采集监控网源的历史数据，

7．S&P Agent：对Warehouse中的历史数据进行汇总计算，生成按照年、月、季、天、小时的历史数据，以及对历史数据进行修剪。

本方案中，我们采取分布式的管理模式，建立统一的事件的管理控制台，从而达到由一点管理全局所有事件的目的。

在系统架构设计中，在财政厅信息中心和各个市分别安装和配置一台Linux高性能PC 服务器，安装系统管理服务器端产品，负责监控数据的采集、分析、处理、展现，在监控过程中产生的事件数据统一发送给财政厅网管中心的事件处理服务器来统一进行事件的处理和展现。

系统管理产品模块

n IBM Tivoli Monitoring (ITM)

系统管理平台及操作系统监控和管理

n IBM Tivoli Monitoring forDatabase

Oracle/SQL Server数据库性能监控和管理

n IBM TivoliComposite Application Manager for Web Resource

用于J2EE应用服务器的性能和监控管理

4.3.存储备份管理架构设计

基于江西省财政厅的备份环境和结构，我们建议存储备份系统采用是基于SAN环境的备份结构，结合客户需求，提出硬件和软件的配置方案。

Ø硬件配置

当我们采用SAN环境作为备份环境的结构时，我们需要有一台额外的Windows服务器作为IBM TSM服务器，推荐采用PC Server安装Windows 2003 Server操作系统。

Ø物理拓扑图

江西省财政厅的应用系统平台采用两台服务器作为Oracle数据库服务器，两台服务器安装SQL Server，在系统中共配置了四台文件服务器；在备份系统架构中，采用一台PC服务器作为存储备份服务器，安装TSM Server，考虑到备份性能的因素，建议将备份服务器安装在连接所有主服务器的主交换机上；在系统架构中配置了一台磁盘阵列和一台带库，用于备份数据的存储(在目前的架构设计中，主要参考现有环境设备)。

对日后的异地灾备中心的存储系统架构中，采用一台PC Server作为存储备份服务器，安装TSM Server，配置了存储和带库。

IBM TSM使用的是IP协议，因此IBM TSM理论上可以安装在局域网的任何地方。但是考虑到备份性能的因素，我们建议将备份服务器安装在连接所有主服务器的主交换机上，用于存储的磁带库通过HBA卡和备份服务器相连。

Ø 软件配置

在本次方案中，我们使用了以下的IBM Tivoli存储产品：

n数据备份管理基础及内核模块： IBM TSM Extended Edition

n数据库在线热备份模块： IBM TSM for Database

nSAN环境下高速备份模块： IBM TSM for SAN

Ø 软件安装配置

参考江西省财政厅的业务特点和当前存储备份系统的架构，TSM部署的架构分为服务器端和客户端，在服务器端需要安装和配置TSMServer和 TSM for SAN模块，在数据库备份的客户端需要部署TSM Client、TSM for DB、TSM for Mail、TSM forSAN，软件具体的架构如下：

IBM TSM采用的是Client/Server的结构。它的安装配置如图所示，

l TSM Server需要安装在备份服务器上

l TSM Client需要安装在所有的服务器上

l TSM for Database需要安装在SQL Server数据库服务器上

l TSM for SAN需要安装在所有连接在SAN网络上需要备份的服务器上

对于江西省财政厅市数据需要定期上传到省中心备份的需求，可以利用TSM提供的灾难恢复管理器(DRM－DisasterRecovery Manager)，该模块不仅通过将数据异地保存来保护您的数据，而且能跟踪您的所有在线和离线的磁带，并可以自动识别那盘磁带离线。自动产生的灾难恢复计划也能自动的每日更新，这将意味着您的灾难恢复计划对每次的数据备份来说都是最新的，而且，将灾难恢复数据保存到另一个TSM服务器存储池的功能(SERVER TO SERVER)也包括在TSM DRM模块中。TSM也对用于灾难恢复的数据拷贝的数量并不限制。

在江西省财政厅下属11个市局的备份建议架构的设计中，建议可以按照以下操作方式进行：在每个市局安装一台TSM服务器来进行备份管理，备份数据保存在本地存储和磁带机中；本地数据库和文件系统在备份时写入到本地存储和磁带机中，本地的备份数据同时也需要上传给财政厅数据中心的的TSM服务器对应带库中，进行灾备。

5.网络管理方案功能实现

5.1. 网络拓扑管理

ü 对不同厂家(主要是Cisco)的网络设备统一管理自动生成网络拓扑图，显示不同设备的物理面板。网络发生变化时，拓扑图自动产生变化。

ü 通过拓扑图能够查看到网络设备的运行状态（如：端口、链路、线路的开启和关闭、设备硬件错误、线路/配置等问题），并能通过拓扑图看到自动告警信息。

ü 在省中心管理控制台管理全省的网络拓扑和设备，各地、市局只管理本地和各县分局网络拓扑和设备。

ü 拓扑图可以查看设备软、硬件配置信息。

ü 可以通过网络拓扑显示交换机VLAN信息，并可设置、修改、删除VLAN。

ü 全线和分层展现网络拓扑和设备图形。显示网络数据流的流向和大小、协议分布、IP和端口以及线路的利用率。

网络拓扑管理的目的并不是简单的发现网络绘制网络的拓扑视图，因为单纯简单的拓扑视图对网络管理效率的提高意义并不大。以拓扑为监控主视图一方面响应速度慢，另一方面也不够直观，很难快速定位故障点，经常在网络拓扑图中有很多节点经常处于黄色和红色状态。拓扑管理的真正意义是帮助更好地了解网络的准确连接情况，在网络出现故障时能够帮助定位故障发生的真正位置从而更快速的恢复故障。因此网络拓扑管理需要与故障管理紧密结合，纳入到整个网络运维流程的过程中。

因此拓扑管理需要提供几个重要功能：

ü 自动发现网络的准确物理连接，一方面可以将拓扑资源信息丰富到原始的事件中，帮助管理人员了解故障设备更丰富的资源信息和连接信息，另一方面可以帮助在故障发生时确定具体位置

ü 根据网络拓扑结构，在发生故障时，定位根源故障点，压缩其他相关联的事件

ü 根据事件，察看故障节点所在的网络拓扑位置，或者其他相关的拓扑关系视图，了解故障节点在网络中的关系

ü 拓扑视图中标示出节点的状态，与节点所发生的事件信息可以互相对应，并且调用该节点相关的事件列表

NETCOOL Precision提供对网络的详细连结和配置的发现，并且自动根据网络的拓扑关系确定故障的根源故障点，帮助网络管理人员更好地进行故障管理。

5.1.1. 网络拓扑的发现

传统的拓扑自动发现一般以三层IP拓扑发现为主，建立IP的逻辑视图。但三层拓扑视图在进行故障定位和诊断时，往往无法为管理人员提供实际的网络物理连接状况，而真实的物理连接视图式管理人员解决网络问题时更需要的。因此网络拓扑管理应该能够对网络的三层和二层连接同时进行自动发现，生成网络真实的连接拓扑，为管理人员提供真正的网络拓扑视图。

作为网络状况的准确视图，Precision对网络进行详细的发现，获取不仅2层和3层的网络设备资源信息，而且包括物理设备端口到端口的连接信息。Precision可以获取网络逻辑连接的信息，如 VPN, VLAN, ATM, Frame Relay and MPLS服务。利用这些数据，Precision为网络绘制一个集成的网络设备连接拓扑图，深入到设备的端口层。

在网络发生变化时，Precision会自动发现新的设备增加，对这部分网络进行局部更新的检测，新增设备和连接状况将自动的加入到网络拓扑中，以保证网络视图持续的准确性。

ü 管理人员可以根据需要，确定发现的范围，如相关的IP网段和节点，从而管理需要管理的网络。Precision提供针对发现策略的管理界面。

ü Netcool/Precesion通过发现器（Finder）首先发现网络上存在的节点，其发现器利用PING、SNMP、File（如DNS服务、hosts文件）、Sniffer（监控服务器通信端口，获取与其通信的节点的地址）等方式对网络进行节点发现。

ü 对于发现网络上存在的节点，根据其不同的设备类型利用Precision提供的Discovery Agent进行详细信息的获取。Precision提供针对设备的大量不同DiscoveryAgent，以支持不同的网络结构和网络设备

ü 不同的网路设备，需要通过不同的途径获取设备的二层信息，如一般网络设备需要通过厂家私有的SNMP MIB进行查询，某些交换机，如Cisco Catalysit55xx由于设备SNMP中不提供此类信息，则需要通过Telnet方式获取连接机VLAN信息。Precision为不同的设备提供发现帮助（Helper），自动以不同的方式获取网络设备的连接信息。

ü Precision发现和采集的网络连接和设备信息，根据网络组织的方式，自动建立拓扑关系，生成网络拓扑数据库，这些拓扑信息，可以通过Precision提供的管理界面进行网络拓扑的检查，也可以将这些信息反馈到事件中，实现信息丰富。

5.1.2. 基于对象策略的管理方式

Precision根据拓扑发现的结果，将这些资源分成对象组进行基于策略的管理。系统缺省提供按照设备OID的设备类型分组，并对不同的对象采取不同的监控策略。用户也可以根据管理需要定义更细致的分组方式，如将Cisco7500系列的路由器根据地址细分为核心路由器和接入路由器，分组的条件可以根据管理需要灵活定制。

进行对象分组的目的是能够针对不同的对象组采取不同的管理策略，实现基于策略的管理。如核心路由器除检查其连通性外，还需察看设备端口的状态和设备的CPU、内存的性能指标，而接入路由其主要检查连通性。而且同样是检查连通性，核心路由器的监控间隔为1分钟，而接入路由器的监控监控为10分钟。管理员可以根据管理需要为不同的对象组定义不同的监控策略。

Precision的对象分组采用Active Object Classes（AOC）定义格式，AOC为树状结构，子对象组会自动继承父对象祖的策略，也可以对子对象组的策略进行特别定义。管理人员可以针对对象组而不是每个设备定义管理策略。Precision的对象分组规则确定后，既是对网络拓扑进行重新发现，也可以自动按照原先定义的规则进行自动分组，并自动套用定义好的监控策略。这些对象信息可以传递给Omnibus事件管理核心，因此当事件发生时，可以根据设备所在的对象组，确定对其事件采集的处理措施。

5.1.3. 基于网络拓扑的根源故障分析

在网络中一个故障的发生可以会引发一系列的其他设备告警，管理人员同时会收到大量的网络事件，因此快速找到问题的根源点，确定根源故障事件和受影响的事件，对减少网络事件噪音，快速解决网络问题非常重要。

Precision RCA （根源故障分析）可以隔离根源故障警告，而不是简单的报告事件。当故障发生时，Precision RCA会关联正确的设备和在拓扑数据库中的连接信息，自动分析真正的根源故障点，即指出真正发生故障的设备和端口，所有由此引发的故障事件会自动被关联。管理员可以查看由此故障影响的设备。这种根源故障分析可以使管理员能够集中精力处理真正需要修复的设备，而不被事件噪声所影响。

故障根源分析的的情况可能有多种情况，如：

1、如某个交换机端口故障可能引发下连一串设备发出连通性故障，如下图：

Precision根据网络的连接关系，会自动定位根源故障点为交换机端口，并压缩其他相关事件。

2、某个节点的故障会引发相连端口的报警，如下图：

Precision会根据网络连接关系确定根源故障点为Node B，并压缩其他端口故障事件。

3、当线路出现故障时，两端的端口可能都会产生端口故障报警，如下图：

Precision会关联两个时间，压缩其中一个。

4、当物理端口故障时，其上的逻辑端口会产生报警事件，如下图：

其中Node B的端口2和3为物理端口1的逻辑子端口，Precision会自动检查端口关系，确定物理端口为根源故障事件，压缩逻辑端口事件。

Precision RCA 为内置的智能策略，网络结构发生变化是不需要重新定义，Precision会自动根据网络连接关系确定根源故障点，压缩受影响的事件信息。

5.1.4. 网络拓扑视图

网络拓扑关系通过自动发现后，会建立网络的拓扑数据库，管理人员可以根据网络管理需要察看网络的物理、逻辑和MPLS连接试图或者根据管理需要建立逻辑关系视图。

物理视图：

三层视图：

MPLS视图：

逻辑网络视图：

VLAN视图：

分区编辑界面：

同时管理人员可以查看节点的配置信息和连接关系，并且查找某个IP地址和其所在的位置。

查找网络节点或端口：

节点的端口信息：

节点间详细的连接信息：

此外Precision所有的拓扑数据库的内容都存储在数据库中，通常会根据用户的需要查找更多的管理信息，并以表格的方式呈现。这种功能一般在发生故障时，管理人员可以直接选择事件，调用工具，察看该故障设备相关的拓扑视图，如针对HSRP故障，察看该节点的HSRP配置视图；针对VLAN故障，察看该节点的VLAN视图，以帮助管理人员了解故障设备的配置和连接信息。

5.1.5. 拓扑管理与其他管理功能的集成

单纯的拓扑视图对网络运维的意义并不大，因为网络拓扑视图往往是以设备为基础单位，监控的直观性和综合性不够。而网络监控往往需要在一张监控视图中包含更广泛的信息，一般都需要通过综合逻辑监控视图的建立来完成。从拓扑管理充分发挥作用是配合故障管理，在网络出现问题时，察看故障设备所在的网络位置、与其他节点的连接关系、相关的配置信息等等。Netcool网络管理将故障管理和拓扑管理紧密结合，配合管理人员进行网络维护工作。

拓扑与故障集成的关系结构如下图所示：

拓扑管理与故障管理的集成体现在几个方面：

ü 拓扑发现的资源信息可以帮助丰富原始的网络告警，包括节点和端口的配置和连接信息。

ü 在事件列表中可以调用查看拓扑信息

ü 拓扑颜色变化应该反映节点相关事件的最高故障级别，并且可以查看节点的事件信息，NETCOOL各种来源事件信息可以体现在拓扑中（不仅仅是状态和和Trap事件）

ü 拓扑内置的根源故障分析功能会自动对故障信息进行与拓扑的根源故障分析，确定根源故障点

管理人员可以在事件窗口中选择相关的事件，调用网络拓扑视图，也可以在网络拓扑视图中，选择节点，查看其实时的事件列表，其操作过程如下图所示：

5.1.6. 与网元配置变更工具的集成和二次开发工作

定位NMS（网络管理系统）解决方案的Netcool尽量避免与EMS（网元管理系统）功能重复和数据不一致，由于设备的配置变更主要通过设备厂商所提供的网元管理系统（EMS）或工具实现，Netcool在功能上不涉及对设备进行配置下发和更改，基于现有Netcool实践经验，该部分功能主要通过集成EMS实现，如Ciscoworks的集成，当网管员需要对设备进行配置变更时，可在Netcool统一界面通过菜单工具自动登录和调用Ciscoworks功能画面，实现对设备的配置变更。

如果用户对设备配置变更没有采用任何EMS，则需要二次开发才能实现对所有设备的统一配置变更管理。

5.2. 设备配置管理

ü 网管系统能自动定期对设备配置文件归档。当系统检测到配置改变时立即归档。

ü 网管人员可以通过配置管理，查阅、比较设备的配置修改情况，并可对配置进行相应调整。

ü 配置文件可以方便的直接上传、下载（设备的配置文件、操作系统能够方便、快捷的备份、恢复和更新）

ü 可以按照用户名、设备分类显示设备的配置修改记录

基于设备SNMP MIB库可提供的设备配置信息均可通过Netcool Precision自动发现和采集归档，并可做实时查询和历史统计分析，针对设备SNMP MIB不能提供的设备配置信息需通过二次开发实现配置管理工具，基于JSP或HTML可方便集成于Netcool统一管理和调用。

5.3. 网络性能管理

l运行参数检测

ü 实时显示监控网络设备的端口、CPU、内存、线路的运行参数。

ü 有仪表盘、饼状图、环形图、柱形图显示设备运行状态和利用率。

ü 有网络协议综合分析功能。

l优化配置、性能管理

ü 监视设备/端口的各种性能指标，用曲线图，柱状图。

ü 全网性能分析，找出网络瓶颈。

ü 智能优化设置设备的QoS

ü 当网络性能下降、网络运行提出特殊要求时以及网络出现故障时有优化配置提示

网络性能和运行参数的监测目标是对指定范围网络运行状况和设备健康状况进行监控，通过网络性能管理，可以判断网络的运行质量、运行效率、流量流向以及连通率水平等，使其更加高效、稳定的运行。网络性能监控制定性能测量的标准和手段，分析网络服务的趋势和行为，在发现性能下降时立即报告，使管理员及时采取措施进行处理。

网络性能数据主要有三大类，一类为网络线路性能信息；一类为网络设备和端口的性能信息，如CPU、内存、端口进出流量；一类为网络流量流向信息，如不同协议的应用类型流经某个网段的总流量等。这三类信息对于发现网络性能问题、进行网络分析和规划都相当重要。

5.3.1. 通过NETCOOL ISM ICMP监控器监控线路性能

ISM ICMP通过PING的方式，对节点的连通性和服务质量进行监控，并将结果报告给事件处理中心，以及时了解网络的连通性、响应时间和丢包率。ISM ICMP监控器采用主动监控的方式，根据定义的周期，定时对节点进行PING操作，并记录整个过程的响应时间和返回的包数。管理员可以根据需要定义监控哪些节点，要求的响应时间阈值为多少，监控的周期为多长。ISM在发现节点无法连通或者响应时间超过阈值时，会将故障报告给NETCOOL ObjectServer事件处理中心。

lICMP Monitor工作机制

ICMP Monitor定期向被监控目的端发出事先定制好的上述ICMP的回应请求（Echo Request）报文来测量具体网络节点或主机的可用性。发出的ICMP报文穿过各级路由器，中间转发报文的路由器可发出类似的响应报文以表明目的端是否可达以及不可达的可能原因。

如果监视器收到从目的端发来的OK回应响应（Echo Reply），则计算响应的时间并记录在有关的文件内，同时以丰富的图形方式显示在ISM的客户端，若监视器在规定的时间内没有收到从目的端发来的响应，则记录为请求失败。

若监视器从中间路由器收到关于目的端的回应响应（此响应也为ICMP报文），则将发送有关故障的事件给ObjectServer，这里监视器将不会计算响应时间。

监视器可配置成发送多个ICMP响应请求报文以计算平均环程时间（RTT）和丢包率。ICMP Monitor可根据事先配置阈值来判断响应延时是否符合服务质量要求，并将不同等级的服务质量以不同颜色在显示出来，一目了然，同时标注具体的通断百分比。此外，还可在配置界面中调整包的大小、每次发送包的数量、发送间隔等来减少网络带宽的占用率。

l网络可达性监控

网络设备的可达性是衡量网络性能的一项重要指标，它是业务得以正常运转的重要保证，因此对此项技术指标的监控和统计是实现网络服务管理的一项基础, 其中网络设备的联通性及网络响应时间是网络可用性的两个重要的组成部分。结合XXXX实际的分级网络环境中各级网络跨度大、网点分布广、重要设备多的特点，加之网络维护人员有限，因此对网络中重要及末端设备的可达性监控显得尤为重要。

l网络可用性监控

测量网络可用性最简单而且行之有效的方法就是借助基于ICMP协议的实用工具Ping来发出ICMP回应请求（Echo request）数据包，根据对其响应包Echo Reply的统计和分析来评估网络的可用性。

5.3.2.利用NETCOOL ISM SNMP监控器监控设备性能

通过ISM SNMP监控器，对网络性能进行实时监控，对网络设备的性能、端口的流量，以了解网络设备运行的效率。

l性能信息：

路由器及交换机（CPU、MEMORY使用率、背板利用率）、端口指标和利用率；

l流量信息：

物理端口及逻辑子端口的输入/输出流量及带宽占用率；所有ISM服务监控器都可以通过诸如Netscape Navigator或Internet Explorer 浏览器进行动态配置。所有监控参数允许管理员定义监控周期和阈值，以及服务水平指标，当性能下降时，以事件的方式通知管理员进行报警。相对一般的SNMP监控手段，ISM SNMP监控器，除对SNMP采集的参数进行阈值判断外，还提供服务水平的监控，如设备CPU处于正常的情况占99%以上，该设备才达到要求的服务水平。这样管理员不仅可以了解实时的性能情况，还可以整体衡量设备的运行情况。对ISM SNMP监控采集的数据，ISM提供实时和历史的性能报表，管理员可以实时查看每个性能当前的状态和服务水平状态，并查看详细的性能曲线，报告包括小时、三小时、天、周、月报表。

5.3.3.性能监控的主要对象

针对网络性能的考虑，主要对以下几个方面的一些参数进行监控：

l环境：电流、电压、温度

l 硬件：风扇、CPU、Memory

l 广域网端口：带宽利用率、错误包数，丢包数

l 端到端时延

l 广域网端口：数据流量的分类统计

l ……

5.4. 审计与故障报警管理

ü 监测设备的故障信息，将故障定位到端口

ü 记录审核所有操作设置，记录发生、发现的意外事件，并可按条件查询变更审计事件和历史记录。

ü 系统日志分析功能：当网络设备运行一些事件(如:端口、链路的开启或关闭、设备硬件错误、线路/配置文件等)有分析报告日志。

ü 设备事件报警能统计、智能组合网络报警事件，有控制台集中分类显示。

事件采集只是网络管理工作第一步，是网络基础设施智能化管理非常重要的基础。随着网络规模的不断扩大，所采集信息和噪音数量的迅速增长，为达到在问题发生时，反映更迅速，更智能，对网络管理的需求已经远超出基本的信息采集和汇总，而是需要智能的网络管理系统。

网络智能化管理系统所面临的挑战是：将大量信息分析，处理，转变为真正有意义的信息，即去除噪音，发现网络正在发生什么事情。

5.4.1. 事件等级的定义

故障事件等级	英文名称	含义
0	Clear	状态正常或可清除事件
1	Indeterminate	未知事件
2	Warning	警告
3	Minor	比较严重
4	Major	严重
5	Critical	非常严重

事件等级的合理定义，有利于网络管理员迅速发现最需要紧急处理的事件，从而提高整个网络系统的服务水平。

5.4.2.性能事件阀值的定义

NETCOOL可对各种性能参数的报警阀值进行灵活的设定，并对统一参数设定不同等级的阀值。针对XXXX的参考阀值定义如下（实际实施中还需进一步细化定义）：

管理范围	管理对象	性能参数
CPU使用率	Memory使用率	输入/输出流量
阀值A	阀值B	阀值A	阀值B	阀值A	阀值B
核心局域网	核心交换机	65%	75%	75%	90%	50%	70%
服务器群交换机	65%	75%	75%	90%	50%	70%
楼层汇集交换机	65%	75%	75%	90%	50%	70%
核心广域网	核心路由器	65%	75%	75%	90%	50%	70%
一级骨干网	核心路由器	65%	75%	75%	90%	50%	70%
各分子局上联路由器	65%	75%	75%	90%	50%	70%
分子局网络	核心交换机	65%	75%	75%	90%	50%	70%
二级骨干网	下联路由器	65%	75%	75%	90%	50%	70%

5.4.3.事件处理方法

5.4.3.1.先进的相关性处理

事件过滤，减少事件的噪音，提供真正有意义的信息。Netcool先进的相关性分析将针对大量的汇聚事件，实现事件的浓缩，有时也许是100：1的浓缩比例，最终让采集的信息变成可管理和有意义的信息。

² 网络信息的相关性处理策略

事件的相关性方法可以从相对简单到特别复杂，全面的业务和服务保障需要实时的、多样的方法组合。

l 基于规则的事件相关性

提供简单但有效的方式，可以显著地压缩事件量，如：一个通用的规则就是同一事件的重复事件压缩。只保留一条带有事件发生次数和事件发生前后时间的事件信息, 以表达重复发生的事件的频率。另一个例子就是关联相关事件，如“link down”和“link up”事件，在发生同一端口的”link up”事件后自动找到其”link down”事件，并清除，以自动恢复故障信息。

l 基于策略的关联方法

依赖与事件相关的外部信息和知识。如收到一个严重告警信息，显示一个设备“Down”，但是如果我们知道（来自于外部数据资源）该系统正在进行系统维护，就可以抑制该事件，或者降低该事件的严重等级从Critical 到Clear。

l 基于设备的相关性

体现在设备层次的异常现象。在这一级别的相关性需要从设备的SNMP MIB库采集一系列数据，并根据规则分析这些数据并得出结论，并将真正的根源事件返回到操作员控制台。

5.4.3.2.诊断和解决问题

先进的事件相关性分析对于今天复杂的网络基础设施管理来说还是不够的。支撑着至关重要业务的企业网络需要先进的诊断和问题解决技术。换句话说，需要网络管理软件可以帮助网络管理者沿着解决问题之路走得尽量远-快速并且尽量少的的操作员参与。智能的网络管理系统应尽可能的提供问题诊断和解决技术，尤其是在事件的采集，汇聚，相关性分析已经很好的完成以后。

l简单自动处理

包括“Generic Clear”，“ping”，“traceroute”以及其它的功能，可以在某种模式的事件发生时，自动调用。如将事件自动升级或者转发到相应有技术的操作员或技术人员（流程系统）。

l先进的自动处理

更复杂的自动处理是通过策略、过程和工具以及人员针对其环境和网络平台的特定知识与经验。可以通过自动的诊断及解决问题过程，抑制或清除不必要的事件，减轻操作员的工作强度，并将网络技术人员解决问题的经验固化在管理系统中。

l设备级诊断

设备级诊断是另一个重要的问题解决方面。相对于只是捕获或者转发基本的的“snmptraps” 或者设备的私有告警，设备级诊断需要分析和计算来源于被管理设备的一组相关的组合值，分析问题的原因。

l根原因分析

通过拓扑结构和技术相关性分析，找到根原因节点，并通知操作员。

网络基础设施智能化管理的目标是：

l 能够在网络管理人员的显示终端上显示尽量少的事件记录。

l 能够保证生成的网络事件更加智能化。

l 能够在网络故障或网络异常发生之前，根据网络事件及时采取行动。

l 尽量能够用自动化的方式处理网络事件。

5.4.4.网络事件管理核心产品NETCOOL /ObjectServer

事件处理是网络管理的核心功能，因为管理员的日常操作即是根据收到的事件报警进行相应的处理，而网络的故障、性能、流量、配置等管理操作，在发生问题时都是以事件的方式进行故障报告。因此网络事件处理核心的功能将很大程度上影响管理的效率。

建议采用NETCOOL /ObjectServer 进行统一的网络事件管理，对事件进行压缩、相关性分析、自动化处理、报警升级、审计报告等工作，为XXXX建立高效、易用、灵活的网络故障管理。

网络故障管理将分成几个过程：

l 以多种方式进行事件的采集，获取网络故障、性能、配置等事件；

l 事件在NETCOOL / ObjectServer中进行压缩和自动化处理，以减少事件信息，并对事件进行自动化响应；

通过上述事件处理步骤，快速发现和定位问题，恢复故障。

5.4.4.1.事件存储

Netcool/ObjectServer数据库是NETCOOL系统的核心，其中所有事件都能实时存储、查看和管理。NETCOOL/ObjectServer属于驻留在内存中的实时主动数据库，以保证高性能的事件处理能力，每秒可以处理超过300条事件，这对于大型网络的故障管理来说是非常重要的。

NETCOOL 将运行维护数据与历史数据分开存储，以确保运维监控的效率。一般网络管理需要保留6个月甚至更长的数据，以进行统计分析和存档，而在日常运行管理中，一般只需要查看最近一周甚至更短的信息，如果采用一个数据库存储，则运行数据库中大量的历史记录势必会影响数据库的处理效率，从而影响实时监控和管理的效率。NETCOOL 运行数据与历史数据分开存储，在线运维数据采用高速的内存数据库保证事件处理的实时性，历史数据采用稳定的关系型数据库保证事件存储的可靠性和容量。实时和历史数据库之间通过Netcool提供的高速网关模块(Netcool/Gateway)实现信息的实时同步或归档。这种结构使事件的处理更加合理。

由于Netcool/ObjectServer是面向对象的，因而能够将故障、警报和提示消息转换成对象，这些对象很容易帮助管理员进行关联、过滤、分类等操作。由于 NETCOOL 将一个故障分解成非常详细的记录字段，管理员可以根据任意字段进行过滤、分类等操作。它们还允许生成逻辑服务小组，包括不同业务、局、分局、部门或设备类型、最新发生的故障等，使管理人员可以访问更确切的信息。

5.4.4.2.事件压缩

网络事件中有很多重复事件，尤其在网络不稳定发生瞬断时。过多的网络事件会使管理员的桌面上罗列大量事件条目，使得管理员无法获取真正需要关注的重要事件，因此对重复事件进行合并对较少管理噪音，帮助管理员快速找到需要处理的故障是非常重要的。

重复事件压缩就是这样的一个过程: 通过将从下层数据源所报告的相似事件加以汇总,合并成一条事件,该事件的内容包含了该事件重复的次数以及发生的起止时间。

从NETCOOL 所有探针和监控器发送到NETCOOL/ObjectServer的事件都带有事件标识符Identifier字段，这个标识符可以唯一的代表此类事件。根据标识符字段，ObjectServer可以自动判断在实时数据库中是否有该事件记录，如果没有，则在数据库中增加一个新的事件记录，如果有，则根据定义更新需要更新的字段，如最后发生事件、事件次数等。由于事件采集器发送的事件中都具有标识信息，因此ObjectServer对重复事件的处理比插入一个新的事件还要快，而不需要借助复杂耗时的数据库操作。

事件的标识在事件采集器的规则文件中进行定义，对所有事件都有现成定义的标识符，用户可以根据实际的管理需要进行调整。如一种极端情况就是对于不希望进行压缩的特殊事件将其唯一标识符包含的组合中增加时间字段，由于不同时间发生的事件具有不同的标识符，ObjectServer就不会按照重复事件对其进行处理。

此外在进行重复事件的更新时，用户也可以选择更新的字段，除缺省的事件、数量外，任何一个字段如果希望更新，都可以进行设置，如警告级别、描述等等。

5.4.4.3.事件自动化处理

Netcool/ObjectServer具有的Automation功能，可以对各类事件信息进行逻辑判断，并做出相应的动作，如及时删除不必要的信息、完成不同事件之间的关联、对严重事件采用明显的声音报警、自动升级警告级别如果严重事件在一段时间内没有人响应、发送邮件进行自动通知等等。

NETCOOL 的自动化规则定义为Trigger和Action组成，Trigger可以根据事件记录中的任意字段进行判断，当符合一定条件时，触发预定义的管理动作。管理动作可以是针对NETCOOL 自身的事件处理，如升级故障级别、分配管理人员等，也可以是任何外部可执行程序，如发送邮件、声音报警、自动创建故障单等等。

5.4.4.4.事件相关性分析

NETCOOL对事件可以进行相关性分析，事件的相关性分析包含多个层面：

l 同类告警关联，将故障和其恢复事件进行自动相关，并同步更新状态。

l 故障根原因分析，找到发生的根本原因，从而采取有效的处理措施。

l 故障根源故障点分析，找到故障发生的具体位置，并关联由此引发的其他相关事件。

l 业务相关性分析，找到故障影响的业务、部门等信息，并根据影响的范围和成都采取不同的措施

5.4.4.5.同类告警关联

同类告警相关性的实现是在ObjectServer层通过自动操作(Automation)机制来实现的。同类告警相关性提供了这样一种能力，实时查找满足一个条件的事件, 并且基于查找的结果，在ObjectServer里对事件执行一个动作。一个类似的例子就是“ Link Down/Link Up”的情况，当从事件源接收到“Link Up”事件，ObjectServer 将会清除掉相关的故障事件“Link Down”。这些自动操作都是在ObjectServer里对所有的层次来实现的。

传统的事件管理没有办法实现历史故障和当前故障的相关性处理，唯一的处理方法是依靠大容量的磁盘来存储数据，进行事件相关性处理的时候往往要依靠编写复杂的程序。

5.5. 历史统计与网络数据分析

ü 有各种统计分析报表（基于端口、流量、IP、协议分布）报表和各种类型的图形化报告。

ü 提供设备的软/硬件配置类型版本等信息的报表。

网管系统不但需要监控、管理网络的运行情况，还需要提供其网络在各种不同期间的行为特点，网络资源的使用情况，网络人员解决问题的情况，网络服务质量的总体运行情况等信息。另外，网络管理员还需要从不同设备、系统和服务的层次上对网络的长期行为特点进行查看和分析，根据管理的需要输出各种报表，作为评估，决策的参考。解决方案中采用Reporter Gateway将ObjectServer上的事件信息实时发送到磁盘数据库（例如：Oracle），用户无论是用Netcool提供的报表定制和发布软件，还是用第三方报表工具(如Crystal Report)，都可以使用这些数据，对网络性能、故障、资源、运维情况做统计和报表生成发布；基于Netcool平台，用户可以登陆报表服务器查看，定制自己所需报表。对于网络性能的实时和历史统计分析报表用户还可通过Netcool/ISM内部的报表工具产生。

报表应用还可以与NETCOOL/ObjectServer、ISM、网络服务资源库等实现无缝集成，为网络人员提供一种长期的综合视图。报表结果可以按照表格形式、曲线图、直方图或饼图的方式进行显示，报表展现形式灵活、直观，用户可以对这种分析的周期进行选择，如天、周、双周或四周等。

报表从制作的周期看，可以分为日报表，周报表，月报表，季报表和年报表，分别反应不同时间端内网络的工作运行情况。

报表从内容上分为几大类，分别对应不同的管理流程。例如在故障管理类中包括设备故障报表，流量超过阈值报表，线路故障报表等，在性能管理类中包括CPU性能报表，MEM性能报表，带宽利用率报表等。

6.系统管理方案功能实现

6.1.主机系统监控

6.1.1.监控平台支持情况

ITM 6.1支持如下的平台监控：

ØIBM AIX 5.x、IBMAIX 4.3.3

Ø SuSE Linux 8、SuSE Linux 9、RHEL AS/ES 2.1、RHELAS/ES 3.0、RHEL AS/ES 4.0

Ø Windows 2000、Windows 2003

Ø AS/400

ITM能够实现全面的主机设备性能监控和管理，包括：CPU、IO、内存、交换空间、文件系统等性能指数；实现设备接口性能管理，包括：接口速率（比特/秒）、接口输入字节数、接口输出字节数、接口带宽输入利用率、接口带宽输出利用率、接口输入错误率、接口输出错误率、接口输入丢包数、接口输出丢包数等；实现对主机系统日志、错误日志的分析与告警；由于ITM对主机的监控采用了轻量级的EndPoint技术，占用主机资源少，对主机性能影响小，该系统已经有了成百上千的成功实施的案例。

具体的监控项目如下：

6.1.2. UNIX系统

对于UNIX系统的监控，主要从以下方面进行。

UNIX系统信息

包括虚拟空间利用率、页面读写错误情况、物理内存和虚拟内存使用情况、CPU利用率、平均负载情况：

磁盘资源监控

包括前十名的空间利用率、节点(i-node)利用率、磁盘利用率、磁盘读写繁忙程度等。

UNIX进程状况

包括前十名最高的CPU利用率的进程、耗用内存最大的十个进程、进程利用情况列表等：

其它系统资源监控

ITM对UNIX系统的监控组还包括了：

l 磁盘性能

l RPC调用的性能情况

l 用户访问情况

l 服务器网络使用情况

l 文件情况

以上这些监控资源都是在ITM中集中管理和监控。

附ITM的Unix监控指标大类。

实现监控功能	功能描述
CPU	判定是否存在与CPU有关的问题。例如，进程执行前在队列中等待的时间
内存	提供有关内存使用情况的信息，主要关注的问题包括： l 可用内存过低 l SWAP可用空间过低 l 额外的或异常的系统页面调度，如page-in或page-out
文件	给出与有系统文件有关的信息，主要关注的问题包括 l 文件改变 l 文件属性改变 l 文件不存在
文件系统	衡量出文件系统的使用频率，主要关注的问题包括： l 可用字节数过低 l 可用百分比过低 l 碎片过多 l I-nodes的可用百分比过低
网卡	判定已安装的loopback，Ethernet或Token-Ring网卡的问题，主要关注的问题包括： l 输入包的错误率过高 l 输出包的错误率过高 l 输出包冲突过频，如输出包被破坏或网络负载过高 l 网卡状态为非up l 网卡已被设置为enabled，但状态并不是running，网卡驱动可能有错误 l 不能获取网卡的监控信息
进程	查找进程的瓶颈，主要关注的问题包括： l 进程占用过多的CPU l 系统中存在太多的僵尸进程 l 进程被停止或被killed l 请求的进程不存在
安全	提供与系统文件和用户有关的信息，主要关注的问题： l 文件特征的改变，如属主，组属性 l 同一用户登录到系统中的次数 l 可疑的超级用户 l 对root无效的账户ID

6.1.3.Windows系统

对于Windows系统的监控，主要从以下方面进行。

系统健康状况总体指示

直观的总体健康指示标尺以图形的方式直观的展现Windows系统的运行状况。

磁盘资源监控

包含逻辑磁盘利用情况、逻辑磁盘IO情况以及物理磁盘利用情况等方面的性能参数。

内存资源监控

包含对内存子系统使用总体健康状况汇总，还包括对Cache、Paging、Paging File、System Pools等对象的性能参数监控。

系统网络服务监控

包含了Windows系统上与网络相关的各种服务和资源的监控，包括DHCP服务、DNS 相关资源、ICMP统计、IP统计、网卡适配器状况、TCP和UDP相关统计等。

进程监控

包含了对系统中各种进程相关的各方面监控，提供直观的进程健康指标指示器，包括作业对象、Process占用资源情况等统计信息。

CPU资源监控

包含了对系统中中央处理器相关的监控，提供CPU活动和繁忙程度的直观指示。

其它系统资源监控

对Windows其它综合性能的监控还包括设备、文件的变化情况与趋势、系统的日志、系统对象、RAS相关对象、Windows服务、系统的总体IO情况等等，也通过直观的指示器报告系统运行的健康状况。

附ITM的Windows监控指标大类。

实现监控功能	功能描述
事件日志	检查Windows系统事件日志中需要被立即关注的事件，也可简单的指定需监控的事件。事件日志中包括的问题主要有： l 客户端连接问题 l 设备故障 l 服务器连接问题
逻辑磁盘	逻辑磁盘监控主要关注的问题包括： l 每秒钟传输的字节数 l 磁盘空间 l 使用率
物理磁盘	判定系统中是否存在与物理磁盘有关的瓶颈，主要关注的问题包括： l 每秒中传输的字节数 l 使用率百分比
内存	内存监控主要关注的问题包括： l Copy Reads，Data Maps，MDL Reads，Pin Reads对Cache的使用 l 虚拟处理器的大小，以及提交的字节数 l 最低可用内存 l 从Private Bytes，System Code，System Drivers分析内存泄漏 l Paging和Page错误
网卡	网卡监控主要关注的问题包括： l Broadcast结构 l 网卡性能检测 l 网络组件使用率 l 服务器和工作站的服务
参数化事件日志	通过用户指定的事件参数，检查Windows NT或Windows 2000的事件日志中的事件，如EventID，RepeatCount等等。
参数化服务	监控用户指定的服务
进程	查找与进程有关的瓶颈，主要关注的问题包括： l 是否存在Handle泄漏 l CPU利用率是否过高
参数化TCPIP端口	检查用户指定的TCP和UDP端口，同时用户还可指定端口的报警状态，当任何端口为用户指定的状态时，系统都会产生报警事件
打印机	判定在Windows2000的打印机引擎上是否存在着瓶颈，主要关注的问题包括： l 打印机错误 l CPU利用率是否过高
CPU	判定是否存在与CPU有关或来自CPU的瓶颈，主要关注的问题包括： l CPU利用率是否过高 l 在多CPU系统中，确认是否每一个CPU的利用率是否接近
服务	检查所有已装的服务是否正在运行且功能是否正常，主要关注的问题包括： l 检查关键服务是否正常运行 l 检查所有已装的服务是否都是可启动的，不能启动的服务是确保不会影响到其它的服务

6.2.数据库系统监控

数据库系统是业务系统的核心环节，Tivoli Monitoring for Databases提供了集成的、自动化的数据库监控体系来帮助企业简化数据库的管理，实现对跨平台的数据库系统24x7的自动职守，支持对于Oracle、DB2、Informix、Sybase、MS SQL Server等各种主流数据库软件的监控与管理。

Tivoli Monitoring forDatabases基于上节所述的Tivoli Monitoring架构，通过统一的Tivoli Enterprise Portal界面来监控各种数据库的关键资源，并且为数据库提供了极为丰富的管理功能。

针对数据库，Tivoli Monitoring for Database提供的主要监控能力包括：

ü 数据库服务器基本情况：

包括数据库状态和关键事件、服务器连接数量、命中率最低的十个数据库buffer pool、出错次数最大的十条SQL语句等：

ü 数据库Cache使用情况：

包括各个Cache的使用情况、汇总使用情况等：

ü 数据库Database的状况：

包括数据库和Tablespace的情况：

ü 数据库Process的状况：

包括数据库本身的进程和使用的CPU情况：

ü 数据库访问Session的状况：

包括数据库Session命中率和Session的详细信息：

ITM针对不同的数据库有不同的监控值，ITM对数据库的监控组还包括了：

ü 服务器连接情况

ü 应用SQL活动情况

ü 服务器IO情况

ü 应用服务时间响应情况

等等。

以上这些监控资源都是在ITM中集中管理和监控。

6.3. 中间件监控

对WebSphere和WebLogic，通过IBMTivoli Composite Application Manager for Web Resources (ITCAM for WR)来进行性能监控和管理。

与常规的IBM TivoliMonitoring产品家族的产品不同，(ITCAM for WR定位在J2EE中间件的性能监控。作为主流中间件的监控者，ITCAM for WR支持包括BEAWebLogic Application Server在内的各种J2EE平台：

ØWebSphere Application Server

ØJBoss Application Server

ØSAP NetWeaver Server

ØTomcat Server

ØOracle Application Server

ØBEA WebLogic Application Server

对于WebSphere和WebLogic应用服务器，监控提供了开箱即用的监控器，主要覆盖了如下方面：

n Request Analysis

ØSelected Request – Datasources

ØSelected Request JMS Queues

ØSelected Request Resource Adapters

ØSelected Request - History

n Garbage Collector Activity

ØAllocation Failures

ØGarbage Collections - Selected Allocation Failure

n Log Analysis Datasources

ØSelected Datasource - History

n JMS Summary

n Web Applications

ØServlets / JSPs - Selected Enterprise Application

n EJB Components Workspace

ØEJBs - Selected Enterprise Application

n JDBC Connection Pools

ØSelected JDBC Connection Pool - History

n JCA Connection Pools

n JMS Sessions

n JTA Resources

与前面所述的ITM产品家族一样，ITCAM for WR的图形化界面被整合到统一的系统管理门户中，用户的操作方式完全相同。

6.4. 其他监控方式

区别与其它系统监控工具，Tivoli Monitoring提供了UniversalAgent来帮助用户对监控进行扩展，从而实现其作为通用监控平台的能力。

Universal Agent提供了如下的Data Provider来实现各种情况下的集中监控和监控集成。

Ø API Server Data Provider
通过Tivoli API形式让应用主动发送客户应用的性能参数

Ø File Data Provider
解析日志等文件获取性能进行监控

Ø HTTP Data Provider
HTTP服务器的可用性监控

Ø ODBC Data Provider
通过ODBC接口从数据库系统获取相关应用的性能参数

Ø Post Data Provider
提供可调用脚本实现向Tivoli Monitoring服务器主动发送性能参数

Ø Script Data Provider
通过类似ping这样有性能数据返回的脚本来获取性能参数

Ø SNMP Data Provider
通过第三方程序的SNMP接口获取SNMP MIB或Trap

Ø Socket Data Provider
通过Socket接口向Tivoli Monitoring服务器主动发送性能参数

用户可以对各种第三方应用进行监控扩展，达到深层次和个性化的系统管理。

同时，IBM通过开放过程自动化库(OPAL)来提供已经经过测试的基于UA的监控器，这些可以免费下载的监控器可以在http://catalog.lotus.com/wps/portal/tm获得。

7.存储管理方案功能实现

7.1.备份及数据保护机制

TSM是Client/Server结构的应用。在本方案中安装在备份服务器上的TSM Server集中的进行备份策略、备份存储设备等数据保护相关主题的管理；同时，在被保护的数据库服务器上，安装有TSM Client程序，它接受TSM Server的管理指令，对本服务器上的数据对象进行保护。硬件构架上，配备一台单独的服务器作为备份服务器，集中管理备份/恢复和磁盘阵列和LTO磁带库等备份介质设备。

发生备份时，安装目标服务器的TSM Client根据用户在TSM Server上定义的备份策略，获取数据对象并传输到备份策略定义的存储设备中。在恢复时，根据恢复需要，TSM Server根据TSM Client端的要求从后端存储设备中检索需要的数据，并传输给TSM Client，由TSM Client在目标服务器上进行数据重建。

整个备份平台由TSM统一管理，并根据具体需求实现自动化。

7.2. 文件系统数据备份/恢复

为了在服务器的主机、应用软件系统发生故障时，能够迅速、有效的使系统得到恢复，需要对主机、数据库、应用软件系统进行备份。由于主机、数据库、应用软件极少发生变动，所以它的备份策略也比较简单。

1)在主机、应用软件安装调试完毕后，将主机、数据库、应用软件系统的备份到磁带上。

2)在对主机参数、数据库参数、应用软件进行修改后，及时将主机、数据库、应用软件系统备份到磁带上。

3)定期对主机、数据库、应用软件系统进行全备份。这些全备份可以通过TSM的定时自动完成。

本地非数据库文件破坏而需要恢复时

当数据库服务器的本地非数据库文件遭到破坏需要恢复时，利用TSM软件的图形界面来浏览所需恢复的文件存储集，触动恢复功能，软件靠自动驱动存储设备，加载相应的存储介质，然后恢复指定文件存储集，也可利用命令：dsmc –r命令恢复相应的文件，恢复时，TSM可以实现多线程的数据恢复，可以利用TSM独特的磁带分类集中存放技术，减少磁带的就位时间，提高数据恢复的效率。

7.3. Oracle数据库备份恢复

Oracle在归档模式下运行，利用IBM Tivoli Storage Manager for Daabases模块调用RMAN进行在线的热备份，可以在备份时，对备份数据保存在不同的存储对象中，以满足客户容灾的要求，可以利用ITSM的多线程的数据迁移、利用多个磁带驱动器同时读写提高其数据备份的效率。

针对Oracle的总数据量和增量数据量大小，我们可以利用Oracle的多达三级的增量备份机制，结合ITSM强大的备份数据追踪寻址能力和介质管理功能，制定灵活的备份策略，实现全自动的备份数据的全生命周期管理。

根据客户的数据量和网络条件，我们建议：Oracle的备份以周为备份周期，星期一到星期六做数据库累积增量、归档日志、控制文件和CATALOG用户所有对象的备份，星期天做全备份，保留前面一周期和当前周期的备份，每个周期有两份容余。而且由于该应用的Oracle系统版本较新，也可以利用一些最新的Oracle备份技术，将同样的一份备份数据同时保存在不同的存储介质中去，如磁带和硬盘，以保证备份数据的完整性和安全性。对于Oracle系统的数据备份和恢复的性能，可以通过开辟多个Oracle数据备份通道和多重数据迁移的技术得到保障。

对于以上的备份文件文件，根据管理的要求设定其保存时间，当此类数据过期时，ITSM将自动进行清理，无须管理人员参与。备份时可以利用ITSM的永远增量备份的功能、多线程的数据迁移提高数据备份的效率，也可以利用ITSM独特的磁带分类集中存放技术保证数据存放的合理性，减少磁带的占用，提高数据恢复的效率。如果此类文件较小的话，可以利用ITSM独特的磁盘池的功能，先将这些小文件备份到备份服务器的本地硬盘存储池的ITSM临时存储池中，待达到一定百分比时，在一次性迁移到带库中。

对于以上的备份文件文件，根据管理的要求设定其保存时间，当此类数据过期时，TSM将自动进行清理，无须管理人员参与。备份时可以利用TSM的永远增量备份的功能、多线程的数据迁移提高数据备份的效率，也可以利用TSM独特的磁带分类集中存放技术保证数据存放的合理性，减少磁带的占用，提高数据恢复的效率。如果此类文件较小的话，可以利用TSM独特的磁盘池的功能，先将这些小文件备份到备份服务器的本地硬盘存储池的TSM临时存储池中，待达到一定百分比时，在一次性迁移到带库中。

Oracle业务数据库破坏而需要恢复时

出现此情况，可以通过本地的TSM Server结合TSM for Databases利用备份数据进行数据恢复。恢复时，TSM可以实现多线程的数据恢复，可以利用TSM独特的磁带分类集中存放技术，减少磁带的就位时间，提高数据恢复的效率。

先用最近一次的全备份恢复＋恢复最近一次的增量备份＋增量备份到断点的ARCHIVE LOG来恢复（要求数据库在ARCHIVELOG模式下工作）。这种恢复方式比全部用ARCIVE LOG恢复要快。

如果两份容余的最近一次增量备份都不可用，可以追溯再上次的增量备份来恢复，然后用增量备份到断点的ARCHIVE LOG恢复。

如果最近一次的全备份恢复都不可用上个周期的全备份＋上个周期的最后一次增量备份＋本周期的最近一次增量备份＋增量备份到断点的ARCHIVE LOG来恢复。

如果增量备份都不可用，那么可以用全备份＋ARCHIVE LOG来恢复。

7.4. SQL Server数据库备份

根据江西省财政厅的业务特点，系统的数据备份要求较高，下面我们分别说明数据备份策略：

用户对当前环境的SQL Server数据库，对业务的支撑要求提高到24×7时，就需要考虑在线备份的方式。TSM通过特有的TSM Data Protector for Database/SQL Server模块提供对Windows平台上SQL Server服务器的在线备份。技术构架上，TSM的SQL Server保护模块与SQLServer数据库接口，同时该模块通过TSM API与TSM服务器获得联系并进行控制指令传输和数据传输（在LAN-Free是，数据直接流向带库）。由于SQL Server数据库复杂度低，其并未引入类似Oracle RMAN的接口和机制，在布署TSM for Database/SQLServer后，管理员通过数据库的备份/恢复命令管理数据库的在线备份和各种恢复，TSM服务器以及后端的存储设备都将被透明化。

通过TSM对SQL Server的保护，用户可以实现在线/离线/数据文件/日志等对象的备份，并对各个数据库逻辑对象进行恢复/前滚/部分文件修复/灾难恢复。

7.5. 智能磁带介质管理

除了可靠灵活的备份和恢复，TSM还对存储介质进行有效的管理。 “磁带集中”使每个客户机的每天的备份数据都对应放在一盒或一组磁带上，使得TSM能够用最少的磁带数做恢复，由于磁带数量减少，可以大大降低由机械臂抓带时间带来的时间开销。这是一种迅速、可靠的数据恢复方式。

“磁带重用”的目的是使磁带库或光盘库介质自动轮转，完全实现备份、恢复的无人值守。原理是：当介质上的过期数据越来越多并达到一定限度时，比如介质上80%的数据都过期了，TSM会自动把数个这样的介质的残余数据整合到一个介质中，而其它介质重新进入新的介质轮转中去。最佳的介质管理能力使已用过的磁带盒在到期后能被回收。这种对有效数据持续不断的整合使得TSM能使用比竞争对手产品更少的磁带，这样，在保证将所有有效数据保存进磁带库的同时，也节省了大量存储费用。

TSM并不是在多个磁带盒间将备份数据平均分布，这就解决了需要多个驱动器来启动恢复的问题。另外，它不需要跨多个磁带驱动器从多个客户机来传送数据就能实现对话复用，从而有效实现了所需要的吞吐量。通过将数据从低性能客户机输出给磁盘，TSM可以将数据从单个客户机节点备份到单盘磁带上，这样就提供了更高的数据可用性，因为单一数据流有效的可靠性即为所有存储数据流的介质产品的可靠性(例如，假如备份数据以99%的可靠性在三个磁带盒间进行“条纹化”备份，则有效的可靠性将只有97%）。因为不必等待安装磁带媒体，因此磁盘缓存还提供了用于单个文件恢复(通常占全部恢复的80%多)更快的平均恢复时间。

为了提高关键数据备份的安全性，减少因硬件故障（如磁带读写故障、磁粉脱落、机房发生灾害等）带来的风险，用户也可以通过TSM的双备份功能，将一份备份数据同时写在两份磁带上（需要硬件支持，磁带库至少有2个驱动器）。当备份完毕后，可以把其中一份磁带从磁带库中取出，另外放置到其它安全的地方（如银行保险库中），这样可以形成一个初步的投资较少的关键数据异地灾难备援解决方案。

这些技术都可以被包含到备份策略的设定上，用户可以根据实际需求进行灵活的设置和变更。

8.附件一：网管系统对客户原有环境影响分析

我们所建议的网络管理技术方案、网管产品在多个网管项目中已经过实际的测试和验证，不会对现有网络的正常运行和业务系统的正常使用造成任何影响。

8.1. 网管系统对线路带宽的影响分析

网管系统对网络带宽的占用主要体现在以下几个方面：

l 被管理对象主动发送给网管服务器的信息流量(Syslog,Trap)；

l 网管服务器主动轮询被管理对象而产生信息流量(SNMP、Ping）；

l 网管客户端(Webtop)与网管服务器之间通信而产生的数据流量；

以下根据NETCOOL提供的数据和经验值，对网管系统对网络带宽的占用进行估算分析。

8.1.1. Syslog的信息流量

Syslog信息的最大字节数约为500字节/条，一般而言平均每条Syslog的字节数约为300字节/条。

根据以往实施经验统计，可大致保守地估算出将来网管系统的Syslog的信息量。

管理对象	对象数量	Syslog数量/天	平均流量(bps)	高峰流量(Kbps)
核心路由器	1	500	78	1.5
核心交换机	1	500	222	4.3
	300	5.8

8.1.2. SNMP/Ping轮询的信息流量

网管服务器主动轮询管理对象有两种方式SNMPPolling(Precision IP和ISM SNMP Monitor)和ICMP Ping(ISM ICMP Monitor)。其中SNMP包字节数大约为100字节/MIB，Ping包字节数大约500字节。假设每间隔10分钟轮询一次。对每台接入路由器进行SNMP轮询所产生的数据量见下表：

MIB	需要数据(字节)	数量	轮询周期(秒)	带宽(bps)
设备重启信息	100	1	600	1.3
CPU	100	1	600	1.3
内存(Free/Used)	200	1	600	2.7
链路流量(in/out)	400	4/2	600	21.3/10.7
小计	26.6/16

如果按照Polling 2台或4台路由器，则其数据量为：53.2/64bps。

每台交换机进行SNMP论巡所产生的数据量见下表：

MIB	需要数据(字节)	数量	轮询周期(秒)	带宽(bps)
设备重启信息	100	1	600	1.3
CPU	100	1	600	1.3
内存(Free/Used)	200	1	600	2.7
小计	5.3

因此，对于一台核心路由器（假设）的30个interfaces进行Polling，其产生的带宽占用为：26.6*30*4=3.2Kbps。（此假设为XXXX有4台核心路由器且每台核心路由器有30个interface进行计算）；同时假设核心交换机有两台，使用上面的公式，可以得到polling核心交换机占用的带宽：5.3*2=10.6bps，由此可见，在正常情况下，网管系统给广域网带宽带来的影响微乎其微。

8.1.3. Webtop与ObjectServer之间的信息流量

网管客户端(Webtop)与网管服务器(ObjectServer)按照B/S架构进行数据传递。Webtop从ObjectServer下载事件(经过压缩)的信息，每条事件的字节数大约是600字节；此外还有一些Java Applet和图片数据。假设Webtop界面7*24小时打开不关闭，根据我们的经验，在首次打开页面时，数据量不会超过600KB(1000条压缩后的事件)， 在正常使用过程中，流量一般不会超过5KB。

8.1.4. 带宽影响分析结论

根据以上的分析的结果可以看到，所有的信息数据流量通常不会超过10KB，高峰时也不会超过50KB。

8.2. 网管系统对网络设备的影响分析

网管系统对网络设备的影响主要体现在以下两个方面：

l 网管服务器主动轮询(SNMP、ICMP)被管理对象从而会提高管理对象CPU利用率；

l 网管服务器主动轮询(SNMP、ICMP)被管理对象从而会提高管理对象内存利用率；

SNMP/ICMP轮询对设备CPU以及内存利用率的影响，取决于SNMP/ICMP轮询的间隔，轮询数据包的大小等参数的设置。根据以往工程实施的经验值，当SNMP协议对设备的轮询间隔为300秒，轮询单元达到1000个的时候，对网管系统对网络设备的CPU以及内存利用率的负荷不会产生明显影响。

8.3.监控系统容灾机制

突发的事件可能影响整个监控系统的运行状况，监控系统自身的安全是保证提供监控服务的基础，因此，在本案中同时预先考虑工程中或以后实际管理监控实际情况中发生紧急情况并制定相应的备份恢复方案，使得防范突发事件的发生，同时降低突发事件给整个监控系统带来的影响，从而防范于未然。

针对XXXX网管所监控的设备以及在以后可能拓展的网络设备，提供工程实施前，收集现有网络系统设备中所用到的所有IOS版本，根据现有IOS版本查找是否有该IOS的SNMP Bug；同时模拟现有IOS版本，在实验设备上进行实际的网管配置并实际采集该IOS版本设备的参数，实际检验网管配置是否会对该IOS版本的网络设备造成影响，从而以保证在工程实施前将实施风险降至最低。

针对与网管系统的可靠性，NETCOOL网管系统提供高可用性双机热备份方案，主备Object Server互为备份。当主ObjectServer发生故障不能被访问时，或出现异常情况，备ObjectServer将及时进行自我激活，从而使得整个监控系统的保障得以加强。

提供冷备份，定期将网管系统配置进行全部备份。如果网管主机出现系统崩溃等特殊情况下，仅仅需要在主机上恢复备份，并简单修改配置文件，即可恢复网管系统正常工作。同时在网管系统实施的过程中，将所有网管系统进程加入到操作系统开机进程中，如果网管系统一旦出现shutdown等情况，保证网管主机在重启后可以自动启动全部网管系统进程，进入工作状态，而无需人工干预。这样最大限度的保证了网管系统的安全运行。

补充一点，所有Netcool模块运行状态均可配置在Netcool PA(Process Agent)守护进程监控之下，PA为免费提供的功能，可帮助用户从任意一台配置有PA的机器上查看、修改、启停其他配置PA运行的设备上的Netcool进程。同时，PA守护下的所有进程在发生意外停止运行时，PA均可自动将其重启，并发出告警到网管控制台，数次重启无效将以严重告警方式提醒网管员注意。目的均为确保网管系统的安全顺行。