Coda COMO 4
4. Introducción
Un sistema de ficheros distribuido almacena ficheros en uno o más ordenadores sincronizados entre sí llamados servidores, y los hace accesibles a otros ordenadores llamados clientes, para quienes el acceso a estos ficheros es transparente. La principal ventaja es la compartición de ficheros y su gestión centralizada desde los servidores (como por ejemplo el control de acceso y la gestión de copias de seguridad). Esta compartición de ficheros es especialmente útil para grupos de trabajo que comparten documentos, aunque también es posible compartir software, como por ejemplo, un procesador de textos.
Un buen sistema de ficheros distribuido debe tener en cuenta cosas tan importantes como la latencia de la red, los posibles cuellos de botella y sobresaturación del servidor, la seguridad de datos comprometidos y los posibles fallos de red y servidores. Evidentemente todo esto toma especial importancia en el caso de que el sistema funcione bajo una WAN.
El Sistema de Ficheros Distribuido Coda es el sucesor de Andrew File
System (AFS) y es un desarrollo de la Universidad de
Carnegie-Mellon como ejemplo de entorno de trabajo distribuido. Coda
destaca sobre AFS por permitir la Computación Móvil (trabajar en modo
desconectado), soportar mejor la tolerancia a fallos del sistema (por
ejemplo caída de los servidores o fallos de la red) y por disponer de
técnicas de replicación de los servidores. Al ser gratuito, su código
fuente está disponible (la licencia de Coda se puede encontrar en
ftp://ftp.coda.cs.cmu.edu/pub/coda/LICENSE) y está
diseñado para trabajar tanto en LAN como en WAN.
Coda se implementó originalmente en Mach 2.6 y ha sido portado recientemente a Linux, NetBSD y FreeBSD. También se está portando a Windows95/NT, pero el estado de desarrollo es menor.
La Computación Móvil [MAR99] permite por ejemplo que un usuario pueda trabajar con su portátil enganchado a la red Coda, llevárselo a su casa para trabajar con él, y cuando vuelva a conectarse a la red los datos se reintegrarán automáticamente, sin que el usuario se percate de ello (entendiendo por reintegrar el proceso en el que tras una reconexión se ponen al día en los servidores los cambios realizados por el cliente durante la desconexión).
4.1 El cliente Coda
[BRA98] Bajo el directorio /coda el cliente monta un sistema
de ficheros de tipo «Coda», desde donde se accederán a todos los
ficheros del Sistema Coda. Un cliente se conecta a todo el sistema Coda y
no a un servidor individual como ocurre en NFS, donde existe un único
directorio o punto de montaje por servidor. La ventaja de un sólo punto
de montaje reside en que todos los clientes pueden ser configurados de
forma idéntica, y en que los usuarios siempre verán el mismo árbol de
ficheros. Con NFS los clientes necesitan actualizar la lista de
servidores y la ruta de directorios que exportan en /etc/fstab,
mientras que en Coda los clientes sólo deben acceder al directorio
/coda para ver los cambios incluso cuando se añaden nuevos
servidores. En las dos siguientes figuras se aprecia la diferencia
funcional entre un sistema NFS y un sistema Coda [MAR99]:
Sistema de Ficheros Distribuido, entorno Cliente-Servidor NFS:
RED
+---------+ +-----+
| | | |
|Servidor |<----|-----|------->Cliente 1
| NFS 1 |<----|-----|--+
| | | | |
+---------+ | | +---->Cliente 2
| | |
| | |
+---------+ | | |
| | | | |
|Servidor |<----|-----|--+
| NFS 2 |<----|-----|------->Cliente 3
| | | |
+---------+ +-----+
Sistema de Ficheros Distribuido, entorno Coda:
Sistema Coda
+-------------+ RED
| +---------+ | +-----+
| | | | | |
| |Servidor | |<----|-----|------->Cliente 1
| | Coda 1 | | | |
| | | | | |
| +----+----+ |<----|-----|------->Cliente 2
| | | | |
| | | | |
| +----+----+ | | |
| | | | | |
| |Servidor | | | |
| | Coda 2 | |<----|-----|------->Cliente 3
| | | | | |
| +---------+ | +-----+
+-------------+
La implementación de Coda en Linux está constituida por un conjunto de demonios que se ejecutan en los servidores, normalmente llamados Vice, y un demonio (Venus) más un módulo del Núcleo en la parte del cliente. La comunicación se establece entre los demonios, siendo el módulo del núcleo la interfaz entre el Sistema Coda y el VFS (Virtual File System) de Linux.
Cuando un usuario intenta leer un fichero del Sistema Coda (por ejemplo
con cat /coda/users/user15/doc.txt) el programa cat realizará
unas llamadas al sistema relacionadas con el fichero, que se comunicarán
con el VFS del núcleo. El VFS comprueba entonces que la petición
se refiere a un fichero Coda, y encamina la petición al módulo del sistema
de ficheros Coda en el Núcleo (Coda FS). Este módulo
mantiene una caché de peticiones recientes resueltas, y si la respuesta no
se encuentra en esta caché, se encamina de nuevo la petición al gestor de
caché Coda Venus (a través del dispositivo de caracter
/dev/cfs0). Venus comprobará si el fichero
user15/doc.txt se encuentra en una segunda caché, almacenada en
disco, y en caso contrario contactará con los servidores (Vice)
para obtenerlo. Una vez conseguido el fichero, Venus responderá al
núcleo, quien devolverá la respuesta al programa cat.
Cuando el núcleo solicita a Venus la apertura de un fichero
por primera vez, éste obtiene el fichero completo de los servidores
utilizando las llamadas a procedimientos remotos (RPC) para comunicarse
con los ellos. Después almacena el fichero en el área de caché (en el
directorio /usr/coda/venus.cache/), desde donde será controlado
por el sistema de ficheros ext2 de Linux. Si un fichero ya se
encuentra en la caché del cliente, Venus permitirá trabajar con él sin
contactar con los servidores, de modo que si el fichero se abre una
segunda vez, no se obtendrá del almacén remoto (trabajo en modo
desconectado) sino de la caché.
Así pues, Venus sólo almacena aquella información que necesita el cliente, como ficheros o directorios (los directorios en Linux son ficheros) y sus atributos (propietario, permisos y tamaño). Si el fichero ha sido modificado y cerrado, entonces Venus actualiza los servidores enviándoles el nuevo fichero. Cualquier otra operación que modifique el sistema de ficheros (como la creación o eliminación de directorios y enlaces -links-) se propagará también a los servidores.
Coda ofrece distintos niveles de seguridad mediante Kerberos: no cifrar; cifrar sólo los paquetes de protocolo interno; cifrar además las cabeceras de los mensajes; y cifrado completo.
4.2 Las operaciones desconectadas
Si el cliente está desconectado e intenta actualizar un fichero que tiene en la caché, Venus se da cuenta que los servidores no están disponibles, se declara en modo desconectado y registra los cambios realizados en el CML (Client Modification Log o Registro de Modificación del Cliente) sobre el sistema de ficheros para actualizarlos en los servidores durante la siguiente conexión. Este proceso es transparente para el usuario, quien no se percata que ha cambiado a modo desconectado. Asimismo el CML está optimizado (por ejemplo, si un fichero es creado y luego borrado, se eliminan estos pasos del CML).
En ocasiones un cliente intenta acceder a un fichero que no tiene en su caché. Si está conectado lo consigue de los servidores, pero si no lo está, no hay nada que hacer y se devuelve un error al programa que haya hecho la petición. Para evitarlo existen los ficheros HOARD, que son un conjunto de ficheros relativamente importantes establecidos por el usuario que se mantienen en la caché. El usuario define la base de datos de ficheros HOARD, y puede solicitar a los servidores las últimas actualizaciones antes de desconectarse. Esta base de datos la puede construir automáticamente el sistema haciendo un seguimiento de los accesos que hace el usuario. Los ficheros Hoard permiten, por ejemplo, que un cliente forzar la carga del caché local antes de entrar en modo desconectado, y tener la garantía de que todo lo que necesita estará en su portátil tras la desconexión.
Puede ocurrir que dos o más clientes hayan actualizado el mismo fichero
cuando estaban en modo desconectado. Cuando los clientes se conecten se
producirá un conflicto LOCAL/GLOBAL entre cliente y servidor y
se debe decidir por una de las actualizaciones. Para «reparar» este
conflicto, el usuario dispone de la orden repair. La reparación
la puede realizar a veces automáticamente «reparadores» específicos de la
aplicación (por ejemplo, si dos usuarios modifican registros distintos de
una misma base de datos, la propia base de datos los actualizaría sin que
existiera un posible conflicto).
4.3 Volúmenes, servidores y replicaciones.
Los servidores Coda no almacenan los ficheros en un sistema de ficheros
tradicional. En lugar de disco, partición o directorio, se utiliza el
concepto de volumen. Físicamente [MAR99] representa un
grupo de ficheros
mapeados
en memoria por el demonio servidor codasrv, que contienen la
información almacenada en dicho volumen. Los volúmenes proporcionan mayor
flexibilidad al administrador, y su tamaño medio aproximado es de 10 MB,
llegando a existir cientos de volúmenes por servidor.
RVM (Recoverable Virtual Memory o Memoria Virtual Persistente) registra la información de volúmenes y directorios, listas de control de accesos y atributos de los ficheros en particiones «crudas»
( raw en inglés, aquellas que tienen escrituras síncronas). En caso de una caída del host repara el sistema accediendo a la información de estas particiones, consiguiendo velocidad y consistencia. Hay dos particiones crudas: Log Partition y Data Partition.
Existe un volumen raíz que se monta bajo /coda, desde donde se
montan el resto de los volúmenes. Obviamente este volumen es propiedad del
administrador Coda. Un volumen tiene un nombre y un identificador Id,
y se monta en cualquier subdirectorio de /coda (por ejemplo el
volumen de un usuario users.user15 se puede montar bajo
/coda/users/user15). Cada fichero se identifica con un
identificador Fid único en un sistema Coda y está compuesto
por tres enteros de 32 bits:
- VolumeId:
identifica el volumen en el que reside el fichero.
- VnodeId:
número de inodo del fichero.
- Uniquifier:
identificador necesario para la resolución de conflictos.
Un volumen replicado es aquél que está almacenado en un grupo de servidores que pertenecen al mismo VSG (Volume Storage Group), de modo que cualquier operación sobre los ficheros de ese volumen afectará a todo el VSG al que pertenece (lo cual no supone mucho coste, ya que Coda implementa difusión -multicast en inglés- ).El objetivo de esto es la alta disponibilidad del volumen. Asimismo existe el subgrupo AVSG (Available VSG), que son aquellos servidores accesibles y pertenecientes a un mismo VSG (puede ocurrir por ejemplo que uno de los servidores del VSG se averíe, con lo cual deja de ser accesible y deja de pertenecer al AVSG). Otros tipos de volúmenes son los locales (no replicados) y volúmenes backup. Los volúmenes backup permiten realizar copias de seguridad del Sistema de Ficheros Coda; sin embargo no se tratará en este documento.
La replicación de servidores puede provocar conflictos globales cuando
el número de servidores que forman parte de un mismo AVSG es inferior al
VSG (por ejemplo si las máquinas de un VSG son separados de los
demás por una caída de la red). En este caso las actualizaciones de los
ficheros no pueden propagarse a todos los miembros del VSG y es
necesario resolver el conflicto con la orden repair (muchas
veces sólo hay que decirle a Coda que lo repare como cuando hay que
sustituir un disco duro y el sistema se encarga de actualizarlo).
4.4 Aplicaciones de Coda
En Internet, las réplicas de servidores FTP podrían ser clientes Coda
que se actualizarían cada vez que los servidores Coda sufrieran cualquier
modificación. Lo mismo pasaría con la réplica de servidores WWW,
los cuales también pueden ser clientes Coda (los cuales pueden ser
optimizados guardando en su caché local todos los datos a replicar). En
ambos casos NFS es inadecuado ya que está diseñado para un entorno
LAN, y hasta la aparición de Coda eran necesarias herramientas de
sincronización entre servidores como rsync, que periódicamente
contrastan las diferencias entre nodos y actualizan las diferencias. La
computación móvil de Coda también puede ser aprovechada para aquellos
clientes de proveedores de Internet que actualizan su página Web tras
diseñarla en modo desconectado.
En las redes locales un usuario podría, por ejemplo, conectarse al sistema
Coda cargando en su caché local los datos que vaya a utilizar ese día
(promoviendo el acceso a servicios locales frente a remotos, lo cual
incrementa el rendimiento disminuyendo los costes de comunicación),
desconectarse*
y, cuando acabe el día, volver a conectarse para reintegrar los cambios efectuados.
*: sin desconectarse también se consigue aumentar
el rendimiento, ya que siempre es más eficiente trabajar sobre una caché
local que sobre un fichero remoto (tal y como ocurre en NFS).
4.5 Desventajas
[MAR99] Debido a sus características Coda tiene una serie de desventajas (algunas ya mencionadas):
- Las operaciones de bloqueo de ficheros no están implementadas debido a que no es posible un algoritmo de bloqueo que tenga en cuenta un funcionamiento en modo desconectado.
- Existe un problema de sincronización intrínseco al modo desconectado: cuando al reconectar un cliente, un fichero ha cambiado tanto en el cliente como en el servidor, ¿cúal es la versión que se debe sincronizar con el resto del sistema?. Existen diversos algoritmos, pero frecuentemente se requiere la mano del operador.
- La implementación de cuotas es limitada y sólo existe para los directorios (no existen cuotas para usuarios). Para solucionarlo se puede asignar un volumen por usuario, pero cambiar la cuota a un usuario es complicado porque los volúmenes Coda no son redimensionables.
- Coda no es estable y actualmente no se soportan bien volúmenes de más de 100 usuarios, ni mezcla de servidores Coda que no estén replicados (cada servidor Coda sirviendo un volumen independiente).
- Todas las operaciones de administración deben hacerse desde un cliente Coda sin que se pueda trabajar directamente con los volúmenes. Esto dificulta enormemente las tareas de mantenimiento y administración.
- Una máquina no puede ser a la vez cliente y servidor Coda.
Página siguiente Página anterior Índice general