Meu amigo administra um site popular de conversão do YouTube para o GIF. Neste momento, ele converteu 250.000 vídeos do Youtube em GIFs (cada vídeo recebe 6 miniaturas para arquivos GIF de 1.5m) e atende a 80TB de largura de banda por mês.
O servidor dele está bloqueando o IO - não sou um administrador do guru, mas parece ser o tempo de busca do disco rígido para GIFs não sequenciais que estão entupindo tudo. Ele tem um servidor com 100tb.com por US $ 300 / mês e vem com 100TB de largura de banda gratuita. No começo, eu o aconselhei a obter um CDN para resolver seus problemas, porque então os GIFs são servidos sem consumir seus recursos de servidor, e sua caixa principal poderia apenas lidar com a codificação - Encontramos um CDN por $ 600 / mo que era muito lento / não confiável, e o resto queria pelo menos $ 2000 / mês para 80TB de largura de banda. Estamos tentando manter todo o projeto abaixo de US $ 900 / mês, no momento.
Assim, a largura de banda mais barata que podemos encontrar é de 100 TB, mas estamos superando um servidor. Poderíamos adicionar outro servidor, mas eu realmente não sei como particionar o armazenamento GIF para que a carga seja distribuída uniformemente entre duas caixas. Nosso anfitrião recomendou o uso de software como o Aflexi.net, mas tenho certeza que deve haver uma solução mais barata.
Alguém pode ajudar? Eu sou um programador de comércio, não um administrador de sistemas, mas tentando aprender as cordas. Obrigado!
O S3 não é uma alternativa, o faturamento de 80 TByte será de mais de 8k $ por mês.
Parece que você serve os GIFs diretamente do sistema de arquivos. Por que você não coloca todos os GIFs em duas máquinas, usa um algoritmo de hash mapeando o nome para uma das duas máquinas e as entrega dessa maneira? Isso seria escalonado facilmente para mais computadores, contanto que o balanceador de carga aguente ...
Envie os arquivos para o S3 e os sirva de lá. O CDN do pobre homem:)
Se você precisar de mais capacidade de processamento, poderá fazer as conversões a partir de instâncias do EC2 e fazer o dump diretamente para o seu "CDN" também.
Eu não posso comentar os outros comentários, mas eles soam bem. Eu procuraria levantar parte da carga dos servidores de arquivos mantendo seus arquivos mais comumente acessados (isto é, os mais populares) em um cache de memória, ou seja, ter um manipulador http que faça algo assim:
Se você consegue uma máquina com uma porcaria de RAM, você está rindo, pois é bem provável que você consiga ajustar uma grande porcentagem de seus arquivos populares na memória.
E quando você saturar isso, adicione outro servidor de manipulador de imagens e faça um round-robin neles. Continue fazendo isso até que algo quebre, ou seja, taxa de transferência, escalabilidade, economia.
Eu fiz algo assim antes para um bom efeito.
Se são apenas duas máquinas, você pode considerar o uso do DRBD para sincronizar as duas máquinas. Então é só usar o PHP para decidir aleatoriamente ou algoritmicamente qual servidor usar durante uma requisição. Solução simples, mas viável.
Tags scaling static-files