
Sistemas
Distribuidos de Archivos




-
Introducción
a los Sistemas Distribuidos de Archivos
-
Diseño
de los Sistemas Distribuidos de Archivos
-
La Interfaz
del Servicio de Archivos
-
La Interfaz
del Servidor de Directorios
-
Transparencia
de los Nombres
-
Semántica
de los Archivos Compartidos
-
Implantación
de un Sistema Distribuido de Archivos
-
Uso de Archivos
-
Estructura del
Sistema
-
Ocultamiento
-
Consistencia
del Caché
-
Réplica
-
Protocolos de
Actualización
-
Conclusiones
Importantes Respecto de la Implantación de un Sistema Distribuido
de Archivos
-
Tendencias en
los Sistemas Distribuidos de Archivos
-
Consideraciones
Respecto del Hardware
-
Escalabilidad
-
Redes en un
Area Amplia
-
Usuarios Móviles
-
Tolerancia de
Fallos
-
Fin
Introducción
a los Sistemas Distribuidos de Archivos
Muchos aspectos son similares a los de los sistemas convencionales
centralizados [25, Tanenbaum].
En un sistema distribuido es importante distinguir entre los conceptos
de servicio de archivos y el servidor de archivos.
El servicio de archivos:
-
Es la especificación de los servicios que el sistema de archivos
ofrece a sus clientes.
-
Describe las primitivas disponibles, los parámetros que utilizan
y las acciones que llevan a cabo.
-
Define precisamente el servicio con que pueden contar los clientes sin
decir nada respecto de su implantación.
El despachador (servidor) de archivos:
-
Es un proceso que se ejecuta en alguna máquina y ayuda con la implantación
del servicio de archivos.
-
Puede haber uno o varios en un sistema.
-
Los clientes no deben ser conscientes de la forma de implantar el sistema
de archivos:
-
No precisan conocer el número de servidores de archivos, su posición
o función.
-
Deberían ver al sistema distribuido de archivos como un sistema
de archivos normal de uniprocesador.
Generalmente un servidor de archivos es un proceso del usuario (a
veces del núcleo) que se ejecuta en una máquina:
-
Un sistema puede contener varios servidores de archivos, cada uno con un
servicio distinto:
-
Ej.: un sistema con un servidor de archivos en “UNIX” y otro en “DOS”.
-
Cada proceso usuario utilizaría el servidor apropiado.
Inicio:
Fin:
Diseño
de los Sistemas Distribuidos de Archivos
Los componentes de un sistema distribuido de archivos son [25,
Tanenbaum]:
-
El verdadero servicio de archivos:
-
Realiza operaciones en los archivos individuales: lectura, escritura, adición.
-
El servicio de directorios:
-
Crea y maneja directorios, añade y elimina archivos de los directorios,
etc.
Inicio:
Fin:
La Interfaz
del Servicio de Archivos
La protección en los sistemas distribuidos utiliza las
mismas
técnicas de los sistemas con uniprocesador [25,
Tanenbaum]:
-
Posibilidades:
-
Cada usuario tiene un permiso o posibilidad para cada objeto al que tiene
acceso:
-
Determina los tipos de accesos permitidos.
-
Listas para control de acceso:
-
Se asocia a cada archivo una lista implícita o explícita
de:
-
Los usuarios que pueden tener acceso al archivo.
-
Los tipos de acceso permitidos a cada uno de ellos.
Los servicios de archivos se pueden clasificar en dos tipos:
-
Modelo carga / descarga:
-
Las principales operaciones son la lectura de un archivo y la escritura
en un archivo.
-
La lectura transfiere todo un archivo de uno de los servidores de archivos
al cliente solicitante.
-
La escritura transfiere en sentido contrario.
-
Los archivos se pueden almacenar en memoria o en un disco local.
-
Modelo de acceso remoto:
-
El sistema de archivos se ejecuta con todas las funciones en los servidores
y no en los clientes.
Inicio:
Fin:
La Interfaz
del Servidor de Directorios
Proporciona operaciones para crear y eliminar directorios, nombrar y
cambiar el nombre de archivos y mover archivos de un directorio a otro
[25,
Tanenbaum].
Se utiliza un sistema jerárquico de archivos, representado
por un árbol de directorios (ver Figura 11.1 [25,
Tanenbaum]).

En ciertos sistemas es posible crear enlaces o apuntadores a un directorio
arbitrario:
-
Se pueden colocar en cualquier directorio.
-
Se pueden construir gráficas de directorios.
En una jerarquía con estructura de árbol solo se puede
eliminar un enlace con un directorio si el directorio al cual se apunta
está vacío.
En una gráfica se permite la eliminación de un
enlace mientras exista al menos otro:
-
Se utiliza un contador de referencias para determinar si el enlace por
eliminar es el último.
-
Se puede armar una gráfica de directorios comprendiendo a directorios
de dos o más máquinas.
-
La eliminación de enlaces puede llevar a directorios y archivos
a la condición de huérfanos, es decir que no pueden ser alcanzados
desde el directorio raíz (ver Figura 11.2 [25,
Tanenbaum]).

Un aspecto fundamental de diseño en sistemas distribuidos
es si todas las máquinas y procesos tendrán exactamente
la misma visión de la jerarquía de los directorios.
En los sistemas que utilizan varios servidores de archivos mediante
el montaje remoto generalmente los diversos clientes tienen una visión
diferente del sistema de archivos, pero la desventaja es que
el sistema no se comporta como un único sistema de tiempo compartido.
Una cuestión relacionada es si existe un directorio raíz
global al que todas las máquinas reconozcan como la raíz;
una posibilidad es que la raíz solo contenga una entrada por cada
servidor.
Inicio:
Fin:
Transparencia de los Nombres
La transparencia con respecto a la posición significa
que el nombre de la ruta de acceso no sugiere la posición del archivo:
-
Se individualiza al servidor pero no se indica dónde está,
por ello puede moverse dentro de la red sin necesidad de cambiar la ruta.
-
Ej.: /servidor1/dir1/dir2/x.
Si el primer componente de todas las rutas de acceso es el servidor, el
sistema no puede desplazar el archivo a otro servidor en forma automática
porque cambiaría el nombre de la ruta de acceso.
Un sistema donde los archivos se pueden desplazar sin que cambien
sus nombres tiene independencia con respecto a la posición.
Resumiendo, los métodos usuales para nombrar los archivos
y directorios en un sistema distribuido son:
-
Nombre máquina + ruta de acceso.
-
Montaje de sistemas de archivos remotos en la jerarquía local de
archivos.
-
Un único espacio de nombres que tenga la misma apariencia en todas
las máquinas.
Inicio:
Fin:
Semántica
de los Archivos Compartidos
Cuando se comparten archivos es necesario definir con precisión
la semántica de la lectura y escritura.
En sistemas monoprocesador que permiten a los procesos compartir
archivos (ej.: UNIX) la semántica generalmente establece:
-
Si un read sigue a un write, read debe regresar el
valor recién escrito.
-
Si dos write se realizan en serie y luego se ejecuta un read,
el valor que se debe regresar es el almacenado en la última escritura.
-
Este modelo se denomina semántica de UNIX.
En un sistema distribuido la semántica de UNIX se
puede lograr fácilmente si:
-
Solo existe un servidor de archivos.
-
Los clientes no ocultan los archivos.
Un problema que se puede presentar se debe a los retrasos en la red:
-
Si un read ocurrido después de un write llega primero
al servidor obtendrá el valor previo al write.
Otro problema es el desempeño pobre de un sistema distribuido
en donde todas las solicitudes de archivos deben pasar a un único
servidor:
-
Una solución es permitir a los cliente mantener copias locales de
los archivos de uso frecuente en sus cachés particulares, lo que
ocasiona el siguiente problema:
-
Un cliente modifica localmente un archivo en su caché.
-
Luego otro cliente lee el archivo del servidor.
-
El segundo cliente obtendrá un archivo obsoleto.
-
Una solución sería propagar inmediatamente todas las modificaciones
de los archivos en caché de regreso al despachador:
-
Resulta prácticamente ineficiente.
Otra solución es relajar la semántica de los archivos
compartidos:
-
Los cambios a un archivo abierto solo pueden ser vistos en un principio
por el proceso (o tal máquina) que modificó el archivo.
-
Los cambios serán visibles a los demás procesos (o máquinas)
solo cuando se cierre el archivo y sea actualizado en el servidor.
-
Esta regla se conoce como la semántica de sesión.
Un problema se presenta cuando dos o más clientes ocultan
y modifican el mismo archivo en forma simultánea:
-
Una solución es que al cerrar cada archivo su valor se envía
de regreso al servidor:
-
El resultado final depende de quién lo cierre más rápido.
Otro problema consiste en que no se pueden compartir los apuntadores
que
para cada archivo indican en la semántica UNIX la posición
actual en el archivo.
Un método distinto es que todos los archivos sean inmutables:
-
No se puede abrir un archivo para escribir en él.
-
Solo se permiten las operaciones create y read.
-
Los directorios sí se pueden actualizar.
-
Se puede crear un archivo nuevo e introducirlo en el directorio con el
nombre de un archivo ya existente:
-
Este se vuelve inaccesible con el mismo nombre.
-
Persiste el problema de cómo tratar la situación presentada
cuando dos procesos intentan reemplazar el mismo archivo a la vez.
Otra vía de solución para el uso de archivos compartidos
en un sistema distribuido es usar las transacciones atómicas:
-
Se garantiza que todas las llamadas contenidas en la transacción
se llevarán a cabo en orden.
-
No habrá interferencias de otras transacciones concurrentes.
Inicio:
Fin:
Implantación
de un Sistema Distribuido de Archivos
La implantación de un sistema distribuido de archivos incluye
aspectos tales como [25, Tanenbaum]:
-
El uso de los archivos.
-
La estructura del sistema.
-
El ocultamiento.
-
La duplicación o réplica.
-
El control de la concurrencia.
Inicio:
Fin:
Uso de Archivos
Antes de implantar un sistema de archivos resulta de interés
analizar los “patrones de uso” de dichos archivos [25,
Tanenbaum].
Para determinar los patrones de uso es necesario tomar mediciones
que pueden ser:
-
Estáticas:
-
Representan una toma instantánea del sistema en un momento dado.
-
– Comprenden la distribución de tamaño de los archivos, la
distribución de tipo de archivos, la cantidad de espacio que ocupan
los archivos de varios tamaños y tipos, etc.
-
Dinámicas:
-
Registran en una bitácora todas las operaciones que modifican el
sistema de archivos.
-
Comprenden información sobre la frecuencia relativa de varias operaciones,
el número de archivos abiertos en un momento dado, la cantidad de
archivos compartidos, etc.
Las principales propiedades observadas son:
-
La mayoría de los archivos son pequeños.
-
La lectura es más común que la escritura.
-
La mayoría de los accesos es secuencial.
-
La mayoría de los archivos son de corta vida.
-
Es poco usual compartir archivos.
-
Los procesos promedio utilizan pocos archivos.
-
Distintas clases de archivos poseen propiedades distintas.
Inicio:
Fin:
Estructura
del Sistema
En ciertos sistemas no existe distinción entre un cliente
y un servidor [25, Tanenbaum]:
-
Todas las máquinas ejecutan el mismo software básico.
-
Una máquina que desee dar servicio de archivos lo puede hacer:
-
Debe exportar los nombres de los directorios seleccionados, para
que otras máquinas los puedan acceder.
En otros sistemas el servidor de archivos y el de directorios
son solo programas del usuario, y se puede configurar un sistema
para que ejecute o no el software de cliente o servidor en la misma
máquina.
Los clientes y servidores también podrían
ser máquinas totalmente distintas en términos de hardware
o de software.
Un aspecto de implantación en donde difieren los sistemas
es la forma de estructurar el servicio a directorios y archivos;
las principales opciones son las siguientes:
-
Combinar el servicio a directorios y archivos en un único
servidor que administre todas las llamadas a directorios y archivos.
-
Separar el servicio a directorios y archivos utilizando un servidor
de directorios y un servidor de archivos.
Si se considera el caso de servidores de archivos y directorios independientes:
-
El cliente envía un nombre simbólico al servidor de directorios.
-
El servidor de directorios regresa el nombre en binario (ej.: máquina
+ nodo_i ) que comprende el servidor de archivos.
-
Es posible que una jerarquía de directorios se reparta entre varios
servidores.
-
El servidor que recibe un nombre binario que se refiere a otro servidor
puede:
-
Indicar al cliente el servidor que tiene el archivo buscado, para que el
cliente lo busque.
-
Enviar la solicitud al siguiente servidor y no contestar.
Un aspecto estructural a considerar es si los servidores de archivos,
directorios o de otro tipo deben contener la información de estado
de los clientes.
Una posibilidad es que los servidores no deben contener los estados,
deben ser sin estado:
-
Cuando un cliente envía una solicitud a un servidor:
-
El servidor la lleva a cabo, envía la respuesta y elimina de sus
tablas internas toda la información relativa a esa solicitud.
-
El servidor no guarda información relativa a los clientes entre
las solicitudes.
Otra posibilidad es que los servidores conserven información
de estado de los clientes entre las solicitudes.
Aclaración:
-
Luego de abrir un archivo el servidor debe mantener la información
que relacione los clientes con los archivos abiertos por éstos.
-
Al abrir un archivo el cliente recibe un descriptor de archivo que se utiliza
en las llamadas posteriores para identificación del archivo.
-
Al recibir una solicitud el servidor utiliza el descriptor de archivo para
determinar el archivo necesario.
-
La tabla que asocia los descriptores de archivo con los archivos
propiamente dichos es información de estado.
En un servidor sin estado cada solicitud debe ser autocontenida:
-
Debe incluir el nombre del archivo y toda la información para que
el servidor realice el trabajo.
-
La longitud del mensaje es mayor.
Si un servidor con estado falla y sus tablas se pierden:
-
Al volver a arrancar no tiene información sobre la relación
entre los clientes y los archivos abiertos por éstos.
-
La recuperación queda a cargo de los clientes.
Los servidores sin estado tienden a ser más tolerantes de los
fallos que los servidores con estados.
Inicio:
Fin:
Ocultamiento
En un sistema cliente - servidor, cada uno con su memoria principal
y un disco, existen cuatro lugares donde se pueden almacenar los archivos
o partes de ellos [25, Tanenbaum]:
-
El disco del servidor.
-
La memoria principal del servidor.
-
El disco del cliente (si existe).
-
La memoria principal del cliente.
Si los archivos se almacenan en el disco del servidor:
-
Disponen de abundante espacio.
-
Serían accesibles a todos los clientes.
-
No habrá problemas de consistencia al existir solo una copia de
cada archivo.
-
Puede haber problemas de desempeño:
-
Antes de que un cliente pueda leer un archivo se lo debe transferir:
-
Del disco del servidor a la memoria principal del servidor.
-
De la memoria principal del servidor a la memoria principal del cliente,
a través de la red.
-
Se puede mejorar el desempeño ocultando (conservando) los archivos
de más reciente uso en la memoria principal del servidor:
-
Un cliente que lea un archivo ya presente en el caché del servidor
elimina la transferencia del disco.
-
Se necesita un algoritmo para determinar los archivos o partes de archivos
que deben permanecer en el caché.
El algoritmo debe resolver los siguientes problemas:
-
La unidad que maneja el caché.
-
Qué hacer si se utiliza toda la capacidad del caché y hay
que eliminar a alguien.
Respecto de la unidad que maneja el caché:
-
Puede manejar archivos completos o bloques del disco.
-
El ocultamiento de archivos completos que se pueden almacenar en forma
adyacente en el disco permite un buen desempeño en general.
-
El ocultamiento de bloques de disco utiliza el caché y el espacio
en disco más eficientemente.
Respecto de qué hacer cuando se utiliza toda la capacidad del
caché y hay que eliminar a alguien:
-
Se puede utilizar cualquier algoritmo de ocultamiento, por ej.:
LRU
mediante listas ligadas.
-
Cuando hay que eliminar a alguien de la memoria:
-
Se elige al más antiguo.
-
Si existe una copia actualizada en el disco se descarta la copia del caché.
-
De lo contrario primero se actualiza el disco.
El mantenimiento de un caché en la memoria principal del servidor
es
fácil de lograr y es totalmente transparente a los clientes.
Si se utiliza ocultamiento en el lado del cliente:
-
Se elimina el acceso a la red para transferir del servidor al cliente.
-
El disco del cliente generalmente es más lento y de menor capacidad.
-
Generalmente es más rápido y más sencillo tener un
caché en la memoria principal del servidor que en el disco del cliente.
Si el caché se coloca en la memoria principal del cliente
las principales opciones son:
-
Ocultar los archivos dentro del propio espacio de direcciones de un proceso
de usuario.
-
Colocar el caché en el núcleo.
-
Ocultar el caché en un proceso manejador del caché, independiente
y a nivel usuario.
Inicio:
Fin:
Consistencia del Caché
El ocultamiento por parte del cliente introduce inconsistencia
en el sistema.
Si dos clientes leen un mismo archivo en forma simultánea y después
lo modifican, aparecen algunos problemas:
-
Cuando un tercer proceso lee el archivo del servidor obtendrá la
versión original y no alguna de las nuevas:
-
Se puede evitar mediante la “semántica de sesión”:
-
No es aplicable cuando se requiere la “semántica de UNIX”.
-
Cuando dos archivos se escriben de nuevo al servidor, el último
de ellos se escribirá sobre el otro.
Una solución a la inconsistencia del caché es el algoritmo
de escritura a través del caché:
-
Cuando se modifica una entrada del caché (archivo o bloque), el
nuevo valor:
-
Se mantiene dentro de él.
-
Se envía de inmediato al servidor.
Los principales problemas de la escritura a través del caché
son los siguientes:
-
Posible suministro de valores obsoletos:
-
Un proceso cliente en la máquina “A” lee un archivo “f
” y mantiene a “f ” en su caché.
-
Un cliente en la máquina “B” lee el mismo archivo, lo modifica
y lo escribe en el servidor.
-
Otro proceso cliente inicia en la máquina “A” abriendo y
leyendo “f ”, que se toma del caché.
-
El valor de “f ” es obsoleto.
-
Una solución consiste en exigir al manejador del caché que
verifique el servidor antes de proporcionar al cliente un archivo del caché:
-
Generalmente utilizará una “RPC” y poca información
de control.
-
El tráfico en la red en el caso de las escrituras es igual que en
el caso de no ocultamiento:
-
Para mejorar se puede aplicar el siguiente procedimiento de retraso
en la escritura:
-
En vez de ir hacia el servidor en el instante en que se realiza la escritura,
el cliente:
-
Hace una notificación de que ha actualizado un archivo.
-
Cada cierto intervalo (ej.: 30”) todas las actualizaciones se agrupan y
envían la servidor al mismo tiempo (un bloque).
-
El retraso en la escritura obscurece la semántica:
-
Si otro proceso lee el archivo, el resultado dependerá de la sincronización
de los eventos.
-
Otro algoritmo para manejar el caché de archivos del cliente
es el de escritura al cierre:
-
Se adopta la semántica de sesión.
-
Solo se escribe un archivo nuevamente en el servidor cuando el archivo
se cierra:
-
Se podría esperar (ej.: 30”) para ver si el archivo es eliminado
en ese lapso.
Un método distinto a la consistencia es utilizar un algoritmo
de control centralizado:
-
Al abrir un archivo la máquina envía un mensaje al servidor
para anunciar este hecho.
-
El servidor de archivos tiene un registro de los archivos abiertos, sus
poseedores y si están abiertos para lectura, escritura o ambos procesos.
-
Si se abre un archivo para lectura otros procesos lo pueden abrir para
lectura pero no para escritura.
-
Si se abre un archivo para escritura se debe evitar abrirlo para lectura
desde otro proceso.
-
Al cerrar un archivo:
-
Se debe informar al servidor para que actualice sus tablas.
-
Se puede enviar el archivo modificado al servidor.
Inicio:
Fin:
Réplica
Frecuentemente los sistemas distribuidos de archivos proporcionan la
réplica
de archivos como un servicio [25, Tanenbaum]:
-
Existen varias copias de algunos archivos.
-
Cada copia está en un servidor de archivos independiente.
Las principales razones para la réplica son:
-
Aumentar la confiabilidad al disponer de respaldos independientes de cada
archivo.
-
Permitir el acceso a archivos aún cuando falle un servidor de archivos.
-
Repartir la carga de trabajo entre varios servidores.
Un sistema es transparente con respecto a la réplica
si la misma se administra sin intervención del usuario.
Una forma de llevar a cabo la réplica consiste en que el programador
controle
todo el proceso (réplica explícita):
-
Los archivos y las copias adicionales se crean en servidores específicos.
-
Las direcciones en la red de todas las copias se asocian con el nombre
del archivo.
Un método alternativo es la réplica retrasada:
-
Solo se crea una copia de cada archivo en un servidor.
-
El servidor crea réplicas en otros servidores, a posteriori, automáticamente
y sin intervención del proceso de usuario.
Otro método consiste en el uso de la comunicación
en grupo:
-
Todas las operaciones de escritura se transmiten simultáneamente
a todos los servidores.
-
Las copias adicionales se hacen al mismo tiempo que el original.
Inicio:
Fin:
Protocolos de Actualización
El principal problema es asegurar la sincronización de
las distintas copias.
Un algoritmo posible es el de réplica de la copia primaria:
-
Uno de los servidores se denomina como primario.
-
Los demás servidores son secundarios.
-
La actualización se envía al servidor primario:
-
Realiza los cambios localmente.
-
Envía comandos a los servidores secundarios para ordenarles la misma
modificación.
-
Las lecturas se pueden hacer de cualquier copia.
-
La desventaja es que si falla el primario no se pueden llevar a
cabo las actualizaciones.
Otro posible algoritmo es el del voto o de Gifford:
-
La idea fundamental es exigir a los clientes que soliciten y adquieran
el permiso de varios servidores antes de leer o escribir un archivo replicado.
-
Se utiliza el número de versión, que identifica la versión
del archivo y es la misma para todos los archivos recién actualizados.
-
Para leer un archivo con “N” réplicas un cliente debe conformar
un quórum de lectura, es decir una colección arbitraria
de “Nr” servidores o más.
-
Para modificar un archivo se necesita un quórum de escritura
de al menos “Nw” servidores.
-
Se debe cumplir que “Nr” + “Nw” > “N”,
por lo cual nunca se podrá obtener un quórum de lectura y
otro de escritura al mismo tiempo.
-
Generalmente “Nr” es muy pequeño y “Nw”
muy cercano a “N” ya que generalmente las lecturas son más
frecuentes que las escrituras.
-
Una variante es el algoritmo del voto con fantasma:
-
Crea un servidor fantasma para cada servidor real fallido:
-
Interviene solo en el quórum de escritura.
-
La escritura solo tiene éxito si al menos uno de los servidores
es real.
Inicio:
Fin:
Conclusiones
Importantes Respecto de la Implantación de un Sistema Distribuido
de Archivos
Los principios generalmente considerados fundamentales del diseño
de un sistema distribuido de archivos son [25, Tanenbaum]:
-
Las estaciones de trabajo tienen ciclos que hay que utilizar:
-
Si se tiene la opción de hacer algo en una estación de trabajo
o en un servidor:
-
Elegir la estación de trabajo.
-
Los ciclos de cpu de la estación de trabajo son menos costosos que
los ciclos de un servidor.
-
Utilizar el caché el máximo posible:
-
Frecuentemente ahorran considerable:
-
Tiempo de cómputo.
-
Ancho de banda de la red.
-
Explotar las propiedades de uso:
-
Considerar la posibilidad de implantar tratamientos diferenciales para
los archivos transitorios de corta vida y no compartidos.
-
Tener presente la dificultad de habilitar diferentes vías para hacer
lo mismo.
-
Considerar aspectos tales como eficiencia y sencillez.
-
Minimizar el conocimiento y modificación a lo largo
del sistema:
-
Es importante para lograr escalabilidad.
-
Generalmente son útiles en este sentido los diseños jerárquicos.
-
Confiar en el menor número posible de entidades:
-
Se trata de un principio ya establecido en el mundo de la seguridad.
-
Crear lotes de trabajo mientras sea posible:
-
El uso del procesamiento por lotes puede contribuir a un mejor desempeño.
Inicio:
Fin:
Tendencias
en los Sistemas Distribuidos de Archivos
Es probable que los cambios en el hardware tengan un efecto muy
importante en los futuros sistemas distribuidos de archivos [25,
Tanenbaum].
También es probable el impacto del cambio en las expectativas
del usuario.
Inicio:
Fin:
Consideraciones
Respecto del Hardware
El abaratamiento de la memoria principal permitirá disponer de
servidores
con memorias cada vez mayores [25, Tanenbaum]:
-
Se podría alojar directamente en memoria el sistema de archivos
logrando mayor sencillez y desempeño.
-
Se debería prever la obtención de respaldos continuos o por
incrementos ante la posibilidad del corte en el suministro eléctrico.
-
El respaldo podría hacerse en discos ópticos regrabables
que tengan una asociación uno a uno con la memoria:
-
El byte “k” de la memoria correspondería al byte “k”
del disco.
La disponibilidad de redes de fibra óptica de alta velocidad
permitiría esquemas tales como:
-
Un servidor de archivos en la memoria principal del servidor con respaldo
en el disco óptico.
-
Eliminación del disco del servidor y del caché del cliente.
-
Se simplificaría significativamente el software.
La posible construcción de interfaces de red especializadas
que permitan resolver por hardware problemas difíciles de soportar
por software:
-
Cada interfaz de red tendría un mapa de bits con un bit por cada
archivo en el caché.
-
Se podrían habilitar cerraduras por archivo.
-
Para modificar un archivo un procesador activaría el bit correspondiente
en la interfaz.
Inicio:
Fin:
Escalabilidad
Una tendencia definida en los sistemas distribuidos es hacia los
sistemas cada vez más grandes [25, Tanenbaum].
Los sistemas distribuidos de archivos que operan bien para cientos de
máquinas podrían fallar en algún aspecto trabajando
con miles o decenas de miles de máquinas.
Generalmente los algoritmos centralizados no se escalan bien
ya que el servidor centralizado podría convertirse en un cuello
de botella; por ello se podría separar el sistema en unidades más
pequeñas relativamente independientes entre sí.
Las transmisiones también son un área problemática:
-
Si cada máquina transmite una vez por segundo:
-
Con “n” máquinas habría “n” transmisiones y
“n
2
” interrupciones por segundo.
-
Si “n” crece esto se puede convertir en un problema.
En general los recursos y algoritmos no deben ser lineales con respecto
al número de usuarios.
Inicio:
Fin:
Redes en
un Area Amplia
Generalmente los sistemas distribuidos se asocian con redes de área
local (LAN), pero cada vez será mayor la necesidad de conectarlos
entre sí cubriendo grandes áreas (nacionales, regionales,
continentales, etc.) [25, Tanenbaum].
Los sistemas de archivos deberán soportar estas necesidades teniendo
presente la heterogeneidad de los equipos, códigos de representación
(ASCII, EBCDIC, etc.), formatos, etc.
Deberá atenderse a los cambios de tendencia en los requerimientos
de las aplicaciones.
Un problema adicional e inherente en los sistemas distribuidos masivos
es el ancho de banda de la red, que puede resultar insuficiente
para el desempeño esperado.
Inicio:
Fin:
Usuarios Móviles
Los usuarios de equipos móviles (laptop, notebook, etc.)
están gran parte del tiempo desconectados del sistema de
archivos de su organización [25, Tanenbaum]:
-
Requieren una solución, que podría usar ocultamiento:
-
Cuando está conectado el usuario carga al equipo móvil los
archivos que cree necesitará después.
-
Los utiliza mientras está desconectado.
-
Al reconectarse, los archivos en el caché deben fusionarse con los
existentes en el árbol de directorios, logrando la sincronización.
-
La conexión para la sincronización puede ser problemática
si se utiliza un enlace de ancho de banda reducido.
Lo deseable sería un sistema distribuido totalmente transparente
para su uso simultáneo por parte de millones de usuarios móviles
que frecuentemente se desconecten.
Inicio:
Fin:
Tolerancia
de Fallos
La difusión de los sistemas distribuidos incrementa la demanda
de sistemas que esencialmente nunca fallen [25, Tanenbaum].
Los sistemas tolerantes a fallos requerirán cada vez más
una considerable redundancia en hardware, comunicaciones, software,
datos, etc.
La réplica de archivos sería un requisito esencial.
También debería contemplarse la posibilidad de que los
sistemas funcionen aún con la carencia de parte de los datos.
Los tiempos de fallo aceptables por los usuarios serán cada
vez menores.
Inicio:
Fin:

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