Hay proyectos muy interesantes, que con el tiempo, tienden a desaparecer y la información también desaparece de la red. Para evitar esto, voy a dejar la información, en este caso sobre el proyecto CUMULO, en la red social Manchegox.org

Espero que os sirva en un futuro.

Terminales Ligeros

Introducción a los terminales ligeros.

Un cliente ligero (thin client), también llamado terminal tonto o cliente liviano, es básicamente es una computadora dentro de una arquitectura red de cliente – servidor, con muy poca o ninguna lógica interna, limitándose a presentar por pantalla un interfaz, y realizándose las operaciones en un servidor que manda los resultados a los terminales a través de la red.

La idea está basada en la tecnología cliente/servidor pero llevada un poco más allá. Tanto los servidores como los clientes son equipos obsoletos que se han reutilizado para el diseño de un laboratorio informático. De esta forma, se ha retirado del mercado material que se iba a tirar a la basura utilizándolo para diferentes fines. Estos fines pueden ser muy variados. Esta tecnología puede ser desplegada con éxito en multitud de ambientes, como pueden ser colegios, academias, bibliotecas, oficinas administrativas, cibercafés…

Otra situación en la que se antoja muy aconsejable su puesta en práctica es en aquellos casos en los que se trata de realizar un despliegue de puestos informáticos nuevos a gran escala, como es el caso de colegios, oficinas nuevas, oficinas dispersas, etc. En estas situaciones esta tecnología no tiene rival en cuanto a mantenimiento y conservación, ahorros energéticos, estructurales y de despliegue.

Cúmulo es un proyecto de puesta en marcha de una sala de informática en la Escuela de Ingenierías Industrial e Informática de la Universidad de León utilizando técnicas de clientes ligeros comentadas en la primera parte de esta documentación.

La sala de informática dispone de 32 ordenadores, que en la actualidad son de limitada utilización debido a su escasa potencia, y que actuarán de clientes ligeros según el esquema descrito en las siguientes páginas. El objetivo es que los usuarios de la sala de informática, en su mayoría estudiantes de Ingeniería Informática, realicen sus tareas habituales (navegación web, edición de texto, desarrollo de aplicaciones…) de modo transparente al funcionamiento interno de la sala, y con prácticamente las mismas prestaciones que si estuvieran trabajando sobre ordenadores actuales. Ésto se puede conseguir utilizando los ordenadores a modo de terminales que muestren la información que se procesa en el servidor.

Usualmente las soluciones de thin-client disponen de un potente servidor que ejecute las tareas y proporcione los servicios a todos los clientes. Sin embargo, para el proyecto Cúmulo utilizaremos un conjunto de servidores ligeros, con lo que el coste en la compra de hardware va a ser mínimo, ya que estamos reutilizando equipos obsoletos tanto en la parte de servidores como en la parte de clientes. Del mismo modo, hemos optado por soluciones thin-client, aplicaciones y sistema operativo de software libre, con lo que el ahorro es aún más sustancial.

Cada uno de los servidores está encargado de realizar determinadas tareas y proporcionar determinados servicios, de acuerdo a las características de cada uno. La autenticación de los clientes se lleva a cabo de forma centralizada, mientras que los archivos que guarden los usuarios se almacenarán en un clúster NFS formado por dos servidores ligeros. Las herramientas utilizadas permiten una fácil administración de la sala, permitiendo gestionar los permisos de los usuarios, añadir nuevas aplicaciones, etc. con relativa facilidad.

Estudios de las tecnologías de acceso gráfico remoto

XDMCP

X Display Manager Control Protocol (XDMCP) es un protocolo para ejecutar entornos gráficos a través de la red de forma remota. El servidor X normalmente es iniciado mediante el XDM (X Display Manager) particular del sistema Linux instalado, como son GDM (Gnome Display Manager) ó KDM (Kde Display Manager). Mediante XDMCP, un ordenador puede ejecutar una sesión XDM remotamente Para que un sistema Linux permita conexiones remotas XDMCP hay que configurar adecuadamente los ficheros Xaccess y xdm-config, que se encuentran en /usr/X11R6/lib/11/xdm.

Este protocolo es el más utilizado en sistemas Linux para la conexión remota al servidor gráfico, y por lo tanto todas las soluciones de clientes ligeros analizadas lo soportan.

RDP

Remote Desktop Protocol (RDP) es un protocolo desarrollado por Microsoft que permite la comunicación en la ejecución de una aplicación entre un terminal (mostrando la información procesada que recibe del servidor) y un servidor Windows (recibiendo la información ingresada por el usuario en el terminal mediante el ratón ó el teclado).

El modo de funcionamiento del protocolo es sencillo. La información gráfica que genera el servidor es convertida a un formato propio RDP y enviada a través de la red al terminal, que interpretará la información contenida en el paquete del protocolo para reconstruir la imagen a mostrar en la pantalla del terminal. En cuanto a la introducción de órdenes en el terminal por parte del usuario, las teclas que pulse el usuario en el teclado del terminal así como los movimientos y pulsaciones de ratón son redirigidos al servidor, permitiendo el protocolo una encriptación de los mismos por motivos de seguridad. El protocolo también permite que toda la información que intercambien cliente y servidor sea comprimida para un mejor rendimiento en las redes menos veloces.

Pxes es la única de las soluciones de clientes ligeros analizadas que nos permite utilizar este protocolo para que los terminales puedan actuar como clientes de servidores Windows, lo que puede ser interesante en multitud de ambientes de trabajo en los que se utilizan servidores Microsoft.

VNC

Virtual Network Computing (VNC) es una aplicación de software libre que permite manejar remotamente un ordenador (servidor) desde ordenadores con el cliente VNC correspondiente.

En una conexión VNC, el servidor y el cliente no tienen porque ser del mismo tipo, lo que permite una gran flexibilidad a esta aplicación. Para la comunicación entre servidor y cliente, VNC necesita una conexión TCP/IP entre ellos.

La ventaja que tiene este protocolo sobre el RDP es que este podras controlar completamente el ordenador remoto(servidor).

NX

NX es una aplicación de NoMachine que permite distribuir aplicaciones centralizadas a clientes ligeros, así como un control remoto del ordenador.

NX realiza una compresión directa del protocolo de las X, lo que permite una mayor eficiencia que VNC. El código de esta compresión ha sido liberado, por lo que existe una implementación libre de esta aplicación, llamada FreeNX.

NX envía la información mediante SSH, por lo que toda la información que se intercambian servidor y cliente está encriptada.

Estudio de soluciones completas de acceso gráfico remoto

LTSP (Linux Terminal Server Project)

LTSP (Linux Terminal Server Project) es un proyecto iniciado por Jim McQuillan y que en este momento ya ha alcanzado la versión 5. Es un proyecto consolidado que proporciona una manera simple de utilizar estaciones de bajo coste como terminales gráficas de un servidor GNU/Linux.

Tras arrancar el terminal y obtener su dirección IP y la localización en el servidor del núcleo que debe cargar, el terminal obtiene el núcleo mediante TFTP (Trivial File Transfer Protocol) y lo ejecuta. Este núcleo del LTSP lleva una imagen de un sistema de archivos que es cargada en memoria como un ramdisk (parte de memoria que es asignada para usarla como si se tratase de una partición de disco) y lanza una serie de scripts (que serán comentados más adelante) que montarán el sistema de archivos raíz que hayamos preparado en el servidor a través de NFS (Network File System). Finalmente, se iniciarán las X Window y se enviará una petición XDMCP al servidor, que permitirá ingresar en el servidor.

Con lo cual, tenemos el sistema de archivos raíz montado mediante NFS desde el servidor GNU/Linux. Ésto es una diferencia importante respecto al proyecto que comentaremos a continuación, ya que PXES no es dependiente del sistema operativo del servidor (lo que permite que pueda ser ejecutado en sistemas Windows, por ejemplo), y no monta el sistema de archivos raíz mediante NFS.

Anteriormente se ha descrito someramente la carga del sistema LTSP por el terminal, pero sin entrar en los detalles concretos que pasaremos a definir a continuación y que nos permiten obtener una visión clara del proceso que hay que seguir para lograr el objetivo propuesto:

1. El terminal arranca y mediante Etherboot realiza una petición DHCP a la red, que es respondida por el servidor DHCP que le proporciona su IP y la localización del núcleo a descargar.
2. Mediante TFTP el terminal contacta con el servidor y se descarga el núcleo, que es cargado en memoria y al que se le pasa el control a continuación.
3. El kernel inicializa el sistema y los periféricos que reconozca.
4. El kernel carga una pequeña imagen ramdisk en memoria y la monta temporalmente como sistema de archivos raíz.
5. El kernel ejecuta el script linuxrc (/linuxrc) que realiza los siguientes procesos

   • Busca en el bus PCI alguna tarjeta de red. Por cada dispositivo PCI que encuentre, realiza una búsqueda en el archivo niclist (/etc/niclist) para encontrar alguna coincidencia. Una vez encontrada una coincidencia, el nombre del módulo de driver NIC es guardado para posteriormente cargarlo en el kernel. Si la tarjeta es ISA, el nombre del módulo del driver debe ser indicado en la línea de comandos del kernel.
   • Ejecuta el cliente DHCP dhclient que realiza una nueva petición DHCP para hallar la ruta del directorio raíz a montar por NFS.
   • Dhclient recibe la información DHCP del servidor y ejecuta el script dhclient-script (/etc/dhclient-script), que configura la interfaz de red eth0 con la información obtenida.
   • Recordemos que en este momento el sistema de archivos raíz está montado en la RAM, por lo que en este momento se monta un nuevo sistema de archivos raíz mediante NFS desde el servidor (por defecto el directorio exportado es /opt/ltsp/i386. Para montar este directorio como raíz el script linuxrc realiza pivot_root (intercambio del sistema de archivos raíz), por lo que el sistema de archivos NFS será montado como /, y el sistema de archivos anterior será montado en /oldroot.

6. Se ejecuta el init (/sbin/init), que realiza los siguientes procesos

   • Init lee el fichero inittab (/etc/inittab) y de acuerdo a éste comienza a preparar el sistema.
   • Se ejecuta el comando rc.local mientras el sistema esté en el estado sysinit.
   • El script rc.sysinit crea un un ramdisk de 1MB para almacenar lo que vaya a ser escrito ó modificado. Este espacio será montado como /tmp
   • El sistema de archivos /proc es montado.
   • Se lee el fichero de configuración lts.conf (/etc/lts.conf), cuyos parámetros comentaremos más adelante y que serán establecidos como variables de entorno para usar por el script rc.sysinit.
   • Se crea el archivos de intercambio swap y se habilita mediante el comando swapon.
   • Se configura la dirección de red loopback (127.0.0.1).
   • Se monta el directorio /home del usuario.
   • Se crean el directorio /tmp y subdirectorios donde se guardarán los archivos temporales y se crea en él el fichero syslog.conf (/tmp/syslog.conf) que contiene información de a qué host de la red debe enviarse la información de los logs.

7. Se cambia el runlevel a 5, con lo que se ejecutarán todas las instrucciones contenidas en inittab (/etc/inittab)

   • Se inicia una sesión de las X Windows System con el comando startx (/etc/screen.d/startx), que proporciona al usuario una interfaz gráfica.
   • El servidor de las X Windows System enviará una petición XDMCP (X Display Manager Control Protocol) al servidor XDM (X Display Manager) que le responderá con una pantalla de inicio de login de usuario.

Por supuesto, todo este proceso está condicionado a las opciones que se han introducido en el archivo de configuracion de Ltsp, que pasaremos a describir a continuación.

Configuración

La configuración de las opciones con las que contará el cliente se llevan a cabo mediante el fichero de configuración lts.conf, situado típicamente en /opt/ltsp/i386/etc/lts.conf . Este fichero consta de un gran número de opciones, que se pueden aplicar por defecto para todos los terminales ligeros ó especificar las características concretas que se aplicarán a cada conexión de terminal ligero.

Entre las opciones que podemos modificar en este archivo de configuración, aparte de las clásicas de configurado del ratón, pantalla, sonido, etc. encontramos interesantes opciones como Local Apps, que nos permite ejecutar ciertas aplicaciones en el terminal ligero, liberando de carga al servidor. Ésto, no obstante, es sólo posible con ciertas aplicaciones y cuando los terminales ligeros son los suficientemente potentes para ejecutar estas aplicaciones.

PXES (Universal Linux Thin Client)

PXES (Universal Linux Thin Client) es un proyecto iniciado por Diego Torres y que en este momento ya ha alcanzado la versión 1.0. Es un proyecto más reciente que el de LTSP, e incorpora interesantes variaciones respecto a éste.

Tras arrancar el terminal y obtener su dirección IP y la localización en el servidor del núcleo que debe cargar, el terminal obtiene el núcleo de la minidistribución PXES, que se ejecuta íntegramente en la memoria RAM del terminal.

Con lo cual, tenemos el sistema de archivos montado en la memoria RAM del terminal. Además, PXES viene con una utilidad PxesConfig, que permite crear fácilmente imágenes a medida para el hardware y prestaciones que se requieran del terminal, permitiendo que el terminal arranque distintos tipos de sesiones, como XDMCP, sesión RDP en un servidor Microsoft Windows ó una interesante opción que consiste en iniciar una sesión local de X Windows con un escritorio muy simple que comentaremos más adelante.

La principal diferencia entre estos dos proyectos radica en el montaje del sistema de archivos raíz, que PXES lo hace de forma local en la RAM mientras que LTSP hace uso del NFS para montarlo a través del servidor, lo que puede provocar un incremento considerable de la carga de red y del servidor si no se realiza adecuadamente. Sin embargo, con PXES nos vemos limitados por la memoria RAM del terminal ligero, que debe ser suficiente para permitir el montaje de todo el sistema de archivos, mientras que con LTSP al utilizar NFS permite una mayor flexibilidad en este aspecto. Con lo cual tenemos que estudiar detenidamente las características de cada proyecto concreto para elegir la solución que más nos convenga.

Funcionamiento

Cuando el terminal ligero se inicia envía una señal a la red identificándose con la MAC de su tarjeta de red y permanece a la espera de indicaciones de un servidor DHCP a la escucha, como está comentado en el apartado de arranque por red.

Si el servidor reconoce esta MAC enviará los datos de asignación de red a ese equipo (nombre de host, ip, rutas, máscara de red, etc.) y a continuación le enviará a través de FTP los archivos indicados en su configuración.

En ese momento el cliente pide, via el servidor que el dhcp le ha indicado, una imagen de boot loader (NP). Más tarde el terminal recibe todo el sistema operativo necesario para el funcionamiento del cliente; este sistema operativo se ejecutará íntegramente en la memoria RAM del terminal ligero.

Básicamente hay tres tipos de imágenes: la imagen Etherboot (con extensión .nbi), las imagenes pxes (con extensión .initrd) y las imagenes squashfs (con extensión .squashfs (comprimidas). Luego también veremos que se puede usar imagenes Etherboot o imagenes pxes especialmente preparadas para usar con GRUB.

Finalizada la carga de la microdistribución PXES, el cliente podrá mostrar el login gráfico que esté ejecutando el servidor. Si tenemos cuentas de usuario, podremos trabajar con las aplicaciones que tengamos autorizadas, teniendo en cuenta que todas las aplicaciones se ejecutan y guardan en el servidor y que nuestro ordenador local sólo es usado para mostrar en pantalla el resultado de las operaciones realizadas en el servidor.

La manera más rápida de tener PXES funcionando es usar las imágenes preconfiguradas (PreBuilt) disponibles en la web oficial. Esta solución es ideal también para usuarios de Windows, ya que no es necesario un entorno linux para construir las imágenes, tan sólo habrá que configurar los servicios DHCP y TFTP.

Dependiendo si el arranque es a través de PXE o de disquete bajaremos las imágenes .initrd o bien .nbi respectivamente. Además tambien se encuentra disponible asimismo una imagen ISO lista para grabar en cd-rom .iso.

Configuración

Pxes dispone de un completo configurador gráfico (PxesConfig) para construir las imágenes que cargarán los sistemas ligeros. También dispone de una serie de imágenes preconstruidas para diferentes situaciones y servicios con las configuraciones más usuales.

PxesConfig es un asistente que permite personalizar fácilmente las imágenes que luego cargarán los clientes ligeros, permitiendo ajustar una gran cantidad de valores como pueden ser la configuración de red, teclado, ratón, tarjeta de video, etc. hasta otros más específicos de los diferentes tipos de sesiones que permite Pxes (XDMCP, Microsoft Terminal Server RDP, VNC, NX…).

Un tipo interesante de sesión que permite Pxes es la denominada Local X Window Session with single desktop, windows manager and applications. Este sistema consiste básicamente en un sistema X Window completo pero muy ligero (<32 MB) que se ejecutaría íntegramente en la RAM del cliente, con lo que se reduciría ostensiblemente la carga de la red. Este sistema incluye un gestor de ventanas ligero como IceWM y algunas utilidades también ligeras como BusyBox.

Diet-PC

Diet-PC (Diskless Embedded Technology Personal Computer) consiste en un sistema operativo Linux embebido que se ejecuta por completo en la memoria RAM del cliente ligero. Este sistema es descargado del servidor de imágenes mediante TFTP. El sistema lanza un pequeño programa que se conecta al servidor a través de un protocolo IP, de modo que el cliente pueda ejecutar un entorno gráfico como X11, RDP, etc.

Diet-PC no tiene la facilidad de configuración que otros proyectos de similares características como Pxes ó Ltsp, ya que está pensado para que los desarrolladores puedan seleccionar los componentes necesarios para sus sistema y así optimizarlo a sus necesidades. Al contrario que los proyectos anteriormente comentados, Diet-PC no se configura a través de un archivo central de configuración, sino que realizará dicha configuración basándose en la detección automática del sistema local y en una mínima dependencia del servidor.

Otro punto importante es que el sistema Linux que carga el terminal está adecuado a los estándares Linux en lugar de utilizar alternativas recortadas que emplean otras soluciones. Por lo tanto, el rendimiento del sistema puede ser inferior al de otro métodos, requiriendo una mayor cantidad de memoria RAM en el terminal que otras alternativas.

Diet-PC puede servirse desde servidores Windows además de Linux, utilizando un protocolo de ventanas Windows (RDP por ejemplo).

	LTSP	PXES	Diet-PC
Versión actual	LTSP 4.1	PXES 1.0	Diet-PC 2.0
S.O. admitidos	Linux	Linux, Windows	Linux, Windows
RAM en el cliente	32 MB	16-32 MB	32-64 MB
Dispositivos locales	Disco duro, diskette, CD-Rom, impresora	Disco duro, diskette, CD-Rom, impresora
Montaje del sistema de archivos raíz	Montaje por NFS	RAM del cliente	RAM del cliente
Sesiones admitidas	XDMCP	XDMCP, escritorio local, RDP, NoMachine NX, FreeNX, ICA, VNC	XDMCP, RDP
Configurador	Configurador modo texto	Configurador gráfico (PxesConfig)	Sin configurador

Netstation

Es una distribución de Linux que permite convertir computadoras en thin clients que soportan la gran mayoría de los protocolos de conectividad. Permite arrancarlos desde la red o desde un dispositivo como diskete, cd, disco duro o flash.

Los protocolos que soporta esta distribución son bastante amplios (X- Terminal XDM, TightVNC, SSH, Citrix ICA, Tarantella,…). Se trata pues, de múltiples clientes accediendo concurrentemente usando administración local de ventanas.

Permite la autodetección de la tarjeta de red, tarjeta de vídeo y ratón. También se puede destacar que soporta paquetes “.nps” dinámico (puede cargarse en tiempo de ejecución). Dispone de configuración centralizada usando TFTP para obtener los ficheros de configuración facilitando el mantenimiento.

Thinstation

Thinstation es un distribución en Linux para thin client, para convertir un PC en un thin client soportando la gran mayoría de los protocolos de conectividad: Citrix ICA, No Machine NX, MS Windows Terminal Services (RDP), Tarantella, X, telnet, tn5250, VMS term y SSH. Puede ser arrancado por red, usando Etherboot/PXE o desde un dispositivo local floppy/CD/HD/flash-disk. La última versión es 2.0.2 (27 de mayo de 2005). Permite generar imagenes RAM personalizadas sin instalar nada en los servidores.

Comparte con Netstation el acceso de múltiples clientes trabajando concurrentemente usando administración local de ventanas. Permite, como Netstation, la autodetección de la tarjeta de red, tarjeta de vídeo y ratón. Puede soportar paquetes “.pkg” dinámico (puede cargarse en tiempo de ejecución). Dispone también de configuración centralizada usando TFTP para obtener los ficheros de configuración. Soporta Samba para compartir discos e impresoras de los clientes ligeros.

Software bajo licencia

Existen varias alternativas no libres para crear una red de thin client creadas por compañias con fines comerciales. Entre ellos vamos a destacar:

eLux NG

Es un sistema operativo embedido basado en Linux. El usuario y el administrador no necesitan conocimientos de Linux para utilizar o configurarlo. La interfaz de usuario es amigable y se puede configurar fácilmente mediante paneles de control. El sistema operativo es muy compacto para dejar capacidad a las aplicaciones y lograr un arranque rápido del Thin Client. eLux NG es una solución de sobremesa completa, que facilita al usuario un acceso rápido, confortable y seguro a Windows y otros servidores en un ambiente cliente/servidor. En un ambiente cliente/servidor las aplicaciones se ejecutan en un servidor central. En el terminal, “Thin Client” o cliente ligero, se instala una aplicación cliente. Con esta aplicación el Thin Client se conecta al servidor correspondiente. Este sistema permite el acceso a multitud de plataformas, basadas en RDP, ICA o X entre otras…

Citrix Metaframe

Uno de los productos más populares en entornos de empresa. Con la única instalación de un cliente (independientemente del sistema operativo utilizado) de Citrix se puede acceder a todo el juego de aplicaciones de la empresa, estando estas solo instaladas en un servidor. Así pues, Citrix proporciona un nivel de acceso centralizado y seguro para la gestión de los datos empresariales más importantes. Utiliza el protocolo ICA.

Terminal Services

Es la opción proporcionado por Microsoft en algunos de sus productos para la instauración de entornos de clientes ligeros. Se basa en el protocolo RDP, sin admitir otras opciones. Comenzó con Windows NT for Terminal Services y actualmente existen versiones avanzadas de los sistemas operativos de Microsoft (Windows 2000, Windows XP) que incluyen soporte de este protocolo como servidor. En cuanto a la parte cliente es fácilmente disponible de forma gratuita desde la página web de la propia empresa, que incluso tiene en cartera de productos la salida al mercado de un sistema operativo optimizado para trabajar como cliente ligero.

Neoware

En realidad no es un solo producto como tal, sino una empresa que dipone de multitud de soluciones relacionadas con los clientes ligeros, tanto hardware como software para acoplar a ellos. Entre estos productos cabe destacar su sistema operativo Linux personalizado, el software ezManager para administrar clientes ligeros o Teemtalk que sirve para conectar con casi cualquier entorno cliente ligero/servidor.

Wyse

Es similar a la anterior, una empresa de soluciones para clientes ligeros que facilita tanto hardware como software. En este caso la solución comercial que nos proporcionan basada en Linux recibe el nombre de WinTerm Linux y su sistema de administración de clientes ligeros, Wyse Rapport.

WinConnect Server XP

Es una solución de software que convierte el computador anfitrión Windows XP que no dispone del servicio “Terminal Services” de Microsoft en un servidor RDP permitiendo que dispositivos como terminales, aplicaciones de Internet/Información, Tablet PCs y PDAs, puedan conectarse con él para ejecutar aplicaciones de Windows simultánea e independientemente a través de cualquier red. La solución es similar por lo tanto a la de Microsoft, pero disminuyendo el coste adicional. No obstante, plantea algunas mejoras respecto al sistema de Microsoft, como son la posibilidad de trabajar con mayor número de colores o de que el flujo de audio MP3 o WAV generado en el servidor suene en el cliente ligero.

Comparativa

Vamos a mostrar unas tablas a modo de resumen de todas las alternativas vistas anteriormente con su información al detalle:

Métodos de arranque

	A Través de Etherboot	A Través de PXE	A Través de NetBoot	A Través de MBA	Desde Cd-rom	Desde Disco Duro	Desde Dispositivos de Almacenamiento USB	Desde DOS Usando Loadlin	DOC (Disk On Chip)	DOM (Disk On Module)
LTSP	Sí	Sí	Sí	Sí	Sí	Sí	Sí	Sí	Sí	Sí
PXES	Sí	Sí	No	No	Sí	Sí	Sí	No	Sí	Sí
DIET-PC	Sí	Sí	No	No	Sí	Sí	Sí	Sí	Sí	No
Netstation	Sí	Sí	No	No	Sí	Sí	No	Sí	Sí Usando Syslinux	No
Thinstation	Sí	Sí	Sí	No	No	Sí	Sí	Sí	Sí	No

Hardware de los terminales ligeros

	RAM Mínimo	RAM Recomendado	RAM Óptimo	Ratón	Soporte de sonido
LTSP	16 MB	32 MB	>32 MB	Serial o PS/2	Sí
PXES	16 MB	32 MB	>32 MB	Serial o PS/2	Sí
DIET-PC	32MB	64MB	64 MB	Serial o PS/2	Sí
Netstation	8MB usando TinyX	16 MB / 32MB	32MB	Serial o PS/2	No
Thinstation	8MB usando TinyX	16 MB / 32MB	32MB	Serial PS/2 y USB	No

Dispositivos locales en el cliente ligero

	Diskette	Disco Duro	CD-Rom	Impresoras	Dispositivos Serial	Audio	Memoria de Almacenamiento Flash USB
LTSP	Sí	Sí	Sí	Paralelo y USB	No	Sí	No
PXES	Sí	Sí	Sí	Paralelo, Serial y Usb	Lectores de Codigos de Barras	Sí	No
Netstation	Sí	Sí	Sí	Paralelo y Usb	No	Sí	Sí
Thinstation	Sí	Sí	Sí (BlackBox)	Paralelo y Usb	No	Sí	Sí
DIET-PC	Sí	Sí	Sí	Paralelo y Usb	No	Sí	No

Otras características

	Cliente gráfico sencillo en una sesión de pantalla completa	Sesión de texto (Telnet ó SSH)	Múltiples clientes simultáneos usando administrador de ventanas local	Autodetección de tarjetas de red, video y ratón	Soporte paquetes dinámicos “.nsp” o “.pkg” (Pueden ser cargados en tiempo de ejecución)	Administración centralizada usando TFTP para obtener los archivos de configuración	Administración remota de los clientes via Telnet SSH	Live CD disponible
LTSP	Sí	Sí	Sí	Sí	No	No	No	Sí
PXES	Sí	Sí	Sí	Sí	No	No	No	Sí
Netstation	Sí	Sí	Sí	Sí	Sí	Sí	No	No
Thinstation	Sí	Sí	No	Sí	Sí	Sí	No	Sí
DIET-PC	Sí	Sí	No	Sí	Sí	Sí	No	Sí

Decisión final

Para la instalación de la sala F5 del Edificio Tecnológico de la Facultad de Ingenierías Industrial e Informática de la Universidad de León hemos optado por basarnos en LTSP, tras probar varios métodos, ya que lo que queremos es que los terminales muestren al arrancar una pantalla de login para que el usuario pueda autentificarse, para a continuación cargar en el terminal el sistema adaptado a sus características y privilegios de usuario, con acceso a las aplicaciones que estén definidas. Un sistema como el LTSP, que envía una imagen mínima (< 2MB) y que luego monta por NFS el sistema del terminal permite realizar lo indicado anteriormente de una manera más lógica y sencilla.

Introducción a Cúmulo

Cúmulo es un proyecto de puesta en marcha de una sala de informática en la Escuela de Ingenierías Industrial e Informática de la Universidad de León utilizando técnicas de clientes ligeros comentadas en la primera parte de esta documentación.

La sala de informática dispone de 32 ordenadores (ver Anexo 3.1), que en la actualidad son de limitada utilización debido a su escasa potencia, y que actuarán de clientes ligeros según el esquema descrito en las siguientes páginas. El objetivo es que los usuarios de la sala de informática, en su mayoría estudiantes de Ingeniería Informática, realicen sus tareas habituales (navegación web, edición de texto, desarrollo de aplicaciones…) de modo transparente al funcionamiento interno de la sala, y con prácticamente las mismas prestaciones que si estuvieran trabajando sobre ordenadores actuales. Ésto se puede conseguir utilizando los ordenadores a modo de terminales que muestren la información que se procesa en el servidor.

Usualmente las soluciones de thin-client disponen de un potente servidor que ejecute las tareas y proporcione los servicios a todos los clientes. Sin embargo, para el proyecto Cúmulo utilizaremos un conjunto de servidores ligeros (ver Anexo 3.1), con lo que el coste en la compra de hardware va a ser mínimo, ya que estamos reutilizando equipos obsoletos tanto en la parte de servidores como en la parte de clientes. Del mismo modo, hemos optado por soluciones thin-client, aplicaciones y sistema operativo de software libre, con lo que el ahorro es aún más sustancial.

Cada uno de los servidores está encargado de realizar determinadas tareas y proporcionar determinados servicios, de acuerdo a las características de cada uno. La autenticación de los clientes se lleva a cabo de forma centralizada, mientras que los archivos que guarden los usuarios se almacenarán en un clúster NFS formado por dos servidores ligeros. Las herramientas utilizadas permiten una fácil administración de la sala, permitiendo gestionar los permisos de los usuarios, añadir nuevas aplicaciones, etc. con relativa facilidad.

Objetivos

1. Implantación y configuración de una red de clientes ligeros sobre servidores ligeros.

   • Inventariado de los recursos HW existentes.
   • Preparación de los terminales y servidores.
   • Estudio de las soluciones de software libre disponibles para ejecutar el proyecto (principalmente PXES, LTSP y Diet-PC)
   • Puesta en marcha de la red de terminales y de sus respectivos desktops.
   • Implementación de los servicios y aplicaciones en los servidores.
   • Implementación de un servicio de administración de las tecnologías y servicios implementados.
   • Realización de pruebas de rendimiento.

2. Desarrollo de un amplio proyecto que pueda servir para ir mejorándolo en años sucesivos con nuevos alumnos que lo utilicen como proyecto fin de carrera.

   • Mejora en el rendimiento del sistema.
   • Mejora en la seguridad y privacidad de los datos.
   • Nuevas configuraciones e implementaciones de tareas.

Dimensionamiento y requisitos generales

Se entiende por dimensionado el hecho de diseñar una pequeña instalación analizando los recursos informáticos que se necesitarán tanto de HW como de SW, viendo lo que es adecuada a la misma. Para ello vamos a exponer las necesidades básicas:

Los servidores

El dimensionado de los servidores depende tanto del número de clientes a conectar como de los servicios ofrecidos. Se da por hecho que el servidor va a ofrecer el arranque, un display manager y las aplicaciones a los clientes, pero además puede estar equipado con un proxy-caché, un dns-caché, algún mecanismo de filtrado como squidguard, etc. Todos estos datos se refieren a una instalación en la que se pueda tolerar una caída del servidor. En caso contrario necesitaríamos un instalación de alta disponibilidad y un diseño más complejo del almacenamiento secundario.

• Procesador: A partir de un Pentium II para pequeñas instalaciones. Según aumente la exigencia o el número de equipos se pueden emplear Pentium IV o equivalentes con uno o más procesadores. En nuestro caso el hecho de utilizar ordenadores antiguos como servidores hará que estemos limitados a Pentium II Pro en el mejor de los casos.
• Memoria: La cantidad necesaria según los programas y servicios a ejecutar. De 50 a 80 MB adicionales por cada cliente en el caso de un servidor que lo gestionara todo. En nuestro caso al tratarse de varios se deberá realizar un estudio de las necesidades de memoria de cada aplicación y servicio.
• Tarjeta gráfica: El servidor no tiene ningún requerimiento específico de tarjeta gráfica, y puede incluso prescindir de ella.
• Discos: Conforme aumente el número de clientes necesitaremos mayor desempeño del almacenamiento secundario. Es recomendable emplear discos SCSI, y cuando el número de clientes se cuenta por decenas utilizar RAID 0+1.

Los terminales

Para los terminales hay dos opciones principalmente: reciclar PCs antiguos o emplear equipos nuevos, basados en una placa del tipo mini-ITX y en un futuro en nano-ITX. Los equipos reciclados pueden obtenerse de alguna de las cooperativas que llevan a cabo estas tareas.

• Procesador: Lo mínimo que se ha utilizado han sido 486 a 66 Mhz, aunque lo recomendable es emplear un Pentium.
• Memoria: El mínimo a emplear depende de la configuración empleada. Por ejemplo, las X-Windows 3.3.6 consumen menos memoria que las 4.3.0. Lo recomendable es una superior a los 32 Mb, aunque con esta cantidad, que es de la que disponen los terminales que vamos a utilizar en nuestro proyecto, es suficiente.
• Tarjeta gráfica: Deberá ir dotada de un mínimo de memoria dependiendo de la resolución que queramos alcanzar, pero a una resolución típica de 800×600 una tarjeta de video de 1 ó 2 MB servirá.

La red

La red puede ser un importante cuello de botella si aumenta el número de terminales; al hacerlo también aumenta el número de colisiones en la comunicación de los equipos. Además, hay que tener en cuenta que los distintos tipos de soluciones propuestas tienen diferentes requisitos en cuanto al uso de la red, principalmente en el caso de Ltsp, que realiza la carga del sistema a través de NFS, con el aumento en la transferencia de información entre cliente y servidor que ello conlleva, aunque este hecho provoca que la carga inicial del sistema sea mucho más rápida, ya que la imagen inicial que carga el terminal ligero en el caso de Ltsp y que hemos descrito anteriormente es mínima, ya que el grueso del sistema se carga por NFS.

• Dispositivos de interconexión: Es imprescindible utilizar un switch para evitar que las colisiones degraden el rendimiento. Si contamos con pocos equipos, hasta una decena, puede valernos con un switch a 10 Mbps. Con más equipos se hace necesario conmutar a 100 Mbps. Si el número de clientes se eleva por encima del medio centenar, será necesario instalar un switch que permita la conexión al servidor a 1 Gbps.
• Modo dúplex: Cuando la autonegociación de los interfaces de red no funciona como debiera, pueden ponerse a funcionar en un modo dúplex no óptimo. Una mala configuración del modo dúplex puede ser difícil de detectar, ya que las pruebas básicas funcionarán aparentemente bien, porque consumen muy poco ancho de banda.
• Calidad del cable Ethernet: Un cable en malas condiciones degrada mucho las prestaciones. Este mal funcionamiento se traducirá en la aparición de errores y colisiones en el medio.

El hardware de red del que se dispone para interconectar los servidores, los terminales y ofrecer salida a Internet es el siguiente:

• Todos los terminales disponen de una tarjeta de red ISA 10 Mbps
• Los servidores disponen de una tarjeta de red PCI 10/100 Mbps
• 2 switchs de 20 bocas 100 Mbps
• 40 metros de cable de red sin entrelazar
• 1 salida a Internet por la red de la universidad

Teniendo en cuenta el material disponible, la solución más adecuada es crear dos subredes, una para los terminales limitada a 10 Mbps por las tarjetas de red de éstos, y otra para los servidores a 100 Mbps. Tanto los terminales como los servidores irán conectados directamente a los switchs, pero no tendrán salida directa a internet, ya que en medio se colocará un servidor como puerta de enlace, que será el que proporcione el servicio de DHCP a los equipos. La razon de la colocación de una puerta de enlace, además de para que los terminales no puedan acceder directamente a Internet, es para que no existan problemas con el DHCP, ya que la salida a Internet de la Universidad ofrece también DHCP a los equipos.

Explicación del funcionamiento del sistema

¿En qué consiste?

La base del funcionamiento de Cúmulo es la segregación de aplicaciones. De hecho, esta es la principal innovación respecto a otras soluciones de clientes ligeros. Tradicionalmente un potente servidor ha llevado toda la carga de procesos, pero lo que se consigue con este sistema es que cada aplicación se ejecute en un solo servidor, de modo que el consumo de recursos gracias a la compartición de librerías es mucho menor. Además, se dispone de cuentas de acceso para cada usuario de modo que tanto los datos de configuración como otros datos están almacenados de forma centralizada.

¿Cómo funciona?

El arranque

A continuación se explica el funcionamiento del sistema desde el punto de vista del terminal ligero. No se va a entrar en detalle en cada uno de los pasos ya que en capítulos posteriores se explicará pormenorizadamente. Cuando arrancamos el cliente, este, de una u otra manera intenta hacer un arranque por red, ya que así están configurados. El servidor DHCP recibe la petición del cliente, y envía la respuesta asociada a su MAC en caso de que haya una entrada en el archivo de configuración. Esta respuesta consta de los datos de configuración de red del terminal, así como la ruta de la imagen que se va a cargar por red para el arranque de terminal.

En nuestro caso hemos elegido arranque con PXE ya que es más compatible con ciertas tarjetas de red que etherboot, aunque esto para nada afecta al resto del funcionamiento del sistema. El servidor ha proporcionado la ruta de un pequeño kernel de linux de unos pocos kBs de tamaño, que después de ser descargado por tftp se ejecutará. A partir de ahora el proceso será solicitar un archivo de configuración con el nombre del kernel y del initrd, además de las opciones que se pasaran al kernel durante su carga. Entre estas opciones está el nombre del script que luego se ejecutará.

Con esto se descarga tanto el kernel como el initrd anteriormente indicados. El control se pasa a este nuevo kernel que monta el initrd como directorio raíz, entonces ejecuta el script que antes mencionamos. Este script se encarga entre otras cosas de cargar los módulos para la tarjeta de red, solicita de nuevo una configuración de red y demás cosas. Pero lo que realmente importa es que va a montar un nuevo sistema raíz por NFS. Para ello monta primero el nuevo sistema en /mnt y luego hace un pivot_root sobre este de manera que intercambia el nuevo sistema por el antiguo.

La estructura de directorios

El nuevo sistema raíz ha sido cargado por NFS desde el servidor instalado a tal efecto. La estructura de directorios de este es un poco peculiar, por lo que a continuación se comentan aspectos destacables de la misma. En primer lugar, este sistema tiene únicamente las herramientas, aplicaciones y librerías necesarias para el funcionamiento de los clientes. por tanto la instalación de las aplicaciones ha sido hecha manualmente analizando las dependencias de cada una.

Para poder hacer uso de las cuentas de usuario periódicamente se actualizan los archivos passwd y shadow con los del ordenador que tiene las cuentas de usuario.

Por último, en el directorio /home se ha montado también por NFS los directorios de usuario, ya que ahí se encuentra la configuración de escritorio y de alguna otra aplicación que luego resultará de vital importancia.

El sistema de autentificación

Para que cada usuario pueda acceder desde cada equipo con su cuenta de usuario es necesario que este haga login antes de hacer uso del terminal.

Esto se realiza por medio de XDM (X Display Manager), que tras solicitar el nombre y la contraseña del usuario, comprobará que son las correctas a través de la información que proporcionarán de forma centralizada los servidores ligeros y procederá a permitir o denegar el acceso al escritorio.

Como cada usuario tiene su propio /home, se puede personalizar el sistema de cada uno dependiendo el uso que se quiera hacer del terminal en una u otra situación.

¿Qué tiene el sistema?

Toda la estructura de directorios que hemos montado por NFS van a ser las aplicaciones y herramientas a las que el terminal tendrá acceso localmente. Aunque esté montado remotamente , esto es transparente para el usuario.

Por tanto necesitamos disponer de lo necesario para que el sistema pueda funcionar. Aparte de un sistema base con algunas herramientas de administración, el sistema tendrá un servidor X para poder cargar las distintas aplicaciones gráficas. Por otra parte, la autentificación la haremos a través de XDM, por lo que este paquete también formará parte del conjunto de aplicaciones. Como se va a hacer uso de un escritorio local para el uso del terminal además de SSH para lanzar las aplicaciones remotas habrá que preocuparse de contar con sus ejecutables y librerías asociadas en el árbol de directorios que hayamos montado por NFS.

Aparte de estas aplicaciones, hay otras tantas que son necesarias para el funcionamiento de los terminales, pero no son aquí nombradas ya que su funcionamiento no es tan destacado en Cúmulo.

Escritorio

Tras haberse validado el usuario se encuentra con un escritorio con iconos de aplicaciones. El escritorio elegido es IceWM por su sencillez y similitud a entornos Windows de los que puede provenir el usuario.

Al usuario, el funcionamiento del sistema le resulta normal, similar a si estuviese en un equipo de sobremesa corriente. Hace doble clic en el icono y la aplicación se ejecuta.

Sin embargo, el funcionamiento no es tan sencillo. Cada icono tiene asociado un comando que lanza esa aplicación en el servidor asociado, de modo que la aplicación se está ejecutando en otro equipo, que es el encargado de ejecutar esa aplicación para todos los clientes, pero se muestra en el terminal, que en este caso hace de servidor gráfico.

Ejecución de aplicaciones

Para la ejecución remota de las aplicaciones se ha optado por la utilización de SSH con la opción -X que activa el X11 Fordwarding.

Para que el uso de esto sea transparente al usuario, se dispone de una serie de scripts que se encargan de personalizar el escritorio de cada usuario de modo que sea el mismo que inició sesión el que ejecute la aplicación remotamente.

Aparte, se han almacenado las “pub keys” en cada home, para no tener que introducir la contraseña cada vez que lancemos una aplicación.

Servicios de almacenamiento

Parte importante en cualquier red informática es disponer de unos adecuados servidores de almacenamiento. En nuestro caso si cabe es más importante todavía.

Por el propio funcionamiento del sistema, se está haciendo un uso continuo del montaje de directorios por NFS. Tanto los clientes como los servidores de aplicaciones basan su funcionamiento en esto. Los clientes porque montan todo el sistema de esta manera y los servidores de aplicaciones porque necesitan que éstas tengan acceso a los home de usuario. Ya que el sistema tiene una gran carga de uso en el sistema prima la disponibilidad, sin descuidar la integridad de la información.

Configuración básica de servidores

Kernel personalizado

Los servidores que empleamos en el proyecto Cúmulo no son todo lo modernos que podríamos desear, y el hecho de ser antiguos servidores de marcas especializadas como IBM, HP, etc… hace que parte de su hardware sea excesivamente específico y por ello un kernel normal no lo detecte de forma adecuada.

Por ello, como una de las primeras fases antes de comenzar la instalación del sistema, se hace necesario el disponer de un kernel personalizado para estos servidores que nos permita hacer uso de todo su hardware en condiciones adecuadas.

Para ello hemos procedido a realizar los pasos habituales para compilar cualquier kernel. En primer lugar nos descargamos la última versión del código fuente de nuestro sistema, así como los ficheros de configuración correspondientes. En nuestro caso, para la versión 2.6.10:

# apt-get install linux-source-2.6.10
# apt-get linux-tree-2.6.10

Tras esto, pasaremos a descomprimir el kernel:

#cd /usr/src
#tar xjsvf linux-source-2.6.10.tar.bz2
#cd linux-source-2.6.10

Y tras ello, copiaremos el fichero con la configuración por defecto del sistema al directorio donde hemos descomprimido nuestro kernel y procederemos a realizar la nueva configuración:

# cp /boot/config-2.6.10-5-386 .config
# make menuconfig

Dentro de la herramienta de configuración del kernel hemos de prestar especial atención a que el nuevo kernel tenga activadas las opciones adecuadas para que los dispositivos SCSI funcionen. En nuestro caso, sabiendo que el modelo de controladora SCSI que tienen nuestros sistemas es el Adaptec AIC 7900, deberemos de activar las opciones.

Otro aspecto importante al que deberemos de prestar atención es la placa que utilizan las máquinas, tanto en lo referente a la optimización para un procesador en concreto como para que incluya soporte para los buses de que disponga (ISA, EISA o MicroChannel, según la opción).

Una vez finalizada la fase de configuración pasaríamos ya a la compilación del kernel y su posterior instalación en el sistema, a través de los pasos habituales:

# make
# make modules_install
# make install

Y con esto ya dispondríamos de un nuevo kernel de arranque adaptado a nuestro sistema que pondríamos a funcionar reiniciando el servidor.

# shutdown -r NOW
DNS
Concepto

El DNS (Domain Name System) es un conjunto de protocolos y servicios  (base de datos distribuida) que permite a los usuarios utilizar nombres  en vez de tener que recordar direcciones IP numéricas. Ésta, es  ciertamente la función más conocida de los protocolos DNS: la asignación  de nombres a direcciones IP. Por ejemplo, si la dirección IP del sitio  FTP de un sitio es 200.64.128.4, la mayoría de la gente llega a este  equipo especificando ftp.nombresitio y no la dirección IP. Además de ser  más fácil de recordar, el nombre es más fiable. La dirección numérica  podría cambiar por muchas razones, sin que tenga que cambiar el nombre.

Inicialmente, el DNS nació de la necesidad de recordar fácilmente  los nombres de todos los servidores conectados a Internet.
Funcionamiento

Para la operación práctica del sistema DNS se utilizan tres  componentes principales:

Los Clientes DNS (resolvers), un programa cliente DNS que se  ejecuta en la computadora del usuario y que genera peticiones DNS de  resolución de nombres a un servidor DNS (de la forma: ¿Qué dirección IP  corresponde a nombre.dominio?).
Los Servidores DNS (name servers), que contestan las peticiones  de los clientes. Los servidores recursivos tienen la capacidad de  reenviar la petición a otro servidor si no disponen de la dirección  solicitada;
Y las Zonas de autoridad (authoritative DNS server), porciones  del espacio de nombres de dominio que manejan las respuestas a las  peticiones de los clientes. La zona de autoridad abarca al menos un  dominio e incluyen subdominios, pero estos generalmente se delegan a  otros servidores.

Puesta en marcha en CÚMULO

Para el buen funcionamiento de nuestro sistema CUMULO, tomamos la  decisión de poner en marcha dos servidores de nombres que pudieran  proporcionarnos de forma redundante los datos de las máquinas de nuestro  sistema (tanto clientes como servidoras) así como la resolución de  nombre necesaria para acceder a la red Internet.

Teniendo en cuenta que los requisitos de capacidad de estas  máquinas  eran mínimos (tanto en lo referente a memoria, como a  capacidad de almacenamiento), decidimos aprovechar para estas funciones  las máquinas equipocinco y equiposeis, dos servidores de IBM con apenas  32 Mb de RAM y 1 Gb de capacidad total de disco duro, cuyo uso para  otras funciones sería enormemente complicado.

Para comenzar la puesta a punto de estas máquinas, una vez  funcione correctamente su sistema operativo procederemos a instalar los  paquetes del software servidor DNS Bind 9, incluído como paquete .deb:
# apt-get install bind9

Una vez con el software instalado, procederemos a añadir Bind 9 al  arranque para que de esta manera cada vez que se arranque el servidor se  ponga en marcha el servicio automáticamente:
# update-rc.d bind9 defaults
	 Adding system startup for /etc/init.d/bind9 ...
	   /etc/rc0.d/K20bind9 -> ../init.d/bind9
	   /etc/rc1.d/K20bind9 -> ../init.d/bind9
	   /etc/rc6.d/K20bind9 -> ../init.d/bind9
	   /etc/rc2.d/S20bind9 -> ../init.d/bind9
	   /etc/rc3.d/S20bind9 -> ../init.d/bind9
	   /etc/rc4.d/S20bind9 -> ../init.d/bind9

Tras esto comenzaremos a hacer la configuración del servicio DNS.  Para ello comenzaremos editando el fichero /etc/named.conf.options, en  el que definimos las opciones con las que arranca el software de  servidor. Como nosotros disponemos de un servidor DNS en la universidad,  vamos a indicarle aquí cual es la dirección, de manera que para  cualquier dirección que no sepamos (es decir, para los servidores de  Internet), nuestro servidor DNS le pregunte al servidor DNS de la  universidad la información adecuada para después respondernos. Eso lo  hacemos añadiendo a este fichero las líneas:
        forwarders {
                193.146.97.133;
         };

Una vez tenemos esto, podemos empezar a definir las zonas (directas e  inversas) para las cuales nuestro servidor DNS va a ser “autoritativo”,  es decir, va a ser él el que proporcione directamente la información  como “autoridad máxima” sobre ellos. En nuestro caso, éstas van a ser  las correspondientes a la red del sistema CUMULO:

La correspondiente a la resolución directa del dominio  cumulo.org, que es el que hemos escogido como dominio común a todas las  máquinas de nuestro sistema.
La zona correspondiente a la resolución inversa de la clase C  192.168.2.0/24, que es en la que están incluídos todos los sistemas de  CUMULO.

Estas las definiremos en el fichero /etc/bind9/named.conf.local  añadiendo a ese fichero lo siguiente:
zone "cumulo.org" IN {
        type master;
        file "/etc/bind/db.cumulo.org";
};

zone "2.168.192.in-addr.arpa" IN {
        type master;
        file "/etc/bind/reverse/db.192.168.2";
};

Vamos a ir viendo a continuación como podría ser el fichero de  configuración del dominio directo /etc/bind9/db.cumulo.org. Para empezar  definiríamos el número de serie y los tiempos de propagación, refresco,  etc... del dominio:
$TTL 4800
@       IN      SOA     server.cumulo.org. root.cumulo.org.  (
                                      2005082700   ; Serial
                                      28800      ; Refresh
                                      14400      ; Retry
                                      3600000    ; Expire
                                      3600 )    ; Minimum

A continuación, dentro del mismo fichero definimos quien es el  servidor autoritativo (nosotros), así como los servidores de correo que  servirán los dominios @cumulo.org:
@       IN                      NS      dns;
;
        IN                      MX      10      relay.unileon.es
        IN                      MX      20      relay.unileon.es

Tras ello, ya podemos pasar a ir definiendo los nombres de máquina  correspondientes a cada dirección IP, como registros A (Address):
equipouno		IN	A	192.168.2.1
equipodos		IN	A	192.168.2.2
equiposiete	IN	A	192.168.2.7

También definiremos seguramente algún alias, es decir, un segundo  nombre para algun equipo, lo que haremos de la siguiente manera:
shuttle		CNAME	equipouno
openoffice		CNAME	equiposiete

Otro tipo de registros que tendremos que definir serán los de  round-robin, es decir, aquellos que a partir de un mismo nombre apuntan a  más de una dirección IP diferente, y que sirven para balanceo de carga  entre las distintas direcciones IP correspondientes al mismo registro.  En nuestro caso definimos que para dns.cumulo.org van a responder dos  máquinas: la 192.168.2.5 y la 192.168.2.6:
dns			0	IN	A	192.168.2.5
			0	IN	A	192.168.2.6

Por último, para los clilentes ligeros, que son muy numerosos,  podemos generar sus nombres a través de una regla sencilla gracias a la  directiva $GENERATE. En nuestro caso vamos a considerar como tales todas  las direcciones IP desde la .100 a la .255  y les vamos a poner como  nombre tclient y el último octeto de su IP. Es decir, para la IP  192.168.2.124 el nombre sería tclient124.cumulo.org. La línea que  debemos de añadir al fichero pa ra esto es la siguiente:
$GENERATE 100-255 tclient$ A 192.168.2.$

Con esto ya hemos acabado la configuración de la resolución directa.  Vamos a ir con la inversa, que la almacenaremos, según hemos indicado  anteriormente, en el fichero /etc/bind9/reverse/db.192.168.2.  Tal y  como hacíamos en la otra zona, comenzaríamos definiendo número de serie y  tiempos de propagación, refresco, etc... de la zona:
@       IN      SOA     server.cumulo.org. root.cumulo.org.  (
                                      20050527   ; Serial
                                      28800      ; Refresh
                                      14400      ; Retry
                                      3600000    ; Expire
                                      3600 )    ; Minimum

NOTA: El campo Serial debe llevar un numero unico para cada dominio,  en caso de querer agregar otro dominio deberá cambiarse el numero. Puede  ser cualquier numero, pero no deben haber dos iguales o BIND no  resolverá ninguno de los dos.
También indicamos el servidor web autoritativo:
@       IN                      NS      dns;

Para a continuación pasar a definir una a una las direcciones IP de  los servidores y su nombre completo correspondiente, añadiéndoles un  punto al final para indicar que es un nombre absoluto y que el programa  no le añada ningún sufijo:
1               PTR     equipouno.cumulo.org.
2		PTR	equipodos.cumulo.org.
5               PTR     dns-1.cumulo.org.
6               PTR     dns-2.cumulo.org.
7		PTR	equiposiete.cumulo.org.

Por último, al igual que hacíamos con la resolución inversa, usamos  la directiva $GENERATE para crear resoluciones inversas para las IPs de  todas las máquinas que van a funcionar de clientes ligeros:
$GENERATE 100-255 $     PTR     tclient$.cumulo.org.

Con esto, ya tendríamos listo nuestro DNS para funcionar. Sólo nos  quedaría arrancarlo, lo que haríamos tecleando el comando:
# /etc/init.d/bind9 start
DHCP
Concepto

DHCP (Dynamic Host Configuration Protocol) es un servicio usado en  redes para:

a) Entregar direcciones IP a clientes de red. 
b) Compatibilizar con BOOTP para booteo de máquinas Diskless. 


Pero sobre todo, DHCP es un modelo de cliente-servidor. En toda LAN  usando TCP-IP, todas las máquinas deben tener un “número” IP. Esto se  puede lograr de dos maneras:

a)Configurando cada cliente por separado, evitando choques de IP  (configuración "per-host"). 
b) Asignando una IP por cliente, de manera dinámica o estática  (DHCP). 


Cada cliente por separado en a) tendra un número IP asignado por el  administrador de red. En b) cada número IP estara asignado dentro de un  "pozo" de números IP dispuestos por el servidor DHCP.

Por otro lado, podemos decir que las ventajas del uso de DHCP  son:

a) Sólo se configura un servidor para entregar números IP para  clientes de red. 
b) Se entregan todos los parámetros básicos de TCP-IP. 
c) Facilidad de configuración. 


También vamos a comentar las desventajas de este servicio:

a) Al entregar números IP dentro de la red, habiendo un DNS, no  hay un puente intermedio entre DNS y DHCP directo. Es decir, hay que  agregar las máquinas "a mano" en el DNS. 
b) Los mensajes tienden a fallar sobre todo si las tarjetas de  red hacen la negociación de velocidad (más conocido como Network Speed  Auto-Sense, que falla con una rapidez increible) ya que la red se llena  de "basura física". La culpa puede ser de las tarjetas o de los HUBs. 

Funcionamiento

Existen diferentes etapas en el desarrollo de una comunicación DHCP:

Etapa de descubrimiento. Cuando un host no posee un número IP  determinado (o sea, necesita un IP de un servidor DHCP), manda un  mensaje llamado DHCPDISCOVER. Este mensaje es enviado dentro de la capa  física de la red. Este mensaje incluye además algunos parámetros  adicionales, como IPs sugeridas o tiempo de duración del número IP  anterior que tuvo (si lo hubiera).
Etapa de ofrecimiento. El mensaje llega a un servidor DHCP (los  clientes que no posean el servicio DHCP ignoran este mensaje). El  servidor responde de la misma manera física, pero con un mensaje llamado  DHCPOFFER. Este mensaje es enviado a toda la red (broadcast a  255.255.255.255) o únicamente al cliente. El cliente sabe como  responder, ya que uno de los parámetros del mensaje DHCPDISCOVER es la  MACAddress (Dirección física de la tarjeta de red).
Etapa de petición. El cliente recibe una o más peticiones  DHCPOFFER de uno o más servidores. El cliente entonces elige (por tiempo  de respuesta, por IP, etc...; es bastante oscuro el proceso de  eleccion). Al elegir, el cliente envia un mensaje DHCPREQUEST al  servidor que ha elegido para su IP (server identifier), junto con otras  opciones. Si el cliente no recibe mensajes DHCPOFFER, expira la peticion  y reenvia un nuevo mensaje DHCPDISCOVER.
Etapa de encuentro. El servidor recibe el broadcast con el  mensaje DHCPREQUEST del cliente. El servidor responde con un mensaje  DHCPACK que contiene los parámetros para el cliente (el número IP). Aquí  viene la etapa de "leasing" de IP. Si el servidor no puede satisfacer  el mensaje DHCPREQUEST, el servidor igualmente debe responder con un  DHCPACK. El servidor marca los números IPs no disponibles.
Etapa de préstamo. El cliente recibe el mensaje DHCPACK y  revisa si la configuración esta OK. Si el cliente detecta un error,  manda un mensaje DHCPDECLINE y reinicia el proceso. Si en vez de recibir  un DHCPACK, el cliente recibe un mensaje DHCPNAK, el cliente reinicia  el proceso. Cuando esto ocurre (DHCPDECLINE y DHCPNAK), el cliente  expira la peticion y la reinicia.
Etapa de devolución. El cliente envía un mensaje DHCPRELEASE al  servidor cuando libera su IP.


Este es el proceso simple y básico. Hay distintos tipos de  interacciones entre Cliente y Servidor,  sobre todo cuando un cliente ya  dispone de un número IP (antiguo lease). En este caso, la negociación  sólo ocurre con un DHCPREQUEST , DHCPACK/DHCPNAK y DHCPRELEASE.

Por tanto, los mensajes enviados entre si son:

DHCPDISCOVER: El cliente envía a toda la red física para  encontrar servidores disponibles DHCPOFFER: Mensaje de servidor a  cliente en respuesta del DHCPDISCOVER.
DHCPREQUEST: El cliente recibe el DHCPOFFER de un servidor y  declina de otro.
DHCPACK: El servidor responde con un IP y otros parámetros  adicionales.
DHCPNAK: Mensaje de servidor a cliente rechazando los  parámetros de configuración (por ejemplo, que un cliente pida un IP ya  asignada).
DHCPDECLINE: Mensaje de cliente a servidor indicando que los  parámetros son inválidos.
DHCPRELEASE: Mensaje de cliente a servidor indicando que  "libera" la IP prestada y que cancela los préstamos restantes.


Si deseamos consultar información detallada al respecto de este  protocolo, podemos encontrarla en los documentos RFC1531 y RFC2131.
Puesta en marcha en CÚMULO

Como siempre que empezamos a poner en marcha un nuevo servicio dentro  de nuestro sistema CUMULO, la primera etapa pasa por identificar el  servidor que nos va a proporcionar este servicio e instalar en él el  software que va a prestar este servicio. En nuestro caso el servidor  equipouno, que centraliza todas las tareas de arranque, va a ser el que  aloje este servicio, y realizaremos la instalación del software servidor  DHCP a través del paquete correspondiente:
# apt-get install dhcp3-server

Una vez que le tenemos instalado, pasaremos a realizar su  configuración, que se realiza a través de los ficheros situados en el  direcotrio /etc/dhcp3 de nuestro sistema.
Concretamente, el que va a sernos más importante para esot es el  fichero /etc/dhcp3/dhcpd.conf, donde especificamos como va a actuar el  servidor DHCP a la hora de proporcionar IP y otra información a los  diferentes clientes ligeros. En primer lugar, indicamos al servidor que  no intente ningún tipo de actualización en el DNS tras proporcionar IP a  los clientes. Eso lo habríamos tecleando:
#
# Sample configuration file for ISC dhcpd for Debian
#
ddns-update-style none;

Tras esto pasaríamos a concretar varias opcione que son comunes para  todos los clientes ligeros a los que les vamos a propocionar dirección  IP, que son:

El nombre del dominio al que van a pertenecer, que será  cumulo.org
Los servidores DNS a los que los clientes ligeros tenedrńa que  hacer sus peticiones de resolución, que son los 192.168.2.5 y  192.168.2.6.
El router por defecto al que tendrán que enviar cualquier  paquete para fuera de su red, que es el 192.168.2.1.
El tiempo por defecto durante el cual va a concederse una IP a  uno de los clientes ligeros, que es de 21.600 segundos (6 horas)
El tiempo máximo durante el cual se podría renovar una  dirección IP a un cliente ligero, que será igual al anterior.

A la hora de teclearlo en el fichero de configuración esta es la  sintaxis que seguimos:
# option definitions common to all supported networks...
option domain-name "cumulo.org";
option domain-name-servers 192.168.2.5,192.168.2.6;
option routers 192.168.2.1;

default-lease-time 21600;
max-lease-time 21600;

En una misma red local podría haber varios servidores DHCP. Entre  ellos se decidiría que uno es el que tiene autoridad para esa red,  prevaleciendo sobre el resto. Esto lo definimos añadiendo al ficheros de  configuración el siguiente parámetro:
# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

En este mismo fichero definiermos también a que facility del demonio  syslog enviamos los mensajes que genere este demonio en su  funcionamiento. Eso se hace con la siguiente sintaxis:
log-facility local7;

También definimos en el fichero de configuración cual es nuestra red  local en la que vamos a dar servicio, de la siguiente manera:
subnet 192.168.2.0 netmask 255.255.255.0 {
        range 192.168.2.20 192.168.2.80;
}

Y a continuación pasaríamos a definir ya las caracterisitcas  concretas de arranque de cada uno de los teminales ligeros, que en  nuestro caso serían:

La dirección MAC de la tarjeta del clilente (hardware ethernet),  que nos sirve para identificarle unívocamente.
La dirección IP que vamos a proporcionarle cuando nos haga una  petición DHCP (fixed-address)
El nombre del fichero que vamos a obligarle a pedir al servidor  TFTP y que va a servirle al cliente como imagen para comenzar el  arranque del sistema (filename).
Las opciones adicionales que le vamos a pasar al arranque  anterior. En nuestro caso hemos incluído la option root-path, a través  de la cual le proporcionamos al cliente fijo el directorio NFS que va a  montar como directorio raíz en cuanto comience su arranque.

Vamos a ejemplificar esto con dos máquinas, junto a su definición  completa:
host terminal1 {
        hardware ethernet 00:60:67:C2:75:A9;
        fixed-address 192.168.2.101;
        filename "/lts/2.4.26-ltsp-3/pxelinux.0";
        option root-path             "192.168.2.12:/cluster/root";
        }

host terminal2 {
        hardware ethernet 00:60:67:C4:7B:56;
        fixed-address 192.168.2.102;
        filename "/lts/2.4.26-ltsp-3/pxelinux.0";
        option root-path             "192.168.2.12:/cluster/root";
        }
...

Una vez especificado esto, nos podemos asegurar que tenemos el  servidor arrancado tecleando:
# /etc/init.d/dhcp3-server start

Y tras ello ya estaremos listos para proporcionar direcciones IP a  todos los clientes que las soliciten.
TFTP
Concepto
TFTP son las siglas de Trivial File Transfer Protocol (Protocolo de  transferencia de archivos trivial). Es un protocolo de transferencia muy  simple semejante a una versión básica de FTP. Uno de los usos más  comunes de este protocolo, es el de la transferencia de  pequeños  archivos entre ordenadores de una red en una red, como cuando un  terminal X-Window o cualquier otro cliente ligero arranca desde un  servidor de red, ya que es más rápido que FTP (TFTP utiliza protocolo de  transporte UDP) al no llevar un control de errores en la transmisión.  Precisamente para eso es para lo que vamos a utilizarle en CUMULO.
Algunos detalles del TFTP:

Utiliza UDP(puerto 69) como protocolo de transporte (a  diferencia de FTP que utiliza el protocolo TCP - puerto 21).
No puede listar el contenido de los directorios.
No existen mecanismos de autentificación o encriptación.
Se utiliza para leer o escribir archivos de un servidor remoto.
Soporta tres modos diferentes de transferencia, "netascii",  "octet" y "mail", de los que los dos primeros corresponden a los modos  “ASCII".

Funcionamiento
Ya que TFTP utiliza UDP, no hay una definición formal de sesión,  cliente y servidor. Sin embargo, cada archivo transferido vía TFTP  constituye un intercambio independiente de paquetes, y existe una  relación cliente-servidor informal entre la máquina que inicia la  comunicación y la que responde.

La máquina A, que inicia la comunicación, envia un paquete RRQ  (read request/petición de lectura) o WRQ (write request/petición de  escritura) a la máquina B, conteniendo el nombre del archivo y el modo  de transferencia.
B responde con un paquete ACK (acknowledgement/confirmación),  que también sirve para informar a A del puerto de la máquina B al que  tendrá que enviar los paquetes restantes.
La máquina origen envía paquetes de datos numerados a la  máquina destino, todos excepto el último conteniendo 512 bytes de datos.  La máquina destino responde con paquetes ACK numerados para todos los  paquetes de datos.
El paquete de datos final debe contener menos de 512 bytes de  datos para indicar que es el último. Si el tamaño del archivo  transferido es un múltiplo exacto de 512 bytes, el origen envía un  paquete final que contiene 0 bytes de datos.

A continuación, explicamos este proceso que acabamos de comentar pero  para el proyecto Cumulo en cuestión.
Puesta en marcha en CÚMULO
Vamos a instalar el servidor TFTP en la máquina equipouno de CUMULO,  que es en la que se centralizan los servicios encargados del arranque de  los terminales ligeros.
Para ello, comenzaremos por instalar el propio software servidor  de TFTP en el servidor, que se encuentra en el paquete tftpd-hpa,  tecleando:
# apt-get install tftpd-hpa

Tenemos dos maneras básicas de usar el servidor TFTP en nuestro  sistema:

Como demonio independiente, que se está ejecutando  permanentemente, esperando conexiones y las atiende cuando llegan
A través del superservidor inetd, que se encarga de lanzar  instancias del demonio tftpd cada vez que recibe una petición de un  fichero a través de este protocolo.

Nosotros hemos escogido esta última versión por el hecho de que el  retraso de unas centésimas de segundo en este servicio al arranque no  supone ningún problema, y sí que es más importante para nos otros el  ahorro de memoria obtenido del hecho de no tener que dejar siempre este  proceso en la máquina (pues además, es un proceso que se utiliza sólo  puntualmente cuando los servidores arrancan).
Por ello lo primero que hacemos para poner en marcha este  servicio es el editar el fichero de configuración /etc/inetd.conf del  supersevidor inetd y añadir (o descomentar) la lína referente al  servicio TFTP:
#:BOOT: Tftp service is provided primarily for booting.  Most sites
# run this only on machines acting as "boot servers."
tftp           dgram   udp     wait    root  /usr/sbin/tcpd /usr/sbin/in.tftpd /tftpboot

Aquí acabamos de definir que el servidor va a arrancar el binario  in.tftpd cada vez que reciba una petición por el puerto de TFTP, y que  le pasa a este programa como parámetro /tftpboot, que es el directorio  donde va a buscar un fichero cada vez que alguien se lo pida.
No obstante, para acabar de configurar el demonio, también  tenemos que editar el fichero /etc/default/tftpd-hpa que el servidor  TFTP lee cada vez que arranca. En este fichero vamos a decirle que NO  tiene que ejecutarse como demonio independiente (es decir, se ejecutará  como un programa que cuando finaliza desaparece de memoria) y también  algunos parámetros de arranque por defecto:
#Defaults for tftpd-hpa
RUN_DAEMON="no"
OPTIONS="-l -s /var/lib/tftpboot"

Con esto, ya tendremos listo nuestro sistema para funcionar. En  nuestro caso concreto, crearemos dentro de este directorio /tftpboot/  otro nuevo directorio con las diversas imágenes que los clientes ligeros  nos pueden solicitar por la red para que se las sirvamos a su arranque.
NTP
Concepto
Según pasa el tiempo el reloj de un computador está expuesto a  ligeros desplazamientos. NTP (Protocolo de Hora en Red, en inglés  “Network Time Protocol”) es un protocolo que permite asegurar la  exactitud de nuestro reloj.
Existen varios servicios de Internet que confían y se pueden  beneficiar de relojes de computadores precisos. Por ejemplo, un servidor  web puede recibir peticiones de un determinado fichero si ha sido  modificado posteriormente a una determinada fecha u hora. Servicios como  “cron” ejecutan comandos en determinados instantes. Si el reloj no se  encuentra ajustado estos comandos pueden ejecutarse fuera de la hora  prevista.
Además, podemos ajustar nuestro reloj según la hora de otros  servidores e incluso proporcionar servicio de hora nosotros mismos.
Funcionamiento
Elección de los servidores de hora adecuados
Para sincronizar nuestro reloj necesitamos comunicarnos con uno o más  servidores NTP. El administrador de nuestra red o nuestro proveedor de  servicios de Internet muy posiblemente hayan configurado algún servidor  NTP para estos propósitos. Se recomienda consultar la documentación de  que disponga. Existe una lista de servidores públicamente disponibles  que se pueden utilizar para buscar un servidor NTP que se encuentre  geográficamente próximo. De todas formas hay q asegurarse de que conoce  la política de uso de estos servidores públicos ya que en algunos casos  es necesario pedir permiso al administrador antes de poder utilizarlos,  principalmente por motivos estadísticos.
La mejor opción es seleccionar servidores NTP que no se  encuentren conectados entre sí por si alguno de los servidores que use  sea inaccesible o su reloj se averíe. El servicio “ntpd” utiliza las  respuestas que recibe de otros servidores de una forma inteligente,  haciendo caso siempre a los más fiables.
Configuración básica
Si solamente deseamos sincronizar nuestro reloj cuando se arranca la  máquina se puede utilizar “ntpdate”. Esto puede ser adecuado en algunas  máquinas de escritorio que se reinician frecuentemente y donde la  sincronización no suele ser un objetivo prioritario pero normalmente la  mayoría de las máquinas deberían ejecutar “ntpd”.
La utilización de “ntpdate” en tiempo de arranque es también una  buena idea incluso para las máquinas que ejecutan “ntpd”. El programa  “ntpd” modifica el reloj de forma gradual, mientras que “ntpdate” ajusta  directamente el reloj sin importar que tamaño tenga la diferencia de  tiempo existente entre la máquina y el servidor de tiempo de referencia.
Para activar “ntpdate” en tiempo de arranque, hay que añadir  ntpdate_enable="YES" al fichero /etc/rc.conf. También es necesario  especificar todos los servidores que deseamos utilizar para realizar el  proceso de sincronización y cualquier parámetro que deseemos pasar al  comando “ntpdate” utilizando la variable ntpdate_flags.
Estructura de los ficheros de configuración
NTP se configura mediante el archivo /etc/ntp.conf. A continuación se  muestra un sencillo ejemplo:
server ntplocal.ejemplo.com prefer
server timeserver.ejemplo.org
server ntp2a.ejemplo.net
driftfile /var/db/ntp.drift

La opción server especifica qué servidores se van a utilizar,  especificando un servidor por línea. Si se especifica un servidor con el  argumento prefer, como en ntplocal.ejemplo.com dicho servidor se  prefiere sobre los demás. No obstante, la respuesta de su servidor  preferido se descartará si difiere sustancialmente de la respuesta  recibida por parte del resto de los servidores especificados; en caso  contrario sólo se tendrá en cuenta la respuesta del servidor preferido  sin importar la información suministrada por el resto. El argumento  prefer se utiliza normalmente en servidores NTP altamente precisos, como  aquellos que poseen hardware de tiempo específico.
La opción driftfile especifica qué fichero se utiliza para  almacenar el desplazamiento de la frecuencia de reloj de la máquina. El  servicio “ntpd” utiliza este valor para automáticamente compensar el  desvío que experimenta de forma natural el reloj de la máquina,  permitiendo mantener una precisión acotada incluso cuando se pierde la  comunicación con el resto de referencias externas.
La opción driftfile especifica qué fichero se utiliza para  almacenar la información sobre respuestas anteriores de servidores NTP.  Este fichero contiene información útil para la implementación de NTP. No  debería ser modificada por ningún otro proceso.
Control de acceso al  servidor NTP
Por defecto, nuestro servidor de NTP puede ser accedido por cualquier  máquina de Internet. La opción restrict se puede utilizar para  controlar qué máquinas pueden acceder al servicio.
Si queremos denegar el acceso a todas las máquinas existentes  basta con añadir la siguiente línea a /etc/ntp.conf:
# restrict default ignore

Si sólo queremos permitir el acceso al servicio de hora a las  máquinas de nuestra red y al menos, nos queremos asegurar de que dichos  clientes no pueden a su vez configurar la hora del servidor o utilizarse  ellos mismos como nuevos servidores de hora basta con añadir lo  siguiente en lugar de lo anterior:
# restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap

donde 192.168.1.0 será la dirección IP de nuestra red y 255.255.255.0  es la máscara de red para esa dirección de clase C.
El archivo /etc/ntp.conf puede contener varias opciones de tipo  restrict.
Para asegurarnos de que el servidor de NTP se ejecuta en tiempo  de arranque se debe añadir la línea xntpd_enable="YES" al fichero  /etc/rc.conf. Si deseamos pasar opciones adicionales al servicio “ntpd”  se puede modificar la variable xntpd_flags del fichero /etc/rc.conf.
Para ejecutar el servidor sin reiniciar la máquina habría q  ejecutar ntpd junto con todos aquellos parámetros que hayamos  especificado en la variable de arranque xntpd_flags del fichero  /etc/rc.conf. Por ejemplo:
# ntpd -p /var/run/ntpd.pid

Puesta en marcha en CÚMULO
Una vez que hemos explicado los conceptos básicos del archivo  /etc/ntp.conf, vamos a explicar cuales han sido los pasos para la  configuración de NTP en los servidores de nuestros sistemas CUMULO.
Como cualquier distribución de Linux basada en Ubuntu, todos  nuestros servidores tienen de serie activado el paquete ntpdate de  manera que en cada arranque el reloj local es sincronizado de forma  remota según lo especificado en el fichero /etc/default/ntpdate. Por  defecto esta sincronización se hace con un servidor de la casa Ubuntu,  pero nosotros lo podemos cambiar en todos nuestros servidores para  especificar que se haga con nuestro servidor local:
NTPSERVERS="ntp.cumulo.org"

Esto nos tomaría la hora de la máquina ntp.cumulo.org, pero... aún no  tenemos una máquina como esa que actúe de servidora horaria, así que  vamos a tomar la máquina equipouno como servidora horaria para nuestra  red local. Para ello, tendremos que, en primer lugar, instalarle el  software de servidor NTP:
# apt-get install ntp-server ntp-simple

Tras ello, podemos pasar a configurar el servidor del cual va a tomar  la hora neustro servidor NTP Cumulo, que no va a ser otro que el  servidor NTP hora.unileon.es del que dispone la Universidad de León.  Para configurarlo asi, únicamente tendremos que editar el fichero  /etc/ntp.conf de forma que contenga la siguiente información:
server hora.unileon.es
driftfile /var/db/ntp.drift

Esta configuración que acabamos de poner sería la apropiada para el  servidor equipouno que va a hacer de maestro NTP dentro de nuestra red.  Para el resto de los servidores, que serán esclavos de éste, la  configuración será similar. En primer lugar deberemos de instalar los  paquetes de NTPD de la misma forma que antes:
# apt-get install ntp-server ntp-simple

Y a continuación, en lugar de añadir en el fichero /etc/ntp.conf un  único servidor referenciando al servidor principal de la Universidad,  haríamos que el resto de los servidores de CUMULO tuvieran como servidor  principal de tiempos nuestra máquina local ntp.unileon.es y como  secundario el servidor de la Universidad, por si este anterior fallara:
server equipouno prefer
server hora.unileon.es
driftfile /var/db/ntp.drift

Esta última línea del archivo (driftfile /var/db/ntp.drift) que hemos  visto en los dos ficheros de configuración sirve para guardar la  implementación del sistema NTP y además, especifica que dicho archivo se  utiliza para almacenar el desplazamiento de la fracuencia de reloj de  la máquina.
Para finalizar con este apartado, podemos decir que esta  configuración que hemos adoptado como solución creemos que es la más  adecuada para el sistema, al poner de forma muy próxima (en la misma red  del laboratorio F5 de CUMULO) al servidor NTP, lo que mejora el  funcionamiento, y también lo hace independiente de que la red externa de  la universidad funcione mejor o peor. La otra opción más sencilla de  sincronizar todos los relojes con el servidor hora.unileon.es es también  posible pero ha sido desestimada de principio.
Elección de arquitectura
Para su correcto funcionamiento, cualquier sistema informático  tiene que disponer de un medio de almacenamiento del cual usuarios y  aplicaciones puedan hacer uso con fiabilidad y prestaciones adecuadas.  En nuestros ordenadores personales éste suele residir en el disco duro  de nuestra máquina local, pero en un sistema como Cúmulo esta opción no  nos era útil:

Al tratarse de un sistema distribuido, un mismo usuario debía de  entrar en él desde puestos diferentes y desde cualquiera de ellos  seguir teniendo acceso a sus datos.
No todos los clientes ligeros disponían necesariamente de disco  local.
El almacenamiento local en cada sistema dejaría esos datos  aislados del control central del sistema, con los consiguientes riesgos  que eso podría suponer para:

La privacidad de los datos, al ser susceptibles de acceso de  manera local.
La integridad, ya que podrían igualmente ser borrados o  modificados y no se dispondría de ninguna copia de ellos.
La disponibilidad de la información, ya que un error físico en  un disco local provocaría la pérdida total de la información.



Teniendo en cuenta estos condicionantes, que descartan la utilización  de sistemas de almacenamiento locales a cada usuario, parece clara la  necesidad de un sistema de almacenamiento remoto. Con esa premisa, se  buscó una solución que aprovechando los servidores ligeros de los que  disponíamos proporcionase en las mejores condiciones posibles: una buena   seguridad, alta disponibilidad e integración al máximo con el resto de  los servidores.
Como posibles soluciones se barajaron:

AFS (Andrew FileSystem), un sistema de ficheros distribuido que  permite compartir recursos de almacenamiento tanto en redes locales como  redes WAN. Si bien este sistema se presentaba como una de las opciones  más interesantes en principio, nos encontramos con serios problemas de  fiabilidad al intentar hacer funcionar el software servidor en sistemas  Linux con kernels 2.6.x, especialmente cuando como en nuestro caso  utilizábamos kernels de distribuciones parcheados. En lo referente a  clientes para el acceso a sistemas AFS, disponía de opciones con un  funcionamiento bastante aceptable como eran OpenAFS y Arla, pero el  punto negro del software servidor nos hizo desechar esta opción.
Coda, otro sistema de ficheros distribuido que ofrece  replicación de servidores, seguridad, escalabilidad, funcionamiento sin  conexión... Surgió a partir de la versión 2 de AFS, a la que se  añadieron nuevas capacidades en la Universidad de Carnegie Mellon. Es un  sistema muy potente, pero tenía una grave limitación a la hora de  trabajar con él, que era la realemente alta cantidad de recursos que  pedía para que el funcionamiento fuera medianamente adecuado. Esto nos  restringía claramente su uso, ya que todos los servidores de nuestro  proyecto son servidores ligeros y como tales no pueden aportar esta  cantidad de recursos.
NFS (Network File System), en sus versiones 2 y 3 es el sistema  de ficheros distribuido estándar de unix, y una muy buena opción que  consideramos ya que ofrecía flexibilidad suficiente para nuestras  tareas, era muy estable y suficientemente ligero para trabajar en  nuestros sistemas. Pero encontramos una opción que nos gustó más...
NFSv4 (Network File System version 4), la última revisión del  estándar NFS, que añadía a las opciones habituales de este sistema otras  influenciadas por AFS con la ventaja de que NFSv4 sí que está soportado  de forma nativa en el kernel de Linux. Además, es perfectamente  integrable con el sistema de seguridad kerberos que se ha planteado usar  en una segunda fase del proyecto Cúmulo y para el cual vamos a dejar  especificados detalles de nuestra instalación. Como puntos oscuros en  esta elección estaba el hecho de que aún no estába (ni está) totalmente  desarrollado este estándar y por ello no es tan robusto como NFS, pero a  pesar de ello sí que es una apuesta de futuro porque en algunos meses  puede convertirse en el estándar de facto.

Una vez escogido NFSv4 como método de compartir los ficheros por la  red nos planteamos el sistema de ficheros que debía de ir debajo de él, y  escogimos el estándar ext3, por sus capacidades de journaling que  minimizan los tiempos de recuperación del disco después de una caída.
También nos interesa lograr una buena disponibilidad del servicio  ante fallos. Para solucionarlo decidimos evaluar diferentes  alternativas de clustering, como puede ser el entorno completo  distribuido ofrecido por Beowulf, o el balanceo de procesos que permite  OpenMosix. Sin embargo ninguna de estas opciones era válida cuando  sabíamos que el recurso a compartir del que disponíamos era único, un  sistema de de almacenamiento del que nuestros recursos de hardware sólo  nos iba a permitir disponer en un sistema, así que optamos por un  cluster de alta disponibilidad.
Como cluster de alta disponibilidad escogimos el estándar dentro  del software libre, que es heartbeat (http://www.linux-ha.org),  que lleva ya varios años funcionando y con paulatinas mejoras que lo  han integrado en multitud de entornos.









Tras la elección de heartbeat para mejorar la disponibilidad, el  siguiente paso era determinar la forma en la cual podríamos compartir un  medio de almacenamiento único como podían ser los discos locales de  cada uno de los servidores de ficheros, entre las máquinas de ese  cluster. La mejor solución hubiera sido un array de discos externo que  pudiera ser compartido entre las máquinas, que nos permite el trabajo en  paralelo. Pero no contábamos con ninguno, así que nos planteamos otras  alternativas. La más asequible para el equipo reciclado que disponíamos  pasaba por utilizar la red como medio de replicación, y estudiando las  posibilidades estuvimos examinando el software ENBD que permite utilizar  un dispositivo remoto como si fuese un dispositivo local. Esto nos era  realmente útil, pero la solución perfecta fue el módulo DRBD, que añade a  estas posibilidades de acceso remoto a un dispositivo, la replicación  de este volumen entre diferentes máquinas, que era justo lo que  deseábamos.
Con todos estos elementos, ya teníamos el sistema prácticamente  definido, pero nos quedaba un aspecto importante por tratar, que era la  manera de trabajar con el espacio en los discos, ya que nuestros  sistemas servidores, en vez de disponer de un gran disco con mucho  almacenamiento, disponían de varios discos pequeños. Eso lo solucionamos  utilizando el clásico LVM (Logical Volume Manager) de Linux,  implementado en el kernel y que nos permite crear volúmenes de datos a  nuestro gusto juntando bloques de espacio individuales.
En el esquema intentamos resumir la arquitectura interna que va a  quedar en cada uno de los servidores de almacenamiento de acuerdo a  estas decisiones que acabamos de tomar.
Adicionalmente, tenemos que plantearnos el como situar estos dos  servidores dentro de toda la arquitectura del proyecto Cúmulo. En la  arquitectura genérica de red podemos diferenciar tres zonas:

La red de clientes ligeros
La red de servidores ligeros
Internet, a la que se lleva a través de uno de los servidores  ligeros

Habida cuenta de que el el sistema de almacenamiento no va a ser  utilizado por los clientes directamente, sino por los servidores, el  lugar adecuado para situar a las dos máquinas que nos van a hacer de  servidores de almacenamiento por NFS es en la red de servidores ligeros.  Además, como forman un cluster, habilitaremos una red particular entre  ellos para que las labores propias del cluster y replicación se realicen  a través de esta red sin influenciar en el resto de máquinas.









El resultado sería el de la figura. A partir de este diseño  procederemos a la instalación del sistema.
Instalación de NFSv4
Como primer paso para la puesta a punto de nuestro sistema de  almacenamiento en red, lo que vamos a hacer precisamente es instalar el  software servidor encargado de compartir en nuestro caso particular los  ficheros de usuario de todas las personas que utilizarán el sistema  Cúmulo.
Nosotros hemos escogido para ello NFSv4 (Network File System  version 4), un protocolo de sistema de ficheros distribuido que no es  sino una puesta al día del sistema clásico de compartición de ficheros  por red en Unix, NFS. Como características interesantes que incluye este  protocolo que no encontramos en versiones anteriores, tenemos entre  otras:

Acceso a ficheros con capacidad de bloquearles si están siendo  usados por otros procesos
Capacidad de manejo del protocolo de montado de unix
Seguridad mejorada, con capacidad de integración con sistemas  kerberos
Caché en cliente
Internacionalización

La desventaja principal que tiene es que, a fecha de este documento  (Septiembre 2005), aún se encuentra en pleno desarrollo y si bien parece  que sus especificaciones ya son estables, no es lo mismo con su  desarrollo, que va implementando los requisitos progresivamente. Hay  varias versiones en desarrollo entre las que destaca la versión libre de  la Universidad de Michigan (http://www.citi.umich.edu/projects/nfsv4/), que es  la que hemos empleado nosotros.
Para tener información amplia al respecto del protocolo se puede  consultar el documento RFC 3530 (http://www.ietf.org/rfc/rfc3530.txt) en el que se  describe con detalle el protocolo.
Para la instalación de este software en nuestra plataforma Cúmulo  nosotros hemos empleado un método totalmente manual, compilando  paquetes, instalando sobre ellos parches de desarrollo y haciendo su  configuración e integración con el sistema por nuestra cuenta, que es el  proceso que vamos a describir en el apartado “Instalación manual”.
Sin embargo, a fecha de redacción de este documento han aparecido  ya los primeros paquetes, todavía no oficiales, que empiezan a incluir  el soporte para NFSv4, por lo cual hemos añadido un nuevo subapartado  “Instalación por medio de paquetes” que se basa en el HowTo de NFSv4 (https://wiki.ubuntu.com/NFSv4Howto) y que indica como  se podría realizar la instalación de una manera mucho más automatizada.
Instalación manual
Compilación e instalación de un kernel preparado para NFS4.
Lo primero que hemos de hacer antes de empezar a trabajar en la  instalación de NFSv4 es asegurarnos de que tenemos un Linux con un  kernel que soporte NFSv4 en todas las máquinas que vayan a hacer uso de  NFSv4, es decir, tanto los dos servidores, como el resto de las máquinas  que van a montar directorios por la red.
Todos los kernels recientes, de la rama 2.6, ya incluyen de serie  soporte para él, pero sus funcionalidades no están totalmente  actualizadas, por lo que nosotros hemos utilizado para solventar el  problema los últimos parches disponibles en http://www.citi.umich.edu/projects/nfsv4/linux/kernel-patches.  Por lo tanto, los pasos que hemos realizado para tener un kernel  adecuado disponible han sido:

Instalar el código fuente de versión del kernel que utilicemos.  Para hacerlo, en primer lugar deberemos de saber la versión que usamos,  tecleando:

root@equipodiez:~ # uname -a
Linux equipodiez 2.6.10-5-386 #1 Tue Apr 5 12:12:40 UTC 2005 i686 GNU/Linux

Por ejemplo, en este caso vemos que la versión es la 2.6.10-5-386,  así que tendríamos que instalar el kernel de la versión 2.6.10. lo que  hacemos tecleando:
root@equipodiez:~ # apt-get install linux-source-2.6.10

El código fuente del kernel irá al directorio  /usr/src/linux-source-2.6.10.tar.bz2. Lo descomprimiremos tecleando:
root@equipodiez:~ # cd /usr/src
root@equipodiez:/usr/src # tar jxvf linux-source-2.6.10.tar.bz2

Ahora ya tenemos nuestro kernel en el directorio linux-source-2.6.10.

Instalar los parches de NFSv4 actualizados para nuestro sistema.  Para ello en primer lugar deberemos de localizarlos en la URL http://www.citi.umich.edu/projects/nfsv4/linux/kernel-patches/,  y una vez que lozalicemos el directorio con la última revisión de  nuestro kernel, bajar el fichero *ALL.dif, lo que podemos hacer  fácilmente tecleando:

root@equipodiez:/usr/src # wget http://www.citi.umich.edu/projects/nfsv4/linux/kernel-patches/2.6.10-2/linux-2.6.10-01-NFS_ALL-2.dif

Y una vez que tengamos ya bajados los parches podemos proceder a  parchear el kernel,
root@equipodiez:/usr/src # cd linux-source-2.6.10
root@equipodiez:/usr/src/linux-source-2.6.10 # patch -p1 < ../linux-2.6.10-CITI_NFS4_ALL-2.dif

Tras teclear esto ya tendremos nuestro kernel parcheado.

Compilar nuestro kernel con las opciones adecuadas. Para ello,  sabiendo la versión del kernel que estamos corriendo en nuestra máquina  (lo que hemos visto hace dos pasos), copiamos su fichero de  configuración al directorio del kernel con el que estamos trabajando:

root@equipodiez:/usr/src/linux-source-2.6.10 # cp /boot/config-2.6.10-5-386 .config

A continuación, por si la configuración en este fichero contuviera  alguna inconsistencia, lo solucionamos tecleando:
root@equipodiez:/usr/src/linux-source-2.6.10 # make oldconfig

Y ahora ya podemos comenzar a elegir las opciones de compilación del  kernel tecleando:
root@equipodiez:/usr/src/linux-source-2.6.10 # make menuconfig

Así entraremos en la aplicación encargada de seleccionar las opciones  del kernel que deseamos. Allí deberemos de escoger como mínimo las  siguientes:

Code maturity options->Prompt for development and/or  incomplete code/drivers
File systems->Network File Systems->NFS file system  support
File systems->Network File Systems->Provide NFSv3 client  support
File systems->Network File Systems->Provide NFSv4 client  support
File systems->Network File Systems->NFS server support
File systems->Network File Systems->Provide NFSv3 server  support
File systems->Network File Systems->Provide NFSv4 server  support
File systems->Network File Systems->Provide NFS server  over TCP support
Cryptographic options->Cryptographic API
Cryptographic options->MD5 digest algorithm
Cryptographic options->DES and Triple DES EDE cipher  algorithms
File systems->Ext3 extended attributes
File systems->Ext3 POSIX Access Control List










De esta manera el sistema que compilemos estará listo para trabajar  con NFSv4, así como para usar los atributos extendidos y ACLs de este  sistema de ficheros (siempre y cuando existieran en el sistema de  ficheros original, claro).
Antes de proceder a compilar el kernel vamos a realizar una copia  de la versión anterior por si acaso la que compilásemos presentase  algún problema de estabilidad:
root@equipodiez:/usr/src/linux-source-2.6.10 # cp /boot/vmlinuz-2.6.10-5-386 /boot/vmlinuz-estable
root@equipodiez:/usr/src/linux-source-2.6.10 # cp /boot/initrd.img-2.6.10-5-386 /boot/initrd-estable

Tras ello, ya podemos compilar este nuevo kernel, tecleando:
root@equipodiez:/usr/src/linux-source-2.6.10 # make

Y finalmente lo instalaremos, tecleando:
root@equipodiez:/usr/src/linux-source-2.6.10 # make modules_install

Ahora ya tenemos los ficheros correspondientes a este nuevo kernel,  que tendrán como sufijo CITI_NFS4_ALL-2 en el directorio /boot. Para que  el sistema arranque desde ellos nos hemos de asegurar que el gestor de  arranque los va a reconocer correctamente, y que también podremos  arrancar si queremos del kernel anterior. Todo esto lo hacemos cambiando  el fichero de configuración del GRUB:
root@equipodiez:/usr/src/linux-source-2.6.10 # vi /boot/grub/menu.lst

Y le añadiremos las siguientes líneas, justo antes de la primera  línea que pudiese anteriormente title algo parecido a esto:
title linux-CITI_NFS4_ALL-2
root (hd0,0)
kernel /boot/vmlinuz-CITI_NFS4_ALL-2 root=/dev/sda1

title linux-estable
root (hd0,0)
kernel /boot/vmlinuz-estable root=/dev/sda1

Los nombres de los dispositivos root en nuestro sistema han sido  estos que ponemos aquí, pero pueden variar para cada uno. Simplemente lo  que habrá que hacer será copiar una entrada de las que existan  anteriormente y cambiarle los títulos y el nombre de los ficheros  conteniendo el kernel por los que sean más adecuados.
Tras esto, ya podemos reiniciar el sistema en cuestión y al  rearrancar dispondrá de un nuevo kernel con soporte para NFSv4.
Parcheado, compilación e instalación de librerías, demonios y  utilidades NFS4.
Una vez con el kernel apropiado listo, el siguiente paso hacia la  puesta en marcha de un sistema NFSv4 va a pasar por tener, a nivel de  aplicación, todos los componentes necesarios en su lugar  correspondiente.
Vamos a ir detallando uno a uno los pasos para llegar a ello.  Excepto si se especifica lo contrario, cada uno de estos pasos hay que  realizarlo en todos los servidores que vayan a hacer uso de NFSv4, tanto  clientes como servidores de este servicio:

Vamos a tener que compilar la mayor parte de las aplicaciones, y  algunas de estas compilaciones dependen de elementos externos, por  ejemplo, de las librerías y cabeceras de las que hace uso OpenLDAP.  Afortunadamente, Ubuntu ya dispone de un paquete con estos ficheros, así  que procederemos a instalarlo tecleando:

apt-get install libldap2-dev


Lo siguiente que vamos a instalar es la librería libnfsidmap,  que se va a encargar de establecer la correspondencia entre nombre de  usuario e id de usuario que le corresponde en los sistemas de ficheros  que hagan uso de NFSv4. Para ello lo primero que haremos será  descargarnos el código fuente de estas librerías desde los servidores de  la Universidad de Michigan:

# wget 	http://www.citi.umich.edu/projects/nfsv4/linux/libnfsidmap/nfsidmap-0.10.tar.gz

Una vez que tenemos el fichero lo descomprimiremos:
# tar zxvf nfsidmap-0.10.tar.gz

Y tras ello procederemos a su compilación e instalación:
# cd nfsidmap-0.10
# ./configure && make && make install

Y para acabar con la configuración, deberemos de crear un fichero  /etc/idmapd.conf donde especificar la manera en la que deseamos que se  realice esta traducción. En él hemos de especificar el método empleado  para la traducción de usuario a id. Hay dos posibles:

nsswitch, que utiliza para establecer esta relación lo que tenga  el sistema reflejado en su fichero /etc/nsswitch.conf para el sistema.  En nuestro caso este hace alusion al Es el método por defecto, que en la  práctica está haciendo uso de los perfiles de usuario en el LDAP  central del sistema.
umich_ldap, que está en fase experimental, y se basa en  consultas al servidor LDAP, en el cual se debe de haber creado un  esquema específico (http://www.citi.umich.edu/projects/nfsv4/crossrealm/libnfsidmap_config.html)  que va a ser utilizado para estas entradas.

Aparte de esta información, el fichero de configuración también  especifica...

Que información se va a guardar en el fichero de log
El directorio de nuestro sistema donde va a estar montado el  sistema de ficheros virtual del que hace uso NFSv4 (que por defecto será  /var/lib/nfs/rpc_pipefs)
El dominio kerberos en el que va a trabajar NFSv4. Nuestro  sistema aún no contempla esta situación, pero en un futuro podría usar  un dominio kerberos CUMULO.ORG
Por cuestiones de seguridad, a que usuario y grupo deseamos que  mapee el sistema los ficheros que originalmente tengan como propietario  el usuario oo grupo root. Nosotros hemos escogido el usuario nobody y  el grupo nogroup.

Al final el resultado va a ser que tendremos que teclear un fichero  /etc/idmapd.conf con el siguiente contenido:
[General]
Verbosity = 99
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = CUMULO.ORG
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup
[Translation]
Method = nsswitch


Vamos a pasar a continuación a la instalación de más librerías  necesarias para las próximas compilaciones que vamos a realizar. En este  caso, las librerías y cabeceras de libevent y MIT kerberos (ya que,  como hemos dicho, dejaremos preparado el sistema para interactuar con  este protocolo) que instalaremos tecleando:

# apt-get install libevent-dev libkrb53 libkrb5-dev


A continuación vamos a pasar a instalar y compilar las librerías  libgssapi, realizadas por el equipo de desarrollo de NFSv4 de la  Universidad de Michigan. Para ello en primer lugar descargaremos el  fichero tar:

# wget http://www.citi.umich.edu/projects/nfsv4/linux/libgssapi/libgssapi-0.4.tar.gz

Y procederemos a descomprimirlo y compilarlo:
# tar zxvf libgssapi-0.4.tar.gz
# cd libgssapi-0.4
# ./configure && make && make install


Análogamente a lo anterior, instalaremos la librerías RPCSECGSS,  primero descargándolas:

# wget http://www.citi.umich.edu/projects/nfsv4/linux/librpcsecgss/librpcsecgss-0.6.tar.gz

Y a continuación descomprimiéndolas y compilándolas:
# tar zxvf librpcsecgss-0.6.tar.gz
# cd librpcsecgss-0.6
# ./configure && make && make install


Ahora vamos a proceder a instalar varias las utilidades de  servidor nfs-utils, actualizadas para trabajar con NFSv4, aunque para  ello necesitarán de un parcheo. Al ser utilidades de servidor,  únicamente necesitamos instalarlas en las máquinas que vayan a funcionar  como servidores NFS, que en nuestro caso son equipodiez y equiposiete.

En primer lugar descargarmos su código fuente:
# wget http://prdownloads.sourceforge.net/nfs/nfs-utils-1.0.7.tar.gz?download

También descargamos los partes de la Universidad de Michingan para  ellas:
# wget http://www.citi.umich.edu/projects/nfsv4/linux/nfs-utils-patches/1.0.7-3/nfs-utils-1.0.7-CITI_NFS4_ALL-3.dif

Y procedemos a descompriir las utilidades, aplicarles el parcheo  adecuado, compilarlas e instalarlas:
# tar zxvf nfs-utils-1.0.7.tar.gz
# cd nfs-utils-1.0.7
# patch -p1 < ../nfs-utils-1.0.7-CITI_NFS4_ALL-3.dif
# ./configure && make && make install

Esto nos instalará entre otros los demonios mountd, idmapd, exportfs,  rpc.gssd y rpc.svcgssd, imprescindibles para poner el sistema a  funcionar como servidor.

Vamos a hacer ahora la instalación de las utilildades de usuario  util-linux que también debemos de tener actualizadas para trabajar con  nuestro sistema NFSv4. Primero descargamos el fichero tar con el código  fuente, así como los parches para él:

# wget http://www.citi.umich.edu/projects/nfsv4/linux/util-linux-tarballs/util-linux-2.12.tar.gz
# wget http://www.citi.umich.edu/projects/nfsv4/linux/util-linux-patches/2.12-3/util-linux-2.12-CITI_NFS4_ALL-3.dif

Y a continuación, descomprimimos, parcheamos, compilamos e  instalamos:
# tar zxvf util-linux-2.12.tar.gz
# cd util-linux-2.12
# patch -p1 < ../util-linux-2.12-CITI_NFS4_ALL-3.dif
# ./configure && make && make install

Este último comando nos instalará entre otras la utilidad de montaje  de sistemas de ficheros mount válida para poder montar sistemas NFSv4  con todas sus posibilidades

Ahora, deberemos de crear un fichero /etc/gssapi_mech.conf que  nos sirva para especificar que mecanismos de autenticación va a usar el  demonio gssd. Para ello, en condiciones normales, nos basta con entrar  en el directorio nfs-utils-1.0.7 que hemos descomprimido antes y copiar  desde allí el fichero support/gssapi/SAMPLE_gssapi_mech.conf:

# cd nfs-utils-1.0.7
# cp support/gssapi/SAMPLE_gssapi_mech.conf /etc/gssapi_mech.conf

Por si acaso tuviéramos algún problema en localizar este fichero,  reproducimos su contenido típico si quisiésemos hacer la autenticación  mediante el mecanismo proporcionado por MIT Kerberos 5:
# GSSAPI Mechanism Definitions
#
# library                               	initialization function
# ================================
/usr/lib/libgssapi_krb5.so     	mechglue_internal_krb5_init
# Other possible options:
# /usr/local/lib/libgssapi.so   	mechglue_internal_krb5_init
# /usr/local/gss_mechs/spkm/spkm3/libgssapi_spkm3.so    spkm3_gss_initialize

Configuración de Kerberos 5 para NFSv4.
En este apartado vamos a indicar las acciones que deberíamos de hacer  para integrar NFSv4 con Kerberos en una segunda fase del proyecto, que  se prevee a medio plazo. En la actualidad no tendremos que realizar  ninguna de las tareas de este apartado, pero merece la pena detallarlas  para facilitar esta labor en un futuro.
Para una buena integración NFSv4 - Kerberos, lo único que nos  requerirá NFSv4 es que cada una de las máquinas que haga tanto de  servidora como de cliente tenga un principal creado para ella del tipo  nfs/nombre_de_la_maquina@CUMULO.ORG. Este principal será el que sirva  para autentificar a la máquina cuando se monte un sistema de ficheros  por NFSv4. Como nosotros querremos que en ese momento la autentificación  sea automática (es decir, no requiera que se introduzca ninguna  contraseña manualmente), además deberemos de preocuparnos que la clave  para este principal esté dentro de la tabla de claves (keytab) de esa  máquina.
El proceso para realizar esto en las máquinas de Cúmulo variará  según el tipo de máquina que sea:

En los servidores NFSv4, se creará un principal y se hará que  tengan credencial de la dirección IP de alta disponibilidad del cluster.  En este caso, vamos a tener procedimientos diferentes según  introduzcamos las credenciales en el primero de los servidores del  cluster o el resto de ellos. Lo explicaremos más adelante.
En cada uno de los clientes NFSv4, para que tengan la  credencial referente a su propia IP

El proceso que tenemos que realizar para poner en marcha todo esto es  el siguiente:

Antes de crear ningún principal hemos de saber el nombre DNS  completo de la máquina de la cual queremos crear el principal, pues éste  va a ser el que tendremos que usar en kerberos. Para ello, conociendo  la IP que tiene la máquina, usaremos el comando nslookup y la  obtendremos. Por ejemplo, para el caso de querer saber el nombre DNS de  la IP es 192.168.2.12 (que en nuestro sistema es la de alta  disponibilidad del cluster), teclearíamos:

root@equipodiez:~ # nslookup 192.168.2.12
Server:         192.168.2.5
Address:        192.168.2.5#53

12.2.168.192.in-addr.arpa       name = nfs.cumulo.org.

Como podemos ver, hemos obtenido el dato que necesitábamos. A esta  dirección le corresponde el nombre DNS nfs.cumulo.org.

Otro dato que es interesante conocer antes de empezar es el  realm que utiliza nuestro servidor kerberos. En nuestro caso, ya sabemos  que es CUMULO.ORG (el nombre de un realm por convención se utiliza  siempre en mayúsculas). Si tuviésemos alguna duda, podríamos consultarlo  examinando el fichero /etc/krb5.conf y viendo que tenemos escrito en la  sección [realms].
Para proceder a crear el principal en kerberos, antes de nada  tendremos que autenticarnos como administrador de kerberos. El  administrador estándar en cualquier sistema suele ser admin/admin si  bien podría ser cualquier otro que nosotros hubiésemos creado siempre y  cuando su instancia fuese /admin. Por ejemplo, la autenticación con el  administrador en nuestro sistema podría realizarse así:

root@equipodiez:/etc/init.d # kinit admin/admin
Password for admin/admin@CUMULO.ORG:


Una vez autenticados ya podríamos ponernos a crear las  credenciales que necesitamos, a través del comando kadmin. Para ello en  primer lugar ejecutamos el comando kadmin y obtenemos su prompt:

# kadmin
kadmin:

Ahora vamos a generar el principal para la dirección IP que nos  interese. Lo haremos con el comando addprinc, poniendo como parámetro  -randkey para que el sistema nos genere la clave al azar, y añadiendo a  continuación el nombre del principal que deseamos que será  nfs/nombre_dns_de_la_maquina. Es decir, por ejemplo para la máquina  nfs.cumulo.org sería teclear...
kadmin:  addprinc -randkey nfs/nfs.cumulo.org
WARNING: no policy specified for nfs/nfs.cumulo.org@CUMULO.ORG; defaulting to no policy
Principal "nfs/nfs.cumulo.org@CUMULO.ORG" created.
kadmin:

Con esto ya tenemos creado el principal y hemos vuelto al prompt de  kadmin, desde donde vamos a poder añadir este nuevo principal a la tabla  de claves de la máquina para que de esta manera al montar NFSv4 se  realice la autenticación de forma automática sin nuestra intervención.  Para ello usaremos el comando ktadd especificando que queremos guardar  esta llave con el tipo de encriptación des-cbc-crc, que es el único que  por ahora aceptan los kernels de NFSv4. También pondremos como parámetro  el nombre del fichero de claves /etc/krb5.keytab que vamos a utilizar,  así como el principal que vamos a pasar allí. Lo hacemos tecleando lo  siguiente:
kadmin:  ktadd -e des-cbc-crc:normal -k /etc/krb5.keytab nfs/nfs.cumulo.org
Entry for principal nfs/nfs.cumulo.org with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.
kadmin:

Con esto ya habremos terminado y podemos salir del interfaz  tecleando...
kadmin: exit
#

Con este paso, ya hemos terminado el proceso a realizar en la mayoría  de las máquinas. Pero, si recordamos, habíamos comentado que en las  máquinas servidoras el proceso no era exactamente igual en todas. ¿Y  como sería entonces? Pues cuando creemos el principal en la primera (da  igual una que otra) de las máquinas que componen el cluster NFS, sí que  seguiremos el proceso indicado, pero con la segunda (o el resto de ellas  si hubiera más) tendremos que hacer una copia manual de la tabla de  claves.
Es decir, una vez que hayamos finalizado el proceso en la primera  de las máquinas del cluster NFSv4, tendremos que tomar el fichero  /etc/krb5.keytab y copiarle directamente a la otra máquina con ese mismo  nombre y en ese mismo directorio, por ejemplo tecleando:
root@equipodiez:~ # scp -p /etc/krb5.keytab equiposiete:/etc/krb5.keytab

Esto lo tenemos que hacer así para que la clave que hemos generado  sea la misma en las dos, ya que si prosiguiésemos con el mismo proceso  estaríamos generando una clave diferente para la IP del cluster en cada  servidor, con lo cual sólo el que hubiese sido dado de alta el último  sería considerado como válido por el servidor de Kerberos.
Y aquí finalizan los pasos para la integración NFSv4-Kerberos, si  bien vamos a recordar un par de detalles que son importantes para que  todo funcione correctamente por si se efectúa esta tarea en otros  sistemas:

Kerberos funciona a través de un sistema de expedición de  tickets a los que da una validez temporal limitada para mejorar su  seguridad. Si los relojes de las máquinas NFSv4 están desincronizados  entre sí, podríamos tener probelmas de funcionamiento. Por ello se  aconseja tener instalado y en funcionamiento el servicio de ntp en estos  servidores.
Para que todo funcione es también importante que si tenemos  definida la dirección IP del servicio NFSv4 en el fichero /etc/hosts de  cualquiera de estas máquinas, el primer nombre de máquina que se  establezca para esta IP sea el nombre DNS completo, el mismo que hemos  visto antes a través del comando nslookup.

Configuración de  demonios NFSv4.
Ahora ya tenemos los binarios necesario para el funcionamiento de  NFSv4 en su sitio, pero hace falta crear los ficheros de configuración, y  hacer varios cambios en el sistema necesarios para su funcionamiento  correcto. Eso es lo que vamos a tratar en este apartado.
Vamos a ir enumerando las operaciones que tenemos que realizar.  Algunas serán tanto para máquinas servidoras como para máquinas  clientes, mientras que otras se tendrán que realizar exclusivamente en  las máquinas que actúan de servidoras:

SERVIDORES Y CLIENTES: Debemos de crear algunos directotios que  van a ser necesarios para que NFSv4 trabaje con ellos, como son  /var/lib/nfs/v4recovery/ y /var/lib/nfs/rpc_pipefs. Para ello vamos a  utilizar el flag -p que nos crea los subdirectorios anteriores de la  estructura si no existieran:

# mkdir -p /var/lib/nfs/v4recovery
# mkdir -p /var/lib/nfs/rpc_pipefs


SERVIDORES Y CLIENTES: NFSv4 hace uso de dos sistemas de  ficheros virtuales, nfsd y rpc_pipefs, en su funcionamiento. El kernel  ya tiene soporte para ellos, pero tendremos que encargarnos de  especificarle al sistema de que manera se han de montar. Para ello lo  haremos editando el fichero /etc/fstab y añadiéndole estas líneas:

rpc_pipefs     	 /var/lib/nfs/rpc_pipefs    rpc_pipefs   defaults,noauto        0       0
nfsd 			/proc/fs/nfsd               	  nfsd            defaults,noauto        0       0

Más tarde, cuando tratemos sobre la alta disponibilidad del servicio,  explicaremos por que le añadimos a las particiones el flag noauto.

SERVIDORES Y CLIENTES: A continuación, montaremos estos dos  sistemas para verificar que no hay errores, tecleando:

# mount rpc_pipefs
# mount nfsd


SERVIDORES: Tendremos que escoger el directorio donde vamos a  tener los ficheros que compartimos por NFS. El más estándar, y que  nosotros hemos elegido para usar en nuestro caso, es el /export. Así que  debemos de crearlo y darle todos los permisos para que después no  tengamos problemas al compartirlo (las restricciones ya las haremos con  los permisos que tengan ficheros y directorios en su interior):

# mkdir /export
# chmod a+rwxt /export

Una vez tenemos el directorio, también tendremos que asegurarnos que  en la tabla de particiones, vamos a montar el sistema de ficheros en el  que esté /export con ACLs, para poder dar soporte a ellas en NFSv4. Sin  embargo, no vamos a preocuparnos de ello por ahora, ya que será más  tarde cuando creemos el dispositivo que vamos a montar aquí.

Lo siguiente que vamos a hacer va a ser preparar los scripts de  arranque de NFSv4, que deberán de encargarse de arrancar...
En máquinas servidor los demonios rpc.mountd, rpc.idmapd,  rpc.svcgssd y rpc.nfsd
En máquinas tanto servidor como cliente los servicios rpc.gssd y  rpc.idmapd

Para hacerlo de forma correcta y ordenada, vamos a emplear para ello  los scripts de arranque de ejemplo incluidos en el paquete nfs-utils con  el que hemos tratado anteriormente. En las máquinas CLIENTES únicamente  tendremos que copiar el script nfs-common al directorio /etc/init.d,  mientras que SERVIDORES copiaremos además el script nfs-kernel-server:
# cp -p nfs-utils-1.0.7/debian/nfs-common.init /etc/init.d/nfs-common
# cp -p nfs-utils-1.0.7/debian/nfs-kernel-server.init /etc/init.d/nfs-kernel-server

Tras la copia, vamos a hacer un pequeño retoque en los dos ficheros  de inicio para adecuarlo a nuestras necesidades. Simplemente va a ser  cambiar el valor de la variable RPCGSSDOPTS en los dos para confirmarle  que la keytab que tiene que emplear es la de defecto del sistema:
RPCGSSDOPTS="-k /etc/krb5.keytab"


SERVIDORES Y CLIENTES: También vamos a necesitar que se estén  cargados algunos módulos del kernel para que NFSv4 arranque  correctamente. Para que esta tarea se produzca de manera automática, lo  haremos añadiendo el siguiente contenido al final del fichero  /etc/modules:

# NFSv4 kernel modules
sunrpc
nfs
rpcsec_gss_krb5


SERVIDORES: Ya tenemos los preparativos preliminares de NFSv4  casi a punto, pero nos queda la parte fundamental, que es definir que es  lo que nosotros queremos compartir (directorio o directorios) y cómo  queremos compartirlo (si lo queremos compartir libremente o autenticando  de alguna manera). Las opciones posibles para a la hora de la  autenticación son:


 * para indicar acceso sin autenticación Kerberos (aunque sí que  puede hacerse por IP)
krb5 para indicar Kerberos 5
krb5i para indicar Kerberos 5 con control adicional de  integridad
krb5p para indicar Kerberos 5 con control adicional de  privacidad

Todo esto lo hemos de indicar en el fichero /etc/exports. Por  ejemplo, si hubiésemos elegido como opción  compartir los contenidos de  /export a través de Kerberos 5, lo que contendría el fichero sería:
/export  gss/krb5(rw,fsid=0,insecure,no_subtree_check)

En nuestro caso concreto, como vamos a compartir el directorio  /export pero de forma “plana” de momento, escribiremos lo siguiente:
/export  *

Tras teclear esto, para que el servidor relea la configuración y  proceda a exportar lo que le acabamos de indicar, nos bastará con  teclear el comando:
# exportfs -r

Uso de ACLs.
Ya tenemos en funcionamiento un sistema NFSv4 estándar. No obstante,  nosotros hemos optado por añadirle soporte para listas de acceso (ACLs),  que permiten mejorar el control sobre los permisos de los ficheros para  cada usuario.
Para ponerlo a funcionar, antes de nada necesitamos tener las  utilidades para trabajar con las ACLs en nuestro servidor, que lo que  hacen en realidad es realizar una traducción de las ACLs que nos ofrece  NFSv4 a las ACLs Posix con las que trabaja habitualmente nuestro sistema  unix. Las conseguiremos en el directorio acl-tarballs (http://www.citi.umich.edu/projects/nfsv4/linux/acl-tarballs/)  de la web de la Universidad de Michigan. Concretamente, la última  versión la descargaríamos así:
# wget http://www.citi.umich.edu/projects/nfsv4/linux/acl-tarballs/acl_2.2.29-1.tar.gz

También vamos a descargar los últimos parches de los desarrolladores  de NFSv4 para este código:
# wget http://www.citi.umich.edu/projects/nfsv4/linux/acl-patches/2.2.29-2/acl-2.2.29-CITI_NFS4_ALL-2.dif

Con los dos ficheros, ya podemos proceder a la descompresión,  compilado e instalación de estas utilidades siguiendo los pasos  habituales:
# tar zxvf acl_2.2.29-1.tar.gz
# cd acl_2.2.29-1
# patch -p1 < ../acl-2.2.29-CITI_NFS4_ALL-2.dif
# ./configure && make && make install && make install-lib

Tras esto ya podemos empezar a trabajar con listas de acceso sobre  NFSv4... siempre y cuando el sistema de ficheros sobre el que esté  montado el directorio compartido en el servidor (en nuestro caso /export  en equipodiez) esté sobre un sistema de ficheros como ext3 que lo  soporte y además este sistema de ficheros esté montado con la opción  acl.
Si hemos seguido los pasos tal cual hasta ahora, es probable que  no tuviéramos el directorio /export montado con ACLs, por lo que no  podremos acceder a estas posibilidades, pero no obstante, si seguimos  los pasos de instalación, un poco más adelante sí que vamos a poder  hacerlo.
Mientras, como ejemplo, mostramos un comando que valdría para  leer las ACLs de un fichero en un directorio montado por NFSv4:
# getfacl /mnt/prueba/FICHERO

...y también el comando para modificar esta ACL a nuestro gusto:
# setfacl -m u:usuario2:rwx /mnt/prueba/FICHERO

Instalación por  medio de paquetes
Para la puesta en marcha del proyecto Cúmulo, nosotros hemos empleado  el procedimiento indicado en el subapartado de “Instalación manual”, el  cual conlleva un montón de tareas y tiempo de espera.
Sin embargo, a fecha de acabar la documentación han aparecido ya  los primeros paquetes .eb (https://wiki.ubuntu.com/NFSv4) en fase beta así como  las instrucciones para poder incluir soporte NFSv4 en una distribución  Debian/Ubuntu en base a ellos (https://wiki.ubuntu.com/NFSv4Howto). Por ello,  nosotros hemos querido incluir en esta documentación un apartado  dedicado a este procedimiento más automatizado, que tiene todas las  posibilidades de pasar a ser el estándar en cuanto se estabilicen los  paquetes NFSv4.
Instalación
Los paquetes de NFSv4 aún no están incluidas en ninguna distribución  oficial de Debian, ni Ubuntu, por lo cual vamos a tener que capturarlos  de un repositorio extraoficial. En nuestro caso, para NFSv4 podemos  encontrar los paquetes en el FTP de la Universidad de Salamanca. Así que  vamos a añadirle al repositorio, editando el fichero  /etc/apt/sources.list y añadiendo la siguiente línea:
deb ftp://ftp.upsa.es/Software/debian/ubuntu/nfsv4/ ./

Tras ello ya podremos instalar el paquete estándar de soporte de  NFSv4 (con las utilidades de cliente) tecleando:
# apt-get install nfs-common

Y de la misma manera el paquete con la parte de soporte servidor de  NFSv4;
# apt-get install nfs-kernel-server

Configurando Kerberos.
En este apartado, igual que hicimos anteriormente, vamos a  especificar la configuración que habría que hacer para integrar NFSv4  para que interactúe con Kerberos. Esto implicaría que tuviésemos un KDC  (Key Distribution Center) funcionando en la red, y en nuestras máquinas  NFSv4 (tanto clientes como servidoras) al menos la parte de cliente de  red. Si no la tuviéramos, en Ubuntu necesitaríamos instalar los paquetes  oficiales krb5-user y llibpam-krb5. Vamos a especificar en este paso a  continuación los pasos que habría que realizar sólo en caso de uso de  Kerberos.
Una vez con la instalación estándar funcionando, conviene  especificar en todas las máquinas NFSv4 el sistema de encriptación  des-cbc-crc (que es el único que actualmente soporta NFSv4) en el  fichero de configuración de kerberos /etc/krb5.conf añadiendo lo  siguiente:
[libdefaults]
	default_tgs_enctypes = des-cbc-crc
       default_tkt_enctypes = des-cbc-crc

Otro paso más a realizar en servidores y clientes NFSv4, es añadir el  módulo de gss al fichero /etc/modules para que lo cargue siempre al  arrancar. Para ello no hay más que añadirle ésta línea a ese fichero:
rpcsec_gss_krb5

Tras ello, hemos de crear las credenciales de los servidores y  clientes NFSv4, lo que vamos a hacer siguiendo exactamente los mismos  pasos que indicamos en el apartado “Configuración de Kerberos 5 para  NFSv4” del punto anterior, ya que ese paso no varía en nada.
Modificaciones en los ficheros de configuración.
Vamos a finalizar la puesta a punto de NFSv4, creando/modificando  algunos ficheros de configuración para adecuarlos a nuestras  necesidades.
Concretamente, vamos a modificar:

/etc/default/nfs-kernel-server en SERVIDORES, para añadirle la  siguiente variable con éste valor:

NEED_SVCGSSD=yes


/etc/default/nfs-common, en CLIENTES y SERVIDORES, en los que  tendremos que establecer:

NEED_IDMAPD=yes
NEED_GSSD=yes


/etc/exports, que indica que compartimos por NFS en los  SERVIDORES, para que contenga:

/export  *

O bien, si usásemos Kerberos:
/export  gss/krb5(rw,fsid=0,insecure,no_subtree_check)

Y tras ello haremos que el software relea su contenido tecleando el  comando:
# exportfs -v

Tras esto podemos hacer las comprobaciones de que el sistema está  funcionando adecuadamente siguiendo las “Pruebas de funcionamiento” que  indica el apartado anterior.
Redundancia en los discos
De  particiones a volúmenes lógicos
La manera más habitual de usar los discos en cualquier sistema unix  se basa en realizar en primer lugar las particiones que deseemos en sus  discos y, una vez formateados, montarles en sus respectivos puntos.
En nuestro caso este era el espacio del que disponíamos  inicialmente para particionar en los dos servidores NFS:
equipodiez

/dev/sda: Nada
/dev/sdb: 16 Gb.
/dev/sdc: 18 Gb. (completo)

equiposiete

/dev/sda: 8 Gb.
/dev/sdb: 18 Gb. (completo)
/dev/sdc: 4 Gb. (completo, pero presenta errores)

El problema que presenta esta configuración de discos es claramente  la fragmentación del espacio, que nos obligaría a usar cada bloque libre  como un espacio de almacenamiento independiente dedicado en exclusiva a  un uso específico, con la consecuente inflexibilidad y  desaprovechamiento de recursos a la que esto aboca. Además el problema  aumentaría con el hecho de que queremos replicar el almacenamiento entre  los servidores, lo que exige tener volúmenes iguales en una y otra  máquina.
La solución para este asunto ha consistido en el uso del LVM2 (http://sources.redhat.com/lvm2/) (Logical Volume  Manager) para poner en marcha volúmenes lógicos de datos que permiten  agrupar las distintas particiones según nuestros requerimientos. Además,  los volúmenes lógicos añaden a esa capacidad la de ser capaces de  extender el tamaño de los volúmenes con nuevos discos/particiones sin  perder la información anterior, lo que facilita tremendamente la  escalabilidad del sistema.
Antes de continuar con la explicación de la manera en la que  hemos puesto a funcionar estos volúmenes vamos a dar una breve  definición de tres términos que vamos a utilizar repetidamente en el  trabajo con volúmenes lógicos:
Volumen físico (PV - Physical Volume)
Es cada uno de los "cachos" que vamos juntando para obtener el  almacenamiento que deseamos. Normalmente es una partición o un disco  duro, aunque también puede ser cualquier dispositivo que tenga ese mismo  aspecto (como por ejemplo un dispositvo de raid por software).
Grupo de volúmenes (VG - Volume Group)
Se define como el nivel de abstracción más alto dentro del LVM.Se  encarga de unir entre sí lo que son una colección de volúemes lógicos y  físicos en una unidad administrativa única. Podría verse que es el  equivalente a un disco duro en el mundo de los volúmenes.
Volumen lógico (LV - Logical Volume)
El equivalente a una partición en el mundo de los volúmenes. El  volumen lógico es visible por el sistema operativo como un dispositivo  de bloques estándar, y como tal sirve para albergar un sistema de  ficheros (como podría ser /home o /usr).
Este pequeño esquema, obtenido del LVM HOWTO (http://www.tldp.org/HOWTO/LVM-HOWTO/), puede servir  para hacernos una idea de esta organizacion:
 hda1   hdc1  	     (PVs: en particiones o discos completos)
   \     /
    \   /
    diskvg           (VG)
  /    |    \
 /     |     \
usrlv rootlv varlv   (LVs:)
|      |       |
ext2 reiserfs xfs    (sistemas de ficheros)

Para nuestros servidor de almacenamiento nuestra decisión ha sido  crear para cada disco un sólo grupo de volúmenes datos con todo el  espacio disponible en los discos que funcionan correctamente, y a su vez  dividir éste en en dos volúmenes lógicos de tamaños exactamente iguales  en los dos sistemas:

cluster, de un tamaño de 200 Mb., y que cobijará en su  interior los ficheros de configuración y de control de estado de los  servicios de nuestro cluster de alta disponibilidad.


homes, de un tamaño de unos 24 Gb., que albergará los  directorios de todos los usuarios del sistema Cúmulo.

Pasado al esquema anterior, la estructura sería ésta:
sdb2    sdc1                           (PVs)    sda3  sdb1 sdc1
 \        /  <-equipodiez                          \    |    /
  \      /               equiposiete->              \   |   /
    datos                              (VG)           datos
  /     \                                             /    \
 /       \                                           /      \
cluster  homes                        (LVs)      cluster    homes
 |         |                              	     |         |
ext3      ext3        (sistemas de ficheros)       ext3      ext3

En cuanto al tipo de volúmenes lógicos creados, si bien LVM acepta en  sus últimas versiones la creación de volúmenes mediante RAID-0  (stripping), que puede mejorar el rendimiento de las lecturas y  escrituras, hemos decidido prescindir de él y hacer una mera  concatenación (RAID linear). Dos son los motivos que nos han hecho tomar  esta decisión:

La necesidad de espacio equivalente en los diferentes volúmenes  que forman el RAID-0, que debido a la asimetría de los discos nos  obligaba a tener un tamaño máximo de 16 Gb.


La seria restricción que esto nos suponía para el futuro  funcionamiento del sistema, ya que los volúmenes en stripping no pueden  modificarse, con lo que no podríamos aumentarlos si conseguimos más  almacenamiento más adelante.

Creación y puesta en funcionamiento de volúmenes lógicos
En primer lugar hemos de asegurarnos de que el kernel que tenemos  compilado incluye soporte para los volúmenes lógicos, para lo que, tras  hacer el habitual make menuconfig o make xconfig, iremos al apartado  Device Drivers > Multi-device support (RAID and LVM) y nos  aseguraremos de que tenemos marcadas por lo menos las siguientes  opciones:









Si estas opciones no hubieran estado activadas, tras salvar los  cambios en la configuración deberíamos de compilar el kernel como es  habitual con make zimage && make modules y reiniciar el sistema  para que éste aceptara los nuevos cambios en la configuración.
También tenemos que asegurarnos de que tenemos instalado las  utilidades de usuario para el trabajo con volúmenes lógicos, lo que en  nuestro caso consiste en tener instalado el paquete lvm2 en nuestro  servidor Debian, junto con sus correspondientes dependencias que  incluyen la librería libdevmapper. Por lo tanto se debe de teclear en  cada máquina:
# apt-get install lvm2

Una vez que tenemos esto hecho el siguiente paso es la creación de  las particiones que van a pasar a ser los volúmenes físicos de nuestro  grupo de volúmenes. Para ello utilizaremos la herramienta fdisk, cfdisk u  otra similar. Aunque no es obligatorio, sí que es aconsejable que todas  las particiones que creemos sean del tipo Linux LVM, identificado por  el código '8e. Aquí hay un ejemplo de como quedaron las particiones en  nuestros equipos de NFS:
Servidor equipodiez
root@equipodiez:~ # fdisk -l /dev/sda

	Disk /dev/sda: 4551 MB, 4551129088 bytes
       255 heads, 63 sectors/track, 553 cylinders
	Units = cylinders of 16065 * 512 = 8225280 bytes

	   Device Boot      Start         End      Blocks   Id  System
	/dev/sda1   *           1         553     4441941   83  Linux
	root@equipodiez:~ # fdisk -l /dev/sdb

	Disk /dev/sdb: 18.2 GB, 18210047488 bytes
 	255 heads, 63 sectors/track, 2213 cylinders
	Units = cylinders of 16065 * 512 = 8225280 bytes

	   Device Boot      Start         End      Blocks   Id  System
	/dev/sdb1               1         123      987966   82  Linux swap / Solaris
	/dev/sdb2             124        2213    16787925   8e  Linux LVM
	root@equipodiez:~ # fdisk -l /dev/sdc

	Disk /dev/sdc: 18.2 GB, 18210047488 bytes
	255 heads, 63 sectors/track, 2213 cylinders
	Units = cylinders of 16065 * 512 = 8225280 bytes

	   Device Boot      Start         End      Blocks   Id  System
	/dev/sdc1               1        2213    17775891   8e  Linux LVM

Servidor equiposiete
root@equiposiete:~ # fdisk -l /dev/sda

	Disk /dev/sda: 18.2 GB, 18210037760 bytes
	255 heads, 63 sectors/track, 2213 cylinders
	Units = cylinders of 16065 * 512 = 8225280 bytes

	   Device Boot      Start         End      Blocks   Id  System
	/dev/sda1   *           1         974     7823623+  83  Linux
	/dev/sda2             975        1218     1959930   82  Linux swap / Solaris
	/dev/sda3            1219        2213     7992337+  8e  Linux LVM
	root@equiposiete:~ # fdisk -l /dev/sdb

	Disk /dev/sdb: 18.2 GB, 18210037760 bytes
	64 heads, 32 sectors/track, 17366 cylinders
       Units = cylinders of 2048 * 512 = 1048576 bytes

          Device Boot      Start         End      Blocks   Id  System
       /dev/sdb1               1       17366    17782768   8e  Linux LVM
       root@equiposiete:~ # fdisk -l /dev/sdc

	Disk /dev/sdc: 4265 MB, 4265238016 bytes
	255 heads, 63 sectors/track, 518 cylinders
       Units = cylinders of 16065 * 512 = 8225280 bytes

          Device Boot      Start         End      Blocks   Id  System
       /dev/sdc1               1         518     4160803+  8e  Linux LVM

Un recordatorio importante: si creamos una partición en el  disco duro en el cual se alberga el sistema de ficheros / de nuestro  sistema operativo, esto nos obligará a reiniciar el sistema para que el  sistema la reconozca adecuadamente y podamos continuar los siguientes  pasos.
Una vez creadas las particiones en nuestro caso en concreto  tenemos disponibles unos 34 Gb (a través de las particiones de 16 y 18  Gb.) en equipodiez y 30 Gb.(particiones de 8, 18 y 4 Gb) en equiposiete,  lo que serán los espacios máximos de los que vamos a disponer para  crear nuestros volúmenes.
El siguiente paso consistirá en convertir estas particiones en  volúmenes físicos que puedan ser usados por Linux para crear un grupo de  volúmenes. Eso lo realizamos con el compando pvcreate, de la siguiente  manera:
Servidor equipodiez
root@equipodiez:~ # pvcreate /dev/sdb2
  Physical volume "/dev/sdb2" successfully created
root@equipodiez:~ # pvcreate /dev/sdc1
  Physical volume "/dev/sdc1" successfully created

Servidor equiposiete
root@equiposiete:~ # pvcreate /dev/sda3
  Physical volume "/dev/sda3" successfully created
root@equiposiete:~ # pvcreate /dev/sdb1
  Physical volume "/dev/sdb1" successfully created
root@equiposiete:~ # pvcreate /dev/sdc1
  Physical volume "/dev/sdc1" successfully created

Tras ello, hemos de juntar en cada servidor los diferentes volúmenes  físicos en su propio grupo de volúmenes. Para el caso del servidor  equipodiez, hemos juntado los volúmenes correspondientes a sdb2 y sdc1  en un grupo de volúmenes llamado datos con el comando:
root@equipodiez:~ # vgcreate datos /dev/sdb2 /dev/sdc1
  Volume group "datos" successfully created

Tras teclear este comando, comprobamos que se ha creado correctamente  tecleando:
root@equipodiez:~ # vgdisplay
         --- Volume group ---
         VG Name               	datos
         System ID
         Format                	lvm2
         Metadata Areas        	2
         Metadata Sequence     	No 1
         VG Access             	read/write
         VG Status             	resizable
         MAX LV                	0
         Cur LV                	0
         Open LV               	0
         Max PV                	0
         Cur PV                	2
         Act PV                	2
         VG Size               	32,96 GB
         PE Size               	4,00 MB
         Total PE              	8437
         Alloc PE / Size       	0 / 0
         Free  PE / Size       	8437 / 32,96 GB
         VG UUID               	N5AUlP-f3GX-4rm6-LS6p-TROd-5YxP-XgyL4f

Lo mismo hemos hecho con equiposiete y sus volúmenes físicos:
root@equiposiete:~ # vgcreate datos /dev/sda3 /dev/sdb1
	  Volume group "datos" successfully created
root@equiposiete:~ # vgdisplay
	  --- Volume group ---
	  VG Name               		datos
	  System ID
	  Format                		lvm2
	  Metadata Areas        	        2
	  Metadata Sequence 	                No  1
	  VG Access             		read/write
	  VG Status             		resizable
	  MAX LV                		0
	  Cur LV                		0
	  Open LV               		0
	  Max PV                		0
	  Cur PV                		2
	  Act PV                		2
	  VG Size               		24,58 GB
	  PE Size               		4,00 MB
	  Total PE              		6292
	  Alloc PE / Size       		0 / 0
	  Free  PE / Size       		6292 / 24,58 GB
	  VG UUID               		KcY7mN-go7y-tudM-K1Cq-We9c-789i-SBa5R7

Con los grupos de volúmenes creados en los dos servidores, pasamos a  crear los volúmenes lógicos, que son los que nos van a ser de utilidad  real para nosotros para trabajar con el sistema. Tal y como habíamos  planificado anteriormente, crearemos dos volúmenes: cluster para los  ficheros de configuración del cluster de alta disponibilidad (tendrá 300  Mb) y homes para almacenar los datos de los usuarios que se van a  compartir mediante NFS (tendrá 24 Gb).
Vamos a crear estos volúmenes con el mapeado linear. Este es el  método clásico de crear volúmenes lógicos, que consiste simplemente en  juntar el fin de cada uno de los volúmenes físicos con el inicio del  siguiente. Hay otros métodos que consiguen un aumento de los  rendimientos de escritura y/o lectura, pero que a cambio son totalmente  inflexibles en la modificación de volúmenes ya creados. Nosotros hemos  considerado más importante el poder redimensionar el sistema de acuerdo  con los nuevos recursos/demandas, por lo cual nos hemos quedado en el  enfoque linear clásico.
Los volúmenes tendrán que tener el mismo tamaño en los dos  servidores, puesto que nuestra intención es replicarlos entre sí para  que contengan exactamente los mismos datos. Por ello tendremos que  proceder a su creación exactamente igual en los dos servidores, lo que  haremos tecleando en ellos:
# lvcreate -L300M -ncluster datos
  Logical volume "cluster" created
# lvcreate -L24G -nhomes datos
  Logical volume "homes" created

Para comprobar que la creación de los volúmenes lógicos ha sido  correcta lo sabremos a través del comando:
Servidor equipodiez
root@equipodiez:~ # lvdisplay
	  --- Logical volume ---
	  LV Name                		/dev/datos/cluster
	  VG Name                		datos
	  LV UUID                		MBNxuT-dkf8-55Yq-Ilkd-GlKY-5C3e-seJYAT
	  LV Write Access        	        read/write
	  LV Status              		available
	  # open                 		0
	  LV Size                		300,00 MB
	  Current LE             		75
	  Segments               		1
	  Allocation             		inherit
	  Read ahead sectors     	        0
	  Block device           		254:0

	  --- Logical volume ---
	  LV Name                		/dev/datos/homes
	  VG Name                		datos
	  LV UUID                		cb9YMq-ImAC-TJnj-qtNN-zcOZ-UcNv-1wWEkS
	  LV Write Access        	        read/write
	  LV Status              		available
	  # open                 		0
	  LV Size                		24,00 GB
	  Current LE             		6144
	  Segments               		2
	  Allocation             		inherit
	  Read ahead sectors     	        0
	  Block device           		254:6

Servidor equiposiete
root@equiposiete:~ # lvdisplay
	  --- Logical volume ---
	  LV Name               	 	/dev/datos/cluster
	  VG Name                		datos
	  LV UUID                		bns3IH-NoZP-Qiy5-z8P3-CDkf-0vGt-Mz0wH5
	  LV Write Access        	        read/write
	  LV Status              		available
	  # open                 		0
	  LV Size                		300,00 MB
	  Current LE             		75
	  Segments               		1
	  Allocation             		inherit
	  Read ahead sectors     	        0
	  Block device           		254:5

	  --- Logical volume ---
	  LV Name                		/dev/datos/homes
	  VG Name                		datos
	  LV UUID                		axKWYW-fYMr-fWIR-qgF6-eGhL-h9QM-Teme2o
	  LV Write Access        	        read/write
	  LV Status              		available
	  # open                 		0
	  LV Size                		24,00 GB
	  Current LE             		6144
	  Segments               		2
	  Allocation             		inherit
	  Read ahead sectors     	        0
	  Block device           		254:6

Con esto ya tenemos nuestros volúmenes lógicos creados en equipodiez y  equiposiete. Eso sí, estos volúmenes, aunque tienen el mismo tamaño son  totalmente independientes.
Replicación de volúmenes a través de red: DRBD
Continuando con la puesta en marcha de la redundancia del  almacenamiento, tenemos que conseguir sincronizar el contenido de los  volúmenes lógicos que hemos creado en los dos servidores de manera que  siempre tengamos el mismo contenido en los dos. Así, si los discos de  alguno de los servidores fallan por cualquier motivo, tendremos una  réplica en el otro que podremos emplear casi inmediatamente.
Esta tarea la vamos a realizar con el software DRBD (http://www.drbd.org/),  un módulo para el kernel de linux, acompañado de diversas aplicaciones  que crean dispositivos de bloques y se encargan de mantenerlos con  contenidos sincronizados a través de una conexión de red. De esta manera  conseguimos realizar un mirror a través de una conexión de red,  evitando costosos dispositivos SCSI.
Para comenzar la instalación, vamos a comenzar instalando los  paquetes .deb necesarios, que en nuestro ubuntu se llaman  drbd0.7-module-source (el que incluye el código fuente del módulo que  necesitaremos añadir a nuestro kernel) y drbd0.7-utils (que incluye los  scripts y aplicaciones de usuario). Los instalaremos tecleando los  comandos habituales de instalación en los Linux tipo debian:
# apt-get install drbd0.7-module-source
# apt-get install drbd0.7-utils

Tras esta instalación, que se encarga de copiar a nuestro sistema de  ficheros los archivos que vamos a necesitar, lo primero que deberíamos  de hacer es compilar el módulo del kernel de DRBD y añadirlo a nuestra  instalación. Para ello comenzaremos desplazándonos al directorio donde  se encuentra este módulo y descomprimiéndolo.
root@equiposiete:/ # cd /usr/src
root@equiposiete:/usr/src # tar zxvf drbd0.7.tar.gz

Como prerrequisito para poder proceder a compilar el módulo DRBD para  nuestro sistema, deberemos de tener el árbol del código fuente del  kernel de nuestro sistema debidamente preparado. Si lo hemos  personalizado seguramente ya lo tengamos listo bajo /usr/src/linux. Si  no es así, podemos instalarlo como paquete en Ubuntu tecleando:
# apt-get install  linux-tree

Esto se encargaría de instalar los paquetes del último kernel junto  con los parches personalizados para Ubuntu de forma automática.
Una vez verificado que tenemos los ficheros del kernel en nuestro  disco, verificaríamos que se ha creado el directorio adecuado bajo  /usr/src, y si no estuviese hecho, le haríamos un enlace para que fuese  accesible a través de /usr/src/linux, y a continuación teclearíamos:
root@equiposiete:/ # cd /usr/src/linux
root@equiposiete:/usr/src/linux # make include/linux/version.h
root@equiposiete:/usr/src/linux # make modules_prepare

Ya tendremos el kernel listo. Ahora procederemos a compilar el  módulo...
root@equiposiete:/ # cd /usr/src/modules/drbd/drbd
root@equiposiete:/usr/src/modules/drbd/drbd# make clean all

Ahora ya tendremos el módulo de kernel DRBD. Es un fichero llamado  drbd.ko que se encuentra en nuestro directorio de trabajo. Pero todavía  no está listo para funcionar. Para ello necesitaremos copiarle a su  localización adecuada y añadirle las dependencias como módulo:
root@equiposiete:/usr/src/modules/drbd/drbd# mkdir /lib/modules/`uname -r`/block
root@equiposiete:/usr/src/modules/drbd/drbd# cp drbd.ko /lib/modules/`uname -r`/block
root@equiposiete:/usr/src/modules/drbd/drbd# depmod -a

Para que los dispositivos DRBD se creen correctamente y se repliquen  como deseamos a través de la red, debemos de indicar a los sistemas como  deseamos que se realicen estas tareas, lo que vamos a hacer a través  del fichero /etc/drdb.conf, en el cual indicamos la partición (en  nuestro caso volumen lógico) qué se replica en cada servidor, la manera  en que se produce esta sincronización, direcciones IP y puertos  empleados, velocidades, nombres de dispositivos... En nuestro caso hemos  definido estos dos recursos:

r-cluster, que se usará como dispositivo para almacenar  los datos principales de configuración de los clusters, almacenados en  los volúmenes lógicos cluster de cada una de las máquinas


r-homes, que se usará como dispositivo para almacenar el  grueso de el contenido de los directorios home de los usuarios de todo  el sistema Cúmulo, almacenados en los volúmenes lógicos homes de cada  una de las máquinas servidoras NFS

Vamos a implementar esto creando un fichero /etc/drbd.conf en cada  uno de los servidores que parametrice todos los valores de configuración  como deseamos. Este fichero contendrá una sección opcional global con  parámetros genéricos, más una sección resource para cada uno de los  recursos que queramos espejar a través de la red. Su contenido, ha de  ser idéntico en los dos nodos cuyos discos se replican. Este es el  fichero concreto que hemos usado, en el que se ha obviado la sección  global pero contiene dos secciones resource, una para cada uno de los  recursos:
#
	# drbd.conf para el cluster NFS de CUMULO
	#

	#
	# RECURSO R-CLUSTER
	#

	resource r-cluster {
	  protocol C;
	  incon-degr-cmd "echo '!DRBD! primario r-cluster inconsistente-degradado' | wall";

	  startup {
	    # wfc-timeout  0;
	    degr-wfc-timeout 120;    # 2 minutos
	  }

	  disk {
	    on-io-error   detach;
	  }

	  net {
	    # sndbuf-size 512k;
	    # timeout       60;    #  6 seconds  (unit = 0.1 seconds)
	    # connect-int   10;    # 10 seconds  (unit = 1 second)
	    # ping-int      10;    # 10 seconds  (unit = 1 second)
	    # max-buffers     2048;
	    # max-epoch-size  2048;
	    # ko-count 4;
	    # on-disconnect reconnect;
	  }

	  syncer {
	    # rate 10M;
	    rate 1M;
	    group 1;
	    al-extents 257;
	  }

	  on equipodiez {
	    device     /dev/drbd0;
	    disk       /dev/datos/cluster;
	    address    192.168.2.10:7788;
	    meta-disk  internal;
	  }

	  on equiposiete {
	    device    /dev/drbd0;
	    disk      /dev/datos/cluster;
	    address   192.168.2.7:7788;
	    meta-disk internal;
	  }

	}

	#
	# RECURSO R-HOMES
	#

	resource r-homes {

	  protocol C;
	  incon-degr-cmd "echo '!DRBD! primario r-homes inconsistente-degradado' | wall";

	  startup {
	    # wfc-timeout  0;
	    degr-wfc-timeout 120;    # 2 minutos
	  }

	  disk {
	    on-io-error   detach;
	  }

	  net {
	    # sndbuf-size 512k;
	    # timeout       60;    #  6 seconds  (unit = 0.1 seconds)
	    # connect-int   10;    # 10 seconds  (unit = 1 second)
	    # ping-int      10;    # 10 seconds  (unit = 1 second)
	    # max-buffers     2048;
	    # max-epoch-size  2048;
	    # ko-count 4;
	    # on-disconnect reconnect;
	  }

	  syncer {
	    # rate 10M;
	    rate 8M;
	    group 2;
	    al-extents 257;
	  }

	  on equipodiez {
	    device     /dev/drbd1;
	    disk       /dev/datos/homes;
	    address    192.168.2.10:7789;
	    meta-disk  internal;
	  }

	  on equiposiete {
	    device    /dev/drbd1;
	    disk      /dev/datos/homes;
	    address   192.168.2.7:7789;
	    meta-disk internal;
	  }

	}

Vamos a explicar a continuación los parámetros de configuración más  importantes que incluyen las secciones resource de este fichero de  configuración para conocer su utilidad concreta y así poder cambiarlos  de acuerdo con las necesidades que podamos tener en un sistema concreto:

protocol nos indica como va a ser el funcionamiento del  protocolo encargado de la replicación de datos entre discos. Indicando  'A' el protocolo da una escritura como finalizada en cuanto se ha  realizado en el disco local y se deja el cambio en el buffer TCP de la  máquina local, con lo cual apenas hay que esperar por la escritura  remota. Si ponemos 'B' la escritura no se da por finalizada hasta que la  petición de escritura no llega al buffer de la máquina remota. Para  nusetro sistema nosotros hemos elegido la opción más fiable aunque más  lenta, que es la 'C', que no considera la operación de escritura hecha  hasta que no se ha confirmado la escritura en el disco remoto.


El parámetro on-io-error de la subsección disk indica como actúa  el módulo DRBD si el dispositivo en el que se intenta escribir diese un  error de escritura. Entre las opciones que presenta, nosotros hemos  elegido la 'detach', que detiene la sincronización. Las otras opciones  que se pueden elegir aquí son 'panic' para que el nodo genere un kernel  panic y deje el cluster o bien 'pass_on' para que el módulo informe del  error a las capas de software más altas.


La función on-disconnect se encuentra dentro de la subsección  net y sirve para indicar que hacemos si perdemos la conectividad con  nodo de sincronización. Nosotros hemos elegido aquí la opción de  'reconnect', que reintenta la conexión y acualiza la información cuando  la consigue. Otras opciones son 'stand_alone' para quedarse en modo  local sin replicación y 'freeze_io' para intentar reconectar pero  detener las tareas en el disco hasta que no lo hayamos conseguido.


La opción rate dentro de la subsección syncer limita el ancho de  banda de red que se emplea para sincronizar el recursos que estamos  definiendo. Nosotros hemos limitado la velocidad del recurso r-cluster a  1 Megabyte/s escribiendo '1M', y la del recurso r-homes a 8 Megabytes/s  escribiendo '8M'. Si queremos emplear otras unidades en vez de 'M'  podemos usar los sufijos 'K' o 'G'.

La opción group dentro de la subsección syncer señala con un número  los diferentes grupos de recurso que se van a sincronizar al mismo  tiempo, y su orden. Nosotros hemos establecido que se sincronice en  primer lugar ('1') el recurso r-cluster y en segundo lugar ('2') el  r-homes.

La opción on viene seguida del 'hostname' de una de las máquinas  que alojan disco compartido (hay una subsección de estas para cada  máquina) y marca una subsección que se dedica a indicar todos los  parámetros que nos interesan de esa máquina, que son estos que ponemos a  continuación:




device nos sirve para indicar el nombre que le queremos  dar al dispositivo espejado, que será el que utilizaremos a partir de  ahora. Siguiendo el estándar, lo hemos llamado /dev/drbd0 para el  recurso r-cluster y /dev/drbd1 para el r-homes.
disk nos indica el nombre del dispositivo físico original que  se va a espejar. Por ejemplo, '/dev/datos/cluster' en el caso del  dispositivo '/dev/drbd0'
address sirve para indicar la dirección IP y puerto TCP por los  cuales se va a hacer la replicación. Nosotros dedicamos para ello una  dirección IP de una red que vamos a dedicar únicamente a la replicación,  para procurar que no interfiera el tráfico normal de la red. Y como  puertos, usamos el estándar 7788 para r-cluster y el siguiente 7789 para  r-homes.
meta-disk nos dice donde se almacena la meta-información sobre  la replicación de los discos. Nosotros hemos puesto 'internal' en los  dos casos para indicar que es dentro del propio disco indicado en el  parámetro disk, pero podríamos haber indicado otro dispositivo físico o  lógico que almacenase toda la información de los dos discos. En este  último caso hubiera sido necesario añadirles al final un número  diferente para cada recurso (es decir, al go como /dev/hde6[0] para uno y  /dev/hde6[1] para otro).



Una vez que tenemos la configuración hecha vamos a poner en marcha e  inicializar el sistema DRBD. En primer lugar cargamos el módulo en los  dos servidores:
# modprobe drbd

A continuación, también en cada uno de los servidores, vamos a  cambiar el estado de todos los dispositivos DRBD a activo tecleando...
# drbdadm up all

De esta manera, tendremos ahora en los dos servidores los  dispositivos de réplica en estado inconsistente (pues tienen contenidos  diferentes, y no están sincronizados entre sí) y secundario (esto es,  que es el que recibe los cambios del disco maestro para ser igual que  él). Esto lo sabemos al teclear en cada uno de los servidores el  comando:
# cat /proc/drbd

El siguiente paso consiste en hacer que uno de los nodos pase a ser  el primario, es decir, aquel que va a tener normalmente montado el  sistema de ficheros y por lo tanto donde se van a hacer los cambios  originalmente ( y él los mandará al otro servidor para que se repliquen  allí). En nuestro caso esto lo vamos a hacer en el servidor equipodiez  (también llamado equipodiez), tecleando el comando:
# drbdadm -- --do-what-I-say primary all

A partir de este momento veremos que los dispositivos de este nodo  pasan a estado primario y consistente, comenzando a realizarse la  sincronización de los contenidos, que dependiendo del tamaño de discos y  velocidad de la red puede llevar de varios minutos a varias horas.
Para ver el transcurso de la sincronización, lo podemos hacer  consultando periódicamente el contenido del fichero /proc/drbd. En el  nodo principal (en nuestro caso equipodiez obtendríamos un resultado  similar a éste.
root@equipodiez:~ # cat /proc/drbd
	version: 0.7.7 (api:77/proto:74)
	SVN Revision: 1680 build by root@equipodiez, 2005-06-03 13:44:14
	 0: cs:SyncSource st:Primary/Secondary ld:Consistent
	    ns:5700 nr:0 dw:0 dr:5700 al:0 bm:11 lo:0 pe:0 ua:0 ap:0
	        [=>..................] sync'ed:  6.9% (170428/176128)K
	        finish: 0:02:22 speed: 1,140 (1,140) K/sec
	 1: cs:PausedSyncS st:Primary/Secondary ld:Consistent
	    ns:0 nr:0 dw:0 dr:0 al:0 bm:1528 lo:0 pe:0 ua:0 ap:0

	root@equipodiez:~ # cat /proc/drbd
	version: 0.7.7 (api:77/proto:74)
	SVN Revision: 1680 build by root@equipodiez, 2005-06-03 13:44:14
	 0: cs:SyncSource st:Primary/Secondary ld:Consistent
	    ns:148800 nr:0 dw:0 dr:148800 al:0 bm:20 lo:0 pe:25 ua:0 ap:0
	        [=================>..] sync'ed: 86.4% (27428/176128)K
	        finish: 0:00:24 speed: 1,084 (996) K/sec
	 1: cs:PausedSyncS st:Primary/Secondary ld:Consistent
	    ns:0 nr:0 dw:0 dr:0 al:0 bm:1528 lo:0 pe:0 ua:0 ap:0

	root@equipodiez:~ # cat /proc/drbd
	version: 0.7.7 (api:77/proto:74)
	SVN Revision: 1680 build by root@equipodiez, 2005-06-03 13:44:14
	 0: cs:Connected st:Primary/Secondary ld:Consistent
	    ns:176128 nr:0 dw:0 dr:176128 al:0 bm:22 lo:0 pe:0 ua:0 ap:0
	 1: cs:SyncSource st:Primary/Secondary ld:Consistent
	    ns:33416 nr:0 dw:0 dr:33568 al:0 bm:1530 lo:0 pe:49 ua:38 ap:0
	        [>...................] sync'ed:  0.2% (24415/24448)M
	        finish: 0:49:36 speed: 8,304 (8,304) K/sec

En el nodo secundario los resultados serían similares, pero  indicándonos que los dispositivos son secundarios, y permaneciendo la  indicación de nodo inconsistente hasta que se hubiese finalizado la  sincronización, así:
root@equiposiete:~ # cat /proc/drbd
	version: 0.7.7 (api:77/proto:74)
	SVN Revision: 1680 build by phil@wiesel, 2004-12-14 16:05:39
	 0: cs:SyncTarget st:Secondary/Primary ld:Inconsistent
	    ns:0 nr:32900 dw:32900 dr:0 al:0 bm:13 lo:0 pe:0 ua:0 ap:0
	        [====>...............] sync'ed: 22.8% (143228/176128)K
	        finish: 0:01:29 speed: 1,496 (996) K/sec
	 1: cs:PausedSyncT st:Secondary/Primary ld:Inconsistent
	    ns:0 nr:0 dw:0 dr:0 al:0 bm:1528 lo:0 pe:0 ua:0 ap:0

root@equiposiete:~ # cat /proc/drbd
	version: 0.7.7 (api:77/proto:74)
	SVN Revision: 1680 build by phil@wiesel, 2004-12-14 16:05:39
	 0: cs:SyncTarget st:Secondary/Primary ld:Inconsistent
	    ns:0 nr:114700 dw:114700 dr:0 al:0 bm:17 lo:1 pe:0 ua:0 ap:0
	        [=============>......] sync'ed: 68.2% (61428/176128)K
	        finish: 0:00:51 speed: 1,196 (996) K/sec
	 1: cs:PausedSyncT st:Secondary/Primary ld:Inconsistent
	    ns:0 nr:0 dw:0 dr:0 al:0 bm:1528 lo:0 pe:0 ua:0 ap:0

	root@equiposiete:~ # cat /proc/drbd
	version: 0.7.7 (api:77/proto:74)
	SVN Revision: 1680 build by phil@wiesel, 2004-12-14 16:05:39
	 0: cs:Connected st:Secondary/Primary ld:Consistent
	    ns:0 nr:176128 dw:176128 dr:0 al:0 bm:22 lo:0 pe:0 ua:0 ap:0
	 1: cs:SyncTarget st:Secondary/Primary ld:Inconsistent
	    ns:0 nr:89140 dw:89140 dr:0 al:0 bm:1533 lo:24 pe:180 ua:24 ap:0
	        [>...................] sync'ed:  0.4% (24361/24448)M
	        finish: 0:50:42 speed: 8,124 (7,420) K/sec

Una vez finalizada la sincronización podremos observar que el estado  de los dos dispositivos en los dos nodos pasa a ser Consistent, lo que  nos indica que ya tenemos los dispositivos perfectamente listos para  trabajar con ellos.
Eso sí, aunque la replicación está funcionando correctamente  ahora, aún nos queda por hacer que al arrancar nuestro sistema, ésta se  ponga de marcha automáticamente para no perder información alguna. Esto  se hace a través del script de arranque /etc/init.d/drbd, que vamos a  añadir al arranque por defecto tecleando en las dos máquinas servidoras  NFS:
root@equipodiez:/etc # update-rc.d drbd defaults
	 Adding system startup for /etc/init.d/drbd ...
	   /etc/rc0.d/K20drbd -> ../init.d/drbd
	   /etc/rc1.d/K20drbd -> ../init.d/drbd
	   /etc/rc6.d/K20drbd -> ../init.d/drbd
	   /etc/rc2.d/S20drbd -> ../init.d/drbd
	   /etc/rc3.d/S20drbd -> ../init.d/drbd
	   /etc/rc4.d/S20drbd -> ../init.d/drbd
	   /etc/rc5.d/S20drbd -> ../init.d/drbd

Con esto ya tenemos los servidores listos para que continúen  replicando correctamente sus datos después del arranque ante cualquier  contingencia.
Sistemas de ficheros
Con los dispositivos ya replicados en la red correctamente, ahora  podemos pasar a formatearlos adecuadamente y prepararlos para que se  monten correctamente en los servidores cuando sea necesario.
En primer lugar, hemos de escoger el sistema de ficheros a  utilizar. En nuestro caso optamos por ext3, probablemente el más  utilizado en la actualidad y que nos venía muy bien para nuestros  propósitos, pues añade al clásico y ultracompatible sistema de ficheros  ext2 las facilidades de journaling, que nos son muy útiles en caso de  que necesitemos la recuperación de contenidos por alguna caída o  inestabilidad del sistema.
Como el sistema de ficheros ya se encuentra en plena  sincronización, sólo vamos a necesitar hacer el formateo en el servidor  que tiene los dispositivos de bloques cluster y homes en modo primario  (el servidor equipodiez en nuestro caso), y los otros ya se  sincronizarán automáticamente. Eso lo haremos simplemente tecleando el  comando mkfs apropiado sobre los dispositivos que hemos creado  anteriormente, sin olvidarnos de poner el path completo a los  dispositivos, de la siguiente manera:
root@equipodiez:~ # mkfs.ext3 /dev/datos/cluster
	mke2fs 1.35 (28-Feb-2004)
	Filesystem label=
	OS type: Linux
	Block size=1024 (log=0)
	Fragment size=1024 (log=0)
	51200 inodes, 204800 blocks
	10240 blocks (5.00%) reserved for the super user
	First data block=1
	25 block groups
	8192 blocks per group, 8192 fragments per group
	2048 inodes per group
	Superblock backups stored on blocks:
	        8193, 24577, 40961, 57345, 73729

	Writing inode tables: done
	Creating journal (4096 blocks): done
	Writing superblocks and filesystem accounting information: done

	This filesystem will be automatically checked every 28 mounts or
	180 days, whichever comes first.  Use tune2fs -c or -i to override.

	root@equipodiez:~ # mkfs.ext3 -b 4096 -R stride=8 /dev/datos/homes
	mke2fs 1.35 (28-Feb-2004)
	Filesystem label=
	OS type: Linux
	Block size=4096 (log=2)
	Fragment size=4096 (log=2)
	3145728 inodes, 6291456 blocks
	314572 blocks (5.00%) reserved for the super user
	First data block=0
	192 block groups
	32768 blocks per group, 32768 fragments per group
	16384 inodes per group
	Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000

	Writing inode tables: done
	Creating journal (8192 blocks): done
	Writing superblocks and filesystem accounting information: done

	This filesystem will be automatically checked every 37 mounts or
	180 days, whichever comes first.  Use tune2fs -c or -i to override.

Ahora ya tenemos formateados los dos sistemas de ficheros que vamos a  utilizar, pero debemos de montarlos para comenzar a utilizarlos.
Si bien la primera idea que se nos puede pasar por la cabeza es  el añadir un punto de montaje automático para estos dispositivos en las  dos máquinas servidoras NFS, esto no es la solución correcta, pues lo  que vamos a pretender es montar un sistema de alta disponibilidad, y  este recurso va a estar únicamente en un servidor, y sólo montarse en el  otro cuando el primero presente fallos.
Por ello, la tarea de montaje/desmontaje de estos dispositivos va  a ser propia del software de cluster, y nosotros únicamente vamos a  encargarnos de indicar en la fstab la localización de éstas particiones a  modo informativo pero con el flag de noauto, para que no los monte  automáticamente en el arranque, pues provocaría conflictos al intentar  montar un mismo dispositivo en los dos servidores a la vez.
Por lo tanto, editaremos el fichero /etc/fstab en los dos  servidores, pero únicamente añadiendo:
/dev/drbd0      /export         ext3    defaults,noauto,acl     0       0
/dev/drbd1      /etc/cluster    ext3    defaults,noauto         0       0

Como se puede ver al dispositivo /dev/drbd0 le hemos añadido  adicionalmente el flag acl, para que podamos utilizar listas de acceso  para particularizar el acceso a los ficheros que compartimos por NFS.  También puede resultar curioso el que tenga el flag noauto que indica  que no se monte al arrancar. El motivo de ello es que el encargado del  montaje de estos procesos va a ser el sistema de alta disponibilidad.
Para que se pueda realizar el montaje correctamente tendremos que  crear los puntos de montaje en los dos servidores, tecleando:
# mkdir /export
# chmod a+rwxt /export
# mkdir /etc/cluster

Tras esto, ya podemos proceder a montar estos dispositivos que hemos  creado exclusivamente en el servidor principal (equipodiez), lo  que haremos tecleando...
# mount /export
# mount /etc/cluster
Alta disponibilidad del servicio NFSv4
Arquitectura del Cluster-HA
Introducción

Tras realizar los pasos indicados en el apartado anterior, ya tenemos  en funcionamiento dos sistemas Linux, con el software de NFS preparado  para funcionar. Tanto /export, el directorio con la información a  compartir por red, como /etc/cluster, donde se almacenan diversas  configuraciones, se encuentran montados en la máquina equipodiez y  replicándose a través del software DRDB en la otra máquina, equiposiete.
Comenzando

Con el sistema en este estado, y simplemente arrancando los servicios  de NFS en equipodiez ya tendríamos en funcionamiento nuestro servidor  de ficheros NFS con la seguridad de que, además, tenemos replicada la  información en el disco duro de otro servidor y la podríamos recuperar  de allí en caso de fallo hardware. La opción puede ser aceptable, pero  no nos proporciona una disponibilidad suficiente para el sistema, pues:

En caso de fallo, lo más probable es que ningún responsable se  entere rápidamente de él, pues no van a estar utilizando continuamente  el servicio.

Una vez detectado el fallo, es preciso localizar a un  administrador y que este realice manualmente las tareas necesarias para  deshabilitar el servidor fallido y poner en marcha el servicio de NFS en  el servidor de respaldo, lo que lleva un tiempo no despreciable.

Para Cúmulo nosotros hemos decidido minimizar en todo lo posible  estos problemas con la instalación de un cluster de alta disponibilidad  (HA - High Availabililty) entre los dos servidores a través del software  heartbeat (http://www.linux-ha.org).
Cluster de Alta  disponibilidad

Antes de seguir hacia adelante, vamos a explicar muy brevemente que  es y para que sirve un cluster de alta disponibilidad. Aunque el  significado de alta disponibilidad o cluster no es el mismo para todo el  mundo, para nosotros un cluster de alta disponibilidad es un conjunto  de servidores que trabajan en común para proporcionar unos servicios  específicos. En un cluster de alta disponibilidad los servicios no  pertenecen a un servidor o a otro, sino al cluster como un único objeto.  Si un servidor falla los servicios son traspasados de forma rápida y  automática al otro servidor. De esta manera, se reduce enormemente  el tiempo que un servicio puede estar sin funcionar.

El funcionamiento básico de estos clusters se basa en un medio a  través del cual estas máquinas se comunican y que les sirve para saber a  la una el estado de la otra. Este es el que se llama canal de  heartbeat. En realidad no tiene por que ser uno solo, sino que conviene  duplicarlo para evitar puntos únicos de fallo que nos puedan desvirtuar  la información sobre el estado de la otra máquina.

Continuando con la explicación, vamos a recordar que cada una de  las máquinas que compone el cluster tendrá su propia dirección IP de red  independiente. Pues bien, además de esta dirección de red  independiente, habrá en el cluster otra dirección IP a la que podemos  llamar "IP del cluster" que va a ser propia del servicio (o en su caso  servicios) que el cluster esté proporcionando. Por ejemplo, en nuestro  sistema, cuando arrancamos los servidores y la máquina equipodiez sea la  encargada de dar servicio al cluster, la situación estaría tal que así  (ver figura):










Vemos que la dirección IP de cluster está asignada a la máquina  equipodiez. Sin embargo, ¿que pasaría si ahora el servidor equipodiez  dejase de funcionar por una avería?. Pues la otra máquina del cluster,  equiposiete, percibiría a través de su canal de heartbeat que el  equipodiez ha dejado de responder adecuadamente. El siguiente paso sería  que tras comprobarlo, la máquina equiposiete tomaría posesión de los  servicios del cluster, se adjudicaría la dirección IP del cluster y  entonces la situación quedaría tal que así (ver figura):










Una vez descrito el funcionamiento básico de un cluster vamos a  mostrar la manera concreta en la que hemos decidido implantarlo en  nuestro caso.
Implantación del cluster

En primer lugar, a nivel lógico ya sabíamos que el servicio que  queríamos poner en cluster era el de NFS, pero esto no es tan sencillo a  la hora de configurar un cluster, pues el cambio de este recurso de NFS  de un nodo del cluster a otro en realidad va a depender de una serie de  tareas, que han de ponerse en marcha y pararse en el orden adecuado.  Tras un estudio detallado, se decidió que esta sería la lógica de un  cambio de servicio:

Adquisición de dirección IP del cluster: Lo primero que habrá  que hacer para asumir un servicio será adoptar la IP del cluster.
Pasar el recurso de disco r-cluster a primario: Lo siguiente  sería hacer que el nodo activo pase a ser el primario (el que marca los  cambios) en la relación de sincronización de los discos, pues de otra  manera no podríamos utilizarle. Escogemos en primer lugar r-cluster  porque es donde están los ficheros de configuración imprescindibles para  que el servicio llegue a arrancar.
Pasar el recurso de disco r-homes a primario: Ahora ponemos  nuestro disco local del recurso r-homes (que es el que incluye todos los  datos de usuario) también para que haga de primario en la  sincronización.
Montar el directorio /etc/cluster: Montamos el directorio  /etc/cluster (a partir del volumen r-cluster que acabamos de pasar a  primario), y así ya vemos los ficheros de configuración que vamos a  necesitar.
Montar el directorio /export: Usando el volumen de r-homes  montamos el directorio con toda la información que vamos a compartir por  NFS.
Montar el sistema de ficheros nfsd: También necesario para el  correcto funcionamiento de NFSv4.
Arranque del script de arranque nfs-common: Es el que se  encarga de cargar en el kernel de ubuntu los módulos para que reconozca  adecuadamente NFSv4.
Script de arranque nfs-kernel-server: Es el que se encarga de  arrancar los demonios del kernel que activan a la máquina como servidora  NFS


Dejando la estructura lógica y pasando al nivel arquitectónico, lo  primero que teníamos que decidir era una dirección IP propia para el  cluster dentro de la misma red en la que están los componentes del  cluster. Para ello escogimos la 192.168.2.12, que estaba disponible.

Lo siguiente a elegir era la manera de realizar el heartbeat  entre las máquinas del cluster. En nuestro caso utilizar para ello dos  canales, para evitar de esta manera un punto único de fallo en el  sistema:

Como primer canal se podía haber utilizado uno de los interfaces  de red existentes en las máquinas (el que las comunica con el resto de  las máquinas de Cúmulo o el de sincronización de discos), pero para  evitar que el tráfico de estas redes pudiera interferir con el heartbeat  se habilitó una tarjeta independiente. La velocidad en este caso no es  importante, por lo que se reaprovechó una vieja tarjeta Ethernet de 10  Mbps. Como direccionamiento para esta conexión se decidió utilizar la  subred 192.168.12.0/24, y direcciones IPs análogas a las de las máquinas  en otras redes: 192.168.12.10 y 192.168.12.7.


Como segundo canal, se decidió utilizar un cable de serie en  configuración de 'módem nulo' comunicando las dos máquinas del cluster.  Se ha hecho así para independizar esta comunicación de la pila TCP/IP,  para que aunque esta se quedara virtualmente inutilizada por alguna  causa, eso no provocara la señalización incorrecta de una  indisponibilidad de la máquina.


El resultado, de todo ello, lo vemos reflejado esquemáticamente en  esta figura:

A partir de estas ideas de base, vamos a explicar los pasos  seguidos para la instalación así como los detalles importante a tener en  cuenta durante la misma en los siguientes puntos.









Preparativos iniciales

Ya hemos tomado la decisión de que vamos a montar un cluster y  tenemos la idea general de su funcionamiento en mente. ¿Por donde  podemos empezar entonces?. Nosotros hemos decidido que en primer lugar,  antes de comenzar con el software, debíamos de empezar a configurar el  hardware, y hemos intentado, antes de nada, poner a punto los canales  que el cluster va a utilizar para la comunicación entre nodos.

Para ello, lo primero que vamos a hacer es apagar los dos nodos  del cluster (por ejemplo, con un init 0) y procedemos a instalar en cada  uno de ellos la tarjeta de red que vamos a utilizar para las labores de  heartbeat. Tras arrancar el kernel ya debe de haber detectado nuestra  nueva tarjeta en cada máquina. Para comprobar el nombre que le ha dado,  podemos teclear...
# cat /proc/net/dev

Con lo cual obtendremos una lista con todos los interfaces de la  máquina similar a la que tenemos debajo, en la que se incluirá el nuevo  que acabamos de instalar en el servidor:
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
    lo: 7253066   97164    0    0    0     0          0         0  7253066   97164    0    0    0     0       0          0
  eth0:24755724   34754    1    0    0     0          0         0  7028342   75488    0    0    0     0       0          0
  eth1:       0       0    0    0    0     0          0         0    18164      92    0    0    0     0       0          0
  eth2:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
  sit0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0

Simplemente deberemos de comparar los interfaces de esta lista con  que sabemos que tenía la máquina anteriormente (o, en su defecto, con  los que aparecen configurados al teclear el comando ifconfig en la  máquina) y aquél que sea nuevo, será el que acabamos de instalar. En  nuestro caso, muy probablemente sería el eth2 en las dos máquinas, así  que continuaremos nuestros ejemplos utilizándole como tal.
Ahora que ya sabemos que nuestra nueva tarjeta de red es eth2,  vamos a configurarla para que adquiera su dirección IP normalmente al  arrancar, lo cual haremos editando el fichero /etc/network/interfaces.  Teniendo en cuenta las direcciones que habíamos elegido y que se pueden  ver en el anterior apartado, tendríamos que añadir para el servidor  equiposiete lo siguiente:
iface eth2 inet static
	address 192.168.12.7
	netmask 255.255.255.0

	auto eth2

...y para equipodiez
iface eth2 inet static
	address 192.168.12.10
	netmask 255.255.255.0

	auto eth2

Hecho lo cual solo quedaría refrescar la configuración de red en cada  máquina para tenerla disponible, ejecutando:
# /etc/init.d/networking force-reload

Una vez realizado esto, comprobamos que la conectividad entre ambos  nodos es correcta, haciendo ping entre ellos. Tras ello, ya habremos  dejado preparado el "canal ethernet" del heartbeat, y podemos ponernos  manos a la obra con el "canal serie" que se va a encargar de la misma  tarea.
Para ello en primer lugar vamos a hacer la conexión física del  cable de módem nulo desde un servidor al otro. La conexión es muy  sencilla, pero antes de darla por buena conviene realizar una prueba,  tal y como hicimos en el caso anterior. Suponiendo que estemos  utilizando el puerto COM1 (/dev/ttyS0 en Linux) podríamos teclear en el  nodo que queramos que haga de receptor el comando:
# cat </dev/ttyS0

Y, con ese comando corriendo, dirigirnos al otro nodo (que hará de  emisor) y teclear allí:
# echo holaaa >/dev/ttyS0

Si todo está funcionando correctamente, en el nodo receptor debería  de aparecer el holaaa que hemos tecleado en el otro nodo. Si es así,  para acabar las pruebas, volvemos a repetir estos mismos pasos, pero  cambiando los roles de nodo emisor y receptor. En caso de fallo conviene  comprobar que estamos utilizando el puerto de comunicaciones correcto y  si es así, echar un vistazo a algún documento como el Serie-COMO (http://es.tldp.org/COMO-INSFLUG/COMOs/Serie-Como/),  que nos puede dar pistas sobre los fallos que podemos estar cometiendo.
Ahora que ya tenemos el hardware listo, vamos a ponernos manos a  la obra con el software, y para ello comenzaremos instalando el software  de alta disponibilidad en nuestros servidores. Como ya comentamos  anteriormente, para ello vamos a utilizar heartbeat, paquete del cual  tenemos la suerte de disponer en ubuntu, por lo cual para proceder a su  instalación únicamente tendremos que teclear en cada uno de los  servidores del cluster:
# apt-get install heartbeat

Configuración de la alta disponibilidad
Tras la instalación del paquete de heartbeat, podemos empezar ya su  configuración, para adecuarle a las tareas que nosotros deseamos que  realice. Los ficheros de configuración de heartbeat se encuentran en el  directorio /etc/ha.d. Nosotros vamos a trabajar principalmente con tres  de ellos: ha.cf, haresources y authkeys.
ha.cf
El fichero ha.cf informa al software heartbeat de parámetros  genéricos del funcionamiento del cluster referentes a los canales que va  a usar para su comunicación de heartbeat, la forma en la que va a  funcionar y los nodos que lo componen.
Vamos a ir analizando uno por uno los parámetros que hemos  incluido en nuestro fichero ha.cf:
serial /dev/ttyS0

En primer lugar, con este comando indicamos que puerto serie es el  que vamos a utilizar en la máquina local para comprobar que el otro nodo  está activo. Como nosotros utilizamos el COM1, hemos puesto /dev/ttyS0.  Si no utilizásemos puertos de serie para estas labores, no habría que  poner esta línea.
bcast eth2

Este comando indica que vamos a utilizar la tarjeta de red eth2 como  canal de heartbeat ethernet a través de paquetes broadcast. Si  utilizásemos otro interfaz distinto, especificaríamos el adecuado en  lugar de eth2.
Keepalive 2

Especifica cada cuanto tiempo enviamos señales a través de los  canales de heartbeat. En este caso, 2 segundos.
warntime 10

Esta línea dice cuanto tiempo debe de pasar para que el software de  alta disponibilidad comience a preocuparse de que no recibe señales del  otro nodo, y por ello escriba un mensaje "late heartbeat" en los logs.  En este caso, 10 segundos.
deadtime 30

Esto indica el tiempo en segundos que debe de transcurrir sin recibir  señales para considerar que el otro nodo con el que nos comunicamos por  los canales de heartbeat está muerto. Aquí son 30 segundos.
initdead 120

A veces al arrancar el sistema cluster, puede que una máquina se  arranque varios segundos desppués que la otra, o incluso que por  diversos motivos las máquinas arranquen a diferente velocidad. Este  parámetro indica que se puede esperar hasta 120 segundos por señales del  otro nodo al arrancar antes de considerar que está muerto.
baud 19200

Velocidad, en bps, a la que estará funcionando el canal de serie que  hemos definido anteriormente. Es importante que sea la misma en los dos  nodos.
udpport 694

Puerto UDP que vamos a utilizar para la comunicación broadcast a  través del interfaz que hemos definido anteriormente. Aunque podemos  cambiarle, el 694 es el puerto estándar definido para esto por el IANA.
auto_failback off

Este es un parámetro obligatorio que indica el comportamiento del  cluster cuando, tras una caída del nodo maestro(que es el que tiene  habitualmente el servicio), este vuelve a estar disponible. Si le  dejásemos en on, lo que indica que en el nodo maestro volverá a tomar  los servicios compartidos. En nuestro caso adoptar el valor off', por lo  que el nodo esclavo seguiría conservando los servicios.
node equipodiez
node equiposiete

Otro parámetro obligatorio. Éste sirve para indicar los nombres de  las máquinas de las que se compone el cluster. ¿Porqué aparece entonces  equipodiez en vez de equipodiez o equiposiete en lugar de equiposiete?  Simplemente porque aquí debemos de poner el hostname real de la máquina,  tal y como nos aparece al teclear uname -a y en nuestro caso esos  nombres son los que acabamos de especificar.
respawn hacluster /usr/lib/heartbeat/ipfail

respawn sirve para indicar los comandos que deben de ser lanzados por  el cluster con algún usuario del sistema y vigilados de forma que si el  proceso muere, los vuelva a lanzar (excepto si al salir indicase el  código 100). Esta línea en concreto lanza con el usuario hacluster el  comando ipfail encargado de la vigilancia de la conectividad a  direcciones IP.
ping_group red_cumulo 192.168.2.1 192.168.1.1 www.cisco.com

Este es un comando opcional. En el se define a través de sus  direcciones un grupo de máquinas externas al cluster llamado red_cumulo.  Utilizaremos éstas para verificar la conectividad con la red a través  de alguna utilidad como ipfail. Es importante escoger unas máquinas que  sean estables, para que realmente nos sirva para aumentar la fiabilidad  de los diagnósticos de cuando un nodo está o no funcionando  correctamente. Al ser un grupo de direcciones IP, con que una sola de  ellas esté disponible consideramos que la conectividad es correcta, lo  que nos ayuda a evitar los errores que se podrían provocar si alguna de  las máquinas estuviese indisponible por alguna causa.
haresources
El fichero haresources especifica los servicios de los que se  hace cargo el cluster, su método de arranque/parada así como quien es su  propietario por defecto. Este fichero debe de ser exactamente igual en  los dos nodos del cluster, o su funcionamiento no será correcto.
Este fichero consiste normalmente en una sola línea con una  estructura similar a esta:
<servidor> <IP> <servicio1>::<parametros1> <servicio2>::<parametros2> <servicio3>::<parametros3> ...

¿Que es lo que indica cada uno de estos elementos?:

En primer lugar hemos de indicar <servidor>, que se  refiere al nombre de la máquina que va a disponer de los servicios por  defecto en el cluster. Ha de ser el hostname de la máquina exacto, tal y  como aparece al teclear el comando uname -n.


Después especificamos <IP>, la dirección IP del cluster,  es decir, la que va a adquirir la máquina que esté controlando los  servicios. Es muy importante tener en cuenta que esta IP 'no debe de  estar configurada en ninguna de las máquinas, sino que será el software  de cluster el que se encarga de activarla y desactivarla, pues en caso  contrario provocaría conflictos. El adquirir la IP es la primera tarea  que se realiza al activarse un nodo del cluster, y el desactivarla la  última tarea (la que se realiza cuando se han completado el resto).


A continuación se indican, en orden de activación, los  diferentes servicios que se han de arrancar al activar un nodo (y  pararse al pararse el nodo, pero en orden inverso). El campo  <serviciox> se va a referir a un script de arranque concretamente  puede ser:




Un script de arranque/parada estándar de cualquiera de  los servicios del sistema, situado en el directorio /etc/init.d
Un script especial de heartbeat. Estos se almacenan en el  directorio /etc/ha.d/resource.d y los hay para diversas utilidades:  desde generar una alarma sonora, enviar un mensaje, cambiar el estado de  un volumen LVM, etc... Nosotros en concreto aqui utilizados dos:  drbddisk para poner como maestro o esclavo un disco y Filesystem para  montar o desmontar un sistema de ficheros.



Una vez hemos explicado estos conceptos básicos vamos a ver cual es  el fichero de configuración de recursos haresources que hemos  confeccionado para nuestro cluster. Aquí va:
equipodiez 192.168.2.12 drbddisk::r-cluster drbddisk::r-homes
Filesystem::/dev/drbd0::/etc/cluster::ext3::defaults,acl
 Filesystem::/dev/drbd1::/export::ext3::defaults,acl
 Filesystem::rpc_pipefs::/etc/cluster/nfs/rpc_pipefs::rpc_pipefs::defaults
 Filesystem::nfsd::/proc/fs/nfsd::nfsd::defaults nfs-common nfs-kernel-server

Como vemos, en primer lugar ponemos equipodiez, que es el nombre de  nuestro nodo maestro por defecto. A continuación, va la dirección IP de  servicio del cluster, 192.168.2.12. Tras esto, y siguiendo la lógica de  cambio de servicio que establecimos en el apartado “Arquitectura del  Cluster-HA” vienen detallados todos los servicios que se han de arrancar  con sus correspondientes parámetros:

drbddisk::r-cluster, que trabaja con la replicación de  información que estamos realizando a través de una red dedicada a través  del ejecutable /etc/ha.d/resource.d/drbddisk. Se encarga de pasar a  maestro en el nodo activo el recurso de almacenamiento r-cluster que  especificamos como parámetro.


drbddisk::r-homes, hace lo mismo que el anterior, pero  con el volumen r-homes que es en esta ocasión el parámetro.


Filesystem::/dev/drbd0::/etc/cluster::ext3::defaults,acl,  que se encarga del montaje de particiones a través del ejecutable  /etc/ha.d/resource.d/Filesystem. Hemos de indicarle exactamente la  manera de montar, para lo cual le especificamos un montón de parámetros:  el dispositivo que debe de montar (/dev/drbd0, que es el  correspondiente al volumen r-cluster que gemos activado), el punto donde  debe de montarlo (el directorio con la configuración del cluster  /etc/cluster en este caso), el tipo de sistema de ficheros que usa ese  dispositivo (ext3) y las opciones que debe de usar para su montaje (en  este caso las defaults habituales más acl para permitir el uso de listas  de acceso).


Filesystem::/dev/drbd1::/export::ext3::defaults,acl,  equivalente a la anterior pero que en este caso se encarga de montar el  dispositivo del volumen r-homes que contiene todos los datos que se  comparten por el servicio de cluster.


Filesystem::rpc_pipefs::/etc/cluster/nfs/rpc_pipefs::rpc_pipefs::defaults,  del mismo tipo que el anterior aunque en esta ocasión en vez de montar  un sistema de ficheros real crea uno virtual que necesita NFSv4 para  funcionar correctamente.


Filesystem::nfsd::/proc/fs/nfsd::nfsd::defaults, muy  parecido al anterior, pues es otro sistema de ficheros virtual que  precisa NFSv4.


nfs-common, hace referencia al fichero de arranque de  servicio /etc/init.d/nfs-common que se encarga de poner en marcha los  servicios fundamentales para que el kernel del sistema entienda NFSv4.


nfs-kernel-server, que hace referencia a otro servicio,  en esta ocasión el lanzado por /etc/init.d/nfs-kernel-server encargado  de poner en marcha los módulos del kernel necesarios para activar  nuestra máquina como servidor de NFSv4.

El orden utilizado aquí es importante, pues es utilizado por el  software de cluster y además, cambiarle implicaría un funcionamiento  incorrecto del sistema, ya que muchas tareas son dependientes de las  anteriores y en caso de no realizarse en el orden adecuado no  funcionarían. ¿Y de qué forma exacta funcionan?

Para el nodo que se convierte en inactivo, el software de  clister lanza los diversos scripts con stop como primer parámetro, y se  realizan las tareas en orden inverso:empezamos parando el servicio de  /etc/init.d/nfs-kernel-server y finalizamos después de acabar con el  resto de los servicio desconfigurando la IP del cluster del nodo que  pasa a inactivo.


En el nodo que se convierte en activo se invocan los scripts  poniéndoles como primer parámetro start, y en el orden indicado aquí  directamente: empezando por el cambio de IP y luego el resto de las  tareas, desde el paso a maestro del disco r-cluster hasta la ejecución  del servicio nfs-kernel-server.

Antes de finalizar recordamos de nuevo que este fichero debe de ser  exactamente igual en los dos nodos del cluster, por lo cual, en cuanto  lo hayamos editado en un nodo, tendremos que copiarle al otro.
authkeys
Este fichero nos determina la forma en la que los componentes del  cluster verifican su identidad entre ellos, así como la clave que  utilizan para ello.
El formato es el siguiente:
auth <número>
<número> <método_de_autenticación> [<clave>]

El parámetro más importante aquí es el del método_de_autenticación  que vayamos a usar. Hay tres métodos de autenticación posibles:

crc, que aplica un simple algoritmo de hash para autenticar al  nodo. Es el que menos recursos consume, el más conveniente si estamos  convencidos de la seguridad de nuestra red. Si la red no fuese segura,  este algoritmo nos expondría a ataques de falseo de la identidad de un  nodo. No necesita que se le proporcione clave alguna, pues el algoritmo  que usa para la autenticación es fijo e independiente de la clave.


md5 es el algoritmo recomendable si la red no es segura. Gasta  un poco de CPU en encriptar la comunicación a través de este algoritmo,  pero de esta manera la comunicación se hace bastante difícil de  falsificar por un atacante.


sha1 es el algoritmo más seguro, únicamente recomendable si  estamos realmente preocupados por la seguridad. Utiliza encriptación  asimétrica, que es prácticamente irrompible por un intruso, pero a  cambio penaliza a la CPU de cada nodo con una carga importante de  recursos.

Conocidos estos conceptos, es muy fácil explicar la utilidad de los  otros dos parámetros: número es simplemente un número cualquiera (por  ejemplo 1, 2 o 7) que ha de ser el mismo en las dos líneas del fichero y  clave la expresión que vamos a utilizar como clave para comunicarnos  entre los dos nodos.
El fichero concreto (bueno, excepto la clave que la hemos  cambiado por obvias cuestiones de seguridad) que empleamos en nuestro  cluster es el siguiente:
auth 1
1 md5 nuetra-clave-secreta

Al contener información de seguridad, es muy importante que este  fichero tenga permisos de lectura y escritura únicamente para el  propietario (por ejemplo, haciendo un chmod 600), pues si no nuestras  claves estarían al alcance de otros usuarios del sistema.
Y para el funcionamiento adecuado del sistema, obviamente,  también es imprescindible que utilicemos el mismo método de  autenticación y la misma clave en los dos nodos, pues en caso contrario  no lograrían entenderse entre si.
Puesta en marcha  del servicio heartbeat
Si hemos seguido los pasos anteriores ya debemos de tener el sistema  casi, casi listo para funcionar. Pero antes de ponerle en marcha todavía  nos quedan por hacer algunos pequeños retoques para dejar todo tal y  como queremos.
Como primer paso, vamos a verificar que el montaje de los  sistemas de ficheros necesarios para el buen funcionamiento del NFS está  establecido como manual, lo cual es necesario para dejar esta tarea en  manos de el servicio de alta disponibilidad, para que éste sea el  encargado de montarlo y desmontarlo según el estado del cluster. ¿Y como  lo hacemos? Simplemente tendremos que editar en los dos servidores el  fichero /etc/fstab y asegurarnos que tiene dos líneas como las  siguientes (y en caso de que no estñen así, modificarlo):
rpc_pipefs      /var/lib/nfs/rpc_pipefs rpc_pipefs      defaults,noauto        0       0
nfsd            /proc/fs/nfsd           nfsd            defaults,noauto        0       0

Una vez hecho esto, vamos a preparar las dos máquinas del cluster  para que tengan algunos enlaces simbólicos que van a hacer que los  ficheros de configuración de los servicios que están en alta  disponibilidad apunten a la localización adecuada dentro del directorio  /etc/cluster que tiene montado el nodo activo.
El primero de los ficheros que vamos a enlazar es exports,  encargado de especificar la configuración del servicio NFSv4. En primer  lugar, hemos de ir al nodo cuyos discos drbd están en modo de maestro,  que si hemos seguido los pasos será equipodiez. Lo comprobaremos  verificando el contenido del fichero /proc/drbd y verificando que el  disco aparece como Primary (es decir, que en la información que nos  aparecerá de los dos dispositivos lo que aparece escrito antes de la  barra / es Primary):
root@equipodiez:/ # cat /proc/drbd
	version: 0.7.7 (api:77/proto:74)
	SVN Revision: 1680 build by phil@wiesel, 2004-12-14 16:05:39
	 0: cs:WFConnection st:Primary/Secondary ld:Consistent
	    ns:0 nr:0 dw:170 dr:31 al:0 bm:3 lo:0 pe:0 ua:0 ap:0
	 1: cs:WFConnection st:Primary/Secondary ld:Consistent
	    ns:0 nr:0 dw:1168 dr:133 al:0 bm:22 lo:0 pe:0 ua:0 ap:0

Si todo aparece tal y como está aquí podemos seguir (si no  verificaríamos que es el otro nodo el que tiene esta configuración y  proseguiríamos en él). Lo que hay que hacer en el nodo con el disco como  maestro es montar el sistema de ficheros /etc/cluster y pasar el  fichero exports a este directorio, lo que haremos así:
root@equipodiez:/ # mount /etc/cluster
root@equipodiez:/ # mv /etc/exports /etc/cluster

Y a continuación creamos el enlace simbólico para que ahora, cada vez  que busque el fichero, vaya a encontrarlo a la nueva localización a  donde lo hemos movido:
root@equipodiez:/ # ln -s /etc/cluster/exports /etc/exports

Con esto ya listo en el nodo con el disco como primario, vamos a  pasar ahora al otro nodo, y allí únicamente tendremos que crear el  enlace simbólico:
root@equiposiete:/ # ln -s /etc/cluster/exports /etc/exports

Ya están listos los enlaces de exports, así que vamos a ponernos  manos a la obra con los enlaces al directorio /var/lib/nfs donde residen  los ficheros de estado de NFSv4. Para hacerlo en primer lugar iremos al  nodo donde hemos montado el directorio /etc/cluster en el paso  anterior, y procederemos a mover el directorio de estado NFS a éste  último directorio de la siguiente manera:
root@equipodiez:/ # mv /var/lib/nfs /etc/cluster/nfs

Ya que el NFS está desactivado, el comando moverá el directorio sin  problema alguno. Tras haberlo movido pasaremos a hacer el link simbólico  adecuado en este servidor.
root@equipodiez:/ # ln -s /etc/cluster/nfs /var/lib/nfs

Y ya que hemos grabado información en su interior, antes de que se  nos olvide vamos a desmontar el directorio /etc/cluster para dejarlo en  su situación original.
En el otro servidor del cluster, el que está con el disco como  "esclavo", vamos en primer lugar a borrar el directorio /var/lib/nfs, ya  que su contenido no nos va a interesar:
root@equiposiete:/ # rm -R /var/lib/nfs

Y a continuación creamos en este mismo servidor (el del disco  "esclavo") también el link:
root@equiposiete:/ # ln -s /etc/cluster/nfs /var/lib/nfs

Todos estos últimos pasos referentes al directorio /var/lib/nfs  pueden parecer un tanto extraños, y lo normal podía haber parecido dejar  cada servidor con su propio directorio. Sin embargo, todo esto tiene su  razón de ser, y es que en caso de que el sistema de alta disponibilidad  cambie de un nodo a otro va a haber cierta información, referente a  estado del servidor NFS, ficheros que se encontraban abiertos en ese  momento, y escrituras que podía haber a medias que se guarda ahí. En  caso de que no pasásemos esta información de un nodo a otro, perderíamos  todos estos datos de los ficheros con los que estamos trabajando en ese  instante.
Por último, aunque tenemos el script de arranque en init.d,  necesitamos que el servicio de heartbeat arranque cada vez que arranca  la máquina, lo que haremos tecleando en cada uno de los dos servidores:
# update-rc.d heartbeat default
	 Adding system startup for /etc/init.d/heartbeat ...
	   /etc/rc0.d/K05heartbeat -> ../init.d/heartbeat
	   /etc/rc1.d/K05heartbeat -> ../init.d/heartbeat
	   /etc/rc6.d/K05heartbeat -> ../init.d/heartbeat
	   /etc/rc2.d/S75heartbeat -> ../init.d/heartbeat
	   /etc/rc3.d/S75heartbeat -> ../init.d/heartbeat
	   /etc/rc4.d/S75heartbeat -> ../init.d/heartbeat
	   /etc/rc5.d/S75heartbeat -> ../init.d/heartbeat

Modificaciones en  el arranque de NFS
Un último detalle que vamos a tener en cuenta cuando arranque el  nuevo servicio de NFSv4 en cluster, es que éste no se va a ejecutar  sobre la dirección de red habitual de la máquina, sino que va a tener  que estar ligado a la dirección IP del cluster, que como hemos comentado  es la 192.168.2.12, también llamada a través del DNS nfs.cumulo.org.
Para que esto ocurra así vamos a tener que hacer unos pequeños  cambios en los ficheros de arranque de los servicios NFSv4 en los dos  servidos equipodiez y equiposiete. Concretamente:

Al fichero /etc/init.d/nfs-kernel-server vamos a tener darle  valor a la variable RPCSVCGSSDOPTS de la siguiente manera:

RPCSVCGSSDOPTS="-n nfs.cumulo.org"


Al otro fichero de arranque, /etc/init.d/nfs-common vamos a  tenerle que añadir una nueva línea, justo antes de la línea de

RPCGSSDOPTS, con el siguiente contenido:
STATDOPTS="-n nfs.cumulo.org"

Estas dos líneas que hemos modificado no hacen otra cosa que invocar  algunos de los demonios de NFS con un parámetro que indica la dirección a  la que hay que asociar el servicio, para que así arranque desde allí.
Montaje de los directorios de clientes
Ya, por fin, tenemos nuestro cluster de servidores listo para  funcionar, ofreciendo su almacenamiento de forma robusta y fiable para  quien lo quiera usar... Pero claro, falta que este espacio de  almacenamiento compartido sea utilizado desde clientes NFSv4, que en  nuestro caso se da la paradoja que aunque son clientes para NFSv4, serán  los servidores de otros servicios: Mozilla, Evolution, OpenOffice, SSH,  ... pero que utilizarán este almacenamiento compartido para guardar  configuraciones y ficheros personales de cada usuario.
Si bien nosotros nos hemos decantado por hacer un montaje del los  directorios de usuario de forma estándar, también detallamos como se  podría hacer un montaje ayudados de las utilidades autofs, que nos  permitiría aislar al máximo para cada usuario la parte del sistema de  ficheros que se monta, independizándola del resto.
Independientemente de qué método de los dos utilicemos, hemos de  tener en cuenta que antes de comenzar a montar el directorio en  cualquiera de las máquinas debemos de eliminar sus contenidos, pues en  caso contrario estarían ocupando espacio inútilmente. Si antes de ello  queremos hacer una copia de seguridad de los datos que hay en él  teclearíamos:
# scp -pr /home/* nfs.cumulo.org:/home/.

Y a continuación borraríamos sus contenidos con:
# rm -Rf /home/*

Montaje estándar
Disponemos de un directorio /home en la máquina local donde se  almacenan los perfiles de usuarios, el cual queremos que utilice el  espacio de nuestro sistema de almacenamiento NFSv4 nfs.cumulo.org.
Para conseguirlo debemos de dirigirnos al fichero /etc/fstab de  cada una de las máquinas y añadir en él la siguiente línea:
nfs.cumulo.org:/     /home    nfs4    	sec=krb5,rw,hard,intr,proto=tcp,port=2049,noauto    0      0

Cuando arranque el sistema ya se procederá al montado automático de  este sistema de ficheros, y si lo queremos hacer manualmente ahora sólo  tendremos que teclear:
# mount /home

Montaje con autofs
Disponemos de un directorio /home en la máquina local donde se  almacenan los perfiles de usuarios, el cual queremos que utilice el  espacio de nuestro sistema de almacenamiento NFSv4 nfs.cumulo.org.
Ahora, en lugar de realizar el montado de los directorios de  todos los usuarios a la vez, vamos a hacerlo con las utilidades autofs  que permiten montar únicamente los subdirectorios que se necesiten y  desmontarles cuando no sean necesarios, lo que aumenta la modularidad y  seguridad.
Para ello, lo primero que debemos de hacer es descargarnos el  paquete autofs que implementa este sistema de montaje automático:
# apt-get install autofs

Ahora vamos a proceder a la configuración de la utilidad de montaje  automático, que se centraliza a través del fichero /etc/auto.master. En  él definimos que directorios son los que se van a montar  automáticamente, en que otro fichero adicional vamos a almacenar su  configuración, y el tiempo que ha de pasar sin actividad para que el  sistema desmonte automáticamente cualquier directorio contenido en él.  En nuestro caso, para establecer 2 minutos de tiempo de inactividad para  el directorio /home este fichero /etc/auto.master tendría que ser tal  que:
#
	# $Id: auto.master,v 1.3 2003/09/29 08:22:35 raven Exp $
	#
	# Sample auto.master file
	# This is an automounter map and it has the following format
	# key [ -mount-options-separated-by-comma ] location
	# For details of the format look at autofs(5).
	/home  /etc/auto.home –timeout=120

Para describir lo que vamos a montar dentro del directorio /home,  acabamos de decir que vamos a utilizar un fichero llamado  /etc/auto.home. Por ejemplo, si nosotros quisiésemos montar en él lo que  comparte nuestro servidor nfs.cumulo.org a través de NFS4 autenticado  por kerberos, tendríamos que crear ese fichero con el siguiente  contenido:
	# This is for mounting user homes over NFSv4
	*      -fstype=nfs4,rw,sec=krb,proto=tcp,port=2049   nfs.cumulo.org:/&

Ya tenemos todo configurado, pero ahora falta poner el servicio  autofs en funcionamiento. En primer lugar vamos a crear los enlaces  simbólicos apropiados para que arranque y pare correctamente con el  sistema:
root@equipodiez:/etc # update-rc.d autofs defaults
	Adding system startup for /etc/init.d/autofs ...
	  /etc/rc0.d/K20autofs -> ../init.d/autofs
	  /etc/rc1.d/K20autofs -> ../init.d/autofs
	  /etc/rc6.d/K20autofs -> ../init.d/autofs
	  /etc/rc2.d/S20autofs -> ../init.d/autofs
	  /etc/rc3.d/S20autofs -> ../init.d/autofs
	  /etc/rc4.d/S20autofs -> ../init.d/autofs
	  /etc/rc5.d/S20autofs -> ../init.d/autofs

Y como querremos que el servicio se ponga a funcionar ya  directamente, lo haremos tecleando:
# /etc/init.d/autofs start

Así ya tendremos el montado automático funcionando y simplemente  entrando dentro del directorio /home y haciendo un cd a cualquier  directorio observaremos como se monta de forma automática.
Explicación del funcionamiento
Para la configuración de los terminales hemos utilizado una  versión modificada de LTSP adaptada a las peculiaridades de Cúmulo.
Los principales cambios con la versión original son el que a  nosotros nos interesa que en los terminales se ejecute primeramente XDM  para realizar la autentificación y posteriormente se cargue como  escritorio local IceWM.
La elección del escritorio se ha hecho en base a las necesidades y  buscando la sencillez junto con un bajo consumo de recursos.
Este escritorio tiene una configuración distinta para cada  usuario, que toma de cada directorio de usuario que se ha montado por  NFS. Hay iconos, que al pulsar sobre ellos, ejecutan el comando  necesario para que se ejecuten aplicaciones remotamente en el terminal  en que nos encontremos. Posteriormente se explica con más detalle este  particular.
En los terminales solamente se ejecuta el escritorio, por lo que  el consumo de recursos es mínimo independientemente de las aplicaciones  que se esten usando simultáneamente.
Un asunto importante es disponer de una buena configuración de  red perfectamente segmentada, ya que aunque las cargas de procesador y  memoria son bajas, el uso de la red es continuo y elevado.
Personalización del directorio raíz
Instalación de aplicaciones y librerías locales en directorio raíz
Para poder ejecutar un aplicación en un terminal es necesario copiar  todos los componentes de esa aplicación en un lugar accesible para el  terminal. Ese lugar será el directorio raíz que montamos por NFS.
Una manera simple y sencilla de conseguir esto sería instalar las  aplicaciones directamente en el servidor y montar en el cliente los  directorios /bin, /usr, /lib ... Sin embargo esto no es una buena  solución. En primer lugar estamos compartiendo un montón de archivos y  directorios que el  terminal no necesita, no es que se pierda  rendimiento, pero no es necesario hacerlo así. En segundo lugar, y la  verdadera razón de no utilizar este método, es que el servidor puede  tener distinta arquitectura que el cliente, de hecho esto casi siempre  sucede. Por tanto un cliente Pentium(i586) o inferior no va a poder  ejecutar aplicaciones de un servidor Pentium II(i686) o superior.
La mejor solución es configurar un árbol de directorios con todas  las aplicaciones y librerías que el terminal necesite,  independientemente de lo que haya en el servidor o de su arquitectura.
LTSP viene con varias aplicaciones ya instaladas, y hay otras  opcionales como Netscape, de las cuales se puede descargar el paquete  del ejecutable con las librerías para copiarlo tal cual en el árbol de  directorios. Pero ciertas aplicaciones necesarias en Cúmulo no están  disponibles de esta manera.
Para poder instalar aplicaciones manualmente necesitamos hacer  uso del comando ldd. Ldd muestra en pantalla las librerías requeridas  por el programa o librería que le sea pasado como parámetro en la linea  de comandos.
Por ejemplo, en el caso que nos acontece, si queremos conocer las  dependencias del programa xdm, que necesitamos que sea ejecutado en los  terminales, haríamos lo siguiente:
user@sevidor:~$ ldd /usr/bin/X11/xdm
        linux-gate.so.1 =>  (0xffffe000)
        libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0xb7fcc000)
        libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0xb7fb7000)
        libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0xb7f68000)
        libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0xb7f5f000)
        libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0xb7f47000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xb7f3a000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb7e74000)
        libXau.so.6 => /usr/X11R6/lib/libXau.so.6 (0xb7e71000)
        libXdmcp.so.6 => /usr/X11R6/lib/libXdmcp.so.6 (0xb7e6c000)
        libpam.so.0 => /lib/libpam.so.0 (0xb7e64000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7e61000)
        libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7e34000)
        libXinerama.so.1 => /usr/X11R6/lib/libXinerama.so.1 (0xb7e30000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d07000)
        /lib/ld-linux.so.2 (0xb7feb000)

Aquí se observa lo que antes se comentaba, que al encontrarnos en una  arquitectura i686, muchas librerías son especificas de esa  arquitectura. Se puede resolver de dos maneras. Podemos sustituir las  librerías dependientes por otras específicas de la arquitectura destino.  Una mejor solución sería realizar el mismo proceso en un ordenador con  la arquitectura deseada y luego copiar el programa y sus dependencias al  árbol de directorios.
Personalización del arranque de LTSP
Una vez hayamos instalado los programas deseados necesitamos indicar  al sistema que debe utilizarlos cuando inicie, en vez de los habituales  de LTSP.
El script linuxrc del initrd ha lanzado una serie de procesos,  entre ellos configurar la red y montar el raiz por NFS. Después de esto  llama al init. El init es el proceso padre de todos los procesos.
El principal objetivo del init es crear procesos a partir del  script almacenado en al archivo /etc/inittab.
Inittab tiene muchas posibilidades de configuración, pero en lo  que a LTSP ser refiere nos interesa que hace una llamada a otro script,  este localizado en /etc, llamado screen_session.
Este nuevo script realiza un serie de comprobaciones en base a la  configuración de LTSP que tenga el sistema. Tras comprobar que se desea  arrancar en entorno gráfico de nuevo vuelve a llamar a otro script,  startx.
Este archivo es el que realmente nos interesa, hasta aquí todo el  proceso de arranque es identico al de LTSP. A partir de ahora en vez de  intentar establecer una conexión a un servidor XDMCP se va a lanzar  localmente xdm para proceder a la autentificación y luego este muestra  el escritorio IceWM con la configuración de cada usuario.
Para conseguir esto hay que hacer un par de cambios en el archivo  “/etc/screen.d/startx”
Simplemente hay que sustituir unas lineas de este script para que  llame a xdm en vez de conectar a un servidor XDMCP. Debemos modificar  las lineas
 /usr/X11R6/bin/${XBINARY} ${ACC_CTRL}              \
                              ${XF_ARGS}               \
                              -xf86config ${XFCFG}     \
                              vt${TTY} ${DISP}

por la ruta de xdm con los argumentos correspondientes.
En este caso con invocar xdm sin parámetros es suficiente, ya que  utilizaremos la configuración por defecto. La única personalización que  hay que realizar es procurar que en cada home de usuario el archivo  $HOME/.xsession tenga el siguiente contenido:
exec icewm

Esta será la información que leerá xdm y por tanto cargará dicho  escritorio.
Con esto ya tenemos el sistema funcionando de forma local a la  espera de que el usuario lance las aplicaciones pulsando sobre los  iconos.
Comparativa de escritorios
Una decisión importante para el correcto funcionamiento de los  terminales, como hemos comentado anteriormente, consiste en decidir si  los terminales únicamente se limitarán a mostrar la información por  pantalla que se procesa en los servidores ó se encargarán de ejecutar  localmente el sistema de X-Window, lo que se conoce como escritorio  local. En el caso de que la solución que se haya escogido permita esta  opción, cobra especial importancia el escritorio ó gestor de ventanas  escogido para mostrar al usuario el escritorio de trabajo, ya que no  debemos olvidarnos de la escasa potencia con la que cuentan los clientes  ligeros para realizar estas tareas.
Existen gran cantidad de entornos de ventanas para sistemas  Linux, cada uno de los cuáles tiene unas características concretas que  los hace idóneos para una u otra situación. Entre ellos, los más  adecuados para nuestro propósito son:

KDE
KDE (K Desktop Environment) es uno de los entornos de escritorio más  utilizados, junto a GNOME. Es un escritorio muy completo y configurable  que se distribuye conjuntamente a las distribuciones Linux más  populares, y que cuenta con un enorme grupo de desarrollo detrás. Del  mismo modo, cuenta con gran cantidad de aplicaciones espefícas del  escritorio, que cubren la casi totalidad de las necesidades básicas de  la mayoría de usuarios. Por todo lo comentado, KDE necesita una cantidad  razonable de memoria RAM, por lo que no supone una opción real de cara a  ser utilizado como escritorio local de los clientes ligeros, no así en  el caso de que sea el servidor el que ejecute las X-Window, en cuyo caso  constituye una muy interesante opción, al tratarse de un entorno que  guarda ciertas similitudes con Microsoft Windows, por lo que los  usuarios podrían acostumbrarse más rápidamente al cambio.









Gnome
Gnome (GNU Network Object Model Environment) es el otro entorno de  escritorio más utilizado en sistemas Linux. Al igual que KDE, es un  completo entorno de escritorio altamente configurable que se distribuye  con la mayoría de distribuciones Linux (entre ellas Ubuntu, la  distribución escogida para el proyecto Cúmulo). Del mismo modo, al igual  que KDE, exige una determinada cantidad de memoria RAM para ejecutarse  con la que no cuentan los clientes ligeros que se pretenden utilizar.









XFCE
XFCE es un entorno de escritorio relativamente joven que pretende  ofrecer al usuario un entorno amigable con posibilidades de  configuración y con un uso de memoria bastante limitado (del orden de  algo más de  32MB RAM bastarían en una configuración típica). Es  posiblemente el entorno de escritorio que ofrece un mejor balance entre  rendimiento y consumo de memoria.









IceWM
A diferencia de los entornos de escritorio comentados hasta el  momento, que cuentan con enormes posibilidades de configuración,  aplicaciones propias y unas interfaces enormemente llamativas, IceWM  tiene como principio de existencia el compromiso entre consumo y  prestaciones, resultando en un entorno de escritorio casi completamente  vacío de utilidades superfluas y cuyo objetivo principal es el bajo  consumo de memoria (en torno a los 2-3 MB) proporcionando una entorno  ligero de ejecución de aplicaciones. Al igual que el resto de entornos  de escritorio, dispone de una gran cantidad de temas con lo que podremos  modificar el aspecto gráfico del sistema para facilitar su utilización  por los usuarios.









WindowMaker
WindowMaker es otra alternativa a tener en cuenta si contamos con  escasos recursos de memoria en el ordenador, ya que proporciona un  interesante gestor de ventanas con bastantes opciones de configuración y  con una utilización muy limitada de memoria.









Nuestra elección
Teniendo en cuenta que los terminales que vamos a utilizar cuentan  únicamente con 32 MB de RAM, en el caso de que se opte por una solución  en la que los terminales ejecuten un escritorio local, Gnome y KDE dejan  de ser alternativas viables, para quedarnos con IceWM, WindowMaker y  XFCE.
Entre estos tres gestores ligeros de ventanas, nos decantamos por  IceWM, de menor consumo de memoria RAM que los otros dos, con  una interfaz amigable e intuitiva para usuarios noveles y que permite  unas posibilidades de configuración suficientes para nuestro propósito,  como son una completa selección de temas, una sencilla modificación de  los menús y accesos directos a aplicaciones mediante ficheros de  configuración, etc.

Carga de aplicaciones remotas
El sistema completo de Thin Servers for Thin Clients se basa en  la ejecución remota de aplicaciones, que es lo que permite en la  práctica que los terminales ligeros puedan resultar de utilidad a los  usuarios.
X Window
El sistema X-Window es un sistema completamente independiente del  sistema operativo que se encarga de dotar de una interfaz gráfica al  sistema Linux. Así, X11 (que es como se denomina a la versión actual del  protocolo) actúa con un esquema de cliente-servidor para proveer el  servicio de representación gráfica a las aplicaciones que actúan como  clientes del servidor X-Window; este servidor sería el encargado de  comunicarse con la tarjeta de video para dibujar las imágenes en  pantalla, y leer las entradas del ratón y del teclado.
X-Window tiene capacidad de trabajar en la red, ésto significa  que podemos ejecutar una aplicación en un equipo e indicar al servidor  X-Window que envíe la información gráfica para representar en pantalla a  otro equipo conectado a la red, que es lo que estamos buscando. Por lo  tanto, podríamos estar ejecutando una aplicación en un servidor mientras  que la interfaz gráfica de usuario se muestra en otro ordenador con  total transparencia para el usuario que está accediendo al terminal  ligero.
Cuando una aplicación gráfica se ejecuta consulta la variable de  entorno DISPLAY que le indica a qué pantalla debe enviar sus gráficos.  Si el ordenador indicado por la variable permite poder recibir esta  información el servidor X-Window envía la información gráfica a dicho  equipo. Para que los equipos admitan la recepción de esta información  del servidor X, existen básicamente dos métodos:
xhost
# xhost +equiposervidorx

Este comando permite que las aplicaciones que están ejecutándose en  el equipo indicado (equiposervidorx) puedan acceder a la pantalla del  terminal.
xauth
Este método de autentificación para ejecución remota de  aplicaciones permite una mayor flexibilidad que la anterior, ya que  controla los permisos a nivel de usuario mediante el empleo de una  cookie. Esta cookie está situada en el directorio personal (/home) de  cada usuario en el fichero /.Xauthority y permite enviar al servidor X  que disponga de la misma cookie que la situada en el directorio personal  del usuario la información gráfica.
# xauth merge ~usuario/.Xauthority

Este comando se debe ejecutar en el servidor para permitir que las  aplicaciones que ejecute usuario puedan enviar su información gráfica  remotamente.
Una vez autentificado el equipo que va a recibir la información,  sólo nos queda indicar al servidor X dónde debe enviar la información  gráfica; para ello, y como hemos comentado antes, modificamos la  variable de entorno DISPLAY:
# export DISPLAY=terminal:0:0

Todo esto se simplifica y mejora si realizamos la conexión al  servidor remoto mediante SSH.
SSH
SSH es un protocolo de acceso a máquinas remotas similar a rsh ó  rlogin que utiliza métodos de cifrado para conseguir comunicaciones  seguras entre las máquinas.
SSH, a diferencia de otros protocolos similares, permite  redirigir el tráfico de las X con lo que podemos ejecutar remotamente  aplicaciones gráficas si tenemos un servidor X arrancado como hemos  explicado en el apartado anterior.
Para permitir esta ejecución y transmisión remota de información  gráfica de aplicaciones es preciso modificar el archivo de configuración  del demonio de ssh (/etc/ssh/sshd.conf) añadiendo la siguiente línea
X11Forwarding yes

SSH utilizar un sistema de keys para la autentificación en el  servidor, estas keys consisten básicamente en un número codificado y  encriptado mediante los algoritmos RSA ó DSA. Por lo tanto, para  permitir la conexión sin tener que insertar contraseña un método  consiste en introducir en la lista de claves autorizadas del servidor  las claves privadas de los equipos que queremos utilicen este servicio.
Esto se consigue ejecutando en el terminal el siguiente comando
# ssh-keygen

Este comando crea una clave pública y otra privada, mediante el  algoritmo que le indiquemos (ssh-keygen -t rsa para utilizar el  algoritmo RSA //// ssh – keygen -t dsa para utilizar el algoritmo DSA).  Estas claves se guardan en el directorio ~/.ssh, y la clave pública  generada sería la que hay que añadir al fichero de claves autorizadas  del servidor (~/.ssh/authorized_keys).
Instalación de aplicaciones
Una de las grandes ventajas del sistema Cúmulo es su gran  escalabilidad, que permite grandes posibilidades de ampliación en todos  los apartados, como el que nos ocupa de las aplicaciones de las que  dispondrán los usuarios de los terminales ligeros. Como hemos comentado con anterioridad, la sala de informática sobre la  que se llevará a cabo el proyecto va a ser utilizada casi en  exclusividad por estudiantes de Ingeniería Informática, por lo que en un  principio sería importante que entre las aplicaciones a las que  pudieran acceder (todas ellas de software libre) se incluyeran  compiladores de los distintos lenguajes de los que pudieran hacer uso y  algún entorno de programación avanzado, además de las clásicas  aplicaciones de navegación web, procesador de texto, etc. Todas estas  aplicaciones se ejecutarán en los servidores (hay que recordar que  existe una opción anteriormente expuesta de ejecutar determinadas  aplicaciones localmente en el cliente ligero) y se mostrarán al usuario  en el gestor de ventanas elegido, que en nuestro caso es IceWM.
Software necesario
La sala de informática F5 no es una sala de acceso libre a todos los  estudiantes de la Universidad de León, sino que es utilizada únicamente  por ciertos grupos de usuarios (estudiantes de 1º de Ingeniería  Informática principalmente) y solo a determinadas horas, lo que  determina en gran medida el tipo de aplicaciones que serán necesarias  para adecuarse a sus usuarios.
En todo tipo de entornos educativos en los que se utilicen  ordenadores, hay ciertas aplicaciones que están presentes y que resultan  de gran utilidad, como son el indispensable navegador web para acceder a  Internet, una suite de ofimática que permita la edición de textos, la  utilización de hojas de cálculo y la creación de presentaciones de  diapositivas, y un editor de textos ligero para pequeñas ediciones que  no requieran el formateado de los completos editores de texto de las  suites ofimáticas. A todo esto hay que añadir un entorno de desarrollo  de aplicaciones que permita una programación más intuitiva que la  lograda al escribir las líneas de código directamente en los sencillos  editores de texto, y por supuesto los distintos compiladores que  requieran los usuarios (típicamente Pascal, C y Java).
Teniendo en cuenta todos estos factores y utilizando para todas  estas necesidades aplicaciones de software libre, las siguientes son las  elecciones para cada categoría.
Mozilla Firefox
Está claro que el navegador web es una de las aplicaciones más  utilizadas (sino la que más) en este tipo de salas de informática, por  lo que en este sentido es importante que el servidor que lo ejecute  pueda soportar con solvencia numerosas instancias del explorador  ejecutándose. Mozilla Firefox es una navegador de amplia utilización,  completo, fiable y con grandes opciones de personalización, que utiliza  una cantidad de memoria RAM bastante destacable, a pesar del ahorro que  supone que las diversas instancias están ejecutándose en el mismo  servidor.









La versión que utilizaremos será la 1.0.7, que podremos encontrar en  la página web de Mozilla (http://www.mozilla.org)  ó instalar con el procedimiento típico de apt-get, aunque la mayoría de  distribuciones actuales la incluyen como navegador predeterminado,  incluida Ubuntu, que es la que utilizarán los servidores.
OpenOffice.org
OpenOffice.org es una completa suite de ofimática que incluye algunas  de las aplicaciones más populares en este campo, como pueden ser un  procesador de textos y editor HTML (OpenOffice Writer), una hoja de  cálculo (OpenOffice Calc) ó una herramienta de creación de  presentaciones (OpenOffice Impress).
La interfaz de todos estas aplicaciones es bastante similar a la  de la popular suite Microsoft Office, por lo que a los usuarios no les  resultará difícil acostumbrarse a ellas. Además, aparte de trabajar con  su propio formato de archivos, es bastante compatible con los archivos  generados por por el procesador de textos de Microsoft Office, y tiene  opciones de exportar los documentos al muy utilizado formato PDF de  Acrobat.









La versión que utilizaremos es la última versión estable,  OpenOffice.org 1.1.5, pero ya existe una versión 2.0beta con numerosas  mejoras pero aún con ciertos errores de diverso tipo que podría ser  utilizada. Podemos encontrarla en http://www.openoffice.org.
Gedit
Gedit es un sencillo editor de texto al estilo del popular Bloc de  Notas de Microsoft Windows, que permite realizar las labores de edición  básica de este tipo de programas, como son copiar y pegar, búsquedas,  reemplazar texto, etc. En una sala que va a ser utilizada por  estudiantes de informática es bastante usual el uso de este tipo de  editores sencillos para ediciones en el código de las aplicaciones que  estén desarrollando los estudiantes.









La versión que utilizaremos es la última versión estable de esta  aplicación, que forma parte del proyecto Gnome, es Gedit 2.12, y puede  ser encontrada en http://www.gnome.org/projects/gedit/.
Elección de los  servidores
Antes de ponernos a instalar las aplicaciones es necesario llevar a  cabo un pequeño estudio de los recursos con los que contamos en cuanto a  servidores (especialmente en cuanto a memoria RAM) para poder realizar  una distribución equilibrada de la carga de trabajo entre los distintos  servidores. Contamos con ocho ordenadores que serán utilizados como  servidores (ver Anexo 1), por lo que teniendo en cuenta que dos de ellos  (Equipo 7 y Equipo 10) van a ser utilizados para el clúster NFS que  almacene la información de los usuarios, otros dos (Equipos 5 y 6)  debido a su limitadísima cantidad de memoria van a ser utilizados como  servidores DNS, y uno de ellos se encargará de los distintos servicios  de red y de arranque de los terminales enviándoles las correspondientes  imágenes, nos quedan 4 equipos para procesar las distintas aplicaciones.  De la correcta repartición de las aplicaciones en estos equipos  dependerá gran parte del rendimiento global del sistema.
El acceso a Internet es típicamente el principal uso que se va a  dar a la sala, con utilización simultánea del navegador web por gran  parte de los usuarios, por lo que el Mozilla Firefox se debe  ubicar en un servidor con una cantidad de memoria RAM importante. Por  ello, el Equipo 1 (ver Anexo 1) es el más indicado para ejecutar  el Mozilla Firefox, ya que cuenta con unas características bastante  apropiadas para este cometido.
La suite de ofimática OpenOffice.org es otra aplicación  bastante utilizada, especialmente el procesador de textos, y exige una  muy considerable cantidad de memoria RAM y capacidad de proceso. El Equipo  2 (ver Anexo 1) resulta apropiado para ejecutar estas aplicaciones.
El editor de texto Gedit es también bastante utilizado  como hemos comentado anteriormente, pero su baja utilización de recursos  permite varias posibilidades a la hora de ubicarlo en los servidores.  El Equipo 4 (ver Anexo 1) puede ser suficiente para esta  aplicación.
En caso de querer añadir un entorno de programación avanzado nos  queda únicamente el Equipo 9 (ver Anexo 1), a no ser que queramos  compartir un servidor para que ejecute varias aplicaciones, opción  perfectamente viable pero teniendo en cuenta que en un principio el  número de aplicaciones que se ofrecerán es bajo, nos podemos permitir  una distribución independiente de cada una. Este tipo de aplicaciones  (como puede ser Eclipse – http://www.eclipse.org)  consumen mucha memoria RAM y una requieren una capacidad de proceso  importante, así que es probable que se necesiten recursos hardware extra  si se utilizan con asiduidad.

Conclusiones
Llegados a este punto, y después del análisis de las  posibilidades de implementación de soluciones de clientes ligeros y de  la implementación concreta llevada a cabo en la Universidad de León,  cabe realizar un repaso a lo beneficioso de la aplicación de estas  tecnologías. La estrategia comentada de Thin Servers for Thin Clients  (TS4TC) proporciona evidentes ventajas de diversa índole; los beneficios  que nos pueden dar la implantación y puesta en práctica de este tipo de   sistemas son los siguientes:
Beneficios técnicos

Servidor de procesamiento centralizado:

Potencia de ejecución. Mejoramos el procesamiento de la  información debido a que existen unos puntos centrales de proceso que  realizan todas las operaciones antes de mostrar sus resultados en los  terminales ligeros. Del mismo modo, al ejecutarse todas las instancias  de las aplicaciones en un mismo servidor se produce una optimización del  rendimiento al producirse una utilización conjunta de las librerías por  parte de todos los usuarios que estén ejecutando dicha aplicación.
Almacenamiento. El servidor almacena toda la información  ya que como hemos dichos los clientes carecen de discos duros aunque  físicamente pueden tenerlos. De este modo, los usuarios pueden acceder a  sus archivos desde cualquiera de los terminales ligeros.
Aplicaciones. La instalación de las aplicaciones se  centraliza en los correspondientes servidores reduciendo el tiempo de  configuraación de los equipos.
Datos. Unos servidores pueden encargarse de ejecutar  ciertas aplicaciones pero también habrá otros cuya función es únicamente  almacenar información de los clientes.




Único punto de administración:

Configuración. Se facilita la configuración del sistema teniendo  una mayor flexibilidad al no ser necesario configurar todos y cada uno  de los equipos.
Actualización. La instalación de los programas sólo se realiza  en el servidor correspondiente, evitando el tener que instalarlos en  todas las máquinas que así lo requieran.
Backups. Como toda la información se guarda en los servidores  encargados de dicha tarea se facilita la realización de copias de  seguridad.
Seguridad. Aumenta considerablemente la seguridad debido a que  todo el sistema de acceso, autenticación, etc. se controla desde una  única máquina.




Visualizador de escritorio: Los terminales al no tener  discos de almacenamiento muestran en el escritorio lo que se está  ejecutando en el servidor.


Transparente al Desktop (Windows, Gnome, KDE...): Podemos  tener cualquier tipo de escritorio, ya que la ejecución en los  servidores se realizará siempre de la misma forma, lo único que cambiará  será la apariencia en los terminales.

Beneficios económicos

Enorme reducción de TCO:

El control del gasto a la hora de instalar unas infraestructuras  tecnológicas, ha llevado al planteamiento de cuáles son los costes  reales (no sólo el precio del ordenador) de la adquisición y  mantenimiento de nuevos equipos. Para ello se ha acuñado el término TCO,  Total Cost of Ownership (coste total de propiedad). Al coste inicial  hay que añadir toda una serie de costes directos e indirectos.
Algunos estudios, afirman que sólo el 25% del coste total  corresponde a la compra del SW y HW propiamente dicho, y existe un 30%  de costes ocultos o no presupuestados.  Podemos citar algunos ejemplos:  reparación de ordenadores, instalación y actualización de nuevo SW,  mantenimiento, coste energético…
Con los datos expuestos, se observa que ninguna empresa puede  pasar por alto este nuevo concepto, por la importancia económica que  representa. Sabiendo lo que es a grandes rasgos el TCO, comprendemos en  mayor profundidad la enorme ventaja que representan los thin client,  sobre todo en el formato que presentamos:



Ahorro en la adquisición de equipos.
Ahorro energético.
Si utilizamos SW libre, ahorro en licencias.



Podemos citar dos datos:



Entre un 45 y un 54% (Gartnert)
Nuestra cifra está en torno al 66% si además el desktop es  software libre.




Punto de inversión único: Reutilizando HW en los  terminales sólo será necesario invertir en los servidores. De todas  formas, como es nuestro caso, también es posible reutilizar los  servidores. Así el ahorro económico es total.


Posible reutilización o reciclado de HW: Se pueden  reutilizar equipos obsoletos siempre que cumplan con unas mínimas  características técnicas (Pentium I y 32 MB de RAM) para ser utilizados  como terminales de acceso, mientras que para ser utilizados como  servidores podemos utilizar igualmente ordenadores de todo tipo,  dependiendo del servicio que vaya a prestar cada uno de ellos.


Bajo coste para adquirir nuevo HW: Si no se dispone de  ordenadores para reutilizar se puede adquirir nuevo HW que en ningún  caso va a salir excesivamente caro ya que buscaremos equipos sin grandes  características de hardware como los explicados anteriormente.

Beneficios de gestión

Punto de administración único: Las tareas de gestión se  realizarán en un único sitio estando centralizadas, disminuyendo de esta  forma el tiempo de gestión.


Simplifica la actualización de SW: Si vamos a añadir  nuevas aplicaciones o a actualizar las ya existentes sólo lo tendremos  que realizar en los servidores y así ya lo tendremos en los clientes.


Los recursos remotos se limpian en cada reinicio: Se  facilita la gestión de memoria y tiempo de ejecución limpiando en cada  reinicio los recursos utilizados en cada interacción remota.


Ayuda a otras puestas en práctica: Si queremos agregar  una nueva máquina sólo tendremos que enchufar el HW y en unos minutos  tendremos un terminal totalmente operativo con SW instalado,  configurado, actualizado y testeado.

Beneficios de usuario

Transparente a los usuarios: Los usuarios ven su terminal  como un ordenador normal porque ellos podrán realizar las mismas tareas  que en cualquier otro equipo independientemente de que no dispongan de  disco duro.


Realce del lugar de trabajo: El login de usuario es  independiente de los terminales, dando la posibilidad de registrarse en  distintas terminales ubicadas geográficamente dispersas.


Funcionamiento creciente: El usuario trabajará cada vez  con más frecuencia con los terminales debido a que sentirá que su  terminal trabaja independiente de los servidores ya que podrá ejecutar  cualquier aplicación sin problemas.


Visualización de escritorio: El usuario tendrá ante sí un  escritorio exactamente igual que otro PC y para él será transparente  dicha función.


Información de usuario: el usuario tiene acceso a su  información con independencia del ordenador desde el que acceda al  sistema.

Beneficios ecológicos

Ahorro de energía: Los clientes consumen menos energía y  son más silenciosos, evitando así la contaminación acústica.

Este ahorro aparece como consecuencia directa de que los thin clients  no disponen de disco duro, y surge de forma espontánea al realizar el  procedimiento.
Es muy importante en países desarrollados donde todas las  empresas en mayor o menor medida disponen de un sistema de información,  con muchos equipos y muchas horas encendidos.
La ventaja se puede apreciar en dos vertientes:



Económica: El disponer de equipos con un consumo  menor, sin que ello repercuta en una perdida de potencial, supone otro  factor que reducirá el TCO. Debido a la reducción de la factura  eléctrica.
Ecológica: A la reducción de residuos electrónicos, hay  que sumar la de electricidad consumida. Lo cual es muy importante en  países desarrollados donde todas las empresas en mayor o menor medida  disponen de un sistema de información, con muchos equipos y muchas  encendidos.



Para demostrar la existencia de este ahorro energético, podemos citar  los siguientes estudios:



Según Thin Client Computing: un thin client consume la  séptima parte de la energía consumida por un PC, lo que supondría un  grandísimo ahorro de electricidad.
Según Network Computing Devices Inc., "Power to the People:  Comparing Power Usage for PCs and Thin Clients in an Office Network  Environment", se destacan los siguientes aspectos:




Los thin client consumen siete veces menos energía que  los PCs.





69 vatios contra 10 vatios. Además de utilizar menos energía, también  generan menos calor. Añadiendo este factor de enfriamiento, la energía  total utilizada es de 103,5 vatios en un PC y de 15 en un thin client.





Una red de thin clients consume menos energía  que una de PCs, entre un 30% - 60% menos.
El ahorro energético se incrementa en la medida que la red de  thin client se hace más grande.




El estudio de Wyse Technology Inc, “Desktop Energy Consumption A  Comparison of Thin Clients and PCs”. Realiza una comparativa entre,  tres tipos de thin client distintos, con dos pcs, obteniendo la  siguiente tabla:






Tipo de dispositivos en el cliente
Un ordenador
100 ordenadores
1000 ordenadores
5000 ordenadores


3200
92 watts
9200 watts
92000 Watts
460000 Watts


3630
24 watts
2400 watts
24000 Watts
120000 Watts


8230
93 watts
9300 watts
93000 Watts
465000 Watts


PC
170 watts
17000 watts
170000 Watts
850000 Watts



Esta tabla nos permitirá calcular el gasto aproximado en electricidad  de los ordenadores clientes de una empresa atendiendo a la siguiente  formula:
n*p*h*52 = número de kWh por año donde:
n es el número de aparatos.
p es la energía consumida por cada aparato.
h número de horas de trabajo por semana.
52 es el número de semanas.
Multiplicando el resultado por el precio del kWh, vemos que la  cifra anual es realmente alta.

Reducción de residuos electrónicos: Al no necesitar  ningún disco de almacenamiento ni lector de cd-rom y casi ningún  periférico se obtienen terminales de menor peso, más pequeños y pueden  ser movidos más fácilmente sin posibilidad de dañarse.

Posibles inconvenientes
Los únicos posibles inconvenientes que nos podemos encontrar al  implantar este tipo de sistemas son los siguientes:

Aspectos socio-culturales. La mentalidad Microsoft puede  hacer que descartemos este tipo de soluciones cuando en realidad  tendremos las mismas o más prestaciones con la puesta en práctica de  este sistema cliente-servidor.


Saturación o sobrecarga de la red. Tendremos que analizar  la cantidad de tráfico que puede tener la red para no encontrarnos con  sorpresas desagradables que degraden el rendimiento del sistema o que lo  hagan inviable, sobre todo teniendo en cuenta que la red entre  servidores y clientes es de 10 Mbps y el sistema elegido para cargar el  sistema en el cliente ligero es mediante NFS (Network File System).


Bajo rendimiento para aplicaciones gráficas en 3D. Cada  terminal tendrá una memoria de 32 MB aproximadamente y unos procesadores  del tipo Pentium I con lo que no podemos esperar que den buen  rendimiento con aplicaciones gráficas de 3D.