etiqueta
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.
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:
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.
Inconvenientes
Los servidores proveerán las cuatro necesidades básicas para que un cliente pueda arrancar y funcionar adecuadamente en red.
Consecuentemente los clientes a su vez seguirán un proceso de arranque distinto al común. Véase este nuevo método.
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
etiqueta
etiqueta para poder arrancar linux
etiqueta
Como se verá a la hora de dar detalles sobre la forma de configurarlo, los nombres de ficheros y directorios pueden ser escogidos arbitrariamente.
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:
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:
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 ![[*]](crossref.png)
.
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:
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.
Reiteremos una vez más un par de puntos importantes:
En este capítulo aprenderemos a configurar los servicos que anteriormente se han expuesto, así pues se seguirá la misma estructurarión cuaternaria: rpl, dhcp, tftp y nfs.
I- CONFIGURACIÓN SERVIDOR RPL. rpld.conf
Lo primero será conseguir un demonio para el protocolo RPL. Una
implementación funcional y estable puede bajarse de un rincón de la web de
la Universidad de Cambridge7.5.
Una vez compilado e instalado -y siendo root- podremos ejecutar el comando
rpld
Este demonio intentará acceder al fichero /etc/rpld.conf. Este fichero
tiene una sintaxis muy concreta -a la vez que potente- y por ello se recomienda leer
las páginas man posteadas en la misma dirección. Su lectura
permitirá al administrador hacer un examen exhaustivo de todas las
posibilidades que pueda brindarnos este servicio.
Existe un ejemplo de este tipo de fichero en el apéndice Salidas de comandos y ficheros. Basta con anotar la dirección MAC del cliente que realizará la petición e indicar la imagen rom que se corresponde al modelo de chipset de su nic7.6. Los demás parámetros se refieren al tamaño de los bloques que se transferirán; los valores indicados en el fichero de ejemplo no deben dar problemas.
N. al LECTOR. La documentación necesaria para generar la rom adecuada a cada modelo de nic se encuentra en la siguiente sección: ROMs para arranque sin discos.
II- CONFIGURACIÓN SERVIDOR DHCP. dhcpd.conf
El fichero que el demonio dhcpd leerá para cargar la configuración
será el /etc/dhcpd.conf . Este demonio puede lanzarse con el comando
/etc/init.d/dhcpd start
La ruta del demonio puede variar según la distribución. En el apéndice
Salidas de comandos y ficheros hay un ejemplo de este tipo de fichero,
para comprenderlo se aconseja ejecutar man dhcpd en cualquier consola.
A continuación se detallan los parámetros que pueden ser más
interesantes. Para la red:
El parámetro filename hace referencia a una imagen del kernel distinta a la salida del comando make bzImage utilizado para realizar la imagen del kernel linux. Para conocer las modificaciones necesarias a una iamgen para obtener una tagged image consúltese ROMs para arranque sin discos en la próxima sección.
III- CONFIGURACIÓN DEL SERVICIO TFTP inetd.conf
Como ya se ha mencionado, el protocolo TFTP es inseguro per se,
es conveniente asegurar nuestro sistema con herramientas como tcp-wrapper y algún tipo de cortafuego -firewall- si queremos bajar
las probabilidades de que llegue a darse una intrusión7.7.
Una vez hagamos hecho las modificaciones ya dadas al fichero /etc/inetd.conf, para relanzar el demonio inetd7.8 deberá ejecutarse:
/etc/init.d/inetd reload
Otra opción para relanzarlo es la señal HUP. Para ello deberemos
conocer el PID del demonio y ejecutar:
kill -HUP inetd_pid
Para restablecer la seguridad que TFTP restará a nuestro sistema se debe hacer el
máximo esfuerzo para: evitar recibir ataques de ipspoofing, proteger
mediante permisos correctos el sistema, realizar un control sobre los logs creados y dar el mínimo de permisos posibles al servicio tftpd, por eso ejecutamos el demonio como el usuario nobody. El chroot es imprescindible así como el control de tcp-wrapper
mediante los ficheros.
/etc/host.allow
/etc/host.deny
/etc/syslog.conf
/etc/inetd.conf
En la línea que hay que añadir -o descomentar- en el inetd.conf
aparece como último parámetro el directorio raíz que sirve para
encontrar los ficheros a importar. En este caso se ha considerado el directorio
/tftpboot/ del servidor.
En este directorio sería conveniente colocar todas las imágenes de los
clientes7.9, para dotar al sistema de cierto criterio y
coherencia. Cabe recordar que es el fichero dhcpd.conf el que marca
qué imagen debe recoger cada cliente.
IV- SERVIDOR NFS
Hasta este punto los clientes tienen que poder empezar a arrancar su kernel,
no obstante no podrán iniciar el proceso con PID 1 , el INIT, debido a que
no deben ser capaces de poder montar ninguna unidad. Aquí es donde entra
el único servicio que resta: el NFS. Esta sección está separada, según
sea el cometido:
IV A- EXPORTACIÓN DE DIRECTORIOS CON NFS
El servidor debe tener arrancado el demonio de servidor de nfs para
poder proveer este servicio. Este demonio comunmente -en la mayor parte de las
distribuciones linux- viene con el nombre nfssserver; para arrancarlo
puede procederse como en cualquier demonio:
/etc/init.d/nfsserver start
El fichero de configuración de NFS que exporta los directorios necesarios
suele estar en /etc/exports. Tiene su propio manual (man exports)
que se deberá leer para incluir los directorios con una sintaxis correcta y
añadir algo de seguridad al servicio NFS. En el caso de dos clientes - metrakilate y mCi- de arranque sin discos, este fichero de configuración tendría que ser algo
parecido a lo siguiente:
/tftpboot/metrakilate/ 192.168.1.2/255.255.255.0(rw,no_root_squash,sync) /tftpboot/mCi/ 192.168.1.3/255.255.255.0(rw,no_root_squash,sync) /media/dvd/ 192.168.1.0/255.255.255.0(ro,no_root_squash,sync)
En este ejemplo se indica donde se encuentra la raíz para cada una de las dos máquinas, más un directorio -la unidad local de dvd- que será exportada a cualquier nodo con IP 192.168.1.X (siendo X un valor entre 1 y 255).
El comando exportfs -a hace que se proceda a exportar los directorios que se lean de este fichero en el caso de que se añada alguna entrada cuando el servicio está activado. Otra posibilidad es guardar los cambios al fichero y enviar una señal tHUP o llamar al script con la opción reload.
IV B- RA´iZ EN LOS NODOS CLIENTES
Dentro de /tftpboot/directorio_raiz_de_un_nodo se debe
encontrar un sistema réplica de ficheros a la distribución que queramos
utilizar. La edción de ficheros para configuraciones añadidas o la
ejecución de aplicaciones podrá hacerse normalmente
como si se trabajara con unidades locales, ya que la capa de VFS nos hace
transparente el proceso.
Así pues una solución es comenzar una instalación de
linux cambiando la ruta de instalación a /tftpboot/ directorio_raiz_de_un_nodo, de manera se aseguran que todos los archivos
necesarios se encuentran en el lugar requerido.
Otra posibilidad es hacer una instalación normal en un disco conectado a la
placa madre del nodo cliente para asegurar que
todo funciona correctamente. Una vez se ha comprobado que el sistema operativo
es capaz de montar unidades por NFS y tiene capacidad de entrar en una red,
puede procederse a empaquetar su directorio / desde la máquina
servidora7.10 para luego desempaquetarlo en el
/tftpboot/directorio_raiz_de_un_nodo elegido.
La alternativa más dura será montar un linux -existente en algun disco- en el directorio mencionado del servidor. Esta alternativa pasa por copiar en el directorio lo siguiente:
directorio_comun_a_los_nodos/ y luego hacerlos compartirdos entre todos los
clientes sin discos mediante enlaces duros7.11.
Existen dos puntos que complican sensiblemente el proceso. Se detallan seguidamente.
En el caso de /etc es conveniente quitar del entorno rc.d todos aquellos scripts de arranque que no sean necesarios para cada nodo. Hay que configurar todos los apartados específicos como pueden ser el /etc/network/interfaces/ y/o adecuar el openmosix.map -que debiere ser indistinto para cualquier máquina del cluster-.
En general deben ser cambiados todos los parámetros propios de cada nodo, es relevante señalar la importancia de los parámetros de red. El problema de los dispositivos se puede resolver de dos maneras. La primera es utilizar el viejo sistema de minor y major number que hasta ahora se han utilizado en linux. Para ello puede hacerse una copia con:
cp -a /dev /tftpboot/directorio_raiz_de_un_nodo
cd /tftpboot/directorio_raiz_de_un_nodo
./MAKEDEV
Esto consigue que se generen los enlaces necesarios a este directorio -propio
del nodo- en lugar de a
/dev/xxxx, que es el directorio del servidor. Además hay que hacer un
nuevo dispositivo de major 0 y minor 255, y exportarlo al kernel
para que se puedan recibir comandos de nfsroot en él. Esto se puede
conseguir con:
mknod /dev/nfsroot b 0 255
rdev bzImage /dev/nfsroot
Aquí bzImage tiene que ser la imagen del kernel del nodo diskless en cuestión. Generalmente se encuentra en /usr/src/linux-version/arch/i386/boot tras su compilación.
Llegados aquí, finalmente, tus clientes disk-less deberían estar funcionando sin nigún problema.