Como configurar corretamente um sistema glusterfs de 2 nós?

Question

Eu estou tentando fazer um servidor linux de 2 nós com alto apache disponível usando o glusterfs 3.7.6 para replicação de dados e o pacemaker + corosync como gerenciador de recursos. No entanto, estou vendo um problema com gluster no cenário específico quando os dois nós são desligados e um deles fica on-line primeiro. Mesmo que haja um tijolo nesse nó e o serviço de gluster esteja em execução, não há nenhum processo em bloco.

[root@node1 ~]# gluster volume status data 
Status of volume: data
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick node1:/gluster_data                   N/A       N/A        N       N/A  
NFS Server on localhost                     N/A       N/A        N       N/A  
NFS Server on localhost                     N/A       N/A        N       N/A  

Task Status of Volume data
------------------------------------------------------------------------------
There are no active volume tasks

E quando eu inicio o outro nó, tudo parece funcionar e eu posso montar o volume.

[root@node1 ~]# gluster volume status data
Status of volume: data
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick node1:/gluster_data                  49152      0          Y       2674 
Brick node2:/gluster_data                  49152      0          Y       3086 
NFS Server on localhost                     N/A       N/A        N       N/A  
Self-heal Daemon on localhost               N/A       N/A        Y       2796 
NFS Server on node2                         N/A       N/A        N       N/A  
Self-heal Daemon on node2                   N/A       N/A        Y       3085 

Task Status of Volume data
------------------------------------------------------------------------------
There are no active volume tasks

E, neste ponto, se eu desligar o node2, o processo brick do node1 permanece ativo para que, pelo menos, eu possa montá-lo e usá-lo.

[root@node1 ~]# gluster volume status data

Status of volume: data
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick node1:/gluster_data                   49152     0          Y       2674 
NFS Server on localhost                     N/A       N/A        N       N/A  
Self-heal Daemon on localhost               N/A       N/A        Y       2796 

Task Status of Volume data
------------------------------------------------------------------------------
There are no active volume tasks

Portanto, minha observação é que, para o volume gluster funcionar, os dois nós precisam estar on-line pelo menos por um momento para que os blocos possam começar e, se um nó cair, isso não afetará a operação do volume. Então, como posso fazer isso funcionar quando um dos nós fica online de um apagão total?

    

Answer 1

O problema que qualquer nó de cluster tem quando chegar de um ponto final é:

Do I have the latest state, or not? I don't want to claim latest if I'm behind the other down nodes.

É por isso que o clustering inclui, com muita frequência, algum tipo de mecanismo de quórum, pelo que os nós existentes podem votar no estado e convergir para um consenso. Dois clusters de nó não podem usar esse mecanismo, pois nunca haverá uma partição "majoritária". Na versão 3.7, o Gluster ganhou um recurso de quórum.

link

Nesse documento, eles afirmam que os clusters de dois nós não podem usá-lo pela mesma razão que descrevi acima.

No seu caso, você pode querer considerar a criação de alguns nós somente de gerenciamento em sua configuração do Gluster. Estes seriam pares que são probed no cluster, mas não hospedam nenhum armazenamento. Sua razão inteira para existir seria manter o estado de cluster. Eles podem existir em diferentes racks, datacenters, fases de energia, para tentar garantir que eles estejam em um domínio de falha diferente dos blocos de armazenamento. Isso aumentará o número de membros em um cluster e aumentará suas chances de ter uma partição majoritária se um dos bricks de armazenamento aparecer sem o outro.

Infelizmente, o comportamento que você está vendo está funcionando como projetado e não pode ser alterado sem adicionar mais servidores ao cluster.