Modelos de los sistemas distribuidos
-
Upload
margarita-labastida -
Category
Engineering
-
view
703 -
download
1
Transcript of Modelos de los sistemas distribuidos
![Page 1: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/1.jpg)
MODELOS DE LOS SISTEMAS DISTRIBUIDOSING. MA. MARGARITA LABASTIDA ROLDÁN
![Page 2: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/2.jpg)
AGENDA
Introducción Modelos Arquitectónicos Modelos Fundamentales Networking e Internetworking Comunicación entre procesos Objetos Distribuidos e invocación
remota.
![Page 3: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/3.jpg)
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.
![Page 4: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/4.jpg)
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.
![Page 5: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/5.jpg)
MODELOS ARQUITECTÓNICOS
![Page 6: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/6.jpg)
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.
![Page 7: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/7.jpg)
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.
![Page 8: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/8.jpg)
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.
![Page 9: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/9.jpg)
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
![Page 10: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/10.jpg)
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.
![Page 11: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/11.jpg)
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.
![Page 12: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/12.jpg)
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.
![Page 13: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/13.jpg)
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.
![Page 14: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/14.jpg)
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.
![Page 15: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/15.jpg)
Modelo cliente – servidor
![Page 16: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/16.jpg)
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.
![Page 17: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/17.jpg)
Servicios proporcionados por múltiples servidores
![Page 18: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/18.jpg)
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.
![Page 19: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/19.jpg)
Servicios proporcionados por múltiples servidores
![Page 20: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/20.jpg)
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
![Page 21: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/21.jpg)
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.
![Page 22: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/22.jpg)
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.
![Page 23: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/23.jpg)
Servidores proxy y cachés
![Page 24: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/24.jpg)
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.
![Page 25: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/25.jpg)
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.
![Page 26: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/26.jpg)
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.
![Page 27: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/27.jpg)
INTERFACES Y OBJETOS
![Page 28: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/28.jpg)
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.
![Page 29: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/29.jpg)
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.
![Page 30: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/30.jpg)
Diseño de Arquitecturas Distribuidas
Prestaciones
Capacidad de Respuesta
ProductividadBalance de Carga
![Page 31: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/31.jpg)
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
![Page 32: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/32.jpg)
MODELOS DE INTERACCIÓN MODELOS DE FALLO
MODELOS DE SEGURIDAD
MODELOS FUNDAMENTALES
![Page 33: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/33.jpg)
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.
![Page 34: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/34.jpg)
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
![Page 35: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/35.jpg)
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
![Page 36: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/36.jpg)
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
![Page 37: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/37.jpg)
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
![Page 38: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/38.jpg)
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
![Page 39: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/39.jpg)
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:
![Page 40: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/40.jpg)
Modelo de interacciónOrdenación de eventos
![Page 41: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/41.jpg)
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
![Page 42: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/42.jpg)
Modelo de interacciónOrdenación de eventos
![Page 43: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/43.jpg)
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
![Page 44: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/44.jpg)
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
![Page 45: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/45.jpg)
Modelo de falloFallo por omisión en comunicaciones
![Page 46: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/46.jpg)
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
![Page 47: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/47.jpg)
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
![Page 48: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/48.jpg)
Modelo de falloFallo por omisión y arbitrarios (resumen)
![Page 49: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/49.jpg)
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
![Page 50: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/50.jpg)
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
![Page 51: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/51.jpg)
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
![Page 52: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/52.jpg)
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
![Page 53: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/53.jpg)
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
![Page 54: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/54.jpg)
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
![Page 55: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/55.jpg)
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
![Page 56: Modelos de los sistemas distribuidos](https://reader035.fdocuments.es/reader035/viewer/2022081506/559134d21a28abc4628b47f1/html5/thumbnails/56.jpg)
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