INTEROPERABILIDAD ENTRE LOS MARCOS DE GESTION SNMP Y CORBA (GATEWAY)

Transcripción

1 UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO DECANATO DE CIENCIA Y TECNOLOGIA MAESTRIA CIENCIA DE LA COMPUTACION MENCION REDES DE COMPUTADORAS INTEROPERABILIDAD ENTRE LOS MARCOS DE GESTION SNMP Y CORBA (GATEWAY) Autor: Elizaul Lopez

2 Barquisimeto 15 de Octubre 2010 Abstract This paper based on the understanding and comprehension of a gateway to provide two different platforms such as SNMP (Simple Network Management Protocol) and CORBA distributed management system (commom Object Broker Architecture) that aims to improve the integration of applications to reach this section first described in a concise comparison of both architectures and interaction of SNMP-CORBA gateway.

3 INTRODUCCION En la actualidad la necesidad de implementar y expandir aplicaciones hacia un universo informático moderno y avanzado, está forzando a los desarrolladores de aplicaciones a trabajar en la interacción entre distintas infraestructuras de gestión de red, entre la arquitectura tradicional con SNMP y el novedoso (CORBA) para un mayor aprovechamiento de los diferentes sistemas operativos, plataformas, escalabilidad de usuarios, paradigmas de programación y sobre todo una mejor gestión de fallas en forma remota. La aparición de entornos distribuidos supone el reto de conseguir una visión global del comportamiento de las aplicaciones a partir de la información de gestión, de allí la importancia de conocer las interacciones entre los distintos dominios de gestión. Dichos intercambios de información son posibles, a través de mecanismos como Gateways o Pasarelas encargadas de traducir la información proveniente de sistemas heterogéneos. En este articulo se considera el estudio de un Gateway basado en intercambios SNMP-CORBA, encargado de distribuir las peticiones de información de gestión entre los componentes dentro de una arquitectura hibrida, es decir, un mecanismo que resuelva peticiones SNMP haciendo invocaciones CORBA y viceversa.

4 Dominios de Gestión con SNMP El protocolo SNMP (Simple Network Management Protocol, Protocolo Simple de Administración de Red) permite monitorear y controlar redes que operan sobre TCP/IP. Su estructura está constituida por un manager o administrador de SNMP, un agente SNMP, una base de datos de gestión de la información o MIB por sus siglas en inglés, dispositivos gestionados SNMP y el protocolo de red. El manager proporciona la interfaz entre el administrador de red y el sistema de gestión. El agente proporciona la interfaz entre el manager y el dispositivo físico que es administrado. Ambos usan MIB (base de datos gestionada) y un conjunto relativamente de comandos para el intercambio de información. En la figura se puede observar en forma general la arquitectura SNMP. Figura 1. Arquitectura General de SNMP.Fuente: MIB: La MIB es la base de datos común para la gestión de equipos en Internet, se apoya en la estructura de información de gestión SNMPv1 definido en el RFC OID: En esta estructura de datos, los componentes de los objetos están asociados a variables, las cuales están organizadas jerárquicamente según estándares de la ISO y la ITU-T. Cada objeto consta de una etiqueta que lo define, la cual es llamada identificador de objeto (OID), utilizada para distinguir cada variable única. Su estructura esa definida por una serie de números separados por punto decimales como por ejemplo:

5 Tipos de mensajes SNMP Existen cinco tipos de mensajes que están disponibles para la comunicación entre el agente y el manager, como se mencionan: Get request (Obtener solicitud): Utilizado para consultar una MIB. Get next request (Obtener la siguiente solicitud): Utilizado para leer secuencialmente a través de una MIB. Get response (Obtener respuesta): Utilizado para lograr una respuesta a un mensaje para obtener solicitud (get request). Set request (Fijar solicitud): Utilizado para fijar un valor en la MIB. Trap (Alarma): Utilizado para reportar eventos. Cuando el manager desea conocer el valor de un objeto,éste enviara un get request al agente que incluye el OID para cada objeto, el agente recibe la solicitud y busca cada OID en su base de datos (MIB).Si la OID se encuentra, el objeto es administrado por el agente,un paquete de respuesta get response se ensambla y se envía con el valor actual del objeto y si el OID no se encuentra, una respuesta de error es enviada, identificando que no se encuentra en la MIB. En general, los paquetes son recibidos por el puerto UDP 161 y las alarmas, por el puerto 162. Por ser un protocolo basado en UDP/IP no garantiza la llegada de los mensajes. Entre sus puntos críticos de la MIB de SNMP están: Los datagramas son ineficientes para la obtención de grandes cantidades de información No existe mecanismos de compresión de la información de la fuente Ausencia de estandarización para la interoperabilidad entre estructuras de datos entre otros sistemas de gestión. DOMINIOS DE GESTION CORBA CORBA (Common Object Request Broker Architecture, Arquitectura Común de Intermediarios de Peticiones de Objetos) es un estándar computacional. Así como indica Farley (1999) El mecanismo de trabajo de CORBA consiste en tener 2

6 programas: una del lado del cliente y otro del lado del lado del servidor, estos programas se enlazan por medio de interfaces IDL (Interface Definition Lenguage) pasando peticiones entre uno y otro mediante ORB (Object Request Broker). Dicha arquitectura se detalla en la figura 2. Figura 2. Arquitectura CORBA COMPONENTES ORB (Object Request Broker): es el centro modular de todas las funciones del modelo distribuido en CORBA, es el encargado de llevar las peticiones de implementación de la interfaz entre los clientes y los servidores IDL (Interface Definition Lenguage): especifica los métodos de los objetos remotos y los parámetros de entrada necesarios para utilizarlos en distintos lenguajes de programacion. La siguiente figura muestra como los traductores de lenguaje existen para C++, java, Small Talk. Figura 3.Interoperabilidad de IDL.Fuente

7 Una de las metas de la especificación CORBA es que la implementación de clientes y objetos sea portable. Ventajas Reutilización de código Partición de las aplicaciones Distribución de la carga computacional Replicación de servidores En contra parte algunos de los inconvenientes es que la tecnología es más compleja y más pesada. Una vez explicada los aspectos más importantes de la gestión tradicional (SNMP) y la gestión distribuida (CORBA), se pueden resumir las características de ambas en el siguiente cuadro: SNMP CORBA Lenguaje de descripción de SMI IDL objetos Identificador de Objeto OID IOR Acceso a objeto Secuencial Aleatorio gestionados Capa de Presentación ASN.1 CDR Protocolo de Transporte UDP TCP Una vez tomados en cuenta dichos aspectos, una pasarela en el escenario CORBA/SNMP, como lo señala De Vergara (1999) se basa en los servicios SNMP definidos por la traducción de interacciones al estilo de la COSS (CORBA Object Standard Services). El fin al traducir nombres del dominio es estandarizar la jerarquía de nombres SNMP (host, variable, índice) basada en la interfaz NamingContext del servicio de nombres de CORBA. Para llegar al objetivo hay que normalizar la jerarquía del árbol de la MIB y extender la interfaz NamingContext para listar sus entradas en orden.

8 La figura anexa representa la operación de una pasarela con manager CORBA basado en SNMP en donde se convierte una interfaz IDL basada en la operación get/set usando un objeto de referencia a un mensaje SNMP Request y convierte el mensaje SNMP resultante como valor de la operación. Figura 4.Pasarela con manager SNMP/CORBA. La pasarela también monitorea el puerto de notificaciones, alarmas SNMP (Trap) y transforma dicha instrucción a una notificación de servicios basadas en eventos OMG. La figura 5 ilustra el caso contrario, en donde existe una interacción entre un manager SNMP y un agente CORBA, esta pasarela mapea los mensajes SNMP a operaciones CORBA IDL. Cuando el manager CORBA basado en SNMP recibe un PDU de la pila de protocolo lo convierte en un mensaje tipo IDL para posteriormente interactuar con la ORB. Cada PDU SNMP genera más de una operación get/set. También genera notificaciones (TRAP) generadas por el agente CORBA al manager SNMP. Figura 5.Pasarela con manager SNMP

9 CONCLUSION Cuando se habla de una integración entre CORBA y SNMP a través de una pasarela acarrea una mejora en la calidad de servicios demandada por sus usuarios, el estudio a profundidad de una pasarela snmp-corba permite conocer las interacciones e intercambios entre dos dominios de gestión diferentes. Esto a su vez permite comprender el funcionamiento de gestión heterogéneo necesario hoy en día para las redes actuales. El Gateway o pasarela SNMP-CORBA es uno de los modelos estudiados en la actualidad para la interacción entre distintos dominios de gestión, los otros modelos por ejemplos son usar gestores capaces de soportar todos los posibles tipos de recursos a gestionar, hacer componentes de las aplicaciones sean capaces de adaptarse a la tecnología tradicional de gestión de red utilizada, es decir, una aplicación distribuida con CORBA y que responda directamente a peticiones SNMP, por otra parte la necesidad de investigar más sobre la conversión de la MIB (la referencia a objeto) a IDL.

10 BIBLIOGRAFIA Unai Estébanez Sevilla Introducción a SNMP URL: Francisco Charte Ojeda CORBA con Java IDL URL: Alan Marshall Network Management Performance Analysis and Scalability Tests: SNMP vs. CORBA URL: es&u= om/layers/l2/snmp_l2_tut_part1.php Subrata Mazumdar Inter-Domain Management between CORBA and SNMP: WEBbased Management - CORBA/SNMP Gateway Approach URL: Jorge Enrique López de Vergara Méndez Diseño e implementación de un sistema para la gestión de una aplicación distribuida de intermediación electrónica