Sistemas Distribuidos Basados en la WEB
Anuncio
Sistemas Distribuidos Basados en la WEB Andrew Tanembaum M. L. Liu Buyya Dilleym Maggs, et all “Globally Distributed Content Delivery” Aplicaciones en Internet z z z La aplicación distribuida más conocida es la World Wide Web o la Web Se trata de un sistema distribuido de servidores HTTP y clientes WEB para acceder a documentos vinculados. La web nació gracias a Tim Berners-Lee a finales de 1990 en el CERN, el laboratorio Europeo de Física de partículas de Suiza. Aplicaciones en Internet z z La idea era permitir que un grupo numeroso de investigadores, dispersos geográficamente tuviera acceso a documentos compartidos. Vinculando los documentos entre sí, fue fácil integrarlos desde diferentes proyectos en un nuevo documento sin necesidad de realizar cambios centralizados. 1 Aplicaciones en la Internet z Actualmente, con la introducción de servicios se está viendo el surgimiento de un enorme sistema de distribución donde se están utilizando, componiendo y ofreciendo servicios a cualquier usuario o aplicación que sea capaz de utilizarlos. Arquitectura z z El WWW es una aplicación cliente/servidor basada en el protocolo HTTP (hypertext Transfer Protocol, Protocolo de Transferencia de Hipertexto) Un servidor WEB es un servidor orientado a conexión que implementa HTTP y que por defecto ejecuta en el puerto 80. Arquitectura z z La parte central de un sitio WEB está conformada por un proceso que tiene acceso a un sistema de archivos local que guarda documentos. El modo más simple de referirse a un documento es por medio de una referencia llamada localizador uniforme de recursos (URL). El URL especifica la localización del documento, a menudo incluye: el nombre DNS de su servidor junto con el nombre del archivo, mediante el cual el servidor puede buscar el documento en el sistema de archivos local. 2 Arquitectura z z z Un usuario ejecuta un cliente WWW (normalmente conocido como navegador) en una máquina local. Un navegador es responsable de desplegar adecuadamente los documentos solicitados por el cliente. También acepta entradas del usuario, en su mayor parte para permitirle seleccionar referencias a otros documentos, los cuales el navegador busca y despliega. Client machine Server machine Browser Web server 2. Server fetches document from local file OS 3. Response 1. Get document request (HTTP) Documentos Web - - Todo en la web llega en forma de documento. Un documento no sólo contiene texto simple, sino que puede poseer características dinámicas tales como: audio, video, animaciones, etc. En la mayoría de los casos se requieren de aplicaciones especiales para interpretar todos los componentes de un documento. Un documento tiene dos partes: la parte principal o plantilla y la información en sí. La parte principal se construye en un lenguaje de marcas. 3 HTML z z Hypertext Markup Language o Lenguaje de Marcado de hypertexto, es el lenguaje de etiquetado (tags) utilizado para crear documentos que pueden ser recuperados usando WWW. HTML permite insertar vínculos a otros documentos. Cuando se activan o se seleccionan estos vínculos, el documento requerido será solicitado al servidor. Ejemplo Código de HTML <html> <body> This is a paragraph. This is a paragraph. This is a paragraph <p>This is a paragraph.</p> <p>This is a paragraph.</p> <p>This is a paragraph.</p> </body> </html> Ejemplo Código de HTML <html> <body> z z This text is a link to a page on this Web site. This text is a link to a page on the World Wide Web. <p> <a href="lastpage.htm"> This text</a> is a link to a page on this Web site. </p> <p> <a href="http://www.microsoft.com/"> This text</a> is a link to a page on the World Wide Web. </p> </body> </html> 4 XML (lenguaje de marcado extensible) z z z z Mientras que HTML permite etiquetar un documento para la presentación posterior de la información, el XML permite estructurar su información. Utiliza etiquetas para describir la información o los elementos contenidos en el documento. HTML y XML incluyen toda clase de señalizaciones que se refieren a documentos embebidos (empotrados), es decir, referencias a archivos que deberán incluirse para que el documento esté completo. Un documento embebido puede ser un programa completo. Ejemplo XML <note> <to>Mary</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me this weekend!</body> </note> Ejemplo XML <breakfast_menu> <food> <name>Belgian Waffles</name> <price>$5.95</price> <description> two of our famous Belgian Waffles with plenty of real maple syrup </description> <calories>650</calories> </food> <food> <name>Strawberry Belgian Waffles</name> <price>$7.95</price> <description> light Belgian waffles covered with strawberries and whipped cream </description> <calories>900</calories> </food> </breakfast_menu> 5 MIME z z z Los documentos insertados pueden ser de varios tipos. Cómo se pueden equipar los navegadores para manejar los diferentes tipos de formatos de archivos y las maneras de interpretarlos? Se requieren dos cosas: z z Una forma de especificar el tipo de documento embebido Un modo de permitir que el navegador maneje tipos de datos específicos. MIME z Cada documento insertado lleva un tipo MIME (multipurpose Internet Mail Interchange) asociado. Tipo Subtipo text Plain rich text, html, xml, etc. message E-mail, news application Octect-stream (puede usarse para enviar archivosJava.class) Adobe-postcript, xml, pdf image Jpeg, gif audio Basic, midi, mp3 Vídeo Mpeg, quicktime Documentos WEB z z z El tipo de documento se representa en la forma de una combinación tipo/subtipo, ejem: aplicación/pdf. En algunos casos se espera que se utilicen aplicaciones distintas para procesar los diferentes tipos de documentos. Esta aplicación la proporciona el servidor, puede ser un programa aparte que funcionará del lado del navegador o un plug-in (componente de software adicional) que puede instalarse como parte del navegador. 6 Documentos WEB z Esta variedad cambiante de tipos de documentos obliga a que los navegadores sean extensibles. Con este objeto se ha llevado a cabo cierta estandarización para permitir que los plug-in se inserten fácilmente dentro del navegador. Contenido WEB generado en forma dinámica: Arquitectura de Varios Niveles z z Al principio la web se utilizaba para transmitir contenido estático: un archivo plano, un archivo con una imagen. Según fue evolucionando, las aplicaciones comenzaron a utilizar http con diferentes propósitos: z El navegador puede ejecutar un programa (consultar a una BD) tomando los datos de un usuario como entrada. Contenido WEB generado en forma dinámica z z z Una de las primeras mejoras de la arquitectura básica fue la de soportar la interacción de un usuario por medio de la interfaz de compuerta común (Common Gateway Interface) CGI define la forma estándar mediante la cual un servidor WEB es capaz de ejecutar un programa (script cgi) tomando los datos de un usuario como entrada. En general los datos del usuario provienen de un formulario html; este formulario especifica el programa a ser ejecutado del lado del servidor, junto con los valores de los parámetros. 7 Contenido WEB generado en forma dinámica z Cuando el servidor procesa la solicitud, inicia el programa nombrado en la solicitud y transfiere los valores de los parámetros. El programa realiza su trabajo y, por lo general, regresa los resultados en la forma de un documento que podrá desplegar el navegador donde se encuentra el usuario. script cgi servidor http cliente web petición de hola.html contenido de hola.html petición de hola.cgi datos, del cliente respuesta del servidor incluyendo páginas generadas automáticamente. 2. Start process to fetch document 1. Get request 5. Return result HTTP request handler CGI program 3. Database interaction 4. HTML document created Web server CGI process Database server 8 CGI z z Un script CGI puede estar escrito en cualquier lenguaje de programación, incluyendo los lenguajes interpretados (perl, TKL, Python, JavaScript, Visual Basic Script), al igual que lenguajes compilados (C, C++, Ada) Un script cgi se invoca normalmente desde una página web especial, conocida como formulario. El formulario web z Es un tipo especial de página web que: z z Proporciona una interfaz gráfica que le permite al usuario introducir datos. Cuando el usuario presiona el botón de envío, invoca la ejecución de un programa externo en la máquina del servidor web. Arquitectura: 3 Niveles z z Como el procesamiento del lado del servidor WEB cada vez requiere de más flexibilidad, no es sorprendente que ahora muchos sitios web estén organizados como una arquitectura de 3 niveles: servidor web, un servidor de aplicaciones y una BD. Servidor de aplicaciones: ejecuta toda clase de programas que pueden o no acceder al tercer nivel, que se compone por una BD. 9 Arquitectura: 3 Niveles z Aunque desde el punto de vista arquitectónico tiene sentido distinguir los tres niveles, se pueden presentar problemas de desempeño. El servidor de aplicaciones y la BD son potenciales cuellos de botella. Sesiones web y datos de estado de la sesión z z Durante una sesión de una aplicación web, se emiten diversas peticiones HTTP, cada una de las cuales puede invocar a un programa externo como puede ser un script cgi. Varios de los scripts invocados, pueden necesitar los mismos datos (ejm, el identificador del usuario). Es decir hay datos que necesitan ser compartidos por los scripts a lo largo de la sesión. Sesiones web y datos de estado de la sesión z z Sin embargo, debido a que los scripts web son programas separados ejecutados en contextos independientes, no comparten datos (por otro lado se activan y mueren con la petición) Ni HTTP, ni CGI, tienen soporte para datos de estado de sesión. Ambos protocolos son sin estado y no tienen el concepto de sesión. 10 Sesiones web y datos de estado de la sesión z Debido a la popularidad de las aplicaciones de internet han surgido diversos mecanismos que permiten compartir datos de sesión entre scripts CGI (y otros programas externos). Estos mecanismos se clasifican en: z z Mecanismos del lado del servidor: se pueden usar archivos o bases de datos como repositorios de datos de una sesión. La desventaja de este mecanismo es el overhead que genera y la necesidad de administrar estos archivos donde se guardan los datos que deben persistir entre sesiones. Mecanismos del lado del cliente: campos ocultos del formulario, cookies. Sesiones web y datos de estado de la sesión z Campos ocultos en el formulario: z z En este caso se introducen los datos de estado de sesión en los formularios web generados dinámicamente. Es un campo oculto. Es simple, ya que sólo requiere de la introducción de nuevos campos en el formulario y no se necesitan recursos adicionales ni el cliente ni en el servidor. La simplicidad conlleva el riesgo de privacidad y seguridad, ya que los datos de estado se transmiten como campos ocultos sin proteger. Este esquema no debe utilizarse para transmitir datos sensibles tales como el número de las tarjetas de crédito. Sesiones web y datos de estado de la sesión z Uso de cookies: z z Este esquema hace uso de una extensión del protocolo HTTP básico que permite que una respuesta del servidor pueda contener información de estado que el cliente deberá almacenar en un objeto. Un script puede crear un cookie como parte de la respuesta HTTP. SE incluye la línea de cabecera Set-Cookie. 11 Sesiones web y datos de estado de la sesión z z z Cuando el navegador recibe esta respuesta, crea un objeto, una cookie, que contiene el par nombre-valor especificado para cada elemento de datos de estado, por ejemplo: id=12345. La cookie se almacena en la máquina cliente de forma temporal o de forma persistente. Cuando sea necesario, el cookie (el par nombre-valor) se envía en las peticiones al servidor web. Servlets z z z Son otro tipo de programa Java. Son extensiones del servidor, ejecutados en la máquina del servidor, como una acción desencadenada por la petición del cliente. A diferencia de los scripts CGI, pueden usarse para extender cualquier servidor que tenga un protocolo del tipo peticiónrespuesta. No obstante, se utilizan normalmente con servidores HTTP, en cuyo caso se denominan servlets http. Servlets: Soporte Arquitectónico z z A diferencia de los scripts cgi, que ejecutan en el servidor sin ningún sistema de soporte arquitectónico adicional, la ejecución de los servlets requiere la existencia de un módulo conocido como motor de servlets o contenedor de servlets. Dependiendo de la implementación del servidor, un servlet puede persistir mientras siga teniendo peticiones, o de forma indefinida hasta que se apague el servidor. 12 Servlets: Soporte Arquitectónico z Persistencia: z z z Un script cgi se carga y ejecuta cada vez que un cliente lo solicita, mientras que una sola instancia de un servlet seguirá ejecutando cuando tenga peticiones. Debido a esta característica un servlet puede mantener datos de estado de las sesiones de los clientes durante su tiempo de vida. Existen varias implementaciones que proporcionan la arquitectura de servlets: el JSWDK y el Apache Tomcat. Applets z z Son clases java solicitadas por el navegador a un servidor web, utilizando el protocolo HTTP y ejecutadas a continuación por la máquina virtual java en el entorno del navegador. Un applet se especifica en una página HTML usando la etiqueta APPLET Applets z z z z Cuando el navegador analiza la etiqueta, se lanza una petición al servidor HTTP. GET /applets/HolaMundo.class HTTP/1.1 El servidor localiza el archivo y envía su contenido al cliente en el cuerpo de la respuesta http. Una vez recibido el archivo de la clase del applet, el navegador lo ejecuta en su maquina virtual de Java y muestra su resultado. 13 Petición HTTP Servidor Cliente Respuesta HTTP Applets z Debido a que los applets se descargan de una máquina remota y se ejecutan en la máquina local, su ejecución está sometida a restricciones por razones de seguridad. z z Una de estas restricciones es que el applet no tiene permitido leer o escribir archivos almacenados en el computador en que se está ejecutando. Otra restricción es que no tiene permitido la realización de conexiones de red excepto a la máquina de donde proviene Servicios WEB z z z Se proponen para la construcción de aplicaciones a partir de componentes distribuidos (servicios) independientes del lenguaje y de la plataforma. Un servicio lo proporciona un servidor y es accedido por un cliente. Un servicio web es un servicio tradicional puesto a disposición de todo el mundo en internet. Este servicio web se apega a un conjunto de estándares que le permiten ser descubierto y accedido a través de la red por aplicaciones que también se apegan a dichos estándares. 14 Servicios WEB z Ejemplos de servicios: reporte meteorológico, validación de tarjetas de crédito, generador de números primos, Mapping de una dirección IP a un país, Información sobre el campeonato de fútbol europeo 2008, envío de texto para eliminar lenguaje obsceno, envíos de sms, conversión de temperatura (celcius- farenheit) etc. (www.xmethods.net) Arquitectura de Servicios z z z z z Servicio de Directorio: permite al servicio ser registrado y localizado. Se adhiere al estándar de descripción, descubrimiento e integración universales: UDDI (Universal Description, Discovery and Integration) Capa de descripción de servicios: permiten que un servicio sea descrito en el directorio (WSDL, Web service description language, muy parecido a los lenguajes de definición de interfaz). Capa de mensajería: proporciona mecanismos para la intercomunicación entre procesos, incluyendo la funcionalidad del empaquetamiento de datos (Soap, XML) Capa de transporte: envía los mensajes (TCP, HTTP, SMTP, etc) Capa de red: se encarga de la transmisión física y del encaminamiento de paquetes (IP) Protocolos z Capa de descripción de servicios: z z Permite describir un servicio en el directorio (WSDL, Web service description language). Es un lenguaje formal muy parecido a los lenguajes de definición de interfaz. Una descripción WSDL contiene definiciones precisas de las interfaces provistas por un servicio, es decir procedimientos, tipos de datos, etc. Las descripciones pueden transformarse automáticamente en resguardos del lado del cliente y del lado del servidor. 15 Soap z z z Soap: es un protocolo que al igual que Corba o JAVA RMI incorpora el paradigma de los objetos distribuidos. La diferencia es que también incorpora los protocolos de Internet. Es un protocolo que extiende HTTP para permitir acceso a objetos distribuidos que representan servicios web. Cada mensaje soap se codifica en XML por razones de inter-operabilidad. El mensaje se transporta en una petición o respuesta http Soap Nombre del método, lista de parámetros servidor web Cliente Web objeto de servicio valor devuelto Petición Respuesta Look up a service Client machine Server machine Client application Server application Stub Stub Communication subsystem SOAP Publish service Communication subsystem Generate stub from WSDL description Generate stub from WSDL description Servicedescription description(WSDL) (WSDL) Service Service description (WSDL) Directory service (UDDI) 16 Procesos: Clientes z z La pieza más importante del lado del cliente es el navegador, que permite al usuario navegar a través de páginas web, que provienen del servidor. La navegación se realiza a través de hipervínculos. Idealmente, los navegadores deben ser independientes de la plataforma. Browser engine (motor de navegador) Display back end User interface Rendering engine (motor de proceso de imagen) Network comm. Client-side script interpreter HTML/XML parser Componentes lógicos de un Navegador WEB Componentes de un navegador z z El motor de proceso de imagen contiene todo el código para mostrar apropiadamente los documentos en pantalla. Este proceso de imagen requiere, por lo menos, el análisis sintáctico del XML o del HTML, aunque también puede requerir de la interpretación de un script. El motor del navegador proporciona los mecanismos indispensables para que el usuario final revise el documento, seleccione algunas partes, active los hipervínculos, etc. 17 Componentes de un navegador z z Plug-in: es un pequeño programa que puede ser dinámicamnete cargado en un navegador para manejar un tipo de documento específico. Proxy web: originalmente se utilizaba para permitir que un navegador manejara protocolos, a nivel de aplicación, diferentes de HTTP. Esta funcionalidad ya la poseen los navegadores. No obstante los Proxies siguen usándose para filtrar solicitudes y respuestas, almacenamiento en cache, entre otras funciones. Un proxy web ampliamente utilizado es Squid. Procesos: Servidores z z El servidor WEB más popular es Apache, que se estima es utilizado para alojar aproximadamente el 70% de todos los sitios WEB. Es una pieza compleja de software, altamente configurable y flexible. Servidores WEB basados en Clusters z z Un servidor WEB puede sobrecargarse con facilidad. Solución: replicar el servidor en un cluster de servidores y utilizar un front-end para direccionar las solicitudes de los clientes hacia una de las réplicas. 18 Web server Web server Web server Web server LAN Front end Request Front end handles all incoming requests and outgoing responses Response Servidores WEB basados en Clusters z z El front end se puede convertir en un cuello de botella. Si la conmutación se hace a nivel de capa de transporte , no se puede tomar en cuenta el contenido de la solicitud HTTP enviada a lo largo de la conexión TCP. En este caso se pasan los datos a uno de los servidores de acuerdo con sus características de carga. Servidores WEB basados en Clusters z Distribución consciente del contenido: primero se inspecciona la solicitud HTTP entrante y luego se re-direcciona al servidor más adecuado. Ventajas: z z Si se remiten las solicitudes para el mismo documento al mismo servidor, dicho servidor puede ser capaz de guardar en memoria cache el documento. Los tiempos de respuesta son más rápidos (Y si es muy popular?) Es posible distribuir el conjunto de documentos entre los servidores en lugar de tener que replicar cada documento en cada servidor. 19 Servidores WEB basados en Clusters z z Distribución consciente del contenido. Desventajas: el front end tiene que realizar mucho trabajo. Otras opciones para establecer grupos de servidores web: utilizar un round robin DNS, mediante el cual: z z z z un sólo nombre de dominio se asocia con múltiples direcciones IP. Cuando se resuelve el nombre de un servidor WEB, el navegador recibe una lista de múltiples direcciones, correspondiendo cada dirección a un servidor del grupo. Los navegadores eligen normalmente al primero de la lista. Existen otras alternativas (Cardellini y colaboradores 2002) Comunicación: HTTP z z z Es un protocolo, orientado a conexión, sin estado y de petición–respuesta. Los clientes WEB o navegadores implementan el protocolo, para poder conectarse a los servidores web y obtener documentos HTML. El HTTP está basado en TCP. Siempre que un cliente envía una solicitud a un servidor , primero establece una conexión TCP con el servidor y luego envía su mensaje a través de la conexión. Al utilizar TCP, HTTP no tienen por qué preocuparse por solicitudes y respuestas perdidas. Comunicación: HTTP z z Un servidor HTTP o servidor WEB ejecuta por defecto en el puerto 80. En http/1.0 cada conexión sólo permite una ronda de petición-respuesta: un cliente obtiene una conexión y manda una petición; el servidor procesa la petición, emite una respuesta y cierra la conexión (conexiones no persistentes) 20 HTTP z z Si un cliente necesita contactar al mismo servidor más de una vez en una misma sesión debe reconectarse al servidor por cada nueva petición. Este esquema trabaja bien si sólo se van a recibir documentos simples, no obstante, no es muy eficiente para recibir documentos que contienen un gran número de enlaces a otros documentos. HTTP z z z Como resultado http/1.0 se extendió para permitir la cabecera de petición Connection: Keep-Alive, que es enviada por los clientes que desean una conexión persistente con el servidor; el servidor mantiene la conexión abierta después de enviar la respuesta. En http/1.1 las conexiones son persistentes por defecto. Para mejorar aún más el desempeño, un cliente puede emitir varias solicitudes en fila sin esperar la respuesta de la primera solicitud (canalización o pipelining) HTTP z El protocolo, independientemente de si se mantiene o no la sesión abierta, sigue siendo sin estado. Cada petición se maneja como una nueva. 21 HTTP z Http es un protocolo de petición-respuesta basado en texto, ya que tanto la petición como la respuesta son cadenas de caracteres. Cada petición y respuesta están compuestas, en orden, por las siguientes partes: z z z z La línea de petición/respuesta Una sección de cabecera Una línea en blanco El cuerpo. Ejemplos URI Solicitado Protocolo Método http GET /index.html HTTP/1.1 <línea en blanco> Línea de Petición Métodos: GET: para solicitar el contenido de un documento WEB referenciado por el URI especificado. HEAD: Para solicitar sólo la cabecera del documento, no el documento completo. POST: Usado para enviar datos a un proceso servidor. HTTP La sección de cabecera puede estar compuesta por una o más líneas con el siguiente formato: <clave>: <valor>\r\n Algunas de las claves son: - Accept: especifica los tipos de contenido aceptados por el cliente. - User-Agent: especifica el tipo de navegador. - Connection: Se puede especificar “Keep-Alive” - Host: Nombre del servidor. z 22 Ejemplos HEAD / HTTP/1.1 Accept:*/* Connection: Keep-Alive Host: algunaMaquina.com User-Agent: Generic <linea en blanco> POST /cgi/miServidor.cgi HTTP/1.0 Accept: */* Connection: Keep-Alive Host: algunaMaquina.com User-Agent: Generic Content-type: application/x-www.form-urlencoded Content-length: 11 <linea en blanco> Nombre=jorge&email=jorge@algunaU.edu La especificación del tipo de contenido sigue un esquema establecido en el protocolo conocido como MIME Códigos devueltos por HTTP z En respuesta a un petición del cliente, el servidor HTTP debe enviar una respuesta. La respuesta también se compone de varias partes: z z z z 1. La respuesta o línea de estado 2. Una sección de cabecera 3. Una línea en blanco El cuerpo. Códigos devueltos por HTTP Los códigos de estado son los siguientes: z 100-199 Informativo z 200-299 Petición del cliente satisfactoria z 300-399 Petición del cliente redirigida z 400-499 Petición del Cliente incompleta. z 500-599 Errores en el servidor. Ejemplos: HTTP/1.0 200 OK HTTP/1.1 404 NOT FOUND 23 Asignación de Nombres z z z La web utiliza un solo sistema de asignación de nombres para referirse a documentos. Los nombres utilizados se llaman identificadores de recursos uniformes o URI Los URI se presentan en dos formas: z z Un URL (localizador de recursos uniforme): identifica el documento e incluye información sobre cómo y dónde accederlo (depende de la localización) Un URN (nombre de recursos uniforme): se utiliza como referencia globalmente única a un documento, independiente de la localización y persistente. Asignación de Nombres z La sintaxis de un URL está determinada por: z z z z Su esquema asociado o protocolo. El nombre del esquema es parte de l URI (http, mailto, ftp, telnet, etc). El nombre DNS del servidor que contiene el documento, aunque también es posible utilizar una dirección IP. También se incluye el número de puerto; cuando se deja afuera se usa un puerto pre-establecido. Finalmente, el nombre del documento. Scheme http Host name :// www.cs.vu.nl Pathname /home/steen/mbox (a) Scheme http Host name Port Pathname :// www.cs.vu.nl : 80 /home/steen/mbox (b) Scheme http Host name Port Pathname :// 130.37.24.11 : 80 /home/steen/mbox (c) urn:issn:1535-3613 24 Consistencia y Replicación z La mayoría de los productos de investigación y desarrollo en este sentido se han dirigido hacia el soporte del contenido estático. Almacenamiento en el CACHE z z z En el navegador. Los clientes, en general, pueden indicar en qué momento se verificará la consistencia. En el Proxy web. El proxy puede guardar el resultado de una búsqueda y éste puede ser utilizado por más de un cliente (cache compartido). Caches Jerárquicos: aparte de los caches en los navegadores y/o proxies también es posible colocar caches que cubran una región o país. Las latencias suelen ser más altas comparados con caches no jerárquicos (se verifica en múltiples caches). Los documentos muy populares tienen mayor probabilidad de encontrarse en el cache más cercano al cliente. Almacenamiento en el CACHE z Caches Cooperativos: z z z z Varios proxies trabajan en conjunto. Si hay una falla en un proxy, éste verifica en los proxies vecinos para comprobar si alguno tiene el documento solicitado. Si la verificación falla, se remite la búsqueda al servidor web responsable del documento. Estudios muestran que esta técnica puede ser altamente efectiva para grupos pequeños conectados a través de una LAN. 25 Caches Cooperativos Web server 3. Forward request to Web server 1. Look in local cache Cache Web proxy 2. Ask neighboring proxy caches Client Client Client Web proxy Cache Client Client Client Web proxy HTTP Get request Cache Client Client Client Consistencia z z z Para garantizar que un documento sea consistente, algunos navegadores utilizan la instrucción GET del protocolo HTTP, para preguntar por el tiempo de la última modificación. Si el documento cambió con respecto a la versión del navegador, se trae el documento del servidor, de lo contrario se regresa la versión local. Desventaja: comunicación Navegador-proxy en cada solicitud. Consistencia z El proxy web Squid trabaja con tiempos de expiración. z z z Texpiración Tguardado en cache Túltima_modificación: tiempo de modificación de un documento (registrado pos su propietario) Texpiración = α (Tguardado_ en_ cache − Túltima_ modificación) + Tguardado_ en_ cache α = 0.2 26 Traído al cache Traído al cache modificado modificado Si los documentos que no han sido modificados durante mucho tiempo, el tiempo de expiración será mayor (no serán verificados tan pronto) como aquellos recientemente modificados. La desventaja, es que un proxy puede regresar un documento inválido. El cliente no tiene forma de detectar que se ha recibido un documento obsoleto. Consistencia z z z Protocolos Push: el servidor notifica a los proxies que un documento ha sido modificado enviando una invalidación. Problema: el servidor tiene que llevar información sobre los proxies, lo cual provoca un problema de escalabilidad. Otro problema inherente a los proxies web es que sólo pueden ser utilizados para documentos estáticos. Replicación z z Redes de Entrega de Contenido (Content Delivery Networks). Surgen de la “observación” de que servir o proveer contenido WEB de un sólo servidor puede traer serios problemas de escalabilidad, confiabilidad y desempeño. Especialmente en la presencia de Flash crowds (múltitudes rápida): Cargas que pueden ser hasta un orden de magnitud mayor que las cargas medias. 27 2 days (a) 2 days (b) 6 days (c) 2.5 days (d) Replicación (CDN) z z La sobre-carga de una “multitud rápida” puede dejar temporalmente fuera de servicio a un site, u ocasionar tiempos de respuesta inusualmente altos. Consecuencia: descontentos por parte de los clientes. Enfoques Existentes Para manejar contenido en forma confiable y escalable: 1.) Clusters de Servidores WEB: - Si falla el centro de datos o el ISP que provee la conectividad el cluster entero queda inaccesible. - Es difícil aumentar a miles de servidores. - Se puede ofrecer “mirroring” ...pero requiere de la sincronización entre sitios espejo, que puede ser difícil. 28 Enfoques Existentes 2.) Proxy Caches: permiten reducir la latencia y los anchos de banda requeridos. No obstante, las tasas de acierto tienden a ser bajas (25 a 40%). Una de las principales razones es que se está utilizando mucho contenido dinámico. Redes de Entrega de Contenido z z Solución: Se diseña un sistema con varios “servidores sustitutos” de los servidores “originales”, que están en los bordes de la internet, más cercanos a los clientes. El contenido se replica en estos servidores, reduciendo así la demanda a los servidores “origen” (proveedores de contenido) y proporcionando un tiempo de respuesta más rápido para los usuarios. Redes de Entrega de Contenido z Las redes de este tipo: z z z z Trabajan muy de cerca con los proveedores de contenido a fin de desarrollar funcionalidades que le permitan mejorar el servicio para el web site. Ofrecen caching y control de consistencia. Ensamblaje de contenido dinámico, lo cual permite almacenar en “cache” algunas de sus partes. El CDN de la red controla la red (hw) y el software. 29 Redes de Entrega de Contenido z Ejemplos de CDNs z z z z z z z Akamai (surgió a partir de esfuerzos de de investigadores del MIT para resolver el problema de multitudes rápidas. El sistema actual tiene alrededor de 12000 servidores en alrededor de 1000 redes. ) Edge Stream LimeLight Networks Mirror Image CoDeeN Coral Globule Composición z Existen varias características estructurales, entre ellas: Organización, tipos de servidores, interacciones entre los componentes, contenido, servicio que proveen, etc. 30 Composición: organización z z Overlay: Servidores de aplicaciones y caches colocados en diversos lugares, manejan la distribución del contenido. Los componentes claves de la red, como routers, switches, etc no juegan ningún papel en la distribución de contenido. Network: los componenetes de la red, poseen código para identificar tipos específicos de aplicaciones y re-dirigir requerimientos a los sitios más adecuados basados en políticas pre-definidas o contenido. Composición: Tipos de Servidores z z Origen: El servidor donde reside la versión definitiva del contenido. La actualiza el proveedor de contenidos. Réplica: Maneja copias del contenido y puede responder a los clientes. Pueden ser “media servers” (contenido digital codificado), web servers (streaming media, u otro tipo de contenido almacenado por un web server) , o un cache (almacena copias de contenido en el borde de la red) . También se llaman sustitutos o servidores en los bordes. Composición: Contenido/Tipos de Servicio z z Los proveedores de una CDN manejan, en general, cualquier contenido digital (estático, dinámico, streaming media) y diferentes tipos de servicio: servicio de directorio, comercio electrónico, servicio de transferencia de archivos, etc). Las fuentes del contenido son: grandes empresas, proveedores de servicios WEB, compañías de multi-medios, “news broadcasters”. 31 Composición: Contenido/Tipos de Servicio z z Cierto tipo de contenido y servicios pueden requerir que se adopten características especiales en la arquitectura, tecnologías, etc. Es por ello que algunas CDNs se especializan en cierto tipo de contenido o servicios. Contenido Estático: la frecuencia de cambios es baja (páginas HTML, imágenes embebidas, archivos ejecutables, documentos pdfs, archivos de video o audio). Todos las CDN soportan este tipo de contenido. Puede ser colocado en caches sin mayores problemas y puede actualizarse usando técnicas tradicionales. Composición: Contenido/Tipos de Servicio z Contenido Dinámico: contenido que se personaliza para cada usuario o se crea bajo demanda de algúna aplicación. Cambia frecuentemente dependiendo de los requerimientos de los usuarios (animaciones, scripts, etc). Se considera que no es apropiado colocar este tipo de contenido en el cache (“uncacheable”) Composición: Contenido/Tipos de Servicio z Akamai: Para manejar el contenido dinámico los servidores en los bordes incluyen la technología Edge Sides Technology (www.esi.org) . Esta technología incluye lenguajes, añade aspectos de tolerancia a fallas (por si falla el servidor de origen) e integra el motor XSLT (Extensible StyleSheet Language Transformation) para procesar datos XML. 32 Composición: Contenido/Tipos de Servicio z z A través de ESI el contenido dinámico se puede separar en diversos fragmentos con diferentes características con respecto a si pueden permanecer o no en el cache. Los fragmentos que no pueden permanecer en el cache, se almacenan en el servidor origen. Todos los fragmentos se mantienen en objetos separados y se ensamblan dinámicamente en el servidor de borde como respuesta a los requerimientos de usuarios. Esto reduce la cantidad de datos que se debe recuperar del servidor origen. Composición: Contenido/Tipos de Servicio z Streaming Media: En vivo o bajo demanda. z z Eventos “en vivo”: deportes, conciertos, difusión de noticias, etc. Van instantaneamente del servidor de medios al cliente. Bajo demanda: los archivos son codificados y cargados en el servidor, donde están disponibles a petición de los clientes (video, música, películas). Los servidores de streaming media se “dotan” de protocolos especializados para el manejo de este tipo de contenidos a través de la Internet. Selección de Contenido y entrega z z Una distribución apropiada del contenido puede mejorar los tiempos de respuesta del cliente y la carga del servidor. Enfoques: Full Site: Los servidores réplicas o sustitutos poseen una copia completa del servidor origen. Es una solución sencilla pero puede no ser factible si el tamaño de los objetos es muy grande. Puede ser un problema la “actualización” de dicho contenido. 33 Selección de Contenido y entrega z Parcial: los servidores sustitutos sólo tienen copias de los objetos “embebidos”. La página base en HTML se recupera del servidor de origen y el resto de los objetos se recuperan del servidor sustituto. Cómo se seleccionan los objetos a ser replicados: z z z Empiricamente, siguiendo ciertas heurísticas. Por su popularidad (la popularidad varía mucho en el tiempo, pudiera no tenerse estadísticas de los nuevos objetos). Se agrupa el contenido basado en correlaciones, frecuencias de acceso, etc y se replica por clusters. Actualización de los Caches z z Los objetos en caches tienen asociado un tiempo de expiración. Para manejar la consistencia se manejan diferentes técnicas, entre las que se encuentran: z z z z Actualización periódica, Propagación de actualizaciones Actualización bajo demanda Invalidación 34 Actualización de los CAches z z z Actualización periódica: Los servidores origen están configurados con la siguiente información: qué contenio es apto para ser colocado en el cache, cuán periodicamente se deben hacer las actualizaciones. Los caches se actualizan regularmente. Propagación de actualizaciones: se dispara cuando hay un cambio en el contenido. Si los cambios son frecuentes se genera tráfico excesivo. Bajo demanda: la última copia del documento se propaga al servidor en el borde, como respuesta a una solicitud del dicho contenido Actualización de los Caches z Invalidación: se invía un mensaje de invalidación a todos los sustitutos cuando el contenido cambia en el servidor de origen. Request-Routing z z Es el sistema responsable de redireccionar los requerimientos de los clientes al servidor en el borde más apropiado para la entrega del contenido. La idea es direccionar el requerimiento al mejor servidor en el borde basado en métricas de proximidad, latencia percibida por el cliente, distancia, carga en el servidor sustituto, etc. 35 Request-Routing z z z La técnica de selección de contenido (full o parcial) es determinante para el sistema de enrutamiento de requerimientos. Full: Request routing system direcciona el requerimiento a un servidor sustituto, el cual puede atender el requerimiento completo. Parcial: El servidor origen provee el contenido básico y los servidores sustituto, el resto del contenido. Request-Routing CDN server Cache 6. Get embedded documents (if not already cached) 5. Get embedded documents Return IP address client-best server CDN DNS server 7. Embedded documents 1. Get base document 4 DNS lookups Client 3 Origin server 2. Document with refs to embedded documents Regular DNS system Request-Routing: pasos z z z z z (1) El requerimiento del cliente se dirige al servidor origen. (2) El servidor origen provee el contenido básico (index page con referencia a imágenes embebidas) (3) Hay un URL fantasma, el cual se transforma en el paso 3 en un servidor DNS de la CDN (4) Se redirecciona un cliente al servidor replicado que sea más adecuado para el cliente, de acuerdo a las métricas mencionadas con anterioridad (algoritmo propietario) (5) El cliente envía la solicitud al servidor replicado más adecuado; si éste no tiene alguno de los documentos en el cache, los busca en el servidor original (6). Los nuevos objetos se dejan en el cache 36 Algoritmo para enrutar requerimientos z z Adaptativos: toman en cuenta las condiciones actuales del sistema. La condición actual se obtiene estimando algunas métricas como la carga de los servidores replicados o la congestión de ciertos enlaces. Akamay usa un algoritmo adaptativo que se adapta a los flash crowds. No-adaptativos: usan heurísticas para seleccionar un servidor replicado en lugar de considerar la condición actual del sistema (round-robin, se supone que todos los servidores ´replicados tienen las mismas capacidades y son capaces de proveer el contenido solicitado. ) Algoritmo para enrutar requerimientos z Akamai: entre los aspectos que usa en la selección del servidor más adecuado se encuentran: z z El más cercano: en función de la topología de la red y de las características dinámicas de los enlaces (round-trip time bajo, baja tasa de pérdida de paquetes). Disponible: en función de la carga y del ancho de banda de la red. Un servidor con mucha carga o utilizando casi en su totalidad su ancha de banda no se encuentra disponible para servir al resto de los clientes. Algoritmo para enrutar requerimientos z Akamai: entre los aspectos que usa en la selección del servidor más adecuado se encuentran: z El más probable: Es una función de cuál servidor posee el contenido requerido por el cliente. Si todos los servidores poseen todo el contenido, round robin puede ser una estrategia. 37 Medidas de Desempeño z Son necesarias para evaluar el desempeño de la CDN: qué tan bien se sirve a los clientes el contenido o los servicios solicitados?. Normalmente se utilizan 5 métricas para evaluar el desempeño de una CDN: Tasa de aciertos (caches), ancho de banda reservado, latencia, utilización de los servidores sustitutos, confiabilidad. Métricas de desempeño z z z z z Tasa de aciertos (caches): Una alta tasa de aciertos sugiere que la técnica de almacenamiento y manejo del cache es adecuada. Ancho de banda reservado: Ancho de banda utilizado por el servidor origen (mientras menos, mejor) Latencia: Tiempo de respuesta percibido por el usuario. Una latencia reducida, implica que el servidor origen está utilizando menos ancho de banda. Utilización de los servidores sustitutos: Fracción de tiempo durante la cual los sustitutos permanecen ocupados. Confiabilidad: se mide la tasa de paquetes perdidos para determinar la confiabilidad de la CDN. Métricas de Desempeño Medidas Internas: Los servidores de la CDN se pueden equipar para recoger sus propias estadísticas. Medidas Externas: realizadas por terceras partes, quienes informan a los clientes, sobre el desempeño de la CDN. Se colocan computadores en sitios especializados y miden cómo se desempeña un sitio web ante el requerimiento de un usuario 38 Tolerancia a Fallos z z z En los sitemas distribuidos basados en la WEB, la tolerancia a fallas se logra principalmente por medio de almacenamiento en cache del lado del cliente y replicación de servidores. La alta disponibilidad se logra mediante redundancia (Ejem: CDNs) La tolerancia a fallas es relativamente fácil de implementar considerando que los servidores no almancenan estado y la naturaleza estática del contenido provisto. Conclusiones z z Los sistemas basados en la web han hecho que las aplicaciones lleguen a ser más populares con los usuarios finales. El uso del documento web, como forma de intercambiar información se acerca a la forma en que las personas se comunican en los ambientes de oficina. Aunque los usuarios perciben una arquitectura C/S, los sitios web modernos están organizados a lo largo de arquitecturas de varios niveles, donde un componente final es responsable de generar páginas XML o HTML como respuesta que pueden presentarse al cliente. Conclusiones z z z Servicio: los usuarios finales pueden ser aplicaciones. Proliferan los servicios. Servicios muy diferentes tienen que poder ser descubiertos y colocados a disposición de clientes autorizados. Por consiguiente se han hecho grandes esfuerzos para estandarizar las descripciones de los servicios, las comunicaciones, directorios, etc. Cómo la web opera a través de la internet, se ha prestado mucha atención en la mejora del desempeño (cache , replicación), especialmente ante la presencia de multitudes rápidas (redes de entrega de contenido). Se estudian incluso maneras de hacer un caching parcial del contenido dinámico. La tolerancia a falla se maneja por técnicas estándar que se han aplicado desde hace mucho tiempo en otros sistemas distribuidos. 39
