Varnish Server Cache

Ricardo Brito do Nascimento 13 de outubro de 2011

dispon em: vel http://brito.blog.incolume.com.br/2011/10/varnish.html
Resumo O Varnish uma soluo de cache e acelerao de processamento e ca ca para os mais diversos tipos de aplicativos web.

Introduo ca

O Varnish um cache web de alta performance. Ele utiliza os recursos e avanados do cerne Linux 2.6, FreeBSD 6/7 e Solaris 10 para atingir seu alto c desempenho. Entre as caracter sticas desta ferramenta de cache-proxy, destaca-se: 1. Design moderno; inclusive contemplando arquitetura com mltiplos prou cessadores; 2. VCL Varnish Conguration Language uma linguagem de congurao ca muito ex vel; 3. O balanceamento de carga com a vericao de estado dos back-ends; ca 4. Suporte parcial a tecnologia ESI; 5. Reescrita de URL; 6. Manipulao elegante para back-ends inoperantes; ca O Varnish trabalha na memria virtual, e o kernel do sistema operacional que o e decide qual processo, e a quantidade de RAM destinada, ao mapear o espao c de endereamento virtual dos processos. c 1

Esta ferramenta cache foi desenvolvida para trabalhar em arquitetura de 64 bits, e usar memria virtual; em um sistema de 32 bits, que foge o estilo projetado, o poder ter problemas para congurar mais de 2 GB de armazenamento. a Atualmente no h planos para adicionar suporte a HTTPS na estrutura do a a Varnish, at que possa encontrar um caminho onde agrega-se um valor e signicativo, em relao ` execuo estvel de proxy HTTPS. ca a ca a Embora no trabalhe nativamente com o protocolo HTTPS, outros recursos a funcionam perfeitamente, como mltiplos VirtualHosts e o balanceamento de u carga com algor timo round-robin, isto atravs da VCL. e

1.1

Porque o nome Varnish?

Varnish do ingls, signica verniz, e segundo sua histria (1), basicamente o e o fato instigador do nome, foi um cartaz publicitrio, com a palavra Vernisage, a que foi vericada em um dicionrio, a qual apresentou os trs seguintes a e signicados: r.v. varnished, varnishing, varnishes 1. To cover with varnish. Para cobrir com verniz. 2. To give a smooth and glossy nish to. Para dar um acabamento liso e brilhante para 3. To give a deceptively attractive appearance to; gloss over. Para dar uma aparncia atraente para enganosamente; encobrir. e As trs descreve o que acontece ao sistema de back-end quando colocado atrs e a do Varnish.

Instalao ca

Com o Varnish tem-se a opo de instalao por binrios, repositrios ou ca ca a o atravs do cdigo fonte, como na maioria dos programas para Linux. e o Os binrios, dispon a veis para Debian, FreeBSD, RHEL5 e Ubuntu; e o cdigo o fonte, na release 2.1.4, pode ser baixado em http://www. varnish-software.com/sites/default/files/varnish-2.1.4.tar.gz

2.1

Requisitos

O Varnish, obrigatoriamente, requer um sistema operacional de 64 bits, sendo Linux, FreeBSD ou Solaris. 2

2.2

Dependncias e

Primeiramente, antes de iniciar a instalao do Varnish as dependncias devem ca e estar contempladas no Sistema Operacional. 2.2.1 autotools-dev automake1.9 libtool autoconf libncurses-dev xsltproc gro-base libpcre3-dev pkg-cong 2.2.2 automake autoconf libtool ncurses-devel libxslt gro pcre-devel pkgcong RHELS/CentOS/Fedora Ubuntu/Debian

2.3

por Repositrios: Ubuntu/Debian o

$ curl http://repo.varnish-cache.org/debian/GPG-key.txt \ | apt-key add $ echo "deb http://repo.varnish-cache.org/debian/ \ lenny varnish-2.1" \ >> /etc/apt/sources.list $ aptitude update $ aptitude install varnish

2.4

por Repositrios: RHELS/CentOS/Fedora o

A intalao do varnish est dispon atravs do repositrio EPEL. Infelizmente ca a vel e o a verso mais recente dispon o varnish 2.0.6. Isto signica, se a instalao a vel e ca no RH-Like for feita atravs do repositrio, no trar a ultima verso. e o a a a $ yum install varnish

2.5

Por Repositrio (ports): FreeBSD o

$ cd /usr/ports/www/varnish && make install clean $ pkg_add -r varnish

2.6

Por binrios: Ubuntu/Debian a

$ dpkg -ih varnish

2.7

Por binrios: RHELS/CentOS/Fedora a

$ rpm - -nosignature -ivh http://repo.varnishcache.org/redhat/el5/noarch/varnish-release-2.1-2.noarch.rpm

2.8

por fonte Linux

Para obter o cdigo fonte do Varnish necessrio o subversion. Execute os o e a comandos: $ $ $ $ $ svn co http://varnish-cache.org/svn/branches/2.1 varnish-cache cd varnish-cache sh autogen.sh sh configure make 4

$ /bin/varnishtest && ./varnishtest tests/*.vtc $ make install A documentao ocial, alerta que podem ocorrer falha no teste, e diz no se ca a preocupe de um ou dois testes falharem, alguns dos testes so demasiadamente a longos. Se tudo ocorreu corretamente, o Varnish, agora est instalado no diretrio a o /usr/local, o binrio varnishd est em /usr/local/sbin/varnishd e o arquivo de a a congurao padro est em /usr/local/etc/verniz/default.vcl. ca a a

Noes de HTTP co

O Hypertext Transfer Protocol, mais conhecido por seu acrnimo HTTP, com o origem do ingls, signica Protocolo de Transferncia de Hipertexto, um e e e protocolo de comunicao, relativo a camada de aplicao conforme o Modelo ca ca OSI. Esta tecnologia utilizada para publicao de contedo em sistemas de e ca u informao com hiper-media distribu ca das e colaborativas, o seu uso para a obteno de recursos interligados levou ao estabelecimento da World Wide Web ca (WWW). Hoje o WWW, Coordenado pela World Wide Web Consortium e a Internet Engineering Task Force, culminou na publicao de uma srie de Requests for ca e Comments; mais especicamente o RFC 2616, de junho de 1999, que deniu o HTTP/1.1 (2), que tornou-se a base para a internet que se conhece hoje. Normalmente, este protocolo utiliza a porta 80 e usado para a comunicao e ca de s tios web, atravs da linguagem HTML(HyperText Markup Language). e Contudo, para haver comunicao com o servidor do s necessrio utilizar ca tio e a comandos adequados, que no esto em linguagem HTML, sim nos protocolos a a motores da Web, os quais so interpretados por clientes web, ou navegadores, a exemplos: Google Chrome, Chromium, Firefox, Epiphani, Mozilla, Safari e Internet Explorer R .

3.1

Cdigos de retorno o

A linha inicial de uma resposta HTTP indica ao cliente http(navegador web) se sua requisio foi bem sucedida ou no (3). Essa situao fornecida atravs ca a ca e e de um cdigo de retorno (Status-Code) e uma frase explicativa o (Reason-Phrase). De acordo com Fielding,() o cdigo de status formado por o e trs d e gitos e o primeiro d gito representa a classe de resposta, que possui cinco tipos de classicao, conforme tabela abaixo: ca 5

1xx 100 101 2xx 200 201 202 203 204 205 206 3xx 300 301 302 303 304 305 306 307 4xx 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 5xx 500 501 502 503 504 505

Informational (Informao) utilizada para enviar informaes para o cliente de que sua requisio ca co ca foi recebida e est sendo processada; a Continue Switching Protocols Success (Sucesso) indica que a requisio do cliente foi bem sucedida; ca OK Created Accepted Non-Authoritative Information No Content Reset Content Partial Content Redirection (Redirecionamento) informa a ao adicional que deve ser tomada para completar ca a requisio; ca Multiple Choices Moved Permanently Found See Other Not Modied Use Proxy (Unused) Temporary Redirect Client Error (Erro no cliente) avisa que o cliente fez uma requisio que no pode ser atendida; ca a Bad Request Unauthorized Payment Required Forbidden Not Found Method Not Allowed Not Acceptable Proxy Authentication Required Request Timeout Conict Gone Length Required Precondition Failed Request Entity Too Large Request-URI Too Long Unsupported Media Type Requested Range Not Satisable Expectation Failed Server Error (Erro no servidor) ocorreu um erro no servidor ao cumprir uma requisio vlida. ca a Internal Server Error Not Implemented Bad Gateway Service Unavailable Gateway Timeout HTTP Version Not Supported

O protocolo HTTP dene somente alguns cdigos em cada classe descritos na o RFC 2616, mas cada servidor pode denir seus prprios cdigos. o o Esta seo pode ser uma interessante referncia para a programao e ca e ca congurao da diretiva com mensagens fornecidas pelo servidor web Apache. ca

Tabela 1: Cdigos HTTP o Cdigo o 2xx 200 201 202 203 204 205 206 3xx 300 301 302 303 304 305 4xx 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 5xx 500 501 502 503 Signicado Sucesso OK Criado Aceito Informao no-autoritativa * ca a Nenhum contedo u Contedo resetado * u Contedo parcial * u Redirecionamento Mltiplas escolhas u Movido Permanentemente Movido Temporariamente Veja outra * No modicada a Use o Proxy (redirecionamento proxy) * Erros no Cliente Requisio incorreta ca No autorizado a Pagamento Requerido * Bloqueado No encontrada a Mtodo no permitido * e a No aceitvel * a a Autenticao via proxy requerida * ca Tempo limite da requisio expirado * ca Conito * Gone * Tamanho requerido * Falha na pr-condio * e ca A requisio parece ser grande * ca A URL requisitada muito longa * e Tipo de m no suportado dia a Erros no Servidor Erro Interno no Servidor No implementado a Gateway incorreto Servio no dispon c a vel ..

Cdigo o 504 505

Tabela 1 Signicado Tempo limite no gateway * Verso HTTP no suportada * a a

Os cdigos de erros marcados com um *pertencem ao padro HTTP 1.1 o a descritos na rfc 2616.

Utilizando o Varnish

Para utilizar o Varnish adequadamente, o administrador de sistemas, deve saber como congurar seu aplicativo ou servidor web e ter conhecimento bsico do a protocolo HTTP, alm do Varnish funcionando com a congurao padro. e ca a O Varnish atua com o conceito de servidores back-end ou origin. Um servidor back-end o responsvel por prover contedo que ser acelerado pelo e a u a Varnish. A primeira tarefa congurar onde encontrar este contedo. e u Isto feito no arquivo de congurao padro do Varnish, o InstallDir / e ca a varnish/default.vcl, que provavelmente estar em /usr/local/etc/varnish/ a default.vcl ou /etc/varnish/default.vcl. Logo no topo deste arquivo de congurao, haver um bloco com a seguinte ca a aparncia: e # # # # backend default { .host = "127.0.0.1"; .port = "8080"; }

Este trecho de congurao, comentado por #, escrito na linguagem VCL, ca dene o servidor default (padro) que hospeda o contedo a ser cacheado e a u acelerado pelo Varnish, ou seja o back-end. Com trechos deste tipo, o Varnish pode ter vrias infra-estruturas denidas e a at aglomerados de back-ends para ns de balanceamento de carga. e Para habilit-lo, vamos retirar o comentrio e apontar para um servidor vlido a a a na rede, considerando a porta do servio. O trecho dever car parecido com o c a trecho abaixo, aps retirar os comentrios e congurar valores vlidos: o a a backend default { .host = "192.168.1.1"; .port = "80"; }

4.1

Iniciando o Varnish

Inicialmente deve-se parar o processo do Varnish, se por ventura estiver rodando, execute: # pkill varnishd Com status de super usurio (root), execute o seguinte comando para iniciar o a Varnish: # varnishd -f InstallDir /varnish/default.vcl \ -s malloc,1G -T 127.0.0.1:2000 -a 0.0.0.0:8080 -f /usr/local/etc/varnish/default.vcl indica o arquivo de congurao a ser ca utilizado. -s malloc,1G dene o tipo de armazenamento o Varnish utilizar para o a contedo de cache. u -T 127.0.0.1:2000 -a 0.0.0.0:8080 Especica que Varnish escutar a porta 8080, recebendo a requisioes HTTP. Em um ambiente de produo normalmente a porta padro c ca a escutada, a porta 80 (HTTP). e Agora o Varnish est em execuo. Para testar o funcionamento correto, use o a ca navegador para acessar a mquina, na qual foi congurado o Varnish, exemplo: a http://192.168.1.2:8080/, dever apresentar a aplicao web que esta a ca rodando no servidor http://192.168.1.1:80. Aps estas alteraoes a unica chance do aplicativo no ter sido acelerado, o c a e utilizao de cookies individuais para cada sesso (Varias aplicaoes em PHP e ca a c Java parecem enviar cookies de sesso mesmo que no seja necessrio, onde a a a ser necessrio correo na aplicao) ou se utiliza sesso autenticada, a qual o a a ca ca a Varnish no far cache. a a Para iniciar o Varnish na porta 80, execute o comando da seguinte forma: # varnishd -f InstallDir /varnish/default.vcl -s malloc,1G -T 127.0.0.1:2000 O que equivalente a: e # varnishd -f InstallDir /varnish/default.vcl -s malloc,1G -T 127.0.0.1:2000 -a 0.0.0.0:80 4.1.1 Dimensionamento de Cache

Denir a quantia de memria e/ou disco, e o tipo a ser utilizado, SATA Serial o Advanced Technology Attachment, SCSI Small Computer System Interface, ISCSI Internet Small Computer System Interface, FC Fibre Chanel ou SAS Serial Attached ISCSI, para montar a infraestrutura do Varnish pode ser uma tarefa complicada. Mas sempre considera-se:

 Quo grande o volume de acesso de dados, para um portal ou s a e tio; o tamanho da pgina com todas as coisas nela contida, e do tamanho de a todas as pginas e objetos ligados, desde a raiz. a O custo de manter um objeto, as vezes no faz sentido. Imagens em a cache por pouco tempo um exemplo. No mante-las em cache, devem e a ser consideradas se possuem baixo custo para servi-las diretamente pelo back-end, ou h uma quantidade limitada de memria na mquina onde o a o a Varnish rodor. a Se o registro de logs ser mantido em disco. a

4.2

Registro de Eventos Logs

Uma das caracter sticas realmente interessante como o Varnish trabalha com e o gerenciamento de logs. Em vez de gravar os registro em um arquivo mapeado em disco no sistema operacional, ele utiliza um segmento de memria o compartilhado. Quando se esgota o espao deste segmento, o Varnish c sobrescreve automaticamente os registros mais antigos. A vantagem deste processo a agilidade para registrar o evento, evitando o e acesso ao sistema de arquivos, que um processo lento, e no requer espao e a c em disco. Por outro lado se no tiver um programa para persistir os logs em a disco o histrico de todos os eventos iro desaparecer. o a O varnish, possui um programa nativo chamado varnishlog, com o qual pode-se acompanhar o registro dos eventos, em tempo real. Este programa executado e via linha de comando, e faz parte do processo master do Varnish, onde pode ser vericado o bom andamento do cache. Havendo acessos a mquina onde varnish, est rodando, o resultado ser a a a semelhante a este trecho: 11 11 11 11 11 11 11 SessionOpen ReqStart RxRequest RxURL RxProtocol RxHeader RxHeader c c c c c c c 127.0.0.1 58912 0.0.0.0:8080 127.0.0.1 58912 595005213 GET / HTTP/1.1 Host: localhost:8080 Connection: keep-alive

A primeira coluna o numero que identica a requisio, todas as linhas que e ca possuem o mesmo numero fazem parte da mesma transao HTTP. ca A segunda coluna a etiqueta da mensagem, todas as entradas so etiquetadas, e a e ordenadas no inicio da atividade. As etiquetas ou tags comeando com Rx c indicam que o Varnish est recebendo dados e Tx indica o envio de dados. a 10

A terceira coluna apresenta a origem dos dados, sendo o cliente representado por (c) e back-end representado por (b). A quarta coluna o registro sobre as requisioes em HTTP. e c Segue algumas opoes do comando varnishlog: c -b Apenas apresenta as linhas do registo de trfego que entram e os a servidores de back-end. Isso util quando se deseja otimizar as taxas e de acesso ao cache; -c Mesmo que -b, mas para o trfego do lado do cliente. a -i tag Exibe apenas as linhas com a etiqueta especicada. -I varnishlog SessionOpen, Nota: s vai apresentar as novas sesses; as tags so case o o a sensitive. -I Filtrar os dados atravs de Expresso Regular. Para mostrar todos e a os cabealhos de cookies provenientes dos clientes: $ varnishlog -c -i c RxHeader -I Cookie; -o Grupo de registro por ID de requisio. ca

4.3

Estat sticas

O Varnish possui uma gama de ferramentas para auxiliar a analise de eventos. varnishtop O utilitrio varnishtop l a memria compartilhada de logs e presenta a e o continuadamente atualizado a lista das ocorrncias mais frequentes. e Com suas opoes de ltro ( -I, -i, -X e -x ), esta ferramenta pode apresentar o c ranking de documentos requisitados, os clientes, os agentes, ou qualquer informao gravada em log. ca varnishtop -i rxurl Exibe as URLs solicitadas pelo cliente. varnishtop -i txurl Exibe o mtodo mais utilizado. e varnishtop -i RxHeader -I Accept-Encoding Exibe o cabealho Accept-Encoding requisitado mais popular. c varnishhist O utilitrio varnishhist l a memria compartilhada do processo varnishd, e a e o atualiza o histrico apresentando a distribuio das ultimas N requisioes por o ca c processo. varnishsizes O utilitrio varnishsizes faz o mesmo que varnishhist, entretanto ele mostra o a tamanho dos objetos e no o tempo necessrio para completar a requisio. a a ca Com isso apresentado uma boa viso de como os grandes objetos esto sendo e a a servidos. varnishstat 11

O Varnish possui diversos contadores, entre eles, conexes perdidas(miss), o aceitas(hit), armazenamento, criao de threads e objetos deletados. O ca utilitrio varnishstat descarrega estes contadores para analise. Estes contadores a so necessrios para fazer tuning no varnish. a a Existem programas que trabalham em paralelo com varnishstat e fazer bons grcos desses contadores. Um desses programas Munin, este programa pode a e ser encontrado em http://munin-monitoring.org. No cdigo-fonte varnish o j existe um plugin para Munin incorporado. a

Varnish Conguration Language VCL

A maioria dos outros sistemas de cache-proxy, utilizam diretivas de congurao, que so habilitadas ou desabilitadas por ativao de parmetros. ca a ca a O Varnish usa uma linguagem de dom espec nio ca chamada Varnish Conguration Language VCL. H uma traduo dessa congurao em a ca ca cdigo binrio, que ento executada quando chegam as requisioes. o a e a c O VCL a linguagem de congurao padro utilizada no Varnish, desenvolvida e ca a pelos autores Dag-Erling Smrgrav, Poul-Henning Kamp, Kristian Lyngstl e Per Buer. E uma linguagem de pequeno porte, especicamente projetada para ser usada na denio e na manipulao de pol ca ca ticas de cache para o acelerador HTTP Varnish. Quando uma nova congurao carregada, o processo gestor varnishd traduz ca e o cdigo de VCL para C, o compilando para um objeto, que ser ento ligado e o a a compartilhado dinamicamente aos processos do servidor. Os arquivos de VCL so divididos em sub-rotinas. Estas sub-rotinas diferentes a so executados em momentos destintos, onde uma atua na chegada da a requisio cliente, e a outra quando o contedo requisitado ao servidor ca u e back-end. O Varnish executar essas sub-rotinas de cdigo em diferentes fases, porque o a o cdigo executado linha ` linha, no ocorrendo o problema de precedncia. o e a a e Se no for chamada a sub-rotina at chegar ao nal da execuo, o Varnish a e ca executar alguns cdigos constru a o dos em VCL. H exemplos deste cdigos em a o VCL comentadas no default.vcl. 99% de todas as alteraoes necessrias j c a a ca esto feitas nas sub-rotinas: vcl recv e vcl fetch. Abaixo a descrio de todas: a 1. vcl recv: Esta sub-rotina acionada no in de uma solicitao, aps e cio ca o o pedido ser recebido e completamente analisado. Seu objetivo decidir e se deve ou no atender a requisio, como faz-la, e, se aplicvel, que a ca e a back-end usar. Tambm poss alterar o pedido, alterar os cookies e a e e vel adicionar ou remover cabealhos de solicitao. c ca 12

2. vcl fetch: Esta sub-rotina acionada depois que um documento foi recue perado com xito de um back-end. Seu objetivo so tarefas para alterar os e a cabealhos de resposta, desencadear o processamento ESIEdge-Side Inc cludes, e tentar recuperar dados em servidores back-end alternativos, caso a solicitao inicial falhe. ca 3. vcl deliver: Chamado antes de enviar um objeto do cache para o cliente. 4. vcl hash: Calcula a chave de hash para identicar os objetos no cache, o padro a URL. a e a 5. vcl miss e vcl hit: Chamados quando o Varnish identica hitou no, miss, uma requisio com um objeto em cache. ca 6. vcl erro: Chamado quando identicado um erro na resposta ` requisio e a ca 7. vcl discard: Chamado quando um objeto esta prestes a ser descartado. o 8. vcl timeout: Chamado quando um documento em memria expira. 9. vcl pipe ou vlc pass: Chamados quando o proxy deve ignorar as comunicaoes entre o servidor Web e o cliente em uma determinada condio. c ca

5.1

Sintaxe

A linguagem VCL foi deliberadamente criada, similar as linguagens C e Perl. Onde os blocos so delimitados por chaves, ponto e virgula para m de a sentena, e os comentrios, podem ser escritos como em C, C++ ou Perl. c a Os operadores da tabela a seguir so vlidos em VCL. a a = Atribuio de operador ca == Comparao ca Equivalncia. Pode ser utilizado em Expresso regular ou ACL e a ! Negao ca && e lgico o ou lgico o Alm da atribuio do tipo C (=), comparao (==) e os operadores booleano e ca ca (!, && e ||), o VCL suporta expresses regulares e vericao de ACL atravs da o ca e utilizao do operador . No trato com strings, elas podem ser concatenadas ca apenas em coloc-las uma aps a outra, sem qualquer operador adicional. a o

13

Declarao Back-end ca A declarao de back-end, cria e inicializa um objeto com o nome desejado ca para o back-end, exemplo: backend www { .host = "www.example.com"; .port = "http"; } 1 backend www: o nome pelo qual o back-end ser identicado pelo Varnish; e a 2 .host = www.example.com: nome pelo qual o back-end ser acessado; e a 3 .port = http: a porta pela qual o back-end oferece seus servios, onde e c http equivale a 80; Os objetos back-end sero utilizados posteriormente para selecionar as a requisioes em tempo de execuo, o exemplo abaixo verica se a requisio c ca ca e para a url http://example.com ou http://www.example.com, se coincidir redireciona a requisio para o back-end www. ca if (req.http.host ~ "^(www.)?example.com$") { set req.backend = www; } Para evitar a sobre carga dos servidores back-ends, pode ser congurado o a a parmetro .max connections, este parmetro limita a quantidade mxima de a conexes simultneas concorrentes. o a O timeout tambm pode ser alterado e ultrapassado na declarao do e ca back-end. Os parametros de timeout congurveis so: a a 1 .connect timeout: Tempo de espera da conexo; a 2 .rst byte timeout: Tempo de espera para envio do 1o byte do back-end; e 3 .between bytes timeout: Tempo de espera para cada byte recebido. Estas opes so declaradas como no exemplo abaixo: co a backend www { .host = "www.example.com"; .port = "http"; .connect_timeout = 1s; 14

.first_byte_timeout = 5s; .between_bytes_timeout = 2s; .max_connections = 100; } O back-end atinge o estado de insalubre, ou inativo, aps ter atingido a quantia o de itens na lista do saint mode, especicamente na declarao .threshold, o ca a parmetro .saintmode threshold, assume o tamanho mximo da lista por a padro, ao ser denido com o valor 0 (zero), a vericao do saint mode a ca e desativada. O valor na declarao de back-end substitui o parmetro. ca a Directors A seleo por status entre os servidores back-ends, baseada na salubridade, ou ca estado ativo do servidor, depende de um algoritmo diretor, no caso do Varnish esto dispon a veis dois, round-robin e aleatrio (random). o Directors are dened using:: director b2 random { .retries = 5; { // We can refer to named backends .backend = b1; .weight = 7; } { // Or define them inline .backend = { .host = "fs2"; } .weight = 3; } } The random director The random director takes one per director option .retries. This species how many tries it will use to nd a working backend. The default is the same as the number of backends dened for the director. There is also a per-backend option: weight which denes the portion of trac to send to the particular backend. 15

The round-robin director The round-robin does not take any options. The DNS director The DNS director can use backends in three dierent ways. Either like the random or round-robin director or using .list: director directorname dns { .list = { .host_header = "www.example.com"; .port = "80"; .connection_timeout = 0.4; "192.168.15.0"/24; "192.168.16.128"/25; } .ttl = 5m; .suffix = "internal.example.net"; } This will specify 384 backends, all using port 80 and a connection timeout of 0.4s. Options must come before the list of IPs in the .list statement. The .ttl denes the cache duration of the DNS lookups. The above example will append internal.example.net to the incoming Host header supplied by the client, before looking it up. All settings are optional. Backend probes Backends can be probed to see whether they should be considered healthy or not. The return status can also be checked by using req.backend.healthy .window is how many of the latest polls we examine, while .threshold is how many of those must have succeeded for us to consider the backend healthy. .initial is how many of the probes are considered good when Varnish starts defaults to the same amount as the threshold. A backend with a probe can be dened like this:: backend www { .host = "www.example.com"; .port = "http"; .probe = { .url = "/test.jpg"; 16

.timeout = 0.3 s; .window = 8; .threshold = 3; .initial = 3; } } It is also possible to specify the raw HTTP request: backend www { .host = "www.example.com"; .port = "http"; .probe = { # NB: \r\n automatically inserted after each string! .request = "GET / HTTP/1.1" "Host: www.foo.bar" "Connection: close"; } } ACLs An ACL declaration creates and initializes a named access control list which can later be used to match client addresses:: acl local { "localhost"; "192.0.2.0"/24; ! "192.0.2.23"; }

// myself // and everyone on the local network // except for the dialin router

If an ACL entry species a host name which Varnish is unable to resolve, it will match any address it is com pared to. Consequently, if it is preceded by a negation mark, it will reject any address it is compared to, which may not be what you intended. If the entry is enclosed in parentheses, however, it will simply be ignored. To match an IP address against an ACL, simply use the match operator:: if (client.ip ~ local) { return (pipe); } 17

Grace If the backend takes a long time to generate an object there is a risk of a thread pile up. In order to prevent this you can enable grace. This allows varnish to serve an expired version of the object while a fresh object is being generated by the backend. The following vcl code will make Varnish serve expired objects. All object will be kept up to two minutes past their expiration time or a fresh object is generated.: sub vcl_recv { set req.grace = 2m; } sub vcl_fetch { set beresp.grace = 2m; } Functions The following built-in functions are available: regsub(str, regex, sub) Returns a copy of str with the rst occurrence of the regular expression regex replaced with sub. Within sub, 0 (which can also be spelled &) is replaced with the entire matched string, and n is replaced with the contents of subgroup n in the matched string. regsuball(str, regex, sub) As regsuball() but this replaces all occurrences. purge url(regex) Purge all objects in cache whose URLs match regex. Subroutines A subroutine is used to group code for legibility or reusability:: sub pipe_if_local { if (client.ip ~ local) { return (pipe); } } Subroutines in VCL do not take arguments, nor do they return values. To call a subroutine, use the call keyword followed by the subroutines name: call pipe if local; There are a number of special subroutines which hook into the Varnish workow. These subroutines may inspect and manipulate HTTP headers and various other aspects of each request, and to a certain extent decide how the request should be handled. Each subroutine terminates by calling one of a small number of keywords which indi cates the desired outcome. 18

vcl recv Called at the beginning of a request, after the complete request has been received and parsed. Its purpose is to decide whether or not to serve the request, how to do it, and, if applicable, which backend to use. The vcl recv subroutine may terminate with one of the following keywords: error code [reason] Return the specied error code to the client and abandon the request. pass Switch to pass mode. Control will eventually pass to vcl pass. pipe Switch to pipe mode. Control will eventually pass to vcl pipe. lookup Look up the requested object in the cache. Control will eventually pass to vcl hit or vcl miss, depending on whether the object is in the cache. vcl pipe Called upon entering pipe mode. In this mode, the request is passed on to the backend, and any further data from either client or backend is passed on unaltered until either end closes the connection. The vcl pipe subroutine may terminate with one of the following keywords: error code [reason] Return the specied error code to the client and abandon the request. pipe Proceed with pipe mode. vcl pass Called upon entering pass mode. In this mode, the request is passed on to the backend, and the backends response is passed on to the client, but is not entered into the cache. Subsequent requests sub mitted over the same client connection are handled normally. The vcl pass subroutine may terminate with one of the following keywords: error code [reason] Return the specied error code to the client and abandon the request. pass Proceed with pass mode. vcl hash Use req.hash += req.http.Cookie or similar to include the Cookie HTTP header in the hash string. The vcl hash subroutine may terminate with one of the following keywords: hash Proceed. vcl hit Called after a cache lookup if the requested document was found in the cache. The vcl hit subroutine may terminate with one of the following keywords: error code [reason] Return the specied error code to the client and abandon the request. pass Switch to pass mode. Control will eventually pass to vcl pass. deliver Deliver the cached object to the client. Control will eventually pass to vcl deliver. vcl miss Called after a cache lookup if the requested document was not found in the cache. Its purpose is to decide whether or not to attempt to retrieve the document from the backend, and which backend to use. The vcl miss subroutine may terminate with one of the following keywords: error code [reason] Return the specied error code to the client and abandon the request. pass Switch to pass mode. Control will eventually pass to vcl pass. fetch Retrieve the requested object from the backend. Control will eventually pass to vcl fetch. vcl fetch Called after a document has been successfully retrieved from the backend. The vcl fetch subroutine may terminate with one of the following keywords: 19

error code [reason] Return the specied error code to the client and abandon the request. pass Switch to pass mode. Control will eventually pass to vcl pass. deliver Possibly insert the object into the cache, then deliver it to the client. Control will eventually pass to vcl deliver. esi ESI-process the document which has just been fetched. vcl deliver Called before a cached object is delivered to the client. The vcl deliver subroutine may terminate with one of the following keywords: error code [reason] Return the specied error code to the client and abandon the request. deliver Deliver the object to the client. If one of these subroutines is left undened or terminates without reaching a handling decision, control will be handed over to the builtin default. See the EXAMPLES section for a listing of the default code. Multiple subroutines If multiple subroutines with the same name are dened, they are concatenated in the order in which the appear in the source. Example:: # in file "main.vcl" include "backends.vcl"; include "purge.vcl"; # in file "backends.vcl" sub vcl_recv { if (req.http.host ~ "example.com") { set req.backend = foo; } elsif (req.http.host ~ "example.org") { set req.backend = bar; } } # in file "purge.vcl" sub vcl_recv { if (client.ip ~ admin_network) { if (req.http.Cache-Control ~ "no-cache") { purge_url(req.url); } } } The builtin default subroutines are implicitly appended in this way. Variables 20

Although subroutines take no arguments, the necessary information is made available to the handler subroutines through global variables. The following variables are always available: now The current time, in seconds since the epoch. The following variables are available in backend declarations: .host Host name or IP address of a backend. .port Service name or port number of a backend. The following variables are available while processing a request: client.ip The clients IP address. server.hostname The host name of the server. server.identity The identity of the server, as set by the -i parameter. If the -i parameter is not passed to varnishd, server.identity will be set to the name of the instance, as specied by the -n parameter. server.ip The IP address of the socket on which the client connection was received. server.port The port number of the socket on which the client connection was received. req.request The request type (e.g. GET, HEAD). req.url The requested URL. req.proto The HTTP protocol version used by the client. req.backend The backend to use to service the request. req.backend.healthy Whether the backend is healthy or not. req.http.header The corresponding HTTP header. The following variables are available while preparing a backend request (either for a cache miss or for pass or pipe mode): bereq.request The request type (e.g. GET, HEAD). bereq.url The requested URL. bereq.proto The HTTP protocol version used to talk to the server. bereq.http.header The corresponding HTTP header. bereq.connect timeout The time in seconds to wait for a backend connection. bereq.rst byte timeout The time in seconds to wait for the rst byte from the backend. Not available in pipe mode. bereq.between bytes timeout The time in seconds to wait between each received byte from the backend. Not available in pipe mode. The following variables are available after the requested object has been retrieved from the backend, before it is entered into the cache. In other words, they are available in vcl fetch: beresp.proto The HTTP protocol version used when the object was retrieved. beresp.status The HTTP status code returned by the server. beresp.response The HTTP status message returned by the server. beresp.cacheable True if the request resulted in a cacheable response. A response is considered cacheable if it is valid (see above), and the HTTP status code is 200, 203, 300, 301, 302, 404 or 410. beresp.ttl The objects remaining time to live, in seconds. After the object is entered into the cache, the following (mostyl read-only) variables are available when the object has been located in cache: obj.proto The HTTP protocol version used when the object was retrieved. obj.status The HTTP status code returned by the server. obj.response The HTTP status message returned by the server. 21

obj.cacheable True if the request resulted in a cacheable response. A response is considered cacheable if it is valid (see above), and the HTTP status code is 200, 203, 300, 301, 302, 404 or 410. obj.ttl The objects remaining time to live, in seconds. obj.lastuse The approximate time elapsed since the object was last requests, in seconds. obj.hits The approximate number of times the object has been delivered. A value of 0 indicates a cache miss. The following variables are available while determining the hash key of an object: req.hash The hash key used to refer to an object in the cache. Used when both reading from and writing to the cache. The following variables are available while preparing a response to the client: resp.proto The HTTP protocol version to use for the response. resp.status The HTTP status code that will be returned. resp.response The HTTP status message that will be returned. resp.http.header The corresponding HTTP header. Values may be assigned to variables using the set keyword:: sub vcl_recv { # Normalize the Host: header if (req.http.host ~ "^(www.)?example.com$") { set req.http.host = "www.example.com"; } } HTTP headers can be removed entirely using the remove keyword:: sub vcl_fetch { # Dont cache cookies remove beresp.http.Set-Cookie; } EXAMPLES The following code is the equivalent of the default conguration with the backend address set to backend.example.com and no backend port specied:: backend default { .host = "backend.example.com"; .port = "http"; } sub vcl_recv { if (req.http.x-forwarded-for) { set req.http.X-Forwarded-For = req.http.X-Forwarded-For ", " client.ip; } else { 22

set req.http.X-Forwarded-For = client.ip; } if (req.request != "GET" && req.request != "HEAD" && req.request != "PUT" && req.request != "POST" && req.request != "TRACE" && req.request != "OPTIONS" && req.request != "DELETE") { /* Non-RFC2616 or CONNECT which is weird. */ return (pipe); } if (req.request != "GET" && req.request != "HEAD") { /* We only deal with GET and HEAD by default */ return (pass); } if (req.http.Authorization || req.http.Cookie) { /* Not cacheable by default */ return (pass); } return (lookup); } sub vcl_pipe { # Note that only the first request to the backend will have # X-Forwarded-For set. If you use X-Forwarded-For and want to # have it set for all requests, make sure to have: # set req.http.connection = "close"; # here. It is not set by default as it might break some broken web # applications, like IIS with NTLM authentication. return (pipe); } sub vcl_pass { return (pass); } sub vcl_hash { hash_data(req.url); if (req.http.host) { hash_data(req.http.host); 23

} else { hash_data(server.ip); } return (hash); } sub vcl_hit { if (!obj.cacheable) { return (pass); } return (deliver); } sub vcl_miss { return (fetch); } sub vcl_fetch { if (!beresp.cacheable) { return (pass); } if (beresp.http.Set-Cookie) { return (pass); } return (deliver); } sub vcl_deliver { return (deliver); } sub vcl_error { set obj.http.Content-Type = "text/html; charset=utf-8"; synthetic {" <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html> <head> <title>"} obj.status " " obj.response {"</title> </head> 24

<body> <h1>Error "} obj.status " " obj.response {"</h1> <p>"} obj.response {"</p> <h3>Guru Meditation:</h3> <p>XID: "} req.xid {"</p> <hr> <p>Varnish cache server</p> </body> </html> "}; return (deliver); } The following example shows how to support multiple sites running on separate backends in the same Varnish instance, by selecting backends based on the request URL:: backend www { .host = "www.example.com"; .port = "80"; } backend images { .host = "images.example.com"; .port = "80"; } sub vcl_recv { if (req.http.host ~ "^(www.)?example.com$") { set req.http.host = "www.example.com"; set req.backend = www; } elsif (req.http.host ~ "^images.example.com$") { set req.backend = images; } else { error 404 "Unknown virtual host"; } } The following snippet demonstrates how to force a minimum TTL for all documents. Note that this is not the same as setting the default ttl run-time parameter, as that only aects document for which the backend did not specify a TTL::: 25

sub vcl_fetch { if (beresp.ttl < 120s) { set beresp.ttl = 120s; } } The following snippet demonstrates how to force Varnish to cache documents even when cookies are present:: sub vcl_recv { if (req.request == "GET" && req.http.cookie) { return(lookup); } } sub vcl_fetch { if (beresp.http.Set-Cookie) { return(deliver); } } The following code implements the HTTP PURGE method as used by Squid for object invalidation:: acl purge { "localhost"; "192.0.2.1"/24; } sub vcl_recv { if (req.request == "PURGE") { if (!client.ip ~ purge) { error 405 "Not allowed."; } return(lookup); } } sub vcl_hit { if (req.request == "PURGE") { set obj.ttl = 0s; 26

error 200 "Purged."; } } sub vcl_miss { if (req.request == "PURGE") { error 404 "Not in cache."; } } 5.1.1 Manipulao de cabealho HTTP ca c

No exemplo a seguir removido o cookie para todos os objetos no diretrio e o /images do servidor web. sub vcl_recv { if (req.url ~ "^/images") { unset req.http.cookie; } } Quando o pedido processado no servidor back-end no haver cabealho de e a a c cookie. A linha interessante aquele com a instruo if. Ele compara a URL, e ca tirada do objeto do pedido, com a expresso regular. Note a correspondncia do a e operador, se corresponder ao Cookie, o cabealho do pedido unset (exclu c e do). 5.1.2 Manipulando o parmetro HTTP: beresp a

Neste exemplo altera-se o TTL Time To Live, de um objeto vindo do servidor se corresponder a determinados critrios: e sub vcl_fetch { if (beresp.url ~ "\.(png|gif|jpg)$") { unset beresp.http.set-cookie; set beresp.ttl = 3600; } } 5.1.3 Access Control List ACLs

Na utilizao de Access Control List, destina-se uma palavra-chave que dene a ca ACL. Ento combina-se atravs de operadores lgicos, o endereo IP do cliente a e o c contra uma ACL, com o propsito de ocorrer uma equivalncia. o e 27

acl local { "localhost"; "192.168.1.0"/24; /* and everyone on the local network */ ! "192.168.1.23"; /* except for the dialin router */ } sub vcl_recv { if (req.request == "PURGE") { if (client.ip ~ local) { return(lookup); } } } sub vcl_hit { if (req.request == "PURGE") { set obj.ttl = 0s; error 200 "Purged."; } } sub vcl_miss { if (req.request == "PURGE") { error 404 "Not in cache."; } }

Congurao para o Servidor Back-end ca

Em alguns casos a h necessidade de congurar o servidor cache-proxy para a servir contedo para vrios servidores back-end. No Varnish poss atravs u a e vel e de mapeamento de URL, podendo ser congurado apenas um ou mltiplos u servidores back-end. Considere que ser introduzido uma aplicao Java em um s PHP, e que a ca tio esta aplicao Java deve manipular URL iniciada com /java/. ca No arquivo de congurao original default.vcl, encontra-se a congurao ca ca padro, rodando na porta 8080, algo como o trecho abaixo: a backend default { .host = "127.0.0.1"; 28

.port = "8080"; } Agora para acrescentar o back-end Java, rodando na mesma mquina, a entretanto, na porta 8000, adiciona-se o seguinte trecho: backend java { .host = "127.0.0.1"; .port = "8000"; } Agora utilizando a linguagem VCL, congura-se a sub-rotina, vcl recv, para tratar todas as requisioes URL, que iniciarem com o padro /java/, as c a desviando para o back-end java, e as outras para o back-end default. sub vcl_recv { if (req.url ~ "^/java/") { set req.backend = java; } else { set req.backend = default. } } Utilizando a mesma lgica aplicada para desviar as requisies que continham o co /java/, em suas URL, pode-se usar ACL em VCL para desviar dispositivos moveis, como palms, e celulares para um back-end especico. ex: if (req.User-agent /mobile/).

6.1

Diretivas

H a possibilidade de aglomerar vrios back-end em grupos. Esses grupos so a a a chamados os diretivas (Directors). Isto lhe dar maior desempenho e resilincia, a e pois pode ser agregado vrias infra-estruturas, agrupadas em uma unica a diretiva. backend server1 { .host = "192.168.0.10"; } backend server2{ .host = "192.168.0.10"; } 29

director example_director round-robin { # server1 { .backend = server1; } # server2 { .backend = server2; } # foo } Exemplo acima, de diretiva com balanceamento round-robin, distribui as requisioes recebidas; h tambm como congurar diretivas para distribuio c a e ca randmica de requisioes. o c

6.2

Alta disponibilidade

O Varnish tambm pode monitorar o back-end, direcionado as requisies e co somente para o servidor ativo. Abaixo um exemplo de diretiva com dois back-ends e vericao de estado. ca Primeiro a denio dos back-ends: ca backend server1 { .host = "server1.example.com"; .probe = { .url = "/"; .interval = 5s; .timeout = 1s; .window = 5; .threshold = 3; } } backend server2 { .host = "server2.example.com"; .probe = { .url = "/"; .interval = 5s; .timeout = 1s; .window = 5; .threshold = 3; 30

} } O Varnish vericar a sade, ou estado, de cada back-end, atravs do a u e parmetro probe. Suas opoes so: a c a url Que URL o varnish deve requisitar interval Intervalo de atualizao do poll ca timeout O timeout da sonda window Quantas imagens o Varnish manter na janela deslizante, a neste caso cinco threshold Quantas imagens boas so consideradas para que o backa end seja declarado saudvel a initial Quantas vericaoes em bom estado, sero executadas ao c a iniciar o Varnish - o padro a mesma quantia do threshold. a e Abaixo a denio da diretiva para vericao de estado dos back-ends: ca ca director example_director round-robin { { .backend = server1; } # server2 { .backend = server2; } } O Varnish no ir enviar o trfego para hosts que so marcados como unhealty, a a a a ou inativo; tambm pode servir contedo obsoleto se todos os back-ends e u estiverem inativos, detalhes podem ser lidos na documentao ocial (5), ou na ca seo 6.3 deste documento. ca

6.3

Tunning back-end com Varnish

Uma caracter stica chave do Varnish, a sua capacidade de proteger a e integridade dos servios fornecidos, contra a instabilidade causada pelo mau c comportamento de servidores ou aplicaoes. c Esta proteo contra a instabilidade pode ser congurada em dois modos: ca Grace ou Saint.

31

6.3.1

Grace mode

Quando vrios clientes requisitam o mesmo contedo ao Varnish, ele enviar a u a apenas uma requisio ao servidor back-end, e manter todas as outras ca a requisioes em espera(wait). Ao receber o resultado da requisio, c ca automaticamente envia uma copia do contedo a todas as requisioes cliente, u c que estavam em espera. Se o servio recebe milhares de acessos por segundo, essa la pode car c enorme. E ningum gosta de esperar, e no Varnish h a possibilidade de servir e a contedo obsoleto em vez de se ter usurios esperando. u a Na pratica isto feito, acrescentando uma instruo VCL orientando o Varnish e ca a manter os objetos em cache alm de seus TTL ( Time To Live) original. e Assim, para manter todos os objetos por 30 minutos alm do seu TTL, usa-se a e seguinte instruo VCL: ca sub vcl_fetch { set beresp.grace = 30m; } Alm da instruo de manter o TTL 30 minutos alm do original, necessrio e ca e e a informar ao Varnish que deve aceitar estes objetos nas requisies, para isto o co cdigo abaixo, orienta a servir os objetos antigos por 15 segundos: o sub vcl_recv { set req.grace = 15s; } Porque manter os objetos em cache por mais 30 minutos, se no h a a oportunidade de servi-los? Bem, se o controle de estado for habilitado, o Varnish vericar o estado do servidor, e disponibilizar o contedo por mais a a u tempo se o back-end estiver indispon vel. if (! req.backend.healthy) { set req.grace = 5m; } else { set req.grace = 15s; } 6.3.2 Saint mode

Algumas vezes alguns servidores se comportam de forma estranha, apresentando erros aleatrios. O Varnish pode ser congurado para tratar esta o situao de uma maneira mais graciosa, denominada Saint mode. Este modo ca 32

permite descartar determinadas paginas indesejadas de um back-end, e tentar buscar o contedo em outro servidor, se possivel, se no apresentar o u a a contedo antigo armazenado em cache. u Este recurso habilitado com o seguinte cdigo VCL: e o sub vcl_fetch { if (beresp.status == 500) { set beresp.saintmode = 10s; restart; } set beresp.grace = 5m; } Quando o beresp.saintmode congurado por 10 segundos, o Varnish no ir e a a vericar a URL por 10 segundos, como se o back-end fosse colocado em quarentena, uma espcie de blacklist. Se houver outros back-ends capazes de e servir o contedo o Varnish tentar neles. Quando todos os back-ends u a estiverem inativos o Varnish ir servir o contedo antigo armazenado em cache. a u

Referncias e
[1] VARNISH. Varnish Cache. nov 2010. Dispon em: <http://www.varnishvel cache.org/>. Acesso em: 07 dez 2010. [2] IEFT, I. E. T. F. Hypertext Transfer Protocol HTTP/1.1. jun 1999. RFC4949. Dispon em: <http://tools.ietf.org/html/rfc2616>. Acesso em: vel 22 dez 2010. [3] HERRMAN. HTTP. [S.l.: s.n.], 1997. Apud (7). [4] RS compute. Hardware utilizado no armazenamento de backup e recuperao. ca dez 2010. Hardware utilizado no armazenamento de backup e recuperao. ca Dispon em: <http://www.compute-rs.com/pt/conselho-1556281.htm>. vel Acesso em: 10 dez 2010. [5] CACHE varnish. Misbehaving servers. dez 2010. Misbehaving servers. Dispon vel em: <http://www.varnish-cache.org/ docs/2.1/tutorial/handling_misbehaving_servers.html# tutorial-handling-misbehaving-servers>. Acesso em: 17 dez 2010.

33

[6] AGUIAR, A. S. Varnish: Uma camada de velocidade. mai 2010. Dispon vel em: <http://www.vivaolinux.com.br/artigos/impressora.php?codigo=11480>. Acesso em: 07 dez 2010. [7] LEANDRO, F. et al. Hypertext Transfer Protocol. nov 2010. Dispon em: vel <http://pt.wikipedia.org/wiki/Hypertext_Transfer_Protocol>. Acesso em: 22 dez 2010. [8] VARNISH. General questions. dez 2010. Dispon vel <http://www.varnish-cache.org/docs/2.1/faq/general.html#what-isvarnish>. Acesso em: 07 dez 2010. [9] VARNISH. Releases Varnish. mai 2010. Dispon vel <http://www.varnish-cache.org/releases>. Acesso em: 07 dez 2010. em:

em:

34