Como os sistemas de arquivos de cluster evitam a miríade de possíveis condições de corrida?
Estou tentando usar um sistema de arquivos em cluster em uma arquitetura Master-Master. Estou pensando especificamente sobre o GlusterFS, então os detalhes da implementação são bem-vindos, mas espero uma resposta geral.
Um processo GlusterFS é composto por unidades funcionais modulares empilhadas chamadas "tradutores". Um tradutor de bloqueio é carregado como parte da pilha do servidor e as operações que podem correr são sincronizadas por este tradutor.
Por padrão, a CLI gluster gera uma configuração que inclui o tradutor "features / locks" como parte da pilha do servidor GlusterFS.
Diferentes sistemas de arquivos em cluster lidam com isso de maneiras diferentes. Fundamentalmente, o problema é como manipular qualquer outra estrutura de dados compartilhada em um cenário de acesso simultâneo (estruturas seguras de thread, por exemplo). Os dados no acesso ao disco são ordens de magnitude mais latentes e mais lentas (menos largura de banda) para serem acessados do que os dados armazenados na RAM. Dessa forma, os algoritmos empregados para lidar com a simultaneidade em um sistema de arquivos em cluster serão ajustados apropriadamente.
Um sistema de arquivos cluster "tradicional" como, por exemplo, o VERTIAS Cluster Filesystem, usa um gerenciador de bloqueio e um processo mestre / escravo (com um mecanismo de fence) para manipular os metadados em disco.
Pessoalmente, não usei o GlusterFS e não posso dizer que estou familiarizado o suficiente com a arquitetura para fazer comentários inteligentes. Pelo que estou lendo, GlusterFS parece mais um mecanismo sofisticado para "colar" sistemas de arquivos não-agrupados em nós de armazenamento individuais e não um sistema de arquivos de cluster "tradicional" (onde vários clientes acessam diretamente os mesmos dispositivos de bloco). Você pode obter alguns bons detalhes aqui (embora eu não saiba como esses detalhes permanecem atuais nas versões mais recentes): link