1 EXPERIMENTOS Y EVALUACION DE METODOS DE ARRANQUE REMOTO APLICADOS A AULAS INFORMATICAS Pello Sánchez Cuesta IRAKASKUNTZA, IKERKETA ETA SAREAREN INFORMATIKAKO GUNEA CENTRO DE INFORMATICA DE DOCENCIA, INVESTIGACION Y RED

2 2 INDICE 1. PRINCIPIOS DEL ARRANQUE REMOTO 2. RESULTADOS EXPERIMENTALES 3. CONCLUSIONES BASADAS EN EXPERIMENTOS 4. CONCLUSIONES BASADAS EN EL USO. PARAMETROS CUALITATIVOS.

3 3 1- Principios del Arranque Remoto Breve Historia y Evolución  Inicialmente 1. Recursos Caros 2. Arranque remoto sin disco (estaciones disk less) 3. Informática centralizada en servidores Objetivo del A.R: Ahorrar recursos con sistema operativo de red  Actualmente 1. PCs con potencia gráfica, de cálculo y baratos 2. Trabajo en local 3. Puestos multisistema 4. Informática descentralizada sobre puestos de trabajo Objetivo del A.R: Eliminar tiempos de reinstalación del sistema operativo

4 4 1- Principios del Arranque Remoto Aportaciones del A.R. en aulas  Características especificas de aulas 1. Gran cantidad de equipos 2. Muchos usuarios diferentes 3. Diferentes S.O. inestables 4. Variedad de software cambiante en el curso 5. Alto costo de mantenimiento 6. Alto riesgo de virus  Ayuda del A.R. 1. Recuperación rápida a situación estable 2. Facilidades para selección de software y S.O. 3. Herramientas para validación presistema 4. Ayuda a instalaciones masivas de nuevos equipos 5. Reducción drástica del mantenimiento

5 5 1- Principios del Arranque Remoto Estimación de costo de mantenimiento diario por aula sin A.R.  Variables Nequip: Número de equipos en la sala. (24) Ta: Tiempo (horas) en que el aula está abierta en un día. (8) P(des): Probabilidad de que un equipo quede desconfigurado en una hora. (0.05) P(uso): Probabilidad de que un equipo este en uso dentro de una hora. (0.75) Ttec: Tiempo medio del técnico para reconfigurar un equipo no operativo. (15m) Ptec: Precio de una hora de técnico de mantenimiento de sala. (20 €)  Fórmula estimada (coste por aula/hora) Cman = Nequip * P(uso)* P(des) * Ttec * Ptec  Coste diario aproximado aula tipo Cman = 24 * 8 * 0.75 * 0.05 * 0.25 * 20 = 36 €= 5.989 Pts Cman = 24 * 8 * 0.75 * 0.05 * 0.25 * 20 = 36 €= 5.989 Pts

6 6 2- Resultados Experimentales Condiciones y topología  Sistemas A.R. –Bpbatch –REMBO  Imagen –Software: W98,Office2000, Solstice,SSH2, McAfee, Winzip. –Tamaño: 197 MB  PC Monitor: –HP AvanceStack Assistant  HUB HP J3202A  Gestión RMON  Red 10 Mbps  PC Monitor en segmento aislado

7 7 2.1. Efecto número clientes 1 cliente unicast  Gráficas similares  Baja utilización  TFTP: tamaño máx. paquete (1500 bytes en vez de 512).

8 8 2.1 Efecto número de clientes Evolución 1-3 clientes

9 9 2.1 Efecto número de clientes Resumen de datos (medias) CLIENTE S UTILIZAC ION (%) TRAFICO (BYTES/SE G) COLISION/SEG PAQUET ES/SEG TIEMPO TOTAL TIEMPO CARGA/ CLIENT E TASA TRANSFERE CIA (MB/SEG) 129,01362.1910,03586825555550,35 252,43655.0131,28191.2336003000,65 363,24790.056351,251.4887642540,77 471,92898.511642,1211.6911.1242810,70

10 10 2.1 Efecto número de clientes Conclusiones  El rendimiento de la red disminuye al aumentar el número de clientes –Aumenta el tráfico –Aumentan las colisiones  El tiempo medio de carga tiene un pto. de inflexión entre 3 y 4 clientes. –Buffering del servidor optimiza tiempos hasta llegar al cuarto cliente.  Es necesario buscar otro mecanismo de optimización independiente del número de clientes

11 11 2.2 Efecto del tamaño de paquete  TFTP tradicional –Tamaño paquete: 512 B  Experimento –Imagen de 20 MB. –2 clientes  TFTP optimizado (Bootix) a 802.3 –Buffering en servidor –Tamaño paquete máximo (1.500 B)

12 12 2.2 Efecto del tamaño de paquete Conclusiones  Mejora la utilización de la red  Mejora el rendimiento –Menos paquetes/s –Menos colisiones  Se reduce el tiempo total de carga COMPARATI VA TFTP TRADICION AL TFTP OPTIMIZAD O UTILIZACIO N 27,6143,95 COLISIONES /SEG 3,032,86 PAQUETES/ SEG 1.481,331.038,01 TRAFICO344.739,3548.942,61 TIEMPO14377 TASA TRANSFERE NCIA 0,13 MB/s 0,25 MB/s

13 13 2.3 Transmisión Broadcast Características  Ajuste del MTU al máximo permitido en 802.3 (1.500 B, datos útiles)  Transmisión única multidifusión sincronizada –Paquetes se envían una sola vez –Menos colisiones  Confirmación ACK por ventanas –IP sobre 802.3 tiene pocos errores –ACK cada 32 paquetes –Retransmisión de ventana en caso de error (todos los clientes esperan)

14 14 2.3 Transmisión Broadcast Comparativa 1-4 clientes

15 15 2.3 Transmisión Broadcast Conclusiones  Utilización fija (58%)  Tráfico broadcast idéntico  Aumento colisiones –Más clientes => Más ACK  Tiempo carga estable (215 seg)  Tráfico alto (58%) y molesto en la red –Broadcast escuchado por equipos ajenos –Interrupciones resultas por soft.  Se necesita otra solución menos “pesada” –Profundizar en topología y métodos de transmisión

16 16 2.4 Transmisión Multicast Características  Pruebas basadas en REMBO –MCAST basado en UDP con mecanismos de ventana deslizante. –Sesión escuchada únicamente por los clientes “unidos al canal”.  Proceso de transferencia 1.Cliente solicita fichero a servidor 2.Inicia sesión multicast nueva 3.O bien se engancha a la existente => Al final reclama al servidor los datos ya transmitidos (se convierte en cliente master)

17 17 2.4 Transmisión Multicast Comparativas 1-4 clientes CLIENTES UTILIZACIO N (%) TRAFICO (BYTES/SEG) COLISION/SEG MULTICAST /SEG PAQUETES/ SEG TIEMPO CARGA/CL IENTE 161,63770.1495,43508,44575,5849 262,13775.1327,50513,13580,8354 364,12799.9626,45528,39598,3164 464,84808.77010,34534,98607,0464

18 18 2.4 Transmisión Multicast Conclusiones y Comparativa  Escasa dependencia del número de clientes –Utilización similar (64%) –Aumento insignificante de colisiones  Aprovechamiento óptimo  Pval = Paquetes válidos por segundo  Col = Colisiones por segundo  A = Pval * 100 (Pval + Col * 2)  Con 4 clientes: METODOUNICASTBROADCASTMULTICAST APROVECHAMIENTO56%85%96%

19 19 2.5 Topología de la red  Factores determinantes –Velocidad: 10, 100, Full/Semi-duplex –Acceso al medio: compartido/conmutado  Elementos de red experimentados –SW1 (3Com 1100): Switch a 10, servidor a 100 –SW2 (Lantech 1601F): Switch a 100 –HUB1 (Lantech): Hub 10/100 (2 VLANs automáticas con bridging entre ellas) –HUB2 (HP J3202A): Hub 10

20 20 2.5 Topología de la red Tabla comparativa 1/2 ELEMEN TO INTER CONEXION CLIEN TES MODO DE TRANSMISI ON VELOCI DAD DE LA RED METODOVOLUMEN TRANSMITI DO (MB) TIEMPO DE TRANSFERENCIA POR RED (Min) TASA TRANSFERENCIA (MB/min) HUB2 2 UNICAST 10 BPBATCH 1979’15”21’29 419710’19’7 HUB2 1 BROADCAST 1973’5849 41973’5849 HUB2 2 MULTICASTREMBO 410’54”45’5 4411’04’’38’6 SW1 2 UNICASTClientes:1 0 Servidor: 100 BPBATCH 59916’37 SW1 2 MULTICASTREMBO 4487’69

21 21 2.5 Topología de la red Tabla comparativa 2/2 ELEMENTO INTERCO NEXION CLIEN TES MODO DE TRANSMI SION VELOCIDA D DE LA RED METO DO VOLU MEN TRANS MITIDO (MB) TIEMPO DE TRANSFEREN CIA POR RED (Min) TASA TRANSFERENCIA (MB/min) SW2 2 MULTICAST 100 REMBO 4482224 4 6 HUB1 2 MULTICASTREMBO 4482224 4 2’10’’207 6 2’50’’158 HUB1 2 UNICASTREMBO 44811’50”37’9 4 16’18”27’5 6 20’45”21’59 SW2 2 UNICASTREMBO 4485’15’’85’33 4 6’30”68’9 6 8’17’’54’63

22 22 3. Definición de parámetros basados en los experimentos  Protocolos de transmisión –TFTP no utiliza conocimiento de 802.3 –Uso de buffering en servidor –IP sobre 802.3 => Carga excesiva ACKs  Métodos de transmisión –UNICAST: Se degrada con más clientes –BROADCAST: Buena utilización estable.  ACKs por ventanas y tiempo de carga acotado  Molesto para equipos ajenos –MULTICAST: Aprovechamiento óptimo  Pocas colisiones y sin interferencias  JOINS a sesiones existentes

23 23 3. Definición de parámetros basados en los experimentos  Topología de red –Velocidad de Transmisión  Multicast sobre red compartida (hub): 802.3u ~ 802.3 * 4,9 (no * 10) –Red compartida vs conmutada  Multicast: Similar en segmento dedicado –Si no dedicado, conmutadas mejor (tráfico molesto). –Solución de aprovechamiento óptimo de la red (sin colisiones).  Unicast: Conmutadas mejor –ACK’s no colisionan (full duplex, dominio de colisión único por puerto) –Tráfico de arranque remoto aislado del resto

24 24 4. Definición de parámetros cualitativos basados en el uso  Caché local en clientes –Reduce el tiempo de carga normal –Recurso disco barato (3,6 €/GB)  Imágenes incrementales –Nuevas versiones y software en el curso –Librería de software  Sincronización vs Restauración –S.O. Inoperativos tras borrar un fichero –Restauración rápida ante virus

25 25 3. Definición de parámetros cualitativos basados en el uso  Tiempo de vida de imágenes –Mantener software fuera de la imagen (servidores de red) –Preparar imágenes genéricas (para varios modelos de PC, con varios drivers)  Ubicación única del espacio de usuario –Independiente del S.O. y el puesto –Facilita copias de seguridad –Solución posible:  Maquina Linux con cuentas de usuarios  Servidor de disco por NFS y Samba  Servidor de cuentas por yp y Samba

26 26 3. Definición de parámetros cualitativos basados en el uso Tolerancia a Fallos  Tolerancia genérica a varios niveles –Físico: UPS, alimentación redundante. –Red: Enlaces de backups en servidor –S.O: Servidores de autentificación múltiples  Tolerancia en DHCP –Diseñado para ser redundado –Balanceo de carga entre servidores –Protocolo escuchado por todos los servidores

27 27 3. Definición de parámetros en el uso Tolerancia en DHCP Servidor seleccionado Servidor no seleccionado Cliente DHCPDISCOVER DHCPOFFER DHCPREQUEST DHCPACK DHCPRELEASE (LIBERA)

28 28 Definición de parámetros en el uso Tolerancia en Arranque remoto (REMBO)  Recuperación automática en transferencias –Requiere servidor de backup idéntico –La transferencia se retoma en el punto donde se cortó  Balanceo de carga por prioridades –Cada servidor es un proxy DHCP  Responde al DHCPDiscover del cliente con DHCPOffer (con extensiones de PXE) despues de un tiempo T.  Tiene una prioridad asocidada en forma de T. –No interfiere con el auténtico servidor DHCP  Solo le aporta la configuración PXE, pero nada relativo a IP.

29 29 Definición de parámetros en el uso Tolerancia en Arranque remoto (REMBO)

30 EXPERIMENTOS Y EVALUACION DE METODOS DE ARRANQUE REMOTO APLICADOS A AULAS INFORMATICAS Pello Sánchez Cuesta IRAKASKUNTZA, IKERKETA ETA SAREAREN INFORMATIKAKO GUNEA CENTRO DE INFORMATICA DE DOCENCIA, INVESTIGACION Y RED http://www.sc.ehu.es/pello GRACIAS POR SU ATENCION