Vous êtes sur la page 1sur 18

SISTEMAS DISTRIBUIDOS

TEMA 1: FUNDAMENTOS DE LOS SISTEMAS


DISTRIBUIDOS

DAVID RODRGUEZ HERNNDEZ


FECHA DE REVISIN: 15 Noviembre 2008
ZAMORA (CURSO 2008/2009)
david.rgh@gmail.com

Nota importante:
Este documento no pretende reemplazar al material propuesto por la UNED para la asignatura Sistemas
Distribuidos.
Su finalidad es presentar de una forma esquematizada los contenidos de la asignatura, para facilitar el
estudio de la misma. Es conveniente disponer de la bibliografa propuesta por la Universidad para su
estudio completo.
Cualquier sugerencia, comentario o correccin sobre este documento, envelo a david.rgh@gmail.com
para poder realizar los cambios necesarios.

INTRODUCCIN
Qu es un sistema distribuido? No es ms que aquel sistema cuyos componentes (tanto software
como hardware) se encuentran localizados en distintas computadoras unidas a travs de una red y que
se comunican y coordinan entre s mediante el paso de mensajes.
Esta definicin tiene algunas implicaciones, como la concurrencia; es decir, varios usuarios trabajando
desde sus propios ordenadores pueden tener acceso simultneo a los mismos recursos del sistema. Esto
es importante, ya que el sistema debe poder gestionar bien la coordinacin entre estos accesos.
Adems, como cada ordenador funciona aparte del resto (aunque conectados entre s todos), no existe
una nocin global del tiempo, manteniendo cada uno sus propios registros. As pues, debe poder
sincronizarse de alguna forma.
Se mantiene relativamente un concepto de individualidad, incluso en los fallos. Si uno de los
ordenadores falla, el resto de ordenadores del sistema debe poder seguir trabajando.

Qu es un recurso? Es algo que se comparte entre los ordenadores de la red. Puede ser algo fsico,
como un disco duro y su capacidad de almacenamiento; o no, como un fichero o una base de datos.

EJEMPLOS DE SISTEMAS DISTRIBUIDOS


Podemos mencionar los siguientes:

Internet:
Quizs el ms conocido. Se compone de diversos tipos de computadores
interconectados. stos se comunican mediante el paso de mensajes, que debe ser posible por
los mecanismos de comunicacin. Algunos servicios de este sistema son la WWW (World Wide
Web) (Cuidado: no confundir WWW con Internet), el correo electrnico o la transferencia de
ficheros (FTP). Los usuarios se conectan a Internet gracias a un ISP (Internet Service Provider),
que proporciona la conexin de su computador con la intranet de la empresa que acta como
ISP. Esta intranet, a su vez, tiene acceso a Internet.

Intranets: Consiste en una porcin de Internet, administrada por separado. Suele pertenecer a
una empresa, que establece los lmites necesarios para mantener su poltica. Los ISPs poseen
intranets que utilizan para conectar a sus clientes a Internet, a travs de un router. Adems,
puede ofrecer sus propios servicios, que pueden estar inaccesibles desde fuera de la intranet
(ej: almacenamiento y visualizacin de datos clnicos de los pacientes de un hospital). Suelen
disponer tambin de un cortafuegos, que filtra los mensajes de entrada y salida de la intranet
con el fin de protegerse de programas nocivos.
Una intranet tambin puede estar aislada completamente de Internet, siendo slo accesible
desde dentro de la misma (en este caso, no es necesario el uso de un cortafuegos).

Computacin mvil y ubicua: Los ordenadores (entindase de sobremesa) no son los nicos
que se conectan a los sistemas distribuidos. Poco a poco van proliferando el uso de dispositivos
mviles, como los ordenadores porttiles, los telfonos mviles, las PDAs Estos dispositivos
pueden viajar entre redes, de forma que no estn conectados siempre a la misma red. Esto se
conoce como computacin mvil.
La computacin ubicua consiste en integrar el uso de la informtica y los dispositivos
inteligentes en la vida ordinaria, de forma que el usuario los use de una forma totalmente
natural. La rama ms avanzada es la domtica (viviendas automatizadas) que tantas veces se
han visto en pelculas de ciencia-ficcin, pero cuya realidad no est tan alejada como pudiera
creerse. La vivienda est dotada de dispositivos inteligentes capaces de reaccionar a su entorno
(ej: controlar la iluminacin de una sala en funcin de la actividad detectada).

RECURSOS COMPARTIDOS Y WEB


Los usuarios estn muy acostumbrados a compartir los recursos disponibles. Esta comparticin puede
ser abierta a todo el mundo, como por ejemplo los datos de un servidor web en Internet; o puede ser
cerrada en un grupo delimitado de usuarios, como por ejemplo documentos en un sistema CSCW
(Computer-Supported Cooperative Working).
Los mecanismos necesarios vienen determinados por el patrn de compartir y por la distribucin
geogrfica de los usuarios.
Un servicio es una parte de un sistema que gestiona una coleccin de recursos relacionados y presenta
su funcionalidad a los usuarios y aplicaciones cliente (ej: un servicio de impresin).
Un servidor es un proceso que acepta y responde a las peticiones enviadas por procesos cliente. Esta
comunicacin se realiza a travs de mensajes. A esta solicitud se le denomina invocacin de la
operacin. Se llama invocacin remota a la interaccin existente desde la solicitud hasta la respuesta
del servidor. Un servidor tambin puede hacer las veces de cliente, contactando con otros servidores
(tngase en cuenta que la denominacin cliente y servidor se aplica a los procesos, no a los
computadores (aunque coloquialmente se les denomine a los propios computadores)). Un ejemplo de
cliente es un navegador web.

WORLD WIDE WEB


La WWW es un sistema para la publicacin y acceso a servicios a travs de Internet. Su nacimiento tuvo
lugar en el CERN (Suiza), donde se concibi como un mecanismo para el intercambio de documentos
entre una comunidad de fsicos.
La Web proporciona una estructura de hipertexto, de forma que un documento puede contener enlaces
y referencias a otro documento o recurso. Los recursos disponibles estn distribuidos por todo el mundo
y es una estructura muy compleja (telaraa).
Adems, es un sistema abierto, de forma que se pueden agregar nuevos servicios con facilidad, sin
alterar la estructura ya existente. Para establecer las comunicaciones existen estndares pblicos.
Aunque ahora exista una serie de recursos disponibles; si se inventa un nuevo tipo de recurso, puede
publicarse inmediatamente en la Web y los navegadores podrn leerlo con la simple inclusin de algn
plug-in o aplicacin.
La Web est basado en tres componentes bsicos:

HTML: HyperText Markup Language. Especifica el texto e imgenes del documento y su


presentacin al usuario. Puede contener cabeceras, prrafos, tablas, imgenes, enlaces a otros
documentos o recursos
Puede verse un ejemplo grfico en la pgina 10 del libro base. El cdigo HTML se escribe a
mano o bien se utiliza un editor WYSIWYG (What You See Is What You Want). Las etiquetas se
escriben siempre entre los smbolos < y > y suelen estar pareadas, es decir, tienen una etiqueta
inicial y otra final similar.

URL: Universal Resource Link. Se trata de un identificador que refiere de forma universal y
unvoca a un recurso concreto de la Web. Se compone de un esquema y de la localizacin

especfica. El primero puede ser mailto, ftp y el segundo puede ser una direccin de correo
electrnico, una direccin web
Como ya se dijo antes, pueden introducirse nuevos tipos de recursos, que pasarn a utilizar un
esquema propio. Evidentemente, los navegadores deben incluir (o instalar con ellos) una
aplicacin que pueda leer el nuevo tipo de recurso.
El esquema de URL ms conocido es, probablemente, el HTTP. Es de la forma:
http://nombredelservidor[:puerto][/pathdelservidor][?argumentos]
En la pgina 12 del libro base se pueden encontrar algunos ejemplos de URL. Las URL HTTP
pueden incluir anclas (#), que hacen referencia a una parte concreta del documento,
permitiendo al usuario ir directamente a esa parte.
Para publicar un nuevo recurso, el usuario debe colocar el fichero en una carpeta accesible del
servidor; de forma que se puede posteriormente componer la URL adecuada y publicarla en
otro documento.

HTTP: HyperText Transfer Protocol. Sus principales caractersticas son:


o

Interacciones peticin-respuesta: El cliente realiza una solicitud al servidor del recurso


que quiere y ste busca dicho recurso y se lo devuelve en un mensaje (si no existe, le
devolver un error).

Tipos de contenido: El cliente especifica, junto con su solicitud, el tipo de archivos que
prefiere (por ejemplo, puede preferir un formato GIF y no un JPEG); de forma que el
servidor lo puede tener en cuenta a la hora de responder a la peticin (en la respuesta
incluir el tipo de contenido para que el cliente sepa cmo procesarlo; esta
informacin se conoce como tipos MIME). Pueden verse algunos ejemplos en la
pgina 13 del libro base.

Un recurso por solicitud: Por cada recurso deseado, se realizar una solicitud distinta
(ej: un documento con 9 imgenes necesitar 10 solicitudes (una por cada imagen y
otra por el propio documento)). Esto es as en la versin 1.0 de HTTP.

Control de acceso simple: Cualquier usuario con una conexin de red a un servidor
web tendr acceso a cualquiera de los recursos publicados en dicho servidor. Sin
embargo, un servidor puede ser configurado para limitar el acceso (por ejemplo,
mediante un sistema de contraseas).

Todo lo anterior ha hecho referencia a documentos estticos, donde si hay algn cambio se realiza de
forma permanente para todos los posibles clientes. Sin embargo, determinados documentos requieren
un formato personalizado (por ejemplo, la confirmacin de los datos personales de una persona en una
tienda online). Por otra parte, algunos documentos se componen de formularios (ej: la pgina de
registro de un sitio web) que deben poder procesar los datos introducidos (esto es, se envan dichos
datos al servidor).
Para poder presentar estos datos se necesita un programa que genere el cdigo dinmico de los
resultados. Se le suele conocer como CGI (Common Gateway Interface). Este programa se ejecuta en el
servidor.

Sin embargo, otros tipos de cdigo, como el Javascript, se descargan junto al documento y se ejecutan
en el cliente (ej: validacin bsica de datos de formulario o modificar algunas partes del documento), lo
cual acorta el tiempo de espera; aunque es bastante limitado. Para salvar esta limitacin, tenemos los
applets, que son programas escritos en Java y que se descargan al cliente, donde se ejecutan. Los
applets pueden tener acceso a la red (ej: chat incrustado en una pgina web).

El xito de la Web es la facilidad de publicacin de recursos. Sin embargo, tiene algunos inconvenientes,
como por ejemplo los enlaces rotos (si se modifica un recurso puede que los enlaces hacia l queden
intiles) o la confusin que puede suponer a un usuario seguir demasiados enlaces.
Por otra parte, HTML es un lenguaje muy limitado en un mundo en el que se requiere un intercambio de
muchos tipos de datos estructurados cada vez ms creciente. Adems, los servidores pueden tener
demasiados accesos simultneos, con lo que se ralentiza el acceso a los usuarios.

DESAFOS
HETEROGENEIDAD
Las redes y computadores accesibles por Internet son muy heterogneos (variados y diferentes). Esta
heterogeneidad se aplica a redes, hardware, sistemas operativos, lenguajes de programacin y
diferentes implementaciones.
Los protocolos de Internet permiten la interconexin entre ellos. Tngase en cuenta que distinto
hardware puede tener distinta representacin para un tipo de dato, al igual que distintos lenguajes de
programacin.
En cuanto a las implementaciones, se necesita el acuerdo de una serie de estndares.
El middleware es un tipo de software que permite encapsular la implementacin de las aplicaciones,
permitiendo que dos programas distintos o en redes distintas puedan comunicarse entre s. Algunos
ejemplos son CORBA y Java RMI. Es una herramienta til adems para los desarrolladores, para poder
crear aplicaciones distribuidas utilizando las invocaciones remotas que proporciona el middleware.
Se conoce como cdigo mvil a aquel que puede enviarse desde un computador a otro y ejecutarse en
el destino. El problema es que dicho cdigo puede no ser entendido por el destino para su ejecucin.
Esto queda solucionado mediante las mquinas virtuales; es decir, se crea cdigo para una mquina
virtual en lugar de para un hardware concreto. Esta mquina virtual (por ejemplo, JVM (Java Virtual
Machine)) traduce el cdigo para el hardware en cuestin (esta solucin no se puede aplicar de modo
general a otros lenguajes).
EXTENSIBILIDAD
Consiste en el grado en que se puede extender y reimplementar con variaciones. En un sistema
distribuido est determinado por el grado en que se pueden aadir nuevos servicios de comparticin de
recursos y publicarlos. Para ello, la documentacin debe estar disponible para los desarrolladores. Los
protocolos de Internet tienen su documentacin en los llamados RFC (Request For Comments), aunque
no son los nicos.
Se conoce como sistema distribuido abierto a aquel sistema diseado para dar soporte a la
comparticin de recursos. La extensin del sistema puede ser por hardware o por software. Sus
interfaces estn publicadas y estos sistemas se basan en la providencia de un mecanismo de
comunicacin uniforme. Como ya se dijo antes, puede construirse con hardware y software
heterogneos, utilizando para ello estndares.
SEGURIDAD
Esta propiedad es vital, pues los recursos pueden tener un gran valor. Tiene 3 componentes:
confidencialidad (impedir accesos no autorizados), integridad (no se modifican los datos) y
disponibilidad (impide el bloqueo del acceso).
En las peticiones, se transmite informacin sensible por la red, que debe tener una cierta seguridad,
adems de asegurarse de que el interlocutor es quien dice ser. Las tcnicas de encriptacin pueden dar
esta seguridad.
Sin embargo, tenemos estos otros problemas:

Ataques de Denegacin de Servicio: DOS. Consiste en bombardear un servidor a base de


peticiones, de manera que ste no puede atenderlas y queda colapsado, impidiendo su uso a
los usuarios.

Seguridad del cdigo mvil: La transmisin de cdigo por la red supone un riesgo para quien
lo recibe. No son pocos los que han sido infectados por cdigo maligno que estaba adjunto en
un correo electrnico.

ESCALABILIDAD
Para que un sistema sea escalable, debe conservar su efectividad cuando se aumenta significativamente
los recursos y usuarios. Un ejemplo de un sistema escalable es el propio Internet.
Un problema existente es el coste de los recursos fsicos, necesarios cuando la demanda de los recursos
(software) aumenta. Por ejemplo, aadir servidores redundantes que puedan balancear la carga de
trabajo de las peticiones.
Adems, extender un sistema puede suponer una prdida de prestaciones, la cual debe ser controlada y
minimizada.
Un recurso puede verse desbordado con la extensin. Por ejemplo, las direcciones IP actuales (IPv4) son
limitadas y se agotan con el rpido crecimiento de usuarios, lo que requiere una ampliacin (IPv6).
La carga debera estar bien balanceada, para evitar problemas de cuellos de botella.
TRATAMIENTO DE FALLOS
Los sistemas fallan, es una realidad. Deben minimizarse sus efectos.
Algunos fallos son detectables, lo cual permite prevenirlos y evitar que sucedan. Por ejemplo, las sumas
de comprobacin (checksum) permiten detectar datos corruptos de un archivo. Otros fallos pueden
ocultarse al usuario (por ejemplo, mediante la redundancia de discos se logra que un dato corrupto sea
servido por el disco que contiene el correcto).
No todos los fallos pueden ocultarse o enmascararse, y supondra un gasto elevado. Por ello, se admite
una cierta tolerancia segn el sistema. Es muy importante tambin disponer de un buen sistema de
recuperacin de fallos, de forma que los datos puedan volver a un estado consistente tras un fallo (ej:
rollback).
CONCURRENCIA
Una consecuencia directa de la comparticin de recursos es la posibilidad del acceso concurrente de
varios usuarios a un mismo recurso. Aunque podra atenderse cada peticin por separado, conllevara a
una prdida de productividad (throughput). Por ello se utilizan threads para ejecutar concurrentemente
el contenido de un objeto en que se encapsula el recurso en cuestin. Las operaciones realizadas deben
estar bien sincronizadas.
TRANSPARENCIA
Consiste en ocultar al usuario la separacin de los componentes distribuidos, de forma que perciba una
sola unidad. Tenemos los siguientes tipos de transparencia:

De acceso: Se accede de la misma forma a recursos locales que a remotos. Por ejemplo, las
carpetas de una GUI se muestran igual tanto si son locales como remotas.

De ubicacin: No se requiere conocer la localizacin de un recurso para acceder a l.

De concurrencia:
recurso.

De replicacin: Puede utilizarse varias (miles) de copias de un recurso para aumentar las
prestaciones (el usuario no es consciente de ello).

Frente a fallos: Oculta los fallos a los usuarios y a las aplicaciones de usuario, permitiendo que
continen su tarea.

De movilidad:
forma).

De prestaciones: Permite reconfigurar el sistema para balancear las cargas segn el estado.

Al escalado: Permite ampliar el sistema sin alterar la estructura ni los algoritmos.

Varios procesos pueden realizar peticiones simultneas sobre el mismo

Permite reubicar recursos sin que el usuario lo note (accede de la misma

De estos, los ms importantes son los 2 primeros. Por ejemplo, un URL tiene transparencia de ubicacin,
ya que da igual la localizacin fsica del recurso, ya que el URL designa un identificador nico que luego
debe traducirse. Sin embargo, no tiene transparencia de movilidad, ya que si se reubica el recurso, sus
enlaces quedan intiles. Pueden verse varios ejemplos en la pgina 23 del libro base.

MODELOS ARQUITECTNICOS
Se conoce como arquitectura del sistema a la estructura de componentes del mismo.
De una manera simplista, se podra desglosar un sistema distribuido en servidores, clientes e iguales.
Los dos primeros ya se explicaron en los apartados anteriores. Los iguales son aquellos procesos que
cooperan entre s ponerse uno por encima del otro.
Recordemos que puede realizarse cdigo mvil, que se descargan del servidor al cliente para ejecutarse
all.
CAPAS DE SOFTWARE
Los sistemas distribuidos se estructuran en capas, como puede verse en la figura de la pgina 30.
Se conoce como plataforma al nivel de hardware y las capas ms bajas del software. Su funcin es servir
a las capas superiores con independencia del computador utilizado. Una parte de la plataforma es el
sistema operativo, que acta de interfaz con las capas superiores.
Se conoce como middleware a una capa de hardware que permite realizar una interconexin entre
capas de forma homognea; es decir, enmascara las capas inferiores para que la capa superior no tenga
que preocuparse de la implementacin de stas. Proporciona bloques tiles que sirven para que los
componentes software puedan interactuar con los sistemas distribuidos.
Como ejemplos de middleware, podemos nombrar las llamadas a procedimientos remotos (RPC)
(fueron de los primeros), CORBA, RMI, DCOM.
Tambin puede proporcionar servicios para que las aplicaciones de servicios los utilicen (ej: CORBA
ofrece funciones como la gestin de nombres, seguridad, transacciones, almacenamiento persistente).
Muchas aplicaciones dependen del middleware para su correcto funcionamiento, pero algunos aspectos
de la confiabilidad an requieres soporte al nivel de aplicacin (puede verse un ejemplo en la pgina
31). El funcionamiento correcto depende de las comprobaciones en los diversos niveles, no solo en el
middleware.
ARQUITECTURAS DE SISTEMA
Una de las caractersticas principales de un sistema distribuido es el reparto de tareas entre sus
componentes. A continuacin veremos los modelos arquitectnicos principales. Es conveniente
acompaar esta parte con las ilustraciones del libro base desde la pgina 32 hasta la 39:

Modelo cliente-servidor: Es la ms comn e importante hoy en da. Adems, es muy intuitivo:


varios procesos cliente realizan peticiones a un proceso servidor. Recurdese que esta
denominacin se aplica a una peticin concreta, por lo que un servidor en una peticin puede
hacer las veces de cliente en otra distinta (contactando con otro servidor distinto) (por
ejemplo, un buscador acepta peticiones de los usuarios (servidor) pero realiza consultas a otros
servidores para buscar los resultados (cliente) (esta bsqueda la hace un programa llamado
escalador (crawler)).

Servicios proporcionados por mltiples servidores: Un servicio puede componerse de varios


servidores que interaccionan entre s para realizar el servicio. Pueden repartirse los objetos o
replicarlos. Un ejemplo es la Web, donde un usuario puede utilizar un navegador para acceder

a un recurso en cualquiera de los servidores. La replicacin proporciona una mayor


disponibilidad y tolerancia a fallos.

Servidores proxy y cachs: Cuando se solicita un recurso, se almacena en la cach, de forma


que queda disponible de una forma mucho ms rpida si se vuelve a solicitar. Si no est
actualizada, se busca el recurso en el servidor original y se actualiza la cach. Esto es muy
empleado actualmente por los navegadores web. Los servidores proxy proporcionan una cach
compartida a clientes de uno o ms sitios, con lo que se mejora la disponibilidad y las
prestaciones y evita sobrecargas en la red.

Procesos de igual a igual: Peer to Peer. Todos los procesos funcionan de forma simtrica e
interactan entre ellos para cooperar para llevar a cabo una determinada tarea. En este caso
no existe proceso servidor.

VARIACIONES EN EL MODELO DE CLIENTE-SERVIDOR


Podemos distinguir las siguientes variaciones:

Cdigo mvil: Ya hemos hablado antes de esto. Un ejemplo de cdigo mvil es un applet de
Java. Con ello se puede extender la funcionalidad de la aplicacin cliente (ej: navegador web)
aadiendo otras que no realiza de forma bsica. Recurdese que el cdigo mvil es un riesgo
de seguridad para el computador destino; aunque los navegadores suelen limitar el acceso de
dicho cdigo a los recursos locales.

Agentes mviles: Se trata de un proceso que, para llevar a cabo su tarea, se traslada entre
varios computadores (ej: una aplicacin que recolecte informacin o una aplicacin que pueda
instalar componentes en varios computadores). Igualmente representan un riesgo para los
computadores visitados.

Computadores de red: Se caracteriza porque descarga su SO y cualquier aplicacin necesaria


desde un servidor remoto. Aunque la ejecucin es local, la gestin real de los archivos se da en
el servidor.

Clientes ligeros: Es una capa de aplicacin con una interfaz de ventanas sobre un computador
local que ejecuta programas de aplicacin en un computador remoto. Se diferencia del anterior
en que no se descarga el cdigo de las aplicaciones, sino que se ejecutan en el servidor
(servidor de cmputo). Su mayor problema est en aplicaciones grficas con una interaccin
fuerte (ej: CAD), que ralentiza excesivamente su uso.
La mayora de variantes de UNIX usan el sistema de ventanas X-11. En la pgina 37 del libro
pueden verse algunos ejemplos.

Dispositivos mviles y enlace espontneo a red: Recordemos que hay infinidad de dispositivos
que pueden conectarse a la red: PDA, mviles, chips de domtica Un sistema distribuido
puede dar soporte para la computacin mvil que permite a estos dispositivos conectarse a los
recursos locales y remotos.
Se conoce como enlace a red espontneo a aplicaciones que usan conexiones de una manera
ms informal (ej: PDA con geolocalizacin o servicios locales como la Web). Vanse varios
ejemplos en la pgina 38. Las caractersticas esenciales son:
o

Conexin fcil a la red local: Cuando se coloca un dispositivo en un nuevo entorno, se


reconfigura automticamente para facilitar la conexin.

Integracin fcil con servicios locales: Un dispositivo que se mueva entre redes
existentes de dispositivos, detecta automticamente qu servicios proporcionan los
dispositivos a los que se conecta. Un ejemplo comn son los servicios bluetooth de un
telfono mvil: detecta los servicios que proporcionan otros dispositivos bluetooth
cercanos.

Todo esto conlleva sus problemas, como puede ser la desconexin temporal, por ejemplo, si se
atraviesa un tnel, en la que el usuario debera poder seguir trabajando. Adems, hay
problemas de seguridad por la proximidad de la conexin de otros dispositivos (en el ejemplo
del bluetooth, otro telfono cercano podra acceder al nuestro si no se establecen medidas de
seguridad).
Se conoce como servicio de deteccin o servicio de descubrimiento a aquel servicio que se
encarga de aceptar y almacenar detalles de los servicios disponibles en la red a la que est
conectado, as como responder consultas de otros dispositivos. Esto, por ejemplo, lo hacemos
cada vez que en nuestro telfono solicitamos hacer un barrido en busca de dispositivos
cercanos. Tiene dos interfaces:
o

Servicio de admisin: Acepta solicitudes de ingreso en el servidor y almacena los


detalles del solicitante en la base de datos del servicio de descubrimiento.

Servicio de bsqueda: Acepta consultas acerca de los dispositivos disponibles y


realiza una bsqueda en la base de datos de aquellos servicios registrados que
coinciden con los parmetros introducidos.

INTERFACES Y OBJETOS
Se conoce como definicin de interfaz a la especificacin del conjunto de funciones que se puede
invocar sobre el proceso en cuestin. En los lenguajes orientados a objetos, los procesos pueden
encapsular un gran nmero de objetos y comunicarse con otros procesos a travs de estas interfaces (a
travs de invocaciones remotas), esta es la aproximacin aportada por CORBA y Java con el RMI.
REQUISITOS DE DISEO PARA ARQUITECTURAS DISTRIBUIDAS
Cuando comenz a extenderse la disponibilidad de redes de computadores de prestaciones medias, la
comparticin de recursos se asumi como normal. Pero compartir datos en gran escala an es un reto.
En cuanto a las prestaciones, podemos considerar los siguientes puntos:

Capacidad de respuesta: Responsiveness. Cuando se implica un servicio remoto, el tiempo de


respuesta est influenciado por los retardos de todos los componentes implicados, as como el
middleware, la comunicacin entre los sistemas y el cdigo del proceso. Esta comunicacin
resulta lenta cuando los datos a transmitir son elevados (no es lo mismo un prrafo de texto
que una imagen).

Productividad: Throughput. Es la rapidez a la que se realiza el trabajo computacional. Es


importante la productividad de las capas de software que intervienen en el proceso.

Balance de cargas computacionales: Es importante distribuir de forma correcta la carga. Por


ejemplo, el uso de applets libera al servidor de su ejecucin, delegndola en el cliente. Un nico
servicio puede ser proporcionado por un conjunto de servidores.

Respecto a la calidad del servicio, se ve afectada por la fiabilidad, la seguridad y las prestaciones.
Tambin es importante la facilidad de adaptacin (adaptability). Los dos primeros son crticos.
Muchos sistemas tienen determinados datos que deben transferirse en un tiempo determinado (ej:
detector de humos que permite activar el sistema de extincin de incendios). La calidad del servicio
(QoS, Quality of Service) es la capacidad del sistema para satisfacer estos tiempos lmite. Una excesiva
carga en el sistema deteriora sus prestaciones y, por tanto, la calidad. Se debe garantizar que los
recursos crticos estn reservados para las aplicaciones que requieren QoS.
Por lo que respecta al uso de cach y de replicacin, ya habamos comentado las ventajas de la cach
para disminuir los tiempos de respuesta. sta almacena los recursos que se han utilizado, de forma que
el siguiente servicio que use dichos recursos se ejecuta ms rpido, al no tener que esperar el envo
desde el servidor original. En la Web, esta cach puede ser del navegador o del proxy (si existe). Si el
recurso no est actualizado (se valida con el servidor original) ser entonces cuando se vuelva a recurrir
al servidor para obtener la ltima actualizacin.
Los recursos de la cach y el proxy suelen tener unos tiempos de expiracin, que permite comprobar si
un recurso est obsoleto, realizando un clculo con su edad en contraposicin al tiempo de expiracin.
Por ltimo, la fiabilidad es un requisito crucial. De este requisito pueden llegar a depender vidas,
aspectos econmicos, seguridad de datos personales etc. Podemos analizar algunos aspectos
importantes:

Tolerancia frente a fallos: Se puede conseguir fiabilidad mediante redundancia. Los recursos
pueden estar duplicados en mltiples servidores, por lo que se logran varios caminos de
comunicacin y que las aplicaciones se reconfiguren automticamente para conectar a uno o a
otro. Es algo costoso y limitado. Las aplicaciones crticas (ej: control areo) requieren un alto
grado de fiabilidad, por lo que el coste de mantenimiento es muy elevado. En las
comunicaciones se logra fiabilidad con otras tcnicas, como el uso de reconocimientos (ACK)
para las transmisiones.

Los datos y procesos deben estar protegidos contra ataques y accesible


Seguridad:
nicamente a los usuarios autorizados (ej: base de datos de un hospital: los historiales deben
estar a salvo de cualquier vulneracin de la seguridad (por ejemplo, impidiendo descargar el
historial completo a un terminal)).

MODELOS FUNDAMENTALES
Todos los modelos descritos anteriormente comparten el hecho de que se componen de procesos que
se comunican mediante mensajes por la red y siguen los principios de diseo que hemos comentado.
Un modelo tiene slo lo esencial para entender y razonar sobre algunos aspectos del comportamiento
del sistema y debe tratar de definir las entidades del sistema y su interaccin, adems de las
caractersticas que les afectan.
Nos permite conocer las premisas sobre los sistemas, y as podemos valorar si son vlidas sobre una
implementacin concreta. As, podemos razonar sobre la interaccin entre los procesos del sistema
(comunicacin por paso de mensajes) (debe reflejar los retrasos y la precisin de coordinacin), los
fallos que estn definidos y clasificados por el modelo (permite analizarlos y disear sistemas
tolerantes) y la seguridad (se definen y clasifican los posibles ataques con el fin de poder combatirlos).
Veamos algunos modelos simples:
MODELO DE INTERACCIN
Los sistemas se componen de procesos que interactan entre s. La interaccin puede incluir clientes y
servidores, y tambin puede realizarse entre iguales.
Se conoce como algoritmo distribuido a la definicin de los pasos que hay que llevar a cabo por cada
proceso, incluyendo los mensajes de transmisin entre ellos. Es complicado conocer todos los posibles
estados de los algoritmos distribuidos, ya que depende mucho de los fallos de ellos mismos y de los
procesos con los que se comuniquen.
A los procesos que interactan, les afectan dos factores principalmente.
Por una parte, tenemos las prestaciones de los canales de comunicacin. Hay varias opciones de
canales. Se debe tener en cuenta la latencia (retarde entre el envo de un mensaje y la recepcin de su
respuesta), el ancho de banda (si se usan varios canales, el ancho de banda tiene que ser compartido, lo
que disminuye las prestaciones) y la fluctuacin (variacin del tiempo invertido en completar el reparto
de una serie de mensajes (es importante para los datos multimedia (no debe presentar demasiada
fluctuacin))).
Por otra parte, tenemos los relojes de computadores y eventos de temporizacin. Cada computador
tiene su propio reloj, que casi siempre presentar derivas con respecto a los relojes del resto de
computadores. Se conoce como tasa de deriva del reloj a la proporcin de deriva de un reloj con otro
de referencia que se considere perfecto. Una forma de corregir los tiempos del reloj es mediante un
receptor GPS, que realice lecturas del tiempo de un sistema GPS; pero es una solucin cara para cada
computador (como alternativa, puede haber un servidor que se encargue de esto y transmita el tiempo
al resto de computadores).
En este modelo podemos encontrar dos variantes:

Sistemas distribuidos sncronos: En estos sistemas, el tiempo de ejecucin de cada etapa de


un proceso tiene lmites superior e inferior conocidos, el tiempo de recepcin de un mensaje
tambin tiene un lmite conocido, al igual que el lmite de la tasa de deriva.
Se pueden sugerir valores de lmites parecidos, pero es complicado ser realista. Deberan
poderse garantizar los lmites. Por ejemplo, puede utilizarse timeouts para marcar el fallo de un
proceso.

Sistemas distribuidos asncronos: Por ejemplo, Internet. No tiene lmites en la velocidad de


procesamiento, los retardes de transmisin de mensajes y en las tasas de deriva de reloj. En
este no se presupone nada acerca de los intervalos de tiempo de cualquier ejecucin.
Debido a que actualmente es muy importante la comparticin de recursos y de canales de
comunicacin, casi todos los sistemas actuales son asncronos. Pero, como ya dijimos,
determinadas situaciones requieren de un sistema sncrono (ej: transmisin multimedia).

Muchas veces nos interesa saber el orden de los eventos o mensajes (vase el ejemplo de las pginas
48-49 del libro base). Como los sistemas distribuidos no pueden sincronizarse de una forma perfecta,
tenemos el modelo de tiempo lgico, que permite inferir el orden sin recurrir a los relojes (vase el
ejemplo de la pgina 50).
MODELO DE FALLO
Pueden fallar tanto los procesos como el canal de comunicaciones. Tenemos la siguiente clasificacin de
fallos:

Fallos por omisin: No se logran realizar acciones que se supone que se pueden hacer.
o

Fallos por omisin de procesos: Fracasa la ejecucin de un proceso o se termina


inesperadamente (crash). En un sistema sncrono, estos fallos se detectan mediante
timeouts (el proceso no responde en el tiempo establecido), pero en uno asncrono,
ese timeout puede significar simplemente que tarda ms de la cuenta. Se conoce
como fallo-parada cuando los otros procesos pueden asegurar con certeza el fallo.

Se produce cuando el canal de


Fallos por omisin de comunicaciones:
comunicaciones no realiza el transporte de un mensaje (pierde los mensajes). El
problema suele estar en el buffer de salida o de entrada (falta de espacio), por lo que
podemos tener fallos por omisin de envo y fallos por omisin de recepcin.

En la figura 2.11 (pgina 52) puede verse la clasificacin de fallos por omisin.

Fallos arbitrarios: (o fallo bizantino). Puede ocurrir cualquier tipo de error. En el proceso se
omiten pasos deseables para el procesamiento o se realizan pasos no intencionados de
procesamiento. Estos fallos no pueden detectarse por la respuesta a las invocaciones. Pueden
ocurrir corrupcin de datos, envo de mensajes no existentes, repeticin de mensajes

Fallos de temporizacin: Se dan en los sistemas sncronos. Superan los lmites de tiempo
establecidos (vase la clasificacin de la figura 2.12 (pgina 53)). En los asncronos no podemos
hablar de fallos de temporizacin, porque el exceso puede deberse simplemente a un retardo
en la comunicacin. En las comunicaciones multimedia, es imprescindible evitar este tipo de
errores.

Enmascaramiento de fallos: Los fallos pueden ser enmascarados (ocultados) si sabemos de


antemano lo que puede suceder (ej: se rompe un disco pero tenemos otros redundantes que lo
sustituyan inmediatamente). El enmascaramiento puede darse ocultando el fallo o
convirtindolo en otro ms aceptable (ej: la suma de chequeo detecta errores arbitrarios
(mensajes corruptos) y puede convertirlos en fallos por omisin).

Fiabilidad y comunicacin uno a uno: Se conoce como comunicacin fiable a aquella que es
vlida (cualquier mensaje en el buffer de salida llegar al buffer de entrada) e ntegro (no se
duplican ni alteran mensajes). Las amenazas a esta integridad provienen de protocolos que

retransmitan mensajes pero que no rechace duplicados o usuarios malintencionados que


duplican o alteran mensajes.
MODELO DE SEGURIDAD
Debe darse asegurando y protegiendo los procesos y canales de comunicacin. Veamos cada aspecto
uno por uno:

Proteccin de objetos: Los objetos del servidor tienen una serie de derechos de acceso, que
determinan quin puede invocar qu operaciones del servidor. Los beneficiarios de estos
derechos son los usuarios. Cada invocacin y cada resultado est asociado a la autoridad con la
que se ordena, llamada principal (puede ser un usuario o un proceso (en el ejemplo de la
pgina 55 (Figura 2.13) la invocacin proviene de un usuario y el resultado de un servidor)). El
servidor debe verificar la identidad y derechos del principal que invoca a la operacin. El cliente
debe comprobar la identidad del principal que le enva el resultado.

Asegurar procesos y sus interacciones: El envo de mensajes est expuesto a ataques.


Asimismo, las interfaces de los servidores y procesos parejos tambin estn expuestas. Debe
protegerse de posibles ataques.

El enemigo: Debe concebirse al enemigo en los peores casos (enva mensajes a cualquier
proceso, tiene todos los derechos), para hacer un modelo de seguridad fiable. Incluso se debe
prever que el enemigo pueda ser un computador que pertenece a la propia red.

Amenazas a procesos: Un proceso puede recibir mensajes de otros procesos de los


que no pueda averiguar su identidad. Incluso aunque el mensaje llevase identidad (ej:
direccin IP), la misma podra estar falseada por el atacante. Esto representa una
amenaza para el correcto funcionamiento de los servidores y clientes (el atacante
puede hacerse pasar por un cliente que enve una peticin o por un servidor que enve
un resultado falso).

Amenazas a los canales de comunicacin: Los mensajes que se transmiten pueden ser
interceptados en el trayecto, provocando que el atacante los elimine, los altere o los
sustituya por un mensaje propio (vase la Figura 2.14 (pgina 55)). Incluso podra
almacenarse el mensaje para ejecutarlo posteriormente repetidas veces (ej: peticin
de transferencia de dinero). Deben utilizarse canales seguros.

Vencer amenazas de seguridad: Veamos algunas tcnicas:


o

Criptografa y secretos compartidos: El secreto compartido se basa en un dato que


slo ambos componentes de la comunicacin conocen y que se transmite para
comprobar la correcta identidad del interlocutor. La criptografa permite encriptar los
mensajes; es decir, codificndolos de tal forma que slo se puedan recuperar
mediante claves secretas consistentes en nmeros grandes difciles de deducir).

Autenticacin: Lo anterior forma la base de la autenticacin; es decir, incluir un


fragmento encriptado con el suficiente contenido del mensaje como para asegurar su
autenticidad. El destinatario desencripta este fragmento y lo compara con la parte
correspondiente no encriptada (deben coincidir).

Canales seguros: Es un canal que comunica dos procesos y que cada uno de ellos
conoce bien la identidad del otro. Adems, asegura la privacidad y la integridad y en

cada mensaje se incluye un sello temporal que evita que sea reenviado o reordenado.
Ejemplos de canales seguros son las VPN y el SSL.

Otras posibilidades de amenaza de un enemigo: Ya habamos visto anteriormente estas otras


dos posibilidades:
o

Denegacin de servicio: Consiste en el envo excesivo de invocaciones sin sentido, lo


que sobrecarga los recursos fsicos afectados. Puede lograr retrasar o impedir
actuaciones legtimas de otros usuarios.

Cdigo mvil: El cdigo mvil puede convertirse en un caballo de Troya que pone en
riesgo al destinatario. Aqu hay muchas posibilidades de ataque, por lo que debe
tenerse especial cuidado.

Aplicaciones de los modelos de seguridad: Aunque la importancia de la seguridad es algo


evidente, no siempre se toma en cuenta. El uso de las tcnicas conlleva un coste adicional y los
anlisis deben ser muy rigurosos, ya que las amenazas pueden llegar desde muchos sitios. Por
ello es necesario un modelo de seguridad, que clasifique y analice los riesgos a los que el
sistema est expuesto.

Vous aimerez peut-être aussi