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
