Previamente se dará un repaso para tener las nociones básicas sobre el ensamblaje del hardware necesario para la construcción de este tipo de computadoras minimalistas. De esta manera si los nodos ya son funcionales7.1, podrás pasarte los primeros apartados. A continuación se exponen esquematicamente los diálogos de comunicación entre nuestras computadoras, a fin de hacer comprender mejor el funcionamiento y poder detectar disfunciones con mayor precisión en el caso de no obtener una rápida puesta en marcha del sistema.
Aquí cubriremos todo el proceso de construcción de un cluster con una política de máquinas centrales -servidores- que servirán los servicios necesarios a un conjunto de nodos que poseerán los componentes hardware mínimos para funcionar -clientes-: desde la construcción de nodos minimalistas hasta su puesta en marcha con linux. Empecemos pues con lo tangible, las piezas.
Componentes hardware requeridos
Como ya se ha indicado, en este tipo de clusters tendremos dos tipos de computadoras: los servidores y los clientes.
Los servidores serán máquinas completas, entendiendo como tal un ordenador manejable localmente a través de su teclado, ratón y con la salida estándar direccionada a un monitor. Los clientes serán nodos con los mínimos componentes para funcionar. Éstos son, para cada uno:
- fuente de alimentación -a su vez podrá alimentar varios nodos si sabemos cómo realizar las conexiones-.
- placa madre -motherboard- con soporte de arranque por red.
- procesador -cpu-.
- memoria -entendiendo memoria principal de acceso aleatorio RAM-.
- y tarjeta de red con soporte de arranque por RPL (Remote Program load).
PRECAUCIONES: Deberemos prestar máxima atención a las compatibilidades entre las piezas que hayamos adquirido, puesto que resulta sumamente desagradable descubrir tras días de pruebas que todas ellas funcionan correctamente por separado, pero no en conjunto. Los problemas de temperatura, sobretodo de los procesadores, también son de máxima importancia, puesto que quemarlos no entra dentro de los objetivos a cubrir. Otra manera de reducir el riesgo de averías es trabajar siempre desconectado de la red eléctrica mientras trabajemos con las tarjetas y demás componentes.
Componentes hardware prescindibles
Para enfatizar aún más sobre lo que NO es necesario cabe mencionar, como componentes estándar, los siguientes:
- monitor, pantalla y targeta gráfica.
- teclado.
- ratón -mouse-.
- discos duros.
- diqueteras -floppy-.
- cualquier tipo de circuito integrado en placa madre.
Ventajas e inconvenientes
Ventajas
- configuración más sencilla, organizada y barata.
- mayor seguridad en el sistema -pérdida de datos, intrusiones-.
- menores costes de mantenimiento del maquinario.
- menores riesgos por averías en discos, al disponer de menor número de ellos.
Inconvenientes
- rompemos la descentralización y las ventajas que ello supone en un cluster.
- mayor tráfico en la red, puesto que añadiremos al tráfico de procesos del cluster el acceso a sistemas de ficheros remotos.
- menor robustez de la red: por estar más cargada es más susceptible a fallos y congestiones.
Croquis de la arquitectura
Los servidores proveerán las cuatro necesidades básicas para que un cliente pueda arrancar y funcionar adecuadamente en red.
- Arranque (protocolo RPL). Desde el momento de su puesta en marcha el computador deberá ser capaz de dejar a parte el reconocimiento de dispositivos locales e intentar hacerse con los servicios de arranque a través de su nic.
- Identificación (DHCP). Los clientes no tienen forma de mantener sus configuraciones anteriores -si hubieran existido- en ningun medio físico, puesto que no disponen de memoria secundaria -discos duros, ...-. Los servidores deben ocuparse de asignar la identidad a cada cliente cada vez que arranquen.
- Descarga de la imagen del kernel (TFTP). Igualmente los clientes no pueden almacenar el kernel con el que deben arrancar. Éste debe mantenerse en el servidor y ser trasferido cada vez que el cliente lo solicite.
- Sistema de archivos remoto (NFS). Una vez que los clientes dispongan de identidad y hayan arrancado su kernel les faltará un lugar donde volcar sus resultados y donde obtener los ejecutables que sus operaciones requieran. Necesitaremos configurar NFSroot
Consecuentemente los clientes a su vez seguirán un proceso de arranque distinto al común. Véase este nuevo método.
- Arranque desde tarjeta de red (RPL). La única información útil de que disponen los clientes es su dirección MAC -o dirección ethernet- que está en el firmware de su tarjeta de red -viene especificada por el fabricante-. Ésta es única en el mundo y es lo primero que el servidor recibirá de un cliente y le permitirá reconocerlo, o no.
- Identificación como miembro de la red (DHCP).
- Descarga del kernel (TFTP). Para el arranque en las computadoras clientes la imagen del kernel tendrá que sufrir ciertas modificaciones que le permitan cargarse en memoria y poder ser arranacadas desde ahí. El resultado de dichos cambios en un bzImage común dan lugar a una tagged images del mismo. La transmisión se realiza por TFTP, todo ello se explicará más tarde.
- Sistema de ficheros remoto (NFS). Para que el host sea útil debe poseer un directorio raíz donde montar su sistema de ficheros y así pasar a ser operable como cualquier sistema linux.
- Integración en el cluster. Para terminar, tendremos que cargar los scripts necesarios para poder integrar cada cliente al cluster openMosix.
Diálogo de comunicación
Llegados a este punto se acuerda tener una idea del proceso que debe llevar a cabo cada tipo de computadora. Seguidamente se presenta todo ello en un pequeño diálogo -muy intuitivo- para esclarecer posibles dudas de procedimiento. Se indica igualmente el protocolo que lo implementa.
El primer paso es arrancar algún servidor, puesto que por deficnición sin ellos ningún cliente podría arrancar ningún servicio. Una vez hecho esto podrá ponerse en marcha un cliente. Su BIOS deberá percatarse de que debe iniciar desde la tarjeta de red -así lo habremos configurado, se explicará más tarde- y enviará por broadcast7.2 su dirección MAC a la espera que alguien -un servidor- la reconozca y sepa qué configuración asignarle.
RPL
- Cliente (C): ¿alguien en esta red reconoce mi MAC?
- Servidor (S): yo mismo. Paso a darte capacidad para formar parte de esta red.
DHCP
- C: perfecto S, ¿quién soy?
- S: eres la IP x.x.x.x, tu servidor soy yo y tu fichero de arranque es vmlinuz.
etiqueta
TFTP
- C: por favor S, dame vmlinuz.etiqueta para poder arrancar linux
- S: coge el fichero de mi directorio /tftpdir/vmlinuz.etiqueta
- C: correcto, empiezo mi arranque...
NFS
- C: arranque completo. Déjame montar mi sistema de ficheros raíz (con NFS)
- S: lo tienes en /tftpboot/C/
- C: déjame montar mis demás directorios (/usr, /home, etc...)
- S: los tienes ahí también
- C: ¡gracias S, ahora soy totalmente operable!
Como se verá a la hora de dar detalles sobre la forma de configurarlo, los nombres de ficheros y directorios pueden ser escogidos arbitrariamente.
Servicios requeridos
El diálogo anterior requiere de los servicios ya introducidos para poder llevarse a cabo.
- el servidor debe ser capaz de responder a peticiones de arranque por RPL de los clientes.
- el servidor y el cliente deberán comprender el protocolo DHCP.
- ídem para el protocolo TFTP.
- el servidor deberá arrancar el demonio servidor de NFS. Las computadoras clientes deben ser capaces de montar unidades por NFS, es una opción del kernel.
Como se ha señalado e impone el número de servicios a configurar, se divide en cuatro partes la temática de esta sección. En una primera fase se comentarán sus especificaciones para tener una visión de las posibilidades que ofrecen y tras ello se verán algunas herramientas necesarias para su configuración.
I - EL SERVIDOR Y EL CLIENTE DEL PROTOCOLO RPL
El protocolo RPL ha sido diseñado para el arranque desde tarjetas de red -nic- y dota al computador de la posibilidad de adquirir la posibilidad de hacer petición por DHCP, servicio que no posee debido a su falta de capacidad de almacenaje.
Instalar un nic con este soporte permite interrumpir a la BIOS del computador -en este caso un nodo cliente- con la interrupción INT 19H para gestionar el arranque desde este dispositivo. Los requerimientos, como ya se ha dicho, es que la placa madre del computador permita arranque por red y que el nic permita arranque RPL, algo común en el maquinario actual.
La estructura de datos en que se basa RPL es una pequeña imagen -rom- que deberá ser transferida al nic. Esta rom puede ubicarse en 2 localizaciones:
- Integrarse directamente en el hardware del nic. Aunque esta posibilidad solo viene contemplada de serie por las tarjetas más caras puesto que requiere un chip bootp rom específico para cada modelo. Este chip ha de colocarse sobre el socket -que suelen llevar todas las tarjetas- y tiene una capacidad de unos 32KB.
- La otra posibilidad -que es la más económica y la que aquí se detalla- es montar un servidor de roms para que los clientes obtengan la suya desde él. Esta posibilidad ofrece ventajas tanto a nivel de flexibilidad -no será necesario el chip. Las imágenes suelen ocupar 16KB.
II - EL SERVIDOR Y EL CLIENTE DEL PROTOCOLO DHCP
DHCP es un superconjunto de las operaciones que puede realizar BOOTP, que a su vez es una mejora sobre el antiguo protocolo de arranque RARP. En este caso utilizaremos DHCP para conseguir la dirección IP.
El funcionamiento de BOOTP -y por extensión DHCP- es sencillo. Es un protocolo de Internet que desde hace años -concretamente desde el 1985- está especificado en la RFC9517.3 de la The Internet Engineering Task Force -perteneciente a la Internet Society-. Este protocolo tiene como principales características:
- se realizan intercambios de un solo paquete con el mismo formato tanto para peticiones como respuestas. Este paquete o datagrama es IP/UDP y se utiliza timeout para retransmitir mientras no se reciba respuesta a una petición.
- Existe un código de opción que indica si el paquete es BOOTREQUEST (por el puerto 68) o BOOTREPLY (por el puerto 67). Las peticiones BOOTREQUEST contienen la máquina que las solicitó si ésta es conocida.
- Opcionalmente, se puede conceder el de la BOOTREPLY del nombre de un fichero que se debe descargar.
- Los servidores se comportan como gateway permitiendo incluso peticiones BOOTP entre varias redes.
El contenido de los campos de un paquete en el protocolo BOOTP es interesante para ver sus opciones. Además puede servirnos para detectar, mediante aplicaciones sniffers, fallos en tarjetas. Lo vemos en el Cuadro ![[*]](http://www.wikilearning.com/imagescc/9756/crossref.png)
.
Tabla: Nodos diskless: Campos de un paquete del protocolo BOOTP
| CAMPO |
BYTES |
DESCRIPCIÓN |
| op |
1 |
opcode, 1=BOOTREQUEST - 2=BOOTREPLY |
| htype |
1 |
tipo de hardware, 1=10Mbps ethernet |
| hlen |
1 |
longitud de la MAC (normalmente 6) |
| hops |
1 |
utilizado por los gateways para contar los saltos |
| xid |
4 |
ID (identificador) de la transacción |
| secs |
2 |
rellenado por el cliente con el riempo que lleva solicitando respuestas |
| - |
2 |
reservados |
| ciaddr |
4 |
dirección IP del cliente, en el caso de conocerse |
| yiaddr |
4 |
dirección de un cliente, lo rellena el servidor tras consultar su configuración |
| siaddr |
4 |
dirección del servidor |
| giaddr |
4 |
opcional, para atravesar varias redes |
| chaddr |
16 |
dirección hardware del cliente |
| sname |
64 |
nombre del servidor (opcional) |
| file |
128 |
ruta del archivo arranque |
| Vend |
64 |
etiqueta específica del fabricante | |
Como puede verse, los campos son muy significativos para el tipo de operación que se pretenda realizar. Estos campos están incluidos en un datagrama IP/UDP, lo que representa una ventaja respecto a RARP, que solamente manipulaba operaciones en bruto sobre la red -sobre ethernet- no permitiendo opciones como el encaminamiento entre redes, ni la utilización de otro tipo de tecnologías distintas que no soportasen protocolo ARP.
El funcionamiento es muy sencillo. El cliente rellena un paquete con todos los campos que conoce y con el opcode de petición, y lo difunde a la dirección 255.255.255.255 de broadcast.
Luego contesta la máquina servidora rellenando el paquete de manera que el cliente recibe el paquete y lo procesa para colocar como praámetros de su pila IP los proporcionados por el servidor. Este caso se da, como se ha comentado repetidamente, siempre que el servidor esté configurado para responder a la dirección MAC del cliente que genera la petición.
El servidor de DHCP se inicia como un demonio -daemon- externo al inetd. Gracias a DHCP queda especificado todo lo referente a la identificación IP de aquellas máquinas que intenten entrar en la red. Se podrá asignar un rango dinámico de direcciones, también se puede hacer que todos descarguen la misma imagen del kernel sin asignarla directamente a ningún host en particular -útil en un cluster homogéneo-. En el apéndice relativo a Salidas de comandos y ficheros se ve un ejemplo del fjchero dhcpd.conf .
En cualquier caso y como resulta obvio, será necesario asignar una IP a cada host -sea nodo cliente o servidor- para que forme parte de la red del cluster y poder especificar el entorno de configuración de cada máquina, así como asignar los ficheros de configuración de openMosix.
III- EL SERVIDOR Y EL CLIENTE DEL PROTOCOLO TFTP
Como su nombre indica -Trivial FTP- este protocolo es un FTP especial: mucho más simple que éste. Para empezar, la capa de transporte utiliza UDP en lugar de TCP y transferencia por bloques para el envío de los ficheros, lo que hace más sencilla la transferencia (y más en una red ethernet). El otro motivo por el que se utiliza UDP y un mecanismo tan simple de control de paquetes es porque se necesita que el programa y lo mínimo de pila IP ocupen poco en memoria para que este pueda grabarse en ROMs, que inherentemente disponen de poca capacidad (32KBytes por lo general).
El servidor de TFTP -controlado por el demonio tftpd- se suele arrancar desde inetd. Su configuración se centrará en el servidor, puesto que el cliente lo adopta sin que sea necesario que lo hagamos explícito en ninguna parte.La configuración puede hacerse:
- Simple. Hay que tener cuidado del entorno en el que se encuentra el servidor, ya que el protocolo tftp es inherentemente inseguro y al no exigir autentificación, los clientes pueden solicitar el fichero /etc/passwd o similar sin ningún problema, lo que supone una inseguridad considerable.
- Seguro. Basa su seguridad en una llamada a chroot(). De este modo, en la ejecución de la rutina de aceptación de peticiones, el directorio exportado se convierte en directorio raíz. Consecuentemente el acceso a otros ficheros es más difícil.
TFTP es un servicio inseguro, ya que el propio protocolo es simple e inseguro, por lo que es recomendable que el servidor que posea este servicio esté aislado de cualquier red que no garantice medidas serias de seguridad. En casi contrario, cualquiera podría sustituir los ficheros que descargan los clientes e incluir en ellos alguna rutina no deseada.
La activación de este servicio es tan fácil como una línea en el fichero /etc/inetd.conf. Los parámetros pueden variar sensiblemente dependiendo de la aplicación que usemos para controlar el demonio. En principio debería no haber problemas con:
tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd /tftpboot
IV- NFS
NFS es el sistema de almacenamiento ingeniado por Sun Microsystems y que utiliza RPC. Es un modelo de servidores sin estado, es decir, los servidores NFS no guardan en nigún momento los archivos a los que se están accediendo7.4.
El funcionamiento se basa en dos secciones: cliente y servidor. El cliente monta el sistema de ficheros exportado por el servidor y a partir de este momento accede a los ficheros remotos como si fuesen propios. Este sistema es utilizado desde hace tiempo en casi todos los sistemas Unix como método de compartir ficheros en red. NFSroot designa el método que sigue el kernel cuando en lugar de tomar el clásico sistema de ficheros ext2 o reiserfs para montar /, importa un directorio NFS de un servidor.
El sistema de archivos que debemos exportar en el servidor debe contener todos los archivos necesarios para que la distribución pueda funcionar. Este factor es muy variable, dentro de cada distribución, según activemos unos servicios u otros.
En principio cabe pensar en qué directorios deben ser necesariamente de lectura y escritura o solamente de lectura. Una buena forma de ahorrar espacio en el servidor sería exportando para todos los clientes los mismos directorios para solo lectura y particularizando para cada uno los de escritura y lectura. De cara a evitar mayores consecuencias en los posibles errores que puedan cometerse en la puesta en marcha del servicio, un buen consejo es no exportar directamente ningún directorio del servidor, sino uno propio de un cliente puesto en el directorio del servidor que usemos para disponer los directorios exportables -normalmente /tftpboot/-.
Aproximadamente se requieren unos 30MB de información específica para cada nodo -si estos disponen de un sistema linux mínimo-, mientras que el resto puede ser compartida.
