Clase 03: Arquitecturas de Sistemas Distribuidos

Los sistemas distribuidos son comúnmente piezas complejas de software cuyos componentes están dispersos en máquinas múltiples. Si se desea tener control sobre esta complejidad, es crucial que estos sistemas estén apropiadamente organizados.

La organización 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 cómo interactúan entre ellos.

La implementación de un sistema distribuido requiere de la división e identificación de los componentes de software y su instalación en máquinas reales. La implementación e instalación 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 adopción de esta capa en una importante decisión arquitectónica, y su principal objetivo es proveer una distribución transparente de la aplicación. La transparencia de la distribución implica en muchos casos la necesidad de hacer ciertos sacrificios o concesiones, por lo que es conveniente que el middleware sea adaptable. Esta adaptabilidad también 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 retroalimentación de control.

3.1 Estilos Arquitectónicos

Para iniciar la discusión sobre arquitecturas, se debe considerar en principio la organización de sistemas distribuidos en componentes de software, también conocida como arquitectura de software.

El estilo arquitectónico está formulado en términos de componentes, la forma en que estos componentes están 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 término más complejo es el de conector, el cual generalmente es descrito como un mecanismo que media la comunicación, coordinación o cooperación 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 arquitectónico de un sistema distribuido. Los estilos más importantes son:

• Arquitecturas en capas

• Arquitecturas basadas en objetos

• Arquitecturas centradas en datos

• Arquitecturas basadas en eventos

Clase 03: Arquitecturas de Sistemas Distribuidos

La idea básica tras el estilo arquitectónico en capas es simple: los componentes están organizados en forma de capas, en la que un componente en una determinada capa puede llamar a componentes en la capa inmediata inferior. Una observación 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 organización, por mucho más 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 están conectados mediante un mecanismo RPC. No es de sorprender que esta arquitectura de software se adapte al modelo cliente-servidor que trataremos más adelante.

Figura 3.1. (a) estilo arquitectónico en capas; (b) estilo arquitectónico basado en objetos.

Las arquitecturas centradas en datos evolucionan en torno a la idea de que los procesos se comunican a través de un repositorio o medio común, ya sea pasivo o activo (ver Figura 3.2 (a)). Por ejemplo, una cantidad importante de aplicaciones distribuidas en las que la comunicación se establece por medio de un archivo compartido a través de un sistema de archivos distribuidos.

En las arquitecturas basadas en eventos, los procesos se comunican esencialmente por medio de la propagación 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 propagación de eventos se ha asociado con lo que se conoce como sistemas publicar/subscribir (publish/subscribe systems). La idea básica es que los procesos publican eventos tras los cuales el middleware asegura que sólo esos procesos que se subscribieron a esos eventos, los recibirán. La ventaja principal de esta arquitectura es que los procesos están acoplados flojamente. En principio, no se requiere una referencia explícita de

Clase 03: Arquitecturas de Sistemas Distribuidos

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 arquitectónicos comunes, se verá cómo muchos sistemas distribuidos están organizados, considerando la manera en que sus componentes de software fueron establecidos. El determinar que componentes de software se usarán, cómo interactuarán y cómo se distribuirán es lo que se conoce como una instancia de arquitectura de software, también 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 términos de clientes que solicitan servicios a servidores ayuda a entender y administrar la complejidad de los sistemas distribuidos.

En el modelo básico cliente-servidor, los procesos en un sistema distribuido están divididos en dos grupos, que posiblemente se traslapan. Un servidor es un proceso que implemente un servicio específico, 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, enviándole una petición y subsecuentemente esperando la respuesta del servidor. La interacción cliente-servidor, también conocida como solicitud-respuesta, se muestra en la Figura 3.3.

Clase 03: Arquitecturas de Sistemas Distribuidos

Figura 3.3. Interacción general entre un cliente y un servidor.

La comunicación entre un cliente y un servidor puede ser implementada por medio de un simple protocolo no orientado a la conexión (sin conexión) 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 envía este mensaje al cliente.

Implementación de aplicaciones en capas

El modelo cliente-servidor ha sido sujeto de muchos debates y controversias a lo largo de los años. Una de las principales cuestiones es el cómo establecer una clara distinción entre un cliente y un servidor. No es de sorprender que en muchas ocasiones esta distinción no es tan clara. Por ejemplo, un servidor de una base de datos distribuida a través 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 más que procesar las solicitudes de búsqueda o filtrado. La Figura 3.4 muestra este caso.

Figura 3.4. Ejemplo de servidor actuando como cliente.

Clase 03: Arquitecturas de Sistemas Distribuidos

Sin embargo, considerando que muchas aplicaciones cliente-servidor están orientadas a facilitar al usuario el acceso a la base de datos, mucha gente ha establecido una distinción entre los tres niveles siguientes, esencialmente usando el estilo arquitectónico 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 administración del despliegue de la información. El nivel de procesamiento típicamente 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 más simple no es más que una simple pantalla de caracteres.

Como ejemplo considérese un motor de búsqueda en Internet. La interfaz es muy simple: un usuario introduce una cadena de palabras claves y subsecuentemente se le presenta una lista de títulos de páginas web. El extremo opuesto de la operación está constituido por una gran base de datos de páginas web, las cuales han sido extraídas e indexadas. El núcleo del motor de búsqueda es un programa que transforma la cadena de palabras claves que proporcionó el usuario en una o más peticiones de búsqueda a la base de datos. Subsecuentemente clasifica los resultados en una lista y transforma esta lista en una serie de páginas HTML. Dentro del modelo cliente-servidor, esta parte de extracción de información es típicamente localizada en el nivel de procesamiento. La Figura 3.5 muestra esta organización.

Clase 03: Arquitecturas de Sistemas Distribuidos

Figura 3.5. Organización simplificada en tres niveles diferentes de un motor de búsqueda.

3.2.2 Arquitecturas Descentralizadas

Las arquitecturas multinivel cliente-servidor, como la del ejemplo del motor de búsqueda 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 organización lógica de las aplicaciones. En muchos ambientes, el procesamiento distribuido es equivalente a organizar una aplicación cliente servidor como una arquitectura multinivel. A este tipo de distribución se le conoce como distribución vertical. La característica relevante de una distribución vertical es que esta puede realizarse disponiendo componentes lógicamente diferentes en máquinas diferentes máquinas. Una vez más, desde la perspectiva de administración del sistema, el tener una distribución vertical puede ser una ayuda: las funciones estás lógica y físicamente divididas y distribuidas en múltiples máquinas, mientras cada máquina está configurada para trabajar óptimamente con un grupo específico de funciones.

Sin embargo, la distribución vertical es tan solo una manera de organizar aplicaciones cliente-servidor. En arquitecturas modernas, es común que la distribución de clientes y servidores sea el factor más importante, por lo que a este forma de distribución se le conoce como distribución horizontal. En este tipo de distribución, un cliente o un server puede estar físicamente dividido en partes lógicamente equivalentes, pero cada parte opera con su proprio conjunto integral de datos, balanceando (equilibrando) la carga del sistema. En esta sección se analizará los sistemas peer-to-peer, una de las arquitecturas modernas que soportan la distribución horizontal.

Un sistema distribuido peer-to-peer (de igual a igual), comúnmente abreviado P2P, es una arquitectura compuesta por participantes que ponen a disposición 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 coordinación 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 interacción entre los procesos participantes (peers) es simétrica, por lo tanto, los peers pueden ser a la vez tanto proveedores (servidores) como consumidores (clientes).

Clase 03: Arquitecturas de Sistemas Distribuidos

Figura 3.6. (a) Sistema peer-to-peer (P2P), (b) Sistema centralizado con cervidor

En su concepto más amplio, los participantes de un sistema peer-to-peer pueden ser computadoras, aplicaciones, procesos, etc. A fin de desarrollar el tema de esta sección, se considerará que los participantes del sistema distribuido P2P son procesos que conforman una aplicación 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 filosofías en otras áreas de la interacción 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 típicamente se forman dinámicamente mediante la adición de nodos (peers participantes). La eliminación de nodos no tiene un impacto significativo en el sistema. La arquitectura distribuida de una aplicación P2P provee una mayor escalabilidad y servicios más robustos.

En los sistemas P2P frecuentemente se implementa, a nivel de Capa de Aplicación del protocolo de comunicación, una red sobreimpuesta sobre la red física. Tal sobreimposición es usada para el indexado o descubrimiento de los peers. En pocas palabras, la organización y optimización de la interconectividad entre los peers es implementada en la red sobreimpuesta . El contenido (información) típicamente 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 organización que define que peers se interconectan entre sí es fija). En estos sistemas, la red sobreimpuesta es construida usando procedimientos o algoritmos determinísticos. El procedimiento más 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, podría 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 función crucial de un sistema basado en una DHT es implementar un esquema eficiente y determinístico que mapee de manera única la llave asignada al dato con el identificador del nodo, basado en una métrica de distancia. Más importante aún, cuando se busca un dato específico, se proporciona la dirección 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 lógicamente 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 condición 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 aplicación que corre en un nodo arbitrario llamará a la función LOOKUP(k), la cual, subsecuentemente, regresará la dirección de red succ(k). En este punto, la aplicación puede contactar el nodo para obtener una copia del dato.

Clase 03: Arquitecturas de Sistemas Distribuidos

Figura 3.7. Mapeo (asociación) 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 números 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 búsqueda usando id, lo cual resulta en la dirección 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 información sobre su predecesor. La inserción 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 organización y optimización de las conexiones en la red. A continuación, 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 sección 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

Clase 03: Arquitecturas de Sistemas Distribuidos

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 sólo una capa de enrutamiento, y no hay nodos preferidos con una función 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

función de infraestructura, comúnmente 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 características de ambas. Como se mencionó en la sección anterior, los Sistemas P2P Hibridos pueden ser clasificados en esta categoría arquitectónica.

Para ejemplificar este caso, considérese el caso de los sistemas para compartir archivos, usando el esquema BitTorrent (ver Figura 3.8). En estos sistemas, la idea básica 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 diseño es el asegurar la colaboración. En la mayoría de las aplicaciones para compartir archivos, la mayoría de los usuarios sólo descargan archivos, sin contribuir en casi nada. En un sistema BitTorrent, un archivo puede ser descargado únicamente cuando el usuario cliente también provee contenido a otro usuario.

Figura 3.8. Principio de operación de un sistema BitTorrent.

Clase 03: Arquitecturas de Sistemas Distribuidos

En un sistema BitTorrent para descargar un archivo, el usuario debe tener acceso a un directorio global, el cual es un conjunto de páginas web. Este directorio contiene referencial (enlaces o links) a lo que se conoce como archivos .torrent. Un archivo .torrent contiene la información necesaria para descargar un archivo específico. 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 colección 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 aún 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 más de lo que está distribuyendo (subiendo) a otros, P puede decidir reducir la velocidad a la que le envía información (parte de un archivo, en este caso). Este esquema trabaja bien, siempre que P tenga algo que descargar de Q. Por esta razón, los nodos obtienen referencias a muchos otros nodos, lo cual los sitúa en una mejor posición para negociar datos.

3.3 Arquitectura v.s. Middleware

Cuando se consideran los aspectos arquitectónicos que se han considerado hasta el momento, uno debe preguntarse dónde entra el middleware. Como se enseño en clases pasadas, el middleware forma una capa entre las plataformas de aplicación y distribución. Un propósito importante es proveer un cierto nivel de transparencia en la distribución, ocultando en lo posible la distribución de datos, el procesamiento y el control de la aplicación.

Lo que comúnmente pasa es que el middleware sigue un estilo arquitectónico específico. Por ejemplo, muchos sistemas de middleware han adoptado un estilo arquitectónico basado en objetos, tales como CORBA; otros, como TIB/Rendeznous, siguen el estilo arquitectónico basado en eventos.

El moldear el middleware a un estilo arquitectónico específico tiene la ventaja de diseñar aplicaciones más simples. Sin embargo, una desventaja es que el middleware puede volverse dejar de ser óptimo para lo que el desarrollador tenía en mente.

Aunque se supone que el middleware tiene como propósito transparentar la distribución, generalmente se requiere que el middleware se adapte a las aplicaciones. Una solución sería desarrollar varias versiones del middleware y otra sería el crear middleware fácilmente configurable y adaptable, según lo requiera la aplicación.

3.4 Autoadministración 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

Clase 03: Arquitecturas de Sistemas Distribuidos

adaptivos, más en cuanto a su comportamiento de su ejecución y no en cuanto a los componentes de software que lo conforman.

Cuando se requiere de adaptación automática, existe una fuerte interrelación 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; también decidir dónde deben ejecutarse los procesos para facilitar la adaptabilidad.

Conceptos:

Plataforma: Generalmente se refiere a la combinación hardware – sistema operativo que determina las principales características 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 aplicación.

HASH TABLES:

In computer science, a hash table or hash map is a data structure that uses a hash function to efficiently map certain identifiers or keys (e.g., person names) to associated values (e.g., their telephone numbers). The hash function is used to transform the key into the index (the hash) of an array element (the slot or bucket) where the corresponding value is to be sought.

Ideally the hash function should map each possible key to a different slot index, but this ideal is rarely

achievable in practice (unless the hash keys are fixed; i.e. new entries are never added to the table after creation). Most hash table designs assume that hash collisions — pairs of different keys with the same hash values — are normal occurrences and must be accommodated in some way.

In a well-dimensioned hash table, the average cost (number of instructions) for each lookup is independent of the number of elements stored in the table. Many hash table designs also allow arbitrary insertions and deletions of key-value pairs, at constant average (indeed, amortized [1] ) cost per operation.[2][3]

In many situations, hash tables turn out to be more efficient than search trees or any other table lookup structure. For this reason, they are widely used in many kinds of computer software, particularly for associative arrays, database indexing, caches, and sets.

Clase 03: Arquitecturas de Sistemas Distribuidos

Hash tables should not be confused with the hash lists and hash trees used in cryptography and data transmission.