Manipulando uploads de usuários para um cluster de servidor da web

Question

Temos vários servidores da Web Linux por trás de um balanceador de carga de hardware, que atende a um único site.

Surgiu a necessidade de os visitantes poderem carregar arquivos. Os arquivos são normalmente de 300 a 700 KB e esperamos na região 1 milhão deles. No entanto, isso representa um problema óbvio: se um usuário fizer o upload de um arquivo para o servidor que está manipulando sua solicitação, como manteremos todos os servidores sincronizados?

O atraso deve ser mínimo, portanto, usar algo como rsync em um cronograma definido não é realmente uma opção. Também não deve haver um único ponto de falha, portanto, o NFS não seria adequado, a menos que fosse combinado com o DRBD para criar um servidor NFS de failover.

Examinei sistemas de arquivos compartilhados / em cluster (GlusterFS, MogileFS, OCFS2 e GFS), mas não tenho experiência com eles, por isso não sei como eles funcionam em um ambiente de produção em termos de desempenho e confiabilidade.

Congratulo-me com qualquer conselho sobre como este problema é melhor resolvido.

Muito obrigado

    

Answer 1

O GFS2 / OCFS2 via DRBD permite que um par de servidores execute dual primary como armazenamento em cluster. Seus frontends da Web seriam extraídos desse par compartilhado. Você poderia ter várias cabeças compartilhando uma única mídia FC conectada usando também, ou, poderia usar o NFS para ter um único sistema de arquivos compartilhado usado por cada front-end da web. Se você usa o NFS com o DRBD, lembre-se de que você só pode executá-lo no modo primário / secundário devido à falta de bloqueios do cluster. Isso poderia reduzir seu throughput potencial pela metade.

O GlusterFS parece mais com o que você está procurando. Ele terá algumas peculiaridades exclusivas, ou seja, arquivo solicitado no nó que ainda não o possui, a pesquisa de metadados diz que ele está lá, é transferido de um dos nós replicados e depois é exibido. A primeira vez solicitada em um nó terá algum atraso dependendo do tamanho do arquivo.

O OpenAFS também é outra possibilidade. Você tem armazenamento compartilhado, cada recurso local tem um conjunto local de itens usados recentemente. Se o mecanismo de armazenamento ficar inativo, seus pools de recursos locais ainda serão veiculados.

O HDFS do Hadoop é outra alternativa que apenas "funciona". Um pouco complicado de configurar, mas também atenderia aos seus requisitos. Você terá muito conteúdo duplicado ao usar um sistema de arquivos distribuído.

Outro método sujo seria ter caches sendo executados em cada um de seus front-ends da Web que extraem conteúdo estático / carregado de uma única máquina e usam Varnish em cada um dos frontends para manter uma versão em cache de sua cópia única. Se a sua única máquina falhar, o Varnish armazenará em cache os itens existentes até o período de tolerância, e novos itens serão perdidos.

Grande parte disso se baseará na confiabilidade de um back-end que você precisa. Sistemas de arquivos distribuídos onde suas máquinas locais são um nó replicante provavelmente terão vantagem sobre a velocidade, já que não envolvem operações de rede para obter os dados, mas, com os cartões gigE e 10G sendo baratos, você provavelmente não experimentará latência significativa .

    

Answer 2

Todos os sistemas de arquivos em cluster têm uma fraqueza central: se uma determinada porcentagem dos sistemas ficarem offline, todo o sistema de arquivos será inútil, mas os nós que ainda estão ativos podem não lidar com isso graciosamente.

Por exemplo, suponha que você tenha 30 servidores em um rack e queira compartilhar seu espaço local. Você constrói um sistema de arquivos em cluster e até o constrói para que, se apenas um nó ficar inativo, os dados tenham sido replicados em outros nós suficientes para que não haja problemas. Por enquanto, tudo bem. Então um cartão no switch Ethernet morre. Essa opção interconecta todos os nós em seu cluster. O cartão desliga a comunicação para 15 de seus 30 nós. As perguntas que você precisa fazer são:

1. Se este cenário está bem para você, então quão gracioso é o fracasso? Os processos param até que a comunicação seja restaurada ou você precisa fazer o login e reinicializar todos os sistemas para recuperar o controle?
2. O seu cliente irá pendurá-lo para secar quando sofrer um interruptor ou falha de energia no rack? Nesse caso, considere distribuir seus nós pelo data center ou fazer com que cada nó seja alimentado em dois switches e vincule as interfaces. Alguma mágica de troca também precisará ocorrer, então encontre um administrador de rede.

Pense duas etapas adiante e o que o sistema fará em caso de falha de qualquer componente principal, incluindo cabos de rede ou de energia.

Agora você está pronto para um sistema de arquivos em cluster e todas as palavras de um milhão de novos jargões que você não conhecia antes.

    

Answer 3

Usamos o NFS das caixas NetApp ou os volumes OCFS2 dos FC LUNs, não sei se são as melhores opções, mas funcionam há anos para nós. Certamente, ambos funcionam perfeitamente adequadamente, embora eu prefira pessoalmente a opção OCFS2 over FC LUN, já que sou mais um cara de armazenamento. Eu acho que realmente se resume a qual infraestrutura de armazenamento compartilhado você já tem e está confortável.