Sistema de archivos distribuidos: CODA (Sistemas Operativos) (página 2)

Partes: 1, 2

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).

Volúmenes

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 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». 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.

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).

Un ejemplo de la aplicación de CODA es la empresa Rodiño SA del Uruguay que utiliza CODA para el control de sus bases de datos alojadas en sus servidores, ya que crea un servidor CODA con la base de datos donde pueden acceder los clientes CODA para realizar cambios en el stock de la bodega.

Desventajas

Debido a sus características Coda tiene una serie de desventajas:

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.

Configuración de servidor y cliente CODA

Servidor:

La instalación se puede hacer por medio de rpms, targz y binarios; este úlitmo es más aconsejables ya que al instalar por las dos otras formas se corre el riesgo de tener problemas de dependencias (tener que instalar otras librerías). Para la instalación hemos usados los binarios:

Nombre de paquete: coser-1.4-20071107-linux-ia32-0.bin

Para ejecutar este binario se l hace de la siguiente manera, enviando algunos parámetros, el nombre del paquete, el directorio que guarda todas las configuraciones de CODA, espacio de memoria y el volumen hostname del servidor:

. / coser-1.4-20071107-linux-ia32-0.bin /vice 789 deber.so.com

Cuando se realiza la instalación mediante rpms o targz se debe correr un script: vice-setup en el que se deberá configurar manualmente algunos parámetros, pero con los binarios esto se hace automáticamente.

Una vez termine la ejecución de vice-setup habrá que levantar los servicios Coda ejecutando los correspondientes demonios, Los demonios están disponibles en el directorio /etc/rc.d/init.d/, y son los siguientes:

update.init

auth2.init,

codasrv.init

Para lanzarlos bastará con pasarles como parámetro la cláusula «start»:

/etc/rc.d/init.d/update.init start, ejecuta rpc2portmap, updateclnt y updatesrv. Este script no ejecuta bien el demonio updatesrv, hay que hacer una pequeña modificación añadiendo "> /dev/null" al final de la línea en la que se le ejecuta.
/etc/rc.d/init.d/auth2.init start, ejecuta auth2.
/etc/rc.d/init.d/codasrv.init start, ejecuta startserver, quien a su vez ejecuta el codasrv.
Cliente:

La instalación del cliente es sencilla, como lo haremos mediante binario la ejecución del paquete es similar que la que se hizo en el servidor, pero no se debe enviar los parámetros adicionales:

Nombre de paquete: cocli-1.4-20071107-linux-ia32-0.bin

Ejecutamos : . /coser-1.4-20071107-linux-ia32-0.bin

Venus es el gestor de la caché del cliente. Para configurarlo tenemos el script venus-setup:

#/usr/bin/venus-setup

Con lo que decimos a Venus cuál es su lista de servidores Coda a los que debe conectarse. También inicializa un directorio para utilizarlo como caché de disco del cliente Coda, con el tamaño indicado en el script venus-setup (para empezar se recomienda una pequeña caché de 20 MB, aunque funciona bien hasta 300 MB). Asimismo venus-setup creará el dispositivo /dev/cfs0 para comunicarse con el Núcleo y dejará todos los ficheros del cliente Coda en el directorio /usr/coda. Tras la instalación del paquete binario se puede lanzar Venus en background con la orden:

# venus &

y se puede parar con: kill -9 venus

Aunque una manera más limpia de lanzar y parar Venus es desde su script de inicio: /etc/rc.d/init.d/venus. Levantamos el servicio del cliente ejecutando:

/codacliente start

Compartición de Archivos

En el cliente debemos ubicarnos en el directorio /coda, luego listar lo que se encuentra dentro de este directorio y nos debe presentar el volumen que lo compartimos en el servidor, en nuestro ejemplo: deber.so.com, este será como una carpeta en la cual se encontrarán todos los archivos que están compartidos.

Para hacer una prueba podemos copiar un archivo dentro de deber.so.com, el cual debe verse en el servidor, ejemplo:

cp –f /root/Linux-coda-6.6 deber.so.com

Mientras que en el servidor los archivos compartidos se alojan bajo el directorio /vice/pa, aquí existe un archivo por defecto que es él: FTREEBD, pero a más de ese debe aparecer los que creamos en el cliente, pero vale aclarar que no se presentará el nombre del archivo ya que el nombre se crea como un código, y si vemos el contenido igual se presentará un código.

Recomendaciones

Si se desea volver a instalar el servidor es necesario y aconsejable borrar el directorio /vice, con: rm –rf /vice.
Revisar si los demonios están levantados, con: ps –ax
Recordar los nombre de usuarios y contraseñas que se ha creado.
Incluir el nombre del hostname junto con la dirección ip estática con la que nos vamos a conectar con el cliente en: /etc/hosts

Conclusiones

El cliente puede trabajar aún estando sin conexión, por lo que guarda una copia de los archivos en su caché. Cuando se reanuda la conexión se realizan las actualizaciones.
Con el sistema de archivos CODA se puede realizar replicación de datos.
No podemos levantar servidor y cliente CODA en la misma máquina.
Es recomendable realizar la instalación mediante binarios, para evitar errores en la instalación.