[FUG-BR] Harware para Cache

[Patrick Tracanelli]

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