Sistemas Distribuidos. Componentes de un S.O. En Particular Minix está dividido en módulos –1)...

Post on 24-Jan-2016

220 views 0 download

Transcript of Sistemas Distribuidos. Componentes de un S.O. En Particular Minix está dividido en módulos –1)...

Sistemas DistribuidosSistemas Distribuidos

Componentes de un S.O.Componentes de un S.O.

En Particular Minix está dividido en módulos– 1) MicroKernel– 2) Tareas E/S– 3) Procesos Servidores– 4) Procesos de Usuarios

Son módulos independientes Para arquitectura FLYNN - SISD

Funciones de un S.O.Funciones de un S.O.

Administración de Procesador– Cambio de Estados para procesos– Politica de Asignación de procesador– Política de Ordenación de Colas

Administración de Memoria– Simple contigua– Paginada / Segmentada

Administración de la Información– Layout en disco– Funciones de acceso al sistema de archivos

• Transparencia Administración de Reloj del sistema

– Fecha, Hora

Funciones de un S.O.Funciones de un S.O.

Administración de Recursos– Dedicados

• Manejo de Deadlocks

– Compartidos Comunicación entre procesos

– Send/receive• Bloqueantes / No• Con Buffer / Sin

– Share memory– Pipes– Sockets

Sincronización entre procesos– Semáforos, Regiones Críticas, Monitores

System Calls - ServiciosSystem Calls - Servicios

[PROC] Administración de Procesos– fork, waitpid, wait, exit, execve, ...

[IPC] Señales– kill, pause, alarm, sigaction, ...

[FS] Administración de Archivos– creat, mknod, open, close, read, write, dup, pipe, ...

[FS] Administración del Sistema de Archivos– mkdir, rmdir, link, mount, umount, chdir, chroot, ...

[FS] Protección– chmod, getuid, setuid, getgid, setgid, chown, ...

[TIME] Administración de Tiempo– time, stime, utime, times, ...

Una clasificaciónUna clasificación

Cola de MultiprocesadorCola de Multiprocesador

Sistema Operativo sobre MIMDSistema Operativo sobre MIMD

Existen dos tipos de arquitecturas MIMD– Fuertemente acopladas

• Multiprocesadores

– Debilmente acopladas• Multicomputadores

Clementina II - SGI (MIMD – FA)– Arquitectura

• 40 procesadores• Inteconectados por Cray-links (Hipercubo grado 3)• Memoria distribuida (NUMA)• Función de Ruteo

– Sistema Operativo IRIX• Tiene share-memory y permite el uso de Threads

Sistema Operativo sobre MIMDSistema Operativo sobre MIMD

Fenix – SUN Enterprise (MIMD – FA)– Arquitectura

• 16 procesadores• Interconectados por Bus• Memoria distribuida (UMA)

– Sistema Operativo SOLARIS• Permite el uso de Threads

Sheldon – Cluster Intel Xeon (MIMD – DA)– Arquitectura

• 40 nodos - dual procesador• Interconectados por Red Ethernet 1 Gbit• Memoria distribuida (NORMA)

Sistema Operativo sobre MIMDSistema Operativo sobre MIMD

Sheldon – Cluster Intel Xeon (MIMD – DA)– Sistema Operativo Linux (Varios)

• Permite uso de Threads dentro de un nodo.

• Entre nodo por pasaje de mensaje

• No hay unica visión de sistema operativo

• Necesidad de JOB SCHEDULER para asignacion de recursos

• Necesidad de un FS para todos los nodos.– File System de Red

• Autenticación entre los distintos S.O.

• No existe Share Memory entre nodos.

Sistema Operativo sobre MIMDSistema Operativo sobre MIMD

IDEAL – Cluster (MIMD – DA)– Sistema Operativo Distribuido

• Visión única de cola de Procesos• Visión única de File System• Visión única de Memoria• Transparencia en la ubicación de Recursos.• Transparencia en la ejecución de Procesos.• Migración de Procesos entre los nodos• Permite uso de Threads.

– Módulos cooperativos para brindar servicio

– Coordinación de módulos• Distribuido / Centralizado

– Coherencia

Temas de ImplementaciónTemas de Implementación

Comunicación entre nodos– Primitivas Send/Receive

• Conexión y Confiabilidad• Niveles de conectividad y confiabilidad (ACKs)

– Función de Ruteo– Tipo de Medio de Transmisión

Identificación de nodos– Estaticos / Con cambios

Identificación de servicios– Estaticos / Con cambios

Stacks ISO / TCP-IP Modelo Cliente/Servidor

– Send / Receive / Accept

Cliente servidorCliente servidor

Direccionamiento– 1) Integrar machine.number – 2) Dejar que los procesos elijan

direcciones al azar y localizarlos mediante transmisiones

– 3) Generar un servidor de nombres

PrimitivasPrimitivas

SEND BLOQUEANTES (Primitivas sincrónicas

SEND NO BLOQUEANTES (Primitivas asincrónicas

SEND SIN BLOQUEO CON INTERRUPCIÓN PRIMITIVAS ALMACENADAS EN BUFFER

vs NO ALMACENADAS PRIMITIVA CONFIABLES vs NO

CONFIABLES

Confiable vs No confiableConfiable vs No confiable

Implementación Cliente ServidorImplementación Cliente Servidor

Mensajes de ControlMensajes de Control

Secuencias de Mensaje de Secuencias de Mensaje de ControlControl

Temas de ImplementaciónTemas de Implementación

Uso de procesadores remotos– Ejecución Asincrónica

• Cliente/Servidor

– Ejecución Sincrónica• Remote Procedure Call

Remote Procedure Call– Simula la llamada a un procedimiento remoto como si

fuera local.– Exiten herramientas que generan el código fuente

• RPCGEN (XDR, SRC) (SRC)

– Se generan los stubs cliente y servidor.– Existe binding dinámico y registración del servidor.

Etapas RPCEtapas RPC

Temas de implementaciónTemas de implementación

Remote Procedure Call (Camino Critico)– El procedimiento cliente llama al stub cliente de manera transparente.

Usando Stack.– El stub cliente arma el mensaje y se lo envía al kernel.– El kernel realiza el send del mensaje al kernel de la máquina remota.– El kernel remoto le da el mensaje al stub del server– El stub del server desempaqueta los parámetros y se los pasa al

server. Usan Stack.– El server propiamente dicho realiza su trabajo y retorna un resultado

al stub.– El stub del server empaqueta el valor retornado y se lo manda al

kernel.– El kernel remoto envía el mensaje al kernel del cliente.– El kernel del cliente sube el mensaje al stub del cliente.– El stub cliente desempaqueta el resultado y se lo pasa al cliente.

Pasaje de ParámetrosPasaje de Parámetros

Pasaje de ParámetrosPasaje de Parámetros

Por referencia ?Por valorcopy/restore

Pasaje de ParámetrosPasaje de Parámetros

Suponemos int a, b; res: a + b (*) Reemplazamos (*) por función suma res = suma(a, b)

suma (c,d) resp:= c + d (por valor) return (resp)

Pasaje de ParámetrosPasaje de Parámetros

Ores := suma (&a, &b)

suma (c, d)resp = *c + *dreturn (resp) (1)

Pasaje de ParámetrosPasaje de Parámetros

Si estamos en (1) copy/restore Stub cliente suma (c, d) c1 = *c d1 = *d Enviar servidor (suma (c1, d1) Recibir seridor (resp) Return (resp)

Pasaje de ParámetrosPasaje de Parámetros

Stub servidor

Recibir (cliente, suma(c1, d1))resp := c1 + d1Enviar (cliente, resp)

Pasaje de ParámetrosPasaje de Parámetros

Imaginemos inc(i, i) o sea i:= i +1 call inc(&i, &i)

inc (i, i) c1 = *i c2 = *i Enviar serv inc (c1, c2) Recibir serv (c1, c2)

&i = c1 &i = c2 ¿qué valor queda en i ?

Protocolos RPCProtocolos RPC

Conexión: Ventajas: comunicación más fácil, el

núcleo del cliente no debe reocuparse de si los mensajes se pierden o de si no hay reconocimiento.

Desventajas: En una LAN tiene pérdida de desempeño debido a que todo este software adicional estorba, además la ventaja de no perder los paquetes no tiene sentido ya que las LAN son confiables en esto.

Protocolos RPCProtocolos RPC

Sin Conexión:En general en sistemas dentro de un único edificio se

utilizan protocolos sin conexión. Mientras que en redes grandes se utiliza uno orientado a conexión.

* Utilizar un protocolo estándar o alguno diseñado en forma específica para RPC, por ejemplo:

* IP (o UDP, integrado a IP) tiene puntos a favor: -- Ya está diseñado (ahorra un trabajo considerable)-- Se dispone de muchas implementaciones

Protocolos RPCProtocolos RPC

* Protocolo Detenerse y esperar (stop and wait protocol): establece que el cliente envíe el paquete y espere un reconocimiento antes de enviar el segundo paquete.

* Protocolo de Chorro (Blast Protocol): establece que el cliente mande todos los paquetes y luego espere el reconocimiento del mensaje completo

Temas de implementaciónTemas de implementación

Remote Procedure Call (Semántica de Fallas)– El Cliente no puede ubicar al servidor

• EXCEPCIÓN

– Se pierde el msg de requerimiento del cliente al servidor• Retransmisión al no recibir ACK usando TIMER

– El msg de respuesta del servidor se pierde• Diferenciar esta falla con la anterior. (nro de secuencia)

– El servidor se cae luego de recibir el requerimiento• A) Recibe y procesa, se cae antes de enviar la respuesta• B) Se cae antes de procesar el pedido

– Semántica: At Lest Once – At most Once – Exactly Once

– El Cliente se cae• Huérfanos :

– Reencarnación – Reencarnación Suave – Expiración Exterminación.

Temas de Diseño de S.O.Temas de Diseño de S.O.

Transparencia– De Locación / De Migración / De Réplica

– De Concurrencia / De Paralelismo Flexibilidad

– Monolitico / Microkernel Confiabilidad Performance

– Métricas• Tiempo de Respuesta / Rendimiento• Uso del Sistema / Capacidad consumida de Red

Escalabilidad– NFS no es escalable

Consultas ?Consultas ?

Arquitecturas MIMD– Tipos / Performance

Sistemas Operativos Distribuidos– Modulos

Sistemas Distribuidos– Servicios

Modelo Cliente-Servidor– RPC

Varias.....