Configuração do servidor para armazenamento de imagens

Question

Eu preciso armazenar 25M fotos em 4 tamanhos = total de 100M arquivos, o tamanho do arquivo varia entre 3Kb e 200 kb por arquivo e o armazenamento usado no início é de cerca de 14-15 TB.

Nosso objetivo é ter os dados disponíveis no Servidor 2-4 e servi-los com um servidor Web rápido local (nginx ou lighthttpd), precisamos fazer o máximo possível de servidores req / seg.

Meu plano é usar 2U Servercase da Intel com 12x2TB (WD RE4) com Raid 6 (ou FS com redundância ??) para os dados e 2x60GB SSD para o sistema operacional, é um bom caminho? Agora: Eu encontrei o Adaptec 5805ZQ que pode usar SSD SLC Drives para cache de arquivos mais usados, alguma sugestão para ele?

Qual tamanho de cache de leitura eu preciso escolher?

Qual será o melhor caminho para redunancy e balanceamento de carga, se eu planeja ter 2-4 de tal servidor?

O que é pro / con entre o Cluster e o FS distribuído em relação ao nosso objetivo?

    

Answer 1

Se este for o desenvolvimento greenfield, então eu absolutamente usaria a nuvem para isso . 100 M arquivos é um monte de dados; seria uma grande melhoria para transferir o armazenamento redundante disso para o fx Amazon S3.

Considerando que estamos falando de arquivos de 100 M, acredito que podemos dizer com segurança que algumas partes do conjunto de dados estarão "quentes" (frequentemente solicitadas) e a maioria das partes estará com problemas. Por isso, realmente queremos o armazenamento em cache.

Uma visão geral de como isso pode ser feito no Amazon Web Services:

• Primeira camada: Elastic Load Balancing gerenciado pela Amazon e o Amazon CloudWatch monitorando algumas pequenas instâncias do EC2 com nginx ou Apache. Esses servidores são apenas balanceadores de carga com arquivos de configuração estáticos, então o Cloudwatch pode monitorá-los para nós e gerar automaticamente novas instâncias se um deles falhar.
• A partir da primeira camada: Hasteamento consistente com base na URL de solicitação (nome do arquivo) para uma camada de servidores de cache. Você deseja hashing com base no nome do arquivo para garantir que cada arquivo não seja armazenado em cache várias vezes (reduzindo a taxa de acertos do cache), mas com N servidores de cache que cada servidor manipula 1 / N do espaço de endereço.
• Segunda camada: servidor (es) de cache. Seus servidores de cache são instâncias EC2 com mais memória e cache Squid ou Varnish ou Servidor de Tráfego Apache instalado.
• Da segunda camada: HTTP antigo simples para o armazenamento de arquivos do Amazon S3.

Como essa configuração é fracamente acoplada, é fácil escalá-la horizontalmente (conforme os problemas de dimensionamento).

A rapidez com que isso vai depender muito da relação entre dados quentes e frios. Se a sua carga de trabalho estiver mais quente, não ficaria surpreso em ver bem acima de 10.000 req / s de apenas 2 EC2s de balanceadores de carga pequenos e 2 instâncias do EC2 de cache de alta mem.

    

Answer 2

SSDs para o sistema operacional em si é um exagero, a menos que você esteja realmente interessado em inicializar 30s mais rápido. Basta pegar um par de drives SAS pequenos e isso deve ser mais do que suficiente.

o cache, a utilidade do cache depende do conjunto de trabalho. Ou seja são pedidos para as imagens que devem ser distribuídas uniformemente em torno de todas as imagens, ou você espera que a maioria das solicitações seja de um pequeno subconjunto? Neste último caso, um cache pode ser útil, no primeiro caso, não tanto. Observe que o cache no controlador de disco é útil principalmente para gravações em cache (se o cache não for volátil), o que é útil para aplicativos com uso intensivo de fsync (), como bancos de dados. Para o serviço de imagens, suspeito que o benefício não seja tão grande.

Um problema com o cluster e FSs distribuídos é que eles são mais complicados de serem configurados, e FSs especialmente distribuídas são menos maduras do que as FSs de nó único "normais". Um cluster FS normalmente significa armazenamento compartilhado, o que significa uma SAN relativamente cara, se você quiser evitar pontos únicos de falha.

Uma alternativa seria configurar um cluster executando algum tipo de aparência semelhante ao Amazon S3 que forneça um armazenamento de valor-chave distribuído e distribuído acessível por HTTP. Por exemplo. armazenamento openstack .

    

Answer 3

Depende muito da frequência com que esses itens serão usados. Se você pode esperar que uma pequena porcentagem deles seja muito ativa de cada vez, então você pode querer considerar o Varnish para fazer o seu tratamento de front-end, carga balanceada fora de seus backends nginx / lighttpd. Como as imagens mais usadas seriam armazenadas em cache, a velocidade do disco é um pouco menos importante.

No entanto, se as imagens não forem solicitadas repetidamente e o cache não fornecer um grande impulso, o nginx / lighttpd em um servidor ou dois o fará. Você também precisa considerar a quantidade de largura de banda que será entregue. 800mb / seg de um pequeno subconjunto de seu conjunto de dados seriam facilmente armazenados em cache pelo sistema operacional. 800mb / s de um enorme subconjunto de seu conjunto de dados provavelmente ficarão presos a um gargalo de IO, pois não é possível obter os dados do disco com rapidez suficiente para serem atendidos. Nesse caso, você precisa dividir o sistema em partes suficientes para ter o IO. largura de banda.

Embora você esteja executando o raid-6, isso não substitui os backups, portanto, faça o orçamento de uma máquina semelhante para fazer backups ou, possivelmente, atuar como um servidor de armazenamento de failover.

    

Answer 4

Eu escolheria um cluster personalizado em vez de um FS distribuído, porque é mais simples de entender e solucionar problemas, enquanto ainda está funcionando. Ou seja, as compensações de confiabilidade de seu próprio cluster são óbvias, embora seja uma tarefa por si só descobrir como um FS distribuído reage a um servidor inativo ou a um switch com falha.

Uma possível solução para o seu tipo de problema é dividir todo o arquivo da foto em partes (digamos, 2 partes) e tornar o ID da peça explícito na URL (por exemplo, torná-lo um subdomínio ou um parâmetro GET fácil de extrair com expressões regulares). Então, você terá 4 servidores de armazenamento com fotos (2 servidores para cada parte). Use o quinto servidor como um proxy reverso que distribui e equilibra a carga. Todos os cinco servidores podem executar o lighttpd. Ou seja, eu proponho um muito estúpido, mas trabalhando (para a empresa em que trabalhei - com a carga total de ~ 5000 solicitações por segundo, arquivos com 3-10 KB de tamanho, 8 TB de arquivos exclusivos, servidor de 24 backends que , no entanto, execute uma solução personalizada do daemon HTTP em vez de lighttpd).

Quanto aos discos e RAM: usamos um software RAID-0 feito de quatro discos SATA rápidos e baratos em cada servidor (se um disco falhar, todos os dados podem ser copiados de qualquer maneira a partir de uma réplica em um servidor diferente), mais uma solução personalizada para colocar todo o servidor offline após um único erro de leitura. RAID-5 e RAID-6 são muito ruins em termos de velocidade, mesmo se um disco falhar, por favor, não os use. Nos servidores de conteúdo, muita memória RAM é essencial (como um cache de disco), procure 24 GB ou mais. Mesmo assim, esteja preparado para um tempo de aquecimento de 30 minutos. No proxy reverso, se você usar o lighttpd, leve em conta que ele armazena toda a resposta upstream na RAM o mais rápido possível, e pode gastar muito tempo empurrando a foto em cache para alguém em discagem ou GPRS (e durante esse tempo , precisa desse buffer na RAM). Nós também levamos 24 GB apenas para ter configurações idênticas, mas não tenho certeza se isso é um exagero. O cache HTTP baseado em memória no proxy reverso não é essencial (mesmo se houver imagens quentes!), Porque o cache de disco fornecido pelo SO nos back-ends também funciona.

Para garantir que todos os back-ends que servem a mesma parte do seu arquivo tenham os mesmos dados: isso é fácil. Ao publicar fotos, basta copiá-las para todos os servidores. Em seguida, use o rsync em partes antigas do arquivo para corrigir quaisquer discrepâncias, tornando uma cópia do master.