[FUG-BR] Harware para Cache

Domingo Novembro 7 12:41:03 BRST 2010

On 07/11/2010 09:47, Levi Lins wrote:
>
>
>
>
> Patrick, e ZFS?

Nunca tive vantagens. Performance abaixo do gstripe.

>
>
>> 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
>   		 	   		
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd