Mdelos Arquitecturaa

Modelos
Architecturales
From Coulouris, Dollimore, Kindberg and

Blair
Distributed Systems:
Concepts and Design
Edition 5, © Addison-Wesley 2012
Modificado DAAP 2015 Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design
Edn. 5
© Pearson Education 2012
Modelos de Sistema
• Motivación.
• Modelos Arquitectónicos.
• Arquitectura de Sistema.
• Variaciones en el modelo Cliente-Servidor.
• Modelos Fundamentales: Interacción, Fallo,
Seguridad
Edn. 5
Introducción
• Los diferentes tipos de SD comparten
propiedades subyacentes y dan lugar a
problemas de diseño comunes.
• Se pueden presentar las propiedades y temas
de diseño comunes mediante modelos
descriptivos.
• Un modelo arquitectónico define:
• Interacciones entre componentes (papeles
funcionales y patrones de comunicación entre ellos).
• Cómo están vinculados con la red.
• “Simplifica y abstrae las funciones y roles de los
componentes”.
• Ejemplos: cliente-servidor, peer-to-peer.
Edn. 5
Introducción (cont)
• Modelo Fundamental, descripción más
formal de las propiedades comunes en todos
los modelos arquitectónicos:
• Modelo de interacción: trata las prestaciones y
dificultad de poner límites temporales en SD
• Modelo de fallos: especifica los fallos que se
pueden producir en procesos y canales de
comunicación. Canales fiables, procesos correctos.
• Modelo de seguridad: discute posibles amenazas a
los procesos y canales de comunicación. Canal
seguro
Edn. 5
• Dificultades y amenazas de los sistemas distribuidos ..

problemas que los desarrolladores de sistemas distribuidos
enfrentan.
• Espectro de los modos de uso:
• Las partes componentes de los sistemas están sujetos a amplia
variaciones por la carga de trabajo - por ejemplo, páginas web con
millones acceso al día.
• Partes del sistema conectados o desconectados en el tiempo -
ejemplo, los móviles incluidos en un sistema.
• Pocas aplicaciones tienen requisitos especiales en ancho de banda
de alta velocidad de comunicación y baja latencia - ejemplo, las
aplicaciones multimedia.
Edn. 5
• Amplia gama de entornos de sistema: Un sistema distribuido

debe acomodar hardware heterogéneo, sistemas operativos y
redes.
 Las redes pueden diferir ampliamente en el rendimiento - redes inalámbricas operan
a una fracción de la velocidad de locales redes.
 Sistemas de escalas muy diferentes, que van desde decenas de computadoras para
millones de computadoras, que deben ser apoyadas.
• Los problemas internos: los relojes no sincronizados,
actualizaciones de datos contradictorios y muchos modos de fallo
de hardware y software que afectan a los componentes individuales
del sistema.
• Las amenazas externas: Los ataques a la integridad de los datos y
el secreto, ataques de denegación de servicio.
Edn. 5
Figure 2.1
Generaciones de los sistemas distribuidos
Edn. 5
7
Elementos Arquitecturales
Para entender los bloques fundamentales de un sistema
distribuido de construcción, es necesario a considerar
las siguientes preguntas claves:
• ¿Cuáles son las entidades que se comunican en el
sistema distribuido?
• ¿Cómo se comunican, o más específicamente, qué
paradigma de la comunicación se utiliza?
• ¿Que roles (cambiantes) y responsabilidades tienen en
la general arquitectura?
• ¿Cómo se asignan a la infraestructura distribuida
física (como son localizados)?
Edn. 5
© Pearson Education 2012 8
Figure 2.2
Entidades y paradigmas de comunicación
Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
Elementos Arquitecturales (cont.)
 Aspectos de diseño evidentes:
 División de responsabilidades:
 Aplicaciones
 Servidores
 Otros procesos
 Ubicación de los componentes

 Implicaciones fundamentales
 Prestaciones
 Fiabilidad
 Seguridad
Elementos Arquitecturales C-S
 Clásica e históricamente la más importante
 Continúa siendo la más utilizada.
 Recursos compartidos gestionados por los
servidores.
 Servidores pueden ser clientes de otros
servicios.
 Ejemplos
 Navegador-Servidor Web-Servidor Archivos
 Navegador-Buscador-Escaladores (crawlers)
Figure 2.3
Clients invoke individual servers
Client invocation Server

invocation
result result
Server
Client
Key:
Process: Computer:
Servicios por Múltiples Servidores
• Distintos procesos servidor en

máquinas separadas interaccionan
para proveer un servicio
• Dos opciones, el conjunto de objetos
en que está basado el servicio:
 Se divide y se distribuye entre los servidores.
 Se mantiene copias en varias máquinas.
Figure 2.4a
Peer-to-peer architecture
Figure 2.4b
A service provided by multiple servers
Service
Server
Client
Server
Client
Server
Mas sobre Procesos Peer-to-Peer
• Todos los procesos realizan tareas semejantes.

• Interactúan cooperativamente para realizar una
actividad distribuida como iguales.
• El patrón de comunicación de la aplicación determina la
cantidad de procesos cooperantes.
• El código de los procesos debe mantener la
consistencia de los recursos y la sincronización de las
acciones.
• Ejemplos, cluster de datos, distribución de contenido,
pizarra distribuida.
16
Servidores Proxy y Cachés
• Caché, almacén de datos utilizados
recientemente.
• Se encuentra más próximo que los datos
originales.
• Pueden estar en cada clientes o en un
servidor proxy.
• Se incrementa la disponibilidad y
prestaciones del servicio.
• La máquina proxy puede desarrollar otros
roles, por ejemplo, cortafuego.
Figure 2.5
Web proxy server
Client Web
server
Proxy
server
Client Web
server
Arquitectura Jerárquica
Servidor
Web
INTERNET
Caché Nacional
(Raíz)
Caché’s
Regionales
Caché’s
Institucionales
Zonas de
Usuarios
Arquitectura Jerárquica Dinámica
Servidores
Web
INTERNET
Caché’s CReps
Usuarios
Aspectos de Diseño del Caché
 Políticas de Reemplazo
 Políticas de control de admisión
 Prefetching
 Mecanismos de coherencia
Producto
Casero
Innovador
SD-AICI
Proyecto
SD -AICI
Yo estudio desde cualquier parte..

Variaciones Modelo Cliente-
Servidor
 Código Móvil
• Código se desplaza al cliente y se ejecuta
• Respuesta interactiva no sufre retardos
• Servicio se accede al ejecutar código que
invoca operaciones.
• Para implementar interfaces complejas
• Para simular un modelo “push” sobre la
Web.
Figure 2.6
Web applets
a) client request results in the downloading of applet code
Client Web
Applet code server
b) client interacts with the applet
Web
Client Applet server
Variaciones Modelo Cliente-Servidor (cont.I)
 Agentes Móviles
• Programa en ejecución que se traslada de una máquina a otra
realizando una tarea.
• Puede realizar solicitudes a los recursos locales de las máquinas
que visita.
• Reduce el coste de comunicación y tiempo de las solicitudes
remotas.
• Constituyen una amenaza potencial a la seguridad de los recursos
de las máquinas que visita.
• Existe el riesgo de que la visita se quede indefinidamente
25
Variaciones Modelo Cliente-Servidor (cont.II)
 Computadores de Red
• Descarga su sistema operativo y cualquier aplicación que necesita
el usuario desde un servidor de archivos remoto.
• Las aplicaciones corren localmente.
• Los archivos se gestionan desde un servidor de archivos remoto.
• Los usuarios pueden migrar desde un computador a otro sin
problemas.
• Capacidad del computador de red es limitada, lo que reduce los
costos.
• Si existe disco, se utiliza como un caché.
26
Variaciones Modelo Cliente-Servidor (cont.III)
Clientes ligeros.
• Capa de aplicación que soporta una interfaz basada en

ventanas.
• Las aplicaciones se ejecutan en un computador remoto,
servidor de cómputo
• Servidor de cómputo, máquina multiprocesador.
• Actividades gráficas fuertemente interactivas, tienen
problemas en este esquema.
27
Intercomunicación Espontánea
Music
service Alarm
gateway service
Internet
Hotel wireless
network
Discovery
service
Camera
TV/PC Guests
Laptop PDA
devices
28
Intercomunicación Espontánea (cont.)
 Características.
• Fácil conexión: dispositivos en un entorno nuevo, se
reconfigura transparentemente.
• Fácil integración: los servicios disponibles se descubren
automáticamente.
 Asuntos por resolver.
• Conectividad limitada: zonas sin cobertura, cambio de
celda, costo involucrado, etc.
• Seguridad y privacidad.
29
Requisitos de Diseño
Arquitecturas Distribuidas
 Temas de prestaciones.
 Capacidad de respuesta
• Carga y prestaciones del servidor
• Carga y prestaciones de la red
• Retardos de los componentes software
“sistemas con pocas capas de software y pequeñas cantidades de
datos a transferir entre cliente y servidor”
 Productividad
• Tareas completadas / tiempo
• En servidor, cliente y red (tasa transferencia)
 Balance de carga
• Entre computadores alternativos
• Entre procesos implicados
30
Figure 2.7
Software and hardware service layers in distributed systems
Applications, services
Middleware
Operating system
Platform
Computer and network hardware
Requisitos… (cont.I)
 Calidad de servicio
• Se ve afectada por: fiabilidad, seguridad, adaptabilidad y
prestaciones.
• En general, se puede ver como el indicador de aceptabilidad de un
servicio.
• Se recomienda usar QoS (Quality of Service), para referirse a la
capacidad de garantizar tasas de transferencia y límites de tiempo.
• Importante para aplicaciones que mantienen datos críticos en el
tiempo (caudales de sonido o vídeo).
• Disponibilidad de los recursos necesarios en los instantes
adecuados…
32
 Uso de caché y replicación.
• Ayudan a mejorar las prestaciones
• Ej. Protocolo de caché de Web
a) TTL (Time-To-Live)
b) PER (Poll Each Read)
c) PPA (Poll Periodically Algorithm)
 Aspectos de fiabilidad.
• Corrección
• Tolerancia a fallos
mediante redundancia, protocolos con reconocimiento y mecanismos
de recuperación
 Seguridad
•Protección activa y pasiva contra ataques, y
•Mecanismos de seguridad criptográfica.
Figure 2.8
Two-tier and three-tier architectures
34
Figure 2.10
Thin clients and compute servers
Compute server
Network computer or PC
Thin network Application

Client Process
Figure 2.11
The web service architectural pattern
36
Modelos Fundamentales
 En general,
 “Un modelo contiene los elementos esenciales para comprender y
razonar sobre el comportamiento del sistema”
 Trata cuestiones del sistema como:
• ¿Cuáles son sus entidades principales?
• ¿Cómo interactúan?
 Cuáles son las características que afectan su comportamiento
individual y colectivo?
 Su objetivo es:
• Explicitar todas las premisas relevantes
• Generalizar respecto a lo que es posible o no, dadas las premisas
anteriores (mediante algoritmos o propiedades)
37
Modelo de Interacción
 De interacción, refleja hechos como

• Comunicación se efectúa con retrasos.
• Probablemente retrasos de considerable duración.
• Precisión en la coordinación está limitada por la duración de los
retrasos y la dificultad de mantener un reloj común.
 De fallo,
• Define y clasifica los fallos.
• Proporciona la base para el análisis de los efectos potenciales de
los fallos y el diseño de sistemas con tolerancia a fallos.
 De seguridad
• Define y clasifica las formas en que se pueden llevar a cabo
ataques al sistema.
• Proporciona la base para el análisis de amenazas.
38
Figure 2.12
Categories of middleware
39
Figure 2.14
Processes and channels --Modelo de Interacción
process p process q
send m receive
Communication channel
Outgoing message buffer Incoming message buffer
 Los procesos transmiten mensajes de unos a otros para transferir

información y coordinar su actividad.
 Cada proceso tiene su propio estado que es privado.
 En general no puede predecirse:
• La tasa con que procede cada proceso.
• La temporización de la transmisión de mensajes.
Modelo de Interacción (cont.I)
 Prestaciones de los canales de comunicación.
 Latencia: retardo entre el envío de un mensaje y su recepción, incluye
• Tiempo de acceso a la red.
• Tiempo de transmisión.
• Tiempo empleado por los servicios de comunicación del sistema operativo
(origen y destino).
 Ancho de banda: cantidad máxima de información que se puede transmitir
en un intervalo de tiempo.
 Fluctuación (jitter): variación del tiempo invertido en completar el reparto de
una serie de mensajes.
Sistemas Distribuidos
Modelo de Interacción (cont.II)
 Relojes y eventos de temporización.
 Cada reloj posee una deriva diferente (diferencia con respecto a un tiempo
absoluto).
 Incluso, sus tasas de deriva son diferentes.
 Además, la concordancia final de los relojes está afectada por retardos
variables de los mensajes.
 Dos variantes del modelo de interacción, según las
restricciones temporales:
 Sistemas distribuidos síncronos
 Sistemas distribuidos asíncronos
Modelo de Interacción (cont.III)
 Sistemas distribuidos síncronos.
Se establecen límites:
 Tiempo de ejecución de cada etapa de un proceso tiene ciertos límites
inferior y superior conocidos.
• Cada mensaje se transmite en tiempo limitado conocido.
• La tasa de deriva de cada reloj tiene un límite conocido.
 Es difícil obtener valores realistas y además dar garantías sobre los valores
elegidos.
 Es posible utilizar timeouts para detectar fallos de procesos o pérdidas de
mensajes.
Modelo de Interacción (cont.IV)
 Sistemas distribuidos asíncronos.
 No existen limitaciones:
• Velocidad de procesamiento.
• Los retardos de transmisión de mensajes.
• Las tasas de deriva del reloj.
 Ejemplo: Internet
 Mayor dificultad para llegar a acuerdos, aún si se utilizan canales seguros.
 Generalmente, se permite realizar otro tipo de tareas durante la espera.
Modelo de Interacción (cont.V)
Sistema Distribuido Sistema Distribuido
Síncrono Asíncrono
Respuesta de Timeouts superior e Velocidad de proceso
los procesos inferior en cada etapa del muy variable
proceso
Tiempo de Timeouts de recepción Retardos imprevisibles
comunicación conocidos en la transmisión
Error en los Tasas de deriva locales Tasas de deriva

relojes conocidas imprevisibles
Modelo de Interacción (cont.VI)
 Ordenamiento de eventos.
 En un sistema asíncrono los eventos se pueden ver en un orden distinto al
que fueron generados.
 Por ejemplo,
• X envía un mensaje con el tema Reunión a Y, Z y A
• Usuarios Y y Z responden con un mensaje Re:Reunión
• El retardo en la transmisión de los mensajes puede hacer que los eventos se
vean en una secuencia distinta a la que se produjeron.
Figure 2.13
Real-time ordering of events
send receive receive

X
1 m1 4
m2
send
2 3 receive Physical
Y
receive time
send
Z
receive receive
m3 m1 m2
A
receive receive receive
t1 t2 t3
Figure 2.15
Omission and arbitrary failures
Class of failure AffectsDescription

Fail-stop Process Process halts and remains halted. Other processes may
detect this state.
Crash Process Process halts and remains halted. Other processes may
not be able to detect this state.
Omission Channel A message inserted in an outgoing message buffer never
arrives at the other end’s incoming message buffer.
Send-omission Process A process completes a send, but the message is not put
in its outgoing message buffer.
Receive-omission Process A message is put in a process’s incoming message
buffer, but that process does not receive it.
Arbitrary Process or Process/channel exhibits arbitrary behaviour: it may
(Byzantine) channel send/transmit arbitrary messages at arbitrary times,
commit omissions; a process may stop or take an
incorrect step.
Figure 2.11
Timing failures
Class of Failure Affects Description

Clock Process Process’s local clock exceeds the bounds on its
rate of drift from real time.
Performance Process Process exceeds the bounds on the interval
between two steps.
Performance Channel A message’s transmission takes longer than the
stated bound.
Modelo de Seguridad
 Lograr la seguridad del sistema distribuido:
• Asegurando los procesos y canales
• Protegiendo los objetos de acceso no autorizados
 Protección de objetos
• Los objetos se construyen para ser utilizados en formas diferentes por
usuarios diferentes
• Los derechos de acceso especifican a quién se permite realizar ciertas
acciones sobre el objeto
• La autoridad con que se ordena una invocación o se da un resultado se
denomina principal
• Un principal puede ser un usuario o un proceso
Figure 2.17
Objects and principals
Access rights Object

invocation
Client
result Server
Principal (user) Network Principal (server)
Figure 2.18
The enemy
Copy of m
The enemy
m’
Process p m Process q
Communication channel
Modelo de Seguridad (cont.III)
 Amenazas
• A procesos: suplantación de la identidad tanto del cliente como del servidor
• A los canales: vulneración de la privacidad e integridad de la información
sobre la red
 Vencer amenazas
• Criptografía
• Encriptación
• Autenticación
• Firmas digitales, etc
Modelo de Seguridad (cont.IV)
 Canales seguros
• Cada proceso conoce la identidad del principal en cuya representación se
ejecuta otro proceso.
• Se asegura la privacidad y la integridad de datos
• Cada mensaje incluye un sello temporal, físico o lógico, para prevenir el
reenvío o reordenación
Principal A Principal B
Process p Secure channel Process q

Mdelos Arquitecturaa

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mdelos Arquitecturaa

Uploaded by

Copyright:

Available Formats

Modelos

From Coulouris, Dollimore, Kindberg and

• Dificultades y amenazas de los sistemas distribuidos ..

• Amplia gama de entornos de sistema: Un sistema distribuido

 Ubicación de los componentes

Client invocation Server

• Distintos procesos servidor en

• Todos los procesos realizan tareas semejantes.

Yo estudio desde cualquier parte..

a) client request results in the downloading of applet code

b) client interacts with the applet

• Capa de aplicación que soporta una interfaz basada en

Computer and network hardware

Thin network Application

 De interacción, refleja hechos como

 Los procesos transmiten mensajes de unos a otros para transferir

Error en los Tasas de deriva locales Tasas de deriva

send receive receive

Class of failure AffectsDescription

Class of Failure Affects Description

Access rights Object

Principal (user) Network Principal (server)

Process p Secure channel Process q

You might also like