Miguel Ángel Manso Callejo Dpto. Ingeniería Topográfica y Cartografía/U.P.M.

Transcripción

1 Curso de Doctorado "Aplicaciones Distribuidas Avanzadas" Servicios Web a Gran escala. Redes de Distribución de contenidos Miguel Ángel Manso Callejo Dpto. Ingeniería Topográfica y Cartografía/U.P.M. Ctra Valencia Km Madrid (Spain) Correo-e: m.manso@euitto.upm.es Abstract. This paper presents the main problems that Web Sites have when increasing access. There are many solutions for increasing throughput of servers based on process that response. In other case the solution to problem is load balance in a farm of servers or Data Center. Recently solution is Content Distribution Networks (CDN) that leave the content to client. CDN have some aspects that are described in this paper. The main object of this work is show solutions to massive access in web to some sites. Technology used in design of CDN is used by ISP to optimize network infrastructure, but some problems have partial different solutions. 1 Introducción La red internet se ha convertido en un medio de comunicación estándar entre personas, organizaciones e instituciones. La información que inicialmente se presentaba de forma estática ahora se genera de forma dinámica y personalizada a partir de información que se almacena en bases de datos. Este hecho junto a la potencial demanda agregada de información de los usuarios hace reflexionar a los responsables de las infraestructuras de comunicaciones sobre cual es la forma más óptima de gestionar los recursos. En este documento se presentan distintas técnicas que se han utilizado ya en el pasado para mejorar el rendimiento en los servidores y se describen las técnicas que permiten distribuir la carga entre los servidores que forman una granja. Se analizan los problemas que generan las caches que utilizan tanto los visualizadores de páginas Web como los Proveedores de Acceso a Internet (ISP). Estos problemas también aparecen en las redes de distribución de contenidos (CDN). Se propone una solución para la mejora del protocolo de control de las caches (ICP) basado en el uso de funciones hashs. Se describe la arquitectura de las CDN desde el punto de vista de la propia distribución de los contenidos, el encaminamiento de las peticiones de información, la conmutación y la gestión de los contenidos. Se describe como las organizaciones que disponen de sus propias CDN en entornos geográficos disjuntos, pueden acordar colaborar con otras y como se puede mantener la consistencia de los contenidos. Se finaliza con unas conclusiones y un listado de referencias utilizadas. 2 Rendimiento de un Web. Cuando un portal Web necesita dar respuesta a un número elevado de peticiones se pueden adoptar varias soluciones. La primera puede ser seleccionar la mejor plataforma para el tipo de información que pretendo publicar. En este sentido existen estudios que demuestran que la parte crítica de los servidores es el modelo de concurrencia y se analizan distintas soluciones alternativas. La segunda solución consiste en añadir capacidad de procesamiento usando servidores adicionales. En esta solución el principal condicionante es usar la misma fuente de información para ser ofrecida o adoptar algún mecanismo que permita dividir la información y reconducir las peticiones al servidor apropiado. Profundizando en la primera solución, se pueden distinguir cuatro modelos de concurrencia: Procesos: Los programas que ofrecen el servicio web se ejecutan como procesos. Los procesos son costosos desde el punto de vista del tiempo de respuesta y de cálculo aunque proporcionan ciertas ventajas desde el punto de vista de la programación y de los espacios de direcciones. Es difícil compartir información entre procesos por lo que se necesitan mecanismos de sincronización. La concurrencia se consigue creando procesos. Un ejemplo de servidor Web es Apache, otro NCSA. Hebras: Intentando subsanar las dolencias de los servidores basados en procesos aparecen los basados en hebras. Se obtienen mejores prestaciones por ser menos costoso en tiempo si bien se pierde la ventaja

2 de usar espacios de direcciones independientes. Se mantiene la forma de pensar de los programadote lo que lo hace más atractivo que las dos próximas opciones. Sin embargo necesita que el sistema operativo soporte las hebras para bloquear el acceso a ficheros o al espacio de direcciones. Ejemplos de servidores basados en hebras son JAWS e IIS. Dirigido por eventos: Otro intento de mejorar las prestaciones intenta simular un conmutador de procesos de altas prestaciones. Utiliza operaciones no bloqueantes y realiza todas las operaciones de una forma asíncrona Se obtiene el mayor grado de concurrencia posible por solo existir un proceso, se pueden compartir y comunicar las operaciones de forma natural. Este tipo de servidores pueden dejar al sistema expuesto a un fallo total por malfuncionamiento del servidor. Para poder utilizar una servidor dirigido por eventos es necesario que el sistema operativo proporcione mecanismos de Entrada/Salida asíncronos. Son ejemplos de servidores dirigidos por eventos: Flash y Zeus. En el núcleo del Sistema Operativo: El último intento por mejorar las prestaciones de los servidores desde el punto de vista de la concurrencia pasa por incluir el servidor dentro del núcleo del sistema operativo. Esto permite que las respuestas sean ultra rápidas si bien no existen mecanismos de recuperación ante fallos. Si el servidor cae, el sistema también. Algunas aplicaciones de este tipo de técnicas solo incluyen las funciones GET del servidor dentro del núcleo del sistema operativo y dejan en el espacio de trabajo de usuarios las peticiones dinámicas de datos. Ejemplos de este tipo de servidores son: AFPA, Tux y ExoKernel. Todas estas soluciones están principalmente pensadas para páginas estáticas, si bien en un portal existen contenidos dinámicos. Para estos sitios mixtos se sugieren soluciones mixtas como Linux Tux para páginas estáticas y Apache con conexión a bases de datos para las páginas dinámicas. concurrencia que utilice el servidor Web. Así [7] presentan la figura 1 en la que se muestran las prestaciones de los servidores Apache, Flash y Tux. Se puede observar que los servidores Tux y Flash proporcionan similares rendimientos mientras que Apache se queda en el 40-50% de las prestaciones de los otros. La segunda solución basada granjas de servidores permite mejorar el throughput del sistema web. Existen varias aproximaciones de la solución consistentes en: utilizar un sistema de ficheros en red (AFS, DFS), de modo que todos los servidores accedan a la misma información y no se produzcan inconsistencias. La otra solución consiste en dividir la información que proporciona el web y asignar las unidades a un servidor o subgrupo de servidores. En ambos casos hay que hacer un reparto de carga. Antes de describir y analizar las técnicas de reparto de carga se presentan las desventajas de cada una de las técnicas enumeradas. El uso de sistema de ficheros distribuido no proporciona buenos rendimientos cuando el contenido que se sirve y que por tanto se comparte en el SFD cambia con una frecuencia media o alta. Es el caso de los contenidos dinámicos. Repartir el contenido entre los servidores también adolece de este problema al que se le añade la gestión del reparto de la información el plano de la distribución. Las soluciones reales en todo caso suelen ser híbridas. Las técnicas de distribución de carga más utilizadas en las granjas de servidores son: a. Redirección basada en el servicio de nombres DNS: El servicio de nombres permite asociar más de una dirección IP a un nombre. El comportamiento del servicio consiste en contestar con una dirección IP a una petición utilizando un algoritmo de cola circular. Este mecanismo que desde el punto de vista conceptual es consistente no es equitativo por las caches del propio servicio DNS. Si se modifica el TTL de las caches se está introduciendo una sobre carga en la red a nivel de servicio DNS. Se han hecho algunas propuestas de modificación del servicio de DNS para poder ser usado en los repartos de carga. Estas propuestas consideran la localización y la carga de los servidores, la carga de la red y los costes de los medios de comunicación. Figura 1. Existen experiencias en las que se demuestra que el rendimiento del servidor depende del tipo de Figura 2. 2

3 b. Encaminamiento por contenido: El routing por contenido permite que los contenidos residan en distintos servidores y que las peticiones se reconduzcan al servidor apropiado. Se necesita que todo el tráfico atraviese un nodo que se encarga de repartir la carga y que en muchos casos actúa como servidor proxy. Los principales inconveniente de este tipo de sistema es la baja fiabilidad del sistema en conjunto y los posibles problemas de latencia. Figura 3. c. Redirección a nivel 7 (http): Se basa en el análisis de las peticiones a nivel de protocolo http, para reconducir la petición mediante un código 302, como respuesta a la petición sobre una dirección real del contenido solicitado. Esta técnica permite monitorizar la actividad de los distintos servidores y hacer un reparto de carga equilibrado, si bien genera problemas de latencia y es débil desde el punto de vista de la fiabilidad. Figura 4. d. Modificación de contenidos: La técnica de modificación contenidos se basa en que un porcentaje importante de las partes de los contenidos son constantes. Se puede pensar en un portal de noticias en el que se presentan los titulares del día, se presentan las noticias de última hora, etc. Los contenidos con una duración media pueden ser considerados fijos y los demás dinámicos consiguiendo de esta forma que parte de la información esté en forma de marco en disco y el resto se extraiga dinámicamente de la BD. Puede existir un nodo que se encargue de interceptar la petición y modificar los contenidos de forma que una parte se enlace con un servidor, las imágenes con otro y los contenidos dinámicos con un tercero. Se está consiguiendo el objetivo de repartir la carga. Figura 5. e. Conmutación a nivel 4: La conmutación de contenidos a nivel 4 unifica los beneficios del software a L4 y la conmutación Hardware de nivel 2. Se trata de un nodo que reconoce las peticiones interpretando la información de los puertos y las direcciones IP de los nodos origen y destino. Este nodo reconduce la petición al nodo más apropiado en función de: una rotación circular, al que menos redirecciones se le han hecho o al que menos cargado está. En los dos últimos casos se necesita información del estado de los servidores. 3 Consistencia en las caches. La técnica de caches se utiliza en muchas tecnologías. En el entorno Web existe cache en el navegador de usuario, los proveedores de acceso a internet también utilizan caches para mejorar las prestaciones y optimizar el uso de los medios de comunicaciones. El principal problema de esta técnica es garantizar la consistencia de los datos almacenados en la cache con lo datos originales. En los orígenes de la web los contenidos eran principalmente estáticos y los mecanismos de caches eran una buena solución pues no existía problema de consistencia. Actualmente la mayoría de los contenidos son dinámicos y las caches adolecen de los problemas de consistencia. La consistencia se puede clasificar en las siguientes categorías: a. Consistencia dura: Se trata de sistemas que no toleran inconsistencias en los datos y por tanto deben disponer de mecanismos que garanticen que la información está actualizada en las caches en todo momento. Ejemplos de sistemas que requieren consistencia dura son los mirrors y los sistemas que proporcionan información financiera en línea. Para conseguir este tipo de consistencia se pueden utilizar técnicas como pooling en el cliente o invalidación de caches desde servidores. b. Consistencia incremental: Se trata de un mecanismo que garantiza que un elemento de la cache no es más viejo que un intervalo de tiempo δ dado. En términos prácticos y de eficiencia este δ no puede ser menor que el tiempo de retardo de la red para obtener dicho elemento, porque todos las peticiones de elementos serían inconsistentes. Uno de

4 los mecanismos utilizados para garantizar este tipo de consistencia es el pooling periódico. c. Consistencia débil: Se trata de una consistencia no garantizada, pueden existir copias de contenidos en las caches que no sean consistentes con los datos originales. Algunas aplicaciones son tolerantes como la navegación Web, en estos casos no es trascendental que los contenidos sean un poco antiguos ya que el usuario puede tomar el control y solicitar una copia más actualizada. d. Consistencia mutua: Este tipo de consistencia garantiza que un elemento es mutuamente consistente con otros elementos que pertenecen a al mismo conjunto. En términos prácticos un elemento no puede ser más reciente que el resto del grupo. 4 Las redes de distribución de contenidos (CDN). Las redes de distribución de contenidos son despliegues de servidores, proxys y distribuidores de carga que permiten acercar los contenidos de los Webs, afiliados a la misma lo más cerca del usuario final. El principal objetivo es mejorar las prestaciones percibidas por el cliente ante una petición del protocolo http. Desde el punto de vista arquitectónico las CDN están formadas por cuatro elementos como se puede observar en la siguiente figura: e. Cesiones: Se trata de un mecanismo por el que el servidor y el proxy, o cache, acuerdan que dentro de un periodo de duración dada, si los contenidos cambian el servidor notifica mediante un mensaje de invalición a la cache. La eficiencia del mecanismo depende de la duración de la cesión. Las caches en la web se organizan en forma jerárquica para obtener mejores prestaciones. Existe un protocolo basado en una RFC Protocolo de caches para Internet (ICP) que define los mensajes que se usan sobre el protocolo de transporte UDP para propagar las peticiones, a los nodos vecinos, ante fallos de la cache local en forma de multicast. El principal inconveniente de este protocolo es la escalabilidad ya que las comunicaciones y los procesos crecen de forma cuadrática con el número de caches. Otro problema añadido a la sobrecarga es la cantidad de memoria necesaria para mantener la información de las páginas cacheadas en un servidor Proxy. Existen propuestas para solucionar al problema de la escalabilidad del protocolo que se basa en almacenar un resumen de los links que se encuentran en disco, de forma que la información que se almacenen la tabla cache quepa en memoria y sea manejable. El principal inconveniente de este tipo de soluciones es el número de falsos positivos y negativos que se generan al utilizar el resultado de la función resumen en vez del dato original. Los autores [4] proponen utilizar una función de tipo filtro Bloom que resume el link en 2 bytes, generando tan solo un 2% de falsos positivos. Para analizar la escalabilidad del sistema se puede realizar un cálculo aproximativo: si hay 100 servidores proxy, con 8Gbytes de datos que representan un total de 1M de páginas, se necesita por servidor 2Mbytes y para el conjunto 200Mbytes. Esta cantidad de memoria hoy en día no supone ningún obstáculo tecnológico. El principal inconveniente puede ser la longitud de los mensajes de actualización de la cache, si bien se utiliza técnica de multicast. Figura 6. a. La distribución de contenidos: El objetivo de la distribución de los contenidos es seleccionar que contenidos del servidor se llevan a la CDN de forma que se garantize la consistencia de los datos. Para alcanzar estos objetivos se deben de obtener los contenidos del proveedor o gestor de la información, se deben realizar las copias y se deben distribuir entre los servidores de la red. Paralelamente se debe generar la información de encaminamiento para poder acceder a la misma. Figura 7. b. El encaminador de contenidos: Se debe encargar de reconducir las peticiones de páginas hacia el nodo más próximo. Para ello se pueden utilizar técnicas ya descritas anteriormente como son: Basadas en el DNS, basadas en el nivel de transporte o en el nivel de aplicación. 4

5 Las CDNs pueden cubrir entornos geográficos más o menos extensos, aunque en muchos casos se enmarcan dentro de un país, comunidad o unión. Lo ideal e interesante de las redes es que estén presentes en todo el territorio mundial. Para poder dar este tipo de servicios los gestores de las CDN deben llegar a acuerdos para distribuir contenidos de unas redes en otras y viceversa. Este hecho se conoce como acuerdos de contenidos. Cada CDN se gestiona de forma independiente y debe de existir una interfaz que permita realizar las redirecciones y las distribuciones a nivel global. Figura 8. c. Al conmutador de contenidos se le conoce como balance de carga sobre servidor local (LSLB). Se basa en las conmutaciones a los niveles 4, 5 y 7 para reconducir una petición al servidor que le toque el turno (si se utiliza una cola circular), el que menos conexiones tiene, al que menos cargado está, en función de los tiempos de respuesta, etc.. En muchos casos se necesita información de retorno por parte de los servidores para optimizar los algoritmos. La técnica de reenvío de las peticiones puede realizarse basándose en reparto de carga por traslación de direcciones de red (LSNAT), por retorno directo de servidor (DSR) o bien por medio de Tuneles. Figura 9. d. La gestión de los contenidos: Se encarga de monitorizar en tiempo real la actividad de los servidores, procesar los datos de utilización y rendimientos con el objetivo de unificar la disponibilidad, rendimiento y localización de los contenidos en función de unos objetivos predefinidos. Figura 10. Figura Mecanismos de consistencia aplicados a los CDN. Los mecanismos de consistencia pretenden garantizar la consistencia de los datos en los servidores locales dentro de la red de distribución de contenidos. Para garantizar la consistencia existen distintos mecanismos unos de los cuales se sitúan en el plano de los servidores, otros en el de los clientes y los últimos son explícitos. Los mecanismos basados en el servidor consiguen consistencia de tipo fuerte o incremental y se basan en que el propio servidor invalide la copia cacheada. El mecanismo de cesiones adaptativas permite a los servidores definir el tiempo de la cesión de los objetos a las caches para luego propagar las invalidaciones. Este último mecanismo debe buscar un valor de compromiso para no sobrecargar la red con mensajes de invalidaciones. Los mecanismos basados en cliente consisten en que por cada petición el propio cliente debe comprobar si se han producido cambios, hecho que introduce una fuerte sobrecarga en la red. Existen diferentes mecanismos explícitos. Unos se basan en los tiempos de vida (TTL) asociados a cada objeto. El valor asociado a cada objeto puede establecerse de una forma fija o puede ser calculado en función de la popularidad con la que se visita dicho objeto. En el segundo caso, los proxys deben comunicar a los servidores datos de popularidad para permitirles calcular el TTL. La segunda técnica cuyo objetivo es garantizar las consistencias individual y mutua. Para ello se ha de calcular el tiempo de refresco (TTR).

6 Una tercera técnica explícita es el sondeo periódico procedente de los proxys hacia los servidores. En el IETF ha existido un borrador de protocolo que permite invalidar y actualizar las caches para proporcionar consistencia, se trata del Protocolo para la Distribución de Contenidos Web (WCDP). Este borrador no se ha convertido en RFC y por tanto ha dejado de existir. Las ideas fundamentales de dicha propuesta consistían en lo siguiente: Los intermediarios se suscribían explícitamente al sistema de avisos de invalidación o actualizaciones. Los objetos se agrupaban por unidades direccionables y los mensajes también se agrupan en un solo mensaje de grupo con la finalidad de mejorar la escalabilidad. Este protocolo soportaba distintos tipos de consistencias: Fuertes, incrementales y explícitas. Soportaba invalidación atómica para poder mantener la consistencia mutua entre objetos. La consistencia en las redes de distribución de contenidos tiene el inconveniente de que las redes están formadas por millares de proxys y las soluciones tradicionales no escalan correctamente. Una técnica estudiada por [8] permite optimizar la gestión de las caches en las CDNs en base a establecer cesiones y que los servidores proxy estén agrupados en clusters. La técnica de cesiones pura no escala ya que el servidor se debe encargar de conocer por cada proxy que objetos contiene, debe calcular un tiempo de cesión por objeto y proxy, así mismo debe invalidar o actualizar por objeto y proxy. También se utilizan técnicas de consistencia cooperativa con un elemento vecino de la CDN utilizando multicast a nivel 7. Se optimiza ya que permite reducir el tráfico de mensajes entre todos los nodos de la jerarquía. Otro mecanismo sugerido para mejorar la consistencia de las caches es el protocolo para la distribución y la replicación (DRP). Este protocolo proporciona disponibilidad y versiones de los datos que se distribuyen, define un índice con un conjunto de información que describen las versiones, los tamaños, los tipos y la estructura jerárquica de la información. Finalmente diferencia las peticiones GET, para enviar únicamente los ficheros diferentes. 6 Conclusiones Intentando aportar alguna conclusión de cada parte de este trabajo se puede decir que: No existe una solución óptima para el modelo de concurrencia de los servidores de páginas web, si bien para las páginas estáticas la mejor técnica es disponer del servidor dentro del núcleo del Sistema Operativo. Para los contenidos dinámicos la mejor opción es que el servidor web sea un proceso. La mejor técnica para el balance de carga es la conmutación a nivel 4 con información de retorno de los servidores. La primera conclusión que se puede extraer de este trabajo, aunque trivial, es que las redes de distribución de contenidos son las infraestructuras ideales para que los usuarios recuperen los contenidos de Internet. Después de analizar las distintas técnicas de distribución de contenidos se puede concluir que no existe ninguna ideal y en la práctica se deben utilizar híbridos de las soluciones. De los mecanismos de consistencia descritos el que permite escalar es el que utiliza multicast a nivel 7 de forma cooperativa a un CDN vecino. Existen algunos servicios de valor añadido ausentes actualmente en las CDNs como son: la autenticación de usuarios y la protección de contenidos. Referencias [1] Aminiab, L. Modeling Redirection in Geographically Diverse Server Sets. Proceedings of the International WWW Conference, [2] Baker, M. Moon, B. Distributed Cooperative Web Servers. Computer Networks and ISDN Systems, 31(11-16): , [3] Doyle, R. The Trickle-Down Effect: Web Caching and Server Request Distribution. Proc. of the Sixth International Workshop on Web Caching and Content Delivery, Boston, Massachusetts, USA, June 200. [4] Fan L. Cao P. A Scalable Wide-Area Web Cache Sharing Protocol. in Proc. SIGCOMM'98, 1998, páginas [5] Krioukov, D. Global Server Load Balancing. [6] Korea Telecom. CDN Technology. 01/data/ldb.pdf [7] Lyengar, A. Enhancing Web Performance. rs/wcc02.pdf [8] Ninan, A. Maintaining Cache consistency in Content Distribution Networks. Master's thesis, Department of Computer Science, Univ. of Massachusetts, June

7 [9] Tewari, R. Niranjan, T. WCDP: A protocol for web cache consistency. [10] Tung, Y and Che, H. Study for flow caching for Layer-4 Switching. flow-caching-icccn2000.pdf