Este documento presenta una introducción a los modelos fundamentales de sistemas distribuidos. Explica brevemente los modelos de interacción, fallos y seguridad, así como los modelos arquitectónicos más comunes como cliente-servidor, procesos peer-to-peer y capas de software. Finalmente, analiza conceptos clave como interfaces, objetos distribuidos e invocación remota en sistemas distribuidos.
2. AGENDA
Introducción
Modelos Arquitectónicos
Modelos Fundamentales
Networking e Internetworking
Comunicación entre procesos
Objetos Distribuidos e invocación remota.
3. Introducción
Un modelo arquitectónico de un sistema
distribuido trata sobre la colocación de sus
partes y las relaciones entre ellas.
Modelo Cliente – Servidor.
Modelo de procesos peer to peer.
Los modelos fundamentales están implicados
en una descripción más formal de las
propiedades que son comunes en todos los
modelos arquitectónicos.
4. Introducción
Algunos problemas como la falta de
sincronización de relojes y la pérdida de
mensajes se consideran en tres modelos:
El modelo de interacción, que trata de las
prestaciones y de la dificultad de poner límites
temporales en un sistema distribuido.
El modelo de fallos que intenta dar una
especificación de los fallos que se producen en los
procesos y en los canales de comunicación.
El modelo de seguridad que discute sobre las
posibles amenazas para los procesos y los canales
de comunicación.
6. Modelos Arquitectónicos
La arquitectura de un sistema es su estructura en
términos de componentes especificados por
separado.
Un modelo simplifica y abstrae las funciones de
los componentes individuales del sistema en
cuestión y considera:
La ubicación de los componentes en la red,
definiendo los patrones utilizables para la distribución
de datos y carga de trabajo.
Las interrelaciones entre los componentes, sus
papeles funcionales y los patrones de comunicación
entre ellos.
7. Modelos Arquitectónicos
Un primer acercamiento es clasificar los procesos
entre servidores, clientes e iguales, lo que permite
identificar las responsabilidades de cada uno y
ayuda a valorar sus cargas de trabajo y a
determinar el impacto de los fallos en cada uno
de ellos.
Los resultados de este análisis puede ser
utilizado para especificar la distribución de los
procesos de forma que concuerde con los
objetivos de prestaciones y fiabilidad del sistema
resultante.
8. Modelos Arquitectónicos
Se pueden construir otros sistemas dinámicos
como variaciones del modelo cliente servidor:
La posibilidad de mover código de un proceso a otro
permite que un proceso delegue tareas en otro
(ejecución local). Los objetos y el código puede
reubicarse para reducir los retardos de acceso y
minimizar el tráfico de la comunicación.
Algunos sistemas se diseñan para permitir que las
computadoras y otros dispositivos móviles se añadan
o eliminen sin incidencias, permitiendo el
descubrimiento de servicios disponibles y ofrecer sus
servicios a otros.
9. Capas de Software
El término arquitectura de
software se refiere a la
estructura del software
como capas o módulos en
una única computadora y
más recientemente en
términos de los servicios
ofrecidos y solicitarlos
entre procesos localizados
en el mismo o diferentes.
Esta vista orientada a
procesos y a servicios
puede expresarse en
términos de capas de
servicio.
Aplicación de
servicios
Middleware
Sistema Operativo
Computadora y
Hardware de red
P
L
A
T
A
F
O
R
M
A
10. Capas de Software
Plataforma
• Se considera el nivel de hardware y las capas más bajas de software.
• Estas capas proporcionan servicios a las que están por encima de ellas, y
que son implementadas independientemente en cada computadora,
proporcionando una interfaz de programación del sistema.
Middleware
• Se representa mediante procesos u objetos en un conjunto de
computadoras que interactúan entre sí para implementar mecanismos de
comunicación y recursos compartidos para aplicaciones distribuidas.
• Mejora el nivel de las comunicaciones soportando abstracciones como:
procedimiento de invocación remota, comunicación entre un grupo de
procesos, notificación de eventos, replicación de datos compartidos y
transmisión de datos multimedia en tiempo real.
11. Capas de Software
Considere a CORBA, ofrece una variedad de
servicios que proporcionan a las aplicaciones
funciones que incluyen la gestión de nombres,
seguridad, transacciones, almacenamiento
persistente y notificación de eventos.
Los servicios de la capa superior son servicios
específicos del domino que utiliza el
middleware, sus operaciones de comunicación
y sus propios servicios.
12. Arquitecturas de Sistema
La división de responsabilidades entre los
componentes del sistema (aplicaciones,
servidores y otros procesos) y la ubicación de
los componentes en las computadoras en red,
es el aspecto más evidente del diseño de un
sistema distribuido.
Sus implicaciones fundamentales están en las
prestaciones, fiabilidad y seguridad del sistema
resultante.
En un sistema distribuido, los procesos con
responsabilidades bien definidas interactúan
con los otros para realizar una actividad útil.
13. Modelo cliente – servidor
Históricamente es la más importante, el fin
principal es acceder a los recursos compartidos
que ellos gestionan.
Los servidores pueden, a su vez, ser clientes de
otros servidores.
Los buscadores, que permiten a los usuarios buscar
resúmenes de la información disponible en las
páginas web de los sitios de Internet.
Los resúmenes están realizados por programas
denominados escaladores, que se ejecutan en
segundo plano en el sitio del buscador utilizando
peticiones HTTP para acceder a los servidores web
en Internet.
14. Modelo cliente – servidor
Las tareas del servidor (responder a las consultas
de usuarios) y las tareas de los escaladores
(hacer peticiones a otros servidores web) son
totalmente independientes; pueden ejecutarse
concurrentemente.
Un buscador típico debiera incluir muchos hilos
de ejecución concurrente, algunos sirviendo a
sus clientes y otros ejecutando escaladores web.
16. Servicios proporcionados por
múltiples servidores
Los servidores pueden implementarse como
distintos procesos de servidor en
computadoras separadas interaccionando,
para proporcionar un servicio a los procesos
clientes.
Los servidores pueden dividir el conjunto de
objetos en los que está basado el servicio y
distribuírselos entre ellos mismos, o mantener
copias replicadas de ellos en varias máquinas.
18. Servicios proporcionados por
múltiples servidores
La web maneja una partición de datos en el
que cada servidor web administra su propio
conjunto de recursos.
Un usuario puede emplear un navegador para
acceder al recurso en cualquiera de los
servidores.
La replicación se utiliza para aumentar las
prestaciones y disponibilidad y para mejorar la
tolerancia a fallos.
Proporciona múltiples copias consistentes de
datos en procesos que se ejecutan en
diferentes computadoras.
20. Servidores proxy y cachés
Un caché es un almacén de objetos de datos
utilizados recientemente, y que se encuentran
más próximo que los objetos en sí.
Al recibir un objeto nuevo en una computadora
se añade al caché, reemplazando, si fuera
necesario algunos objetos existentes.
Cuando se necesita un objeto en un proceso
cliente, el servicio caché comprueba inicialmente
la caché y le proporciona el objeto de una copia
actualizada.
Si no, se buscará una copia actualizada
21. Servidores proxy y cachés
Las cachés pueden estar en cada cliente o en
un servidor proxy que puede compartirse
desde varios clientes.
Los navegadores mantienen una caché de las
páginas visitadas recientemente, y de otros
recursos web, en el sistema local de ficheros
del cliente; utilizan una petición HTTP para
comprobar si dichas páginas han sido
actualizadas.
Los servidores proxy para el web proporcionan
una caché compartida de recursos web a las
máquinas cliente de uno o más sitios.
22. Servidores proxy y cachés
El propósito de los servidores proxy es
incrementar la disponibilidad y prestaciones
del servicio, reduciendo la carga en redes de
área amplia y en servidores web.
24. Procesos <<de igual a igual>>
En esta arquitectura todos los procesos
desempeñan tareas semejantes,
interactuando cooperativamente como iguales
para realizar una actividad distribuida sin
distinción entre clientes y servidores.
El código en los procesos parejos o
<<iguales>> mantiene la consistencia de los
recursos y sincroniza las acciones a nivel de
la aplicación cuando es necesario.
25. Procesos <<de igual a igual>>
En general n procesos parejos podrán interactuar entre
ellos, dependiendo el patrón de comunicación de los
requisitos de la aplicación.
La eliminación del proceso servidor reduce los retardos
de comunicación entre procesos al acceder a objetos
locales.
26. Procesos <<de igual a igual>>
Considerando una aplicación de pizarra
distribuida que permite que usuarios en varias
computadoras vean y modifiquen
interactivamente un dibujo que se comparte.
Se puede implementar con un proceso de
aplicación en cada sitio y que se basa en capas
de middleware para realizar notificación de
eventos y comunicación a grupos para indicar a
todos los procesos de la aplicación de los
cambios en el dibujo.
Proporciona a los usuarios de objetos distribuidos
una respuesta interactiva mejor que la que se
puede obtener con una arquitectura basada en
28. Interfaz
Se conoce como la especificación del conjunto
de funciones que se pueden invocar sobre él.
En la forma básica de la arquitectura cliente –
servidor, se considera cada proceso servidor
como una entidad aislada con una interfaz
prescrita que define las funciones que ofrece.
29. Requisitos para el diseño de
arquitecturas distribuidas
La idea de compartir se logró, en los sistemas
de tiempo compartido de los años 70 con la
utilización de los archivos compartidos.
Los beneficios se explotaron en sistemas
operativos como Oracle para permitir que los
procesos compartieran recursos, dispositivos
y procesos de aplicación para compartir
objetos de aplicación.
31. Diseño de Arquitecturas
Distribuidas
Calidad de Servicio
Propiedades no
funcionales:
*fiabilidad
*seguridad
*prestaciones
La facilidad de
adaptación
para adecuar
configuraciones
variables de
sistema y
disponibilidad.
Algunas
aplicaciones
mantienen
datos críticos
en el tiempo,
flujos de datos
que precisan
ser procesados
o transferidos
de un proceso
a otro
Implica un
requisito para
que el sistema
proporcione
recursos
garantizados de
computación y
comunicación
que sean
suficientes para
permitir a las
aplicaciones
finalizar cada
tarea a tiempo
Cada recurso
crítico debe
reservarse para
las aplicaciones
que requieren
QoS y deben
ser los gestores
de los recursos
los que
proporcionen
las garantías.
Las solicitudes
de reserva se
pueden
rechazar
33. Modelos fundamentales
Todas las arquitecturas comparten algunas
propiedades fundamentales:
Procesos que se comunican por paso de mensajes a
través de una red de computadores
En particular, trataremos con tres aspectos
Interacción: el modelo debe definir y clasificar la
comunicación entre elementos del sistema
Fallos: el modelo debe definir y clasificar los fallos
que pueden darse en el sistema.
Seguridad: el modelo debe definir y clasificar los
tipos de ataque que pueden afectar al sistema.
34. Modelo de interacción
Respecto a la interacción, los sistemas
distribuidos deben tener en cuenta que
Hay limitaciones debidas a la comunicación
Es imposible predecir el retraso con el que llega un
mensaje
Es imposible tener una noción global de tiempo
La ejecución es no determinista y difícil de depurar
Algoritmo distribuido
Definición de los pasos que hay que llevar a cabo por
cada uno de los procesos del sistema, incluyendo los
mensajes de transmisión entre ellos
35. Modelo de interacción
Prestaciones del canal de comunicación
Latencia
Retardo entre el envío de un mensaje y su
recepción
Ancho de banda
Información que puede transmitirse en un
intervalo de tiempo
Fluctuación (jitter)
Variación del tiempo invertido en repartir una
serie de mensajes
36. Modelo de interacción
Relojes y eventos de tiempo
Cada computador tiene su propio reloj interno
(reloj local)
Puede usarse en procesos locales para marcas de
tiempo
Tasa de deriva de reloj (clock drift rate)
Diferencia entre un reloj local y un reloj de referencia
“perfecto”
Receptores GPS
Network Time Protocol (NTP)
Mecanismos de ordenación de eventos
Dos tipos de modelo de interacción
Síncrono y asíncrono
37. Modelo de interacción
Modelos síncronos
Conocimiento de características temporales:
El tiempo de ejecución de cada etapa de un proceso tiene
ciertos
límites inferior y superior conocidos
Cada mensaje transmitido sobre un canal se recibe en un
tiempo límite conocido
Cada proceso tiene un reloj local cuya tasa de deriva
sobre el tiempo de referencia tiene un límite conocido
A nivel teórico, podemos establecer unos límites para
tener una idea aproximada de cómo se comportará el
sistema
A nivel práctico, es imposible garantizar esos límites
siempre
Aunque a veces se pueden utilizar, por ejemplo como
38. Modelo de interacción
Modelos asíncronos
No hay limitaciones en cuanto a
Velocidad de procesamiento
Retardos en la transmisión de mensajes
Tasas de deriva de los relojes
Los sistemas distribuidos reales suelen ser
asíncronos
Por ejemplo, Internet
Una solución válida para un sistema asíncrono
lo es también para uno síncrono
39. Modelo de interacción
Ordenación de eventos
Podemos describir un sistema en términos de
eventos, solucionando así la falta de precisión de
los relojes
Imaginemos un grupo de usuarios de correo (X, Y,
Z, A)
X manda un mensaje m1 con el asunto Reunión
Y y Z responden con mensajes m2 y m3,
respectivamente y en ese orden, con el asunto Re:
Reunión
Debido a la independencia en los retardos de cada
envío, el usuario A podría ver lo siguiente:
41. Modelo de interacción
Ordenación de eventos
Si los relojes de X, Y y Z estuvieran sincronizados,
podríamos incluir el tiempo local t1, t2, t3 en los
mensajes m1, m2, m3
Estaríamos seguros de que t1 < t2 < t3
Podríamos ordenar los mensajes en concordancia
Pero los relojes no suelen estar sincronizados
Lamport [1978] propuso un modelo de tiempo lógico
Infiere el orden de los mensajes sin recurrir al tiempo físico
Se basa en las siguientes afirmaciones
Un mensaje siempre se recibe después de enviarlo
X manda m1 antes de que Y reciba m1
La réplica no se envía hasta que no se ha recibido el original
Y recibe m1 antes de que envíe m2
43. Modelo de fallo
Estudio de las causas posibles de fallo
Para poder comprender sus consecuencias
Tipo de fallo según la entidad
Fallos de proceso
Fallos de comunicación
Tipo de fallo según el problema
Fallos por omisión
No se consigue realizar una acción que se debería poder
hacer
Fallos arbitrarios (bizantinos)
Errores de cualquier tipo, fuera del esquema de mensajes
Fallos de temporización
Superación de tiempos límite en un sistema síncrono
44. Modelo de fallo
Fallo por omisión en procesos
Fallo del procesamiento (crash)
Detección del fallo por timeouts (síncrono)
Si el proceso no responde, consideramos que ha
habido un fallo
En sistemas asíncronos, nunca podemos estar
seguros
Fallo-parada (fail-stop)
Fallo de procesamiento que puede ser detectado
con certeza por el resto de procesos
46. Modelo de fallo
Fallos arbitrarios o bizantinos
En proceso:
Se omiten pasos necesarios o deseables del
procesamiento
Se realizan pasos innecesarios o indeseables en el
procesamiento
Se omite arbitrariamente la respuesta a mensajes
En canales de comunicación
Corrupción de mensajes
Reparto de mensajes inexistentes
Duplicación del reparto de mensajes auténticos
Origen: problema de los generales bizantinos
Lamport, Shostak and Pease (1982). “The Bizantine
Generals’ Problem”. ACM Transaction on
Programming Languages and Systems 4 (3): 382-401
47. Modelo de fallo
Fallos bizantinos
El problema es encontrar un algoritmo para
asegurar que los “generales leales” lleguen a
un acuerdo.
Se muestra que, usando sólo los mensajes
orales, este problema tiene solución si y sólo
si hay más de dos tercios de los generales
son leales
49. Modelo de fallo
Fallos de temporización
Sistemas síncronos
Sistemas asíncronos
No existen fallos de temporización, ya que no se
ha dado ninguna garantía al respecto
50. Modelo de fallo
Enmascaramiento de fallos
Construcción de servicios fiables a partir de
componentes que presenten fallos
Por ocultación del error
Por conversión a fallos más aceptables
Por ejemplo:
Checksum a de fallo arbitrario a fallo por
omisión
+retransmisión a de fallo por omisión a
ocultación
51. Modelo de fallo
Comunicación fiable entre dos procesos
Debe cumplir con dos criterios:
Validez
Cualquier mensaje en el búfer de mensajes salientes
llegará, eventualmente, al búfer de mensajes
entrantes
Es decir, no hay fallos por omisión en el canal
Integridad
El mensaje recibido es idéntico al enviado, y no se
repiten mensajes
Protocolo que adjunta números de secuencia a los
mensajes
Canales de comunicación seguros
No hay fallos bizantinos en el canal
52. Modelo de seguridad
La seguridad en un sistema distribuido se
basa en la seguridad de los procesos y
canales utilizados
Entendida como seguridad de objetos
Almacenados e invocados por los procesos
Transmitidos a través de los canales
Se logra mediante un sistema de derechos de
acceso y distintos tipos de autoridad
53. Modelo de seguridad
Principal y derechos de acceso
Principal: autoridad con la que se ordena
cada invocación de objetos o sus resultados
Se contrasta con los derechos de acceso de
dicho objeto
54. Modelo de seguridad
Modelo de enemigo
Entidad
Cualquier máquina conectada (de forma autorizada o
no) a la red
Enemigo: entidad capaz de
Enviar cualquier mensaje a cualquier proceso
Leer o copiar cualquier mensaje compartido entre dos
procesos
Leer mensajes o emitir mensajes falsos de petición
de servicios
55. Modelo de seguridad
Amenazas
Amenazas a servidores
Ciertos servicios no comprueban la identidad del cliente
Si la comprueban, no suele ser difícil suplantarla (spoofing)
En vez de una petición de servicio auténtica se busca, p.
ej., obtener información no autorizada o bloquear el
servicio (DoS)
Amenazas a clientes
Reciben un resultado falso de la invocación al servicio
Generalmente, acompañado de suplantación de identidad
Amenazas a canales de comunicación
Inyección, copia o alteración de mensajes que viajan por el
canal
Por ejemplo: obtener un mensaje de transferencia de
dinero, cambiar la cuenta y reenviarlo después
56. Modelo de seguridad
Técnicas de seguridad
Autenticación: comprobación de la identidad del
proceso
Criptografía: uso de claves públicas y privadas
Canales seguros: canal de comunicación sobre
el que dos procesos han establecido una capa de
seguridad basada en criptografía + autenticación:
Se garantiza la identidad fiable de servidores y
clientes
Se garantiza la integridad y privacidad de los
mensajes enviados
Los mensajes incluyen una marca de tiempo para
prevenir su repetición o reordenación maliciosa
Notas del editor
Las prestaciones de los visualizadores web clientes, se accede localmente a páginas e imágenes de la cache, por lo que se encuentran almacenadas en la aplicación cliente.
El ejemplo visualiza que explota la funcionalidad del servicio de búsqueda de nombres de dominio para devolver una de las varias direcciones de host para un único nombre de dominio