Isso é complicado com uma implementação Gluster de dois nós.
O primeiro problema que encontramos é o tratamento das condições do cérebro dividido, que você estaria criando intencionalmente. No cenário que você descreve, você estará modificando apenas um nó e modificando outro fora da replicação do cliente do Gluster. O Gluster em si não é tradicionalmente replicado entre nós, mas depende de clientes para gravar e ler de todos os nós simultaneamente em um método de fan-out. Por causa disso, as máquinas cliente são as principais responsáveis pela "replicação", em vez de uma replicação de servidor para servidor. Portanto, precisamos ter certeza de que os clientes podem acessar todos os nós da Gluster em todos os momentos.
Quando você coloca este volume online com os dois tijolos ligados a ele depois de causar um cérebro dividido, você verá que o Gluster se recusa a ativar o volume até que você conserte o problema do cérebro dividido manualmente no bloco nível. Ele fará o favor de dizer-lhe o que é o cérebro partido, mas você já sabe disso porque você teria sido a parte diretamente responsável. Isso ocorre porque existem apenas dois nós e nenhum terceiro nó para atuar como um desempatador ao analisar se os dados devem ser sobrescritos de uma cópia "dominante". 3n Os volumes do Gluster podem se auto-curar na maioria das situações, mas não garantem o tipo de comportamento que você deseja.
Para evitar isso, é necessário repensar seriamente a estratégia, caso você ainda pretenda usar o GlusterFS. Gluster não é projetado com a intenção de dividir o cérebro intencional, nem é um sistema tradicional de "failover". Ele foi projetado para ser acessado em todos os nós simultaneamente e pode lidar com uma falha de nó usando uma regra de maioria (ou intervenção manual offline prolongada).
Uma solução razoável do GlusterFS :
Você poderia criar um novo volume GlusterFS em seus nós e montá-lo no nó para o qual pretende gravar seu novo conteúdo da Web após parar o serviço por meio do HAproxy. Em seguida, mude para esse nó e monte o mesmo volume do GlusterFS no outro nó. Descarte o antigo volume do Gluster após terminar.
Isso mudaria seus passos assim:
1) Como vou usar o HaProxy como um balanceador de carga, posso alterar o status de node1 para manutenção e deixar o node2 lidar com todo o tráfego.
2) Crie um novo volume GLusterFS a partir de novos tijolos em ambos os nós e monte esse volume no diretório app / web do nó no modo de manutenção, desmontando o volume original primeiro.
3) Copie todos os dados relevantes novos e inalterados para este novo volume do Gluster.
4) A partir do HaProxy, desative o node2 para manutenção e pegue o node1 para lidar com o tráfego.
5) Monte o novo volume do Gluster no nó 2, primeiro retirando o antigo
6) deixe que o HAproxy carregue os serviços de saldo novamente, pois teremos um cluster ativo / ativo ativo novamente.
7) Livre-se do antigo volume do GlusterFS quando não precisarmos mais dele.
Isso garantirá que você mantenha seu serviço on-line e não receba uma condição horrível de cérebro dividido. Em relação aos seus tijolos: um tijolo é apenas um diretório e não precisa ser um sistema de arquivos separado. Você pode fazer com que o seu novo bloco esteja no mesmo sistema de arquivos que o antigo, simplesmente usando um diretório diferente na raiz desse sistema de arquivos. Dessa forma, você não precisa de um monte de espaço em disco para fazer uma atualização do serviço online.
Uma solução alternativa :
O DRDB manipula dados em um anel de replicação de servidor para servidor e você pode forçar um nó a replicar para outros arbitrariamente. Não é tão bom para clusters de carga ativa / ativa e balanceada, já que você teria que usar um sistema de arquivos como o OCFS2 em cima dele. No entanto, é um sistema de replicação tradicional que seria de bom grado aderir ao seu plano atual.
Esclarecimento :
Você não precisa de um cluster de três nós para implementar o plano GlusterFS que descrevi acima. Dois nós farão bem.