Alguém pode explicar essa configuração do GlusterFS?

Question

Depois de pesquisar para entender como configurar a replicação usando o gluster, me deparei com essa pergunta: O Apache pode ler o Brick GlusterFS diretamente mas gravar no GlusterFS?

Eu também encontrei uma forma que parece explicar a mesma coisa, e eu pensei que eu entendi, mas agora eu acho que não.

Então, para obter esse kinf de replicação, preciso que as duas máquinas funcionem como servidores e clientes de uma só vez? Agora não entendo como funciona o relacionamento: não é B, por exemplo, um cliente de A?

Há mais de um nível de relacionamento cliente-servidor envolvido? É um cliente para A e B um cliente para B, cada montagem em uma pasta de um volume da mesma máquina e esses dois volumes de alguma forma estão em sincronia (de A para B) em uma terceira camada de relacionamentos?

Por que a pergunta acima está perguntando sobre como gravar no sistema de arquivos ou no volume montado? Quando faço B um cliente para A, com A exportando uma pasta e B montando-a como um volume remoto em uma pasta, nunca me perguntei o que estava escrevendo: escrevi na pasta original em A e no volume montado em B. Não é assim que deveria funcionar?

    

Answer 1

Digamos que você tenha duas máquinas, A e B. Em cada máquina, você exporta /opt/files como um bloco Gluster e configura a replicação do lado do cliente. Em seguida, montamos o diretório resultante como /mnt/gluster-files em ambas as máquinas. Isso é importante!

Usando esse ponto de montagem, agora temos um sistema de arquivos altamente disponível nas duas máquinas.

Quando você escreve um arquivo - digamos /mnt/gluster-files/example na máquina A, isso fará com que duas coisas aconteçam:

1. Escreva uma cópia para /opt/files
2. Envie uma cópia pela rede para ser gravada em /opt/files na máquina B.

Isso é bom, porque queremos ter redundância, o que significa que precisamos ter mais de uma cópia dos dados.

Em seguida, digamos que queremos ler o mesmo arquivo. Novamente na máquina A:

1. Você emite uma leitura para /mnt/gluster-files/example
2. O GlusterFS diz "Preciso verificar todos os nós de réplica para descobrir quem tem a versão mais recente desse arquivo"
3. O GlusterFS verifica cada nó
4. Acontece que todas as cópias são iguais, porque a replicação está funcionando bem
5. Você retorna o arquivo do disco local. §

(§ Existe uma opção read-subvolume client, e é sensato configurá-la para o volume local em qualquer máquina que seja cliente e servidor Gluster, como neste caso. Caso contrário, o passo 5 poderia ser 'você é enviou o arquivo de um nó aleatório '.)

Nos bastidores, o GlusterFS mantém /opt/files nas duas máquinas em sincronia. Verificar todos os nós, especialmente para um grande número de arquivos pequenos, adiciona uma penalidade de desempenho não insignificante.

A pergunta é levantada: se estou executando um processo em uma dessas duas máquinas e sei que os arquivos estão em sincronia, por que não posso simplesmente ler os arquivos do compartilhamento local?

Não é recomendado, mas você pode fazer isso. Leia os arquivos de /opt/files . Acompanhe manualmente se você sair da sincronização e, se fizer isso, faça algo como ls -laR in /mnt/gluster-files , que acionará uma sincronização.

Então, o que acontece se você escreve em /opt/files na máquina A?

O arquivo fica lá sem ser notado pelo GlusterFS. Gluster não funciona assim. Ele não entra na máquina B, a menos que você faça alguma coisa que faça com que a Gluster a note na máquina A.

Portanto, você não pode simplesmente dizer ao Apache para ler e escrever em /opt/files . O que parece ser um bom compromisso é dizer para ler /opt/files , mas escreva para /mnt/gluster-files . Isso só é possível se seu aplicativo permitir que você especifique um caminho diferente para ler e gravar arquivos, o que muitos não fazem.