UNIVERSIDAD SIMÓN BOLÍVAR. Ingeniería de la computación ENRUTAMIENTO DE SOLICITUDES DE USUARIOS PARA SERVIDORES WEB HETEROGÉNEOS.

Tamaño: px
Comenzar la demostración a partir de la página:

Download "UNIVERSIDAD SIMÓN BOLÍVAR. Ingeniería de la computación ENRUTAMIENTO DE SOLICITUDES DE USUARIOS PARA SERVIDORES WEB HETEROGÉNEOS."

Transcripción

1 UNIVERSIDAD SIMÓN BOLÍVAR Ingeniería de la computación ENRUTAMIENTO DE SOLICITUDES DE USUARIOS PARA SERVIDORES WEB HETEROGÉNEOS Por Aarón Gabriel Mizrachi Pérez Proyecto de Grado Presentado ante la Ilustre Universidad Simón Bolívar Como Requisito Parcial para Optar el Título de Ingeniero en Computación Sartenejas, julio de 2008

2 UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA DE LA COMPUTACIÓN ACTA FINAL DEL PROYECTO DE GRADO ENRUTAMIENTO DE SOLICITUDES DE USUARIOS PARA SERVIDORES WEB HETEROGÉNEOS Presentado por: AARÓN GABRIEL MIZRACHI PÉREZ Este Proyecto de Grado ha sido aprobado por el siguiente jurado examinador: Prof. Emely Arráiz (Tutor) Prof. Yudith Cardinale Prof. Eduardo Blanco SARTENEJAS, 16/07/2008

3 ENRUTAMIENTO DE SOLICITUDES DE USUARIOS PARA SERVIDORES WEB HETEROGÉNEOS POR AARÓN GABRIEL MIZRACHI PÉREZ RESUMEN El balanceo de requerimientos web en servidores ha sido uno de los principales tópicos de interés para quienes poseen páginas altamente solicitadas. Los principales objetivos que buscan los sistemas de despacho y balanceo de carga en servidores web, consisten en distribuir equitativamente la carga a lo largo de los recursos disponibles, y a su vez lograr los mejores tiempos de respuesta en el despacho de estos requerimientos. En los últimos diez años, se han desarrollado e implementado nuevos métodos para la distribución y el balanceo de requerimientos web, algunos de los cuales han presentado inconvenientes como por ejemplo, el rango limitado de algoritmos de distribución de requerimientos, el bajo nivel de portabilidad y la dificultad inherente para su implantación. Buscando una mejora continua sobre los métodos de despacho de conexiones, se han propuesto distintos mecanismos con sus ventajas y desventajas asociadas. Uno de estos mecanismos, Layer 4/7 con TCP Handoff descrito en Scalable Content-aware Request Distribution in Cluster-based Network Servers [10], presenta una opción prometedora para realizar un despacho de conexiones óptimo y a su vez abrir el espacio para la utilización de algoritmos de balanceo de requerimientos que puedan lograr una mejor distribución de recursos, como por ejemplo el Multi-Class Round Robin policy (MC-RR) descrito en Scalable web clusters with static and dynamic contents [9]. En este trabajo se presenta el desarrollo de un sistema que unifica los dos métodos anteriormente descritos para realizar distribución y balanceo de carga. En la búsqueda de soluciones innovadoras se logró: soportar servidores heterogéneos, realizar implementaciones poco invasivas al sistema operativo, lograr metodologías de aprendizaje dinámico de la carga requerida por una solicitud y mejorar el algoritmo de balanceo de carga MC-RR.

4 Índice General Capitulo 1: Introducción Problema de carga en servidores web Objetivos del proyecto...2 Capitulo 2: Algunas definiciones y estado del arte Definiciones El cluster web Estrategias de despacho Varios IP Certificados, DNS Round Robin Varios Dominios, Varias direcciones IP certificadas Varios Dominios, Varias direcciones IP certificadas con Round Robin Una dirección IP certificada, reescritura del paquete TCP (NAT) NAT/PAT Con conocimiento de estado del cluster NAT/PAT Con servicios diferenciados por puerto NAT/PAT Con servicios diferenciados por nombre de dominio ONE IP TCP HandOff HTTP Reverse Proxy Layer 4/7, Content-aware switching Layer 4/7, Content-aware switching con TCP Handoff Estrategias para la selección del servidor...19 Capitulo 3: Decisiones de implementación Elección sobre la distribución de paquetes Distribución de carga Parámetros para la distribución de carga disponibles...21

5 Elección de los parámetros para la distribución de carga Actividades para implementación del algoritmo de despacho Ventajas de las decisiones de implementación Desventajas de las decisiones de implementación...24 Capitulo 4: Protocolo L47H y distribución de requerimientos Estructura inicial: Nodo/Despachador Despachador Nodo Mecanismos de comunicación entre nodos (Protocolo L47H) Razón para la utilización de ETH_P_IP_FAKE Diagramas de secuencia del protocolo L47H Evento Conexión de un nuevo nodo Evento Mensajes sobre la saturación Evento Desconexión y re-conexión del despachador Evento Recepción de conexión del cliente (Sin modo aprendizaje) Evento Recepción de conexión del cliente (Con modo aprendizaje) Selección del mejor servidor Metodología utilizada para calcular el consumo del procesador Metodología utilizada para calcular el consumo del disco duro Metodología utilizada para correlacionar los valores de consumo de CPU/Disco y elegir el mejor servidor disponible Mecanismo de aprendizaje...38 Capitulo 5: Pruebas y análisis de resultados Programas de pruebas Página web de pruebas Otros programas utilizados...41

6 5.2. Hardware de pruebas Pruebas Prueba 1 - Requerimientos homogéneos, servidores heterogéneos Prueba 2 - Requerimientos heterogéneos, servidores heterogéneos...49 Capitulo 6: Conclusiones y Recomendaciones...52 Glosario de términos...54 Bibliografía...57 Apéndices...59 Apéndice A: Protocolo experimental ETH_P_IP_FAKE Estructura...59 Apéndice B: Protocolo experimental L47H - Estructura...60 Apéndice C: Aplicaciones...64 Apendice D: Layer 4/7 Content Aware Switching - Fundamentos...70 Apendice E: Contenido del CD...72

7 Índice de Figuras Figura 1: Topología Round Robin DNS...6 Figura 2: Topología de varios dominios...7 Figura 3: Topología de varios dominios con Round Robin DNS...8 Figura 4: Topología NAT/PAT...9 Figura 5: Topología de NAT/PAT con política de selección...10 Figura 6: Topología de NAT/PAT con diferenciación de puertos...11 Figura 7: Topología de múltiples NAT/PAT usando múltiples nombres de dominio...12 Figura 8: Topología para ONE IP...13 Figura 9: Topología TCP Handoff...14 Figura 10: Topología de proxy HTTP reverso...15 Figura 11: Topología Layer 4/7 Content Aware Switching...16 Figura 12: Layer 4/7 Con TCP Handoff...18 Figura 13: Diagrama de secuencia para conexión web utilizando Layer4/7 con TCP Handoff...26 Figura 14: Diagrama de secuencia con funcionamiento interno del nodo...27 Figura 15: Topología de Layer 4/7 con TCP Handoff...28 Figura 16: Escenario de bloqueo de Switch...30 Figura 17: Evento L47H - Conexión de un nuevo nodo...31 Figura 18: Evento L47H - Estado del nodo...31 Figura 19: Evento L47H, Secuencia de re-conexión del despachador...32 Figura 20: Secuencia de interacción NODO-Despachador-Cliente para una nueva conexión con el protocolo L47H...33 Figura 21: Secuencia de interacción NODO-Despachador-Cliente para una nueva conexión con el protocolo L47H con modo Aprendizaje...34 Figura 22: Hardware utilizado...41

8 Figura 23: Imagen de conjunto de conexiones para distintos tipos de distribuciones de carga...43 Figura 24: Diagrama de caja para distribución inteligente...44 Figura 25: Diagramas de caja para la distribución aleatoria...44 Figura 26: Regresión lineal simple para distribución aleatoria versus distribución inteligente...45 Figura 27: Imagen de conjunto de conexiones para distribución de carga aleatoria con peso y distribución inteligente...46 Figura 28: Diagrama de caja para distribución inteligente...47 Figura 29: Diagramas de caja para la distribución aleatoria con peso...47 Figura 30: Regresión lineal para comportamientos de distribución aleatoria por capacidad versis distribución inteligente...48 Figura 31: Imagen de conjunto de conexiones para distintos tipos de distribuciones de carga...50

9 Capitulo 1: Introducción 1.1. Problema de carga en servidores web En los últimos años el éxito de Internet ha sido sin precedentes, causando un crecimiento asombroso en el número de conexiones y velocidad. Esto ha provocado que los proveedores de contenidos web más solicitados busquen mecanismos para seguir atendiendo a los usuarios con la misma o mejor calidad del servicio. Sin embargo, para lograr atender la creciente cantidad de usuarios con tiempos de respuesta aceptables se deben contar con computadores más poderosos y mejores estrategias. Hasta el momento existen dos grandes maneras que nos permiten satisfacer la demanda: Utilización de una gran supercomputadora que pueda atender los requerimientos sin saturarse. Distribución de los requerimientos entre varios nodos servidores (cluster) utilizando diversas estrategias. El principal factor de decisión a la hora de implementar alguna solución es el costo-beneficio. Los cluster web, superan a las supercomputadoras en esto por dos razones fundamentales: 1. Escalabilidad: un cluster puede adaptarse y crecer a medida que los requerimientos sean mayores, mientras un solo supercomputador, debe ser reemplazado completamente cuando éste ya no pueda atenderlos. 2. Precios: A medida que se requieren supercomputadores cada vez más poderosos, el precio escala exponencialmente. No obstante el crecimiento de la capacidad de un cluster escala linealmente a medida que se le agregan computadores. La razón de los precios se puede corroborar fácilmente en la página web de Intel y en la página de DELL. Al chequear los precios de computadores de alto nivel de procesamiento como los basados en el chip Xeon con respecto a los computadores de escritorio basados en la tecnología CORE 2 DUO obtenemos lo siguiente: 1

10 Procesador Velocidad agregada Cantidad / Precio unitario Precio Core 2 Duo 3Ghz 96Ghz 16 / 459 USD 7344 USD 1 / 7585 USD 7585 USD 2 Xeon cuadruple 21.28Ghz de 2.66Ghz X5355 Esto indica que se puede comprar un gran computador de dos procesadores Xeon cuadruple por 7586 USD lo cual nos da una velocidad agregada de 21.28Ghz, ó 16 computadores con un procesador de doble núcleo de 3Ghz por 7344 USD lo cual nos da una velocidad agregada de 96Ghz. Nota: Esta comparación tiene errores de estimación que para el caso de estudio no es relevante, como lo son las mejoras que existen dentro de un procesador Xeon para manejar múltiples procesos que requieran de sincronía e intercomunicación rápida y eficaz. Sin embargo, cada proceso que atiende un requerimiento web es independiente y en la mayoría de los casos no requiere una comunicación de alta velocidad con otros procesos web ejecutándose. Si las necesidades de CPU de cada requerimiento son realmente altos, o se requiere una gran velocidad de transferencia de datos entre dos procesos web, el hecho de ejecutarlos y comunicarlos a través de la red estará limitado por los tiempos de respuesta de la tecnología utilizada para enlazar la red, lo cual podría incrementar los precios del cluster. Finalmente, la clave del uso de un cluster de computadoras en el caso web, es la facilidad de distribuir los requerimientos en varios equipos que pueden atenderlos por separado, configurados para responder de forma similar, dando la impresión al usuario de que sólo existe una gran computadora de alta disponibilidad Objetivos del proyecto En la actualidad los mecanismos para realizar balanceo de carga en servidores web presentan fallas comunes de diseño que en ciertas ocasiones los llevan a no alcanzar el nivel óptimo de desempeño. Entre los factores de fracaso de un sistema de balanceo de carga están: 2

11 El riesgo de saturación de un equipo que centralice las operaciones sobre los paquetes creando el cuello de botella. Mala elección del nodo candidato para atender el requerimiento: Si no existe un mecanismo previo para conocer el estado del nodo antes de atender el requerimiento, se corre el riesgo de sobresaturarlo. La imposibilidad de escalar el tamaño del cluster con hardware heterogéneo. La idea del proyecto es diseñar, implementar e implantar un distribuidor de carga web que posea la capacidad de revisar las peticiones antes de ser despachadas para conocer su carga y tomar decisiones de balanceo óptimas utilizando una buena estrategia. Además de conocer la carga actual de los nodos contribuyendo así a evitar los factores de fracaso que expusimos con anterioridad. 3

12 Capitulo 2: Algunas definiciones y estado del arte Definiciones El cluster web En un ambiente web, los requerimientos tienden a presentarse en ráfagas y el tráfico de cada uno de los usuarios debe ser atendido rápida y eficientemente. Las estrategias de balanceo de requerimientos web entre diversos nodos deberán ir orientadas hacia este objetivo. Actualmente existen diversas estrategias y fórmulas que se aplican para balancear y despachar cada requerimiento web en el cluster, cada una de las cuales tiene sus ventajas y desventajas. Uno de los principales problemas del balance de carga web, es saber dividir bien estos requerimientos entre los servidores disponibles para proveer los mejores tiempos de respuesta del requerimiento de forma equitativa, todo ello sin crear un cuello de botella en el balanceador que impida que el cluster pueda atender todos los requerimientos. En otras palabras, el balance de carga es diseñado para lograr el mejor aprovechamiento de una serie de recursos distribuidos. Las razones por la cual el despachador se puede saturar y llegar a ser cuello de botella pueden llegar a ser diversas, y dependen principalmente de dos factores: 1. Algoritmos de balanceo de carga web: Mientras el algoritmo de balanceo sea menos eficiente, la carga de memoria, red y cpu del balanceador aumentará, haciendo que se sature. Es por ello, que los mejores algoritmos tratan de sacar mayor provecho a la menor información procesada posible para evitar consumir recursos que puedan saturar el balanceador. 2. Capacidad del hardware: Mientras la capacidad del hardware del despachador de conexiones sea óptima, éste podrá ejecutar el algoritmo de balanceo, dividiendo el tráfico sin convertirse en un cuello de botella. 4

13 2.2. Estrategias de despacho A continuación presentamos un breve resumen de las estrategias utilizadas para dividir el tráfico entre servidores web. Dichas estrategias están determinadas por ciertos parámetros que podemos enumerar: a) IP externas certificadas disponibles: Cantidad de direcciones IP asignadas por el proveedor de servicios de Internet, accesibles desde cualquier lugar de Internet b) Tamaño del cluster: Cantidad de nodos que posee el cluster, así como velocidad de procesamiento de los nodos. c) Tipo de servicio prestado: Capacidad de diferenciar tipos de servicio, como por ejemplo, requerimientos que requieran acceso a base de datos, requerimientos de contenido estático, etc. d) Requerimiento solicitado: Capacidad de diferenciar el requerimiento web solicitado antes de realizar la elección del nodo servidor de forma de poder determinar tanto la cantidad de recursos que consume, como el tipo de servicio que requiere. e) Estado actual de carga del cluster: Capacidad de conocer el estado actual de los nodos del cluster para la toma de decisiones con el propósito de no sobresaturar a los nodos. f) Presupuesto: Capacidad económica para el desarrollo del cluster Varios IP Certificados, DNS Round Robin Esta técnica se basa en la utilización de varios registros de DNS con distintas direcciones IP para un solo dominio. Los DNS entregan estas direcciones IP de forma aleatoria a los clientes, de tal manera que se puede decir que en promedio el tráfico se distribuirá equitativamente entre los distintos servidores. El DNS que realiza el Round Robin, puede estar ubicado en cualquier parte de Internet y no necesariamente debe pertenecer a nuestra red de servidores, ver Figura 1. 5

14 Sin embargo, esta técnica presenta ciertos inconvenientes: Requiere varias direcciones IP Certificadas, las cuales son escasas No presta atención sobre el estado de carga actual de los nodos, ni sobre la carga necesaria del requerimiento. No puede distinguir el tipo de servicio solicitado. No distribuye de forma efectiva entre nodos de distinta capacidad. Figura 1: Topología Round Robin DNS A continuación presentamos dos solicitudes de resolución de dominio a google.com que posee DNS Round Robin: Query 1: Query 2: 6

15 Varios Dominios, Varias direcciones IP certificadas Esta técnica se basa en distribuir el tráfico utilizando distintos dominios para cada tipo de servicio. Por ejemplo, se pueden manejar las imágenes y archivos pequeños en nodos de bajo rendimiento a través de un dominio particular, la base de datos en otro dominio, y los archivos principales en otro dominio que representan nodos distintos. Un ejemplo a continuación: Servidor de base de datos: db.dominio.com ( ) Servidor de imágenes: img.dominio.com ( ) Servidor principal: dominio.com ( ) Servidor de archivos: files.dominio.com ( ) El servidor DNS puede estar ubicado en cualquier parte de internet, como se observa en la Figura 2. Figura 2: Topología de varios dominios Con ello, una página web podrá solicitar imágenes, requerimientos a la base de datos y archivos pesados sin saturar el contenido principal de la misma a través de distintos URL's: Esta metodología puede ser utilizada con un Round Robin de DNS, lo cual permite alojar varios nodos para los distintos tipos de requerimientos, adecuando estos nodos en cantidad y calidad a dichos tipos. 7

16 Sin embargo, esta técnica presenta algunos inconvenientes: requiere poseer varias direcciones IP Certificadas, las cuales son escasas no presta atención sobre el estado de carga actual de los servidores, ni sobre el peso del requerimiento. Requiere reescribir el HTML entregado, para que los URL coincidan con los servidores, lo cual no resulta ser transparente a la hora de implantar la solución. Cada tipo de requerimiento puede sólo ser atendido por el o los nodos elegido para esa función, no aprovechando nodos que se encuentran disponibles destinados a otras tareas Varios Dominios, Varias direcciones IP certificadas con Round Robin Consiste en aplicar la técnica anterior de división de contenido por DNS, agregando la posibilidad de que para cada dominio con diferente tipo de servicio existan varios IP que sean entregados de forma aleatoria, ver Figura 3. Las ventajas de utilizar esta metodología, es la posibilidad de agregar nodos manualmente a servicios donde haga falta más capacidad de procesamiento. Los problemas de este método son los siguientes: requiere varias direcciones IP Certificadas, las cuales son escasas no presta atención sobre el estado de carga actual de los servidores, ni sobre la carga necesaria del requerimiento. Figura 3: Topología de varios dominios con Round Robin DNS 8

17 Cada tipo de requerimiento puede sólo ser atendido por los nodos elegidos a esa función, no aprovechando nodos que se encuentran disponibles destinados a otras tareas Una dirección IP certificada, reescritura del paquete TCP (NAT) Basado en el principio de NAT / PAT, genera y mantiene una tabla de conversión para las conexiones con la cual reescribe los paquetes que entran y salen de la red para dirigirlos a los distintos nodos del cluster, ver Figura 4. La idea es reescribir los paquetes en capa 3 y 4 (IP/TCP) sin tener que tocar la información que transporta. Esto lo convierte en un proceso relativamente ligero lo cual permite que el despachador no se convierta en cuello de botella. Además permite ahorrar direcciones IP. Sin embargo, esta estrategia presenta características similares a la estrategia 2.2.3: No analiza el tipo de requerimiento por lo cual no puede predecir que carga necesaria de éste, ni qué tipo de servicio se solicita. No conoce el estado actual de los nodos del cluster Figura 4: Topología NAT/PAT NAT/PAT Con conocimiento de estado del cluster Utiliza el mismo sistema y topología de la estrategia 2.2.4; sin embargo, el despachador de conexiones, a través de un protocolo de monitoreo, posee información de la carga de los nodos servidores del cluster, ver Figura 5. Pudiendo así elegir nodos tomando en cuenta la saturación de estos. 9

18 Figura 5: Topología de NAT/PAT con política de selección Problemas asociados: Este sistema es capa 3 y 4 (IP/TCP), por lo cual no puede diferenciar el tipo de servicio solicitado. La emisión constante de estados del nodo puede saturar tanto la red como al despachador, y la emisión a períodos más largos puede conducir a una mala selección del nodo NAT/PAT Con servicios diferenciados por puerto Utiliza el modelo de distribución y reescritura de paquetes presentado en que nos permite ahorrar direcciones IP. Sin embargo, se pueden diferenciar algunos tipos de servicios mediante el puerto (443: HTTP SSL, 80: HTTP), ver Figura 6. 10

19 Figura 6: Topología de NAT/PAT con diferenciación de puertos Con ello se pueden tomar decisiones de distribución, ya sea asignando ciertas peticiones a ciertos servidores (cluster A: Servicios HTTP, cluster B: Servicios HTTPS), ó utilizando la información de la carga para seleccionar el mejor nodo que lo soporte. Problemas asociados: Este modelo no permite diferenciar los requerimientos más allá de saber si éste viene cifrado NAT/PAT Con servicios diferenciados por nombre de dominio Este modelo se basa en utilizar una estrategia similar a la presentada en 2.2.3, pero en vez de enviar los requerimientos a un solo servidor, se crean varios NAT con varios clusters, ver Figura 7. Cada cluster se adapta al tipo de requerimiento destinado en tamaño y características. 11

20 Figura 7: Topología de múltiples NAT/PAT usando múltiples nombres de dominio Por ejemplo, para servidores de archivos convencionales se adapta un cluster con mejor almacenamiento. Para base de datos se adapta un cluster con mucha memoria y capacidad de procesamiento. Problemas asociados: El problema principal de este modelo, consiste en que la distribución de los recursos físicos disponibles en los distintos clusters se debe realizar de forma manual. Por ejemplo, si se demuestra que el cluster que maneja las operaciones con la base de datos posee más memoria de la que necesita, y el cluster encargado de las operaciones con archivos requiere más memoria para hacer caché, se debe reemplazar manualmente la memoria afectando la disponibilidad del sistema. Este modelo también requiere la misma cantidad de direcciones IP para atender distintos requerimientos que el

21 ONE IP Esta metodología se basa en configurar todos los nodos con la misma dirección IP externa, siendo la dirección MAC el diferenciador para ubicar cada nodo dentro del cluster. Adicionalmente como se observa en la Figura 8, se requiere de un ONE IP Router para balancear la carga. Figura 8: Topología para ONE IP De esta forma no se necesita volver a calcular el checksum TCP, ni el checksum IP para cada paquete como se requería en NAT/PAT. Además, como en NAT/PAT, puede utilizar información del estado del cluster para elegir el mejor servidor disponible. Las ventajas de ONE IP se basan en el poco cálculo que debe hacer el enrutador ONEIP, lo cual implica que no se convierte fácilmente en un cuello de botella. Problemas asociados: Requiere deshabilitar el protocolo ARP en todo el segmento de red. Esto debido a que los todos nodos responden a la petición de ARP de ubicación por IP (Who has ip ?) con distintas direcciones MAC provocando confusiones entre los mismos nodos. Este sistema no puede diferenciar los tipos de servicio solicitado, a menos que se utilicen varios dominios. 13

22 TCP HandOff Esta metodología utiliza un protocolo de transferencia de responsabilidades. Un despachador que posee el IP certificado se encarga de seleccionar el mejor nodo que puede atender el requerimiento en un momento determinado, ver Figura 9. Mediante un protocolo interno, el despachador que atendió la conexión se Figura 9: Topología TCP Handoff comunicará con el nodo que debe atender el requerimiento para entregarle el primer paquete y encargarlo de la responsabilidad de manejar la conexión a nivel de capa 3 y 4. Esta metodología nos permite eliminar el cuello de botella entre la conexión de internet y los nodos. Sin embargo, requiere de cambios drásticos tanto en la estructura de la red como en el sistema operativo. Problemas asociados: Los nodos deben tener la misma dirección MAC, debido a que la puerta de enlace (Gateway) no acepta múltiples direcciones MAC por dirección IP. 14

23 Generalmente lleva consigo modificaciones a nivel de Kernel que pueden no ser sostenibles en el tiempo. Se deberá utilizar un HUB en vez de un Switch, Este sistema no puede diferenciar los tipos de servicios solicitados, a menos que se utilicen varios dominios con varios IP HTTP Reverse Proxy Tal como se puede observar en la Figura 10, utilizamos un proxy HTTP en el borde de la red interna que recibe la conexión, analiza el requerimiento, y realiza la selección del nodo servidor. Figura 10: Topología de proxy HTTP reverso Esto permite: Despacho con conocimiento previo de carga de los nodos. Conocimiento de la carga que genera el requerimiento web. Conocimiento del tipo de requerimiento a nivel de HTTP, que permite una mejor diferenciación de los servicios. Conocer tiempos de respuesta previos del mismo requerimiento. 15

24 Proxy caché en memoria, lo cual nos permite acelerar la entrega de páginas estáticas livianas altamente solicitadas. Acelera requerimientos cifrados con SSL si el hardware del proxy es óptimo para funciones de criptografía. Sin embargo existen problemas asociados: Representa una gran cantidad de carga para el despachador proxy, debido a que debe analizar todas y cada una de las secuencias TCP, lo cual es un proceso costoso que puede convertirlo en cuello de botella. Es por ello que generalmente se emplea este método en conjunto con otros (Ej. Round Robin DNS) Layer 4/7, Content-aware switching Consiste en un despachador que debe atender el requerimiento hasta lograr un entendimiento parcial, generalmente esto ocurre cuando recibe el primer paquete de datos. Luego este despachador debe entregar la conexión a través de NAT/PAT a uno de los nodos dispuestos como se puede observar en la Figura 11. Para seleccionar el mejor nodo que atiende el requerimiento, se conoce la carga actual de cada nodo y se realiza un pre-análisis para determinar la carga del requerimiento. Como ventaja principal sobre un proxy reverso, el router de Layer-4/7 no tiene que mantener la conexión abierta, sino simplemente realizar procesos de NAT/PAT los cuales se reducen a recalcular checksum y modificar la cabecera TCP/IP. Sin embargo, este sistema es completamente heurístico y se basa en ciertas suposiciones que generan problemas en contados casos: Figura 11: Topología Layer 4/7 Content Aware Switching 16

25 En IP no se garantiza que los paquetes vengan ordenados. El principal paradigma de este método es la capacidad de analizar el requerimiento sin volver a ensamblar TCP, lo cual implica no realizar reconstrucción de la secuencia a pesar de que los paquetes vengan en desorden. Si el primer paquete de datos de la conexión llega en desorden o llega fragmentado, se debe optar por despachar la conexión sin conocer el requerimiento ó esperar por el primer paquete. En TCP/IP no se garantiza que el primer paquete contenga todo el requerimiento: La misma pudo haber sido fragmentada por un bajo MTU en el cliente, se debe optar por despachar la conexión sin conocer el requerimiento o en su defecto volver a ensamblar la secuencia TCP para conocerla. Una sesión TCP puede mantener varios requerimientos web consecutivos luego de establecida la conexión con el servidor, lo que nos lleva a dos problemas: o La decisión de carga para realizar la selección del servidor no cubre las demás peticiones. o Cada nodo del cluster debe poder entregar cualquier tipo de requerimiento sin capacidad de diferenciación de servicios. Nota: esto puede evitarse con el encabezado de HTTP Connection: Close, sin embargo, esto nos puede causar overhead en la red si se tiene poco ancho de banda Layer 4/7, Content-aware switching con TCP Handoff Una novedosa técnica recientemente implementada, consiste en mezclar los beneficios de Layer 4/7 con TCP Handoff eliminando un posible cuello de botella en el despachador, como se puede observar en la Figura 12. Este método se basa en delegar la conexión como en TCP Handoff (2.2.9), pero conociendo el requerimiento como en Layer 4/7 (2.2.11), lo cual nos permite tomar una mejor decisión sobre el balance de carga. 17

26 Figura 12: Layer 4/7 Con TCP Handoff Actualmente hay dos proyectos OpenSource que implementan esta tecnología a nivel del Kernel: LVS Linux Virtual Server TCPHA Sin embargo presenta las siguientes desventajas: Requieren modificar el Kernel, lo cual las hace poco portables. Presentan un número limitado de algoritmos de selección de nodo Requieren eliminar ARP para evitar que varios nodos respondan al mismo IP. El despachador es el encargado de redirigir todos los paquetes entrantes. 18

27 2.3. Estrategias para la selección del servidor En la sección 2.2 se presentó un resumen de las estrategias para realizar el despacho de la conexión, éstas están relacionadas con las estrategias para la selección del servidor ya que la selección del servidor depende del conocimiento de parámetros como la carga actual del cluster y la carga del requerimiento. De acuerdo con las capacidades de la estrategia de despacho adoptada se puede utilizar distintos tipos de distribución de carga: Se conoce el Estado de los nodos servidores Se conoce el requerimiento - Se puede elegir el nodo servidor que mejor ajusta al requerimiento Best fit No se conoce el requerimiento - Se puede enviar la carga al nodo servidor con mejor disponibilidad - Se puede realizar un mejor - No se puede saber si el balanceo de carga para conseguir requerimiento saturará el homogeneidad en la carga de los servidor nodos servidores. - No se conoce el estado exacto - Se puede predecir qué nodo del servidor sino hasta haber servidor tiene el documento en recibido una actualización caché (Recientemente utilizado) y esto puede además mezclarse - Si las actualizaciones son con políticas donde se conoce el constantes puede saturar la red. estado del servidor. No se conoce El estado de los nodos servidores - Se puede predecir el estado futuro del servidor conociendo la carga del requerimiento y la carga del nodo. - Se pueden dividir los nodos - Se puede utilizar Round Robin servidores en grupos para para enviar homogéneamente la atender requerimientos distintos carga y esperar que se saturen de forma similar - Se puede predecir qué nodo servidor tiene el documento en - Se puede utilizar Random con caché (Recientemente utilizado). peso por nodo, el cual podría soportar homogéneamente la - Se puede determinar cuántos carga en servidores recursos consume el heterogéneos. Sin embargo, no requerimiento y elegir el servidor de forma exacta ya que cada más capacitado. requerimiento puede variar. 19

28 Capitulo 3: Decisiones de implementación 3.1. Elección sobre la distribución de paquetes Para este proyecto se eligió utilizar la estrategia Layer 4/7 con TCP HandOff (2.2.12) que evita el riesgo de saturación del equipo que centraliza operaciones y la mala elección del nodo servidor. Esta elección es actualmente la utilizada por IPHA y LVS, sin embargo, presentamos mejoras sustanciales: No se modifica el Kernel y no es necesario deshabilitar ARP Es posible conocer y predecir el estado del cluster Posee algoritmos mejorados para la distribución de carga con modo de aprendizaje. Admite hardware heterogéneo en el cluster. Para más detalles de Layer 4/7 ver apéndice D Distribución de carga En este proyecto se integran y desarrollan técnicas para medir la carga de un requerimiento y calcular estrategias que permiten balancear heurísticamente la carga a través de los nodos logrando niveles de saturación homogéneos sobre nodos servidores heterogéneos. Para lograr un balanceo efectivo de carga web sobre un cluster heterogéneo, se puede realizar por tres vías: 1. Conocer la carga actual de cada uno de los nodos mediante constantes actualizaciones vía red 2. Predecir heurísticamente la carga mediante los requerimientos enviados a cada servidor 3. Combinar las dos técnicas antes mencionadas. 20

29 En el sistema desarrollado, se eligió la forma de combinar las predicciones heurísticas con actualizaciones constantes Parámetros para la distribución de carga disponibles Los parámetros de decisión para la distribución de carga son representados como la disponibilidad de los recursos, y los recursos necesarios para atender un requerimiento. Algunos parámetros de decisión para determinar el mejor servidor son: Uso del procesador: Definido por los ciclos libres del procesador en un período de tiempo. Uso de la memoria: Definido por la cantidad de memoria libre del sistema en bytes. Uso de la red: Definido como la taza de transferencia en bytes, la cual es determinada por los bytes transmitidos en un período de tiempo. Uso del disco: Definido por los bytes transmitidos y recibidos desde una unidad de disco en específico en un período de tiempo Elección de los parámetros para la distribución de carga Generalmente el desempeño de un cluster es medido por una relación entre el costo en dinero del mismo y la capacidad de atender una cantidad de requerimientos de forma homogénea. Mientras más parámetros para la distribución de la carga se utilicen en el algoritmo de selección de nodo servidor, el balanceo de los recursos puede estar tomando en cuenta parámetros no indispensables y realizando selecciones erradas. Es por ello que los parámetros que representen recursos más costosos a nivel monetario deben ser evaluados con prioridad sobre otros menos costosos para evitar malgastar recursos económicos. Un ejemplo de ello es la red. Si tomamos decisiones de balanceo donde consideremos que la velocidad en la red es más importante que la lectura en disco, finalmente, el disco se encontrará saturado y la decisión administrativa a posterior será de comprar más discos para los servidores. Cada disco puede costar entre 100$ y 300$, si esto lo multiplicamos por 100 servidores, el costo de inversión será entre 10000$ y 30000$. Sin embargo, si tomamos 21

30 como más importante la velocidad del disco, posiblemente el parámetro que no quede bien balanceado sea la red. Una ampliación de la capacidad en red cuesta aproximadamente 10$ por servidor, para 100 servidores, el costo de inversión será de 1000$. Con este ejemplo, ilustramos de forma pragmática cómo se deben tomar estos valores en orden de importancia. Otro factor a la hora de tomar decisiones sobre la importancia de un parámetro es la saturación promedio del mismo. Por ejemplo, existen características que son costosas económicamente, pero que pueden ser desechados por considerar que no se llegarán a saturar. Un ejemplo de ello es la memoria. Un servidor web difícilmente llenará la memoria debido a que las funciones básicas asociadas al mismo sólo requieren leer un requerimiento y escribir en un socket, pequeños fragmentos de respuesta. Finalmente, basados en una relación de costo beneficio, elegimos como parámetros de balanceo de carga el CPU y el uso de disco, ya que parámetros como memoria y uso de la red no son susceptibles a saturación en un corto plazo Actividades para implementación del algoritmo de despacho Se desarrolló un protocolo de comunicaciones en capa 2 (L47H) que permite redirigir y volver a ensamblar los paquetes que recibe el despachador y son asignados a un nodo en específico. Además este protocolo permite sincronizar dinámicamente los nodos con un servidor despachador que contiene una configuración maestra. Mediante la utilización de interfaces virtuales basadas en TUN/TAP, cada nodo posee una dirección IP externa en su interfaz de red real, y una dirección IP común en la interfaz de red virtual. El programa que reescribe las conexiones trabaja a nivel de usuario y no a nivel de Kernel, logrando una mejor portabilidad entre sistemas y cambios menos radicales. El programa que reescribe las conexiones se encarga del NAT en cada uno de los nodos de forma distribuida, logrando evitar que el nodo despachador se convierta en un cuello de botella 22

31 El programa que reescribe las conexiones se encarga de transferir los paquetes entre la interfaz virtual y la real, de esta forma, quien se encarga de filtrar ARP no es el Kernel, y todos los computadores pueden responder con el mismo Mac Address y mismo IP Ventajas de las decisiones de implementación No es necesario que el hardware sea homogéneo, de hecho, uno de los objetivos principales de este trabajo consiste en poder hacer crecer el cluster con nuevo hardware sin desechar el viejo. En otras implementaciones similares de TCP Handoff, se requiere modificar el Kernel del sistema operativo para evitar las respuestas ARP duplicadas de solicitud del mismo IP, en esta no. Al mezclar TCP Handoff con Layer4/7, podemos interpretar el requerimiento inicial del cliente web sin la necesidad de recibir completamente la conexión. El hecho de utilizar TCP Handoff permite delegar el proceso de reconversión de números de secuencia y checksum al nodo servidor que atiende la solicitud, si bien es una tarea sencilla de realizar, puede convertirse en un cuello de botella si varias de estas conexiones son re-ensambladas en un equipo ejecutando el protocolo de Layer 4/7 Content Aware Switching El mecanismo de selección del mejor servidor considera una predicción de la carga actual de cada nodo del cluster. El mecanismo de selección del mejor servidor considera más de un parámetro para tomar su decisión, de modo que se da por sentado que la saturación de un servidor podría deberse no sólo a la saturación del recurso CPU, sino también de otros recursos como Memoria ó Uso de disco. Las reglas de distribución de carga según la petición considera que cada petición tiene un consumo distinto de carga. El mecanismo de selección del mejor nodo es Orden n, en donde n es la cantidad de nodos que pueden atender el requerimiento, lo cual evita la saturación del despachador. 23

32 Desventajas de las decisiones de implementación Se debe enviar en la cabecera HTTP el parámetro Connection: Close, ya que el cliente puede enviar varias solicitudes en una misma conexión y esto afectaría la predicción. No se acepta IPv4 fragmentado. Al unir los nodos, se deberá utilizar un HUB en vez de un Switch para evitar que paquetes con el mismo Mac Address en distintos puertos causen una confusión del Switch. Sin embargo la utilización de un HUB no se considera un problema severo en este caso, esto debido a que generalmente todas las conexiones son entre los nodos y el Gateway, caso en el cual la segmentación de los dominios de colisión que realiza un Switch es poco efectiva. La negociación implementada en L47H consume ancho de banda de la red local, se sugiere la utilización de redes LAN mas veloces. 24

33 Capitulo 4: Protocolo L47H y distribución de requerimientos 4.1. Estructura inicial: Nodo/Despachador La arquitectura implantada posee dos tipos básicos de módulos; el despachador, quien es el que se encarga de recibir y redirigir la conexión inicial del cliente a los nodos servidores mediante una estrategia de balanceo de carga, y el nodo, quien se encarga de recibir y volver a ensamblar los paquetes provenientes del despachador para entregarlos a la aplicación de servidor web que escucha en una interfaz virtual TUN/TAP, el nodo luego debe independizarse del despachador y responder directamente al cliente Despachador El despachador recibe los paquetes SYN de conexión HTTP, respondiendo el paquete SYN/ACK al cliente y esperando por el primer ACK del Three Way Handshake de TCP. Adicionalmente el despachador espera el primer paquete de datos de la conexión. Se asume que en el primer paquete de datos hay suficiente información para determinar la petición del cliente y calcular los recursos necesarios tanto en procesador como en disco. Una vez hecho esto, el despachador envía todos los paquetes que recibió del cliente web al nodo que se encargará de darle respuesta, para poder luego desentenderse de la conexión. Para evitar la congestión del despachador, el nodo que atiende la solicitud reescribe los números de secuencia y checksums TCP a medida que transcurre la conexión basado en el primer número de secuencia que recibió el cliente del despachador. Este mecanismo esta descrito en el diagrama de secuencia de la Figura

34 Figura 13: Diagrama de secuencia para conexión web utilizando Layer4/7 con TCP Handoff 26

35 Nodo En el nodo reside la aplicación de servidor web que atiende el requerimiento, éste recibe la conexión del despachador a través de un paquete SYN modificado que indica cual nodo debe atender la solicitud y con qué número de secuencia comenzó a responderse (Seq2), reteniendo el paquete SYN/ACK de salida y volviendo a procesar los paquetes de datos anteriormente recibidos por el despachador. Una vez el nodo recibe el requerimiento, éste sincroniza los números de secuencia a los utilizados por el despachador de forma que el cliente no nota un cambio en la conexión que pueda hacerla fallar. El funcionamiento interno del nodo, consiste en generar una interfaz virtual que replicará y reescribirá los paquetes en la interfaz de red del nodo. El servidor web escuchará conexiones en esta interfaz virtual, y la aplicación nodo procesará los paquetes para enviarlos a la interfaz de Ethernet disponible. Este mecanismo se describe en la Figura 14. Figura 14: Diagrama de secuencia con funcionamiento interno del nodo 27

36 Es importante destacar que el nodo responde las peticiones con el mismo IP y el mismo MAC Address que el despachador, de esta forma se garantiza continuidad, y ni la puerta de enlace, ni los switches superiores al HUB notan ninguna diferencia relevante que pueda bloquear el tráfico saliente. Para ello se plantea la topología de red visualizada en la figura 15: Figura 15: Topología de Layer 4/7 con TCP Handoff El DNS permanece fuera de la red, indicando que la dirección de la página web se encuentra en el IP externo suministrado. En este caso, el despachador es el único que tiene dirección IP externa en la interfaz de red Ethernet, y los nodos poseen la misma dirección IP que el despachador en la interfaz virtual. 28

37 Ningún paquete es replicado en la interfaz real Ethernet del sistema de los nodos a menos que el despachador le delegue la conexión, en cuyo caso, sólo los paquetes de la conexión podrán viajar de la interfaz virtual donde se encuentra el servidor HTTP, a la interfaz real donde se encuentra la red. De esta forma se evita tener que bloquear ARP para evitar duplicados a nivel del Kernel debido a que la aplicación sólo dejará pasar paquetes TCP Mecanismos de comunicación entre nodos (Protocolo L47H) Cada nodo puede no poseer una dirección IP, es posible que las interfaces de red de los nodos no posean dirección IP, y sólo las interfaces virtuales posean el mismo IP para todos los nodos. Para lograr una comunicación efectiva entre el despachador y los nodos, sin valernos de IP ni del MAC Address, se creó un protocolo de comunicaciones capa 2 de nombre L47H. Adicionalmente se crearon dos extensiones de IP para retransmitir paquetes internamente llamados: ETH_P_IP_FAKE: Retransmitir paquete SYN de conexión con información del servidor nodo quien atiende el requerimiento ETH_P_IP_FAKE2: Retransmitir paquetes conectados a la red sobre los MAC Address. evitando confundir a equipos El protocolo L47H fue diseñado para las siguientes labores: Comunicar al despachador sobre el estado de cada uno de los nodos del cluster a través de paquetes emitidos periódicamente Intercomunicar al despachador con los nodos para aprender cuál es el costo de cada petición realizada al cluster Anunciar y reconectar nuevos nodos en el cluster Transmitir la configuración del despachador a los nodos, de modo que todos posean el mismo IP en la interfaz virtual. Para más información acerca de la estructura de los protocolos, ver apéndice A y B 29

38 Razón para la utilización de ETH_P_IP_FAKE2 Como se mostró en la Figura 13, en el método Layer 4/7 con TCP Handoff, el despachador le envía al nodo los paquetes ACK y ACK-PSH que retiene del cliente. Estos paquetes contienen los datos originales de la conexión con el requerimiento del cliente. Si estos paquetes fuesen replicados al HUB sin ninguna modificación ocurriría un problema de pérdida de paquetes como se explica a continuación: Supóngase que el Gateway tiene MAC Address 00:00:00:00:00: El paquete es replicado con el mismo MAC Address del Gateway por el despachador (MAC 00:00:00:00:01) 2. El HUB retransmite a todos sus puertos el mismo paquete, incluyendo el puerto del Gateway 3. El Gateway por lo general tiene un Switch intermedio, es decir, existe un Switch entre el HUB y el Gateway, este Switch aprende que el MAC Address 00:00:00:00:01 está en el puerto del HUB y no del Gateway (el cual corresponde) Figura 16: Escenario de bloqueo de Switch 4. Inmediatamente después, el nodo envía un paquete al Gateway, este paquete, tiene como MAC destino el MAC del Gateway (00:00:00:00:00:01), y el Switch tiene guardado este MAC en el puerto del cluster y no del Gateway, desviando su destino incorrectamente. 5. Finalmente y segundos después, el cliente vuelve a enviar los datos que no fueron acusados por el nodo, los cuales corresponden a la réplica que envió el despachador, en este caso, el Switch vuelve a aprender el MAC Address del Gateway en el puerto correcto y los datos posteriores se envían correctamente. 30

39 En este juego se pierden segundos y se agrega una retransmisión de datos. Para evitar este escenario, se reescribe el encabezado de Ethernet con valor 0x090A en vez de 0x0800 de IP, además de reescribir el MAC Address fuente por el del despachador. Esto le indica al nodo que debe entender internamente que el paquete es una réplica del Gateway y debe reescribir el MAC Address antes de pasarlo a la interfaz virtual Diagramas de secuencia del protocolo L47H A continuación presentaremos diagramas de secuencia explicando cada uno de los eventos posibles por el protocolo L47H Evento Conexión de un nuevo nodo Al conectarse un nodo, como vemos en la Figura 17, éste envía un anuncio del nodo a la red con su información, como por ejemplo, su número de identificación, su nombre y sus capacidades. El despachador tiene la responsabilidad de registrarlo y enviarle un mensaje al nodo recién conectado con la información del cluster (Direcciones IP y Direcciones MAC) Figura 17: Evento L47H - Conexión de un nuevo nodo Evento Mensajes sobre la saturación Como vemos en la figura 18, luego de establecerse la conexión del nodo, éste comienza a enviar periódicamente datagramas con la información de su estado, a intervalos predefinidos por el usuario. En la separación de tiempo que existe entre cada notificación de estado del nodo, el despachador debe predecir la saturación de los nodos utilizando heurísticas. Figura 18: Evento L47H - Estado del nodo 31

40 Evento Desconexión y re-conexión del despachador Como vemos en la Figura 19, uno de los errores preconcebidos es la re-inicialización del despachador. En tal caso, el nodo, quien transmite su estado periódicamente, es informado de que debe volver a enviar su anuncio, luego de eso, ocurre la secuencia de conexión de un nuevo nodo en la cual se envía el anuncio de un nuevo nodo, y el despachador responde con su información, finalmente se envía el estado del nodo periódicamente. Figura 19: Evento L47H, Secuencia de re-conexión del despachador Evento Recepción de conexión del cliente (Sin modo aprendizaje) En una conexión con el protocolo Layer 4/7 Content Aware Switching + TCP Handoff, la implementación propuesta en este trabajo utiliza el protocolo L47H, ETH_P_IP_FAKE y ETH_P_IP_FAKE2 para informar al nodo de los paquetes que llegan al despachador. El diagrama de secuencia de la Figura 20 muestra la secuencia de interacción: 1. El despachador envía un SYN modificado con el protocolo ETH_P_IP_FAKE para anunciar al nodo que ha recibido una nueva conexión 2. El cliente envía mediante el protocolo L47H una solicitud de replay de la conexión, que no es más que la solicitud de retransmisión de los paquetes guardados por el despachador. 3. El despachador envía los paquetes modificándolos con ETH_P_IP_FAKE2 y se olvida para siempre de la conexión. 32

41 El overhead de esta operación es representado por 4 paquetes adicionales que se emiten a la red local, sin embargo la utilización de este mecanismo ayuda al despachador a no procesar las conexiones mientras el nodo responde la solicitud, mejorando así los tiempos de respuesta al elegir servidor. Si comparamos este mecanismo con respecto a otros métodos como layer 4/7 content aware switching solo, podemos predecir que la selección del servidor no se verá afectada por la cantidad de conexiones. Figura 20: Secuencia de interacción NODO-DespachadorCliente para una nueva conexión con el protocolo L47H 33

42 Evento Recepción de conexión del cliente (Con modo aprendizaje) A diferencia del modo de conexión sin aprendizaje, el modo de conexión con aprendizaje envía al Nodo el flag de aprendizaje activado al nodo. Además, el despachador marca al nodo como ocupado mientras éste responde el requerimiento para evitar mediciones incorrectas con varios requerimientos solapados. Este modo de aprendizaje, como se puede observar en la Figura 21, envía al finalizar la conexión un mensaje del nodo al despachador con la información de cuanto CPU y Disco consumió. El despachador tiene el deber de registrarlo y procesar esta información de forma persistente y permanente. También es importante recalcar que el despachador debe ajustar una escala común a todos los nodos para lograr una medición fiable que trascienda a nodos de distinta capacidad. Figura 21: Secuencia de interacción NODODespachador-Cliente para una nueva conexión con el protocolo L47H con modo Aprendizaje 34

43 4.3. Selección del mejor servidor Existen varias estrategias que nos podrían servir para elegir el mejor nodo a utilizar para el despacho de la conexión, en este caso, al poseer información sobre el requerimiento, se puede predecir como este requerimiento afectará a cada uno de los nodos. Es importante destacar que el diseño del algoritmo de selección del nodo es crucial para evitar la sobresaturación de alguno de los nodos en especial, de la red, e incluso del despachador. El principal objetivo al realizar una mejor selección de servidor, pretende disminuir la variabilidad de tiempos de respuesta mejorando así la percepción del usuario sobre el cluster. Como en nuestro caso estamos trabajando sobre servidores heterogéneos, una distribución uniforme sobre los nodos no es eficiente, especialmente si hay variabilidad en varios factores (cpu, disco, etc). La idea principal es mantener los porcentajes de consumo de recursos de todos los servidores de forma similar. Para ello utilizaremos los parámetros de decisión antes mencionados, calculando el mejor servidor a través de una comparación de combinaciones lineales entre el consumo predicho de CPU y Disco. A continuación se especifica cómo se mide en el sistema operativo cada uno de los parámetros de decisión seleccionados (CPU y Disco) Metodología utilizada para calcular el consumo del procesador En la plataforma Linux, el Kernel no provee información sobre cuál porcentaje del procesador se está utilizando actualmente, sin embargo, mediante el archivo /proc/stat, se puede leer valores de cuántos ciclos ha consumido cada parte del sistema (kernel, aplicación, idle, etc). Para obtener el valor porcentual de cuánto CPU fue utilizado, sumamos los ciclos en un período de tiempo T definido, y relacionamos qué porcentaje de ciclos consumió idle, el cual representa, el porcentaje libre de CPU en un período de tiempo snaptime T. Por ejemplo, si en el primer snap, /proc/stat informa que a lo largo del transcurso del sistema se han consumido ciclos, de los cuales 2000 fueron idle, y en el 2do snap, las estadísticas dicen que se han consumido ciclos, de los cuales

44 fueron idle, en un snaptime (diferencia de tiempo T entre dos snaps), se puede constatar que se consumió 1000 ciclos, de los cuales 100 fueron idle, lo cual resulta de la resta de , y , es decir, tiene 10% del procesador libre. Este mecanismo de calculo del consumo de CPU es utilizado por herramientas como top en Linux. Estandarización de los valores de CPU: La medida BOGOMIPS es un estándar en Linux que define cuál es la capacidad real del sistema en una escala universal y sencilla, no contemplando extensiones complejas que podrían variar entre procesadores. Al aplicar una simple proporción, donde la cantidad de bogomips detectada en el sistema es el 100% del CPU, y el porcentaje de uso del CPU durante un período de tiempo snaptime, representa cierta cantidad de bogomips utilizados en durante el proceso, podrán medirse en una escala similar el peso de cada proceso. Esta estandarización nos permite interrelacionar los consumos en servidores heterogéneos Metodología utilizada para calcular el consumo del disco duro En la plataforma Linux, el Kernel no provee información sobre qué porcentaje del disco se está utilizando actualmente, sin embargo, mediante el archivo /proc/diskstats, se puede leer valores de cuántos sectores se han leído hasta el momento por cada dispositivo. Al iniciar el programa, y con la especificación de qué unidad de disco medir, se inicia un proceso de período snaptime T que lee disco indiscriminadamente. Finalmente, cuando termina, la cantidad de cluster leídos en un snaptime representa el 100% del consumo máximo en un snaptime. Este valor es transmitido al despachador para realizar los cálculos Metodología utilizada para correlacionar los valores de consumo de CPU/Disco y elegir el mejor servidor disponible Una vez iniciado el sistema, cada nodo debe informar a su despachador sobre los recursos que éste posee en su máquina, sean en bogomips, y en máximo de sectores que se pueden leer por unidad de tiempo snaptime. 36

45 Todos los snaptimes deben ser iguales para un mejor desempeño y una comparación justa. Esta información sirve para calcular el grado de saturación de cada uno de los nodos. Periódicamente, cada snaptime, que por defecto son 4 segundos, los nodos envían un broadcast a la red que informará sobre el estado de consumo del nodo en el último snaptime. De esta forma el despachador puede calcular qué porcentaje libre posee para cada recurso. El método de comparación entre nodos servidores se basa en la siguiente estrategia: Recibir información del consumo de un requerimiento (bogomips utilizados, sectores a leer) o Los bogomips utilizados se calculan en base al porcentaje de saturación del CPU, si el CPU está saturado en un 50%, y la capacidad máxima de bogomips del CPU es de 4000, entonces, el servidor está saturado en 2000 bogomips. Para cada nodo, calcular: o Porcentaje de saturación predicho en CPU, se calculan mediante los bogomips en uso actuales (B.a), más los bogomips requeridos (B.r), dividido entre los bogomips de capacidad (B.c), Fórmula: o Porcentaje de saturación predicho en Disco, se calcula mediante los sectores de disco leídos en un SnapTime, sumados a los sectores requeridos, todo ello divido entre los sectores capaces de leer el nodo. Agregar un factor no lineal: Debido a que los CPU no se comportan ni se saturan linealmente por diversas razones, entre ellas que mientras más procesos existen deben agregar más operaciones para intercambio de procesos, se debe agregar un factor de corrección no lineal. Este factor se suma a el porcentaje de saturación de CPU predicho de la siguiente manera: o Se toma F.c un valor de costo de CPU máximo en bogomips/snaptime, generalmente F.c es un valor preestablecido 37

46 o Sat es el % de saturación (valor de 0 a 1.0) actual del servidor Fusionar el valor de saturación de CPU predicho tomando en cuenta el factor no lineal, con el valor de saturación de Disco predicho utilizando una combinación lineal mediante un factor de fusión. Por ejemplo, si deseamos que el disco duro tenga menos influencia sobre la decisión, tomamos un parámetro de fusión bajo (0.2), y la fusión de los valores de saturación se calculan de la siguiente manera: o %CPU Predicho = C o %Disco Predicho = D o x = factor de fusión (0 1.0) En nuestro caso 0.2 Elegir la mejor fusión, que representa la fusión con un menor valor de saturación. Actualizar la saturación actual del nodo seleccionado con la predicción de saturación. Esta metodología nos provee de un mecanismo estándar para evaluar el mejor servidor a través de hardware distinto. Sin embargo, el sistema debe conocer el promedio de consumo de cada tipo de petición. Para ello, se establece un mecanismo de aprendizaje que presentaremos a continuación Mecanismo de aprendizaje Este mecanismo se utiliza para calcular el consumo de bogomips y de sectores en un snaptime de un requerimiento. Para ello se sigue el siguiente algoritmo: Se recibe una conexión del cliente Se busca un servidor que pueda atender el requerimiento Se le solicita al servidor que atiende el requerimiento que permanezca bloqueado mientras lo atiende 38

47 El servidor nodo responde el requerimiento y envía al despachador un paquete que indica cuánto se saturó: o Indica cuántos sectores de disco consumió el requerimiento o Se calcula cuánto porcentaje de procesador se consumió (P.c: escala 0-1.0) y cuánto se demoró en consumirlo (T.c). Se divide esto entre Snaptime (St) y se multiplican por los bogomips máximos (B): Esta fórmula da como resultado una escala común de max bogomips/snaptime que puede ser utilizada con distintos tipos de hardware. El despachador registra el evento al recibir la información de consumo de CPU y Disco, y lo promedia con información anterior. Mediante éste mecanismo estandarizamos la medición de consumo en distintas plataformas, lo que nos permite calcular el mejor servidor sin importar que éstos tengan distintas capacidades. El mecanismo de aprendizaje debe ser ejecutado en la etapa de configuración del cluster antes de proveer el servicio al público en ambiente de producción, los cálculos deben ser realizados con todos las posibles páginas web existentes en el cluster. En caso de no ser sometido a un algoritmo de aprendizaje, el cluster no podrá saber con exactitud el peso de los requerimientos, y esto afectará el desempeño del algoritmo de selección de nodo servidor. 39

48 Capitulo 5: Pruebas y análisis de resultados 5.1 Programas de pruebas Se desarrollaron tres aplicaciones distintas para la realización de un entorno experimental de pruebas: localconnectionrewriter: o Modo Despachador: Aplicación escrita en C++ para Linux 2.6, encargada de administrar las conexiones entrantes al cluster y despacharlas a los nodos, además de conocer el estado de los nodos y administrar el protocolo L47H. o Modo Nodo: Aplicación escrita en C++ para Linux 2.6, encargada de administrar las conexiones entre la interfaz virtual y la red, además de administrar el protocolo L47H y recibir las conexiones del despachador. http_meter: Aplicación escrita en C diseñada para realizar cálculos de media y desviación estándar sobre requerimientos destinados a saturar el servidor. Pagina web de pruebas: Escrita en PHP utilizando Apache y PHP5, En el apéndice C puede localconnectionrewriter y http_meter. encontrarse mas información acerca Página web de pruebas Se desarrollaron una serie de páginas de prueba en PHP que simularán distintos requerimientos y cargas solicitados. Cada página tendría propiedades específicas que saturarían cada nodo de forma distinta, a continuación una enumeración de las mismas encontrada en el archivo exp_cost generado por la aplicación en modo aprendizaje: 1:0:GET:/: 0:0:GET:/cebolla.jpg: 211:256:GET:/universe.jpg: 45:0:GET:/factorize.php: 274:576:GET:/sha.php: La página principal casi no tuvo un consumo considerable ni de CPU ni de disco, posiblemente porque fue alojada en memoria RAM por la aplicación de servidor 40

49 web apache. Sin embargo, a nivel de balanceo de carga, muchas instancias de esta página podrían saturar el servidor, lo cual fue previsto por el factor no lineal. El archivo universo.jpg, el cual era una imagen grande tuvo un alto consumo de CPU y Disco. El archivo factorize.php tuvo un consumo mediano de CPU como se esperaba. El archivo sha.php, quien realizaba hashing a un archivo grande, tuvo alto consumo de CPU y Disco, como se esperaba Otros programas utilizados Para el análisis estadístico de las muestras se utilizó el software R 2.7 Como servidor web se utilizó Apache 2 con Connection: Close activado en el encabezado HTTP 5.2. Hardware de pruebas Como vemos en la figura 22, para las pruebas de la implementación se utilizaron 4 computadoras. Tres de ellas pertenecientes al cluster y la cuarta a http_meter, de donde se obtendrían los resultados y estadísticas necesarias. Además se utilizó un HUB de cuatro puertos para unir los computadores del cluster, y un Switch para comunicarlo con el computador de pruebas. Figura 22: Hardware utilizado 41

50 A continuación la distribución del hardware: Nombre Función Yali Despachador Cluster01 Nodo 1 Cluster02 Nodo 2 tester Test http_meter Sistema Operativo Ubuntu 7.10 Ubuntu 7.10 Ubuntu 7.10 FreeBSD 7 Capacidad 550Mhz Pentium 3, 1103 Bogomips, 512Kb Cache, 100Mbps LAN, 128Mb RAM 931Mhz Pentium 3, 1864 Bogomips, 256Kb Cache, 100Mbps LAN, 256Mb RAM 664Mhz Pentium 3, 1330 Bogomips, 256Kb Cache, 100Mbps LAN, 256Mb RAM 800Mhz Pentium 3, 100Mbps LAN, 32Mb ram reales,16mb RAM disponibles Pruebas A continuación se presentan las pruebas realizadas mediante el prototipo. Estas pruebas consisten en comparaciones de métodos de selección de servidor utilizados por distintos algoritmos de despacho. Es importante recalcar que no se está tomando en cuenta la distribución del disco duro como un factor determinante para este caso de estudio de pruebas debido a la complejidad que puede envolver interpretar dos variables combinadas linealmente. Sin embargo los resultados que veremos a continuación son suficientemente determinantes para llegar a una conclusión. Para la realización de las pruebas se utilizó el programa localconnectionrewriter con sus valores predeterminados por defecto, iniciándose primero en modo aprendizaje y más tarde en modo normal, y el programa generador de carga fue http_meter. Los resultados numéricos de las pruebas se encuentran en el CD Anexo al documento Prueba 1 - Requerimientos homogéneos, servidores heterogéneos Conjunto de requerimientos: factorize.php : Script generador de operaciones matemáticas, consumo de CPU: medio (45 Bogomips / 4 seg), consumo de disco: bajo (0 sectores). 42

51 Motivación: Se eligió esta prueba como un proceso sencillo con una carga de CPU medianamente alta que pudiese ser solicitada al servidor. Se emitieron conjuntos de 100 hasta 1500 conexiones en ráfaga para estudiar su comportamiento. Para ello se selecciona la media y el error estándar de cada uno de los conjuntos y se grafican con cada método seleccionado. Mediante requerimientos homogéneos simplificamos la variabilidad de los datos resultantes. Tipos de prueba y resultados: 1. Distribución aleatoria vs Utilización del despachador Figura 23: Imagen de conjunto de conexiones para distintos tipos de distribuciones de carga. Leyenda En azul: Método inteligente utilizado por la aplicación localconnectionrewriter En negro: Método de distribución aleatoria directamente sobre los servidores. 43

52 En la figura 23 se puede distinguir tres bandas por cada color, el primer cuartil es representado por la banda inferior, la media por la banda central, y el tercer cuartil, por la banda superior. Se puede visualizar inmediatamente que el método de distribución propuesto genera una mejora en la media de los tiempos de respuesta de forma consistente. Además podemos destacar que se realizó una mejor distribución de la carga, logrando que los tiempos de respuesta tuviesen menor variabilidad. En otras palabras, los usuarios del cluster web experimentan tiempos de respuesta más homogéneos ayudando a la consistencia del cluster y mejor planificación del mismo. Algunos algoritmos de despacho que utilizan distribución aleatoria son Round Robin DNS, NAT sin conocimiento del estado del cluster y Proxy sin conocimiento del estado del cluster. Concluimos que el método inteligente para el despacho de conexiones con conocimiento y predicción de carga se comporta mejor que los algoritmos de despacho antes mencionado. Otro gráfico útil a la hora de comparar la variabilidad de los tiempos de respuesta son los diagramas de cajas. Figura 24: Diagrama de caja para distribución Figura 25: Diagramas inteligente distribución aleatoria de caja para la 44

53 La figura 24 se puede apreciar el diagrama de cajas para la distribución de carga inteligente implementada, mientras que en la figura 25 se observa el diagrama de cajas para la distribución aleatoria. Como se puede constatar, el diagrama de cajas para la distribución aleatoria muestra una variabilidad de tiempos de respuesta mas grande que el diagrama de cajas para la distribución inteligente, ésto se visualiza a través de la comparación del tamaño de las cajas y de los limites inferiores y superiores. Por ejemplo, si comparamos una ráfaga de 1500 conexiones en ambas distribuciones, el 98 por ciento de la muestra la distribución inteligente no sobrepasará los cuatro segundos, mientras la aleatoria podría llegar hasta nueve segundos. La Figura 26 nos muestra una regresión lineal que aproxima el comportamiento de cada una de las bandas, lo cual nos confirma nuestra afirmación anterior. Es importante destacar que para realizar la distribución aleatoria se utilizó una función aleatoria a nivel del programa que realizaba el test, realizando las conexiones directamente a los nodos, lo cual reducía la saturación del nodo despachador que podría inducir un NAT o un Proxy. Figura 26: Regresión lineal simple para distribución aleatoria versus distribución inteligente 45

54 2. Distribución aleatoria con preferencia por capacidad de nodo servidor vs utilización del despachador con distribución inteligente. Figura 27: Imagen de conjunto de conexiones para distribución de carga aleatoria con peso y distribución inteligente Leyenda En azul: Método inteligente utilizado por la aplicación localconnectionrewriter En negro: Método de distribución aleatoria directamente sobre los servidores. 46

55 El la figura 27, se puede visualizar tres bandas de dos diferentes colores, el primer cuartil es representado por la banda inferior, la media por la banda central, y el tercer cuartil, por la banda superior. Además se puede distinguir que el método propuesto posee medias similares a una distribución de carga aleatoria que toma en cuenta la capacidad de los servidores. Este método envía aleatoriamente conexiones a los servidores en proporción a sus capacidades de CPU. Sin embargo podemos destacar que se realizó una mejor distribución de la carga, logrando que los tiempos de respuesta tuviesen una menor variabilidad. En otras palabras, los usuarios del cluster web experimentan tiempos de respuesta más homogéneos ayudando a la mejor planificación de esscalabilidad del mismo. Algunos algoritmos de despacho que utilizan distribución aleatoria con conocimiento de capacidad de los servidores son NAT con conocimiento de capacidad de los servidores, TCP Handoff con conocimiento de capacidad de los servidores y Proxy con conocimiento de capacidad de los servidores. Figura 28: Diagrama de caja para distribución Figura 29: Diagramas de caja inteligente distribución aleatoria con peso para la 47

56 En la figura 29 se puede visualizar un gráfico de cajas con la distribución aleatoria por peso, y en la figura 28 se visualiza los diagramas de caja para la distribución inteligente. En comparación con la distribución aleatoria, la distribución aleatoria por peso muestra menor variabilidad, sin embargo se puede corroborar que aun presenta mas variabilidad que en la distribución inteligente. Otro gráfico útil para analizar el comportamiento de la varianza es el gráfico de regresión lineal: Figura 30: Regresión lineal para comportamientos de distribución aleatoria por capacidad versis distribución inteligente Basados en el gráfico de regresión lineal de la figura 30, podemos afirmar que la variabilidad de los tiempos de respuesta de las conexiones con un método que conozca la capacidad de los servidores crece más rápidamente que la variabilidad utilizando un método inteligente de despacho. De esta forma se concluye que el método inteligente para el despacho de conexiones con conocimiento y predicción de carga se comporta mejor que los algoritmos de despacho antes mencionado, especialmente para mayores cantidades de conexiones simultáneas. 48

57 Es importante destacar que para realizar la distribución aleatoria se utilizó una función random a nivel del programa que realizaba el test, realizando las conexiones directamente a los nodos, lo cual mejora los tiempos con respecto a un NAT o un Proxy. Para simular el conocimiento de la capacidad de los servidores se distribuye proporcionalmente de acuerdo a los bogomips de cada servidor Prueba 2 - Requerimientos heterogéneos, servidores heterogéneos Conjunto de requerimientos: /factorize.php : CPU Medio / Disco Bajo /icons/blank.gif : CPU Bajo / Disco Bajo /icons/folder.gif : CPU Bajo / Disco Bajo / : CPU Bajo / Disco Bajo /cebolla.jpg : CPU Bajo / Disco Bajo /universo.jpg : CPU Medio / Disco Alto /sha.php : CPU Alto / Disco Alto Motivación: Se eligió esta prueba como un proceso dinámico con distintos tipos de carga para CPU, lo cual simularía un entorno real. Se emiten conjuntos de 100 hasta 1000 conexiones en ráfaga para estudiar su comportamiento. Es importante destacar que esta prueba aumenta drásticamente la variabilidad de los datos ya que cada requerimiento tiene distinto tipo de consumo. 49

58 Tipos de prueba y resultados: 1. Distribución aleatoria vs Utilización del despachador Figura 31: Imagen de conjunto de conexiones para distintos tipos de distribuciones de carga. Leyenda En azul: Método inteligente utilizado por la aplicación localconnectionrewriter En negro: Método de distribución aleatoria directamente sobre los servidores. 50

59 En la figura 31 se puede apreciar dos bandas de dos diferentes colores, la media es representada por la banda inferior y el tercer cuartil, por la banda superior. Se puede visualizar que el método propuesto de distribución genera una leve mejora en la media de los tiempos de respuesta cuando existen menos de 500 conexiones por ráfaga. Luego comienzan a oscilar con similares tiempos de respuesta. Además podemos destacar que se realizó una mejor distribución de la carga cuando el número de conexiones por ráfaga era menor a 800, logrando que los tiempos de respuesta tuviesen menor variabilidad. En otras palabras, los usuarios del cluster web experimentan tiempos de respuesta más homogéneos hasta 800 conexiones por ráfaga (28 conexiones simultaneas), ayudando a la consistencia del cluster y mejor planificación del mismo. Algunos algoritmos de despacho que utilizan distribución aleatoria son Round Robin DNS, NAT sin conocimiento del estado del cluster y Proxy sin conocimiento del estado del cluster. En este caso, concluimos que el método inteligente para el despacho de conexiones con conocimiento y predicción de carga se comporta mejor que los algoritmos de despacho antes mencionado. 51

60 Capitulo 6: Conclusiones y Recomendaciones Hace aproximadamente diez años se comenzó a abrir una nueva frontera hacia nuevos tipos de servicios web dinámicos donde los preceptos convencionales para la distribución de carga como LRU (Last Recent Used) [4], WRR (Weidghted Round Robin) y LARD (Locality Aware Request Distribution) han quedado obsoletos. Otros algoritmos como MC-RR (Multi-Class Round Robin) [9] han intentado solventar el nuevo paradigma combinando información del requerimiento con la carga actual del cluster. Sin embargo, MC-RR no se ajusta a la realidad cuando existe una alta carga en servidores heterogéneos. Esto se debe a que al intentar realizar una predicción basándose en carga actual de cada nodo del cluster, se requieren demasiadas actualizaciones del mismo para un corto período de tiempo. En ese sentido se lograron cuatro mejoras básicas sobre MC-RR. La primera mejora fue lograr hacerlo funcionar de forma óptima en un entorno de servidores heterogéneos, lo cual es un área poco explorada, pero útil a la hora de escalar un cluster. La segunda mejora fue implementar un método de aprendizaje estadístico para las clases, así el servidor puede realizar la predicción de forma más ajustada a la realidad. La tercera mejora fue tomar en cuenta que la saturación de recursos como CPU no es lineal, ello debido a procesos inherentes al servidor web y al sistema, como por ejemplo, Context Switching. Finalmente, la cuarta mejora fue la utilización de clases más granulares. Este mecanismo de selección de servidor fue adaptado al método de despacho Layer 4/7 con TCP Handoff, el cual evita que el despachador de conexiones se convierta en un cuello de botella. Esta solución, a diferencia de la implementada por IPVS [11] y TCPHA [13], fue adaptada de forma no invasiva al Kernel del sistema operativo. Finalmente, se realizó el análisis y las pruebas respectivas, quedando así demostrada la efectividad de dicho método. Esto amplia el panorama existente sobre la distribución de requerimientos dinámicos en servidores web heterogéneos, abriendo una brecha para el estudio de la escalabilidad de clusters utilizando una combinación de hardware heredado con nuevo hardware. 52

61 Recomendaciones: A medida que se iba diseñando, implementando y probando el proyecto surgieron ideas para mejorarlo. Sin embargo por razones de tiempo no fue posible su desarrollo dentro de la tesis. Sin embargo, las enumeraremos a continuación: Despachador distribuido: Cualquier nodo podría actuar de despachador de conexiones en un momento especifico, de esta forma se pretende utilizar recursos en servidores ociosos y no convertir a un solo equipo en un cuello de botella para todas las conexiones. Tolerancia a fallos: utilización de mecanismos para verificar el estado de los nodos y el despachador. De esta forma, en caso de cualquier falla en los nodos servidores, el sistema podría detectarla y evitar desatender alguna solicitud. Ipv4 Fragmentado: No se considera el uso de Ipv4 fragmentado en la implementación actual, sin embargo, es importante considerarlo para versiones futuras. Ipv6: El soporte para Ipv6 no fue considerado en la investigación, sin embargo, podría ser implementado en versiones futuras. Connection-Close: En vez de utilizar Connection-Close desde el servidor web para finalizar la conexión, el nodo podría redirigir la segunda petición a otro nodo con mejor capacidad. En este caso cada nodo a su vez funciona como despachador. 53

62 Glosario de términos ARP: Protocolo de resolución y conversión de direcciones IP a direcciones MAC para redes locales. Balanceo de carga: Mecanismo utilizado para equilibrar la carga del cluster de forma homogénea y uniforme. Big Endian: Formato en el que se representan varios bytes y los valores más significativos quedan a la izquierda. Carga del Cluster: Nivel de utilización de recursos del cluster a través de sus nodos Carga del Requerimiento: Nivel de utilización de recursos necesario por un requerimiento. Cluster: Conjunto de computadoras agrupadas a realizar una tarea en especifico. CPU: Unidad de procesamiento central de un computador, en ella se realizan los cálculos y se ejecutan las instrucciones de un programa. Delay: Tiempo de retraso de un evento. Despachador: Computador encargado de retransmitir paquetes y delegar responsabilidades Dirección MAC / MAC Address: Dirección representada por 6 octetos, generalmente asociada de fabrica a una tarjeta de red DNS: Sistema de resolución de dominios IP Ethernet: Protocolo destinado a la transmisión de datagramas en la red local, generalmente Capa 2. Los computadores de la red local se identifican por su MAC Adress. Gateway / Puerta de enlace: Enrutador a nivel IP que se encarga de manejar los paquetes provenientes de la red los cuales no pertenezcan a la red local. Hardware: Parte física de un computador 54

63 HTTP: Protocolo de comunicaciones basado en TCP utilizado generalmente para servir páginas web, archivos y otros contenidos. HUB: Dispositivo ethernet que replica los paquetes recibidos en todos sus puertos IP: Protocolo de comunicaciones capa 3 encargado de la transmisión de datagramas entre redes Kernel: Nucleo del sistema operativo Little Endian: Formato en el que se representan varios bytes donde se invierte la secuencia de bytes y los valores más significativos quedan a la derecha. Método de aprendizaje: forma que utiliza un sistema para conocer dinámicamente un parámetro. NAT: Network Address Translation, mecanismo utilizado para convertir un IP Interno en uno externo. Nodo Servidor: Computador encargado de responder peticiones. PAT: Port Address Translation. Mecanismo utilizado para convertir un IP externo en varios IP Internos. Proxy: Aplicación intermedia que entiende el protocolo manejado. Red: Agrupación de computadores interconectados Servidor (Hardware): Computador destinado a realizar labores de servicio como atender solicitudes Servidor (Software): Aplicación destinada a atender requerimientos Servidor web: Aplicación o Hardware destinado a atender solicitudes HTTP Servidores Heterogéneos: Servidores con hardware de distintas capacidades Supercomputador: Computadoras de alto desempeño, pueden ser conformadas por varios procesadores integrados en un mismo circuito, o mediante un gran procesador. Switch: Dispositivo ethernet que replica los paquetes recibidos en el puerto asociado a la dirección MAC de destino 55

64 TCP: Protocolo de comunicaciones capa 4 basado en IP utilizado para transmitir secuencias de datos de forma ordenada y con integridad Tiempo de respuesta del requerimiento: Tiempo transcurrido entre el comienzo de la transmisión de la respuesta hasta el final de la transmisión. 56

65 Bibliografía [1] Valeria Cardellini, Emiliano Casalicchio, Michele Colajanni, Marco Mambelli, Enhancing a Web-Server Cluster with Quality of Service Mechanisms, Proceedings of the Performance, Computing, and Communications Conference on 21st IEEE International [2] Valeria Cardellini, Emiliano Casalicchio, Michele Colajanni, Marco Mambelli, Web Switch Support for Differentiated Services, ACM SIGMETRICS Performance Evaluation Review, 2001 [3] Valeria Cardellini, Emiliano Casalicchio, Michele Colajanni, A performance Study of Distributed Architectures for the Quality of Web Services, IEEE Conference, 2001 [4] Bitorika Arkaitz, "Scalability Issues in Cluster Web Servers", Trinity College Dublin. Department of Computer Science, 2002 [5] Daniel A. Menascé, Trade-offs in designing Web Clusters, George Mason University, 2002 [6] Chu-Sing Yang, Mon-Yen Luo, Efficient Support for Content-Based Routing in Web Server Clusters, In Proceedings of the 2nd Usenix Symposium on Internet Technologies and Systems, 1999 [7] Mauro Andreolini, Emiliano Casalicchio, Michele Colajanni, Marco Mambelli, A Cluster-Based Web System Providing Differentiated and Guaranteed Services, Kluwer Academic Publishers, 2004 [8] Emiliano Casalicchio, Michele Colajanni, A Client-Aware Dispatching Algorithm for Web Clusters Providing Multiple Services, ACM, 2001 [9] Emiliano Casalicchio, Michele Colajanni, Scalable Web Clusters with Static and Dynamic Contents, Cluster Computing, Proceedings. IEEE International Conference, 2000 [10] M. Aron, D. Sanders, P. Druschel, and W. Zwaenepoel. Scalable Content-aware Request Distribution in Cluster-based Network Servers. In Proceedings of the USENIX 2000 Annual Technical Conference, San Diego, CA, June [11] Linux Virtual Server Project, Server IP Tunneling,

66 [12] Linux Kernel [13] Wikipedia Clusters [14] TCPHA Software, 58

67 Apéndices Apéndice A: Protocolo experimental ETH_P_IP_FAKE Estructura El protocolo experimental ETH_P_IP_FAKE se envía a través de Ethernet modificando el identificador ETH_P_IP 0x0800 por ETH_P_IP_FAKE 0x0900. A este se le agrega un nuevo LAYER entre Ethernet e IP, el cual contiene 97 bytes el cual describiremos a continuación. Cuando un paquete SYN va a ser retransmitido a un nodo para la inicialización de una conexión, se debe incluir información adicional a la que envió el cliente, como por ejemplo: Modo de aprendizaje (8-bit bool): Valor booleano que de ser activado se debe transmitir al despachador información sobre la saturación de recursos que genera un requerimiento. Ajuste de Número de secuencia (32-bit): El despachador utiliza un número de secuencia aleatorio para responder la petición, para no romper la secuencia TCP, el nodo debe seguir respondiendo con este número de secuencia, el cual se le informa por esta vía. La reconversión de números de secuencia la realiza el re escritor de conexiones del nodo. Nodo destino (32-bit): El despachador debe indicar el nodo destino quien tiene el deber de responder a la petición, cada nodo contiene un identificador de 32-bit, los que no correspondan ignoraran el paquete. Descriptor de conexión (32-bit): En caso de que exista un modo de aprendizaje de valores de saturación (definido en el primer campo de 1 byte), se envía un descriptor de la conexión que guarda el despachador para identificar la conexión cuando reciba un acuse de la saturación. Es importante recalcar que los paquetes SYN de conexión no contienen datos en el común de los casos. Sistemas operativos como FreeBSD, Linux y Windows en todas sus versiones comienzan a enviar datos luego del 3way handshake de TCP, lo que hace que los paquetes SYN por lo general no posean más de 54 a 80 bytes, por lo que nos permite agregarle los 97-bytes sin el peligro de llegar a los 1500 bytes del MTU de Ethernet. 59

68 Apéndice B: Protocolo experimental L47H - Estructura El protocolo L47H es un protocolo centralizado en un despachador de conexiones quien es el que maneja las opciones principales y de mantenimiento del protocolo. Este protocolo experimental corre sobre Ethernet, utilizando el identificador Big Endian (BE1) de Ethernet 0xFF0F y debido a su carácter experimental no es tolerante a fallas de red en su etapa inicial de conexión. El protocolo L47H que viaja sobre frames Ethernet contiene el siguiente encabezado principal: l47h_address (unsigned int 32-bit LE2): Dirección única del nodo, cada nodo y el despachador genera un número aleatorio de 32-bit que debe ser único. Este número sirve como identificador para posteriores operaciones de comunicación. Este número podría repetirse, por lo que se sugiere configurarlo a mano por cada nodo. l47h_type (unsigned char 8-bit): Tipo de comando. A continuación se mostrarán los distintos tipos de comandos relacionados a l47h_type, y la estructura del paquete L47H para cada uno de los comandos. 1 BE: Distribución de bytes Big Endian 2 LE: Distribución de bytes Little Endian 60

69 Estructuras para los distintos anuncios y comandos de L47H: 0x01: Anuncio del Nodo a la red, utilizado para informar sobre la presencia de un nodo, transmite el nombre físico del nodo, así como valores de capacidad del nodo. Header L47H L47h_address (32-bit LE) L47h_type = 0x01 Header L47H_NODE_ANNOUNCEMENT Tipo del siguiente frame = 0x01 ( Valores de capacidad ) Nombre del nodo (32-bytes) Header L47H_NODE_INFORMATION Tipo del siguiente frame (8-bit) = 0x01 Header L47H_NODE_LL_VALUE Tipo de valor (8-bit): Memoria 0x01 CPU 0x02 Disco 0x03 Red 0x04 Valor transmitido (32-bit LE) Hay otro frame LL_VALUE? (8-bit): 0x01: Si 0x02: No... Header L47H_NODE_LL_VALUE Tipo de valor (8-bit): Memoria 0x01 CPU 0x02 Disco 0x03 Red 0x04 Valor transmitido (32-bit LE) Hay otro frame LL_VALUE? (8-bit): 0x01: Si 0x02: No Generalmente el despachador transmite un anuncio a cada nodo que se una a la red. 61

70 0x02: Anuncio del despachador a la red, utilizado para informar sobre la presencia del despachador, transmite la dirección IP del cluster, la máscara de red, la dirección IP del Gateway, así como las direcciones MAC del Gateway y del Cluster. En este caso el parámetro l47h_address donde se especifica la dirección del nodo es considerado el nodo destinatario. Es responsabilidad del nodo interpretar y ajustarse a los parámetros enviados. Header L47H L47h_address (32-bit LE) L47h_type = 0x02 Header L47H_DISPATCHER_ANNOUNCEMENT IP Cluster (in_addr 32- Netmask Cluster (in_addr IP Gateway (in_addr bit LE) 32-bit LE) 32-bit LE) Gateway Mac Address (6-bytes) Cluster Mac Address (6-bytes) 0x03: Transmite la información de niveles de saturación actuales del nodo. Generalmente es transmitido en periodos de tiempo definidos por el usuario. Header L47H L47h_address (32-bit LE) Header L47H_NODE_INFORMATION Tipo del siguiente frame (8-bit) = 0x01 L47h_type = 0x03 Header L47H_NODE_LL_VALUE Tipo de valor (8-bit): Memoria 0x01 CPU 0x02 Disco 0x03 Red 0x04 Valor transmitido (32-bit LE) Hay otro frame LL_VALUE? (8-bit): 0x01: Si 0x02: No. Header L47H_NODE_LL_VALUE Tipo de valor (8-bit): Memoria 0x01 CPU 0x02 Disco 0x03 Red 0x04 Valor transmitido (32-bit LE) Hay otro frame LL_VALUE? (8-bit): 0x01: Si 0x02: No 62

71 0x04: Anuncia la salida de servicio del nodo (No implementado) 0x05: Anuncia la salida de servicio del despachador (No implementado) 0x06: Anuncia colisión de identificadores de nodos (No implementado) Header L47H L47h_address (32-bit LE) L47h_type = 0x06 0x07: Anuncia una petición de réplica de paquetes de una conexión retenida por el despachador Header L47H L47h_address (32-bit LE) L47h_type = 0x07 Header L47H_REPLAY_CONNECTION IP Source (in_addr 32-bit LE) IP Dest (in_addr 32-bit LE) Port Source(Ushort 16-bit LE) Port Dest(Ushort 16-bit LE) 0x08: Anuncia el fin de una conexión y emite al despachador los valores de costos asociados a un requerimiento. En un futuro deberá ser reescrito para soportar otros tipos de consumo como memoria y red. Header L47H L47h_address (32-bit LE) Header L47H_LEARN_VALUES Descriptor de la conexión (32bit LE) Valor de consumo de CPU (32-bit LE) Valor de consumo de HD (32-bit LE) L47h_type = 0x08 0x09: Anuncia que el despachador se ha reconectado y los nodos deben volver a enviar su anuncio. Header L47H L47h_address (32-bit LE) L47h_type = 0x09 63

72 Apéndice C: Aplicaciones El código fuente de las aplicaciones puede conseguirse en el CD anexo a este documento. A continuación un resumen de las decisiones de implementación de la programación. Aplicación localconnectionrewriter Esta aplicación fue desarrollada en el entorno de programación KDEvelop utilizando C++ con la librería pthread para manejo de hilos. Fue diseñada con un enfoque orientado a objetos, e inicialmente se utilizó las librerías STL, pero fueron desechadas por su baja optimización y alto consumo de recursos. El lenguaje C++ fue elegido debido a su alto desempeño y su enfoque orientado a objetos el cual nos permitió escalar el programa de forma sencilla y rápida. Prerrequisitos El software fue diseñado para ser ejecutado bajo Linux 2.6. Adicionalmente, La aplicación debe poseer suficientes privilegios para controlar las interfaces de red, como por ejemplo, inyección de paquetes y escucha en modo promiscuo. Librerías y drivers de terceros utilizados en la implementación Pthread: Realiza varias operaciones multihilo dentro de la aplicación TUN/TAP: Driver para la creación de interfaces virtuales El programa se compone de las siguientes clases: CommonFunctions: Tiene funciones comunes a distintos procesos, como por ejemplo, leer /dev/urandom del sistema para obtener valores realmente aleatorios. 64

73 CommonInterfaceManager: Clase base para PacketInterfaceManager y TunInterfaceManager, define métodos comunes a ambas, como enviar paquete, recibir paquete, y obtener direcciones MAC. PacketInterfaceManager: Clase encargada del manejo de paquetes y las direcciones IP de las interfaces de red reales de las computadoras. Es importante destacar que el envió de paquetes fue realizado mediante RAW Sockets, lo cual nos permitió sobrescribir el encabezado Ethernet. TunInterfaceCreator: Clase encargada de crear una interfaz de red virtual en los nodos mediante el driver TUN de Linux. Además permite el manejo de paquetes en esta interfaz. ConnectionNetstat: Mantiene internamente las tablas de conexiones para el nodo y despachador. En caso del nodo al finalizar una conexión correlaciona los datos con /proc/net/tcp de forma de chequear que la conexión realmente haya terminado y no se esté esperando un paquete. ExpresionCosts: Clase que permite llevar estadísticas persistentes sobre los costos de los requerimientos. InternalStatusMonitor: Clase que provee el monitoreo de saturación de recursos como CPU y Disco. Además es la encargada de realizar los cálculos de capacidad de estos recursos. L47HProtocol: Clase encargada de manejar el protocolo L47H. Tanto en el envió de paquetes L47H como en su recepción y análisis. PacketReadAndWrite: Clase encargada del análisis de los paquetes entrantes en la interfaz de red del despachador. Esta clase se comunica con TCPHandShake para dar respuesta al cliente, mientras envía a través de L47H las directivas a los nodos. PacketReadAndWriteForNode: Clase encargada del análisis de nuevas conexiones, así como de la comunicación entre la interfaz de red virtual y la interfaz de red real. También delega los paquetes L47H a la clase L47HProtocol para su análisis y procesamiento. RawTCPPacketAssembler: Clase ensamblador de paquetes TCP, se encarga también de re-calcular checksum y tamaños de encabezado. 65

74 TCPHandShake: Clase encargada de las respuestas del 3-way Handshake de TCP. RegExpFinder: Clase proveedora de expresiones regulares. ServerList: Mantiene una lista de servidores así como de sus valores de carga. También es la encargada de proveer la simulación sobre un requerimiento preprocesado por ExpresionCosts, evaluando el mejor servidor a atender un requerimiento. El siguiente diagrama de clases nos presenta una distribución de herencia de las mismas: Para lograr persistencia en los costos de las expresiones asociadas a un requerimiento, se creó el archivo de configuración /etc/l47h/exp_cost el cual se compone línea a línea por la siguiente especificación: ConsumoCPU:ConsumoDisco:GET/POST:Path 66

75 Donde Path puede ser una expresión regular, de forma que luego de un modo de aprendizaje, puedan ser definidos a mano conjuntos con consumos de cpu y disco similares. Esta aplicación fue diseñada para poseer un alto nivel de configuración de modo que cada parámetro variable pudiese ajustarse a las especificaciones del cluster y a los requerimientos de los usuarios: Universidad Simón Bolívar - Proyecto de Grado Proxy NODE - Servidor HTTP (Layer 4-7 / TCP HandOff) L47H Autor: Aaron Mizrachi, carnet Modo de uso:./localconnectionrewriter -v Opciones: -v -d -f 90 (90% CPU) -l -q defecto 100) -a -c -s 4s) -i -m Verbose/Debug mode Servir como despachador de conexiones Factor de fusiã³n para CPU (Versus HD), por defecto se usa Modo de aprendizaje Factor de incremento máximo para cambio de proceso (Por Define el identificador (Default: Random) Define el nombre del nodo (Default: NODO-*ID*) Tiempo entre snapshots de monitor de Disco y CPU (default: interface (Default - Ex. -i eth0) Disco principal (Default sda) Ejemplo:./localconnectionrewriter -s 3 Esta aplicación permite configurar: Ser despachador de conexiones o nodo. Al ser despachador: se puede configurar el factor de fusión de la combinación lineal, dándole más peso a la variable que uno elija ser más importante. Al ser despachador: se puede configurar el máximo del factor no lineal F.c que se utiliza para descartar servidores mas saturados. Se puede definir modo aprendizaje Se puede definir el número de 32-bit identificador del nodo. 67

76 Se puede definir el nombre del servidor Se puede definir el tiempo entre snapshots, dependiendo de la cantidad de servidores, si es mayor se deberá aumentar para evitar sobresaturar la red de mensajes de estado de los servidores. Indicar la interfaz. Indicar el disco principal del servidor. Su compilación se limita a./configure con make y make install, ya que kdevelop agrega los scripts de configuración e instalación. Es importante crear el directorio /etc/l47h para el despachador. No es requerido KDE para ejecutar los scripts. Aplicación http_meter La elección de las pruebas fue un argumento interesante a la hora de realizar las mediciones, debido a que la simulación de los requerimientos debería ser de forma fiel a la realidad. En ambientes de producción, se ha determinado que los problemas principales de los cluster web se basan en la llegada de requerimientos en ráfaga en fechas u horarios determinados. Al recibir conexiones en ráfagas, cada tipo de cluster tiene un comportamiento distinto, tanto en media, como en desviación estándar de los valores, y lo ideal, sería reducir tanto la media como la desviación estándar. Por la gran cantidad de conexiones, generalmente, los algoritmos de despacho aumentan la media dependiendo de los niveles de saturación que alcancen. Sin embargo, en presencia de cientos de conexiones, una media alta comparada con una distribución óptima, solo demuestra saturación del despachador y no de los nodos. El verdadero factor de medición sobre la distribución óptima en un cluster con cientos de conexiones lo representa la variabilidad de los tiempos de respuesta y su crecimiento. Para simular estos requerimientos se diseño http_meter, el cual recibe como parámetros: Un archivo con las direcciones URL a ser probadas 68

77 Número de conexiones a ser probada. Incrementos Los números de conexiones a ser probadas se envían en ráfagas de conexiones. Para determinar cuántas conexiones en paralelo tendría una ráfaga de conexión se tomó la raíz cuadrada del número de peticiones de la ráfaga. Por ejemplo, si se requieren 200 conexiones, se inician 14 hilos simultáneos con conexiones iterativas hasta cumplir las 200 conexiones. Si se eligió comenzar en 100 conexiones, con 10 iteraciones, el probará ráfagas de 100 conexiones, de 200, 300, 400, 500, 600, 700, 800, 900 y 1000 conexiones. Se verificó que existe menos de un 0.2% de pérdida de paquetes por colisión en el HUB, lo que causaba un porcentaje mayor de conexiones que debían retransmitir paquetes. Estas conexiones no fueron tomadas en las estadísticas. Los URL serían asignados aleatoriamente en las pruebas. http_meter fue escrito en C utilizando la librería CURL. Fue compilado en el ambiente FreeBSD

78 Apendice D: Layer 4/7 Content Aware Switching - Fundamentos A continuación se realizará un análisis del funcionamiento de la metodología de despacho de conexiones Layer 4/7. Cuando se realiza una petición HTTP, llamada requerimiento, esta ocurre en el primer datagrama que se envía en el protocolo TCP/IP luego de haber establecido la secuencia de conexión de 3 vías SYN/SYN-ACK/ACK, y es el cliente el primero en escribir en el socket ya que HTTP es un protocolo síncrono (Pregunta-Respuesta, Pregunta-Respuesta,...), haciendo que TCP se comporte de forma síncrona a la siguiente secuencia: > REQUERIMIENTO HTTP (GET/POST/HEAD/ETC...) > PARAMETROS DEL REQUERIMIENTO (Agent-User, Content-Length,etc) > POST DATA < RESPUESTA HTTP (Versión, Mensaje, Código de error) < PARAMETROS DE LA RESPUESTA (Server, Content-Length,etc) < RESPONCE DATA En la primera línea, marcada de color verde, se transmite en el primer paquete que se envía luego de los primeros paquetes de negociación de números de secuencia (Syn/Syn-Ack/Ack). Layer 4/7 puede realizar la negociación syn/syn-ack/ack, obtener este primer paquete, y luego pasar a NAT, o a NAT distribuido con TCP Handoff. Las líneas marcadas con color azul representan otros contenidos no relevantes enviados entre el primer paquete y los demás paquetes, y la POST DATA, que son datos más extensos enviados por el cliente, se envía de último para esperar la respuesta del servidor. A continuación veremos una imagen extraída del programa WireShark, que nos ilustrará el hecho de que el requerimiento puede ser analizado con frecuencia en el cuarto paquete. 70

79 Problemas inherentes a Layer 4/7 Content Aware Switching El principal problema en Layer 4/7, es el hecho de que TCP puede fragmentar una secuencia de forma que el requerimiento quede dividido en varios paquetes, sin embargo, los sistemas operativos más comunes, como Windows, Linux, Mac, y BSD, usualmente se implementa el algoritmo Nagle, que intenta llenar los paquetes lo más posible antes de enviarlos para evitar el overhead que representa segmentarlos. 71

Instituto Tecnológico y de Estudios Superiores de Monterrey Práctica de Laboratorio 4 Implementación de un NAPT

Instituto Tecnológico y de Estudios Superiores de Monterrey Práctica de Laboratorio 4 Implementación de un NAPT Instituto Tecnológico y de Estudios Superiores de Monterrey Práctica de Laboratorio 4 Implementación de un NAPT Marco teórico: La red más grande del mundo, Internet, ha tenido un gran crecimiento en la

Más detalles

1) Proxy, Cortafuegos, que son? Pág.2. 2) Funcionamiento de un proxy Pág.3. 3) Proxy NAT / Enmascaramiento Pág.3

1) Proxy, Cortafuegos, que son? Pág.2. 2) Funcionamiento de un proxy Pág.3. 3) Proxy NAT / Enmascaramiento Pág.3 Indice 1) Proxy, Cortafuegos, que son? Pág.2 2) Funcionamiento de un proxy Pág.3 3) Proxy NAT / Enmascaramiento Pág.3 4) Servidores proxy / Servidores de Sockets Pág.4 5) Proxy de web / Proxy cache de

Más detalles

Redes de Computadoras Junio de 2006. Teoría y problemas (75 %)

Redes de Computadoras Junio de 2006. Teoría y problemas (75 %) Redes de Computadoras Junio de 2006 Nombre: DNI: Teoría y problemas (75 %) 1. (1 punto) Suponga una aplicación P2P de compartición de ficheros en la que existe un servidor central que ofrece un servicio

Más detalles

1 of 6. Visualizador del examen - ENetwork Chapter 5 - CCNA Exploration: Network Fundamentals (Versión 4.0)

1 of 6. Visualizador del examen - ENetwork Chapter 5 - CCNA Exploration: Network Fundamentals (Versión 4.0) 1 of 6 Visualizador del examen - ENetwork Chapter 5 - CCNA Exploration: Network Fundamentals (Versión 4.0) 1 Qué información se agrega durante la encapsulación en la Capa 3 de OSI? MAC (Control de acceso

Más detalles

Sistemas de Operación II

Sistemas de Operación II Sistemas de Operación II Procesos en Sistemas Distribuidos Prof. Yudith Cardinale Abril-Julio 2012 Contenido Hilos en Sistemas Distribuidos Clientes Servidores Anexo: Virtualización 2 Procesos e hilos

Más detalles

Protocolo de Internet (IP)

Protocolo de Internet (IP) Semana 12 Empecemos! Estimado y estimada participante, esta semana tendrás la oportunidad de aprender sobre protocolo de Internet (IP), el cual permite enlazar computadoras de diferentes tipos, ser ejecutado

Más detalles

Introducción a redes Ing. Aníbal Coto Cortés

Introducción a redes Ing. Aníbal Coto Cortés Capítulo 5: Ethernet Introducción a redes Ing. Aníbal Coto Cortés 1 Objetivos En este capítulo, aprenderá a: Describir el funcionamiento de las subcapas de Ethernet. Identificar los campos principales

Más detalles

Examen de Redes de Datos Tecnólogo en Telecomunicaciones (ROCHA)

Examen de Redes de Datos Tecnólogo en Telecomunicaciones (ROCHA) Examen de Redes de Datos Tecnólogo en Telecomunicaciones (ROCHA) SOLUCIÓN (más completa que el mínimo requerido para obtener los máximos puntajes) Pregunta 1 En el sistema de nombre de dominio (DNS): a)

Más detalles

Capa de TRANSPORTE. Ing. José Martín Calixto Cely Original: Galo Valencia P.

Capa de TRANSPORTE. Ing. José Martín Calixto Cely Original: Galo Valencia P. Capa de TRANSPORTE Ing. José Martín Calixto Cely Original: Galo Valencia P. Capa de Transporte La Capa 1 crea y transporta las corrientes de bits; La Capa 2 encapsula los paquetes de datos en tramas, y

Más detalles

UNIDAD 1.1 - MODELO OSI/ISO

UNIDAD 1.1 - MODELO OSI/ISO UNIDAD 1.1 - MODELO OSI/ISO El modelo de referencia OSI es el modelo principal para las comunicaciones por red. Aunque existen otros modelos, en la actualidad la mayoría de los fabricantes de redes relacionan

Más detalles

Índice general. Tipos de servicio de transporte. Por qué un nivel de transporte? TEMA 6 Funciones de los niveles superiores. Miguel A.

Índice general. Tipos de servicio de transporte. Por qué un nivel de transporte? TEMA 6 Funciones de los niveles superiores. Miguel A. Arquitectura de Redes, Sistemas y Servicios Curso 2007/2008 TEMA 6 Funciones de los niveles superiores Miguel A. Gómez Hernández ARITT/ITT-IT CURSO 07/08 TEMA 6 (2) Por qué un nivel de transporte? Tipos

Más detalles

Configuración del acceso a Internet en una red

Configuración del acceso a Internet en una red Configuración del acceso a Internet en una red Contenido Descripción general 1 Opciones para conectar una red a Internet 2 Configuración del acceso a Internet utilizando un router 12 Configuración del

Más detalles

LA ARQUITECTURA TCP/IP

LA ARQUITECTURA TCP/IP LA ARQUITECTURA TCP/IP Hemos visto ya como el Modelo de Referencia de Interconexión de Sistemas Abiertos, OSI-RM (Open System Interconection- Reference Model) proporcionó a los fabricantes un conjunto

Más detalles

66.69 Criptografía y Seguridad Informática FIREWALL

66.69 Criptografía y Seguridad Informática FIREWALL 66.69 Criptografía y Seguridad Informática Qué es un Firewall? = Cortafuegos Qué es un Firewall? = Cortafuegos Qué es un Firewall? = Cortafuegos Elemento de hardware o software utilizado en una red de

Más detalles

GUÍAS FÁCILES DE LAS TIC

GUÍAS FÁCILES DE LAS TIC GUÍAS FÁCILES DE LAS TIC del COLEGIO OFICIAL DE INGENIEROS DE TELECOMUNICACIÓN Trabajo Premiado 2006 Autor: Router IP D. José María Jurado García-Posada 17 de Mayo 2006 DIA DE INTERNET Guía fácil Router

Más detalles

REDES DE COMPUTADORES Laboratorio

REDES DE COMPUTADORES Laboratorio 1nsloo.cl REDES DE COMPUTADORES Laboratorio Práctica 1: Emulación de redes con NetGUI. 1. OBJETIVOS. El objetivo de esta práctica es aprender a utilizar la herramienta de emulación de redes Netkit / NetGUI,

Más detalles

Redes conmutadas y de área local

Redes conmutadas y de área local Redes conmutadas y de área local Jorge Juan Chico , Julián Viejo Cortés 2011-14 Departamento de Tecnología Electrónica Universidad de Sevilla Usted es libre de copiar,

Más detalles

Aranda 360 ENDPOINT SECURITY

Aranda 360 ENDPOINT SECURITY Tabla de contenido Product Architecture Product Architecture Introducción Ambiente Redesdetrabajo Configuraciones Políticas Servidores Componentes Agente Servidor Base de datos Consola Comunicación Consola

Más detalles

Bloque IV: El nivel de red. Tema 10: Enrutamiento IP básico

Bloque IV: El nivel de red. Tema 10: Enrutamiento IP básico Bloque IV: El nivel de red Tema 10: Enrutamiento IP básico Índice Bloque IV: El nivel de red Tema 10: Enrutamiento IP básico Introducción Tabla de enrutamiento Algoritmo de enrutamiento Direcciones IP

Más detalles

PROYECTO. Solución Empresarial Ingeniería y Desarrollo de Software www.solucionempresarial.com.ar - info@solucionempresarial.com.

PROYECTO. Solución Empresarial Ingeniería y Desarrollo de Software www.solucionempresarial.com.ar - info@solucionempresarial.com. PROYECTO 1 ÍNDICE 1. Presentación 2. Que es OpenVPN 3. Uso de las VPN s 4. Implementación 5. Seguridad 6. Ventajas 6. Requisitos 7. Objetivos 8. Presupuesto 2 Presentación Es una solución multiplataforma

Más detalles

Introducción a las Redes de Computadoras

Introducción a las Redes de Computadoras Introducción a las Redes de Computadoras Temas: - Repaso del curso Práctico 10 Objetivos: Practicar con ejercicios de examen. Ejercicio 1. (05/02/2003) Una empresa desde donde se realizan muchas consultas

Más detalles

Redes de Computadoras Ethernet conmutada

Redes de Computadoras Ethernet conmutada Redes de Computadoras Ethernet conmutada Ing. Eduardo Interiano Ing. Faustino Montes de Oca Contenido Diversos problemas de las comunicaciones LAN Segmentación de LAN Equipos de comunicaciones LAN Conmutación

Más detalles

Dispositivos de Red Hub Switch

Dispositivos de Red Hub Switch Dispositivos de Red Tarjeta de red Para lograr el enlace entre las computadoras y los medios de transmisión (cables de red o medios físicos para redes alámbricas e infrarrojos o radiofrecuencias para redes

Más detalles

Portafolio de Productos Sirius-NA Appliance de Balanceo de ENLACE

Portafolio de Productos Sirius-NA Appliance de Balanceo de ENLACE Sirius-NA Appliance de Balanceo de ENLACE Diseñamos tecnologías enfocadas a satisfacer las necesidades de su empresa, con costos de implementación reducidos, para proporcionarle mejoras sustanciales a

Más detalles

Metodología de diseño de una LAN

Metodología de diseño de una LAN Metodología de diseño de una LAN Para que una LAN sea efectiva y satisfaga las necesidades de los usuarios, se la debe diseñar e implementar de acuerdo con una serie planificada de pasos sistemáticos.

Más detalles

Análisis de desempeño y modelo de escalabilidad para SGP

Análisis de desempeño y modelo de escalabilidad para SGP Análisis de desempeño y modelo de escalabilidad para SGP Este documento es producto de la experiencia de Analítica en pruebas de stress sobre el software SGP. Estas pruebas se realizaron sobre un proceso

Más detalles

SEGURIDAD INFORMATICA HERRAMIENTAS PARA LA SEGURIDAD EN REDES DE COMPUTADORES

SEGURIDAD INFORMATICA HERRAMIENTAS PARA LA SEGURIDAD EN REDES DE COMPUTADORES SEGURIDAD INFORMATICA HERRAMIENTAS PARA LA SEGURIDAD EN REDES DE COMPUTADORES Defensa equipo a equipo INTERNET Redes Externas Defensa perimetral Cliente Herramientas para la seguridad en Firewall Servicios

Más detalles

Solución del examen de Redes - Segundo parcial - ETSIA - 1 de junio 2007

Solución del examen de Redes - Segundo parcial - ETSIA - 1 de junio 2007 Solución del examen de Redes - Segundo parcial - ETSIA - de junio 2007 Apellidos, Nombre: Grupo de matrícula:. (0,75 puntos) La captura mostrada en la figura siguiente se ha realizado desde un equipo del

Más detalles

Universisdad de Los Andes Facultad de Ingeniería Escuela de Sistemas. Capa de Red. Mérida - Venezuela Prof. Gilberto Díaz

Universisdad de Los Andes Facultad de Ingeniería Escuela de Sistemas. Capa de Red. Mérida - Venezuela Prof. Gilberto Díaz Universisdad de Los Andes Facultad de Ingeniería Escuela de Sistemas Capa de Red Mérida - Venezuela Prof. Gilberto Díaz Capa de Red Gestión de tráfico entre redes Direcciones IP Las direcciones de red

Más detalles

Estos requisitos son específicos para ciertos tipos de redes y más generales en otros tipos de redes.

Estos requisitos son específicos para ciertos tipos de redes y más generales en otros tipos de redes. Objetivos y componentes de diseño LAN 1- Objetivos del diseño LAN El diseño de una red puede ser una tarea fascinante e implica mucho más que simplemente conectar computadores entre sí. Una red requiere

Más detalles

Modelo TCP/IP. Página 1. Modelo TCP/IP

Modelo TCP/IP. Página 1. Modelo TCP/IP Modelo TCP/IP Página 1 Índice: Página 1.-Introducción 3 2.-Arquitectura TCP/IP 3 3.-Protocolo IP 8 4.-Direccionamiento IP 9 5.-Otros Protocolos de la capa de Red. 12 6.-Ejercicios 13 7.-Protocolos de resolución

Más detalles

Capítulo 3. Software para el Monitoreo de Redes

Capítulo 3. Software para el Monitoreo de Redes Capítulo 3 Software para el Monitoreo de Redes No basta saber, se debe también aplicar. No es suficiente querer, se debe también hacer. Johann Wolfgang Goethe Software para el Monitoreo de Redes El estilo

Más detalles

CCNA 1 v3.0 Módulo 9 Suite de Protocolos TCP/IP y Direccionamiento IP Prof: Mg Robert Antonio, Romero Flores

CCNA 1 v3.0 Módulo 9 Suite de Protocolos TCP/IP y Direccionamiento IP Prof: Mg Robert Antonio, Romero Flores CCNA 1 v3.0 Módulo 9 Suite de Protocolos TCP/IP y Direccionamiento IP Prof: Mg Robert Antonio, Romero Flores 1 Objetivos Los estudiantes que completen este módulo deberán poder: Explicar por qué se desarrolló

Más detalles

PC ROUTER. Redes de computadores UTFSM UNIVERSIDAD TÉCNICA FEDERICO SANTA MARÍA DEPARTAMENTO DE ELECTRÓNICA

PC ROUTER. Redes de computadores UTFSM UNIVERSIDAD TÉCNICA FEDERICO SANTA MARÍA DEPARTAMENTO DE ELECTRÓNICA UNIVERSIDAD TÉCNICA FEDERICO SANTA MARÍA DEPARTAMENTO DE ELECTRÓNICA Redes de computadores UTFSM PC ROUTER Fecha 04 de Agosto del 2008 Integrantes Felipe González Valenzuela 2404097-6 Pablo Morales Pimentel

Más detalles

Figura 1: Ciclo de la Administración del desempeño

Figura 1: Ciclo de la Administración del desempeño 1 INTRODUCCIÓN El servicio de acceso a Internet de la Escuela Politécnica Nacional, no cubre las expectativas de los usuarios finales debido a que los tiempos de respuesta, la disponibilidad y la seguridad

Más detalles

Ampliación de Data Centers con Cisco Fabric Path

Ampliación de Data Centers con Cisco Fabric Path Informe técnico Ampliación de Data Centers con Cisco Fabric Path Qué aprenderá Las arquitecturas de redes tradicionales están diseñadas con el fin de ofrecer alta disponibilidad para las aplicaciones estáticas,

Más detalles

DHCP NAT. Redes WAN. DHCP y NAT. Esteban De La Fuente Rubio esteban@delaf.cl L A TEX. Universidad Andrés Bello. 27 abr 2011

DHCP NAT. Redes WAN. DHCP y NAT. Esteban De La Fuente Rubio esteban@delaf.cl L A TEX. Universidad Andrés Bello. 27 abr 2011 y esteban@delaf.cl L A TEX Universidad Andrés Bello 27 abr 2011 Tabla de contenidos 1 BOOTP 2 BOOTP Dynamic Host Configuration Protocol Qué equipos utilizarán? Tarea primordial: asignar dirección IP. BOOTP

Más detalles

Proyecto Infraestructura Virtual

Proyecto Infraestructura Virtual 2011 Proyecto Infraestructura Virtual Integrates: RevolucionUnattended 01/01/2011 CONTENIDO ESCUELA POLITÉCNICA NACIONAL 1. INTRODUCCION 1.1. Propósito 1.2. Ámbito del Sistema 1.2.1 Descripción 1.2.2 Objetivos

Más detalles

Gráficos de tráfico y estadísticas usando MRTG

Gráficos de tráfico y estadísticas usando MRTG Gráficos de tráfico y estadísticas usando MRTG La presentación de gráficos estadísticos para evaluar el uso del ancho de banda a Internet se considera una característica opcional de un router; sin embargo,

Más detalles

Capítulo 11: Capa 3 - Protocolos

Capítulo 11: Capa 3 - Protocolos Capítulo 11: Capa 3 - Protocolos Descripción general 11.1 Dispositivos de Capa 3 11.1.1 Routers 11.1.2 Direcciones de Capa 3 11.1.3 Números de red únicos 11.1.4 Interfaz/puerto del router 11.2 Comunicaciones

Más detalles

FUNDAMENTOS DE REDES CONCEPTOS DE LA CAPA DE RED

FUNDAMENTOS DE REDES CONCEPTOS DE LA CAPA DE RED FUNDAMENTOS DE REDES CONCEPTOS DE LA CAPA DE RED Dolly Gómez Santacruz dolly.gomez@gmail.com CAPA DE RED La capa de red se ocupa de enviar paquetes de un punto a otro, para lo cual utiliza los servicios

Más detalles

Gestión de Redes TCP/IP basada en RMON. Dra. Ing. Caridad Anías Calderón Cujae cacha@tesla.cujae.edu.cu

Gestión de Redes TCP/IP basada en RMON. Dra. Ing. Caridad Anías Calderón Cujae cacha@tesla.cujae.edu.cu Gestión de Redes TCP/IP basada en RMON Dra. Ing. Caridad Anías Calderón Cujae cacha@tesla.cujae.edu.cu Aspectos a tratar Introducción Características de RMON Ventajas del empleo de RMON Versiones de RMON

Más detalles

De Wikipedia, la enciclopedia libre

De Wikipedia, la enciclopedia libre Proxy De Wikipedia, la enciclopedia libre En el contexto de las redes informáticas, el término proxy hace referencia a un programa o dispositivo que realiza una acción en representación de otro. Su finalidad

Más detalles

Redes de Computadoras Junio de 2007. Teoría y problemas

Redes de Computadoras Junio de 2007. Teoría y problemas edes de Computadoras Junio de 2007 Nombre: DNI: Teoría y problemas 1. (2 puntos) Suponga la siguiente red de computadoras: H 1 S 1 H 2 L El nodo emisor H 1 envía al nodo receptor H 2 un mensaje de F bits

Más detalles

Fundamentos de Redes de Computadoras

Fundamentos de Redes de Computadoras Fundamentos de Redes de Computadoras Modulo III: Fundamentos de Redes de Area Extendida (WAN) Objetivos Redes conmutadas Circuito Paquetes Conmutación por paquetes Datagrama Circuito virtual Frame Relay

Más detalles

Práctica de laboratorio 4.5.2: Protocolos de la capa de Transporte TCP/IP, TCP y UDP Diagrama de topología

Práctica de laboratorio 4.5.2: Protocolos de la capa de Transporte TCP/IP, TCP y UDP Diagrama de topología Práctica de laboratorio 4.5.2: Protocolos de la capa de Transporte TCP/IP, TCP y UDP Diagrama de topología Este documento es información pública de Cisco. Página 1 de 10 Tabla de direccionamiento Dispositivo

Más detalles

1.Introducción. 2.Direcciones ip

1.Introducción. 2.Direcciones ip 1.Introducción El papel de la capa IP es averiguar cómo encaminar paquetes o datagramas a su destino final, lo que consigue mediante el protocolo IP. Para hacerlo posible, cada interfaz en la red necesita

Más detalles

Efectos de los dispositivos de Capa 2 sobre el flujo de datos 7.5.1 Segmentación de la LAN Ethernet

Efectos de los dispositivos de Capa 2 sobre el flujo de datos 7.5.1 Segmentación de la LAN Ethernet 7.5 Efectos de los dispositivos de Capa 2 sobre el flujo de datos 7.5.1 Segmentación de la LAN Ethernet 1 2 3 3 4 Hay dos motivos fundamentales para dividir una LAN en segmentos. El primer motivo es aislar

Más detalles

Introducción a redes Ing. Aníbal Coto Cortés

Introducción a redes Ing. Aníbal Coto Cortés Capítulo 7: Capa de transporte Introducción a redes Ing. Aníbal Coto Cortés 1 Capítulo 7 7.1 Protocolos de la capa de transporte 7.2 TCP y UDP 7.3 Resumen 2 Capítulo 7: Objetivos Describa el propósito

Más detalles

Cortafuegos ( Firewall ) Arquitecturas de cortafuegos Juan Nieto González IES A Carballeira -

Cortafuegos ( Firewall ) Arquitecturas de cortafuegos Juan Nieto González IES A Carballeira - Cortafuegos ( Firewall ) Arquitecturas de cortafuegos Juan Nieto González IES A Carballeira - 1 ÍNDICE 1.- Qué es un firewall 2.- Tecnologías de Firewall Filtros de paquetes Puertas de enlace de aplicación

Más detalles

Universidad Autónoma de Manizales Departamento de Ciencias Computacionales

Universidad Autónoma de Manizales Departamento de Ciencias Computacionales Universidad Autónoma de Manizales Departamento de Ciencias Computacionales ASIGNATURA Redes LAN CÓDIGO 10126 NÚMERO DE CRÉDITOS Trabajo Presencial PRERREQUISITOS Trabajo dirigido 80 créditos aprobados

Más detalles

Concentradores de cableado

Concentradores de cableado Concentradores de cableado Un concentrador es un dispositivo que actúa como punto de conexión central entre los nodos que componen una red. Los equipos conectados al propio concentrador son miembros de

Más detalles

McAfee Web Gateway 7.4.0

McAfee Web Gateway 7.4.0 Notas de la versión Revisión A McAfee Web Gateway 7.4.0 Contenido Acerca de esta versión Nuevas funciones y mejoras Problemas resueltos Instrucciones de instalación Problemas conocidos Documentación del

Más detalles

Computación de alta disponibilidad

Computación de alta disponibilidad Computación de alta disponibilidad Universidad Tecnológica Nacional - FRBA Autor: Gustavo Nudelman Necesidad de un sistema HA Causas de downtime. (estudio realizado por IEEE) 10% 5% 13% Hardware 1% 1%

Más detalles

Nivel de Transporte en Internet

Nivel de Transporte en Internet Nivel de Transporte en Internet Nivel de Transporte en TCP/ La capa de transporte transmite mensajes entre las aplicaciones de dos ordenadores. La programación de aplicaciones sobre el nivel de transporte

Más detalles

TEMA 12 DISEÑO SEGURO DE REDES: ALTA DISPONIBILIDAD Y REDUNDANCIA

TEMA 12 DISEÑO SEGURO DE REDES: ALTA DISPONIBILIDAD Y REDUNDANCIA TEMA 12 DISEÑO SEGURO DE REDES: ALTA DISPONIBILIDAD Y REDUNDANCIA INTRODUCCIÓN Cuando se habla de alta disponibilidad se habla de los tres nueves (99,999% del tiempo del año funcionando correctamente),

Más detalles

Guido Caicedo 1, Jorge Crespo 2, Eduardo Damian 2, Verónica Macías 2, Jorge Pérez 2, Jessica Suárez 2, Víctor Viejó 2, Marisol Villacrés 2

Guido Caicedo 1, Jorge Crespo 2, Eduardo Damian 2, Verónica Macías 2, Jorge Pérez 2, Jessica Suárez 2, Víctor Viejó 2, Marisol Villacrés 2 MONITOR DE TRÁFICO IP PARA REDES ETHERNET Guido Caicedo 1, Jorge Crespo 2, Eduardo Damian 2, Verónica Macías 2, Jorge Pérez 2, Jessica Suárez 2, Víctor Viejó 2, Marisol Villacrés 2 RESUMEN La mayoría de

Más detalles

Grupo de Usuarios Linux del Uruguay. http://www.uylug.org.uy - http://www.linux.org.uy Mario Bonilla - miope@linux.org.uy

Grupo de Usuarios Linux del Uruguay. http://www.uylug.org.uy - http://www.linux.org.uy Mario Bonilla - miope@linux.org.uy Grupo de Usuarios Linux del Uruguay UYLUG http://www.uylug.org.uy - http://www.linux.org.uy Mario Bonilla - miope@linux.org.uy 2da. Conferencia Abierta de GNU/Linux Alta Disponibilidad y Balance de Carga

Más detalles

Materia: Telefonía UNEFA 2013 Semestre 11. Prof. Ing. Eduardo Gutierrez. 1

Materia: Telefonía UNEFA 2013 Semestre 11. Prof. Ing. Eduardo Gutierrez. 1 Spanning tree (Spanning Tree Protocol) (SmmTPr o STP) es un protocolo de red de nivel 2 de la capa OSI (nivel de enlace de datos). Está basado en un algoritmo diseñado por Radia Perlman mientras trabajaba

Más detalles

Habiendo hecho esta salvedad, comencemos por definir Qué es IP?

Habiendo hecho esta salvedad, comencemos por definir Qué es IP? APUNTE BÁSICO SOBRE REDES IP Es necesario conocer los conceptos básicos sobre IP ya que es la tecnología y el canal de comunicación esencial que IP-400 utiliza para todas sus interacciones con el mundo

Más detalles

Concepto de Procesamiento Distribuido y Centralizado

Concepto de Procesamiento Distribuido y Centralizado Concepto de Procesamiento Distribuido y Centralizado Procesamiento Centralizado: En la década de los años 50 s las computadoras eran máquinas del tamaño de todo un cuarto con las siguientes características:

Más detalles

Examen Final de Redes - ETSIA - 24 de junio de 2006

Examen Final de Redes - ETSIA - 24 de junio de 2006 Apellidos, Nombre: Grupo de matrícula: Examen Final de Redes - ETSIA - 24 de junio de 2006 1. (0,5 puntos) Calcula el tiempo necesario para recibir la respuesta a una consulta DNS si el servidor de nombres

Más detalles

Internet: TCP/IP Transmisión de datos y redes de ordenadores Internet: TCP/IP La familia de protocolos TCP/IP La capa de red en Internet El protocolo IP Protocolos auxiliares La capa de transporte en Internet

Más detalles

Nombre C.C. Representante Legal EL USUARIO

Nombre C.C. Representante Legal EL USUARIO ESPECIFICACIONES DE CONECTIVIDAD A LOS SISTEMAS TRANSACCIONALES DE DERIVEX Y PARA AFILIADOS QUE UTILIZAN PANTALLAS INFORMATIVAS Nombre C.C. Representante Legal EL USUARIO TABLA DE CONTENIDO INTRODUCCION...

Más detalles

- ENetwork Chapter 9 - CCNA Exploration: Network Fundamentals (Versión 4.0)

- ENetwork Chapter 9 - CCNA Exploration: Network Fundamentals (Versión 4.0) 1 of 5 - ENetwork Chapter 9 - CCNA Exploration: Network Fundamentals (Versión 4.0) 1 Convierta el número binario 10111010 en su equivalente hexadecimal. Seleccione la respuesta correcta de la lista que

Más detalles

Int. Cl.: 74 Agente: Fàbrega Sabaté, Xavier

Int. Cl.: 74 Agente: Fàbrega Sabaté, Xavier 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 38 811 1 Int. Cl.: H04L 29/12 (06.01) H04L 12/26 (06.01) 12 TRADUCCIÓN DE PATENTE EUROPEA T3 96 Número de solicitud europea:

Más detalles

Diseño e Implantación de una WAN Segura para el Transporte y Procesamiento de Datos Estadísticos del Instituto Nacional de Estadística (INE)

Diseño e Implantación de una WAN Segura para el Transporte y Procesamiento de Datos Estadísticos del Instituto Nacional de Estadística (INE) UNIVERSIDAD CENTRAL DE VENEZUELA COMISIÓN DE ESTUDIOS DE POSTGRADO FACULTAD DE INGENIERIA ESCUELA DE INGENIERIA ELECTRICA Diseño e Implantación de una WAN Segura para el Transporte y Procesamiento de Datos

Más detalles

Univ. de Concepción del Uruguay Facultad de Ciencias Agrarias Ingeniería Agrónoma

Univ. de Concepción del Uruguay Facultad de Ciencias Agrarias Ingeniería Agrónoma INFORMÁTICA Univ. de Concepción del Uruguay Facultad de Ciencias Agrarias Ingeniería Agrónoma Informática Teoría Unidad 5 Prof. Ing Ezequiel Benavente Ciclo lectivo 2014 Diferencias entre un Modem y un

Más detalles

Nombre: Francis Ariel Jiménez Zapata. Matricula: 2010-0077. Tema: Trabajando con Windows Server 2008 Módulo 6. Materia: Sistema Operativo II

Nombre: Francis Ariel Jiménez Zapata. Matricula: 2010-0077. Tema: Trabajando con Windows Server 2008 Módulo 6. Materia: Sistema Operativo II Nombre: Francis Ariel Jiménez Zapata Matricula: 2010-0077 Tema: Trabajando con Windows Server 2008 Módulo 6 Materia: Sistema Operativo II Facilitador: José Doñe Introducción En este trabajo estaremos tratando

Más detalles

PRÁCTICAS ÓPTIMAS DE IP SAN

PRÁCTICAS ÓPTIMAS DE IP SAN PRÁCTICAS ÓPTIMAS DE IP SAN Arreglo de almacenamiento PowerVault MD3000i www.dell.com/md3000i TABLA DE CONTENIDO Tabla de contenido INTRODUCTION... 3 OVERVIEW ISCSI... 3 IP SAN DESIGN... 4 BEST PRACTICE

Más detalles

PROYECTO INTEGRADO CLUSTER DE ALTA DISPONIBILIDAD CON HAPROXY Y KEEPALIVED

PROYECTO INTEGRADO CLUSTER DE ALTA DISPONIBILIDAD CON HAPROXY Y KEEPALIVED PROYECTO INTEGRADO CLUSTER DE ALTA DISPONIBILIDAD CON HAPROXY Y KEEPALIVED Obra bajo licencia Creative Commons 1 21 de Diciembre de 2012 Índice de contenido Introducción...3 Topología de red...4 Instalación

Más detalles

Archivo de programa Es el que inicia una aplicación o un programa y tiene una extensión EXE, PIF, COM, BAT. Véase también Programa.

Archivo de programa Es el que inicia una aplicación o un programa y tiene una extensión EXE, PIF, COM, BAT. Véase también Programa. Glosario de términos Ancho de Banda El ancho de banda es la máxima cantidad de datos que pueden pasar por un camino de comunicación en un momento dado, normalmente medido en segundos. Cuanto mayor sea

Más detalles

Seminario Electrónico de Soluciones Tecnológicas sobre Content Networking

Seminario Electrónico de Soluciones Tecnológicas sobre Content Networking Seminario Electrónico de Soluciones Tecnológicas sobre Content Networking 1 de 13 Seminario Electrónico de Soluciones Tecnológicas sobre Content Networking 3 Bienvenida. 4 Objetivos. 5 Soluciones comerciales

Más detalles

Redes (IS20) Ingeniería Técnica en Informática de Sistemas. http://www.icc.uji.es. CAPÍTULO 8: El nivel de transporte en Internet

Redes (IS20) Ingeniería Técnica en Informática de Sistemas. http://www.icc.uji.es. CAPÍTULO 8: El nivel de transporte en Internet Redes (IS20) Ingeniería Técnica en Informática de Sistemas http://www.icc.uji.es CAPÍTULO 8: El nivel de transporte en Internet ÍNDICE 1. Introducción Curso 2002-2003 - Redes (IS20) -Capítulo 8 1 1. Introducción

Más detalles

IFCM0410 Certificación Profesional: Gestión y Supervisión de Alarmas en redes de Telecomunicaciones

IFCM0410 Certificación Profesional: Gestión y Supervisión de Alarmas en redes de Telecomunicaciones IFCM0410 Certificación Profesional: Gestión y Supervisión de Alarmas en redes de Telecomunicaciones UF1854.- Monitorización de Red y Resolución de Incidencias UD1.- Redes de Comunicaciones Generalidades

Más detalles

Tipos de Redes: Topologías de red: Según el tamaño: Según su tecnología de transmisión: Según en tipo de transferencia de datos:

Tipos de Redes: Topologías de red: Según el tamaño: Según su tecnología de transmisión: Según en tipo de transferencia de datos: Tipos de Redes: Según el tamaño: -LAN (red de área local): de 10 metros a 1 kilómetro, suelen usar broatcast y su velocidad va de 10 a 100 MBps. -MAN (red de área metropolitana): tamaño máximo 10 kilómetros.

Más detalles

Proyecto Implementación de un nodo para una red libre (Wi-Fi) Redes de computadores I

Proyecto Implementación de un nodo para una red libre (Wi-Fi) Redes de computadores I Proyecto Implementación de un nodo para una red libre (Wi-Fi) Redes de computadores I Integrantes Patricio Jaque González Jorge Pareja Ayala Profesor Agustín González V. RESUMEN Una red libre con tecnología

Más detalles

Fundamentos de Redes LI. Unidad III Modelos de Comunicaciones 3.1 Modelo de referencia OSI.

Fundamentos de Redes LI. Unidad III Modelos de Comunicaciones 3.1 Modelo de referencia OSI. 3.1 Modelo de referencia OSI. Durante las últimas dos décadas ha habido un enorme crecimiento en la cantidad y tamaño de las redes. Muchas de ellas sin embargo, se desarrollaron utilizando implementaciones

Más detalles

Requerimiento Tecnológico para acceso a Sistemas del SIAF

Requerimiento Tecnológico para acceso a Sistemas del SIAF Requerimiento Tecnológico para acceso a Sistemas del SIAF Lineamientos de infraestructura tecnológica para la operación de Sistemas Financieros Ver. 3.0 Guatemala, Diciembre de 2008 PAG. 1/7 INDICE ANTECEDENTES...3

Más detalles

Gestión de Redes IP. Presentación realizada por: Ing. Pablo Borrelli. Gestión de Redes IP 1

Gestión de Redes IP. Presentación realizada por: Ing. Pablo Borrelli. Gestión de Redes IP 1 Gestión de Redes IP Lugar: Sala de I.T.I. (Instituto Tecnológico de Informática) Presentación realizada por: Ing. Pablo Borrelli Gestión de Redes IP 1 Presentación e introducción. Gestión de la Red de

Más detalles

8 Conjunto de protocolos TCP/IP y direccionamiento IP

8 Conjunto de protocolos TCP/IP y direccionamiento IP 8 Conjunto de protocolos TCP/IP y direccionamiento IP 8.1 Introducción a TCP/IP 8.1.1 Historia de TCP/IP El Departamento de Defensa de EE.UU. (DoD) creó el modelo de referencia TCP/IP porque necesitaba

Más detalles

VPN RED PRIVADA VIRTUAL INTEGRANTES: ALEXANDER BERNAL RAMIREZ CARLOS TRANCA JOSUE FLORES MIGUEL ANGEL VILLANUEVA

VPN RED PRIVADA VIRTUAL INTEGRANTES: ALEXANDER BERNAL RAMIREZ CARLOS TRANCA JOSUE FLORES MIGUEL ANGEL VILLANUEVA VPN RED PRIVADA VIRTUAL INTEGRANTES: ALEXANDER BERNAL RAMIREZ CARLOS TRANCA JOSUE FLORES MIGUEL ANGEL VILLANUEVA CONCEPTO VPN DEFINICIÓN, QUE SE PUEDE HACER CON UN VPN TIPOS DE VPN - ARQUITECTURA VPN ACCESO

Más detalles

Diseño y configuración de redes IP

Diseño y configuración de redes IP Contenido Tema 8 Diseño y configuración de redes IP Protocolos de encaminamiento Características Sistemas autónomos IGP: RIP y OSPF EGP: BGP Segunda parte 1 Ampliación interconexión de redes: Conmutadores

Más detalles

Redes de Computadoras 3 de Diciembre de 2004. Examen de teoría

Redes de Computadoras 3 de Diciembre de 2004. Examen de teoría Redes de Computadoras 3 de Diciembre de 2004 Nombre: DNI: Examen de teoría V F Verdadero/Falso. Con FDM cada circuito consigue todo el ancho de banda periódicamente durante breves instantes de tiempo (es

Más detalles

ARQUITECTURA DE REDES, SISTEMAS Y SERVICIOS

ARQUITECTURA DE REDES, SISTEMAS Y SERVICIOS Universidad Pública de Navarra Nafarroako Unibertsitate Publikoa Departamento de Automática y Computación Automatika eta Konputazio Saila Campus de Arrosadía Arrosadiko Campusa 31006 Pamplona - Iruñea

Más detalles

Capítulo 5. Cliente-Servidor.

Capítulo 5. Cliente-Servidor. Capítulo 5. Cliente-Servidor. 5.1 Introducción En este capítulo hablaremos acerca de la arquitectura Cliente-Servidor, ya que para nuestra aplicación utilizamos ésta arquitectura al convertir en un servidor

Más detalles

Luis Villalta Márquez

Luis Villalta Márquez - Alojamiento virtual basado en IPs. - Alojamiento virtual basado en nombres. - Alojamiento virtual basado en puertos. - Alojamientos híbridos. Luis Villalta Márquez El término Hosting Virtual se refiere

Más detalles

Seminario de Redes TRABAJO PRACTICO Nº 3. UDP y TCP. E-mail: deimos_azul@yahoo.com Padrón: 77902. E-mail: gonzalojosa@hotmail.

Seminario de Redes TRABAJO PRACTICO Nº 3. UDP y TCP. E-mail: deimos_azul@yahoo.com Padrón: 77902. E-mail: gonzalojosa@hotmail. Departamento de Electrónica Facultad de Ingeniería Seminario de Redes TRABAJO PRACTICO Nº 3 UDP y TCP. Grupo: NMNK Responsable a cargo: Integrantes: Guzmán Pegazzano, Ma. Azul E-mail: deimos_azul@yahoo.com

Más detalles

Experimente la red tal como lo hacen sus clientes: Cómo disminuir la brecha de activación

Experimente la red tal como lo hacen sus clientes: Cómo disminuir la brecha de activación Hoja técnica Experimente la red tal como lo hacen sus clientes: Cómo disminuir la brecha de activación Introducción Tradicionalmente, las pruebas de activación de capas 2/3, como RFC 2544, se realizan

Más detalles

Qué es DHCP? Funcionamiento del protocolo DHCP. DHCP 20 de octubre de 2011

Qué es DHCP? Funcionamiento del protocolo DHCP. DHCP 20 de octubre de 2011 Qué es DHCP? DHCP significa Protocolo de configuración de host dinámico. Es un protocolo que permite que un equipo conectado a una red pueda obtener su configuración (principalmente, su configuración de

Más detalles

Protocolos de red. IP: Internet Protocol

Protocolos de red. IP: Internet Protocol Protocolos de red Para comunicarse, bien sea entre personas, bien sea entre máquinas, es necesario establecer una serie de reglas (idioma, decidir quién habla primero, cómo se solicita turno para hablar,

Más detalles

5 Compresión de Cabeceras de Van Jacobson

5 Compresión de Cabeceras de Van Jacobson 5 Compresión de Cabeceras de Van Jacobson 5.1 INTRODUCCIÓN El acceso a servicios de Internet a través de líneas de baja velocidad tanto alámbricas como inalámbricas pone de manifiesto el hecho de la gran

Más detalles

Multi Traffic Routing Grapher (MRTG)

Multi Traffic Routing Grapher (MRTG) UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO DECANATO DE CIENCIAS Y TECNOLOGÍA COORDINACIÓN DE POST-GRADO Maestría en Ciencias de la Computación- Mención Redes de Computadoras Multi Traffic Routing Grapher

Más detalles

WAN y Enrutamiento WAN

WAN y Enrutamiento WAN WAN y Enrutamiento WAN El asunto clave que separa a las tecnologías WAN de las LAN es la capacidad de crecimiento, no tanto la distancia entre computadoras Para crecer, la WAN consta de dispositivos electrónicos

Más detalles

Práctica de laboratorio: Uso de Wireshark para examinar una captura de UDP y DNS

Práctica de laboratorio: Uso de Wireshark para examinar una captura de UDP y DNS Práctica de laboratorio: Uso de Wireshark para examinar una captura de UDP y DNS Topología Objetivos Parte 1: Registrar la información de configuración IP de una PC Parte 2: Utilizar Wireshark para capturar

Más detalles

CCNA 1 - Examen final

CCNA 1 - Examen final CCNA 1 - Examen final 1. Se refieren a la exposición. B acogida a los intentos de establecer una red TCP / IP con el período de sesiones de acogida C. Durante este intento, uno fue capturado en el marco

Más detalles

Laboratorio 4: Asignación de Direcciones IPv4.

Laboratorio 4: Asignación de Direcciones IPv4. Redes de Datos Laboratorio 4 - Instructivo. Laboratorio 4: Asignación de Direcciones IPv4. Instrucciones generales Para poder realizar exitosamente la práctica, deberá cumplir las siguientes etapas: Previo

Más detalles

Redes de Computadoras 7 de Julio de 2004. Examen de teoría

Redes de Computadoras 7 de Julio de 2004. Examen de teoría Redes de Computadoras 7 de Julio de 2004 Nombre: DNI: Examen de teoría V F Verdadero/Falso. Con FDM cada circuito consigue todo el ancho de banda periódicamente durante breves instantes de tiempo (es decir,

Más detalles

Objetivos. Comprender el funcionamiento de Internet y los protocolos que la hacen funcionar

Objetivos. Comprender el funcionamiento de Internet y los protocolos que la hacen funcionar Internet Jorge Juan Chico , Julián Viejo Cortés 2011-14 Departamento de Tecnología Electrónica Universidad de Sevilla Usted es libre de copiar, distribuir y comunicar

Más detalles