ARQUITECTURA DE SISTEMAS DISTRIBUIDOS

Los sistemas distribuidos son comnmente piezas complejas de software cuyos componentes estn dispersos en mquinas mltiples. Si se desea tener control sobre esta complejidad, es crucial que estos sistemas estn apropiadamente organizados. La organizacin de los sistemas distribuidos depende mayormente de los componentes de software que constituyen al sistema. Estas arquitecturas de software establecen como son organizados varios componentes del software y cmo interactan entre ellos. La implementacin de un sistema distribuido requiere de la divisin e identificacin de los componentes de software y su instalacin en mquinas reales. La implementacin e instalacin final de la arquitectura de software se conoce como arquitectura de software. Como se explic con anterioridad, un objetivo importante de los sistemas distribuidos es separar las aplicaciones de las plataformas subyacentes mediante una capa de middleware. La adopcin de esta capa en una importante decisin arquitectnica, y su principal objetivo es proveer una distribucin transparente de la aplicacin. La transparencia de la distribucin implica en muchos casos la necesidad de hacer ciertos sacrificios o concesiones, por lo que es conveniente que el middleware sea adaptable. Esta adaptabilidad tambin se puede lograr permitiendo que el sistema monitoree su propio comportamiento y que tome las medidas necesarias cuando se requiera. Estos sistemas distribuidos son organizados frecuentemente en la forma de retroalimentacin de control.

3.1 Estilos Arquitectnicos

Para iniciar la discusin sobre arquitecturas, se debe considerar en principio la organizacin de sistemas distribuidos en componentes de software, tambin conocida como arquitectura de software. El estilo arquitectnico est formulado en trminos de componentes, la forma en que estos componentes estn conectados unos con otros y los datos intercambiados entre ellos. Un componente es una unidad modular con interfaces bien definidas, y que puede ser reemplazado en el sistema. Tal vez un trmino ms complejo es el de conector, el cual generalmente es descrito como un mecanismo que media la comunicacin, coordinacin o cooperacin entre componentes. Por ejemplo, un conector puede implementarse mediante RPCs, transferencia de mensajes o flujos de datos. Existen varias configuraciones de componentes y conectores que definen el estilo arquitectnico de un sistema distribuido. Los estilos ms importantes son:

Arquitecturas en capas Arquitecturas basadas en objetos Arquitecturas centradas en datos Arquitecturas basadas en eventos

La idea bsica tras el estilo arquitectnico en capas es simple: los componentes estn organizados en forma de capas, en la que un componente en una determinada capa puede llamar a componentes en la capa inmediata inferior. Una observacin clave es que el control generalmente fluye de capa en capa: las peticiones van de arriba abajo y los resultados de abajo a arriba, tal como se puede observar en la Figura 3.1(a). Una organizacin, por mucho ms suelta, se tiene en arquitecturas basadas en objetos, tal como se muestra en la Figura 3.1(b). En esencia, cada objeto corresponde a lo que hemos definido como componente, y estos componentes estn conectados mediante un mecanismo RPC. No es de sorprender que esta arquitectura de software se adapte al modelo clienteservidor que trataremos ms adelante.

Figura 3.1. (a) Estilo arquitectnico en capas; (b) estilo arquitectnico basado en objetos.

Las arquitecturas centradas en datos evolucionan en torno a la idea de que los procesos se comunican a travs de un repositorio o medio comn, ya sea pasivo o activo (ver Figura 3.2 (a)). Por ejemplo, una cantidad importante de aplicaciones distribuidas en las que la comunicacin se establece por medio de un archivo compartido a travs de un sistema de archivos distribuidos. En las arquitecturas basadas en eventos, los procesos se comunican esencialmente por medio de la propagacin de eventos, los cuales de manera opcional pueden llevar datos consigo, tal como se muestra en la Figura 3.2 (b). Generalmente, en los sistemas distribuidos, la

propagacin de eventos se ha asociado con lo que se conoce como sistemas publicar/subscribir (publish/subscribe systems). La idea bsica es que los procesos publican eventos tras los cuales el middleware asegura que slo esos procesos que se subscribieron a esos eventos, los recibirn. La ventaja principal de esta arquitectura es que los procesos estn acoplados flojamente. En principio, no se requiere una referencia explcita de proceso a proceso. A esto se le conoce como desacoplamiento en el espacio o referencialmente desacoplados.

Figura 3.2. (a) arquitectura centrada en datos; (b) arquitectura basada en eventos.

3.2 Arquitecturas de Sistemas

Ya que se ha discutido brevemente sobre algunos estilos arquitectnicos comunes, se ver cmo muchos sistemas distribuidos estn organizados, considerando la manera en que sus componentes de software fueron establecidos. El determinar que componentes de software se usarn, cmo interactuarn y cmo se distribuirn es lo que se conoce como una instancia de arquitectura de software, tambin llamada arquitectura de sistema.

3.2.1. Arquitecturas Centralizadas

A pesar de las diferencias en cuanto a varios aspectos de los sistemas distribuidos, solo hay un aspecto en los que muchos expertos coinciden: pensar en trminos de clientes que solicitan servicios a servidores ayuda a entender y administrar la complejidad de los sistemas distribuidos. En el modelo bsico cliente-servidor, los procesos en un sistema distribuido estn divididos en dos grupos, que posiblemente se traslapan. Un servidor es un proceso que implemente un servicio especfico, por ejemplo, un servicio de sistema de archivos distribuido o de base de datos. Un cliente es un proceso que solicita un servicio a un servidor, envindole una peticin y

subsecuentemente esperando la respuesta del servidor. La interaccin cliente-servidor, tambin conocida como solicitud-respuesta, se muestra en la Figura 3.3.

Figura 3.3. Interaccin general entre un cliente y un servidor.

La comunicacin entre un cliente y un servidor puede ser implementada por medio de un simple protocolo no orientado a la conexin (sin conexin) cuando la red subyacente es suficientemente confiable como es el caso de muchas redes de rea local (LANs). En estos casos, cuando un cliente solicita un servicio, empaca simplemente el mensaje para el servidor, identificando el servicio que requiere y anexando los datos de entrada necesarios. El mensaje es posteriormente enviado al servidor. El servidor se encuentra continuamente en espera de recibir solicitudes, tras lo cual las procesa, empaqueta los resultados en un mensaje de respuesta, y finalmente enva este mensaje al cliente.

Implementacin de aplicaciones en capas

El modelo cliente-servidor ha sido sujeto de muchos debates y controversias a lo largo de los aos. Una de las principales cuestiones es el cmo establecer una clara distincin entre un cliente y un servidor. No es de sorprender que en muchas ocasiones esta distincin no es tan clara. Por ejemplo, un servidor de una base de datos distribuida a travs de la web puede actuar continuamente como cliente porque ste transfiere las solicitudes a varios servidores de archivos responsables de implementar las tablas de las bases de datos. En este caso, el servidor de base de datos por s mismo no hace ms que procesar las solicitudes de bsqueda o filtrado. La Figura 3.4 muestra este caso.

Figura 3.4. Ejemplo de servidor actuando como cliente. Sin embargo, considerando que muchas aplicaciones cliente-servidor estn orientadas a facilitar al usuario el acceso a la base de datos, mucha gente ha establecido una distincin entre los tres niveles siguientes, esencialmente usando el estilo arquitectnico en capas que se vio previamente: 1. El nivel de interfaz de usuario. 2. El nivel de procesamiento. 3. El nivel de datos. El nivel de interfaz de usuario contiene todo lo necesario para establecer una interfaz directa con el usuario, tal como la administracin del despliegue de la informacin. El nivel de procesamiento tpicamente contiene las aplicaciones. El nivel de datos administra los datos sobre los cuales se est trabajando. Los clientes normalmente implementan el nivel de interfaz de usuario. Este nivel consiste de los programas que permiten al usuario final interactuar con las aplicaciones. Hay una diferencia considerable en que tan sofisticada puede ser una interfaz de usuario. La ms simple no es ms que una simple pantalla de caracteres. Como ejemplo considrese un motor de bsqueda en Internet. La interfaz es muy simple: un usuario introduce una cadena de palabras claves y subsecuentemente se le presenta una lista de ttulos de pginas web. El extremo opuesto de la operacin est constituido por una gran base de datos de pginas web, las cuales han sido extradas e indexadas. El ncleo del motor de bsqueda es un programa que transforma la cadena de palabras claves que proporcion el usuario en una o ms peticiones de bsqueda a la base de datos. Subsecuentemente clasifica los resultados en una lista y transforma esta lista en una serie de pginas HTML. Dentro del modelo cliente-servidor, esta parte de extraccin de informacin es tpicamente localizada en el nivel de procesamiento. La Figura 3.5 muestra esta organizacin.

Figura 3.5. Organizacin simplificada en tres niveles diferentes de un motor de bsqueda.

3.2.2 Arquitecturas Descentralizadas

Las arquitecturas multinivel cliente-servidor, como la del ejemplo del motor de bsqueda mostrado anteriormente, son una consecuencia directa del dividir las aplicaciones en los tres niveles: interfaz de usuario, componentes de procesamiento y datos. Los diferentes niveles corresponden directamente con la organizacin lgica de las aplicaciones. En muchos ambientes, el procesamiento distribuido es equivalente a organizar una aplicacin cliente servidor como una arquitectura multinivel. A este tipo de distribucin se le conoce como distribucin vertical. La caracterstica relevante de una distribucin vertical es que esta puede realizarse disponiendo componentes lgicamente diferentes en mquinas diferentes mquinas. Una vez ms, desde la perspectiva de administracin del sistema, el tener una distribucin vertical puede ser una ayuda: las funciones ests lgica y fsicamente divididas y distribuidas en mltiples mquinas, mientras cada mquina est configurada para trabajar ptimamente con un grupo especfico de funciones. Sin embargo, la distribucin vertical es tan solo una manera de organizar aplicaciones clienteservidor. En arquitecturas modernas, es comn que la distribucin de clientes y servidores sea el factor ms importante, por lo que a este forma de distribucin se le conoce como distribucin horizontal. En este tipo de distribucin, un cliente o un server puede estar fsicamente dividido en partes lgicamente equivalentes, pero cada parte opera con su proprio conjunto integral de datos, balanceando (equilibrando) la carga del sistema. En esta seccin se analizar los sistemas peer-to-peer, una de las arquitecturas modernas que soportan la distribucin horizontal. Un sistema distribuido peer-to-peer (de igual a igual), comnmente abreviado P2P, es una arquitectura compuesta por participantes que ponen a disposicin directa de los otros participantes del sistema parte de sus recursos (poder de procesamiento, almacenamiento de disco, ancho de banda, etc.), sin la necesidad de una instancia de coordinacin central, tales

como servidores o hosts permanentes (ver Figura 3.6). Desde una alta perspectiva, los peers (iguales) de un sistema P2P son todos iguales, lo que significa que las funciones que deben ser desarrolladas en el sistema pueden ser realizadas por todo peer participante. En consecuencia, mucha de la interaccin entre los procesos participantes (peers) es simtrica, por lo tanto, los peers pueden ser a la vez tanto proveedores (servidores) como consumidores (clientes).

Figura 3.6. (a) Sistema peer-to-peer (P2P), (b) Sistema centralizado con cervidor En su concepto ms amplio, los participantes de un sistema peer-to-peer pueden ser computadoras, aplicaciones, procesos, etc. A fin de desarrollar el tema de esta seccin, se considerar que los participantes del sistema distribuido P2P son procesos que conforman una aplicacin distribuida, es decir, componentes de software. Los sistemas P2P fueron popularizados por aplicaciones para compartir archivos (file sharing), tales como Napster. Las redes P2P para compartir archivos han inspirado nuevas estructuras y filosofas en otras reas de la interaccin humana. En tales contextos, P2P, como tal, hace referencia a una red social igualitaria que actualmente est emergiendo en nuestra sociedad, habilitada en mucho por la Internet. Los sistemas P2P tpicamente se forman dinmicamente mediante la adicin de nodos (peers participantes). La eliminacin de nodos no tiene un impacto significativo en el sistema. La arquitectura distribuida de una aplicacin P2P provee una mayor escalabilidad y servicios ms robustos. En los sistemas P2P frecuentemente se implementa, a nivel de Capa de Aplicacin del protocolo de comunicacin, una red sobreimpuesta sobre la red fsica. Tal sobreimposicin es usada para el indexado o descubrimiento de los peers. En pocas palabras, la organizacin y optimizacin de la interconectividad entre los peers es implementada en la red sobreimpuesta . El contenido (informacin) tpicamente es intercambiado directamente sobre la red IP subyacente. Existen dos tipos de redes sobreimpuestas: las que son estructuradas y las no estructuradas. Sistemas P2P Estructurados. La conectividad en la red sobreimpuesta es fija (la organizacin que define que peers se interconectan entre s es fija). En estos sistemas, la red sobreimpuesta es construida usando procedimientos o algoritmos determinsticos. El procedimiento ms usado

es organizar la conectividad mediante una Tabla Hash Distribuida (DHT, Distributed Hash Table). En un sistema basado en un DHT, a cada dato se le asigna una llave aleatoria obtenida en un espacio de identificadores (valores) muy grande; por ejemplo, podra ser un identificador de 128 o 160 bits. Igualmente, a los nodos o peers, se les asigna un identificador obtenido en este mismo espacio de identificadores. La funcin crucial de un sistema basado en una DHT es implementar un esquema eficiente y determinstico que mapee de manera nica la llave asignada al dato con el identificador del nodo, basado en una mtrica de distancia. Ms importante an, cuando se busca un dato especfico, se proporciona la direccin de red del nodo responsable de ese dato. Efectivamente, esto se logra enrutando una solicitud de dato con el nodo responsable. Por ejemplo, en el Sistema Chord, los nodos se organizan lgicamente en un anillo de tal manera que un dato con llave k es mapeado (asociado) a un nodo con el identificador id, el cual es el nodo con el menor identificador posible que cumple la condicin id k. A este nodo se le llama sucesor de la llave k y se denota como succ(k), tal como se muestra en la Figura 3.7. Al buscar el dato con llave k, una aplicacin que corre en un nodo arbitrario llamar a la funcin LOOKUP(k), la cual, subsecuentemente, regresar la direccin de red succ(k). En este punto, la aplicacin puede contactar el nodo para obtener una copia del dato.

Figura 3.7. Mapeo (asociacin) de datos y nodos en el Sistema Chord.

Cuando un nodo quiere agregarse al sistema, este empieza por generar un identificador id. Note que el espacio de identificadores es lo suficientemente grande, por lo que el generador de nmeros aleatorios es de buena calidad; es decir, la probabilidad de generar un identificador

que ya ha sido asignado a otro nodo es casi nula. Entonces, el nodo simplemente realiza una bsqueda usando id, lo cual resulta en la direccin de red succ(id). En este punto, el nuevo nodo simplemente contacta a succ(id) y su predecesor, y se inserta entre stos en el anillo. Claro, en este esquema es necesario que cada nodo contenga la informacin sobre su predecesor. La insercin del nuevo nodo implica que cada dato cuya llave est ahora asociada al nodo id, sea transferido desde succ(id). El que el nodo id abandone el sistema es tan simple como informar a su sucesor y predecesor de su partida, y transferir todos sus datos al nodo succ(id). Sistemas P2P No Estructurados. Estos sistemas no proveen un algoritmo para la organizacin y optimizacin de las conexiones en la red. A continuacin, se presentan los tres modelos de arquitecturas P2P no estructuradas, sin embargo es oportuno puntualizar que el primer modelo, Sistemas P2P centralizados, clasifica como la arquitectura centralizada descrita en la seccin anterior; el segundo modelo, Sistemas P2P puros, es el nico modelo que podemos definir como descentralizado; el tercer modelo involucra un tercer tipo de arquitectura, la hibrida, la cual combina la arquitectura centralizada y la descentralizada. Sistemas P2P centralizados. Se utiliza un servidor central para indexar las funciones y coordinar el sistema. Aunque tiene similaridades con la arquitectura estructurada, las conexiones entre peers no es determinada por un algoritmo. Napster es un ejemplo de sistema no estructurado centralizado. Sistemas P2P puros (descentralizados). El sistema consiste en nicamente en peers equipotentes. Existe slo una capa de enrutamiento, y no hay nodos preferidos con una funcin de infraestructura especial. Gnutella y Freenet son ejemplos de sistemas P2P puros. Sistemas P2P hibridos. El sistema permite la existencia de nodos especiales con una funcin de infraestructura, comnmente llamados supernodos. Kazaa y los sistemas BitTorrent son ejemplos de sistemas P2P hibridos.

3.2.3 Arquitecturas Hibridas

Hasta el momento nos hemos concentrado en arquitecturas cliente-servidor y arquitecturas peer-to-peer. Muchos sistemas distribuidos combinan las caractersticas de ambas. Como se mencion en la seccin anterior, los Sistemas P2P Hibridos pueden ser clasificados en esta categora arquitectnica. Para ejemplificar este caso, considrese el caso de los sistemas para compartir archivos, usando el esquema BitTorrent (ver Figura 3.8). En estos sistemas, la idea bsica es que un usuario que busca un archivo pueda descargarlo (bajarlo) en partes obtenidas de otros usuarios, hasta que todas las partes obtenidas puedan ser ensambladas para reproducir el archivo de forma integral. Un aspecto importante de este diseo es el asegurar la colaboracin. En la mayora de las aplicaciones para compartir archivos, la mayora de los usuarios slo descargan archivos, sin contribuir en casi nada. En un sistema BitTorrent, un

archivo puede ser descargado nicamente cuando el usuario cliente tambin provee contenido a otro usuario.

Figura 3.8. Principio de operacin de un sistema BitTorrent.

En un sistema BitTorrent para descargar un archivo, el usuario debe tener acceso a un directorio global, el cual es un conjunto de pginas web. Este directorio contiene referencial (enlaces o links) a lo que se conoce como archivos .torrent. Un archivo .torrent contiene la informacin necesaria para descargar un archivo especfico. En particular, se establece una referencia a lo que se conoce como tracker (rastreador), el cual es un servidor que mantiene un registro preciso de todos los nodos activos que tienen partes del archivo deseado. Un nodo activo es aquel que en el momento est descargando otro archivo. Obviamente, habr varios trackers diferentes, aunque generalmente solo habr uno por archivo (o coleccin de archivos). Una vez que los nodos de los que se pueden descargar partes del archivo han sido identificados, el nodo del usuario que desea descargar el archivo, se vuelve activo. En este punto, este nodo ser forzado a ayudar a otros, tal vez proporcionando a otros las partes que an no han obtenido del archivo que se est descargando. Esta regla tiene origen en la siguiente regla: si el nodo P nota que el nodo Q est descargando ms de lo que est distribuyendo (subiendo) a otros, P puede decidir reducir la velocidad a la que le enva informacin (parte de un archivo, en este caso). Este esquema trabaja bien, siempre que P tenga algo que descargar de Q. Por esta razn, los nodos obtienen referencias a muchos otros nodos, lo cual los sita en una mejor posicin para negociar datos.

3.3 Arquitectura v.s. Middleware

Cuando se consideran los aspectos arquitectnicos que se han considerado hasta el momento, uno debe preguntarse dnde entra el middleware. Como se enseo en clases pasadas, el middleware forma una capa entre las plataformas de aplicacin y distribucin. Un propsito importante es proveer un cierto nivel de transparencia en la distribucin, ocultando en lo posible la distribucin de datos, el procesamiento y el control de la aplicacin.

Lo que comnmente pasa es que el middleware sigue un estilo arquitectnico especfico. Por ejemplo, muchos sistemas de middleware han adoptado un estilo arquitectnico basado en objetos, tales como CORBA; otros, como TIB/Rendeznous, siguen el estilo arquitectnico basado en eventos. El moldear el middleware a un estilo arquitectnico especfico tiene la ventaja de disear aplicaciones ms simples. Sin embargo, una desventaja es que el middleware puede volverse dejar de ser ptimo para lo que el desarrollador tena en mente. Aunque se supone que el middleware tiene como propsito transparentar la distribucin, generalmente se requiere que el middleware se adapte a las aplicaciones. Una solucin sera desarrollar varias versiones del middleware y otra sera el crear middleware fcilmente configurable y adaptable, segn lo requiera la aplicacin.

3.4 Autoadministracin en Sistemas Distribuidos

Los sistemas distribuidos y el middleware asociado a ellos requieren proveer soluciones generales orientadas a crear un escudo contra condiciones indeseables inherentes a la red, de tal manera que puedan brindar soporte a tantas aplicaciones como sea posible. Los sistemas distribuidos deben ser adaptivos, ms en cuanto a su comportamiento de su ejecucin y no en cuanto a los componentes de software que lo conforman. Cuando se requiere de adaptacin automtica, existe una fuerte interrelacin entre las arquitecturas del sistema y las arquitecturas del software. Por otro lado, se requiere organizar los componentes de un sistema distribuido en tal forma que se pueda implementar el monitoreo y ajuste del sistema; tambin decidir dnde deben ejecutarse los procesos para facilitar la adaptabilidad.

Conceptos: Plataforma: Generalmente se refiere a la combinacin hardware sistema operativo que determina las principales caractersticas computacionales de una computadora. Aplicaciones distribuidas: Aplicaciones de software que consisten en varias partes o componentes que son distribuidos en un sistema distribuido y que se intercomunican entre s para lograr el objetivo de la aplicacin.