Esta é uma maneira sensata de dimensionar o Nginx para conteúdo estático?

Question

Eu preciso configurar alguns VPSs para servir conteúdo estático (muitos arquivos pequenos). Eu planejo usar o Nginx para isso, e gostaria de configurá-lo para que possamos escalar com relativa facilidade. Os requisitos são:

• Muitos arquivos (pelo menos centenas de milhares).
• Pequenos tamanhos de arquivo (menos de 10 KB).
• Arquivos são adicionados constantemente por um aplicativo em servidores vizinhos.
• Os novos arquivos devem estar imediatamente disponíveis para todos os servidores Nginx.

Meu plano atual é:

• Ter um servidor 'master' com um compartilhamento NFS contendo todos os arquivos.
• O aplicativo que produz novos arquivos interage apenas com o mestre.
• Ter vários servidores Nginx montando esse compartilhamento NFS.
• Carregar saldo nas instâncias do Nginx.

Um problema óbvio com isso é que o servidor 'mestre' é um ponto único de falha (qualquer solução para isso?). Existem outras questões potenciais que negligenciei? Existem elementos aqui que não serão bem dimensionados dessa maneira? Alguém sugeriria uma abordagem alternativa?

Com relação aos requisitos de memória, estou assumindo que devo dar a cada servidor Nginx o máximo possível para que arquivos em cache possam ser armazenados em cache (por SO? Nginx?) e não precisarem ser reqested do compartilhamento NFS constantemente.

Por último, estou louco para não usar um CDN?

    

Answer 1

O NFS não é dimensionado. Ele adiciona latência a todas as solicitações e acabará se tornando um gargalo muito grande. Temos um problema semelhante no trabalho, mas com fotos (por isso, arquivos muito maiores) e escrevemos nosso próprio software para fragmentá-los e distribuí-los. Para alguns GB de arquivos como o seu, você pode se safar com o processo de upload fazendo um HTTP PUT em todos os servidores e fazendo ressincronizações quando os servidores estiverem offline.

Ou use outra forma: tenha um (conjunto de) servidor (es) central (is) com todos os arquivos e proxies reversos em cache (squid, pound, verniz) que realmente sirvam os arquivos para os clientes.

E você não é louco por não usar um CDN. Você é louco se você não investigar se vale a pena embora: -)

    

Answer 2

Use cachefilesd (e um kernel linux recente, com cachefs) para armazenar em cache arquivos NFS em um HD local. Desta forma, toda leitura no nfs copiará o arquivo para um diretório / var / cache / fs e as próximas leituras serão entregues a partir daí, com o kernel verificando o nfs se o conteúdo ainda é válido.

Desta forma, você pode ter um NFS central, mas sem perder o desempenho dos arquivos locais

Cachefilesd cuidará da limpeza de arquivos antigos quando o tamanho / inodes livres atingirem um nível configurado, para que você possa servir dados incomuns do NFS e solicitações comuns do HD

Depois de configurar isso, use um verniz para entregar o conteúdo, ele armazenará em cache as solicitações mais usadas, economizando uma tonelada de solicitações para o nginx / NFS.

Aqui é um pequeno howto de cachefilesd.

    

Answer 3

Eu recomendaria obter um único servidor (potencialmente dedicado) para isso, em vez de usar vários servidores VPS individuais e separar nginx instâncias conectadas por meio de nfs . Se você está pensando em usar o VPS e o NFS, não acho que suas preocupações com a escalabilidade sejam justificadas.

nginx faz quase todo o seu caching através do sistema de arquivos da máquina, então, se você for usar o nginx para isso, você deve garantir um sistema operacional que tenha um excelente desempenho de sistema de arquivos e cache. Certifique-se de que seu kernel tenha o suficiente vnodes etc.

Se você ainda está pensando em máquinas separadas (minha sugestão, como acima, é usar uma máquina com um nginx), então pode fazer sentido investigar varnish . O verniz faz todo o cache na memória virtual, portanto, você não precisa se preocupar com ineficiências de vnodes ou cache com arquivos menores. Como está usando memória virtual, seu cache pode ser tão grande quanto a memória física + swap.

Eu recomendo strongmente contra o squid. Se você quiser saber o porquê, basta olhar para uma apresentação de verniz, que descreve por que a memória virtual é a melhor maneira de ir para um proxy de aceleração. Mas o verniz só faz aceleração, então se você estiver usando um único host com arquivos estáticos e bom cache do sistema de arquivos (por exemplo, FreeBSD), então o nginx provavelmente seria a melhor escolha (caso contrário, com verniz você terminará com o mesmo conteúdo em cache duplo em vários lugares).

    

Answer 4

Nenhum projeto de servidor de produção pode ter um único ponto de falha.

Portanto, você precisa de pelo menos duas máquinas como balanceadores de carga. Você pode usar um balanceador de carga como HAProxy . Tem todos os recursos que você pode precisar, verifique este exemplo de arquitetura HAproxy. A carga real da solicitação que você enfrentará é "muitas solicitações de arquivos pequenos" em um sistema de armazenamento NFS.

O número de caches depende dos seus recursos e solicitações do cliente. O HAProxy pode ser configurado para adicionar ou remover servidores de cache.

A solicitação de arquivo NFS é a operação mais exigente, portanto, você precisa de uma forma de armazenamento em cache nas máquinas "cache".

O servidor de cache tem 3 camadas de armazenamento, você quer que os arquivos mais comuns estejam disponíveis localmente e, de preferência, na RAM.

• NFS, de longe o mais lento. (REMOTO)
• Armazenamento local, rápido. (LOCAL)
• Ram, ultra rápido. (LOCAL)

Isso pode ser resolvido com nginx, squid ou verniz.

O nginx pode armazenar em cache arquivos locais usando SlowFs , isso é bom tutorial lento do fs

O Nginx com este sistema armazena arquivos no disco do sistema de arquivos local e os atende a partir daí. Você pode usar PURGE para remover um arquivo modificado do cache. É tão simples quanto fazer uma solicitação com a palavra "purge" na string de solicitação.

O Nginx com FS Lento usa o RAM que o SO fornece, aumentando o nginx ram disponível pelo SO para melhorar a velocidade média da solicitação. No entanto, se o armazenamento exceder o tamanho da RAM do servidor, ainda será necessário armazenar os arquivos em cache no sistema de arquivos local.

O Nginx é um servidor multiuso que não é extremamente rápido. Pelo menos não tão rápido quanto os servidores de cache estático, como o squid ou o verniz. No entanto, se o seu problema é o NFS, o Nginx resolve 90% do problema.

O Squid e o Varnish são muito rápidos e têm APIs para remover arquivos do cache.

O Squid usa o RAM e o sistema de arquivos local para o cache. O verniz usa memória ram para cache.

O Squid é antigo e a maioria dos benchmarks mostra que o verniz é mais rápido do que o squid colocando arquivos estáticos.

No entanto, quando o verniz falha, o cache de RAM é perdido e todo o servidor pode levar muito tempo se recuperando. Portanto, uma falha é um grande problema para o verniz.

O Squid manipula os travamentos melhor porque também usa o disco de armazenamento local e pode reinicializar algum cache de lá, em vez de usar o NFS.

Para um ótimo desempenho servindo pequenos arquivos estáticos, você pode usar Nginx e Squid OR Varnish.

Outros tamanhos de arquivo exigem uma abordagem diferente.