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

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
 Clase 03: Arquitecturas de Sistemas Distribuidos

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
proceso a proceso. A esto se le conoce como desacoplamiento en el espacio o referencialmente
desacoplados.
 Clase 03: Arquitecturas de Sistemas Distribuidos

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.

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

 Clase 03: Arquitecturas de Sistemas Distribuidos

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).

Figura 3.6. (a) Sistema peer-to-peer (P2P), (b) Sistema centralizado con cervidor
 Clase 03: Arquitecturas de Sistemas Distribuidos

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
conexiones entre peers no es determinada por un algoritmo. Napster es un ejemplo de
sistema no estructurado centralizado.
 Clase 03: Arquitecturas de Sistemas Distribuidos

 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.

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
 Clase 03: Arquitecturas de Sistemas Distribuidos

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
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
 Clase 03: Arquitecturas de Sistemas Distribuidos

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.

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