Sistema de arquivos de armazenamento distribuído - Qual deles / Existe um produto pronto para uso?

Com o Hadoop e o CouchDB em todo o Blogs e notícias relacionadas, o que é um armazenamento (mecanismo) tolerante a falhas distribuído que realmente funciona.

• O CouchDB, na verdade, não possui nenhum recurso de distribuição embutido, pelo que sei, a cola para distribuir entradas automaticamente ou mesmo bancos de dados inteiros está simplesmente ausente.
• O Hadoop parece ser amplamente utilizado - pelo menos, é bom para a imprensa, mas ainda tem um único ponto de falha: o NameNode. Além disso, ele só pode ser montado via FUSE, eu entendo que o HDFS não é realmente o principal objetivo do Hadoop
• O GlusterFS tem um conceito de nada compartilhado, mas ultimamente eu li vários posts que me levaram à opinião de que não é tão estável
• O Lustre também possui um único ponto de falha, pois usa um servidor de metadados dedicado
• O Ceph parece ser o player preferido, mas a página inicial afirma que ainda está nos estágios alfa.

Portanto, a questão é qual sistema de arquivos distribuído possui o seguinte conjunto de recursos (sem ordem específica):

• Compatível com POSIX
• fácil adição / remoção de nós
• conceito de nada compartilhado
• roda em hardware barato (processadores AMD Geode ou VIA Eden)
• autenticação / autorização incorporada
• um sistema de arquivos de rede (eu gostaria de montá-lo simultaneamente em diferentes hosts)

Bom ter:

• arquivos acessíveis localmente: posso desmontar um nó, montar a partição com um sistema de arquivos local padrão (ext3 / xfs / qualquer que seja ...) e ainda acessar os arquivos

Estou não à procura de aplicações hospedadas, em vez de algo que vai me permitir tomar dizer 10GB de cada uma das nossas caixas de hardware e ter essa armazenamento disponível em nossa rede, Facilmente montável em uma multidão dos exércitos.

Eu acho que você terá que abandonar o requisito POSIX, pouquíssimos sistemas implementam isso - na verdade, nem o NFS realmente (acha bloqueios etc.) e isso não tem redundância.

Qualquer sistema que use replicação síncrona será glacialmente lento; qualquer sistema que tenha replicação assíncrona (ou "consistência eventual") violará as regras do POSIX e não se comportará como um sistema de arquivos "convencional".

Não posso falar com o resto, mas você parece estar confuso entre um 'mecanismo de armazenamento distribuído' e um 'sistema de arquivos distribuídos'. Eles não são a mesma coisa, não devem ser confundidos com a mesma coisa, e nunca serão a mesma coisa. Um sistema de arquivos é uma maneira de acompanhar onde as coisas estão localizadas no disco rígido. Um mecanismo de armazenamento como o hadoop é uma maneira de acompanhar um grande número de dados identificados por uma chave. Conceitualmente, não há muita diferença. O problema é que um sistema de arquivos é uma dependência de um mecanismo de armazenamento ... afinal, ele precisa de uma maneira de gravar em um dispositivo de bloco, não é?

Tudo isso de lado, posso falar sobre o uso do ocfs2 como um sistema de arquivos distribuído em um ambiente de produção. Se você não quiser detalhes detalhados, pare de ler após esta linha: é bem legal, mas pode significar mais tempo de inatividade do que você pensa.

Temos executado o ocfs2 em um ambiente de produção nos últimos dois anos. Tudo bem, mas não é ótimo para muitas aplicações. Você deve realmente analisar seus requisitos e descobrir quais são - você pode descobrir que possui muito mais espaço para falhas do que pensava.

Como exemplo, o ocfs2 possui um diário para cada máquina no cluster que montará a partição. Então, digamos que você tenha quatro máquinas da Web e, quando criar essa partição usando mkfs.ocfs2, especifique que haverá seis máquinas no total para dar espaço para crescer. Cada um desses diários ocupa espaço, o que reduz a quantidade de dados que você pode armazenar nos discos. Agora, digamos que você precise escalar para sete máquinas. Nessa situação, você precisa derrubar toda acluster (ou seja, desmonte todas as partições ocfs2) e use o utilitário tunefs.ocfs2 para criar um diário adicional, desde que haja espaço disponível. Então, e somente então, você poderá adicionar a sétima máquina ao cluster (que requer a distribuição de um arquivo de texto para o restante do cluster, a menos que você esteja usando um utilitário), trazer tudo de volta e montar a partição nos sete máquinas

Entendeu o que eu quis dizer? Deveria ser alta disponibilidade, o que deveria significar 'sempre on-line', mas ali você tem um monte de tempo de inatividade ... e Deus não permita que você esteja lotado por espaço em disco. Você NÃO quer ver o que acontece quando você aglomera ocfs2.

Lembre-se de que evms, que costumava ser a maneira 'preferida' de gerenciar clusters ocfs2, seguiu o caminho do pássaro dodô em favor de clvmd e lvm2. (E boa viagem para evms.) Além disso, os batimentos cardíacos rapidamente se transformarão em um projeto de zumbi em favor da pilha de openais / marcapasso. (Além disso: ao fazer a configuração inicial do cluster para o ocfs2, você pode especificar 'pcmk' como o mecanismo de cluster, em vez da pulsação. Não, isso não está documentado.)

Pelo que vale a pena, voltamos aos nfs gerenciados pelo pacemaker, porque os poucos segundos de inatividade ou alguns pacotes tcp perdidos à medida que o pacemaker migra um compartilhamento nfs para outra máquina são triviais em comparação com a quantidade de tempo de inatividade que estávamos observando para o básico operações de armazenamento compartilhado, como adicionar máquinas ao usar o ocfs2.

Talvez eu esteja entendendo mal seus requisitos, mas você já consultou http://en.wikipedia.org/wiki/List_of_file_systems#Distributed_file_systems

Só para jogar aqui os meus € 0,02: o OpenAFS não pode fazer o que você quer?

Dê uma olhada em chirp http://www.cse.nd.edu/~ccl/software/chirp/ e papagaio http://www.cse.nd.edu/~ccl/software/parrot/

E o Xtreemfs ? A versão 1.4 (novembro de 2012) é considerada Qualidade da produção.

É compatível com POSIX e possui excelente tolerância automática a falhas.

O Luster permite vários repositórios de metadados na configuração ativa / passiva para redundância, portanto, nenhum ponto único de falha.

Também vale a pena olhar para o OCFS2.

Observe que, eliminando o requisito de acesso múltiplo à rede, é possível alternar para algo como iSCSI ou mesmo CIFs ou NFS. A desvantagem é que você precisa "esculpir" pedaços do seu uberArray em pedaços para cada servidor que precisar de espaço.

A menos que seja para fins acadêmicos / de desenvolvimento, esse tipo de coisa deve ser abordado a partir dos requisitos gerais do projeto. A maioria dos sistemas de arquivos distribuídos não é madura o suficiente para uma implantação séria - por exemplo, o que você faz se tudo acontecer. Se for para fins acadêmicos / de desenvolvimento, isso é realmente uma coisa boa, pois você pode aprender bastante e corrigir muitos bugs.

O comentário questionando se você realmente precisa da semântica do POSIX é um bom começo. A semântica de "sistema de arquivos" não POSIX pode ser muito mais flexível, levando a sistemas muito mais confiáveis.

Se esse é um aplicativo herdado, eu realmente me pergunto por que um sistema de arquivos distribuído moderno pode ser considerado a melhor solução.

Não me interpretem mal - estes são brinquedos incrivelmente divertidos. Eu só não gostaria de ser responsável por uma solução interdependente complexa que não é comumente usada e seria muito difícil de corrigir quando ela sair.

Você realmente precisa absolutamente semântica POSIX? A vida fica muito mais fácil se você pode usar um armazenamento de dados personalizado. Temos um armazenamento de dados gravado internamente que é efetivamente um armazenamento de valor-chave distribuído muito grande. Você armazena um arquivo nele e recebe um token de volta. Se você quiser o arquivo de volta, forneça o token que você recebeu anteriormente. É distribuído, não é compartilhado, os dados são replicados três vezes, os nós podem ser adicionados e removidos à vontade, servidores de armazenamento e servidores de controle.

O Lustre também possui um único ponto de falha, pois usa um servidor de metadados dedicado

O Luster foi projetado para oferecer suporte ao failover e um MDS / MDT / OSS pode ter um número de endereços nos quais pode ser contatado; a pulsação pode ser usada para migrar o serviço.

Esteja ciente de que algumas versões recentes tiveram problemas nos quais a desmontagem parece funcionar, mas ainda há dados em andamento no disco. No entanto, a proteção de montagem dupla deveria ter ajudado (além dos problemas interessantes que tivemos) ...

Eu recomendo que você use o MooseFS (sistema de arquivos distribuído em rede, tolerante a falhas, em expansão ). É compatível com POSIX e, desde a versão 1.6, o MooseFS oferece uma autenticação / autorização simples, semelhante ao NFS. Veja também requisitos de hardware .