2.2.

Caractersticas de los Sistemas

Distribuidos.
Editar 0 5
{Nicolas Zarco}
2.2. Caractersticas de los Sistemas Distribuidos.
Un sistema distribuido que pretenda ofrecer una visin de sistema nico deber cumplir las
propiedades que se presentan a continuacin.
Transparencia
El objetivo esencial de un sistema distribuido es proporcionar al usuario y a las aplicaciones una
visin de los recursos del sistema como gestionados por una
sola mquina virtual. La distribucin fsica de los recursos es transparente.
Pueden describirse diferentes aspectos de la transparencia:

De identificacin. Los espacios de nombres de los recursos

son independientes de la topologa de la red y de la propia distribucin de los recursos.

Deben entenderse como propiedades deseables. Como veremos reiteradamente,

el compromiso con el rendimiento provoca en la prctica que algunas de las ropiedades se relajen.

De la ubicacin fsica de los recursos. Ni los usuarios ni las aplicaciones conocen

en qu nodo reside el recurso accedido, o si ste es local o remoto. Esto implica tambin que los
recursos pueden migrar entre nodos sin que las aplicaciones se vean afectadas. La diferencia
entre transparencia de ubicacin e identificacin se resume en diagrama Transparencia de
identificacin y transparencia de ubicacin.

De replicacin. Ni los usuarios ni las aplicaciones conocen cuntas unidades hay

de cada recurso, ni si se aaden o eliminan copias del recurso.

De paralelismo. Otra consecuencia de la replicacin de recursos es que una

aplicacin puede ejecutarse en paralelo, sin que la aplicacin tenga que especificarlo, y sin
consecuencias sobre la ejecucin, salvo por cuestiones de rendimiento.

De comparticin. El que un recurso compartido intente ser

accedido simultneamente desde varias aplicaciones no tiene efectos sobre la ejecucin de la
aplicacin.

De rendimiento. Inevitablemente, implementar las propiedades de los sistemas

distribuidos ser a costa de una prdida de rendimiento. Por ejemplo, conseguir identificacin y
ubicacin transparentes implica muchas veces resolver nombres remotamente, con el consiguiente
incremento de la latencia. Por lo tanto, es necesario buscar soluciones de compromiso cuando la

degradacin del rendimiento hace impracticable implementar alguna de las propiedades.

Escalabilidad
Una de las caractersticas de los sistemas distribuidos es su modularidad, lo que le permite
una gran flexibilidad y posibilita su escalabilidad, definida como la capacidad del sistema para
crecer sin aumentar su complejidad ni disminuir su rendimiento. Uno de los objetivos del diseo de
un sistema distribuido es extender la escalabilidad a la integracin de servicios.La escalabilidad
presenta dos aspectos. El sistema distribuido debe (1)proporcionar espacios de
nombres suficientemente amplios, de forma que nosupongan una limitacin inherente, y
(2) mantener un buen nivel de rendimiento en el acceso a los recursos cuando el sistema crece.

Espacios de nombres. Los espacios de nombres, al igual que en los sistemas

centralizados, pueden identificar objetos de diferente naturaleza, como ficheros, procesos,
variables, o incluso direcciones de memoria (en los sistemas de memoria compartida
distribuida, DSM). En el caso de los espacios lineales, como la memoria, existe una limitacin
inherente asociada al tamao del nombre, de forma que hoy en da es razonable plantear la
insuficiencia de los espacios de direcciones de 32 bits. En otros casos, los espacios de nombres
son jerrquicos y por lo tanto escalables por naturaleza.

Complejidad/rendimiento. El crecimiento de un sistema distribuido puede

introducir cuellos de botella y latencias que degradan su rendimiento. Adems del incremento de
los costes de comunicacin por el aumento de la distancia fsica entre los componentes del
sistema, la complejidad estructural de los algoritmos distribuidos es a menudo ms que lineal con
respecto al tamao del sistema, como iremos comprobando a lo largo del curso. Es necesario, por
tanto, establecer compromisos entre tamao del sistema, rendimiento y complejidad.

Fiabilidad y tolerancia a fallos

La fiabilidad de un sistema puede definirse como su capacidad para realizar correctamente y en
todo momento las funciones para las que se ha diseado. La
fiabilidad se concreta en dos aspectos:

Disponibilidad. Es la fraccin de tiempo que el sistema est operativo. El

principal parmetro para medir la disponibilidad es el tiempo medio entre fallos (MTBF), pero hay
que considerar tambin el tiempo de reparacin. La disponibilidad se puede incrementar de dos
formas: (a) utilizando componentes de mayor calidad, y/o (b) con un diseo basado en la
replicacin de componentes que permita al sistema seguir operando an cuando alguno(s) de ellos
falle(n). Ambas alternativas incrementan el coste del sistema; sin embargo, en el estado
tecnolgico actual, la replicacin resulta, en general, menos costosa. Los sistemas distribuidos
proporcionan inherentemente la replicacin de algunos recursos (por ejemplo, unidades de
proceso), mientras que otros normalmente compartidos (por ejemplo, un servidor de ficheros)
pueden replicarse para aumentar la disponibilidad. Por otra parte, la ausencia de fallos en los
componentes de un sistema, tanto hardware como software, nunca puede garantizarse, de modo
que, ms all de unos lmites, la replicacin es necesaria para seguir incrementando la
disponibilidad, ya que la probabilidad de fallo disminuye como una funcin exponencial de la
replicacin. Por ejemplo, dada una probabilidad de fallo de un 1% en un componente (en un
periodo de tiempo dado), si montamos un sistema replicado con cuatro componentes idnticos, la
probabilidad de que fallen en ese periodo los cuatro componentes disminuira a 0,000001%. Este
clculo, sin embargo, debe matizarse: por una parte, la probabilidad de fallo de los componentes
individuales suele estar correlacionada debido a varias causas, como errores de diseo o
catstrofes naturales; por otra parte, la interconexin de los componentes es una fuente de fallos
adicional.

Tolerancia a fallos. An con una alta disponibilidad, un fallo en un momento

determinado puede tener consecuencias desastrosas. Pinsese en sistemas de tiempo real crticos
que controlan dispositivos vitales (por ejemplo en medicina, centrales nucleares...). Es decir,
aunque la replicacin aumenta la disponibilidad, no garantiza por s sola la continuidad del servicio
de forma transparente. La tolerancia a fallos expresa la capacidad del sistema para seguir
operando correctamente ante el fallo de alguno de sus componentes, enmascarando el fallo al
usuario o a la aplicacin. Por lo tanto, la tolerancia a fallos implica (1)detectar el fallo, y (2)
continuar el servicio, todo ello de forma transparente para la aplicacin (transparencia de
fallos).

Consistencia
La distribucin de recursos introduce importantes beneficios. Por una parte, contribuye al
incremento del rendimiento a travs del paralelismo y promoviendo el acceso a copias locales del
recurso (disminuyendo los costes de comunicacin). Por otra, como se acaba de ver, la replicacin

aumenta la disponibilidad, siendo la base para proporcionar tolerancia a fallos. No obstante,

distribuir recursos acarrea algunos problemas. Por una parte, la red de interconexin es una nueva
fuente de fallos. Adems, la seguridad del sistema es ms vulnerable ante accesos no permitidos.
Pero el problema de mayor complejidad es el de gestin del estado global para evitar situaciones
de inconsistencia entre los componentes del sistema. Este es un aspecto fundamental en el diseo
del sistema distribuido, por lo que lo comentaremos a continuacin.
El problema radica en la necesidad de mantener un estado global consistente en un sistema con
varios componentes, cada uno de los cuales posee su propio estado local. Los nodos del sistema
se hallan fsicamente distribuidos, por lo que la gestin del estado global depende fuertemente de
los mecanismos de comunicacin, a su vez soportados por una red sujeta a fallos. Como veremos,
la gestin de la consistencia puede basarse en una buena sincronizacin entre los relojes de los
nodos o en mecanismos de ordenacin de eventos (relojeslgicos). La distribucin fsica hace, en
general, inviable la utilizacin de un reloj global que aporte referencias absolutas de tiempo, lo que
permitira una ordenacin total de los eventos y, por lo tanto, de las transiciones de estado en cada
nodo.
As pues, el mantenimiento de una consistencia estricta requiere un fuerte soporte que implica gran
carga de comunicacin adicional entre los nodos del sistema, por lo que muchas veces es
preferible relajar la consistencia para mantener el rendimiento en un nivel aceptable, de acuerdo a
las necesidades de las aplicaciones.
{Nicolas Zarco}
{Nicolas Berruezo}
Openess:
Un sistema informtico es abierto si el sistema puede ser extendido de diversas maneras. Un
sistema puede ser abierto o cerrado con respecto a extensiones hardware (aadir perifricos,
memoria o interfaces de comunicacin, etc... ) o con respecto a las extensiones software ( aadir
caractersticas al sistema operativo, protocolos de comunicacin y servicios de comparticin de
recursos, etc... ). La apertura de los sistemas distribuidos se determina primariamente por el grado
hacia el que nuevos servicios de comparticin de recursos se pueden aadir sin perjudicar ni
duplicar a los ya existentes.
Bsicamente los sistemas distribuidos cumplen una serie de caractersticas:

Los interfaces software clave del sistema estn claramente especificados y se ponen a
disposicin de los desarrolladores. En una palabra, los interfaces se hacen pblicos.

Los sistema distribuidos abiertos se basan en la provisin de un mecanismo uniforme de

comunicacin entre procesos e interfaces publicados para acceder a recursos compartidos.

Los sistema distribuidos abiertos pueden construirse a partir de hardware y software

heterogneo, posiblemente proveniente de vendedores diferentes. Pero la conformidad de cada

componente con el estndar publicado debe ser cuidadosamente comprobada y certificada si se

quiere evitar tener problemas de integracin.

Concurrencia
Cuando existen varios procesos en una nica maquina decimos que se estn ejecutando
concurrentemente. Si el ordenador esta equipado con un nico procesador central, la concurrencia
tiene lugar entrelazando la ejecucin de los distintos procesos. Si la computadora tiene N
procesadores, entonces se pueden estar ejecutando estrictamente a la vez hasta N procesos.
En los sistemas distribuidos hay muchas maquinas, cada una con uno o mas procesadores
centrales. Es decir, si hay M ordenadores en un sistema distribuido con un procesador central cada
una entonces hasta M procesos estar ejecutndose en paralelo.
En un sistema distribuido que esta basado en el modelo de comparticin de recursos, la posibilidad
de ejecucin paralela ocurre por dos razones:

Muchos usuarios interactuan simultneamente con programas de aplicacin.

Muchos procesos servidores se ejecutan concurrentemente, cada uno respondiendo a

diferentes peticiones de los procesos clientes.

El caso (1) es menos conflictivo, ya que normalmente las aplicaciones de interaccin se ejecutan
aisladamente en la estacin de trabajo del usuario y no entran en conflicto con las aplicaciones
ejecutadas en las estaciones de trabajo de otros usuarios.
El caso (2) surge debido a la existencia de uno o mas procesos servidores para cada tipo de
recurso. Estos procesos se ejecutan en distintas maquinas, de manera que se estn ejecutando en
paralelo diversos servidores, junto con diversos programas de aplicacin. Las peticiones para
acceder a los recursos de un servidor dado pueden ser encoladas en el servidor y ser procesadas
secuencialmente o bien pueden ser procesadas varias concurrentemente por mltiples instancias
del proceso gestor de recursos. Cuando esto ocurre los procesos servidores deben sincronizar sus
acciones para asegurarse de que no existen conflictos. La sincronizacin debe ser cuidadosamente
planeada para asegurar que no se pierden los beneficios de la concurrencia.
Adicional sobre Escalabilidad:
Los sistemas distribuidos operan de manera efectiva y eficiente a muchas escalas diferentes. La
escala ms pequea consiste en dos estaciones de trabajo y un servidor de ficheros, mientras que
un sistema distribuido construido alrededor de una red de rea local simple podra contener varios
cientos de estaciones de trabajo, varios servidores de ficheros, servidores de impresin y otros
servidores de propsito especifico. A menudo se conectan varias redes de rea local para
formar internetworks, y stas podran contener muchos miles de ordenadores que forman un
nico sistema distribuido, permitiendo que los recursos sean compartidos entre todos ellos.
Tanto el software de sistema como el de aplicacin no deberan cambiar cuando la escala del

sistema se incrementa. La necesidad de escalabilidad no es solo un problema de prestaciones de

red o de hardware, sino que esta ntimamente ligada con todos los aspectos del diseo de los
sistemas distribuidos. El diseo del sistema debe reconocer explcitamente la necesidad de
escalabilidad o de lo contrario aparecern serias limitaciones.
La demanda de escalabilidad en los sistemas distribuidos ha conducido a una filosofa de diseo
en que cualquier recurso simple -hardware o software- puede extenderse para proporcionar
servicio a tantos usuarios como se quiera. Esto es, si la demanda de un recurso crece, debera ser
posible extender el sistema para darla servicio,. Por ejemplo, la frecuencia con la que se accede a
los ficheros crece cuando se incrementa el numero de usuarios y estaciones de trabajo en un
sistema distribuido. Entonces, debe ser posible aadir ordenadores servidores para evitar el cuello
de botella que se producira si un solo servidor de ficheros tuviera que manejar todas las peticiones
de acceso a los ficheros. En este caso el sistema deber estar diseado de manera que permita
trabajar con ficheros replicados en distintos servidores, con las consideraciones de consistencias
que ello conlleva.
Cuando el tamao y complejidad de las redes de ordenadores crece, es un objetivo primordial
disear software de sistema distribuido que seguir siendo eficiente y til con esas nuevas
configuraciones de la red. Resumiendo, el trabajo necesario para procesar una peticin simple para
acceder a un recurso compartido debera ser prcticamente independiente del tamao de la red.
Las tcnicas necesarias para conseguir estos objetivos incluyen el uso de datos replicados, la
tcnica asociada de caching, y el uso de mltiples servidores para manejar ciertas tareas,
aprovechando la concurrencia para permitir una mayor productividad. Una explicacin completa de
estas tcnicas puede encontrarse en [ Colouris 1994 ].
Tolerancia a Fallos:
Los sistemas informticos a veces fallan. Cuando se producen fallos en el software o en el
hardware, los programas podran producir resultados incorrectos o podran pararse antes de
terminar la computacin que estaban realizando. El diseo de sistemas tolerantes a fallos se basa
en dos cuestiones, complementarias entre s: Redundancia hardware (uso de componentes
redundantes) y recuperacin del software (diseo de programas que sean capaces de recuperarse
de los fallos).
En los sistemas distribuidos la redundancia puede plantearse en un grano mas fino que el
hardware, pueden replicarse los servidores individuales que son esenciales para la operacin
continuada de aplicaciones criticas.
La recuperacin del software tiene relacin con el diseo de software que sea capaz de recuperar
(roll-back) el estado de los datos permanentes antes de que se produjera el fallo.
Los sistemas distribuidos tambin proveen un alto grado de disponibilidad en la vertiente de fallos
hardware. La disponibilidad de un sistema es una medida de la proporcin de tiempo que esta
disponible para su uso. Un fallo simple en una maquina multiuruario resulta en la no disponibilidad
del sistema para todos los usuarios. Cuando uno de los componentes de un sistema distribuidos
falla, solo se ve afectado el trabajo que estaba realizando el componente averiado. Un usuario
podra desplazarse a otra estacin de trabajo; un proceso servidor podra ejecutarse en otra
maquina.

HERRAMIENTAS