ComHadoopeCouchDBem todos os blogs e notícias relacionadas, o que é um armazenamento (mecanismo) distribuído e tolerante a falhas que realmente funciona.
- Na verdade, o CouchDB não possui nenhum recurso de distribuição integrado; até onde sei, a cola para distribuir entradas automaticamente ou até mesmo bancos de dados inteiros simplesmente está faltando.
- O Hadoop parece ser amplamente utilizado - pelo menos recebe boa publicidade, mas ainda tem um único ponto de falha: o NameNode. Além disso, só pode ser montado via FUSE, entendo que o HDFS não é realmente o objetivo principal do Hadoop
- GlusterFStem um conceito de nada compartilhado, mas ultimamente li vários posts que me levam à opinião de que não é tão estável
- Brilhotambém tem um único ponto de falha, pois usa um servidor de metadados dedicado
- Cephparece ser o jogador preferido, mas a página inicial afirma que ainda está em fase 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
- funciona em hardware barato (processadores AMD Geode ou classe VIA Eden)
- autenticação/autorização integrada
- um sistema de arquivos de rede (gostaria de poder montá-lo simultaneamente em hosts diferentes)
Bom ter:
- arquivos acessíveis localmente: posso desativar um nó, montar a partição com um sistema de arquivos local padrão (ext3/xfs/qualquer coisa...) e ainda acessar os arquivos
Eu sounãoprocurando aplicativos hospedados, algo que me permita pegar, digamos, 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 hosts.
Responder1
Eu acho que você terá que abandonar o requisito POSIX, poucos sistemas implementam isso - na verdade, mesmo o NFS não (pense em bloqueios, etc.) e isso não tem redundância.
Qualquer sistema que use replicação síncrona será extremamente lento; 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".
Responder2
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ído'. 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 forma de controlar onde as coisas estão localizadas em um disco rígido. Um mecanismo de armazenamento como o hadoop é uma forma de rastrear um pedaço de dados identificado 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 forma de gravar em um dispositivo de bloco, não é?
Deixando tudo isso de lado, eupodefale 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: É muito legal, mas pode significar mais tempo de inatividade do que você pensa.
Temos executado ocfs2 em um ambiente de produção nos últimos dois anos. Tudo bem, mas não é ótimo para muitas aplicações. Você realmente deve analisar seus requisitos e descobrir quais são - você pode descobrir que tem muito mais liberdade para falhas do que pensava.
Por exemplo, ocfs2 possui um diário para cada máquina do cluster que irá montar a partição. Então, digamos que você tenha quatro máquinas web e, ao criar essa partição usando mkfs.ocfs2, especifique que haverá seis máquinas no total para ter 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 dimensionar para sete máquinas. Nessa situação, você precisa derrubar ointeirocluster (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 (o que requer a distribuição de um arquivo de texto para o resto do cluster, a menos que você esteja usando um utilitário), trazer tudo de volta e, em seguida, montar a partição em todos os sete máquinas.
Veja o que quero dizer? É suposto ser de alta disponibilidade, o que significa 'sempre online', mas aí você tem um monte de tempo de inatividade... e Deus me livre, você está lotado de espaço em disco. Você NÃO quer ver o que acontece quando você lota ocfs2.
Tenha em mente que o evms, que costumava ser a forma 'preferida' de gerenciar clusters ocfs2, seguiu o caminho do pássaro dodô em favor do clvmd e do lvm2. (E boa viagem para evms.) Além disso, o batimento cardíaco rapidamente se transformará em um projeto zumbi em favor da pilha openais/pacemaker. (Além disso: ao fazer a configuração inicial do cluster para ocfs2, você pode especificar 'pcmk' como o mecanismo do cluster em vez de pulsação. Não, isso não está documentado.)
Pelo que vale a pena, voltamos ao nfs gerenciado pelo marcapasso, porque os poucos segundos de tempo de inatividade ou alguns pacotes tcp descartados enquanto o marcapasso migra um compartilhamento nfs para outra máquina são triviais em comparação com a quantidade de tempo de inatividade que estávamos vendo para o básico operações de armazenamento compartilhado, como adicionar máquinas ao usar ocfs2.
Responder3
Posso estar entendendo mal seus requisitos, mas você já olhouhttp://en.wikipedia.org/wiki/List_of_file_systems#Distributed_file_systems
Responder4
Dê uma olhada no chilrearhttp://www.cse.nd.edu/~ccl/software/chirp/e papagaiohttp://www.cse.nd.edu/~ccl/software/parrot/