Tema 2: Caracterización de SSDD...Describiendo los patrones de composición Describiendo el middleware que forma el SD 18/01/2012 4 Sistemas distribuidos – Curso 2011-2012

18/01/2012

1

Tema 2: Caracterización de SSDD

Sistemas Distribuidos Marcos López Sanz [Curso 2011-2012]

Sistemas distribuidos – Curso 2011-2012 www.kybele.es

Índice

Caracterización de SSDD Modelos de SSDD

Modelos físicos Modelos de arquitecturas Modelos “fundamentales”

Modelo de interacción Modelo de fallos Modelo de seguridad

Paradigmas de SSDD Sistemas de computación distribuida Sistemas de información distribuida Sistemas distribuidos embebidos/ubicuos

Ejercicios Dudas

18/01/2012

2


Caracterización de SSDD

Formas complementarias de abordar el diseño de SSDD: Modelos físicos: capturan la estructura física de un SSDD

junto con las características de las redes que los interconectan

Modelos arquitectónicos: describen el sistema desde el punto de vista de las tareas realizadas por las entidades computacionales que lo forman

Modelos “fundamentales”: perspectiva abstracta. Centrados en definir aspectos concretos: Modelos de interacción: estructura y secuenciación de la

comunicación Modelos de fallos: centrado en qué puede fallar en un SD Modelos de seguridad: forma de proteger el sistema


Modelos físicos

Def.: Modelo físico: representación del HW que conforma un SD abstrayendo los componentes y redes utilizados Modelo “base”: aquél que define un SD como un conjunto de entidades

computacionales conectadas a través de una red y basado en el paso de mensajes

Sistemas “primitivos” (finales ‘70, principios ‘80): ~10 – 100 nodos interconectados a través de área local Conectividad limitada Tareas: compartir impresoras/ficheros o email y transferencia de ficheros

a través de la red Capacidades limitadas de: homogeneidad, openness, QoS…

Sistemas de Internet (década de los 90) Conjunto extensible de nodos unidos por la “red de redes” Gran número de nodos, variedad de servicios ofrecidos a organizaciones Heterogeneidad Proliferación de estándares y tecnologías de middleware (CORBA, WS) Servicios específicos para aspectos concretos (seguridad, QoS)

18/01/2012

3


Modelos físicos

Sistemas actuales (desde principios de los 2000):

Pasado: nodos estáticos (localizados), discretos (individuales) y autónomos (infraestructura propia)

Tendencia actual:

Computación móvil (localización?) servicios de descubrimiento

Computación ubicua (atomicidad?) nodos embebidos en objetos de uso cotidiano (lavadoras!)

Cloud computing/cluster computing servicios ofrecidos por varios nodos (frente a equipos autónomos)

Resultado: arquitectura heterogénea

Aparición de “sistemas de sistemas” (forecasting?)


Modelos arquitectónicos

Definición: Architecture is the fundamental organization of a

system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. [IEEE 1471]

Formas de definir la arquitectura de un SD: Describiendo los componentes (individuales)

Describiendo los patrones de composición

Describiendo el middleware que forma el SD

18/01/2012

4


Modelos arquitectónicos: Elementos arquitectónicos

Tipos de componentes en un SD:

1. Entidades computacionales que se comunican (qué)

2. Paradigmas de comunicación (cómo)

3. Responsabilidades en el SD (para qué)

4. Distribución sobre elementos físicos (dónde)



1. Entidades computacionales que se comunican: Desde el punto de vista del sistema: Nodos

Procesos

Desde el punto de vista de la programación: Objetos: “a computation consists of a number of interacting

objects representing natural units of decomposition for the given problem domain”

Componentes: “resemble objects in that they offer problem-oriented abstractions for building distributed systems and are also accessed through interfaces”

Web services: “a software application identified by a URI, whose interfaces and bindings are capable of being defined, described and discovered as XML artefacts” (W3C)

18/01/2012

5



2. Paradigma de comunicación (I): Comunicación interprocesos: comunicación al más bajo nivel

entre procesos Primitivas de paso de mensajes Programación basada en sockets (acceso a API de los protocolos de

Internet) Comunicación multicast

Invocación remota: técnicas basadas en el intercambio de mensajes en dos sentidos (conocimiento explícito) Protocolos “Request-Reply”: computación cliente-servidor

(soportado por HTTP) Llamadas a procedimientos remotos (RPC): la invocación ofrece

transparencia de acceso y localización Invocación remota de métodos (RMI): RPC en ambientes de

orientación a objetos. Identificación y parámetros

Comunicación indirecta: …



2. Paradigma de comunicación (II):

Comunicación indirecta: desacoplamiento de destinatario (space uncoupling) y desacoplamiento con respecto a cuándo existe cada uno (time uncoupling)

Comunicación en grupo: receptores “apuntados” a un grupo considerado como una entidad más a la que se envían los mensajes (mail lists)

Sistemas de publicación-subscripción: sistemas de eventos distribuidos (RSS)

Colas de mensajes: existencia de un recurso intermedio (cola)

Espacios de tuplas: recurso compartido de publicación/lectura (P2P inicial?)

Memoria compartida distribuida

18/01/2012

6



3. Roles y responsabilidades:

Estrategias basadas en la definición de entidades diferenciadas por su rol en el SD

2 estrategias:

Cliente-Servidor: interacción basada en la provisión de un servicio y la consumición del mismo después de una invocación

Peer-to-peer: interacción entre entidades equivalentes basada en la cooperación



4. Distribución de los elementos:

Importancia de la localización (implementación) y distribución de los recursos en nodos físicos

Estrategias:

Mapeado de recursos a múltiples servidores: especialización de servidores

Técnicas de caching: almacenamiento de datos usados recientemente

Código móvil: applets

Agentes móviles: SW ejecutable enviado al cliente sin petición explícita (push)

18/01/2012

7


Modelos arquitectónicos: Patrones arquitectónicos

Definición: “patterns [..] provide composite recurring structures that have been shown to work well in given circumstances”

Patrones:

Por capas (layers)

Por funcionalidades (tiers)

Basados en ‘thin clients’

Otros



División por capas (layers)

Un sistema complejo se divide en capas (como abstracción de software) cada una haciendo uso de la inmediatamente superior o inferior

Organización vertical en los elementos distribuidos en función de los elementos abstraídos

Capas más utilizadas en SSDD:

Aplicación / Servicio

Middleware

Plataforma (sist. operativo + HW de computación y red)

18/01/2012

8



División por responsabilidades (tiers)

Cada elemento del SD se atribuye una responsabilidad

Patrones típicos:

2 capas: cliente / servidor de aplicaciones y datos

3 capas: cliente / servidor de aplicaciones con la lógica de negocio / servidor gestor de datos

N-capas: balanceo / seguridad / replicación / …



‘Thin clients’: Idea: permitir el acceso a servicios muy complejos a través

de la red con poca carga derivada al cliente (ej.: Cloud)

Ventaja: clientes locales simples (ventana de usuario)

Desventaja: latencias inaceptables para tareas gráficas o de alta interactividad

Otros patrones: Proxy servers: intermediarios para soportar transparencia

de localización

Service brokering: servicios de búsqueda (UDDI), triángulo SOA

Mashups y otros: Buschman et al.

18/01/2012

9


Modelos arquitectónicos: Soluciones middleware

Objetivo: Proveer de una abstracción de programación de alto nivel para el desarrollo de

sistemas distribuidos y abstraer de la heterogeneidad subyacente para mejorar la interoperabilidad y la portabilidad

Categorías de middleware Objetos distribuidos:

Estándares: RM-ODP Plataformas: CORBA, Java RMI

Componentes distribuidos: Componentes ligeros: Fractal, OpenCOM Servidores de aplicaciones: Sun EJB, CORBA Component Model, Jboss

Sistemas publicación-subscripción: CORBA Event Service, Scribe, JMS Colas de mensajes: Websphere MQ, JMS Servicios web:

Servicios Web: Apache AXIS, IIS + .Net Framework Servicios Grid: Globus Toolkit

Peer-to-Peer: Enrutamiento encubierto: Pastry, Tapestry Aplicaciones específicas: Gnutella, Squirrel, OceanStore, Ivy


Modelos fundamentales

Aspectos compartidos por los modelos Basados en procesos comunicados por mensajes

Requisitos de diseño para conseguir rendimiento y fiabilidad dentro de unos grados de seguridad

Aspectos propios de los modelos fundamentales Interacción: entendida como comunicación (flujo de

información) y coordinación (sincronización de actividades)

Fallos: base para el análisis de los fallos de un SD y sus consecuencias

Seguridad: tipos de ataques y análisis de amenazas

18/01/2012

10


Modelos fundamentales: Modelo de interacción

Factores involucrados El rendimiento de las comunicaciones es un factor

limitante (latencias)

Es imposible mantener una noción global de tiempo

Aspectos considerados Rendimiento de los canales de comunicación

Relojes de computación y temporización de eventos

Variantes del modelo de interacción

Ordenación de eventos



Rendimiento de los canales de comunicación. Requisitos de rendimiento: Def.: latencia: retraso entre el inicio del envío de un

mensaje y el inicio de su recepción. Incluye El tiempo que se tarda en alcanzar el destino Retraso en el acceso a la red (CSMA/CA en Ethernet) Tiempo utilizado por el sistema operativo en comunicar

entre capas de procesos

Def.: Ancho de banda: cantidad de información que puede ser enviada por la red en un momento determinado

Def.: Jitter (variación de retardo): tiempo que ocurre entre el envío de varios mensajes consecutivos. Importancia en multimedia

18/01/2012

11



Relojes de computación y temporización de eventos

Cada nodo en un SD tiene su propio reloj interno

“Clock drift rate”: grado en el que un nodo se desvía de un tiempo “perfecto” de referencia



Variantes del modelo de interacción SSDD síncronos Tiempo para ejecutar un paso de un proceso tiene

límites superior e inferior

Cada mensaje transmitido a través de un canal se recibe en un intervalo de tiempo determinado

Cada nodo tiene un “clock drift rate” conocido dentro de un intervalo

SSDD asíncronos (Internet). Sin límites en: Velocidad de ejecución de los procesos

Retraso en la transmisión de mensajes

“Clock drift rate” arbitrario y variable

18/01/2012

12



Ordenación de eventos

Definición de un SD en función de los eventos producidos y su orden en vez de en función de la precisión de un reloj/tiempo

Uso de la idea de “tiempo lógico” (Lamport)


Modelos fundamentales: Modelo de fallos

Fallo: Desviación con respecto a lo que se considera como un

comportamiento correcto o esperado

Elementos que pueden fallar Procesos Canales de comunicaciones

Taxonomía simplificada de fallos Fallos de omisión Fallos arbitrarios Fallos de temporización (timing) Fallos por enmascaramiento Fiabilidad de la comunicación 1-a-1

18/01/2012

13



Fallos de omisión Omisión de procesos Fallo (crash): el proceso no continuará ejecutando Característica deseable: discretización del comportamiento (o está

funcionando o está parado) Fail-Stop: detección del fallo de un proceso por parte de otros

elementos del SD Fácil en SD síncronos: timeout = fallo Difícil (imposible?) en SD asíncronos

Omisión en las comunicaciones No se transporta el mensaje de ‘x’ a ‘y’ Pérdida de mensajes

• Del receptor (fallo de proceso) • Del emisor (fallo de proceso) • Del canal



Fallos arbitrarios (‘bizantinos’) Situación en la que se prevee el peor escenario

Situaciones habituales: Fallos en los procesos (‘procesos traidores’)

Fallos en los canales (incoherencias, omisión de mensajes o envío de mensajes no solicitados)

Soluciones: Responsabilidad del SW de red (evitar mensajes erróneos)

Checksum (para corrupción de mensajes)

Números de secuencia (para mensajes duplicados u omitidos)

18/01/2012

14



Fallos de temporización (‘timing’) Aplicable (únicamente) en SSDD síncronos Límites a: tiempos de ejecución, de entrega de mensajes, ‘clock drift

rate’ Relevante en SSDD multimedia (audio/vídeo)

Enmascaramiento de fallos

Uso de replicación Conversión a fallos identificables

Comunicación fiable (‘reliable’)

Validez: cualquier mensaje es enviado eventualmente Integridad: los mensajes enviados y recibidos son idénticos Amenazas:

Duplicación de mensajes Inyección de mensajes en el canal



Resumen Categoría Tipo de fallo Elemento afectado Descripción

Omisión

Fail-Stop Proceso Proceso parado. Detectable

Crash Proceso Proceso parado. No detectable

Omisión Canal Mensaje enviado no se recibe

Omisión de envío Proceso Mensaje no enviado (fallo búfer)

Omisión de recepción Proceso Mensaje no recibido (fallo búfer)

Arbitrario Proceso o canal Fallos arbitrarios

Timing

Reloj Proceso Variación de tiempo local excedida

Rendimiento Proceso Tiempo entre pasos de ejecución excedido

Rendimiento Canal Tiempo de transmisión excedido

18/01/2012

15


Modelos fundamentales: Modelo de seguridad

Definición: “The security of a distributed system can be achieved

by securing the processes and the channels used for their interactions and by protecting the objects that they encapsulate against unauthorized access”

Aspectos considerados Protección de objetos (permisos de acceso, ‘autoridad’) Seguridad de procesos y sus interacciones Caracterización del “enemigo” Provisión de seguridad en SSDD Otras posibles amenazas Utilidad de los modelos de seguridad



‘Enemigo’ Modelado para representar las amenazas al SD Capaz de leer los mensajes del canal Capaz de enviar mensajes a receptor/emisor por el canal

Amenazas a procesos Problema para identificar al emisor de un mensaje recibido Fallos en la fiabilidad para conocer el origen de un mensaje Tanto cliente como servidor se ven afectados

Amenazas al canal de comunicación El enemigo puede copiar, alterar o insertar mensajes en el canal Problema de privacidad e integridad.

Soluciones: Dotar de seguridad al canal

18/01/2012

16



Provisión de seguridad en SSDD. Soluciones:

Criptografía y encriptación

Autenticación de mensajes: incluir en el mensaje parte de la información encriptada para verificar su autenticidad

Uso de claves públicas y privadas

Canales seguros:

Cada proceso conoce la fiabilidad de la identidad de la autoridad controlando el canal

Se asegura la privacidad y la integridad

Cada mensaje incluye un ‘timestamp’ para evitar repeticiones de mensajes o reordenaciones no deseadas



Otras posibles amenazas Denegación de servicio Exceso de carga computacional Sobrecarga que produce retrasos y fallos en las entidades del

SD

Código móvil Código enviado a través del canal y ejecutado en el cliente Virus

Utilidad de los modelos de seguridad Los modelos se utilizan para analizar las posibles

amenazas Necesidad de diseñar estrategias de seguridad Creación de un modelo de amenazas (listado),

consecuencias y planes de contingencia

18/01/2012

17


Paradigmas de SSDD

Tipos de SSDD en función de su propósito

Sistemas de computación distribuida

Sistemas de información distribuida

Sistemas embebidos y ubicuos


Paradigmas de SSDD

Sistemas de computación distribuida

Utilizados para tareas de cómputo de alto rendimiento

Clasificación:

Cluster Computing

Grid Computing

18/01/2012

18


Paradigmas de SSDD: Sistemas de computación distribuida

Cluster Computing Evolución debido al ratio precio/rendimiento Objetivo: construir un “supercomputador”

Tecnología pre-existente Colección de ordenadores “simples” homogéneos Sobre una red (única) de alta velocidad

Propósito Ejecución de programas en paralelo “Cluster”: colección de nodos de cómputo que son controlados y

accedidos desde un nodo especial (‘master’) Gestiona la asignación de nodos a un programa paralelo concreto Mantiene una “cola” de trabajos a realizar (batch jobs queue) Ejecuta el middleware necesitado para la ejecución de programas y

control del cluster Los nodos no tienen middleware especializado

Middleware Librerías especializadas para cómputo distribuido (MPI) Los nodos comparten recursos (directorio raíz)



Cluster Computing. Tipos De alto rendimiento:

Beowulf: Linux, >1000 nodos, programas paralelos, MPI

De balanceo de carga: MOSIX: movimiento de procesos entre nodos para balanceo de carga

Para servicios Web: Balanceo de conexiones TCP, páginas Web y aplicaciones

De almacenamiento: Sistemas de ficheros paralelos: los nodos ven los mismos datos

De bases de datos: Oracle Parallel Server

Ejemplos: Beowulf (1993), Berkeley NOW (Network Of Workstations), STFX Sun Cluster, Sony PS3 (secuenciación de genes proteínicos)

18/01/2012

19



Definición “A computational grid is a hardware and software infrastructure

that provides dependable, consistent, pervasive and inexpensive access to high-end computational capabilities”. I. Foster & C. Kesselman, 1998.

Evolución: Compartición de recursos y Resolución de problemas en Organizaciones virtuales multi-institucionales

Diferencias con la computación distribuida tradicional: Compartición de recursos heterogéneos Coordinación descentralizada Gestión derivada de las organizaciones virtuales Alto rendimiento



Organización virtual (VO) “A dynamic group of individuals, groups or organizations

who define the conditions and rules for sharing resources” Joseph et al. 2004

Elementos: Recursos compartidos Miembros de la organización virtual Reglas y condiciones establecidas en la VO Tareas habituales: asignación de miembros a recursos, federación o

delegación de aspectos de seguridad, control de acceso

Características habituales: Existen una serie de aspectos y requisitos referidos a la compartición

de recursos La compartición de recursos es

18/01/2012

20



Organización virtual (VO)

Características habituales:

Existen una serie de aspectos y requisitos referidos a la compartición de recursos

La compartición de recursos es condicional, limitada en el tiempo y dependiente de unas reglas establecidas

El conjunto de participantes (individuos o instituciones) es dinámico

La relación de compartición entre los participantes es, por naturaleza, peer-to-peer (1-a-1)

La compartición de recursos depende de un conjunto de interacciones y reglas de acceso abiertas y bien definidas



Arquitectura Grid

Obtenido de: http://www.beacon-ct.co.uk/knowledge/overview-grid-technology

18/01/2012

21



Arquitectura Grid

“Fabric Layer”

Define la interfaz a los recursos locales que pueden ser compartidos

Suele dividirse en 2 subcapas: • Capa de Recursos: contiene los recursos físicos tales como

recursos computacionales, sistemas de almacenamiento, sensores, catálogos, etc.

• Capa de Red: contiene todos aquellos dispositivos necesarios para la interconexión de los diferentes recursos tales como enrutadores, líneas de comunicación, etc.

Obtenido de: http://www.beacon-ct.co.uk/knowledge/overview-grid-technology



Arquitectura Grid Capa middleware Funciona como capa intermedia, abstrayendo las

características de los recursos compartidos a todas aquellas aplicaciones que quieren hacer uso del grid Suele estar dividida en 3 capas:

• Capa de conectividad: Define los protocolos básicos de comunicación y autenticación necesarios para poder dar soporte a transacciones de red específicas del grid

• Capa de recursos: utiliza los protocolos de comunicación y seguridad para realizar tareas tales como negociación segura, iniciación, monitorización, registro y pago por uso de recursos compartidos, etc.

• Capa de “colectividad”: si la capa anterior definía tareas para controlar recursos individuales, esta capa implementa un conjunto de comportamientos con el fin de gestionar los recursos subyacentes de forma global.

18/01/2012

22



Arquitectura Grid

Capa de aplicación

Permite el uso de recursos en un entorno grid a través de la definición de diferentes protocolos de acceso a recursos

Contiene el software y los servicios que el usuario ve y con los que puede interactuar



Productos y propuestas: Oracle 10g/11g

Soporte para uso de recursos compartidos en un entorno distribuido

Proyectos europeos: EU DataGrid, ESDB, CrossGrid, CondorG, etc…

Estándares: OGSA

WSRF

Globus Toolkit (GT4): middleware estándar de facto

Storage Request Broker: Middleware que permite el acceso uniforme a conjuntos de datos

almacenados en entornos heterogéneos

Centrado en ficheros y conjuntos de ficheros

Transparencia de localización mediante catálogo de metadatos

18/01/2012

23


Paradigmas de SSDD: Sistemas de información distribuida

Sistema de información distribuida

Objetivo: integrar aplicaciones para conseguir un sistema de información global (a distintos niveles organizativos

Diferentes niveles de integración:

Bajo nivel: sistemas de procesamiento de transacciones

Alto nivel: integración de componentes independientes (cómputo vs. almacenamiento) EAI (Enterprise Application Integration)



Sistemas de procesamiento de transacciones Fragmentos de código (sentencias) que, o bien se

ejecutan todas o bien ninguna Sentencias: llamadas al sistema, procedimientos de

librería, etc. Fundamento de las bases de datos distribuidas Conceptos fundamentales Transacción Propiedades ACID

Transacción anidada Forma de distribuir transacciones en múltiples máquinas Monitor de procesamiento de transacciones: permite acceder

a recursos distribuidos a través de un modelo de programación transaccional

18/01/2012

24



EAI (Enterprise Application Integration)

Objetivo: integración basada en la comunicación entre aplicaciones

Fundamento: existencia de un middleware de comunicación

Middleware de comunicación:

RPC

RMI



Arquitectura EAI

Sop

ort

e al

des

arro

llo

Capa de gestión de procesos

Capa de transformación

Capa de integración

Capa B2Bi

Sop

ort

e a

la e

xplo

taci

ón

Paso 1 Paso 2 Nuevo Proceso

Paso 3a

Paso 3b

Fin de proceso

Capa de comunicación

Adaptador/ Conector

Adaptador/ Conector

Adaptador/ Conector

Adaptador/ Conector

Adaptador/ Conector

Host CRM ERP Web Facturación

Usuario Internet

18/01/2012

25



Arquitectura EAI Capa de gestión de procesos Traduce las funcionalidades de un objeto de negocio en

un sistema para su ejecución mediante llamadas desde otras aplicaciones

Permite el modelado de procesos distribuidos

Generar flujos de trabajo para eventos/incidencias

Capas de comunicación y transformación Capacidades transaccionales

Soporta protocolos y diferentes representaciones de datos

Traducción de modelos de datos



Arquitectura EAI

Capa de integración

Formado por módulos de adaptación (driver) o conexión

Facilita la interoperabilidad y la migración

Soporte al desarrollo

APIs comerciales y librerías de desarrollo

Repositorio de metadatos y configuraciones

Plantillas de procesos

Soporte a la explotación

Administración, monitorización, gestión de incidencias, etc.

18/01/2012

26



Evolución de los SSDD para integración Interfaces punto a punto EAI (bus o hub de integración) B2B

Ventajas Soluciones de integración basadas en estándares Desacoplamiento entre servicios del sistema Enrutamiento basado en reglas no en programación Facilidad de gestión y monitorización Extensibilidad

Inconvenientes Obliga a estandarizar Nuevos perfiles en los recursos distribuidos/integrados Dependencia de productos comerciales de integración Problemas en la empresa: no ROI inmediato, exige madurez TI

(estrategias bien definidas), modificación de arquitectura actual…

Ejemplos: IBM WebSphere, Tibco Business Works, Mule, etc.


Paradigmas de SSDD: Sistemas distribuidos embebidos y ubicuos

Características de los nodos en SSDD ubicuos Pequeños Batería propia Móviles Conexión inalámbrica Autogestionables

Requisitos Ser capaz de adecuarse a cambios en el contexto

(context-aware) Favorecer la adaptación a la composición dependiente

de los nodos (easily configurable & adaptable) Capacidades por defecto de un recurso: leer, almacenar,

gestionar y compartir información

18/01/2012

27


Paradigmas de SSDD: Sistemas distribuidos embebidos y ubicuos

Ejemplos

Domótica (home devices)

Sistemas de salud (e-Healthcare)

Redes de sensores


Ejercicios

¿Cuáles son los retos de los SSDD contemporáneos con respecto a heterogeneidad, openness y calidad de servicio?

¿Cómo se clasificaría una arquitectura distribuida basada en AJAX desde el punto de vista de los SSDD?

¿Qué retos o dificultades plantea el uso masivo de middleware como solución al diseño de SSDD?

Estudiar el problema de los generales ‘bizantinos’ y los algoritmos de consenso en SSDD

Documents

Tema 2: Caracterización de SSDD...Describiendo los patrones de composición Describiendo el middleware que forma el SD 18/01/2012 4 Sistemas distribuidos – Curso 2011-2012