Sistemas Distribuidos

Definiciones
Sistemas Distribuidos
Por: Mariela Curiel
Basado en los textos :
Sistemas Distribuidos Conceptos y Diseño
G. Coulouris, J. Dollimore, TimKinberg
Ejemplos
Desafíos en el diseño de sistemas
distribuidos
Modelos Arquitectónicos
Modelos fundamentales para describir
sistemas distribuidos

Definiciones Definición
``Se define un sistema distribuido como Esta definición tiene las siguientes
aquel en el que los componentes de consecuencias:
hardware y software, localizados en ? Concurrencia
computadores unidos mediante una ? Inexistencia de un reloj global
red, comunican y coordinan sus ? Fallos Independientes
acciones sólo mediante el paso de
mensajes´´, (c,d,k, 2001)

1
 Definiciones
``Un sistema distribuido se compone de
un grupo de computadores autónomos,
enlazados mediante una red y
equipados con un software de sistemas
distribuidos. Este software permite que
los computadores coordinen sus
actividades y compartan recursos.
Definiciones
Los usuarios de un sistema distribuido
bien diseñado deberían percibir un
sistema de computación único e
integrado, aun cuando las máquinas
estén dispersas geográficamente´´
(c,d,k, 1998)

Definiciones Ejemplos
``Un sistema distribuido es un grupo de Internet
computadores independientes que son Intranets
percibidas por los usuarios como un Computación Móvil
único computador´´, (tanenbaum, 1995)

2
 Desafíos Desafíos: Heterogeneidad
Heterogeneidad Tolerancia a Fallas La heterogeneidad se aplica en los
Extensibilidad Concurrencia siguientes elementos:
Seguridad Transparencia ? Redes
Escalabilidad ? Hardware de computadores
? Sistemas operativos
? Lenguajes de programación
? Implementaciones de diferentes
desarrolladores

Desafíos: Heterogeneidad Desafíos: Heterogeneidad

Middleware: es el estrato de software
que provee una abstracción de
programación, así como un
enmascaramiento de la heterogeneidad
subyacente de las redes, hardware,
sistemas operativos y lenguajes de
programación. Ejem: Corba, Java RMI
Heterogeneidad y código móvil
? Código Móvil: código que puede enviarse
desde un computador a otro y ejecutarse
en este último.
? Elconcepto de máquina virtual ofrece un
modo de crear código ejecutable sobre
cualquier hardware

3
 Desafíos: Extensibilidad
Es la característica que determina si el
sistema puede extenderse de varias
maneras. Un sistema puede ser abierto
o cerrado con respecto a extensiones
de hardware o de software.
Para lograr la extensibilidad es
imprescindible que las interfaces clave
sean publicadas.
Desafíos: Seguridad
La seguridad tiene tres componentes:
Confidencialidad: protección contra
individuos no autorizados
Integridad: protección contra la alteración o
corrupción
Disponibilidad: protección contra la
interferencia que impide el acceso a los
recursos
Desafíos: Extensibilidad
Los Sistemas Distribuidos Abiertos pueden
extenderse a nivel de hardware mediante la
inclusión de computadoras a la red y a nivel
de software por la introducción de nuevos
servicios y la reimplementación de los
antiguos.
Otro beneficio de los sistemas abiertos es su
independencia de proveedores concretos.
Desafíos: Seguridad
Existen dos desafíos que no han sido
resueltos en su totalidad:
? Ataques de denegación de servicio
? Seguridad del código móvil
4
 Desafíos: Escalabilidad
Se dice que un sistema es escalable si
conserva su efectividad cuando ocurre un
incremento significativo en el número de
recursos y en el número de usuarios.
El diseño de SD escalables presenta los
siguientes retos:
Control de costo de los recursos físicos : para
que un sistema con n usuarios sea escalable,
la cantidad de recursos físicos necesarios
para soportarlo debería ser O(n).
Desafíos: Escalabilidad
Prevenir el desbordamiento de los
recursos de software
Desafíos: Escalabilidad
Controlar la degradación del
rendimiento: Ejm: Los algoritmos que
emplean estructuras jerárquicas se
comportan mejor frente al crecimiento
de la escala, que los algoritmos que
emplean estructuras lineales.
Evitar cuellos de botella: los algoritmos
deberían ser descentralizados.
Desafíos: Tratamiento de
Fallos
Detección de fallos: Ejem. Se pueden
utilizar sumas de comprobación
(checksums) para detectar datos
corruptos en un mensaje.
Enmarascamiento de fallos: Ejem.
? Los mensajes pueden retransmitirse
? Replicar los datos
5
 Desafíos: Tratamiento de
Fallos
Tolerancia de fallos: los programas clientes
de los servicios pueden diseñarse para
tolerar ciertos fallos. Esto implica que los
usuarios tendrán también que tolerarlos.
Recuperación de fallos: implica el diseño
de software en el que, tras una caída del
servidor, el estado de los datos puede
reponerse o retractarse (rollback) a una
situación anterior.
Redundancia: emplear componentes
redundantes.
Desafíos:Transparencia
Transparencia de acceso: permite acceder a
los recursos locales y remotos empleando
operaciones idénticas.
Transparencia de ubicación: permite acceder
a los recursos sin conocer su localización.
Transparencia de concurrencia: permite que
varios procesos operen concurrentemente
sobre recursos compartidos sin interferencia
mutua.
Desafíos: Concurrencia
Existe la posibilidad de acceso concurrente a
un mismo recurso.La concurrencia en los
servidores se puede lograr a través de
threads.
Cada objeto que represente un recurso
compartido debe responzabilizarse de
garantizar que opera correctamente en un
entorno concurrente.
Para que un objeto sea seguro en un entorno
concurrente, sus operaciones deben
sincronizarse de forma que sus datos
permanezcan consistentes.
Desafíos:Transparencia
Transparencia de replicación: permite replicar
los recursos sin que los usuarios y los
programadores necesiten su conocimiento.
Transparencia frente a fallos: permite ocultar
fallos.
Transparencia de movilidad: permite la
reubicación de recursos y clientes en un
sistema sin afectar la operación de los
usuarios y los programas.
6
 Desafíos:Transparencia
Transparencia de rendimiento: permite
reconfigurar el sistema para mejorar el
desempeño según varíe su carga.
Transparencia al escalado: permite al
sistema y a las aplicaciones expandirse
en tamaño sin cambiar la estructura del
sistema o los algoritmos de aplicación.
Modelos arquitectónicos
Modelo Arquitectónico de un SD: trata sobre
la colocación de sus partes y las relaciones
entre ellas. Ejem: modelo cliente-servidor y el
modelo de procesos de ¨igual a igual¨ (peer-
to-peer)
Diferentes modelos arquitectónicos:
? Capas de Software
? Arquitecturas de Sistema
? Interfaces y Objetos

Capas de Software Capas de Software

El término arquitectura de software se Plataforma: estas capas
Aplicación de
refería inicialmente a la estructuración servicios
más bajas proporcionan
servicio a las superiores y
del software como capas en un único
su implementación es
computador. Más recientemente las Middleware
dependiente de cada
capas son uno o varios procesos, Sistema computador.
localizados en el mismo o diferentes Operativo
Plataforma
computadores, que ofrecen y solicitan Computador y
Hw. de red
servicios.

7
 Capas de Software:
Capas de Software
Middleware
Middleware:es una El middleware se ocupa de proporcionar
Aplicación de capa de software cuyo bloques útiles para la construcción de
servicios
propósito es componentes de software que puedan
enmascarar la trabajar con otros en un sistema distribuido.
Middleware heterogeneidad y En particular mejora el nivel de las
proporcionar un modelo actividades de comunicación de los P. de
Sistema de programación aplicación soportando abstracciones como:
Operativo conveniente para los llamadas a procedimientos remotos,
Computador y programadores de comunicación entre un grupo de procesos,
Hw. de red aplicaciones
etc.

Capas de Software: Capas de Software:

Middleware
Ejem: Sun RPC (llamadas a
procedimientos remotos), CORBA
(middleware orientado a objeto), Java
RMI (invocación de objetos remotos en
Java), DCOM (Modelo común de
objetos distribuidos de Microsoft)
Middleware
El middleware también puede
proporcionar otros servicios, aparte de
la comunicación, para su uso en
programas de aplicación. Por ejemplo:
gestión de nombres, seguridad,
almacenamiento persistente, etc.

8
 Arquitecturas de Sistema Modelo Cliente-Servidor
Invocación Resultado
Modelo Cliente-Servidor Cliente
Servidor

Servicios proporcionados por múltiples Resultado

Servidor Invocación
servidores
Servidores proxy y caches Cliente

Proceso
Procesos peer-to-peer
Computador

- El servidor puede o no estar en la misma máquina del cliente

- Tanto servidores como clientes pueden ser iterativos o concurrentes

Servicios proporcionados por Servidores Proxy y Caches

múltiples servidores Servidor
Servidor
Cliente Web
Proxy
Servidor Servidor
Proxy
Cliente
Cliente Servidor
Servidor Servidor
Web
Proxy
Cliente
Servidor -Un cache es un almacén de objetos de datos utilizados
recientemente.
-Los caches pueden estar ubicados en los clientes o en un servidor
servicio
Proxy que se puede compartir desde varios clientes.
-Los servidores pueden dividir el conjunto de objetos en los que -El propósito de los servidores proxy es incrementar la disponibilidad
está basado el servicio y distribuírselos entre ellos mismos.
y las prestacionesdel servicio, reduciendo la carga en las redes de área
- Pueden mantener réplicas de los objetos en cada máquina.
Amplia y en los servidores WEB.

9
 Procesos Peer-to-Peer Interfaces y Objetos
Todos los procesos
Servidor Servidor desempeñan tareas Una interfaz de un proceso es la
Proxy
Aplicación Proxy
Aplicación semejantes, interactuando especificación del conjunto de funciones que
Código de Código de cooperativamente como
Coord. Coord. se pueden invocar sobre él.
iguales para realizar una
actividad distribuida o cómputo En lenguajes orientados a objetos, los
sin distinción entre clientes y procesos distribuidos pueden ser construidos
Servidor servidores de una forma más orientada al objeto. Las
Proxy
Aplicación Los procesos pares mantienen referencias a estos objetos se pasan a otros
Código de la consistencia de los recursos procesos para que se pueda acceder a sus
Coord.
y sincroniza las acciones a
nivel de aplicación. métodos de forma remota. Esta es la
aproximación adoptada por CORBA y Java
RMI.

Otros Modelos Otros Modelos

Arquitectónicos
Código Móvil
Agente Móvil: es un programa que se
traslada en la red, de un computador a otro,
realizando una tarea para alguien. Ejem.
Recolecta información.
Computadores en red: se descarga desde
un servidor remoto el sop y cualquier
software de aplicación necesario.
Arquitectónicos
Clientes Ligeros: en el cliente sólo se
ejecuta una interfaz basada en
ventanas, mientras que la aplicación si
se ejecuta en un servidor remoto,
usualmente muy potente
(multiprocesador, clusters, etc.)

10
 Requisitos para el diseño de
Arquitecturas Distribuidas
Rendimiento
? Capacidad de respuesta: para obtener buenos
tiempos de respuesta los sistemas deben estar
compuestos por pocas capas de software y la
cantidad de datos transferida debe ser pequeña
(ejem. Uso de proxys y caches)
? Productividad: trabajos/unidad de tiempo
? Balance de cargas: applets, varios servidores o
computadores para alojar un único servicio.
Requisitos para el diseño de
Arquitecturas Distribuidas
Calidad de Servicio
El satisfacer tales exigencias depende de la
disponibilidad de los recursos en los
instantes adecuados.
Cada recurso crítico debe reservarse para las
aplicaciones que requieren QoS. Los
administradores de los recursos deben
proporcionar la garantía. Las solicitudes de
reserva que no se puedan cumplir se
rechazan.
Requisitos para el diseño de
Arquitecturas Distribuidas
Calidad de Servicio
Algunas aplicaciones mantienen datos
críticos en el tiempo, flujos de datos que
precisan ser procesados o transferidos
de un proceso a otro a una tasa pre-
fijada.
QoS es la capacidad de los sistemas
para satisfacer dichos límites.
Requisitos para el diseño de
Arquitecturas Distribuidas
Aspectos de Fiabilidad (que el sistema
funcione correctamente)
Correctitud
Tolerancia de fallos
Seguridad:
? Confidencialidad
? Integridad
? Disponibilidad
11
 Requisitos para el diseño de
Arquitecturas Distribuidas
Tolerancia a Fallos: las aplicaciones
estables deben continuar funcionando
correctamente en presencia de fallos de
hw, sw y redes.
? Se logra con redundancia
? Para hacer fiable un protocolo de
comunicación se emplean otras técnicas.
Ejem. Retransmitir el mensaje.
Modelos Fundamentales
Los modelos fundamentales están implicados
en una descripción más formal de las
propiedades que son comunes en los
modelos arquitectónicos.
Ayudan a localizar los problemas clave para
los diseñadores de SD. Su propósito es
especificar los problemas, dificultades y
amenazas que deben superarse para
desarrollar sistemas distribuidos fiables.
Requisitos para el diseño de
Arquitecturas Distribuidas
Seguridad: necesidad de ubicar datos y
otros recursos sensibles sólo en
aquellos computadores equipados de
un modo eficaz contra el ataque.
Modelos Fundamentales
Modelo de Interacción: Trata sobre el
rendimiento y sobre la dificultad de poner
límites temporales en un sistema distribuido
Modelo de Fallos : intenta dar una
especificación precisa de los fallos que se
pueden producir en procesos y en canales de
comunicación.
Modelo de seguridad : posibles amenazas
para los procesos y canales de
comunicación-
12
 Modelo de Interacción
Trata sobre el rendimiento y sobre la dificultad
de poner límites temporales en un sistema
distribuido.
El cómputo ocurre en procesos. Los
procesos interactúan a través del paso de
mensajes.
En la comunicación hay retrasos. El modelo
estudia como afectan estos retrasos la
coordinación de los procesos.
Dos variantes del Modelo de
Interacción
Sistemas distribuidos síncronos
? El tiempo de ejecución de cada etapa de
un proceso tiene límites superior e inferior
conocidos.
? Cada mensaje se recibe en un tiempo
limitado conocido.
? Cada proceso tiene un reloj local cuya tasa
de deriva sobre el tiempo real tiene un
límite conocido.
Modelo de Interacción
Rendimiento de los canales de
comunicaciones:
? Latencia:retardo entre el envío de un mensaje por
un proceso y su recepción por otro.
? Ancho de banda: cantidad total de información
que se puede transmitir en un momento dado.
? Jitter o fluctuación: variación en el tiempo invertido
en completar el reparto de una serie de mensajes.
Dos variantes del Modelo de
Interacción
Sistemas distribuidos síncronos
? Es posible sugerir valores para esos límites pero
es difícil obtener valores realistas y dar garantías
sobre los valores elegidos.
? Se pueden tener timeouts. Cuando expiran
significa que ha fallado el proceso.
? Hay que garantizar ciclos suficientes de
procesador, capacidad de red y proveer relojes
con tasa de deriva limitadas.
13
 Dos variantes del Modelo de
Ordenamiento de Eventos
Interacción
Sistemas distribuidos asíncronos . Son Aún cuando no hay relojes precisos la
aquellos donde no existen limitaciones sobre: ejecución de un sistema se puede describir
? La velocidad de procesamiento en términos de los eventos y su ordenación.
? Los retardos de transmisión de mensajes Ejemplo:
? Las tasas de deriva del reloj. 1. X envía un mensaje de reunión

Los sistemas reales son frecuentemente 2. Y y Z responden

asíncronos. Pero existen problemas que no x envía
y lee y responde
pueden resolverse con este modelo.
z lee x, y y envía otra respuesta.

Ordenamiento de Eventos Ordenamiento de Eventos

envía
x
m1 Tiempo lógico de Lamport
envía m2 ? Los mensajes se reciben después de su
y Tiempo Físico
envío
envía
z x envía m1 antes que y reciba m1
Y envía m2 antes que x reciba m2
A m1 m2 ? Las respuestas se envían después que se
t1 t2 t3
m3
reciben los mensajes
- Si los relojes pudieran sincronizarse pudiera utilizarse el tiempo Y recibe m1 antes de enviar m2
Asociado localmente a c/mensaje enviado. Los mensajes en A se
Mostrarían según el ordenamiento temporal.

14
 Ordenamiento de Eventos Modelo de Fallos
envía 4
x 1 m1 Intenta dar una explicación precisa de los
envía 3
y
m2
Tiempo Físico fallos que se pueden producir en los
2
envía
procesos y en los canales de
z comunicación para darnos una
comprensión de sus efectos.
A m1 m2
t1 t2 t3m3 Fallos por omisión
1 2 ? De procesos
m1 3
4 ? De comunicaciones
m2 5
1

Modelo de Fallos Modelo de Fallos

Fallos de procesos Fallos de procesos
Ruptura accidentada del procesamiento. Fail- Stop: es cuando el resto de los procesos
Es deseable si el resto de los procesos que puede detectar con certeza que cierto
interactúan con el proceso interrumpido, o proceso interrumpio su ejecución. Se
bien funcionan correctamente o se puede detectar en un sistema síncrono por
detienen. los timeouts.
El método de detección de ruptura descansa
en timeouts.

15
 Modelo de Fallos Modelo de Fallos
Fallos por omisión de comunicaciones.
? Fallos por omisión de envíos Fallos arbitrarios: cualquier tipo de error.
? Procesos: se omiten pasos del procesamiento
? Pérdida de mensajes entre los buffers
o se realizan pasos adicionales, no
? Fallos por omisión de recepción.
intencionados.
? Canales: se corrompe el contenido de un
Proceso p Proceso q

Envía m
mensaje o se repiten mensajes. Estos fallos se
Recibe
Fallos por Canal de Fallos por
omisión de
comunicación omisión de pueden reconocer y ocultar o enmascarar.
envío recepción

Buffer de Fallos por Buffer de

Mensajes entrantes omisión del canal Mensajes salientes

Clase de Fallo Afecta a Descripción

Fail-stop (fallo-parada) Proceso El proceso para y deja de
funcionar. Otros procesos
pueden detectarlo.
Modelo de Fallos
Ruptura Proceso El proceso para y deja de
funcionar. Otros procesos
pueden no ser capaces de
detectar su estado. Fallos de temporización
Omisión Canal Un mensaje en el buffer
saliente nunca llega al buffer ? Existen en los SD síncronos donde se
de mensajes entrantes establecen límites. Fallos de reloj y fallos de
Omisión de Envío Proceso El procesos envía pero el prestaciones.
mensaje no se coloca en el
buffer de mensajes salientes ? En un SDA un proceso pude terminar mas

Omisión de recepción
Arbitrario (bizantino)
Proceso El mensaje llega a la cola de tarde pero no hay un fallo porque no se ha
mensajes entrantes pero el dado ningún tipo de garantía.
proceso no lo recibe.
? Los SOP a tiempo real se diseñan con vistas a
Proceso o Canal Transmitir mensajes
arbitrariamente, comenter proporcionar garantías de temporización.
omisiones, un proceso puede
realizar un paso incorrecto o
detenerse.

16
 Modelo de Fallos Modelo de Fallos
Clase de Fallo Afecta a Descripción
Enmascaramiento de fallos
Reloj Proceso El reloj local del proceso
? Ocultar el fallo
excede el límite de su tasa
de deriva sobre el tiempo ? Convertirlo en un tipo razonable
real.
Fiabilidad y comunicación uno a uno. El término
Prestaciones Proceso El proceso excede el
límite de ejecución comunicación fiable se define en términos de
validez e integridad.
Prestaciones Canal La transmisión del ? Validez: cualquier mensaje en el buffer de salida llega
mensaje toma más tiempo eventualmente al buffer de mensajes entrantes.
del límite permitido.
? Integridad: el mensaje recibido es idéndico al enviado y
no se reparten mensajes por duplicado

Modelo de Fallos Modelo de Seguridad

Amenazas de Integridad La seguridad de un SD puede lograrse

? Protocolos que retransmiten pero no usan
números de secuencia para evitar que el
mismo mensaje llegue duplicado.
? Usuarios mal intencionados que insertan
mensajes inválidos, repiten mensajes antiguos
o modifican mensajes autenticos.
asegurando los procesos y los canales
empleados para sus interacciones y
protegiendo los objetos que se
encapsulan contra el acceso no
autorizado.

17
 Modelo de Seguridad
Protección de Objetos
? Los objetos pueden contener datos
privados y públicos o compartidos.
? Se otorgan derechos de acceso que
especifican a quien se permite realizar
ciertas operaciones sobre un objeto. Los
usuarios son los principales beneficiarios
de estos derechos de acceso.
Modelo de Seguridad
Protección de Objetos
? A cada invocación y a cada resultado se le asocia
la autoridad con que se ordena. Tal autoridad se
denomina principal.
? El servidor es responsable de verificar la identidad
del principal tras la invocación y comprobar que
dispone de los diferentes derechos para realizar
operaciones sobre el objeto.
? El cliente puede comprobar la identidad del
principal tras el servidor para asegurar que el
resultado proviene del servidor requerido.

Modelo de Seguridad Modelo de Seguridad

Derechos Asegurar procesos y sus interacciones
de acceso Objeto
? Cierto tipo de aplicaciones son más propensas a
los ataques.
Invocación
? Para este tipo de aplicaciones probablemente
Cliente Servidor
habrá ataques a los procesos de los que se
Resultado
componen tales aplicaciones y a los mensajes
que viajan entre los procesos.
Principal (usuario) Principal (servidor)
? Cómo podemos analizar estas amenazas para
red
derrotarlas?

18
 Modelo de Seguridad Modelo de Seguridad
Modelo de amenazas de seguridad Amenazas a procesos : cualquier proceso
El enemigo: es capaz de enviar cualquier puede recibir mensajes de otro proceso y
mensaje a cualquier proceso y también de bien pudiera no ser capaz de identificar la
leer o copiar cualquier mensaje entre un par identidad del emisor. Los protocolos incluyen
de procesos. El ataque puede venir de un la dirección IP del emisor, pero no es un
computador legitimamente conectado o de problema generar un mensaje con una
una máquina no autorizada.
dirección falsa. No conocer cuál es el origen
del mensaje es una amenaza al correcto
Copia de m El enemigo
m´ funcionamiento de clientes y servidores.
Proceso P m Proceso Q

Modelo de Seguridad Modelo de Seguridad

Amenazas a canales: un enemigo Cómo se pueden vencer las amenazas
puede copiar, alterar o insertar de seguridad?
mensajes según viajen a través de la Criptografía y secretos compartidos
red. Otra forma es recopilar mensajes
Autenticación
para volver a enviarlo más tarde,
haciendo posible volver a enviar el Canales seguros
mensaje más de una vez.

19
 Modelo de Seguridad
Criptografía es la ciencia de mantener
los mensajes seguros y la encriptación
es el proceso de transformar el mensaje
de forma que quede oculto el contenido.
Se emplean claves secretas que
conoce el emisor y receptor.
Modelo de Seguridad
Un canal seguro presenta las siguiente
Canales Seguros: para construirlos se
emplean técnicas de encriptamiento y
autenticación.
Un canal seguro es un canal de
comunicación que conecta un par de
procesos, cada uno de los cuales actúa
en representación de un principal.
Modelo de Seguridad
Autenticación: probar la identidad
probada por los emisores. La técnica
básica consiste en incluir dentro del
mensaje un fragmento encriptado que
contenga suficiente información para
garantizar la autenticidad del mensaje.
Modelo de Seguridad
propiedades:
Cada proceso conoce bien la identidad del
principal en cuya representación se ejecuta el
otro proceso.
Asegura privacidad e integridad (protección
contra la manipulación)
Cada mensaje incluye un sello de carácter
temporal, de tipo fisico o lógico, para prevenir
el re-envío o la reordenación de los
mensajes.
Ejemplo: SSL (Secure Sockets Layer)
20
 Modelo de Seguridad
Otras posibilidades de amenaza del
enemigo son:
Denegación de servicio
Código móvil: puede incluir código que
accede o modifica los recursos que
están legitimamente disponibles para
los procesos del host pero no para el
creador del código.

21