Varnish Cache – Servidor de Proxy Reverso com Cacheamento
O Squid é sem dúvida um dos mais poderosos e completos sistemas de caching proxy do mercado. Para nossa sorte, é livre e conhecido por funcionar muito bem no FreeBSD. O Squid é utilizado frequentemente como servidor de procuração e cacheamento de dados servindo uma rede ou algumas estações, para acesso à grande rede. Mas o Squid também é projetado para atuar como Reverse Proxy com cacheamento. Um servidor de procuração reverso funciona de forma similar a um servidor de procuração convencional, mas ao invés de atender uma rede pré-conhecida ou uma estação, atende a toda Internet, mas seu target de procuração e cacheamento é normalmente apenas um (ou alguns) servidor(es) Web. Por isso é denominado proxy reverso, pois faz a procuração para acesso e cache de servidores Web pré-conhecidos. Por exemplo, imagine que você entre em um site na Web, como http://www.freebsd.org ou http://www.fug.com.br. Normalmente espera-se que quem atenda sua requisição HTTP/1.0 ou superior seja o servidor Web desses sites. Se um proxy reverso existir, sua requisição será atendida por este proxy, e não pelo servidor Web. O objetivo é aliviar a carga do servidor Web e poder oferecer à diversos clientes acessando o site ao mesmo tempo o mesmo conteúdo, resultado do processamento único realizado pelo Web server, ao invés de exigir que o próprio servidor http cuide de processar esse site.
À primeira vista o uso de um proxy reverso parece não ter grandes vantagens, especialmente porque o consumo de banda, observado por alguns como a grande vantagem de uso de um servidor de procuração, não existirá, já que, sendo transmitido do servidor Web ou do proxy, a demanda de largura de banda dos dados será a mesma. Correto, mas esse é o único ponto onde o proxy reverso não apresenta vantagens. Em grandes sites e principalmente em sites com conteúdo essencialmente dinâmico, o custo mais relevante não é banda, mas sim recursos computacionais e atendimento paralelo à requisições Web. Apesar de servidores como Apache serem extremamente robustos e atender seguramente a demanda de requisições paralelas, a questão de desempenho é afetada devido à necessidade de sites dinâmicos ter que ser processados sempre, toda vez, para cada requisição Web feita.
Tendo em vista esta grande demanda de recursos de processamento, o próprio Apache já tem seu módulo de proxy reverso, inclusive com algum suporte à cacheamento de objetos. E não é só. Linguagens popularmente usadas em ambiente livre como php tem versões de aceleradores de objetos. São sistemas livres e proprietários, todos com o mesmo objetivo: acelerar o processamento de conteúdo gerado dinâmicamente. Mas esses aceleradores não são de propósito geral. Por exemplo, não existe acelerador que funcione bem para PHP, Java e Perl ao mesmo tempo. Pior ainda se há um servidor com ASP no ambiente Web em questão. Nesses casos o proxy reverso é a solução mais indicada.
Mas os dias de hegemonia do Squid, atuando como proxy reverso e sendo unanimidade de opções para tal função, estão contados. Pelo menos é o que promete a VG Multimedia e o Grupo de Usuários Unix da Noruega. Segundo a VG Multimedia, empresa de produção áudio-visual da Noruega, o Squid atuando como Reverse Proxy se apresentou limitado demais em performance, por uma série de motivos incluindo não fazer uso apropriado de várias tecnologias disponíveis em sistemas computacionais modernos. O módulo de proxy reverso do Apache também não se mostrou satisfatório em ambiente de grande demanda. Essas averiguações já foram constatadas por grandes provedores de conteúdo dinâmico. O Yahoo! por exemplo usa uma solução de Proxy Reverso própria. No Brasil alguns dos maiores provedores de conteúdo usam o Netapp ou similar, de fabricantes como Sun Microsystems, IBM ou outras empresas.
Mas no mundo livre, a melhor opção até então era mesmo o Squid, atuando em um ambiente para o qual ele não foi originalmente projetado. Recentemente a VG Multimedia, grupo responsável pelo maior jornal publicado no país e o Grupo de Usuários Unix da Noruega e da empresa de Consultoria em Linux, Linpro, se uniram para financiar a criação de um novo projeto: o Varnish Cache. E os resultados já estão aí: em um benchmark recente comparando Varnish com Squid usando diskd(8) como proxy reverso, Varnish apresentou 600% mais performance que o Squid. O motivo, segundo seus desenvolvedores, é simples: código. Varnish utiliza racionalmente técnicas como Copy-On-Write e o uso do sendfile(2). Evita chamadas de sistema onde não é impossível deixar de usá-las, e introduz um novo algorítimo de cacheamento de objetos dinâmicos. Os detalhes internos das diferenças de codificação usadas podem ser acompanhados em um vídeo recente com palestra técnica sobre o Varnish Cache. Varnish tem ainda mais vantagens. Ele é capaz de cachear conteúdo considerado não-cacheável por outros sistemas. Incluíndo dados protegidos por senha.
O ambiente de desenvolvimento e uso em produção do Varnish Cache é FreeBSD, especificamente FreeBSD 6 -STABLE e 7 -CURRENT. O único Linux utilizado durante o desenvolvimento, para garantir compatibilidade com o kernel Linux é o Ubuntu Dapper. Isso porquê os desenvolvedores do Varnish são velhos conhecidos da comunidade FreeBSD. O desenvolvedor chefe é Poul-Henning Kamp e o líder do Projeto é Dag-Erling Smøgrav. Ambos commiters FreeBSD. A licença do Varnish é Licença BSD de dois cláusulas.
Se você ficou curioso e quer saber mais sobre o Varnish, vai gostar de saber que mesmo antes de ser oficialmente lançado, já estava disponível na Coleção de Ports do FreeBSD, em /usr/ports/www/varnish. Vai querer também assistir ao vídeo de apresentação técnica do Varnish , incluindo discussões sobre implementações internas e algorítimos escolhidos e criados para o Varnish, ou talvez ouvir a apresentação em mp3. Como é um novo esforço, a documentação do Varnish ainda é pouca, mas um bom começo pode ser observado aqui.
Apenas para não gerar confusão, é importante deixar claro que o Varnish não é feito para atuar como um proxy convencional, tão pouco para substituir o Squid ou qualquer outro proxy a não ser exclusivamente atuando na função de proxy reverso.
Fonte: http://www.fug.com.br/