Tesina Final
-
Upload
deusexmachina-thx-deusexmachina -
Category
Documents
-
view
41 -
download
2
Transcript of Tesina Final
INSTITUTO POLITÉCNICO NACIONAL
ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA UNIDAD CULHUACAN
SEMINARIO DE SEGURIDAD DE LA INFORMACION
IMPLEMENTACION DE CONTROLES TECNICOS PARA MONITOREO DE SLA’S
EN PAGINAS WEB
INTEGRANTES
HERNANDEZ ROSA ISRAEL ISSAC
MIRANDA BAUTISTA ISRAEL FELIPE
VALLE GARCIA SALVADOR
ASESOR
DR. ANTONIO CASTAÑEDA SOLIS
ENERO-JUNIO DE 2011
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Contenido
OBJETIVO...................................................................................................................V
PLANTEAMIENTO DEL PROBLEMA.........................................................................VI
JUSTIFICACIÓN........................................................................................................VII
CAPITULO I: CONCEPTOS DE ADMINISTRACIÓN Y MONITOREO DE REDES.....1
1.1 Elementos de la Administración de Red con SNMP...........................................2
1.1.1 NMS (Network Management Station)...........................................................2
1.1.2 Agentes.........................................................................................................3
1.1.3 Protocolo.......................................................................................................3
1.2 Arquitecturas de Administración de Red.............................................................4
1.2.1 Arquitectura centralizada..............................................................................4
1.2.2 Arquitectura Distribuida.................................................................................5
1.2.3 Arquitectura Jerárquica.................................................................................6
1.3 Modelos de administración y monitoreo de redes...............................................7
1.3.1 Modelo OSI (FCAPS)....................................................................................8
1.3.2 Modelo De Administración TMN.................................................................14
1.4 Gestión de Niveles de Servicio.........................................................................17
1.4.1 Indicadores de Nivel de Servicio.................................................................19
1.4.2 Implementación de acuerdo de nivel de servicio........................................22
1.4.3 Monitorización de los niveles de servicio....................................................23
1.4.4 Revisión de los acuerdos de nivel de servicio............................................24
CAPITULO II CONCEPTOS BASICOS DE PROTOCOLOS TCP/IP.........................26
2.1 Protocolo de control de transmisión (TCP)........................................................26
2.2 Protocolo Internet (IP).......................................................................................27
2.3 Protocolo de datagramas de usuario (UDP)......................................................28
2.3.1 Características del protocolo UDP..............................................................29
2
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
2.4 Protocolo de mensajes de control de Internet (ICMP).......................................31
2.4.1 Mensajes informativos................................................................................32
2.4.2 Mensajes de error.......................................................................................33
2.5 HTTP.................................................................................................................35
CAPITULO III PROTOCOLOS Y HERRAMIENTAS TÍPICOS PARA MONITOREO. 38
3.1 SNMP................................................................................................................38
3.2 SYSLOG............................................................................................................42
3.2.1 Prioridad......................................................................................................43
3.2.2 Cabecera....................................................................................................45
3.2.3 Texto...........................................................................................................45
3.3 NTP...................................................................................................................46
3.3.1 Modos de operación....................................................................................48
3.3.2 SNTP..........................................................................................................48
3.4 IP SLA (Cisco)...................................................................................................48
3.4.1 Beneficios de Cisco IP SLA........................................................................51
3.4.2 Funcionamiento..............................................................................................52
CAPITULO IV CASO PRÁCTICO...............................................................................57
4.1 Monitoreo de los SLA con CISCO IP SLA.........................................................57
4.2 Escenario Planteado.........................................................................................58
4.2.1 Selección de la operación correcta.............................................................59
4.2.2Selección del intervalo de muestreo adecuado...........................................61
4.2.3 Selección de los umbrales de servicio........................................................62
4.2.4 Monitoreo con IP SLA monitor....................................................................64
CONCLUSIONES.......................................................................................................68
REFERENCIAS..........................................................................................................69
Figura 1.1 Modelo Básico de Administración...................................................................................4
3
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Figura 1.2 Arquitectura Centralizada.................................................................................................5Figura 1.3 Arquitectura distribuida.....................................................................................................6Figura 1.4 Arquitectura Jerárquica.....................................................................................................7Figura 1.5 Tareas del Modelo FCAPS...............................................................................................8Figura 1.6 Capas del Modelo TNM..................................................................................................16Figura 1.7 Gestión de Niveles de Servicio......................................................................................19Figura 2.1. Encabezado protocolo UDP..........................................................................................30Figura 2.2 Cabecera ICMP...............................................................................................................32Figura 3.1 Arquitectura NTP.............................................................................................................47Figura 4.1 Ejemplo de monitoreo de SLA.......................................................................................57Figura 4.2 Escenario planteado........................................................................................................59Figura 4.3 Tiempos de respuesta en operación http.....................................................................61Figura 4.4 Configuración para obtener los umbrales de servicio.................................................63Figura 4.5 Configuración de IP SLA Monitor..................................................................................65Figura 4.6 Configuración de Umbrales de Nivel de Servicio........................................................66Tabla 2.1. Tipos de Mensajes Informativos....................................................................................33Tabla 2.2 Tipos de mensajes de error de ICMP.............................................................................35Tabla 3.1 Códigos de Recurso.........................................................................................................43Tabla 3.2 Códigos de Severidad......................................................................................................44Tabla 3.3. SLA tradicional versus IOS de Cisco IP SLA...............................................................54Tabla 4.1. Tiempos de respuesta obtenidos para calculo de umbral..........................................64
4
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
OBJETIVO.
Implementar mediante la herramienta de Cisco IP SLA’s el monitoreo de páginas
web para garantizar el cumplimiento de los acuerdos de nivel de servicio.
5
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
PLANTEAMIENTO DEL PROBLEMA.
En la actualidad diversas funciones en las organizaciones, se realizan a través de
internet, específicamente por medio de páginas web, como son comercio electrónico,
acceso a bases de datos remotas, manejo de cuentas, etcétera. Por lo cual es
necesario garantizar la disponibilidad y operatividad de los servicios en la página web
de la organización, ya que la interrupción de estos servicios se traduce en pérdidas
económicas para la organización.
Mediante los acuerdos de nivel de servicio la organización puede trasladar estas
pérdidas, por medio de sanciones, a los proveedores o área encargada del servicio
web. Por lo que estos últimos deben monitorizar que dichos acuerdos se cumplan,
según los indicadores establecidos y evitar posibles sanciones, a través de alarmas
generadas en cuanto ocurra alguna anomalía.
Cisco IP SLA es una herramienta ya integrada en sus dispositivos de ruteo, que nos
permite el monitoreo del tiempo de respuesta y la automatización del envió de
mensajes en caso de que ocurra alguna anomalía.
6
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
JUSTIFICACIÓN.
Para las organizaciones cuyas actividades se centran en los servicios web es
importante el mantener la calidad del servicio, para eso se crean un contrato
conocido como acuerdo de nivel de servicio, en el cual se asegura que el proveedor
del servicio tiene que mantener la disponibilidad de los servicios web que ofertan
como son bases de datos, archivos en servidores remotos, servicio de correo
electrónico, etcétera.
En los últimos años se han dado casos de ataques de negación de servicios web
como lo han reportado amazon, google, microsoft, sony, quienes han sido víctimas
de este tipo de ataques. Se puede decir que el mayor afectados fue el usuario final,
el cual no conto, con los servicios que estas empresas ofrecen, lo que se traduce en
pérdidas de clientes y sanciones gubernamentales.
El monitoreo de los acuerdos de nivel de servicio, también ofrece la capacidad de
reaccionar a ciertas anomalías que pudieran indicar alguna amenaza a través de
alarmas o alertas que llegan al administrador, el cual puede hacer un análisis de lo
que está ocurriendo en la red.
7
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
CAPITULO I: CONCEPTOS DE ADMINISTRACIÓN Y MONITOREO DE REDES.
La administración de redes es un proceso de control, supervisión, previsión y
corrección de fallas para el óptimo funcionamiento de la red mediante el uso de
herramientas de gestión.
Sus objetivos son:
1. Mejorar la continuidad en la operación de la red.
2. Hacer uso eficiente de la red.
3. Reducir costos por medio del control de gastos y de mejores mecanismos de
cobro.
4. Hacer la red más segura.
5. Controlar cambios y actualizaciones en la red de modo que ocasionen las
menores interrupciones posibles, en el servicio a los usuarios.
El sistema de administración de red opera bajo las siguientes directivas:
1. Colección de información acerca del estado de la red y componentes del
sistema. La información recolectada de los recursos debe incluir: eventos,
atributos y acciones operativas.
8
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
2. Transformación de la información para presentarla en formatos apropiados
para el entendimiento del administrador.
3. Transporte de la información del equipo monitoreado al centro de control.
4. Almacenamiento de los datos coleccionados en el centro de control.
5. Análisis de parámetros para obtener conclusiones que permitan deducir
rápidamente lo que pasa en la red.
6. Actuación para generar acciones rápidas y automáticas en respuesta a una
falla mayor.
1.1 Elementos de la Administración de Red con SNMP.
La administración con el protocolo SNMP para el monitoreo de red se basa en
el modelo tradicional cliente-servidor compuesto por estaciones gestoras y
dispositivos administrados o agentes.
1.1.1 NMS (Network Management Station).
Son los dispositivos independientes que sirven como interfaz entre el
administrador y la red. Poseen software que recibe información de
administración de los dispositivos gestionados o nodos.
Sus principales características son:
1. Aplicación de la administración donde se analizan los datos.
2. Interfaz que permite al administrador gestionar la red.
3. Control de dispositivos remotos.
9
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
4. Una base de información extraída de las diferentes MIBs
(Management Information Base).
1.1.2 Agentes.
Son programas o un conjunto de programas que se encuentran en los
nodos y recolectan información de estos; a esta colección se le cose
como MIB.
Transmite información a la NMS acerca de:
1. Notificación de problemas.
2. Datos de diagnóstico.
3. Identificador del nodo.
4. Características del nodo.
1.1.3 Protocolo.
Es el encargado de la comunicación entre el gestor y el agente,
dependiendo el modelo de gestión implementado.
En la figura 1.1 se muestran los elementos básicos de administración,
en donde el protocolo se encarga de transmitir la información del
agente de monitorización y también de dar respuesta a las solicitudes
de este en caso de alguna anomalía.
10
NSM (Network Management Station) Protocolo Agente de Monitorización
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Figura 1.1 Modelo Básico de Administración.
1.2 Arquitecturas de Administración de Red.
La mayoría de las arquitecturas para la administración de redes utilizan la
misma estructura y conjuntos básicos de relaciones. Las estaciones
terminales, como los sistemas de cómputo y otros dispositivos de red, utilizan
un software que les permite enviar mensajes de alerta cuando se detecta
algún problema. Al recibir estos mensajes de alerta las entidades de
administración son programadas para reaccionar, ejecutando una o varias
acciones que incluyen la notificación al administrador, el cierre del sistema, y
un proceso automático para la posible reparación del sistema.
Se tienen tres tipos de arquitecturas centralizada, distribuida y jerárquica.
1.2.1 Arquitectura centralizada.
En esta arquitectura todas las consultas son enviadas a un sistema de
administración simple, como se muestra en la figura 1.2. Todas las
aplicaciones de administración son instaladas en una solo NMS que
también responde a todos los avisos de los agentes. Si bien es fácil de
manejar, una sola NMS puede llegar a sobrecargarse fácilmente.
11
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Figura 1.2 Arquitectura Centralizada.
1.2.2 Arquitectura Distribuida.
En una arquitectura distribuida se pueden tener varios NMS, ya sea
por ubicación geográfica o para asignar a cada NMS la responsabilidad
de dispositivos específicos.
El tener varios NMS evita que éstos se sobrecarguen, sin embargo,
limita las características del modelo centralizado ya que solo pueden
enviarse mensajes entre ellas pero no pueden actualizar consultas o
resultados de bases de datos de agentes administrados por otras NMS,
como se muestra en la Figura 1.3.
Figura 1.3 Arquitectura distribuida
12
NMS
Agente Agente Agente
NMS
Agente Agente
NMS
Agente Agente
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
1.2.3 Arquitectura Jerárquica.
La arquitectura jerárquica es una combinación de la centralizada y
distribuida. Se tiene una NMS centralizada que solo coordina consultas
enviadas de entidades NMS adicionales.
Se puede delegar varias tareas y responsabilidades a varios sistemas
en la red, de esta manera se mantiene y almacena la información de
una manera centralizada y sin embargo asegura que los sistemas
distribuidos sean responsables del procesamiento de consultas y
respuestas.
La principal desventaja de este sistema es que su complejidad aumenta
bastante.
En la figura 1.4 se muestra una arquitectura distribuida donde el NMS
central almacena toda la información de los agentes, y los NMS 1 y 2
se encargan de administrar a sus propios agentes.
13
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Figura 1.4 Arquitectura Jerárquica
1.3 Modelos de administración y monitoreo de redes.
La administración y monitoreo tienen una gran importancia ya que este
se emplean para mantener el correcto funcionamiento de la red. Nos
permiten realizar un análisis completo en la búsqueda de posibles fallas
que pudieran presentarse en el funcionamiento de la red, así como,
garantizar óptimo rendimiento, ya que permite informar a los
administradores o automatizar reacciones cuando llega a ocurrir alguna
falla en la red.
Existen diversos modelo para implementar una adecuada
administración de red a continuación se describirán algunos de ellos.
14
NMS(Central)
NMS1
Agente Agente
NMS2
Agente Agente
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
1.3.1 Modelo OSI (FCAPS).
La ITU (International Telecomunicatión Union) desarrollo el concepto
de FCAPS (Fault, Configuration, Accounting, Performance,
Security), como asistencia para la administración de redes de
telecomunicaciones en la norma ITU-M.3400. Sin embargo fue ISO
(International Standards Organitation) quien aplico este concepto a
redes de datos y lo denomino OSI (Open Systems Interconnect).
Como se muestra en la figura 1.5 FCAPS es un modelo que separa las
tareas de la administración del sistema en 5 categorías permitiendo una
mejor organización y no requiere de un protocolo específico.
Figura 1.5 Tareas del Modelo FCAPS
Estas capas se describen a continuación.
15
FaultConfiguration
AccontingPerformance
Security
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Gestión de fallas: Una falla es cualquier anormalidad en el servicio y
perjudica el rendimiento de la red, por lo que la detección y corrección
inmediata son indispensables.
La Gestión de Fallas es un conjunto de funciones que permiten
detectar, aislar y corregir un funcionamiento anormal de la red y de su
entorno.
Sus objetivos son:
Reconocer, aislar, corregir y registrar los problemas que ocurren
en la red.
Monitoreo continuo.
Establecimiento de alarmas
Análisis de tendencias para predecir posibles errores
Notificar de manera automática al administrador cuando ocurra
algún problema.
Procedimiento para la gestión de fallas:
1. Monitoreo continuo de los componentes de red
2. Identificación exacta de la ubicación de la falla.
3. Aislamiento de la falla para que la red opere sin interferencia.
4. Reacción ante la falla estableciendo su resolución.
5. Asignar recursos suficientes para su resolución.
6. Proveer una solución.
16
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
7. Notificación, creación de reportes de estado y seguimiento de la
reparación.
Gestión de configuración: La gestión de la configuración
proporciona las funciones para ejercer el control sobre la identificación,
recolección y suministro de datos de los elementos de red.
Por medio de este proceso se inicializan, identifican, configuran y
controlan las operaciones diarias de los dispositivos que conforman a la
red.
Sus objetivos son:
Obtener información para establecer ajustes y modificaciones de
configuración tanto de hardware o software.
Eliminación de los componentes obsoletos.
Generación de reportes y gestión de cambios dentro de la red.
En esta gestión se debe tener en cuenta:
Un acceso rápido a la información sobre configuraciones.
Un inventario continuamente actualizado de los elementos de la
red y de la configuración de los recursos.
Facilidad de acceso remoto a los dispositivos
Simplificación de la configuración de los equipos
17
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Gestión de análisis de datos: Contabiliza el tráfico y los generales
por elementos y enlaces de la red. Los sistemas de monitoreo
recolectan a diario esta información para almacenarla en una base de
datos a fin de generar información útil y manejable para diferentes
objetivos.
Identificar el uso ineficiente de la red.
Evitar sobrecargas dentro de la red y perjuicios a otros usuarios.
Planificar el crecimiento de la red.
Verificar los servicios a los usuarios en función de sus
necesidades.
Gestión de rendimiento: Provee información del desempeño y de la
calidad actual, recolecta y analiza datos de rendimiento con el fin de
asegurar que las prestaciones estén acorde a la necesidad de los
usuarios.
Permite establecer un historial estadístico de sucesos, para tomar
medidas preventivas y correctivas ante posibles conflictos que
degraden la calidad de los servicios prestados.
La supervisión de la calidad de funcionamiento comprende los
siguientes conjuntos de funciones:
Funciones de política de supervisión de la calidad de
funcionamiento.
18
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Funciones de correlación y filtrado de eventos de supervisión de
la calidad de funcionamiento de la red.
Funciones de acceso a datos agregados e información para
pronóstico.
Funciones de recogida de datos específicos de la red.
Funciones sobre la situación del tráfico.
Funciones de supervisión del funcionamiento del tráfico.
Funciones de procesamiento de alertas por sobrepasar los
umbrales de los elementos de red.
Funciones de análisis de las tendencias de los elementos de red.
Funciones de acumulación de datos y supervisión de la calidad
de funcionamiento.
Funciones de detección, cómputo y almacenamiento de la
información.
La información recolectada del monitoreo debe ser interpretada a fin de
determinar el comportamiento de la red y tomar mediad que ayuden a
mejorar su rendimiento. Se pueden detectar comportamientos
relacionados a:
Utilización Elevada. Utilización en altos niveles de los
dispositivos o enlaces.
Trafico Inusual. El tráfico fuera de los patrones normales aporta
elementos importantes en la resolución de problemas de
rendimiento.
19
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Elementos principales. Al identificarse los elementos que más
reciben y transmiten información se puede establecer un
monitoreo más constante debido a su importancia. La detección
de elementos que generalmente no se encuentra dentro de un
patrón de equipos con más actividad ayuda a la detección de
posibles ataques a la seguridad.
Calidad de Servicio. Garantizar las condiciones necesarias a
aplicaciones que requieren de un trato especial, como son VoIP,
video, entre otros.
Control de tráfico. El tráfico puede ser reenviado o ruteado por
otro camino cuando se detecte saturación en un enlace o al
detectar que se encuentra fuera de servicio.
Gestión de seguridad: Controla el acceso a los recursos de la red y
se protege la información para evitar alteraciones. Puede ser mediante
la implementación de controles de acceso, políticas, procedimientos o
funciones de software, dividendo recursos dentro de áreas autorizadas
y no autorizadas.
La gestión de seguridad sigue los siguientes puntos:
Identificación de la información que se quiere proteger y su
ubicación.
Identificación de los puntos de acceso a la información.
20
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Protección y mantenimiento de los puntos de acceso a la
información.
1.3.2 Modelo De Administración TMN.
Su objetivo es proporcionar una estructura de red organizada para
interconectar distintos tipos de sistemas de administración y
dispositivos de telecomunicación. Tiende a ser flexible escalable y
confiable.
Se orienta hacia la cooperación entre los sistemas de gestión
individuales para conseguir un efecto coordinado en la red usando un
conjunto de arquitecturas siguientes:
Arquitectura funcional define la funcionalidad del modelo TNM en un
conjunto de bloques funcionales que se describen a continuación.
Bloque OSF (Operations System Functions): Lleva a cabo
funciones típicas de una administración gestor-agente.
Bloque NEF (Network Element Functions): Agrupa las
funciones que permiten a los elementos de red actuar como
agentes de gestión.
Bloque WSF (Work Station Functions): Otorga los medios
necesarios para conectar al usuario con el sistema de
operaciones.
21
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Bloque QAF (Q Adaptor Functions): Permite la administración
de elementos de red que posean un sistema de gestión
propietario.
Bloque MD (Mediation Function): Actúa sobre la información que
llega de los NEF y de los QAF para adaptarla, filtrarla y
condensarla al formato usado por los OSF.
Arquitectura física, muestra la manera en que los bloques funcionales
se pueden implementar en los dispositivos físicos interconectados
mediante interfaces.
Arquitectura de información está basada sobre un modelo orientado a
objetos y define el formato en que los datos se transmiten entre los
datos funcionales.
Arquitectura organizativa, introduce una relación jerárquica entre los
diferentes sistemas de operación existentes en la red, de tal manera
que existan gestores de bajo nivel para la solución de problemas
técnicos y gestores de alto nivel encargados que garantizar la calidad
del servicio.
Como se muestra en la figura 1.6 el modelo TMN define las siguientes
cuatro capas de la OSF:
Capa de gestión de elemento de red (NE).
Capa de gestión de red.
22
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Capa de gestión de servicio.
Capa de gestión de negocio.
Figura 1.6 Capas del Modelo TNM
1.4 Gestión de Niveles de Servicio.
23
Gestión de Negocio
Gestión de Servicio
Gestion de Red
Gestion de elementos de Red
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
La Gestión de Niveles de Servicio es el proceso por el cual se definen,
negocian y supervisan la calidad de los servicios de Tecnologías de
Información (TI) ofrecidos.
La Gestión de Niveles de Servicio es responsable de buscar un compromiso
realista entre las necesidades y expectativas del cliente y los costos de los
servicios asociados, de forma que estos sean asumibles tanto por el cliente
como por la organización TI.
El objetivo primordial de la gestión de niveles de servicio es definir, negociar y
monitorizar la calidad de los servicios ofrecidos. Si los servicios no se adecuan
a las necesidades del cliente, la calidad de los mismos es deficiente o sus
costos son desproporcionados, tendremos clientes insatisfechos y la
organización TI será responsable de las consecuencias que se deriven de ello.
La gestión de los niveles de servicio debe:
Documentar todos los servicios TI ofrecidos.
Presentar los servicios de forma comprensible para el cliente.
Centrarse en el cliente y su negocio y no en la tecnología.
Colaborar estrechamente con el cliente para proponer servicios TI
realistas y ajustados a sus necesidades.
Establecer los acuerdos necesarios con clientes y proveedores para
ofrecer los servicios requeridos.
Establecer los indicadores claves de rendimiento del servicio TI.
24
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Monitorizar la calidad de los servicios acordados con el objetivo último
de mejorarlos a un costo aceptable por el cliente.
Elaborar los informes sobre la calidad del servicio y los planes de
mejora del servicio (SIP).
Las principales actividades de la gestión de niveles de servicio se resumen en:
Planificación:
o Asignación de recursos.
o Elaboración de un catálogo de servicios.
o Desarrollo de SLAs.
o Herramientas para la monitorización de la calidad del servicio.
o Análisis e identificación de las necesidades del cliente.
o Elaboración del los Requisitos de Nivel de Servicio (SLR) e
Indicadores de Nivel de Servicio.
Implementación de los acuerdos de nivel del servicio:
o Negociación.
o Acuerdos de nivel de operación.
o Contratos de soporte.
Supervisión y revisión de los acuerdos de nivel de servicio:
o Elaboración de informes de rendimiento.
o Control de los proveedores externos.
o Elaboración de programas de mejora del servicio (SIP).
25
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
En la figura 1.7 podemos ver el diagrama de flujo que representa las etapas y
resultados de los de la Gestión de Niveles de Servicio
Figura 1.7 Gestión de Niveles de Servicio
1.4.1 Indicadores de Nivel de Servicio.
Para cada servicio considerado, se debe identificar y definir claramente
el indicador de nivel de servicio a utilizar. También se debe incluir una
descripción de cómo se mide el indicador.
26
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Estos indicadores deben cumplir las siguientes características:
Alcanzable. Los niveles de servicio deben ser logrables. De nada
sirve establecer objetivos para el nivel de servicio que el
proveedor del servicio sabe de antemano que no podrá alcanzar.
Medible. Los indicadores definidos se deben poder medir, para lo
cual se debe disponer de los datos que lo componen. Además
estos datos deben ser percibidos por ambas partes, cliente y
proveedor, como objetivos.
Con significado. Los indicadores deben tener un significado claro
para ambas partes de modo que sean útiles. En general los
indicadores propios de las organizaciones de TI no tienen
significado o no se entienden por los clientes, ya que entregan
una visión fragmentada del problema.
Controlable. El factor debe ser controlable por el proveedor del
producto/servicio para que pueda definirse un nivel de servicio.
Hay factores que pueden ser muy útiles, pero que están fuera
del control del proveedor directo, como por ejemplo un enlace
satelital.
Mutuamente aceptado. Un indicador de nivel de servicio, para
que sea válido, debe ser aceptado como tal por el proveedor y
por el cliente y de ninguna manera impuesto por alguna de las
partes. Esto es especialmente importante si el indicador se va a
usar en un acuerdo de servicio.
27
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Costo-eficiente. El indicador, así como el nivel de calidad de
servicio a ofrecer, deben poder generarse a un costo razonable,
para que tenga sentido. El costo de obtener un indicador o un
reporte de servicio no debe superar el beneficio que significa
disponer de éste. En general se tiende a pensar que el costo de
obtener un reporte de servicio es despreciable, sin embargo hay
costos reales e incrementales de recolectar y analizar los datos
necesarios para generar dicho reporte.
Uno de los indicadores más importante para el cliente es el tiempo de
respuesta final (end to end) para transacciones en línea. Los
proveedores de servicio deben ser muy cautos al incorporar este
indicador en el acuerdo, ya que es muy difícil de medir en forma
precisa. Además, la medición tomada por el proveedor debe reflejar
más o menos lo que el usuario ve, de modo que éste no invalide el
indicador.
Un aspecto muy importante de tener presente al definir indicadores de
nivel de servicio es que se requiere de creatividad. Es efectivo que los
indicadores deben ser medibles, lo que quiere decir que debe existir
una fuente de datos para esa información. Sin embargo, no siempre
existe una única fuente de que provea los datos exactos que se
requieren. En algunos casos fuentes alternativas pueden entregar el
mismo resultado y en otros casos es necesario correlacionar datos de
distintas fuentes para tener la visión final. A veces, por ejemplo, es
28
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
necesario analizar los eventos registrados en el sistema de mesón de
ayuda para generar los valores de un indicador.
En un SLA se pueden establecer tantos indicadores como se estime
necesario y de su evaluación se obtienen por ejemplo penalizaciones a
la empresa suministradora, identificación de puntos débiles del proceso
e indicaciones para procesos de mejora continua en determinadas
actividades
1.4.2 Implementación de acuerdo de nivel de servicio.
Un acuerdo de nivel de servicio o SLA (Service Level Agreement), es
un contrato en el que se estipulan los niveles de un servicio en función
de una serie de parámetros objetivos, establecidos de mutuo acuerdo
entre el cliente y el prestador del servicio. No está implicado
necesariamente con la contratación de servicios a terceras partes, sino
que puede implantarse a nivel interno, transformando una determinada
unidad de negocio en centro de servicios que provea a la propia
compañía.
Un SLA tratará de mantener y de garantizar la calidad de un servicio
brindado a un cliente, mantener la disponibilidad de un determinado
servicio basado en un compromiso que puede ser medido y
demostrado.
29
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Los SLAs deben contener una descripción del servicio que abarque
desde los aspectos más generales hasta los detalles más específicos
del servicio.
Es conveniente estructurar los SLAs más complejos en diversos
documentos de forma que cada grupo involucrado reciba
exclusivamente la información correspondiente al nivel en que se
integra, ya sea en el lado del cliente como del proveedor.
La elaboración de un SLA requiere tomar en cuenta aspectos no
tecnológicos entre los que se encuentran:
La naturaleza del negocio del cliente.
Aspectos organizativos del proveedor y cliente.
Aspectos culturales locales.
1.4.3 Monitorización de los niveles de servicio.
El proceso de monitorización de los niveles de servicio es
imprescindible si queremos mejorar progresivamente la calidad del
servicio ofrecido, su rentabilidad y la satisfacción de los clientes y
usuarios.
La monitorización de la calidad del servicio requiere el seguimiento
tanto de procedimientos y parámetros internos de la organización como
los relacionados con la percepción de los usuarios.
30
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Para llevar a cabo esta tarea de manera eficiente es necesario haber
establecido con anterioridad unos indicadores de calidad del servicio
que han de servir de guía en la elaboración de los informes
correspondientes.
Los informes de rendimiento elaborados deben cubrir factores clave
tales como:
Cumplimiento de los SLAs, con información sobre la frecuencia y
el impacto de los incidentes responsables de la degradación del
servicio.
Quejas, justificadas o no, de los clientes y usuarios.
Utilización de la capacidad predefinida.
Disponibilidad del servicio.
Tiempos de respuesta.
Costos reales del servicio ofrecido.
Problemas detectados y cambios realizados para restaurar la
calidad del servicio.
1.4.4 Revisión de los acuerdos de nivel de servicio.
La correcta Gestión de Niveles de Servicio es un proceso continuo que
requiere la continua revisión de la calidad de los servicios ofrecidos.
Esta revisión debe realizarse en base a parámetros objetivos y
medibles resultado de la experiencia previa, los SLAs en vigencia
31
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Este proceso de revisión no debe limitarse a aquellos SLAs que por una
razón u otra han sido incumplidos, aunque, evidentemente, en estos
casos sea inexcusable, sino que debe tener como objetivo mejorar y
homogeneizar la calidad del servicio.
El resultado de la revisión debe ser un programa de mejora del servicio
(SIP) que tome en cuenta factores tales como:
Problemas relacionados con el servicio TI y sus posibles causas.
Nuevas necesidades del cliente.
Avances tecnológicos.
Cumplimiento de los niveles de servicio.
Evaluación de los costos reales del servicio.
Implicaciones de una degradación de la calidad del servicio en la
estructura organizativa del cliente.
Reasignación de recursos.
Percepción del cliente y usuarios sobre la calidad de servicio.
Necesidades de formación adicional a los usuarios de los
servicios.
32
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
CAPITULO II CONCEPTOS BASICOS DE PROTOCOLOS TCP/IP.
2.1 Protocolo de control de transmisión (TCP).
El TCP es el responsable de la transmisión fiable de datos desde un nodo a
otro. Es un protocolo orientado a la conexión y establece una conexión
(también conocida como una sesión, circuito virtual o enlace) entre dos
máquinas antes de transferir ningún dato. Para establecer una conexión fiable,
TCP utiliza lo que se conoce como “acuerdo en tres pasos”. Establece el
número de puerto y los números de secuencia de inicio desde ambos lados de
la transmisión. El acuerdo consta de tres pasos:
1. El solicitante envía al servidor un paquete especificando el número de
puerto que él planea utilizar y el número de secuencia inicial (ISN).
2. El servidor responde con su ISN, que consiste en el ISN del solicitante
más uno.
3. El solicitante responde a la respuesta del servidor con el ISN del
servidor más uno.
En orden a mantener una conexión fiable, cada paquete tiene que contener:
33
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Un número de puerto TCP origen y destino.
Un número de secuencia para mensajes que tienen que dividirse en
partes más pequeñas.
Un checksum que asegura que la información se ha recibido sin error.
Un número de confirmación que indica a la máquina origen qué partes
de la información han llegado.
Ventanas deslizantes (sliding windows) TCP.
2.2 Protocolo Internet (IP).
El protocolo internet (IP) es un protocolo de conmutación de paquetes que
realiza direccionamiento y encaminamiento. Cuando se transmite un paquete,
este protocolo añade una cabecera al paquete, de forma que pueda enviarse
a través de la red utilizando las tablas de encaminamiento dinámico. IP es un
protocolo no orientado a la conexión y envía paquetes sin esperar la señal de
confirmación por parte del receptor. Además, IP es el responsable del
empaquetado y división de los paquetes requerido por el nivel físico y de
enlace de datos del modelo OSI. Cada paquete IP está compuesto por una
dirección de origen y una de destino, un identificador de protocolo, un
checksum (un valor calculado) y un TTL (tiempo de vida, del inglés time to
live). El TTL indica a cada uno de los routers de la red entre el origen y el
destino cuánto tiempo le queda al paquete por estar en la red. Funciona como
un contador o reloj de cuenta atrás. Cuando el paquete pasa por el router,
éste reduce el valor en una unidad (un segundo) o el tiempo que llevaba
esperando para ser entregado. Por ejemplo, si un paquete tiene un TTL de
34
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
128, puede estar en la red durante 128 segundos o 128 saltos (cada parada, o
router, en la red), o una combinación de los dos. El propósito del TTL es
prevenir que los paquetes perdidos o dañados (como correos electrónicos con
una dirección equivocada) estén vagando en la red. Cuando la cuenta TTL
llega a cero, se retira al paquete de la red.
2.3 Protocolo de datagramas de usuario (UDP).
UDP es un protocolo no orientado a la conexión y es el responsable de la
comunicación de datos extremo a extremo. En cambio, a diferencia de TCP,
UDP no establece una conexión. Intenta enviar los datos e intenta comprobar
que el host de destino recibe los datos. UDP se utiliza para enviar pequeñas
cantidades de datos que no necesitan una entrega garantizada. Aunque UDP
utiliza puertos, son distintos de los puertos TCP; así pues, pueden utilizar los
mismos números sin interferirse.
El UDP ofrece a las aplicaciones un mecanismo para enviar datagramas IP en
bruto encapsulados sin tener que establecer una conexión. Muchas
aplicaciones cliente-servidor que tienen una solicitud y una respuesta usan el
UDP en lugar de tomarse la molestia de establecer y luego liberar una
conexión. El UDP se describe en el RFC 768. Un segmento UDP consiste en
una cabecera de 8 bytes seguida de los datos. La cabecera se muestra a
continuación. Los dos puertos sirven para lo mismo que en el TCP: para
identificar los puntos terminales de las máquinas origen y destino. El campo
de longitud UDP incluye la cabecera de 8 bytes y los datos. La suma de
35
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
comprobación UDP incluye la misma pseudocabecera de formato, la cabecera
UDP, y los datos, rellenados con una cantidad par de bytes, de ser necesario.
UDP no admite numeración de los datagramas, factor que, sumado a que
tampoco utiliza señales de confirmación de entrega, hace que la garantía de
que un paquete llegue a su destino sea mucho menor que si se usa TCP. Esto
también origina que los datagramas pueden llegar duplicados y/o
desordenados a su destino. Por estos motivos el control de envío de
datagramas, si existe, debe ser implementado por las aplicaciones que usan
UDP como medio de transporte de datos, al igual que el re-ensamble de los
mensajes entrantes. Es por ello un protocolo del tipo best-effort (máximo
esfuerzo), porque hace lo que puede para transmitir los datagramas hacia la
aplicación, pero no puede garantizar que la aplicación los reciba.
2.3.1 Características del protocolo UDP.
El protocolo UDP (Protocolo de datagrama de usuario) es un protocolo
no orientado a conexión de la capa de transporte del modelo TCP/IP.
Este protocolo es muy simple ya que no proporciona detección de
errores (no es un protocolo orientado a conexión).
Por lo tanto, el encabezado del segmento UDP es muy simple y se
muestra en la figura 2.1:
36
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
puerto de origen(16 bits);
puerto de destino(16 bits);
longitud total(16 bits);
suma de comprobación del encabezado
(16 bits);datos
(longitud variable).
Figura 2.1. Encabezado protocolo UDP
Puerto de origen: es el número de puerto relacionado con la aplicación
del remitente del segmento UDP. Este campo representa una dirección
de respuesta para el destinatario. Por lo tanto, este campo es opcional.
Esto significa que si el puerto de origen no está especificado, los 16 bits
de este campo se pondrán en cero. En este caso, el destinatario no
podrá responder (lo cual no es estrictamente necesario, en particular
para mensajes unidireccionales).
Puerto de destino: este campo contiene el puerto correspondiente a la
aplicación del equipo receptor al que se envía.
Longitud: este campo especifica la longitud total del segmento, con el
encabezado incluido. Sin embargo, el encabezado tiene una longitud de
4 x 16 bits (que es 8 x 8 bits), por lo tanto la longitud del campo es
necesariamente superior o igual a 8 bytes.
Suma de comprobación: es una suma de comprobación realizada de
manera tal que permita controlar la integridad del segmento.
2.4 Protocolo de mensajes de control de Internet (ICMP).
37
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
El Protocolo de Mensajes de Control y Error de Internet, ICMP, es de
características similares a UDP, pero con un formato mucho más simple, y su
utilidad no está en el transporte de datos de usuario, sino en controlar si un
paquete no puede alcanzar su destino, si su vida ha expirado, si el
encabezamiento lleva un valor no permitido, si es un paquete de eco o
respuesta, etc. Es decir, se usa para manejar mensajes de error y de control
necesarios para los sistemas de la red, informando con ellos a la fuente
original para que evite o corrija el problema detectado. ICMP proporciona así
una comunicación entre el software IP de una máquina y el mismo software en
otra.
El protocolo ICMP solamente informa de incidencias en la entrega de
paquetes o de errores en la red en general, pero no toma decisión alguna al
respecto. Esto es tarea de las capas superiores.
Los mensajes ICMP se transmiten como datagramas IP normales, con el
campo de cabecera "protocolo" con un valor 1, y comienzan con un campo de
8 bits que define el tipo de mensaje de que se trata. A continuación viene un
campo código, de o bits, que a veces ofrece una descripción del error concreto
que se ha producido y después un campo suma de control, de 16 bits, que
incluye una suma de verificación de errores de transmisión. Tras estos
campos viene el cuerpo del mensaje, determinado por el contenido del campo
"tipo". Contienen además los 8 primeros bytes del datagrama que ocasionó el
error. Como se puede observar en la figura
38
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Figura 2.2 Cabecera ICMP
Los principales tipos de mensaje ICMP son los siguientes:
2.4.1 Mensajes informativos.
Entre estos mensajes hay algunos de suma importancia, como los
mensajes de petición de ECO (tipo 8) y los de respuesta de Eco (tipo
0). Las peticiones y respuestas de eco se usan en redes para
comprobar si existe una comunicación entre dos host a nivel de capa
de red, por lo que nos pueden servir para identificar fallos en este nivel,
ya que verifican si las capas física (cableado), de enlace de datos
(tarjeta de red) y red (configuración IP) se encuentran en buen estado y
configuración.
Tabla 2.1. Tipos de Mensajes Informativos.
0 Echo Reply (respuesta de eco)
39
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
3Destination Unreacheable (destino inaccesible)
4Source Quench (disminución del tráfico desde el origen)
5Redirect (redireccionar - cambio de ruta)
8 Echo (solicitud de eco)
11Time Exceeded (tiempo excedido para un datagrama)
12Parameter Problem (problema de parámetros
13Timestamp (solicitud de marca de tiempo)
14Timestamp Reply (respuesta de marca de tiempo)
15Information Request (solicitud de información) - obsoleto-
16Information Reply (respuesta de información) - obsoleto-
17Addressmask (solicitud de máscara de dirección)
18Addressmask Reply (respuesta de máscara de dirección
2.4.2 Mensajes de error.
En el caso de obtener un mensaje ICMP de destino inalcanzable, con
campo "tipo" de valor 3, el error concreto que se ha producido vendrá
dado por el valor del campo "código", pudiendo presentar los siguientes
valores que se muestran en la parte derecha.
40
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Este tipo de mensajes se generan cuando el tiempo de vida del
datagrama a llegado a cero mientras se encontraba en tránsito hacia el
host destino (código=0), o porque, habiendo llegado al destino, el
tiempo de reensamblado de los diferentes fragmentos expira antes de
que lleguen todos los necesarios (código=1).
Los mensajes ICMP de tipo= 12 (problemas de parámetros) se originan
por ejemplo cuando existe información inconsistente en alguno de los
campos del datagrama, que hace que sea imposible procesar el mismo
correctamente, cuando se envían datagramas de tamaño incorrecto o
cuando falta algún campo obligatorio.
Por su parte, los mensajes de tipo=5 (mensajes de redirección) se
suelen enviar cuando, existiendo dos o más routers diferentes en la
misma red, el paquete se envía al router equivocado. En este caso, el
router receptor devuelve el datagrama al host origen junto con un
mensaje ICMP de redirección, lo que hará que éste actualice su tabla
de enrutamiento y envíe el paquete al siguiente router.
Tabla 2.2 Tipos de mensajes de error de ICMP
0 no se puede llegar a la red
1 no se puede llegar al host o aplicación de destino
41
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
2 el destino no dispone del protocolo solicitado
3no se puede llegar al puerto destino o la aplicación destino no está libre
4se necesita aplicar fragmentación, pero el flag correspondiente indica lo contrario
5 la ruta de origen no es correcta
6 no se conoce la red destino
7 no se conoce el host destino
8 el host origen está aislado
9la comunicación con la red destino está prohibida por razones administrativas
10
la comunicación con el host destino está prohibida por razones administrativas
11
no se puede llegar a la red destino debido al Tipo de servicio
12
no se puede llegar al host destino debido al Tipo de servicio
2.5 HTTP.
Cada transacción de información realizada en la Web es realizada utilizando el
protocolo HTTP, (HyperText Transfer Protocol) por sus siglas en inglés, o
Protocolo de Transferencia de HyperTexto.
De este modo, las peticiones de acceso a una página y la respuesta brindada
por la misma en forma de contenido de hipertexto utilizan este sistema de
comunicación, el cual permanece un tanto "oculto" al usuario final. El protocolo
42
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
HTTP es utilizado también para enviar formularios con campos de texto, u otro
tipo de información en ambos sentidos.
La conexiones realizadas mediante este protocolo no son guardadas por el
mismo en ningún sitio, es decir que se trata de un protocolo "sin estado": los
datos se pierden, por lo tanto, cuando la transacción de los mismos ha
terminado, cosa que da lugar a las cookies, archivos livianos que se guardan
en determinado sitio del disco duro con el objetivo de almacenar información
del usuario. De tal forma, el sitio Web sabrá de quién se trata al volver a
acceder al mismo, mostrando por ejemplo su nombre y o permitiendo su
acceso sin necesidad de ingresar contraseña, etc.
Las cookies también son utilizadas por ciertos sitios Web para llevar una
estadística de sus visitantes.
Es útil saber que los sitios web cuya dirección de Internet comienza con https
serán seguros; por lo general los navegadores web informan de esto
mostrando un fondo amarillo detrás del texto de la url, y algún candado.
El http facilita la definición de la sintaxis y semántica que utilizan los distintos
softwares web – tanto clientes, como servidores y proxys – para interactuar
entre sí.
Este protocolo opera por petición y respuesta entre el cliente y el servidor. A
menudo las peticiones tienen que ver con archivos, ejecución de un programa,
consulta a una base de datos, traducción y otras funcionalidades. Toda la
43
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
información que opera en la Web mediante este protocolo es identificada
mediante el url o dirección.
La típica transacción de protocolo http se compone de un encabezado seguido
por una línea en blanco y luego un dato. Este encabezado define la acción
requerida por el servidor.
Desde su creación, el http evolucionó en diversas versiones. Entre ellas, la
0.9, la 1.0, la 1.1 y la 1.2.
El protocolo de este tipo opera con códigos de respuesta de tres dígitos, que
comunican si conexión fue rechazada, si se realizó con éxito, si ha sido
redirigida hacia otro url, si existe un error por parte del cliente, o bien, por
parte del servidor.
Las aplicaciones y navegadores web tienden a complementar la acción del
http como ocurre, por ejemplo, con las denominadas “cookies”, que permiten
almacenar información de la sesión, función de la que no dispone este
protocolo, ya que opera sin estado.
44
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
CAPITULO III PROTOCOLOS Y HERRAMIENTAS TÍPICOS PARA MONITOREO.
3.1 SNMP.
SNMP (Simple Network Management Protocol), es un conjunto de
aplicaciones de gestión de red que emplea los servicios ofrecidos por TCP/IP,
es un protocolo del mundo UNIX que ha llegado a convertirse en un estándar.
Para el protocolo SNMP la red constituye un conjunto de elementos básicos
Administradores o Management Stations ubicados en el o los equipos de
gestión de red y los gestores Network Agents elementos pasivos ubicados en
los nodos (host, routers, modems, multiplexores, etc.) a ser gestionados,
siendo los segundos los que envían información a los primeros, relativa a los
elementos gestionados, ya sea por iniciativa propia o al ser interrogados
(polling) de manera secuencial, apoyándose en los parámetros contenidos en
sus MIB (Management Information Base). Su principal inconveniente es el
exceso de tráfico que se genera, lo que lo puede hacer incompatible para
entornos amplios de red.
Las versiones de SNMP más utilizadas son SNMP versión 1 (SNMPv1) y
SNMP versión 2 (SNMPv2). SNMP en su última versión (SNMPv3) posee
45
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
cambios significativos con relación a sus predecesores, sobre todo en
aspectos de seguridad, sin embargo no ha sido mayoritariamente aceptado en
la industria.
Los cinco tipos de mensajes SNMP intercambiados entre los Agentes y los
Administradores, son:
Get Request.- Una petición del Administrador al Agente para que envíe
los valores contenidos en el MIB (base de datos).
Get Next Request.-Una petición del Administrador al Agente para que
envíe los valores contenidos en el MIB referente al objeto siguiente al
especificado anteriormente.
Get Response.-La respuesta del Agente a la petición de información
lanzada por el Administrador.
Set Request.- Una petición del Administrador al Agente para que
cambie el valor contenido en el MIB referente a un determinado objeto.
Trap.- Un mensaje espontáneo enviado por el Agente al Administrador,
al detectar una condición predeterminada, como es la
conexión/desconexión de una estación o una alarma.
El protocolo de gestión SNMP facilita, pues, de una manera simple y flexible el
intercambio de información en forma estructurada y efectiva, proporcionando
significantes beneficios para la gestión de redes, aunque necesita de otras
aplicaciones en el NMS que complementen sus funciones y que los
46
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
dispositivos tengan un software Agente funcionando en todo momento y
dediquen recursos a su ejecución y recogida de datos.
A través del MIB se tiene acceso a la información para la gestión, contenida
en la memoria interna del dispositivo en cuestión. MIB es una base de datos
completa y bien definida, con una estructura en árbol, adecuada para manejar
diversos grupos de objetos (información sobre variables/valores que se
pueden adoptar), con identificadores exclusivos para cada objeto.
La arquitectura SNMP opera con un reducido grupo de objetos que se
encuentran definido con detalle en la RFC 1066 (base de información de
gestión para la gestión de redes sobre TCP/IP).
Los 8 grupos de objetos habitualmente manejados por MIB (MIB-I), que
definen un total de 114 objetos (recientemente, con la introducción de MIB-II
se definen hasta un total de 185 objetos) son:
Sistema: Incluye la identidad del vendedor y el tiempo desde la última
reinicialización del sistema de gestión.
Interfaces: Un único o múltiples interfaces, local o remoto, etc.
ATT (Address Translation Table): Contiene la dirección de la red y las
equivalencias con las direcciones físicas.
IP (Internet Protocol): Proporciona las tablas de rutas, y mantiene
estadísticas sobre los datagramas IP recibidos.
47
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
ICMP (Internet Communication Management Protocol): Cuenta el
número de mensajes ICMP recibidos y los errores.
TCP (Transmission Control Protocol): Facilita información acerca de las
conexiones TCP, retransmisiones, etc.
UDP (User Datagram Protocol): Cuenta el número de datagramas UDP,
enviados, recibidos y entregados.
EGP (Exterior Gateway Protocol): Recoge información sobre el número
de mensajes EGP recibidos, generados, etc.
Además de éstos, ciertos fabricantes están cooperando para el desarrollo de
extensiones particulares para ciertas clases de productos y la gestión remota
de dispositivos, conocidas como RMON (Remote MONitor), normas RFC 1757
(antes 1271) para Ethernet y RFC 1513 para Token Ring del IETF (Internet
Engineering Task Force), que incluyen sobre unos 200 objetos clasificados en
9 grupos: alarmas, estadísticas, historias, filtros, ordenadores, n principales,
matriz de tráfico, captura de paquetes y sucesos. Con RMONv2 se decodifican
paquetes a nivel 3 de OSI, lo que implica que el trafico puede monitorizarse a
nivel de direcciones de red (puertos de los dispositivos) y aplicaciones
específicas.
RMON define las funciones de supervisión de la red y los interfaces de
comunicaciones entre la plataforma de gestión SNMP, los monitores remotos
y los Agentes de supervisión que incorporan los dispositivos inteligentes.
48
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
3.2 SYSLOG.
Syslog fue desarrollado por Eric Allman como parte del proyecto Sendmail en
1980 sólo para éste proyecto. Sin embargo, se comprobó que era muy útil, y
otras aplicaciones empezaron también a usar syslog. Hoy en día syslog está
presente por defecto en casi todos los sistemas Unix y GNU/Linux, y también
se encuentran diversas implementaciones de syslog para otros sistemas
operativos, como Microsoft Windows.
El protocolo syslog es muy sencillo, existe un servidor ejecutando el servidor
de syslog, conocido como syslogd (demonio de syslog). El cliente envía un
pequeño mensaje de texto (de menos de 1024 bytes). Los mensajes de syslog
se suelen enviar vía UDP, por el puerto 514, en formato de texto plano.
Algunas implementaciones del servidor, como syslog-ng, permiten usar TCP
en vez de UDP, y también ofrecen Stunnel para que los datos viajen cifrados
mediante SSL/TLS.
Aunque syslog tiene algunos problemas de seguridad, su sencillez ha hecho
que muchos dispositivos lo implementen, tanto para enviar como para recibir.
Eso hace posible integrar mensajes de varios tipos de sistemas en un solo
repositorio central.
El mensaje enviado se compone de tres campos:
Prioridad
Cabecera
49
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Texto
Entre todos no han de sumar más de 1024 bytes, pero no hay longitud
mínima.
3.2.1 Prioridad.
La prioridad es un número de 8 bits que indica tanto el recurso (tipo de
aparato que ha generado el mensaje) como la severidad (importancia
del mensaje), números de 5 y 3 bits respectivamente. Los códigos de
recurso y severidad los decide libremente la aplicación, pero se suele
seguir una convención para que clientes y servidores se entiendan.
Códigos de recurso
Los códigos observados en varios sistemas, basados en el RFC 3164
se numeran en la tabla 3.1.
Tabla 3.1 Códigos de Recurso
0 Mensajes del kernel 12 Subsistema de NTP
1 Mensajes del nivel de usuario
13 Inspección del registro
2 Sistema de correo 14 Alerta sobre el registro
3 Demonios de sistema 15 Demonio de reloj
4 Seguridad/Autorización 16 Uso local 0
5 Mensajes generados internamente
17 Uso local 1
6 Subsistema de impresión 18 Uso local 2
7 Subsistema de noticias 19 Uso local 3
50
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
sobre la red
8 Subsistema UUCP 20 Uso local 4
9 Demonio de reloj 21 Uso local 5
10 Seguridad/Autorización 22 Uso local 6
11 Demonio de FTP 23 Uso local 7
Códigos de severidad
Los 3 bits menos significativos del campo prioridad dan 8 posibles
grados descritos de igual forma en el RFC 3164 y numerados en la
tabla 3.2.
Tabla 3.2 Códigos de Severidad
0 Emergencia: el sistema está inutilizable
1 Alerta: se debe actuar inmediatamente
2 Crítico: condiciones críticas
3 Error: condiciones de error
4 Peligro: condiciones de peligro
5 Aviso: normal, pero condiciones notables
6 Información: mensajes informativos
7 Depuración: mensajes de bajo nivel
Para conocer la prioridad final de un mensaje, se aplica la siguiente
fórmula:
Prioridad = Recurso * 8 + Severidad
Por ejemplo, un mensaje de kernel (Recurso=0) con Severidad=0
(emergencia), tendría Prioridad igual a 0*8+0 = 0. Uno de FTP (11) de
51
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
tipo información (6) tendría 11*8+6=94. Los valores más bajos indican
mayor prioridad.
3.2.2 Cabecera.
El segundo campo de un mensaje syslog, la cabecera, indica tanto el
tiempo como el nombre del ordenador que emite el mensaje. Esto se
escribe en codificación ASCII (7 bits), por tanto es texto legible.
El primer campo, tiempo, se escribe en formato Mmm dd hh:mm:ss,
donde Mmm son las iniciales del nombre del mes en inglés, dd, es el
día del mes, y el resto es la hora. No se indica el año.
Justo después viene el nombre de ordenador (hostname), o la dirección
IP si no se conoce el nombre. No puede contener espacios, ya que este
campo acaba cuando se encuentra el siguiente espacio.
3.2.3 Texto.
Lo que queda de paquete syslog al llenar la prioridad y la cabecera es
el propio texto del mensaje. Éste incluirá información sobre el proceso
que ha generado el aviso, normalmente al principio (en los primeros 32
caracteres) y acabado por un carácter no alfanumérico (como un
espacio, ":" o "["). Después, viene el contenido real del mensaje, sin
ningún carácter especial para marcar el final.
52
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
3.3 NTP.
El protocolo NTP (Network Time Protocol) es un protocolo de internet
ampliamente utilizado para transferir el tiempo a través de una red. NTP es
normalmente utilizado para sincronizar el tiempo en clientes de red a una hora
precisa.
El protocolo NTP, es uno de los más antiguos de Internet y sigue estando en
uso hoy en día. Ha estado en continuo uso desde hace más de 25 años. Fue
en un primer momento diseñado originalmente para sincronizar computadoras
y procesos críticos dependientes del tiempo sobre la red. Fue inicialmente
pensada para el sistema operativo Linux, pero luego fue migrado también a
Windows, aunque sigue siendo instalado por defecto en muchos sistemas
Unix y distribuciones BSD. Por este motivo, hay una gran cantidad de
servidores NTP que utilizan Linux debido a su kernel especializado y sus
algoritmos de tiempo.
NTP es un protocolo basado en un sistema cliente-servidor. Provee a los
clientes con tres productos fundamentales: clock offset, round-trip delay y
referencia de dispersión. El offset especifica la diferencia entre la hora del
sistema local y la referencia externa de reloj. Round-trip delay especifica las
latencias de tiempo medidas durante la transferencias de paquetes dentro de
la red. La referencia de dispersión de tiempo especifica el máximo número de
errores asociados con la información de tiempo recibido de un reloj externo.
53
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
El protocolo tiene una estructura jerárquica. Un servidor Stratum 1, es el
servidor primario de referencia y se asienta en el más alto nivel de la jerarquía.
Este servidor primario está seguido de servidores secundarios de referencia y
clientes. Un servidor NTP primario generalmente se sincroniza mediante una
referencia externa de reloj, como puede ser un reloj de radio o GPS figura
3.1.
Figura 3.1 Arquitectura NTP.
El protocolo NTP usa el protocolo UDP el cual es una parte integrada de la
pila TCP/IP. Actualmente, la versión actual que se está utilizando es NTP 4, y
54
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
todas las versiones son compatibles entre si, La única modificación entre la
versión 3 y 4 es una variación en la cabecera para acomodar IPv6.
3.3.1 Modos de operación.
Un servidor NTP stratum 1 tiene tres modos de operación unicast,
anycast y multicast. El cliente inicia los modos unicast y anycast y el
servidor responde con un mensaje de tiempo NTP con el que el cliente
se sincroniza. Multicast es un modo de envío de mensajes a solo
ciertos elementos de la red, a diferencia de broadcast, el cual habla con
todos. A periodos regulares, el dominio es inundado por estos
mensajes con motivos de sincronización.
3.3.2 SNTP.
El protocolo SNTP (Simple Network Time Protocol), es una versión
simplificada de NTP. Normalmente es utilizada donde la precisión y
complejidad de NTP no es necesaria. Ambos protocolos son
compatibles e intercambiables, es decir, cualquier cliente SNTP puede
sincronizar con un servidor NTP.
3.4 IP SLA (Cisco).
Los servicios de red han cambiado drásticamente en los últimos años, debido
a la adición de voz, vídeo y otras aplicaciones sensibles de misión crítica,
demora y rendimiento sensible. La red ha sido adoptada como una
55
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
herramienta de productividad. Los clientes demandan garantizar, servicios de
red fiable para aplicaciones críticas de negocio Cisco IOS IP Service Level
Agreements (SLAs) es una capacidad integrada en casi todos los dispositivos
que ejecutan el software Cisco IOS, que permite a los clientes de Cisco IP
para comprender los niveles de servicio para los servicios IP, aumentar la
productividad, reducir los costes operativos, y reducir la frecuencia de las
interrupciones de red.
Cisco IOS IP SLA usa monitoreo de tráfico activo, la generación de tráfico de
manera continua, confiable y predecible, para medir el desempeño. Se puede
simular la red de datos y servicios IP y la información recopilar rendimiento de
la red en tiempo real. Esto incluye datos sobre el tiempo de respuesta, latencia
en un solo sentido, jitter, pérdida de paquetes, calidad de voz de puntuación, y
el tiempo de respuesta del servidor. Cisco IOS IP SLA también puede
monitorear el desempeño de las diferentes clases de tráfico a través de la
misma conexión.
Los niveles de servicio son fundamentales porque afectan a la prestación de
servicios IP y aplicaciones críticas del negocio. SLA entre los proveedores de
servicios y clientes o entre los departamentos de TI corporativos de empresa y
los usuarios finales tienen por objeto proporcionar garantías de servicio y
validar el rendimiento de la red de manera continua. SLA debe ser simple de
comprender y mejorar el tiempo medio de respuesta.
56
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Cisco IP SLA está incrustado dentro del software Cisco IOS y no hay ningún
dispositivo adicional para implementar, aprender o manejar. Una herramienta
confiable para verificar los niveles de servicio IP, Cisco IP SLA proporcionar
una solución escalable y rentable para la medición de rendimiento de la red.
Cisco IP SLA recopila información de rendimiento de la red en tiempo real:
tiempo de respuesta, la latencia en un solo sentido, el jitter, pérdida de
paquetes, la medición de la calidad de voz, y otras estadísticas de la red. El
usuario podrá continuamente contar con un sistema confiable, predecible y
podrá medir el rendimiento de la red de forma proactiva y vigilar la salud de la
red. Con Cisco IP SLA, se cuenta con un control de nivel de servicio es
automático, los niveles de servicio IP pueden estar seguros, el funcionamiento
de la red puede ser verificada de manera proactiva, y el rendimiento de la red
se puede medir con precisión. La supervisión activa continuamente mide el
rendimiento de la red entre varias rutas en la red, proporcionando información
continua en base del rendimiento.
Los administradores de red también pueden utilizar Cisco IP SLA como una
herramienta de solución de problemas. Pueden obtener hop-by-hop
estadísticas de rendimiento entre dos routers de Cisco, o entre un enrutador y
un servidor. Si el nivel de rendimiento de la red cae durante la operación (por
ejemplo: debido a la congestión), el administrador de red puede identificar
rápidamente la ubicación de los cuellos de botella y resolver el problema.
Cisco IP SLA También puede realizar una evaluación de la red para un nuevo
servicio IP y verificar los niveles de calidad de servicio (QoS). Por ejemplo,
57
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Cisco IOS IP SLA puede determinar si la red está lista para la voz sobre IP
(VoIP) mediante la simulación de los codecs de VoIP y medir el rendimiento
de la red y la calidad de VoIP a través de la red IP.
3.4.1 Beneficios de Cisco IP SLA.
Los beneficios que plantea Cisco por el uso de la medición de lP SLA
se listan a continuación:
Integrado en el software Cisco IOS
Automatizada y en tiempo real, vigilancia del rendimiento preciso
de la red y la salud de la red.
Es capaz de comprobar y medir los niveles de servicio IP y los
parámetros necesarios para los acuerdos de nivel de servicio.
Monitoreo de tráfico por la clase de QoS.
Flexibilidad de programación.
Notificaciones proactivas con Simple Network Management
Protocol (SNMP) trap.
Hop-by-hop y la medición de extremo a extremo.
Control a través de SNMP o software Cisco IOS interfaz de línea
de comandos (CLI)
VoIP simulación códec VoIP y la medición de la calidad;
Puntuación de opinión media (MOS) y planificación y cálculo del
factor deterioro (ICPIF).
58
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Multiprotocol Label Switching (MPLS) para la monitorización de
red.
Integrado en varios productos de los socios de terceros y la
gestión del rendimiento.
3.4.2 Funcionamiento.
Cisco IOS IP SLA mide el rendimiento mediante el envío de uno o más
paquetes a un dispositivo IP de destino o un router de Cisco. Cisco IOS
IP SLA utilizar la información de fecha y hora para el cálculo de
métricas de rendimiento, tales como jitter, la latencia de red y los
tiempos de respuesta del servidor, la pérdida de paquetes, y las
puntuaciones MOS de calidad de voz.
Un router de destino que ejecuta el software Cisco IOS se puede
configurar como una respuesta de Cisco IP SLA, que procesa los
paquetes de medición y proporciona información detallada de marca de
tiempo. La respuesta puede enviar información acerca de retrasar el
proceso del router destino de nuevo a la fuente del router Cisco. Este
retraso se elimina durante el cálculo para mejorar aún más la precisión.
Las mediciones de una sola dirección también son posibles con Cisco
IP SLA. Los usuarios pueden programar una operación de Cisco IOS IP
SLA en cualquier momento o de forma continua en cualquier intervalo
de tiempo.
59
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Cisco IOS IP SLA se pueden configurar para controlar el tráfico por
clase sobre el mismo enlace mediante el establecimiento de la Diff-Serv
Code Point (DSCP).
También se puede utilizar para solucionar problemas de las
operaciones de red MPLS, la medición de los resultados son esenciales
para el servicio de monitoreo de MPLS VPN.
Cisco IOS IP SLA proporcionar una función de notificación proactiva
con una captura de SNMP. Cada operación de medición puede
controlar con un umbral de rendimiento preestablecido. Cisco IP SLA
generar una trap SNMP para alertar a las aplicaciones de gestión
cuando este umbral se cruza. Una alerta se produce si se supera un
determinado valor entre dos puntos de la red, y una trap envía a un
sistema de administración de redes (NMS) para alertar al administrador
de la red. Los administradores también pueden configurar Cisco IP SLA
para ejecutar una nueva operación automáticamente cuando se cruza
el umbral. Esta característica, combinada con la capacidad de medición
hop-by-hop, permite el análisis inmediato problemas en tiempo real. Los
resultados de las mediciones de rendimiento de la red están disponibles
tanto con SNMP y el software Cisco IOS CLI.
60
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Cisco IOS IP SLA realiza vigilancia activa mediante la generación y
análisis de tráfico para medir el rendimiento entre dispositivos de Cisco
IOS por software o de servicios de aplicación de red. Cisco IOS IP SLA
permite la funcionalidad más allá de los SLAs tradicionales y se
comparan en la tabla 3.3:
Tabla 3.3. SLA tradicional versus IOS de Cisco IP SLA
Requisito SLA tradicional Cisco IOS IP SLA
Seguimiento de extremo a extremo
Limitada Sí
Sin costo de hardware No Sí
Penetrante Frame Relay o ATM (Sólo)
Sí
Facilidad de implementación
Pobres Sí
Compatibilidad con QoS No Sí
Las mediciones de latencia No Sí
Las mediciones de voz No Sí
IP Application Aware No Sí
Soporte capa 2 Frame Relay o ATM (Sólo)
Sí
El ciclo de implementación de los SLA reduce el tiempo de despliegue
de nuevas aplicaciones. Permite a los usuarios comprender su servicio
desplegado rendimiento de la red IP, y hacer realidad los beneficios de
la gestión y probar el servicio y la diferenciación de la aplicación.
61
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Cisco IOS IP SLA recoge estadísticas sobre la demora, pérdida de
paquetes, jitter, la secuencia de paquetes, conectividad, ruta y tiempo
de descarga. Los paquetes con IP configurable y opciones de la capa
de aplicación, incluyendo la dirección IP de origen y destino, UDP /
números de puerto TCP, byte ToS (incluye servicios diferenciados
punto de código (DSCP) y el período bits Prefijo), VRF, y la URL. Como
es de nivel 2 de transporte independiente, Cisco IOS IP SLA se pueden
configurar de extremo a extremo a través de redes diferentes a fin de
reflejar mejor las métricas que un usuario final es probable que la
experiencia.
Cisco IOS IP SLA tiene un subconjunto único de las métricas de
rendimiento siguientes:
Retraso (tanto de ida y vuelta y en un solo sentido)
Variación (direccional)
Pérdida de paquetes (direccional)
Paquete de Secuenciación (paquete de pedido)
Ruta (por salto)
Conectividad (direccional)
El servidor Web o el tiempo de descarga
Las puntuaciones de calidad de voz
Estas capacidades permiten la ejecución de las funciones de red:
62
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Cisco IOS IP SLA seguimiento
- Seguimiento del SLA, medición y verificación
Red de monitoreo del desempeño
- Medida de jitter, latencia o pérdida de paquetes en la red
IP de la red de servicios de evaluación de salud
- Verificar la calidad de servicio de red es suficiente para
los nuevos servicios IP
- Continua, confiable, predecible y mediciones después de
la implementación de servicios
Red de extremo a extremo la disponibilidad de supervisión
- Pruebas de verificación proactiva y la conectividad de los
recursos de red (por ejemplo: ¿cuál es la disponibilidad de
la red de un servidor NFS utiliza para almacenar datos
críticos del negocio desde un sitio remoto?)
Solución de problemas de funcionamiento de la red
- De conformidad y la medición confiable de inmediato
localiza problemas y reduce el tiempo de solución de
problemas
Cada una de estas áreas funcionales proporciona soporte para el
despliegue con éxito de las aplicaciones críticas de negocio. Cisco IP
SLA admite estas funciones a través de una serie de operaciones.
Cada operación tiene ciertas capacidades, la métrica, el protocolo y las
63
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
opciones configurables. La selección del correcto funcionamiento
depende en gran medida de la aplicación requerida y la función.
64
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
CAPITULO IV CASO PRÁCTICO.
4.1 Monitoreo de los SLA con CISCO IP SLA.
En los SLA normalmente hay un nivel de servicio esperado y un nivel mínimo
de servicio. El nivel de servicio esperado es lo que se contrae y es necesario
dar un buen rendimiento, y el nivel mínimo de servicio sin duda dará malos
resultados. Así por ejemplo, si cae el servicio por debajo del 90% del servicio
esperado de un x número de veces durante un período específico de tiempo o
si cae por debajo del nivel mínimo de servicio de 80%, como se muestra en la
figura 4.1.
1 2 3 4 5 6 7 8 9 100
102030405060708090
100
Nivel de Servico 1Nivel de Servicio 2
Violacion de SLA
Figura 4.1 Ejemplo de monitoreo de SLA.
65
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Cisco IP SLA se pueden utilizar para el análisis de la red, dar solución a
problemas en la red, la verificación de los QoS, y el control de nivel de
servicio. Varios de los temas deben ser resueltos antes de decidir cuándo
monitorear los niveles de rendimiento de redes y servicios.
¿Cuál es el objetivo principal de las mediciones? ¿Qué indicadores son
importantes para controlar? En otras palabras, ¿en qué días y horarios son las
medidas necesarias?
El segundo paso es hacer una amplia evaluación de los patrones de tráfico en
la red. Cuando las muestras de paquetes se distribuyen y se mide con mayor
frecuencia, los patrones de tráfico de la red son más confiables. Más puntos
significan que la información es más precisa. Las mediciones activas debe
imitar el tipo de tr áfico en la red de, por ejemplo, el tamaño de paquete
correcto, el espaciamiento de un intervalo para imitar un códec VoIP.
4.2 Escenario Planteado.
En la figura 4.2 se presenta el escenario planteado donde se tiene un sitio web
con el cual se tiene contacto a través de una VPN. En base a estos datos,
debe considerar cómo se puede medir y verificar los niveles de servicio. Por
otra parte, si no se cumplen con estos niveles de servicio, se debe notificar al
NMS desde el cual se hace el monitoreo.
66
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Figura 4.2 Escenario planteado
4.2.1 Selección de la operación correcta.
El primer paso en la implementación de los SLA consiste en responder
a la pregunta de qué necesita ser analizada. Una variedad de tipos de
operación son compatibles con Cisco IP SLA. Ya que solo es necesario
obtener el tiempo de respuesta del servidor web las operaciones más
indicadas son:
Operación UDP echo: La operación UDP echo mide el tiempo de
respuesta de extremo a extremo o la conectividad entre un router Cisco
y dispositivos IP o UDP en la capa de red (nivel 3) protocolo de Internet
que informa de los errores y proporciona información pertinente para el
procesamiento de paquetes IP. El tiempo de respuesta se calcula
midiendo el tiempo transcurrido entre el envío del mensaje de solicitud
de eco UDP en el destino y la recepción de una respuesta de eco
UDP.
67
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Operación TCP: Mide el tiempo respuesta de la conexión TCP se
calcula tomando la diferencia entre los tiempos empleados para solicitar
el TCP, SYN y ACK. Este resultado será útil para probar la conexión a
puertos específicos en los servidores
Operación HTTP: La operación HTTP mide el tiempo de ida y vuelta
(RTT), adoptada para conectarse y acceder a los datos de un servidor
HTTP, que se puede especificar con una dirección URL. Las
mediciones del tiempo de respuesta del servidor HTTP consta de tres
tipos:
Búsqueda en DNS -RTT necesario para realizar operaciones de
búsqueda del nombre de dominio.
Conexión TCP -RTT necesario para realizar una conexión TCP
con el servidor http.
Tiempo de transacción HTTP -RTT adoptadas para enviar una
solicitud y obtener una respuesta desde el servidor HTTP para la
página web completa o el primer byte de la página web.
La figura 4.3 muestra los componentes de la medición del tiempo
respuesta en la operación HTTP.
68
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Figura 4.3 Tiempos de respuesta en operación http
Dado que la conexión al servidor es desde una red interna que no
pasara por internet las operaciones UDP Echo y TCP, tendrán un
tiempo de respuesta demasiado bajo, por lo que, la operación HTTP
será la más indicada para el cálculo de los umbrales de servicio y el
establecimiento del acuerdo de nivel de servicio.
4.2.2Selección del intervalo de muestreo adecuado
La frecuencia con la que Cisco IP SLA envía la supervisión activa y
paquetes muestra, configurado en función de las necesidades y
requerimientos de ancho de banda de red. El muestreo se puede
producir de forma frecuente a fin de obtener la valoración más precisa
de los niveles de servicio de red, por desgracia, esto no siempre es
factible. Por ejemplo, cuando la vigilancia a través de una conexión
69
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
WAN es más caro, el usuario no puede ser que desee crear una gran
cantidad de tráfico a través del enlace.
También es importante tener en cuenta el tráfico de vigilancia activa se
genera por el IP SLA en un dispositivo Cisco por software. El poder de
procesamiento podría ser una preocupación cuando un router Cisco de
gama baja se utiliza, o hay una gran cantidad de tráfico que pasa por el
router.
En este caso el intervalo de muestreo seleccionado es de 300
segundos para no generar tráfico tanto tráfico en el servidor
4.2.3 Selección de los umbrales de servicio
Los proveedores de servicios a veces predefinir los umbrales de
rendimiento. Los ISP pueden proporcionar los SLA que especifican la
cantidad de latencia o un porcentaje de disponibilidad. Si los términos
de un SLA particular, son más ambiguos, corresponde al administrador
de red para decidir qué tipo de umbrales para seleccionar
Para hacer la correcta de selección de los umbral de servicio es
necesario hacer primero un monitoreo del tiempo de respuesta que
realmente nos está brindando el servidor HTTP.
Realizamos la primera implementa de CISCO IP SLA con la siguiente
configuración.
70
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Figura 4.4 Configuración para obtener los umbrales de servicio.
La principal característica de esta configuración es que se presenta con
el intervalo de muestreo mínimo aceptado por la operación HTTP (60
segundos), esto se debe a que se pretende generar algo de tráfico en
el servidor.
71
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Con los datos obtenidos se genera una tabla y se obtiene la media para
tener una referencia a partir del cual se seleccionara el nivel de servicio
óptimo y el nivel se servicio mínimo.
En la tabla 4.1 se pueden ver algunos de los tiempos de respuesta
obtenidos para realizar el cálculo del umbral para el nivel de servicio
aceptable.
Tabla 4.1. Tiempos de respuesta obtenidos para calculo de umbral
Muestra 1 2 3 4 5 6 7 8 9 … n
RTT DNS 0 0 0 0 0 0 0 0 0 … 0
RTT TCP 3 3 3 3 3 3 3 3 3 … 3
RTT HTTP503
546 420 490 446543
595 501 524 … 584
TOTAL506
549 423 493 449546
598 504 527 … 587
La media que se obtuvo del tiempo de respuesta fue de 514ms, por lo
que para el umbral de servicio optimo se tomaron 600 ms, mientras que
para el umbral de servicio mínimo se tomaron 1000 ms, ya que este
último es casi el doble del tiempo de respuesta promedio.
4.2.4 Monitoreo con IP SLA monitor.
Finalmente para el monitoreo se empleo la herramienta de Solar Winds
IP SLA Monitor, la cual es muy fácil de usar y provee una intefaz
sencilla de configurar para medir los IP SLA’s de Cisco.
72
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
En la figura 4.5 podemos ver el modo de configurar el IP SLA, se indica
la dirección del la interfaz del router que realizara la operación y a la
cual el SNMP se encuentra conectado; se selecciona el tiempo de
operación y el intervalo de muestreo; se indica la dirección web a la
cual se medirá el tiempo de respuesta, en este caso se empleo la
dirección de red del servidor ya que no se cuenta con un servidor DNS.
Figura 4.5 Configuración de IP SLA Monitor
Después de configurar la operación de IP SLA se introducen los
umbrales de nivel de servicio óptimo y mínimo como se muestra en la
figura 4.6
73
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Figura 4.6 Configuración de Umbrales de Nivel de Servicio
En la figura 4.7 se presentan algunas capturas de los estados del nivel
servicio que recibimos por el IP SLA monitor, teniendo en cuenta que
cuando se sobre pasa el umbral de tiempo de respuesta optimo la
alerta se presenta en amarillo, mientras que cuando sobrepasa el
umbral mínimo la alarma se presenta en rojo.
74
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
Figura 4.7 Alarmas obtenidas con IP SLA Monitor.
75
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
CONCLUSIONES.
Cisco IP SLA es una herramienta que resulto sumamente sencilla de utilizar al
momento de monitorear el tiempo de respuesta de un servidor HTTP; también
pudimos determinar los umbrales de servicio para que de acuerdo a estos se
verifiquen los tiempos de respuesta para determinar el cumplimiento de los acuerdos
de nivel de servicio.
En los casos en los que los umbrales establecidos fueron sobrepasados se
recibieron alertas indicándonos la gravedad del excedente en el tiempo de respuesta,
de esta forma podemos darnos cuenta cuando ocurre alguna anomalía en la
conexión con el servidor HTTP junto con el riesgo que representa a la disponibilidad
de nuestro servicio web; de tal modo que podamos dar una respuesta oportuna a
dicha anomalía.
76
IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB
REFERENCIAS
[1].http://gemini.udistrital.edu.co/comunidad/profesores/jruiz/jairocd/texto/redes/
temas/admoredest.pdf
[2].http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/
gestion_de_niveles_de_servicio/proceso_gestion_de_niveles_de_servicio/
planificacion_de_niveles_de_servicio.php
[3].Cisco IOS IP SLAs Configuration Guide.
[4].User Guide Cisco IOS IP Service Level Agreements.
77