Sistemas Distribuidos
Sesión 1 – Introducción a los Sistemas Distribuidos
Diego Sevilla Ruiz
DITEC Facultad de Informática
Índice
Sistemas Distribuidos: Introducción y Conceptos Sistemas Distribuidos: Arquitecturas
Sistemas Cloud
Sistemas Operativos Distribuidos
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 aboertos, protocolos estándar (HTTP) homogeneización de datos y procesamiento, Map/Reduce, paralelismo funcional, automático, REST, etc.
Sistemas Distribuidos: Retos
Heterogeneidad Redes Hardware Sistemas Operativos Middleware Extensibilidad Seguridad Escalabilidad Tratamiento de Fallos Concurrencia TransparenciaSistemas 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 (ii)
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
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
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 dehash, etc.
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ónProxy) Redundancia y votado
Disponibilidad
Idempotentibilidad
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 sólo 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
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
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 (ii)
Servicios básicos por parte del Sistema Operativo Direccionamiento
Sockets
Arquitecturas – Internet/World Wide Web/CGI
Nivel 1 HTTP Internet TCP/IP HTTP Nivel 2 Nivel 3 P´aginas HTML Prog. CGI Servidor HTTP Browser SGBD Servidor SMTPArquitecturas – Internet/World Wide Web/CGI (ii)
Sockets
API de bajo nivel ¿Gestión de errores?
No hay tipos de datos... ¿comprobación? Protocolo CGIad-hoc
Stateless (salvo con otros hackscomo los cookies)
El servidor no da soporte para persistencia (bases de datos), transacciones, seguridad, gestión de usuarios, etc.
Lasaplicacionestienen que implementarTODO, o usarframeworks etc.
Arquitecturas – 2 y 3 niveles
Cliente
Presentaci´on L´ogica del negocio
Acceso a datos Servidor Servidores BD Sistemas Legacy etc. Nivel 1 Nivel 2 Cliente Presentaci´on
L´ogica del negocio Acceso a datos
Servidor
Servidores BD Sistemas Legacy
etc.
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.)
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
Objetos Distribuidos: CORBA/RMI
Muy parecido a RPC, pero basado en objetos El middleware ahora toma más importanciaMessage-Oriented Middleware
Síncrono/asíncrono
Normalmente Suscripción/Respuesta Documentos XML ⇒ Mensajes Loose Coupling
D-Bus (ii)
1 M e s s a g e m e s s a g e = new M e s s a g e (" / r e m o t e / o b j e c t / p a t h ", " M e t h o d N a m e ", arg1 , a r g 2 ) ; 3 C o n n e c t i o n c o n n e c t i o n = g e t B u s C o n n e c t i o n () ; c o n n e c t i o n . s e n d ( m e s s a g e ) ; 5 M e s s a g e r e p l y = c o n n e c t i o n . w a i t F o r R e p l y ( m e s s a g e ) ; if ( r e p l y . i s E r r o r () ) { 7 // ... } e l s e { 9 O b j e c t r e t u r n V a l u e = r e p l y . g e t R e t u r n V a l u e () ; }D-Bus (iii)
$ dbus - m o n i t o r 2 m e t h o d ca l l s e n d e r = : 1 . 7 5 1 - > d e s t = org . g n o m e . G C o n f s e r i a l =2 p a t h =/ org / g n o m e / G C o n f ; i n t e r f a c e = org . g n o m e . G C o n f ; m e m b e r = G e t I O R m e t h o d r e t u r n s e n d e r = : 1 . 4 - > d e s t = : 1 . 7 5 1 r e p l y _ s e r i a l =2 4 s t r i n g " IOR : 0 1 . . . " s i g n a l s e n d e r = org . f r e e d e s k t o p . D B u s - > d e s t =( nu l l d e s t i n a t i o n ) s e r i a l = 1 2 1 8 p a t h =/ org / f r e e d e s k t o p / D B u s ; i n t e r f a c e = org . f r e e d e s k t o p . D B u s ; m e m b e r = N a m e O w n e r C h a n g e d 6 s t r i n g " : 1 . 7 5 1 " s t r i n g " : 1 . 7 5 1 "Peer to Peer
Modelo más descentralizado: todos aportan por igual o en la medida de sus posibilidades
Web Services/SOA
Todo se hace accesible a través de servicios (web) Protocolos «estándar»: HTTP, XML, SOAP, WSDL ¿Qué pasa con los callbacks?
REST (ii)
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 incluyenmetadatos(cache, validez, MIME). Incluidos en losheadersde HTTP
Los metadatos permiten tratar el mensaje
Tejido hypermedia como representación del estado de la aplicación (HATEOAS)
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.
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
Sistemas Operativos Distribuidos
Sistemas Distribuidosversus Sistemas Operativos Distribuidos? Polémica hace unos años
Principales diferencias:
Heterogeneidad (hw, so., etc.)
Sistema débilmente acoplado vs. Sistema fuertemente acoplado Inmaduros en su comienzo
Ahora sería el momento de avanzar en la dirección GNU/Hurd
CODA
Introducción a los Patrones y Herramientas
Patrones
Solución dada reiteradamente a un problema común «Best practices»
Suben el nivel de abstracción, tratan problemas en abstracto En programación distribuida ⇒ poca experiencia
Los utilizaremos para aprender sobre cómo construir mejores aplicaciones distribuidas
Elementos:
Nombre, Contexto, Problema, Cuestiones relevantes, Solución
Lenguaje de Patrones: Conjunto de patrones relacionados que sirven para un fin común (POSA2)
Introducción a los Patrones y Herramientas (ii)
Idioms
Patrones, pero de más bajo nivel
Asociados a un lenguaje, normalmente C++ No por ello menos importantes
Importantísimos por ejemplo en elmappingde C++ a CORBA Ejemplo: «Scoped Locking»
C++ Idioms: James O. Coplien
Introducción a los Patrones y Herramientas (iii)
Scoped Locking (POSA2, p. 325) (Resource Acquisition is Initialization)pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; int función(...) { pthread_mutex_lock(&mutex); if (condición) { // lo que sea pthread_mutex_unlock(&mutex); return 1; } pthread_mutex_unlock(&mutex); return 0; }
Introducción a los Patrones y Herramientas (iv)
Introducción a los Patrones y Herramientas (v)
Scoped Locking (cont.)
class SyncLock { public: SyncLock(pthread_mutex_t* m) { mutex_ = m; pthread_mutex_lock( mutex_ ); } ~SyncLock() { pthread_mutex_unlock( mutex_ ); } private: pthread_mutex_t* mutex_; }
