Por Jennifer Vesperman - 17/09/2001
Um cache Squid pode ser configurado para verificar com outros servidores Squid (seus pares) por páginas web cacheadas antes de ir direto para a página solicitada. Agrupar os seus caches Squid pode resultar em respostas mais rápidas e menores custos. Os caches agrupados trocam objetos de cache, retornando os mesmos aos usuários mais rapidamente e reduzindo os custos de banda de passagem para a Internet.
O Squid primeiro procura por objetos em seu próprio cache. Se o objeto não está em cache, então o Squid deverá recuperar o mesmo de outra origem. Para supersimplificar o algoritmo: O Squid cria uma lista ordenada de possíveis fontes.
Esta lista consiste dos pais (parents), irmãos (siblings) e o servidor de origem. O Squid tenta recuperar o objeto de cada servidor em ordem até que obtém sucesso, um servidor responda com um erro 404 (objeto não encontrado), ou não haja mais fontes para tentar.
Controles de acesso e consultas ICP alteram a lista usando as seguintes regras:
never_direct proibem o Squid de contatar o
servidor de origem diretamente, o Squid remove o mesmo da lista.
allways_direct exigem que o Squid use o
servidor de origem, o Squid remove todos os outros pares da lista.
cache_peer_access proíbe um determinado par de
fazer solicitações para este objeto, o par é removido da lista.
Os caches pares precisam informar uns aos outros quais objetos encontram-se em seus caches. O ICP e o HTCP permitem consultas e respostas instantâneas. Digests são imagens do que está atualmente no cache.
O Squid normalmente utiliza o protocolo ICP para fazer a comunicação entre caches, e pode usar o HTCP se ambos os caches estão configurados para isto. O ICP e o HTCP são suficientemente similares para que, a menos que for dito o contrário, este artigo use o ICP para descrever ambos.
Artigos relacionados:
Quando o Squid recebe uma solicitação por um objeto que não está em cache,
ele envia um pacote de consulta ICP para cada um de seus pares configurados.
Se pelo menos um deles informar que tem o objeto, o Squid solcita o objeto
daquele que for o mais rápido dos que responderam. Se todos os pares
responderem "não" ou não responderem antes do tempo de timeout configurado, o
Squid solicita o objeto da origem ou falha, dependendo das configurações de
never_direct.
O ICP utiliza pacotes UDP untracked. Já que pacotes UDP untracked podem ser perdidos, descartados, ou danificados, o Squid utiliza um valor de timeout. Qualquer consulta que não for respondida neste tempo é assumida como perdida, e o Squid descarta estes pares de sua lista para a consulta.
O Squid utiliza um timeout ICP dinâmico por padrão, mas isto pode ser
sobrescrito com icp_query_timeout ou limitado por
icp_maximum_query_timeout se você achar que os valores que o
Squid calcula não sejam os valores ótimos para seu ambiente.
Um digest de cache é um bloco de chaves URI que representam o conjunto de objetos que o cache mantém. As URIs são passadas através de um algoritmo determinístico que compacta os dados e gera as chaves. Os digests são trocados com pares que possuem a capacidade de tratar digests, e são usados para determinar se um par pode ter um objeto que tenha sido requisitado.
Os digests estão sujeitos a falsos hits e fasos misses (um hit acontece quando um objeto é encontrado no cache, e um miss acontece quando um objeto não é encontrado no cache), dependendo da freqüência com que é feita a troca, mas elas reduzem o tráfego imediato e são úteis se a largura de banda entre os caches é pequena ou não confiável.
Use um cache pai se você quer reduzir os custos de upstream e tornar a coleta de páginas mais rápidas para seus computadores, especialmente se os usuários estão em grupos que podem ter caches filho.
acl cache_users src 192.168.0.0/255.255.0.0
http_access allow cache_users
miss_access allow cache_users
icp_access allow cache_users
Informe aos caches-clientes o hostname, portas HTTP e ICP do cache, e por quê eles devem usar o mesmo. Um usuário informado provavelmente irá usar o cache.
Cuidado: Quanto mais caches houverem após o seu cache, menor será a sua taxa de hit como cache pai. Os caches que estão atrás do seu cache irão colocar em cache o que puderem, e passarão adiante solicitações apenas para conteúdos que eles não tem, ou que são difíceis de achar. Todo hit é ainda um benefício, mesmo que a taxa seja baixa.
Se sua largura de banda é paga por byte, você verá que mesmo uma taxa de hit baixa irá cobrir as despesas com hardware e as despesas operacionais.
Alguns ISPs darão um desconto nos custos se você usar o cache-pai deles. Caches-pai podem conter a página que você vai solicitar, fornecendo um serviço mais rápido.
Você irá precisar:
no_query se seu cache-pai não suportar ICP
Para cada parente que você tenha, acrescente uma linha como esta ao seu
squid.conf:
cache_peer hostname parent HTTP_port ICP_port [OPTIONS]
Por exemplo:
cache_peer proxy.cache.example.org parent 3128 3130 no_query no-digest
Se você tem somente um cache-pai, utilize as opções de configuração
no-query e no-digest. Se você sempre irá solicitar o
objeto do cache-pai, não há necessidade de checar se o objeto está no
mesmo.
Se você tiver múltiplos caches-pai, as consultas ICP podem melhorar a performance. Um exemplo com dois caches-pai:
Cuidado: quando um par falha em responder uma consulta ICP em
dead_peer_timeout segundos, o Squid assume que ele está
indisponível ou não pode ser encontrado até que ele recebe outra resposta ICP
daquele par. Enquanto um par está em seu estado de "presumivelmente morto", o
Squid irá enviar consultas ICP, mas não irá esperar respostas. O Squid irá
basear suas decisões nas respostas dos servidores "vivos".
Se todos os caches-pai estão "mortos" de acordo com este teste e o Squid não estiver configurado para ir diretamente ao site, ele não poderá retornar objetos que não estão em seu cache.
Caches-irmãos funcionam melhor onde você tem grupos de usuários. Cada proxy local de grupo compartilha o cache com outros proxies, somente "pesquisando adiante" em um cache-pai ou servidor de origem se nenhum dos caches tem uma cópia recente do objeto solicitado.
Use caches-irmãos se vários caches estão atrás de algum tipo de gargalo mas tem uma boa conexão uns com os outros.
Caches-irmãos podem ser agrupados para permitir que vários computadores pequenos simulem um computador mais caro e servir como um cache maior.
Para permitir que outro cache use o seu cache como irmão, configure o seu cahce como se fosse um cache pai, mas em vez de dar acesso MISS, negue o mesmo aos seus irmãos.
acl sibling1 src 192.168.44.55/255.255.255.255
miss_access deny sibling1
Para usar outro cache como irmão, ambos devem suportar ou ICP/HTCP ou cache digests. Estes irão permitir ao Squid procurar objetos em outros caches.
A linha cache_peer deve se parecer com isto:
cache_peer hostname sibling HTTP_port ICP_port [OPTIONS]
cache_peer sibling1.myinternalnet.org sibling 3128 3130 proxy-only
Note a opção proxy-only. Normalmente, cachear objetos
recuperados de um irmão são um desperdício de espaço. Se a largura de banda
com o irmão é pequena, com ruídos ou cara, considere retirar a opção e cachear
objetos daquele irmão.
FALSOS HITS: (somente ICP) Como o ICP não comunica cabeçalhos (somente a URI é apresentada em uma consulta ICP), é possível que um par retorne uma resposta positiva para uma dada URI, mas não possa satisfazer a solicitação do cache.
cache1 envia uma consulta ICP ao cache2 pelo
objeto http://www.example.org/index.html.
cache2 possui uma cópia do objeto (87,376 segundos de idade),
e responde afirmativamente.
cache1 então envia a solicitação ao cache2, mas
os cabeçalhos da solicitação contém "Max-Age: 86400". A cópia de
cache2 é muito velha para satisfazer a solicitação.
cache1 tem miss_access no
cache2, então cache2 irá repassar a soliticação para
o cache origem (ou um cache-pai) e recuperar a nova cópia. Se não,
cache2 irá retornar uma resposta HTTP 504 e cache1
terá de selecionar uma nova origem para o objeto.
O HTCP incorpora os cabeçalhos no pacote de consulta, e desta forma é imune a falsos hits -- apesar destes ainda serem possíveis em raras circunstâncias teoricamente possíveis.
Versão inglesa oreillynet.com Copyright © 2000 O'Reilly & Associates, Inc.
Tradução do original em http://www.oreillynet.com/pub/a/linux/2001/08/17/squidpeering.html
Nota do Tradutor: O título original é "Peering Squid Caches". O termo "peering" denota que se coloca o Squid a trabalhar em uma espécie de associação com outros Squid. Na falta de melhor termo, ficou "agrupando"...