Instalar Linux 100% por Red

Una propuesta general de alto rendimiento de Infraestructura de instalación Linux
Trabajo respaldado por contrato del Ministerio de Energía AC USA
Alf Wachsmann - Stanford Linear Accelerator Center (SLAC), Stanford University, Menlo Park, CA USA

http://www.slac.stanford.edu/~alfw/Publications/SLAC-PUB-9193.pdf

Extracto
Con más y más grandes clusters (grupos) de Linux, la pregunta que aparece es cómo instalarlos. Este trabajo aborda esta pregunta proponiendo una solución usando solamente componentes de software estándar. Son instalaciones de infraestructura en escala y está bien para un número grande de nodos. Es también utilizable para instalar computadoras de escritorio o clientes de Linux sin disco duro, por lo tanto, no está diseñado solo para instalaciones de clusters (grupos) en particular, pero es no obstante, de alto rendimiento.
La infraestructura propuesta usa PXE como el componente de booteo de la red en los nodos. Usa DHCP y servidores de TFTP para conseguir una dirección IP y un bootloader (gestor de arranque) para todos los nodos. Luego la usaremos como booteo kickstart (arranque) para instalar Linux Red HAT a través de NFS.
Hemos implementado esta infraestructura de instalación en SLAC (Stanford Linear Accelerator Center) con nuestro hardware servidor en particular e instalado un cluster (grupo) de 256 nodos en 30 minutos. Este trabajo presenta las mediciones desde esta instalación y se analizan los obstáculos en nuestra instalación.

1. Introducción
El problema de re-instalar una gran cantidad de máquinas Linux en un lapso muy corto de tiempo es más difícil conseguir a mayor número de máquinas a instalar.

Dos ejemplos de grandes instalaciones de clúster (grupos) de Linux: Muchas empresas dot.com tienen varios miles de máquinas Linux en su clúster de servidores WEB.
En los cuatro experimentos del LHC, en el CERN, se proponen organizaciones Linux con varios miles de máquinas.
LHC, Large Hadron Collider (acelerador y colisionador de partículas).
CERN, Conseil Européen pour la Recherche Nucléaire (Organización Europea para la Investigación Nuclear).
El proyecto de EU DataGrid [1] tiene incluso un paquete de trabajo dedicado a "Red de gestión" [2] para investigar más a fondo cómo instalar y mantener grandes clusters (grupos).
EU DataGrid: recursos distribuidos para el procesado de grandes volúmenes de información, basados en clusters de PC conectados por switches de alta velocidad con sistema operativo Linux con servidores de disco y de aplicaciones diferenciados.

La dificultad es que existen muchas herramientas y set de herramientas para tratar de resolver este problema de instalación o actualización. Pero la mayoría si no todas, asume que el hardware no es diverso y está utilizando algún tipo de técnicas de clonación de discos (por ejemplo, Systemimager [12]). Este enfoque no funciona para las organizaciones con hardware heterogéneo y hace que sea necesario disponer de una infraestructura de instalación de grupos de nodos homogéneos y otro para las más diversas máquinas. Otras herramientas como IBM LUI [5] están tratando con esta diversificación de hardware. Pero conseguir (por ejemplo) todas las configuraciones de máquinas de escritorio para un sitio muy grande es una pesadilla. El instalador de Red Hat "Anaconda" es ideal para cada una de estas situaciones, ya que sondea los equipos e instala los controladores necesarios y paquetes de software automáticamente. "Anaconda" es ejecutada automáticamente desde el booteo kickstart y el programa instala automáticamente Red Hat. La pregunta que surge, es si esta instalación bastante general se enfoca a escala para un gran número de máquinas para ser instaladas o si realmente cobra sentido tener un cluster especial de infraestructura de instalación.
Otro objetivo de nuestro enfoque es utilizar sólo los servidores y servicios que ya están en marcha y que pueden ser reutilizados para otros fines.
A diferencia de un servidor "rsync", el cual sólo puede ser utilizado para "systemimager" (por tomar sólo un ejemplo), un servidor DHCP para el grupo de nodos de instalación, también puede ser utilizado para la instalación de máquinas de escritorio. Además, una imagen del sistema en particular -para fijarnos en el ejemplo “systemimager” - puede solo ser utilizado sobre exactamente el mismo hardware. Considerando que un set de RPM (Red Hat Package Manager ") usados por "Anaconda" es utilizable para todos los instalaciones Linux.
"NPACI's Rocks" [9] contiene paquetes de este tipo con propósito de instalación de infraestructura general, pero alguna intervención manual sigue siendo necesaria y su enfoque es de re-instalar una máquina cada vez que bootea (arranque). Nos gustaría buscar una solución menos radical. Además, "Rocks" está destinado a instalar sólo pequeños grupos de hasta 128 nodos [8]. Teniendo en cuenta todo esto, los objetivos de diseño de nuestra infraestructura Linux de instalación, son los siguientes: 1. Utilizar sólo los servicios estándar, los cuales ya están en el lugar y se puede utilizar para otros fines. 2. Hacerlo altamente escalable para permitir la instalación de miles de máquinas al mismo tiempo. Este trabajo describe nuestra solución y damos algunos resultados de referencia de nuestra aplicación para demostrar su viabilidad. En la siguiente sección vamos a describir todos los componentes de nuestra infraestructura. En la Sección 3 se describen las características de escalabilidad de la infraestructura y en la sección 4 se presenta las mediciones que efectuamos instalando hasta 256 nodos al mismo tiempo.

2. Arquitectura de la infraestructura de instalación
Nuestra arquitectura para la instalación de grandes clusters (grupos) de Linux facilita la capacidad de arranque de red (Pre-boteo Ejecución Ambiente PXE [6]) de las tarjetas de red de interfaz moderna (NIC's).
Esto requiere servidores DHCP y TFTP para obtener los programas necesarios y los archivos de configuración para los clientes.
La cadena de programas cargados e iniciados desde PXE son:
Un bootloader (gestor de arranque), un Kernel-Linux (núcleo de Linux), y un disco RAM inicial para este núcleo.
El kernel de Linux inicia el booteo kickstart para instalar Red Hat Linux. Después de que Linux esté instalado, un proceso de post-instalación, hace necesarias adaptaciones locales.
La figura 1 muestra todos los servidores necesarios para la arquitectura propuesta en su aspecto más general.
Figura 1: Arquitectura General del entorno de la Instalación

En las siguientes secciones vamos a describir todos los componentes utilizados en más detalle. Y vamos a presentar algunos scripts de pegar, que todo lo unen para hacer una instalación masiva y completamente automática y desatendida. Los detalles técnicos y todos los scripts mencionados están disponibles en [13].

2.1. Preboot Execution Environment (PXE) (Entono de Ejecución de Pre-booteo) Para bootear (arrancar) un PC Intel través de la red, la mayoría de las NICs (tarjetas de red), están equipadas con PXE, un estándar propuesto por Intel.
El primer paso en este procedimiento es la emisión DHCP (broadcast) desde un cliente para obtener su dirección IP. Esto permite que el servidor PXE envíe la dirección IP y un menú al cliente de tal manera que el usuario pueda elegir qué sistema operativo podría ser instalado en su sistema.
PXE en el cliente a continuación, carga un bootloader (gestor de arranque) por TFTP que a su vez carga el sistema operativo elegido.
Sólo necesitamos la parte de DHCP y TFTP para obtener una dirección IP y un bootloader (gestor de arranque) sobre cada máquina. Siempre instalaremos Linux como sistema operativo. Por lo tanto, no necesitamos un servidor PXE, sólo un servidor DHCP y servidor TFTP.

2.2. DHCP Por varias razones, cada máquina en SLAC necesita una dirección IP estática. Por lo tanto, nosotros no podemos ofrecer simplemente una gama de direcciones IP libres a nuestro servidor DHCP, que se asignarían a los clientes en orden cronológico de sus solicitudes. Para permitir la asignación de direcciones IP estáticas a través de DHCP, el servidor DHCP necesita saber de todos los clientes las direcciones MAC de antemano. Esto no es un problema para las máquinas que ya están corriendo y necesitan ser reinstaladas. Para las máquinas nuevas con direcciones MAC desconocidas hay varias posibilidades para lograr esto. 1. Obtener una lista de direcciones MAC y los números de serie de la máquina del proveedor y realice un seguimiento de cada máquina durante el armado. 2. Todas las máquinas tienen etiquetas de código de barras que contiene su dirección MAC. Después las máquinas son colocadas y pueden ser escaneados en su orden de ubicación. 3. Cambie las máquinas en el orden que desee, las direcciones IP asignadas a ellos.
Examine el archivos de registro dhcpd logfiles de recepción de solicitudes y asignación de las direcciones IP de acuerdo con este orden. Esta tercera opción es elegida por NPACI para "Rocks" [9]. Todo esto es angustioso, necesita un esfuerzo adicional y está propenso a errores de hardware. El tercer enfoque depende en gran medida del timing (sincronización) en que las máquinas son encendidas. 2.2.1. Detección de direcciones MAC Hemos desarrollado un script para detectar las direcciones MAC de forma automática y al vuelo, mientras los clientes realizan su transmisión (broadcast) PXE - DHCP. Esta emisión (broadcast), envía una señal por Ethernet a través del switch (conmutador) para encontrar un servidor DHCP. El switch, ve esta nueva dirección MAC en uno de sus puertos y llena su "bridging table" ("tabla de puente") con esta información. Nuestro switch (conmutador) Cisco Catalyst 6509, puede consultar a través de SNMP (Simple Network Management Protocol) Protocolo Simple de Administración de Red, la lectura de la tabla de bridge.
Las direcciones IP pueden ser ahora asignadas en el orden de los puertos del switch: la máquina con la dirección MAC que fue vista en el primer puerto, obtiene la primera dirección IP y así sucesivamente. El único requisito para que esta técnica trabaje y funcione es un cableado Ethernet cuidadoso entre las máquinas y el switch. La máquina en la primera posición en el rack (bastidor), debe estar conectada al primer puerto del switch, la segunda posición en el rack debe ser conectada al segundo puerto, y así sucesivamente. Este orden determina el orden en que las direcciones IP son asignadas a las máquinas. Nuestro script de Perl que consulta al switch, toma como entrada sólo el nombre del switch, las tarjetas en el switch y los puertos sobre estas tarjetas a buscar.
Se genera un nuevo archivo de configuración del servidor DHCP (dhcpd.conf) con todas las direcciones MAC previamente desconocidas que se agregan. Un segundo script, observa este archivo dhcpd.conf y se detiene e inicia el servidor DHCP siempre que el archivo de configuración haya cambiado.
Todo este proceso es un momento altamente crítico, porque el PXE standard requiere que los clientes emitan sólo 2 peticiones DHCP. Por lo tanto, nuestro script lee todo el archivo dhcpd.conf, sola una vez al principio y lo mantiene en la memoria. Cada vez que agrega una o más direcciones MAC, se escribe el archivo entero en vez de editarlo. Todos los cambios realizados a este archivo entretanto por otros scripts serían anulados y reemplazados. Volveremos a este punto en la sección 2.4.2. Con este truco de programación y nuestros clientes que emiten sobre 10 peticiones DHCP, lo cual toma a la larga sobre 1 minuto el tiempo de espera. Tenemos tiempo suficiente para detectar las direcciones MAC automáticamente.

2.3. TFTP
PXE plantea algunos requisitos en el servidor TFTP que se pueda utilizar. Para obtener más información acerca de los requisitos especiales, véase el debate H. Peter Anvin en [4]. Un open source server (servidor de código abierto) que cumple estas condiciones es el servidor TFTP de Jean-Pierre Lefebvre y Remi [7]. Este servidor TFTP es capaz de correr como un demonio independiente que mejora el rendimiento, en comparación con un servidor TFTP de un proceso iniciado por inetd.

2.4. Bootloader
El programa gestor de arranque se carga desde PXE a través de TFTP al cliente y a continuación start (comienza).
Estamos utilizando el gestor de arranque pxelinux.0 de H. Peter Anvin de su paquete de syslinx [4]. Que carga su propio archivo de configuración a través de TFTP y ejecuta lo que sea que este archivo de configuración dicta.

2.4.1. Configuración del Bootloader (gestor de arranque)
Si el archivo de configuración del bootloader (gestor de arranque), le dice al gestor de arranque que realice una carga de inicio de red, (en nuestro caso) un Linux Kernel(núcleo Linux) y su disco “inital RAM” (RAM de inicio) a través de la red en el cliente. El gestor de arranque entonces inicia el kernel de Linux con todos los parámetros necesarios lo cual se encuentra en su archivo de configuración. Estos parámetros le dicen al núcleo que realice un booteo kickstart de instalación y que busque el archivo de configuración del booteo en una cierta localización de un servidor NFS.
En el caso de que su archivo de configuración le indique que debe efectuar el arranque desde el disco duro local, hará precisamente esto. El bootloader (gestor de arranque) pxelinux.0 nos permite tener un archivo de configuración independiente para cada cliente. El nombre del archivo es la dirección IP de la máquina en notación hexadecimal sin puntos. Esta característica es útil para prevenir las re-instalaciones interminables.

2.4.2. Prevención de Re-Installations interminables
Después que la instalación del sistema operativo está completa, se reinicia el equipo. Debido a que el BIOS está configurado para arranque PXE, necesitamos un mecanismo para evitar una nueva instalación. La solución obvia, es cambiar la configuración del servidor DHCP no dando al cliente un nombre de archivo para que la fase siguiente TFTP no funcione en esta situación. Véase la sección 2.2.1. para ver las razones. pxelinux.0 partir de la versión 1.53 comprende un " parámetro localboot " en su archivo de configuración. Este parámetro le indica al bootloader (gestor de arranque) que inicie el proceso de arranque desde el disco duro local y así evitar una nueva instalación por red. Todos tenemos que tener cuidado de cambiar el archivo de configuración para cada cliente después de que se lleve a cabo la instalación. Transferiremos un marcador adicional (vacío) a través de TFTP al final de la fase de booteo. Esto añade una entrada en syslog en el servidor TFTP. Con esta transferencia de archivos adicionales es muy sencillo escribir un script que busca en el log file (archivo de registro) de syslog y verifique en el archivo marcador de transferencia y cambie la configuración del archivo pxelinux para la máquina que recibió este archivo. Iniciando una instalación masiva, el archivo de configuración del bootloader (gestor de arranque) de cada máquina está enlazado a un archivo que le permita realizar un arranque de red. El mecanismo descrito anteriormente elimina este enlace simbólico cuando la máquina esta completa (is done) y crea uno nuevo que apunta a un archivo diciéndole a la máquina efectue el arranque desde su disco duro local.


2.5. Booteo kickstart sobre eth1
Si nuestras máquinas clientes tienen dos NIC: "eth0" se encuentra en la placa base y "eth1" en una tarjeta PCI. Debido a que la NIC de la placa base no pueda realizar un arranque de red PXE, tendremos que conectar las máquinas a través de "eth1". La versión de producción de Red Hat Linux en el SLAC es todavía 6,2. El programa de instalación de Red Hat "Anaconda" que viene con esta versión no nos permite seleccionar un adaptador Ethernet específico para realizar la instalación - que está codificada para "eth0". Por lo tanto, tendremos que cambiar esto a "eth1" en el código fuente de “anaconda" compilarlo y generar un nuevo disco initial RAM (initrd.img). "Anaconda" en Red Hat 7 y posteriores tienen un nuevo parámetro "ksdevice" precisamente para este propósito.

2.5.1. Mountando NFS
Se puede hacer la instalación del booteo Kickstart, ya sea desde un medio adjunto conectado localmente (en el disco duro o CD-ROM) o través de la red a través de FTP, HTTP o NFS. Tenemos un servidor que mantiene de forma centralizada (localmente modificada) la distribución Red Hat en NFS. El booteo kickstart monta este sistema de archivos y obtiene todos los paquetes de software necesarios desde ahí. El archivo de configuración del booteo kickstart determina el nombre del servidor NFS y el sistema de ficheros a montar.

2.5.2. %post
El último paso en una instalación kickstart es ejecutar la sección "post%" del archivo de configuración de booteo kickstart. Estamos utilizando este paso para desactivar los servicios innecesarios e instalar nuestro script real post-instalación.

3. Escalabilidad
Metas primarias del diseño para la instalación de esta infraestructura son la escalabilidad y el rendimiento. Para los sitios más pequeños, la escalabilidad baja es una consecuencia, así como que la escalabilidad suba para los grandes sitios. Nuestra infraestructura satisface ambas necesidades.

3.1. Escalabilidad Baja
Todos los servidores (DHCP, TFTP, NFS) y todos los control de scripts pueden funcionar juntos en una sola máquina. Este podría ser la típica operación de esta instalación de infraestructura día a día, cuando se utiliza también para instalar las máquinas de escritorio con Linux, donde la carga no es muy alto para cada servidor/servicio. Dependiendo de las necesidades de rendimiento individual, cada uno de estos servicios puede trasladarse a su propia máquina.

3.2. Escalabilidad Alta
Con la forma en que el control de Script (secuencias de comandos) funciona, incluso es posible utilizar más de una máquina para cada servicio. Si los clientes se conectan a más de un switch, utilice una instancia de script de detección de la dirección MAC para cada switch. Cada instancia se puede ejecutar en un equipo diferente y puede poner detectar las direcciones MAC en varios ficheros de configuración para diferentes servidores DHCP. Cada entrada de host de esos archivos puede tener una entrada diferente de servidor TFTP. Finalmente, cada archivo de configuración de pxelinux puede contener un nombre diferente del servidor NFS. La forma más sencilla de lograr una distribución equitativa de los clientes a los servidores es asignar a los clientes en un ronda-robin a la medida de los servidores.

4. Performance (Rendimiento)
Para nuestras pruebas de evaluación comparativa teníamos dos servidores disponibles para servir a los paquetes de Linux a los clientes, uno con 100 Mb/s, y otro con 1 Gb/s de conectividad de red. Tuvimos que instalar 256 máquinas clientes.
Es bastante claro que el servidor con 100 Mb/s de conexión no tiene ninguna chance de servir a 256 clientes. Por lo tanto tratamos de instalar sólo 128 clientes.
La figura 2 muestra la salida total que viene de la red procedente de este servidor, vista en el switch que está conectado. El link (vínculo) está completamente saturado con cerca de 93 Mb/s de rendimiento.
La caída profunda en el gráfico marca el final de la instalación de Linux y el inicio de nuestro script post-instalación local, que utiliza el mismo servidor par su propia instalación.

La Figura 3 muestra un histograma de cuántos clientes y que cantidad de tiempo necesitaron para terminar su instalación del sistema operativo.
Los tiempos son discretos en intervalos de 5 segundos. Le tomó 45 a 47 minutos para las máquinas que se instalaron.
Tenga en cuenta que los gráficos contienen datos de sólo 105 clientes a pesar de que se comenzó la instalación de 128 máquinas. Resulta que siempre hay máquinas que tienen problemas (como problemas de hardware) que les impide terminar su instalación.

Figura 2: salida de la red de 100 Mb/s conectados al servidor NFS durante la instalación de Linux de 105 máquinas.
Figura 3: Distribución: Duración de la instalación del sistema operativo Linux con 105 máquinas y conexión de 100 Mb/s al servidor NFS.


4.1. Estimación
Antes de hacer una instalación con el servidor-rápida conectado, primero hacer algunos cálculos de lo que podemos esperar de este cambio.
Los 256 clientes se conectan con fast Ethernet (Ethernet rápido). 256 x 100 Mb/s = 25,6 Gb/s. Así pues, el enlace de 1 Gb/s recibirá un exceso de 25 veces de solicitudes.
Algunas instalaciones manuales sugieren que dar booteo kickstart a la red, pero no está relacionado a la CPU y/o al disco. Usando la misma máquina cliente una vez en 100 Mb/s y otra vez en 10 Mb/s de conexión Ethernet no hay prácticamente ninguna diferencia en el tiempo de instalación. Cualquiera de las instalaciones tarda unos 10 minutos. Dada la cantidad de 830MB de datos que se instala en una máquina, el siguiente cálculo de rendimiento puede hecho: 830MB/10min= 11Mb/s
Dado que este tipo de datos se produce en cada una de las 256 máquinas, la subida de 1Gb/s tendrá sólo un exceso de solicitudes de: 1,4 veces [11 Mb/s * 256] /1 Gb/s = 1,4 veces
Por lo tanto, el tiempo estimado para la instalación de 256 máquinas puramente basado en el rendimiento nominal de red es de: 14 min 1,4 * 10 min = 14 min
No estaba claro cómo el servidor NFS rinde con tantos clientes conectados a él y leyendo sólo archivos de tamaños pequeños y medianos.

4.2. Configuración de Hardware
La infraestructura de instalación descrita, fue elaborado para instalar una nueva agrupación de 256 máquinas 1RU dual PIII VA1220 [11]. Cada nodo está conectado a través de un enlace fast Ethernet de 100 Mb/s a un switch. Ahora todos los nodos están conectados al mismo switch. El switch es un Cisco Catalyst 6509 con un 1 Gb/s de conexión de enlace ascendente de la agrupación de PCs a una red troncal Ethernet multi-gigabit.
El servidor DHCP y servidor TFTP se conectan a través de fast Ethernet. El servidor NFS utilizado para servir los paquetes de Linux a los clientes es una red de NetApp F760 Appliance filer con 1 Gb/s de conexión Ethernet, 1 GB de memoria principal, y un total de 1 TB de espacio en disco duro.
Este conjunto de máquinas es "prestada" y no utilizada exclusivamente para esta instalación de Linux.
Por lo tanto, vemos algunos pequeños usos para otros fines que (después del hecho) resultó ser lo suficientemente livianos como para no afectar el rendimiento de instalación en modo alguno.
4.3. Mediciones
Las 256 máquinas clientes se encienda de forma remota a través de VACM [10] en aproximadamente 1 minuto. A continuación, realizaron un broadcast de DHCP (emisión de DHCP), seguidos de tres descargas TFTP y luego un booteo kickstart de instalación de Red Hat Linux a través de NFS. Una vez más, nuestros clientes resultaron ser no muy fiables, con sólo 206 máquinas que en realidad pudieron terminar su instalación.
La Figura 4 muestra un histograma de la cantidad de máquinas y qué cantidad de tiempo necesitaron desde la última descarga de TFTP, hasta que finalizaron la fase de booteo kickstart. Este es el momento para instalar el sistema operativo Linux en las máquinas. Los tiempos son discretos en intervalos de 5 segundos. La máquina más rápida estaba lista después de 29:35 minutos, el equipo más lento tomó 31:00 minutos. El tiempo promedio es de 30:23 minutos.
Figura 4: Distribución: Duración de la instalación del sistema operativo Linux.
Este es el doble del tiempo sugerido por el cálculo de rendimiento de la red.
Figura 5: Lecturas de disco en el servidor de archivos NFS durante la instalación de Linux.

Nota: El Network File System (Sistema de archivos de red), o NFS, es un protocolo de nivel de aplicación, según el Modelo OSI. Es utilizado para sistemas de archivos distribuido en un entorno de red de computadoras de área local. Posibilita que distintos sistemas conectados a una misma red accedan a ficheros remotos como si se tratara de locales.

Las lecturas del disco de los archivos NFS durante la instalación son muy moderadas, como puede verse en la Figura 5 (todas las mediciones en el servidor NFS de Network Appliance se hace con el comando sysstat con una salida cada 10 segundos).
La distribución Linux completa, cerca de 835 MB se mantienen en su caché (el archivo tiene 1 GB de memoria), de modo que no son necesarios tener acceso a múltiples discos para servir a múltiples clientes.
Como se observa en la figura 6, la utilización de la CPU del servidor de archivos NFS no es tampoco la razón del tiempo más lento de la instalación.
La utilización es de aproximadamente el 83% con algunos peaks y caídas. En todos nuestros días, al usar estos archivos, vemos hasta un 95% - 100% de utilización de CPU en las horas peaks.
Figura 6: Uso de la CPU del servidor NFS durante la instalación de Linux.
Figura 7 muestra la salida de la red real que se observa en el servidor de archivos NFS durante la instalación de Linux. El archivero es capaz de entregar alrededor de 370 Mb/s sostenidamente sobre su salida de red de 1 Gb/s enlace. Para nuestro caso usado de 256 clientes sólo leyendo archivos de pequeños y mediano tamaño, esto parece razonable.
Figura 7: Salida de red del servidor NFS, durante la instalación de Linux en 206 máquinas.
Si comparamos estas cifras de rendimiento con los obtenidos en otra instalación de prueba con tan sólo 110 clientes, vemos que con la mitad de los clientes conectados, el servidor de archivos ya ofrece alrededor de 370 Mb/s de salida de red (véase la figura 8).
No se puede escalar mucho más sobre estos rangos con mayor número de clientes conectados. Por lo tanto, el servidor de ficheros NFS que actúa como servidor de la distribución de Linux durante el booteo kickstart, es el cuello de botella en nuestras instalaciones! Tenga en cuenta que esto no es una limitación de la infraestructura en general propuesta, sino de nuestra aplicación en nuestro hardware existente y disponible.
Figura 8: Salida de la red del servidor NFS de Linux durante la instalación de 110 máquinas. Para superar este cuello de botella, se puede utilizar más de un servidor de archivos y distribuir la carga del cliente de manera uniforme sobre ellos. Esto se puede hacer, teniendo un archivo de configuración con booteo kickstart diferente para cada servidor NFS el cual es asignado (por ejemplo, a través de "round-robin” metodo de selección equitativa y ordenada) a las máquinas de Linux por el archivo de configuración PXE.

5. Futuras Aplicaciones
Hemos usado esta infraestructura para recientemente instalar Linux en nuevas máquinas. El mismo método se puede utilizar para re-instalaciones en las máquinas. Esto es necesario para upgrades (actualizaciones de sistemas), pero puede también ser necesario cuando un trabajo por lotes requiere un sistema operativo en un clúster de máquinas que no está actualmente almacenada en su disco duro. Dado que un programador de horarios por lotes de todos los trabajos que requiere este nuevo sistema operativo de forma consecutiva y teniendo en cuenta servidores de archivos más rápidos, esto podría ser factible. Con todos los servidores en su lugar, ahora también es sencillo de aplicar un complemento a esta infraestructura para la instalación automática y desatendida máquina de escritorio. Una manera de hacer esto, es el diseño de una página web donde un usuario proporciona una dirección MAC y la configuración de hardware (el tamaño del disco en particular). La parte de atrás-script final sería añadir una entrada en el archivo de configuración del servidor DHCP y facilitará un adecuado archivo de configuración kickstart. La máquina de escritorio puede ser arrancado con un genérico de instalación de Red Hat Linux disquete. Más general el procedimiento de instalación de escritorio, podría incluso favorecer la funcionalidad PXE completo: un usuario podría elegir si s / que quiere instalar Linux o Windows en su máquina de mesa, de la suya. Incluso los clientes sin disco (ver LTSP [3]) no son difíciles de apoyar con la infraestructura de instalación dada en su lugar.
Con todos los servidores en su lugar, ahora también es sencillo implementar un complemento a esta infraestructura, para la instalación automática y desatendida de máquinas de escritorio.
Una manera de hacer esto, es diseñar una página web donde un usuario proporcione una MAC address (dirección MAC) y la configuración de hardware (el tamaño del disco duro en particular).
La parte de final del script, sería añadir una entrada en el archivo de configuración del servidor DHCP y proporcione un adecuado archivo de configuración del booteo kickstart.
La máquina de escritorio puede ser booteada (arrancar) con un disquete de instalación genérica de Linux Red Hat.
Un procedimiento más general de instalación de escritorio, podría incluso favorecer la completa funcionalidad de PXE : un usuario podría elegir si s/él quiere instalar Linux o Windows sobre su máquina de escritorio.
Incluso en los clientes sin disco (ver LTSP [3]) no es difícil apoyarlos con darle instalación de infraestructura dada en su lugar

6. Conclusiones
En este trabajo, presentamos una propuesta de infraestructura general de alto rendimiento de instalación de Linux. Hemos puesto en marcha esta infraestructura y realizado la instalación en un cluster (grupo) de tamaño mediano de hasta 256 nodos, en 30 minutos. Si un menor tiempo de instalación es necesario o si hay más clientes que necesitan ser instalados, la presente infraestructura permite a cada servicio individual (TFTP, DHCP, NFS) ser distribuidos en más de un solo servidor físico
Es sencillo modificarle los script presentados, para llevar a cabo un “round-robin” de equilibrio en la carga sobre todos estos servidores. Con estos cambios, la arquitectura que aparece debería ser capaz de instalar clusters de miles de nodos, como será necesario hacerlo en el futuro muy próximo. Nuestras mediciones ofrecen algunos datos puntuales, que permiten predecir aproximadamente la forma de ampliar su infraestructura de instalación según sus necesidades.

References
[1] EU DataGrid. http://www.eu-datagrid.org
[2] EU DataGrid Work Package 4: Fabric Management. http://hep-proj-grid-fabric.web.cern.ch/hep-proj-grid-fabric/
[3] Linux Terminal Server Project. http://www.ltsp.org/
[4] H. Peter Anvin. Syslinux/pxelinux: A boot loader for linux. http://syslinux.zytor.com/
[5] IBM. Linux Utility for Cluster Installation (LUI). http://oss.software.ibm.com/developerworks/projects/lui
[6] Intel Corporation. Preboot Execution Environment (PXE) Specification Version 2.1. ftp://download.intel.com/ial/wfm/pxespec.pdf
[7] Jean-Pierre and Remi Lefebvre. atftp ftp://ftp.mamalinux.com/pub/atftp/
[8] Philip M. Papadopoulos. VA Linux 1220. Talk at the "Large-Scale Cluster Computing Workshop (LCCWS) 2001", http://conferences.fnal.gov/lccws/
[9] Philip M. Papadopoulos, Mason J. Katz, and Greg Bruno. NPACI Rocks: Tools and Techniques for Easily Deploying Manageable Linux Clusters. In Submitted to: Proceedings of the Cluster 2001, October 2001.
[10] VA Linux Systems, Inc. VA-Cluster Manager. http://sourceforge.net/projects/vacm/
[11] VA Linux Systems, Inc. VA Linux 1220. http://www.valinux.com/systems/productinfo.html?product=1220
[12] VA Linux Systems, Inc. VA Linux SystemImager Software. http://systemimager.org/
[13] Alf Wachsmann. Howto Install Red Hat Linux via PXE and Kickstart. http://www.SLAC.Stanford.EDU/~alfw/PXE-Kickstart/