240 likes | 393 Views
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. INDICE. PRINCIPIOS DEL ARRANQUE REMOTO RESULTADOS EXPERIMENTALES
E N D
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
INDICE • PRINCIPIOS DEL ARRANQUE REMOTO • RESULTADOS EXPERIMENTALES • CONCLUSIONES BASADAS EN EXPERIMENTOS • CONCLUSIONES BASADAS EN EL USO. PARAMETROS CUALITATIVOS.
Inicialmente Recursos Caros Arranque remoto sin disco (estaciones disk less) Informática centralizada en servidores Objetivo del A.R: Ahorrar recursos con sistema operativo de red Actualmente PCs con potencia gráfica, de cálculo y baratos Trabajo en local Puestos multisistema Informática descentralizada sobre puestos de trabajo Objetivo del A.R: Eliminar tiempos de reinstalación del sistema operativo 1- Principios del Arranque RemotoBreve Historia y Evolución
Características especificas de aulas Gran cantidad de equipos Muchos usuarios diferentes Diferentes S.O. inestables Variedad de software cambiante en el curso Alto costo de mantenimiento Alto riesgo de virus Ayuda del A.R. Recuperación rápida a situación estable Facilidades para selección de software y S.O. Herramientas para validación presistema Ayuda a instalaciones masivas de nuevos equipos Reducción drástica del mantenimiento 1- Principios del Arranque RemotoAportaciones del A.R. en aulas
1- Principios del Arranque RemotoEstimació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
2- Resultados ExperimentalesCondiciones 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
2.1. Efecto número clientes1 cliente unicast • Gráficas similares • Baja utilización • TFTP: tamaño máx. paquete (1500 bytes en vez de 512).
2.1 Efecto número de clientesConclusiones • 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
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) 2.2 Efecto del tamaño de paquete
Mejora la utilización de la red Mejora el rendimiento Menos paquetes/s Menos colisiones Se reduce el tiempo total de carga 2.2 Efecto del tamaño de paqueteConclusiones
2.3 Transmisión BroadcastCaracterí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)
2.3 Transmisión BroadcastConclusiones • 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
2.4 Transmisión MulticastCaracterí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 • Cliente solicita fichero a servidor • Inicia sesión multicast nueva • O bien se engancha a la existente => Al final reclama al servidor los datos ya transmitidos (se convierte en cliente master)
2.4 Transmisión MulticastConclusiones 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:
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
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
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
GRACIAS POR SU ATENCION 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