C. Valores, Cadencias, Almacenar, Umbrales y Acciones
III. IMPLANTACIÓN DEL PLAN DE MONITORIZACIÓN
VI. RESPONSABLES DE MONITORIZACIÓN
I. ABSTRACT
Este trabajo es un plan de monitorización para la red de Eskola, donde se establecerán los parámetros a monitorizar en los dispositivos más importantes para el correcto funcionamiento de la red de Eskola. De este modo se hará un pequeño análisis sobre cual es la disponibilidad de la red y el rendimiento.
II. PLAN DE MONITORIZACIÓN
A. Introducción
Entre los diferentes modelos de gestión que existen en el mercado se ha utilizado el SNMP, que es un estándar abierto definido por IETF y soportado por casi todos los fabricantes.
Para realizar la monitorización se han empleado dos herramientas:
- HP OpenView Windows Network Node Manager Release B.06.10
- JFFNMS
B. Elementos
Después de estudiar la topología, características… de la red de Eskola se pasó a definir cuales eran los criterios para elegir los elementos a monitorizar. Se decidió que los criterios más importantes para la elección son disponibilidad y rendimiento, ya que en Eskola se requiere que la red esté operativa la mayor parte del día y a poder ser con una velocidad de transmisión alta.
Teniendo en cuenta que no es posible monitorizar toda la red se tuvieron que elegir los elementos que más influían en el rendimiento de la red de Eskola en base a los criterios antes citados. Los dispositivos son:
- Cajun: se ha elegido el router principal de la red de Eskola ya que se considera que puede aportar datos muy interesantes para poder monitorizar porque es el centro de la red e interconecta las subredes de eskola.
- Este elemento dispone de 123 interfaces distintos, por lo que hemos decidido monitorizar 4 de ellos, que nos han parecido los más significativos:
- 56: Módulo 8, puerto 10 (Servidor de Correo de Eskola)
- 89: Servidores (Un conjunto de servidores, no todos)
- 106: Edificio_6 (Interfaz hacia el edificio 6 de Eskola, donde se sitúan los departamentos de administración, sistemas de información, organización...)
- Proxy2: es la computadora proxy que permite a los alumnos acceder a Internet, por ello es un recurso muy utilizado a lo largo del día. Proxy2 no sólo es una puerta que permite a los alumnos acceder a Internet, hay que tener en cuenta que también puede ser un modo de acceso desde el exterior a la red de Eskola. Por tanto, es importante monitorizar Proxy2 ya que:
- Si produjese algún error se privaría de acceso a Internet a los alumnos o la capacidad de acceso a Internet se vería disminuida.
- Es una amenaza para la red de Eskola porque es un modo de entrada para el exterior.
- Ikasleak: es un servidor utilizado sobre todo para el almacenaje de ficheros, donde cada alumno tiene una carpeta personal para depositar documentos propios, los profesores dejan a disposición de los alumnos distintos tipos de documentos, software... Ha parecido interesante monitorizar este elemento porque es un servidor muy utilizado dentro de la red de Eskola y por consiguiente su correcto funcionamiento puede resultar vital.
- Critix: es un conjunto de tres computadoras que dan servicio a todas las terminales de la red, a la cual están conectada:
- Las secretarías virtuales (terminales que proporcionan información sobre aulas libres, horarios, etc para los alumnos).
- Terminales que se usan para prácticas en las aulas.
- Y demás terminales como las terminales de la biblioteca, etc...
Por tanto, se puede apreciar que la caída de Citrix o un funcionamiento precario provocaría numerosos problemas en el funcionamiento de Eskola: falta de información para los alumnos (desconocimiento de cambios de horarios, aulas informáticas disponibles, ...), falta de recursos para realizar prácticas, menos elementos a disposición de los alumnos con acceso a Internet.
Dentro de este conjunto de elementos no todos tienen la misma importancia, ya que la repercusión que puede tener la caída de los dispositivos es diferente. De este modo han priorizado los dispositivos de la siguiente manera:
· Cajun: es un elemento crítico, puesto que si deja de funcionar inhabilitaría la red de Eskola y su repercusión más grave sería en los procesos administrativos y comunicativos. Además hay que tener en cuenta que Cajun no sólo interconecta los diferentes edificios y departamentos de Eskola, sino que también se conecta con la redes de las demás facultades de MU (Oñate, etc…).
· Citrix, Ikasleak, Proxy2: se consideran muy importantes pero no críticos, ya que su caída no repercute en los procesos mas importantes de eskola (administrativos comunicación interna) pero sí que afectaría a procesos secundarios para eskola (acceso a Internet, almacenamiento de datos para alumnos, utilización de terminales….)
C. Valores, Cadencias, Almacenar, Umbrales y Acciones
Una vez definido cuales son los elementos de la red de Eskola que son interesantes para monitorizar hay que decidir qué valores de los elementos analizados son los que más información interesante nos pueden proporcionar. Para cada valor se precisará:
- Cada cuánto tiempo se deben consultar los valores para lograr suficiente información sin repercutir en el funcionamiento de la red.
- Cuáles son los valores que se deben de almacenar para que luego sean analizados más profundamente.
- Cuáles son los umbrales que a partir de ellos los valores sean alarmantes y ante esos casos que acciones que se deben de tomar.
1. CAJUN
a) Porcentaje de utilización:
El porcentaje de utilización de los interfaces del router es un valor interesante ya que se podrá averiguar cual es el estado de las interfaces: si están saturados, si la cantidad de datos transmitida es muy cercana a la capacidad máxima del interface o si la capacidad máxima del interface es bastante superior al tráfico. De este modo se conocerá si Cajun ofrece la disponibilidad requerida en Eskola y si el tráfico que transmite es cercano a su máximo.
Con los resultados obtenidos y una vez analizados habría que reflexionar si es necesario cambiar de router para satisfacer las necesidades de la red o sino modificar la red para que el router sea capaz soportar el tráfico de la red.
La expresión utilizada en OpenView es la siguiente:
If%util = (Received byte rate + transmitted byte rate) * 8 / interface link speed
- Cadencia: 15 minutos
- Almacenar: Sí, para controlar la evolución. Intervalo: 1 año
- Umbral: >75% Rearme <=65%
- Acciones: Aviso al administrador sobre el estado crítico del router.
b) Porcentaje de error de los paquetes a la entrada:
El porcentaje de error de los paquetes tal y como indica su nombre es un valor que indica el numero de paquetes erróneos que se reciben por el número de paquetes totales recibidos. Este valor nos puede orientar para conocer cual es la cantidad de tráfico erróneo que corre por la red. Ese tráfico erróneo repercutirá en el rendimiento ya que entorpecerá el router para enrutar los paquetes buenos.
La expresión utilizada en OpenView es la siguiente:
If%InError = input error rate/total packets received rate
- Cadencia: 15 minutos, se considera que no variará mucho en este intervalo.
- Almacenar: Sí, una semana sería suficiente para conocer una aproximación a la media del porcentaje de paquetes erróneos.
- Umbral: <10%. Rearme: <=5%
- Acciones: Aviso al administrador sobre la numerosa cantidad de tráfico erróneo.
c) Porcentaje de error de los paquetes a la salida:
Para conocer la calidad de servicio que está ofreciendo el elemento Cajun en las interfaces elegidas:
La expresión utilizada en OpenView es la siguiente:
In%OutError = input error rate/total packets received rate
- Cadencia: 15 minutos,
- Almacenar: Sí, una semana sería suficiente para conocer una aproximación a la media del porcentaje de paquetes erróneos.
- Umbral: <10%. Rearme: <=5%
- Acciones: Aviso
d) Interfaz activo:
El objeto IfOperStatus devuelve cuales son el estado de los interfaces del router. Es una información interesante ya que si alguna interface está cerrada la comunicación en la red no será correcta. Cuando se han descrito los elementos que se habían escogido para monitorizar se especificado que en Cajun sólo se analizarían tres interfaces, aunque en este apartado se analizarán todos sus interfaces para analizar la disponibilidad.
El MIB utilizado en OpenView:
.iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.IfOperStatus
- Cadencia: 1 minuto porque es una valor crítico.
- Almacenar: no nos parece representativo el graficar el estado de las interfaces, ya que los monitorizamos sobre todo, para que salte la alarma cuando uno de ellos cae.
- Umbral: si caído (== 2). Rearme != 2.
- Razón: para ver si el interfaz en cuestión está caído o no.
- Acciones: alarma y envío de mail al administrador.
- Razón: por ser un valor crítico que puede afectar a las comunicaciones.
e) Tráfico entrante en paquetes:
Para comprobar que la capacidad de recepción del router es suficientemente holgada como para recibir todos los paquetes que le llegan. No es lo mismo el ancho de banda que la capacidad de emisión, este último nos dice los paquetes por segundo que es capaz de recibir el interfaz. Nos da información de la saturación del interfaz tal como lo hace el porcentaje de utilización pero desde la perspectiva de los paquetes.
La expresión utilizada en OpenView:
IfAllInPackets= (ifInUcastPkts + ifInNUcastPkts) + (ifInErrors + ifInDiscards + ifInUnknownProtos)
- Cadencia: 5 minutos
- Almacenar: Sí para obtener estadísticas. Intervalo de un año.
- Umbral: 75% Rearme <=65%
- Acciones: alarma
2. Proxy2
a) Porcentaje de utilización:
El porcentaje de utilización de la interfaz (ip 172.17.12.2) del Proxy2 es un valor interesante ya que se podrá averiguar cual es la utilización de la interfaz: está saturado, la cantidad de datos transmitida es muy cercana a la capacidad máxima del interface o la capacidad máxima del interface es bastante superior al tráfico. De este modo se conocerá si Proxy2 ofrece la disponibilidad requerida en Eskola y si el tráfico que transmite es cercano a su máximo.
La expresión utilizada en OpenView es la siguiente:
If%util = (Received byte rate + transmitted byte rate) * 8 / interface link speed
- Cadencia: 15 minutos
- Almacenar: Sí, para controlar la evolución. Intervalo: 1 año
- Umbral: >75% Rearme <=65%
- Acciones: Aviso al administrador sobre el estado crítico del router.
b) Número de bytes recibidos
Para controlar el tráfico en bytes que recibe de la red, este valor será importante a la comparar con la capacidad máxima de Proxy2 y de este modo saber si está saturado o no. De este modo se sabrá si la conexión es la adecuada para satisfacer las peticiones web de los alumnos.
El objeto MIB utilizado en OpenView es el siguiente:
.iso.org.dod.internet.private.enterprises.lanmanager.lanmgr-2.server.svStatRcvdBytes
· Cadencia: 15 minutos.
· Almacenar: Sí, para controlar la evolución. Intervalo de 1 año.
· Umbral: No, no es un dispositivo crítico para el correcto funcionamiento de la red.
c) Número de bytes enviados
Se controlará el número que bytes que envía Proxy2 para conocer el tráfico que es solicitado por parte de los alumnos. De este modo se sabrá si la conexión es la adecuada para satisfacer las peticiones Web de los usuarios conectados.
La expresión utilizada en OpenView es la siguiente:
.iso.org.dod.internet.private.enterprises.lanmanager.lanmgr-2.server.svStatSentBytes
· Cadencia: 15 minutos.
· Almacenar: Sí, para controlar la evolución. Intervalo de 1 año.
· Umbral: No, no es un dispositivo crítico para el correcto funcionamiento de la red.
d) Proxy Error Rate:
El porcentaje de error de los paquetes tal y como indica su nombre es un valor que indica el numero de paquetes erróneos que se reciben y se envían por el número de paquetes totales recibidos y enviados.
- Cadencia: 15 minutos
- Almacenar: Sí, para controlar la evolución. Intervalo: 1 año
- Umbral: >75% Rearme <=65%
- Acciones: Aviso al administrador sobre el estado crítico del router.
3. Citrix
a) Porcentaje de utilización del disco
Los usuarios que trabajan contra Citrix tienen la posibilidad de guardar sus archivos en los discos duros de las computadoras Citrix. Por ejemplo: la configuración personal de cada usuario, archivos del usuario, etc…
Por tanto, la utilización óptima de los discos duros de Citrix son claves para su funcionamiento. Para calcular el porcentaje de utilización del disco se ha empleado la siguiente expresión:
La expresión utilizada en OpenView es la siguiente:
Disk%util = (blocks - free) / (blocks - free + avail)
- Cadencia: 1 hora, una cadencia bastante baja debido al carácter del valor. Suponemos que este porcentaje no cambie mucho en poco tiempo.
- Almacenar: no, ya que no variará demasiado en el tiempo no se considera interesante el conocer su evolución.
- Umbral: >85%. Rearme: <=80%.
- Acciones: alarma, para que el administrador tome las acciones correctoras pertinentes (limpiar discos, instalar uno nuevo...)
b) Número de sesiones establecidas
El número de sesiones establecido en los servidores Citrix es un dato meramente informativo que nos permite conocer la evolución de la utilización de los terminales.
El objeto MIB utilizado en OpenView:
.iso.org.dod.internet.private.enterprises.lanmanager.lanmgr-2.server.svSessionNumbers
· Cadencia: 30 min, no consideramos necesaria una cadencia alta ya que el valor no variará mucho en el tiempo.
· Almacenar: SI, para analizar la evolución de la utilización de los terminales, se considera adecuado monitorizarlo durante un año.
· Umbral: No, no se tenía criterios de referencia para establecer un umbral. Lo ideal sería conocer si se estable un máximo de sesiones permitidos para este servidor y establecer este dato como umbral pero no disponemos de este dato.
c) Número de bytes recibidos
Para controlar el tráfico en bytes que recibe de la red, este valor será importante para comparar con la capacidad máxima de Citrix y saber si está saturado o no. De este modo se sabrá si la conexión es la adecuada para satisfacer las peticiones de los usuarios conectados.
El objeto MIB utilizado en OpenView es el siguiente:
.iso.org.dod.internet.private.enterprises.lanmanager.lanmgr-2.server.svStatRcvdBytes
· Cadencia: 15 minutos.
· Almacenar: Sí, para controlar la evolución del trafico generado por las terminales durante 1 año.
· Umbral: No, no se tenía criterios de referencia para establecer un umbral.
d) Número de bytes enviados
Se controlará el número de bytes que envía Citrix para conocer el tráfico que es solicitado por parte de los usuarios. De este modo se sabrá si la conexión es la adecuada para satisfacer las peticiones de los usuarios conectados.
El objeto MIB utilizado en OpenView:
.iso.org.dod.internet.private.enterprises.lanmanager.lanmgr-2.server.svStatSentBytes
· Cadencia: 15 minutos.
· Almacenar: Sí, para controlar la evolución del trafico generado por las terminales durante 1 año.
· Umbral: No, no se tenía criterios de referencia para establecer un umbral.
III. IMPLANTACIÓN DEL PLAN DE MONITORIZACIÓN
Tras un largo periodo de formación y fase de pruebas con las herramientas de monitorización Jffnms y OpenView se llevó a cabo el plan de monitorización el día 27 de enero desde las 4 de la tarde hasta las 8 de la noche.
Este periodo no es lo suficientemente largo como para sacar contundentes conclusiones sobre los resultados obtenidos, aunque nos permite hacernos una pequeña idea sobre el estado de la red.
Problemas surgidos durante la implantación:
Durante la implantación del plan de monitorización han surgido varios problemas:
- No se han podido monitorizar el servidor ikasleak, puesto que tiene SNMP desactivado.
- No se ha podido monitorizar Cajun con Jffnms, ya que para ello es necesario crear nuevos módulos con los OIDs específicos de Cajun.
- Aunque en fase de prueba se pudo monitorizar la utilización de los discos duros de Citrix con OpenView, el día de la monitorización, por motivos que se desconocen no se pudo realizar dicha monitorización.
MIBs específicos
Excepto en el elemento Ikasleak los MIB utilizados han sido los estándares que ofrecía la propia herramienta de monitorización. En este último, tuvimos que cargar el MIB específico para servidores Windows NT y 2000, descargado de la página http://snmpboy.msft.net/pub/w2kmibs/ que nos permitía monitorizar los siguientes OIDs:
- svSessionNumbers: número de sesiones establecidas en el servidor
- SvStatRcvdBytes: número de bytes enviados por el servidor (también monitorizable mediante el OID estándar)
- SvStatSentBytes: número de bytes recibidos por el servidor (también monitorizable mediante el OID estándar)
IV. RESULTADOS OBTENIDOS
A. Cajun
OpenView:
ifAllInPackets: monitorización de la entrada de paquetes en Cajun por la interface número 56
Como se puede observar el trafico que circula por esta interfaz no es constante lo que supone que en algunos momentos pueda haber peligro de desbordamientos en cambio otras veces la utilización es muy baja..
ifInErrors: monitorización de la entrada de paquetes con error en Cajun por la interface numero 106, como se puede apreciar ningún paquete llegó con error en este intervalo.
Basándose en esta grafica donde se muestra el número de paquetes con error recibidos por la interface 106 se puede deducir que el porcentaje de paquetes con error es muy baja.
B. Citrix
svSessionNumbers: número de sesiones activas en los tres servidores Citrix.
OpenView
Jffnms:
Como se puede apreciar la monitorización en OpenView no es correcta, puesto que los datos obtenidos en Jffnms son mucho más reales y coherentes.
El número de usuarios conectados a los servidores es muy estable y además tiene capacidad para iniciar más sesiones. Por tanto Citrix es capaz de dar respuesta a las necesidades de los usuarios de eskola.
OpenView:
svStatsendBytes:
En la siguiente grafica se pueden apreciar los byts enviados por los tres servidores Citrixy el servidor Proxy2.
svStatRcvdBytes:
En la siguiente grafica se puede apreciar los bytes recibidos por los tres servidores Citrix y por Proxy2.
Jffnms:
Continuación podemos observar las graficas obtenidas del tráfico de red monitorizada a través de Jffnms.
Observando las gráficas de utilización de los servidores Citrix se puede apreciar que durante el tiempo de monitorización Urraki a las 18:00 transmitió y recibió una elevada cantidad de tráfico. El motivo de este suceso lo desconocemos pero comparado con el tráfico que tuvieron Mello y Ernio parece inusual. Por lo que convendría analizarlo más exhaustivamente.
Utilización del disco:
Por motivos que desconocidos, aunque previamente, en fase de prueba, se había conseguido monitorijzar los discos duros de los servidores Citrix con Open View, El día de la monitorización no se puedo realizar con ésta herramienta. A pesar de todo si que conseguimos monitorizarlo con Jffmns, Aquí tenemos los resultados:
Los discos de Ernio:
Los discos de Mello:
Los discos de Urraki:
Tras el estudio de la utilización de los discos duros se ha llegado a la conclusión que siempre hay uno de los discos prácticamente lleno y el otro aún con mucho de su espacio libre. Por ello, creemos que en cuanto a la capacidad de discos duros no existe ningún problema, aunque tal vez se debería revisar la administración para que sea más equilibrada la utilización de los discos duros.
C. Proxy2
OpenView
svStatsendBytes:
En la siguiente grafica se pueden apreciar los bytes enviados por los tres servidores Citrixy el servidor Proxy2.
svStatRcvdBytes:
En la siguiente grafica se puede apreciar los bytes recibidos por los tres servidores Citrix y por Proxy2.
Jffnms:
En la siguiente grafica se observan la grafica de la monitorización de tráfico de red del proxy2:
En las gráficas se muestra que el tráfico que se envía y se transmite en Proxy no es constante por lo que habría que cuidar que los picos no desborden su capacidad.
Proxy Error Rate:
Comparando la gráfica del ratio de errores con la gráfica de utilización del Proxy se puede apreciar que existe una contradicción porque cuando menos tráfico existía más errores se han producido. No hemos podido entender el motivo, aunque creemos que habría estudiarlo más a fondo.
Utilización interfaz:
V. ACCESO A LOS DATOS
No todo el mundo tendrá acceso a los datos de la monitorización. El responsable de la administración de la red de Eskola tendrá acceso total. Los trabajadores relacionados con la administración de la red, el jefe de sistemas de información de Eskola y el jefe del departamento de Informática tendrán acceso de lectura a todos los datos monitorizados. Demás personal y trabajadores de Eskola podrán acceder a las gráficas sobre el porcentaje de utilización del elemento Cajun.
VI. RESPONSABLES DE MONITORIZACIÓN
El responsable de monitorización de todos los dispositivos será el administrador de la red de Eskola. Y en el caso excepcional de que no se encontrase disponible dicha persona, la responsabilidad pasaría al jefe de Sistemas de Información de Eskola.
VII. CONCLUSIONES
Una vez finalizado el trabajo sobre el plan de monitorización en Eskola se ha llegado a las siguientes conclusiones:
- Para realizar un plan de monitorización más serio en Eskola creemos que es necesario tener un mayor conocimiento de la red y más permisos para monitorizar mejor los dispositivos. Por ello, se ha considerado que sería conveniente que el administrador de la red tome parte en el grupo de trabajo que lleva a cabo el plan de monitorización.
- Sobre las herramientas utilizadas se ha llegado a la conclusión que OpenView es un programa bastante fácil de utilizar. Jffnms en cambio no es tan intuitivo como OpenView y hay que trabajarlo más para monitorizar (por ejemplo, creación del modulo para monitorizar Cajun).
- A otra conclusión importante a la que hemos llegado es que creemos que un plan de monitorización se debería de aplicar en cualquier red para averiguar cuales son las puntos fuertes que no necesitan mejoras pero sí un seguimiento y cuales son las áreas que se pueden mejorar.