INTRODUCCIÓN A LOS SISTEMAS
DISTRIBUIDOS
Nuestro propósito es el de transmitir una visión clara de la naturaleza de los sistemas distribuidos y de los desafíos que deben ser considerados.
Un
sistema distribuido es aquel en el que los componentes localizados en computadores,
conectados en red, comunican y coordinan sus acciones únicamente mediante el
paso de mensajes.
Existen redes de
computadores como Internet, como lo son las muchas redes de las que se compone.
Las redes de teléfonos móviles, las redes corporativas, todas, tanta separadas
como combinadas comparten características esenciales que las hacen elementos
importantes para su estudio bajo el titulo de sistemas distribuidos.
Hay tres ejemplos
de sistemas distribuidos:
* Internet. * Una Intranet. * La computación móvil y
ubicua.
Compartir recursos
es uno de los motivos principales para construir sistemas distribuidos. Estos
pueden ser administrados por servidores y accedidos por clientes o pueden ser
encapsulados como objetos y accedidos por otros objetos clientes.
Recurso:
se extiende desde los componentes hardware como los discos y las impresoras
hasta las entidades de software definidas como ficheros, base de datos y
objetos de datos de todos los tipos.
Los desafíos que
surgen en la construcción de sistemas distribuidos son la heterogeneidad de sus
componentes, su carácter abierto, el tratamiento de los fallos, la concurrencia
de sus componentes y la transparencia.
Consecuencias
significativas:
Concurrencia:
la ejecución de programas concurrentes es la norma. La capacidad del sistema
para manejar recursos compartidos se puede incrementar añadiendo mas recursos
(ej. Computadores) a la red. La coordinación de programas que comparten
recursos y se ejecutan de forma concurrente es también un tema importante y
recurrente.
Inexistencia
de reloj global: cuando los
programas necesitan cooperar coordinan sus acciones mediante el intercambio de
mensajes. Pero resulta que hay limites a la precisión con lo que los computadores
en una red pueden sincronizar sus relojes, no hay una única noción global del
tiempo correcto. Esto es una consecuencia directa del hecho que la única
comunicación se realiza enviando mensajes a través de la red.
Fallos
independientes: todos los
sistemas informáticos pueden fallar y los diseñadores de sistemas tienen la
responsabilidad de planificar las consecuencias de posibles fallos. Los
sistemas distribuidos pueden fallar de nuevas formas. Los fallos en la red
producen el aislamiento de los computadores conectados a él, pero eso no significa que detengan su ejecución.
EJEMPLOS DE SITEMAS DISTRIBUIDOS
Están
basados en redes de computadores conocidos y utilizados ampliamente:
INTERNET
Internet
es una vasta colección de redes de computadas de diferentes tipos
interconectados.
El
diseño y la construcción de los mecanismos de comunicación Internet (los
protocolos Internet) es una
realización técnica fundamental, que permite que un programa que se está
ejecutando en cualquier parte dirija mensajes a programas en cualquier otra
parte.
Internet
es también un sistema distribuido muy grande, permite a los usuarios hacer uso
de servicios como el World Wide Web, el correo electrónico, y la transferencia
de ficheros. A veces se confunde incorrectamente el Web con Internet. El
conjunto de servicios es abierto, puede ser extendido por la adición de los
servidores y nuevos tipos de servicios. Los proveedores de servicios de
Internet (ISP) son empresas que proporcionan enlaces de módem y otros tipos de
conexión a usuarios individuales y
pequeñas organizaciones. Las intranets están enlazadas conjuntamente por
conexiones troncales (backbone). Una conexión o red troncal es un enlace de red
con una gran capacidad de transmisión, que puede emplear conexiones de satélite, cables de fibra
óptica y otros circuitos de gran ancho de banda.
En
Internet hay disponibles servicios multimedia, que permite a los usuarios el
acceso de datos de audio y video.
INTRANETS
Una
Intranet es una porción de Internet que es administrada separadamente y que
tiene un límite que puede ser configurado para hacer cumplir políticas de
seguridad local. Está compuesta de varias redes de área local (LANs) enlazadas
por conexiones backbone. La configuración de red de una Intranet particular es
responsabilidad de la organización que la administra. Una Intranet está
conectada a Internet por medio de un encaminador (router), lo que permite a los
usuarios hacer uso de servicios de otro sitio y acceder a los servicios que
ella proporciona a los usuarios de otras intranets. Muchas organizaciones
necesitan proteger sus propios servicios frente al uso no autorizado de
programa nocivos.
El
papel del cortafuegos es proteger una intranet impidiendo que entren o salgan mensajes
no autorizados.
Algunas
organizaciones no desean conectar sus redes internas a Internet. La solución
que se adopta es realizar una intranet, pero sin conexiones a Internet.
COMPUTACIÓN
MOVIL Y UBICUA
Los
avances tecnológicos han llevado cada vez más a la integración de dispositivos
de computación pequeños y portátiles en
sistemas distribuidos. Estos dispositivos incluyen:
- Computadores portátiles.
- Dispositivos de mano (handheld),
entre los que se incluyen asistentes digitales personales (PDA), teléfonos
móviles, etc.
- Dispositivos que se pueden llevar
puestos.
- Dispositivos insertados en
aparatos.
La
facilidad de transporte en muchos de estos dispositivos, junto con su capacidad
para conectarse adecuadamente a redes en diferentes lugares, hace posible la computación
móvil. Los usuarios acceden a los recursos mediante los
dispositivos que llevan con ellos.
Y se
está incrementando la posibilidad de que utilicen recursos, como impresoras,
que están suficientemente próximos a donde se encuentren. Esto último se conoce
como computación independiente de posición.
Computación
ubicua es la utilización concertada de muchos dispositivos de computación
pequeños y baratos que están presentes en los entornos físicos de los usuarios,
sin que estos se den cuenta de ellos. O sea, su comportamiento computacional
estará ligado con su función física de forma íntima y transparente.
La
computación ubicua y móvil se solapan. Pero, son distintas. La computación
ubicua podrá beneficiar a los usuarios mientras permanecen en un entorno
sencillo como su casa o un hospital. De forma similar, la computación móvil
tiene ventajas si sólo se consideran computadores convencionales y dispositivos
como computadores portátiles e impresoras.
RECURSOS COMPARTIDO Y WEB
Los
usuarios compartimos recursos hardware. Pero es mucho más significativo para
los usuarios compartir recursos de alto nivel que forman parte de sus
aplicaciones y su trabajo habitual y sus actividades sociales.
Los
patrones de compartir recursos varían en su alcance y cuán estrechamente
trabajan juntos los usuarios. En un extremo, una máquina de búsqueda en el Web
proporciona una función para los usuarios en todo el mundo, los usuarios no
necesitan establecer contacto con los demás directamente. En el otro extremo,
en un sistema de trabajo cooperativo mantenido por computador (CSCW, computer-supported
cooperative working), un grupo de usuarios particulares determina qué
mecanismos debe proporcionar el sistema para coordinar sus acciones.
Utilizamos
el término servicio para una parte diferente de un sistema de
computadores que gestiona una colección de recursos relacionados y presenta su
funcionalidad a los usuarios y aplicaciones.
El
hecho de que los servicios limiten el acceso a los recursos a un conjunto bien
definido de operaciones, refleja la organización física de los sistemas
distribuidos. Los recursos en un sistema distribuido están encapsulados
físicamente con los computadores y sólo pueden ser accedidos desde otros
computadores a través de comunicación. Para que se compartan de forma efectiva,
cada recurso debe ser gestionado por un programa que ofrece una interfaz de
comunicación permitiendo que se acceda y actualice el recurso de forma fiable y
consistente.
El
término servidor se refiere a un programa en ejecución (un proceso)
en un computador en red que acepta peticiones de programas que se están
ejecutando en otros computadores para realizar un servicio y responder
adecuadamente. Los procesos solicitantes son llamados clientes. Cuando
un cliente envía una petición para que se realice una operación, decimos que el
cliente invoca una operación del
servidor. Se llama invocación remota a una interacción completa entre un cliente y
un servidor, desde el instante en el que el cliente envía su petición hasta que
recibe la respuesta del servidor.
Los
términos cliente y servidor se
aplican a los roles desempeñados en una
única solicitud. Ambos son distintos, en muchos aspectos, los clientes
son activos y los servidores pasivos, los servidores se están ejecutando
continuamente, mientras que los clientes sólo lo hacen el tiempo que duran las
aplicaciones de las que forman parte.
Muchos
sistemas distribuidos, aunque no todos, pueden ser construidos completamente en
forma de clientes y servidores que interaccionan. El World Wide Web. El correo
electrónico y las impresoras en red concuerdan con este modelo.
Un
navegador (browser) es un ejemplo de cliente. El navegador se comunica
con el servidor web para solicitar páginas.
EL WORLD WIDE WEB
Este es
un sistema para publicar y acceder a recursos y servicios a través de Internet.
Utilizando el software de un navegador web, como Netscape o Internet Explorer,
los usuarios utilizan el Web para interaccionar con un conjunto ilimitado de
servicios.
El Web
comenzó su vida en el centro europeo para la investigación nuclear (CERN),
Suiza, en 1989 como un vehículo para el intercambio de documentos entre una
comunidad de físicos. Una característica fundamental del Web es que proporciona
una estructura hipertexto entre los documentos que almacena. Esto
significa que los documentos tienen enlaces.
Es
fundamental para la experiencia del usuario en el Web que cuando encuentra una
imagen determinada o una parte de texto en un documento, esto estará acompañado
de enlaces a documentos relacionados y otros recursos. La estructura de los
enlaces pude de ser arbitrariamente compleja y el conjunto de recursos que
puede ser añadido es ilimitado, la “telaraña” (web) de enlaces está por consiguiente
repartida por todo el mundo (world-wide).
El Web
es un sistema abierto.
Primero,
su operación está basada en estándares de comunicación y en documentos estándar
que están publicados libremente e implementados ampliamente. Por ejemplo,
existen muchos tipos de navegador y existen muchas implementaciones de
servidores Web. Cualquier navegador conforme puede recuperar recursos de
cualquier servidor conforme.
Segundo,
el Web es abierto respecto a los tipos de recursos que pueden ser publicados y
compartidos en él. En su forma más simple, un recurso es una página web o algún
otro tipo de contenido que puede ser almacenado en un fichero y
presentado al usuario, como ficheros de programa, de imágenes, de sonido y
documentos en forma PostScript o PDF. Los usuarios necesitan un medio de ver
imágenes en este nuevo formato, pero los navegadores están diseñados para
acomodar la nueva funcionalidad de presentación en forma de aplicaciones colaboradoras
y conectores (plug-ins).
El Web,
ha evolucionado sin cambiar su arquitectura básica. El web está basado en tres
componentes tecnológicos de carácter estándar básicos:
Ø El lenguaje de etiqueta de hipertexto (HTML, Hypertext Markup
Language) es un lenguaje para especificar el contenido y el diseño de las
páginas que son mostradas por los navegadores.
Ø Localizadores Uniformes de Recursos (URL, Uniform Resource
Locator) que identifica documentos y otros recursos almacenado como parte
del Web
Ø Una arquitectura de sistema cliente-servidor, con reglas estándar
para interacción (el protocolo de transferencia hipertexto-http, HyperText
Transfer Protocol) mediante la cual los navegadores y otros clientes
obtienen documentos y otros recursos de los servidores web. Una característica
importante es que los usuarios pueden localizar y gestionar sus propios
servidores web en cualquier parte de Internet.
A
continuación se detallaran los componentes
v
HTML el lenguaje de etiquetado de hipertexto se utiliza para
especificar el texto e imágenes que forman el contenido de una página web, y
para especificar cómo serán formateados para la presentación al usuario. Una
página web contiene elementos estructurados como cabeceras, párrafos, tablas e
imágenes. HTML se utiliza también para especificar enlaces y qué recursos están
asociados con ellos.
Los usuarios producen HTML a mano, utilizando un editor de texto
estándar.
Un ejemplo típico de texto HTML puede ser:
< IMG SRC = http://www.cdk3.net/WebExample/Images/earth.jpg> 1
< P > 2
¡Bienvenido a la Tierra! Los visitantes pueden estar interesados
también en echar un
vistazo a la
3
< A HREF. = http://www.cdk3.net/WebExample/moon.html >Luna</A> 4
< P >
5
( etcétera).
6
Este texto HTML se almacena en un fichero al que puede acceder un
servidor web, supongamos que es el fichero earth.html . Un navegador
recupera el contenido de este fichero desde un servidor web, en este caso un
servidor es un computados llamado www.cdk3.net. El navegador lee el
contenido devuelto por el servidor y lo organiza en texto formateado y en
imágenes presentadas en una página web en la forma habitual. Sólo el navegador,
no el servidor, interpreta el texto HTML. Pero el servidor debe informar al
navegador sobre el tipo de contenido que devuelve, para distinguirlo de, por
ejemplo, un documento de PostScript. El servidor puede deducir el tipo de
contenido de la extensión del fichero .html
Las directivas HTML, conocidas como etiquetas,
están encerradas entre ángulos como <P>.
La
línea 1 del ejemplo identifica un fichero que contiene una imagen para la
presentación. Su URL es http://www.cdk3.net/WebExample/Images/earth.jpg.
Las líneas 2 y 5 son una directiva de
comienzo de un nuevo párrafo cada una. Las líneas 3 y 6 contienen texto que
será mostrado por el navegador en el formato estándar
de párrafo.
La línea 4 especifica un
enlace en la página. Contiene la Palabra
“Luna” rodeada por dos etiquetas HTML relacionadas < A HREF...> y
</A>. El texto comprendido entre dichas etiquetas es lo que aparece en el
enlace tal como se presenta en la página web. La mayoría de los navegadores
están configurados para mostrar el texto de los enlaces subrayados, asi que lo
que el usuario verá en el párrafo es:
¡Bienvenido a la Tierra! Los visitantes pueden estar interesados
en echar un vistazo a la Luna.
El navegador registra la asociación entre el
texto mostrado del enlace y el URL contenido en la etiqueta <A HREF...>,
en este caso:
http://www.cdk3.net/WebExample/moon.html
Cuando
el usuario selecciona un texto, el navegador localiza
el recurso identificado por el correspondiente URL y se lo presenta. En el
ejemplo, el recurso es un fichero HTML que especifica una página sobre la Luna.
v
URLs. El
propósito de un URL es identificar un recurso de tal forma que permita al
navegador localizarlo.
Cada URL, en su forma global, tiene dos componentes:
Esquema: localización-específica-del-esquema.
El primer componente, el esquema, declara qué tipo de URL
es. Se precisan los URLs para especificar posiciones de una variedad de
recursos y también para especificar una variedad de protocolo de comunicación
para recuperarlos.
El Web es abierto con respecto a los tipos de recursos que pueden
ser utilizados para acceder, mediante los designadores de esquema de los URLs.
Si alguien inventa un nuevo tipo de recurso llamémoslo artefacto. Como
es lógico, los navegadores deben disponer de la capacidad para utilizar el
nuevo protocolo artefacto, pero esto se puede conseguir añadiendo una
aplicación colaboradora o conector.
Un URL http tiene dos tareas importantes que hacer: identificar
qué servidor Web mantiene el recurso, e identificar cuál de los recursos del
servidor es solicitado.
En general, los URLs de http son de la forma:
http://nombredelservidor
[ :puerto]
[/nombredelpathdelservidor]
[?argumentos]
en el que los elementos entre corchetes son opcionales. Un URL de
http siempre comienza con “ http://” seguido por un nombre de servidor,
expresado como un nombre del Servicio de Nombre de Dominio (DNS, Domain
Name Service). El nombre DNS del servidor esta seguido opcionalmente por el
nombre del “puerto” en el que el servidor escucha las solicitudes. Después
viene un nombre de recorrido opcional del recurso del servidor. Si éste no
aparece se solicita la página web por defecto del servidor. Por último, el URL
finaliza opcionalmente con un conjunto de argumentos, por ejemplo, cuando un
usuario envía las entradas en una forma como una página de consulta de una
máquina de búsqueda.
Considérese los URLs:
http://www.w3.org/protocols/Activity.html
http://www.google.com/search?q=kindberg
Pueden
ser separados de la forma siguiente:
Nombre
del servidor de DNS Ruta en el servidor Argumentos
www.cdk3.net (por defecto) (ninguno)
www.w3.org Potocols/Activity.html (ninguno)
www.google.com
search q=kindberg
El
primer URL indica la página por defecto proporcionada por www.cdk3.net. El
siguiente identifica un fichero en el servidor www.w3.org, cuyo nombre de recorrido es
Protocols/Activity.html. El tercer URL especifica una consulta a una
máquina de búsqueda.
Pueden haber observado también la presencia de un ancla al final
de un URL, las cuales no son parte de los URL sino que están definidas como una
parte de la especificación HTML. Únicamente los navegadores interpretan anclas,
los navegadores siempre recuperan páginas web completas de los servidores, no
partes de ellas indicadas por anclas.
El método para publicar un recurso en la web todavía es difícil de
manejar y normalmente precisa intervención humana.
Publicación de un recurso: un
usuario debe colocar, en primer lugar, el
correspondiente fichero en un directorio al que pueda acceder al
servidor web. Existen unas ciertas convenciones para nombres de recorrido que
los servidores reconocen.
v
HTTP. (Protocolo de
Transferencia de Hiper Texto) Define
las formas en las que los navegadores y otros tipos de clientes interaccionan
con los servidores web. Principales
características:
Interacciones petición-respuesta: HTTP
es un protocolo de petición-respuesta. El cliente envía un mensaje de petición
al servidor que contiene el URL del recurso solicitado. El servidor localiza el
nombre de recorrido y, si existe, devuelve el contenido del fichero en un
mensaje de respuesta al cliente. En caso contrario, devuelve un mensaje de
error.
Tipos de contenido: cuando un navegador hace una petición, incluye una lista de los
tipos de contenido que prefiere. El servidor puede ser capaz de tener esto en
cuenta cuando devuelve el contenido al navegador. El servidor incluye el tipo de contenido en el mensaje de respuesta
de forma que el navegador sabrá cómo procesarlo. Las cadenas de caracteres que
indican el tipo de contenido se llaman tipos MIME, y están estandarizados en el
RFC 1521. el conjunto de acciones que un navegador tomará para un tipo de
contenido dado es configurable, y los lectores deben preocuparse de comprobar
estos defectos en sus propios navegadores.
Un recurso por solicitud: en la versión 1.0 de HTTP el cliente solicita un recurso por cada
petición HTTP. Si una página web
contiene nueve imágenes, por ejemplo, el navegador realizará un total de diez
peticiones separadas para obtener el contenido completo de la página.
Control de acceso simple: cualquier usuario con una conexión de red a un servidor web puede
acceder a cualquiera de los recursos publicados. Si los usuarios desean
restringir el acceso a un recurso, pueden configurar el servidor. Los usuarios
correspondientes deben probar entonces que tienen derecho para acceder al
recurso, por ejemplo tecleando una contraseña (password).
v
Características más
avanzadas, servicios y páginas dinámicas. Hasta
ahora hemos descrito cómo los usuarios pueden publicar páginas web y otros
contenidos almacenados en ficheros Web. El contenido puede cambiar en el
tiempo, pero es lo mismo para
cualquiera. Sin embargo, mucha de la experiencia de los usuarios del Web es la
de los servicios con los que el usuario puede interaccionar, el navegador envía
una petición HTTP a un servidor web, que contiene los valores enviados por el
usuario.
Puesto que el resultado de la petición depende de los datos
introducidos por el usuario, el servidor debe procesar dichos datos. Por
tanto, el URL o su componente inicial
representa un programa en el servidor, no un archivo. Si los datos
introducidos por el usuario son pocos, entonces son enviados como el componente
final del URL, siguiendo a un carácter "?". Por ejemplo, una
solicitud que contenga el URL siguiente llama a un programa llamado search en www.google.com y especifica una consulta para
kindberg:http://www.google.com/search?q=kindberg.
El programa <<search>> produce como resultado texto
HTML, y el usuario verá una lista de páginas que contienen la palabra kindberg.
La diferencia entre el contenido estático localizado en un fichero y el
contenido que es generado dinámicamente es transparente para el navegador.
Un programa que se ejecuta en los servidores web para generar
contenido para sus clientes se suele llamar, a menudo, programa de Interfaz de
Pasarela Común (CGI). Un programa CGI puede tener una funcionalidad específica
de la aplicación. El programa consultará o modificará una base de datos cuando
procesa la solicitud.
Código descargado: un
programa CGI se ejecuta en el servidor. A veces los diseñadores de servicios
web precisan algún código relacionado con el servicio para ejecutar en el
navegador, en el computador del usuario. Por ejemplo, código escrito en
Javascript se descarga a menudo con un formulario web para proporcionar una
interacción con el usuario de mejor
calidad que la proporcionada por los
artefactos estándar de HTML.
Como contraste, un applet es una pequeña aplicación que
descarga automáticamente el navegador y se ejecuta cuando se descarga la página
correspondiente. Los applets pueden acceder a la red y proporcionar
interfaces de usuario específicas, utilizando las posibilidades del lenguaje.
v Discusión sobre el web: el extraordinario
éxito del web se basa en la facilidad con la que pueden publicarse recursos,
una estructura de hipertexto apropiada para la organización de muchos tipos de
información, y la extensibilidad arquitectónica del sistema.
El éxito del web contradice algunos principios de diseño. Primero,
su modelo de hipertexto es deficiente en algunos aspectos. Si se borra o mueve
algún recurso, ocurre que los llamados enlaces descolgados a este
recurso permanecen, causando cierta frustración a los usuarios.
También aparece el problema habitual de los usuarios perdidos
en el hiperespacio. Los motores de búsqueda claramente imperfectos a la
hora de generar lo que quiere concretamente el usuario. Los metadatos
describirían los atributos de los recursos web, y sería leídos por herramientas
que asistirían a los usuarios que procesaran recursos web masivamente,
tal como ocurre al buscar y recopilar listas de enlaces relacionados.
Existe una necesidad creciente de intercambio de muchos tipos de
datos estructurados en el Web, pero HTML
se encuentra limitado en que no
es extensible a aplicaciones más allá de la <<inspección>> de la
información. HTML consta de un conjunto estático de estructuras tales como los
párrafos, que se limitan a indicar la forma en que se presentan los datos a los
usuarios.
Como arquitectura del sistema, el web plantea problemas de escala.
Los servidores web más populares pueden experimentar muchos accesos por
segundo, y como resultado la respuesta a los usuarios se ralentiza.
Finalmente, una página
web no siempre es una interfaz de usuario satisfactoria. Los elementos de
diálogo definidos para HTML son limitados, y los diseñadores incluyen a menudo
en las páginas web, pequeñas aplicaciones, o applets, o bien muchas imágenes
para darles una función y apariencia más aceptable. Consecuentemente el tiempo
de carga se incrementa.
DESAFIOS.
Muchos
de los desafíos que se discuten en esta sección ya están resueltos, pero los
futuros diseñadores necesitan estar al tanto y tener cuidado de considerarlos.
HETEROGENEIDAD.
Internet permite que los usuarios accedan a servicios y ejecuten
aplicaciones sobre un conjunto heterogéneo de redes y computadores. Esta
heterogeneidad (es decir, variedad y diferencia) se aplica a todos los
siguientes elementos:
o Redes.
o Hardware de computadores.
o Sistemas operativos.
o Lenguajes de programación.
o Implementaciones de diferentes desarrolladores.
v
Middleware: el término middleware
se aplica al estrato software que provee una abstracción de programación, así
como un enmascaramiento de la heterogeneidad subyacente de las redes, hardware,
sistemas operativos y lenguajes de programación. La mayoría de middleware se implementa sobre protocolos de internet,
enmascarando éstos la diversidad de redes existentes.
Aún así cualquier middleware trata con las diferencias de sistema operativo y
hardware. El midleware proporciona un modelo computacional uniforme al enlace
de los programadores de servidores y aplicaciones distribuidas. Los posibles
modelos incluyen invocación sobre
objetos remotos, acceso remoto mediante SQL y procesamiento distribuido de
transacciones.
v Heterogeneidad y código civil: el
término código móvil se emplea para referirse al código que puede ser
enviado desde un computador a otro y ejecutarse en éste. Dado que el conjunto
de instrucciones de un computador depende del hardware, el código de nivel de
máquina adecuado para correr en un tipo de computador no es adecuado para
ejecutarse en otro tipo.
La aproximación de máquina virtual provee un modo de crear
código ejecutable sobre cualquier hardware: el compilador de un lenguaje
concreto generará código para una máquina virtual que en lugar de código
apropiado para una hardware particular.
EXTENSIBILIDAD.
La extensibilidad de un sistema de cómputo es la característica
que determina si el sistema puede ser extendido y reimplementado en diversos
aspectos. La extensibilidad de los sistemas distribuidos se determina en primer
lugar por el grado en el cual se pueden añadir nuevos servicios de compartición
de recursos y ponerlos a disposición para el uso por una variedad de programas
cliente.
No es
posible obtener extensibilidad a menos que la especificación y la documentación
de las interfaces software clave de los componentes de un sistema estén
disponibles para los desarrolladores de software. Es decir, que las interfaces
clave estén publicadas. Este procedimiento es similar a una
estandarización, que por lo demás suelen ser lentos y complicados.
Los
sistemas diseñados de este modo para dar soporte a la compartición de recursos
se etiquetan como sistemas distribuidos abiertos para remarcar el hecho
de ser extensibles. Pueden ser extendidos en el nivel hardware mediante la
inclusión de computadores a la red y en el nivel software por la introducción
de nuevos servicios y la reimplementación de los antiguos, posibilitando a los
programas de aplicación la compartición de recursos. Otro beneficio más, citado
a menudo, de los sistemas abiertos es su independencia de proveedores
concretos.
En resumen:
·
Los sistemas abiertos se
caracterizan porque sus interfaces están publicadas.
·
Los sistemas distribuidos
abiertos se basan en la providencia de un mecanismo de comunicación uniforme e
interfaces públicas para acceder a recursos compartidos.
·
Los sistemas distribuidos
abiertos pueden construirse con hardware y software heterogéneo, posiblemente
de diferentes proveedores. Sin embargo, la conformidad con el estándar
publicado de cada componente debe contrastarse y verificarse cuidadosamente si
se desea que el sistema trabaje correctamente.
SEGURIDAD.
La
seguridad de los recursos de información tiene tres componentes:
confidencialidad, integridad y disponibilidad.
En un
sistema distribuido, los clientes envían peticiones de acceso a datos
administrados por servidores, lo que trae consigo enviar información en los
mensajes por la red. Por ejemplo:
1. Un médico puede
solicitar acceso a los datos hospitalarios de un paciente o enviar
modificaciones sobre ellos.
2. En comercio electrónico y banca, los usuarios envían su número de
tarjeta de crédito a través de Internet.
La seguridad no sólo es cuestión de
ocultar los contenidos de los mensajes, también consiste en conocer con certeza
la identidad del usuario u otro agente en nombre del cual se envía el mensaje.
Existen
dos desafíos de seguridad que no han sido cumplimentados completamente:
Ataques de denegación de servicio: otro problema de seguridad ocurre cuando un usuario desea
obstaculizar un servicio por alguna razón. Esto se obtiene al bombardear el
servicio con un número suficiente de peticiones inútiles de modo que los
usuarios serios sean incapaces de utilizarlo. A esto se le denomina ataque de denegación
de servicio.
Seguridad del código móvil: el
código móvil necesita ser tratado con cuidado. Suponga que alguien recibe un
programa ejecutable adherido a un correo electrónico: los posibles efectos al
ejecutar el programa son impredecibles: por ejemplo, pudiera parecer que
presentan un interesante dibujo en la pantalla cuando en realidad están
interesados en el acceso a los recursos locales, o quizás pueda ser parte de un
ataque de denegación de servicio.
ESCALABILIDAD.
Los
sistemas distribuidos operan efectiva y eficientemente en muchas escalas
diferentes, desde pequeñas intranets a Internet. Se dice que un sistema es escalable si
conserva su efectividad cuando ocurre un incremento significativo en el número
de recursos y el número de usuarios. Internet proporciona un ejemplo de un
sistema distribuido en el que el número de computadores y servicios experimenta
un dramático incremento.
El diseño de los sistemas distribuidos presenta los siguientes
retos:
Control del costo de los recursos físicos: según crece la demanda de un recurso, debiera ser posible
extender el sistema, a un consto razonable, para satisfacerla. Para un que
sistema con n usuarios fuera escalable, la cantidad de recursos físicos
necesarios para soportarlo debiera ser como mínimo O(n), es decir proporcional
a n.
Control de las pérdidas de prestaciones: considere la
administración de un conjunto de datos cuyo tamaño es proporcional al número de
usuarios o recursos del sistema. Los algoritmos que emplean estructuras
jerárquicas se comportan mejor frente al crecimiento de la escala que los
algoritmos que emplean estructuras lineales. Pero incluso con estructuras
jerárquicas un incremento en tamaño traerá consigo pérdidas en prestaciones: el
tiempo que lleva acceder a datos estructurados jerárquicamente es O(log n),
donde n es el tamaño del conjunto de datos. Para que un sistema sea escalable,
la máxima pérdida de prestaciones no debiera ser peor que esta medida.
Prevención de desbordamiento de recursos software: no hay una solución idónea para este problema.
Es difícil predecir la demanda que tendrá que soportar un sistema con años de
anticipación. Además, sobredimensionar para prever el crecimiento futuro
pudiera ser peor que la adaptación a un cambio cuando se hace necesario; las
direcciones internet grandes ocupan espacio extra en los mensajes, y en la
memoria de los computadores.
Evitación de cuellos de botella de prestaciones: en general, para evitar cuellos
de botella de prestaciones, los algoritmos deberían ser descentralizados.
TRATAMIENTO DE FALLOS.
Los
sistemas computacionales a veces fallan, cuando aparecen fallos en el hardware
o el software, los programas pueden producir resultados incorrectos o pudieran
parar antes de haber completado el cálculo pedido.
Los
fallos en un sistema distribuido son parciales; es decir, algunos componentes
fallan mientras otros siguen funcionando.
Técnicas para tratar fallo:
Detección de fallos: se pueden utilizar sumas de comprobación (cheksums) para
detectar datos corruptos en un mensaje o un archivo. Es difícil o incluso
imposible detectar algunos fallos que no pueden detectarse pero que sí pueden
esperarse.
Enmascaramiento de fallos: algunos fallos que han sido
detectados pueden ocultarse o atenuarse. Ejemplos de ocultación de fallos son:
1. Los mensajes pueden retransmitirse cuando falla la recepción.
2. Los archivos con datos pueden escribirse en una pareja de discos
de forma que si uno está deteriorado el otro seguramente está en buen estado.
Eliminar un mensaje corrupto es un ejemplo de atenuar un fallo
(pudiera retransmitirse de nuevo).
Tolerancia de fallo: la mayoría de los servicios en internet exhiben fallo; es posible
que no sea práctico para ellos pretender detectar y ocultar todos los fallos
que pudieran aparecer en una red tan grande y con tantos componentes. Sus
clientes pueden diseñarse para tolerar ciertos fallos, lo que implica que
también los usuarios tendrán que tolerarlos.
Recuperación frente a fallos: la recuperación implica el diseño
de software en el que, tras una caída del servidor, el estado de los datos
pueda reponerse o retractarse (roll back) a una situación anterior. En
general, cuando aparecen fallos los cálculos realizados por algunos programas
se encontrarán incompletos y al actualizar
datos permanentes (archivos e información ubicada ene el almacenamiento
persistente) pudiera encontrarse en un estado inconsciente.
Redundancia: puede lograrse que los servicios toleren fallos mediante empleo
redundante de componentes. Considere los siguientes ejemplos:
1. Siempre deberá haber al menos dos rutas diferentes entre
cualquiera dos routers (encaminadores) en internet.
2. En el Sistema de Nombres de Dominio, cada tabla de nombres se
encuentra replicada en dos servidores diferentes.
3. Una base de datos puede
encontrarse replicada en varios servidores para asegurar que los datos siguen
siendo accesibles tras el fallo de cualquier servidor concreto; los servidores
pueden diseñarse para detectar fallos entre sus iguales; cuando se detecta
algún error en un servidor se redirigen los clientes a los servidores
restantes.
Los sistemas distribuidos proporcionan un alto grado de
disponibilidad frente a los fallos del hardware. La disponibilidad de un
sistema mide la proporción de tiempo en que está utilizable. Cuando falla algún
componente del sistema distribuido solo resulta afectado el trabajo relacionado
con el componente defectuoso. Así como cuando un computador falla el usuario
puede desplazarse a otro, también puede iniciarse un proceso de servicio en
otra ubicación.
CONCURRENCIA.
Tanto los servicios como las
aplicaciones proporcionan recursos que pueden compartirse entre los clientes en
un sistema distribuido. Existe por lo tanto una posibilidad de que varios
clientes intenten acceder a un recurso compartido a la vez.
Cada objeto que represente un recurso compartido en un sistema
distribuido debe responsabilizarse de garantizar que opera correctamente en un
entorno concurrente. De este modo cualquier programador que recoge una
implementación de un objeto que no está concebido para su aplicación en un
entorno distribuido deberá realizar las modificaciones necesarias para que sea
seguro su uso en el entorno concurrente.
Para que un objeto sea seguro en un entorno concurrente, sus
operaciones deben sincronizarse de forma que sus datos permanezcan
consistentes. Esto puede lograrse mediante el empleo de técnicas conocidas como
los semáforos, que se usan en la mayoría de los sistemas operativos.
TRANSPARENCIA.
Se define transparencia como la
ocultación al usuario y al programador de aplicaciones de la separación de los
componentes en un sistema distribuido, de forma que se perciba el sistema como
un todo más que como una colección de componentes independientes. Las
implicaciones de la transparencia son de gran calado en el diseño del software
del sistema. Algunas transparencias:
Transparencia de acceso: que permite acceder a los recursos locales y remotos empleando
operaciones idénticas.
Transparencia de ubicación: que permite acceder a los
recursos sin conocer su localización.
Transparencia de concurrencia: que permite que varios procesos
operen concurrentemente sobre recursos compartidos sin interferencia mutua.
Transparencia de replicación: que permite utilizar múltiples
ejemplares de cada recurso para aumentar la fiabilidad y las prestaciones sin
que los usuarios y los programadores de aplicaciones necesiten su conocimiento.
Transparencia frente a fallos: que permite ocultar los fallos, dejando que los usuarios y
programas de aplicación completen sus tareas a pesar de fallos de hardware o de
los componentes software.
Transparencia de movilidad:
que permite la reubicación de recursos y clientes en un sistema sin afectar la
operación de los usuarios y los programas.
Transparencia de prestaciones:
que permite reconfigurar el sistema para
mejorar las prestaciones según su carga.
Transparencia al escalado: que permite al sistema y a las
aplicaciones expandirse en tamaño sin cambiar la estructura del sistema o los
algoritmos de aplicación.
Las dos más importantes son transparencia de acceso y la
transparencia de ubicación; su presencia o ausencia afecta principalmente a la
utilización de recursos distribuidos. A veces se les da nombre conjunto de transparencia
de red.
FIABILIDAD
Una de las ventajas claras
que nos ofrece la idea de sistema distribuido es que el funcionamiento de todo
el sistema no debe estar ligado a ciertas máquinas de la red, sino que
cualquier equipo pueda suplir a otro en caso de que uno se estropee o falle;
otro tipo de redundancia más compleja se refiere a los procesos. Las tareas
críticas podrían enviarse a varios procesadores independientes, de forma que el
primer procesador realizaría la tarea normalmente, pero ésta pasaría a
ejecutarse en otro procesador si el primero hubiera fallado.
COMUNICACIÓN
La comunicación entre
procesos en sistemas con un único procesador se lleva a cabo mediante el uso de
memoria compartida entre los procesos. En los sistemas distribuidos, al no
haber conexión física entre las distintas memorias de los equipos, la
comunicación se realiza mediante la transferencia de mensajes.
EL
ESTÁNDAR ISO OSI
Para el envío de mensajes
se usa el estándar ISO OSI (interconexión de sistemas abiertos), un modelo por
capas para la comunicación de sistemas abiertos. Las capas proporcionan varias
interfaces con diferentes niveles de detalle, siendo la última la más general.
El estándar OSI define las siguientes siete capas: física, enlace de datos,
red, transporte, sesión, presentación y aplicación.
El modelo OSI distingue
dos tipos de protocolos, los orientados hacia las conexiones y los protocolos
sin conexión. En los primeros, antes de cualquier envío de datos se requiere
una conexión virtual, que tras el envío deben finalizar. Los protocolos sin conexión
no requieren este paso previo, y los mensajes se envían en forma de datagramas.
MODO DE
TRANSMISIÓN ASÍNCRONA ATM
El modo de transmisión
asíncrona o ATM proporciona un rápido modo de transmisión. Las altas
velocidades se alcanzan prescindiendo de la información de control de flujo y
de control de errores en los nodos intermedios de la transmisión. ATM usa el
modo orientado a conexión, y permite la transmisión de diferentes tipos de
información, como voz, vídeo, datos, etc.
El modelo cliente-servidor
basa la comunicación en una simplificación del modelo OSI. Sólo se usarán tres
capas: física (1), enlace de datos (2) y solicitud/respuesta (5). Las
transferencias se basan en el protocolo solicitud/respuesta y se elimina la
necesidad de conexión.
RPC
Otro paso en el diseño de
un sistema operativo distribuido plantea las llamadas a procedimientos remotos
o RPCs. Los RPC amplían la llamada local a procedimientos, y los generalizan a
una llamada a un procedimiento localizado en cualquier lugar de todo el sistema
distribuido. En un sistema distribuido no se debería distinguir entre llamadas
locales y RPCs, lo que favorece en gran medida la transparencia del sistema.
La limitación del RPC más
clara en los sistemas distribuidos es que no permite enviar una solicitud y
recibir respuesta de varias fuentes a la vez, sino que la comunicación se
realiza únicamente entre dos procesos. Por motivos de tolerancia a fallos,
bloqueos, u otros, sería interesante poder tratar la comunicación en grupo.
SINCRONIZACIÓN
La sincronización en
sistemas de un único ordenador no requiere ninguna consideración en el diseño
del sistema operativo, ya que existe un reloj único que proporciona de forma
regular y precisa el tiempo en cada momento. Sin embargo, los sistemas
distribuidos tienen un reloj por cada ordenador del sistema, con lo que es
fundamental una coordinación entre todos los relojes para mostrar una hora
única. Los osciladores de cada ordenador son ligeramente diferentes, y como
consecuencia todos los relojes sufren un desfase y deben ser sincronizados
continuamente. La sincronización no es trivial, porque se realiza a través de
mensajes por la red, cuyo tiempo de envío puede ser variable y depender de
muchos factores, como la distancia, la velocidad de transmisión o la propia
saturación de la red, etc.
EL
RELOJ
La sincronización no tiene
por qué ser exacta, y bastará con que sea aproximadamente igual en todos los
ordenadores. Hay que tener en cuenta, eso sí, el modo de actualizar la hora de
un reloj en particular. Es fundamental no retrasar nunca la hora, aunque el
reloj adelante. En vez de eso, hay que ralentizar la actualización del reloj,
frenarlo, hasta que alcance la hora aproximadamente. Existen diferentes
algoritmos de actualización de la hora.
MODELOS
DE ACCESO
Debido a la complejidad
del acceso a los archivos a través de todo el sistema distribuido, surgen dos
modelos para el acceso a los archivos: el modelo carga / descarga, y el modelo
de acceso remoto. El primer modelo simplifica el acceso permitiendo únicamente
las operaciones de cargar y descargar un archivo. El acceso a cualquier parte
del archivo implica solicitar y guardar una copia local del archivo completo, y
sólo se puede escribir de forma remota el archivo completo. Este método sería
especialmente ineficaz a la hora de realizar pequeñas modificaciones en
archivos muy grandes, como podrían ser bases de datos. El modelo de acceso
remoto es mucho más complejo, y permite todas las operaciones típicas de un
sistema de archivos local.
MEMORIA
COMPARTIDA DISTRIBUIDA
La memoria compartida distribuida o DSM es una abstracción que se
propone como alternativa a la comunicación por mensajes.
MEMORIA
COMPARTIDA BASADA EN PÁGINAS
El esquema de DSM propone
un espacio de direcciones de memoria virtual que integre la memoria de todas
las computadoras del sistema, y su uso mediante paginación. Las páginas quedan
restringidas a estar necesariamente en un único ordenador. Cuando un programa
intenta acceder a una posición virtual de memoria, se comprueba si esa página
se encuentra de forma local. Si no se encuentra, se provoca un fallo de página,
y el sistema operativo solicita la página al resto de computadoras. Los fallos
de página se propagan al resto de ordenadores, hasta que la petición llega al
ordenador que tiene la página virtual solicitada en su memoria local..
MEMORIA
COMPARTIDA BASADA EN OBJETOS
Una alternativa al uso de
páginas es tomar el objeto como base de la transferencia de memoria. Aunque el
control de la memoria resulta más complejo, el resultado es al mismo tiempo
modular y flexible, y la sincronización y el acceso se pueden integrar
limpiamente. Todos los accesos a los objetos compartidos han de realizarse
mediante llamadas a los métodos de los objetos, con lo que no se admiten
programas no modulares y se consideran incompatibles.
MODELOS
DE CONSISTENCIA
La duplicidad de los
bloques compartidos aumenta el rendimiento, pero produce un problema de
consistencia entre las diferentes copias de la página en caso de una escritura.
Si con cada escritura es necesario actualizar todas las copias, el envío de las
páginas por la red provoca que el tiempo de espera aumente demasiado,
convirtiendo este método en impracticable. Para solucionar este problema se
proponen diferentes modelos de consistencia, que establezcan un nivel aceptable
de acercamiento tanto a la consistencia como al rendimiento. Nombramos algunos
modelos de consistencia, del más fuerte al más débil: consistencia estricta,
secuencial, causal, PRAM, del procesador, débil, de liberación y de entrada.
ASPECTOS DEL DISEÑO DE LOS SOD RENDIMIENTO
Cuando se ejecuta una aplicación
en un Sistema Distribuido, no debe parecer peor que su ejecución en un único
procesador.
Métricas:
v
Tiempo de
Respuesta
v
Throughput
( Número de trabajos por hora)
v
Utilización
del Sistema
v
Cantidad
de la capacidad de la red consumida.
Comunicación
(más por el tiempo de procesamiento de los mensajes que por el traslado del
mismo).
Tomar en
cuenta el tamaño del grano de los cálculos.
Tipos:
Grano grueso: Trabajos que involucran grandes
cálculos, bajas ratas de interacción y pocos datos.
Grano fino: Es recomendable distribuir los
cálculos de grano grueso.
APLICACIONES COMERCIALES
v Reservas en líneas aéreas
v Redes bancarias y de cajeros
v Terminales de punto de venta
v Requisitos comunes:
· Fiabilidad
· Seguridad (privacidad y autentificación)
· Multiusuario (acceso concurrente por múltiples usuarios)
· Tiempos de respuesta garantizados
· Dispersión espacial
· Escalabilidad
RAZONES PRINCIPALES PARA CONSTRUIR SISTEMAS DISTRIBUIDOS
VENTAJAS SOBRE LOS SISTEMAS CENTRALIZADOS:
- Economía y Velocidad:
- Mejor relación Precio /
rendimiento en comparación a un Mainframe.
- Confiabilidad:
- La falla de un componente afecta
a lo más a una máquina
- Razones principales para
construir Sistemas Distribuidos
- Ventajas sobre los Sistemas
Centralizados (cont.):
- Escalabilidad (crecimiento por
incrementos):
- Si aumenta la carga, se pueden
agregar más procesadores o equipos al sistema
- Distribución Inherente:
- Hay aplicaciones que se
distribuyen por naturaleza.
RAZONES PRINCIPALES PARA CONSTRUIR SISTEMAS DISTRIBUIDOS
VENTAJAS SOBRE LOS PCS INDEPENDIENTES:
- Compartir:
- Recursos Lógicos: dato, registro,
archivo
- Recursos físicos o dispositivos.
- Comunicación entre personas:
- Más rápido que enviar un
documento físico.
- Permite que sea asíncrona
- Su contenido puede ser
actualizable.
- Flexibilidad:
- Permite la distribución de la carga de trabajo
CONCLUSIÓN: El uso de los Sistemas
Distribuidos permite compartir información, recursos como ser impresoras,
archivos, líneas de red, paginas web, etc., que son accedidas por clientes que
son llamados navegadores.
Los
avances en la tecnología posibilitan la integración de dispositivos de
computación pequeños y portátiles en Sistemas Distribuidos, la base de estos
últimos es obtener sistemas mucho más rápidos. Para lograr un sistema eficiente
hay que descartar la idea de ejecutar un programa en un único procesador de
todo el sistema y pensar en distribuir las tareas a los procesadores libres más
rápidos en cada momento.
REFERENCIAS
§
Sistemas Distribuidos – Conceptos
y Diseño, Tercera Edición. G. Coulouris, J. Dellimore y T. Kindberg, Pearson
Educación, España, 2001, ISBN 84-7829-049-4.
§
[AW98] Hagit Attiya and Jennifer Welch. Distributed
Computing. Fundamentals, Simulations and Advanced Topics. McGraw-Hill,
1998.
§
[BA90] M. Ben-Ari. Principles of Concurrent and
Distributed Programming. Prentice
Hall, 1990.
§ [CDK94] George Coulouris, Jean Dollimore,
and Tim Kindberg. Distributed Systems.
Concepts and
Design.
Addison-Wesley, 1994.
§
[Cor91] John R. Corbin. The Art of Distributed
Applications. Springer-Verlag, 1991.
§
[Mul93] Sape Mullender, editor. Distributed Systems.
Addison-Wesley, 1993.
Universidad Simón Bolívar. Departamento de Computación y T. I.
§ Sistemas de
Operación III . CI-4822
§ c _ 2000
Francisco Ballesteros Ampliación de Sistemas Operativos: Introducción a los
Sistemas Operativos Distribuidos
Número de visitas efectuadas desde
el 17/12/2001:
Estadísticas diarias desde el 10/07/2002:
Número de visitantes actuales disponible desde el 14/07/2002:
Autor: lrmdavid@exa.unne.edu.ar
Ó FACENA - http://exa.unne.edu.ar
Servicios WEB: webmaster@exa.unne.edu.ar