1.1. Conceptos relativos a los servidores Coda

Esta sección tiene el objetivo de asentar los conceptos básicos relativos a un servidor Coda, para así comprender mejor el proceso de instalación y configuración de las siguientes secciones.

1.1.1. Organización de un servidor Coda

[Note]Nota

Esta sección está basadas en la sección 1.4 del capítulo 1 de la entrada bibliográfica Coda97.

El programa principal es el servidor de archivos de Coda, codasrv. Este es el responsable de hacer todas las operaciones con los ficheros, así como de mantener el servicio de ubicación de volumenes.

El servidor de autentificación de Coda, auth2, administra las peticiones de clog para los tokens así como los cambios de claves requeridos por las aplicaciones au y cpasswd. De todas formas, se ha de tener en cuenta que sólo el processo auth2 en el SCM puede modificar la base de datos de claves.

Todos los servidores en una Célula Coda comparten las bases de datos de configuraciones, la cual está almacenada en el directorio /vice/db. Esta información la obtienen del servidor SCM cuando se realiza algún cambio. El programa encargado de comprobar y recuperar los cambios en la base de datos es updateclnt, quien consulta el demonio updatesrv disponible en el servidor SCM. Algunas veces, el servidor SCM necesita una base de datos (no compartida) de otro servidor para actualizar la base de datos compartida. Este la coge gracias al demonio updatesrv que se ejecuta en el servidor desde el cual va a actualizar la base de datos, para ello el servidor SCM utiliza la aplicación updatefetch.

En el servidor hay herramientas para la creación y administración de volumenes. Estas utilidades consisten en shell scripts y la aplicación volutil. También existe una herramienta para manipular las bases de datos protegidas.

1.1.2. Algunas definiciones...

[Note]Nota

Las siguientes secciones están basadas en el capítulo 6 de la entrada bibliográfica Coda97.

1.1.2.1. RVM - Recoverable Virtual Memory

Para asegurarse que los datos no se pierden por inconsistencia entre el intervalo de reinicio de un servidor, Coda utiliza RVM, que es un sistema transaccional que mantiene el estado de los metadatos del servidor Coda. RVM es un sistema transaccional que escribe las modificaciones realizadas a los datos en el log de RVM y cuando este log se trunca o se reinicia RVM, dichas modificaciones son incorporadas al fichero de datos RVM. Así, cuando un servidor Coda arranca, este utiliza RVM para restaurar el estado del sistema Coda.

[Note]Nota

Esto no se ha de confundir con la memoria virtual.

Idealmente, tanto el archivo de log como el de datos se almacena en una partición raw. Si se desea un rendimiento óptimo, sería recomendable poseer un disco duro dedicado para las particiones de metadatos y logs[6].

Almacenamiento de los metadatos RVM Esto es un archivo o una partición raw donde se almacenan los metadatos de RVM. Se puede utilizar un archivo, pero será bastante lento en grandes servidores. El tamaño de la partición o del archivo ha de ser sobre el 4% del total del tamaño de los archivos que se deseen almacenar bajo /vicepa (por ejemplo, en un sistema con 2GB en dicho directorio, se necesitarán unos 80MB en la partición de datos de RVM[7]).

Memoria virtual.  Los metadatos, almacenados en el archivo de datos de RVM, son mapeados en memoria. Por este motivo, se necesita esa cantidad de espacio en la memoria virtual del sistema y, adicionalmente, se necesitará memoria para poder ejecutar el servidor Coda (~6MB) y el software que acompañe a dicho servidor.

Log transaccional RVM Este es el archivo de LOG, preferiblemente una partición raw en un disco duro dedicado. No necesita ser muy grande, unos pocos megas son suficientes.

1.1.2.2. Organización del disco del servidor

Los servidores Coda necesitan un mínimo de dos particiones para un rendimiento óptimo (una partición raw para el LOG RVM y otra partición raw para los metadatos RVM; también es necesario un sistema de archivos tipo UNIX donde mantener el almacenamiento de los datos de Coda), seguridad en los datos y protección ante borrados acidentales. Para ganar rendimiento, la partición dedicada al log RVM debería ubicarse en un disco propio, evitandose de esta forma latencias en el movimiento de las cabezas lectoras, reduciendo los tiempos de búsqueda en las operaciones de log. Opcionalmente, el directorio /vice puede ser ubicado en una partición separada; esto es así por las mismas razones que se separa el directorio /var.

Sin embargo, se puede hacer uso de archivos para almacenar el log y los metadatos de RVM, lo que implica una pérdida de rendimiento y seguridad en los datos. También, si se necesita más de un área de almacenamiento de datos en un servidor Coda (el directorio por defecto se llama /vicepa), las áreas adicionales de almacenamiento deberían ubicarse en particiones separadas y montarse, por ejemplo, como /vicepb, /vicepc, etc.

La tabla que se muestra a continuación perfila una posible forma de particionar un disco en un servidor Coda. La tabla también muestra el propósito, los puntos de montaje, los tamaños típicos y el programa de comprobación de consistencia para cada una de las particiones.

[Note]Nota

Los tamaños de las particiones han sido tomados del servidor Coda montado en CMU-SCS, por lo que dichos tamaños pueden variar de una instalación para otra.

Tabla 1.1. Ejemplo de particiones de un servidor Coda

ParticiónPropósito del almacenamientoPunto de montajeTamaño típico¿Ha de ser chequeado?
hda2Raíz del sistema de archivos UNIX/650MB
hda5Directorio var/var100MB
hda3Directorio vice/vice300MB
hdc1Log RVMnada12MBNo
sda1Metadatos RVMnada130MBNo
sda2FS Coda Datos0/vicepa1.6GB
sda3FS Coda Datos1/vicepb1.6GB
sda5FS Coda Datos2/vicepc1.6GB


[6] Si la partición donde se almacena el archivo de log pertenece a un disco duro compartido, o se usa un archivo para almacenar el log, el resultado será una pérdida de rendimiento.

[7] En este documento se utilizará un tamaño de 22MB y se hará uso de archivos para el log y los metadatos de RVM