El manual para el clustering con openMosix - Sistemas distribuidos (II)

La tendencia a lo distribuido

Existen varios métodos para intentar distribuir a nivel de aplicación, son métodos que abstraen las capas inferiores y hacen la vida más fácil a los programadores de las aplicaciones, que no se tendrán que preocupar sobre las peculiaridades de las capas inferiores consiguiéndose una mayor efectividad en la programación. Las tecnologías que se verán, en este orden, son:

---

RPC: Remote Procedure Calls.
RMI: Remote Method Invocation.
CORBA: Estándar de comunicación de objetos.
Bonobo: Abstracción sobre CORBA de GNOME.
KDE: Desktop Enviroment. Veremos: KIO, XMLRPC, DCOP.
SOAP: Simple Object Access Protocol.

RPC.-

El concepto de RPC o llamada a procedimiento remoto ha sido explotado desde hace ya varias décadas, de hecho, existen varias implementaciones creadas por distintos grupos e incluso varios protocolos. El concepto de llamada a procedimiento remoto no es otra que la que su propio nombre indica, es decir, se pretende ejecutar funciones o procedimientos en otras máquinas distintas a la nuestra y que el resultado retorne a nuestra máquina, todo ello de manera transparente. Hasta aquí el concepto de llamada a procedimiento remoto parece bastante asequible. El problema surge como siempre a la hora de implementarlo, codificarlo y tener en cuenta consideraciones de sistema.

Para empezar se deben tener en cuenta cosas como que tipo de protocolo se va a utilizar en capas inferiores. Puede ser conectivo, perfecto para olvidarse de las retransmisiones y fallos o no conectivos y aprovechar al máximo la capacidad de la red. También hay que prestar atención al formato de representación entre distintas máquinas de un mismo sistema, como podrían ser ASCII, EBCDIC o Little Endian y Big Endian, y en otros muchos problemas que implican las llamadas a procedimientos remotos2.17.

Por último (como colofón de las pegas de los sistemas implementados de los RPC) está el que generalmente no son tan transparentes como debieran. En el caso ideal, se supone que, el programador no debe saber si los procedimientos de una biblioteca son locales o remotos, ni necesitar de ningún tipo de interface para poder llamar a dichos procedimientos. Esto no se cumple, no sólo en el caso de RPC, sino en prácticamente cualquier sistema distribuido.

El RPC por excelencia es el RPC diseñado e implementado por Sun Microsystems cuya versión 2 esta especificada y tipificada en el RFC 1831. En esta RFC se puede leer no sólo el modelo de llamada a procedimiento remoto, sino también ejemplos de programación de RPC, semánticas de transporte, sistema de autenticación y modelo de programación en general de esta implementación. Dicha implementación utiliza como modelo de comunicación IP/UDP ya que la mayoría de las aplicaciones suelen estar en una LAN y por tanto se obtiene más efectividad que con TCP. Se utiliza también XDR para hacer compatible entre varios formatos de representación. Los programas requieren de librerías y funciones especiales y al mismo tiempo se requiere rpcportmapper instalado como demonio para efectuar las transacciones. Existen varias referencias acerca de como podría implementarse un sistema distribuido de este tipo en el libro Sistemas Operativos Distribuidos de Andrew S. Tanembaum.

¿Por qué no utilizar RPC en sistemas distribuidos o clusters? Existen diversas causas, unas con más peso que otras. Por norma general el modelo RPC suele ser bastante lento a pesar de utilizar UDP, por ejemplo en lo que se refiere al checksum, cambio de referencias en memoria, traducción XDR, rellenado de cabeceras y otras tantas operaciones que hacen que dicho sistema sea compatible en un entorno de trabajo hetereogéneo.

Es decir, en entornos de trabajo en los cuales no se requiere de confiabilidad, autenticación (y seguridad en general), eficiencia, y consistencia; la solución RPC es aceptable. En el caso de los clusters, suele implementarse con unos requerimientos de sistema bastante exigentes en lo que se requiere a eficiencia, y es mejor considerada una macro en el programa que utilizar todo un sistema como puede ser XDR. Generalmente los sistemas distribuidos suelen basar su desarrollo en nuevas implementaciones o modelos, que no tienen por que ser el de RPC, y no utilizan RPC debido a la poca eficiencia que este reporta y a la mala fama en seguridad que este posee.

---

RMI.-
También desarrollado por Sun para Java, mucha gente considera a RMI el sucesor de RPC.

RMI es un concepto confuso, tiene dos aceptaciones:

• RMI es cualquier protocolo que invoque métodos de objetos remotamente. Aparte de la implementación de Java, existen otras implementaciones que se pueden considerar RMI como las implementaciones de CORBA, DCOM y DCOP.
• RMI como Java RMI, se suele abreviar como RMI, es específico de Java y es del que hablaremos aquí pues las demás tecnologías las vemos en los siguientes apartados.

RMI es un mecanismo que permite invocar un método de un objeto que no existe en el espacio de direccionamiento de la propia aplicación, este otro espacio de direcciones puede encontrarse en la propia máquina o en otra diferente. Básicamente podemos aplicar lo explicado en RPC pero teniendo en cuenta que este mecanismo es orientado a objetos. Comparando con el siguiente punto CORBA, aunque básicamente ambos métodos son un RPC para lenguajes orientados a objetos, CORBA es un estandard e independiente del lenguaje, RMI sólo es para Java. CORBA incluye muchos otros mecanismos en su estándar (lo que le hace ser una implementación más lenta y pesada) que no son parte de RMI. Tampoco existe el concepto de ORB (Object Request Broker) en RMI. Java RMI ha estado evolucionando y convirtiéndose en más compatible con CORBA, en particular hay ahora una nueva forma de RMI llamada RMI/IIOP (RMI sobre IIOP) que usa IIOP (Internet Inter-ORB Protocol de CORBA como protocolo de bajo nivel para las comunicaciones RMI. Por supuesto podemos imaginar las consecuencias para el rendimiento.

Hay 3 procesos que participan en que la invocación de métodos remotos se haga efectiva:

• El cliente: es el proceso que está invocando a un método en un objeto remoto.
• El servidor: es el proceso al que pertenece el objeto remoto. El objeto remoto es un objeto ordinario en el espacio de direcciones del proceso servidor.
• El registro de objetos: es el servidor de nombre que relaciona objetos con nombres. Objetos están registrados con el registro de objetos. Una vez que un objeto ha sido registrado, cualquiera puede usar el registro de objetos para obtener acceso a los objetos remotos usando el nombre del objeto.

Hay dos tipos de clases que pueden ser usadas en Java RMI.

• Remote class: es una clase cuyas instancias pueden ser usadas remotamente. Un objeto de esa clase puede ser referenciado de dos maneras:
  1. Dentro de su propio espacio de direcciones donde el objeto fue construido, este objeto es un objeto ordinario Java.
  2. Dentro de otro espacio de direcciones, el objeto puede ser referenciado usando un manejador de objeto. Aunque hay limitaciones en cómo se puede usar un manejador de objeto comparado con un objeto, la mayor parte del tiempo los manejadores de objetos se pueden usar de la misma forma que un objeto.

Serialized class: las instancias de este objeto (serializable object) pueden ser copiadas de un espacio de direcciones a otro. Se puede usar para el protocolo entre objetos. Si uno de estos objetos es pasado como parámetro (o es un valor de retorno) de una invocación remota a un método, entonces el valor del objeto será copiado de un espacio de direcciones a otro. En cambio si un remote object es pasado como parámetro ( o valor de retorno) el manejador del objeto será copiado de un espacio de direcciones a otro.

CORBA.-

Es un estándar desarrollado por una fundación creada por distintas empresas llamada OMG (Object Management Group) para poder hacer fácilmente programación distribuida, reutilización de objetos y de código ya hecho. CORBA cumple correctamente estos objetivos, para ello la estructura de CORBA cuenta de un lenguaje estandar llamado IDL (Interfaz Definition Language) que sirve para determinar los interfaces entre objetos, la implementación de los objetos se hace con cualquier lenguaje que tenga un compilador capaz de enlazar IDL.

CORBA es un middleware entre el sistema operativo y las aplicaciones usuario, entre ese middleware se encuentra el ORB encargado de hacer las llamadas entre objetos. En resumidas cuentas, CORBA es un nivel más de abstracción.


-- Ventajas:

• Abstrae a la aplicación de todo lo referente a las comunicaciones, el programa ni siquiera sabe donde esta el objeto al que llama.
• Se pueden reutilizar programas anteriores simplemente añadiendo algo de código
• Tiene todas las ventajas de la programación orientada a objetos.
• Se puede programas en varios lenguajes. Puedes crear un programa con varios lenguajes distintos ya que cada una de las partes solo verá el interfaz CORBA de la otra.
• Las simplificaciones en la programación deberían llevar a una programación con menos errores.
• Abstrae el Sistema Operativo.
• Es un estándar para todas las plataformas y abierto.

--Desventajas:

• Más capas de software, más carga.
• Usa RPC en su nivel más bajo, anteriormente explicamos los problemas que acarrea esto.
• En sus versiones Real Time o QoS necesita dar preferencia a unas llamadas sobre otras para conseguir el objetivo.
• CORBA es muy grande, un fallo en CORBA podría ser difícil de detectar.
• Aunque se necesite añadir poco código las aplicaciones se necesitan reescribir.
• Un objeto se ejecuta en el sistema que le alberga.

Aunque haya más ventajas que inconvenientes estos últimos son más relevantes puesto que no podemos suponer que los procesos con los que trabajemos vayan a estar desarrollados en CORBA, además CORBA no nos soluciona el problema de migrar procesos y si lo hiciera sería extremadamente lento.

Aún se podría pensar en usar CORBA para envío de mensajes, pero la sobrecarga que genera no merece la pena. CORBA es muy potente para aplicaciones distribuidas o no de nueva creación y seguramente se le pudieran añadir funciones de balanceo de carga, pero para que nuestra solución sea más general es preferible no usar CORBA y tratar todo a nivel de proceso, sin abstracciones mayores. Aunque el estándar CORBA no añade estas capacidades de balanceo, implementación es específicas si que tienen reconfiguración dinámica, por ejemplo, Dinamic TAO.

---

Bonobo.-
Abstracción por encima de CORBA desarrollada por el proyecto GNOME.

Bonobo es un conjunto de interfaces CORBA, algunos implementados por objetos contenedores y otros por los objetos que serán contenidos (por ejemplo cuando pulsamos sobre un pdf y este se abre en nuestro propio navegador, el navegador es el contenedor y el programa lector de pdf el contenido). Bonobo es también una implementación por defecto de estos interfaces CORBA que es exportado en forma de API C para evitar a la mayoría de los programadores de preocuparse por tener que codificar directamente los interfaces CORBA.

Aunque no lo hemos mostrado en el punto anterior la programación en CORBA es ciertamente compleja, por tanto dentro del esfuerzo del proyecto GNOME para incorporar CORBA se ha desarrollado una librería de un nivel más alto llamada Bonobo (el nombre es de ciertos monos en vías de extinción que sirven para ilustrar la teoría de conexión de componentes). Otro de estos desarrollos fue ORBit que es un ORB pero con la particularidad de estar altamente mejorado en velocidad, siendo el más rápido existente (casi el doble que su más cercano competidor Omniorb) y de los que menos memoria necesita.

A parte de ORBit tenemos Gnorba que facilita en algo algunas tareas de ORBit y es más específico de GNOME, por ejemplo permite la integración del bucle principal de ORBit con el bucle principal de Gtk+, añade seguridad a las comunicaciones y un método estándar para acceder al servicio de nombres de GNOME. Para permitir acceso a un objeto en concreto se dispone la información en GOAD (GNOME Object Activation Directory) donde tenemos el id del objeto, las interfaces que exporta y como crear un ejemplar, gracias a esto se pueden usar métodos a través de la red.

Bonobo se creó para intentar mantener las aplicaciones con poca complejidad para que a los nuevos programadores les cueste poco saber cómo funciona el código y sea más fácil el mantenimiento y desarrollo. Usando todas las facilidades de CORBA que es usado para la capa de comunicación y para unir todos los componentes Bonobo entre sí. Cada componente tiene su interfaz (definido en términos de las interfaces CORBA) que exporta, ahíes donde cualquier otro componente puede conseguir información o unirse al componente.

El interface CORBA se introduce en un objeto GTK+, esto quiere decir que los objetos GTK+ son la implementación del interface IDL. Las implementaciones contienen ciertas acciones por defecto para no molestar al programador con detalles de CORBA, pero se dan unos métodos para cambiar este comportamiento.

---

KDE.-
En este apartado vamos a ver tres tecnologías que utiliza KDE a partir de sus versiones 2.0 y posteriores:

1. KIO: entrada y salida , transparencia de red.
2. XML-RPC: manejo de programas remotamente.
3. DCOP: comunicación entre componentes Kparts.

Estas tres tecnologías permiten acercarnos a un proceso distribuido y a una transparencia de red enormes. KDE es muy buen ejemplo de cómo se intenta cumplir algunos de los objetivos de los sistemas distribuidos, y cómo usuarios que somos de este entorno podemos decir que esta tecnología hace el día a día más sencillo.

• 1.- KIO:

Esta es la librería que implementa prácticamente todas la funciones de manejo de ficheros. Es la librería que se usa para proveer un manejo de ficheros transparente a red. La implementación de los distintos protocolos (FTP, HTTP, SMB, POP3, IMAP4, gopher, printer, man, gzip, etc.) es hecha por un proceso independiente llamado kioslave, uno por cada protocolo, kio_ftp implementa FTP, kio_http implementa HTTP etc. La aplicación indica el protocolo a usar y KIO decide que kioslave usar.
Por tanto gracias a estos kioslaves por ejemplo podemos tener acceso transparent e a servidores ftp, subir y bajar información simplemente copiando y pegando o haciendo drag'n drop. Podemos tener acceso a discos remotos e información remota de forma totalmente transparente. Un usuario sin mucho conocimiento de informática podría incluso nunca darse cuenta de que no estaba accediendo a su propio disco duro.

• 2.-XML-RPC

Esta tecnología no es específica de KDE sino que se usa en este entorno como en otros, vamos a ilustrar el ejemplo de KDE. En KDE existe el kxmlrpcd que permite que un cliente escrito en cualquier lenguaje, en cualquier plataforma pueda acceder a los servidores DCOP de KDE . Como casi todas las aplicaciones de KDE son servidores DCOP, se puede manejar este entorno remotamente, de forma transparente. Por tanto vemos una vez más que el límite entre local y remoto se difumina permitiéndonos ejecutar KDE como si estuviéramos ejecutando un telnet.
XmlRpc es la forma estándar de implementar RPC usando XML y HTTP. Con XML se marcan todas las llamadas a funciones , sus parámetros y sus valores de retorno. Entonces se utiliza HTTP para transferir la llamada al método. Muchísimos lenguajes disponen de parsers XML y clientes HTTP por lo que la implementación es bastante sencilla. Como el proyecto KDE ya tenía el protocolo DCOP para hacer RPC e IPC, kxmlrpcd es básicamente un traductor (servidor web por soportar HTTP), que traduce las peticiones XmlRpc en llamadas a DCOP y viceversa. Tanto el cliente XmlRpc como el servidor DCOP creen que están comunicándose solamente en su protocolo nativo con el demonio.

• 3.- DCOP : Desktop COmunication Protocol

Fue creado por la necesidad de comunicación entre aplicaciones, no podían usar X Atoms por ser demasiado simples y crear una dependencia con Xwindow. También estuvieron intentando implementar CORBA pero se dieron cuenta que para la simple tarea de intercomunicar tareas era demasiado lento y requería demasiada memoria, además no tenía ningún tipo de autentificación.
Lo que realmente se quería era un protocolo simple con autentificación básica, aunque no fuera capaz de hacer todo lo que era capaz de hacer CORBA, pero que fuera suficientemente bueno para la tarea encomendada. Un ejemplo de estas llamadas es una aplicación recién iniciada que pregunta si hay otra aplicación con el mismo nombre abierta, si es así abrirá una nueva ventana en la antigua aplicación en vez de abrir una nueva.
DCOP es un mecanismos IPC/RPC muy simple que funciona sobre sockets. Están soportados los sockets del dominio UNIX y TCP/IP. Como capa inferior utiliza el protocolo ICE (Inter Client Exchange), que viene estándar como parte de X11R6. También depende de Qt, pero más allá de estos requerimientos no necesita más librerías. Es una capa de software muy ligera.
Las aplicaciones son clientes DCOP y se comunican entre sía través de un servidor DCOP, que funciona como director del tráfico, enviando los mensajes o las llamadas a los destinos apropiados. Todos los clientes son pares entre ellos. Hay dos tipos de acciones posibles:
Mensajes: en estos mensajes se envía el mensaje y no se espera la vuelta, por lo que la llamada no bloquea y es muy rápida.
Llamadas: se llama a una función y se debe esperar a que se devuelva algún dato.
Para crear las llamadas se ha desarrollado un compilador al estilo del compilador IDL que vimos en CORBA, llamado dcopidl (y dcopidl2cpp) que generan los stubs y skels al estilo que CORBA lo hacía para ahorrar el trabajo del programador.
En definitiva DCOP provee un método sencillo y eficiente que fue desarrollado exactamente para ese uso que evita la complejidad de CORBA pero que también permite la interconexión de objetos en una máquina o en máquinas distintas. Además en unión con XML-RPC del capítulo anterior se permite usar este protocolo desde cualquier lenguaje que era otra de las características de CORBA.
Las ventajas para crear aplicaciones distribuidas usando este protocolo son las mismas que se vieron en el apartado de CORBA.

SOAP.-

Hoy en día lo que se le pide a un sistema que use RPC o RMI es que sea confiable, robusto, que tenga APIs desarrolladas para varios lenguajes, interoperabilidad entre lenguajes, plataformas y modelos de componentes.

Desafortunadamente no hay un único sistema que tenga todas esas características. El formato de los datos y el protocolo usado para intercambiarlos es un factor determinante en el grado de interoperabilidad que pueden alcanzar las aplicaciones.

XML(eXtensible Markup Language) se está convirtiendo en un estandar para representar datos en un formato independiente de la plataforma. XML es un lenguaje fácil de general y de leer. HTTP (HyperText Transfer Protocol) también se está convirtiendo en un protocolo muy usado gracias a las aplicaciones web, que está soportado por todos los sistemas.

Las peticiones/respuesta de HTTP se pasan a través de firewall y son manejadas de forma segura, todo lo contrario que una ejecución de una llamada RPC o RMI.

Por lo tanto XML sobre HTTP parece una forma bastante inteligente para las aplicaciones distribuidas de comunicarse entre ellas. SOAP hace exactamente eso.

Representando RPCs de forma independiente a la plataforma, abre la posibilidad de implementar otros protocolos específicos de arquitectura en SOAP. Por ejemplo Microsoft parece querer usar SOAP como protocolo intermedio de intercambio al que otros protocolos pueden ser fácilmente traducidos, para potenciar el uso de sus componentes COM.

RPC en SOAP son interacciones cliente servidor sobre HTTP donde la petición/resp uesta se hacen de acuerdo con las reglas SOAP. Para elegir el objeto se usa el URI (Universal Resource Identifier) que es propio de HTTP o la cabecera SOAPAction que indica el nombre del interface. Se especifica una convención de la llamada remota , que determina la representa ción y el formato de las llamadas y respuestas. Una llamada es un dato compuesto con varios campos, uno por cada parámetro. Un mensaje de retorno es un valor de retorno y unos parámetros.