Unidad 1.2.
- Objetivos de los Sistemas Distribuidos
Objetivos de diseño de los servicios distribuidos
Comportamiento transparente
Soporte a la heterogeneidad
Fiabilidad (reliability)
Rendimiento (performance)
Escalabilidad
Objetivos de diseño: transparencia
Que los usuarios no perciban (o no les importe) la naturaleza distribuida del servicio.
Aspectos de la transparencia:
Ubicación (dónde está ubicado el servicio)
Migración (se pueden reubicar los recursos)
Replicación (los recursos pueden estar replicados, sin que lo controle el usuario)
Concurrencia (varios usuarios comparten un recurso, sin que se note)
Ejemplo: servicios P2P
Objetivos de diseño: soporte a la heterogeneidad
Permitir la convivencia de sistemas diferentes en hardware, sistema operativo, etc. Ejemplo: máquinas
virtuales (Java)
Objetivos de diseño: fiabilidad (reliability)
Disponibilidad (availability). Conseguir que el servicio esté disponible la mayor cantidad de tiempo.
Tolerancia a fallos (fault tolerance). Conseguir mantener la disponibilidad del servicio incluso si hay fallos
parciales.
Integridad. Garantizar que la información contenida es correcta y completa.
Protección. Garantizar que no se producen accesos no autorizados.
Objetivos de diseño: rendimiento
La transparencia, el soporte a la heterogeneidad y el aumento de fiabilidad no deberían penalizar
excesivamente el rendimiento.
Aspectos a tener en cuenta: Lentitud de la red de comunicaciones.
Costo de los protocolos que garantizan la integridad de la información y la tolerancia a fallos.
Impacto de los servicios que se gestionan de forma centralizada
Objetivos de diseño: escalabilidad
Un servicio distribuido debe ser muy escalable: el número de nodos debería poder crecer
indefinidamente sin que la calidad del servicio se degrade notablemente.
Esto tiene mucho que ver con evitar centralizar recursos o componentes.
Escalabilidad y descentralización
Un servicio distribuido escalable suele poseer estas características (descentralización):
Ninguna máquina contiene información completa y actualizada sobre todo el sistema
Las decisiones se toman usando solamente información local
Los algoritmos funcionan bien incluso si alguna máquina participante deja de estar disponible
Los algoritmos no se basan en un reloj global
Administración de un s.d.
La administración se vuelve más complicada
¿Cómo lanzamos un servicio distribuido? ¿Cómo monitorizamos el servicio?
¿Tenemos permiso para actuar sobre todos los servidores?
Conclusión: el enfoque tradicional de administración centralizada no es el más adecuado en un sistema
distribuido.
Fallos en un s.d.
Tipos de fallos:
fallo de un enlace
fallo de una máquina
pérdida de mensajes
fallos de software
En un sistema asíncrono, es imposible conocer con certeza si una máquina ha fallado. La detección de
fallos se basa en suposiciones.
Problema añadido: desconexiones temporales (particiones en la red)
Modelos de diseño de componentes distribuidos
El modelo natural en un s.d. es la interacción cliente-servidor
Enfoques:
Procesos/aplicaciones distribuidas
Objetos distribuidos
Servicios distribuidos
Tecnologías:
Paso de mensajes (tecnología más básica)
Llamada a procedimiento remoto (RPC)
Llamadas a objetos remotos Servicios Web (Web Services, SOAP)
