Coda (sistema de archivos)

De Wikipedia, la enciclopedia libre
Coda
Desarrollador Universidad Carnegie Mellon
Sistemas operativos compatibles Linux, NetBSD FreeBSD
Introducción 1987
Características

Es un sistema de archivos distribuido descendiente de AFS y desarrollado como proyecto de investigación por Satyanarayanan y otros trabajadores en la Universidad Carnegie Mellon bajo la dirección de M.Satyanarayanan. Intenta cumplir varios requisitos que AFS no consideraba, particularmente el de proporcionar un alto grado de disponibilidad a pesar de realizar operaciones desconectadas (debido a errores de red o del servidor, o simplemente porque el cliente no está conectado a ninguna red). Coda todavía está en desarrollo, aunque el interés se ha desplazado desde la investigación hacia la creación de un producto robusto para uso comercial.

Características[editar]

Coda es un sistema de archivos (ficheros) distribuido que tiene sus orígenes en AFS2. Tiene múltiples características que son deseables en la mayoría de sistemas de archivos. Además, tiene algunas características propias.

  1. puede funcionar sin conexión
  2. es software libre
  3. gran rendimiento gracias a la caché persistente en el cliente
  4. replicado de servidores
  5. modelo de seguridad para autenticación, cifrado y control de acceso
  6. funcionamiento continuado durante fallos de red
  7. ajuste del ancho de banda de red
  8. escala bien

Si se compara con su antecesor (AFS), son destacables tres áreas de mejora:

  • La limitada forma de replicación debido al uso de una estrategia de replicado pesimista (restringida a volúmenes de sólo lectura)
  • La disponibilidad del servicio (era común que ocurriesen varios fallos al día que interrumpían las operaciones durante varios minutos o incluso horas)
  • La imposibilidad de localizar los archivos cuando no se tuviese conexión, a no ser que se recurriese a métodos manuales (lo cual cobró especial importancia con la aparición de los ordenadores portátiles).

Coda busca cumplir estos tres requisitos bajo la máxima de disponibilidad constante de los datos. El objetivo era ofrecer a los usuarios los beneficios de un repositorio de archivos compartido, pero al mismo tiempo darles la posibilidad de depender de sus recursos locales cuando el repositorio estuviese inaccesible total o parcialmente.

Coda es comparable a Bayou en cuanto a que también sigue una estrategia optimista, debido a que permite a los clientes actualizar información mientras el sistema está dividido, puesto que considera que los conflictos son poco probables y que se pueden solucionar en el caso de que ocurran. Sin embargo, se diferencia de éste en que realiza las comprobaciones sin tener en cuenta la semántica de los datos y proporciona un soporte limitado para resolver conflictos entre réplicas.

Arquitectura[editar]

Se pueden distinguir procesos Venus en los clientes y procesos Vice en los servidores (siguiendo la terminología AFS). Los procesos Vice se corresponden con los gestores de réplicas, mientras que los Venus vendrían a ser una mezcla entre éstos y los frontales. Llevan a cabo la tarea de estos últimos de hacer transparente la implementación de los servicios a los clientes, pero como también gestionan una caché local de los archivos, son considerados a su vez como gestores de réplicas, aunque de un tipo diferente.

Grupo de almacenamiento de volumen (VSG)[editar]

El conjunto de servidores que contiene réplicas de un volumen de archivos se conoce como grupo de almacenamiento de volumen (VSG,  por sus siglas en inglés) En cualquier momento, un cliente que quiera abrir un fichero en este volumen puede acceder a un subconjunto de dicho VSG, conocido como grupo de almacenamiento de volumen disponible (AVSG). La pertenencia a un determinado AVSG varía a medida que los servidores se vuelven accesibles o inaccesibles por fallos de la red o del servidor.

Funcionamiento[editar]

La estrategia de replicación seguida por este sistema permite la modificación de archivos cuando la red está dividida o durante una operación desconectada. Se basa en la inclusión de un vector de marcas temporales (CVV, Coda Version Vector) en cada versión de un archivo, formado por un elemento por cada servidor en el correspondiente VSG. Cada elemento contiene una estimación de las modificaciones realizadas en dicha versión del archivo que está almacenada en ese servidor.

El objetivo de estos vectores temporales es proporcionar suficiente información sobre el historial de actualizaciones como para permitir la detección de potenciales conflictos, de modo que estos sean solucionados de manera manual y que las réplicas obsoletas se actualicen automáticamente. Si el CVV en uno de los sitios es mayor o igual a los correspondientes CVVs de todos los demás sitios, entonces significa que no hay conflicto. Las réplicas antiguas incluyen todas las actualizaciones en una nueva réplica y pueden ponerse al día con ella de manera automática. Si este no fuera el caso, entonces es que se ha producido un conflicto.

En general, Coda no resuelve los conflictos automáticamente, por lo que el procedimiento habitual sería marcar el archivo como inoperable y posteriormente avisar al propietario sobre el conflicto.

Cuando un archivo que se ha modificado se cierra, el proceso Venus en el cliente envía un mensaje de actualización a cada sitio en el AVSG actual, conteniendo el CVV actual y el nuevo contenido del fichero. El proceso Vice en cada sitio comprueba el CVV y, si es mayor del que se tiene en ese momento, guarda los nuevos contenidos del archivo y devuelve un mensaje de confirmación. Tras esto, el proceso Venus calcula un nuevo CVV con la cuenta de modificaciones incrementada para aquellos servidores que respondieron positivamente al mensaje de actualización, y lo distribuye a los miembros del AVSG. Como este mensaje solo se envía a estos miembros y al VSG, los servidores que no se encuentren en el actual AVSG no recibirán el vector. Esto implica que la cuenta de modificaciones siempre será precisa en el servidor local, pero los servidores no locales tendrán que esperar a recibir un mensaje de actualización.

Ventajas[editar]

Las ventajas derivadas del uso de replicación para algunos o todos los volúmenes de archivos son:

  • Los archivos en un volumen replicado permanecen accesibles para cualquier cliente que tenga acceso al menos a una de las réplicas.
  • El rendimiento del sistema se puede mejorar compartiendo parte de la carga de atender las solicitudes de los clientes en un volumen replicado entre todos los servidores que contienen réplicas.

Referencias[editar]