[FUG-BR] Harware para Cache

Segunda Novembro 8 01:37:38 BRST 2010

Isso não deveria ser um e-mail, deveria ser um artigo postado na FUG.
E desculpem a resposta no topo, depois de uma explanação dessas
ninguém iria encontrar meu comentário lá embaixo.

2010/11/7 Patrick Tracanelli <eksffa em freebsdbrasil.com.br>
>
> On 06/11/2010 18:55, sergio wrote:
> > Alguém recomenda algum hardware ou solução para cache profissional para provedor ?
>
> Sérgio, solução recomendo fortemente Lusca com Thunder Cache Pro.
>
> Quanto a hardware depende de muitos fatores. O principal é quantos
> usuários você vai pendurar atrás desse proxy.
>
> O mais importante gargalo a ser evitado é o de I/O de disco. Considere
> que de forma geral você tem dois limites em um disco. O mais óbvio,
> espaço. O menos, número de operações por segundo (TPS). Um disco
> SATA-300 de 7200rpm por exemplo vai suportar de 300 a 420TPS variando de
> acordo com as taxas de operações de escrita e leitura. Isso vai resultar
> numa taxa de 80MB/s a 120MB/s.
>
> Em um cache já rodando há alguns dias, as operações de disco são em sua
> maioria (~> 75%) de leitura (o restante de escrita). Quanto mais dados
> em disco, maior a taxa de operações de leitura. Óbvio.
>
> Com cerca de 400GB de disco alocado, seu TPS já fica acima de 300. Com
> cerca de 550, 600GB provavelmente você vai bater no limite de TPS do
> disco. Dessa forma imagine o que acontece se você usar um disco de 1TB
> por exemplo, mas com performance SATA2/7200rpm.
>
> Ou seja discos muito grandes são excelente pra backup. Pra cache vão
> gargalar. Então a primeira dica é ficar com discos de 500GB pra SATA2,
> discos de 750GB pra SATA3 e acima disso, SAS. Claro que da pra variar um
> pouco pra cima, mas já passa do ponto de segurança.
>
> Outra consideração é ser seletivo no que cachear. Não cachear qualquer
> coisa e em especial não cachear arquivos muito pequenos. Arquivos
> pequenos vão consumir seus preciosos TPS, e dependendo da taxa de uso
> dos discos é mais rápido busca-los na internet do que no disco.
> Atenha-se a arquivos acima de 32K. Você pode tunar isso no Lusca e no
> Thunder.
>
> O próximo ponto é a memória. O ideal é que a placa mãe suporte a memória
> em sua maior taxa barramento. Mas a velocidade nesse caso é menos
> relevante que a quantidade. A regra é bem simples: quanto mais memória
> melhor!
>
> Na FAQ do Squid existe[1] uma discussão muito boa sobre como calcular o
> tamanho do seu cache_dir com base em quanto você tem de memória RAM.
>
> Note que a ordem é diferente do que todos pensam. Você não configura o
> tamanho do cache em disco de acordo com o tamanho do seu disco. Esse é o
> primeiro erro, e o principal fator de fracasso. Você define quanto usar
> de cache_dir de acordo com quanto tem de RAM. É um cálculo delicado que
> envolve quanto de RAM você tem, quanto será usado por MB de cache_dir,
> quanto você quer usar pro cache_mem e quanto seu sistema operacional vai
> consumir.
>
> Se colocar o Thunder na mesma máquina ainda envolve no cálculo quanto de
> memória o thunder vai consumir. E isso vai variar com a sua expectativa
> máxima de threads.
>
> Leia com muita atenção a FAQ do Squid e do Thunder[2] pra tunar isso.
>
> Outro ponto é que quanto mais cache_mem você puder ter, mais vai aliviar
> seu disco, podendo compensar inclusive arquivos pequenos (aqueles que é
> bom evitar). Mas lembre-se que cache_mem não é quanto de memória o
> Lusca/Squid vão usar. É quanto de memória será usado pros Hot Objects.
>
> De qualquer forma se você tiver muita RAM e tunar o cache_mem pra baixo,
> em tese não aproveitando a meória pros Hot Objects, no FreeBSD e graças
> ao UFS_DIRHASH e também ao cache de dados do sistema de arquivo que o
> FreeBSD vai fazer sozinho por padrão (kernel GENERIC), você vai ter
> compensação de I/O de disco com esse cache de memória. Nesse caso, com
> bastante RAM, da até pra fugir desses limites de tamanho de disco, pois
> quanto mais RAM pro FreeBSD, menos TPS consumidos nos seus discos.
>
> Ou seja quanto você puder investir em RAM vai orientar todas as outras
> suas decisões.
>
> Voltando aos discos, tente ter um ou dois discos pro sistema, isolados
> (se for 2, em RAID-1 com gmirror), e os demais discos em RAID-0. Faça
> RAID-0 com Geom Stripe.
>
> Faça RAID-0 com Geom Stripe.
>
> Sei que repeti. É pra dar ênfase ;-) Eu testei muito RAID-0 com
> controladoras típicas no percado tupiniquim, em especial as P4X vendidas
> com servidores HP e PERC vendidas com DELL. O RAID-0 delas não chega nem
> perto em performance do Gstripe. Fuja como o diabo corre da cruz, de
> RAID de BIOS. RAID de BIOS são esses RAID... de BIOS sabe? Que vem na
> placa mãe. Os linuxers chamam de FakeRAID, eu chamo de qualquer RAID que
> o "atacontrol" controle e o FreeBSD reconheça como ar(4). Nem considere
> usar! Você tem Geom Stripe ;-)
>
> RAID-0 por hardware que substituiria o Gstripe só se for com
> controladora LSI Logic ou QLogic. Essas podem dar mais performance que o
> Gstripe. De todas que tive o prazer de testar, só elas.
>
> Dê uma lida na man page do stripe pra considerar tuning através das
> sysctl documentadas. Se você conseguir diminuir a relação de espaço em
> disco por TPS (por exemplo, discos SAS são em geral mais caros e
> normalmente você vai investir em discos SAS de tamanho abaixo do que
> eles poderiam ser, especialmente pq SAS de 1TB ainda são bem caros).
> Nesse caso diminua o stripesize na hora de fazer o gstripe.
>
> Se quiser arriscar discos maiores do que os que eu mencionei, por
> exemplo, usar discos de 750GB SATA2/7200rpm, aumente o stripesize pra
> tentar aliviar o TPS. O quanto aumentar vai depender do número de
> discos. Não tem uma formula pra isso, infelizmente.
>
> Não use discos SATA de 5400rpm, a não ser pro sistema. Senão você vai
> perder a referência de taxa de I/O em TPS com taxa de transferência em
> bytes.
>
> Quanto a placa mãe o fundamental é que ela tenha canais independentes
> pros discos. Seja SAS, SATA, SSD... não adianta nada ter discos que dão
> 140MB/s em um disco mas dão 70MB/s quando 2 estão em uso simultâneamente.
>
> Da mesma forma, claro, corra de discos slave. Cuidado porque o conceito
> de slave é especialmente deturpado com discos SATA/SAS em relação aos
> PATA. Você pode achar que são todos master mas estão dividindo canal.
>
> Eu gosto de placas mãe supermicro pra isso. Mas claro Intel Server e
> Gigabyte Server vão atender.
>
> Quanto a CPU, com Lusca você consegue pelo menos 400Mbit/s atendendo
> alguns milhares de clientes, com um Quad Core de 2.0Ghz. Acima disso
> talvez você precise rodar multiplos lusca.
>
> Evite usar regex, senão você vai encontrar limite por voltados 30Mbit/s.
> Infelizmente o processamento de regex do Lusca ainda é uma das heranças
> malditas do Squid: ruim e pesado. E monothread o que é ainda pior. No
> Lusca o Chadd conseguiu[3] mitigar um problema de exaustão de fila
> quando você usa o recurso de external_acl_type pra processas as regex.
> Então use-o!
>
> Acho que com base nessas observações você vai conseguir dimensionar bem
> seu hardware :-)
>
> [1]http://wiki.squid-cache.org/SquidFaq/SquidMemory#How_much_memory_do_I_need_in_my_Squid_server.3F
> [2]http://www.thundercache.com.br/faq-leia.html
> [3]http://code.google.com/p/lusca-cache/issues/detail?id=120
>
> --
> Patrick Tracanelli
> FreeBSD Brasil LTDA
> http://www.freebsdbrasil.com.br
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

--
Antônio Rogério Lins de A. Pessoa
Técnico em Tecnologia da Informação
SysAdm Soluções em T.I.