[FUG-BR] Harware para Cache
Patrick Tracanelli
eksffa em freebsdbrasil.com.br
Domingo Novembro 7 03:30:33 BRST 2010
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
Mais detalhes sobre a lista de discussão freebsd