Gestión remota de servidores de bases datosrepositorios.unimet.edu.ve/docs/25/TA168A53G4.pdf ·...
144
GESTIÓN REMOTA DE SERVIDORES DE BASES DE DATOS Rafael Angelico Oswin Ondarza Tutor: Hugo Morales Caracas, Julio 2001. Universidad Metropolitana Facultad de Ingeniería Escuela de Ingeniería de Sistemas
Transcript of Gestión remota de servidores de bases datosrepositorios.unimet.edu.ve/docs/25/TA168A53G4.pdf ·...
GESTIÓN REMOTA DE SERVIDORES
DE BASES DE DATOS
Rafael Angelico
Oswin Ondarza
Tutor: Hugo Morales
Caracas, Julio 2001.
Universidad Metropolitana Facultad de Ingeniería Escuela de Ingeniería de Sistemas
DERECHO DE AUTOR
Cedemos a la Universidad Metropolitana el derecho de reproducir y
difundir el presente trabajo, con las únicas limitaciones que establece la
legislación vigente en materia de derecho de autor.
En la ciudad de Caracas, a los doce días del mes de julio del año dos
mil uno.
_____________________ _____________________
Rafael Angelico Oswin Ondarza
I
APROBACIÓN
Consideramos que el Trabajo Final titulado
GESTIÓN REMOTA DE SERVIDORES
DE BASES DE DATOS
elaborado por los ciudadanos
RAFAEL ANGELICO
OSWIN ONDARZA
para optar al título de
INGENIERO DE SISTEMAS
Reúne los requisitos exigidos por la Escuela de Ingeniería de Sistemas de
la Universidad Metropolitana, y tiene méritos suficientes como para ser
sometido a la presentación y evaluación exhaustiva por parte del jurado
examinador que se designe.
En la ciudad de Caracas, a los 12 días del mes de julio del año 2001.
____________________
Ing. Hugo Morales
II
ACTA DE VEREDICTO
Nosotros, los abajo firmantes constituidos como jurado examinador y
reunidos en Caracas el día ________________________, con el propósito de
evaluar el trabajo final titulado
GESTIÓN REMOTA DE SERVIDORES
DE BASES DE DATOS
presentado por los ciudadanos
RAFAEL ANGELICO
OSWIN ONDARZA
para optar al título de
INGENIERO DE SISTEMAS
emitimos el siguiente veredicto:
Aprobado__ Notable__ Sobresaliente__
Sobresaliente con Mención Honorífica__
Observaciones:_______________________________________________________
____________________________________________________________________
__________________ ___________________ __________________
Hugo Morales Ricardo Strusberg Lucia Cardoso
III
DEDICATORIA
-A Raffaele, Norka,
Pedro y Vero-
Rafa
-A Gloria, Alex,
Pio y Mariana-
Ticky
IV
AGRADECIMIENTOS
A Susana Romagni y Hugo Morales, por apoyarnos en los
momentos más difíciles de este último año.
A Ricardo Strusberg “linux-man”, por apoyarnos en el
desarrollo de esta investigación.
A José Vicente Núñez “Dark Angel”, por ser nuestro guía en la
realización de este trabajo.
A nuestras familias, por todo el apoyo que nos dieron a lo largo
de nuestra carrera.
A EL UNIVERSAL por facilitarnos una gran parte de la
bibliografía y por permitirnos monitorear sus servidores.
A Luna, por la compañía brindada cada día de trabajo.
A todos nuestros amigos que siempre estuvieron con nosotros.
A todos, mil gracias.
V
TABLA DE CONTENIDOS
LISTA DE TABLAS.................................................................................................. 1
LISTA DE FIGURAS ............................................................................................... 2
RESUMEN ................................................................................................................. 4
INTRODUCCIÓN ..................................................................................................... 5
CAPÍTULO I .......................................................................................................... 9
MARCO DE REFERENCIA ................................................................................. 10
1. MONITOREO .................................................................................................. 10
1.1. ¿QUÉ ES MONITOREO?................................................................................. 10 1.2. CONCEPTOS ASOCIADOS Y TERMINOLOGÍA................................................ 12 1.3. DEFINIENDO UN MODELO DE MONITOREO GLOBAL................................ 13
1.3.1 Generación de Información de Monitoreo........................................14 1.3.2 Procesamiento de Información de Monitoreo ................................18 1.3.3 Distribución de la Información de Monitoreo................................21 1.3.4 Presentación de la Información de Monitoreo...............................22
2. MONITOREO EN BASES DE DATOS..................................................... 22
2.1. MEMORIA Y CPU.......................................................................................... 23 2.2. QUERIES ......................................................................................................... 24 2.3. TRANSACCIONES............................................................................................ 25
3. BALANCEO DE CARGAS ............................................................................ 26
3.1. ASIGNACIÓN DE CARGAS DE TRABAJO........................................................ 27 3.2. ARQUITECTURA DE LOS SISTEMAS DE BASE DE DATOS PARALELOS ..... 28 3.3. TÉCNICAS DE BALANCEO DE CARGAS......................................................... 31 3.4. ESTRATEGIAS PARA EL BALANCEO DE CARGAS........................................ 31 3.5. PARTICIONES DE DATA................................................................................ 33
4. DISPOSITIVOS MÓVILES...................................................................... 33
4.1. GENERANDO INFORMACIÓN PARA DISPOSITIVOS MÓVILES ................ 34 4.1.1 Poder Computacional .....................................................................35 4.1.2 Consumo de Poder ..........................................................................37 4.1.3 Capacidad de Presentación................................................................38 4.1.4 Comunicación........................................................................................39
5. XML Y SUS EXTENSIONES................................................................... 40
5.1. INTRODUCCIÓN A XML................................................................................. 40 5.2. XSL (EXTENSIBLE STYLESHEET LANGUAGE) ........................................... 41 5.3. PARSEADOR XML...................................................................................... 42
VI
5.4. JAVA Y XML.................................................................................................. 42
CAPÍTULO II ...................................................................................................... 43
DESARROLLO DE LA HERRAMIENTA ......................................................... 44
1. ANÁLISIS DE REQUERIMIENTOS ..................................................... 47
1.1. ELABORACIÓN DE CASOS DE USO DE ALTO NIVEL.................................. 47 1.2. ELABORACIÓN DE LOS CASOS DE USO EXPANDIDOS................................. 51 1.3. MODELO CONCEPTUAL O MODELO DEL MUNDO........................................ 63 1.4. ESPECIFICACIÓN INICIAL DE LA INTERFAZ DE USUARIO.......................... 67
2. DISEÑO DEL SISTEMA............................................................................... 69
2.1. ARQUITECTURA DE LA HERRAMIENTA........................................................ 70
3. DISEÑO DETALLADO ................................................................................. 76
3.1. DISEÑO DEL DIAGRAMA DE CLASES............................................................ 76 3.2. ELABORACIÓN DE LOS DIAGRAMAS DE SECUENCIA.................................. 79 3.3. DISEÑO DE LA BASE DE DATOS.................................................................... 81 3.4. INTERFAZ GRÁFICA DE USUARIO................................................................. 83
4. IMPLEMENTACIÓN Y PRUEBAS........................................................ 86
4.1. MÓDULO DE GENERACIÓN .......................................................................... 88 4.2. MÓDULO DE PROCESAMIENTO.................................................................... 89 4.3. MÓDULO DE DISTRIBUCIÓN ........................................................................ 92 4.4. MÓDULO DE PRESENTACIÓN........................................................................ 94
MODELO DE BALANCEO DE CARGAS SEGÚN EL MONITOREO REALIZADO .......................................................................................................... 102
CAPÍTULO III .................................................................................................. 110
RESULTADOS...................................................................................................... 111
CONCLUSIONES................................................................................................. 117
RECOMENDACIONES....................................................................................... 119
BIBLIOGRAFÍA.................................................................................................... 121
APÉNDICE A: DIAGRAMAS DE SECUENCIA............................. 124
APÉNDICE B: TECNOLOGÍAS.............................................................. 130
LINUX................................................................................................................... 131
ORACLE............................................................................................................... 133
JAVA...................................................................................................................... 135
VII
1
LISTA DE TABLAS
Tabla 1. Poder computacional......................................................................35
Tabla 2. Propiedades de presentación.........................................................39
Tabla 3. Lista de posibles conceptos u objetos dentro del dominio de la Herramienta de monitoreo..........................................................65
Tabla 4. Lista de candidatos a métodos.......................................................66
Tabla 5. Lista de candidatos a atributos.....................................................67
2
LISTA DE FIGURAS
Figura 1. Modelo de administración de sistemas........................................11
Figura 2. Generación de reportes y trazas de monitoreo............................14
Figura 3. Procesamiento de los reportes de monitoreo...............................19
Figura 4. Arquitecturas de sistemas de bases de datos paralelos..............30
Figura 5. Comparación de capacidad de memoria......................................36
Figura 6. Comparación de capacidad total de almacenamiento.................38
Figura 7. Caso de uso de alto nivel de la herramienta de monitoreo.........49
Figura 8. Caso de uso expandido de monitoreo...........................................58
Figura 9. Caso de uso expandido de Reportes de Desempeño....................61
Figura 10. Casos de uso expandidos de la herramienta de monitoreo.......63
Figura 11. Top-down de pantallas...............................................................69
Figura 12. Arquitectura 3-capas. Distribución de las capas a través
de la red.......................................................................................71
Figura 13. Arquitectura de una aplicación Web. .......................................72
Figura 14. Módulos de Monitoreo dentro de una Arquitectura de
Aplicación WEB..........................................................................75
Figura 15. Diagrama de clases del sistema.................................................78
Figura 16. Diagrama de secuencias elaborado para el escenario Monitoreo por Petición.................................................................80
Figura 17. Diagrama de entidad de relación de la herramienta de monitoreo................................................................................82
Figura 18. Pantalla de autenticación...........................................................83
Figura 19. Menú principal. ..........................................................................84
Figura 20. Menú de Monitoreo de Memoria................................................85
Figura 21. Rendimiento de CPU del 16/05/2001. .......................................90
Figura 22. Módulo de generación y módulo de procesamiento...................91
Figura 23. Módulo de distribución y su interacción....................................93
Figura 24. Archivo de propiedades..............................................................94
3
Figura 25. Proceso de generación del archivo producto..............................95
Figura 26. Diferentes tipos de dispositivos realizando peticiones.............96
Figura 27. Archivo XML para el menú monitoreo......................................97
Figura 28. Archivo XSL para Palm Pilot.....................................................97
Figura 29. Archivo XSL para formato HTML.............................................98
Figura 30. Archivo XSL para WAP..............................................................99
Figura 31. Presentación HTML...................................................................99
Figura 32. Presentación Palm Pilot.............................................................99
Figura 33. Presentación WAP......................................................................99
figura 34. SPMD.........................................................................................104
Figura 35. Proceso del Distribuidor...........................................................108
Figura 36. Resultados del Monitoreo por Petición....................................113
Figura 37. Resultados de los Reportes de Desempeño..............................114
Figura 38. Reportes de Desempeño a través de los dispositivos..............115
4
RESUMEN
GESTIÓN REMOTA DE SERVIDORES DE BASES DE DATOS
Autores: Rafael Angelico Oswin Ondarza Tutor: Ing. Hugo Morales Caracas, Julio 2001.
El objetivo del siguiente trabajo especial de grado es diseñar y desarrollar una herramienta Web de gestión de servidores de base de datos orientada al monitoreo, utilizando para ello dispositivos remotos. La herramienta busca ofrecer una visión única del contenido, sin importar el tipo de dispositivo que realiza las peticiones. Para lograr el objetivo anteriormente planteado, se investigó sobre servidores de bases de datos, en particular sobre el monitoreo de desempeño de los servidores y, con base a los hallazgos de la búsqueda, . se investigó sobre el balanceo de cargas en servidores de bases de datos. De igual manera se estudiaron las diferentes tecnologías en dispositivos móviles PDA y celulares, así como XML como estándar de desarrollo y sus posibles extensiones para la elaboración de la herramienta. El desarrollo de la herramienta Web de gestión de servidores de base de datos orientada al monitoreo se llevó a cabo utilizando la metodología orientada a objetos basada en la notación UML (Unified Method Language). Una vez cubiertas las fases de análisis y diseño, se inició la implementación de la herramienta en cuestión, utilizando como lenguaje de programación: XML para especificar el contenido y la estructura de la información, XSL para crear la presentación por tipo de dispositivo y Java para las funcionalidades de la herramienta. Como resultado se logró crear una herramienta que permite a los administradores de base de datos la supervisión de los recursos y tareas que los servidores manejan, a través de cualquier tipo de dispositivo y sin importar el lugar en donde se encuentren. Por último se presenta un modelo heurístico de balanceo de cargas, basado en los factores críticos del monitoreo realizado por la herramienta.
5
INTRODUCCIÓN
El objetivo que se persigue con la gestión de servidores de base de
datos, es ofrecer a los usuarios el acceso eficaz y eficiente a cualquier tipo
de datos, acorde a sus requerimientos y a la plataforma tecnológica
habilitada para tales funciones.
El proceso puede dividirse en tres fases
?? Estimación del desempeño
?? Medida del desempeño
?? Mejoras al desempeño.
De dicho proceso, se cubre de manera exhaustiva la fase medida del
desempeño, dados los objetivos planteados en la presente investigación.
Esta fase, también conocida como monitoreo, consiste en la recolección,
interpretación y presentación, en forma dinámica, de la información
relacionada con el desempeño de un servidor de base de datos. Su
finalidad es verificar el funcionamiento del proceso y facilitar la toma de
decisiones en cuanto a los posibles ajustes que deban hacerse para lograr
el o los objetivos de la plataforma solución.
Sin excepción, los esfuerzos en cuanto al monitoreo de servidores
de base de datos deben abarcar las diferentes estructuras físicas y lógicas
asociadas a los procesos del manejador, tales como el CPU, la memoria
utilizada y las transacciones que se están realizando, entre otros. De igual
manera, es necesario supervisar el ambiente en donde opera el manejador
de base de datos, el cual pudiera, directa o indirectamente, afectar su
funcionamiento, incluyendo el sistema operativo y las tareas asociadas a
6
él, como también el de algunos componentes, tales como los relativos a la
red en donde se llevan a cabo las operaciones.
En ocasiones, el proceso de supervisión de los servicios puede verse
afectado, porque los encargados del manejo de esta tecnología están
ubicados en zonas geográficas distantes de los servidores que brindan los
servicios. De allí la necesidad de diseñar y desarrollar una herramienta de
gestión de servidores de base de datos orientada al monitoreo, utilizando
para ello dispositivos remotos, objetivo que se plantea para los fines del
presente trabajo especial de grado.
Para facilitar los procesos de comunicación se establece como medio
de operaciones la WWW (World Wide Web), generando una sola
especificación del contenido y diferentes presentaciones, dependiendo del
tipo de dispositivo que realiza la petición. De esta manera se pretende
establecer un ambiente homogéneo de trabajo, evitando así la creación y
mantenimiento de múltiples versiones de la herramienta.
Para cumplir con el objetivo planteado anteriormente, se utiliza el
lenguaje de programación XML, modelo basado en el diseño, transmisión
y acceso Web, que separa el contenido y la estructura de la información de
la presentación de la misma.
Además del uso de XML, es necesario el uso de otras extensiones de
éste, como XSL para crear la presentación por tipo de dispositivo y Java
para las funcionalidades de la herramienta. Para el desarrollo de la
herramienta se utiliza la metodología orientada a objetos basada en la
notación UML (Unified Method Language).
7
El modelo heurístico de balanceo de cargas basado en los factores
críticos de desempeño, realizado por la herramienta, pretende mejorar el
funcionamiento de los distintos procesos que el servidor de base de dato s
realiza.
El trabajo especial de grado está estructurado como sigue: el capítulo
I presenta el marco teórico referencial que envuelve el contexto de la
investigación realizada. En este capítulo se presenta un modelo genérico
de monitoreo, a p artir de las actividades principales realizadas en el
proceso (generación, procesamiento, distribución y presentación de la
información de monitoreo). También se describen los elementos más
importantes en cuanto al desempeño de un servidor de base de datos,
además de analizar algunas investigaciones sobre el balanceo de cargas en
bases de datos paralelos. Por último, se exhiben los hallazgos en cuanto a
las capacidades que existen actualmente con los dispositivos remotos y
con XML y sus extensiones.
El capítulo II presenta de forma detallada el proceso de desarrollo de
la herramienta de monitoreo de servidores de base de datos. Para ello, se
inicia el capítulo con la presentación de una visión general de la
metodología implementada y luego se plantean los resultados de algunas
investigaciones, hallazgos y consideraciones que permiten definir los
requerimientos de la herramienta. Seguidamente, se presenta un análisis
del diseño y desarrollo e implementación del sistema, para finalizar el
capítulo con la presentación de un Modelo de Balanceo de Cargas según el
modelo realizado.
En el capítulo III se presentan los resultados obtenidos, una vez
finalizado el trabajo de investigación. Se inicia la presentación con la
8
descripción de las principales características de la herramienta de
monitoreo y las salidas que genera la misma, para finalizar con las
conclusiones y recomendaciones, una vez concluida la investigación.
9
CAPÍTULO I
10
MARCO DE REFERENCIA
1. MONITOREO
Según Van Riek (1993), entender un sistema es una “ciencia que a
veces significa poder predecir el comportamiento del mismo” (p. 4). Sin
embargo, con sistemas complejos como es el caso de los manejadores de
base de datos, esto pudiera no ser posible, por lo que una meta más real y
menos ambiciosa consistiría en conocer, al menos, qué es precisamente lo
que está pasando con el sistema.
Las ventajas de conocer qué está ocurriendo con un sistema son
considerables. En efecto, se puede “controlar su comportamiento y además
poder tomar decisiones en cuanto a la administración del sistema”
(Mansouri y Sloman. 1995, p. 3).
A continuación se presenta un modelo genérico de monitoreo en
términos de generación, procesamiento, distribución y presentación de la
información.
1.1. ¿Qué es Monitoreo?
Monitoreo puede ser definido como el “proceso dinámico de
recolección, interpretación y presentación de información concerniente a
objetos o procesos realizados por cualquier software durante su
desempeño” (Joyce y otros. 1987, p. 121). Este proceso es necesario por
diferentes razones, entre ellas, las actividades de administración de
recursos, rendimiento del servidor, configuración y seguridad de las
11
transacciones. Para lograr estos objetivos, el comportamiento del sistema
es observado y la información de monitoreo es recopilada. Esta
información es utilizada para la toma de decisiones en cuanto a la
administración del sistema y para llevar a cabo las acciones de control
necesarias en el sistema En la Figura 1 se puede observar el modelo de
administración de sistema realizado por Mansouri y Sloman (1995) que,
por ser recursivo, permite realizar acciones de control al mismo monitoreo.
Figura 1. Modelo de administración de sistemas
Existen diferentes problemas asociados con el monitoreo:
?? “Retrasos en la transferencia de la información donde es generada
al lugar o persona que la usará, lo cual significa que la información
puede ser innecesaria para el momento de su llegada” (Mansouri y
Sloman. 1995, p. 7).
?? Retrasos continuos al momento de reportar los eventos, pudiendo
causar que éstos se presenten en el orden incorrecto, lo que obliga a
implementar algún tipo de reloj que pueda ordenar la información.
?? “Competencia por recursos con el sistema al cual monitorea,
modificando así su comportamiento” (Van Riek y otros.1993, p. 16).
Toma de Decisiones
Control
Sistema a Administrar
Monitoreo
12
Según Feldkuhn y Erickson (1989), para lograr superar estos
problemas es necesario diseñar un sistema de monitoreo basado en sus
funciones generales, como son la generación, procesamiento, distribución y
presentación de la información.
1.2. Conceptos asociados y terminología
Mansouri y Sloman (1995) consideran el monitoreo como un proceso
basado en objetos; por lo tanto, es preciso definir un objeto a ser
administrado como cualquier componente de hardware o software cuyo
comportamiento puede ser controlado por un sistema. El objeto encapsula
su comportamiento detrás de una interfaz que posee la información vital
para propósitos de monitoreo. Por este motivo, el concepto de
encapsulamiento en los sistemas actuales causa problemas a los sistemas
de monitoreo, dadas las diversas formas en que se debe acceder a esa
información (Holden, 1989).
El monitoreo puede ser realizado a uno o varios objetos. Cada uno
está asociado a un status y a un grupo de eventos. El status de los objetos
es “una medida de su comportamiento en algún momento en el tiempo y es
representado por diferentes variables de status contenidas en un vector de
status” (Mansouri y Sloman. 1995, p. 10). Un evento es definido como “un
cambio en el estado del objeto en un período de tiempo específico.” (Van
Riek y otros. 1993, p. 10). Usualmente el status del objeto cambia
constantemente: su comportamiento es observado en términos de eventos
resaltantes, llamados eventos de interés. Estos reflejan cambios que son
significativos para la administración, por lo tanto son generados cuando
una serie de condiciones predefinidas son satisfechas. La información de
13
monitoreo describe el status y eventos asociados con un objeto o grupo de
objetos en desempeño. Esta información puede ser representada en
reportes de status y eventos individuales o reportes secuenciales de esa
información en forma individual o en forma histórica.
El monitoreo temporal es el proceso realizado con la finalidad de
obtener status periódicos del desempeño, proveyendo vistas instantáneas
del comportamiento de los objetos. Por otra parte, el monitoreo por
eventos se basa en la obtención de la información sobre eventos de interés,
el cual brinda una visión dinámica de las actividades del sistema cuando
un cambio significativo ocurre. (Mansouri y Sloman. 1995)
1.3. Definiendo un Modelo de Monitoreo Global
El modelo de monitoreo global, según Feldkuhn y Erickson (1989),
establece cuatro actividades para monitorear:
?? Generación: Eventos importantes son detectados al ser observado el
sistema a administrar y reportes de status y eventos son generados.
Estos reportes son usados para construir trazas de monitoreo, que
representan las vistas históricas del sistema.
?? Procesamiento: Un servicio de monitoreo debe brindar
funcionalidades comunes como combinación de trazas, validación,
actualización y filtración de la información de monitoreo. Debe
convertir cualquiera que sea el nivel de la información a un formato
adecuado y con los detalles necesarios para el usuario.
14
?? Distribución: Los reportes de monitoreo son distribuidos a los
usuarios, gerentes, o administradores que los requieran.
?? Presentación: La información recolectada y procesada es presentada
a los usuarios en formato apropiado.
1.3.1 Generación de Información de Monitoreo
Los datos del monitoreo son generados en forma de status, y los
reportes de eventos son creados (véase Figura 2). La recolección de estos
eventos es usualmente llamada trazas, debido a que representa la
información que es dejada por la ejecución del programa (Van Riek y
otros, 1993). La secuencia de esos reportes es usada para generar trazas
de monitoreo.
Figura 2. Generación de reportes y trazas de monitoreo
Trazas de monitoreoTrazas de monitoreo
Generaci ón de Trazas
Reportes de MonitoreoReportes de Monitoreo
Reportes de statusReportes de status Reportes de eventosReportes de eventos
Detección de status
Detección de
eventosCriterios para la detección de
eventos
Criterios para la detección de
status
Vector de status
Trazas de monitoreoTrazas de monitoreo
Generaci ón de Trazas
Reportes de MonitoreoReportes de Monitoreo
Reportes de statusReportes de status Reportes de eventosReportes de eventos
Detección de status
Detección de
eventosCriterios para la detección de
eventos
Criterios para la detección de
status
Vector de status
15
Al momento de ser detectado un evento, “algún tipo de información
asociada con el evento debe ser almacenada” (Van Riek y otros. 1995, p.10)
y es denominado atributo. A continuación se analizan los distintos
reportes de monitoreo
A. Reportes de Status
Estos reportes contienen una serie de valores del vector de status y
pueden incluir otros tipos de datos, como el tiempo de ocurrencia o la
identificación del objeto. Representan el status de una instancia
específica en el tiempo y pueden ser generados como se describe a
continuación:
- De forma periódica. Generados en intervalos predefinidos.
- Por petición. Generados por una petición recibida. Estas
peticiones pueden ser periódicas o en un momento cualquiera.
B. Detección de Eventos y Reportes de Eventos
“Los cambios significativos en el status de un objeto o grupo de
objetos deben ser detectados (eventos de interés)” (Mansouri y
Sloman. 1995, p. 14) . Un evento de interés ocurre cuando una serie
de condiciones predefinidas son satisfechas. Para detectarlo, es
necesario algún tipo de censor que pueda detectar cambios
significativos en los objetos. Cuándo y cómo el detector de eventos se
active, dependerá exclusivamente del sistema de monitoreo.
16
- Localización del detector de eventos.
El detector de eventos puede ser localizado en dos lugares: en el
objeto en sí mismo y funciona como un proceso de éste, o externa
al objeto, donde un agente externo recibe los reportes y detecta
cambios en el estado del objeto.
- Tiempo en la detección de eventos.
La detección de eventos puede ocurrir de forma inmediata o con
retraso (posterior a la ocurrencia). Por ejemplo, la capacidad del
buffer puede ser monitoreada de forma constante para así
detectar cualquier cambio significativo en el mismo.
Alternativamente, los reportes pueden ser generados,
almacenados y usados posteriormente para detectar cualquier
evento de interés.
- Formato del reporte de eventos.
Luego de ocurrir el evento, un reporte debe ser generado. Debe
contener atributos como un identificador del evento a reportar,
tipo, prioridad, tiempo de ocurrencia, estado del objeto antes y
después de la ocurrencia del evento y otras variables relevantes.
Un reporte preliminar puede ser generado por un objeto que
contenga una cantidad mínima de información de monitoreo. Este
reporte puede ser enviado a otro objeto diferente, el cual puede
generar un reporte más completo.
17
C. Generación de Trazas
Para poder describir el comportamiento dinámico de un objeto o
grupo de objetos en un período de tiempo, los reportes de eventos y
status son almacenados cronológicamente como trazas de monitoreo.
“Una traza completa contiene todos los reportes de monitoreo
generados por el sistema desde el comienzo de la sesión de monitoreo.
Un segmento de traza es una secuencia de reportes recolectada en un
período de tiempo dado” (Mansouri y Sloman, p. 19).
Una traza puede tener como encabezado información general sobre
el proceso, como el período de tiempo de lectura de la información, la
identificación de los objetos de monitoreo presentados y otros (Van
Rick y otros, 1993). Las trazas de monitoreo, según Feldkuhn y
Erickson (1989) , pueden ser generadas por diferentes motivos:
- Propósitos de almacenamiento y análisis posterior: los reportes de
monitoreo pueden ser necesitados en el futuro para su
procesamiento, análisis y uso, los cuales pueden ser importantes
para propósitos de entonación. Estos archivos de trazas son
llamados usualmente históricos o logs.
- Capacidad de recursos: otra razón para crear estos trazas puede
ser la falta de poder de procesamiento para analizar e interpretar
los reportes de monitoreo a medida que se generan, o limitaciones
al momento de transmitir éstos a un agente externo. Esto ocurre
comúnmente cuando se realiza monitoreo en tiempo real.
18
- Velocidad de visualización: generación de trazas pueden ser
necesarias cuando el tiempo en que los reportes se reciben y
presentan es muy rápida para ser observada.
El acceso a estos reportes puede ser realizado por demanda,
utilizando una petición al sistema, o de acuerdo a condiciones pre -
establecidas. El acceso por demanda permite que el agente que
procesa los reportes lo haga con los recursos necesarios para
manejarlos, o cuando el tráfico de comunicación es bajo.
1.3.2 Procesamiento de Información de Monitoreo
En esta sección se consideraran algunas actividades de
procesamiento común que pueden ser realizadas con la información
generada. Un servicio de monitoreo “puede ofrecer ciertas unidades de
funcionalidad que pueden ser combinadas de diferentes formas, para
cumplir con los requerimientos de monitoreo”. (Mansouri y Sloman. 1995,
p. 27). La Figura 3 muestra una posible combinación y en ella se puede
observar como las funcionalidades de procesamiento están integradas
frecuentemente y son realizadas en diferentes lugares y etapas.
A. Generación y combinación de múltiples trazas
Para poder brindar diferentes vistas lógicas de las actividades del
sistema monitoreado durante un período de tiempo, las trazas de
monitoreo pueden ser construidas y ordenadas de distintas formas.
Según Feldkuhn y Erickson (1989), los atributos que pueden ser
19
usados como criterio de selección para determinar cómo las trazas de
monitoreo pueden ser procesadas incluyen los siguientes aspectos:
- Tiempo en el que fueron generados o recibidos.
- Prioridad o tipo de reporte.
- Tipo de objeto al cual el reporte se refiere.
Figura 3. Procesamiento de los reportes de monitoreo
Distribución
Trazas de monitoreo
Generación de múltiples trazas
Reportes de monitoreo
Filtros Criterios de filtros
Validación
Reporte de Validación
Reglas de Validación
Actualización de
B.D.
Trazas de monitoreo globales
Combinación
Trazas de monitoreo
20
Las trazas de monitoreo pueden ser generadas a partir de reportes de
eventos o estatus, a medida que éstos son creados o combinando los
mismos con trazas ya existentes y utilizando los factores
anteriormente nombrados, como el tipo de traza generada.
Una de las actividades más importantes de un sistema de monitoreo,
según Mansouri y Sloman (1995), es l a combinación de diferentes
trazas de monitoreo. Por ejemplo, el uso de la información de
monitoreo generado por diferentes objetos dentro del sistema, puede
ser utilizado para realizar una sola traza y así representar el
comportamiento global del sistema en un intervalo específico.
B. Validación de Información de Monitoreo
Otra actividad importante de monitoreo consiste en la validación y
chequeo de integridad de la información de monitoreo, a objeto de
asegurarse que el sistema ha sido monitoreado correctamente. Esta
actividad debe ser realizada en diferentes niveles: cuando un reporte
es recibido, su contenido puede ser chequeado para ver si es válido.
Por ejemplo, si la identificación del evento en un reporte es de un
evento esperado, los reportes inválidos, o no esperados, son
descartados. La validación de la información de monitoreo debe ser
realizada antes de actualizar la información en la base de datos. La
validación es realizada de acuerdo a ciertas reglas de validación y
pueden ser generados reportes de validaciones realizadas, por
ejemplo, reportes generados con información inválida en un intervalo
de tiempo específico.(Hofmann, 1992).
21
C. Actualización de la Base de Datos
La información válida de monitoreo puede ser utilizada para
mantener un modelo del status actual de sistema. Esta puede ser
utilizada por otros usuarios o agentes, a fin de examinar la
configuración del sistema, detectar fallas y aplicar los correctivos
necesarios al sistema.
D. Filtración de la Información de Monitoreo
Un sistema que está siendo monitoreado puede generar grandes
cantidades de información de monitoreo. Esto puede resultar en el
uso excesivo de recursos, como CPU, para la generación, recolección,
procesamiento y presentación de la información de monitoreo.
Además, los usuarios de la información pueden estar expuestos a
una c antidad masiva de i nformación que no pueden comprender.
Filtrar es “el proceso de minimizar la cantidad de data de monitoreo,
para que así los usuarios sólo reciban la data deseada con los niveles
de detalle relevantes para el propósito.”( Mansouri y Sloman, 1995, p.
27). Este proceso también es necesario por medidas de seguridad, ya
que pueden existir algunos usuarios sin autorización para acceder a
alguna información de monitoreo en particular.
1.3.3 Distribución de la Información de Monitoreo
Los reportes de monitoreo generados por los objetos deben ser
enviados a diferentes usuarios del sistema. El destino de los mismos
pueden ser usuarios humanos, otros objetos de monitoreo o entidades de
procesos. Los esquemas de distribución pueden variar de muy complejos a
22
muy simples. En nuestro caso, el servidor de monitoreo se encarga de
enviar la información a todos los usuarios.
Los clientes de los servicios de monitoreo realizan las peticiones para
recibir los estatus requeridos o los reportes de eventos, registrándose en
el sistema. Cada uno envía su identificación así como los reportes
requeridos. Esta información es utilizada para determinar si el cliente
está autorizado a recibir los reportes requeridos.
1.3.4 Presentación de la Información de Monitoreo
La generación, recolección y procesamiento de la información de
monitoreo debe ser presentada a los clientes en un formato que cumpla
con los requerimientos de la aplicación. Una buena interfaz con el usuario
debe permitirle especificar cómo desplegar la información, así como los
diferentes niveles de abstracción y tiempo de recolección de la misma.
2. MONITOREO EN BASES DE DATOS
Un sistema de base de datos es “un programa que permite a uno o
más usuarios crear y acceder data en una base de datos. El sistema
administra las peticiones de los usuarios (y de otros programas) para que
éstos no necesiten conocer dónde están físicamente localizados los datos.
El sistema se encarga de la integridad de la data (quiere decir que se
asegura que la misma pueda ser constantemente accedida y organizada de
23
forma consistente) y de la seguridad (asegurarse que sólo los que tengan
los privilegios adecuados puedan accederla” (Giordano 2001, p.1)
Monitorear la base de datos es la única forma de asegurarse que su
desempeño es estable. Aún cuando monitorear el ambiente de la base de
datos pueda revelar fallas críticas en el mismo, lo que se busca,
primordialmente, es descartar al ambiente como factor de problemas de
desempeño.
A continuación se presenta un enfoque de los diferentes aspectos que
deben ser monitoreados en un servidor de base datos y las estadísticas a
ser recolectadas.
2.1. Memoria y CPU
Según Aronoof y otros (1998), el hit ratio es el aspecto más
importante a monitorear en cuanto a memoria se refiere. El hit ratio es la
relación que existe entre las lecturas a memoria y las lecturas a disco. Por
esto, es necesario conocer cuáles son los diferentes tipos de acceso a data
que aumentan o disminuyen el hit ratio total.
La eficiencia del administrador de memoria cache se expresa por el
hit ratio en la base de datos. Diferentes autores coinciden que, en general,
un 90% de hit ratio a las horas pico de trabajo es un nivel aceptable. Esto
quiere decir que cada bloque leído en la memoria cache será leído 9 veces
antes de ser escrito de nuevo en disco (si ha cambiado, sino, simplemente
se remueve la misma).
Las estadísticas a recolectar en cuanto al uso de memoria y CPU
describen como el manejador de base de datos administra las áreas de
24
memoria. Existe relación entre las estadísticas sobre el procesamiento de
queries y éstas (ya que los queries leen y escriben data en memoria).
Términos
La definición de los términos a utilizar es presentada a continuación:
Bloque: unidad de transferencia de data entre la memoria principal
y disco. Un grupo de bloques de una sección de un espacio de
dirección de memoria forma un segmento.
Buffer: una dirección de memoria principal donde el administrador
de la memoria cache utiliza frecuentemente data leída de disco. El
buffer puede almacenar diferentes bloques. Cuando un nuevo bloque
es necesitado, el administrador de la memoria cache puede descartar
un bloque para remplazarlo con el necesitado.
Piscina de Buffer: una colección de buffers.
Memoria cache: todos lo buffers y piscinas de buffers.
En cuanto a CPU se refiere, es de gran importancia conocer el
desempeño del mismo ya que es la unidad central de procesamiento del
servidor de base de datos.
2.2. Queries
Un query puede ser visto como una pregunta que se realiza al
manejador de base de datos, sólo que éste tiene una estructura formal.
25
Los queries pueden ser divididos en queries de selección y de acción.
Los primeros realizan consultas de la información, mientras que los
segundos -los de acción-, realizan también operaciones como inserciones,
actualizaciones o eliminaciones de la data almacenada.
Es necesario conocer cuáles son las consultas que son realizadas al
servidor, ya que éstos pueden ocasionar fallas en el desempeño de la base
de datos.
2.3. Transacciones
Las transacciones son secuencias de intercambio de información que
son realizadas para cumplir un propósito específico y asegurar alguna
petición y mantener la integridad de la base de datos.
En una base de datos existen diferentes tipos de transacciones, como
rollbacks 1, los cuales son tratados de forma distintas, dependiendo de cada
manejador.
Adicionalmente a los tipos de monitoreo relacionados con el
manejador de base de datos, es necesario supervisar el ambiente en donde
opera la base de datos. Este ambiente usualmente incluye los
componentes del servidor, así como los componentes de la red en donde
realiza sus operaciones.
Según Gavin (2001), entre los componentes del servidor manejados
por el sistema operativo se encuentra: el uso del CPU, el manejo de
1 Proceso mediante el cual, se deshace algún proceso parcialmente completado, debido a alguna falla en la transacción relacionada.
26
memoria en la cual se ejecutan todos los procesos (del manejador de B.D. y
externos a éste), las compaginaciones a disco que ocurren cuando el
sistema de memoria virtual escribe páginas de memoria real en el disco ya
que la capacidad de memoria no es suficiente, E/S de red en donde se
maneja el flujo de entradas y salidas de tráfico, colisiones y errores, y las
lecturas y escrituras en disco.
Un sistema que se encargue de monitorear un servidor de base de
datos, debe expandirse para lograr el seguimiento de factores críticos del
servidor a través del tiempo y reportar los mismos para poder realizar
modificaciones necesarias en la configuración del manejador o del
ambiente en el cual se encuentra. Por ejemplo, se puede utilizar una
herramienta de monitoreo que supervise el porcentaje de espacio libre en
las tablas y su crecimiento, y así poder referir reportes de trazas con esa
información y, en un futuro, conocer cuando esas tablas no tendrán la
capacidad de soportar los requerimientos de espacio.
Por lo anteriormente expuesto se puede apreciar que las
herramientas de monitoreo, además de reportar el desempeño y posibles
eventos críticos, también pueden ayudar a “predecir el futuro”.
3. BALANCEO DE CARGAS
Los sistemas de base de datos paralelos deben procesar de forma
efectiva complejos queries en paralelo. Para ello, se hace necesario el
empleo de estrategias de balaceo de cargas que consideren el estado actual
del sistema, para así seleccionar el procesador adecuado para ejecutar los
queries.
27
El balanceo de cargas necesita un simple modelo, dependiendo de la
arquitectura del sistema de base de datos, y de algunos factores críticos
qué medir y así decidir. Estos factores críticos, como son el uso de
memoria, disco y CPU, se obtienen a través de data estática sobre los
recursos del sistema y su comportamiento. Por ello, estudiamos diferentes
arquitecturas de sistemas de bases de datos en paralelo, como son “nada
se comparte” (Shared Nothing) y “compartir disco” (Shared Disk).
3.1. Asignación de Cargas de Trabajo
El término se refiere a la asignación de las peticiones de cargas,
recursos físicos o lógicos. Dependiendo de la carga o el recurso, deben ser
considerados tipos especiales de problemas de asignación, como son la
asignación de queries o transacciones o asignación de memoria o
procesador. El balanceo de carga se refiere a “la asignación de cargas de
trabajo en sistemas distribuidos donde las peticiones de cargas deben ser
distribuidas entre diferentes nodos de procesamiento”.(Rahm. 1996, p. 2)
Uno de los problemas es encontrar un espacio de memoria que evite
que largos queries monopolicen el espacio de buffer disponible, causando
hit ratios inaceptables para transacciones que se estén realizando en
línea.
Según Rahm (1995), para el procesamiento de bases de datos
paralelas, la asignación de recursos de forma efectiva es uno de los
mayores problemas en balanceo de cargas. Este puede ser aplicado con
diferentes niveles de cargas, dependiendo del nivel de paralelismo. A un
28
nivel alto, existen inter-transaciones e inter-queries2 con ejecuciones
independientes entre sí. Este es el balanceo de cargas concerniente con la
distribución de transacciones y queries entre nodos de procesamiento.
Paralelismo de queries requiere formas adicionales de balanceo de cargas
para asignar subqueries a los nodos. Por lo tanto, el balanceo de cargas
debe ser dinámico, y las decisiones de asignación deben ser basadas en el
uso del sistema en tiempo real. De no ser así, no se puede lograr un uso
uniforme de todos los nodos debido a las variaciones constantes de los
estados del sistema.
3.2. Arquitectura de los Sistemas de Base de Datos Paralelos
Los Sistemas de Base de Datos Paralelos están comúnmente basados
en múltiples procesadores interconectados por una red local de alta
velocidad. Un soporte efectivo para las inter-transacciones e intra-
transacciones paralelas requiere el uso adecuado de paralelismo de los
dispositivos de E/S y el procesamiento en paralelo. Paralelismo en E/S
debe ser soportado por una asignación de la base de datos a través de
múltiples discos (declustering). Declustering soporta paralelismo de
intra-queries3 leyendo y escribiendo grandes cantidades de data procesada
por un query en paralelo desde ó a múltiples discos. Paralelismo en inter -
transacciones es soportado debido a que las peticiones independientes de
E/S en diferentes discos pueden ser realizadas en paralelo.
2 Ocurre cuando múltiples queries realizados por peticiones de múltiples usuarios pueden ser procesados al mismo tiempo. 3 Ocurre cuando un simple query es dividido en múltiples procesos (sub-queries), para así poder procesarlos en paralelo
29
Con respecto a procesamiento en paralelo, existen tres grandes
arquitecturas para sistemas de bases de datos en paralelo:
A. Shared Everything (SE Fig. 4a, compartir todo): se refiere al uso de
multiprocesadores para el procesamiento de base de datos. En este
caso, todos los procesadores trabajan en conjunto y comparten una
memoria principal y los dispositivos periféricos. Existe una sola copia
del código del sistema de administración de la base de datos que
puede ser ejecutada e n múltiples procesos para utilizar todos los
procesadores.
B. Shared Nothing (SN Fig. 4b, nada se comparte): estos sistemas
consisten en múltiples elementos de procesamiento, autónomos entre
ellos (EP). Cada uno posee una memoria principal privada y corre
copias separadas del sistema operativo, del sistema administrativo de
base de datos y otros softwares. Comunicación para inter-procesos se
realiza a través de mensajes transmitidos entre los nodos. Un PE
pude consistir en uno o más procesadores, cada nodo en un sistema
SN que puede ser un multiprocesador. La base de datos es repartida
entre los PE para que cada instancia del sistema de administración
de base de datos pueda acceder directamente la data de su partición.
Acceso a data no local, requiere la ejecución de queries distribuidos y
ejecución de transacciones.
C. Shared Disk (SD Fig. 4C, compartir disco): similar a SN, en múltiples
PE trabajando en conjunto. De todas formas, las instancias tienen
acceso a cualquier objeto de data. Se asume que cada nodo tiene
acceso a cualquier disco.
30
Figura 4. Arquitecturas de sistemas de bases de datos paralelos.
Las tres arquitecturas son soportadas por manejadores de base de
datos comerciales. Implementaciones de SD paralelas incluyen IBM
Database system y Oracle Parallel Server, los cuales soportan su propio
balanceo de cargas.
Procesador 1 Procesador n… Memória Principal 1
Memória Principal n
…
Red de alta velocidad
a) Compartir todo (SE)
Red de alta velocidad
Proc.
Mem.
Proc.
Mem.
Proc.
Mem.
EP1 EP2 EPn
…
b) Nada se comparte (SN)
Proc.
Mem.
Proc.
Mem.
Proc.
Mem.
EP1 EP2 EPn
…
Red de alta velocidad
c) Compartir Disco (SD)
Procesador 1 Procesador n… Memória Principal 1
Memória Principal n
…
Red de alta velocidad
a) Compartir todo (SE)
Red de alta velocidad
Proc.
Mem.
Proc.
Mem.
Proc.
Mem.
EP1 EP2 EPn
…
b) Nada se comparte (SN)
Proc.
Mem.
Proc.
Mem.
Proc.
Mem.
EP1 EP2 EPn
…Proc.
Mem.
Proc.
Mem.
Proc.
Mem.
EP1 EP2 EPn
…
Red de alta velocidad
c) Compartir Disco (SD)
31
3.3. Técnicas de Balanceo de Cargas
En general, las técnicas de balanceo de cargas se clasifican en:
estáticas, dinámicas y adaptables.
?? Estáticas: las decisiones de balanceo de cargas se toman a partir del
conocimiento previo del sistema y del comportamiento que tendrá con
la asignación de tareas.
?? Dinámicas: utilizan información del estado de rendimiento del
sistema distribuido para así proponer las decisiones de balanceo de
cargas.
?? Adaptables: son una clase especial de balanceo de cargas dinámico,
que tiene la capacidad de auto adaptarse según el comportamiento
del sistema y así poder cambiar las políticas de decisión de acuerdo a
los resultados que se obtengan.
3.4. Estrategias para el Balanceo de Cargas
Las ideas previas muestran que el soporte efectivo de balanceo de
cargas requiere estrategias dinámicas para determinar los procesadores
que consideren los factores críticos, como son CPU, memoria y disco. Para
los cuellos de botella causados por CPU, se pueden usar las
aproximaciones propuestas de acuerdo al uso del CPU y seleccionar los
procesadores menos utilizados para el procesamiento enlazado. Para
determinar el número óptimo de procesadores enlazados, en caso de
existir cuellos de botella por memoria, es necesario considerar la memoria
32
disponible en cada procesador individualmente. El Balanceo de cargas
dinámico es más complejo para situaciones en las que ocurren ambos
cuellos de botella, CPU y memoria, los cuales afectan a todos los
procesadores (sobrecarga global). Para situaciones de sobrecargas
parciales, cuando sólo algunos procesadores sufren de cuellos de botella,
son más efectivas las estrategias de balanceo de cargas que seleccionan los
procesadores menos utilizados para el procesamiento enlazado
A continuación se presentan diferentes estrategias aisladas,
destacadas en los trabajos realizados por Rahm y Marek (1995) p ara
balanceo de cargas, considerando políticas dinámica que basan sus
decisiones en el uso de CPU actual y la memoria disponible. Para este
propósito, un control de nodos designado es informado periódicamente por
el procesador sobre su utilización actual. Durante la ejecución del query,
información sobre el estado actual del CPU y la memoria es pedido por el
nodo de control para soportar el balanceo de cargas.
?? Aleatoria: esta estrategia selecciona los procesadores de forma
aleatoria. Con RANDOM se espera que las cargas de trabajo sean
repartidas equitativamente a todos los nodos disponibles. Como
RANDOM no considera el estado actual del sistema, representa una
aproximación estática.
?? Procesamiento en procesadores con menos uso de CPU: en esta
aproximación, se seleccionan los procesadores con menor uso de CPU.
Para este propósito, la información sobre los nodos utilizados es
actualizada en el nodo de control, para evitar que próximos queries
enlazados sean asignados a los mismos procesadores.
33
?? Procesamiento e n procesadores con menor uso de memoria: los
procesos son asignados a los nodos con mayor capacidad de memoria
disponible. Al igual que el anterior, el nodo de control es actualizado
con la información.
3.5. Particiones de Data
Para manejar data en paralelo de forma efectiva, la partición de la
misma debe asegurar tamaños equitativos para los subqueries. En
general, ello resulta una tarea difícil de lograr, debido a que la
distribución de los valores es generalmente poco uniforme para la
partición de los atributos, o porque la selección de los queries tampoco es
uniforme.
La partición resultante puede provocar grandes diferencias en los
tiempos de ejecución de los sub-queries, reduciendo la efectividad de los
intra-queries paralelos (ya que el tiempo de respuesta está determinado
por el sub-query más lento).
4. DISPOSITIVOS MÓVILES
En ocasiones, se dificulta la supervisión de los servicios que brindan
los servidores de base de datos, debido a que los encargados del manejo de
esta tecnología pueden encontrarse en una ubicación geográfica distante.
34
Por t al motivo, es necesario brindar los servicios de monitoreo a
través de dispositivos móviles, los cuales ofrecen la posibilidad de tener
acceso a diferentes aplicaciones de forma remota.
Estos dispositivos no poseen la misma capacidad que un computador
personal, por lo que se hace necesario conocer las ventajas y limitantes
que éstos poseen, para poder diseñar una herramienta que pueda ser
manejada utilizando estos dispositivos.
Según la revista PC Magazine (Abril 2001), los dispositivos móviles
remotos o inalámbricos son un nuevo reto para los desarrolladores Web,
ya que las aplicaciones a crear deben trabajar de forma óptima p ara
browsers tradicionales así como para estos nuevos dispositivos.
Antes de continuar, se define un dispositivo móvil como
“simplemente un dispositivo computacional que tiene una velocidad de
procesamiento y/o memoria limitada comparado con un servidor o PC.”
(Giguere. 2000, p. 4).
En este capítulo se destaca el impacto de la arquitectura de los
diferentes agentes móviles inalámbricos (PDA, celulares), para el acceso a
la información utilizando como medio la World Wide Web (WWW).
Para ello es necesario que la información presentada en formato web,
pueda ser adaptada a plataformas móviles tomando en cuenta las
restricciones de este ambiente.
4.1. Generando Información para Dispositivos Móviles
35
Al momento de generar i nformación para dispositivos móviles es
necesario tomar en cuenta una gran variedad de restricciones que existen
en este ambiente, de compararse a las computadoras personales (PC).
Estas restricciones influyen en cuanto a la información y la forma cómo
puede ser presentada la misma en estos dispositivos. Las restricciones
más importantes, según Gaedke y otros (1998, p. 206-210), se presentan a
continuación:
4.1.1 Poder Computacional
Los dispositivos móviles, comparados con las computadoras
personales, poseen una baja velocidad de CPU, lo cual limita su capacidad
de procesamiento y memoria y restringe la capacidad de manejar y
almacenar data no volátil. La tabla 1 muestra una comparación de
velocidad de CPU, memoria RAM y memoria ROM de diferentes PDA que
actualmente se encuentran en el mercado.
Dispositivo Velocidad CPU RAM ROM
3Com PilotIII 17 MHz 2M 2M
Apple MessagePad 20 MHz 2.5M 8M
Compaq C-Series 80 MHz 8M 16M
Casio Cassiopeia 49/80 MHz 4/8M 8M
Tabla 1. Poder computacional . (Fuente: www.saugus.net/PDA)
En la tabla 2 (página 40 de este trabajo) se puede observar que la
capacidad de memoria de los dispositivos móviles es inferior, de
compararse con la capacidad de un computador personal que puede llegar
a tener alrededor de los 128M o más. A pesar de esto, “los dispositivos
móviles tienen la capacidad de procesar gran variedad de aplicaciones,
como browsers, agendas y otros” (Imielinski y Badrinath. 1998, p. 6). La
36
Figura 1 muestra la comparación de una memoria RAM de un PC de
64MB y de una Compaq C-Series de 8MB de RAM.
0
10
20
30
40
50
60
70
PC Compaq
Cap
acid
ad d
e M
emo
ria
(MB
)
Figura 5. Comparación de capacidad de memoria
En cuanto a la capacidad de memoria, debemos tomar en cuenta la
capacidad de almacenamiento total de estos dispositivos. Esta es la “suma
de las capacidades de almacenamiento en línea o desconectado del
dispositivo.” La capacidad de almacenamiento en línea (online) es “la
cantidad de memoria disponible para almacenar data de aplicaciones en
procesamiento” y del sistema operativo. Esta se c aracteriza por estar
disponible de forma inmediata y puede o no ser persistente. Esta es la
memoria RAM del dispositivo. La capacidad de almacenamiento
desconectado (offline) es “la capacidad de almacenamiento persistentes de
módulos secundarios”, que se caracterizan por tener un acceso más lento y
normalmente no permiten el almacenamiento de data. Esta es la memoria
ROM del dispositivo. (Giguere. 2000, p. 7).
También se puede o bservar que estos dispositivos funcionan de
forma diferente a un computador personal, ya que utilizan la memoria
RAM para almacenamiento de data volátil como no volátil, a diferencia de
37
los PC, donde el RAM es utilizado para almacenar memoria volátil
únicamente.
Cuando comparamos la capacidad de almacenamiento total entre
un PC y un dispositivo móvil, la diferencia es más pronunciada. Digamos
que un PC incluye 10 GB de disco duro para almacenamiento. La Figura 6
muestra la diferencia entre ambos dispositivos. El PC pareciera que
tuviera casi infinita capacidad de almacenamiento en comparación con el
PDA.
Aún más resaltante es l a capacidad de memoria de un celular,
donde “500 bytes es una gran cantidad de memoria” (PC Magazine, Abril
2001) para estos dispositivos.
4.1.2 Consumo de Poder
Estudios realizados en estos dispositivos indican que la vida de la
batería y el consumo de poder de los dispositivos es una restricción
esencial en éstos. Según Imielinski y Badrinath (1998, p. 9), se espera que
“la vida de las baterías de estos dispositivos aumente sólo en un 20% en
los próximos 5 años”. Debido a esta restricción, los clientes móviles se
encuentran frecuentemente desconectados, por lo que las actividades en la
web, como envío de correos o consultas a base de datos, se realizan en
forma breve, separados por largos periodos sin conexión
38
0
2
4
6
8
10
12
PC Compaq
Cap
acid
ad t
ota
l de
alm
acen
amie
nto
(G
B)
Figura 6. Comparación de capacidad total de almacenamiento
4.1.3 Capacidad de Presentación
PDA y otros dispositivos móviles poseen pantallas bastante
pequeñas al ser comparadas con l as que presentan los computadores
personales. Los desarrolladores de aplicaciones Web enfrentan retos
especiales cuando tratan de presentar a los usuarios s u programas a
través de browsers de dispositivos como PDA y celulares. Las limitaciones
en cuanto al tamaño de pantalla son resaltantes debido a que la mayoría
de las páginas HTML son diseñadas para verse en monitores de
computadoras personales. Estas son diseñadas asumiendo que el usuario
puede ver gran cantidad de información de la página al mismo tiempo. En
dispositivos móviles, la pantalla “puede interferir con la comprensión del
usuario y resultando con una mayor actividad de movimiento en sentido
vertical” (Kaljuvee y otros. 2001, p. 6), en ocasión de observar toda la
información. La tabla 2 muestra una comparación de la resolución, y el
tamaño de pantalla de diferentes PDA que actualmente se encuentran en
el mercado.
39
Dispositivo Resolución Tamaño
3Com PilotIII 160x160 6x6 cm
Apple MessagePad 480x320 12,98x8,32 cm
Casio Cassiopeia 420x240 8x6 cm
Tabla 2. Propiedades de presentación (Fuente: ww
w.saugus.net/PDA)
Además de las restricciones en tamaño y resolución, la mayoría de
los dispositivos móviles sólo soportan gráficos de 2 bits. De allí que
imágenes para browsers de PC deben ser transformadas antes de ser
presentadas (Kaljuvee y otros, 2001).
4.1.4 Comunicación
Cualquier dispositivo móvil debe tener algún tipo de capacidad de
comunicación en red que le permita acceder a data externa y de la misma
forma bajar data a otro tipo de dispositivo, como un PC.
Según Giguere (2000), los dispositivos móviles pueden ser
clasificados en dos grupos, según su tipo de red de comunicación. Un
grupo incluye los dispositivos sin conexión permanente a una red, a los
cuales nos podemos referir como “dispositivos conectados ocasionalmente”.
La mayoría de los PDA soportan comunicación serial con un PC, por
ejemplo, a través de un cargador (o un simple cable) que está
permanentemente conectado a una computadora. El otro grupo incluye
dispositivos con conexión permanente a alguna red de comunicación, a los
40
cuales nos podemos referir como “dispositivos siempre disponibles”. Estos
dispositivos utilizan algún tipo de comunicación inalámbrica (como
infrarrojo o basada en radio) para intercambiar data, por ejemplo, los
celulares. Algunos dispositivos, como los PDA, pueden ser categorizados
en ambos grupos.
“La comunicación serial básica no es muy rápida, en un rango entre
los 19Kbps a los 33Kbps”. La comunicación inalámbrica por r adio se
encuentra “actualmente entre los 4Kbps a los 19Kbps”. (Giguere. 2000,
p.13).
5. XML Y SUS EXTENSIONES
La reciente proliferación de diferentes dispositivos computarizados,
como PDA y celulares, causan una diversidad equivalente al momento de
desarrollar aplicaciones Web que soporten los diferentes dispositivos.
Como consecuencia de ello, algunos desarrolladores generan diferentes
publicaciones de una misma aplicación, donde cada una soporta un
dispositivo específico.
De allí que diferentes autores afirman que el uso de XML como
herramienta para el manejo de información, es una solución para la
creación de aplicaciones en un ambiente heterogéneo.
5.1. Introducción a XML
Un documento de XML (eXtensible Markup Language) es una unidad
de información que puede ser observada en dos formas: como una
41
secuencia lineal de caracteres o como una estructura abstracta que es un
árbol de nodos”(Allamaruju y otros, 2001). XML especifica el contenido de
la información y su estructura (Kaplan y Lunn, 2000).
Para cambiar de la secuencia lineal a la es tructura abstracta, es
necesario el uso de un procesador de XML, también conocido como
parseador de XML.
Según McLaughlin (2000), el uso más popular para XML es la
creación de forma separada del contenido y la presentación. Definimos
contenido en “una aplicación como la data que necesita ser mostrada al
cliente y presentación como el formato de la data” (McLaughlin, 2000, p.
15).
Por ser un lenguaje para el manejo de información, es necesario el
uso de estándares asociados para su traducción y especificación. A
continuación se presentan, en forma breve, los diferentes acrónimos de
este lenguaje utilizados en la realización de este trabajo.
5.2. XSL (eXtensible Stylesheet Language)
Permite “transformar y traducir data en XML de un formato a
otro”(McLaughlin. 2000, p. 46). Este provee un mecanismo para definir
diferentes estilos de presentación que evita la duplicación de los
documentos XML para ser presentados diferentes formatos.
Actualmente, clientes utilizan diferentes tipos de browsers en
múltiples sistemas operativos, celulares que soportan WML (Wireless
Markup Language) y PDA que soportan diferentes variantes de HTML.
La ventaja principal del uso de XSL es que permite manejar el contenido
42
de forma universal en la aplicación, sin importar que tipo de cliente
solicita la misma. La presentación varia dependiendo del tipo de cliente
que realiza la petición.
5.3. Parseador XML
Este componente realiza l a tarea de tomar el documento XML y
asegurarse de que el documento esté bien estructurado, para que así
poder ser procesado y construido el árbol con la información encontrada en
el documento.
5.4. Java y XML
Diferentes autores coinciden en que el uso de Java como herramienta
de desarrollo, junto a XML para el manejo de data, es una buena opción
para aplicaciones orientadas a la Web.
Según Allamaraju y otros (2001), las principales razones son las
siguientes: ambas herramientas soportan diferentes plataformas de
trabajo y están listas para manejo en redes. La creación de clases de Java
que intercambien la data XML a través de componentes y aplicaciones en
una red, es una vía para que ambas herramientas puedan trabajar en
conjunto.
43
CAPÍTULO II
44
DESARROLLO DE LA HERRAMIENTA
Este capítulo presenta el proceso de desarrollo de la herramienta de
monitoreo de servidores de base de datos. Por ello, inicialmente se
presenta una visión general de la metodología implementada. Luego, se
plantean las investigaciones, hallazgos y consideraciones que permiten
definir los requerimientos de la herramienta y, por último, se presenta el
análisis y diseño que lleva al logro del objetivo planteado.
El desarrollo de la investigación se lleva a cabo utilizando la
metodología OO (orientada a objetos) basada en la notación UML (Unified
Method Language). El enfoque orientado a objetos da una nueva visión de
análisis y diseño de software. Actualmente, OMT («Object Modeling
Technique») de Rumbaugh, AOO (Object Oriented Design) de Booch y
Objectory de Jacobson, son los métodos orientados a objetos más
utilizados.
El método UML, constituye un signo de madurez en el desarrollo de
software que establece las bases de programación estándar. Esta
metodología ofrece la oportunidad de estar en un continuo ciclo de
mejoramiento del producto final; el ciclo comienza con una fase y termina
con un producto definido, con el cual comienza un nuevo ciclo para su
mejoramiento; así consecutivamente, hasta obtener el producto final
deseado. El producto a desarrollar va incrementado en calidad,
funcionalidad y presentación, de manera que vaya acercándose a lo que se
desea obtener.
45
El método de desarrollo expone las siguientes etapas, incluyéndose en
cada una de ellas la elaboración de diferentes modelos y diagramas
definidos por el sistema de notación UML:
?? Análisis de requerimientos.
Esta etapa incluye la concepción inicial del proyecto, las
investigaciones preliminares realizadas y la especificación de los
requerimientos. En ella se identifican las siguientes especificaciones:
1. Identificar casos de uso del sistema, los cuales muestran las
distintas operaciones que se esperan de una aplicación o sistema
y cómo se relacionan con su entorno (usuarios u otras
aplicaciones).
2. Dar detalles y describir cada uno de los casos de uso. Especificar
la información de entrada y salida de cada uno de ellos.
3. Desarrollar el modelo del mundo. Esta información se
representa en un diagrama de estructura estática de clases,
donde se identifican las clases, atributos, asociaciones,
mensajes, relaciones de herencia, restricciones del modelo y los
paquetes.
4. Definir una interfaz inicial del sistema, dibujando las pantallas
de interacción para los distintos actores-usuarios en un nivel de
mínimo detalle posible.
46
?? Diseño del sistema.
En esta etapa se define una subdivisión en aplicaciones del sistema y
la forma de comunicación entre los módulos existentes con los cuales
debe interactuar. En ella se identifica la arquitectura del sistema y se
definen los componentes, las aplicaciones y su ubicación. Una vez
concluido el proceso, se definen los mecanismos de ubicación.
?? Diseño Detallado.
En esta etapa se adecua el análisis a las características específicas
del ambiente de implementación y se completan las distintas
aplicaciones del sistema con los modelos de control, interfaz o
comunicaciones, según sea el caso. En ella se identifican las
siguientes especificaciones:
1. Elaboración del diagrama de clases de implementación (o
diagrama de clases de diseño).
2. Elaboración de los diagramas de secuencia a partir de las clases
definitivas.
3. Desarrollo de modelos de interfaz para enlazar las clases de
interfaz con las clases del modelo del mundo.
?? Implementación y pruebas.
En esta etapa se realiza la programación y desarrollo del sistema. Se
adecuan los estándares de las clases definidas al lenguaje de
programación, así como las pruebas y revisión del código.
47
Para la elaboración y documentación de los distintos modelos y
diagramas incluidos en la notación del lenguaje de modelado UML, se
emplea la herramienta de modelado visual Rational Rose.
Para las pruebas con los distintos dispositivos se utiliza el emulador
de celular Nokia WAP Toolkit y el de Palm Pilot Palm Emulator OS.
A continuación se presenta el desarrollo de las etapas
anteriormente nombradas.
1. Análisis de requerimientos
Esta etapa const ituye las investigaciones, planteamientos iniciales y
consideraciones desde el punto de vista de la administración y monitoreo
de un servidor de bases de datos, tomando en cuenta un ambiente
heterogéneo para el uso de una herramienta que cumpla con este
propósito.
1.1. Elaboración de casos de uso de alto nivel
Una forma de describir los requisitos iniciales del usuario durante la
etapa de análisis de requerimientos, es construir casos de usos del
sistema, descritos inicialmente por Jacobson en 1987 y actualmente
incorporados a la metodología de desarrollo de software OO basada en
UML.
Un caso de uso está formado por una serie de interacciones entre el
sistema y un actor (una entidad externa, ejerciendo un rol determinado),
que muestra una determinada forma de utilizar el sistema. Cada
48
interacción comienza con un evento inicial que el actor envía al sistema y
continua con una serie de eventos entre el actor, el sistema y posiblemente
otros actores involucrados.
Siguiendo la metodología de desarrollo expuesta, en la fase de
análisis de requerimientos se determinan los actores principales de la
herramienta de monitoreo, se identifican los casos de uso y se modela la
interacción entre los actores y el sistema, a través de la descripción de los
casos de uso de alto nivel y la construcción del diagrama de casos de uso
para el escenario global de la herramienta.
Primeramente se identifican como actores de la herramienta de
monitoreo el DBA (administrador de base de datos), el administrador del
sistema y el servidor de base de datos.
El DBA es el usuario quién puede realizar los procesos de monitoreo
de las diferentes estructuras físicas y lógicas del servidor de base de datos,
e incluye información de monitoreo actual, reportes de eventos y reportes
históricos, los cuales puede recibir el usuario directamente a través del
dispositivo donde realiza la petición o vía e-mail.
El administrador del sistema, por su parte, además de poder realizar
peticiones de información de monitoreo, se encarga de la configuración de
los procesos para detectar los eventos y el manejo de las alarmas, así
como la administración de la seguridad del sistema. Tal es el caso del
control de acceso de usuarios, manejo de bitácoras e históricos y acciones
referentes al manejo del servidor.
49
De igual forma, otro actor de la herramienta lo constituye el agente
de tareas quién, de la misma forma que el D BA, realiza procesos de
monitoreo de las diferentes estructuras físicas y lógicas del servidor de
base de datos, de manera periódica a lo largo del tiempo, para detectar
posibles eventos de interés que puedan ocurrir, y así reportar los mismos
a las personas interesadas.
Una vez identificados los actores, se definen los casos de uso de alto
nivel de la herramienta de monitoreo, los cuales describen los procesos de
una forma muy breve y permiten elaborar el diagrama de casos de uso
para el escenario global del sistema. En la Figura 7 se muestra el
diagrama de casos de uso de alto nivel elaborado para el escenario de la
herramienta de monitoreo -escenario que comprende la totalidad del
sistema
Figura 7. Caso de uso de alto nivel de la herramienta de monitoreo
Man ten im ien to de Usua r i os
R e p o r t e s d e D e s e m p e ñ oD B A
Agen te de Ta reas
Admin i s t rado r de l S i s t e m a
M o n i t o r e o
50
Se identifican los siguientes casos de uso, que modelan la interacción
del DBA con la herramienta:
?? Monitoreo. Este caso de uso consiste en el diagnóstico del
comportamiento de las estructuras del servidor, a través de la
visualización de los diferentes estados de cada uno de los
componentes del servidor de base de datos, como pueden ser CPU,
memoria y otros, así como la configuración de los atributos del
mismo. Además, el manejo de los eventos de interés, realizando
las alertas necesarias para efectuar las acciones correctivas por
parte del DBA.
?? Reportes de Desempeño. Este caso de uso consiste en la
visualización de las diferentes estadísticas generadas por el
sistema, que muestran las acciones realizadas, tales como errores,
notificaciones y otros, además del comportamiento del servidor de
distintas formas, dependiendo del tipo de petición. Estas pueden
mostrarse en forma de históricos, eventos de interés, gráficas u
otros, dependiendo del dispositivo en donde se realiza la petición.
Por otro lado, observamos en la figura 7, como el administrador
del sistema, además de poder realizar el rol del DBA, interactúa
con otro caso de uso de alto nivel de la herramienta de monitoreo,
que se identifica a continuación:
?? Mantenimiento de Usuarios. Este caso de uso consiste en la
configuración y manejo de los diferentes usuarios que intervienen
en el sistema, como el manejo de perfiles y otros aspectos
concernientes a la seguridad del sistema.
51
1.2. Elaboración de los casos de uso expandidos
Esta fase consiste en el refinamiento de los casos de uso de la
herramienta de monitoreo, a través de la elaboración de los casos de uso
expandidos. Estos últimos describen de una manera precisa la interacción
entre los actores y el sistema, incluyéndose para cada caso de uso una
secuencia típica de eventos, la cual narra paso a paso cómo se realiza esta
interacción.
Una vez especificados los casos de uso de alto nivel de la herramienta
de monitoreo en la fase de análisis de requerimientos, se modela de una
manera más detallada la interacción entre los actores -DBA,
administrador del sistema y agente de tareas- y la herramienta. Para ello,
se proponen como escenarios particulares los casos de uso de alto nivel de
la herramienta de monitoreo y se obtienen nuevos casos de uso a partir de
cada uno de estos escenarios.
Para realizar los casos de uso expandidos, se sigue la documentación
de los casos de uso planteada por Schneider y Winters (1998), como se
detalla a continuación
Nombre del caso de uso: breve descripción del mismo. Usualmente un
párrafo o menos.
Actores: una lista de los actores que se comunican con el caso de uso
planteado.
Prioridad: la importancia del caso de uso para el proyecto.
52
Precondiciones: una lista de condiciones que deben cumplirse antes
de que el caso de uso se inicie.
Poscondiciones: una lista de condiciones que deben cumplirse cuando
el caso de uso finalice, sin importar que escenario se ejecute.
Casos de uso utilizados: si el caso de uso utiliza otro caso de uso, se
lista.
Pasos del Evento: esto puede ser el camino básico a seguir por el caso
de uso o los caminos alternativos, o el escenario principal.
Según esta documentación, a continuación se presentan los casos de
uso expandidos de la herramienta de monitoreo para el caso de uso de alto
nivel de monitoreo.
?? Monitoreo por petición:
Monitoreo realizado por petición del DBA, para diagnosticar el
desempeño del servidor de Base de datos en un momento dado. El
usuario puede especificar el tipo de estructura física o lógica que
desea monitorear.
Actor: DBA.
Prioridad: Alta.
Precondiciones:
- Autenticación.
Poscondiciones:
- Reporte del monitoreo solicitado
.
53
Pasos del Evento:
1. El DBA se conecta al sistema introduciendo una dirección URL
2. El sistema despliega la pantalla de autenticación.
3. El DBA realiza la autenticación.
4. Si autenticación Válida:
a) Se despliega menú de opciones según su perfil
b) Se selecciona opción de monitoreo
c) Se despliegan las opciones de monitoreo de Sistema Operativo
o Manejador de Base de Datos
d) Si se selecciona Monitoreo de sistema operativo:
i. Se despliegan las siguientes opciones de monitoreo: uso
de CPU, disponibilidad de memoria, uso de I/O, uso de
memoria SWAP, uso de discos, uso de ancho de banda.
ii. Al seleccionar la opción de monitoreo deseada:
- Sistema realiza la petición de monitoreo
- Se almacenan las acciones realizadas en la bitácora.
iii. Si existe un error se almacena en la bitácora y se
despliega en pantalla, sino:
iv. Se despliega el último reporte de monitoreo realizado
en pantalla.
v. Se despliega la opción para actualizar la información
de monitoreo desplegada.
e) Si se selecciona Monitoreo del manejador de base de datos:
i. Se despliegan las siguientes opciones de monitoreo:
uso de CPU, uso de memorias, uso de I/O,
Procesamiento de Queries, transacciones.
54
ii. Al seleccionar la opción de monitoreo deseada:
- Sistema realiza la petición de monitoreo
- Se almacenan las acciones realizadas en la bitácora
de sesiones.
iii Si existe un error se almacena en l a bitácora y se
despliega en pantalla, sino:
iv Se despliega el ultimo reporte de monitoreo realizado
en pantalla.
v Se despliega la opción para actualizar la información
de monitoreo desplegada.
?? Monitoreo periódico:
Monitoreo realizado por el agente de tareas, el cual se realiza en
forma periódica para llevar un seguimiento del desempeño del
servidor de base de datos a lo largo del tiempo y detectar eventos de
interés para así notificar los mismos.
Actor: Agente de tareas
Prioridad: Alta
Poscondiciones:
- Estadísticas del desempeño del servidor de base de datos
- Eventos de interés
Casos de uso utilizados:
- Notificación de eventos
55
Pasos del evento:
1. Agente de tareas realiza petición de monitoreo
2. El sistema realiza petición de desempeño al servidor de base de
datos
3. La información de monitoreo de las estructuras físicas o lógicas
(como uso de CPU, hit ratio, y otros) que se desean consultar
posteriormente en forma de históricos, son almacenados en la
base de datos de la herramienta de monitoreo.
4. Se compara la información de monitoreo generada con los
estándares de rendimientos establecidos.
5. Si ocurre un evento de interés:
a. Se realiza una notificación de evento.
b. Se almacena el evento en la bitácora.
?? Notificación de Eventos:
Al surgir un evento de interés detectado por el monitoreo periódico,
se realizan notificaciones de este evento a los actores interesados en
él, además, se genera un reporte cada vez que ocurra un evento de
interés, el cual es enviado de forma automática por el sistema a las
personas interesadas en dichos eventos.
Actor: DBA
Prioridad: Alta
Precondiciones:
- Monitoreo periódico
- Evento de interés
Poscondiciones:
- E-Mail con reporte del evento
56
Casos de uso utilizados:
- Monitoreo Periódico
- Reportes de Desempeño
Pasos del evento:
1. Se realiza el reporte del evento de interés.
2. Se verifican los destinatarios interesados en el evento.
3. Se genera el reporte con el siguiente contenido:
a) Atributos del evento de interés (nombre, fecha, valor y otros)
b) Estándares del evento de interés ocurrido
c) Atributos de i nformación de monitoreo relacionado con el
evento.
4. Se envía el reporte del evento de interés vía E-Mail a los
destinatarios.
5. Si existe un error, éste se almacena en la bitácora, sino
6. Se almacena la notificación en la bitácora.
?? Configuración Monitoreo:
En este caso de uso, se configura la frecuencia con la cual se
realizarán los monitoreos periódicos al servidor de Base de datos, así
como los estándares de rendimiento de los diferentes eventos
manejados por la herramienta de monitoreo.
Actor: Administrador del sistema
Prioridad: Baja
Precondiciones:
- Usuario autorizado
57
Poscondiciones:
- Atributos del monitoreo periódico y estándares de rendimiento
Pasos del evento:
1. El administrador se conecta al sistema introduciendo una
dirección URL
2. El sistema despliega la pantalla de autenticación.
3. El administrador realiza la autenticación.
4. Si autenticación Válida:
a. Se despliega menú con las opciones de administrador
b. Se selecciona la opción de configurar monitoreo
c. Se despliega el menú de opciones
d. Si se selecciona modificar estándares:
i. Sistema despliega los estándares
ii. Se selecciona el estándar que se desea modificar
iii. Se modifica el estándar seleccionado
iv. Se almacenan los cambios en la base de datos
v. Se despliegan los nuevos valores del estándar modificado
e. Si se selecciona configurar frecuencia del monitoreo periódico:
i. Sistema despliega los atributos y frecuencias de
monitoreo
ii. Se selecciona la frecuencia que se desea modificar
iii. Se modifica la frecuencia seleccionada
iv. Se almacenan los cambios en la base de datos
v. Se despliegan la nueva frecuencia y los atributos del
monitoreo seleccionado.
En la Figura 8 se muestra el diagrama de casos de uso expandidos
para el caso de uso de alto nivel monitoreo.
58
Se identifican los siguientes casos de uso expandidos para el caso de
uso de alto nivel Reportes de Desempeño .
?? Reporte Desempeño del Servidor:
Se reporta el desempeño de las distintas estructuras físicas o lógicas
del servidor de base de datos, dado un intervalo de tiempo deseado.
Ejemplo: una gráfica con el desempeño del uso del CPU durante una
semana u otro intervalo solicitado.
Figura 8. Caso de uso expandido de monitoreo
Actor: DBA
Prioridad: Media
Precondiciones:
- Existencia del intervalo de tiempo en los históricos
Monitoreo por Petición
Agente de Tareas
Monitoreo Periódico
Extiende a
Notif icación de Eventos
DBA Administrador del Sistema
Configuración Monitoreo
59
Poscondiciones:
- Reportes
Pasos del evento:
1. El DBA se conecta al sistema introduciendo una dirección URL
2. El sistema despliega la pantalla de autenticación.
3. El DBA realiza la autenticación.
4. Si autenticación Válida:
a. Se despliega menú de opciones según el perfil
b. Se selecciona opción de reportes
c. Se selecciona el tipo de reporte deseado
d. Se introduce el intervalo de tiempo deseado para el reporte
e. El sistema recolecta los datos de los históricos dependiendo
del tipo de reporte y el intervalo de tiempo deseado.
f. Se despliega el reporte en pantalla
g. Se despliega la opción para enviar el reporte por E-mail.
Reportes del sistema:
Son los reportes generados a partir de la bitácora del sistema para
consultar el uso de la herramienta.
Actor: Administrador del sistema
Prioridad: Baja
Precondiciones:
- Usuario autorizado
Poscondiciones:
- Reportes del sistema
60
Pasos del evento:
1. El administrador se conecta al sistema e introduciendo una
dirección URL
2. El sistema despliega la pantalla de autenticación.
3. El administrador realiza la autenticación.
4. Si autenticación Válida:
a) Se despliega menú con las opciones de administrador
b) Se selecciona la opción de reportes de sistema
c) Se despliegan las opciones de reporte las cuales incluye:
i. Reportes de eventos: contiene los eventos de interés
ocurridos a lo largo del tiempo.
ii. Reportes de errores: contiene los errores ocurridos en
el sistema a causa de una operación no realizada o no
completada.
iii. Reportes de Notificaciones: contiene los
destinatarios que recibieron notificaciones de eventos
de interés.
iv. Reporte de Sesiones: contiene información del acceso
de los usuarios al sistema.
d) Se despliega el reporte en pantalla
e) Se despliega la opción para enviar el reporte por E-Mail.
En la Figura 9 se muestra el diagrama de casos de uso expandidos
para el caso de uso de alto nivel Reportes de Desempeño .
61
Figura 9. Caso de uso expandido de Reportes de Desempeño
?? Mantenimiento de usuarios:
El administrador del sistema crea, modifica o elimina el perfil de los
usuarios, lo cual incluye el manejo de sus datos, clave de acceso y
permisos para el monitoreo o configuración del sistema.
Actor: Administrador del sistema
Prioridad: Media
Precondiciones:
- Usuario autorizado
Poscondiciones:
- Usuarios con su perfil.
Pasos del evento:
1. El administrador se conecta al sistema introduciendo una
dirección URL
2. El sistema despliega la pantalla de autenticación.
3. El administrador realiza la autenticación.
DBAReportes de Desempeño del
Servidor
Administrador del Sistema
Reportes del Sistema
62
4. Si autenticación Válida:
a. Se despliega menú con las opciones de administrador
b. Se selecciona la opción de mantenimiento de usuario
c. Se despliega menú con las opciones de mantenimiento de
usuarios
d. Si se selecciona crear usuario:
i. Se introducen los atributos del usuario, los cuales
incluyen: nombre, apellido, clave, E-Mail, teléfono.
ii. Se le asigna un perfil de usuario.
iii. Se almacena el usuario creado en la base de datos del
sistema.
e. Si se selecciona modificar usuario:
i. Se despliegan los usuarios existentes en el sistema
ii. Se selecciona el usuario a modificar
iii. Se modifican los atributos o perfil del usuario
iv. Se almacenan los cambios en la base de datos
v. Se despliegan los nuevos valores del usuario
modificado
f. Si se selecciona eliminar usuario:
i. Se despliegan los usuarios existentes en el sistema
ii. Se selecciona el usuario a eliminar
iii. Se desactiva el usuario en la base de datos
La especificación de un caso de uso expandido consiste en agregar al
caso de uso una sección conocida como secuencia típica de eventos, la
cual describe paso a paso la interacción entre el actor (o actores) y el
sistema. De esta forma, se elaboran los casos de uso expandidos para
cada nuevo escenario constituidos por los casos de uso de alto nivel de
la herramienta de monitoreo.
63
En la figura 10 se presenta la totalidad de los casos de uso de la
herramienta de monitoreo y la interacción entre ellos y con los
actores.
.
Figura 10. Casos de uso expandidos de la herramienta de monitoreo
Figura 10. Casos de uso expandidos de la herramienta de monitoreo
1.3. Modelo conceptual o modelo del mundo
Una de las actividades principales en la etapa de análisis de
requerimientos es la creación de un modelo conceptual (o modelo del
mundo real) para los casos de uso definidos. Para ello, se debe
Monitoreo por Pet ic ión
Notif icación de Eventos
Reportes de Desempeño del Servidor
DBA
Mantenimiento de Usuar ios
Conf iguración MonitoreoReportes del Sistema
Administrador del Sistema
Agente de Tareas
Monitoreo Periódico
Monitoreo por petición
64
descomponer el sistema en objetos o conceptos individuales y modelar las
relaciones entre los mismos.
Durante la elaboración del modelo del mundo, el modelador se debe
abstraer de aspectos de implementación y sólo enfocarse en reconocer los
conceptos u objetos del mundo relevantes para el sistema que se quiere
construir. Para ilustrar el modelo del mundo se emplea la notación de
diagramas de estructura e stática, provista por el sistema de notación
UML, despreciándose de las operaciones o métodos de los objetos.
Continuando con la metodología propuesta, una vez elaborado el caso
de uso de alto nivel de la herramienta de base de datos, se elabora el
modelo conceptual o modelo del mundo del sistema. Para ello se abstraen
los conceptos más significativos dentro de las descripciones de los casos de
uso y se proponen los mismos como objetos que se incluyen en el modelo
del mundo. Luego se agregan los atributos para cada objeto y se
determinan las relaciones entre objetos. Este modelo se va refinando a
medida que se identifican nuevos conceptos en la etapa de diseño que se
habían considerado anteriormente.
Para identificar los conceptos u objetos significativos a partir de los
casos de uso, se emplea la siguiente estrategia: primero, se identifican los
sustantivos del enunciado del problema y de las descripciones de los casos
de uso, los cuales pasan a ser candidatos a clases de modelo del mundo.
65
DOMINIO Herramienta de monitoreo
SUSTANTIVOS - DBA, usuario, perfil ? DBA - agente de tareas ? Agente de tareas - administrador ? Administrador de Sistema - Desempeño, Reporte de monitoreo, información de
monitoreo ? Reporte de monitoreo - servidor de Base de datos ? Servidor de base de
datos a ser monitoreado , compuesto de Sistema operativo y Manejador de Base de datos
- Sistema, la herramienta de monitoreo, herramienta., sistema ? Herramienta de monitoreo
- Pantalla, menú, menú de opciones ? Pantalla de opciones (pantalla de autenticación, pantalla de administrador, pantalla de reportes, pantalla de autenticación, pantalla de opciones de monitoreo, etc.)
- opciones, opciones de monitoreo, estructura física o lógica, ? estructuras a monitorear (CPU, Memoria, I/O, memoria SWAP, discos, ancho de banda, Procesamiento de Queries, Transacciones)
- eventos de interés ? eventos de interés - petición de monitoreo, Petición ? Petición de
monitoreo - bitácora, bitácora del sistema ? bitácora - Eventos de bitácora (Errores, sesiones,
notificaciones, eventos de interés) - Estadísticas del desempeño, seguimiento del
desempeño, Históricos ? Históricos de -desempeño
- estándares de rendimientos, estándares ? Estándares
- Reportes de Desempeño - frecuencias de monitoreo, intervalo de tiempo de
monitoreo ? frecuencia de monitoreo - Destinatarios ? Destinatarios interesados en el
evento ocurrido - Notificación
Tabla 3. Lista de posibles conceptos u objetos dentro del dominio de la Herramienta de monitoreo. Fuente: Elaboración propia.
66
Luego, se identifican los verbos, los cuales forman los posibles
métodos de las clases anteriormente seleccionadas. Para finalizar, se
identifican los adjetivos del enunciado del problema y de los casos de uso,
los cuales forman los posibles atributos de las clases y métodos
seleccionados.
En las tablas 3, 4 y 5 se presenta la lista de posibles conceptos u
objetos obtenidos utilizando esta estrategia.
DOMINIO Herramienta de monitoreo
VERBOS - Monitorear , realizar petición de monitoreo, Diagnosticar: clase Diagnosticador
- Especificar, seleccionar opción: clase pantalla - Autenticar : clase Auntenticador - Conectar: clase Diagnosticador - Desplegar menú: clase Pantalla - Almacenan acciones realizadas, Almacenar error
en bitácora, almacenar eventos en bitácora: clase Bitácora
- Actualizar la información de monitoreo: clase Pantalla
- Realizar monitoreo de forma periódica: clase Agente de Tareas
- Almacenar seguimiento de rendimiento: clase Histórico
- Detectar eventos de interés : clase Estándares - Notificar eventos de interés, Generar notificación:
clase Notificador - Consultar históricos, Consultar datos histórico:
clase Histórico - Verificar destinatarios: clase Notificador - Enviar E-mail: clase Notificador - Crear, modificar, eliminar perfil de usuarios: clase
Gestor de usuarios - Configurar frecuencia: clase Calendario Monitoreo - Modificar estándares: clase Estándar - Generar reportes: clase Generador Reportes
Tabla 4. Lista de candidatos a métodos. Fuente: Elaboración Propia
67
DOMINIO Herramienta de monitoreo
ADJETIVOS - tipo de monitoreo - tipo de reporte - opciones de monitoreo - opciones del menú - tipo de bitácora - frecuencia de monitoreo - datos del usuario
Tabla 5. Lista de candidatos a atributos . Fuente: Elaboración Propia
Consecutivamente, se elabora una lista por categorías de los
conceptos identificados en los casos de uso de la herramienta de
monitoreo. Estos son resaltados en las tablas 3, 4 y 5.
La elaboración del modelo del mundo constituye un paso importante
en la etapa de análisis de requerimientos de la herramienta de monitoreo.
El modelo conceptual permite descomponer el sistema en conceptos u
objetos individuales y plasmar la manera en cómo se relacionan estos
objetos, permitiendo así depurar la conceptualización del sistema iniciada
durante el desarrollo de los casos de uso.
1.4. Especificación inicial de la interfaz de usuario
Una vez identificados los casos de uso de alto nivel y desarrollado el
modelo del mundo, se posee suficiente información para ir definiendo una
interfaz inicial del sistema, donde se presenta cómo los actores
interactuarán con el sistema que se quiere construir.
De esta forma, para finalizar la etapa de análisis de requerimientos
de la herramienta de monitoreo, se definen las distintas pantallas que
68
formarán la herramienta y se modela la secuencia de navegación a través
de las mismas. Para esto, se toma en cuenta el rol de los diferentes actores
y los distintos escenarios del sistema, modelados a través de los casos de
uso y los elementos del modelo del mundo.
Se definen las siguientes pantallas a través de las cuales el DBA
interactúa con la herramienta de monitoreo:
?? Autenticación: En esta pantalla, común para el DBA como
para el administrador, el usuario ingresa su E-Mail y su
clave y se despliegan las opciones según su perfil.
?? Monitoreo por petición: En esta pantalla, el usuario
selecciona qué desea monitorear del servidor, para luego
desplegarse el reporte con la información solicitada.
?? Reportes: En esta pantalla, el usuario puede seleccionar
reportes de las diferentes trazas almacenadas a lo largo del
tiempo.
Por otra parte, se identifican las siguientes pantallas a través de las
cuales el administrador interactúa con el sistema:
?? Opciones de Administración: En esta pantalla se despliegan las
opciones de administración, donde se puede seleccionar la
configuración de los tiempos del monitoreo periódico, los
estándares, así como el mantenimiento de usuarios que incluye
la creación, modificación y eliminación de éstos.
69
Figura 11. Top-down de pantalla
Para modelar la forma cómo se realiza la navegación por las distintas
pantallas de la herramienta de monitoreo, la Figura 11 ilustra un
diagrama de navegación de pantallas o top-down de pantallas.
2. DISEÑO DEL SISTEMA
Una vez finalizada la etapa de análisis de requerimientos de la
herramienta de monitoreo, el siguiente paso es definir una subdivisión en
aplicaciones del sistema (si es lo suficientemente grande) y la forma de
comunicación con los sistemas ya existentes con los cuales debe
interactuar.
Autenticación
Monitoreo por Petición
Sistema Operativo
Manejador de Base de Datos
Reporte de Eventos
Opciones de Administración
Configurar Monitoreo
Reporte de Desempeño
Reportes
Reporte del Sistema
Mantenimiento de Usuarios
Crear Usuario
Modificar Usuario
Eliminar Usuario
Reportes de eventos de interés
(via email)
Autenticación
Monitoreo por Petición
Sistema Operativo
Manejador de Base de Datos
Reporte de Eventos
Opciones de Administración
Configurar Monitoreo
Reporte de Desempeño
Reportes
Reporte del Sistema
Mantenimiento de Usuarios
Crear Usuario
Modificar Usuario
Eliminar Usuario
Reportes de eventos de interés
(via email)
70
En este sentido, la etapa de diseño del sistema de la herramienta de
monitoreo busca definir componentes del sistema, las aplicaciones y su
ubicación, así como definir los mecanismos de comunicación e ntre los
mismos.
2.1. Arquitectura de la Herramienta
La herramienta fue desarrollada en un ambiente de arquitectura
WEB, cuya principal función es separar la presentación de la lógica de
aplicación, para así poder generar un contenido dinámico de una manera
sencilla y útil. Funciona bajo el modelo de aplicación “cliente/servidor”,
donde hay un servidor en espera de peticiones de múltiples clientes, en
ocasión de prestar diversos servicios de red.
Se implementó esta arquitectura porque la información de
monitoreo, como fue señalado anteriormente, es dinámica. Esto significa
que la información que se genera está en un continuo cambio y se
presenta por medio de la Web a distintos tipos de dispositivos; por este
motivo surge la necesidad de manejar la presentación
independientemente del tipo de dispositivo que realice la petición.
Se implementa una arquitectura WEB de 3 capas, las cuales son:
1. Presentación.
2. Lógica de la aplicación.
3. Data.
La distribución de las capas a través de la red es presentada en la
figura 12.
71
La capa de presentación es la interfaz gráfica del cliente, la cual
permite realizar peticiones al sistema y recibir la información de forma
adecuada. Su principal responsabilidad es la de presentar la data según el
formato de presentación soportado por el cliente. Esta capa está ubicada
del lado del cliente y consta de los programas que permiten procesar el
formato de presentación requerido, por ejemplo, un explorador WEB ya
sea en un PC o dispositivo móvil.
Figura 12. Arquitectura 3-capas. Distribución de las capas a través de la
red.
La capa de aplicación contiene la lógica de cómo funciona el sistema
y está formada por los programas que realizan el procesamiento de la
información. Su responsabilidad es procesar la data según el
funcionamiento del sistema y así servir de interfase entre la data y la
presentación. Otra funcionalidad muy importante es la de servir de
interfase a otras capas, haciendo así que el sistema tenga una
arquitectura de n-capas. Estas nuevas capas pueden ser otros sistemas o
aplicaciones fuera del sistema que interactúan con éste. Esta capa esta
ubicada del lado del servidor, el cual recibe las peticiones.
Presentación
Aplicación
Data
Cliente HTML Cliente WML Cliente con cualquier otro formato
Interface - Aplicación Interface - Aplicación Interface - Aplicación
Otro Sistema o CapaBase de DatosXML
Conectividad BD
72
La capa de data es donde se almacena toda la información, ya sea
en bases de datos, archivos de texto, archivos XML u otros formatos. Su
responsabilidad es almacenar y proveer la data de forma eficiente a la
capa de aplicación sin importar el formato o la manera en que esté
almacenada. Esta capa puede estar situada en otro servidor o en
servidores distribuidos de base de datos distintos al servidor de peticiones.
En esta arquitectura, cada capa puede tener un lenguaje de
programación distinto a las otras, sin que se vean afectadas entre ellas.
Además, ello permite que el sistema pueda evolucionar cambiando los
lenguajes o lógicas de una capa sin afectar a la otra o al funcionamiento
del sistema.
Figura 13. Arquitectura de una aplicación Web.
La figura 13 muestra una típica arquitectura de una aplicación
Web, primero se recolecta data de la petición del usuario, luego se envía
una petición al servidor Web; el servidor Web envía la petición al
contenedor de programas para así correr el programa requerido por el
Servidor
Servidor WEB
Cliente Programas del lado del servidor
Aplicación
DBMS
1ra capa
2da capa
3ra capa
Petición
Respuesta
Servidor
Servidor WEB
Cliente Programas del lado del servidor
Aplicación
DBMS
1ra capa
2da capa
3ra capa
Petición
Respuesta
73
usuario. Después se realiza el empaquetamiento de la data para luego ser
presentada por la aplicación del cliente. Por último, se envía la data para
que la aplicación del cliente la procese y la muestre en el formato
soportado por el cliente.
Componentes de la Arquitectura Web
?? Cliente: el cliente es quién realiza la petición de información al
servidor. Es el usuario en una relación cliente/servidor, quién utiliza
un programa que se encarga de presentar la data en un formato
definido.
?? Petición: el cliente realiza una petición http al servidor para solicitar
algún tipo de servicio o acceso a información. Generalmente la petición
consiste de un URL al que se quiere acceder, el encabezado de la
petición (información del explorador, tipo y tamaño de la petición), y
opcionalmente una forma que envíe variables con información de la
petición.
?? Servidor Web: se encarga de recibir las peticiones del cliente a través
del protocolo http. En caso de que exista una petición de ejecución de
programas, el servidor Web entrega dicha petición al contenedor de
programas.
?? Contenedor: es donde se encuentran y ejecutan los programas de
aplicación del lado del servidor, el contenedor se encarga de ejecutar
los programas de manera correcta. Se comunica con el Web Server
para manejar las peticiones, también tiene comunicación con el
manejador de la data.
74
?? DBMS: es el manejador de base de datos que contiene la data del
sistema que servirá para brindar información a las peticiones de los
clientes. Un manejador de base de datos es un ejemplo común, pero la
data también puede estar en archivos de texto o archivos XML para
brindar portabilidad entre sistemas y no depender del tipo de
manejador de base de datos.
Módulos de la aplicación
Tomando en cuenta que la herramienta tendrá como función el
monitoreo del rendimiento de desempeño de servidores de base de datos, y
tomando en cuenta el modelo de monitoreo genérico que se presento en el
marco de referencia (página 14), el sistema desarrollado se dividió en 4
módulos: generación, procesamiento, distribución y presentación de la
información de monitoreo.
?? Módulo de generación de información: son todos los procesos de
recolección y generación de información de monitoreo. Eventos
importantes son detectados al ser observado el comportamiento en el
tiempo del servidor a monitorear, y reportes de status y eventos son
generados Esto incluye la conectividad y monitoreo a los servidores de
base de datos para medir su rendimiento y también el almacenamiento
de la información en la base de datos del sistema en forma de
históricos.
?? Módulo de procesamiento de la información: en este módulo se realiza
el procesamiento de la información de monitoreo. Debe brindar
funcionalidades comunes como combinación de históricos, validación,
actualización y filtración de la información de monitoreo, se crean los
75
reportes, se realizan las comparaciones de desempeño, y otros cálculos
necesarios para el procesamiento de la información de monitoreo.
?? Módulo de distribución: es donde se realiza las distribuciones de las
peticiones según su tipo, y luego de que la petición es atendida se
realiza la distribución de reportes por medio de la Web o correo
electrónico a todos los usuarios interesados.
?? Módulo de presentación: La información recolectada y procesada es
presentada a los usuarios en una forma apropiada, según el tipo de
formato que soporte el dispositivo con que hicieron la petición.
La figura 14 presenta una gráfica en donde se identifica el alcance
de cada módulo dentro de la arquitectura de aplicación Web explicada
anteriormente.
Figura 14. Módulos de Monitoreo dentro de una Arquitectura de Aplicación WEB.
Servidor
Servidor WEB
Cliente Programas del lado del servidor
Aplicación
DBMS
1ra capa
2da capa
3ra capa
Petición
Respuesta
Módulo Presentación
Módulo Distribución
Módulo Procesamiento
Módulo Generación
Servidor
Servidor WEB
Cliente Programas del lado del servidor
Aplicación
DBMS
1ra capa
2da capa
3ra capa
Petición
Respuesta
Servidor
Servidor WEB
Cliente Programas del lado del servidor
Aplicación
DBMS
1ra capa
2da capa
3ra capa
Petición
Respuesta
Módulo Presentación
Módulo Distribución
Módulo Procesamiento
Módulo Generación
Módulo Presentación
Módulo Distribución
Módulo Procesamiento
Módulo Generación
76
3. DISEÑO DETALLADO
Una vez finalizada la etapa de diseño del sistema de la herramienta
de monitoreo, el siguiente paso es adecuar el análisis a las características
específicas del ambiente de implementación y complementar las distintas
aplicaciones del sistema con los modelos de control, interfaz y
comunicaciones, según sea el caso.
En este sentido, la etapa de diseño detallado de la herramienta de
monitoreo busca identificar las diferentes clases que comprenden las
entidades de software a traducir en un lenguaje de programación OO,
diseñar la interacción entre instancias (u objetos) particulares de las
clases, diseñar la base de datos, definir los diagramas de estados y una
interfaz gráfica que facilite la interacción de los usuarios finales con la
herramienta que se desea construir.
3.1. Diseño del diagrama de clases
Esta fase consiste en identificar las distintas clases que constituirán
el sistema, incluyéndose sus atributos y métodos, como también las
relaciones existentes entre las mismas.
Una clase es una abstracción que describe un grupo de objetos con
propiedades (atributos) comunes, comportamiento (método) común,
relaciones comunes con otros objetos y una semántica común.
Al definir las clases, las relaciones entre ellas, y al asignarles
trabajos a través de las especificaciones de sus métodos, se modela la
arquitectura de un software OO, ya que éste se compone de objetos -o
77
instancias de clases-, los cuales se comunican entre ellos a través del envío
de mensajes o invocación de métodos, con la finalidad de llevar a cabo los
diferentes procesos.
El modelado de las entidades del software (clases) y de las relaciones
entre las mismas, se realiza mediante la elaboración del diagrama de
clases, descrito inicialmente por Booch. Este diagrama muestra, de una
manera estática, la estructura de información del sistema y la visibilidad
que tiene cada una de las clases, dada por sus relaciones con las demás en
el modelo. Para la elaboración de dicho diagrama se emplea la siguiente
estrategia para identificar las clases, atributos y métodos necesarios:
?? Se obtienen las clases, utilizando los diferentes sustantivos
asociados al e nunciado del problema, junto con el modelo del
mundo planteado anteriormente.
?? Para la identificación de los atributos, se describe cada una de las
clases dentro del dominio del problema, especificando qué tipo de
datos se necesitan saber y posiblemente almacenar en el tiempo.
?? Para la identificación de los métodos, se estudia dentro del
dominio del problema qué actividades deben realizar cada objeto
dentro de una clase y de esta manera se determinan las acciones
de los mismos. Para ello, se utiliza como referencia los
componentes y aplicaciones del sistema identificados en la etap a
de diseño.
?? Se modelan las relaciones entre clases utilizando las asociaciones
del modelo del mundo y la arquitectura del sistema.
78
Figura 15. Diagrama de clases del sistema
GestorEmai l
FormatoEmail : String
ServidorEmail : String
mensaje : Str ingencabezado : String
mot ivo : Str ing
destinatarios : Array
EnviarEmailconArchivo()EnviarEmail()
CrearEmail()
GestorReportes
tipoReporte : String
formatoReporte : String
valoresReporte : Array
codigoServidor : IntegertipoGrafica : String
generarReporteDesempeño()
procesarHistoricos()
procesarGrafica()generarGrafica()
generarReporteEvento()
GenerarReporteSistema()
Estandar
codigoServidor : Integer
tipoMonitoreo : String
valorMonitoreo : Double
valorEstandar : Double
consultarEstandar()
insertarEstandar()
modificarEstandar()
borrarEstandar()compararEstandar()
ModificarFrecuencia()
Historicos
codigoServidor : Integer
fecha : Date
hora : TimetipoMonitoreo : String
valorMonitoreo : Double
insertarHistorico()consultarHistorico()limiarHistorico()
Presentador
tipoCliente : String
archivoXML : String
archivoXSL : String
URL : String
parsearXML()
seleccionarXSL()
procesarXML+XSL()
generarReporte()crearFormato()
Notif icador
evento : String
gradoImportancia : Integer
fecha : Datehora : Time
formato : String
listaDestinatarios : Array
codigoServidor : Integer
crearNotificacion()enviarNotificacion()
Diagnosticador
codigServidor : Integer
tipoMonitoreo : StringXMLdestino : String
valorMonitoreo : DoublevalorEstandar : Double
QueryMonitoreo : String
ComandoMonitoreo : StringeventoInteres : Boolean
historico : Boolean
conectar()
monitorearB.D.()monitorearS.O.()
generarXML()
ActualizarMonitoreo()
Diagnosticar()
Conector
codigoServidor : Integerinstancia : Stringdriver : String
host : String
usuario : String
clave : String
conectar()
ping()
Distribuidor
tipoCliente : String
URL : String
consultarTipoCliente()desplegarPantalla()
Bitacora
tipoBitacora : String
tipoEvento : String
mensajeEvento : String
gradoImportancia : Integer
almacenarEvento()
consultarEvento()
borrarEvento()
GestorUsuarios
nombre : String
clave : Stringemail : String
telefono : String
direccion : String
eventoInteres : Boolean
tipoUsuario : String
autenticar()
insertarUsuario()
modificarUsuario()borrarUsuario()
consultarPerfil()
79
Durante la etapa de implementación y prueba de la herramienta de
monitoreo, se refina el diagrama de clases, agregando o modificando
clases, con sus atributos y métodos, no identificados durante la etapa de
diseño detallado.
La figura 15 muestra el diagrama de clases del sistema, elaborado
durante la etapa de diseño detallado y refinado d urante la etapa de
implementación y pruebas.
3.2. Elaboración de los diagramas de secuencia
Los diagramas de secuencia son un tipo de diagrama de interacción,
que se incluyen en la notación del lenguaje de modelado UML. Un
diagrama de secuencia muestra la interacción de las clases a través de
una secuencia en el tiempo.
Estos diagramas enfatizan el paso de mensajes a través del tiempo,
entre los componentes del sistema (clases) desde los actores del sistema.
Con la elaboración de estos diagramas, se observa el uso de los métodos
planteados para cada evento (casos de uso) que puede ocurrir en la
herramienta.
Para la elaboración de estos diagramas, se extraen los actores
involucrados en los casos de uso planteados en la etapa de análisis de
requerimientos -el DBA, el administrador del sistema y el agente de
tareas-, luego se extraen las clases del diagrama de clases y, por último,
se modela la interacción entre los actores y las clases, a través del
seguimiento de la secuencia típica de los casos de uso del sistema.
80
En la figura 16 se ilustra el diagrama de secuencias elaborado para el
escenario Monitoreo por Petición. En este diagrama se puede observar
cómo se modela la interacción entre el actor DBA y las diferentes clases
que participan en el escenario y los métodos que se ejecutan.
Figura 16. Diagrama de secuencias elaborado para el escenario Monitoreo por Petición
81
El apéndice A muestra los diferentes diagramas de secuencia
realizados en esta etapa.
3.3. Diseño de la base de datos
El diseño de la base de datos de la herramienta de monitoreo
constituye una actividad esencial, debido a que en la base de datos se
almacena toda la información de los diferentes usuarios, bitácoras e
históricos. Es de vital importancia el manejo de esta información, ya que a
partir de la misma se logra obtener los reportes de desempeño de los
distintos servidores a lo largo del tiempo, entre otras cosas.
Para la elaboración de la base de datos, se toman los posibles
repositorios de data de los casos de uso elaborados anteriormente. Luego,
para complementar la información, se toman los posibles atributos
asociados a éstos.
Luego, se realizan las asociaciones entre las tablas, con la creación de
las claves principales y foráneas de cada una, de esta forma se asegura la
integridad de la data almacenada.
Para la representación del modelo de la base de datos, se realiza el
modelo ER (modelo de entidad relación) que describe los datos como
entidades, vínculos y atributos (Elmasri y Navathe, 1997, p.41-45).
La figura 17 muestra el diagrama de entidad relación de la base de
datos de la herramienta de monitoreo.
82
Figura 17. Diagrama de Entidad Relación del sistema
83
3.4. Interfaz gráfica de usuario
La interfaz gráfica de usuario de la herramienta de monitoreo se
desarrolla para cada tipo de dispositivo remoto que realiza peticiones al
sistema. Cada presentación es realizada tomando en cuenta las
limitaciones de cada dispositivo.
La figura 18 presenta la pantalla de autenticación para cada
dispositivo, donde se identifican las partes esenciales de la misma.
También se puede observar en la figura 18, como el usuario, sin
importar el tipo de ambiente, ingresa su nombre de usuario y clave, para
así poder tener acceso a las diferentes opciones que brinda la herramienta
de monitoreo.
1
2
Figura 18. Pantalla de autenticación
84
A continuación se describen las partes de la pantalla de autenticación
de la herramienta de monitoreo, siguiendo la numeración de la figura 18.
1. Nombre: El usuario ingresa el nombre para poder acceder al
sistema
2. Clave: Ingresa su clave, la cual será el e-mail del usuario.
Figura 19. Menú Principal.
A continuación se nombran las partes del menú principal del sistema,
siguiendo la numeración de la figura 19.
1
2
3
85
1. Monitorear Servidores: Con esta opción, el usuario podrá
seleccionar las diferentes estructuras del servidor de base de datos
a monitorear. Esta a su vez se divide en sistema operativo y
manejador de base de datos.
2. Administración: Donde el usuario podrá configurar los tiempos del
monitoreo periódico, así como la administración de usuarios.
3. Reportes: Donde podrá hacer las peticiones por reportes de eventos
o históricos a la herramienta de monitoreo.
La figura 20 muestra uno de los menú desplegados al elegir una de
las opciones de monitoreo de servidores.
Figura 20. Menú de Monitoreo de Memoria
86
4. IMPLEMENTACIÓN Y PRUEBAS
En esta etapa se realiza la programación y desarrollo del sistema. Se
adecuan los estándares de las clases definidas al lenguaje de
programación, así como las pruebas y revisión del código. Para ello se
presenta el desarrollo de la herramienta de monitoreo a partir de los
módulos del mismo, donde se presentan las diferentes tecnologías
utilizadas en cada una de ellas, así como los objetos que intervienen en
cada módulo. El apéndice B muestra diferentes características de las
tecnologías seleccionadas.
La herramienta de monitoreo fue desarrollada con características de
una arquitectura de aplicación Web, por este motivo fue necesar io separar
la presentación de la lógica de aplicación, teniendo en cuenta el
funcionamiento del modelo de 3-capas nombrado en la arquitectura.
Se escogió Java Enterprise Edition como tecnología para el desarrollo
del sistema, ya que permite desarrollar la herramienta con una
arquitectura Web en ambientes distribuidos. La tecnología Java brinda
las siguientes ventajas:
Independencia de plataformas: La tecnología Java puede ser
usada en cualquier plataforma, ya sea en ambientes Windows o
en ambientes Unix.
Eficiencia: Los Java servlets4 extienden una nueva tarea en un
mismo proceso para atender la petición del usuario. Esto permite
4 Servlets son programas del lado del servidor que permiten a la lógica de una aplicación estar unidos a través de peticiones y respuestas utilizando el protocolo http.
87
que cientos de usuarios tengan acceso al mismo Java servlet
simultáneamente sin dejar fuera de servicio al servidor.
Acceso a otras aplicaciones Java: Como los servlets son una
extensión de la plataforma Java, éstos pueden acceder cualquier
otra aplicación que tenga ambiente Java, como por ejemplo,
mandar y recibir correos electrónicos, invocar métodos de objetos
remotos, o conectividad a manejadores de base de datos
Reutilización de código: Es un lenguaje orientado a objetos, que
permite la reutilización de código.
Modularidad: Permite que la aplicación se divida en módulos
discretos en los cuales cada uno tiene una tarea especifica. Esto
hace que la aplicación sea fácil de mantener y comprender.
Durante la programación de la herramienta, la tecnología Java se
utilizó en los cuatro módulos de la aplicación, los cuales incluyen
conectividad de base de datos, generación de reportes, creación de archivos
XML, procesos de monitoreo, procesamiento de la información de
monitoreo, presentación de archivos XML, manejo de la creación y
distribución de correos electrónicos, creación de gráficas de desempeño, y
todas las actividades o procesos que se realizan dentro del sistema.
Gracias a estos servicios y con el uso de archivos XML para recolectar y
presentar los reportes de monitoreo, se logra que la herramienta pueda
ser utilizada en cualquier tipo de plataforma.
A continuación se presenta el desarrollo e implementación de cada
uno de los módulos de la herramienta:
88
4.1. Módulo de Generación
Para este módulo se desarrolló una clase llamada diagnosticador.
Ésta es una clase de monitoreo genérica que se encarga de supervisar el
desempeño del servidor de base de datos. Puede ser invocada por medio de
una petición que realiza el usuario y contiene los parámetros de
monitoreo. Por ejemplo, cuál es: el servidor a monitorear, el tipo de
monitoreo, el nombre de las columnas a mostrar en el reporte, la
descripción de las columnas, el nombre del archivo XML que contendrá el
reporte, entre otros. El diagnosticador contiene un método para
monitorear el manejador de base de datos y otro método para monitorear
el sistema operativo donde se encuentra el manejador de base de datos.
Monitorear el manejador de base de datos consiste en crear una
conexión directa a éste, a través de su respectivo puerto de conexiones
remotas, utilizando JDBC5, para luego interrogar directamente su
rendimiento. Este diagnosticador puede trabajar en cualquier manejador
de base de datos, sólo se necesita especificar los parámetros adecuados
según el manejador, a saber: el comando de monitoreo adecuado, las
columnas que retornará, el tipo de datos que retornará, entre otros.
Adicionalmente, es necesario especificar cuál es la clase conexión que va a
utilizar, ya que cada manejador posee un driver y puerto específico para
su conexión remota.
El monitoreo del sistema operativo, donde se encuentra el manejador
de base de datos, consiste en abrir una conexión remota directa al mismo,
para ejecutar comandos de monitoreo de rendimiento según el sistema
5 JDBC (Java Database Connectivity) es un manejador (driver) que proporciona la habilidad de conexión a base de datos relacionales.
89
operativo. El diagnosticador recibe la salida de estos comandos al
ejecutarlos, luego se almacenan los valores resultantes en un arreglo para
así poder procesarlos como información de monitoreo.
Una vez que el diagnosticador contiene toda la información de
monitoreo, invoca una clase “estándares” para poder consular los valores
estándares relacionados con el monitoreo realizado y así poder llevar a
cabo las comparaciones necesarias para la creación del reporte de
monitoreo.
El diagnosticador también usa la clase “histórico” para almacenar la
información de monitoreo realizada en la base de datos como históricos de
monitoreo. Además del valor de monitoreo se almacena la fecha, la hora,
el nombre del monitoreo, tipo de monitoreo y el código del servidor que fue
monitoreado.
Para finalizar el proceso de monitoreo, la clase diagnosticador
ejecuta el método crear reporte, el cual consiste en guardar en un archivo
XML toda la información de monitoreo generada, y una vez que el archivo
se haya creado correctamente, se le envía al distribuidor el URL del
reporte XML generado para que pase al proceso de presentación el cual se
explicará posteriormente.
4.2. Módulo de Procesamiento
En este módulo intervienen las clases que realizan algún tipo de
procesamiento a la información de monitoreo, como por ejemplo,
promedios de rendimiento, comparaciones, validaciones y otros. La clase
Gestor de Reportes realiza este tipo de procesos cada vez que recibe una
petición de reporte. Las peticiones de reportes se realizan dependiendo de
un intervalo de tiempo definido, el tipo de reporte que se quiere (gráfica,
90
textual, compacto, comparativo, correo electrónico, etc.), las estructuras
que se desean visualizar y el servidor que se monitoreó.
Una vez que se realiza la petición de monitoreo, la clase Gestor de
Reporte invoca a la clase de Históricos para consultar los valores de
rendimiento realizados anteriormente, pertenecientes al intervalo de
tiempo requerido. Por ejemplo, para generar un reporte de rendimiento de
CPU de algún servidor de un día completo en una fecha determinada por
intervalos de una hora, se requiere consultar todos los valores de
monitoreo obtenidos es ese día y promediarlos en intervalos de una hora,
es decir, si el agente de tareas tiene programado monitorear el CPU cada
10 minutos, se tendría que promediar los seis valores de monitoreo que
contiene c ada hora del día, y así poder desplegar una gráfica con 24
columnas, una por cada hora, y el rango será desde 0% hasta 100%. La
figura 21 presenta una gráfica que contiene un reporte del ejemplo
explicado anteriormente elaborado con datos reales de monitoreo.
Figura 21. Rendimiento de CPU del 16/05/2001. Fuente: Servidor de base de datos www.porlapuerta.com, manejador Oracle, Sistema Operativo
Solaris 2.6
0,0
10,0
20,0
30,0
40,0
50,0
60,0
70,0
80,0
90,0
100,0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
91
La clase Gestor de Reportes, también tiene la opción de procesar
varios reportes de gráficas a la vez con distintas estructuras de monitoreo
realizadas en un mismo intervalo de tiempo, y así poder observar si existe
algún tipo de relación en sus rendimientos. Por ejemplo, si el manejador
de base de datos muestra un mal rendimiento en el buffer hit ratio
(relación de lecturas a disco y lecturas a buffer), quiere decir que existen
más lecturas a disco de las que debería tener el manejador en un
rendimiento óptimo. Entonces se debería graficar el rendimiento del
buffer hit ratio del manejador junto con el rendimiento de lecturas a disco
del sistema operativo, y así poder relacionarlos y determinar si esta
información logra o no brindar algún tipo de respuesta en cuanto a los
motivos del bajo rendimiento. Adicionalmente, se podría graficar el
rendimiento del CPU, ya que necesita 10 veces más recursos para hacer
una lectura a disco en vez de una lectura a buffer.
Figura 22. Módulo de generación y módulo de procesamiento
Gestor de Reportes
Gestor de Usuarios Históricos EstandaresEventosConector
Diagnosticador
DBMS
Servidor
Texto Texto
Usuarios Políticas
Seguridad
Bitácoras Sesiones
B.D.
EstandaresGráficas
B.D.
Históricos
Petición URL Alerta,ReportePetición
Agente de Tareas
XML
ReportesReportes
92
La clase Históricos también pertenece al módulo de procesamiento.
Esta clase se encarga de validar la información de monitoreo antes de
introducirla en la base de datos de la herramienta. La figura 22 presenta
el funcionamiento e interacción del módulo de generación y
procesamiento.
4.3. Módulo de Distribución
Este módulo se encarga de la distribución de las peticiones de
monitoreo y de reportes realizados al sistema y la distribución de los
reportes de salida que se muestran en los dispositivos o el envío por correo
electrónico de estos reportes a los usuarios. En este módulo se encuentra
la clase Distribuidor, la cual recibe las peticiones del usuario y las
distribuye según el tipo de petición.
Las peticiones de ejecución de programas son enviadas por la clase
Distribuidor al módulo de procesamiento o al módulo de generación para
que sean ejecutados. Por ejemplo, algunas de las peticiones son
autenticación, algún monitoreo a realizar o algún reporte. Después que se
realiza el monitoreo por parte del módulo de generación o algún reporte
generado por el módulo de procesamiento, le devuelve al distribuidor un
URL con la ubicación del reporte XML generado por el monitoreo o por el
gestor de reportes. El distribuidor, al recibir el URL con extensión XML, lo
envía al módulo de presentación para ser formateado, según sea el soporte
de presentación que tenga el dispositivo que está realizando la petición.
Cada vez que el distribuidor recibe una petición del cliente, éste le
pregunta qué clase de cliente es, para así determinar qué tipo de formato
93
de presentación soporta, y así poder enviar la petición y el tipo de cliente
al presentador para que éste determine cómo presentar el reporte.
La clase gestor de E-Mail también pertenece a este módulo de
distribución. Esta clase en la responsable de enviar correos con reportes
de rendimiento o alarmas de eventos a los usuarios. Esta clase será
invocada por la clase gestor de reportes o por la clase estándares al surgir
un evento de interés que debe ser notificado. Recibe el cuerpo del mensaje,
el motivo, un arreglo con las direcciones de las personas que deben recibir
el correo, y opcionalmente un archivo adjunto con alguna imagen de una
gráfica de rendimiento.
La figura 23 presenta el funcionamiento e interacción del módulo de
distribución en la herramienta de monitoreo.
Figura 23. Módulo de distribución y su interacción
Distribuidor de Peticiones
Aplicación Presentador
Petición programa
URL
Petición XML
Reporte con formato
Mail Server
Alerta
Reporte
Texto Texto
Usuarios Políticas
Seguridad
Bitácoras Sesiones
DBMS
ServidorB.D.
Históricos Desempeño Estandares
Modificar, consultar
Crear, eliminar
Status Estadísticas
XSLXML
Generar
Petición XMLPetición formato
FormatoXSL
Reportes Formatos
Servidor a Monitorear
Cliente
PeticiónFormato según
dispositivo
Email con reporte
Email con alarma
94
4.4. Módulo de Presentación
En este módulo se encuentra la clase Presentador y es responsable
de brindar el formato correcto según el tipo de cliente que realiza la
petición. Esta clase recibe una petición por parte del distribuidor de algún
archivo XML a presentar junto con el tipo de cliente. Según el tipo de
cliente, busca el tipo de formato que éste soporta en un archivo de
propiedades para así poder seleccionar la hoja de formato XSL correcta
para la presentación. El archivo de propiedades en un archivo de texto que
contiene el orden de búsqueda de los formatos de presentación y el tipo de
formato soportado por cada tipo de cliente. De esta manera se pueden
agregar tantos tipos de clientes y de formatos como se desee. La figura 24
muestra este archivo de comandos.
Figura 24. Archivo de propiedades
Una vez seleccionado el archivo XSL que contiene el formato
adecuado para el tipo de dispositivo que realizó la petición, se envía el
archivo XML junto con el archivo XSL correspondiente al procesador
XSLT para generar el archivo producto, el cual contiene el reporte con el
formato adecuado para el dispositivo. Por ejemplo, el presentador genera
browser.0 = explorer=MSIE browser.1 = pocketexplorer=MSPIE browser.2 = handweb=HandHTTP browser.3 = avantgo=AvantGo browser.4 = imode=DoCoMo browser.5 = opera=Opera browser.6 = lynx=Lynx browser.7 = java=Java browser.8 = wap=Nokia browser.9 = wap=Motorola browser.10 = palm=PalmOS browser.11 = wap=UP browser.12 = wap=Wapalizer browser.13 = mozilla5=Mozilla/5 browser.14 = mozilla5=Netscape6/ browser.15 = netscape=Mozilla
95
reportes en archivos con formato WML para los celulares; se generan
archivos HTML para los exploradores comunes, archivos HTML sin
figuras y sin tablas para las agendas como la Palm Pilot; archivos de
texto para navegadores de texto como el Lynx, y cualquier otro formato
que se haya definido. El archivo producto es enviado al distribuidor para
que sea mostrado al cliente. La figura 25 muestra el proceso de generación
del archivo producto.
Figura 25. Proceso de generación del archivo producto
Esta implementación permite separar la lógica de presentación del
contenido, la información de un reporte estará contenida en un sólo
archivo XML, mientras que la presentación dependerá de los archivos XSL
asociados al archivo XML según el tipo de formato requerido por el cliente.
La información del archivo XML puede cambiar continuamente sin afectar
la forma en que será presentada, igualmente, se puede modificar la forma
Cliente
Petición HTTP
Petición HTTP Servidor
WEB
Distribuidor
Archivo XSL Formatos XSL
XSL + XML
Procesador XSLT
Reporte WML
Doc. WML
Presentador
Documento XML
96
en que será presentada la información, sin afectar el contenido del
archivo XML. La figura 26 muestra cómo diferentes tipos de dispositivos
pueden realizar peticiones al sistema, sin importar el formato de los
mismos.
Figura 26. Diferentes tipos de dispositivos realizando peticiones
Si en el futuro s urge un nuevo tipo de formato, simplemente se
necesita crear un nuevo archivo XSL y asociarlo a los archivos XML. Esto
quiere decir que un archivo XML tendrá tantos archivos XSL, como tipos
de dispositivos deseados para acceder a la información y que sea
presentada de acuerdo a las ventajas y limitaciones que tenga cada
dispositivo.
A continuación se presenta un ejemplo de un archivo XML (figura 27)
con tres archivos XSL asociados (figuras 28, 29 y 30), uno para
exploradores comunes que soportan HTML sin limitaciones(figura 31),
Internet
Petición
Petición
Petición
Petición
Respuesta
Respuesta
Respuesta
Respuesta
Inalámbrico
33.6k
T1
56k
Web Server
Distribuidor de Peticiones
Petición
Respuesta
97
otro para Palm Pilot (figura 32) con HTML limitado (sin imágenes o
tablas) y otro para celulares con formato WML (figura 33).
Figura 27. Archivo XML para el menú monitoreo
Figura 28. Archivo XSL para Palm Pilot
<?xml version="1.0"?> <?xml-stylesheet href="xsl/menu.xsl" type="text/xsl" ?> <?xml-stylesheet href="xsl/menu-wap.xsl" type="text/xsl" media="wap"?> <?xml-stylesheet href="xsl/menu-palm.xsl" type="text/xsl" media="palm"?> <?process type="xslt"?> <IndiceMonitoreo> <Titulo> Memoria </Titulo> <Menu> <Opcion Link="data/bufferhitratio.xml"> <Nombre> Buffer Hit Ratio </Nombre> </Opcion> <Opcion Link="data/datadicthitratio.xml"> <Nombre> Data Dict Hit Ratio </Nombre> </Opcion> <Opcion Link="data/sqlcachehitratio.xml"> <Nombre> SQL Cache Hit Ratio </Nombre> </Opcion> <Opcion Link="data/librarycachehitratio.xml"> <Nombre> Library Cache Miss Ratio </Nombre> </Opcion> </Menu> </IndiceMonitoreo>
<?xml version="1.0"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/"> <xsl:processing-instruction name="format">type="text/html"</xsl:processing-instruction> <html> <head> <title>Indice Monitoreo</title> </head> <b> <xsl:value-of select="IndiceMonitoreo/Titulo"/> </b> <xsl:for-each select="IndiceMonitoreo/Menu/Opcion"> <b> <a href="{@Link}"><xsl:value-of select="Nombre"/></a> </b> </xsl:for-each> </body> </html> </xsl:template> </xsl:stylesheet>
98
Figura 29. Archivo XSL para formato HTML
<?xml version="1.0"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/"> <xsl:processing-instruction name="format">type="text/html"</xsl:processing-instruction> <html> <head> <title>Indice Monitoreo</title> </head> <body bgcolor="#FFFFFF" background="gifs/fondo.gif"> <p> </p> <table width="300" border="1" align="center"> <tr bgcolor="#000099"> <td height="39"> <div align="center"><font face="Verdana, Arial, Helvetica, sans-serif" size="4" color="#FFFFFF"><b> <xsl:value-of select="IndiceMonitoreo/Titulo"/> </b></font></div> </td> </tr> <xsl:for-each select="IndiceMonitoreo/Menu/Opcion"> <tr> <td> <div align="center"><font face="Verdana, Arial, Helvetica, sans-serif" size="3" color="#000099"><b> <a href="{@Link}"><xsl:value-of select="Nombre"/></a> </b></font><font size="3" color="#000099"><b></b></font></div> </td> </tr> </xsl:for-each> </table> </body> </html> </xsl:template> </xsl:stylesheet>
99
Figura 30. Archivo XSL para WAP
<?xml version="1.0"?> <xsl:stylesheet version="1.0" <xsl:processing-instruction name="cocoon-format">type="text/wml"</xsl:processing-instruction> <wml> <card id="index" title="Monitoreo" > <p align="center"> <small> <b> <xsl:value-of select="IndiceMonitoreo/Titulo"/> </b> </small> <br/> <xsl:for-each select="IndiceMonitoreo/Menu/Opcion"> <small> <a href="{@Link}"><xsl:value-of select="Nombre"/></a> <br/> </small> </xsl:for-each> </p> </card> </wml> </xsl:template> </xsl:stylesheet>
Figura 33. Presentación
WAP
Figura 32. Presentación Palm
Pilot
Figura 31. Presentación HTML
100
Aspectos de Seguridad
En el desarrollo de la herramienta se tomaron en cuenta ciertos
aspectos de seguridad, necesarios para que la información esté siempre
disponible y para que sea accedida única y exclusivamente por quienes
tienen la autorización requerida.
Los aspectos tomados en cuenta fueron:
1. Disponibilidad - La información debe estar en el momento
que el usuario requiera de ella. Un ataque a la
disponibilidad es la negación de servicio.
2. Privacidad - La información debe ser vista y manipulada
únicamente por quienes tienen el derecho o la autoridad
de hacerlo. Un ejemplo de ataque a la Privacidad es la
Divulgación de Información Confidencial.
Los métodos desarrollados para poder cumplir estos aspectos fueron:
?? Creación y lectura de bitácoras
Se desarrollaron dos tipos de bitácoras: una bitácora de autenticación
y sesiones que almacena todas las autenticaciones que hayan fallado
con su procedencia y el seguimiento de sesiones por el sistema, y otra
bitácora de errores de sistema, que almacena todos los errores
ocurridos en el sistema con su respectivo grado de importancia. Estas
bitácoras son archivos de texto con propiedades de lectura y de
“append”, es decir, sólo se les puede agregar información o leerlas.
101
De esta manera los posibles intrusos no podrán borrar estas
bitácoras, para así poder proteger su identidad y esconder la ruptura
de seguridad que estén realizando.
?? Creación de Respaldos
Todas las bitácoras, reportes de monitoreo e históricos son
respaldados cada cierto tiempo en cintas magnéticas. El actor agente
de tareas nombrado anteriormente, será quién realice estos
respaldos cada cierto tiempo.
?? Alertas
Cuando ocurran errores en el sistema que tengan posibilidad de
comprometer la disponibilidad del sistema, éstos serán reportados
por medio del gestor de correos de la herramienta a los
administradores de sistema.
?? Encriptación
Las claves de acceso de los usuarios estarán almacenadas en el
sistema, luego de haberle aplicado encriptación, de manera que los
intrusos no puedan obtener las claves de acceso y de esta manera
poder entrar en el sistema.
102
MODELO DE BALANCEO DE CARGAS SEGÚN EL MONITOREO
REALIZADO
En años recientes, los avances en la tecnología han hecho posible la
creación de ambientes distribuidos de computadores a través de redes de
alta velocidad, y de esta manera poder distribuir grandes cantidades de
tareas con el propósito de aprovechar al máximo los recursos de estos
computadores de forma equilibrada.
Los servidores de base de datos distribuidos permiten que usuarios o
aplicaciones puedan obtener información a partir de servidores ubicados
en lugares distintos, interconectados por una red de alta velocidad. Sin
embargo, existe la posibilidad de que el rendimiento global de la base de
datos de algunos servidores se vea afectado, bien sea por ausencia de
carga, o por e star ligeramente cargados o sobrecargados de tareas.
Situación que, en cualquiera de los casos, obliga a balancear las cargas
entre servidores, con miras a mejorar el tiempo de respuesta y aprovechar
los recursos disponibles de manera eficiente.
En tal sentido, se propone un modelo heurístico para el balanceo de
cargas dinámico que, a partir de la información de monitoreo que brinda
la herramienta, sea capaz de distribuir las tareas en los distintos
computadores en un ambiente distribuido, basado en políticas
predefinidas de decisión. Este modelo también es capaz de demostrar la
recuperación de tareas perdidas en caso de que uno o varios de estos
computadores o nodos falle.
103
Modelo
El modelo que se propone tiene como objetivo distribuir un gran
número de tareas en varios computadores que se encuentran en una red;
con miras a balancear las cargas a nivel de aplicación para aprovechar los
recursos de hardware disponibles de la mejor manera posible, sin
contemplar otros niveles de balanceo de cargas: nivel de hardware y nivel
de trasporte de red.
Según el objetivo de este modelo, se define balanceo de cargas como
la técnica que permite utilizar los recursos disponibles en computadores
distribuidos en una red de alta velocidad de una manera eficiente,
aprovechar el paralelismo existente entre los sistemas y reducir el tiempo
de respuesta a través de una distribución apropiada de las tareas.
En los servidores de base de datos, la cantidad de peticiones que
provienen de los usuarios no está coordinada ni planificada. De allí que el
modelo de balanceo de cargas propuesto debe trabajar de forma dinámica,
según los cambios de rendimiento que se presentan e n el sistema al
atender las peticiones.
Este modelo opera en un ambiente distribuido de servidores iguales,
es decir, con una sola política para la distribución de tareas en todos los
nodos, por lo que no requiere de un modelo de tipo adaptable a la
capacidad de cambiar sus políticas dinámicamente, según el
comportamiento de cada servidor.
104
Por otra parte, el modelo trabaja en forma dinámica, dada la
capacidad de adaptar la distribución de las tareas según cambios de
rendimientos ocurridos en los computadores. La detección de estos
cambios se realiza por medio de la herramienta de monitoreo.
Este modelo funciona en ambientes distribuidos de tipo “SPMD”
(Simple Program Múltiple Data). Esto quiere decir, que todas las
computadoras presentes en los nodos del balanceo de cargas son iguales y
conforman una piscina de recursos, para que luego un distribuidor de
tareas las asigne a el nodo con mas recursos disponibles en el momento de
recibir la tarea. La figura 34 muestra el funcionamiento del “SPMD”.
Figura 34. SPMD
Distribuidor de tareas
El distribuidor de tareas es un agente dinámico que contiene
información de la disponibilidad de cada nodo y el estado actual de
rendimiento de cada uno de éstos. Este agente será quién reciba todas las
peticiones de tareas y las distribuya a los nodos, según la política de
Cliente Distribuidor
Nodo A1
Nodo A2
Nodo A3
Nodo An
Data A1
Data A2
Data A3
Data An
información
HerramientaMonitoreo
Cliente Distribuidor
Nodo A1
Nodo A2
Nodo A3
Nodo An
Data A1
Data A2
Data A3
Data An
información
HerramientaMonitoreo
105
rendimiento establecida, p ara así poder decidir cuál será el nodo que
obtendrá la próxima tarea.
También el agente distribuidor lleva un seguimiento de las tareas
que se están ejecutando en cada uno de los nodos. De esta manera en caso
de que algún nodo quede no disponible, las tareas que contenía se
redistribuyen en los nodos que quedan disponibles. Para poder detectar la
disponibilidad de los nodos, el agente realiza cada cierto período de tiempo
una revisión de estatus de cada nodo para verificar su disponibilidad y
capacidad.
La herramienta de monitoreo se ejecuta en cada uno de los nodos, a
objeto de proporcionar los estados de rendimientos de cada uno de ellos,
para luego reportarlos al distribuidor de tareas.
Política de decisión
El agente distribuidor asigna la próxima tarea pendiente al nodo que
esté disponible y que tenga mayor cantidad de recursos libres, siguiendo el
orden definido en las políticas de decisión. Las políticas que se proponen
para este modelo son las siguientes:
?? Disponibilidad: la primera condición que se tiene que cumplir es
que el nodo esté disponible. Los nodos que no estén disponibles no
se tomarán en cuenta para la distribución de tareas hasta que estén
en funcionamiento nuevamente.
?? CPU: éste es el principal factor que permite decidir cuál nodo
recibirá la próxima tarea. También es el principal indicador de la
cantidad de carga que maneja un servidor de base de datos debido a
106
que el exceso de tareas o el exceso de lecturas a disco, en relación
con las lecturas a memoria, causan una mayor cantidad de carga al
CPU.
?? E/S Disco: las lecturas a disco tienen un tiempo de respuesta mucho
mayor y consumen diez veces mas recursos en relación a las
lecturas a memoria. Por esta razón, los computadores que tengan
mas flujo de Entrada/Salida de información a los discos, tienen más
carga y demora en los tiempos de respuesta que los computadores
que tengan menos.
?? Memoria: la memoria es un indicador de la capacidad que tiene el
servidor de procesar más tareas, sin tener que utilizar la memoria
virtual en disco. Cuando un servidor se queda sin memoria real,
éste procede a utilizar la memoria virtual que se encuentra en el
disco, lo cual genera grandes cantidades de lecturas a disco
provocando que el rendimiento general del servidor se reduzca.
?? Tráfico de Red : el tráfico de red que exista en un nodo puede ser
indicador de la cantidad de peticiones de tareas que se esté
manejando para el momento.
En general, se puede decir que la política propuesta es simplemente
asignar las tareas al nodo que tenga menos carga de CPU. En caso de que
los CPU tengan la misma cantidad de carga, se procede a realizar
comparaciones de los otros recursos como son las lecturas a disco,
memoria y tráfico de la red.
107
El distribuidor posee localmente una lista en memoria con la
disponibilidad de cada uno de los nodos, junto con su estado de
rendimiento. Primero, revisa el porcentaje de uso del CPU sólo en los
nodos disponibles para luego enviar la tarea al nodo con mayor porcentaje
de CPU disponible. En caso de que todos tengan el mismo porcentaje CPU
libre, la tarea se asigna al computador que tenga menores lecturas a disco.
De igual manera, si todos los nodos tienen la misma cantidad de lecturas
a disco, la tarea se asigna al nodo con mayor porcentaje de memoria libre.
Si todos tienen el mismo porcentaje de memoria libre, se envía al nodo que
tenga menos tráfico de red. De darse todas las condiciones anteriores, se
asigna la tarea de forma aleatoria.
Cada cierto tiempo el distribuidor de tareas tendrá comunicación con
cada uno de los nodos para actualizar su disponibilidad y estado de
rendimiento; de esta manera, se harán las comparaciones localmente para
que el tiempo de este procesamiento sea prácticamente despreciable y así
no aumentar el tiempo de respuesta en las peticiones.
Cada nodo consta de un computador que se encuentra en paralelo con
los otros computadores a través de una red rápida, y cada nodo obtiene la
información de monitoreo generada por la herramienta para poder
actualizarla con el distribuidor cada cierto tiempo. Es recomendable que el
intervalo de tiempo entre actualizaciones de la disponibilidad y capacidad
de los nodos con el distribuidor sea lo más corto posible, facilitando que el
distribuidor obtenga la información actualizada y así poder hacer una
repartición de tareas de forma eficiente. Los nodos tienen la
responsabilidad de reportar al distribuidor cada tarea que haya
culminado. La figura 35 muestra gráficamente el proceso del distribuidor.
108
Figura 35. Proceso del Distribuidor
Soporte de Fallas
El distribuidor está continuamente encuestando a los nodos para
saber su disponibilidad. En caso que uno o mas nodos queden no
disponibles, el distribuidor los marca como no habilitados y no envía
tareas a éstos hasta que estén disponibles de nuevo. El distribuidor
también tiene la responsabilidad de detectar cuáles fueron las tareas que
no se culminaron en el nodo o los nodos que presentaron la falla, y de esta
manera poder redistribuir las areas en los nodos que quedan disponibles.
El modelo de balanceo de cargas, a partir del monitoreo realizado por
la herramienta, brinda las siguientes ventajas:
?? Periódico: el distribuidor de tareas está en constante comunicación
con los nodos para determinar su estado de rendimiento o
disponibilidad.
?? Dinámico: la distribución de tareas se realiza dependiendo del
estado de rendimiento actual existente en los nodos.
DISTRIBUIDOR
Lista Queries Lista Nodos
Petición1 (nodo) nodo1(estado) Petición2 (nodo) nodo2(estado) Peticiónn (nodo) nodon (estado)
POLÍTICAS
CPU DISCO
MEMORIA RED
NODOS
nodo1 nodo2
: nodon
HerramientaMonitoreo
DISTRIBUIDOR
Lista Queries Lista Nodos
Petición1 (nodo) nodo1(estado) Petición2 (nodo) nodo2(estado) Peticiónn (nodo) nodon (estado)
POLÍTICAS
CPU DISCO
MEMORIA RED
NODOS
nodo1 nodo2
: nodon
HerramientaMonitoreo
109
?? Eficiente: se realiza una distribución eficiente de las tareas en los
nodos siguiendo las políticas de rendimiento establecidas.
?? Tolerante a fallas: el distribuidor detecta si un nodo falla para así
poder recuperar las tareas que no pudo completar y redistribuirlas
en los nodos que queden disponibles.
110
CAPÍTULO III
111
RESULTADOS
Este capítulo presenta formalmente a la herramienta de monitoreo.
La herramienta de monitoreo es una aplicación cuyo objetivo consiste
en presentar el desempeño de los servidores de base de datos en
momentos específicos o a lo largo del tiempo y reportar eventos de interés
que puedan ocurrir en un momento dado. Esto se realiza a través de
dispositivos remotos, como PDAs o celulares, vía Internet.
Esta herramienta, por la estructura de su diseño, tiene la capacidad
de ser utilizada por cualquier otro tipo de dispositivo de acceso a través de
la Web, especificando únicamente el tipo de presentación de la misma.
La aplicación facilita a los administradores de base de datos
supervisar el desempeño de los servidores que están a su cargo, sin
importar l a ubicación geográfica e n la cual se encuentran. A su vez,
permite recibir notificaciones del sistema cuando ocurren factores críticos,
a fin de realizar los correctivos pertinentes de forma inmediata.
La herramienta de monitoreo permite:
1. Establecer una conexión remota, vía Internet, utilizando los
dispositivos remotos o el envío de E-Mail.
2. Monitorear el desempeño de diferentes estructuras de servidores de
base de datos, las cuales incluyen:
112
A. Sistema Operativo:
i Carga del CPU
ii Memoria disponible
iii Actividad en disco (lecturas, escrituras)
iv Memoria SWAP
v Compaginaciones
vi Tráfico en red
B. Manejador de Base de Datos
i Uso de CPU por sesiones
ii Uso de Memoria
iii Transacciones
iv Procesamiento de SQL
v Información General
3. VISUALIZAR EL DESEMPEÑO HISTÓRICO DEL SERVIDOR
4. Controlar el desempeño del servidor, comparando el desempeño
estándar con el actual, notificando al administrador por correo
electrónico, eventos críticos ocurridos y de los factores que
ocurren a su alrededor.
5. Almacenar el desempeño del servidor para que así el
administrador tenga un registro de su comportamiento a través
del tiempo.
Para presentar la herramienta de monitoreo, se prepararon tres
escenarios particulares que permiten demostrar las características
mencionadas anteriormente.
113
1. Caso de Uso: Monitoreo por petición
El objetivo de este caso es reportar al usuario que realizó una
petición de monitoreo, el estado de rendimiento de alguna estructura del
servidor de base de datos.
La información que se presenta en estos reportes de rendimiento es la
siguiente:
?? Tipo de Monitoreo.
?? Fecha y hora del monitoreo.
?? Estructuras monitoreadas con los valores obtenidos.
?? Breve descripción de cada estructura.
La figura 36 muestra los resultados del monitoreo por petición.
Figura 36. Resultados del Monitoreo por Petición
114
2. Caso de Uso: Reportes de Desempeño
Los reportes de desempeño permiten observar el rendimiento de
alguna estructura del servidor de base de datos a lo largo del tiempo. Por
ejemplo, se puede visualizar el comportamiento del CPU en el transcurso
de un día.
Para generar estos reportes se consultan los históricos de
rendimiento, para así poder mostrar el desempeño a través del tiempo en
forma de gráfica o en forma de texto, en los caso de dispositivos que no
soporten imágenes o tablas. Existe la opción de mandar estos reportes en
forma de gráficas por correo electrónico, para que los usuarios que estén
usando dispositivos con estas limitaciones, puedan luego ver las gráficas
en alguna otra máquina o dispositivo que los soporte.
La figura 37 muestra los resultados de los reportes de desempeño.
Figura 37. Resultados de los Reportes de Desempeño
0,0
10,0
20,0
30,0
40,0
50,0
60,0
70,0
80,0
90,0
100,0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
115
En la figura 38, se muestran los resultados de los reportes de desempeño,
observados desde diferentes tipos de dispositivos.
Figura 38. Reportes de Desempeño a través de los dispositivos
3. Caso de Uso: Notificación de eventos
El objetivo de este caso es informar a los usuarios interesados, a
través de un correo electrónico, la ocurrencia de algún evento de interés y
así alertar a estos usuarios en caso de que exista algún tipo de problema
en el servidor de base de datos.
Debido a que las estructuras de rendimiento de un servidor de base
de datos están relacionadas entre si, es necesario informar el estado de
rendimiento de estructuras relacionadas con el evento de interés ocurrido.
Por ejemplo, un evento de exceso de lecturas a disco puede estar
116
relacionado con una mayor carga al CPU y de esta manera retrazar los
tiempo de respuesta.
El usuario recibirá un correo donde aparecerá:
?? El servidor que generó el evento.
?? La fecha y hora cuando se generó el evento.
?? El evento ocurrido con su respectivo valor.
?? El valor estándar sobrepasado por el evento.
?? Valores de otras estructuras relacionadas con este evento.
117
CONCLUSIONES
?? Las características del lenguaje de notación UML y la metodología
orientada a objetos, han demostrado ser una herramienta bastante
útil al momento de análisis e implementación de soluciones críticas
como la presentada en este trabajo, debido a su versatilidad y
adaptabilidad a las diferentes condiciones y problemáticas que
pudieran plantearse.
?? El uso de XML y sus extensiones, como estándar de desarrollo,
facilita el proceso de implementación de soluciones en plataformas
tecnológicas heterogéneas con un alto nivel de interacción.
?? El uso de Java como tecnología de implementación, permite que las
soluciones desarrolladas sean portables a cualquier plataforma.
?? El uso de la arquitectura web por capas implementada con
tecnología Java y XML, facilita la generación de contenido dinámico
de forma eficiente y adaptable a las diferentes plataformas de
presentación de datos basadas en las tecnologías existentes y
emergentes.
?? El desarrollo de herramientas de monitoreo de bases de datos
universales demostró ser un proceso complejo, debido a la
diversidad de las plataformas tecnológicas y de las posibles
variables a considerar, incluyendo el manejador, el sistema
operativo, entre otros, al momento de generar los datos relevantes.
118
?? La implementación de mecanismos de seguridad en ambientes de
comunicación abiertos, garantiza la confiabilidad y veracidad de los
procesos que se realizan en los mismos.
?? El uso de agentes de distribución de información, basados en
alarmas, demuestra ser un mecanismos bastante útil para la
notificación de eventos de interés y factores críticos, para la toma de
decisiones por parte de los administradores de los servidores de
bases datos que se encuentren localizados en áreas remotas a la
ubicación física de los servidores, a través del uso de dispositivos
móviles.
?? El uso de dispositivos móviles basados en las tecnologías actuales
limitan la cantidad de información a ser presentada y su formato,
por lo que se justifica el poco volumen suministrado por petición.
?? El manejo de herramientas de monitoreo ha demostrado la
factibilidad del desarrollo de modelos heurísticos de balanceo de
cargas en servidores de bases de datos distribuidos, basados en los
resultados obtenidos de éstas.
119
RECOMENDACIONES
?? Dada la universalidad de la herramienta desarrollada, ésta
contempla aquellos elementos de carácter común entre los
diferentes manejadores de bases de datos. Por consiguiente,
algunas de las características propietarias de las mismas han sido
descartadas por su diversidad y diferencia entre las plataformas. Se
plantea el desarrollo de módulos opcionales, por manejador de
bases de datos, con los que se aumentaría la capacidad de
monitoreo de la herramienta original, al incluir aquellas
propiedades o características que se deseen además monitorear.
?? Otra recomendación relacionada al sistema de monitoreo, incluye
mejoras a las alarmas, donde una de ellas pudiera ser la
incorporación de notificación a través de llamadas telefónicas de los
eventos de interés con un modulador de voces.
?? El presente trabajo incluye un modelo heurístico de balanceo de
cargas, el cual, a pesar de cumplir con los objetivos planteados, no
es fácil de implementar como sistema de información. Se
recomienda l a adaptación del modelo heurístico a un modelo de
sistemas que pueda ser implementado con mayor facilidad, para su
posterior desarrollo e incorporación a la presente herramienta.
?? El conjunto de herramientas presentadas forma parte de un
sistema de gestión de servidores, y en este caso, de bases de datos.
Se recomienda la elaboración de los módulos de análisis situacional
120
y el de ajustes, para su integración con el módulo de monitoreo,
logrando así un sistema de gestión completo.
?? Se recomienda mantener actualizada la herramienta a la par de las
tecnologías de conexión remota, para aprovechar las nuevas
características emergentes.
121
BIBLIOGRAFÍA
?? Allamaraju, S. y otros. (2001). Profesional Java Server
Programming. USA, Wrox.
?? Behr, M. y Graven, A. (2001). Choose your Weapon. PC Magazine.
?? Bobrowski, S. (2000). Oracle 8i for Linux . USA, Osborne.
?? Elmasri, R. Y Navathe, N. (1997). Sistemas de Base de Dato s
conceptos fundamentales. USA, Adisson-Wesley Iberoamericana.
?? Erciyes, K. y otros. (1995). A semi-distributed Load Balancing
Model for Parallel Real -Time Systems . Univesidad Ege, Turquia.
?? Feldkuhn, L. y Erickson, J. (1989). Event Management as a
Common Functional Area of Open Systems Management.
Integrated Network Management, Boston, North-Holland.
?? Feng, Y. y otros (2000). A Dynamic Load Balancing Algorithm
Based on Distributed Database System. IEEE.
?? Gaedke, M. y otros. (1998). Web Content Delivery to Heterogeneous
Mobile Platforms. Telecooperation office (TecO), Universidad de
Karlsruhe, Alemania.
?? Gavin, D. (2001). Performance Monitoring Tools for Linux. Link:
www.linuxjournal.com
122
?? Giordano, J. (2001). Managing rollback segments.
Link:http://searchhp.techtarget.com
?? Giguere, E. (2000). Java 2 Micro Edition. USA, Wiley.
?? Holden, D. (1989). MANDIS: Management of Distributed Systems .
(Vol. 433).
?? Imielinski, T. y Badrinath, B. (1998). Mobile Wireless Computing:
Challenges in Data Management. Department of Computer
Science, Universidad Rutgers.
?? Joyce, J. y otros. (1987). Monitoring Distributed Systems. ACM
Trans. Comput. Syst., Vol. 5, No. 2.
?? Kaljuvee, O. y otros. (2001). Efficient Web Form Entry on PDAs .
Digital Libraries Proyect (InfoLab), Universidad de Stanford,
California, USA.
?? Lina, L., Longguo L. y Yang X. (2001). An Agent-based Load
Balancing Mechanism: PLRM Using Java. Departamento de
Computer Science & Engineering, Universidad Xi’an Jiaotong.
?? Mansouri, M. y Sloman, M. (1995). Monitoring Distributed
Systems. Imperial College of Science, Technology and Medicine,
Universidad de Londres.
123
?? McDowell, C. y Helmbold, D. (1989). Debugging Concurrent
Programs. ACM Computing Surveys. (Vol. 21, No. 4).
?? McLaughlin, B. (2000). Java and XML . USA, O’Reilly.
?? Nakhimovsky, A y Myers, T. (2000). Java XML programming with
servlets and JSP. USA, Wrox.
?? Quatrani, T. (1998). Visual Modeling with Rational Rose and UML.
USA, Addison-Wesley.
?? Rahm, E. (1996). Dinamic Load Balancing i n Parallel Database
Systems. Instituto de Computer Science, Universidad de Leipzig,
Alemania.
?? Rahm, E. y Marek, R. (1995). Dinamic Multi-Resource Load
Balancing in Parallel Database Systems. Instituto de Computer
Science, Universidad de Leipzig, Alemania.
?? Rennhackkamp, M. (2001). Performance Monitoring. Link:
www.dbmsmag.com
?? Schneider, G. y Winters, J. (1998). Applying Use Cases A Practical
Guide. USA, Addison-Wesley.
?? Van Riek, M., Bernard T. y Xavier-Francois V. (1993). Monitoring
of Distributed Memory Multicomputer Programs . Center of
Research on Parallel Computation, Universidad de Rice.
124
APÉNDICE A: DIAGRAMAS DE SECUENCIA
125
Reportes del Sistema
Mantenimiento de Usuarios
: Administrador del Sistema
: Distribuidor : GestorReportes : Bitacora
1: consultarTipoCliente( )
2: desplegarPantalla( )
3: GenerarReporteSistema( )4: consultarEvento( )
5: desplegarPantalla( )
: Administrador del Sistema
: Distribuidor : GestorUsuarios : Bitacora
1: consultarTipoCliente( )2: desplegarPantalla( )
3: insertarUsuario( )
4: modificarUsuario( )
5: borrarUsuario( )
6: almacenarEvento( )7: desplegarPantalla( )
126
: DBA : Distribuidor : GestorUsuarios
1: desplegarPantalla( ) 2: autenticar( )3: consultarPerfil( )
4: desplegarPantalla( )
Autenticación
: Distribuidor : DBA
1: consultarTipoCliente( )
2: desplegarPantalla( )
: GestorReportes : Historicos : Bitacora
3: generarReporteDesempeño( ) 4: consultarHistorico( )
5: almacenarEvento( )
6: desplegarPantalla( )
7: RecibirEmail( )
Reportes de Desempeño
127
Notificación de Eventos
128
Monitoreo Periódico
129
: Administrador del S is tema
: Distribuidor : Estandar : Bitacora
1: desplegarPantalla( )
2: desplegarPantalla( )
3: modificarEstandar( )
4: ModificarFrecuencia( )
6: almacenarEvento( )
5: desplegarPantalla( )
Configurar Monitoreo
130
APÉNDICE B: TECNOLOGÍAS
131
Linux
La Herramienta se desarrolló en el sistema operativo Linux. La
razón por la cual se escogió este sistema operativo, entre los estudiados,
fueron todas las ventajas que brinda para el monitoreo de su rendimiento.
Este sistema operativo es de código abierto, lo cual significa que no tiene
ningún costo para su uso y nos permitió reconfigurarlo a nuestras
necesidades para el desarrollo y pruebas de la herramienta, también nos
brindó una gran cantidad de documentación.
Los aspectos mas importantes a monitorear que nos brinda este sistema
operativo son :
Uso del CPU: estos son los posibles estados que presenta:
?? idle: esperando, desocupado.
?? user: funciones de alto nivel, movimientos de data, matemática, etc.
?? system: realizando funciones del núcleo, I/O y otras interacciones de
hardware
?? nice: el CPU se cambia a trabajos con mayor prioridad.
Notando el porcentaje de tiempo usado en cada estado, se logra
descubrir la sobrecarga en un estado u otro. Mucho tiempo e n “idle”
significa que el sistema no está haciendo nada; mucho tiempo de sistema
indica la necesidad de dispositivos que distribuyan la carga.
Interrupciones: La mayoría de los dispositivos I/O del sistema usan
interrupciones para decirle al CPU cuando hay trabajos por hacer.
Analizando la cantidad de interrupciones puede dar una idea de cuanta
carga están manejando los dispositivos.
132
Memoria: Cuando varios procesos están corriendo y usando la memoria
disponible, el sistema se torna lento en la medida en que los procesos
crean paginaciones (paged, swapped) para poder crear espacio en la
memoria y así poder ejecutar otros procesos.
Paginaciones (Paging): Cuando la memoria disponible empieza a
disminuir, la memoria virtual crea paginaciones en el dispositivo de
“swap”, creado así espacio para procesos activos
Disk I/O : Linux mantiene estadísticas en los primeros cuatro discos; I/O
total, lecturas, escrituras, lectura y escritura de bloques.
Network I/O: Se diagnostican los problemas de red, y se examina la carga
de las interfases de red. Estas estadísticas muestran el tráfico que entra y
sale, colisiones y errores encontrados.
133
Oracle
Este manejador de base de datos se adapta perfectamente al sistema
operativo escogido y a las finalidades de monitoreo que tiene este trabajo.
Los procesos usados por Oracle pueden ser monitoreados por medio del
sistema operativo o por medio de la instancia de Oracle en sí.
Monitoreando los procesos desde la instancia de Oracle se puede obtener
mejor información de lo que de verdad están haciendo estos procesos, pero
no se puede determinar exactamente cuantos recursos están consumiendo.
Es necesario una combinación del análisis interno y externo para poder
realizar un buen monitoreo.
Monitoreo por medio de línea de comandos
Se puede obtener una gran cantidad de información acerca de los
procesos de Oracle realizando consultas a las tablas internas de
rendimiento a través de las vistas “V$”. Estas vistas, predefinidas por
Oracle, utilizan las tablas dinámicas de rendimiento.
Oracle define las siguientes categorías para su monitoreo tanto de
recursos como de problemas:
?? “Fault Management Events” : condiciones catastróficas del sistema,
pueden ser problemas en la base de datos, en el nodo de conexión u
otro aspecto que requiera de una acción inmediata del
administrador.
?? “Space Management Events” : problemas de espacio de disco.
?? “Resource Management Events” : problemas de recursos del
sistema.
134
?? “Performance Management Events”: problemas de rendimiento,
como exceso de uno del CPU o memoria cache.
Algunas vistas $V que son de mayor interés cuando se monitorean
procesos, son las siguientes:
?? V$CIRCUIT: Contiene información sobre los circuitos virtuales que
son creados por procesos de servidor.
?? V$QUEU: Contiene información sobre las colas de espera
?? V$SESS_I: Contiene información de cada sesión
?? V$SHARED_SERVE: Contiene información compartida de los
servidores
?? V$SYSSTA: Contiene la mayoría de las estadísticas del sistema en
general
Un resumen completo de la descripción que nos puede brindar el
monitoreo interno de Oracle es:
?? Número de usuarios activos
?? Números de usuarios con una sesión abierta
?? Número de usuarios realizando una operación
?? Número de usuarios en espera
?? Buffer Cache Hit
?? File I/O Rate
?? Porcentaje Cache Hit de librerías
?? Memorial total
?? Porcentaje de memoria Hit
?? Porcentaje de espera del “rollback”
?? Rango de I/O del sistema
?? Rendimiento de procesamiento
135
Java
Para complementar el uso de XML como lenguaje de programación se
utilizó Java, el cual brinda las siguientes ventajas:
Independencia de plataformas:
Hoy en día, tecnologías Java pueden ser usadas en cualquier
plataforma que tenga instalado el JVM ( Java Virtual Machine ).
Eficiencia:
Comparado con CGI, los Java servlets brindan más eficiencia en el
uso de los métodos que son requeridos por los usuarios. Los programas de
CGI necesitan crear procesos separados por cada petición de usuario. Los
Java servlets simplemente extienden una nueva tarea en el mismo
proceso para atender la petición del usuario. Esto permite que cientos de
usuarios tengan acceso al mismo servlet simultáneamente sin dejar fuera
de servicio al servidor.
Acceso a otras aplicaciones Java:
Como los servlets son una extensión de la plataforma Java, éstos
pueden acceder cualquier otra aplicación que tenga ambiente Java, como
por ejemplo, mandar y recibir E-Mail, invocar métodos de objetos remotos
usando RMI o CORBA, obtener información de directorios del sistema
operativo usando JNDI, o crear Enterprise Java Beans.
136
Reutilización de código:
Es un lenguaje completamente orientado a objetos, que permite el
reutilización de código.
Modularidad:
Cuando se crean grandes aplicaciones de server-side , los programas
tienden a crecer y complicarse. Es por esto que la aplicación se debe
romper en módulos discretos y cada uno de ellos debe tener una tarea
especifica. Esto hace que la aplicación sea fácil de mantener y entender.
