Varnish cache
-
Upload
lincolm-aguiar -
Category
Internet
-
view
25 -
download
0
Transcript of Varnish cache
Varnish CacheImplementação no clicRBS
Agenda
O projeto Varnish Cache
A implementação no clicRBS
Configuração
Alta disponibilidade e performance
Monitoramento
Logs
Extensões via VMODs
O Projeto Varnish Cache
O Projeto Varnish Cache
Iniciado por Poul-Henning Kamp, desenvolvedor líder no tabloide norueguês Verdens Gang. Teve a primeira versão publicada em 2006.
Criado na linguagem C sob a licença BSD (Bekerley Software Distribution).
Está na versão 4.0, no clicRBS usamos a versão 3.0.4 (em Maio/2014).
Utilizado por grandes empresas de conteúdo, dentre elas BBC e Globo.com
Tem versão open source (via varnish-cache.org) e comercial via a empresa Varnish Cache (varnish-cache.com)
Por que o Varnish?
1. Open Source
1. Iniciativas de tornar o clicRBS viável com produtos open source;
2. Confiabilidade
1. Precisava ter a confiabilidade conquistada pelo Oracle WebCache;
3. Fácil configuração
1. A equipe de infra não poderia ter que seguir processos para implementar modificações no cache
4. Otimizado para sistemas Linux
1. Os servidores do clicRBS são Linux, a implementação do HTTP Cache teria que ter aderência primária para essa plataforma de sistema operacional.
Implementação no clicRBS
Requisitos para o clicRBS
Oracle WebCache como servidor de cache primário, o Varnish precisa “comportar-se” como WebCache para os mecanismos de entrega e invalidação.
Por mecanismos de entrega, entenda Caixa Cisco.
Por mecanismos de invalidação, entenda Vinas.
As aplicações usam recursos direcionados para o WebCache, como o suporte a tags ESI, o Varnish precisa usar o mesmo dialeto para processar as mesmas tags ESI.
Requisitos do Varnish no clicRBS
Vinas
Persistência de sessão
HTTPS
O VARNISH NÃOSUPORTA SSL
Invalidações de conteúdo
O Varnish suporta dois tipos de invalidação:
Por parão de URL
Por URL completa
Invalidar o quê?
Invalidações de conteúdo
Quando você invalida um conteúdo em um HTTP Cache, o que você espera atingir?
Como você notifica aos milhares, ou milhões, de usuários navegando em seu site que o conteúdo foi expirado no cache?
Seu site tem uma política de cache de conteúdo alinhada com o que fica no cliente e o que não pode ficar?
Para o conteúdo que fica no cliente, quando fazer “conditional get”?
Você pensa no consumo de banda do usuário do seu site quando você usa “don´t cache” no servidor de HTTP Cache?
Invalidações....
Dados...
Os sites do clicRBS passaram a ser servidos por apenas servidores Varnish em 17 de Abril de 2014. Desde essa data não havia nenhuma entrega por Oracle WebCache;
De 17 de Abril de 2014 a 29 de Abril de 2014 o clicRBS ficou sem NENHUM mecanismo de invalidação de cache ativo. O mecanismo existia, mas não estava configurado.
O mecanismo de invalidação de cache foi configurado no clicRBS em 29 de Abril de 2014, mas continua ate hoje desligado o mecanismo de invalidações automáticas para conteúdos. O mecanismo automático não mais será ativado!
Log de requisições
O Varnish precisava ter suporte a log de requisições usando o formato Apache Common Format.
Usamos os logs de acesso nos sites para envio para o IVC.
Configuração
Configuração
Usamos a versão 3.0.4 do Varnish compilando a partir do fonte.
A compilação permite a customização de diretórios de instalação e configuração.
Linguagem de configuração do Varnish: VCL – Varnish Configuration Language
Configuração - VCL
VCL
O Varnish é configurado via sua linguagem de descrição de configuração;
A sintaxe parece com uma estrutura json com definição de rotinas;
Há uma ordem de execução das rotinas, como mostrado no slide anterior;
A configuração é sobre-escrita apenas no ponto de modificação.
A linguagem trabalha com tipos próprios e não contém estruturas completas de uma linguagem de programação (por isso é de configuração!).
VCL
A solicitação inicia na rotina vcl_recv.
O documento pode ser lido do cache (lookup) ou diretamente do servidor (pass ou miss).
Quando a estratégia lookup é selecionada, a rotina vcl_hash cria o identificador único da URL para que o Varnish possa localizar o conteúdo no cache.
O documento retornado do servidor pode “informar” ao varnish para não reter aquela cópia em cache.
O Varnish trata a solicitação via a rotina vcl_deliver antes de entregar a resposta ao cliente.
Definições de VCL
- Um backend é, para o Varnish, o servidor de origem que contém a página.
- Sendo o Varnish um proxy reverso, ele irá buscar o conteúdo em um servidor, caso o conteúdo não esteja com ele.
- Um backend tem as propriedades:
- Host: identificação de rede do backend
- Port: qual porta atende o serviço
- Probe: como validar se o serviço no backend está funcionando.
- Múltiplos backends podem agir com um só em uma configuração denominada director.
BACKEND
Definições de VCL
- ACL é Access Control List. O Varnish permite criar restrições de acesso para recursos, seja por qual informação for.
- Usamos ACL no Varnish para que ele aceite invalidações pelos servidores do CMS.
- Podemos implementar ACLs para restringir um conteúdo a apenas acessos internos, por exemplo.
- A verificação é feita por VCL, logo é possível usar qualquer atributo da solicitação, da URL à cabeçalhos HTTP, por exemplo.
ACL
Definições de VCL
- Probe é um atributo de um backend.
- O Varnish não “deixa” o usuário saber que um servidor está com problemas. Ele usa as definições de probe, para de forma pró-ativa, verificar os backends. Os backends inaptos não recebem solicitações dos usuários.
PROBE
Definições de VCL
- O Varnish usa três escopos de cache:
- LOOKUP: o documento deverá ser lido do cache, caso não exista, será lido no servidor e armazenado no cache. O tempo de armazenado é definido pelo cabeçalho Cache-Control, ou na sua ausência, pela diretiva de DEFAULT_TTL.
- PASS: o documento será entregue do cache, mas será antes buscado no servidor de aplicações. O cache age como um buffer.
- PIPE: o documento será entregue diretamente do servidor, sem usar a estrutura de cache e fail over.
ESCOPO DE CACHE
Definições de VCL
- Rotina responsável por iniciar o processamento da solicitação.
- Nela são tomadas as decisões para:
- Diferenciação mobile;
- Seleção de backend;
- Estratégia de cache;
- Redefinição de informações de solicitação etc.
vcl_req
Definições de VCL
- Rotina responsável por criar o identificador único da URL para o cache.
- Utilizamos vcl_hash para distinguir documentos com e sem paywall no clicRBS. vcl_hash
Definições de VCL
- Rotina responsável por buscar, por isso fetch, o documento no servidor de aplicações.
- Permite a customização da solicitação para o servidor de aplicações, bem como permite a configuração de como o varnish irá servir o documento (se do cache ou não, com gzip ou não, com esi ou não).
- Usamos vcl_fetch no clic para habilitar o suporte a ESI através do cabeçalho Surrogate-Control
- Também usamos no vcl_fetch a instrução de ignore cache no Varnish de acordo com o cabeçalho Surrogate-Control.
vcl_fetch
Definições de VCL
- Rotina responsável por tratar a resposta para o usuário removendo informações que julgamos desnecessárias, dentre elas temos os cabeçalhos:
- Surrogate-Control: contém dialeto Oracle WebCache
- Server: exposição desnecessária da implementação do servidor de aplicações;
- Content-Location: exposição desnecessária da localização de recursos no servidor abaixo das URLs amigáveis.
- Cabeçalhos de controle de cache: usamos três cabeçalhos de controle de cache que permitem a invalidação pelo vinas.
vcl_deliver
Definições de VCL
- O Varnish permite definir rotinas customizadas. Usamos isso para implementar a identificação de mobile. Hoje identificamos os dispositivos:
- iPhone, iPad, tablet Android, phone Android, Firefoxos, bots, mobile smartphone (que não seja Android nem iOS) e mobile genéric (telefone com WAP).
rbs_mobile
Tempo de vida em cache
O Varnish usa o cabeçalho Cache-Control, enviado pelo servidor de aplicações, para controlar o tempo de vida do documento em cache.
O header Age é gerado pelo Varnish para que o navegador possa calcular corretamente o tempo que o objeto pode ser considerado válido.
O Varnish NÃO modifica cabeçalhos da requisição SENÃO por definição no VCL. Usamos no clic a inclusão do cabeçalho Cache-Control via VCL para SOMENTE as páginas que não o definem e, com isso, caem na regra de DEFAULT_TTL.
Alta disponibilidade
Alta disponibilidade
A alta disponibilidade de entrega no Varnish é feita via três mecanismos de garantia de entrega:
1. Probe: o mecanismo principal para garantir que o Varnish não encaminhe a solicitação para um servidor que não está apto a fazer entregas;
2. Director: um director é uma composição de backends, tal que o Varnish lida com todos como se fossem um só. Via Director é possível implementar mecanismos de seleção sendo round-robin, round, random, fallback, cliente e dns.
3. Saint-mode: O mecanismo saint-mode apenas está disponível na configuração do tipo Director. Nela o Varnish valida a resposta do servidor, se for inadequada, o varnish repete a solicitação em outro servidor, sem interação com o usuário.
Probe
probe hc_it_80 {.request = "HEAD /rs/jsp/probe.jspx HTTP/1.1“
"Host: zerohora.clicrbs.com.br“"User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64;
rv:21.0) Gecko/20100101 Firefox/21.0“"Connection: close";
.interval = 10s;
.timeout = 0.5s;
.window = 9;
.threshold = 3;}
Director
backend enzo_7779 {
.host = "enzo.rbs.com.br";
.port = “7779";
.probe = hc_it_80;
}
director it_80 round-robin {
{ .backend = enzo_7779; }
{ .backend = jaguar_7779; }
{ .backend = lincolm_7779; }
{ .backend = bentley_7779; }
}
Saint-mode
sub vcl_fetch {
(...)
//Saint Mode for 10 seconds
if (beresp.status >= 500) {
set beresp.saintmode = 10s;
return(restart);
}
return(deliver);
}
Monitoramento
Monitoramento
O Varnish usa monitoramento ativo e tão efetivo que é possível assumir um comportamento reativo antes mesmo que os usuários no site comecem a perceber algum erro.
Via a api varnishadm o Varnish exporta dados de execução do runtime para que possam ser analisadas por mecanismos de acompanhamento de disponibilidade como Zabbix, por exemplo.
A api Varnishlog expõe com nível de detalhamento de mensagem de rede, como foi a verificação de disponibilidade do servidor de backend.
varnishlog
0 Backend_health - wp_clicrbs_com_br_80[1] Still sick 4--X-R- 0 3 9 0.640206 0.000000 HTTP/1.1 404 Not Found
0 Backend_health - www_clicrbs_com_br_80[0] Still healthy 4--X-RH 9 3 9 0.004539 0.004548 HTTP/1.1 301 Moved Permanent
Extensões do Varnish
VMODs (Varnish Modules)
O Varnish permite customização de configurações via inclusão de módulos compiláveis, escritos na linguagem C.
A instalação padrão traz o vmod std que contém rotinas utilitárias.
Os projetos de vmods são mantigos no github
Para compilar um vmod você só precisa do fonte do Varnish e baixar, ou criar o seu próprio fonte do vmod.
Performance
Performance
Havia um grande receio de o Varnish não suportar a carga que era entregue pelos servidores de Oracle WebCache.
Fizemos um trabalho de publicar uma máquina de Varnish por vez, medindo sempre a resposta e comparando com os Oracle WebCaches.
Não havia máquina disponível para “subir” ao lado, então a instalação no clicRBS consistiu de retira um servidor de Oracle WebCache, remove tudo, instala e configura o Varnish e sobe novamente o servidor.
Foi catastrófico....para o Oracle WebCache
Estatísticas via APIs Open Source
VARNISHSTAT
Consumo de CPU com Varnish
Somente Oracle WebCache
Aqui, tiramos a máquina para remover o Oracle WebCache e instalar o Varnish. Mantemos o SO.
Somente o Varnish
Lincolm AguiarGrupo RBS
Obrigado!