Dual Primary OCFS2 O DRBD encontrou um cérebro dividido. A recuperação será sempre manual neste caso?

Question

Eu tenho dois servidores web, cada um com um disco conectado. Este disco é sincronizado entre eles usando drbd (2: 8.3.13-1.1ubuntu1) no modo 'dual primário', e por cima disso eu executo ocfs2 (1.6.4-1ubuntu1) como um sistema de arquivos em cluster . Os nós se comunicam em uma rede privada 192.168.3.0/24 . Na maior parte, isso é estável e funciona bem.

Ontem à noite, parece ter havido uma interrupção na rede. Isso resultou em um cenário de divisão de cérebro em que node01 foi deixado em Standalone e Primary , enquanto o node02 foi deixado em WFConnection e primary . A recuperação foi um processo manual nesta manhã de tentar diferenciar os dois sistemas de arquivos, decidindo que o node01 deveria ser autoritativo, colocando o node02 em secundário e, em seguida, emitindo os comandos drbdadm connect em cada nó. Remontando o sistema de arquivos depois disso e estamos de volta em funcionamento.

Minha pergunta é: esse tipo de interrupção sempre exigirá uma resolução manual? Ou existem maneiras pelas quais esse processo pode ser automatizado? Meu entendimento era que drbd deveria tentar ser inteligente no caso de um cérebro dividido em descobrir qual nó deveria se tornar primário e secundário. Parece que, neste caso, uma interrupção de rede simples deixou ambas no primário, que minha configuração apenas diz "desconectar". Olhando para os logs, o que eu acho interessante é o fato de que ambos pareciam concordar que node02 deveria ser o SyncSource, e ainda assim, ao olhar para o log do rsync, é na verdade node01 que tem as mudanças mais recentes. Também interessante é a linha em node01 afirmando 'eu me tornarei SyncTarget, mas eu sou primário!'. Para mim, parece que o drbd tentou resolver isso, mas falhou por algum motivo.

Existe uma maneira melhor de fazer isso?

A configuração para r0 é esta:

resource r0 {
    meta-disk internal;
    device /dev/drbd0;
    disk /dev/xvda2;

    syncer { rate 1000M; }
    net {
        #We're running ocfs2, so two primaries desirable.
        allow-two-primaries;

        after-sb-0pri discard-zero-changes;
        after-sb-1pri discard-secondary;
        after-sb-2pri disconnect;

    }
    handlers{
        before-resync-target "/sbin/drbdsetup $DRBD_MINOR secondary";

        split-brain "/usr/lib/drbd/notify-split-brain.sh root";
    }
    startup { become-primary-on both; }

    on node02 { address 192.168.3.8:7789; }
    on node01 { address 192.168.3.1:7789; }
}

Eu também coloquei os arquivos kern.log no pastebin:

Node01: link

Node02: link

    

Answer 1

IMHO você já escolhe a melhor política SB para DRBD. Então, no seu caso, teve que haver mudanças na mesma parte do sistema de arquivos (ou seja, bloco DRBD) em ambos os lados.

Então, nesse caso - sim - você tem que resolver isso manualmente.

A pergunta que me vem é por que esses acessos simultâneos aconteceram ?

Você deve investigar nessa direção. Se a rede estiver inoperante, não deve haver acesso de um lado, portanto, "descartar as alterações zero" deve ajudar - mas isso não aconteceu.

Além disso, você deve evitar cérebros divididos por ter duas ou mais conexões de rede INDEPENDENTES. Eu sempre uso três deles nos meus clusters.