[FUG-BR] Harware para Cache

Domingo Novembro 7 09:47:59 BRST 2010

Patrick, e ZFS?

> Date: Sun, 7 Nov 2010 03:30:33 -0200
> From: eksffa em freebsdbrasil.com.br
> To: freebsd em fug.com.br
> Subject: Re: [FUG-BR] Harware para Cache
> 
> 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