Download - Modelos de los sistemas distribuidos
MODELOS DE LOS SISTEMAS DISTRIBUIDOSING. MA. MARGARITA LABASTIDA ROLDÁN
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 Operativo
Computadora 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