SISTEMAS OPERATIVOS-

VIRTUALIZACIÓN

Procesamiento
distribuido,
cliente/servidor y
clusters

Docente: Pedro Coronado Rodríguez

Sistemas Distribuidos (enfoque clásico)
• Un sistema distribuido es aquel en el que los
componentes localizados en computadores,
conectados en red, comunican y coordinan sus
acciones únicamente mediante el paso de mensajes.
[Colouris, p.1].
– Concurrencia de los componentes
– Carencia de un reloj global
– Fallos independientes
 Sistemas Distribuidos (actualmente))
• Uso ubícuo de Internet
– (y de sus protocolos)
• Sistemas abiertos
• La consistencia fuerte sólo se necesita en algunos casos
– En la mayoría de los casos, se puede tolerar una “consistencia
eventual” (W. Vogels. Eventually Consistent. ACM Queue vol. 6, no. 6,
December 2008.) 1

• Uso ubícuo de cachés, sistemas abiertos, protocolos estándar

(HTTP) homogeneización de datos y procesamiento,
Map/Reduce, paralelismo funcional, automático, REST, etc.
• Amazon Elastic MapReduce
• Google MapReduce La Transferencia de Estado
Hadoop es una plataforma que Representacional (Representational
Map/Reduce: Framework nos permite desarrollar State Transfer) o REST es una técnica
para procesamientos de aplicaciones que tengan que de arquitectura software para
datos en paralelo tratar con grandes cantidades sistemas hipermedia distribuidos
de datos, hasta petabytes. como la World Wide Web
 Sistemas Distribuidos: Retos
• Heterogeneidad
– Redes
– Hardware
– Sistemas Operativos
– Middleware
• Extensibilidad
• Seguridad
• Escalabilidad
• Tratamiento de Fallos
• Concurrencia
• Transparencia
Sistemas Distribuidos: Heterogeneidad
• Hardware, Sistema Operativo, lenguajes, Redes Razones:
• Ingeniería – Diferentes personas eligen diferentes soluciones
• Coste – Se compran recursos que se adapten a las
necesidades
• Aplicaciones antiguas – Imaginemos una aplicación de
reserva de billetes en COBOL. Se tienen que amortizar las
inversiones
• Hardware antiguo – El hardware nuevo que se compra es
necesariamente diferente.
Sistemas Distribuidos: Heterogeneidad
• Herramientas:
– Protocolos de comunicación
– APIs estándar (Middleware)
– Sistemas Abiertos (i.e. CORBA, Internet,
etc.)
• Especificaciones públicas
• Mecanismos de comunicación estandarizados
• Utilizando hardware y software COTS( Commercial Off
The Shelf
DSBC: Técnicas de software para la elaboración de sistemas abiertos y • fiabilidad
distribuidos mediante el ensamblaje de partes de software reutilizables.
El DSBC es utilizado para reducir los costos, tiempos y esfuerzos en el
• flexibilidad
desarrollo de software, a la vez que ayuda a mejorar: • reutilización
 Sistemas Distribuidos: Extensibilidad

• Característica de un sistema que permite

añadirle nuevas características y servicios
de forma dinámica
• Herramientas:
– Sistemas Abiertos
– Loose Coupling (Acoplamiento flexible)
 Sistemas Distribuidos: Seguridad
• Elemento más importante y más complejo
(conexiones y equipos físicamente distribuidos)
• Necesidad de:
– Autenticar a usuarios y recursos
– Definir roles y patrones de acceso
– Encriptar las comunicaciones
– Seguridad física
• Herramientas:
– PKIs, SSL, Servicios de Directorio, Proxys anonimizadores, funciones de
hash, etc.
PKI, Public Key Infrastructure
Es una combinación de hardware y software, políticas y procedimientos de
seguridad que permiten la ejecución con garantías de operaciones criptográficas
como el cifrado, la firma digital o el no repudio de transacciones electrónicas.
Sistemas Distribuidos: Escalabilidad
• Un sistema es escalable si el aumento de demanda de
servicios se puede suplir con una aportación de recursos
• También: Un sistema puede ofrecer servicio a un número
potencialmente muy grande de demandas: degrada el tiempo
medio de respuesta, pero no se colapsa
– Prever el desbordamiento de recursos tanto software como hardware.
– Evitar cuellos de botella de prestaciones.
• Soluciones:
– Uso de software eficiente en tiempo y espacio
– Patrones de diseño y de código (idiomas) para manejar eficientemente
conexiones, threads, etc.
– Uso de cachés, consistencia eventual, etc.
– Uso de algoritmos altamente paralelizables (programación funcional,
lógica, algoritmos Map/Reduce), etc.
 Sistemas Distribuidos: Fallos
• El rango de fallos en sistemas distribuidos es mayor
que en cualquier otro sistema
• Además, es interesante que los sistemas distribuidos
«toleren» fallos. ¿Por qué?
• Cuestiones:
– Detección de fallos (unos detectables, otros no)
– Enmascaramiento de fallos (p. ej. patrón Proxy)
– Redundancia y votado
– Disponibilidad
– Idempotentibilidad
• No tratado en profundidad en esta asignatura
 Sistemas Distribuidos: Concurrencia
• Normalmente los datos se comparten
• Hay que establecer órdenes de acceso y procesos atómicos:
Transacciones
• Cuello de botella si los datos están almacenados en un solo
ordenador
• Necesidad de transacciones distribuidas
• Problemas de consistencia
• A veces se necesitan coordinar varios procesos de varios
• ordenadores (barreras). La mala programación de estos
procesos puede hacer el sistema muy ineficiente
• No tratadas en profundidad en esta asignatura
 Sistemas Distribuidos: Transparencia
• El tópico más importante y el más difícil de conseguir
• Con transparencia, el desarrollo de aplicaciones
distribuidas es similar al de aplicaciones
convencionales
• Delega en los niveles inferiores la complejidad y ofrece
servicios fiables:
– Transparencia de localización
– Transparencia de concurrencia
– Transparencia de replicación
– Transparencia ante fallos
– Transparencia . . .
Arquitecturas – Sistemas Centralizados

• No escalables
• ¿Cómo añadir más recursos?
 Arquitecturas – Primeros sistemas
distribuidos

• Primeros programas distribuidos

• Conexiones explícitas, protocolos explícitos, herramientas básicas
• P. ej. Demonios remotos UNIX
 Arquitecturas – Primeros sistemas
distribuidos

• Servicios básicos por parte del Sistema Operativo

• Direccionamiento
• Sockets
• Normalmente sólo implicaban a dos programas
(Cliente/Servidor)
Arquitecturas – Internet/World Wide
Web/CGI
Arquitecturas – 2 y 3 niveles
 TPMs, Clusters, etc.

• En la práctica, se utilizan sistemas de n capas

• La distribución: múltiples clientes por Web (thin clients) y un sistema de BBDD
que está basado en clúster
• Clústers de bases de datos/procedimientos proporcionados por paquetes
comerciales (Oracle, DB/2, etc.)
• Gestión de MUCHOS clientes: Transaction-Processing Monitors
 Sistemas de más alto nivel: RPC
• Primer sistema en diferenciar interfaz/implementación
• Más alto nivel (comprobación de tipos)
• Interfaz (lista de operaciones) ) Stubs/Skeletons
 El interfaz se describe en C
 El compilador de RPC genera los stubs y los skeletons
 El programador realiza llamadas locales
 Los stubs y skeletons realizan el trabajo remoto
 TRANSPARENCIA LOCAL/REMOTA
• Ejemplo: SUN RPC
• Software intermedio: MIDDLEWARE
Sistemas de más alto nivel: RPC
Objetos Distribuidos: CORBA/RMI
• Muy parecido a RPC, pero basado en objetos
• El middleware ahora toma más importancia
 Message-Oriented Middleware

Síncrono/asíncrono
Normalmente Suscripción/Respuesta
Documentos XML ) Mensajes
Loose Coupling
JMS, AMQP, ActiveMQ, ØMQ, MSMQ, D-Bus, etc.
ESBs: Mensajería + Servicios de dominio
D-Bus
REST – REpresentational State Transfer
Patrón arquitectural de desarrollo de aplicaciones sobre el Web
 Desarrollado por Roy T. Fielding en su tesis doctoral
 Aprovecha el web tal y como está
 El web ha sido escalable hasta ahora por tener una serie de
 requisitos: se aplicarán a REST
Identificación de recursos
 Todos los elementos accedidos remotamente tienen una identificación
(URI). Se elige una representación para cada recurso (XML, YAML)
Manipulación de recursos
 Hay operaciones para crear, modificar y borrar (CRUD) recursos
Mensajes auto-descriptivos
 Los recursos incluyen metadatos (cache, validez, MIME). Incluidos en los
headers de HTTP
 Los metadatos permiten tratar el mensaje
Tejido hypermedia como representación del estado de la aplicación (HATEOAS)
 Los datos retornados pueden incluir enlaces a otros recursos
 Componentes: CCM/EJB
• Componentes: Entidades redistribuibles binarias ejecutadas
en un entorno de ejecución (run-time)
• Modelo contenedor
• Unidades independientes de construcción de programas
• Unidades binarias de desarrollo, prueba y ensamblado
• Soporte run-time que permite instalar componentes
• El entorno de ejecución (run-time) ofrece todos los servicios
a los componentes instalados
 Seguridad, transacciones, persistencia, etc.
 Ofrecidos como aspectos (Aspect-Oriented
Programming (AOP))
Componentes: CCM/EJB
Modelos de Componentes Distribuidos
• Los componentes se encuentran distribuidos
• Diferentes organizaciones ofrecen componentes
 Bien para descargar
 Bien para utilizarlos remotamente bajo pago
• Necesidad de un entorno seguro, autenticado... p. ej. Grid
• Transparencia local/remota
• Paletas de componentes similares a Delphi o VB, pero
distribuidas
Cloud Computing
 Clusters
• Servidor diferente
– Cada computadora es un servidor diferente
– No hay discos compartidos
– Se necesita algún tipo de software de gestión o de
planificación
– Se debe copiar constantemente la información
entre los sistemas, de forma que cada sistema
tenga acceso a los datos actualizados de otros
sistemas
Configuraciones de los clusters

Enlace de mensajes de alta velocidad

M E/S E/S E/S E/S M

(a) Servidor en espera sin disco compartido

 Clusters
• Nada compartido (Shared Nothing)
– Reduce la sobrecarga de las comunicaciones
– Los discos comunes se particionan en volúmenes
– Cada volumen pertenece a una computadora
– Si falla una computadora, el cluster se debe
reconfigurar para que otra computadora tome
posesión del volumen de la computadora que falló
Configuraciones de los clusters

Enlace de mensajes de alta velocidad

E/S P P
P P E/S

M E/S E/S E/S E/S M

(b) Disco compartido

 Clusters
• Disco compartido
– Múltiples computadoras comparten los mismos
discos al mismo tiempo
– Cada computadora tiene acceso a todos los
volúmenes de todos los discos
 Aspectos de diseño de sistemas
operativos
• Gestión de fallos
– Un cluster de alta disponibilidad ofrece alta
posibilidad de que todos los servicios estén en
servicio
• No garantiza el estado de las transacciones
parcialmente realizadas si ocurre algún fallo
– Un cluster tolerante a fallos asegura que todos los
recursos están siempre disponibles
 Aspectos de diseño de sistemas
operativos
• Equilibrado de carga
– Cuando se añade una nueva computadora al cluster, el servicio
de equilibrado de carga debe incluir automáticamente la nueva
computadora en la planificación de las aplicaciones
• Computación paralela
– Compilación paralela: Determina el tiempo y partes de la
aplicación que se puede ejecutar en paralelo.
– Aplicaciones paralelas: Utiliza el paso de mensajes para mover
datos.
– Computación paramétrica: Enfoque que se puede utuilizar si
la esencia de la aplicación es un algoritmo un gran numero de
veces cada ves con un conjunto diferente de condiciones o
parámetros iniciales
 Arquitectura de un cluster
• Servicios y funciones del middleware de
cluster
– Un único punto de entrada
– Una única jerarquía de ficheros
– Un único punto de control
– Una única red virtual
– Un único espacio de memoria
– Un único sistema de control de trabajos
 Arquitectura de un cluster
• Servicios y funciones del middleware de
cluster
– Un único interfaz de usuario
– Un único espacio de E/S
– Un único espacio de procesos
– Puntos de control
– Migración de procesos
 Arquitectura de un cluster

Aplicaciones paralelas

Aplicaciones secuenciales Entorno de programación paralela

Middleware de cluster (Imagen del sistema e infraestructura de disponibilidad)

PC/Estación de trabajo PC/Estación de trabajo PC/Estación de trabajo PC/Estación de trabajo PC/Estación de trabajo

Sw comunicaciones Sw comunicaciones Sw comunicaciones Sw comunicaciones Sw comunicaciones

Hw interfaz red Hw interfaz red Hw interfaz red Hw interfaz red Hw interfaz red

Red de alta velocidad/conmutador

Figura 14.14. Arquitectura de computación cluster [BUYY99a]

 Cluster frente a SMP
• SMP es más fácil de gestionar y configurar
• SMP ocupa menos espacio físico y gasta menos
energía
• Los productos SMP están bien establecidos y son
muy estables
• Los clusters son superiores que SMP en relación a la
escalabilidad incremental y absoluta
• Los clusters son superiores en términos de
disponibilidad
 Servidor cluster de Windows
Servidor clúster de Windows, conocido como wolfpack. Hace uso
de los sgtes conceptos
• Servicio Cluster
– La colección de software de cada nodo que gestiona toda la actividad
específica del cluster
• Recurso
– Un elemento gestionado por el servicio cluster
• En línea (online)
– Se dice que un recurso está en línea en un nodo cuando está
proporcionando servicio en ese nodo específico
• Grupo
– Una colección de recursos gestionada como una unidad
 Herramientas de gestión del cluster

API DLL del cluster

RPC

Servicio de cluster
Gestor actualizaciones
globales
Gestor de base de datos

Procesador de
Gestor de
eventos
nodos

DLL Gestor de recuperación de fallos

recursos Gestor de comunicaciones Otros
aplicación Gestor de recursos nodos

Monitor de recursos Interfaz de gestión de

recursos

DLL DLL DLL App no conscientes

recursos recursos recursos
aplicación aplicación aplicación
App conscientes
del cluster
Figura 14.15. Diagrama de bloques del Windows Cluster Server [SHOR97]
 Sun Cluster
• Sun Cluster es un sistema operativo
distribuido, es extension de UNIX solaris
• Principales componentes
– Soporte de objetos y comunicaciones
– Gestión de procesos
– Redes
– Sistema de ficheros distribuido global
 Aplicaciones

Interfaz de llamadas al sistema

Red

Sun Sistema de ficheros Procesos

cluster
Otros nodos
Invocación de objetos
C++ Estructura de objetos

Núcleo Solaris existente

Figura 14.16. Estructura de Sun Cluster

 Núcleo

Interfaz
nodo-v/VFS

Cache
Capa proxy

Invocación al objeto
Núcleo

Interfaz
nodo-v/VFS Implementación del objeto Cache

Interfaz
nodo-v/VFS
Sistema de Sistema de Sistema de Sistema de
ficheros ficheros ficheros ficheros

(a) Solaris estándar (b) Sun cluster

Figura 14.17. Extensiones del sistema de ficheros de sun Cluster

 Clusters Beowulf y Linux
• Principales características
– Componentes genéricos disponibles en el mercado
– Procesadores dedicados (mejor que ciclos disponibles de
estaciones de trabajo ociosas)
– Una red privada y dedicada (LAN o WAN o una
combinación de redes)
– Ningún componente propio
– Fácilmente replicable para múltiples vendedores
 Clusters Beowulf y Linux
• Principales características
– E/S escalable
– Basado en software gratuito disponible
– Utiliza herramientas de computación gratuitas con
mínimos cambios
– Retorno del diseño y de las mejoras a la
comunidad
 Almacenamiento
compartido
distribuido

Estaciones de
trabajo Linux

Ethernet o Ethernets
interconectados

Figura 14.18. Configuración genérica de Beowulf