Introducción a los sistemas distribuidos

1. Introducción a los sistemas distribuidos

2. Contenido • Sistemas distribuidos • Sistemas operativos distribuidos • Comunicación de procesos • Sincronización de procesos • Gestión de procesos • Sistemas de archivos • Gestión de memoria

3. Conceptos previos • Un programa es un conjunto de instrucciones. • Un proceso es un programa en ejecución. • Una red de computadoreses un conjunto de computadores conectados por una red de interconexión. • Un sistema distribuido (SD) • Modelo físico: conjunto de nodos (procesadores sin memoria ni reloj común) conectados por una red. • Modelo lógico: conjunto de procesos que ejecutan concurrentemente en uno o más computadores que colaboran y comunican intercambiando mensajes. • Un protocolo es un conjunto de reglas e instrucciones que gobiernan la comunicación en un sistema distribuido, es decir, el intercambio de mensajes.

4. Características • Compartir recursos (HW, SW, datos). • Acceso a recursos remotos. • Modelo cliente-servidor • Modelo basado en objetos • Ofrecen una buena relación coste/rendimiento • Capacidad de crecimiento • Tolerancia a fallos, disponibilidad • Replicación • Concurrencia • Velocidad • Paralelismo

5. Desventajas • Necesidad de software más complejo • Problemas de fiabilidad • Problemas de seguridad y confidencialidad

6. Arquitectura de un sistema distribuido

7. Redes e interconexión • Paquete: tipo de mensaje que se intercambia entre dos dispositivos de comunicación. • Tamaño limitado por el hardware • Mensaje: objeto lógico que se intercambian entre dos o más procesos. • Su tamaño puede ser bastante grande. • Un mensaje se descompone en paquetes. • Subsistema de comunicación: conjunto de componentes HW y SW que proporcionan servicios de comunicación en un sistema distribuido. • Protocolo: conjunto de reglas e instrucciones que gobiernan el intercambio de paquetes y mensajes

8. Propiedades de un subsistema de comunicación • Tasa de transferencia: velocidad de transferencia • Latencia: tiempo necesario para transferir un mensaje vacío • Tiempo de transferencia = latencia + tamaño/tasa de trasferencia • Paquetes/segundo • Capacidad de crecimiento. Aumento en el nº de nodos • Calidad de servicio • Importante en aplicaciones multimedia y de tiempo real • Fiabilidad del subsistema • Mecanismos de detección de errores • Seguridad: protección de los paquetes • Confidencialidad: proteger la identidad de los emisores

9. Tipos de redes de computadores • Redes de área local (LAN, Local Area Network) • Redes que enlazan sistemas cercanos • Posibilidad de difusión de mensajes (broadcast) • Redes de área extensa (WAN, Wide Area Network) • Poco ancho de banda (20-500 Kbps) • Bajas latencias • Redes telefónicas, redes públicas de datos, fiabra óptica RDSI, B-RDSI, ATM • Nuevos desarrollos en telecomunicaciones (ATM y RDSI) • Diferencias entre LAN y WAN cada vez más borrosas

10. Protocolos de comunicación • Protocolo: conjunto de reglas y formatos que permiten la comunicación entre procesos. • La definición de un protocolo tiene dos parte: • Especificación de la secuencia de mensajes que deben intercambiarse. • Especificación del formato de mensajes. • El software de red se organiza en niveles

11. Funciones de una pila de protocolos • Segmentación y ensamblado de mensajes • Encapsulado: incorporación de información de control a los datos • Dirección del emisor y receptor • Código de detección de errores • Control de conexión • Protocolos orientados a conexión • Protocolos no orientados a conexión: • No se asegura el orden secuencial de los datos transmitidos • Entrega ordenada en protocolos orientados a conexión • Números de secuencia

12. Funciones de una pila de protocolos II • Control de flujo: función realizada en el receptor para limitar la cantidad o tasa de datos que envía el emisor. • Control de errores: se basan en el uso de una secuencia de comprobación y reenvío. • Direccionamiento, conseguir que los mensajes alcancen al receptor • Multiplexación: necesario para un uso más eficiente de los servicios • Servicios de transmisión: • Prioridad • Calidad de servicio • Seguridad

13. Ejemplos de protocolos • Protocolos internet: • Originados por el trabajo de DARPA en los 70 • Muy utilizados en la actualidad • Gran crecimiento durante los 90 debido al uso del Web • Protocolos OSI (open system interconection) • Estándar desarrollado por ISO • Estándares propietarios • SNA de IBM (años 70) • DECnet desarrollado por DEC • NetWare: red de Novell para redes de PC

14. Protocolos TCP/IP • Resultado de la investigación y desarrollo llevados a cabo en la red ARPANET (financiada por DARPA) en los años 70 • Familia de protocolos utilizados en Internet • En los 90 se ha establecido como la arquitectura comercial dominante: • Se especificaron y utilizaron antes de OSI • Independiente de la tecnología de red utilizada • Internet está construida sobre un conjunto de protocolos TCP/IP. • Espectacular desarrollo de World Wide Web

15. Protocolos TCP/IP

16. Protocolo Internet (nivel IP) • La transmisión no es fiable (no se asegura la recepción de los paquetes IP). Los paquetes se pueden descartar por: • Expiración del tiempo de vida • Congestión • Error en la suma de comprobación • Control de flujo muy limitado • Calidad de servicio muy limitado • Seguridad: normal o alto • Retardo: normal o bajo • Rendimiento: normal o alto

17. Protocolos de transporte • ProtocoloTCP • Orientado a conexión • Garantiza que los datos se entregan en el orden en el que se envían • Las conexiones TCP se ven como un flujo de bytes • La transmisión se considera “fiable”. Pueden perderse mensajes (sobrecarga en la red, fallos en encaminadores, etc.) • Cuando los mensajes son muy pequeños, TCP los retrasa hasta conseguir uno más grande • Esta opción debe desactivarse si es necesario • Escrituras concurrentes sobre una misma conexión TCP pueden provocar que los datos se entremezclen.

18. Protocolos de transporte • Protocolo UDP • Protocolo de datagramas no orientado a conexión. • Protocolo no fiable • Los paquetes se pueden perder, duplicar, recibir en orden distinto al enviado • Tamaño máximo del mensaje: 64 KB

19. Encaminamiento • Permite que los paquetes viajen del proceso emisor al receptor. • Algoritmo: • Un programa de aplicación genera un paquete, o bien se lee un paquete de la interfaz de red. • Si el paquete es para la máquina, se acepta. • En caso contrario, se incrementa el contador de saltos, si se excede el máximo, el paquete se descarta. • Si el paquete no es para la máquina se busca en la tabla de encaminamiento y se retransmite a la interfaz adecuada. • Tablas estáticas, las más utilizadas • Tablas dinámicas

20. Papel del sistema operativo • El SW de comunicación de un sistema operativo se organiza como un conjunto de componentes con tareas concretas • Subsistema de almacenamiento: buffers donde almacenar los paquetes que llegan y se envían (limitado) • En implementaciones UNIX típicas • TCP reserva para cada puerto (socket) un buffer de 8 KB y UDP 2 buffers de 8KB. El tamaño se puede incrementar hasta 64 KB. • Los mensajes a enviar se copian a estos buffers • El contenido de estos buffers se fragmenta y se copian a nuevos bloques de memoria a utilizar por IP • IP envía finalmente los paquetes por la interfaz de red correspondiente

21. Papel del sistema operativo • Un sistema operativo puede perder paquetes cuando la tasa de envíos y de recepción es muy grande. • En sistemas operativos multiusuario la pérdida de paquetes suele producirse a ráfagas debido a los algoritmos de planificación. • La latencia del SO ha crecido en términos relativos

22. ¿Dónde se pierde el tiempo? • Códigos de corrección (Checksum) • Sobre datos TCP y UDP • Sobre cabeceras IP • Copias de datos • Entre usuario y kernel • Estructura de datos • Gestión de los buffers, colas de defragmentación de paquetes IP, • Sistema Operativo • Sobrecarga impuesta por las operaciones del SO

23. Contenido • Sistemas distribuidos • Sistemas operativos distribuidos • Comunicación de procesos • Sincronización de procesos • Gestión de procesos • Sistemas de archivos • Gestión de memoria

24. Sistema operativo en red (SOR) • El usuario ve un conjunto de máquinas independientes • No hay transparencia • Se debe acceder de forma explícita a los recursos de otras máquinas • Difíciles de utilizar para desarrollar aplicaciones distribuidas

25. Sistema operativo distribuido (SOD) • Se comporta como un SO único (visión única) • Distribución. Transparencia • Se construyen normalmente como micronúcleos que ofrecen servicios básicos de comunicación • Mach, Amoeba, Chorus. • Todos los computadores deben ejecutar el mismo SOD

26. Transparencia • Acceso: acceso a recursos remotos y locales de igual forma • Posición: acceso a los recursos sin necesidad de conocer su situación • Concurrencia: acceso concurrente a recursos compartidos sin interferencias • Replicación: Acceso a recursos replicados sin conocimiento de que lo son • Fallos: mantenimiento del servicio en presencia de fallos. • Migración: permite que los recursos y objetos se muevan sin afectar a la operación de los programas. • Capacidad de crecimiento: facilidad para crecer sin afectar a la estructura del sistema

27. Middleware y entornos distribuidos • Servicios y protocolos estándarizados: Sistemas abiertos • Ofrecen servicios no incluidos en el SO (servicios de ficheros distribuidos, servicios de nombres, ...) • Facilitan el desarrollo de aplicaciones distribuidas • Independientes del HW y del SO subyacente. • DCE, CORBA, DCOM, Legion, Globe, Globus

28. Servicios de un sistema operativo distribuido • Servicios de comunicación • Servicios de sincronización • Gestión distribuida de procesos • Sistemas de archivos distribuidos • Memoria compartida distribuida

29. Contenido • Sistemas distribuidos • Sistemas operativos distribuidos • Comunicación de procesos • Sincronización de procesos • Gestión de procesos • Sistemas de archivos • Gestión de memoria

30. Comunicación en sistemas distribuidos • La comunicación de procesos es fundamental en cualquier sistema distribuido • Existen diferentes posibilidades todas ellas basadas en el paso de mensajes • Mecanismos de bajo nivel, el programador debe preocuparse de establecer los protocolos de comunicación, representación de datos, etc. • Colas de mensajes • Sockets • Mecanismo de alto nivel, ofrecen abstracciones donde el programador no debe preocuparse de establecer protocolos • Llamadas a procedimientos remotos • Invocación de métodos remotos (entornos orientados a objetos)

31. Comunicación cliente-sevidor • Muy utilizada en entornos distribuidos (más del 90% de los sistemas distribuidos utilizan la arquitectura cliente-servidor) • Protocolo típico: petición-respuesta

32. Comunicación de grupos • Utiliza mensajes multicast • Útil para: • Ofrecer tolerancia a fallos basado en servicios replicados • Localizar objetos en sistemas distribuidos • Mejor rendimiento mediante datos replicados • Actualizaciones múltiples • Operaciones colectivas en cálculo paralelo

33. Sockets • Aparecieron en 1981 en UNIX BSD 4.2 • Intento de incluir TCP/IP en UNIX • Diseño independiente del protocolo de comunicación • Un socket es punto final de comunicación (dirección IP y puerto) • Abstracción que: • Ofrece interfaz de acceso a los servicios de red en el nivel de transporte • Protocolo TCP • Protocolo UDP • Representa un extremo de una comunicación bidireccional con una dirección asociada

34. Sockets: introducción • Sujetos a proceso de estandarización dentro de POSIX (POSIX 1003.1g) • Actualmente • Disponibles en casi todos los sistemas UNIX • En prácticamente todos los sistemas operativos • WinSock: API de sockets de Windows • En Java como clase nativa

35. Sockets UNIX • Dominios de comunicación • Tipos de sockets • Direcciones de sockets • Creación de un socket • Asignación de direcciones • Solicitud de conexión • Preparar para aceptar conexiones • Aceptar una conexión • Transferencia de datos

36. Dominios de comunicación • Un dominio representa una familia de protocolos • Un socket está asociado a un dominio desde su creación • Sólo se pueden comunicar sockets del mismo dominio • Algunos ejemplos: • PF_UNIX (o PF_LOCAL): comunicación dentro de una máquina • PF_INET: comunicación usando protocolos TCP/IP • Los servicios de sockets son independientes del dominio

37. Tipos de sockets • Stream (SOCK_STREAM) • Orientado a conexión • Fiable, se asegura el orden de entrega de mensajes • No mantiene separación entre mensajes • Si PF_INET se corresponde con el protocolo TCP • Datagrama(SOCK_DGRAM) • Sin conexión • No fiable, no se asegura el orden en la entrega • Mantiene la separación entre mensajes • Si PF_INET se corresponde con el protocolo UDP • Raw (SOCK_RAW) • Permite el acceso a los protocolos internos como IP

38. Direcciones de sockets • Cada socket debe tener asignada una dirección única • Las direcciones se usan para: • Asignar una dirección local a un socket (bind) • Especificar una dirección remota (connect o sendto) • Dependientes del dominio • Se utiliza la estructura genérica struct sockaddr • Cada dominio usa una estructura específica • Direcciones en PF_UNIX (struct sockaddr_un) • Nombre de fichero • Direcciones en PF_UNIX (struct sockaddr_in) • Uso de conversión de tipos (casting) en las llamadas

39. Direcciones de sockets en PF_INET • Host (32 bits) + puerto (16 bits) • Una dirección IP se almacena en una estructura de tipo: • struct in_addr • Estructura struct sockaddr_in • Debe iniciarse a 0 • sin_family: dominio (AF_INET) • sin_port: puerto • sin_addr: dirección del host • Función que facilita el nombre de la máquina en la que se ejecuta: int gethostname(char *name, int namelen);

40. Obtención de la dirección de host • Usuarios manejan direcciones en forma de texto: • decimal-punto: 138.100.8.100 • dominio-punto: laurel.datsi.fi.upm.es • Algunas funciones para trabajar con direcciones: • char *inet_ntoa(struct in_addr in); • Devuelve una dirección en notación decimal-punto. • struct hostent *gethostbyname(char *str); • Convierte una dirección en notación dominio-punto a una estructura que describe máquina. • Algunos campos de la estructura struct hostent: • char *name nombre oficial de la máquina • char **h_addr_list lista de direcciones

41. Ejemplo • Programa que obtiene la dirección en formato decimal-punto a partir de un formato dominio-punto. void main(int argc, char **argv) { struct hostent *hp; struct in_addr in; hp = gethostbyname(argv[1]); if (hp == NULL) { printf(“Error en gethostbyname\n”); exit(0); } memcpy(&in.s_addr,*(hp->h_addr_list),sizeof(in.s_addr)); printf(“%s es %s\n”, hp->h_name, inet_ntoa(in)); }

42. Direcciones de sockets II • En TCP/IP los números se emplean con formato big-endian. • En computadores que no utilicen este formato es necesario emplear funciones para traducir números entre el formato que utiliza TCP/IP y el empleado por el propio computador: u_long htonl (u_long hostlong)u_short htons (u_short hostshort)u_long ntohl (u_long netlong)u_short ntohs (u_short netshort) • Las primera traduce un número de 32 bits representado en el formato del computador al formato de red (TCP/IP).

43. Creación de un socket • int socket(int dominio, int tipo, int protocolo) • Crea un socket devolviendo un descriptor de fichero • dominio: PF_XXX • tipo: SOCK_XXX • protocolo: dependiente del dominio y tipo • 0 elige el más adeucado • Especificados en /etc/protocols • El socket creado no tiene dirección asignada

44. Asignación de direcciones • int bind(int sd, struct sockaddr *dir, int long) • sd: descriptor devuelto por socket • dir: dirección a asignar • long: longitud de la dirección • Si no se asigna dirección (típico en clientes) • Se le asigna automáticamente (puerto efímero) en la su primera utilización (connect o sendto) • Direcciones en dominio PF_INET • Puertos en rango 0..65535. Reservados: 0..1023. Si 0, el sistema elige uno • Host: una dirección local IP • INNADDR_ANY: elige cualquiera de la máquina • El espacio de puertos para streams y datagramas es indendiente

45. Solicitud de conexión • Realizada en el cliente • int connect(int sd, struct sockaddr *dir, int long) • sd: descriptor devuelto por socket • dir: dirección del socket remoto • long: longitud de la dirección • Si el socket no tiene dirección asignada, se le asigna una automáticamente • Normalmente se usa con streams

46. Preparar para aceptar conexiones • Realizada en el servidor stream después de socket y bind • int listen(int sd, int baklog) • sd: descriptor devuelto por socket • backlog: • Número máximo de peticiones pendientes de aceptar que se encolarán (algunos manuales recomiendan 5) • Hace que el socket quede preparado para aceptar conexiones.

47. Aceptar una conexión • Realizada en el servidor stream después de socket, bind y listen • Cuando se produce la conexión, el servidor obtiene: • La dirección del socket del cliente • Un nuevo descriptor que queda conectado al socket del cliente • Después de la conexión quedan activos dos sockets en el servidor: • El original para aceptar nuevas conexiones • El nuevo para enviar/recibir datos por la conexión

48. Aceptar una conexión • int accept(int sd, struct sockaddr *dir, int *long) • sd: descriptor devuelto por socket • dir: dirección del socket del cliente devuelta • long: parámetor valor-resultado • Antes de la llamada: tamaño de dir • Después de la llamada: tamaño de la dirección del cliente que se devuelve.

49. Obtener la dirección de un socket • Obtener la dirección a partir del descriptor • int getsockname(int sd, struct sockaddr *dir, int *long) • sd: descriptor devuelto por socket • dir: dirección del socket devuelta • long: parámetro valor-resultado (igual que en accept) • Obtener la dirección del socket en el toro extremo de la conexión: • int gerpeername(int sd, struct sockaddr *dir, int *long) • sd: descriptor devuelto por socket • dir: dirección del socket remoto • long: parámetro valor-resultado

50. Transferencia de datos con streams • Una vez realizada la conexión, ambos extremos puede transferir datos. • Envío: • int write(int sd, char *mem, int long); • Devuelve el nº de bytes enviados • También puede utilizarse el servicio send. • Recepción: • int read(int sd, char *mem, int long); • Devuelve el nº de bytes recibidos • También puede utilizarse el servicio recv • Es importante comprobar siempre el valor que devuelven estas llamadas: pueden no transferirse todos los datos.