Sistema de arquivos distribuído, paralelo e tolerante a falhas

6

Existem tantas opções que é difícil saber por onde começar. Minhas exigências são estas:

  • Executa no Linux
  • A maioria dos arquivos terá entre 5 e 9 MB de tamanho. Haverá também um número significativo de pequenos jpgs (100px x 100px).
  • Todos os arquivos precisam estar disponíveis em http.
  • Redundância - idealmente ele forneceria a eficiência de espaço similar ao RAID 5 de 75% (no RAID 5 isso seria calculado assim: com 4 discos idênticos, 25% do espaço é usado para paridade = > 75% de eficiência )
  • Deve suportar vários petabytes de dados
  • escalonável
  • é executado em hardware de commodity

Além disso, procuro essas qualidades, embora não sejam "requisitos":

  • Sistema de arquivos estável e maduro
  • Muita dinâmica e suporte
  • etc

Eu gostaria de receber algumas informações sobre qual sistema de arquivos funciona melhor para os requisitos fornecidos. Algumas pessoas da minha organização estão se inclinando para a MogileFS, mas não estou convencido da estabilidade e do momento desse projeto. GlusterFS e Lustre, baseados em minha pesquisa limitada, parecem ser melhor suportados ...

Pensamentos?

    
por Eddified 05.11.2009 / 01:55

5 respostas

4

Se fosse eu, estaria usando o GlusterFS. A versão atual é bastante sólida e conheço pessoas em instalações muito grandes, tanto no HPC quanto no espaço da Internet, que dependem dela em seus sistemas de produção. Você pode basicamente adequá-lo às suas necessidades, colocando os componentes como você precisa deles. Ao contrário do Lustre, não há servidores de metadados dedicados, portanto, os pontos centrais de falha são minimizados e é mais fácil dimensionar a configuração.

Infelizmente, não acho que haja uma maneira fácil de atender aos seus critérios de 75% sem prejudicar o desempenho.

Ele roda em hardware comum, mas o desempenho realmente brilha ao usar a interconexão Infiniband. Felizmente, o preço do IB é realmente muito baixo nos dias de hoje.

Você pode querer verificar os caras da > Scalable Informatics e seus produtos da Jackrabbit como uma solução. Eles suportam o GlusterFS em seus hardwares, e o preço de sua solução certamente rivaliza com o custo de montar algo do zero.

    
por 05.11.2009 / 04:01
6

Na verdade, não acho que existam muitas opções realistas. Em ordem de preferência, minhas escolhas seriam:

  1. Amazon S3 . Atende todos os seus requisitos e suas qualidades opcionais também. Tem um histórico muito bom de tempo de atividade e suporte. Não é em casa; mas isso não é realmente um requisito que você poderia contornar, f.x. usando o acesso VPN ou apenas um bom e velho HTTPS ... O S3 seria realmente a minha primeira escolha, se a latência da WAN e O trabalho de precificação da Amazon para você. E se o preço não funcionar para você, bem, eu duvido que uma solução DYI realmente acabe significativamente mais barata ...
  2. O MogileFS parece se adequar perfeitamente às suas necessidades. Não há muita atividade em torno do MogileFS, mas isso é principalmente porque ele está funcionando como planejado para seus (relativamente poucos) usuários.
  3. Lustre tem realmente excelente tecnologia por trás dele, é um sistema de arquivos POSIX local regular (se isso é benéfico para você) e tem sido continuamente atualizado ao longo dos anos. A grande questão é se toda a fusão Sun - Oracle terá impacto no Lustre. A longo prazo, se a Sun jogar suas cartas corretamente, ter ZFS e o Luster sob o mesmo teto pode levar a coisas muito boas. .. Agora, acho que o Lustre é usado principalmente em iniciativas de HPC acadêmicas e comerciais e não em aplicativos da Internet - isso pode não ser verdade, mas se o Lustre está indo bem em aplicativos da Internet, eles não estão divulgando bem esse fato ...

O Hadoop Distributed File System (HDFS) não corresponde aos seus requisitos IMHO. O HDFS é incrível, mas sua abordagem tipo bigtable significa que ele é menos acessível que os sistemas de arquivos acima. É claro que, se você está realmente procurando escalabilidade massiva e uma perspectiva de longo prazo, então o HDFS pode estar certo - com o Yahoo, o Facebook e outros envolvidos no crescimento do Hadoop.

Um comentário, a maioria dos sistemas acima copia o arquivo inteiro para 2-3 nós para obter redundância. Isso ocupa mais espaço que os esquemas de codificação de paridade / RAID, mas é gerenciável em escala e parece ser a solução que todos adotaram. Então você não terá a eficiência de 75% que você mencionou ...

    
por 05.11.2009 / 02:56
1

Ele pode não atender a todos os seus requisitos, especialmente a eficiência de espaço (por padrão, ele divide cada bloco em 10 compartilhamentos, sendo que 3 podem fornecer recuperação (embora isso possa ser reduzido)), mas você ainda pode querer veja Tahoe-LAFS .

Ele é projetado principalmente para backup, mas as pessoas criaram (e ainda estão criando) muitos aplicativos interessantes de não backup sobre ele. Um dos desenvolvedores hospeda o blog dele, por exemplo.

GPL, escrito em Python. Já está incluído no Ubuntu, IIRC.

    
por 24.02.2010 / 21:41
1

O sistema de arquivos Moose parece adequado às suas necessidades. Ele roda no Linux (por exemplo, Ubuntu ou Debian) e hardware de commodity. O armazenamento pode ter até 16 exabytes (~ 16.000 petabytes). Além disso, é maduro (lançado em 2008), sistema de arquivos distribuídos tolerante a falhas com grande suporte.

    
por 26.06.2018 / 17:02
0

Complementando a resposta de Kamil, você pode forçar a replicação de dados no GlusterFS após uma falha no nó de armazenamento, tentando ler de todos os arquivos no GFS - AFAIK, não há maneira mais fácil de dizer quais arquivos requerem replicação.

O comando abaixo pode ajudar - essencialmente chama head -c1 em cada arquivo e registra sucesso / falhas em /tmp/gfs-check.log

find /mnt/gfs ! -type d \( \( -exec head -qc1 '{}' + \
    -fprintf /tmp/gfs-check.log "%p OK\n" \) -o \
    -fprintf /tmp/gfs-check.log "%p ERROR\n" \) > /dev/null
    
por 06.01.2010 / 13:36