Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Introducción a varnish cache (@irontec)

2,157 views

Published on

Apuntes para una futura formación sobre "Varnish Cache", ideado para aumentar el rendimiento de las aplicaciones web, también conocido como caché de proxy HTTP inversa.
¿Quieres aprender más? Consúltanos -> info@irontec.com

Published in: Technology
  • Be the first to comment

Introducción a varnish cache (@irontec)

  1. 1. Introducción a la instalación y despliegue de Varnish Cache Varnish Cache
  2. 2. “No tienes que ser mejor que todos los demás. Tienes que ser mejor de lo que nunca pensaste que podrías ser.” Ken Venturi
  3. 3. Índice 1. Algunos datos sobre Irontec 2. ¿Qué es Varnish Cache? 3. Escenarios Típicos para el Despliegue de Varnish Cache 4. Versiones de Varnish Cache 5. Instalación de Varnish Cache 6. Conceptos Teóricos Precios 7. Introducción a la Gestión Interna de Varnish Cache y sus Flujos 8. Obtención de Estadísticas 9. Configuración de Varnish Cache 10. Monitorización de Varnish Cache 11. Configuraciones Específicas para WordPress 12. Conclusiones
  4. 4. algunos datos sobre Irontec 10 años de experiencia en el mundo del Software Libre 30 puestos de trabajo centrados 100% en Software Libre Desarrollo de aplicaciones para Internet, Sistemas y Telefonía IP como ejes corporativos Diversificación en clientes y servicios Empresa fundadora de ESLE
  5. 5. 2. ¿Qué es Varnish Cache?
  6. 6. ¿Qué es Varnish Cache? • Según la página oficial: https://www.varnish-cache.org/ • Acelerador de aplicaciones web. • Se instala delante de cualquier servidor HTTP. Introduce el concepto de servidor de backend. • Caché de proxy HTTP inverso. • Software libre licenciado bajo la licencia FreeBSD.
  7. 7. ¿Qué es Varnish Cache? • “Intercepta” las peticiones que los clientes realizan sobre una aplicación web, utilizando una serie de mecanismos para acelerar la gestión de dichas peticiones.
  8. 8. 3. Escenarios Típicos para el Despliegue de Varnish Cache
  9. 9. Escenarios Típicos para el Despliegue de Varnish Cache ✔ Aplicaciones web que responden lentamente a las peticiones de usuario. ✔ Aplicaciones web disponibles en varios servidores diferentes. ✔ Aplicaciones web con diferentes versiones según el tipo de dispositivo y ✔ Aplicaciones web con gran carga de transacciones. ✔ Aplicaciones web con excesivo tráfico. ✔ …
  10. 10. 4. Versiones de Varnish Cache
  11. 11. Versiones de Varnish Cache • Versión “OS” – Es software libre, ¿acaso podría ser mejor? – ¿Hemos comentado ya que es software libre? – Lo dicho, OpenSource. • Version “Subscription” (http://www.varnish-software.com) – Incluye soporte de Varnish Software – Incluye productos propietarios – Añade soluciones que proporcionan valor añadido a Varnish Cache
  12. 12. Versiones de Varnish Cache
  13. 13. 5. Instalación de Varnish Cache
  14. 14. Instalación de Varnish Cache Usando el gestor de paquetes (Debian) • # curl http://repo.varnish-cache.org/debian/GPG-key.txt| apt-key add - • # echo "deb http://repo.varnish-cache.org/debian/wheezy varnish-3.0” >> /etc/apt/sources.list • # apt-get update • # apt-get install varnish Puede sustituirse wheezywheezy por squeezesqueeze dependiendo de la versión de Debian sobre la que quiera instalarse Varnish. Puede instalarse la versión 2.1 de Varnish sustituyendo varnish-3.0varnish-3.0 por varnish-2.1varnish-2.1
  15. 15. Instalación de Varnish Cache Usando el gestor de paquetes (Debian) • Los ficheros de configuración se ubican en: – /etc/varnish • El fichero con la configuración principal es: – /etc/varnish/default.vcl • Se añade automáticamente la configuración para el inicio del servicio en posteriores reinicios. Los parámetros pueden modificarse editando el fichero: – /etc/default/varnish
  16. 16. Instalación de Varnish Cache Compilando el Código Fuente (Debian) • # wget http://repo.varnish-cache.org/source/varnish-3.0.5.tar.gz • # apt-get install build-essential automake libtool pkg-config libpcre3-dev libncurses-dev xsltproc groff-base libedit-dev1 • # cd varnish-cache • # sh autogen.sh • # sh configure • # make • # make check • # make install Es normal que al ejecutar “make check” de uno o dos errores.
  17. 17. Instalación de Varnish Cache Compilando el Código Fuente (Debian) • Los ficheros de configuración se ubican en: – /usr/local/etc/varnish • El fichero con la configuración principal es: – /usr/local/etc/varnish/default.vcl • No se instala la configuración necesaria para el inicio del servicio. Debe crearse manualmente o realizarse desde el CLI. – Ej: # varnish -f /usr/local/etc/varnish/default.vcl -s malloc,1G -T 127.0.0.1:6081 -a :6081
  18. 18. 6. Conceptos Teóricos Previos
  19. 19. En esta sección... Trataremos los conceptos teóricos básicos necesarios para comprender como funciona Varnish; de donde toma los datos, como se lleva a cabo su configuración, como realiza determinados controles y como mantiene su contenido cacheado “fresco”.
  20. 20. Conceptos Teóricos Previos Servidor de Backend • Servidor HTTP que provee el contenido que Varnish debe acelerar. • Se indica en el fichero de configuración de Varnish mediante su IP y el puerto donde sirve el contenido.
  21. 21. Conceptos Teóricos Previos Servidor de Backend • host – Host que se usará como servidor de backend. Puede ser una IP o un hostname que resuelva sobre una única IP. • port – El puerto del servidor de backend al que se conectará Varnish. El puerto por defecto para el servicio HTTP es el 80. • host_header – Cabecera para añadir al host. • connect_timeout – El timeout para las conexiones. • first_byte_timeout – El timeout para el primer byte. • between_bytes_timeout – El timeout entre bytes. • probe – Pruebas de salud del host. Se detalla más adelante. • max_connections – Número máximo de conexiones que pueden abrirse contra el backend.
  22. 22. Conceptos Teóricos Previos Servidor de Backend • El servicio Varnish y el servicio HTTP que ofrece el contenido a acelerar pueden estar en la misma máquina (1) o en máquinas diferentes (2).
  23. 23. Conceptos Teóricos Previos VCL - (Varnish Configuration Language) • Lenguaje específico para configurar Varnish. • Se traduce en código binario que se ejecuta cuando se reciben peticiones. • Se organiza en subrutinas que se ejecutan en diferentes etapas del proceso. • En algún momento de la subrutina se invoca una acción y la ejecución de la subrutina finaliza. • Si no se invoca una acción y la subrutina llega a su fin se ejecuta una lógica incluida con Varnish. El código VCL correspondiente puede consultarse en el fichero default.vcl
  24. 24. Conceptos Teóricos Previos VCL - (Varnish Configuration Language) https://www.varnish-cache.org/docs/trunk/reference/vcl.html • Operadores • Condicionales • Tipos de datos • Expresiones regulares • Includes • Imports • ...
  25. 25. Conceptos Teóricos Previos • vcl_recv • vcl_pipe • vcl_pass • vcl_hash • vcl_hit • vcl_miss • vcl_fetch • vcl_deliver • vcl_error vcl_recv y vcl_fetch permiten el 99% de las configuraciones que puedan Requerirse. Todas estas subrutinas se explican más adelante en detalle.
  26. 26. Conceptos Teóricos Previos • pass – Hace que la solicitud y las consecuentas respuestas pasen hacia y desde el servidor directamente sin ser cacheadas. • lookup – Indica a Varnish que entregue contenido de la caché. • pipe – Cortocircuita la conexión entre el cliente y el servidor de backend, de manera que Varnish sólo mueve bytes entre uno y otro extremo hasta que la conexión se cierra. • deliver – Remite el objeto cacheado al cliente. • esi – Lleva a cabo el procesamiento ESI sobre el documento recuperado.
  27. 27. Conceptos Teóricos Previos • req – Proviene del cliente. – Cuando Varnish recibe una petición este objeto es creado y poblado. – La mayor parte del trabajo en vcl_recv se hace sobre este objeto. • beresp – Respuesta que proviene del servidor de backend. – Contiene las cabeceras y el objeto proveniente del servidor de backend. – La mayor parte del trabajo en vcl_fetch se hace sobre este objeto. • obj – El objeto cacheado. – Es un objeto parcialmente de sólo lectura (excepto obj.ttl) que reside en memoria.
  28. 28. Conceptos Teóricos Previos Directors • Consiste en un grupo lógico de servidores de backend que proporcionan redundancia. • Su rol principal es que Varnish pueda elegir entre varios backend si alguno falla.
  29. 29. Conceptos Teóricos Previos Directors • Existen diferentes tipos de “Directors”, y cada uno usa diferentes algoritmos para determinar qué backend usar: 1. Random Directors • El tráfico se distribuye entre los backend asignados al director distribuyéndolo entre ellos aleatoriamente según una “semilla”. 2. Round-Robin Director 3. DNS Director 4. Fallback Director
  30. 30. Conceptos Teóricos Previos Directors • Un director puede referenciar los backend o definirlos inline. • Ejemplo:
  31. 31. Conceptos Teóricos Previos Directors – Random DirectorsRandom Directors • Random DirectorRandom Director – Usa un número generado aleatoriamente para determinar el backend. – Opciones Director: ● .retries: Opcional. Veces que intentará el director localizar un backend saludable si el primer intento falla. – Opciones Backends: ● .weight: Indica la cantidad de tráfico que tendrá un backend en relación a otros.
  32. 32. Conceptos Teóricos Previos Directors – Random DirectorsRandom Directors • Client DirectorClient Director – Escoge un backend basado en la “identity” del cliente. Se puede establecer la variable VCL client.identity para identificar al cliente. – Opciones Director: ● .retries: Opcional. Veces que intentará el director localizar un backend saludable si el primer intento falla. – Opciones Backends: ● .weight: Indica la cantidad de tráfico que tendrá un backend en relación a otros.
  33. 33. Conceptos Teóricos Previos Directors – Random DirectorsRandom Directors • Hash DirectorHash Director – Escoge un backend en base al valor hash de la URL. Útil para realizar balanceo de carga. Usa el valor de req.hash. – Opciones Director: ● .retries: Opcional. Veces que intentará el director localizar un backend saludable si el primer intento falla. – Opciones Backends: ● .weight: Indica la cantidad de tráfico que tendrá un backend en relación a otros.
  34. 34. Conceptos Teóricos Previos Directors – Round-Robin DirectorRound-Robin Director • Usa el primer backend para la primera petición,luego el segundo y así hasta el último. Después vuelve al primero y otra vez a empezar. • Si un backend no está sano, Varnish pasa al siguiente. – Opciones Director: ● Ninguna. – Opciones Backends: ● Ninguna.
  35. 35. Conceptos Teóricos Previos Directors – DNS DirectorDNS Director • Puede usar los backends en modo random / round-robin o usando .list. – Opciones Director: ● .list: Determina las lista IPs de los backend que Varnish creará internamente. No soporta IPv6. ● .ttl: Opcional. Duración de la caché de las búsquedas (lookup) DNS. ● .suffix: Opcional. Sufijo que se añadirá a la cabecera del host de entrada proporcionada por el cliente.
  36. 36. Conceptos Teóricos Previos Directors – DNS DirectorDNS Director • Ejemplo: • Se especifican 384 backends, todos usando el puerto 80, con un timeout para la conexión de 0.4ms. • Las opciones de los backend deben especificarse antes de las lista de IPs.
  37. 37. Conceptos Teóricos Previos Directors – Fallback DirectorFallback Director • Coge el primer backend saludable. Los toma en el orden en que se han definido. – Opciones Director: ● Ninguna. • Ejemplo:
  38. 38. Conceptos Teóricos Previos Health Checks – Backend Probes • Pueden establecerse pruebas para determinar si un backend está sano o no. • El estado de un backend puede consultarse usando req.backend.healthy.
  39. 39. Conceptos Teóricos Previos Health Checks – Backend Probes • .url – URL que Varnish solicitará para probar el backend. Por defecto es “/”. • .request – Tiene precedencia sobre .url. Especifica una petición HTTP usando varias cadenas de caracteres. Se inserta rn automáticamente después de cada cadena de caracteres. • .window – Ventana con los últimos X resultados. Se sobrescriben los más antiguos conforme se realizan nuevas pruebas. Por defecto es 8. • .threshold – Determina el número de entradas de .window que deben ser positivas para que el backend sea declarado saludable. Por defecto es 3.
  40. 40. Conceptos Teóricos Previos Health Checks – Backend Probes • .initial – Determina el número de entradas de .window que se consideran positivas cuando Varnish se inicia. Por defecto toma el valor de .threshold. • .expected_response – Respuesta que se espera recibir del backend. Por defecto 200. • .interval – Con qué frecuencia se realizan las pruebas. Por defecto cada 5 segundos. • .timeout – Velocidad con que una prueba da un timeout. Por defecto 2 segundos.
  41. 41. Conceptos Teóricos Previos Health Checks – Backend Probes • Ejemplos:
  42. 42. Conceptos Teóricos Previos ACLs • Las declaraciones de ACL (Access Control List) crean e inicializan una lista de control de acceso basado en nombres que pueden usarse posteriormente para comprobar direcciones de clientes.
  43. 43. Conceptos Teóricos Previos Purging • Una purga es lo que sucede cuando se obtiene un objeto de la caché y se deshecha junto con todas sus variantes. • Se invoca a través de HTTP con el método PURGE.
  44. 44. Conceptos Teóricos Previos
  45. 45. 7. Introducción a la Gestión Interna de Varnish Cache y sus Flujos
  46. 46. En esta sección... Aprenderemos como es el flujo interno de Varnish, como gestiona las peticiones que recibe de los clientes hasta que les entrega el contenido solicitado, pasando por como lo obtiene del servidor de backend, como lo cachea o que hace en caso de error.
  47. 47. Introducción a la Gestión Interna de Varnish Cache y sus Flujos Máquina de Estados
  48. 48. Introducción a la Gestión Interna de Varnish Cache y sus Flujos Máquina de Estados - Modos • recv (vcl_recv) – Se invoca al comienzo de una petición, después de que la petición haya sido recibida y parseada. – Decide si se sirve o no a la petición, cómo se sirve y, dado el caso, desde qué backend. – Termina con una llamada a return() con alguna de las siguientes palabras clave: ● error code [reason] – Devuelve un código de error al cliente y abandona la petición. ● pass – Cambia a modo pass. Transmitiá el control a vcl_pass. ● pipe – Cambia a modo pipe. Transmitirá el control a vcl_pipe. ● lookout – Busca el objeto en la caché. Transmitirá el control a vcl_hit o vcl_miss dependiendo de si el objeto esa en la caché o no.
  49. 49. Introducción a la Gestión Interna de Varnish Cache y sus Flujos Máquina de Estados - Modos • pipe (vcl_pipe) – Se invoca al entrar en modo pipe. – En este modo la solicitud es remitida al servidor de backend y cualquier dato intercambiado entre el cliente y el backend es transmitido sin alterarse hasta que se cierra la conexión. – Termina con una llamada a return() con alguna de las siguientes palabras clave: ● error code [reason] – Devuelve un código de error al cliente y abandona la petición. ● pipe – Procede con el modo pipe.
  50. 50. Introducción a la Gestión Interna de Varnish Cache y sus Flujos Máquina de Estados - Modos • pass (vcl_pass) – Se invoca al entrar en modo pass. – En este modo la petición se pasa al backend y la respuesta del backend se manda al cliente sin entrar en la caché – Termina con una llamada a return() con alguna de las siguientes palabras clave: ● error code [reason] – Devuelve un código de error al cliente y abandona la petición. ● pass – Procede con el modo pass. ● restart – Reinicia la transacción e incrementa el contador de reinicios. Si dicho contador supera max_restarts Varnish arroja un error de “guru meditation”.
  51. 51. Introducción a la Gestión Interna de Varnish Cache y sus Flujos Máquina de Estados - Modos • hash (vcl_hash) – Debe invocarse hash_data() sobre los datos que quieren incorporarse al hash. – Termina con una llamada a return() con alguna de las siguientes palabras clave: ● hash – Procede.
  52. 52. Introducción a la Gestión Interna de Varnish Cache y sus Flujos Máquina de Estados - Modos • hit (vcl_hit) – Se invoca después de una búsqueda (lookup) si el documento solicitado se encuentra en la caché. – Termina con una llamada a return() con alguna de las siguientes palabras clave: ● error code [reason] – Devuelve un código de error al cliente y abandona la petición. ● pass – Cambia a modo pass. Transmitiá el control a vcl_pass. ● restart – Reinicia la transacción e incrementa el contador de reinicios. Si dicho contador supera max_restarts Varnish arroja un error de “guru meditation”. ● deliver – Entrega el objeto en caché al cliente. Transmitirá el control a vcl_deliver.
  53. 53. Introducción a la Gestión Interna de Varnish Cache y sus Flujos Máquina de Estados - Modos • miss (vcl_miss) – Se invoca después de una búsqueda (lookup) si el documento solicitado no se encuentra en la caché. – Su funcionalidad consiste en decidir si se intenta recuperar o no el documento desde el backend y desde qué backend. – Termina con una llamada a return() con alguna de las siguientes palabras clave: ● error code [reason] – Devuelve un código de error al cliente y abandona la petición. ● pass – Cambia a modo pass. Transmitiá el control a vcl_pass. ● fetch – Recupera el objeto solicitado del backend. Transmitirá el contorl a vcl_fetch.
  54. 54. Introducción a la Gestión Interna de Varnish Cache y sus Flujos Máquina de Estados - Modos • fetch (vcl_fetch) – Se invoca después de que un documento haya sido satisfactoriamente recuperado del backend. – Termina con una llamada a return() con alguna de las siguientes palabras clave: ● error code [reason] – Devuelve un código de error al cliente y abandona la petición. ● esi – Realiza un procesamiento ESI sobre el documento que ha sido recuperado del backend. ● pass – Cambia a modo pass. Transmitiá el control a vcl_pass. ● restart – Reinicia la transacción e incrementa el contador de reinicios. Si dicho contador supera max_restarts Varnish arroja un error de “guru meditation”. ● deliver – Incorpora el objeto a la caché y lo entrega al cliente. Transmitirá el control a vcl_deliver.
  55. 55. Introducción a la Gestión Interna de Varnish Cache y sus Flujos Máquina de Estados - Modos • deliver (vcl_deliver) – Se invoca antes de que un documento sea entregado al cliente. – Termina con una llamada a return() con alguna de las siguientes palabras clave: ● error code [reason] – Devuelve un código de error al cliente y abandona la petición. ● restart – Reinicia la transacción e incrementa el contador de reinicios. Si dicho contador supera max_restarts Varnish arroja un error de “guru meditation”. ● deliver – Entrega el objeto al cliente.
  56. 56. Introducción a la Gestión Interna de Varnish Cache y sus Flujos Máquina de Estados - Modos • error (vcl_error) – Se invoca cuando se encuentra un error, tanto implícita como exlícitamente, sea por errores internos o del backend. – Termina con una llamada a return() con alguna de las siguientes palabras clave: ● restart – Reinicia la transacción e incrementa el contador de reinicios. Si dicho contador supera max_restarts Varnish arroja un error de “guru meditation”. ● deliver – Entrega el objeto al cliente.
  57. 57. Introducción a la Gestión Interna de Varnish Cache y sus Flujos Flujos
  58. 58. 8. Obtención de Estadísticas
  59. 59. Obtención de Estadísticas • Varnish no logea en ficheros, lo hace en segmentos de memoria que, llegado un tamaño, se sobrescriben. ¡CUIDADO! Esto es muy rápido. Varnish es rápido, pero si no se escriben los logs a disco desaparecerán
  60. 60. Obtención de Estadísticas • varnishlogvarnishlog – Lee y muestra por consola los logs que el servicio de Varnish está generando en memoria. – Opciones más comunes: ● -b: Muestra sólo registros del tráfico transmitido entre Varnish y el backend. ● -c: Muestra sólo los registros del tráfico transmitido entre Varnish y el cliente. ● -m tag:regex: Muestra sólo las transacciones donde la etiqueta concuerda con una expresión regular. – https://www.varnish-cache.org/docs/3.0/reference/varnishlog.html
  61. 61. Obtención de Estadísticas • varnishlogvarnishlog
  62. 62. Obtención de Estadísticas • varnishhistvarnishhist – Lee los registros que Varnish está generando y muestra un histograma que se actualiza continuamente mostrando la distribución de las últimas N peticiones. – Opciones más comunes: ● -b: Muestra sólo registros del tráfico transmitido entre Varnish y el backend. ● -c: Muestra sólo los registros del tráfico transmitido entre Varnish y el cliente. ● -d: Procesa entradas de registro viejas cuando se inicia. Por defecto toma los datos que se generan a partir del inicio de su ejecución. ● -m tag:regex: Muestra sólo las transacciones donde la etiqueta concuerda con una expresión regular. – https://www.varnish-cache.org/docs/3.0/reference/varnishhist.html
  63. 63. Obtención de Estadísticas • varnishhistvarnishhist
  64. 64. Obtención de Estadísticas • varnishtopvarnishtop – Lee los registros que Varnish está generando y muestra una lista actualizada con las entradas de registro más frecuentes. – Opciones más comunes: ● -1: No actualiza la lista, muestra las estadísticas una vez y sale (implica -d). ● -b, -c, -d: Estas opciones realizan la misma función que con el comando anterior (varnishhist). – https://www.varnish-cache.org/docs/3.0/reference/varnishtop.html
  65. 65. Obtención de Estadísticas • varnishtopvarnishtop
  66. 66. Obtención de Estadísticas • varnishsizesvarnishsizes – Lee los registros que Varnish está generando y muestra un histograma que se actualiza continuamente mostrando la distribución de las últimas N peticiones en una escala logarítmica que representa los bytes. – Opciones más comunes: ● -b, -c, -d: Estas opciones realizan la misma función que en comandos anteriores (varnishhist). – https://www.varnish-cache.org/docs/3.0/reference/varnishsizes.html
  67. 67. Obtención de Estadísticas • varnishsizesvarnishsizes
  68. 68. Obtención de Estadísticas • varnishstatvarnishstat – Muestra estadísticas de la instancia de Varnish que está en ejecución. – Opciones más comunes: ● -1: No actualiza la lista, muestra las estadísticas una vez por la salida estándar y finaliza. ● -x: Muestra los resultados en formato XML (-j para hacerlo en formato JSON). – https://www.varnish-cache.org/docs/3.0/reference/varnishstat.html
  69. 69. Obtención de Estadísticas • varnishstatvarnishstat
  70. 70. Obtención de Estadísticas • varnishncsavarnishncsa – Lee los registros generados por Varnish en memoria en el formato de registro “combined” Apache/NCSA. – Opciones más comunes: ● -a: En caso de escribirse a un fichero anexa la información, no la sobrescribe. ● -d: Procesa entradas de registro viejas cuando se inicia. Por defecto toma los datos que se generan a partir del inicio de su ejecución. ● -f: Hace que prevalezca la cabecera HTTP X-Forwarded-For frente a client.ip en el registro. ● -D: Ejecuta el comando como un demonio. ● -F format: Especifica el formato usado para el registro. – https://www.varnish-cache.org/docs/3.0/reference/varnishncsa.html
  71. 71. 9. Configuración de Varnish Cache
  72. 72. En esta sección... Haremos una pequeña introducción a la configuración básica de Varnish, tanto desde un acercamiento teórico como su aplicación práctica usando el VCL.
  73. 73. Configuración de Varnish Cache Iniciar Varnish (/etc/default/varnish) • # pkill varnishd • # varnishd -f /etc/varnish/default.vcl -s malloc,1G -T 127.0.0.1:2000 -a 0.0.0.0:8080 – -f: Ruta al fichero de la configuración que usará Varnish. – -s: Tipo y cantidad de almacenamiento que usará Varnish. – -T: Activa la consola de administración en modo texto de Varnish (accesible mediante telnet). Permite manejar Varnish sin detener el servicio. – -a: Especifica el puerto en que Varnish escuchará peticiones HTTP entrantes.
  74. 74. Configuración de Varnish Cache Determinar el Tipo de Almacenamiento • Asociado al parámetro -s existen los siguientes tipos de almacenamiento: 1. malloc[,size] • Los objetos cacheados se almacenan en la memoria. • Si el sistema se queda sin memoria usará el swap (¡OJO!) • Añade una sobrecarga de 1K por cada objeto. • El tamaño puede expresarse en K(ibibytes), M(ebibytes), G(ibibytes), T(ebibytes). Por defecto es ilimitado. 2. file[,path[,size[,granularity]]] • Los objetos cacheados se almacenan en un fichero de disco con mmap. • Es la opción usada por defecto si no se especifica otra. • El tamaño puede expresarse igual que en el caso de malloc, pero se añade la opción %, que indica usar un determinado porcentaje del espacio libre en disco. 3. persistent,path,size {experimental} • Almacenamiento persistente. Los objetos cacheados se almacenan en un fichero de manera que la mayoría pueda sobrevivir en caso de una parada de Varnish. • El tamaño puede expresarse igual que en el caso de malloc.
  75. 75. Configuración de Varnish Cache Determinar el Algoritmo de Hash • Asociado al parámetro -h existen los siguientes algoritmos de hash: 1. simple_list • Lista simple con doble enlace. • No es recomendable usarlo en entornos de producción. 2. classic[,buckets] • Tabla estándar de hash. Es la opción por defecto. • La llave hash es el CRC32 de la URL del objeto. Cada entrada de la tabla apunta a un conjunto de objetos que comparten las misma llave hash. • El bucket determina el número de entradas de la tabla hash. Por defecto es 16383. 3. critbit • Estructura de árbol autoescalable. • El árbol Crit-Bit es comparativamente mejor que el típico árbol B.
  76. 76. Configuración de Varnish Cache Determinar el Tamaño de la Caché • Determinar el tamaño de la caché es uno de los pasos más importantes de la configuración de Varnish. • Cuestiones a tener en cuenta: – El tamaño de la información “viva” Por ejemplo: Página principal + un nivel con todos sus objetos – El coste de generar un objeto Por ejemplo: Imágenes, fáciles de servir desde el backend – El valor del contador n_lru_nuked de varnishstat Mucha actividad LRU indica que se están eliminando objetos por problemas de espacio, así que habría que incrementar es espacio de caché) ¡CUIDADO! Varnish añade una sobrecarga de 1Kb a cada objeto que almacena en Memoria. Si hay mucho objetos pequeños puede suponer un problema.
  77. 77. Configuración de Varnish Cache Poner Varnish a Escuchar en el Puerto 80 1. Si el servidor de backend y Varnish están en la misma máquina y el servidor de backend escucha en el puerto estándar (80), habrá que modificarlo. 2. Nos aseguramos de que el servicio de Varnish no está en ejecución. ● # pkill varnishd 3. O bien modificamos la configuración del servicio de Varnish (/etc/default/varnish) y lo reiniciamos (service varnishd restart), o ejecutamos el comando para iniciar el servicio con los parámetros adecuados. ● # varnishd -f /etc/varnish/default.vcl -s malloc,1G -T 127.0.0.1:2000
  78. 78. Configuración de Varnish Cache Varnish Configuration Language ● Repasemos un poco VCL: ● Ejemplos:
  79. 79. Configuración de Varnish Cache Lograr un Ratio Elevado de Hits • Analizar las peticiones de los clientes y las cabeceras que se transmiten. – varnishtop -i txurl – varnishlog -c -m 'RxURL:^/foo/bar – lwp-request (Perl) – Live HTTP Headers https://addons.mozilla.org/es/firefox/addon/live-http-headers/
  80. 80. Configuración de Varnish Cache Lograr un Ratio Elevado de Hits • Con cada petición HTTP vienen cabeceras con metadatos que le dicen a Varnish qué hacer con el contenido. Algunas de las más importantes son: – Cache-Control – Age – Pragma – Authorization
  81. 81. Configuración de Varnish Cache Lograr un Ratio Elevado de Hits • Otras opciones para incrementar el ratio de hits: – Incrementar el TTL – Forzar el cacheo de ciertas peticiones y respuestas (NO RECOMENDADO) – Normalizar el namespace
  82. 82. Configuración de Varnish Cache Cookies • Varnish, por defecto, no cacheará objetos provinientes del backend con la cabecera Set-Cookie. • Igualmente, si el cliente manda una cabecera Cookie, Varnish hará un bypass y enviará la petición directamente al servidor de backend. MUY CONSERVATIVO Para muchas aplicaciones web pueden descartarse completamente las cookies salvo para determinadas secciones.
  83. 83. Configuración de Varnish Cache Cookies • Del clientecliente:
  84. 84. Configuración de Varnish Cache Cookies • Del servidor de backendservidor de backend: – Si el servidor de backend pone una cookie usando la cabecera Set-Cookie, Varnish no cacheará la página. – Se crea un objeto hit-for-pass.
  85. 85. Configuración de Varnish Cache Vary • La cabecera Vary, enviada por el servidor web, indica qué es lo que hace a un objeto HTTP “cambiar su apariencia” (vary). • Varnish cachea versiones separadas de un objeto por cada Vary. Ejemplo / PROBLEMA SOLUCIÓN “Vary: Accept-Encoding” le dice a Varnish que guarde una versión diferente por cada Accept-Encoding, pero ese campo puede contener un montón de codificaciones diferentes. Cuando diferentes navegadores manden diferentes Accept-Encoding (ejemplo), aunque sólo en apariencia, Varnish mantendrá una variante diferente de la página por cada uno de ellos. Normalizar con VCL la cabecera Accept-Encoding de manera que haya tan pocas variantes como sea posible. El ejemplo comprueba si el cliente acepta gzip, en cuyo caso prevalece, si no deflate.
  86. 86. Configuración de Varnish Cache Vary • Si hay errores de parseo de la cabecera Vary o la cabecera supera los 65Kb caracteres: – Página de error 503 (internal server error) – Se añade entrada SLT_Error al registro • Muchas veces se envía “Vary: User-Agent” con el contenido: – Problema: Algunas aplicaciones o servidores de aplicaciones mandan un Vary: User-Agent con su contenido – Solución: Normalizar las cabeceras User-Agent
  87. 87. Configuración de Varnish Cache Compresión • Varnish tiene soporte nativo para compresión usando gzip. • Activado por defecto, puede desactivarse con el parámetro http_gzip_support a false (varnishd). • Comportamiento: 1. Varnish comprueba si el cliente acepta la compresión gzip. 2. Si lo hace desprecia el valor de la cabecera Accept-Encoding y la establece en “gzip”. 3. Realiza entonces la solicitud al servidor de backend del contenido comprimido en gzip. Varnish almacenará el objeto en caché tal y como se lo entregue el backend. ¡CUIDADO! Hay que evitar intentar comprimir contenido que no es comprimible (JPG, GIF, MP3, etc). Hace que Varnish comprima el contenido antes de almacenarlo en caché.
  88. 88. Configuración de Varnish Cache ESI (Edge Side Includes) • ESI es un lenguaje para incluir fragmentos de páginas web dentro de páginas web. Es una sentencia include para HTML que funciona sobre HTTP. • Implementación parcial de ESI en Varnish: – esi:include – esi:remove – <!--esi ... --> http://www.akamai.com/html/support/esi.html
  89. 89. Configuración de Varnish Cache ESI (Edge Side Includes) • Ejemplo: • Ejemplo:
  90. 90. Configuración de Varnish Cache Detección de Dispositivo https://github.com/varnish/varnish-devicedetect/ • La detección de dispositivo consiste en determinar el contenido que el servidor debe proporcionar al cliente basándose en la cabecera User-Agent proporcionada en la solicitud.
  91. 91. Configuración de Varnish Cache Detección de Dispositivo • Ejemplo: • Ejemplo: Varnish añade la cabecera HTTP X-UA-Device a la solicitud al servidor de backend, el cual indica en la cabecera Vary de la respuesta que el contenido es dependiente de dicha cabecera. Establecemos la cabecera.
  92. 92. Configuración de Varnish Cache Websockets • Tecnología que proporciona un canal de comunicación bidireccional y full-duplex sobre un único socket TCP diseñada para ser implementada en navegadores y servidores web. • Para ejecutar websockets a través de Varnish hay que hacer lo siguiente. http://www.websocket.org/ - http://dev.w3.org/html5/websockets/
  93. 93. Configuración de Varnish Cache VMOD (Extensiones y Módulos de Varnish) • Las VMOD son extensiones para Varnish. • Disponibles en un directorio, donde se indica su estado (en desarrollo, prueba de concepto, en producción), la licencia bajo la que se ofrecen y si disponen o no de soporte comercial. • Algunas son: – Cookie – Dclass Apache DeviceMap – cURL – Soft purge – Header manipulation – Digest – Shield – ... https://www.varnish-cache.org/vmods
  94. 94. Configuración de Varnish Cache CLAVES ● Conocer si la instalación de Varnish se va a realizar en donde se ubicará el servidor de backend y si se trata de un entorno virtualizado. ● Determinar todos los dominios que sirven el mismo contenido. ● Determinar si existen diferentes versiones de la web para diferentes dispositivos. ● Conocer el peso de la página principal con todos sus objetos mas el primer nivel de enlaces. ● Conocer el uso que se hace de las sesiones y las cookies en la aplicación web. ● En base al tipo de contenido, determinar las opciones de compresión del mismo. ● Ver si existen grandes flujos de datos que deban pasar directamente entre el cliente y el backend. ● Determinar si algunas partes de la aplicación web no deben cachearse. ● Determinar si existen redirecciones 301/302. ● Determinar si existe la necesidad de identificar la IP del cliente. ● ... ¿OTRAS CLAVES?
  95. 95. 10. Monitorización de Varnish Cache
  96. 96. Monitorización de Varnish 1. Seleccionar el servidor a monitorizar (IP: E.F.G.H) e instalar el nodo de munin: ● # apt-get install munin-node 2. Seleccionar el servidor donde se van a recolectar los datos (IP: A.B.C.D) e instalar munin (puede ser la misma máquina): ● # apt-get install munin 3. Configurar munin en el nodo y reiniciar el servicio: ● # echo allow ^A.B.C.D$ >> /etc/munin/munin-node.conf ● # service munin-node restart 4. Configurar munin en el servidor: ● Añadir al fichero /etc/munin/munin.conf [Domain;ServerA] address E.F.G.H use_node_name yes Integrar Varnish con Munin (Debian) Munin viene, out-of-the-box, con un plugin para generar gráficas en base al comando varnishstat
  97. 97. Monitorización de Varnish 1. Descargar el plugin de Varnish para Nagios: – https://www.varnish-cache.org/utility/nagios-varnish-plugin 2. Si hubiese que explicar aquí Nagios... No acabábamos nunca... Integrar Varnish con Nagios
  98. 98. 11. Configuraciones Específicas para WordPress
  99. 99. Configuraciones Específicas para WordPress ● Plugin para WordPress que purga/banea la cache del servidor Varnish cuando: ✔ Hay nuevo contenido ✔ Se borra contenido ✔ Se edita contenido WordPress Varnish as a Service http://wordpress.org/plugins/wordpress-varnish-as-a-service
  100. 100. Configuraciones Específicas para WordPress ● Plugin para WordPress que genera ficheros HTML estáticos a partir de los ficheros PHP. Ahorra una gran carga de trabajo. ● Varnish usa las cabeceras del servidor de backend para determinar el TTL de un objeto. WP Super Cache establece el TTL por defecto en 3 segundos, puede modificarse en “wp-content/cache/.htaccess”. WP Super Cache http://wordpress.org/plugins/wp-super-cache/
  101. 101. Configuraciones Específicas para WordPress ● Plantillas con ejemplos de configuraciones para WordPress y varias configuraciones para: ➢ Reescritura de URLs desde el servidor ➢ Páginas de error limpias para debugging ➢ Implementación de host virtuales ➢ Normalización de varias cabeceras ➢ Manipulación de cookies ➢ Gestión de redirecciones 301/302 con Varnish Plantillas de Configuración de Varnish https://github.com/mattiasgeniar/varnish-3.0-configuration-templates
  102. 102. Configuraciones Específicas para WordPress ● Varnish siempre incluye una cabecera X-Forwarded-For cuando “habla” con el backend. Problemas: ➢ Debería omitirse en las peticiones normales que no sean de tipo pass o pipe. ➢ En el caso de pass, si está presente, debería añadírse la IP del cliente separada por una coma. Problema con la Cabecera X-Forwarded-For https://www.varnish-cache.org/trac/ticket/203
  103. 103. 12. Conclusiones
  104. 104. Conclusiones ✔ Gran rendimiento y portabilidad. ✔ Completo lenguaje propio, VCL: veloz, robusto y flexible. ✔ Balanceo de carga embebido. ✔ Registro de transacciones a coste cero: rapidísimo, completo y sin ocupación en disco. ✔ Gestión del servicio sin downtimes. ✔ Edge Side Includes. ✔ ¡¡¡OpenSource!!! (y versión de subscripción)
  105. 105. Gracias por vuestra atención

×