Patrick, muito obrigado pelas informações, neste caso de usar o Lusca com Thunder Cache Pro com FreeBSD, estou pensando se vale a pena fazer o redirecionamento para porta http apartir de um roteador Mikrotik ou se devo usar o FreeBSD como roteador/cache.
A última vez que tentei usar o o Cache com um Link de 300Mbps, um Mikrotik redirecionando o tráfego http para uma máquina com FreeBSD + Lusca + Thunder Cache tive problema com I/O de disco (Disco SAS), acabei não focando mais nisso, mas estou com vontade de voltar. Fiz testes de download em um circuito da Intelig com 100Mbps de banda livre e tive uma taxa de transferência variando entre 20Mbps e 38Mbps, já em um circuito da GVT com 50Mbps tive uma taxa entre 40Mbps e 50Mbps. É notável que a GVT tem muitos Cache, notamos que os downloads pela GVT geralmente são mais rápidos, atingem taxas de transferência altas mais rapidamente etc. > -----Original Message----- > From: eks...@freebsdbrasil.com.br > Sent: Sun, 07 Nov 2010 03:30:33 -0200 > To: freebsd@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
