MODELOS DE LOS SISTEMAS DISTRIBUIDOS

AGENDA Introducción Modelos Arquitectónicos Modelos Fundamentales Networking e Internetworking Comunicación entre procesos Objetos Distribuidos e invocación

remota.

Introducción Un modelo arquitectónico de un sistema

distribuido trata sobre la colocación de sus partes y las relaciones entre ellas. Modelo Cliente – Servidor. Modelo de procesos peer to peer.

Los modelos fundamentales están implicados en una descripción más formal de las propiedades que son comunes en todos los modelos arquitectónicos.

Introducción Algunos problemas como la falta de

sincronización de relojes y la pérdida de mensajes se consideran en tres modelos: El modelo de interacción, que trata de las

prestaciones y de la dificultad de poner límites temporales en un sistema distribuido.

El modelo de fallos que intenta dar una especificación de los fallos que se producen en los procesos y en los canales de comunicación.

El modelo de seguridad que discute sobre las posibles amenazas para los procesos y los canales de comunicación.

MODELOS ARQUITECTÓNICOS

Modelos Arquitectónicos La arquitectura de un sistema es su estructura en

términos de componentes especificados por separado.

Un modelo simplifica y abstrae las funciones de los componentes individuales del sistema en cuestión y considera: La ubicación de los componentes en la red,

definiendo los patrones utilizables para la distribución de datos y carga de trabajo.

Las interrelaciones entre los componentes, sus papeles funcionales y los patrones de comunicación entre ellos.

Modelos Arquitectónicos Un primer acercamiento es clasificar los procesos

entre servidores, clientes e iguales, lo que permite identificar las responsabilidades de cada uno y ayuda a valorar sus cargas de trabajo y a determinar el impacto de los fallos en cada uno de ellos.

Los resultados de este análisis puede ser utilizado para especificar la distribución de los procesos de forma que concuerde con los objetivos de prestaciones y fiabilidad del sistema resultante.

Modelos Arquitectónicos Se pueden construir otros sistemas dinámicos

como variaciones del modelo cliente servidor: La posibilidad de mover código de un proceso a otro

permite que un proceso delegue tareas en otro (ejecución local). Los objetos y el código puede reubicarse para reducir los retardos de acceso y minimizar el tráfico de la comunicación.

Algunos sistemas se diseñan para permitir que las computadoras y otros dispositivos móviles se añadan o eliminen sin incidencias, permitiendo el descubrimiento de servicios disponibles y ofrecer sus servicios a otros.

Capas de Software El término arquitectura de

software se refiere a la estructura del software como capas o módulos en una única computadora y más recientemente en términos de los servicios ofrecidos y solicitarlos entre procesos localizados en el mismo o diferentes.

Esta vista orientada a procesos y a servicios puede expresarse en términos de capas de servicio.

Aplicación de servicios

Middleware

Sistema OperativoComputadora y Hardware de red

PLATAFORMA

Capas de Software

Plataforma

• Se considera el nivel de hardware y las capas más bajas de software.• Estas capas proporcionan servicios a las que están por encima de ellas, y que son implementadas

independientemente en cada computadora, proporcionando una interfaz de programación del sistema.

Middleware

• Se representa mediante procesos u objetos en un conjunto de computadoras que interactúan entre sí para implementar mecanismos de comunicación y recursos compartidos para aplicaciones distribuidas.

• Mejora el nivel de las comunicaciones soportando abstracciones como: procedimiento de invocación remota, comunicación entre un grupo de procesos, notificación de eventos, replicación de datos compartidos y transmisión de datos multimedia en tiempo real.

Capas de Software Considere a CORBA, ofrece una variedad de

servicios que proporcionan a las aplicaciones funciones que incluyen la gestión de nombres, seguridad, transacciones, almacenamiento persistente y notificación de eventos.

Los servicios de la capa superior son servicios específicos del domino que utiliza el middleware, sus operaciones de comunicación y sus propios servicios.

Arquitecturas de Sistema La división de responsabilidades entre los

componentes del sistema (aplicaciones, servidores y otros procesos) y la ubicación de los componentes en las computadoras en red, es el aspecto más evidente del diseño de un sistema distribuido. Sus implicaciones fundamentales están en las

prestaciones, fiabilidad y seguridad del sistema resultante.

En un sistema distribuido, los procesos con responsabilidades bien definidas interactúan con los otros para realizar una actividad útil.

Modelo cliente – servidor Históricamente es la más importante, el fin

principal es acceder a los recursos compartidos que ellos gestionan.

Los servidores pueden, a su vez, ser clientes de otros servidores.

Los buscadores, que permiten a los usuarios buscar resúmenes de la información disponible en las páginas web de los sitios de Internet.

Los resúmenes están realizados por programas denominados escaladores, que se ejecutan en segundo plano en el sitio del buscador utilizando peticiones HTTP para acceder a los servidores web en Internet.

Modelo cliente – servidor Las tareas del servidor (responder a las

consultas de usuarios) y las tareas de los escaladores (hacer peticiones a otros servidores web) son totalmente independientes; pueden ejecutarse concurrentemente.

Un buscador típico debiera incluir muchos hilos de ejecución concurrente, algunos sirviendo a sus clientes y otros ejecutando escaladores web.

Modelo cliente – servidor

Servicios proporcionados por múltiples servidores

Los servidores pueden implementarse como distintos procesos de servidor en computadoras separadas interaccionando, para proporcionar un servicio a los procesos clientes.

Los servidores pueden dividir el conjunto de objetos en los que está basado el servicio y distribuírselos entre ellos mismos, o mantener copias replicadas de ellos en varias máquinas.

Servicios proporcionados por múltiples servidores

Servicios proporcionados por múltiples servidores La web maneja una partición de datos en el que

cada servidor web administra su propio conjunto de recursos.

Un usuario puede emplear un navegador para acceder al recurso en cualquiera de los servidores.

La replicación se utiliza para aumentar las prestaciones y disponibilidad y para mejorar la tolerancia a fallos.

Proporciona múltiples copias consistentes de datos en procesos que se ejecutan en diferentes computadoras.

Servicios proporcionados por múltiples servidores

Servidores proxy y cachés Un caché es un almacén de objetos de datos

utilizados recientemente, y que se encuentran más próximo que los objetos en sí.

Al recibir un objeto nuevo en una computadora se añade al caché, reemplazando, si fuera necesario algunos objetos existentes. Cuando se necesita un objeto en un proceso

cliente, el servicio caché comprueba inicialmente la caché y le proporciona el objeto de una copia actualizada.

Si no, se buscará una copia actualizada

Servidores proxy y cachés Las cachés pueden estar en cada cliente o en

un servidor proxy que puede compartirse desde varios clientes.

Los navegadores mantienen una caché de las páginas visitadas recientemente, y de otros recursos web, en el sistema local de ficheros del cliente; utilizan una petición HTTP para comprobar si dichas páginas han sido actualizadas. Los servidores proxy para el web proporcionan

una caché compartida de recursos web a las máquinas cliente de uno o más sitios.

Servidores proxy y cachés El propósito de los servidores proxy es

incrementar la disponibilidad y prestaciones del servicio, reduciendo la carga en redes de área amplia y en servidores web.

Servidores proxy y cachés

Procesos <<de igual a igual>> En esta arquitectura todos los procesos

desempeñan tareas semejantes, interactuando cooperativamente como iguales para realizar una actividad distribuida sin distinción entre clientes y servidores.

El código en los procesos parejos o <<iguales>> mantiene la consistencia de los recursos y sincroniza las acciones a nivel de la aplicación cuando es necesario.

Procesos <<de igual a igual>> En general n procesos parejos podrán interactuar

entre ellos, dependiendo el patrón de comunicación de los requisitos de la aplicación.

La eliminación del proceso servidor reduce los retardos de comunicación entre procesos al acceder a objetos locales.

Procesos <<de igual a igual>> Considerando una aplicación de pizarra

distribuida que permite que usuarios en varias computadoras vean y modifiquen interactivamente un dibujo que se comparte. Se puede implementar con un proceso de aplicación

en cada sitio y que se basa en capas de middleware para realizar notificación de eventos y comunicación a grupos para indicar a todos los procesos de la aplicación de los cambios en el dibujo.

Proporciona a los usuarios de objetos distribuidos una respuesta interactiva mejor que la que se puede obtener con una arquitectura basada en servidor.

INTERFACES Y OBJETOS

Interfaz Se conoce como la especificación del

conjunto de funciones que se pueden invocar sobre él.

En la forma básica de la arquitectura cliente – servidor, se considera cada proceso servidor como una entidad aislada con una interfaz prescrita que define las funciones que ofrece.

Requisitos para el diseño de arquitecturas distribuidas

La idea de compartir se logró, en los sistemas de tiempo compartido de los años 70 con la utilización de los archivos compartidos.

Los beneficios se explotaron en sistemas operativos como Oracle para permitir que los procesos compartieran recursos, dispositivos y procesos de aplicación para compartir objetos de aplicación.

Diseño de Arquitecturas Distribuidas

Prestaciones

Capacidad de Respuesta

ProductividadBalance de Carga

Diseño de Arquitecturas Distribuidas

Calidad de Servicio

Propiedades no

funcionales:*fiabilidad*seguridad

*prestaciones

La facilidad de

adaptación para adecuar configuraciones variables de sistema y disponibilidad

.

Algunas aplicaciones mantienen

datos críticos en el tiempo,

flujos de datos que

precisan ser procesados o transferidos

de un proceso a

otro

Implica un requisito para

que el sistema

proporcione recursos

garantizados de

computación y

comunicación que sean

suficientes para permitir

a las aplicaciones

finalizar cada tarea a

tiempo

Cada recurso crítico debe reservarse

para las aplicaciones

que requieren

QoS y deben ser los

gestores de los recursos

los que proporcionen las garantías.

Las solicitudes de

reserva se pueden rechazar

MODELOS DE INTERACCIÓN MODELOS DE FALLO

MODELOS DE SEGURIDAD

MODELOS FUNDAMENTALES

Modelos fundamentales Todas las arquitecturas comparten algunas

propiedades fundamentales: Procesos que se comunican por paso de mensajes

a través de una red de computadores En particular, trataremos con tres aspectos

Interacción: el modelo debe definir y clasificar la comunicación entre elementos del sistema

Fallos: el modelo debe definir y clasificar los fallos que pueden darse en el sistema.

Seguridad: el modelo debe definir y clasificar los tipos de ataque que pueden afectar al sistema.

Modelo de interacción Respecto a la interacción, los sistemas

distribuidos deben tener en cuenta que Hay limitaciones debidas a la comunicación Es imposible predecir el retraso con el que llega un

mensaje Es imposible tener una noción global de tiempo La ejecución es no determinista y difícil de depurar

Algoritmo distribuido Definición de los pasos que hay que llevar a cabo

por cada uno de los procesos del sistema, incluyendo los mensajes de transmisión entre ellos

Modelo de interacciónPrestaciones del canal de comunicación

Latencia Retardo entre el envío de un mensaje y su

recepción Ancho de banda

Información que puede transmitirse en un intervalo de tiempo

Fluctuación (jitter) Variación del tiempo invertido en repartir

una serie de mensajes

Modelo de interacciónRelojes y eventos de tiempo

Cada computador tiene su propio reloj interno (reloj local) Puede usarse en procesos locales para marcas de

tiempo Tasa de deriva de reloj (clock drift rate)

Diferencia entre un reloj local y un reloj de referencia “perfecto”

Receptores GPS Network Time Protocol (NTP) Mecanismos de ordenación de eventos

Dos tipos de modelo de interacción Síncrono y asíncrono

Modelo de interacciónModelos síncronos

Conocimiento de características temporales: El tiempo de ejecución de cada etapa de un proceso tiene

ciertos límites inferior y superior conocidos

Cada mensaje transmitido sobre un canal se recibe en un tiempo límite conocido

Cada proceso tiene un reloj local cuya tasa de deriva sobre el tiempo de referencia tiene un límite conocido

A nivel teórico, podemos establecer unos límites para tener una idea aproximada de cómo se comportará el sistema

A nivel práctico, es imposible garantizar esos límites siempre

Aunque a veces se pueden utilizar, por ejemplo como timeouts

Modelo de interacciónModelos asíncronos

No hay limitaciones en cuanto a Velocidad de procesamiento Retardos en la transmisión de mensajes Tasas de deriva de los relojes

Los sistemas distribuidos reales suelen ser asíncronos Por ejemplo, Internet

Una solución válida para un sistema asíncrono lo es también para uno síncrono

Modelo de interacciónOrdenación de eventos

Podemos describir un sistema en términos de eventos, solucionando así la falta de precisión de los relojes

Imaginemos un grupo de usuarios de correo (X, Y, Z, A) X manda un mensaje m1 con el asunto Reunión Y y Z responden con mensajes m2 y m3,

respectivamente y en ese orden, con el asunto Re: Reunión

Debido a la independencia en los retardos de cada envío, el usuario A podría ver lo siguiente:

Modelo de interacciónOrdenación de eventos

Modelo de interacciónOrdenación de eventos

Si los relojes de X, Y y Z estuvieran sincronizados, podríamos incluir el tiempo local t1, t2, t3 en los mensajes m1, m2, m3

Estaríamos seguros de que t1 < t2 < t3 Podríamos ordenar los mensajes en concordancia

Pero los relojes no suelen estar sincronizados Lamport [1978] propuso un modelo de tiempo lógico Infiere el orden de los mensajes sin recurrir al tiempo físico Se basa en las siguientes afirmaciones

Un mensaje siempre se recibe después de enviarlo X manda m1 antes de que Y reciba m1

La réplica no se envía hasta que no se ha recibido el original Y recibe m1 antes de que envíe m2

Modelo de interacciónOrdenación de eventos

Modelo de fallo Estudio de las causas posibles de fallo

Para poder comprender sus consecuencias Tipo de fallo según la entidad

Fallos de proceso Fallos de comunicación

Tipo de fallo según el problema Fallos por omisión

No se consigue realizar una acción que se debería poder hacer Fallos arbitrarios (bizantinos)

Errores de cualquier tipo, fuera del esquema de mensajes Fallos de temporización

Superación de tiempos límite en un sistema síncrono

Modelo de falloFallo por omisión en procesos

Fallo del procesamiento (crash) Detección del fallo por timeouts (síncrono)

Si el proceso no responde, consideramos que ha habido un fallo

En sistemas asíncronos, nunca podemos estar seguros

Fallo-parada (fail-stop) Fallo de procesamiento que puede ser

detectado con certeza por el resto de procesos

Modelo de falloFallo por omisión en comunicaciones

Modelo de falloFallos arbitrarios o bizantinos

En proceso: Se omiten pasos necesarios o deseables del procesamiento Se realizan pasos innecesarios o indeseables en el

procesamiento Se omite arbitrariamente la respuesta a mensajes

En canales de comunicación Corrupción de mensajes Reparto de mensajes inexistentes Duplicación del reparto de mensajes auténticos

Origen: problema de los generales bizantinos Lamport, Shostak and Pease (1982). “The Bizantine

Generals’ Problem”. ACM Transaction on Programming Languages and Systems 4 (3): 382-401

Modelo de falloFallos bizantinos

El problema es encontrar un algoritmo para asegurar que los “generales leales” lleguen a un acuerdo.

Se muestra que, usando sólo los mensajes orales, este problema tiene solución si y sólo si hay más de dos tercios de los generales son leales

Modelo de falloFallo por omisión y arbitrarios (resumen)

Modelo de falloFallos de temporización

Sistemas síncronos

Sistemas asíncronos No existen fallos de temporización, ya que

no se ha dado ninguna garantía al respecto

Modelo de falloEnmascaramiento de fallos

Construcción de servicios fiables a partir de componentes que presenten fallos Por ocultación del error Por conversión a fallos más aceptables

Por ejemplo: Checksum a de fallo arbitrario a fallo

por omisión +retransmisión a de fallo por omisión a

ocultación

Modelo de falloComunicación fiable entre dos procesos

Debe cumplir con dos criterios: Validez

Cualquier mensaje en el búfer de mensajes salientes llegará, eventualmente, al búfer de mensajes entrantes Es decir, no hay fallos por omisión en el canal

Integridad El mensaje recibido es idéntico al enviado, y no se

repiten mensajes Protocolo que adjunta números de secuencia a los mensajes Canales de comunicación seguros

No hay fallos bizantinos en el canal

Modelo de seguridad La seguridad en un sistema distribuido se

basa en la seguridad de los procesos y canales utilizados Entendida como seguridad de objetos

Almacenados e invocados por los procesos Transmitidos a través de los canales

Se logra mediante un sistema de derechos de acceso y distintos tipos de autoridad

Modelo de seguridadPrincipal y derechos de acceso

Principal: autoridad con la que se ordena cada invocación de objetos o sus resultados Se contrasta con los derechos de acceso de

dicho objeto

Modelo de seguridadModelo de enemigo Entidad

Cualquier máquina conectada (de forma autorizada o no) a la red

Enemigo: entidad capaz de Enviar cualquier mensaje a cualquier proceso Leer o copiar cualquier mensaje compartido

entre dos procesos Leer mensajes o emitir mensajes falsos de

petición de servicios

Modelo de seguridadAmenazas

Amenazas a servidores Ciertos servicios no comprueban la identidad del cliente

Si la comprueban, no suele ser difícil suplantarla (spoofing) En vez de una petición de servicio auténtica se busca, p. ej.,

obtener información no autorizada o bloquear el servicio (DoS) Amenazas a clientes

Reciben un resultado falso de la invocación al servicio Generalmente, acompañado de suplantación de identidad

Amenazas a canales de comunicación Inyección, copia o alteración de mensajes que viajan por el

canal Por ejemplo: obtener un mensaje de transferencia de dinero,

cambiar la cuenta y reenviarlo después

Modelo de seguridadTécnicas de seguridad

Autenticación: comprobación de la identidad del proceso

Criptografía: uso de claves públicas y privadas Canales seguros: canal de comunicación sobre el

que dos procesos han establecido una capa de seguridad basada en criptografía + autenticación:

Se garantiza la identidad fiable de servidores y clientes

Se garantiza la integridad y privacidad de los mensajes enviados

Los mensajes incluyen una marca de tiempo para prevenir su repetición o reordenación maliciosa