UNIVERSIDAD NACIONAL DE INGENIERIA , FACULTAD DE INGENIERÍA ELÉCTRICA Y ELECTRÓNICA SISTEMA DE SUPERVISIÓN DE FALLAS Y SERVICIOS PARA OPERADORAS EN TELECOMUNICACIONES USANDO CIC (CISCO INFO CENTER) INFORME DE SUFICIENCIA PARA OPTAR EL TÍTULO PROFESIONAL DE: INGENIERO ELECTRONICO PRESENTADO POR: LUIS MIGUEL MARCELO FERNANDEZ PROMOCIÓN 23 - 1 LIMA-PERÚ 2007
75
Embed
UNIVERSIDAD NACIONAL DE INGENIERIAcybertesis.uni.edu.pe/bitstream/uni/10168/1/marcelo_fl.pdf · Entre las actividades soportadas por el SIGRES están: • Aprovisionamiento de Redes
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
UNIVERSIDAD NACIONAL DE INGENIERIA
,.
FACULTAD DE INGENIERÍA ELÉCTRICA Y ELECTRÓNICA
SISTEMA DE SUPERVISIÓN DE FALLAS Y SERVICIOS PARA OPERADORAS EN TELECOMUNICACIONES USANDO
CIC (CISCO INFO CENTER)
INFORME DE SUFICIENCIA
PARA OPTAR EL TÍTULO PROFESIONAL DE:
INGENIERO ELECTRONICO
PRESENTADO POR: LUIS MIGUEL MARCELO FERNANDEZ
PROMOCIÓN 2003 - 1
LIMA-PERÚ 2007
SISTEMA DE SUPERVISIÓN DE FALLAS Y SERVICIOS PARA OPERADORAS EN TELECOMUNICACIONES USANDO CIC
(CISCO INFO CENTER)
Dedico este trabajo a:
Mis padres, quienes siempre apoyaron toda
iniciativa de progreso con ejemplo de valor y
contante esfuerzo
SUMARIO
El presente trabajo describe la implementación de un sistema de gestión y supervisión de
fallas y servicios para operadoras, esta implementación pretende encajar dentro del
marco del mapa de procesos TOM (Telecom Operations Map) que es ampliamente
adoptado por las operadoras alrededor del mundo.
El sistema implementado se basa principalmente en almacenar en un repositorio
centralizado los eventos y/o notificaciones que alertan de un cambio en el estado,
configuración o incumplimiento en el nivel de servicio SLA en la red de la operadora a
nivel de equipos de red y servidores.
El almacenamiento de eventos en un repositorio nos permite centralizar todos los eventos
independiente de la tecnología o plataforma del equipo o servidor sobre la cual podemos
realizar todo tipo de análisis (correlación de eventos, análisis de causa raíz,
enriquecimiento de eventos, etc.) para posteriormente normalizar y clasificar los eventos,
este trabajo se realiza en forma conjunta desarrolladores y personas implicadas en la
operadora.
La plataforma usada para tal fin es Cisco lnfo Center este nos permite una rápida y
eficiente recolección, consolidación y correlación de eventos en la red. Es también
comúnmente conocido como el "gestor de gestores" porque tiene la capacidad de
comunicarse con los sistemas de gestión de las diferentes plataformas instaladas en la
red, o a punto de serlo, para lograr la consolidación de información que facilite y mejore la
operación de la red. La herramienta permite eficiencia de operación, continuidad del
negocio, reducción de costos de infraestructura IT e incrementa la disponibilidad de los
servicios ofrecidos.
PROLOGO
CAPITULO 1
INDICE
1
CONSIDERACIONES GENERALES Y DESCRIPCION DEL PROYECTO 2
1.1 Introducción
1.2 Alcance del Proyecto
1. 3 Normatividad aplicable
1.3.1 Funcionalidades
CAPITULO 11
IDENTIFICACIÓN DE LA INFRAESTRUCTURA DE RED EN LA OPERADORA
2.1 Tecnologías involucradas
2.2 Elementos de Red
2.2.1 Red de acceso ADSL
2.2.2 Red ATM
2.2.3 Red de Agregación
2.2.4 RedlP
2.3 Topología actual de la operadora
CAPITULO 111
2
2
4
6
9
9
10
10
11
11
12
12
IDENTIFICACIÓN DE LOS SERVICIOS INTERNET EN LA OPERADORA. 15
3.1
3.2
3.3
3.3.1
3.3.2
3.4
3.5
3.6
Descripción de los servicios Internet en la operadora
Servicio DNS
Servicio Radius
Servidores Radius para servicio dial-up
Servidores Radius para servicio ADSL
Servicio LDAP
Gestor de Cuenta
Softswitch
15
15
17
17
19
19
20
21
CAPITULO IV
MÉTODOS DE RECOLECCIÓN DE EVENTOS EN LA RED. 23
4.1 Descripción de los métodos de Recolección 23
4.2 Recolección de eventos en la red de Acceso 23
4.2.1 Recolección mediante AWS (ADSL WorkStation) 24
4.2.2 Recolección mediante NMS iManager N2000-Huawei 25
4.3 Recolección de eventos en la red de ATM usando CWM(Cisco Wananager)
4.3.1 Interfaz de administración de averías
4.3.2 Traps
4.4 Recolección de eventos en la red de Agregación y la red IP
4.4.1 Proceso ovtrapd
4.5 Recolección de eventos para los servicios IP
4.5.1 Listado de pruebas DNS
4.5.2 Listado de pruebas LDAP
4.5.3 Listado de pruebas RADIUS
4.6 Solución basado Cisco lnfo Center
4.6.1 Probes o Sondas
4.6.1.1 Funcionamiento básico de las sondas
4.6.1.2 Fichero de propiedades
4.6.1.3 Fichero de reglas
4.6.1.4 Parada y arranque de las Sondas
4.6.2 INTERNET SERVICE MONITOR (ISM)
4.6.2.1 Arquitectura Netcool/lSMs
CAPITULO V
ANÁLISIS Y PROCESAMIENTO DE EVENTOS EN LA RED.
5.1 Normalización de Eventos
5. 1. 1 Repositorio Centralizado
5.1.2 Proceso de Normalización
5.2 Correlación de Eventos
5.2.1 Detección de duplicaciones de eventos
5.2.2 Enriquecimiento de eventos
5.2.3 Correlación de evento de falla con su evento de Clear (on/off)
5.2.4 Automatizaciones para eliminación de eventos
28
28
28
30
31
32
32
34
36
39
39
41
42
43
44
45
45
47
47
47
48
51
51
52
53
53
5.2.5 Intermitencia de eventos
5.3 Análisis de Causa Raíz en los eventos
5.4 Solución basado Cisco lnfo Center
CAPITULO VI
MECANISMO DE PRESENTACIÓN Y GENERACIÓN DE REPORTES DE LOS
EVENTOS.
6.1
6.2
6.3
Web de supervisión
Web para la monitorización de servicios de Internet
Solución basado Cisco lnfo Center
6.3.1 CIC/Webtop
6.3.2 CIC/Reporter
CONCLUSIONES
BIBLIOGRAFÍA
54
54
56
61
61
64
64
64
65
67
68
PROLOGO
Este trabajo pretende buscar un consolidado para la gestión de fallos sobre la situación
del hardware, los servicios y las aplicaciones a lo largo de toda la red para cualquier
operadora, constituyendo una única interfaz de gestión para los equipos de operaciones
de red y TI. Esto facilitara a los citados equipos la identificación y gestión de los
problemas de infraestructura, en tiempo real.
La suite CIC (Cisco lnfo Center) es el agente para gestión de fallos en la red
perteneciente a un Soporte de Funcionamiento de Red (OSS) de última generación Estas
soluciones de vanguardia trabajan conjuntamente para recopilar y consolidar información
sobre redes, detectar eventos asociados que puedan generar disfunciones en el
funcionamiento de la red y mejore así la eficiencia de las redes simplificando la
administración de grandes redes mediante la automatización de los procesos, la
integración de los procesos de servicios y la habilitación del personal para que pongan el
foco en actividades de mayor nivel.
CAPITULO 1
CONSIDERACIONES GENERALES Y DESCRIPCION DEL PROYECTO
1.1 Introducción
La importancia de un sistema integrado de gestión de red y servicios radica
principalmente la amplísima gama de arquitecturas de sistema para garantía de servicio y
gestión de alarmas, que se pueden ir ampliando para alcanzar múltiples niveles de
rendimiento, tanto en consolas como en gestión de eventos. Las empresas proveedoras
de servicios y las grandes redes corporativas evolucionan para dar soporte a mayores
anchos de banda y a nuevos servicios. Por tal motivo la solución que se plantea permite
que puedan configurarse y realizar la transición entre redes con toda facilidad, ideal para
infraestructuras que tienden a expandirse con rapidez.
Este documento pone de relieve las numerosas ventajas que conlleva la implementación
de un sistema Integrado de gestión de eventos en grandes arquitecturas distribuidas,
como:
• Contención de gastos de explotación (reducción de los costes de operación de los
centros de gestión de red o NOC).
• Reducción de los gastos de capital (al disminuir las consolas de gestión).
• Mayor facilidad para ampliación de los sistemas de hardware/software mediante la
minimización de la carga en consolas.
• Mejora del Mean Time to Resolve (tiempo medio de reparación o MTTR), gracias
a una mayor capacidad resolutiva de la intervención humana.
• Evitar penalizaciones por el incumplimiento de los contratos de nivel de servicio
(SLA).
1.2 Alcance del Proyecto
El sistema SIGRES - Sistema Integrado de Gestión de Redes y Servicios - es un
proyecto global y sinérgico concebido por T-LATAM (Telefónica Latin America) para
actuar sobre las redes ADSL e IP de sus operadoras latinoamericanas, así como en los
servicios suministrados por estas redes.
Por ser una herramienta involucrada con las capas de gestión de red y servicios, SIGRES
3
podrá atender a los complejos procesos de negocios de Cumplimiento de Servicios
(Service Fulfillment), Garantía de Servicios (Service Assurance) y demás procesos
asociados, posibilitando su actuación en diversos niveles de gestión.
Según la recomendación M.3010 del ITU-T y la Figura 1-1: Sistema Integrado de Gestión
de Red y Servicios, SIGRES contendrá las siguientes funcionalidades:
1. Gestión de Provisión y Activación: permite la optimización de recursos de red
mediante la provisión dinámica y flexible de servicios, incluso de forma masiva.
2. Gestión de Inventario de Red: hace la gestión en línea de los recursos (equipos y
enlaces) y servicios existentes en las redes cubiertas, posibilitando la disposición
de datos confiables para las demás operaciones de la operadora (Área de
Negocios, Planificación, Operación y Mantenimiento, etc.).
3. Gestión de Alarmas: provee la supervisión y gestión centralizada de fallos en la
red. Su integración con los módulos de Inventario y Desempeño permite el
enriquecimiento de alarmas, la detección de causa-raíz, la definición de clientes y
servicios afectados, así como la toma de acciones pro-activas mediante la
detección de umbrales de desempeño excedidos.
4. Gestión de Desempeño: monitoriza el desempeño de la red y servicios
registrados, permitiendo ejecutar medidas, observar la degradación de la calidad
del servicio y soportar acciones pro-activas para resolución de problemas. Los
datos de prestaciones también podrán soportar eventuales acuerdos de niveles de
servicios con los clientes internos y externos de la operadora.
Entre las actividades soportadas por el SIGRES están:
• Aprovisionamiento de Redes y Configuración de Servicios.
Se realiza una labor de descarte y lilb'Bd.>. ya que en algunos ""'°" el voltm1en ele ahumas es enorme y de adaptación a l()S cumpoo de la alauna noanalizada
j•c,·,.w.,•·,·,.· ... :Il>
Catálogo de Alarmas
NORMALIZADO
•! ::---:".'" ..... ·• · · • •· •��-.. -- __ ..
'fms la labor de adaplación realizada. los mrevoa campos se almacenan en la BBDD del O ·ect Smver
ObjectServer Tabla alttt1.statas dota BBDD del Object Server. En esta tnbla so guardan los campoo de las a lannas.
1 ipología de evento: ADSL, A TM, gregadores, CorelP, Servicio,
Desempeño, Polling, RAS
Fecha de última actualización de la alarma
Número de veces que ha llegado la
Identificador único de la alarma, número de serie del evento
Tabla 5.1.2 Definición de alarma normalizada.
51
Para la gestión de las alarmas normalizadas de todos los equipos de la red, además de
las provenientes de la monitorización de los servicios de Internet se elaboró el Catálogo Normalizado de Alarmas., este es un documento Excel en el que se distribuyen por vistas las alarmas normalizadas de todos los equipos tal como se mostrarán en el repositorio Normalizado cuando las visualicemos.
5.2 Correlación de Eventos
Para la gerencia de fallos del proyecto SIGRES, varios tipos de correlaciones fueron implementados. Este apartado describirá tales correlaciones.
• Detección de duplicaciones de eventos
• Enriquecimiento de alarmas
• Correlación de evento de falla con su evento de Clear ( on/off)
• Automatizaciones para eliminación de eventos• Intermitencia de eventos
5.2.1 Detección de duplicaciones de eventos
Para elementos de red que presentan algún fallo, es normal que, en determinadas ocasiones, el evento representando este fallo, sea generado más por un golpe. Esto puede ocurrir debido al propio mecanismo de gerencia de estos elementos o debido al funcionamiento intrínsico de los elementos de red. Aunque este evento esté siendo
52
generado continuamente, del punto de vista de gerencia, sólo un evento es necesario. El
proceso de detectar cuáles eventos son idénticos es llamado de detección "de
duplicaciones de eventos". Para ello el repositorio Centralizado (BBDD en memoria
ObjectServer), utiliza del campo ldentifier para identificar eventos duplicados, o sea,
siempre que él recibe más de un evento con el mismo ldentifier, el ObjectServer
considera que no es un nuevo evento que está siendo recibido, pero sí, está es una
nueva ocurrencia de un evento anterior. La definición del campo ldentifier es realizada en
cada sonda en el proceso de recolección de eventos.
5.2.2 Enriquecimiento de eventos
Al recibir los eventos provenientes de !as sondas, muchos de ellos no poseen la
información de Nombre del Elemento (NEName) o Dirección del Elemento (NEAddress).
Para solucionar este problema de una forma centralizada, fue implementada una política
en el enriquecimiento de eventos, que identifica lo que el evento posee: nombre o
dirección y completa la información que estuviera faltando.
Estas políticas de enriquecimiento son implementadas usando lmpact que forma parte de
la arquitectura de solución de (CIC) Cisco lnfo Center esta herramienta permite
conectarse con Base de datos propietarias para obtener información adicional de los
elementos de red como por ejemplo IP; Nombre, Localidad del equipo,# de Usuarios, etc.
La política de enriquecimiento ejecuta entonces el siguiente algoritmo:
1. Convierte NENAME y NEAddress en mayúsculas.
2. Verifica si NEName es un IP o un nombre.
3. Si NEName es un IP, entonces:
a. NEAddress recibe NEName
b. Se busca por el IP, cual es el nombre del elemento en la tabla
IMPACT _NENAME_IP
c. NEName recibe el nombre encontrado.
4. Se NEName es un IP, entonces:
a. Verifica si NEAddress es un IP
b. Si NEAddress es un IP, entonces:
i. Sebusca por IP, cual es el nombre del elemento en la tabla
IMPACT _NENAME_IP
ii. NEName recibe el nombre encontrado.
c. Si NEAddress no es un IP, entonces:
i. Supone que NEName sea um nombre.
ii. Se busca por nombre, cual es el IP del elemento en la tabla
IMPACT _NENAME_IP.
iii. En el caso de encontrar el nombre, NEAddress recibe el IP
encontrado.
5. Por e! NEName se descubre cuál es la localidad.
6. Location recibe la localidad.
5.2.3 Correlación de evento de falla con su evento de Clear (on/off)
53
En la red, cuando un evento de fa!!o es generado, este evento se quedará activo en e!
ObjectServer del CIC, posibilitando la visualización por el operador de que existe un fallo.
Cuando el elemento deja de presentar fallo, el propio elemento o un controlado de
elementos, genera un evento de clear para este fallo. Este evento de clear es un nuevo
evento que debe ser correlacionado al evento anterior de fallo. Esta cuestión es resuelta
a través de una automatización (triggers en BBDD) denominada GenericClear, la cual
rueda cada 15 segundos. La automatización GenericClear es resuelta en dos etapas:
Trigger y Action. La etapa Trigger selecciona eventos que contiene información relevante
para la etapa de Action, donde efectivamente ocurre la alteración del registro. Así
tenemos la siguiente regla:
Tigger:
select ldentifier, LastOccurrence, NEName, AlertGroup, AlertKey from
alerts.status where Type = 2 and Acknowledged = O and Severity = O;
Action:
update alerts.status set Severity = O, Grade= Grade +1 where Severity > O and
Type = 1 and LastOccurrence <= @LastOccurrence and NEName = '@NEName'
and AlertGroup = '@AlertGroup' and AlertKey = '@AlertKey';
update alerts.status via '@ldentifier' set Severity = O, Acknowledged = 1;
5.2.4 Automatizaciones para eliminación de eventos
El objetivo del de estas automatizaciones es mantener los eventos que actualmente
representan fallo, o sea, sólo los eventos actuales. Para efecto de histórico, los eventos
son enviados a la base de datos Oracle, pero en el ObjectServer debemos mantener sólo
los eventos actuales. Debido a ello algunas automatizaciones fueron creadas para
eliminar eventos que ya no representen un problema. Son ellas:
54
• DeleteClears
= Delete 24hs old
DeleteClears
La regla DeleteC!ears rueda cada 93 segundos y su objetivo es borrar los eventos que
estén en el estado de clear de más de 5 minutos.
Regla: delete from alerts.status where Severity = O and Abertura <> 10 and
StateChange <= (getdate - 300);
Delete 24hs old
La regla De!ete 24hs o!d rueda cada 1577 segundos y su objetivo es remover los eventos
más antiguos que 24 horas.
Reg!a: delete from alerts.status where ( LastOccurrence < getdate - 86400 );
5.2.5 Intermitencia de eventos
Existe en la red la posibilidad de algunos fallos intermitentes, por ejemplo, una puerta de
un router que se cae e inmediatamente enseguida sube nuevamente. Este tipo de evento
es de difícil observación por el operador, principalmente si la puerta pasa más tiempo
activa que inactiva. En conjunto con la operadora se definió por crear en el ambiente de
gerencia de fallos, una variable que fuera capaz de medir la intermitencia de un
determinado evento. Para que midamos este dato, utilizamos el campo Grade del evento
en e! CIC, y hicimos con que cada Clear para un evento el Grade incrementara en 1.
Como, al recibir un clear el evento continúa activo por lo menos 5 minutos, es de
esperarse que un evento intermitente vuelva a representar fallo antes de este periodo,
luego el campo Grade irá incrementando cada ocurrencia.
5.3 Análisis de Causa Raíz en los eventos
Dentro de un ambiente de red controlado, muchas veces existe avalanchas de eventos
que son decurrentes de una única causa. Entendemos como Analice de Causa Raíz la
correlación hecha entre varios eventos diferentes, a fin de identificar cua! evento puede
ser considerado como "causa raíz" de otros eventos, facilitando la identificación por parte
del operador de cuál es el problema real. Un ejemplo típico de este tipo de correlación es
el caso donde varios eventos de Node Down llegan hasta la interfaz del operador, pero
55
efectivamente la causa de estos eventos es la caída de sólo un equipo o una interfaz de
un equipo. Aunque simple de ser imaginado este problema es de compleja resolución
automática por los sistemas utilizados, por esto varias herramientas del CIC, fueron
utilizadas en conjunto para producir el efecto deseado por el cliente. Son ellas:
Automatizaciones, Políticas del lmpact y Políticas del Precisión.
Para el proyecto las siguientes reglas de correlación de causa raíz fueron desarrolladas:
1 Correlación de Causa Raíz entre eventos de un mismo nodo.
Según esta definición, si el sistema recibe varios eventos de shelf, slot y puerta deun
mismo nodo, el sistema deberá correlacionar estos eventos encontrando la causa raíz.
2 Correlación de Causa Raíz entre eventos Node Down y otros eventos del mismo
Nodo.
Según esta definición, si el sistema recibe un evento de Node Down, este
deberá ser considerado con causa raíz de otros eventos ocurridos para el
nodo.
3 Correlación de Causa Raíz entre eventos Node Down.
evento
mismo
Según esta definición, si el sistema recibe un evento Node Down, el sistema deberá
relacionar este evento con otros eventos Node Down de nodos aislados por el fallo del
primer evento.
5.4 Solución basado Cisco lnfo Center
56
En este apartado se describe la distintas herramientas que hacen posible la
implementación de las tareas emprendidas en este capitulo.
Histórico de Eventos
l!f ,iJl.f lJii:¡; 1 \
lmpact
ObjectSen,e
Sondas
# r
Webtop
• •
Figura 5.4 Solución Cisco lnfo Center.
lmpact es la principal herramienta de análisis y correlación de datos para la suite de
productos CIC. Utilizado principalmente para customizar y mejorar el rendimiento del
ObjectServer haciendo posible el enriquecimiento de eventos, notificación de eventos
especiales y la integración con otros sistemas como bases de datos, sistemas de
mensajería, aplicaciones de inventario, etc. lmpact puede enriquecer y actualizar un
determinado evento con información contenida en su 8800 interna o en otras bases de
datos como Oracle .
LJ OBJECTSERVER
IMPAC
Tratamiento
avanzado de
eventos
u Figura 5.4.1 lmpact (Tratamiento avanzaao ae eventos).
Precision /Topoviz
BBDD
interna
57
Precision nos permite obtener la topología de red desde una BBDD cargada mediante un
procedimiento mixto de autodescubrimiento de red y carga por fichero.
La base de datos de topología de red de Precision se actualiza mediante dos procesos
distintos:
Carga automática de datos de red mediante descubrimientos. Precision dispone de
agentes que debidamente configurados realizan el descubrimiento de la red y almacenan
los datos obtenidos en la BBDD de topología.
Carga manual mediante fichero de texto. Los datos que se introducen en la BBDD de
topología mediante carga por fichero son facilitados por TdP. Mediante unos scripts de
Unix, los datos que siguen un determinado formato en el fichero, son leídos y extraídos
para ser almacenados en la base de datos.
�--·· Re&
·�- -- - a, .
- --
Arqt1i'-·o de Carga de.
Totologia
Amos
Precision
Figura 5.4.2a Funcionamiento de Presicion.
1 Las probes recolectan eventos de la red y los encaminan al ObjectServer.
58
2 De tiempos en tiempos el Inventario deberá crear un archivo con toda la información
de topología, la cual será cargada en el precision.
3 Dentro del precision, el componente Model es el responsable por el banco de datos
de Topología.
4 El gateway del prec1s1on mantiene informaciones de eventos, provenientes del
ObjectServer, y de topología, provenientes del Model, relacionándolas.
5 El Componente Amos del Precision es responsable por el análisis de causa raíz
(RCA - Root Cause Analice). Relacionando las informaciones de eventos con la
información de topología él identifica cuáles eventos deben ser considerados Causa
(Root) y cuáles deben ser considerados Síntoma (Symptom).
6 Después del analisis el Gateway actualiza estas informaciones de !os respectivos
eventos en el ObjectServer.
Para que un evento llegue hasta un analice de causa raíz es preciso que él pase por un
filtro de selección, tenga un reconocimiento sobre cual regla de analice él participará, sea
posible encontrar la entidad con fallo en el banco de topología y sea posible encontrar el
elemento de referencia para la designación de la correlacion. Este proceso puede ser
verificado por la siguiente figura:
No
No
No
Discard
ObjectSe-rver
Ewnt En.-k:hment
Updale E�nt
Yes
Figura 5.4.2b Filtro de selección para RCA.
AMOS
OOL lnSE-rt
Statsm�nt
59
Una vez que los eventos llegan estén disponibles para el proceso Amos de tratamiento
de causa raíz, el precision se utiliza de los siguientes conceptos para este tratamiento: