Perguntas Frequentes

Abaixo algumas perguntas frequentes (FAQ, do inglês Frequently Asked Questions) e suas respostas. Essa lista de FAQs foi elaborada pela FreeBSD Brasil LTDA, em caso de dúvidas entre em contato com eles. A leitura dessa FAQ é fortemente recomendada.

P-1: Quantas threads eu preciso?

R-1: Para calcular quantas threads você precisa ter para rodar o Thunder Cache Pro exclusivamente, instale em seu gateway Linux ou FreeBSD o comando/aplicação trafshow, e digite:

# trafshow port 80

Em baixo, no fim da tela, haverá um resumo dizendo X Flows, por exemplo 923 Flows. Esse é o número de sessões porta 80 em andamento nesse exato momento. Monitore essa informação ao longo de alguns dias. O maior valor é o seu pico, e você deve ter um número de threads suficiente para atender esse pico.

Se você não tem um gateway FreeBSD ou Linux instalado, mas tem um Firewall, pode usar a seguinte estratégia:

• Crie uma regra de firewall que seja stateful e libere todo tráfego da porta 80
• Depois veja quantos states foram criados por essa regra;
• Procure o pico de states gerados pela regra: esse é seu pico e você deve ter um número de threads suficiente para atendê-lo;

P-2: Devo utilizar o Thunder Cache com ou sem o Squid?

R-2: Em primeiro lugar não use o Squid. Se considerar usar o Thunder com outro proxy, use o Lusca. O Lusca é um fork, uma evolução direta do Squid com foco em performance e estabilidade. De fato os ganhos de performance do Lusca comparado com o Squid são consideráveis; estabilidade ainda mais, já que esse não é o forte do Squid a partir de sua série 3. Outro motivo: Lusca é desenvolvido por developers FreeBSD, encabeçados por Adrian Chadd.

Isso posto, tenha em mente que o Thunder Cache Pro não precisa do Lusca para funcionar. De fato a eficiência do Thunder, especialmente com conteúdo dinâmico, é muito maior, lógico. Mas o Thunder também faz Cache de conteúdo estático com equivalência de eficiência na maior parte das vezes ou com alguns nuances de destaque para o Thunder em outras. Ou seja se seu objetivo é Cache, economia de banda, você não precisa do Squid/Lusca.

Todavia, o Thunder não implementa funções genéricas de proxy, como filtro de conteúdo, Access Control List, autenticação modular de usuários e outros recursos tipicamente de proxy e não de caching proxy. Nesse caso se você precisa de recursos de filtro de conteúdo e afins, precisa implantar o Thunder em conjunto com alguma outra solução, como Squid, Lusca, Squidguard ou Dansguardian.

Para entender, tenha em mente algumas considerações. O ambiente computacional moderno é fundado em SMP (Multiprocessamento Simétrico), ou seja servidores com múltiplos núcleos/CPUs. No entanto ter múltiplas CPUs não é garantia de performance para qualquer aplicação. Ela precisa saber tirar proveito de um ambiente SMP. As aplicações que sabem tirar proveito, chamamos de multithreaded ou apenas multithread. O Lusca/Squid não são aplicações massivamente multithread. O Lusca de fato é multithread para operações paralelas de acesso a disco, mas não para processamento. O Thunder Cache Pro também não é multithread.

No entanto o Squid/Lusca tem uma arquitetura de software fundamentada em um único processo. Ou seja não só não é multithread como não permite que o sistema operacional tire proveito adequado das múltiplas CPUs, pois usualmente o Squid é apenas um processo, de uma única thread de processamento, e como tal, pode até ser processado por múltiplas CPU, mas nunca ao mesmo tempo. O que piora a situação ainda mais pois a troca de contexto de escalonamento pode gerar ainda alguma perda de performance, sendo necessário muitas vezes dedicar uma ou mais CPUs ao Squid (processo que chamamos de CPU Affinity). Ou seja, não adianta ter 2, 4, 16, 32 processadores. O Squid usará apenas um por vez.

Já o Thunder Cache, apesar de essencialmente monothread, ele é modular. Cada requisição feita é processada por um processo separado (de forma similar ao Qmail, vários processos desempenhando a mesma função para clientes distintos). Ou seja apesar da aplicação não saber tirar proveito de múltiplas CPU, o fato do Thunder gerar várias instâncias de processos permite que seu processamento seja escalonado e dividido entre as múltiplas CPUs do servidor. Portanto no caso do Thunder Cache existe o paralelismo real de processamento, e a eficiência desse aproveitamento é diretamente relacionado a habilidade do Sistema Operacional (FreeBSD ou Linux) escalonar cada processo do thunder em uma CPU mais livre, ou outra. Por isso a escolha do sistema operacional é importante, e por isso o Thunder escala muito melhor que o Squid/Lusca em ambiente de grande porte.

No entanto, a discussão não termina ai. Uma técnica[1] para diminuir o impacto do problema no caso do Squid é rodar múltiplos processos. Só que o Squid não foi projetado pra isso. Resultado, o administrador tem que criar vários arquivos squid.conf e iniciar vários processos, cada um com seu próprio conf. É um trabalho enorme e que demanda muita manutenção e recurso humano. Especialmente porquê cada instância do Squid vai ter que ouvir numa porta. E aí o responsável pelo Cache tem que balancear as redes que são direcionadas pra cada Squid em cada porta. Uma demanda grande de recurso humano e principalmente grande demanda de manutenção pois o equilíbrio de carga pode mudar ao longo dos dias, e uma rede ou cliente com um perfil pode passar a demandar mais ou menos acessos Web, elevando ou diminuindo a demanda de um processo Squid, e o administrador tem que equilibrar, periodicamente, balanceando as redes mais pesadas entre os múltiplos Squid rodando.

Atenção: Essa questão traz a tona uma discussão muito importante e associada ao uso de expressões regulares no Squid/Lusca. Hoje é possível utilizar o Thunder integrado com Lusca sem o uso de expressões regulares, com o uso de um recurso desenvolvido pela FreeBSD Brasil, chamado FBSDBR-DLIST. Leia mais aqui. Com o uso desse recurso é possível agora usar o Lusca em uma única instância na maioria dos cenários e organizações. Hoje em links de até 400Mbit/s o recurso FBSDBR-DLIST garante integração com Thunder sem nenhuma elevação de consumo de CPU. Isso associado com um adequado tuning do recurso multithread de I/O de disco no Lusca em modo AUFS e com a aceleração HTTP, DNS e VFS_AIO do kernel do FreeBSD, estabelece um novo padrão e nova realidade para caching de Lusca+Thunder em ambiente de grande porte.

Mas o que justificaria esse trabalho todo? Em tese, o custo poderia ser uma resposta. O Thunder é o grande cara para fazer Cache de conteúdo dinâmico, enquanto o Squid/Lusca normalmente servem para conteúdo estático, basicamente. O Thunder pode fazer praticamente todo cache estático relevante que o Squid/Lusca, mas o Lusca/Squid pode também ser usado pra cache estático. Dessa forma, basta somar 1+1. A vantagem de integrar o Lusca com Thunder é demandar menos threads do Thunder, ja que uma boa parte do serviço fica com o Lusca (o estático), teoricamente gerando economia financeira na compra de licenças com mais threads. Mas essa economia tem o custo óbvio do trabalho e da demanda constante de recurso humano para ficar monitorando e acompanhando a carga do Lusca.

Portanto podemos elencar:

• Vantagens Lusca+Thunder: menor custo de licença do Thunder, pois demandará menos threads; uso de recursos de filtro de conteúdo, autenticação modular, listas de controle de acesso, filtro por grupos de usuários, locais e horários, recursos não de caching  e portanto não implementados no Thunder;
• Desvantagens Lusca+Thunder: Compromete a escalabilidade da solução; setup complexo e cenário mais sujeito a problemas; alta demanda de recurso humano pra manutenção da solução; elevação de custo de manutenção por demandar mais recurso humano;
• Vantagem Thunder Cache independente: escala que é uma beleza, e ainda da pra usar em cluster; é implantar, configurar, homologar e esquecer; se tiver problema será referente a esgotamento de recursos de hardware (memória, disco, CPU), não associado a uso ineficiente destes, portanto bastará crescer em hardware, nem que seja escalando em modo clusterizado;
• Desvantagem Thunder Cache independente: até 60% a mais de demanda de threads;
• Vantagens Thunder+Lusca by FreeBSD Brasil: Todas as vantagens sem nenhuma desvantagem para ambientes até 400Mbit/s; Escalabilidade facilitada em implementação multisquid com CPU Affinity (FreeBSD) para mais de 400Mbit/s.

O que é realmente vantajoso então? Um cálculo elaborado de TCO (Custo Total de Propriedade), considerando estimativa de custo por homem/hora de trabalho, valor da hora de trabalho do profissional responsável, escalabilidade, paradas por problemas, tempo de falha, métricas FCAPS e ITIL e custo por thread é a unica forma real de responder a pergunta. E a resposta certamente vai variar de empresa para empresa. A FreeBSD Brasil LTDA pode te ajudar a fazer esse cálculo. Sem uma avaliação adequada de TCO combinado com ROI, difícil definir o que é mais vantajoso para sua empresa, que dirá uma resposta genérica. Mas ficam as considerações para que cada indivíduo reflita a respeito.

P-3: O que é Cache Full? E o que é ZPH?

R-3: Cache Full é uma técnica que é acima de tudo apenas uma boa sacada. A idéia é permitir acesso aos dados em seu Cache a uma velocidade superior que o limite de banda que os usuários normalmente tem na navegação Internet. Ou seja você pode dobrar ou triplicar a velocidade dos clientes aos dados em Cache, pois o cliente não está utilizado link Internet para esse acesso.

A idéia geral do Cache Full eleva consideravelmente a sensação de velocidade de navegação, criando uma aceleração real na navegação devido a alta velocidade de acesso aos dados cacheados.

O conceito de Cache Full original é liberar acesso full, ou seja, acesso pleno aos dados em Cache sem qualquer restrição de velocidade. Na velocidade máxima de rede local (LAN). Essa abordagem funciona bem em empesas, condomínios e escritórios, mas normalmente em provedores o melhor é impor um limite, ainda que muito acima do limite de banda utilizado para navegação na Internet, pois usualmente a infra-estrutura LAN ou MAN do provedor pode sofrer com gargalos e congestionamento se todos seus clientes acessarem os dados em cache sem qualquer controle de velocidade. Além de antecipar o esgotamento de recursos do próprio servidor de Cache (estrangulamento de acesso a disco, memória e CPU). Esse conceito de Cache Full é também chamado de ZPH, ou Zero Penalty HIT (HIT com penalidade zero). De fato ZPH é o nome adequado para essa técnica. Cache Full é uma expressão essencialmente utilizada... no Brasil ;-) Bem tupiniquim.

P-4: Porquê dizem que Cache Full por "X-Cache: HIT" não é eficiente?

R-4: Para alinhar: existem duas formas de implementar ZPH/CacheFull. A primeira e bastante utilizada entre profissionais Mikrotik é criar regras de mangle que marquem os pacotes que chegam com cabeçalho de resposta com o conteúdo "X-Cache: HIT". Existem muitos problemas nessa abordagem. Vamos elencar:

• Performance: essa abordagem depende de inspeção de pacotes na camada 7 (OSI Layer 7), cada pacote é aberto e seu conteúdo inspecionado pra saber se o header HTTP contém essa expressão, para então marcar os pacotes. A consequência é consumo elevado de CPU, além de colocar em risco a segurança geral do sistema já que processamento de expressões regulares podem causar impactos de disponibilidade de serviço;
• Eficiência: essa abordagem não funciona sempre pelo fato que pacotes trafegam na rede de forma fragmentada; assim sendo só existe match desse tipo de regra pros pacotes que tiverem a expressão inteira em um único pacote;
• Segurança/Comportamento adverso: entenda, o header "X-Cache: HIT" não é exclusivo do Thunder Cache, tão pouco do Lusca; X-Cache* é um padrão, e como tal, é declarado em uma série de especificações RFC, pode ser usado em Web Servers, proxies diretos, reversos, etc. Então entenda, enquanto o Lusca popula entradas como X-Cache: HIT from <visible_hostname>, o Thunder popula X-Cache: HIT from Thunder. Outros proxies populam recursos como X-Cache: HIT from Varnished, outros X-Cache: HIT from HA-Proxy, etc. Dessa forma, veja por exemplo o site da FreeBSD Brasil LTDA. Se você entrar em http://www.freebsdbrasil.com.br, e se inspecionar os headers de resposta do Web Server ao acessar nosso site, vai encontrar essa assinatura de HIT vindo do Varnished (proxy reverso) e do Thunder, pois utilizamos um mixto de aceleração com esses dois sistemas, com o Thunder operando em modo reverso em conjunto com o Varnished. E não adianta dar uma de esperto e pensar: vou fazer a regra utilizando a expressão completa, X-Cache: HIT from Thunder (ou o que for), pois além de elevar mais o consumo de CPU, o Header HTTP pode ser alterado em Web Servers com muita facilidade. Ou seja se você usa essa abordagem, corre o risco de que seus clientes acessem alguns sites na Internet (como da FreeBSD Brasil) na velocidade de Cache Full/ZPH. Péssima idéia.

A segunda, é através do uso de ToS (Type of Service) ou DSCP (Differentiated Services). Essa abordagem utiliza recurso nativo/padrão do protocolo IP, onde os pacotes são identificados de forma diferenciada de acordo com seu tipo de serviço. O Lusca suporta identificação por ToS em dados que estão em cache nativamente, com os recursos zph_local e zph_parent configuráveis no squid.conf. O Thunder Cache suporta com a configuração do DSCP_TOS_HIT e ainda com TOS_REQ no thunder.conf. Essa abordagem tem as vantagens:

• Performance: o custo de processar um pacote é o mesmo custo de processar uma flag IP qualquer, muito leve especialmente se comparado com análise em camada 7;
• Eficiência: absolutamente todos os pacotes transmitidos na rede serão marcados, não ficando nenhum fora da sua regra;
• Segurança: a maior parte dos roteadores e sistemas de firewall normalizam o ToS transmitido pra Internet; você consegue se precisar, normalizar facilmente o ToS/DSCP de entrada da sua rede garantindo que não venha da Internet pacotes classificados com o seu ToS/DSCP de HIT de cache.

P-5: Não consigo fazer o Cache Full por marcação ToS nem por"X-Cache: HIT" do Thunder ser repassado pelo Squid (ou Lusca).

R-5: A FreeBSD Brasil resolveu esse problema com um recurso chamado FBSDBR-SToS, leia mais aqui.

P-6: Como eu faço Cache Full por DSCP/ToS então?

R-6: Veja nessa thread em nosso fórum; se houverem dúvidas pergunte no fórum ou consulte seu suporte.

P-7: Comprei o Thunder. Tenho direito a Suporte?

R-7: Leia sobre Suporte aqui.

P-8: Ao comprar o Thunder. O que mais eu recebo?

R-8: Além da economia considerável de banda e consequentemente de custos na sua organização? Nada além disso ;-) Não oficialmente, mas note que cada parceiro tem seu método de trabalho e alguns podem oferecer diferenciais dependendo de como você trata com eles seu caso/negócio. Leia aqui e aqui sobre nossos parceiros.

P-9: FreeBSD ou Linux?

R-9: A resposta curta: FreeBSD. A resposta longa: depende do seu ambiente. Leia a lista de recursos do Thunder e observe alguns só estão disponíveis para FreeBSD. Se você precisa deles, então escolha FreeBSD. Se não precisa, considere que com FreeBSD você tem de 20% a 80% a mais de performance que com Linux ao usar o Thunder Cache em um mesmo hardware. Mas se seu ambiente é pequeno, ou seu hardware dá conta da sua demanda e ainda sobre espaço para crescimento a decisão depende apenas do seu gosto pessoal.

P-10: Máquina com Arquitetura 64bits é melhor que 32bits mesmo ou é apenas conceito/teoria?

R-10: Não só é melhor, como o Thunder é desenvolvido nativamente em 64bits. Alias desde a versão 4.1 o Thunder Cache não suporta mais arquitetura 32bits. Só 64bits, portanto você não tem escolha ;-) E acredite, nesse caso é melhor não ter essa opção mesmo.

P-11: Quero experimentar o Thunder Cache Pro. Como faço?

R-11: Siga as instruções de instalação. Se você tiver dificuldades ou preferir o suporte de um profissional, avalie as opções de suporte. Por último se precisar de uma licença liberada por alguns dias para testes, fale com seu consultor dentre nossos parceiros.

P-12: Quais as estimativas reais de economia?

R-12: Na casa de 40% para conteúdo estático e 30% para dinâmico, com mínimos de 22% e 20% respectivamente. Mas se você implementar Cache Full pode conseguir picos muito além dessas porcentagens, chegando a incríveis 800%, 900% especialmente em dias de Service Pack,Hotfix novo ou em atualizações full de anti-vírus.

P-13: O que é o Thunder Cache 3?

R-13: A versão anterior do Thunder. Era shareware, ou seja não havia custos mas não era aberto. Hoje foi descontinuado, conta com uma arquitetura ineficiente de caching quando comparado ao TC4, e uma parte dos plugins estão desatualizados e podem gerar mais problemas do que soluções para seus usuários hoje. Na época era a melhor opção de Caching dinâmico. Se comparar com as outras opções no mercado hoje ainda é uma das melhores, ficando atrás apenas do TC4 tamanha a qualidade do TC3.

P-14: O que é o Thunder Cache 3.1?

R-14: Oficialmente não existe o Thunder Cache 3.1. No entanto houve um vazamento do código fonte do TC3 e algumas pessoas passaram a comercializa-lo com algumas modificações com o nome de TC 3.1. Nós não endorsamos, aprovamos nem recomendamos esse software. Seu uso é ato ilícito passível de indenização jurídica conforme Código Civil Brasileiro artigos 927, 186 e 187.

P-15: O que é o Thunder Cache 2?

R-15: O TC 2 e demais versões da série 2 são uma série de scripts PHP escritos para trabalhar em conjunto com o Squid, sob a técnica de reescrita de URL. É uma abordagem que serviu bem aos seus objetivos iniciais mas depois se mostrou ilitada, levando o Thunder Cache a evoluir até se tornar um Proxy completo independente, escrito em linguagem compilada e nào interpretada, de alta performance e funcionalidade. O TC 2 foi a elaboração maior de um conceito, mas que chegou ao seu limite. Está disponívem em http://www.thundercache.org

P-16: O que é o ThunderSnarf++?

R-16: Você conhece o Thunder Snarf certo? O ThunderSnarf++ é uma variação dele, focada em características e detalhes de implementação de Caching padrão FreeBSD Brasil LTDA. Apresenta uma série de informações adicionais e incluindo informações não específicas do Thunder Cache, como suporte a Lusca. Depende de recursos nativos de FreeBSD e processos próprios da FreeBSD Brasil LTDA, dessa forma não é para ser utilizado por qualquer usuário Thunder. Precisa ser implementado de acordo com o padrão FreeBSD Brasil LTDA, e portanto está disponível apenas aos clientes de consultoria FreeBSD Brasil LTDA.

P-17: Estou tendo problema com alguns sites, alguns navegam normalmente outros dão problema. Só acontece com alguns clientes e em algumas ocasiões (intermitência aleatória).

P-18: Para migrar do Thunder Cache 4.0 para o um superior preciso perder/regerar todo meu cache?

R-18: Sim, mas você pode optar por utilizar o cache atual. Leia atentamente o texto abaixo, retirado do thunder.conf 4.1:

# A partir do Thunder Cache 4.1 a estrutura de diretorios onde os dados sao
# armazenados em cache foi consideravelmente modificada, melhorando pelo menos
# em 20% a performance de acesso a disco e corrigindo uma serie de bugs. Se
# a opcao OLD_CACHE for ativada, o Thunder 4.1 usa o modelo antigo, do 4.0.
# Essa opcao deve ser evitada ao maximo e utilizada apenas em casos extremos
# onde o Thunder 4.1 esta entrando no lugar de um Thunder 4.0 com muitos e
# muitos TeraBytes de dados em Cache, e o cache nao possa ser convertido nem
# exista a possibilidade de baixar os CACHE HIT por alguns dias ate o cache
# ser gerado novamente. Considere o efeito negativo de usar o mode antigo!
# OLD_CACHE false