O que exatamente o Gluster faz?

Eu tenho jogado com gluster nos últimos 2 dias e tenho feito perguntas aqui e no sistema de perguntas deles. Eu realmente não entendo algumas coisas. Eu vejo pessoas dizendo coisas como

Configure tijolos replicados entre os servidores (como você está usando apenas 3, a replicação seria mais segura) e cada servidor verá os arquivos de todos os outros servidores como 'locais' - mesmo se um servidor falhar, os arquivos foram replicados para os outros servidores.

ou

O Gluster manterá a sincronização de arquivos entre os volumes (tijolos) e possui recursos de 'autocorreção' que lidarão com qualquer inconsistência devido ao fato de um servidor estar offline.

Como monto um volume remoto do servidor para o (s) cliente (s), como o gluster lida com a falha do nó do servidor, aquele em que os volumes são montados? Pelo que tentei, a pasta no cliente onde o volume foi montado se torna inacessível e eu tenho que usar umount para desbloqueá-lo. E depois disso, não há conteúdo do servidor.

Isto é, basicamente, o que não vejo coberto em explicações: o que acontece quando o nó do servidor falha e se é possível replicar realmente o conteúdo, como unison ou rsync?

Recentemente, começamos a pesquisar o GlusterFS para nosso próprio uso, portanto essa pergunta foi interessante para mim. O Gluster usa o que é chamado de 'tradutores' no cliente FUSE para lidar com a maneira como você armazena dados. Existem vários tipos de tradutores descritos aqui:

http://www.gluster.com/community/documentation/index.php/GlusterFS_Translators_v1.3

O que você está perguntando especificamente é chamado de Automatic File Replication Translator ou AFR, e é abordado em detalhes aqui:

http://www.gluster.com/community/documentation/index.php/Understanding_AFR_Translator

Observando o código fonte, parece que os dados são realmente gravados nos nós simultaneamente, muito melhor que o rsync!

Em relação à recuperação de uma situação de falha, há uma nota interessante que encontrei. O sistema Gluster é diferente do Ceph, pois não está ciente das alterações no estado de replicação e precisa ser 'acionado'. Portanto, se você perder um nó no cluster, precisará procurar cada arquivo para que o Gluster verifique se ele é replicado:

http://www.gluster.com/community/documentation/index.php/Gluster_3.2:_Triggering_Self-Heal_on_Replicate

Não consegui encontrar uma boa página descrevendo os mecanismos do cenário de falha internamente, como a maneira como o cliente detecta que as coisas estão quebradas. No entanto, ao baixar o código-fonte e procurar no cliente, parece que existem vários tempos limite que ele usa para comandos e um probe que ele faz de vez em quando para outros sistemas no cluster. Parece que a maioria deles tem marcas TODO e não é configurável no momento, exceto pela modificação do código-fonte, o que pode ser uma preocupação para você se o tempo de convergência for crítico.

Com apenas 2 nós replicando, o gluster não é muito diferente de um script rsync automático. As coisas só começam a ser interessantes quando você tem 4 ou mais nós de armazenamento - as máquinas clientes veem um espaço de espaço, mas os arquivos constituintes estão espalhados por todos os nós de armazenamento (tijolos). Isso significa que, se seus 4 servidores tiverem 10 TB de espaço local, as máquinas clientes poderão ver um único espaço para nome de 20 TB (replicado ou 40 TB de armazenamento desprotegido).

Eu vi um breve soluço - talvez 30 segundos ou mais - em uma máquina cliente quando ele tenta IO depois que um bloco de armazenamento se torna indisponível. Após o soluço, no entanto, o IO continuará normalmente enquanto houver servidores online que ainda mantêm um conjunto completo de dados de volume.

Você está descrevendo um comportamento inesperado - consultaria #gluster em irc.freenode.net ou gluster-users@gluster.org ou http://community.gluster.org/

-John Mark Gluster Comunidade

Quando o servidor que está enfrentando o cliente falha (ou seja, o servidor cujo IP / DNS foi usado pelo cliente para montar o sistema de arquivos), todo o volume fica offline para esse cliente, ou seja, não pode ler / gravar no volume.

No entanto, se o cliente o montou usando IP / DNS de outro servidor, o volume ainda estará online para esse cliente. No entanto, a leitura / gravação não irá para a instância com falha / falha.