Actualizado el 22/11/2007

RedIRIS © 1994-2008

• Publicaciones
• Boletín

Pello Sánchez Cuesta

Resumen

A lo largo de estos últimos cinco años, el modelo de aula informática universitaria se ha ido normalizando. La mayoría de las universidades han adoptado un modelo similar basada principalmente en PCs con servidores de arranque remoto que permiten la recarga rápida del software y el sistema operativo, evitando el típico problema de la desconfiguración continua de los equipos, y por tanto, el alto coste de mantenimiento de salas con un gran número de PCs usados por múltiples personas en un mismo día.

La variedad de soluciones de arranque remoto hace necesaria un estudio para determinar cuáles son los parámetros críticos que determinan el funcionamiento idóneo en el entorno universitario. Para ello, se han realizado varios experimentos monitorizados que nos han permitido alcanzar ciertas conclusiones agrupadas en: protocolos, métodos de transmisión y topología de red. Finalmente se incluyen también otra serie de factores cualitativos que mejoran considerablemente el sistema global, y deberían ser tomados en cuenta al elegir o implementar un sistema de arranque remoto.

Palabras clave: Arranque remoto, aulas informáticas, rembo, redes locales, experimentos

Summary

In the last five years the model of computer rooms for lectures has been normalised. Most of the Universities have adopted a similar model based mainly on PCs with remote reboot servers that allow a fast installation of both software and operating system. This avoids the usual problem of having all the computers wrongly configured, and therefore reducing the cost of maintaining the computer rooms with a high number of PCs used by many different people every day.

The many remote booting options available make necessary a study on the critical parameters that determine the optimum solution for university environments. For this reason, several monitoring experiments have been carried out that resulted in many conclusions in the fields of protocols, transmission methods, and network topologies. Finally, a set of qualitative factors are also discussed in order to improve the overall performance of the global system, and these should be taken into account when choosing or implementing any remote booting system.

Keywords: Remote Boot, Computer Rooms, Rembo, Local Area Networks, Experiments

1.- Principios del arranque remoto

La idea de arranque remoto no es nueva. Hasta hace pocos años la mayoría de las instalaciones informáticas de mediana envergadura disponían de una red a la que se conectaban servidores y puestos de trabajo. Los servidores se caracterizaban por ser máquinas caras, que exportaban sus recursos al resto (disco, impresoras, etc.). Los puestos de trabajo podían ser terminales, PCs o estaciones de trabajo. En estos dos últimos casos, los recursos eran más bien escasos, los PCs apenas tenían potencia gráfica ni de cálculo y las estaciones en muchas ocasiones no tenían ni siquiera disco duro para recortar gastos.

Entonces, los objetivos del arranque remoto eran aprovechar al máximo los recursos del servidor a través de la red, tomando del mismo el sistema operativo, el software, y el espacio en disco para usuarios. Ejemplos significativos eran las redes de PCs que arrancaban de un servidor Novell o bien estaciones de trabajo disk less que arrancaban desde un servidor UNIX o VMS.

Actualmente, gracias al continuo aumento de prestaciones de los PCs, y su bajo costo, hemos pasado de aquella informática centralizada en servidores a la informática descentralizada sobre los puestos de trabajo. En esta situación, es más interesante trabajar en local, utilizando el disco duro del PC (rápidos, baratos y de gran capacidad) para cargar el sistema operativo y el software, y opcionalmente, guardar los datos de usuario en un servidor para facilitar las copias de seguridad.

Las aulas informáticas universitarias se caracterizan por tener gran cantidad de equipos y usuarios diferentes al día, una buena variedad de software (incluido el S.O.) cambiante durante el curso, gran riesgo de virus, y como consecuencia de todo ello, un alto costo diario de mantenimiento. En este entorno específico el objetivo del arranque remoto ya no tiene que ver tanto con los recursos sino con reducir al mínimo los tiempos de reinstalación de un puesto de trabajo.

Para poder extraer los parámetros comunes que permiten optimizar el arranque remoto al margen de su implementación, se ha procedido a ejecutar una serie de experimentos sobre diferentes soluciones actuales, como bpbatch, REMBO o RIS. Estas pruebas se clasificaron en cuatro grupos para estudiar el efecto de:

1. El incremento en el número de clientes simultáneos
2. La optimización de los protocolos de transferencia
3. Los métodos de transmisión: unicast, broadcast y multicast
4. La topología de red: redes compartidas versus conmutadas

Un PC monitor situado en un segmento independiente (para discernir entre el tráfico real y el de monitorización) recogía los valores a estudiar vía RMON, y posteriormente eran analizados con SPSS.

A continuación se muestran las conclusiones obtenidas agrupadas según los protocolos y métodos de transmisión, y según la topología de red.

2.- Protocolos y métodos de transmisión

Ambos están relacionados y forman parte de la estrategia software empleada para hacer llegar los paquetes del servidor a los clientes, independientemente del soporte físico de red que se disponga.

Respecto al protocolo, se ha comprobado que el sistema habitual de transferencia de ficheros TFTP es deficiente para la aplicación que nos ocupa por los motivos siguientes:

a) No utiliza el conocimiento que posee sobre la red que se está usando. Trocea los paquetes con un tamaño de 512 bytes, cuando el máximo permitido en Ethernet podría llegar hasta 15.000 bytes¹. Esto provoca un mayor número de paquetes en la red y mayor probabilidad de colisiones y pérdida de rendimiento.

b) No utiliza mecanismos de buffering en el servidor. Cuando hay varios clientes solicitando a la vez el mismo fichero el rendimiento aumenta si el servidor mantienen un buffer considerable en memoria con los últimos segmentos de fichero servidos (hay gran probabilidad de que sean requeridos de nuevo en un espacio corto de tiempo).

c) Al igual que el resto de protocolos sobre IP, supone que la información circula por una red no fiable, y dispone de un mecanismo fuerte de confirmaciones (ACKs) y retransmisiones. Sin embargo la tasa de errores en una red local de tipo Ethernet es muy pequeña, por tanto no sería necesario confirmar cada paquete enviado.

Respecto a los métodos de transmisión, resumimos las características (ventajas y desventajas) de cada uno de ellos en función de los experimentos:

a) UNICAST: A pesar de ser el método de transmisión más utilizado en una red local, no resulta muy adecuado en una aplicación de arranque remoto. A partir de cuatro clientes, el aprovechamiento de la red (relación de paquetes válidos respecto a los perdidos por colisiones) decae a medida al entrar un cliente más. Con cuatro clientes no llega al 56%.

b) BROADCAST: Los paquetes se envían una única vez a los clientes, y no son confirmados individualmente, sino por ventanas. Gracias a esto, la utilización de la red se mantiene más o menos estable independientemente del número de clientes, y por otra parte, el tiempo de carga de cada cliente está acotado (prácticamente no depende del número de clientes, excepto en el raro caso de retransmisiones) y es mucho menor que en el caso unicast.

Como contrapartida, todos los equipos que se encuentran en el mismo segmento de red, participen o no del arranque remoto, son interrumpidos ² por los paquetes broadcast. El aprovechamiento medio de la red con cuatro clientes ronda el 85%.

c) MULTICAST: Al igual que en broadcast los paquetes se transmiten una sola vez, pero sólo son escuchados por los clientes del segmento que pertenecen a la sesión multicast en curso, y no interfiere al resto de las estaciones del segmento ³. Por otra parte, el número de colisiones es muy bajo y no aumenta con el número de clientes. Otro punto de optimización y flexibilidad que lo diferencia de los otros dos métodos de transmisión es que un nuevo cliente puede engancharse a una sesión en curso en cualquier momento, sin interferir en la sesión en curso y sin iniciar otra nueva transferencia. El multicast de REMBO logra un aprovechamiento de la red de un 96% (cuatro clientes), gracias a la optimización añadida por usar el tamaño máximo de paquete, tal y como muestra la gráfica adjunta obtenida al cargar una imagen con Win98, SPSS y Office 2000 de 448 Mbytes.

3.-Topología de red

Aunque podemos tener Ethernet sobre diferentes medios (cable coaxial, fibra, cable trenzado, etc.) vamos a centrarnos en el modelo de cableado que se ha convertido en estándar de facto para redes locales, y aconsejado por la EIA/TIA Commercial Building Wiring Standard. Por una parte define un cableado horizontal en cada planta basado en UTP que va desde la roseta del usuario hasta el armario de distribución de esa planta. Por otra parte, hay un cableado vertical basado en fibra óptica que va desde cada uno de los armarios hasta el armario principal. Cada armario dispone de hubs o conmutadores donde se concentran las estaciones de esa planta.

En el [5] se describe con detalle las funciones de cada uno de estos elementos de red, así como las velocidades y características de cada uno de los tres estándares definidos para Ethernet: 802.3 (Ethernet tradicional), 802.3u (Fast Ethernet) y 802.3z (Gigabit Ethernet).

Una vez definida la estructura de red, y en vista de los resultados (tasa de transferencia) de varios experimentos podemos decir que los dos parámetros críticos relacionados con la topología son:

a) VELOCIDAD DE TRANSMISIÓN: Cuando mayor sea la velocidad de red, menor será el tiempo de carga de los clientes. Sin embargo los experimentos demuestran que pasar de una Ethernet tradicional a 10 Mbps teóricos a una Fast Ethernet a 100 Mbps no significa multiplicar por 10 la tasa de transferencia, sino aproximadamente por 5 en el mejor de los casos (multicast). Esto es debido a que las diferencias tecnológicas de ambos estándares van más allá de la velocidad de transmisión.

b) HUBS O SWITCHES (COMPARTICION VERSUS CONMUTACIÓN): Teniendo en cuenta los resultados experimentales así como las diferencias entre estos elementos, podemos concluir:

• Las diferencias son mínimas en el caso de transmisión multicast cuando el segmento de pruebas está dedicado, y sólo incluye a los clientes y al servidor de arranque remoto. Sin embargo, en un caso real también existen otras estaciones que no están participando del arranque remoto pinchadas en el mismo elemento. Si éste es un hub, el tráfico de arranque remoto y el de las estaciones que están fuera de él comparten el mismo medio dentro de un único dominio de colisión, y por tanto se interfieren entre sí. Pero, si el elemento que une todas las estaciones es un switch, existe un dominio independiente de colisión por cada uno de sus puertos, los paquetes circulan desde el servidor a cada uno de los clientes sin entrar en los segmentos del resto de los puertos y el tráfico de arranque remoto está totalmente aislado del resto.
• Cuando la transmisión es unicast la mejoría del switch con respecto al hub es más evidente en todos los casos, por los mismos motivos expuestos anteriormente y otro nuevo de mayor impacto: la gran cantidad de ACKs hacia el servidor necesarios en unicast no supone ningún problema al switch porque los clientes son capaces de enviarlos y recibir a la vez la imagen del cliente (comunicación full-duplex). Este factor de mejora que se refleja en la tasa de transferencia incrementa a medida que aumenta el número de clientes, llegando por ejemplo a 10 en el caso de 6 clientes simultáneos.

4.- Otros factores cualitativos

Al margen de los parámetros estudiados hasta ahora, y centrándonos en el entorno universitario que nos incumbe, a continuación se citan brevemente otras características fundamentales que debería contemplar cualquier implementación de arranque remoto, así como ciertas políticas de buen uso.

• a) CACHÉ DE DISCO EN CLIENTES: Hace reducir el tiempo medio de carga total de cierta imagen sobre la partición destino, así como el tráfico específico de arranque remoto.
• b) IMÁGENES INCREMENTALES Y DIFERENCIALES: Permiten reducir el espacio de almacenamiento sobre el servidor de arranque remoto, así como disponer de una librería de software en imágenes para asociar a un cliente (distribución dinámica del software).
• c) SINCRONIZACIÓN COMO RESTAURACIÓN SELECTIVA: Permite reponer de forma rápida sólo los ficheros dañados. Se puede ver como una auto-reparación rápida del puesto de trabajo.
• d) TIEMPO DE VIDA DE LAS IMÁGENES: Para que las imágenes sean útiles durante más tiempo hay dos políticas a tener en cuenta: mantener todo el software posible fuera de la imagen (sobre un servidor de red por ejemplo), y no crear imágenes demasiado específicas (que dependan incluso del hardware del cliente).
• e) UBICACIÓN ÚNICA DEL ESPACIO DE USUARIO: Un sistema de arranque remoto multisistema debe proveer al usuario de una ubicación y validación única independiente del sistema operativo elegido. Existen varias soluciones para ambos problemas relacionadas que pueden combinar LDAP, radius, páginas amarillas, NFS, NetBios, etc.
• f) TOLERANCIA A FALLOS: La criticidad del servidor de arranque remoto plantea la necesidad de tolerancia a fallos a varios niveles diferenciados:
  • A nivel físico, disponiendo de UPS y fuentes redundantes.
  • A nivel de red, contando con líneas de backup en el servidor.
  • A nivel de sistema operativo, para poder validar usuarios aunque un servidor no esté operativo.
  • A nivel de DHCP, para proveer redundancia entre servidores y balanceo de carga.
  • A nivel de arranque remoto, disponiendo de servidores clones que permitan continuar una transferencia en el mismo punto cuando uno de ellos cae, o definir un sistema de prioridades entre ellos (REMBO, por ejemplo)

5.-Bibliografía

[1] REMBO Server/Client Administration Manual,
http://www.rembo.com
[2] BPBATCH, Universidad de Ginebra,
http://cuiwww.unige.ch/info/pc/remote-boot/
[3] Linux Remote-Boot mini-HOWTO: Configuring Remote Boot Workstations with Linux, DOS,
Windows 95/98 and Windows NT, v3.21 March 1999, March Vuilleunmier Stückelberg, David Clerc
[4] TCP/IP BOOT-PROM Users Manual. Version 1.56b, InCom Information & Communication GmbH,
Malcom Agnew, Ralf Büttner, Larry Epstein, Dirk Köppen
[5] Ethernet: de 2,94 a 1.000 Mbps en 25 años, Boletín de la red nacional de I+D RedIRIS
(http://www.rediris.es/rediris/boletin/), números 46, 47 y 48, Rogelio Montañana.

___
Notas:
1.- Algunas de las últimas versiones de TFTP permiten negociar el tamaño del paquete (opción blksize)
2.- La interrupción es resuelta por el software de TCP/IP asociado a la tarjeta de red
3.- El firmware de la tarjeta de red discierne las tramas que pertenecen a una sesión multicast propia sin interrumpir al procesador