Sistemas distribuidos - Departamento de Computación

Sistemas distribuidos
Diego Fernández Slezak
Departamento de Computación, FCEyN,
Universidad de Buenos Aires, Buenos Aires, Argentina
Sistemas Operativos, primer cuatrimestre de 2014
Diego Fernández Slezak
Sistemas distribuidos
(2) Juntos pero no revueltos
Hay tres nociones que son similares, aunque no iguales.
Cómputo (o procesamiento) simultáneo.
Cómputo paralelo.
Cómputo distribuido.
Vamos a usar los tres términos a veces de manera genérica e
intercambiable, y a veces de manera especı́fica. ∆
!
Pero va a quedar claro por el contexto.
Diego Fernández Slezak
Sistemas distribuidos
(3) Sistemas distribuidos, ¿para qué?
Hay varias motivaciones para trabajar con sistemas
distribuidos:
Cooperación (en algún sentido) a pesar de separación
geográfica o administrativa.
Incrementar el poder de cómputo.
Incrementar la capacidad de almacenamiento.
Noción cercana: permitir (en el futuro) el crecimiento
horizontal en lugar de vertical.
(Porque es conceptualmente más claro.)
Diego Fernández Slezak
Sistemas distribuidos
(4) Procesamiento simultáneo, ¿cómo?
Una de las primeras preguntas es qué tipo de simultaneidad
queremos.
Una posible respuesta es la taxonomı́a de Flynn.
En ella los sistemas se caracterizan por sus flujos de
instrucciones y de datos.
Da lugar a las siguientes categorı́as:
SISD (Single Instruction Single Data): monoprocesadores.
SIMD (Single Instruction Multiple Data): procesadores
vectoriales, como algunas computadoras “poderosas” de hace
un par de décadas o algunas placas de video.
MISD (Multiple Instruction Single Data): Poco Común. A
veces, para tolerancia a fallos
MIMD (Multiple Instruction Multiple Data): sistemas
distribuidos y paralelos en general.
No es demasiado útil hoy en dı́a.
Diego Fernández Slezak
Sistemas distribuidos
(5) Qué comparten
Dejemos de lado los procesadores vectoriales, por especı́ficos.
Supongamos que tenemos varios procesadores.
Para mı́ la verdadera pregunta es qué comparten: ∆
!
Memoria.
Scheduler.
Clock.
Canal de comunicaciones (con garantı́as, sin garantı́as, etc.).
Esos parámetros van a dar las caracterı́sticas de la interacción.
En la práctica, hay dos tipos: ∆
!
Paralelos: misma máquina (memoria compartida).
Distribuidos: distintas máquinas (en general, conectados a
través de una red de algún tipo).
Estos últimos no comparten ni memoria ni clock.
En general, un sistema paralelo puede “emular” uno
distribuido.
Diego Fernández Slezak
Sistemas distribuidos
(6) Formas de cooperación
Lo importante es cómo se comunican los distintos procesos
del sistema distribuido. ∆
!
De manera un poco más general, cómo cooperan entre sı́.
Ejemplo: dos personas pueden trabajar juntas para resolver
una tarea de varias formas distintas.
La forma en la que se estructuran los procesos para que
cooperen entre sı́ se llama arquitectura de software.
(En realidad el término es más amplio, pero incluye a esta
información sobre el sistema.)
Las caracterı́sticas anteriores, relacionadas con qué comparte
el sistema, se llaman, en este contexto, arquitectura de
hardware.
Vamos a ver varias arquitecturas de software distribuidas, y
analizar cómo se mapean a arquitecturas de hardware.
Diego Fernández Slezak
Sistemas distribuidos
(7) Arquitecturas de hardware
SMP (Symmetric Multi Processing): varios procesadores,
compartiendo memoria. El término simétrico a veces hace
referencia a la capacidad de auto planificar cada procesador
independientemente, a veces a que todos los procesadores
tienen la misma función.
Multicore: Más de un procesador por board, compartiendo
caché L2, etc.
NUMA (Non-Uniform Memory Access ): cada procesador tiene
su propia ”memoria local”pero puede también tener acceso a la
memoria de otros procesadores, aunque de forma más lenta.
Redes: Más allá de la infraestructura de comunicaciones en sı́,
es el nombre que se le suele dar a un conjunto de
computadoras. Hace un tiempo se usaba el término NOW:
Network of Workstations.
Diego Fernández Slezak
Sistemas distribuidos
(8) Arquitecturas de hardware (cont.)
Clusters:
En sentido cientı́fico: un conjunto de computadoras conectadas
por una red de alta velocidad, con un scheduler de trabajos
común.
En el resto: un conjunto de computadoras que trabajan
cooperativamente desde alguna perspectiva. A veces para
proveer servicios relacionados, a veces para proveer el mismo
de manera redundante.
Diego Fernández Slezak
Sistemas distribuidos
(9) Arquitecturas de hardware (cont.)
Clusters: http://www.top500.org
Diego Fernández Slezak
Sistemas distribuidos
(10) Arquitecturas de hardware (cont.)
Grids: conjunto de clusters, cada uno bajo dominio
administrativo distinto.
Clouds: clusters donde uno puede alquilar una capacidad fija o
bajo demanda.
Diego Fernández Slezak
Sistemas distribuidos
(11) Telnet
En realidad, telnet es el nombre de un protocolo y un
programa que permite conectarse remotamente a otro equipo.
Pero es representativo de una forma de cooperación, muy
elemental pero muy usada, que podrı́amos llamar “conexión
remota”.
La idea es que los recursos necesarios para cierta parte del
procesamiento están en otro equipo.
Entonces, accedemos a éste como si estuvieramos sentados
frente al mismo y hacemos el procesamiento de manera
remota.
Notar que involucra al menos dos equipos, pero sólo uno de
ellos hace el trabajo.
El otro simplemente corre un programa interactivo de
comunicaciones, que es bastante liviano.
Diego Fernández Slezak
Sistemas distribuidos
(12) RPC
Birrel & Nelson, Implementing remote procedure calls, ACM
Transactions on Computer Systems, 1984.
Se trata de un mecanismo que les permite a los programas (C en un
principio) hacer procedure calls de manera remota.
The idea of RPC is quite simple. It is based on the
observation that procedure calls are a well-known and
well-understood mechanism for transfer of control and data
within a program running on a single computer. Therefore, it is
proposed that this same mechanism be extended to provide for
transfer of control and data across a communication network.
(...) the calling environment is suspended, the parameters are
passed across the network to the environment where the
procedure is to execute, and the desired procedure is executed
there. When the procedure finishes and produces its results,
the results are passed backed to the calling environment, where
execution resumes as if returning from a simple
single-machine call.
Diego Fernández Slezak
Sistemas distribuidos
(13) RPC (cont.)
Leer los detalles del paper y/o libro.
Stub y marshalling de parámetros.
Se podrı́a pensar que SOAP y WebServices son una versión
moderna de RPC.
¿Quién procesa? ¿una o varias máquinas?
Diferencias con LPC
Diego Fernández Slezak
Sistemas distribuidos
(14) En general
Notar que lo que tienen en común estos métodos es que la
cooperación tiene la forma de solicitarle servicios a otros.
Estos otros no tienen un rol activo.
Este tipo de arquitecturas se suelen llamar cliente/servidor. ∆
!
El servidor es un componente que da servicios cuando el
cliente se lo pide.
Entonces, el programa “principal” hace de cliente de los
distintos servicios que va necesitando para completar la tarea.
Diego Fernández Slezak
Sistemas distribuidos
(15) Pensando localmente: Threads
A nivel conceptual los threads son una herramienta para
referirse a ejecuciones independientes dentro del mismo
sistema.
A veces se precisa el concepto un poco más y se los piensa en
la misma máquina, y por ende con memoria compartida.
A nivel más concreto son:
Unidades independientes de scheduling dentro del procesador.
Con memoria compartida a través de variables.
Además de variables privadas.
Que “viven” dentro del mismo proceso.
Además de un equivalente a fork(), suelen proveer facilidades
para hacer join().
Diego Fernández Slezak
Sistemas distribuidos
(16) Threads, más en concreto
Veamos algunas diferencias entre threads y procesos:
Variables compartidas.
Potencialmente, el scheduling.
Proveen un mecanismo sencillo para agruparse.
Los threads comparten segmentos, interrupciones, File
Handles, etc.
Crear un thread es mucho más rápido que crear un proceso
(hoy en dı́a se puede estimar entre 5 y 25 veces más rápido,
dependiendo del SO, aunque esa distancia se tiende a achicar
con el tiempo).
En algunos SO, los threads se pueden atar a procesadores.
Desventaja: el programa no se puede llevar fácilmente a un
entorno distribuido.
Hay “soluciones” de compromiso: OpenMP.
Diego Fernández Slezak
Sistemas distribuidos
(17) Más threads
Notemos que los threads son el entorno ideal para utilizar las
primitivas de sincronización que vimos antes:
Semáforos, mutexes, regiones crı́ticas, monitores, variables de
condición, etc.
Cada SO solı́a proveer una API distinta para el manejo de
threads.
Cada una de ellas incluı́a un subconjunto distinto de estas
primitivas.
En 1996 se estadarizaron las POSIX threads: una API bien
definida para el manejo de threads, portable entre distintos
SO.
La vamos a ver en la práctica.
Lo interesante es que este tipo de funcionalidad es tan
sensible a las distintas decisiones tomadas en el kernel que
cada SO debe reimplementarla.
Detalle importante: los programas que usan threads deben
usar funciones reentrantes. ∆
!
Diego Fernández Slezak
Sistemas distribuidos
(18) Pensando en muchas máquinas: Pasaje de mensajes
De alguna forma, éste es el mecanismo más general.
Porque no supone que haya nada compartido, excepto un
canal de comunicación.
Notar: si tengo un canal de comunicación muchas veces no
voy a necesitar mutexes.
Problemas que sı́ vamos a considerar:
Tengo que manejar la codificación/decodificación de los datos.
Si hago una comunicación asincrónica, tengo que dejar de
procesar para atender el traspaso de mensajes.
La comunicación es lenta.
Eventualmente el canal puede perder mensajes (hoy en dı́a con
TCP/IP se puede pensar que el canal es confiable).
Eventualmente podrı́a haber un costo económico por cada
mensaje que se transite por el canal.
Existen bibliotecas que ayudan con algunos de estos
problemas. La más popular es MPI (que es una API en
realidad).
Diego Fernández Slezak
Sistemas distribuidos
(19) Pasaje de mensajes (cont.)
Problemas que vamos a ignorar en esta materia:
Los nodos pueden morir (también en los otros esquemas, pero
acá es más probable/de mayor impacto).
La red se puede partir (partes incomunicadas).
Sólo como curiosidad:
Conjetura de Brewer: en un entorno distribuido no se puede
tener a la vez consistencia, disponibilidad y tolerancia a fallas.
Sólo dos de esas tres.
Detalles en “Brewer’s conjecture and the feasibility of
consistent, available, partition-tolerant web services”, de Seth
Gilbert y Nancy Lynch.
Diego Fernández Slezak
Sistemas distribuidos
(20) Pensando en más máquinas: Map-Reduce
Dean, Jeffrey and Sanjay Ghemawat. MapReduce: simplified
data processing on large clusters OSDI, Operating Systems
Design and Implementation, 2004.
Dean, Jeffrey and Sanjay Ghemawat. MapReduce: simplified
data processing on large clusters Communications of the
ACM, 51.1 (2008): 107-113.
MapReduce es un modelo de programación que presupone una
cierta arquitectura de hardware (Clusters grandes).
Pensado para procesar y generar grandes corpus de datos (en
general, con operaciones simples).
Hay que definir dos funciones (etapas):
Map(MapInput ) → ReduceInput: función sencilla que opera
sobre una porción del set de datos.
Reduce(ReduceInput ) → Result: función que agrupa los
resultados.
Diego Fernández Slezak
Sistemas distribuidos
(21) Arquitecturas hı́bridas
Luis von Ahn, Human Computation, Carnegie-Mellon
University, PhD dissertation, 2005.
TEDx Rio de la Plata: Utilizando el poder de millones de
mentes humanas
Diego Fernández Slezak
Sistemas distribuidos
(22) Repaso
Vimos:
Sistemas distribuidos, para qué.
Taxonomı́a de Flynn.
Sistemas paralelos/distribuidos, diferencias.
Arquitecturas de hardware.
Arquitecturas de software.
RPC.
Threads y pasaje de mensajes.
Introducción a Map-Reduce.
Locks en entornos distribuidos (intro).
Enfoque centralizado.
Veremos:
Marco conceptual para analizar algoritmos distribuidos.
Luego sı́, algoritmos verdaderamente distribuidos.
Diego Fernández Slezak
Sistemas distribuidos