agentes inteligentes aplicados a la gestión de redes

Agentes inteligentes aplicados a la gestión de redes

1 / 53

Agentes inteligentes aplicados a la gestión de redes:

HP OpenView Operations

IBM iSeries Navigator

BMC Patrol

CA Unicenter

IBM Tivoli Enterprise Console

MICROSOFT SMS: Microsoft Operations Manager

Network Agent Research Group (NAR)

Héctor Olmedo

17 de abril de 2005

Universidad de Valladolid (2005)


2 / 53

1 Introducción.............................................................................................................. 4

2 HP OpenView Operations ........................................................................................ 4

2.1 Administración y operación.............................................................................. 6

2.2 Mapas de servicios ........................................................................................... 6

2.3 Descripción de la arquitectura .......................................................................... 8

2.4 Bases de datos, Propósitos y Localizaciones.................................................... 9

2.4.1 Consola de gestión.................................................................................. 10

2.4.2 Servidor de gestión ................................................................................. 11

2.4.3 Nodos gestionados.................................................................................. 12

2.5 Funcionalidades adicionales ........................................................................... 13

2.5.1 Monitorización del rendimiento ............................................................. 14

2.5.2 Generación de Informes.......................................................................... 15

2.5.3 Herramientas........................................................................................... 15

2.6 SMART Plug-Ins............................................................................................ 16

3 iSeries Navigator .................................................................................................... 17

3.1 ABLE.............................................................................................................. 18

3.2 Gestión centralizada ....................................................................................... 19

3.3 Evolución........................................................................................................ 19

3.4 Interfaz de usuario y funcionalidades............................................................. 24

3.4.1 Management Central............................................................................... 24

3.4.2 My Connections...................................................................................... 27

3.5 iSeries Navigator Plug-ins .............................................................................. 31

4 CA Unicenter.......................................................................................................... 32

5 BMC Patrol............................................................................................................. 35

5.1 Agente Patrol .................................................................................................. 36

5.2 Servidor de consola Patrol.............................................................................. 36

5.3 RTserver cloud ............................................................................................... 36

6 IBM Tivoli Enterprise Console .............................................................................. 37

6.1 Adapter Configuration Facility....................................................................... 38

6.2 Event adapter .................................................................................................. 38

6.3 Tivoli Event Integration Facility .................................................................... 38

6.4 Tivoli Enterprise Console gateway ................................................................ 38

6.5 Tivoli NetView............................................................................................... 39

6.6 Event server .................................................................................................... 39

6.7 Event database ................................................................................................ 39

6.8 User interface server....................................................................................... 39

6.9 Event console.................................................................................................. 39

7 Microsoft Systems Management Server: Microsoft Operations Manager ............. 41

7.1 Business Logic Layer ..................................................................................... 41

7.2 Data Layer ...................................................................................................... 41

7.3 Presentation Layer .......................................................................................... 41

7.4 Configuration Group ...................................................................................... 42

7.5 Communicaciones .......................................................................................... 42

7.6 Persistence/State ............................................................................................. 43

7.7 Rule Types...................................................................................................... 44

7.8 Monitoring Data Sources................................................................................ 45

7.9 Scripting ......................................................................................................... 45

8 Network Agent Research Group (NAR) ................................................................ 46

8.1 Programación de Agentes y comunicación entre agentes .............................. 46


3 / 53

8.1.1 Inter-Agent Communication Model (ICM) ............................................ 46

8.1.2 April........................................................................................................ 47

8.1.3 DialoX .................................................................................................... 47

8.1.4 April Agent Platform (AAP) .................................................................. 48

8.2 Soporte para agentes móviles y dispositivos intermitentemente conectados . 48

8.3 Estándares para Agentes ............................................................................... 49 9 Conclusiones........................................................................................................... 50

10 Bibliografía y referencias ................................................................................... 51

10.1 HP OpenView Operations .............................................................................. 51

10.2 IBM iSeries Navigator.................................................................................... 51

10.3 BMC Patrol..................................................................................................... 51

10.4 CA Unicenter.................................................................................................. 51

10.5 IBM Tivoli Enterprise Console ...................................................................... 51

10.6 Microsoft Systems Management Server: MOM............................................. 51

10.7 Network Agent Research Group (NAR) ........................................................ 51

10.7.1 2002 ........................................................................................................ 51

10.7.2 2001 ........................................................................................................ 52

10.7.3 2000 ........................................................................................................ 52

10.7.4 1999 ........................................................................................................ 52

10.7.5 1998 ........................................................................................................ 52

10.7.6 1996 ........................................................................................................ 53

10.7.7 1995 ........................................................................................................ 53


4 / 53

1 Introducción

El objetivo de este documento es presentar varias herramientas comerciales basadas en una arquitectura de sistemas multiagente.

Todas las herramientas revisadas, excepto el proyecto presentado en el apartado 8, son sistemas de gestión de otros sistemas es decir que pretenden facilitar la administración y operación de un grupo de sistemas de una red heterogénea u homogénea, refiriéndonos mayoritariamente a sistemas Windows y Unix (excepto IBM iSeries Navigator).

Lejos de detallar sus funcionalidades, nos vamos a fijar en el detalle de la arquitectura adoptada en cada una de dichas herramientas aunque en los dos primeros apartados detallaremos sus funcionalidades para poder hacernos una idea de lo que se busca con estos sistemas de gestión.

2 HP OpenView Operations

Esta herramienta, a la cual nos referiremos de ahora en adelante como OVO, se basa en el concepto de “gestión de servicio”, esto no es más que dar una nueva visión para gestionar la disponibilidad y el rendimiento de los servicios de negocio críticos desde la perspectiva de un usuario final.

Esta solución se orienta en el proceso de negocio o aplicación que es crítica para el éxito del negocio. Por ejemplo: Mantener operativa la web de un cliente durante el 100% del tiempo es un ejemplo de un servicio.

La fiabilidad de un servicio requiere la capacidad de recoger datos de rendimiento y relacionarlos con un servicio dado. Esto es un desafío ya que la mayoría de las aplicaciones de negocio se ejecutan en diferentes plataformas.

Para todo esto, necesitamos un software de gestión que pueda:

Detectar cuándo el rendimiento de un servicio o aplicación es pobre.

Reconocer cuándo acaba de ocurrir un problema.

Saber cómo responder a un bajo rendimiento, a quién notificar cuando hay un problema y cómo relacionar el problema con los procesos de negocio.

Informar de la resolución y documentar la solución dada al problema para utilizarla en un futuro evento similar.

Todo esto se muestra en el esquema de la ilustración 1.

OVO es una solución cliente/servidor distribuida que permite a una organización gestionar los sistemas de su cliente por servicios de negocio primeramente y desde ahí gestionar todos los elementos de los que dependen cada uno de esos servicios.

Aporta soluciones para identificar, diagnosticar, priorizar y responder a estos problemas en entornos Windows y/o Unix.


5 / 53

Ilustración 1 Esquema del proceso de gestión de sistemas en el que se basa OVO

OVO facilita además, interfaces de usuario gráficos para configurar:

_ Políticas

_ Nodos

_ Servicios

_ Herramientas

Estos componentes trabajan juntos para automatizar la detección, evaluación, y respuesta a eventos simplificando así el proceso de análisis y resolución de problemas.

Un evento es una notificación no solicitada tal como una trama SNMP, una notificación CMIP, etc. generada por un agente o proceso en un objeto gestionado o por una acción de usuario. Normalmente un evento representa un fallo, cambio de estado, violación de un límite o un problema en una operación. Por ejemplo, cuando la bandeja de papel de la impresora se queda vacía, el estado de la impresora cambia. El cambio genera un evento.

OVO utiliza agentes y políticas para ayudar a gestionar nodos y servicios.


6 / 53

Un Agente es un programa o proceso ejecutándose en un dispositivo remoto o sistema remoto que responde a peticiones de gestión, ejecuta operaciones de gestión y envía notificaciones de eventos.

En OVO los agentes están diseñados para ejecutarse en los nodos gestionados y ejecutar tareas específicas para la monitorización de servicios. Por ejemplo, se pueden indicar tareas a los agentes como monitorizar eventos SNMP en los nodos gestionados, notificar violaciones de seguridad, recoger métricas, etc. que generan mensajes ante eventos.

Un mensaje es una notificación estructurada y que se puede leer, se genera como resultado de un evento, la evaluación de uno o más eventos relativos a condiciones específicas o por un cambio en la aplicación, sistema, red o estado del servicio. Los mensajes se crean en OVO cuando las condiciones en las que se produce el evento coinciden con las condiciones de una política y cuando la política especifica que se cree un mensaje.

Los mensajes se muestran en la interfaz de mensajes y dan información detallada acerca del evento. Los mensajes se pueden configurar también para que no se muestren en la interfaz de eventos y para que se guarden en el histórico.

En lugar de un agente para todo un rango de servicios que a menudo no se usan, se instalan sólo los componentes software necesarios para que las políticas y el agente ejecuten su cometido.

2.1 Administración y operación

Por seguridad, los usuarios de OVO se agrupan por las tareas que se les permite ejecutar. Existen dos categorías de usuarios:

Administradores: son aquellos que planifican la implementación de la producción, instalan y configuran la producción, mantienen la configuración de la producción y desarrollan y despliegan las políticas necesarias.

Operadores: son quienes monitorizan el estado de un servicio o nodo gestionado utilizando vistas predefinidas por el administrador y resuelven problemas utilizando filtros apropiados definidos por el administrador.

2.2 Mapas de servicios

Los servicios son las funcionalidades que ofrecen los sistemas de información desde el punto de vista del usuario final, estas funcionalidades son provistas por uno o más componentes software dentro de un entorno informático. Por ejemplo, servicios pueden ser aplicaciones comerciales como ORACLE, aplicaciones de servidores de Internet (Microsoft Exchange) o los servicios internos de Windows que son típicamente gestionados por OVO. OVO permite construir modelos de gestión que son representaciones gráficas de los elementos que componen los servicios de una organización o cliente y que se denominan “mapas de servicios”. Este interfaz especializado permite la asociación de la infraestructura de red física con los servicios lógicos de negocio.


7 / 53

Ilustración 2 Representación genérica del servicio de e-mail de una empresa con los subservicios o

elementos dependientes

El mapa de servicio muestra una vista del negocio global en una representación basada en un modelo de jerarquía arbórea para así ilustrar las relaciones y dependencias entre los componentes del mapa.

Ilustración 3 Ejemplo de un mapa de servicios describiendo los Servicios de una red Microsoft

Windows

Utilizando la vista de mapas de servicios rápidamente podemos llegar al subservicio o dependencia origen del problema, una vez conocido éste, se pueden ver los mensajes relacionados con él y con los datos obtenidos con las herramientas y con éstas podríamos resolver el problema.


8 / 53

2.3 Descripción de la arquitectura

OVO se basa en un servidor de gestión que interactúa con varios nodos gestionados y que reporta y recibe órdenes de una o varias consolas de gestión. También es posible que existan varios servidores de gestión delegados que reporten a uno o más servidores de gestión principales.

Ilustración 4 Las políticas permiten indicar al agente en el nodo gestionado qué queremos

monitorizar explícitamente

Una política es un conjunto de especificaciones y reglas que ayudan a automatizar la administración de la red y los sistemas. Con OVO los administradores pueden desplegar políticas a varios destinos para dar una administración consistente y automatizada a través de la red. Las políticas pueden ser de descubrimiento de servicios, de revisión de ficheros de log, de captura de traps SNMP, de redireccionamiento de mensajes, de monitorización de WMI (Windows Management Instrumentation), de tareas programadas, de monitorización, etc. Despliegue es el proceso de instalar y activar software, hardware, capacidades y/o servicios para que trabajen en el entorno de negocio. En OVO las políticas y los datos relacionados se despliegan desde un servidor de gestión a uno o más nodos gestionados. Cuando una política es desplegada a un nodo gestionado, los datos son recogidos en ese nodo de acuerdo a la configuración de la política. Para mantener toda esta información consistente, se definen varias bases de datos.


9 / 53

2.4 Bases de datos, Propósitos y Localizaciones

OVO se basa en la utilización de tres tipos de bases de datos: La base de datos del Servidor de Gestión, que reside en el propio servidor de gestión. Esta base de datos contiene mensajes activos y reconocidos, gestión de políticas y datos de configuración. La base de datos del Measurement Data Collector (MDC) o recopilador de datos de rendimiento que reside en los nodos gestionados. Esta base de datos contiene datos de métricas que se recogen una vez desplegadas las políticas MDC. La base de datos “Repositorio de Objetos Estáticos” o Static Object Repository (STORE) que reside en el servidor de gestión. Esta base de datos almacena informaciones acerca del modelo de servicio tales como qué nodos están configurados y cómo debería dibujarse el mapa de servicios.

Ilustración 5 Esquema de las distintas bases de datos que forman un sistema OVO


10 / 53

2.4.1 Consola de gestión

Es una instancia del interfaz de usuario desde la cual el usuario puede controlar las aplicaciones que hacen la gestión de la red y los sistemas. Es lo que permite a los administradores y operadores monitorizar la salud de los servicios o nodos gestionados. Se puede usar una consola de administrador o una consola de operador pero sólo la consola de administrador permite ejecutar tareas de configuración, desarrollar y mantener políticas y desplegar políticas mientras que la consola de operación reporta a los operadores lo que el administrador ha designado y les permite realizar las acciones que el administrador haya dispuesto para éstos.

Ilustración 6 Aspecto de la consola de OVO

En la tabla siguiente se muestran los servicios y procesos que se han de ejecutar para la funcionalidad de la consola de gestión:

Servicio y Descripción Proceso(s) asociado(s) Descripción del proceso

OvDnsDiscoveryService OvDnsDiscoveryService Servicio de descubrimiento para encontrar nodos DNS. Da funcionalidad para leer entradas de servidores DNS.

OvServiceEditor Editor de configuración de servicios.

-- Ovunsecapp.exe Proceso usado para llamadas desde el proceso Ovpmad.exe del servicio de gestión a la consola..

-- OvPmdPolicyEditorFrame.exe Editor de políticas..

Ovconfreporter.exe Genera un inventario XML de políticas y reports de configuración de servicios..

Tabla 1 Procesos que integran la consola de gestión


11 / 53

2.4.2 Servidor de gestión

Se trata de un servidor que da servicios de gestión, procesos y/o una interfaz de usuario a los clientes. En OVO recoge eventos y datos de rendimiento y los redirige a la consola de gestión. También despliega de manera centralizada políticas y almacena definiciones y otros parámetros. En la tabla siguiente se muestran los servicios y procesos que se ejecutan en el servidor de gestión:


OvEpStatusEngine Motor de estado de OVO, este proceso calcula el estado de los servicios y nodos basándose en los mensajes activos y en la configuración de servicios. Calcula el estado de servicios, nodos, grupos de nodos y asociaciones. Busca la causa del problema “root cause” y realiza el análisis de impacto.

OvEpStatusEngine

* UNSECAPP Proceso que permite el acceso WMI al Motor de estado.

OVMSDB Solid.exe Proceso de base de datos para el servidor de Mensajes/Acciones y la gestión de políticas.

OvEpMsgActSrv Servidor de Mensajes/Acciones de OVO. Este proceso maneja los mensajes que llegan y ejecuta la ejecución de las acciones en los nodos gestionados.

Recibe y procesa mensajes OVO y acciona y notifica cambios.

OvEpMessageActionServer

* UNSECAPP Proceso que permite el acceso WMI al Servidor de Mensajes/Acciones.

OVSTODB Solid.exe Proceso de base de datos para el componente STORE.

OvMsmAccessManager OvMsmAccessManager Protege al sistema contra accesos de escritura concurrentes en la base de datos OVSTODB.

El servicio controla los accesos de lectura y escritura en el modelo de servicio.

-- Ovpmad.exe Controla la creación y almacenamiento de políticas así como el despliegue de éstas.

-- Ovpmutil.exe Herramienta de línea de comando para despliegue de políticas y carga de configuraciones.

OVAutoDiscoveryServer OVAutoDiscoveryServer.exe Administra el servidor de autodescubrimiento-

OVSecurityServer OVSecurityServer.exe Provee de servicios de seguridad.

ReportSvc ReportSvc.exe Servicio de generación de informes.

Tabla 2 Procesos que integran un servidor de gestión


12 / 53

2.4.3 Nodos gestionados

Un nodo gestionado es cualquier sistema gestionado por OVO con una CPU ejecutando un sistema operativo UNIX o Windows que además mantiene en ejecución unos servicios que se interrelacionan con el servidor de gestión, a ese conjunto de servicios lo denominamos “agente OVO”. Se describen los servicios y procesos en un sistema gestionado en la tabla siguiente:


OVMEDB Solid.exe Proceso de base de datos para MDC.

OVNPCS Ovnpcs.exe. Proceso de recogida de datos de medidas.

ARM 2.02 Transaction Event Processor

Scpmid.exe Proceso encargado recoger los eventos y transacciones ARM (APPLICATION RESPONSE MEASUREMENT).

ARM 2.02 Transaction Registration Server

Scpttd.exe Proceso servidor de registro de transacciones ARM (APPLICATION RESPONSE MEASUREMENT).

PV Adapter Service OVPVASrvr.exe Servicio que muestra los datos del MDC al interfaz de rendimiento.

opcctla Agente de Control, proceso que arranca y para otros procesos del agente.

opcacta Agente de Acción, proceso que ejecuta acciones en el nodo gestionado.

opcmsga Agente de Mensajes, proceso que maneja la comunicación de mensajes y resultados de acciones al servidor de gestión.

Opcle Proceso encapsulador de ficheros que crea un mensaje a partir de los ficheros de log del sistema operativo que se ejecute en el nodo gestionado.

opcwbemi Interceptor WBEM que crea mensajes a partir del WBEM.

Opcdista Agente de Distribución, proceso que maneja el despliegue de políticas.

opcmona Proceso agente de Monitorización que maneja rangos de medida.

opcntprocs Proceso que monitoriza procesos, es utilizado en políticas de rangos de medida para revisar si ciertos procesos están en ejecución.

HP Operations Agent

opcevti Interceptor de tramas SNMP que crea mensajes a partir de tramas SNMP.

-- ngsb.exe Despliega paquetes de instrumentación en los nodos gestionados.

Opcmsgi Interceptor de mensajes

Coda Agente de rendimiento

OvSvcDiscAgt Agente de descubrimiento de servicios.

Tabla 3 Procesos de OVO en un nodo gestionado


13 / 53

Además de estos servicios, en el nodo gestionado han de estar en ejecución servicios propios del sistema operativo que se ejecuta en el nodo gestionado, por ejemplo en un nodo gestionado basado en un sistema operativo Windows deben encontrarse en ejecución los servicios siguientes: “Event Log”/ “Registro de sucesos” “Plug and Play” “RPC Service”/ “Llamada a procedimiento remoto(RPC)” “Security account manager”/ “Administrador de cuentas de seguridad” “Net Logon”/ “Inicio de sesión de red” “Remote Registry”/ “Servicio de registro remoto” “WMI”/ “Instrumental de administración de Windows” “SNMP Trap Service”/ “Servicio de captura SNMP”

2.5 Funcionalidades adicionales

Además de la puesta en marcha del esquema de gestión definido descrito en la siguiente

ilustración:

Ilustración 7 Puesta en práctica del esquema del proceso de gestión planteado en la Ilustración 1


14 / 53

Podemos ver tres funcionalidades adicionales en OVO que dan un valor añadido al

proceso de gestión buscado:

• Monitorización del rendimiento

• Generación de informes y gráficos

• Herramientas

2.5.1 Monitorización del rendimiento

Podemos solicitar para un nodo o grupo de nodos gestionados, la generación de un

informe o gráfico acerca de la actividad de éste o éstos para un determinado tiempo o en

tiempo real.

Ilustración 8 Los datos de rendimiento recogidos desde un sistema pueden verse representados en

un gráfico


15 / 53

2.5.2 Generación de Informes

Podemos generar informes periódicos para poder comparar la actividad de nuestros

sistemas en distintos periodos de tiempo.

Ilustración 9 Ejemplos de informes

2.5.3 Herramientas

Una herramienta es un programa software, script, proceso o comando utilizado para ejecutar una tarea. Puede ser un producto complejo o un conjunto de productos, incluyendo cualquier número de programas y ficheros de configuración. Cuando una herramienta es configurada en OVO, aparece un icono en el árbol de la consola. Las herramientas pueden ser asignadas a nodos o servicios específicos. Los usuarios pueden elegir utilizar la herramienta desde la consola de herramientas o desde un nodo o servicio que la tenga asignada. Podemos utilizar herramientas que ofrece OVO para corregir problemas de sistema operativo o de aplicación en cada uno de nuestros nodos gestionados de manera que evitemos que por ejemplo ciertos operadores tengan que tener conocimientos avanzados acerca de los sistemas operativos gestionados.


16 / 53

2.6 SMART Plug-Ins

OVO también permite el uso de SMART Plug-Ins (SPI) que son paquetes de programas pre-diseñados para la gestión de una aplicación específica. Cuando se instala un SPI en un sistema OVO, éste nos aporta conocimiento, información de configuración y herramientas que nos permitirán la gestión de aplicaciones específicas como SAP R/3, Oracle, o BackOffice. Son conjuntos de políticas predefinidas para monitorizar procesos propios de la aplicación específica, de herramientas y de informes predefinidos para ayudarnos en las tareas de configuración, monitorización y documentación de dicha aplicación.

Ilustración 10 AD Topology Viewer perteneciente al Active Directory SPI

Por supuesto, aprovechando nuestra experiencia, podríamos diseñar nueva políticas, tareas, herramientas e informes que resuelvan rápidamente problemas conocidos para minimizar los estados críticos de nuestros procesos, podrían ser nuestros SPIs personalizados.


17 / 53

3 iSeries Navigator El objetivo de esta herramienta es gestionar los sistemas iSeries de una corporación de una manera centralizada. El objetivo al desarrollar esta herramienta era conseguir una interfaz de usuario actualizada con la última tecnología y una administración de múltiples sistemas de una manera sencilla.

Ilustración 11 Aspecto de la interfaz de usuario


18 / 53

3.1 ABLE

ABLE o Agent Building and Learning Environment es un entorno de trabajo basado en Java para desarrollar y desplegar agentes inteligentes, ABLE nos da un conjunto de componentes JavaBean reutilizables, llamados AbleBeans, a través de los cuales con varios métodos de interconexión flexibles para combinarlos, permite crear agentes software. Los agentes inteligentes que ayudan a IBM iSeries Navigator en la administración y monitorización de sistemas están desarrollados con ABLE. Estos agentes se ejecutan en los sistemas iSeries gestionados desde IBM iSeries Navigator. Unos realizan las tareas de recogida de información reportándola a la consola y otros ejecutan las órdenes que desde la consola se especifican para cada uno de los sistemas.

Ilustración 12 Esquema en el que se definen los agentes diseñados con ABLE para la gestión de

sistemas iSeries con la herramienta IBM iSeries Navigator

SysAdminBrainRuleSet

SysAdminActionsRuleSet

CPUWatcher

FindLargeObjectsfindDuplcateJobs

CleanupFindRunawayJobs

DiskWatcher

DiskPredictor NOJWatcher

iSeries System Administration using ABLE

SysAdmin Agent

Task/Info Agents

Action Agents


19 / 53

3.2 Gestión centralizada

Esta gestión centralizada se basa en unos conceptos básicos: • Un PC (Graphical client) provee la interfaz gráfica y la entrada/salida de las actividades de gestión. • Un Sistema central (Central system) conecta con otros sistemas (Endpoint systems). • Los otros sistemas o Endpoints son simplemente sistemas con los que el PC no necesita estar en contacto directo para “gestionarlos” • El Sistema central (Central system) es desde donde los objetos, ficheros e información son enviados desde el menú “Management central”. El Sistema origen (Source system) es el origen de los objetos, ficheros e información enviados. • El Sistema modelo (Model system) tiene todos los fixes deseados instalados o los valores del sistema fijados correctamente para cuando se quieran enviar a un Sistema objetivo (Target system). • Los Sistemas objetivo (Target systems) son aquellos a los cuales se envían objetos, ficheros e información a través del menú “Management Central”, son los destinos de los objetos, ficheros e información enviados.

Ilustración 13 Sistemas gestionados con IBM iSeries Navigator

3.3 Evolución

La evolución de esta herramienta va unida a la evolución de los sistemas iSeries de IBM (OS/400). Como se puede ver en las imágenes siguientes, evoluciona desde las tareas básicas permitidas en la primera versión:

• Gestión de procesos, • Gestión de mensajes, • Gestión de impresión, • Gestión de impresoras, • Gestión de backup, • Gestión de usuarios y grupos

hasta las tareas avanzadas desarrolladas para las últimas versiones: • Gestión de base datos • Gestión de sistemas de ficheros


20 / 53

Ilustración 14 Funcionalidades de IBM iSeries Navigator V3R7/V4R1

Ilustración 15 Funcionalidades de IBM iSeries Navigator V4R3


21 / 53




22 / 53




23 / 53




24 / 53

3.4 Interfaz de usuario y funcionalidades

Describiendo la interfaz de usuario de esta aplicación, se puede llegar a ver las ventajas que aporta al administrador u operador de sistemas iSeries la utilización de esta interfaz sobre el uso de las consolas de estos sistemas. Asimismo podremos detallar las funcionalidades que ofrece. Se puede dividir la interfaz de usuario en dos partes claramente diferenciadas, la primera es la que permite gestionar los sistemas de una manera más global (Management central) y la segunda permitirá bajar a cada uno de los sistemas de una manera particular (My Connections).

3.4.1 Management Central

3.4.1.1 Gestión de tareas (Task Activity)

Cuando se define una acción en “Management central” se crea una tarea. Desde “Task activity” se puede seleccionar el tipo de tareas a visualizar indicando su estado o indicando las de un sistema o grupo de sistemas bien las hayamos generado nosotros u otros usuarios.

Ilustración 22 Task Activity

3.4.1.2 Programación de tareas (Scheduled Tasks)

Permite ver la programación de las tareas que se han indicado realizar en una fecha y hora determinada.

Permite reutilizar tareas programadas para crear nuevas tareas en distintas fechas de ejecución o eliminar tareas programadas previamente, etc.

Ilustración 23 Scheduled Tasks


25 / 53

3.4.1.3 Definiciones (Definitions)

Definiciones son plantillas utilizadas para crear tareas usadas comúnmente.

Permiten definir procedimientos o grupos de comandos complejos para así poder utilizarlos de nuevo en un futuro.

Se pueden crear y almacenar definiciones de productos para enviarlos e instalarlos en sistemas gestionados (Endpoint systems).

Ilustración 24 Definitions

3.4.1.4 Monitorización de rendimiento (Monitors)

Permite mostrar métricas históricas de rendimiento en forma de gráfico (Graph history). Se pueden ver datos de tu sistema, monitorizaciones recogidas durante un periodo determinado o datos en tiempo real.

Los monitores de “Management Central” son muy potentes, se pueden crear monitores simples o complejos, fijar límites y automatizar ejecuciones (triggers) cuando se alcanzan esos límites. Se pueden crear monitores de sistema, trabajos, mensajes, ficheros y actividad B2B.

Ilustración 25 Monitors

3.4.1.5 Sistemas gestionados (Endpoint systems)

Una vez se descubren todos los sistemas de nuestra red y desde este apartado se permite añadirlos a la lista de “Endpoint systems”.

Ilustración 26 Endpoint systems


26 / 53

3.4.1.6 Agrupación de sistemas (System Groups)

Una vez definidos los “Endpoint systems” desde aquí se pueden agrupar, cambiar sus propiedades, etc.

También se pueden modificar los grupos, eliminarlos o crear nuevos grupos según las nuevas necesidades.

Ilustración 27 System Groups

3.4.1.7 Soporte preventivo (Extreme Support)

Permite enviar información a IBM para obtener soporte preventivo, etc.

El inventario contiene registros con información acerca del hardware, software, fixes, usuarios y grupos, valores del sistema, atributos de red, información de contacto, atributos de servicio, así como otros datos de inventario personalizados.

Tras recolectar el inventario de los sistemas, se puede enviar éste a IBM para que lo evalúe y envíe tras ello el software necesario para corregir los problemas localizados.

Ilustración 28 Extreme Support

3.4.1.8 Sistemas con particiones (Systems with Partitions)

Permite crear particiones secundarias bajo OS/400 tales como Linux, AIX, etc.

Éstas pueden ser administradas sin afectar a la partición origen, permite reiniciarlas, apagarlas o cambiar sus opciones de comunicación.

Ilustración 29 Systems with Partitions


27 / 53

3.4.1.9 Clusters

Permite configurar uno o más sistemas iSeries para trabajar juntos (en cluster) como si de un solo sistema se tratase.

Ilustración 30 Clusters

3.4.2 My Connections

Para entender este apartado de la interfaz, vamos a basarnos en la conexión de uno de los sistemas gestionados (System1) dentro del grupo de Endpoint Systems:

3.4.2.1 Operaciones básicas (Basic Operations)

Permite gestionar los mensajes, impresoras y trabajos del sistema System1 adaptando la información referente a éstos a las necesidades específicas de este sistema.

Ilustración 31 Basic Operations


28 / 53

3.4.2.2 Gestión de procesos (Work Management)

Permite gestionar la carga de CPU del sistema System1, gestionar las colas de trabajos, los propios trabajos, los subsistemas y la memoria de este sistema.

Se pueden gestionar los trabajos activos, las colas de trabajos, etc.

Ilustración 32 Work Management

3.4.2.3 Configuración y servicio (Configure & Service)

Desde aquí se ofrece gestionar el hardware y software del sistema System1, sus fixes, y particiones lógicas, etc.

Permite comparar los fixes del sistema System1 con los fixes instalados en un Sistema modelo.

Permite cambiar el sistema definiendo su entorno de trabajo, ajustando la fecha del sistema, características internacionales, etc.

Ilustración 33 Configuration & Service

3.4.2.4 Gestión de red (Network)

Para configurar las propiedades de red del sistema System1:

TCP/IP

RAS

Políticas IP

VPN

Etc.

Ilustración 34 Network


29 / 53

3.4.2.5 Gestión de seguridad (Security)

Para establecer políticas de seguridad, listas de autorización, etc. en el sistema System1

Ilustración 35 Security

3.4.2.6 Gestión de usuarios y grupos (User & Groups)

Desde aquí se gestionan los usuarios y grupos del sistema System1, se crean usuarios, se crean grupos, se copian desde otros sistemas, etc.

Ilustración 36 Users & Groups

3.4.2.7 Gestión de bases de datos (Databases)

Permite la gestión de las bases de datos instaladas en el sistema System1 permitiendo manejar tablas, vistas, journals, índices y sinónimos.

También se ofrece ver las sentencias SQL de un trabajo, estadísticas de aplicación, visualizar las relaciones de los objetos de la base de datos, etc.

Ilustración 37 Databases


30 / 53

3.4.2.8 Gestión de sistemas de ficheros (File Systems)

Aquí es donde se gestionan los sistemas de ficheros del sistema System1.

Se pueden encontrar, cambiar y copiar ficheros y directorios navegando a través de una jerarquía similar a la mostrada por Windows Explorer.

Ilustración 38 File Systems

3.4.2.9 Gestión de copias de seguridad (Backup)

Se establecen las políticas de copia de seguridad para el sistema System1

Ilustración 39 Backup

3.4.2.10 Gestión de recursos AFP (AFP Manager)

Los recursos AFP (Advanced File Printing) son funcionalidades propias de los sistemas iSeries que permiten modificar la salida de impresión del sistema System1 por ejemplo exportándola como un fichero de texto o un PDF en lugar de imprimirla.

Permite manejar fuentes de texto, definir formularios, enviar la salida de impresión como un e-mail, etc.

Ilustración 40 AFP Manager


31 / 53

3.5 iSeries Navigator Plug-ins

Plug-ins son conjuntos de clases predefinidas y métodos que iSeries Navigator lanzará en respuesta a una acción de un usuario particular. Se pueden utilizar plug-ins para añadir o modificar objetos y directorios en la jerarquía de iSeries Navigator que representarán las herramientas y aplicaciones definidas por el usuario en Java, C++ o Visual Basic. Con los Plug-ins se puede personalizar completamente el soporte para directorios y objetos añadiendo o modificando:

• Menús contextuales para lanzar aplicaciones, presentar nuevos diálogos y añadir o modificar comportamientos.

• Páginas de propiedades para dar soporte a atributos personalizados, por ejemplo

establecimiento de seguridad adicional. Se pueden añadir páginas de propiedades a cualquier objeto o directorio que tiene un conjunto de propiedades.

• Barras de tareas se pueden personalizar completamente barras de tareas y botones. • Objetos y directorios personalizados se pueden añadir directorios y objetos

personalizados dentro del árbol de jerarquía de iSeries Navigator.

Ilustración 41 Esquema de relación entre la interfaz de iSeries Navigator, los Plug-ins y las

aplicaciones de usuario personalizadas


32 / 53

4 CA Unicenter

Unicenter TNG es la heramienta de gestión de sistemas que ofrece Computer Associates. Permite gestionar sistemas Unix, Windows, Netware y OpenVMS, asimismo ofrece agentes específicos para monitorizar servicios que se ejecutan sobre estos sistemas (bases de datos, copias de seguridad, etc.).

Revisaremos someramente la arquitectura en la que se basa este sistema ya que en lo esencial no tiene grandes diferencias con respecto a sus competidores.

En la figura siguiente se muestra la arquitectura general de Unicenter TNG:

Ilustración 42 Arquitectura general de Unicenter TNG

Se pueden distinguir tres capas: • Agents: son los agentes que están recogiendo información de los nodos gestionados y

que corren en cada uno de éstos. • Management Technology: es la infraestructura que relaciona a los agentes con el

repositorio de objetos o “Common Object Repository”. • WoldView: abarca al “Common Object Repository” y a las interfaces que representan la

información que en éste se almacenan. Para entender la arquitectura de esta tecnología basada en agentes de Unicenter TNG vamos a entrar dentro de algunas de las “cajas” que mostrábamos en la ilustración anterior y a definir las relaciones entre las más representativas.


33 / 53

Los datos recogidos por los agentes de cada nodo pasan a la “Distributed State Machine” (DSM) y desde ésta a la “capa WorldView”. En ésta se representa toda la red monitorizada a través de mapas con los recursos monitorizados y sus relaciones. Dentro de esta capa como veíamos anteriormente tenemos:

• Interfaz WorldView: es realmente la representación en mapas de la que acabamos de hablar. Estos mapas derivan del “Common Object Repository”.

• Commom Object Repository: es el área de almacenamiento que mantiene la información referente a los objetos, sus propiedades y relaciones con otros objetos. Toda la información que se muestra en la interfaz WorldView debe estar definida en éste.

• WorldView API: es un conjunto de funciones que permiten a la DSM “Distributed State Machine” comunicarse con el “Common Object Repository” para almacenar información acerca de los nodos.

La DSM como veíamos en la ilustración anterior estaría ya dentro de la capa que denominábamos “Management Technology” y que por ello pasaremos a denominar “capa DSM”. Esta capa DSM puede ejecutarse en una plataforma Windows o Unix y se encarga de interpretar los datos recogidos por los agentes y de poner esta información disponible para las aplicaciones de la “capa WorldView”. Además de la DSM y de otros componentes en los que se apoya se incluyen en la “capa DSM” los componentes siguientes:

• Service Control Manager (awservices) • Distributed Services Bus (aws_orb): permite el intercambio de mensajes entre todos los

componentes de la capa “Management Technology” o “capa DSM”. • SNMP Gateway (aws_snmp): codifica las peticiones en PDUs del protocolo SNMP y las

envía a los agentes SNMP, asimismo recibe y decodifica las tramas en PDUs del protocolo SNMP que envían los agentes.

• Trap MUX (aws_listen): permite a varias aplicaciones de gestión escuchar las tramas en el mismo puerto.

• Object Store (aws_store): almacena clases de datos de los objetos gestionados que DSM utiliza para descubrir agentes y objetos gestionados en los nodos apropiados.

• Distributed State Machine (aws_dsm): controla el descubrimiento de los objetos gestionados y crea una lista de objetos gestionados con su estado actual.

• WorldView Distributed State Machine Gateway (aws_wvgate): informa al Commom Object Repository de los cambios de estado de los nodos gestionados generados por el DSM.

Estos componentes se ejecutan como procesos que pueden ser iniciados y terminados como un grupo por el Service Control Manager, éste también controla el arranque y parada de los elementos de la capa que hemos denominado “Agents” y que son los siguientes:

• Service Control Manager (awservices) • Distributed Services Bus (aws_orb): permite el intercambio de mensajes entre todos los

componentes de la capa “Agents”. • SNMP Administrator (aws_sadmin): controla la comunicación SNMP entre agentes y

DSM vía SNMP Gateway. • Individual agents: recogen y almacenan datos de gestión y envían traps al DSM.

En la imagen siguiente podemos ver todo el proceso descrito con cada uno de los actores definidos:


34 / 53

Ilustración 43 Arquitectura detallada de Unicenter TNG


35 / 53

5 BMC Patrol

Otra de las soluciones de gestión de sistemas nos la ofrece BMC Software con su plataforma Patrol.

Su filosofía es similar a las del resto de sistemas de gestión.

La arquitectura PATROL está formada por componentes que interactúan entre ellos para monitorizar bases de datos, redes y recursos del sistema. Los componentes de la arquitectura se pueden agrupar en las áreas siguientes tal y como muestra la figura siguiente:

Ilustración 44 Arquitectura PATROL


36 / 53

• Sistemas cliente de aplicación o “client application systems”: hospedan las aplicaciones de usuario tales como consolas, interfaces de usuario, visores y navegadores para monitorizar la información de gestión que ofrece Patrol. Desde las consolas se puede monitorizar toda una red o un subconjunto específico de ésta.

• Sistemas con servicios comunes de medio nivel o “mid-level common services systems”: hospedan servicios que son compartidos por los sistemas gestionados y por los sistemas cliente de aplicación. Estos sistemas pueden ser instalados en cualquier máquina de la red.

• Sistemas gestionados o “managed systems”: son los sistemas cuyos recursos son monitorizados y para ello se están ejecutando dentro de estos sistemas el agente y los módulos de conocimiento o “knowledge modules” (KMs).

5.1 Agente Patrol

El agente Patrol es el corazón de la arquitectura, es quien realmente monitoriza los sistemas gestionados. Cargan información desde los KMs, confeccionan estadísticas, envían alertas e información solicitada a las consolas Patrol, aceptan peticiones desde las consolas e inician acciones basadas en dichas peticiones.

• Utilizando la información de los KMs, un agente puede realizar las siguientes actividades:

• Detectar la presencia y el estado de una instancia de aplicación (descubrimiento)

• Recoger datos en cualquier aspecto susceptible de ser medido de una instancia de aplicación (parámetros)

• Interpretar datos utilizando reglas definidas

• Actuar como proveedor de servicios para gestión de eventos

• Almacenar datos recogidos en ficheros (historia)

• Implementar acciones predefinidas para corregir condiciones anormales (acciones de recuperación)

Los módulos de conocimiento o KMs contienen instrucciones para monitorizar un sistema operativo o una aplicación en uno o más sistemas. Los KMs del tipo “computer class” son para monitorizar sistemas operativos Unix o Windows. Los KMs del tipo “application class” monitorizan la aplicación específica para la que están diseñados y que se ejecuta sobre los sistemas operativos indicados.

5.2 Servidor de consola Patrol

Es quien comunica a los agentes que se ejecutan en los sistemas gestionados con las consolas basándose en la infraestructura que ofrece la “RTserver cloud”.

5.3 RTserver cloud

Son un conjunto de sistemas que ejecutan el software “RTserver” (Real Time server), todos ellos forman la “nube RTserver” o “RTserver cloud”.


37 / 53

6 IBM Tivoli Enterprise Console

Es la propuesta de IBM para la gestión de sistemas Unix y Windows. Aquí lo que otros sistemas de gestión denominarían “agentes” se denominan “adaptadores TME” propios de este producto y “adaptadores no-TME” que es la denominación que utiliza para los agentes de otros productos revisados anteriormente y con los cuáles también interactúa en algunos casos.

Los componentes de la arquitectura de Tivoli Enterprise Console y el camino que sigue un evento desde la fuente que lo origina hasta que se muestra a un operador, se detallan en el esquema siguiente, mostrando a su vez la relación entre dichos componentes:

Ilustración 45 Arquitectura Tivoli Enterprise Console


38 / 53

6.1 Adapter Configuration Facility

Da la interfaz de usuario gráfica (GUI) para configurar y distribuir los adaptadores TME. Se puede utilizar para crear perfiles para adaptadores y establecer opciones de configuración y distribución de adaptadores. Se hacen las configuraciones de los adaptadores desde una localización centralizada y se distribuyen los cambios a los nodos gestionados.

6.2 Event adapter

Son procesos que se ejecutan en los nodos gestionados, son específicos para la aplicación o proceso “fuente” a monitorizar y generan eventos entendibles para el “event server” a partir de la información que detectan de su fuente correspondiente.

Ilustración 46 Proceso de recogida información y envío del evento correspondiente

Se puede configurar un event adapter para descartar eventos seleccionados en lugar de redirigirlos a un event server, con esto reducimos el tráfico de red y la carga de trabajo del event server.

Se pueden crear event adapters especializados para aplicaciones y procesos propios utilizando la Tivoli Event Integration Facility.

Un event adapter envía eventos al event server utilizando una interfaz Tivoli o una interfaz no-Tivoli. La primera se ejecuta en un entorno Tivoli y la segunda se ejecuta en un entorno no-Tivoli. Ambas interfaces envían eventos utilizando un simple mecanismo de comunicación entre procesos, la diferencia entre ambas es el método utilizado para establecer la conexión: los primeros utilizan servicios que provee el marco de gestión Tivoli y los segundos utilizan mecanismos estándar de comunicación entre procesos, se elige el tipo de conexión para un entorno cuando se instala un event adapter.

Un event adapter puede almacenar eventos, esto es muy útil cuando no se puede establecer una conexión con el event server ya que se almacenan éstos para ser enviados más adelante cuando el problema se resuelva y la conexión con el event server pueda ser establecida.

Se pueden especificar uno o más event servers secundarios para un event adapter. Son un event server de backup que recibe eventos cuando la Tivoli Enterprise Console gateway no puede contactar con el event server específico para el event adapter.

6.3 Tivoli Event Integration Facility

Es una herramienta que aumenta las posibilidades de gestión de Tivoli permitiendo desarrollar a medida nuevos event adapters y permitiendo interactuar con otras herramientas de gestión.

6.4 Tivoli Enterprise Console gateway

Recibe eventos de adaptadores TME y no-TME y los redirige a un event server reduciendo las tareas de comunicación a ejecutar y reduciendo el tráfico de red.


39 / 53

6.5 Tivoli NetView

Provee la función de gestión de red monitorizando el estado de los dispositivos de red y filtra y redirige los eventos relacionados con la red (tráfico SNMP) al event server.

6.6 Event server

Es una localización centralizada para la gestión de eventos en un entorno distribuido. Cada región Tivoli contiene sólo un event server. El event server procesa la entrada que obtiene de las event consoles y actualiza la event database.

Como las event consoles leen datos de la event database, el estado de los eventos en todas las event consoles se actualiza. El event server crea una entrada en la event database por cada evento que llega y evalúa estos eventos contra una serie de reglas para determinar si el event server debería automáticamente ejecutar una tarea predefinida o modificar el evento. Si se requiere intervención humana, el event server notifica al operador adecuado. Éste ejecuta la tarea requerida y entonces notifica al event server cuándo la condición que causó el evento ha sido resuelta.

6.7 Event database

Se utiliza un sistema de gestión de base de datos relacional (relational database management system o RDBMS) externo para almacenar una gran cantidad de eventos recibidos al que denominamos event database. Para acceder a esta base de datos utilizamos el RDBMS Interface Module (RIM) que es un componente del Tivoli Management Framework.

6.8 User interface server

El UI server es un proceso que da servicios de comunicación entre el event server y las event consoles.

Se comunica con el dispatch engine cuando necesita contactar con el event server. The UI server provides transaction locking for event console status updates and prevents multiple event consoles from responding to the same event.

Actualiza automáticamente el estado de los eventos en todas las event consoles redirigiendo los cambios en los eventos desde las event consoles hasta el dispatch engine que reenvía los cambios a la event database. Por ejemplo, cuando un operador reconoce un evento, el UI server automaticamente actualiza el estado del evento en cada event console que contiene el evento.

El UI server también provee un conjunto de comandos que permiten al operador cambiar cualquier atributo del evento, listar los eventos en un event group específico y mostrar un mensaje en el escritorio del operador.

El UI server puede instalarse en cualquier nodo gestionado en la region Tivoli, pero solo en uno. No tiene porqué estar localizado en el mismo host que el event server.

6.9 Event console

Provee una GUI que los operadores pueden utilizar para ver y responder a eventos. Existen dos versiones de la event console: una versión Java y una versión Web.

Los administradores deben usar la versión Java para ejecutar tareas de configuración. Administradores y operadores deben usar la versión Java para iniciar funciones de Tivoli NetView y ejecutar tareas locales automatizadas.

Para gestionar eventos, administradores y operadores pueden utilizar cualquiera de las dos versiones o incluso ambas a la vez.


40 / 53

Una event console muestra una ventana para monitorizar event groups, que los operadores pueden utilizar para monitorizar y responder a eventos.

Un event group es un conjunto de eventos que cumplen un cierto criterio de filtrado. Un administrador define event groups y los asigna a event consoles para cada operador.

Los operadores pueden tener vistas de eventos compartidas o independientes.

El UI server controla que múltiples event consoles no actualicen el mismo evento y se encarga de actualizar el estado del evento en todas las event consoles. Por tanto, solo un operador responde y trabaja en la resolución del problema.


41 / 53

7 Microsoft Systems Management Server: Microsoft Operations Manager

MOM es la aplicación basada en reglas para gestionar plataformas Windows y sus aplicaciones. Se basa en la arquitectura distribuida multitier de Microsoft que consiste de múltiples componentes que residen en las diferentes capas.

7.1 Business Logic Layer

Esta capa la forman un agente y un servidor MOM. Un agente es un servicio Win32 de Microsoft que se ejecuta en cada computador a monitorizar. Captura información del servidor gestionado, aplica reglas de procesamiento a la información recogida y envía la información a un Consolidator. El servidor MOM consiste en el Consolidator y en el Agent Manager (CAM) además de los componentes Data Access Server (DAS).

CAM es un servicio Microsoft Win32 que se ejecuta en un número seleccionado de servidores de la red a gestionar. Un Consolidator incluye un componente conocido como un Agent Manager, que descubre, instala, desinstala, y escanea atributos de agentes. Un Consolidator también actúa como un agente en el ordenador en el cual se ha instalado y envía los datos recogidos a la base de datos a través del DAS.

El DAS consiste de varios componentes Component Object Model + Enterprise Services (COM+) que se ejecutan en un número seleccionado de ordenadores de la red. El DAS controla el flujo de datos entre la base de datos, los Consolidators, la MOM Administrator console y la MOM Web console.

7.2 Data Layer

Dentro de esta capa está la base de datos que permite el almacenamiento de información de configuración y datos recopilados para un configuration group.

MOM requiere Microsoft SQL Server 2000 o MSDE.

7.3 Presentation Layer

Dentro de esta capa está la MOM Administrator console, la MOM Web console, y MOM Reporting.

La MOM Administrator console monitoriza datos, crea reglas, y configura los componentes MOM. La consola está basada en la tecnología Microsoft Management Console (MMC).

La MOM Web console da una vista de los datos MOM almacenados en la base de datos desde cualquier plataforma que ejecute Windows con Microsoft Internet Explorer versión 4.01 o superior. La MOM Web console también ofrece monitorización remota y acceso fácil para administradores sin un puesto fijo en la red.

MOM Reporting ofrece informes de operaciones y disponibilidad, además de gestión de rendimiento y gráficos de capacity-planning a partir de la información almacenada en la base de datos.

La imagen siguiente muestra como todos los componentes de MOM trabajan juntos.


42 / 53

Ilustración 47 Componentes de MOM e interacciones entre éstos

7.4 Configuration Group

La unidad de administración en MOM se denomina configuration group. Consiste de un grupo de ordenadores que contienen los siguientes componentes:

● Una base de datos

● Uno o más servidores MOM

● Uno o más agentes MOM

El nombre del configuration group debe ser único dentro de una red y no puede ser cambiado sin reinstalar MOM. El término “MOM server” o “DCAM” se refiere a los components DAS y CAM en un servidor físico.

7.5 Communicaciones

Esta sección describen los diferentes mecanismos de comunicación entre los componentes MOM.

Ilustración 48 Mecanismos de comunicación de los componentes de MOM


43 / 53

El componente CAM es un servicio Win32 llamado el OnePoint service. Ejecuta funcionalidades de de Consolidator, Agent Manager y agente local. Las funcionalidades de Agent Manager incluyen descubrimiento, instalación, o eliminación del agente, y escaneo de grupos de ordenadores basándose en atributos específicos. El Agent Manager principalmente utiliza llamadas a procedimiento remoto (RPCs) para ejecutar sus funciones y requiere privilegios de administrador local en cada servidor gestionado para ejecutar estas funciones.

Las funcionalidades del Consolidator incluyen el envío de reglas y configuraciones a agentes, la recepción de datos de los agentes, y la inserción de los datos en la base de datos a través del DAS. El Consolidator también obtiene nuevas configuraciones almacenadas en la base de datos a través del DAS. El Consolidator se comunica con el DAS a través del distributed component object model (DCOM), y el DAS se comunica con la base de datos a través del OLE database. La autenticación de seguridad se ejecuta en esta function a través de los perfiles COM+, que son mapeados a los grupos de OnePoint local security.

La comunicación entre el agente y el Consolidator es TCP encriptado (pero no autenticado) basada en sockets. Por defecto, utiliza el puerto 1270 para comunicación encriptada y el puerto 51515 para comunicación desencriptada. El agente es siempre quien inicia la comunicación con el Consolidator por razones de seguridad.

En un intervalo configurable (por defecto – 300s), los agentes envían información “heartbeat” al Consolidator. Esta information “heartbeat” incluye la versión de la última configuración del agente. En este momento, el agente descarga sus colas. Tipicamente, existen tres colas de agente: una cola de alertas, una cola de datos numéricos y una cola de eventos. La cola de alertas es siempre descargada la primera, porque los datos que contiene han sido ya procesados y priorizados como alertas y deben ser enviados inmediatamente a la MOM Administrator console.

Cuando el agente ha descargado todas sus colas, el Consolidator verificará si la configuración del agente está actualizada. Si no es así, el Consolidator enviará la última información de configuración. El agente almacena la nueva información de configuración en el ordenador local. El Consolidator también guarda la marca de tiempo de la última vez que se comunicó con el agente y muestra esta información como la última información de contacto en la MOM Administrator console.

El agente local no solo actúa como un agente en el servidor CAM también tiene como función ser un agente de redirección enviando alertas a otros Consolidators en diferentes configuration groups.

La MOM Administrator console se comunica con la MOM database a través del DAS utilizando DCOM. La MOM Web console se comunica con los components MOM Web console server a través de standard Hypertext Transfer Protocol (HTTP), esto requiere además el componente Microsoft Internet Information Services (IIS). El MOM Web console server se comunica con la base de datos a través de DAS utilizando DCOM.

Reporting está basado en Microsoft Access y se comunica directamentecon la base de datos MOM database a través del open database connectivity (ODBC), a través del componente DAS.

7.6 Persistence/State

El agente almacena información en ficheros cola, en el registro, y en ficheros de configuración.

Los ficheros cola contienen datos que han sido recogidos y datos preparados para ser enviados.

El registro contiene información que incluye el Consolidator apropiado al que enviar datos y el nombre del configuration group.


44 / 53

Los ficheros de configuración contienen información acerca de reglas a procesar y otra información que un agente necesita para ejecutar. Estos ficheros se actualizan periódicamente a través de la operación “heartbeat”.

El Consolidator contiene todos los ficheros que están en el agente porque el Consolidator contiene un agente para gestionarse él mismo. Además, tiene un fichero cola que contiene los datos recibidos del agente. El registro en el Consolidator contiene información tal como la base de datos utilizada, qué DAS fue el último que utilizó e información de workflow que necesita para dar respuestas. Si un Consolidator está configurado para redirigir alertas, habrá información de workflow adicional en el registro de un Zone Consolidator para asegurarse de que los datos se redireccionan correctamente. El Consolidator también contiene ficheros cola para grandes inserciones de datos.

Los servidores IIS tienen muchos de los componentes DAS en añadidura a los reports generados por el componente MOM Reporting. El registro en los servidores IIS contiene información tal como qué DAS será utilizado para comunicarse con la base de datos.

MOM soporta envío de datos certificado a través del uso de reconocimiento. Existen varios ficheros cola para almacenar datos e información de configuración en el agente y en el Consolidator. El agente almacena datos en un fichero cola antes de enviarlos al Consolidator. El Consolidator almacena los datos recibidos del agente en un fichero cola antes de insertar los datos en la base de datos. Los datos en el fichero cola del agente no son borrados hasta que el agente recibe un reconocimiento por parte del Consolidator indicando que el datos ha sido insertado correctamente en la cola del Consolidator.

En la imagen siguiente se muestran los distintos sitios en los que la información es almacenada en los componentes MOM:

Ilustración 49 Localizaciones de los almacenes de información en MOM

7.7 Rule Types

Con las reglas de MOM los administradores pueden especificar cómo MOM recoge, maneja, responde a la información y la almacena en la base de datos. Cuando se cumple la condición de una regla, MOM ejecuta las acciones asociadas a la condición de la regla. Cada regla tiene una acción implícita, podríamos hacer tres grandes grupos:

1. Event processing o de procesado de eventos, que a su vez pueden ser:

• Event Collection o de recogida de eventos

• Missing Event o de eventos no producidos


45 / 53

• Event Consolidation o de consolidación de eventos

• Event Filter o de filtrado de eventos

• General Event Processing o de procesado de eventos generales

2. Alert processing o procesado de alertas

3. Performance processing o procesado de datos de rendimiento, que a su vez son:

• Performance Collection o de recogida de datos de rendimiento

• Performance Threshold o de límites de rendimiento

7.8 Monitoring Data Sources

MOM recoge datos de instrumentación de una gran variedad de fuentes a través de una variedad de proveedores MOM. Cada regla de procesamiento necesita especificar un tipo de proveedor. Existen los siguientes tipos de proveedores:

• Event Log o visor de eventos: Application, System, Security, Domain Name System (DNS), File Replication service (FRS) y Directory service logs

• Windows NT Performance Counters

• Application Logs: IIS, WWW, Gopher, FTP, ILS, SQL Server 6.5 trace log files, Generic single line y SYSLOG port

• WMI Events

• WMI Numeric Events

• Timed Events

• SNMP Trap

7.9 Scripting

A través del IActiveScript engine MOM provee capacidades de scripting para customizar la monitorización y la respuesta a eventos.

Los scripts se ejecutan o son disparados cuando se cumplen determinadas reglas. Se almacenan en la base de datos y son ditribuídos pòr el Consolidator junto a las reglas de procesamiento. Estos scripts pueden ser de varios tipos:

• Scripts basados en variables de estado o State Variables

• Scripts de respuesta o Response Scripts

• Scripts programados o Timed Scripts


46 / 53

8 Network Agent Research Group (NAR)

A diferencia de los apartados anteriores, no vamos a describir ninguna herramienta de gestión de sistemas, vamos a detallar las herramientas que ponen a nuestra disposición un grupo de investigadores. A partir de dichas herramientas podríamos construir nuestra propia herramienta de gestión de sistemas.

Este grupo es parte de Fujitsu Laboratories of America y se constituyó en Septiembre de 1997 para investigar y desarrollar nuevas tecnologías para dar apoyo a aplicaciones distribuidas en redes globalmente interconectadas, tales como Internet.

Todo el software se ha publicado como Open Source bajo una licencia GNU en el Web site SourceForge dentro del proyecto “Network Agents”.

La relación de documentos publicados por los integrantes de este grupo y sus colaboradores se indica en el apartado de bibliografía correspondiente.

El grupo NAR está envuelto en la investigación de las siguientes áreas:

8.1 Programación de Agentes y comunicación entre agentes

Han desarrollado un conjunto de herramientas para ayudar a los programadores que quieran desarrollar aplicaciones basadas en agentes distribuidos, éstas compreden:

8.1.1 Inter-Agent Communication Model (ICM)

Es un sistema de mensajería asíncrona para agentes. Su objetivo es ser utilizado como mecanismo de transporte para lenguajes de comunicación entre agentes (ACLs: agent communication languages), tales como KQML y el ACL de FIPA.

ICM consta de un protocolo y una implementación basados en una modificación del modelo de comunicaciones April. El núcleo de la funcionalidad del ICM reside en un proceso diferenciado llamado servidor de comunicación (CS: communication server). La función de un CS es ofrecer:

Facilidades de asignación de nombres para Agentes, tales como asignación de nombres únicos globales, asignación de aliases y registro.

Facilidades de mensajería, tales como codificación de mensajes, transporte, encolado y redirección.

ICM también da soporte específico para agentes móviles y para dispositivos intermitentemente interconectados, tales como ordenadores portátiles y PDAs (personal digital assistants).

El API de ICM está implementado actualmente para April, C y Java y da una serie de funciones y procedimientos que han de ser invocados por una plataforma de agentes haciendo referencia a cada uno de los agentes soportados por la plataforma consiguiendo así:

1. Una arquitectura de almacenamiento y reenvío que permite una verdadera comunicación asíncrona entre agentes ya que el agente receptor no tiene que estar on-line cuando se le envía un mensaje.

2. Los mensajes se codifican de un modo estructurado eficiente permitiendo representar listas, tuplas, strings, código de programas y estructuras circulares.

3. La naturaleza auto-parseable del código permite formas de comunicación extensibles y abiertas sin requerir el uso de mensajes de información con formato predefinido a ser compilados dentro de las aplicaciones.


47 / 53

4. El uso de CSs permite a las plataformas agente individuales comunicarse con gran número de sistemas distintos minimizando el uso de recursos.

5. El uso de manejadores de agentes únicos globalmente permite al ICM enrutar mensajes sin requerir que cada plataforma agente tenga que tener esta capacidad.

6. El uso de aliases para los manejadores de agentes permite la migración de agentes de una manera controlada.

7. El uso de hosts virtuales permite el uso de dispositivos intermitentemente conectados tales como PDAs de una manera transparente a plataformas agente individuales y a aplicaciones agente.

8. El API de ICM permite acceso multilenguaje a la plataforma agente via comunicación por mensajes.

9. ICM se asienta lógicamente bajo el lenguaje de comunicación de un agente: especifica cómo los mensajes pueden ser construidos y transportados entre plataformas agente mientras que permite a potentes mensajes del estilo KQML ser construidos en términos de componentes ICM más simples.

Podríamos decir que ICM da una infraestructura de “correo electrónico” entre agentes para lenguajes de comunicación tales como KQML o FIPA ACL.

8.1.2 April

Es un lenguaje de programación para escribir aplicaciones basadas en agentes, fue el origen de ICM.

Contiene facilidades para definir procesos, para permitir a los procesos comunicarse entre ellos y tiene potentes capacidades para manejar estructuras de datos y expresiones con el objetivo de dar un vehículo para la programación simbólica en un entorno distribuido. Además de sus aspectos computacionales, es tipado, incorpora también capacidades sintácticas, es de alto nivel e incluye un sublenguaje de macroprocesamiento.

El sistema tipado construido dentro de April sirve para muchos propósitos. Además del tradicional papel del tipado como una técnica que ayuda a asegurar que los programas funcionan a la primera, los tipos en April también son la base del reconocimiento de patrones en mensajes y operaciones de búsqueda en listas de valores estructurados.

Algunas de sus capacidades son utilizadas para programación estructurada (módulos con registros de funciones y procedimientos) y permite al código pasar de un proceso a otro. Es usado también para implementar objetos estáticos (estructuras de datos abstractas) que son módulos con estado.

La facilidad de macroprocesamiento es importante para la usabilidad del lenguaje. Con ella, es posible construir capas de lenguaje por encima del lenguaje básico para incorporar capacidades sintácticas adicionales que son añadidas al lenguaje base en tiempo de compilación. Se ha usado esto para definir una extensión orientada a objetos de April y se ha usado para definir una extensión estilo Prolog para definir y consultar una base de conocimiento de hechos y reglas dentro de un proceso u objeto.

8.1.3 DialoX

Es un gestor de interfaces de usuario o un servidor de HCIs distribuídos basado en XML. En lugar de construir en la aplicación todo el código necesario para construir interfaces de usuario gráficos, esta tarea se delega al servidor. Las aplicaciones interactúan con el servidor a través de un protocolo de propósito especial que permite a la aplicación solicitar que una ventana


48 / 53

particular se construya y notificar a la aplicación a través de un mensaje que un usuario invoca a alguna acción a través de la ventana.

De esta manera se permiten desarrollar rápidamente interfaces de usuario gráficos y se permite que el programador enfoque su esfuerzo a la estructura del programa.

Dialox utiliza una notación basada en XML para describir las ventanas que forman la interfaz de usuario y también en el protocolo de interacción entre la aplicación y el servidor DialoX. Esto permite que podamos utilizar un parser XML estándar con la librería DialoX.

DialoX se basa en GTK/Gnome y es totalmente compatible con Gnome.

8.1.4 April Agent Platform (AAP)

Es una plataforma de agentes y un entorno de desarrollo de agentes que cumple los requisitos del estándar FIPA 2000 y está desarrollada por Fujitsu Laboratories of America.

La versión 0.9 de AAP requiere April e ICM y ofrece:

• Soporte para el Stanford’s Java Theorem Prover (JTP) para razonamiento sobre hechos DAML+OIL y KIF.

• Soporte para Web Services (WSDL parser, transporte SOAP y registro UDDI).

• Soporte para bases de datos MySQL y Postgres.

• Soporte para HTTPS.

• Un Gestor de Plataforma Gráfico para gestionar visualmente agentes (requiere DialoX).

• Una Herramienta para Visualización de Ontologías para representar visualmente las estructuras de ontología DAML+OIL/RDFS (requiere DialoX).

• Un nuevo módulo de transporte que encola mensajes a la misma dirección de transporte (lo cual ayuda si una dirección de transporte en particular está atascada)

• Lenguaje de texto plano

• Agentes adicionales y ejemplos

• Varios fixes a bugs detectados.

• AAP, April e ICM están soportados en entornos basados en UNIX, tales como Linux, Solaris y MacOS X y se está trabajando en una versión para Windows que se ejecutará bajo RedHat’s Cygwin.

8.2 Soporte para agentes móviles y dispositivos intermitentemente conectados

El grupo se encuentra en el proceso de utilización de tecnologías como APRIL e ICM para proveer soporte a agentes móviles y a usuarios de dispositivos intermitentemente conectados, tales como PDAs y ordenadores portátiles.

Se consideran tres formas diferentes de movilidad, tales como:

• Migración de Agente, que permite a un agente moverse entre nodos de una red.

• Clonación de Agente, que permite a un agente crear un duplicado exacto de sí mismo.


49 / 53

• Invocación de Agente, que permite a un agente crear una instancia de un nuevo agente.

Se está investigando en aplicaciones prototipo que utilizan estos tres aspectos de movilidad, así como la gestión de configuración de agentes (agent configuration management). Esto es un aspecto crítico en la gestión de grandes sistemas basados en agentes, especialmente cuando abarcan gran número de agentes distribuidos sobre muchos ordenadores. Aspectos relacionados con esto serían:

Ciclo de vida del Agente: En muchas aplicaciones es importante ser capaz de asegurar que ciertos agentes pueden ser controlados de modo remoto: incluyendo el reinicio de agentes cuando éstos han muerto por alguna razón. Asimismo, es importante para cualquier sistema de gestión de configuración de agentes ser capaz de iniciar, parar y reiniciar otros agentes, posiblemente desde un sitio remoto.

Dependencias de Agentes y asignación de recursos: En algunas situaciones, los agentes se apoyan en otros agentes u otros recursos disponibles en el contexto en el que se ejecuta el agente. Esta relación está dentro del ámbito de cualquier sistema de gestión de configuración de agentes y puede ser necesario para tal sistema ser capaz de dirigir tanto los recursos relativos al agente como los no relacionados con el agente para ser capaz de gestionar el agente.

Monitorización de Agentes: En sistemas complejos, la gestión de errores y el reporte de alarmas están también muy ligados a la cuestión de la configuración del agente. Además, la búsqueda de errores es decir, encontrar qué agente es realmente la causa de una alarma, puede ser importante. Por todo ello, métodos estandarizados para controlar el flujo de alarmas y de monitorización del estado de agentes gestionados deberían ser considerados a estar dentro del ámbito de la gestión de configuración de agentes.

8.3 Estándares para Agentes

El grupo NAR está envuelto activamente en el grupo de estándares de la FIPA (Foundation for Intelligent Physical Agents: http://www.fipa.org/ ) y ayuda a confeccionar el borrador de las especificaciones para la próxima versión del estándar FIPA, particularmente en el área de comunicación entre agentes y agentes móviles.

Contribuye también con el Agent Working Group (http://www.objs.com/agent/index.html ) que se engloba dentro del OMG (Object Management Group: http://www.omg.org/ ) para ayudar a desarrollar una arquitectura de agentes y un marco para un entorno CORBA.

También lidera y coordina el grupo Sun’s Java Community Process para el desarrollo de estándares para JAS (Java Agent Services: http://jcp.org/en/jsr/detail?id=087 ) que es una implementación de la especificación de la Arquitectura Abstracta de la FIPA (FIPA’s Abstract Architecture specification: http://www.fipa.org/specs/fipa00001/ ) que ayudaron a co- desarrollar.


50 / 53

9 Conclusiones Una vez mostradas las características de cada una de estas herramientas de gestión, podríamos decir que encontramos diversas similitudes a la hora de dar respuesta a la pregunta ¿Qué quiero hacer? por parte de los propios diseñadores de todas las herramientas. Las diferencias sólo se encuentran al dar respuesta a la pregunta ¿Cómo lo hago? por parte de dichos diseñadores. Esto en parte es debido a las características propias de los sistemas operativos a gestionar con cada una de las herramientas presentadas. Características que han de tenerse en cuenta a la hora de desarrollar estas herramientas de gestión y que marcarán su implementación. Como punto común se puede establecer la arquitectura en la que se basan todas las herramientas mostradas: en todas existe el concepto de gestión centralizada basada en un servidor central y una interfaz que coordinados gestionan los sistemas en los que se ejecutan los agentes propios de cada herramienta. Los diseñadores de cada empresa han buscado soluciones a problemas comunes:

• Identificación y localización de agentes • Comunicación entre agentes • Comunicación entre Servidor o Gestor y Agentes • Monitorización del estado de los agentes • Arranque y fin de las instancias agente • Movilidad de los agentes • Etc.

Todas las soluciones comerciales aprovechan los servicios ofrecidos por los sistemas operativos para resolver estas cuestiones. La propia interfaz de cada una de las herramientas es otra diferencia en sí misma aunque todas ellas quieren dar una visión global. Finalmente señalaremos que no se ha encontrado en la documentación referente a las plataformas comerciales de gestión de sistemas ninguna referencia a estándares relativos a agentes inteligentes y sistemas multiagente. Por lo que podríamos afirmar que únicamente una plataforma de gestión de sistemas basada en las herramientas presentadas en el apartado 8, cumpliría algunos de los estándares definidos.


51 / 53

10 Bibliografía y referencias

10.1 HP OpenView Operations

http://www.openview.hp.com/

10.2 IBM iSeries Navigator

http://www.ibm.com//iseries/

J.P. Bigus, D.A. Schlosnagle, J.R. Pilgrim, W.N. Mills III, Y. Diao, “ABLE: A toolkit for building multiagent autonomic systems”, IBM SYSTEMS JOURNAL, VOL 41, NO 3, 2002.

J.P. Bigus, J. Bigus, “Constructing Intelligent Agents Using Java, 2nd Edition”, WILEY 2001

10.3 BMC Patrol

http://www.bmc.com

10.4 CA Unicenter

http://www.ca.com

10.5 IBM Tivoli Enterprise Console

http://www.ibm.com/software/tivoli/library/

10.6 Microsoft Systems Management Server: MOM

http://www.microsoft.com/smserver/

10.7 Network Agent Research Group (NAR)

http://www.nar.fujitsulabs.com/icm/

10.7.1 2002

Ceccaroni, L., Cortes, U. and Sanchez-Marre, M., OntoWEDSS: Augmenting Environmental Decision-Support Systems with Ontologies. Fujitsu Laboratories of America Technical Memorandum FLA-NARTM02-09. PDF.

Dale, J., Levine, D., McCabe, F. G., Arnold, G., Lyell, M. and Kuno, H., Advanced Web Services. Fujitsu Laboratories of America Technical Memorandum FLA-NARTM02-08, Fujitsu Laboratories of America, September 2002. PDF.

Dale, J., Willmot, S. and Burg, B., Agentcities: Challenges and Deployment of Next-Generation Service Environments. In: Proceedings of the Pacific Rim Intelligent Multi-Agent Systems Conference 2002, Tokyo, Japan, August 2002. PDF.

Dale, J., Willmott, S. and Burg, B., Agentcities: Building a Next-Generation Service Environment. In: IEEJ Special Issue on Agents and the Internet, August 2002. PDF.

Willmott, S., Dale, J. and Charlton, P., Agent Communication Semantics for Open Environments. Fujitsu Laboratories of America Technical Memorandum FLA-NARTM02-05, Fujitsu Laboratories of America, May 2002. PDF.


52 / 53

Ceccaroni, L. and Ribiere, M., Experiences in Modeling Agentcities Utility-Ontologies with a Collaborative Approach. In: Ontologies in Agent Systems Workshop, Autonomous Agents and Multi-Agent Systems Conference 2002, Bologna, Italy, July 2002. PDF.

Dale, J. and Ceccaroni, L., Pizza and a Movie: A Case Study in Advanced Web Services. In: Agentcities: Challenges in Open Agent Environments Workshop, Autonomous Agents and Multi-Agent Systems Conference 2002, Bologna, Italy, July 2002. PDF.

Willmott, S., Somacher, M., Constantinescu, I., Dale, J., Poslad, S., Bonnefoy, D., Picault, J. and Tan, J., The Agentcities Network Architecture. In: Agentcities: Challenges in Open Agent Environments Workshop, Autonomous Agents and Multi-Agent Systems Conference 2002, Bologna, Italy, July 2002. PDF.

Ceccaroni, L., Cortes, U. and Sanchez-Marre, M., OntoWEDSS: an Ontology-Underpinned Decision-Support System for Wastewater Management. In: International Environmental Modelling and Software Society Conference, Lugano, Switzerland, June 2002. PDF.

10.7.2 2001

Willmott, S., Dale, J., Burg, B., Charlton, P. and O’Brien, P., Agentcities: A Worldwide Open Agent Network. In: AgentLink News, Issue 8, November 2001. PDF.

Dale, J. and Mamdani, E., Open Standards for Interoperating Agent-Based Systems. In: Software Focus, 1(2), John Wiley and Sons, 2001. PDF.

Burg, B., Dale, J. and Willmott, S., Open Standards and Open Source for Agent-Based Systems. In: AgentLink News, Issue 6, January 2001. PDF.

10.7.3 2000

Dale, J., The April Distributed Communication HowTo. Fujitsu Laboratories of America Technical Memorandum FLA-NARTM00-01, Fujitsu Laboratories of America, January 2000. HTML, PDF.

10.7.4 1999

McCabe, F. G. and Dale, J., Agent Configuration Management. Fujitsu Laboratories of America Technical Memorandum FLA-NARTM99-04, Fujitsu Laboratories of America, November 1999. HTML, PDF, Compressed Postscript.

Dale, J., Agent Naming. Fujitsu Laboratories of America Technical Memorandum FLA-NARTM99-03, Fujitsu Laboratories of America, November 1999. HTML, PDF, Compressed Postscript.

Dale, J., ICM Pocket Reference. Fujitsu Laboratories of America Technical Memorandum FLA-NARTM99-02, Fujitsu Laboratories of America, April 1999. HTML, PDF, Compressed Postscript.

Dale, J., April 4 Pocket Reference. Fujitsu Laboratories of America Technical Memorandum FLA-NARTM99-01, Fujitsu Laboratories of America, March 1999. HTML, PDF, Compressed Postscript.

McCabe, F. G., April—An Agent Programming Language for the Internet. Unpublished paper, February 1999.

10.7.5 1998

McCabe, F. G. and Dale, J., Asynchronous Messaging. Fujitsu Laboratories of America Technical Memorandum FLA-NARTM98-04, Fujitsu Laboratories of America, April 1998. HTML, PDF, Compressed Postscript.


53 / 53

Dale, J. and McCabe, F. G., Agent Management Support for Mobility. Fujitsu Laboratories of America Technical Memorandum FLA-NARTM98-05, Fujitsu Laboratories of America, April 1998. HTML, PDF, Compressed Postscript.

10.7.6 1996

Wada, Y., Kawamura, A., McCabe, F. G., Shiouchi, M., Teramoto, Y., Takada, Y., An Agent Oriented Schedule Management System—IntelliDiary. In: Proceedings of the First International Conference on the Practical Application of Intelligent Agents and Multi-Agent Systems (PAAM), pp.655—667, April 1996.

10.7.7 1995

McCabe, F. G. and Clark, K. L., April—Agent Process Interaction Language. In: Intelligent Agents, Lecture Notes in Artificial Intelligence, 890, Wooldridge, M. J. and Jennings, N. R., Eds, pp.324—340, Springer-Verlag, 1995.

Takada, Y., McCabe, F. G., Wada, Y., Multi-Agent Oriented Programming Language—April. In: Proceedings of the 51st International IPSJ Conference, 1995.