Ubicua de computación n distribuida

Texto completo

(1)Universidad Simón Bolívar Departamento de Computación y T.I Sistemas de operación III CI-4822. Computación. Ubicua. Una nueva técnica de computación distribuida. Prof. Yudith Cardinale y Mariela Curiel Abr - Jul 2006.

(2) Contenido Conceptos de GRIDS. Qué ofrecen? Desafíos Razones que motivaron la creación de GRIDS Posibles aplicaciones Tipos de usuarios y su descripción Arquitectura Peer to peer computing Ejemplos.

(3) Computación Ubicua ¿Dónde aplica el concepto de ubicuidad? Se ofrece la misma imagen o entorno desde cualquiera de los lugares de trabajo (la misma interfaz “está en todas partes”) Los procesos se ejecutan en alguna plataforma elegida por el sistema (el hardware “está en todas partes”). ¿Se puede hablar de subclases de Sistemas Distribuidos? Proponemos dos subclases, Grids Computacionales y Sistemas P2P: No necesariamente disjuntas Sistemas conformados por sistemas.

(4) Computación Ubicua Grids Computacionales: se presupone que hay control sobre el acceso a los servidores. Rendimiento Transparencia Tolerancia a fallas Seguridad. Sistemas P2P: se presupone que los nodos participantes no tienen control sobre el acceso a los mismos. Cooperación Independencia de localidad Rodeo de controles Anonimato.

(5) Grid Computacional: qué es? Otros términos usados: Metasistemas, Metacomputación, Sistemas de Metacomputación Infraestructura de hardware y software que provee alto desempeño y alta disponibilidad.

(6) Metasistema. IBM Compatible. Workstation. Laptop computer. Token-ring. Laptop. Computer. Red. IBM Compatible Ethernet. Laptop computer. Mac II. Laptop computer. Metasistema.

(7) Grid Computacional: qué es? Ambientes que integran, a través de redes de alta velocidad recursos heterogéneos complejos tales como: supercomputadores, grandes bases de datos, etc. Mecanismo para que los usuarios puedan usar recursos distribuidos geográficamente de forma transparente, creando la ilusión de un sistema de computación integrado. Esta ilusión la provee el middleware..

(8) Grid Computacional: qué es? Los GRIDS hacen posible el compartir recursos, en forma coordinada, dentro de organizaciones dinámicas e interinstitucionales (organizaciones virtuales). La infraestructura debe proveer alto desempeño y alta disponibilidad.

(9) Grids y SD Como un SD los grids computacionales deben integrar recursos de capacidades variadas, conectados por redes no confiables, localizadas en dominios administrativos distintos. No obstante, la necesidad de alto rendimiento puede requerir de modelos de programación e interfaces radicalmente diferentes..

(10) Grids Computacionales: qué ofrecen? Colaboración más efectiva, agrupando coinvestigadores en el mismo espacio virtual. Incremento de la capacidad de cómputo local. Productividad mejorada a través de un ambiente de programación considerablemente más simple..

(11) Grids Computacionales: qué ofrecen? Ahorro, los recursos en cuestión pueden ser muy costosos. Espacio de objetos (Archivos) persistentes compartido. Ejecución remota transparente. Meta-aplicaciones.

(12) Desafíos Escalabilidad: la idea es que soporten cientos, miles e incluso millones de máquinas. Estas máquinas se conectan a través de Internet (alta latencia y bajo throughput) Facilidad de Uso: debe ser fácil agregar una nueva máquina al conjunto. Facilidad del desarrollo de aplicaciones. Tiempos de Ejecución: Problemas que toman tiempo en resolverse (horas meses o años); hacen falta mecanismos de checkpoiting para asegurar que se pierda la mínima cantidad de trabajo en caso de fallas..

(13) Desafíos Paralelismo Adaptativo: el conjunto de máquinas crece y decrece durante la ejecución de una aplicación. El metasistema debe ser capaz de reasignar trabajos. Heterogeneidad: involucra múltiples arquitecturas. Seguridad: No existe un administrador único para manejar todos los nodos participantes. Los oferentes necesitan garantías de que no se permitirán accesos no autorizados a sus máquinas. Disponibilidad y alto rendimiento.

(14) Razones que motivaron su creación Los datos presentan un gran desafío: Los detectores del Laboratorio Europeo de Partículas Físicas, producirán para el año 2005 varios petabytes de datos por año, un millon de veces la capacidad de un computador de escritorio promedio. Analizar estos datos pudiera requerir de alrededor de 20 teraflops/seg de poder computacional. Hoy en día el supercomputador más rápido ofrece 3 teraflops/seg..

(15) Razones que motivaron su creación Supercomputadores Clusters Surgen en 1980 Los más rápidos son 8000 procesadores (ASCI White System) en el laboratorio nacional Lawrence Levermore. Ofrecen una mejora considerable en poder de cómputo, pero es un conjunto de computadores dedicados, ubicados en un solo lugar. Existen razones financieras y técnicas que imponen límites a cúan grandes deben ser estos sistemas..

(16) Razones que motivaron su creación Clusters El sistema ASCI White costó 110 millones de dolares y necesitó de un nuevo edificio.. Computación en Internet Existen alrededor de 400 millones de PC´s en el mundo, muchas tan poderosas como los supercomputadores de los 90. La mayoría de estos PC´s tienen mucho tiempo ocioso..

(17) Razones que motivaron su creación Computación en Internet La computación en Internet busca explotar los ciclos ociosos de workstations y PC´s de modo de crear un sistema poderoso de computación distribuida. En 1985 Miron Livny mostró que la mayoría de las estaciones de trabajo permanecian ociosas y propuso el sistema Condor para utilizar ciclos libres de CPU. Es efectivo a pequeña escala: Universidades..

(18) Razones que motivaron su creación Computación en Internet En 1997 apareció Entropía (Scott Kurowski). Usa ciclos ociosos de computadores, alrededor del mundo, para resolver problemas de interés científico. En 2 años creció hasta llegar a 30000 computadoras que proveen una rapidez de cómputo por encima de un teraflop/seg. Usando este sistema se identificó el número primo más grande hasta ahora conocido..

(19) Razones que motivaron su creación Computación en Internet El próximo paso lo representa David Anderson con su proyecto SETI@home. Los ciclos ociosos se utilizan para analizar datos del telescopio de ARECIBO buscando signos que indiquen la presencia de inteligencia extraterrestre. Abarca alrededor del millon de PC´s..

(20) Razones que motivaron su creación Computational GRIDS [Foster y Kesselman, 1998]: La computación en Internet es sólo un caso especial de algo mucho más poderoso: la necesidad de distintas organizaciones (ambito científico) que buscan metas comunes de compartir recursos. El web y el correo electrónico ofrecen mecanismos básicos que permiten a estos grupos trabajar juntos. Lo ideal es agrupar datos, computadores, sensores y otros recursos en un único laboratorio virtual..

(21) Razones que motivaron su creación Computational GRIDS La tecnología GRID persigue este propósito, ofreciendo protocolos, servicios y kits para el desarrollo de software, necesarios para crear un ambiente que permita compartir recursos a gran escala. Los primeros conceptos se exploraron en 1995 (experimento I-WAY): se usaron redes de alta velocidad para conectar 17 sites en Norteamerica. Hoy en día existen muchos proyectos de Investigación encargados de desarrollar las tecnologías para crear GRIDS en varias comunidades y disciplinas científicas..

(22) Aplicaciones Supercomputación distribuida: usan las GRIDS para agrupar recursos que permitan resolver problemas que no pueden ser resueltos por un solo computador. Ejemplos: simulación interactiva distribuida (entrenamiento y planificación militar), simulación de procesos físicos complejos (cosmología, modelamiento del clima,etc.).

(23) Aplicaciones High-Throughput computing: la idea es planificar un gran número de tareas independientes o débilmente acopladas (poca sincronización) para aprovechar ciclos de CPUs ociosos. La naturaleza independiente de las tareas conduce a diferentes métodos para resolver el problema. Ejem: Problemas de criptografía, se uso durante la etapa crucial en el diseño de los procesadores K6 y K7, CONDOR..

(24) Aplicaciones Computación por demanda: satisfacen requerimientos de recursos a corto plazo. Se trata de recursos a los que no se tiene acceso de manera local. Entre los recursos tenemos: BD, sensores, software, cómputo. Ejem: NEOS y NetSolve, envían a servidores remotos cálculos que necesitan mucho poder de cómputo o un software especializado..

(25) Aplicaciones Computación con un manejo intensivo de datos: sintetizan información a partir de datos en repositorios distribuidos, librerías digitales y bases de datos. El proceso de síntesis es intensivo desde el punto de vista computacional y comunicacional. Ejem: Experimentos Físicos, Fotografías Astronómicas..

(26) Aplicaciones Computación colaborativa: permite interacción hombre-hombre, generalmente las aplicaciones están estructuradas en términos de un espacio virtual compartido..

(27) Usuarios Usuarios finales Desarrolladores de aplicaciones Desarrolladores de herramientas Desarrolladores del metasistema Administradores del sistema.

(28) Usuarios Desarrolladores: Propósito: diseñar e implementar los servicios básicos (protocolo del metasistema). Usan los servicios de los sistemas locales. Se preocupan por la simplicidad local, la conectividad y la seguridad..

(29) Usuarios Desarrolladores de herramientas: Propósito: implementar herramientas, compiladores, librerías, etc. que implementan los modelos de programación y servicios usados por los desarrolladores de aplicaciones. Usan los servicios del metasistema Se preocupan por la adaptabilidad, el desempeño y la seguridad.

(30) Usuarios Desarrolladores de herramientas: Ejem: Netsolve, MPI Los desarrolladores de herramientas deben usar los servicios básicos para programar implementaciones eficientes de modelos de programación que utilizarán los programadores de aplicaciones..

(31) Usuarios Desarrolladores de herramientas: Modelos de programación secuenciales: proveen abstracciones como subrutinas Modelos de programación paralelo: threads, variables de condición, pase de mensajes, etc. No hay consenso sobre cuál sería el modelo de programación apropiado en GRID: Shared memory, message passing, RPC, orientación por objeto, agentes..

(32) Usuarios Desarrolladores de aplicaciones: Propósito: desarrollar aplicaciones. Usan los modelos de programación (tanto secuencial como paralelo) y las herramientas Se preocupan por la facilidad de uso y el desempeño..

(33) Usuarios Usuarios finales: Propósito: resolver problemas Usan las aplicaciones (paquetes), que a su vez usan los recursos y servicios del GRID. Les importa la transparencia y el desempeño..

(34) Usuarios Administradores del sistema: Propósito: administrar los recursos del metasistema (administración distribuida) Entre los problemas que encuentran se tienen: manejar comunidades de usuarios, lograr un equilibrio entre las políticas locales y las necesidades del metasistema..

(35) Usuarios Administradores del sistema: Usan herramientas de administración. Surgen nuevas actividades tales como: monitoreo; establecer políticas en situaciones donde el conjunto de usuarios puede ser muy largo variando en forma dinámica; negociar políticas con otros sites y usuarios, mecanismos de accounting y pago, etc..

(36) Arquitectura Application Collective Resource Connectivity Fabric.

(37) Arquitectura Fabric (estructura, cimientos): Interfaces para el control local. En este nivel están los recursos de acceso compartido: recursos de cómputo, de almacenamiento, de red, BD, sensores, etc. Un recurso puede ser una entidad lógica (un FS distribuido, un cluster de computadoras) o física. Este nivel implementa operaciones sobre recursos específicos. Dichas operaciones son el resultado de operaciones, para compartir recursos, que se invocan en niveles más altos..

(38) Arquitectura Fabric (estructura, cimientos): Interfaces para el control local.  Deben implementar como mínimo dos tipos de mecanismos: – Consulta: permiten descubrir la estructura del recurso, su estado y capacidades (por ejemplo si pueden reservarse) – Gestión del recurso: resto de operaciones que se pueden realizar sobre c/recurso en particular..

(39) Arquitectura Fabric (estructura, cimientos): Interfaces para el control local.  Recursos de Cómputo: – Consulta: características de hw y sw, carga. actual, estado de la cola de procesos, etc. – Gestión: Iniciar programas, monitorear y controlar la ejecución de los procesos, mecanismos de reservación..

(40) Arquitectura Fabric (estructura, cimientos): Interfaces para el control local.  Recursos de Almacenamiento: – Gestión: recuperar e introducir archivos, leer yo escribir partes del archivo, controlar la cantidad del recurso que es asignado a los datos (espacio, ancho de banda de la red, etc). – Consulta: determinar las características de hw y sw, información relevante sobre la carga: espacio en disco disponible, utilización del ancho de banda, etc..

(41) Arquitectura Fabric (estructura, cimientos): Interfaces para el control local.  Recursos de Red: – Gestión: proveen control sobre los recursos asignados a las transferencias a través de la red (establecer prioridades, reservar, etc.) – Consulta: características de la red y carga..

(42) Arquitectura . Connectivity: define los protocolos de comunicación y autenticación que se requieren para las transacciones a través de la red.. Application Collective Resource Connectivity Fabric.

(43) Arquitectura Connectivity Protocolos de comunicación: facilitan el intercambio de los datos entre los recursos del nivel de estructura. Protocolos de autenticación: proveen mecanismos seguros para verificar la identidad de los usuarios y los recursos..

(44) Arquitectura Connectivity Protocolos de comunicación: deben manejar transporte, routing, naming. Las alternativas existentes son utiles, pero no se descarta la creación de protocolos en el futuro que se adapten mejor a la dinámica de la red. Entre las alternativas existentes tenemos: IP (Internet), TPC y UDP (transporte), DNS (Aplicación), etc..

(45) Arquitectura Connectivity Protocolos que se encargan de la seguridad: muchos de los estándares existentes son de utilidad, no obstante se requieren de nuevas soluciones con las siguientes características: – Single sign on: Los usuarios deberían ¨hacer log on¨. una sola vez y luego tener acceso, sin intervenciones adicionales, a los múltiples recursos del GRID definidos en el nivel de estructura..

(46) Arquitectura Connectivity – Delegación: un usuario debe ser capaz de dotar. a un programa con derechos para que se ejecute en su nombre. El programa estará así en capacidad de utilizar recursos sobre los cuales el usuario tiene acceso autorizado. Opcionalmente, el programa podría delegar un subconjunto de tales derechos a otro programa..

(47) Arquitectura Connectivity – Integración con varias soluciones locales de seguridad:. Cada site o proveedor de recursos debe tener sus soluciones de seguridad local (kerberos, Unix). Las soluciones del GRID deben ser capaces de interoperar con estas soluciones. – Relaciones basadas en la confianza: Si un usuario va a necesitar recursos de múltiples proveedores, el sistema de seguridad no debe exigir la interacción o cooperación de tales proveedores para configurar el sistema de seguridad..

(48) Arquitectura Resource: Manejo de recursos en forma individual. Se apoya en los protocolos del nivel anterior para definir protocolos (y APIs y SDKs) que permiten la negociación segura, el monitoreo, control, contabilidad y pago de sharing operations. Ofrece operaciones sobre recursos en forma individual.. Application Collective Resource Connectivity Fabric.

(49) Arquitectura Resource Invocan operaciones del nivel de estructura para acceder y controlar recursos en forma individual. Las operaciones de este nivel están relacionadas con recursos de forma individual; ignoran aspectos tales como: estados globales, acciones atómicas, etc. El uso de los recursos como grupos forma parte del nivel Collective..

(50) Arquitectura Resource Se distinguen dos clases de protocolos: Protocolos de Información: se usan para obtener la estructura y el estado de los recursos. Ejem: configuración, carga, política de uso. Protocolos de Gestión: permiten negociar el acceso a un recurso compartido especificando: – Requerimientos especiales: QoS, reservación – Las operaciones que serán efectuadas: creación de. procesos, acceso a los datos, etc..

(51) Arquitectura Resource Los protocolos de gestión deben garantizar que se cumplan las políticas bajo las cuales se comparten los recursos (las operaciones que se efectuan sobre los recursos deben ser consistentes con tales políticas). Se deben considerar aspectos de contabilidad, pago, monitorear el status de una operación, etc..

(52) Arquitectura Resource Los protocolos deben ofrecer al menos la misma funcionalidad que se ofrece en el nivel de estructura. A la lista de funcionalidades se agrega la semántica de ¨al menos una vez¨ para muchas operaciones, con un reporte de errores que indique cuando fallan las operaciones..

(53) Arquitectura . Collective: define los protocolos, APIs y SDKs, que no están asociados con ningún recurso en particular sino que son de naturaleza global y capturan las interacciones entre conjuntos de recursos.. Application Collective Resource Connectivity Fabric.

(54) Arquitectura Collective Implementan una amplia gama de sharing behaviors sin colocar requerimientos adicionales en los recursos que se comparten. Entre los servicios que se implementan se tienen: Servicios de directorio Co-asignación, scheduling, brokering services. Monitoreo y diagnóstico.

(55) Arquitectura Collective Replicación de datos Modelos de Programación Software Discovery Community authorization servers Contabilidad y pago Servicios de colaboración.

(56) Arquitectura Collective Servicios de directorio: permiten a los participantes de la VO descubrir la existencia y/o propiedades de los recursos. Co-asignación, scheduling, ruptura (brokering services): permiten a los participantes solicitar uno o varios recursos para un propósito específico. Permiten la planificación de tareas en recursos adecuados. (AppleS, Condor-G) Monitoreo y diagnóstico para detectar fallas, sobrecarga, ataques de seguridad, etc..

(57) Arquitectura Collective Replicación de datos: se encargan de la administración réplicas para mejorar el desempeño y la confiabilidad. Modelos de Programación. Software Discovery: descubren y seleccionan la mejor implementación de software y la mejor plataforma de ejecución para el problema que se resuelve (Netsolve, Ninf).

(58) Arquitectura Collective Community authorization servers: hacen cumplir las políticas que gobiernan el acceso a los recursos. Contabilidad y pago: recogen información sobre el uso de recursos para propósitos de contabilidad, pagos y/o colocar límites en el uso de recursos. Servicios de colaboración: soportan el intercambio de información dentro de potencialmente grandes comunidades de usuarios, ya sea de forma síncrona o asíncrona..

(59) Arquitectura Collective Los componentes o servicios de este nivel se pueden adaptar a los requerimientos de una comunidad de usuarios específica o dominio de aplicación. También se pueden implementar servicios de un propósito más general.

(60) Arquitectura Aplicaciones Se trata de las aplicaciones propias de las organizaciones virtuales. Se construyen invocando servicios de los niveles inferiores. Application Collective Resource Connectivity Fabric.

(61) Grids y Sistemas Distribuidos convencionales A2 A1. A2. A4. A1. A3. Nivel de máquina virtual Nivel de pool virtual. Nivel físico. A4 A3.

(62) Tipos de Grid Grids de cómputo. Grids de datos. Acceso compartido a sistemas de computación de alto rendimiento. Grids de servicio. Acceso compartido a software y otros Acceso compartido recursos a bases de datos computacionales y sistemas de archivos.

(63) PeertoPeer computing: Cómputo intensivo descentralizado. Sistemas y aplicaciones que emplean recursos distribuidos para realizar funciones críticas de manera descentralizada Cómputo distribuido Almacenamiento y compartimiento de datos (intercambio de archivos) Comunicación y colaboración para crear software Conversación directa en línea Servicios en plataformas heterogéneas.

(64) PeertoPeer computing: Se presupone que los nodos participantes no tienen control sobre el acceso a los mismos. Qué ofrecen: Cooperación Independencia de localidad Rodeo de controles Anonimato.

(65) PeertoPeer computing: Ejemplos de sistemas Sistemas para cómputo distribuido: Proyecto académico para búsqueda de señales provenientes de otros mundos. MAGI. Producto para aplicaciones de negocios colaborativos (comercio basado en p2p) e incorpora múltiples tipos de dispositivos entre peers (PDAs, celulares, chips especializados, comunicación basada en eventos) Proyecto de software abierto que provee servicios para p2p: encontrar peers, compartir archivos, encontrar contenido en sitios remotos, crear un grupo de peers, monitorear actividades y comunicación segura..

(66) PeertoPeer computing: Ejemplos de sistemas Sistemas para comunicación:. groove. Provee espacios virtuales compartidos para la interacción de pequeños grupos. Los usuarios que comparten un espacio pueden “chatear”, comunicarse por voz, enviar mensajes instantáneos, actualizar un calendario o plan de eventos, compartir un archivo, etc. Sistemas para compartir información:. Intercambio de música mp3. Creció considerablemente a punto de que fueron demandados por compañías editoras de discos... y perdieron. Servidor centralizado para mantenimiento de información de ubicación El intercambio de información se hace directamente entre clientes.

(67) PeertoPeer computing: Ejemplos de sistemas. Sistemas para compartir información: (cont.) Intercambio de archivos, principalmente mp3. Incluyeron secretamente un módulo de cómputo, hecho por Brilliant Digital para hacer cómputo distribuido.. Compartimiento, búsqueda y copiado de archivos entre usuarios en Internet en forma descentralizada Los clientes son servidores al mismo tiempo. Aprende sobre los nodos conectados al vecino Descubrimiento de la red (ping y pong).

(68) Modelo Cliente/Servidor Los clientes se comunican con el servidor Pueden comunicarse entre sí a través del servidor.

(69) Modelo P2P (punto- a- punto) Los clientes se comunican directamente Pueden consultar previamente a un servidor con propósitos de localización.

(70) Variantes de P2P Control central (ej. Napster). Distribuido (ej. Gnutella).

(71) Espacio de Aplicaciones P2P Las aplicaciones P2P se pueden definir en tres ejes principales: – Descentralización: puede haber un control centralizado. (seti) o ser completamente independiente de un servidor central (freenet) – Cooperación: puede no haber comunicación entre pares (seti), basarse en la cooperación continua entre pares (freenet) o un esquema intermedio (napster) – Indirección: puede haber cooperación P2P directamente entre máquinas cliente (napster) o indirectamente, entre servidores (almacenamiento distribuido).

(72) Consideraciones Interoperabilidad Protocolos Formato de datos. Seguridad Confidencialidad Presencia de cortafuegos, NAT, etc.. Descentralización Independencia del DNS Compartir recursos sin intermediación. Identificación Nombres para los “peers”.

(73) Interoperabilidad: protocolos  Hay. muchos de ellos, ejemplos:. – HTTP (Hypertext Transfer Protocol): protocolo para – – – –. solicitud de información, usado en el Web SOAP (Simple Object Access Protocol): protocolo para invocar código usando XML sobre HTTP GIOP (General Inter ORB Protocol): protocolo utilizado en CORBA para comunicar ORBs RTP (Real- Time Transport Protocol): protocolo para intercambio de datos a tiempo real, como video y audio Gnutella Protocol: descubrimiento usado por Gnutella.

(74) Interoperabilidad: datos HTML: conjunto de etiquetas y reglas para definir documentos de hipertexto XML: conjunto de reglas para definir formatos de datos estructurados Java bytecode: se pueden ejecutar applets en casi cualquier plataforma ¿DOC?: estamos hasta la coronilla de que nos envíen documentos en formato DOC.

(75) Seguridad: autenticación y confidencialidad SSL (Secure Socket Layer): protocolo para establecer conexiones de sockets seguras HTTPS: simplemente HTTP sobre SSL PKI (Public Key Infrastructure): sistema de cifrado de clave pública que se apoya en certificados digitales SSH (Secure Shell): programa para utilizar un shell en un computador remoto y para hacer túneles seguros.

(76) Seguridad: cortafuegos y NAT – El modelo cliente-servidor ha dado origen a mecanismos. que permiten la conexión “hacia afuera” a todos pero limitan la conexión “hacia adentro” – NAT Se origina por la carencia de direcciones IP Impide el acceso a máquinas internas, a menos que haya NAT hacia adentro. – Cortafuegos Se origina por la necesidad de protegerse de ataques Intencionalmente se evita el acceso a máquinas internas, con excepción de ciertos servicios – Se necesitan mecanismos de conexión a servicios que. utilicen la conexión TCP hacia afuera.

(77) Descentralización: independencia del DNS – Los servicios de acceso a Internet (por discado o por. – – – –. conexión de banda ancha) en general no incluyen un nombre DNS De hecho, los servicios de acceso a internet suelen asignar números IP que cambian continuamente Hay servicios de DNS dinámico (solución parcial) Se necesitan mecanismos de identificación (naming) alternativos, que no se basen en la asociación DNS- IP Para asociar un nombre con un destino (IP, Puerto) hace falta  . Servidor de nombres Mecanismo de descubrimiento.

(78) Descentralización: participar sin intermediación No necesariamente se cuenta con servidores con DNS oficial Posibilidad: establecer redes que se tejen extendiendo las conexiones con vecinos Se necesitan protocolos de descubrimiento, tanto de nodos como de otros objetos (archivos) Se puede tejer una red de servidores de nombres alternativa al DNS.

(79)