Com Hadoop e CouchDB em Blogs e notícias relacionadas, o que é um armazenamento (engine) tolerante a falhas distribuídas que realmente funciona.
Então a questão é qual sistema de arquivos distribuído tem o seguinte conjunto de recursos (sem ordem particular):
É bom ter:
Eu não estou procurando por aplicativos hospedados, algo que me permita usar 10 GB de cada uma de nossas caixas de hardware e ter esse armazenamento disponível em nossa rede, facilmente montável em uma infinidade de anfitriões.
Eu acho que você terá que abandonar o requisito POSIX, muito poucos sistemas implementam isso - na verdade, mesmo o NFS não (realmente acha bloqueios, etc) e isso não tem redundância.
Qualquer sistema que usa replicação síncrona será lento demais; qualquer sistema que tenha replicação assíncrona (ou "consistência eventual") violará as regras POSIX e não se comportará como um sistema de arquivos "convencional".
Não consigo falar com o resto, mas parece que você está confuso entre um 'mecanismo de armazenamento distribuído' e um 'sistema de arquivos distribuído'. 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 rastrear onde as coisas estão localizadas em um disco rígido. Um mecanismo de armazenamento como o hadoop é uma maneira de rastrear uma parte dos 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 é?
Além disso, eu posso falar sobre o uso de ocfs2 como um sistema de arquivos distribuído em um ambiente de produção. Se você não quer os detalhes, pare de ler depois desta linha: É legal, mas pode significar mais tempo de inatividade do que você pensa.
Estamos executando o ocfs2 em um ambiente de produção nos últimos dois anos. Tudo bem, mas não é ótimo para muitos aplicativos. Você deve realmente olhar para as suas necessidades e descobrir o que elas são - você pode achar que tem muito mais latitude para falhas do que você pensou ter feito.
Como exemplo, o ocfs2 tem um diário para cada máquina no cluster que montará a partição. Então, digamos que você tenha quatro máquinas web, e quando você fizer essa partição usando mkfs.ocfs2, você especificará que haverá seis máquinas no total para dar a si mesmo algum espaço para crescer. Cada uma dessas revistas ocupa espaço, o que reduz a quantidade de dados que você pode armazenar nos discos. Agora, digamos que você precisa escalar para sete máquinas. Nessa situação, você precisa desmontar o cluster inteiro (ou seja, desmontar todas as partições ocfs2) e usar o utilitário tunefs.ocfs2 para criar um diário adicional, desde que haja espaço disponível. Então, e só então, você pode 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), restaurar tudo e montar a partição em todos os sete. máquinas.
Veja o que quero dizer? É suposto ser alta disponibilidade, o que significa "sempre online", mas aí você tem um monte de tempo de inatividade ... e Deus me livre de que você esteja lotado de espaço em disco. Você não quer ver o que acontece quando você mistura ocfs2.
Tenha em mente que o evms, que costumava ser o modo 'preferido' para gerenciar clusters ocfs2, foi o caminho do pássaro Dodô em favor de clvmd e lvm2. (E boa viagem para as evas.) Além disso, o batimento cardíaco rapidamente se transformará em um projeto de zumbis em favor da pilha openais / marcapasso. (Além: Ao fazer a configuração inicial do cluster para ocfs2, você pode especificar 'pcmk' como o mecanismo do cluster em oposição à pulsação. Não, isso não está documentado.)
Por que vale a pena, voltamos para o nfs gerenciado pelo marca-passo, porque os poucos segundos de inatividade ou alguns pacotes tcp descartados, à medida que o marca-passo migra um compartilhamento nfs para outra máquina, são triviais em comparação com a quantidade de tempo de inatividade vendo as operações básicas de armazenamento compartilhado, como adicionar máquinas ao usar o ocfs2.
Só para jogar meus 0,02 € aqui: não é possível OpenAFS fazer o que você quer?
Que tal Xtreemfs ? versão 1.4 (novembro de 2012) é considerada Qualidade de Produção.
É compatível com POSIX e possui excelente tolerância automática a falhas.
O Lustre permite vários armazenamentos de metadados na configuração ativa / passiva para redundância, portanto, nenhum ponto único de falha.
O OCFS2 também pode valer a pena ser visto.
Note que cortar o requisito de múltiplos acessos simultâneos à rede torna possível mudar para algo como iSCSI ou até mesmo cifs ou nfs. A desvantagem é que você tem que 'esculpir' pedaços do seu uberArray em mordidas para cada servidor que precisa de espaço.
Eu posso estar entendendo mal suas exigências, mas você analisou o link
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 está madura o suficiente para uma implantação séria - por exemplo, o que você faz se a coisa toda se esvair. Se é para fins acadêmicos / de desenvolvimento, então isso é realmente uma coisa boa, pois você pode aprender muito e consertar muitos bugs.
O comentário questionando se você realmente precisa da semântica 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 este é um aplicativo legado, eu realmente me pergunto por que um sistema de arquivos distribuído moderno pode ser considerado a melhor solução.
Não me entenda mal - estes são brinquedos incrivelmente divertidos. Eu simplesmente não gostaria de ser responsável por uma solução complexa e interdependente que não é comumente usada e que seria muito difícil de consertar quando se solta.
Você realmente precisa absolutamente positivamente da semântica POSIX? A vida fica muito mais fácil se você puder usar um datastore personalizado. Temos um armazenamento de dados escrito 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. Ele é distribuído, é nada compartilhado, os dados são replicados três vezes, os nós podem ser adicionados e removidos à vontade, tanto nos servidores de armazenamento quanto nos servidores de controle.
Lustre also has a single point of failure as it uses a dedicated metadata server
O Lustre é projetado para oferecer suporte a failover e um MDS / MDT / OSS pode ter vários endereços nos quais ele pode ser contatado, e o heartbeat pode ser usado para migrar o serviço.
Esteja ciente de que algumas versões recentes tiveram problemas em que a desmontagem parece funcionar, mas ainda há dados em andamento para o disco. Entretanto, a proteção de montagem dupla deve ter ajudado (além das questões interessantes que tiveram) ... .
Eu recomendo que você use MooseFS (tolerante a falhas, dimensionamento, sistema de arquivos distribuídos pela rede). É compatível com POSIX e desde a versão 1.6 do MooseFS oferece uma autenticação / autorização simples, semelhante ao NFS. Consulte também requisitos de hardware .