Sistemas Distribuidos

Transcripción

En este capítulo trataremos las cuestiones de comunicación a tener en cuenta en un
sistema distribuido, no obstante lo haremos con un alto nivel de abstracción,
considerando el modelo de comunicación entre los distintos componentes del sistema.
En primer lugar abordaremos los mecanismos para referenciar los componentes que se
ofrecen un un sistema distribuido, esto es, la Denominación y Servicio de Nombres.
Seguidamente presentamos tres modelos concretos de comunicación apropiados para la
comunicación entre los procesos que componen el sistema distribuido: las llamadas a
procedimientos remotos (RPC’s) de Sun, la invocación a métodos remotos (RMI) de
Java y el modelo de CORBA.
Sistemas
Distribuidos
La particularidad de estos mecanismos estriba en que mantiene a los procesos
abstraídos del hecho de que forman un sistema distribuido, y que la comunicación entre
ellos se realiza de igual manera a la comunicación con los procesos locales de cada
máquina.
1. Introducción
2. Modelos arquitectónicos
3. Servicio de Nombres
1. El Modelo de Comunicación
2. Denominación y servicio de nombres
Servicio de Nombres - 1
La Comunicación - 1
Los Modelos de Comunicación
Máquina 1
P1
P3
P2
Máquina 2
P6
RED
P8
P4
P7
P9
Los componentes de un sistema distribuido no solamente están separados lógicamente,
sino también físicamente, por lo que requieren líneas de comunicaciones para
interaccionar.
Nosotros supondremos aquí que las aplicaciones y software básico de un sistema
distribuido están construidos de tal forma que todos los componentes que requieren o
proporcionan accesos a recursos están implementados como procesos.
Para que los procesos remotos implicados en un mismo trabajo puedan interaccionar,
parece claro que se va a requerir una comunicación entre ellos para:
- Transferencia de datos
- Sincronización de operaciones o acciones.
Los procesos
están separados
Para la implementación de un sistema de paso de mensajes entre distintos ordenadores
se requiere una red de comunicaciones con los consiguientes protocolos de
comunicación para la transmisión de datos y señales de sincronización. Nosotros nos
vamos a centrar únicamente en la semántica del alto nivel.
Lógicamente
Físicamente
Se requiere una línea de comunicaciones
para
Transferir Datos
¿Cómo se
Una Pareja
comunican un
grupo de
A un Grupo
procesos?
Sincronizarse
Modelo CLIENTE-SERVIDOR
Modelo MULTICAST
El mecanismo de comunicación que se va a utilizar para la comunicación entre procesos
remotos va a ser el paso de mensajes, con la misma semántica que el correspondiente a
los sistemas operativos centralizados. Es decir, que se va a disponer de primitivas de
envío y recepción de mensajes, y que estas operaciones pueden ser síncronas o
asíncronas (bloqueantes o no bloqueantes). Este mecanismo de comunicación por paso
de mensajes recibe diversos nombres, tales como canales, sockets o puertos.
El rendimiento global de un sistema distribuido tiene una dependencia crítica de los
mecanismos de los subsistemas de comunicaciones utilizados para la intercomunicación
de procesos. Y no depende únicamente de la optimización de los niveles bajos de
comunicaciones, sino de la implementación de la política o modelos de comunicaciones
utilizados.
En los dos siguientes apartados vamos a presentar los dos modelos de comunicación
más comúnmente utilizados en el diseño de sistemas distribuidos:
Modelo cliente-servidor, para comunicación entre parejas de procesos.
Modelo multicast, para comunicación entre grupos de procesos cooperantes.
Modelo Cliente
-
La Comunicación
cliente
servidor
1. petición
bloqueado
Servidor
2. procesando
3. respuesta
1. Cliente:
Envío → bloqueado
2. Servidor:Recibe → procesa → contesta
3. Cliente: Recibe respuesta → continúa
RPC
Averiguar_Nodo_Impresor
Imprimir (Fichero,Impresora,ok) Envía (Fichero, Nodo_Impresor)
Recibir (Respuesta, Nodo_Impresor)
LOS SERVIDORES SON DINÁMICOS
¿Cómo se Los servidores deben registrarse con un nombre de
servicio predefinido
conocen los
clientes y los
servidores?
LOS SERVIDORES NO CONOCEN A LOS CLIENTES
Los clientes deben incluir su id. en la petición
Clientes Y
Servidores
NO son máquinas
¡SON
PROCESOS !
El modelo cliente-servidor está orientado a la provisión de servicios. Una conversación
típica consiste en:
1. El proceso cliente transmite una petición al proceso servidor.
2. El proceso servidor ejecuta la petición solicitada.
3. El proceso servidor transmite la respuesta al cliente.
Este modelo implica la transmisión de dos mensajes y alguna sincronización entre el
cliente y el servidor. Es decir, el proceso servidor debe estar pendiente de la llegada de
peticiones del cliente, y a su recepción debe ejecutar el servicio solicitado y comunicar la
respuesta. El proceso cliente por su parte, una vez enviada la petición en el paso 1,
debe esperar bloqueado hasta la recepción de la respuesta después del paso 3.
Este modelo de comunicaciones puede implementarse directamente mediante el
mecanismo de paso de mensajes (operaciones enviar y recibir) del sistema operativo,
pero normalmente se utiliza una construcción del nivel del lenguaje que le abstrae al
programador de las operaciones de envío-espera-recepción. Esta construcción, que
veremos en detalle más adelante, en este capítulo, se conoce como RPC (Remote
Procedure Call) o Llamada a Procedimiento Remoto, y esconde las operaciones de
envío y recepción bajo el aspecto de la llamada convencional a una rutina o
procedimiento.
Estamos viendo cómo se comunica un cliente con un servidor, pero hay una cuestión
que aclarar: ¿cómo han llegado a conocerse el cliente y el servidor para iniciar una
comunicación?
Los procesos clientes no pueden programarse, a priori, con los identificadores de
comunicación de todos los servidores posibles de la red, por lo que se requiere algún
mecanismo que permita un enlace dinámico. Este mecanismo normalmente consiste en
que cuando un proceso servidor arranca, él mismo se registra en un servidor de
nombres indicando su dirección y el nombre predefinido del servicio que proporciona.
Cuando un cliente requiere un servicio, le pregunta a un servidor de nombres por la
dirección de algún servidor que ofrezca tal servicio, obteniendo así su identificador de
comunicación para enviarle la petición.
Por su parte, un proceso servidor, durante su vida, atiende a muchos procesos clientes
distintos sin tener conocimiento previo de ellos, por lo que cada petición debe incluir el
identificador de comunicación del proceso cliente que realiza la petición, para que así le
pueda responder.
Debe tenerse en cuenta que un proceso dado no tiene por qué ser exclusivamente
cliente o servidor. Un proceso se comporta como cliente o servidor en un intercambio
concreto de información o servicio, pero un servidor puede solicitar servicios de otro
servidor, convirtiéndose así en cliente, mientras que en un momento dado un cliente
puede estar prestando un servicio a otro proceso, convirtiéndose a su vez en servidor.
ambivalentes
Modelo Multicast
La Comunicación
MULTICAST
Envío de múltiples copias de un mismo
mensaje desde un proceso origen a
múltiples procesos de destino.
Recibe
Recibe
Búsqueda de un objeto o recurso. Un cliente puede enviar un mensaje a un grupo
de procesos servidores, y el que realmente tenga el objeto buscado será el único en
contestar.
Actualizaciones. Cuando se quiere actualizar información común entre varios nodos
–como tablas de encaminamiento o la hora– el proceso encargado del mantenimiento
se lo envía a los demás mediante multicast.
P3
Recibe
Recibe
P4
Envío a
Grupo
P0
Búsqueda de un recurso
APLICACIONES
DE
MULTICAST
Puede haber varios motivos para enviar un mismo mensaje a un grupo de nodos:
Tolerancia a fallos. Un cliente solicita un servicio muy importante mediante
multicast. Uno o más servidores procesan la petición y contestan. El cliente toma la
primera respuesta y deshecha las posteriores. De esta manera, se asegura una
respuesta aunque falle un servidor.
P2
P1
El modelo de comunicación multicast consiste en el envío de un mismo mensaje desde
un origen a un grupo de nodos de destino. No se debe confundir con broadcast (o
difusión), que es el envío de un mensaje de forma que pueda ser escuchado por todos
los nodos de la red, y que en sistemas distribuidos se utiliza con menor frecuencia.
Tolerancia a fallos
Hay diversos algoritmos o métodos para el envío de mensajes en modo multicast, desde
el mero envío secuencial de un mensaje tras otro desde el nodo origen, o la técnica de la
inundación, hasta los basados en árboles de expansión, pero su estudio no está entre
los objetivos de esta asignatura. No obstante sí debemos tener en cuenta que la
elección del algoritmo de envío utilizado puede repercutir seriamente en el rendimiento
general del sistema.
También puede ayudar a mejorar la velocidad de envío el disponer de cierto soporte
hardware que, para el algoritmo que le convenga, posibilite el envío paralelo de las
múltiples copias del mensaje.
El sistema de alto nivel que pueden utilizar los procesos para difundir mensajes a grupos
puede estar basado también en primitivas RPC, aunque con algún mecanismo adicional
en la primitiva de envío para poder indicar las direcciones a las que va dirigido el
mensaje (por ej. una tabla con todas las direcciones o direcciones de grupo).
Actualizaciones múltiples
La velocidad del envío multicast
depende del algoritmo utilizado y
del soporte hardware disponible.
Rendimiento
General del
Sistema
Denominación
La Comunicación
DENOMINACIÓN
(Gestión de Nombres)
Es la correspondencia entre
objetos lógicos y físicos
En un sistema distribuido hay que añadir una nueva dimensión a la abstracción: ¿En qué
lugar (máquina) de la red está el objeto referenciado?
ESTRUCTURA DE UN SISTEMA DE NOMBRES
PLANA
JERÁRQUICA
NotasDiaEuiUpmEs
dia.eui.upm.es/Notas.html
atc.eui.upm.es/Notas.html
Capacidad Finita
(nombres relativos al contexto)
Capacidad Ilimitada
Capacidad de Nombres ≠ Capacidad de Identificadores
Capacidad de Identificadores: Limitada
Internet
Capacidad de Nombres:
La denominación, o gestión de nombres, es la correspondencia entre objetos lógicos y
físicos. Por ejemplo, un usuario trata con conjuntos de datos representados por nombres
de ficheros, mientras que el sistema gestiona bloques físicos de datos almacenados en
pistas de un disco. Normalmente el usuario se refiere a un fichero por un nombre
textual, el cual posteriormente se traduce a un identificador numérico que acaba
refiriéndose a bloques de un disco. Esta correspondencia entre los dos niveles
proporciona a los usuarios una abstracción de cómo y dónde están realmente
almacenados los datos.
Capacidad y estructura del esquema de nombres . Veamos ahora cómo puede ser el
espacio de nombres en cuanto a su capacidad y estructura.
El Espacio de Nombres puede tener una capacidad Limitada o Infinita. El actual espacio
de las direcciones de Internet es un ejemplo de capacidad limitada (ej. 138.100.56.34).
En cuanto a su estructura, puede ser Plana o Jerárquica. La estructura plana de
nombres está asociada a espacios de nombres de capacidad finita (a no ser que la
longitud de los nombres sea ilimitada), mientras que en la estructura jerárquica las
direcciones pueden crecer indefinidamente. Cuando se utiliza la estructura jerárquica, se
dice que la resolución de nombres se realiza de “acuerdo al contexto”, es decir,
traduciendo cada uno de los nombres anteriores al nombre final que indican la jerarquía
por la que hay que pasar hasta llegar al objeto concreto. Ejemplo:
dia.eui.upm.es/notas.html hace referencia a un fichero (notas.html) situado
en la máquina dia de la eui de la upm. Para resolver tales nombres se va ascendiendo
por esta jerarquía de nombres, de tal forma que en cada nivel se es capaz de resolver el
nombre y obtener la dirección del siguiente nivel hasta llegar a la máquina de destino, y
en ella obtener el objeto con el nombre indicado (notas.html).
No se debe confundir la capacidad de nombres con la capacidad de identificadores de
dirección. Así, por ejemplo, aunque el actual sistema de direcciones de Internet es finito
(en número de máquinas), el número de algunos recursos referenciables en la red es
ilimitado, puesto que cada máquina puede contar con una estructura jerárquica de
ficheros potencialmente ilimitada (salvo por la capacidad y limitaciones de tablas).
Infinita
...Denominación
La Comunicación
Servidor
de
nombres
NOMBRE
[email protected]
IDENTIFICADOR DE
COMUNICACIÓN
138.100.56.67
+ Puerto
N1
b re
nom
Este nuevo servicio de resolución de nombres se denomina Servidor de Nombres (en
inglés también se le conoce como binder, ya que a la traducción de nombres se le
denomina binding). Así, cuando un cliente necesite conocer la dirección de cualquier
servidor, lo único que tiene que hacer es preguntárselo al servidor de nombres. Desde
luego, el servidor de nombres residirá en alguna máquina de dirección bien conocida.
Funciones del Servidor de Nombres. Ya hemos visto que la función básica del
servidor de nombres es la resolución o traducción de un nombre a un identificador, pero
requiere otros servicios adicionales:
id.
MAQ. 1
Podemos ver, entonces, la necesidad de la resolución o traducción de nombres por
identificadores de dirección. Una posibilidad sería que cada programa o sistema
operativo de un sistema distribuido se programara directamente con las direcciones de
todos los objetos actuales y futuros de la red completa, pero no resultaría muy práctico,
pues no es fácil conocer, a priori, todos los posibles objetos de una red, y sería imposible
realizar cualquier cambio de dirección. Parece mucho más razonable ver que esta
resolución de nombres no es más que un nuevo servicio que debe ofrecer el sistema a
los clientes.
Resolución: La traducción del nombre por el identificador de comunicación.
Inclusión: Añadir una pareja nombre/identificador al servidor de nombres.
Borrado: Eliminar una entrada del servidor de nombres.
Modificación: Modificación del nombre/identificador de una entrada.
id
.
N1 ID2
N2 ID7
…
…
N5 ID8
Recurso
SERVIDOR DE
NOMBRES
SERVIDOR
MAQ. 17
MAQ. 2
FUNCIONES DEL
SERVIDOR DE NOMBRES
Resolución
Inclusión
Borrado
Ya hemos comentado que cuando un cliente requiere cualquier servicio del sistema
distribuido, primero es necesario comunicarse con el servidor de nombres para obtener
el identificador de un servidor del servicio requerido. ¡Y si el servidor de nombres falla o
se cae? La respuesta es clara: Se pierden todos los accesos a los servicios del sistema.
Dada la importancia del servidor de nombres, cuyo funcionamiento es vital para el resto
del sistema, parece que se hace necesario que este servicio especial sea tolerante a
fallos. Teniendo en cuenta, además, que va a ser un servicio muy requerido, pues todas
las utilizaciones de cualquier servicio deben pasar primero por él, para facilitar la
tolerancia a fallos y evitar el cuello de botella, suele ser normal que el servicio de
nombres esté formado por servidores replicados que ofrezcan este servicio de nombres.
Modificación
¡Debe Ser Tolerante A Fallos!
...Denominación
Para comunicarse un cliente con un servidor, ANTES
debe comunicarse con un servidor de nombres
Para acceder a un objeto remoto, el proceso cliente (que sólo conoce el nombre del
recurso) debe conseguir el identificador de comunicación del recurso que solicita antes
de comunicarse realmente con él. Para ello debe acudir primero a los servidores de
nombres intermedios necesarios hasta conseguir dicho identificador de comunicación,
con el consiguiente tiempo de demora debido a los tiempos de resolución o traducción
de cada uno de los servidores de nombres requeridos.
N1
Cuando se está accediendo a menudo a un objeto remoto, para evitar el tiempo de
resolución de los nombres intermedios, el proceso cliente puede mantener una tabla
caché con los identificadores de dirección de los objetos más recientemente
referenciados, y utilizar directamente estos identificadores para acceder a los objetos.
La Comunicación
b re
nom
MAQ. 1
id
.
N1 ID2
N2 ID7
…
…
N5 ID8
Recurso
SERVIDOR DE
NOMBRES
SERVIDOR
MAQ. 17
En accesos
frecuentes
a un objeto
MAQ. 2
Para evitar tiempos de resolución de nombres
Utilizar CACHÉ LOCAL EN EL CLIENTE
N1
N2
…
N5
N1
ID 2
ID 7
…
ID 8
CACHÉ DE
NOMBRES
MÁQ. 1
id.
Recurso
SERVIDOR
MAQ. 2
...Denominación
La Comunicación
A la hora de diseñar un sistema de nombres o de denominación, se deben perseguir
estos dos objetivos:
• Transparencia de ubicación. El nombre de un objeto no debe revelar su ubicación
física.
SE DEBE PERSEGUIR
TRANSPARENCIA
DE UBICACIÓN
(estático)
• Independencia de ubicación. El nombre del objeto no debe cambiar cuando
cambie su ubicación física. Esto implica transparencia dinámica, ya que un nombre
puede asociar el mismo objeto a lugares diferentes en momentos distintos.
INDEPENDENCIA
DE UBICACIÓN
(dinámico)
Actualmente, la mayoría de los sistemas proporcionan simplemente la transparencia de
ubicación, por lo que no ofrecen migración, es decir, el cambio automático de
ubicación de un objeto sin afectar a sus usuarios o clientes. Chorus y Charlotte son
ejemplos de sistemas que permiten la migración.
MIGRACIÓN
Nombres Puros e Impuros. Los nombres puros son simplemente series de bits sin
ninguna interpretación posible (salvo para el servidor de nombres). Otros nombres (los
impuros) incluyen bits que indican directamente una dirección, permisos de acceso o
cualquier otra información sobre el objeto.
Los nombres impuros entran en conflicto con el principio de transparencia al que tanto
hemos aludido. Obsérvese que con un nombre impuro, cualquier información implícita
que lleve, puede quedarse obsoleta si el recurso al que se refiere cambia su dirección,
permisos, etc. Con los nombres puros simplemente hay que preocuparse de mantener
actualizadas las bases de datos de los servidores de nombres de cada contexto.
TIPOS DE NOMBRES
IMPUROS
PUROS
138.100.55.fenix
fenix.eui.upm.es
Tienen información
explícita
Sin interpretación
(salvo para el S.N.)
¿Si hay cambios?
¿Si hay cambios?
OBSOLETO
Requiere actualizaciones
del Servidor de Nombres
Por falta de
TRANSPARENCIA
...Denominación
La Comunicación
Si es fácil reproducir el id.
de un proceso sin pedirlo al
servidor de nombres
Puede haber accesos
no autorizados
El Servidor de Nombres debe comprobar la
identidad del cliente antes de proporcionar el id.
CREDENCIALES
(Capabilities)
Credencial de Amoeba
48
Puerto del servidor
24
8
48
Objeto
Derechos
Verificación
Control de acceso. Para evitar accesos no autorizados a los recursos del sistema, un
primer paso consiste en hacer que el identificador de un recurso no se pueda obtener
fácilmente a partir de su nombre si no es a través del servidor de nombres. Y, por
supuesto, el servidor de nombres debe ocuparse de comprobar la identidad del cliente
que solicita una resolución de nombres antes de darles el identificador solicitado. Los
identificadores que se comportan así, se denominan credenciales (capabilities). Por eso
se dice que para poder acceder a un recurso o servicio, previamente debe obtenerse la
credencial correspondiente.
Ejemplo: Credencial de Amoeba. Cuando un cliente requiere cierto servicio, en primer
lugar se identifica y solicita la credencial correspondiente al servidor de nombres, el cual
devuelve la credencial solicitada para el cliente identificado. Una vez se tiene la
credencial, se obtiene de ella el Puerto del servidor que va a prestar el servicio
requerido, con lo que ya se le puede enviar el mensaje con la petición del servicio y la
credencial completa.
El campo Objeto lo utiliza el servidor para identificar el objeto específico con el que el
cliente quiere realizar alguna operación. Para el caso de un archivo, este campo sería
algo parecido a un i-nodo de Unix.
Los Derechos están compuestos por una serie de bits que indican las operaciones que
le están permitidas al usuario para ese objeto (por ej. lectura, escritura, ...).
El campo Verificación se utiliza para dar validez a la credencial. La verificación la
establece el servidor de nombres mediante un cierto algoritmo en función del resto de
los campos de la credencial, y el servidor del objeto comprueba si la verificación que le
llega efectivamente es la correspondiente a esa credencial. De ser así, y si cuenta con
los derechos apropiados realiza la operación solicitada; en caso contrario, devolverá
algún código de error al cliente.
De esta manera se evita que cualquier proceso de la red solicite indiscriminadamente
cualquier operación, pues las credenciales solamente las pueden construir los
servidores de nombres, y solamente mediante éstas puede solicitarse operaciones a los
servidores.
...Denominación
La Comunicación
¿Dónde está el binder? El binder nos proporciona la dirección del servidor solicitado,
pero ¿cómo se lo pedimos al binder? ¿dónde está el binder?
Se tienen las siguientes alternativas:
...Denominación
La Comunicación
¿DÓNDE ESTÁ EL BINDER ?
Hay Varias Alternativas
En una
dirección fija
La sabe el S.O.
(var. entorno)
• Que los sistemas operativos de los clientes y de los servidores sean responsables
de proporcionar dinámicamente a sus procesos la dirección del binder. Esto puede
hacerse mediante variables de entorno. Si se reubica el binder, debe actualizarse la
dirección en la variable de entorno del sistema operativo, e informarse a los
usuarios para que rearranquen los procesos. Con este enfoque se permite la
reubicación ocasional del binder sin tener que recompilar todos los clientes y
servidores; normalmente, solo obliga a pararlos y rearrancarlos de nuevo.
Broadcast de
búsqueda
Si cambia la dirección del binder
Recompilar
Todos Clientes
y Servidores
Actualizar var.
de entorno del
S.O.
No Reubicación Dinámica
• Ubicar siempre al binder en un ordenador de dirección bien conocida, e incluirla al
compilar todos los clientes y servidores. Si se reubica el binder, se deben
recompilar todos los clientes y servidores con la nueva dirección. Obviamente, no
es posible la reubicación dinámica del binder.
Ante un fallo, el
cliente/servidor hace
broadcast de nuevo
• Cuando un cliente o un servidor arranca, difunde un mensaje por toda la red para
localizar al binder. Cuando un proceso binder reciba este mensaje, contesta al
emisor con su dirección. Mediante este sistema, el binder puede ejecutarse
siempre sobre cualquier ordenador y reubicarse dinámica y fácilmente.
Reubicación
Dinámica

Sistemas Distribuidos

Transcripción

Documentos relacionados

Apuntes de identificadores - Universidad Nacional de Tucumán