SISTEMA DISTRIBUIDO DE ARCHIVO
Un componente fundamental de cualquier sistema distribuido es el sistema de archivo.
Los sistemas distribuido de archivos permite a los programas almacenar y acceder a archivos remotos del mismo modo que si fueran locales, permitiendo a los usuarios que accedan archivos desde cualquier computador.
Un servidor de archivos es un proceso que se ejecuta en alguna maquina y ayuda a implantar el servicio de archivo. Un sistema puede tener uno o varios servidores de archivos, cada uno de los cuales ofrece un servicio de archivos distintos,
pero los clientes no deben conocer el numero de servidores de archivos, su posición o función. Todo lo que saben es que al llamar los procedimientos especificados en servicio de archivos, el trabajo necesario se lleva a cabo de alguna manera y se obtienen los resultados pedidos. Los clientes ni siquiera deben saber que el servicio de archivos es distribuido. Lo ideal es que se vea como un sistema de archivos normal de un procesador.
DISEÑO DE LOS SISTEMAS DISTRIBUIDOS DE ARCHIVOS
Por lo general un sistema distribuidos de archivos tiene dos componentes razonablemente distintos: el verdadero servicio de archivos y el servicio de directorios. El primero se encarga de las operaciones en los archivos individuales, como la lectura escritura y adición, mientras que el segundo se encarga de crear y administrar directorios, añadir y eliminar archivos de los directorios, etc.
La interfaz del servicio de archivos
Un aspecto importante del modelo de archivo es si éstos se pueden modificar después de su creación. Existen algunos sistemas distribuidos que permiten únicamente las operaciones de archivos CREATE Y READ. Una vez creado un archivo no se puede modificar. Se dice que tal archivo es inmutable. Estos archivos facilitan el ocultamiento y duplicación de archivos, puesto que esto elimina todos los problemas asociados con la actualización de todas las copias de un archivo cada vez que éste se modifique.
La protección en los sistemas distribuidos utiliza la misma técnica de los procesos con un procesador: posibilidades y listas para control de acceso. En el caso de las posibilidades cada usuario tiene cierto boleto llamado posibilidad, para cada objeto al que tiene acceso. La posibilidad determina los tipos de accesos permitidos ( por ejemplo se permite la lectura pero no la escritura ).
Todos los esquemas de lista para el control de acceso asocian a cada archivo una lista implícita o explícita de los usuarios que pueden tener acceso a los archivos y la forma de dicho acceso. El esquema de UNIX es una lista para control de acceso simplificada, con los bits que controlan la lectura, escritura y ejecución de cada archivo, en forma independiente para el propietario, grupo del propietario y todas las demás personas.
Los servicios de archivos se pueden dividir en dos tipos, según si soportan un modelo carga /descarga o un modelo de acceso remoto. En el modelo carga/descarga el servicio de archivo sólo proporciona la lectura de un archivo y la escritura del mismo. En la lectura transfiere todo un archivo de uno de los servidores de archivos al cliente solicitante. La escritura transfiere todo un archivo en sentido contrario del cliente al servidor. Los archivos se pueden almacenar en memoria o en disco local, como sea necesario.
La ventaja del modelo carga/descarga es la sencillez del concepto. Los programas de aplicación buscan los archivos que necesitan y después lo utilizan de manera local. Los archivos modificados o nuevos se escriben de regreso al terminar el programa.
Además, la transferencia de archivos completos es muy eficiente. Sin embargo el cliente debe disponer de un espacio suficiente de almacenamiento para todos los archivos necesarios. Otra desventaja es que si sólo se necesita una pequeña fracción de un archivo, el traslado del archivo completo es un desperdicio.
El otro tipo de servicios de archivos el de acceso remoto, en este modelo se proporcionan un gran número de operaciones para abrir y cerrar archivos, leer y escribir parte de archivo, moverse a través de un archivo, examinar y modificar los atributos de archivos, etc. Mientras en el modelo carga/descarga el servicio de archivos sólo proporciona el almacenamiento físico y la transferencia, en este caso el sistema de archivos se ejecuta en los servidores y no en los clientes. Su ventaja es que no necesita mucho espacio por parte de los clientes, a la vez que elimina la necesidad de transferir archivo completos cuando sólo se necesita un parte de ellos.
La interfaz del servidor de directorios
Proporciona la operaciones para crear y eliminar directorios, nombrar o cambiar el nombre de archivo y mover esto de un directorio a otro.
El servicio de directorios define un alfabeto y una sintaxis para formar los nombres de archivos( y directorio ). Lo usual es que los nombres de archivos tengan de uno hasta un cierto numero de letras, números y ciertos caracteres especiales. Algunos sistemas dividen los nombres de archivo en dos partes, a menudo separada por un punto. La segunda parte del nombre llamada la extensión de archivo identifica el tipo de este. Otros sistemas utilizan un atributo explícito para este fin, en vez de utilizar una extensión dentro del nombre.
Todos los sistemas distribuido permiten que los directorios contengan subdirectorios, para que los usuarios puedan agrupar los archivos relacionados entres si. De acuerdo con esto se dispone para la creación y eliminación de directorios, asi como para introducir, eliminar y buscar archivos en ellos. Por lo general, cada subdirectorio contiene todos los archivos de un proyecto, como un programa o un documento de gran tamaño. Cundo se despliega el (sub)directorio solo se muestra los archivos relevantes, los archivos no relacionados estan en otros (sub)directorios y no agrandan la lista. Los subdirectorios pueden contener sus propios subdirectorios y asi sucesivamente. Lo que conduce a un árbol de directorios, el cual se conoce como sistema jerárquico de archivo.
En ciertos sistemas es posible crear enlace o apuntadores a un directorio arbitrario. Estos se pueden colocar en cualquier directorio, lo que permite construir no solo arboles, sino gráficas arbitrarias de directorios que son mas poderosas. La distinción entre arboles y gráficas es de particular importancia en un sistema distribuido.
El directorio D tiene un enlace con el directorio B. El problema aparece cuando se elimina el enlace de A a B. En una jerarquía de estructura de árbol solo se puede eliminar un enlace con un directorio si el directorio al cual se apunta es vacío. En una gráfica se permite la eliminación de un enlace mientras existan al menos otros enlaces. Mediante un contador de referencias que aparece en la esquina superior derecha de cada directorio se puede determinar si el enlace por eliminar es el ultimo.
Después de eliminar el enlace de A a B, el contador de referencia de B se reduce de 2 a 1. Sin embargo ahora no es posible llegar a B desde la raíz del sistema de archivo A. Los tres directorios B, D y E y todos sus archivos se convierten en huérfanos.
Si todo esta en una máquina, es posible, aunque costoso, descubrir los directorios huérfanos, puesto que toda la información esta en un lugar. Se puede detener toda la actividad de los archivos y recorrer la gráfica desde la raíz, para señalar todos los directorios alcanzables. En un sistema distribuido existen varias máquinas y no se puede detener toda la actividad.
Un aspecto fundamental en el diseño de cualquier sistema distribuido de archivos es si todas las máquinas (y procesos) deben tener con exactitud la misma visión de la jerarquía de los directorios.
Nombre de dos niveles
La mayoría de los sistemas distribuidos utilizan cierta forma de nombres con dos niveles. Los archivos tienen nombres simbólicos, como prog.c, para uso de las personas, pero también pueden tener nombres binarios internos, para uso del propio sistema. Lo que los directorios hacen en realidad es proporcionar una asociación entre estos dos nombres. Para las personas y los programas, es conveniente utilizar nombres simbólicos, pero para el uso dentro del propio sistema, estos nombres son muy grandes y difíciles. Cuando un usuario abre un archivo o hace referencia a un nombre simbólico, el sistema busca de inmediato en el directorio apropiado para obtener el nombre binario, el cual utilizará para localizar en realidad al archivo.
Los nombres binarios varían mucho de un sistema a otro. En ciertos sistemas el nombre binario puede ser sólo un número de un nodo-i , en Unix.
En un esquema general para los nombres es que el nombre binario indique el servidor y un archivo especifico en ese servidor. Este método permite que un directorio en un servidor tenga un archivo en un servidor distinto. Otra alternativa es utilizar un enlace simbólico. Un enlace simbólico es entrada de directorio asociada a una cadena (servidor, nombre de archivo) la cual se puede buscar en el directorio correspondiente para encontrar el nombre binario. El propio enlace simbólico es sólo el nombre de una ruta de acceso.
Otra idea es utilizar las posibilidades como los nombres binarios. En este método la búsqueda de un nombre en ASCII produce una posibilidad, la cual puede tomar una de varias formas, estos nombres pueden contener un número físico o lógico de una máquina o la dirección en la red del servidor apropiado y del archivo específico necesario. Se puede utilizar una dirección física para enviar un mensaje al servidor sin mayor interpretación. Una dirección lógica se puede localizar mediante una transmisión o mediante una búsqueda en un servidor de nombres.
Otra posibilidad es buscar un nombre en ASCII y obtener no uno sino varios nombres binarios. Por lo general estos representan al archivo original y todos sus respaldos. Este método proporciona cierto grado de tolerancia de fallas por medio de la redundancia.
Semántica de los Archivos compartidos
Si dos o más usuarios comparten el mismo archivo, es necesario definir con precisión la semántica de la lectura y escritura para evitar problemas.
Existe cuatros maneras de compartir archivos :
La semántica de UNIX se puede lograr fácilmente en un sistema distribuido mientras exista un servidor de archivos y los clientes no oculten los archivos Cada operación en un archivo es visible a todos los procesos de manera instantánea.
En un sistema distribuido mientras sólo exista un servidor de archivos y los clientes no oculten los archivos. Todas las instrucciones READ y WRITE pasan en forma directa al servidor de archivos, que lo procesa en forma secuencial.
Los retrasos en la red pueden hacer que un READ ejecutado después de un WRITE llegue primero al servidor y obtenga primero el servidor. Este problema se puede resolver si se permite a los clientes que mantengan copias locales de los archivos de uso frecuente en sus cachés particulares, pero si un cliente modifica de forma local un archivo en caché y si poco después otro cliente lee el archivo del servidor obtendría un archivo obsoleto.
Para salir de esta dificultad se debería enviar de inmediato todas las modificaciones de los archivos en caché al servidor. Aunque esto es sencillo desde el punto de vista conceptual el método es ineficiente. Otra solución consiste en que los cambios a un archivo abierto solo pueden ser vistos en un principio por el proceso (o tal vez la 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. Este método es de uso común y se conoce como semántica de sesión.
La dificultad con el uso de cachés y la semántica de sesión es que viola otro aspecto de la semántica de UNIX además del hecho de que no todos los READ
regresen el valor de escritura más reciente. En UNIX, a cada archivo abierto se le
asocia un apuntador que indica la posición actual en el archivo. Una instrucción
READ toma los datos a partir de esa posición y WRITE deposita los datos ahí.
Este apuntador es compartido por los procesos que abrieron el archivo.
Ningún cambio es visible a otros procesos hasta que el archivo se cierra.
Un problema mas molesto consiste en que hacer si un archivo se reemplaza
mientras otro esta ocupado leyéndolo. Una solución consiste en que el lector
utilice el archivo anterior, aunque este ya no exista en directorio alguno de esta
forma se permite que un proceso con un archivo abierto continua utilizándolo, aún cuando este haya sido eliminado de todos los directorios. otra solución consiste en detectar la modificación del archivo y hacer que fallen los intentos posteriores por leerlos. No existe actualizaciones; es más fácil de compartir y replicar.
IMPLANTACION DE UN SISTEMA DISTRIBUIDO
Uso de archivos
Antes de implantar cualquier sistema, distribuido o no, es útil tener una buena idea de su posible uso, para garantizar la eficiencia de las operaciones de ejecución frecuente.
Es necesario hacer un estudio acerca de los patrones de uso de los archivos, mediante mediciones estáticas y dinámicas.
Las mediciones estáticas representan una medición instantánea del sistema en un cierto momento que consiste en examinar el disco y ver lo que hay en él, tamaño de los archivo, la distribución de tipo de archivos, cantidad de espacio que ocupan con varios tamaños y tipo.
Las mediciones dinámicas se llevan a cabo al modificar el sistema de archivos, de modo que registre todas las operaciones en una bitácora para un análisis posterior. Estos datos proporcionan información con respecto a la frecuencia relativa de varias operaciones, el numero de archivos abiertos en un momento dado y la cantidad de hechos compartidos.
Cuando los archivos son pequeños se sugiere transferencia de archivos completos en vez de bloques de disco entre el servidor y el cliente. Puesto que es mas sencilla y eficiente. algunos archivos son de gran tamaño por lo que hay que tomar ciertas medidas preventivas.
A demás la mayoría de los archivos tienen tiempo de vida cortos. Esto implica que seria una buena idea crear el archivo en el cliente y mantenerlo ahí hasta su eliminación. Esto elimina una cantidad importante de trafico entre el cliente y el servidor.
Es raro el uso de archivos compartidos.
Las distintas clases de archivos sugiere que tal vez se deberían utilizar mecanismos diferentes para el manejo de las distintas clases.
Estructura del sistema
En ciertos sistemas no existe distinción alguna entre un cliente y un servidor. Todas las maquinas ejecutan el mismo software básico, de modo que una maquina que desee dar servicio de archivo al publico en general es libre de hacerlo. Este ofrecimiento del servicio de archivos consiste en sólo exportar los nombres de los directorios seleccionados, de modo que otras máquinas puedan tener acceso a ellos.
En otros sistemas, el servidor de archivos y el de directorios son sólo programas del usuario, por lo que se puede configurar un sistema para que ejecute o no el software de cliente o servidor en la misma máquina. Tambien existe sistemas donde los clientes y servidores son máquinas distintas, ya sea en términos de hardware o de software. Donde los servidores y clientes pueden ejecutar versiones distintas del sistema operativo.
Otro aspecto de la implantación donde difieren los sistemas es la forma de estructurar el servicio a archivos y directorios. una forma de organización consiste en combinar ambos en un servidor, que maneje todas las llamadas a directorios y archivos. Otra posibilidad es sepáralos. En este caso la apertura de un archivo exige ir hasta el servidor de directorios para asociar su nombre simbólico con el nombre binario y después ir hasta el servidor de archivos con nombre en binario para llevar a cabo la lectura o escritura real del archivo.
Si se considera el caso de servidores de archivos y directorios independientes, los clientes envía un nombre simbólico al servidor de directorios, que a su vez regresa el nombre en binario que comprende el servidor de archivos. Es posible que una jerarquía de directorios se reparta entre varios servidores. Puede suceder que un servidor que reciba un nombre binario, pero que se refiera a otro servidor, envíe al cliente el servidor que contiene el archivo, que el cliente esta buscando ,o que la solicitud sea enviada al siguiente servidor y no contestar.
El aspecto estructural fina a considerar es si los servidores de archivos, directorios o de otro tipo deben contener la información de estado de los clientes. Existe dos escuelas de pensamiento con respecto a esto. Una escuela sugiere que los servidores no deben tener los estados, es decir, ser sin estado. En otras palabras, cuando un cliente envía una solicitud a un servidor, este la leva a cabo, envía la repuesta y elimina de sus tablas internas toda la información relativa a dicha solicitud. El servidor no guarda información alguna relativa a los clientes entre las solicitudes.
La otra escuela sostiene que los servidores conserven información de estado de los clientes entre las solicitudes.
Un servidor de archivos, que pueda abrir, leer, escribir y cerrar, al abrir un archivo debe mantener la información que relacione los clientes con los archivos abiertos por éstos. El cliente al abrir un archivo recibe un descriptor de archivó o algún otro número 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 estar autocontenida. Debe contener todo el nombre del archivo y el ajuste dentro de éste, para que el servidor pueda realizar el trabajo. Esta información aumenta la longitud del mensaje.
En un servidor con estado si falla, todas sus tablas se pierden de manera irremediable. Al volver arrancar el servidor, éste ya no tiene idea de la relación entre los clientes y los archivos abiertos por éstos. Fracasaran los intentos posteriores por leer y escribir en archivos abiertos y la recuperación quedara por completo a cargo de los clientes. En consecuencia los servidores sin estados tienden a ser más tolerantes de fallas que los que mantienen los estados.
Ocultamiento
En un sistema cliente-servidor, cada uno con su memoria principal y u disco, existen cuatro lugares donde se puede almacenar los archivos o partes de archivos: el disco del servidor, la memoria principal del servidor, el disco del cliente(si existe) o la memoria principal del cliente.
El lugar más directo para almacenar todos los archivos es el disco del servidor. Ahí existe mucho espacio y los archivos serían accesibles a todos los clientes. Además, con sólo una copia de cada archivo, no surgen problemas de consistencia.
El problema con el uso del disco del servidor es el desempeño. Antes que un cliente pueda leer un archivo, este debe ser transferido primero del disco del servidor a la memoria principal del servidor y luego, a través de la red, a la memoria principal del cliente. Ambas transferencias tardan ciertos tiempos.
Se puede mejorar el desempeño si se ocultan (se conservan) los archivos de más recientes 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, aunque se deba realizar transferencia en la red. Puesto que la memoria principal es menor que el disco, se necesita un algoritmo para determinar los archivos o partes de archivos que deben permanecer en el caché. El algoritmo debe resolver dos problemas: Primero es el tamaño de la unidad que administra el caché. Puede administrar archivos completos o bloque de disco. Si se ocultan archivos completos , éstos se pueden almacenar en forma adyacente en el disco, lo cual permite transferencia a alta velocidad entre la memoria y el disco. El ocultamiento de bloque de disco utiliza el caché y el espacio en disco en forma más eficiente.
El segundo es que el algoritmo debe decidir qué hacer si se utiliza toda la capacidad del caché y hay que eliminar a alguien. Aquí se puede utilizar cualquiera de los algoritmos comunes de ocultamiento, pero como la referencia al caché son poco frecuentes comparadas con las referencias a memoria, por lo general es factible una implantación exacta de 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, sólo se descarta la copia del caché. En caso contrario, primero se actualiza el disco.
El mantenimiento de un caché en la memoria principal del servidor es fácil de lograr. El uso de caché en el servidor elimina una transferencia de disco en cada acceso, pero tiene aun un acceso a la red. La única forma de deshacerse del acceso a la red es hacer el ocultamiento en el lado del cliente. El disco del cliente puede contener más información, pero es más lento. Al considerarlas opciones de tener una caché en la memoria principal del servidor o en el disco del cliente, la primera es más rápida y más sencilla. Si se utilizan grandes cantidades de datos, podría preferirse un caché en el disco del cliente. Si se coloca el caché en la memoria principal del cliente, existen tres opciones para su posición precisa. La más sencilla consiste en ocultar los archivos en forma directa, dentro del propio espacio de direcciones de un proceso usuario.
El segundo sitio donde se puede colocar el caché es el núcleo. La desventaja de este caso es que siempre hay que llamar al núcleo, incluso en aquellos casos en que los archivos estan dentro de la caché pero el caché sobreviva al proceso compensa en mucho este hecho.
En tercer lugar donde se puede colocar el caché es en un proceso administrador del caché, independiente y a nivel de usuario. La ventaja del administrador de la caché a nivel usuario es que libera al micronucleo del código del sistema de archivo. Es más fácil de programar y es más flexible.
El promedio de RPC (llamada a procedimiento remoto) siempre es menor si se utiliza el ocultamiento, en caso en el que las RPC sean rápidas y las transferencia en la red sean lentas, el ocultamiento puede ser un factor importante en el desempeño. Sin embargo si las transferencia en la red son rápidas, en este caso las RPC consumirían mayor tiempo. Entonces el mejoramiento en el desempeño mediante del ocultamiento depende de la tecnología y de la cpu y de las redes.
Consistencia del cache
El ocultamiento por parte del cliente introduce inconsistencia en el sistema. Si dos clientes leen un mismo archivo en forma simultanea y después lo modifican, aparecen varios problemas. Uno de ellos es que si un tercer proceso lee el archivo del servidor, obtendrá la versión original y no algunas de las nuevas. Este problema se puede evitar mediante la semántica de sesión(donde los efectos de modificación no son visibles en forma global hasta que se cierra el archivo).
Otro problema es que cuando dos archivos se escriben de nuevo al servidor, el ultimo de ellos se escribirá sobre el otro.
Una forma de solucionar el problema de la inconsistencia es utilizar el algoritmo de escritura a través del cache. Cuando se modifica una entrada del cache, el nuevo valor se mantiene dentro de él, pero tambien se envía de inmediato al servidor. Entonces cuando otro proceso lee el archivo obtiene el valor mas reciente. Surge el siguiente problema, un proceso cliente en la máquina A lee un archivo f, pero la máquina mantiene f en su caché. Luego un cliente en la máquina B lee el mismo archivo modifica y lo actualiza en el servidor. Por ultimo un nuevo proceso cliente inicia en la máquina A lee el archivo f del caché. Por desgracia su valor es obsoleto.
Una solución consiste en exigir al manejador de caché que verifique el servidor antes de proporcionar al cliente un archivo del caché. La verificación se puede realizar mediante una comparación de la hora de la ultima modificación de la versión en la caché con la ultima versión del servidor. Si son iguales el caché esta actualizado. Sino la versión actual se debe buscar en el servidor. Otro problema con este algoritmo de escritura es que produce trafico en la red en el caso de la escritura como en el caso que no exista ocultamiento. Una solución a este problema es que el cliente una vez cada 30 segundo reúna todas las actualizaciones y la envía al servidor al mismo tiempo. El retraso de la escritura oscurece la semántica, puesto que si otro proceso lee el archivo lo que obtendrá dependerá de la sincronización de los eventos.
Otro algoritmo para manejar caché del cliente es la escritura del cierre, que consiste en escribir un archivo nuevamente en el servidor solo cuando este se cierre, se puede esperar 30 segundos después del cierre para ver si el archivo es eliminado.
Un método distinto a la consistencia es utilizar un algoritmo de control centralizado. Al abrir un archivo, la maquina que lo abre envía un mensaje al servidor para anunciar este hecho. El servidor de archivo tiene un registro de los archivos abiertos, sus poseedores y si estan abiertos para lectura y escritura o para ambos procesos. La lectura no presenta ningún inconveniente, contrariamente si un proceso tiene un archivo abierto para escritura, se debe evitar que otros proceso lo abran. Cuando se cierra un archivo se debe informar de ello al servidor para que pueda actualizar sus tablas, para indicar sus archivos abiertos y sus poseedores.
Replica
La replica consiste en disponer en varias copias de algunos archivos donde cada copia esta en un servidor de archivos independiente. La razones principales son aumentar la confiabilidad al disponer de respaldos independientes de cada archivos. Si un servidor falla no se pierden los datos.
Otra razón es permitir el acceso al archivo aunque falle un servidor de archivo, ósea la falla de un servidor no debe hacer que todo el sistema se detenga.
Tambien permite repartir la carga de trabajo en varios servidores. Con varios archivos duplicado en dos o más servidores, se puede utilizar el que tenga menor carga. Un aspecto clave en la replica es la transparencia. En un caso los usuarios pueden tener consciencia del proceso de replica y lo pueden controlar.
En otro caso el sistema hace todo a espalda de los usuarios, este sistema seria transparente con respecto a la replica.
Una forma consiste en que programador controle todo el proceso de replica. Cuando un proceso crea un archivo lo hace en un servidor especifico, puede crear varias copias adicionales en otros servidores. Si el servidor de directorios permite varias copias de un archivo, las direcciones de la red de todas las copias se asocian con el nombre del archivo, de este modo cuando se busca el nombre se encuentran todas las copias. Esto se llama replica explícita.
Otro método es la replica retrasada, solo se crea una copia de cada archivo en un servidor. Luego el propio servidor crea replica en otro servidores en forma automática. El sistema debe ser hábil como para recuperar algunas de estas copias cuando se necesiten. Se debe tener en cuenta de que el archivo podría cambiar antes de que se hagan las copias secundarias.
Tambien se puede utilizar la comunicación en grupo para realizar la replica. Todas las llamas WRIRTE al sistema se transmite en forma simultanea a todos los servidores a la vez, las copias adicionales se hacen al mismo tiempo que las originales.
Protocolo de actualización
Réplicación con copia primaria: Un servidor es primario, el resto son secundarios. La actualización llega al servidor primario, éste realiza los cambios en forma local y después envía órdenes a los servidores secundarios para que realicen las mismas modificaciones. Las lecturas se ejecutan desde cualquier servidor. ¿Qué sucede si falla el primario antes de la actualización de los secundarios? Si falla el primario, ¿quién hace las actualizaciones?. Para solucionar este problema se utiliza el método del voto. Los clientes solicitan y requieren permiso de varios servidores antes de leer o escribir en un archivo replicado. Para leer de un archivo de N réplicas, un cliente necesita un quórum de lectura Nr servidores o más. Para modificar se requiere un quórum de escritura Nw y se debe cumplir que Nr + Nw > N. El voto consiste del número de la versión asociado al archivo. ¿Qué sucede si fallan muchos servidores y quedan menos de Nw?. No se puede llegar a un acuerdo. Una variante del voto es el voto con fantasma. Pretende aliviar el problema anterior. La idea es crear un servidor fantasma sin espacio de almacenamiento para cada servidor real que falle. En las lecturas no se permiten fantasmas. Las escrituras sólo tienen éxito si al menos uno de los servidores es real. Cuando se levante un servidor, obtiene un quórum de lectura para localizar la versión más reciente.
SISTEMA DE ARCHIVO DE RED (NFS) DE SUN
Este sistema soporta sistemas y maquinas heterogéneos. La idea básica del NFS es permitir que una colección arbitraria de clientes y servidores compartan un sistema de archivos común. En la mayoría de los casos, todos los clientes y servidores estan en la misma LAN, pero esto no es necesario.
El NFS permite que cada máquina sea cliente y servidor al mismo tiempo.
Cada servidor NFS exporta uno o más de sus directorios para su acceso por parte de los clientes remotos. Cuando se dispone de un directorio, tambien de todos sus directorios. Los clientes tienen acceso a los directorios exportados al montarlos. Cuando un cliente monta un directorio (remoto), este se vuelve parte de su jerarquia de directorios. Un cliente sin disco puede montar un sistema de archivos remoto en su directorio raíz, lo que produce un sistema de archivos por completo soportado en un servidor remoto. Las estaciones de trabajos que si tienen discos locales pueden montar directorios remotos en el sitio que deseen de su jerarquía local de directorios, lo que produce un sistema de archivos parcialmente local y parcialmente remoto.
La característica básica del NFS es que los servidores exportan directorios y los clientes los montan de manera remota. Si dos o más clientes montan el mismo directorio al mismo tiempo, se pueden comunicar compartiendo archivos en sus directorios comunes. Una vez realizado los montajes, no hay que hacer nada especial para lograr compartir los archivos. Los archivos compartidos sólo estan en la jerarquía de directorios de varias maquinas y pueden leerse y escribir en ellos de la manera usual.
Protocolos de NFS
Uno de los objetivos del NFS es soportar un sistema heterogéneo, con cliente y servidores que tal vez ejecuten diferentes sistemas operativos con hardware distintos. Es esencial que la interfaz entre los clientes y los servidores esté bien definida.
NFS logra este objetivo al definir dos protocolos cliente-servidor. Un protocolo es un conjunto de solicitudes enviadas por los clientes a los servidores, junto con las respuestas enviadas de regreso de los servidores a los clientes.
El primer protocolo NFS controla el montaje. Un cliente puede enviar un nombre de ruta de acceso a un servidor y solicitar para montar ese directorio en alguna parte de su jerarquía de directorios. El lugar donde se montará no esta contenido en el mensaje, ya que el servidor no se preocupa por dicho lugar. Si la ruta es valida y el directorio especificado, ha sido exportado, el servidor regresa un asa de archivo al cliente, que contiene campos que identifican de manera única al tipo de sistema de archivo, el disco, número de nodo-i del directorio, e información de seguridad. Las llamadas posteriores para la lectura y escritura de archivos en el directorio montado utilizan el asa del archivo. Existe otra alternativa donde el cliente se libera del montaje. El automontaje, es una característica que permite asociar un conjunto de directorios con un directorio local. Esto se logra cuando se abre por primera vez un archivo remoto. El sistema operativo envía un mensaje a cada uno de los servidores, el primero en responder gana, y se monta su directorio.
La ventaja del automentaje con respecto al montaje estático es que se evita contactar servidores y montar directorios que no son requeridos de inmediato.
Si el cliente puede utilizar varios servidores en paralelo, se puede tener cierta tolerancia a fallas y mejorar el rendimiento.
El automontaje se utiliza con más frecuencia para los sistemas de archivos exclusivos para lectura que contienen binarios del sistema y para otros archivos que rara vez cambian.
El segundo protocolo NFS es para el acceso a directorios y archivos. Los clientes pueden enviar mensajes a los servidores para que manejen los directorios y lean o escriban en archivos. Además, también pueden tener acceso a los atributos de un archivo, como el modo, tamaño y tiempo de su última modificación.
Cada uno de estos mensajes está autocontenido, la ventaja de este esquema es que el servidor no tiene que recordar lo relativo a las conexiones abiertas entre las llamadas a él. Así, si un servidor falla y después se recupera , no se pierde información acerca de los archivos abiertos, puesto que no hay ninguno. Un servidor como éste, que no conserva información del estado de los archivos es sin estado. Por el contrario, el sistema V de Unix, el sistema de archivos remotos (rfs) requiere abrir un archivo antes de leerlos y escribir en él. El servidor crea una entrada de tabla con un registro del hecho del que el archivo este abierto y la posición actual del lector. La desventaja es que si el servidor falla y vuelve a arrancar rápidamente se pierde todas las conexiones y fallan los programas clientes. Por desgracia el método NFS dificulta el hecho de lograr la semántica de archivo propia de Unix. En Unix un archivo se puede abrir y bloquear para que otro proceso no tengan acceso al él, al cerrar el archivo se liberan la cerradura de bloqueo. En un servidor sin estado como el NFS la cerradura no se puede asociar con los archivos abiertos puesto que el servidor no sabe cual archivo estan abiertos. NFS necesita un mecanismo independiente para controlar la cerradura.
NFS utiliza el mecanismo de protección de Unix, con los bit rwx para el propietario, grupo y demás personas. En un principio, cada mensaje de solicitud sólo contenia los identificadores de usuario y del grupo de quien realizo la llamada, lo que utilizaba el servidor NFS para validar el acceso. Actualmente se puede utilizar la criptografía de claves públicas para establecer una clave segura y validar al cliente y al servidor en cada solicitud y respuesta.
Todas las claves utilizadas para la autenticación, así como las demás información, son mantenidas por el NIS( servicio de información de red). La función del NIS es de guardar parejas (clave, valor). Cuando se proporciona un clave, regresa el valor correspondiente. No solo controla la clave de cifrado, sino tambien la asociación de los nombres de usuarios con las contraseñas (cifradas), así como la asociación de los nombres de las máquinas con las direcciones de la red, y otros elementos.
Implantación de NFS
Aunque la implantación del código del cliente y el servidor es independiente de los protocolos NFS, es interesante echar un vistazo a la implantación de NFS. Consta de tres capas. La capa superior es la capa de llamadas al sistema. Después de analizar la llamada y verificar sus parámetros, llama a la segunda capa, la capa del sistema virtual de archivos (VFS). La tarea de la capa VFS es mantener una tabla con una entrada por cada archivo abierto llamada nodo-v (nodo-i virtual). Los nodos-v se utilizan para indicar si un archivo es local o remoto. Para los archivos remotos, se dispone de suficiente información para tener acceso a ellos.
Para montar un sistema remoto de archivos, el administrador del sistema llama al programa mount con la información del directorio remoto, el directorio local donde será montado y algunos otros datos adicionales. El programa mount analiza el nombre del directorio remoto. Si el directorio existe y está disponible para su montaje remoto, el servidor regresa entonces un asa de archivo para el directorio. Por último , llama a mount para transferir el asa del archivo al núcleo. El núcleo construye entonces un nodo-v para el directorio remoto y pide el código del cliente NFS. El nodo-v apunta al nodo-r. Así, cada nodo-v de la capa VFS contendrá en última instancia un apuntador a un nodo-r en el código del cliente NFS o un apuntador a un nodo-i en el sistema operativo local. Así, es posible ver desde el nodo-i un archivo o directorio es local o remoto y, si es remoto encontrar su asa de archivo.
Al abrir un archivo remoto, en cierto momento durante el análisis del nombre de la ruta de acceso, el núcleo alcanza el directorio donde se desea montar el sistema de archivo remoto. Ve que este es remoto y el nodo-v del directorio encuentra el apuntador. Le pide entonces al código del cliente NFS que abra el archivo. El cliente NFS busca la parte restante del nombre de la ruta de acceso en el servidor remoto asociado con el directorio montado y regresa un asa de archivo para él. Crea en su tabla un nodo-r para el archivo remoto my regresa ala capa VFS, la cual coloca en su tabla un nodo-v para el archivo que apunta al nodo-r. Vemos que todo archivo o directorio abierto tiene un nodo-v que apunta a un nodo-r o aun nodo-i.
Quien hizo la llamada recibe un descriptor de archivo para el archivo remoto. Este descriptor de archivo se asocia con el nodo-v mediante la tabla en la capa VFS.
Cuando el descriptor de archivo se utiliza en una llamada posterior al sistema, la capa VFS localiza el nodo-v correspondiente y por medio de él determina si es local o remoto y el nodo-i o nodo-r que lo describe.
La transferencia entre el cliente y el servidor se realiza en bloques grandes por lo general en bloques de 8k. Después que la capa VFS del cliente a obtenido el bloque emite en forma automática una solicitud del siguiente bloque, esto se conoce como lectura adelantada y mejora el desempeño.
Con respecto a la escritura si el bloque no llega a 8k los datos se acumulan en forma local hasta que este completo, cuando se completa se envía al servidor. Sin embargo al cerrar un archivo todos sus datos se envían al servidor de manera inmediato. Para mejorar el desempeño los servidores ocultan los archivos del disco en el cache, estos es invisible para los clientes. Los clientes tambien ocultan archivos en los cache, cuando se necesita un archivo primero se verifica el cache, si se encuentra alli se evita el trafico en la red. El problema es que afecta la semantica de archivo. El cache del cliente no es coherente. Para solucionar este problema NFS asocia a cada bloque del cache un cronometro, cuando este expira la entrada se descarta. Por lo general asocia 3 sg para bloques de datos y 30 para bloques de directorios. Cuando expiran los cronometros los bloques modificados se envian al servidor. Tambien al abrir un archivo en cache se puede enviar un mensaje al servidor para revisar la hora de la ultima modificacion. Si la ultima modificacion ocurrio antes de capturar en el cache la copia local, se descarta la copia del cache y se utiliza la nueva copia del servidor.
SISTEMA DE ARCHIVOS ANDREW
AFS proporciona acceso transparente a archivos compartidos remotos para los programas UNIX que se ejecutan en estaciones de trabajo. AFS es compatible con NFS. Los servidores AFS mantienen los archivos UNIX locales, pero el sistema de archivo en los servidores esta basado en NFS, los archivos pueden ser accedidos remotamente a través de NFS.
AFS difiere con NFS en su diseño e implementacion. La principal diferencia en diseño es la mayor escalabilidad, AFS esta diseñado para trabajar bien con gran cantidad de usuarios activos, la clave para alcanzar la escalabilidad es la cache de los archivos completos en el cliente.
AFS tiene dos características de diseño inusuales:
Servicios de archivos completo: el contenido entero de los directorio y de archivos es transmitido a los computadores clientes por los servidores AFS(los archivos grandes son transferidos en trozos de 64 kbytes).
Cache de archivo completo: la cache contiene varios cientos de archivos, los mas utilizados recientemente en el computador . Las copias locales de los archivos se utilizan para satisfacer las necesidades de los clientes.
Cuando un proceso usuario en un computador cliente intenta acceder a un archivo que no este presente en él cache local, se localiza el servidor y se solicita una copia del archivo. El cliente recibe una copia del archivo, todas las operaciones de lectura y escritura se realizan en la copia local. Cuando se actualiza el archivo se envía la copia al servidor quien actualiza el archivo original y sus marcas de tiempo.
La copia en el disco local del cliente es retenida por si se necesita de nuevo por un proceso usuario en la misma estación de trabajo.
Para archivos compartidos que son actualizados infrecuentemente y para archivos que son accedidos frecuentemente por un usuario, las copias en el cache permanecen validas durante períodos largos, en el primer caso porque no se actualizan y en el segundo porque si se actualizan. La copia actualizada estará en la cache de la estación de trabajo.
La cache local puede reservar un espacio en el disco de la estación de trabajo para que cada usuario pueda establecer su conjunto de trabajo.
Implementación
AFS esta implementado como dos componentes software que existen como procesos UNIX llamados Vice y Venus.
Venus es un proceso a nivel usuario que se ejecuta en cada computador cliente. Los archivos disponibles para los procesos de usuario que se ejecutan en estaciones de trabajo son locales o compartidos. Los archivos locales se manejan como archivos UNIX. Están almacenados en el disco de la estación de trabajo y están disponibles solo para los procesos de usuario locales. Los archivos compartidos están almacenados en los servidores y las copias de ellos son introducidas en el cache en los discos locales de las estaciones de trabajo.
Los directorios de los usuarios están en el espacio compartido permitiendo a los usuarios acceder a sus archivos desde cualquier estación de trabajo.
Venus administra la cache eliminando los archivos menos recientemente utilizados cuando necesita ese espacio para un nuevo archivo. El cache es lo suficientemente grande para alojar a cientos de archivos.
Los servidores Vice implementan un servicio de archivos planos, y la estructura jerárquica de directorios requerida por los programas usuario UNIX es implementada en el conjunto de procesos Venus en las estaciones de trabajo. Cada archivo y directorio en el espacio de archivos compartido se reconoce por un identificador de archivo único de 96 bits (ida). Los procesos Venus trasladan los nombres de ruta emitidos por los clientes a ida. Los archivos se agrupan en volúmenes para facilitar la localización y el movimiento. La representación de cada ida incluye el numero de volumen para el volumen que contiene el archivo y un identificador único.
AFS utiliza las idas en la comunicación entre los procesos Venus y Vice. Los servidores Vice aceptan solicitudes solo en términos de idas. Venus traduce los nombres de ruta proporcionados por los clientes en idas utilizando una búsqueda paso a paso para obtener información de los archivos, directorios mantenidos en los servidores Vice.
Consistencia del cache
Cuando Vice proporciona una copia de un archivo a un proceso Venus también le proporciona una promesa de devolución de llamada, un testigo emitido por el servidor Vice que es el custodio del archivo, que garantiza que notificara al proceso Venus cuando otro cliente modifica el archivo. Las promesas de devolución de llamadas se almacenan en archivos en la cache y tienen dos estados(valida o cancelada). Cuando un servidor realiza una solicitud para actualizar un archivo notificara a todos los procesos venus a los que ha emitido promesas de devolución de llamada, una promesa de devolución de llamada es una RPC desde el servidor al proceso venus. Cuando el proceso venus recibe una devolución de llamada, coloca el testigo de la promesa de devolución de llamada para el archivo relevante a cancelada. Cuando venus usa OPEN en nombre de un cliente, comprueba la cache. Si el archivo requerido se encuentra en la cache, se comprueba el testigo. Si su valor es cancelada, entonces debe buscarse una copia reciente del archivo en el servidor vice, pero si el testigo es valida, entonces puede ser abierta y utilizada la copia de la cache sin referenciar a vice.
Cuando se produce un fallo del servidor, por cada archivo con testigo valido, venus envía al servidor una solicitud de validación de la cache que contiene la marca de tiempo de modificación del archivo. Si la marca es actual el servidor responde con valida y el testigo es rehabilitado. Si la marca de tiempo muestra que el archivo esta caducado, el servidor responde con cancelada y el testigo es colocado a cancelada.
Las promesas de devolución de llamadas deben ser renovadas antes de un open si ha transcurrido un tiempo t desde que el archivo fue introducido en la cache sin comunicación con el servidor. Las ultimas versiones de AFS requiere que los servidores vice mantengan algo del estado en nombre de sus clientes. La información de estado consiste en mantener una lista de los procesos venus para los que se han planteado promesas de devolución de llamada para cada archivo. Estas listas deben retenerse en casos de fallo del servidor, se mantienen en el disco del servidor y se actualizan con operaciones atómicas.
Semántica de actualización
La semántica de UNIX requiere que los resultados de cada write a un archivo sean distribuidos a todos los sitios en los que se mantenga el archivo en la cache antes de que puedan ocurrir otros accesos. Este tipo de semántica no se utiliza en sistemas de gran escala. Si se utiliza AFS un cliente puede abrir una copia antigua de un archivo después de que haya sido actualizado por otro cliente. Esto ocurre si se pierde un mensaje de devolución de llamada en caso de un fallo en la red. Pero existe solo un tiempo máximo t en el cual el cliente no conoce la nueva versión de un archivo. T representa el intervalo de tiempo en que deben ser renovadas las promesas de devolución de llamada. En la mayoría de las instalaciones el valor de t es de 10 minutos.
AFS no proporciona otro mecanismo para el control de actualizaciones concurrentes.
El algoritmo para la consistencia del cache se utiliza solo con las operaciones open y close. Una vez abierto el archivo el cliente puede acceder y actualizar la copia local sin el conocimiento de ninguno de los procesos en las otras estaciones de trabajo. Cuando se cierra un archivo, se devuelve una copia al servidor reemplazando la versión actual.
Si los clientes en diferentes estaciones de trabajo hacen open, write, close sobre el mismo archivo, todas las actualizaciones menos la resultante del ultimo close se perderán, no se da ningún informe de error. La implementacion de un control de concurrencia queda a cargo de los usuarios. Por otro lado si dos clientes en la misma estación de trabajo abren el mismo archivo, comparten la misma copia del cache y las actualizaciones son realizadas en la forma normal UNIX, bloque a bloque.
Aunque las semánticas de actualización de AFS y UNIX difieren, son lo suficientemente próxima para que la gran mayoría de los programas UNIX existentes trabajen concurrentemente.
Otros aspectos
Replicas de solo lectura: Los volúmenes conteniendo archivos que son leídos frecuentemente pero modificados raramente, pueden estar replicados como volúmenes de solo lectura en varios servidores, de este modo solo hay una replica de lectura/escritura y todas las actualizaciones se dirigen a ella. La propagación de los cambios en la replica de solo lectura, se realiza después de la actualización por un procedimiento operativo explícito.
Transferencias al por mayor: AFS transfiere archivos entre los clientes y los servidores en trozos de 64 kbytes. E l uso de paquetes de tan gran tamaño es una ayuda importante para las prestaciones, minimizando el efecto de latencia de la red. Por tanto el diseño de AFS permite optimizar el uso de la red.
Cacheado parcial de archivos: Tener que transferir todo un archivo al cliente solo para este lea una porción del mismo produce ineficiencia. AFS permite transferir e introducir archivos en el cache en bloques de 64 kbytes, manteniendo la semántica de consistencia y otras características del protocolo AFS.
Avances Recientes
Desde la aparición de NFS y AFS se han realizado varios avances en el diseño de sistemas de archivos distribuidos con respecto a escalabilidad, disponibilidad y prestaciones.
MEJORAS NFS
Obtención de la semántica de actualización de una copia: en NFS los efectos de las escrituras concurrentes por diferentes clientes en el mismo archivo no esta garantizado que sean las mismas que serian en un sistema único UNIX cuando múltiples archivos escriben en un archivo local. También impide las devoluciones de llamada para notificar a los clientes los cambios en los archivos y esto provoca solicitudes frecuentes de getattr de los clientes para comprobar la modificación de archivos.
El sistema Spritely NFS es una implementación del protocolo NFS con la adición de llamadas OPEN y CLOSE. Los módulos de los clientes deben enviar una operación OPEN cuando un proceso local a nivel de usuario abre un archivo que esta en el servidor. Los parámetros de una operación OPEN en Sprite especifican un modo(lectura, escritura, o ambas)e incluyen contadores del numero de procesos locales que tienen el archivo abierto para lectura y para escritura. De modo semejante, cuando un proceso local cierra un archivo remoto se envía una operación CLOSE al servidor con los contadores actualizados de los lectores y escritores. El servidor registra esos números en una tabla de archivos abiertos con la dirección IP y numero de puerto del cliente.
Cuando un servidor recibe un OPEN, comprueba la tabla de archivos abiertos para otros clientes que tengan el mismo archivo abierto y envía mensajes de devolución de llamadas a dichos clientes instruyéndoles para modificar su estrategia de cache. Si open especifica el modo de escritura, entonces fallara si cualquier otro cliente tiene el archivo abierto para escritura. Los clientes que tengan los archivos abiertos para la lectura serán instruidos para invalidar cualquier porción del archivo en el cache local.
Estas medidas conducen a un servicio de archivos que mantienen la semántica de actualización de una copia UNIX. También permite ganar alguna eficiencia en el mantenimiento de las escrituras en el cache. Si el estado relacionado con el cliente se mantiene en memoria volátil y se produce un fallo del servidor, el sistema implementa un protocolo de recuperación que interroga a una lista de clientes con archivos abiertos recientemente en el servidor para recuperar la tabla de archivos abiertos completa.
Cuando se evalúo Spritely NFS frente a NFS se observo un mejor tratamiento en el uso del cache de escritura. También se comprobó que es posible conseguir la semántica de actualización de una copia sin perdidas de prestaciones.
WebNFS: el objetivo de WebNFS es permitir a los navegadores web, programas java y otras aplicaciones interaccionar con un servidor NFS directamente para acceder a archivos que se encuentran publicados utilizando un apuntador de archivo publico para acceder a los archivos relativos a un directorio raíz publico. Para acceder a los archivos por nombre de ruta los clientes lanzan solicitudes lookup utilizando un apuntador publico de archivo. El apuntador publico de archivo tiene un valor bien conocido que es interpretado especialmente por el sistema de archivos virtual en el servidor.
También en redes de área amplia se puede buscar un nombre de ruta compuesta en una única solicitud.
Para leer una porción de un archivo localizado en un servidor NFS que soporta WebNFS se precisa el establecimiento de una conexión TCP y dos llamadas RPC, un lookup compuesto y una operación READ. El tamaño del bloque leído no esta limitado por el protocolo NFS.
MEJORAS EN AFS
El sistema DFS va mas allá que AFS particularmente en la consistencia del cache. En AFS las devoluciones de llamada se generan solo cuando el servidor recibe una operación CLOSE para un archivo que ha sido actualizado. DFS utiliza una estrategia semejante a la de SpritelyNFS para generar devoluciones de llamada tan pronto como ha sido actualizado el archivo. Para actualizar un archivo, el cliente debe obtener un testigo WRITE del servidor, especificando el rango de bytes del archivo en el que se permite al cliente actualizar el archivo. Cuando se solicita en testigo WRITE, los clientes que mantienen copias del mismo archivo para lectura reciben devoluciones de llamada de revocación. Todos los testigos tienen un tiempo de vida asociado, y los clientes los deben renovar después de que dicho tiempo ha transcurrido.
MEJORAS EN LA ORGANIZACIÓN DEL ALMACENAMIENTO
El principal avance en almacenamiento esta dado por el modo RAID(cadenas redundantes de discos baratos), los bloques de datos están segmentados en trozos de tamaño fijo y almacenados en ristras entre varios discos, también disponen de un código corrector que permite la recuperación de los bloques.
Otro avance importante se dio con el proyecto LFS(almacén de archivo estructurado en histórico). Si se asigna mayor cantidad de memoria principal para el cache en los servidores se obtienen excelentes prestaciones lectura. Pero las prestaciones en escritura siguen siendo mediocres debido a las altas latencias asociadas con las escrituras en bloques del disco. LFS acumula un conjunto de escrituras en memoria y entonces llevarlas al disco en segmentos de tamaño fijo, grandes y contiguos. Los bloques de datos son almacenados en el orden en que fueron actualizados. LFS logra prestaciones globales excelentes y también mejora la recuperación luego de la falla de un servidor.
LFS fue mejorado en el sistema de archivo ZEBRA, este combina escritura estructurada en históricos con una aproximación RAID distribuida, los segmentos se subdividen en secciones con corrección de error en los datos y escrituras en los discos en nodos de red separados. Las prestaciones son cuatro a cinco veces las de NFS.
A raíz de estos avances surge el sistema xFS, sin servidor en el sentido que distribuye las responsabilidades del servidor de archivos entre un conjunto de computadores disponibles en la red local. Con respecto al almacenamiento xFS implementa un software de sistema de almacenamiento RAID, se reparten los datos en varios computadores. También utiliza la técnica de estructuración en históricos de una manera similar ZEBRA.
Se realizaron estudios utilizando un prototipo de xFS, se comparo con AFS y NFS. Los resultados indican que el proceso altamente distribuido y la arquitectura de almacenamiento de xFS permite alcanzar una mayor escalabilidad en los sistemas distribuidos.
TENDENCIAS EN LOS SISTEMAS DISTRIBUIDOS DE ARCHIVOS
En estos últimos años se ha logrado un avance significativo tanto en software como en hardware. Es probable que los cambios en hardware tengan un efecto importante en los sistemas distribuidos de archivos.
El hecho de que la memoria se siga abaratando produciría un efecto significativo en los sistemas distribuidos de archivos, de este modo el sistema de archivo podría estar
presente en la memoria en forma permanente y no existirá la necesidad de los discos. También mejoraría mucho el desempeño y haría mucho más sencillo la estructura del sistema de archivo.
La mayoría de los sistemas de archivos de la actualidad organizan los archivos como una colección de bloques, ya sea como árbol (UNIX) o como una lista ligada (MS-DOS). Con un sistema de archivos en el núcleo, podría ser más sencillo almacenar el archivo en forma adyacente en la memoria, en vez de separarlo en bloques. Es más fácil llevar un registro de los archivos almacenados en forma adyacente, además de que se pueden transmitir más rápido en la red. La razón de que los archivos adyacentes no se utilicen en los discos es que, si un archivo crece, su desplazamiento hacia un área del disco con mas espacio es una operación cara. Por el contrario, el desplazamiento de un archivo a otra área de la memoria es una operación factible.
La principal desventaja de tener el servidor de archivos en la memoria principal es si se interrumpe la energía eléctrica, se pierden todos los archivos. La memoria principal se borra al eliminar la electricidad. La solución seria hacer respaldos continuos en cintas de videos, pero si solo se necesita tener acceso una o dos veces por año para recuperarse de fallas en la energía, este método no es conveniente.
Otra forma de hacer respaldos sería utilizando discos ópticos, cuando la carga de trabajo no es pesada, los archivos que todavía no hayan sido respaldados se transfieren al disco de modo que el byte k de la memoria sea el byte k del disco, la asociación entre el dispositivo de respaldo y la memoria es uno a uno.
Otro desarrollo importante en hardware son las redes de fibras ópticas. Se podría equipar al sistema con un servidor de archivos en la memoria principal, una red de fibras ópticas de alta velocidad y haciendo respaldos en discos ópticos, no seria necesario el cache del cliente y el disco en el servidor.
Otro avance sería diseñar una nueva interfaz de red exclusivamente para solucionar el problema de la inconsistencia del cache de los clientes, la situación que se presenta cuando dos clientes ocultan el mismo archivo y uno de ellos lo modifica y el otro no descubre esto es análoga a los cache de memoria en un multiprocesador. Solo que en este caso, cuando un procesador modifica una palabra compartida, se envía una señal de hardware a través del bus de la memoria a los demás caches, con el fin de permitirles que invaliden o actualicen dicha palabra. Entonces se podrían diseñar interfaces de red que soporten estas señales.
Cada interfaz tendría un mapa de bits, uno por cada archivo en el cache. Para modificar un archivo, un procesador activa el bit correspondiente en la interfaz, el cual es 0 si ningún procesador ha actualizado recientemente el archivo. La activación de un bit hace que la interfaz cree y envíe un paquete a través del anillo que verifique y active el bit correspondiente en las demás interfaces. Este mecanismo permite cerrar el archivo en forma global en todas las maquinas en unos pocos microsegundos.
Luego de la actualización el procesador limpia el bit del mapa de bits, lo cual hace que la interfaz de la red localice el archivo mediante una tabla en memoria y que deposite en forma automática todos los bloques modificados en su posición correcta en las demás maquinas. Cuando el archivo queda actualizado en todas partes, el bit del mapa de bits se limpia en todas las maquinas.
Escalabilidad
La escalabilidad se refiere a que los sistemas son cada vez mas grandes, este hecho afecta al diseño de los sistemas de archivos. Los algoritmos que funcionan bien para 100 maquinas pueden trabajar un poco mal para los sistemas con 1000 maquinas y
no funcionar con 10000 maquinas. Por lo general los algoritmos centralizados no se escalan bien, en cierto momento cuando el sistema crece demasiado se puede convertir en cuello de botella.
La solución a este problema es separar el sistema en unidades pequeñas que sean independientes y que cada unidad disponga de un servidor.
Las transmisiones también constituyen un problema. Si cada maquina realiza una transmisión por cada segundo, con n maquinas, hay un total de n transmisiones en la red por cada segundo, lo cual genera n2 interrupciones.
Por otra parte la semántica de UNIX, es difícil de implantar al crecer los sistemas, con respecto a este tema se debe tomar una decisión puesto que los programadores prefieren trabajar con una semántica bien definida, pero estas son las que no se escalan bien.
Otro problema es que al crecer los sistemas también crece la longitud de los nombres de las rutas de acceso cuando se utiliza un árbol de archivos en UNIX, sería necesario partir el árbol de archivos en arboles más pequeños.
Redes de área amplia
En la actualidad el trabajo relativo a los sistemas distribuidos se centra en los sistemas basados en LAN. En el futuro, muchos sistemas basados en LAN serán conectados entre si para formar sistemas distribuidos transparentes a través de piases y continentes.
El problema es como lograr esa transparencia, en la mayoría de las redes de área amplia existen una gran variedad de equipo. Lo primero que se debe lograres que los sistema sean heterogéneos.
Al difundirse cada vez más los sistemas distribuidos, la tendencia de los usuarios que va en crecimiento es su inclinación hacia el correo electrónico, la banca electrónica, el acceso a las bases de datos y actividades recreativas, esto cambiará el uso de los archivos y los patrones de acceso.
Otro problema en los sistemas distribuidos masivos es que el ancho de banda de la red es muy bajo. Si la línea telefónica es la conexión principal, no se obtienen de ella más de 64 Kb por segundo. Tardara décadas llevar las fibras ópticas a todas las casas, además el costo será muy alto. Por otro lado se pueden almacenar grandes cantidades de datos en discos compactos y cintas de vídeo. En vez de conectarse a la computadora de la compañía telefónica para buscar cierto número, podría ser mas barato enviar a cada persona un disco o cinta con toda la base de datos. Tal vez habría que desarrollar sistemas de archivos donde se distinga entre la información estática y exclusiva para lectura (por ej. el directorio telefónico) y la información dinámica (por ej. el correo electrónico). Esta distinción podría ser la base de todo el sistema de archivos.
Usuarios móviles
Las computadoras portátiles son el segmento de mayor crecimiento en la industria de la computación. El hecho es que gran parte del tiempo el usuario esta desconectado del sistema de archivos. La principal solución se basa en el ocultamiento. Mientras este conectado el usuario carga en la computadora portátil los archivos que piensa utilizar después. Estos se utilizan mientras esta desconectado. Al reconectarse, los archivos en el caché deben fusionarse con los existentes en el árbol de directorios. Puesto que la desconexión puede durar horas e incluso días, los problemas de mantenimiento de la consistencia del caché son muchos más severos que en los sistemas en línea.
Otro problema es que al ocurrir la reconexión, el usuario se puede encontrar en una ciudad lejana de su origen. Una llamada telefónica a la maquina de origen es una forma de volverse a sincronizar, pero el ancho de banda del teléfono es bajo. Además en un sistema distribuido verdadero, bastaría contactar con el servidor local de archivos.
Tolerancia a fallas
Los sistemas en la actualidad en general no son tolerantes a fallas a excepción de los que controlan el trafico aéreo. Con la difusión de los sistemas distribuidos, crecerá la demanda de sistemas que esencialmente nunca fallen. Los sistemas actuales no pueden cumplir ese requisito.
Estos sistemas necesitaran una considerable redundancia en hardware, infraestructura en comunicación, software y particularmente datos. También la replica de archivos será un requisito fundamental en los sistemas futuros. También se tendrán que diseñar los sistemas para que funcionen cuando solo se dispone de una parte de los datos, puesto que la insistencia en la disponibilidad de todos los datos no conduce a la tolerancia de fallas. Los tiempos de falla que ahora consideran aceptables los programadores y otros usuarios complejos, lo serán cada vez menos, al difundirse el uso de las computadoras entre las personas no especializadas.
Multimedia
Las aplicaciones que implican el vídeo en tiempo real o multimedia, tendrán un efecto enorme en los sistemas distribuidos de archivo del futuro.
Los archivos de texto rara vez tienen unos cuantos megabytes de longitud, pero los archivos de vídeo pueden exceder con facilidad un gigabyte. Para controlar las aplicaciones como el vídeo por solicitud, se necesitaran sistemas de archivos por completo diferentes.
CONCLUSIÓN
Las características fundamentales para el diseño de un sistema distribuido son:
Las prestaciones de los sistemas de archivos distribuidos han estado sujetas a muchos ajustes. NFS tiene un protocolo sin estado sencillo, se ha mantenido como la tecnología dominante de los sistemas de archivos distribuidos con algunas mejoras menores que se le han hecho.
AFS demostró una viabilidad de una arquitectura relativamente sencilla utilizando el estado del servidor para reducir el coste del mantenimiento de la coherencia de las caches en los clientes.
AFS sobrepasa a NFS en muchas situaciones. Los avances recientes han empleado reparto de los datos entre múltiples discos y escritura estructurada en históricos para mejorar mas las prestaciones y la escalabilidad.
En la actualidad los sistemas de archivos distribuidos son altamente escalables, proporcionan buenas prestaciones tanto para redes de área local como las áreas grandes, mantienen la semántica de una copia, toleran y se recuperan de los fallos
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