[MASOCH-L] Solução de cache / aberta

[Paulo Henrique - BSDs Brasil]

Tiago A. Peçanha wrote:
> Paulo,
> Hoje temos esses usuários distribuídos em 3 caches com as specs 
> mencionadas.
>
> E não é RAID10 é um disco apenas mesmo.
>
> O relato sobre o incomun tem sido positivo?
>
> ----- Original Message ----- From: "Paulo Henrique - BSDs Brasil" 
> <paulo.rddck at bsd.com.br>
> To: "Mail Aid and Succor, On-line Comfort and Help" 
> <masoch-l at eng.registro.br>
> Sent: Thursday, July 19, 2012 2:36 PM
> Subject: Re: [MASOCH-L] Solução de cache / aberta
>
>
>> Tiago A. Peçanha wrote:
>>> Boa tarde pessoal,
>>> Estou definindo requisitos para cache web para refazer os caches que 
>>> temos na rede de um cliente em cima do squid que não estão muito 
>>> satisfatórios (usamos TPROXY), a intenção também é incluir cache de 
>>> vídeo nesses servidores (todos com 16GB RAM, quadcore xeon e 1 disco 
>>> SAS - pretendemos adicionar alguns SATA para vídeo).
>>>
>>> Estou na dúvida sobre sistema de arquivos ideal para se utilizar (ou 
>>> algum método que elimine esse overhead do fs), se uso lusca ou squid 
>>> simples mesmo, com incomun (alguém usa com sucesso para cache de 
>>> vídeo?)... enfim, ainda são muitas dúvidas, e gostaria de contar com 
>>> a experiência de vocês para melhorar nosso ambiente. Outro aspecto é 
>>> que estou evitando a compra de um OVERSI ou algo do tipo, mas temos 
>>> que ter uma performance legal.
>>>
>>> Temos em média 4000-5000 usuários simultâneos em horário de pico.
>>>
>>> O que vocês estão usando e me recomendam?
>>> Obrigado!
>>>
>>> Tiago A. Peçanha
>>>
>>>
>>> __
>>> masoch-l list
>>> https://eng.registro.br/mailman/listinfo/masoch-l
>>>
>> 1 disco sas ou um array RAID 10 sobre sas ?
>> A questão maior não bem as melhores praticas/dicas a ser seguidos 
>> mais sim onde colocar os caches.
>> Para 4000/5000 usuário simultaneos, considere distribuir os usuários 
>> em celulas menores, segmentando as rede que cada cache irá interagir.
>> Tem quantas saidas de operadoras na rede ? são todas presentes no 
>> mesmo ponto ?
>> Quanto a cache de video, eu implantei o thundercache3 sobre FreeBSD, 
>> mais já tenho relatos de companheiros com o incomum sobre o CentOS e 
>> o Fedora Core.
>>
>> Att.
>> __
>> masoch-l list
>> https://eng.registro.br/mailman/listinfo/masoch-l
>>
>
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l
Tiago,
Creio que colocar pelo menos um raid 5 sobre o SAS deixará o servidor 
menos ofegando quando der os picos,
E sim o relato do incomum foi positivo,
Quanto ao modo de operação, embora segmentar seja bom uni-los 
posteriormente ( dentro da rede dos servidores ) com o ICP permitirá a 
você um melhor ganho, é meio complexo e não sei se funciona com o 
Tproxy, mais cache que existe em um servidor e não possui no servidor 
solicitado irá antes de ir a internet irá questionar os demais caches 
primeiro para depois ir para a internet.
E acredite o principal gargalo/pfu seu será disco, é melhor investir em 
um bom array de discos do que em multiplos servidores ( mais de dois 
servidores .
16Gbs de ram é bom, porem coloca um FreeBSD sobre 32Gbs  ( memoria está 
barata ) e ZFS.
Disctribui o cache nos discos usando fatores tais como:
Deixe os sas para conteudos com maior capacidade de acesso e menor 
tamanho ( espaço em sas é caro )
Use um monte de sata 2 ( que são barato ) para conteudos que serão 
cacheados porem o acesso será menor ( videos e objetos grandes ).
Coloca duas ou tres controladoras off-boards de discos e utilize um 
softraid com nivel 5 ou 10  para unilas assim se um disco der problema 
os demais continua a operação sem maiores problema até poder resolver.
E duplique ambos os servidores:
se tem dois segmentos utilize quatro servidores ( dois são 
redundâncias/balanceamento ) e use o ICP para manter comunicação entre eles.

Se achar que a coisa está muito complexa para gerenciar, faço uso dos 
demais conselhos do pessoal mais experiente na lista, parte para solução 
tais como OVERSI e MARACACHE, tem outros mais não recordo o nome.

E deixa o sistema operacional plenamente fora dos discos de cache ( 
exigencia ).

pfu = ponto de falha unica.


att. Paulo Henrique.