IIC2523 - Pontificia Universidad Católica de Chile

02 - Arquitecturas de Sistemas Distribuidos
IIC2523 - Sistemas Distribuidos
Cristian Ruz – cruz@ing.puc.cl
Departamento de Ciencia de la Computación
Pontificia Universidad Católica de Chile
Semestre 1-2013
C.Ruz (PUC)
IIC2523
1/2013
1 / 89
Contenidos
1
Taxonomı́as
Paralelismo de control y paralelismo de datos
Organización de la memoria
2
Modelos de comunicación
Entidades
Paradigmas
Roles
Ubicación
3
Patrones de arquitectura
4
Middlewares
5
Soporte del sistema operativo
Procesos y Threads
Comunicación e invocación
Virtualización
C.Ruz (PUC)
IIC2523
1/2013
2 / 89
Taxonomı́as
Contenidos
1
Taxonomı́as
Paralelismo de control y paralelismo de datos
Organización de la memoria
2
Modelos de comunicación
Entidades
Paradigmas
Roles
Ubicación
3
Patrones de arquitectura
4
Middlewares
5
Soporte del sistema operativo
Procesos y Threads
Comunicación e invocación
Virtualización
C.Ruz (PUC)
IIC2523
1/2013
3 / 89
Taxonomı́as
¿Cómo construir los sistemas?
Recordemos la arquitectura de Von Neumann
Queremos llevar esto a una arquitectura distribuida
¿Cómo organizar las CPUs?
¿Cómo organizar la memoria?
¿Cómo organizar la entrada/salida de datos?
C.Ruz (PUC)
IIC2523
1/2013
4 / 89
Taxonomı́as
Paralelismo de control y paralelismo de datos
Taxonomı́a de Flynn
Michael J. Flynn (1972)1 propuso cuatro modos de procesamiento.
De acuerdo a cantidad de flujos de control y cantidad de flujos de datos:
Single Data
Multiple Data
Single Instruction
SISD
SIMD
Multiple Instruction
MISD
MIMD
1
M.Flynn. Some computer organizations and their efectiveness, IEEE Transactions
on Computers, 1972
C.Ruz (PUC)
IIC2523
1/2013
5 / 89
Taxonomı́as
Paralelismo de control y paralelismo de datos
SISD: Single Instruction, Single Data
Un flujo instrucciones, operando sobre un flujo de datos.
Corresponde exactamente a una arquitectura de Von Neumann.
Procesamiento secuencial de instrucciones
Incluyendo pipelining, prefetching, branch prediction
PCs tradicionales, mainframes
C.Ruz (PUC)
IIC2523
1/2013
6 / 89
Taxonomı́as
Paralelismo de control y paralelismo de datos
SIMD: Single Instruction, Multiple Data
Un flujo de instrucciones, operando sobre distintos datos.
El flujo de instrucciones se replica en múltiples procesadores.
Cada instrucción se ejecuta sobre distintos flujos de datos.
Aplicaciones sobre vectores o matrices
Aplicaciones cientı́ficas, multimedia, videojuegos
Procesadores vectoriales
Cray, Intel MMX (Pentium), AltiVec (PowerPC), 3DNow!(AMD)
Explotan paralelismo a nivel de datos
C.Ruz (PUC)
IIC2523
1/2013
7 / 89
Taxonomı́as
Paralelismo de control y paralelismo de datos
SIMD: Single Instruction, Multiple Data
Ejemplo
Tarea: multiplicar 4 números almacenados en RAM
C.Ruz (PUC)
IIC2523
1/2013
8 / 89
Taxonomı́as
Paralelismo de control y paralelismo de datos
MISD: Multiple Instruction, Single Data
Múltiple flujos de instrucciones, sobre un único flujo de datos
Solo paralelismo de control
Pipelining de instrucciones
Systolic Arrays
No es una arquitectura muy común
C.Ruz (PUC)
IIC2523
1/2013
9 / 89
Taxonomı́as
Paralelismo de control y paralelismo de datos
MISD: Multiple Instruction, Single Data
Ejemplo
Arreglos sistólicos
Procesadores independientes, compartiendo su output
¿Otra aplicación?
C.Ruz (PUC)
IIC2523
1/2013
10 / 89
Taxonomı́as
Paralelismo de control y paralelismo de datos
MIMD: Multiple Instruction, Multiple Data
Múltiples flujos de instrucciones, sobre múltiples flujos de datos.
Caso más general de computación paralela
¿Memoria compartida o distribuida?
Multi-cores
Explotan paralelismo de control y de datos
C.Ruz (PUC)
IIC2523
1/2013
11 / 89
Taxonomı́as
Organización de la memoria
Memoria
¿Cómo organizar el acceso a la memoria?
Antes de eso hay que elegir una alternativa:
Memoria compartida
Memoria distribuida
C.Ruz (PUC)
IIC2523
1/2013
12 / 89
Taxonomı́as
Organización de la memoria
Memoria compartida
Todos los procesadores están conectados a una memoria globalmente
accesible.
Todos pueden leer o escribir a la vez
Memoria podrı́a ser un cuello de botella
. . . ¡pero podemos usar caches!
Se requiere coherencia de memoria
¿El dato leı́do es el mismo que está en memoria?
¿y si alguien lo cambió justo después que lo leı́?
Coherencia puede proveerse por hardware o software
Se pueden usar distintos modelos de consistencia
C.Ruz (PUC)
IIC2523
1/2013
13 / 89
Taxonomı́as
Organización de la memoria
Memoria compartida
pero ... ¿cómo la organizo?
De acuerdo al tipo de acceso:
UMA, Uniform Memory Access
NUMA, Non-Uniform Memory Access
COMA, Cache-Only Memory Access
C.Ruz (PUC)
IIC2523
1/2013
14 / 89
Taxonomı́as
Organización de la memoria
Memoria compartida: UMA
Uniform Memory Access
Todos los procesadores acceden de la misma manera a la memoria.
Ejemplo: Symmetric MultiProcessor (SMP)
¿Como evitar congestión? → ¡Cache!
¿Cómo lo mantengo coherente? . . .
C.Ruz (PUC)
IIC2523
1/2013
15 / 89
Taxonomı́as
Organización de la memoria
Memoria compartida: UMA
Uniform Memory Access
No solo puede ser un bus. También puede ser un crossbar switch:
C.Ruz (PUC)
IIC2523
1/2013
16 / 89
Taxonomı́as
Organización de la memoria
Memoria compartida: NUMA
Non-Uniform Memory Access
Diferentes tipos de acceso. ¿Dependiendo de qué?
Accesos locales versus accesos remotos
Diferentes modos de acceder a la memoria
Local >> Remoto
Clave: aprovechar localidad de referencia
Aún se debe mantener cache coherence
C.Ruz (PUC)
IIC2523
1/2013
17 / 89
Taxonomı́as
Organización de la memoria
Memoria compartida: Cache Coherence
¿Cómo mantenar las copias en cache de manera coherente?
Diferentes niveles de coherencia
Writes aparecen “instantáneamente”
Cada procesador ve la misma secuencia de cambios
Cada procesador puede ver distintas secuencias de cambios (i.e. no
hay coherencia)
Algunas condiciones:
Order preservation: WP (x)a ⇒ RP (x)a
Coherent view: WP2 (x)a ⇒ RP1 (x)a
Secuencial: WP1 (x)a, WP2 (x)b ⇒ RP3 (x)a, RP3 (x)b ∨ RP3 (x)b
Inmediato si escritura fuera instantánea
C.Ruz (PUC)
IIC2523
1/2013
18 / 89
Taxonomı́as
Organización de la memoria
Memoria compartida: Cache Coherence
Mecanismos:
Coherencia basada en directorio.
Registro de copias. Invalidación al escribir.
Snooping
Bus de coherencia de caches
Cada cache se preocupa de la coherencia con los demás
Tres estados: V (valid), D(dirty), S(shared)
Read miss → broadcast (y D → V )
Local write → broadcast (y V → D)
Snarfing
Controlador de cache monitorea la escritura en memoria de sus datos
Updates inmediatos
Protocolos de coherencia:
Distintos modelos de consistencia de memoria
Secuencial, causal, weak, release, . . .
C.Ruz (PUC)
IIC2523
1/2013
19 / 89
Taxonomı́as
Organización de la memoria
Memoria distribuida
Cada procesador tiene su memoria local.
Accesos a memorias remotas son explı́citos.
No hay contención
¿Cómo se comparten datos?
Distintas topologı́as
C.Ruz (PUC)
IIC2523
1/2013
20 / 89
Taxonomı́as
Organización de la memoria
Memoria distribuida: Mesh
Procesadores conectados en 2D grid.
Apropiado para aplicaciones particulares.
p
Conexiones se incrementan en O( (n))
C.Ruz (PUC)
IIC2523
1/2013
21 / 89
Taxonomı́as
Organización de la memoria
Memoria distribuida: Hypercube
Menos conexiones
Dimensión d
Construcción recursiva
Cada procesador tiene d conexiones a otros
Complejidad de conexiones O(log(d))
Propiedades de distancia definidas
Distancia máxima: d
Dimensión d → 2d nodos
C.Ruz (PUC)
IIC2523
1/2013
22 / 89
Taxonomı́as
Organización de la memoria
Memoria distribuida: Hypercube
9D Hypercube
C.Ruz (PUC)
IIC2523
1/2013
23 / 89
Modelos de comunicación
Contenidos
1
Taxonomı́as
Paralelismo de control y paralelismo de datos
Organización de la memoria
2
Modelos de comunicación
Entidades
Paradigmas
Roles
Ubicación
3
Patrones de arquitectura
4
Middlewares
5
Soporte del sistema operativo
Procesos y Threads
Comunicación e invocación
Virtualización
C.Ruz (PUC)
IIC2523
1/2013
24 / 89
Modelos de comunicación
Modelos de comunicación
Distribución sin comunicación no sirve.
4 puntos de vista:
¿Quiénes se comunican? → Entidades
¿Cómo se comunican? → Paradigmas
¿Qué papel juega cada uno? → Roles
¿Desde dónde se comunican? → Ubicación
C.Ruz (PUC)
IIC2523
1/2013
25 / 89
Modelos de comunicación
Entidades
Entidades
Protagonizado por . . .
Dos maneras de pensarlo:
Desde el punto de vista del sistema:
Nodos
Procesos
Threads
Desde el punto de vista de la programación:
¿Con qué resuelvo el problema?
Objetos
Componentes
Web Services
C.Ruz (PUC)
IIC2523
1/2013
26 / 89
Modelos de comunicación
Entidades
Entidades: objetos
Orientación a objetos
Abstracciones “del mundo real”
Solución mediante interacción de objetos
Interfaces y descripción de métodos
Objetos distribuidos
Java RMI, CORBA, DCOM/.NET, Pyro, JavaSpaces
C.Ruz (PUC)
IIC2523
1/2013
27 / 89
Modelos de comunicación
Entidades
Entidades: componentes
Orientación a componentes
Abstracciones de “soluciones”
Interacción de componentes
Interfaces y contratos
Interfaz y dependencias explı́citas
3rd party - components
Composición de soluciones y reusabilidad
CCA, CCM, GCM, .NET, SOFA, Fractal, Entreprise Javabeans
C.Ruz (PUC)
IIC2523
1/2013
28 / 89
Modelos de comunicación
Entidades
Entidades: Web Services
Servicios Web
Interfaces y encapsulamiento
Similar en concepto a objetos y componentes
Integrado en standards WWW
Servicios completos y sujetos a composición
Acoplamiento débil entre requester y provider
C.Ruz (PUC)
IIC2523
1/2013
29 / 89
Modelos de comunicación
Paradigmas
Paradigmas: ¿cómo comunicarse?
SMS, Voicemail, Twitter, Facebook, G+ ?
Tres clasificaciones:
Comunicación interprocesos
Invocación remota
Comunicación indirecta
C.Ruz (PUC)
IIC2523
1/2013
30 / 89
Modelos de comunicación
Paradigmas
Paradigmas: Interprocess Communication
Comunicación de bajo nivel entre procesos
Primitivas de paso de mensajes
Sockets: send(), recv()
Sincronı́a / asincronı́a, confiabilidad, orden
Codificación: marshalling, XML,
Comunicación de grupos: multicast
Virtualización de redes
MPI: Message Passing Interface
Popular en aplicaciones cientı́ficas
C.Ruz (PUC)
IIC2523
1/2013
31 / 89
Modelos de comunicación
Paradigmas
Paradigmas: Invocación Remota
Ejecución de operaciones/procedimientos/métodos en otro lugar
Request/reply
Modelo más básico (o único). Ej: HTTP
Remote Procedure Call (RPC)
Invocación similar a una invocación local
Sistema RPC maneja comunicación y marshalling
Remote Method Invocation (RMI)
RPC para objetos
Referencias a otros objetos
RPC y RMI se basan en Request/Reply
C.Ruz (PUC)
IIC2523
1/2013
32 / 89
Modelos de comunicación
Paradigmas
Paradigmas: RPC y RMI
RPC
RMI
C.Ruz (PUC)
IIC2523
1/2013
33 / 89
Modelos de comunicación
Paradigmas
Paradigmas: Invocación Remota
Comunicación es básicamente entre dos: sender y receiver
Acomplamiento fuerte suele no ser una buena idea
¿Debo conocer al receptor?
¿Es necesario que el receptor exista?
Suele agregarse un tercer elemento que permita desacoplar:
Espacio: no es necesario conocer al receptor
Tiempo: no es necesario que el receptor exista al mismo tiempo
C.Ruz (PUC)
IIC2523
1/2013
34 / 89
Modelos de comunicación
Paradigmas
Paradigmas: Comunicación Indirecta
No sólo entre pares:
Group Communication: one-to-many
Abstracción de grupo, pertenencia
Publish-Subscribe
Distribución de eventos a interesados, one-to-many
Colas de mensajes
Punto-a-punto basado en colas
Espacios de tuplas
Publicación de tuplas. Lectura por patrones.
Memoria Compartida Distribuida (DSM)
Abstracción de lectura/escritura a memoria
Acceso transparente a memoria remota
Modelos de consistencia
C.Ruz (PUC)
IIC2523
1/2013
35 / 89
Modelos de comunicación
Paradigmas
Paradigmas: Comunicación Indirecta
Publish-Subscribe
Publish-Subscribe
C.Ruz (PUC)
IIC2523
1/2013
36 / 89
Modelos de comunicación
Paradigmas
Paradigmas: Comunicación Indirecta
Message Queues
Message Queues
C.Ruz (PUC)
IIC2523
1/2013
37 / 89
Modelos de comunicación
Paradigmas
Paradigmas: Comunicación Indirecta
Tuplas
Espacios de Tuplas
C.Ruz (PUC)
IIC2523
1/2013
38 / 89
Modelos de comunicación
Paradigmas
Paradigmas: Comunicación Indirecta
DSM
Distributed Shared Memory
C.Ruz (PUC)
IIC2523
1/2013
39 / 89
Modelos de comunicación
Roles
Roles
Role Playing Games?
Roles implican responsabilidades2
¿Roles estáticos o dinámicos?
Dos modelos tı́picos
Cliente-Servidor
Peer-to-Peer (P2P)
2
y con un gran ¿rol? viene un gran responsabilidad . . . o algo ası́
C.Ruz (PUC)
IIC2523
1/2013
40 / 89
Modelos de comunicación
Roles
Roles: Cliente-Servidor
Cliente: Envı́a solicitudes (requests)
Servidor: Responde solicitudes con replies
Servidores pueden actuar como clientes de otros servidores
Web, DNS, NFS, . . . Internet Services
¿Cómo manejar la centralización?
C.Ruz (PUC)
IIC2523
1/2013
41 / 89
Modelos de comunicación
Roles
Roles: Peer-to-Peer
No solo para file sharing . . .
Miembros (pares, peers) cumplen
roles similares.
Motivación: compartir recursos
(sharing)
Objetivo: escalabilidad
Ejemplo: BitTorrent
Dificultades:
¿Cómo ubicar recursos?
Réplicas y consistencia
C.Ruz (PUC)
IIC2523
1/2013
42 / 89
Modelos de comunicación
Ubicación
Ubicación
¿Dónde se ejecuta esto?
Mapeo entidades → infrastructura fı́sica
Múltiples consideraciones: concurrencia, hardware, calidad de red, . . .
Algunas estrategias:
Mapeo a múltiples servidores
Caching
Código móvil
Agentes móviles
C.Ruz (PUC)
IIC2523
1/2013
43 / 89
Modelos de comunicación
Ubicación
Múltiples servidores
Replicación de servidores
Datos replicados o particionados
Cliente no sabe necesariamente con cuál se comunica
Ejemplo: NIS
C.Ruz (PUC)
IIC2523
1/2013
44 / 89
Modelos de comunicación
Ubicación
Caching
Almacenamiento de requests comunes
Verificación de actualidad
Incremento de disponibilidad
Ejemplo: Web Proxy Servers
C.Ruz (PUC)
IIC2523
1/2013
45 / 89
Modelos de comunicación
Ubicación
Código móvil
Ejecución de código local en lugar de remoto
Ejecución interactiva más eficiente
Simulación de actualizaciones push desde servidor
Potencial problema de seguridad
Ejemplo: Applets
C.Ruz (PUC)
IIC2523
1/2013
46 / 89
Modelos de comunicación
Ubicación
Agentes móviles
Código que se ejecuta remotamente de computador en computador
Migración
Algunas tareas:
Recolección de información
Actualización y mantenimiento
Potencial problema de seguridad
Ejemplo: Xerox PARC worm, 1982
C.Ruz (PUC)
IIC2523
1/2013
47 / 89
Patrones de arquitectura
Contenidos
1
Taxonomı́as
Paralelismo de control y paralelismo de datos
Organización de la memoria
2
Modelos de comunicación
Entidades
Paradigmas
Roles
Ubicación
3
Patrones de arquitectura
4
Middlewares
5
Soporte del sistema operativo
Procesos y Threads
Comunicación e invocación
Virtualización
C.Ruz (PUC)
IIC2523
1/2013
48 / 89
Patrones de arquitectura
Patrones Arquitecturales
Cómo organizo la aplicación distribuida.
Soluciones arquitecturales tı́picas.
Cuatro a analizar:
Layering
Tiering
Thin clients
C.Ruz (PUC)
IIC2523
1/2013
49 / 89
Patrones de arquitectura
Layers
Basado en niveles de abstracción.
Cada capa provee servicios a la siguiente, y obtiene servicios de la
anterior.
Plataforma: x86/Windows, x86/Linux, ARM/Symbian, x86/MacOSX
Middleware: ocultar heterogeneidad, interfaz común para
programadores
C.Ruz (PUC)
IIC2523
1/2013
50 / 89
Patrones de arquitectura
Tiers
Separación de funcionalidades.
Aplicable a cada layer.
Tı́picamente organización de aplicaciones.
Comúnmente 2 ó 3 tiers, pero generalizable a n.
Ejemplo: 3-tier
Presentation tier
Interacción con usuario, actualización visual
Application/logic/business tier
Funcionalidad de la aplicación
Data tier
Almacenamiento de datos
C.Ruz (PUC)
IIC2523
1/2013
51 / 89
Patrones de arquitectura
Tiers
C.Ruz (PUC)
IIC2523
1/2013
52 / 89
Patrones de arquitectura
Thin Clients
Mı́nima funcionalidad en el cliente.
Tendencia en Cloud Computing
Cliente sólo maneja la interfaz
Procesamiento se hace en la nube
Ejemplos:
Cloud-based: GMail, Google Docs
Very thin: Chromebooks
Ultra thin: VNC
C.Ruz (PUC)
IIC2523
1/2013
53 / 89
Patrones de arquitectura
Otros casos
Proxy. Representante.
Transparencia de ubicación.
Replicación y caching.
Ejemplo: Web Proxies
Brokers. Servicio de contacto.
Provider + Requester + Broker
Broker relaciona Provider con Requester
Ejemplo: Service Oriented Architectures (SOA)
Reflection. Introspection e intercession.
Capacidad del sistema de examinarse y modificarse.
Meta-interfaz sobre elementos del sistema.
Ejemplo: Java RMI.
C.Ruz (PUC)
IIC2523
1/2013
54 / 89
Middlewares
Contenidos
1
Taxonomı́as
Paralelismo de control y paralelismo de datos
Organización de la memoria
2
Modelos de comunicación
Entidades
Paradigmas
Roles
Ubicación
3
Patrones de arquitectura
4
Middlewares
5
Soporte del sistema operativo
Procesos y Threads
Comunicación e invocación
Virtualización
C.Ruz (PUC)
IIC2523
1/2013
55 / 89
Middlewares
¿Qué es un Middleware?
Una capa de abstracción de alto nivel.
Objetivos:
Proveer una interfaz de programación común para desarrolladores.
Abstrayendo caracterı́sticas de sistema operativo e infrastructura
(hardware y red)
Un middleware provee ciertas garantı́as al programador.
¿Para que pueda hacer qué? . . .
. . . muchas cosas
C.Ruz (PUC)
IIC2523
1/2013
56 / 89
Middlewares
Muuuuchos tipos de Middleware
Comunicación de procesos
Objetos distribuidos
Componentes livianos
Componentes / Application Servers
Publish/Subscribe
Message Queues
Web Services
Grid Services
P2P Routing
P2P
C.Ruz (PUC)
RPC
CORBA, Java RMI
Fractal, OpenCOM
Enterprise JavaBeans, CORBA
Component Model, JBoss
CORBA Event Service, Scribe,
JMS
Websphere MQ, JMS, Apache
Active MQ, AMQP
Apache AXIS, Apache CXF
Globus Toolkit
Pastry, Tapestry, Chord, CAN
Squirrel,
OceanStore,
Ivy,
Gnutella
IIC2523
1/2013
57 / 89
Soporte del sistema operativo
Contenidos
1
Taxonomı́as
Paralelismo de control y paralelismo de datos
Organización de la memoria
2
Modelos de comunicación
Entidades
Paradigmas
Roles
Ubicación
3
Patrones de arquitectura
4
Middlewares
5
Soporte del sistema operativo
Procesos y Threads
Comunicación e invocación
Virtualización
C.Ruz (PUC)
IIC2523
1/2013
58 / 89
Soporte del sistema operativo
Sistemas Operativos
Qué caracterı́sticas provee el sistema operativo para ejecutar procesos
distribuidos.
¿Qué es lo que hace un Sistema Operativo?
Abstraer detalles de infrastructura fı́sica
Proveer una interfaz para ejecutar programas sobre el hardware
Archivos (en lugar de bloques de disco)
Sockets (en lugar de paquetes de red)
C.Ruz (PUC)
IIC2523
1/2013
59 / 89
Soporte del sistema operativo
Network Operating Systems
Windows, UNIX, permiten acceso a red: Sistemas Operativos de Red
¿Proveen una imagen de sistema único?
Cada sistema administra sus propios recursos
Nodos mantienen un alto grado de autonomı́a
¿Habrá algún Sistema Operativo Distribuido ?
Más probable: S.O. + Middleware
C.Ruz (PUC)
IIC2523
1/2013
60 / 89
Soporte del sistema operativo
Sistema Operativo y Middlewares
Middleware provee la interfaz única sobre distintos SS.OO.
Caracterı́sticas interesantes:
Procesos y threads
Comunicación e invocación
Virtualización
C.Ruz (PUC)
IIC2523
1/2013
61 / 89
Soporte del sistema operativo
Procesos y Threads
Procesos y Threads
Proceso: entorno de ejecución con uno o más threads.
Espacio de direccionamiento
Sincronización de threads y acceso a recursos del S.O. (semáforos,
sockets, . . . )
Acceso a recursos de alto nivel (archivos abiertos, ventanas, . . . )
Thread: actividad dentro de un proceso
Múltiples threads pueden compartir los recursos de un proceso.
C.Ruz (PUC)
IIC2523
1/2013
62 / 89
Soporte del sistema operativo
Procesos y Threads
Procesos vs. Threads
Procesos
Caros de crear y administrar
Sirven como un ambiente protegido para threads
Threads
Pueden ser creados y destruı́dos dinámicamente (y fácilmente)
Permiten aprovechar el grado de ejecución concurrente
Separando tareas colaborativas
Aprovechando el overlap ejecución vs. I/O
C.Ruz (PUC)
IIC2523
1/2013
63 / 89
Soporte del sistema operativo
Procesos y Threads
Espacios de direcciones
Unidad virtual de memoria de un
proceso.
Regiones: código, heap, stack
Stacks adicionales por thread
C.Ruz (PUC)
IIC2523
1/2013
64 / 89
Soporte del sistema operativo
Procesos y Threads
Creación de procesos
¿Dónde crearlo?
En UNIX:
fork, nuevo proceso copiado del caller
exec, ejecuta el código del programa indicado
En un ambiente distribuido: ¿en qué nodo crearlo?
Nodo local
Nodo externo indicado explı́citamente
Nodo externo seleccionado por otra entidad (scheduler)
¿Es posible modificar esta asignación?
Polı́tica estática o adaptiva
Sistemas de balance de carga
C.Ruz (PUC)
IIC2523
1/2013
65 / 89
Soporte del sistema operativo
Procesos y Threads
Creación de procesos
Creando el entorno
fork, copia del espacio de direcciones
¿Y si el proceso hijo no necesita todo el espacio?
Copy-On-Write (COW)
Regiones compartidas hasta que se escriben
C.Ruz (PUC)
IIC2523
1/2013
66 / 89
Soporte del sistema operativo
Procesos y Threads
Threads
Procesos multithreaded
Capacidad de atender más request (¿cuántas?)
C.Ruz (PUC)
IIC2523
1/2013
67 / 89
Soporte del sistema operativo
Procesos y Threads
Threads
Distintas maneras de asignar threads a tareas.
Pool de workers
Thread-per-request
Thread-per-connection
Thread-per-object
C.Ruz (PUC)
IIC2523
1/2013
68 / 89
Soporte del sistema operativo
Procesos y Threads
Programando threads
Kernel threads
Creados y manejados por el S.O.
Input/Output administrador por S.O.
User threads
Provisto por librerı́as de usuario
Más livianos que kernel threads
No pueden aprovechar directamente multiprocesadores
Administración debe ser proveı́da por la librerı́a
Posibilidad de crear deadlocks en operaciones de I/O
pthreads, CThreads, Java Thread class
C.Ruz (PUC)
IIC2523
1/2013
69 / 89
Soporte del sistema operativo
Procesos y Threads
Administración de Threads
Estados en Java: SUSPENDED, RUNNABLE, READY
Thread(ThreadGroup group, Runnable target, String name)
setPriority(int newPriority), getPriority()
run()
start(), SUSPENDED → RUNNABLE.
sleep(int millisecs)
yield()
destroy()
Sincronización
thread.join(long millisecs)
thread.interrupt()
object.wait(long millisecs, int nanosecs)
object.notify(), object.notifyAll()
C.Ruz (PUC)
IIC2523
1/2013
70 / 89
Soporte del sistema operativo
Comunicación e invocación
Comunicación e invocación
Comunicación: transferencia de datos entre procesos, posiblemente en
nodos distintos
Invocación: Solicitud de ejecución de una operación en un espacio de
direcciones distinto
C.Ruz (PUC)
IIC2523
1/2013
71 / 89
Soporte del sistema operativo
Comunicación e invocación
Costo de invocación
Tipos de comunicación
RPC null ∼ 10−3 sec
∼ 100 bytes transmitidos
Llamado normal ∼ 10−6
sec
C.Ruz (PUC)
IIC2523
1/2013
72 / 89
Soporte del sistema operativo
Comunicación e invocación
Costo de invocación
C.Ruz (PUC)
IIC2523
1/2013
73 / 89
Soporte del sistema operativo
Comunicación e invocación
¿Podemos mejorar?
Comunicación ası́ncrona
Invocaciones concurrentes
Aprovechando
multi-threading
Invocaciones ası́ncronas
Solo se hace un
rendez-vous
C.Ruz (PUC)
IIC2523
1/2013
74 / 89
Soporte del sistema operativo
Virtualización
Virtualización
Objetivo: proveer máquinas virtuales sobre una misma máquina fı́sica.
Cada máquina ejecuta su propia versión del S.O.
Multiplexación de recursos
C.Ruz (PUC)
IIC2523
1/2013
75 / 89
Soporte del sistema operativo
Virtualización
Virtualización
¿Para qué sirve?
Máquinas virtuales pueden ser migradas, i.e., mapeadas a distintas
máquinas fı́sicas.
Cloud Computing. Permite provee IaaS (Infrastructure as a Service).
Desafı́os en asignación de recursos entre máquinas virtuales y fı́sicas.
Utilización de otros sistemas operativos en una misma máquina host.
C.Ruz (PUC)
IIC2523
1/2013
76 / 89
Soporte del sistema operativo
Virtualización
Virtualización
¿Quién lo administra?
Virtual Machine Monitor, ó Hypervisor
Provee una interfaz similar a aquella de la máquina fı́sica.
Diferentes niveles:
Full Virtualization
Paravirtualization
Ejemplos:
VirtualBox
VMWare
Parallels
Virtual Server
Xen
C.Ruz (PUC)
IIC2523
1/2013
77 / 89
Soporte del sistema operativo
Virtualización
Xen3
Solución de virtualización. (XenoServer project, 2003)
Objetivo: proveer infrastructura pública para computación distribuida de
gran escala.
Conjunto de XenoServers
Administrados por Xen Virtual Machine Monitor
Xen
Múltiples SS.OO. ejecutando de manera aislada en hardware
tradicional, y con poco overhead
Cada S.O. cree que es el único ejecutando.
3
http://www.xen.org
C.Ruz (PUC)
IIC2523
1/2013
78 / 89
Soporte del sistema operativo
Virtualización
Arquitectura de Xen
Xen Hypervisor
Provee manejo de recursos y aislamiento
No conoce los devices, pero permite acceder a ellos
Falla en Hypervisor → Falla en todos los S.O.
C.Ruz (PUC)
IIC2523
1/2013
79 / 89
Soporte del sistema operativo
Virtualización
Arquitectura de Xen
Domains: Instancias de VMs en Xen
DomainU: conjunto de todas las instancias
Domain0: control, y acceso privilegiado a recursos
Creación de nuevos dominios
C.Ruz (PUC)
IIC2523
1/2013
80 / 89
Soporte del sistema operativo
Virtualización
¿Virtualizar qué?
Las mismas funciones de un S.O.:
CPU
Scheduling
Memoria
Dispositivos
C.Ruz (PUC)
IIC2523
1/2013
81 / 89
Soporte del sistema operativo
Virtualización
¿Cuándo se puede virtualizar?
Popek y Goldberg (1974) definen las instrucciones sensibles como
aquellas que modifican el estado de la máquina de manera que puedan
afectar a otros procesos.
Instrucciones sensibles de control: permiten cambiar la configuración
de los recursos de un proceso.
Instrucciones sensibles de comportamiento: permiten leer estados
privilegiados obteniendo información de la máquina fı́sica
Condición para virtualización
Todas las instrucciones sensibles deben ser privilegiadas.
De esta manera el Hypervisor podrı́a interceptar todas esas
instrucciones.
Sin embargo no es ası́ en las arquitecturas x86.
C.Ruz (PUC)
IIC2523
1/2013
82 / 89
Soporte del sistema operativo
Virtualización
¿Cuándo se puede virtualizar?
Dos soluciones para virtualizar CPU
1
Full virtualization: proveer la emulación para todas las instrucciones.
Hypervisor puede interceptar todo.
Produce más overhead.
2
Paravirtualization: permitir que algunas instrucciones se ejecuten en
el hardware.
Hypervisor solo puede interceptar las privilegiadas.
El S.O. guest debe manejar las instrucciones sensible.
Más eficiente, pero require modificar el S.O. guest.
C.Ruz (PUC)
IIC2523
1/2013
83 / 89
Soporte del sistema operativo
Virtualización
¿Cómo virtualizar?
Ejemplo: 4 niveles de privilegios en x86
Kernel-based operating systems
Paravirtualization en Xen
En el guest modificado, instrucciones privilegiadas se reescriben como
hypercalls
C.Ruz (PUC)
IIC2523
1/2013
84 / 89
Soporte del sistema operativo
Virtualización
Scheduling
Tradicionalmente:
Scheduling de procesos
Scheduling de threads intra-procesos
Xen provee un nivel más: VCPU (Virtual CPU)
Hypervisor hace scheduling de VCPUs
S.O. Guest hace scheduling de procesos
S.O. o bibliotecas hacen scheudling de threads
Dos estrategias:
Simple Earliest Deadline First (SEDF)
VCPU con deadline más cercano
Deadline a partir de slice y periodo
Credit Scheduler
Definido en base a weight y cap (porcentaje de tiempo que debe correr)
VCPU consumen créditos
C.Ruz (PUC)
IIC2523
1/2013
85 / 89
Soporte del sistema operativo
Virtualización
Virtualización de Memoria
Dos dificultades:
Asignar nivel intermedio de mapeo
Mantener protección entre distintos guest
Hypervisor ocupa memoria fı́sica
Debe proveer una abstracción de memoria fı́sica ”limpia” al guest
La memoria pseudo-fı́sica provee esta abstracción
Hypervisor permite algunas instrucciones de asignación al guest
C.Ruz (PUC)
IIC2523
1/2013
86 / 89
Soporte del sistema operativo
Virtualización
Virtualización de dispositivos
Split Device Drivers: imagen de dispositivo único
Back-end: multiplexación, e interfaz genérica
Front-end: proxy para el guest
C.Ruz (PUC)
IIC2523
1/2013
87 / 89
Soporte del sistema operativo
Virtualización
Llevando un sistema guest a Xen
Se requiere:
Reemplazar instrucciones privilegiadas por hypercalls
Reimplementar instrucciones sensibles no-privilegiadas
Portar el sistema de manejo de memoria
Proveer split-device drivers
C.Ruz (PUC)
IIC2523
1/2013
88 / 89
Soporte del sistema operativo
Virtualización
Resumen
Un largo capı́tulo
Taxonomı́as
Clasificaciones de acuerdo a organización de CPUs y de memoria
Modelos de comunicación
Quienes se comunican y cómo
Por ver . . . detalles de cómo programar la comunicación
Patrones de arquitectura
Cómo se organizan las entidades comunicantes
Middleware
Variadas soluciones para problemas especı́ficos
Soporte del Sistema Operativos
Procesos y threads permiten construir las aplicaciones
Virtualización permite multiplexar los recursos
C.Ruz (PUC)
IIC2523
1/2013
89 / 89