DRBD / Heartbeat em máquinas virtuais

Question

Alguém tem experiência em configurar drbd com heartbeat entre duas máquinas virtuais Linux (VMWare Infrastructure)?

O problema que estou encontrando é que o heartbeat gosta de vários caminhos de dados para ver o seu nó de mesmo nível. Por exemplo, ele gosta de ter uma conexão de rede com o peer, talvez um para seu gateway, e um cabo serial para seu peer - melhorando a probabilidade de que quando ele detecta uma falha de peer, ele esteja realmente inoperante e não devido a congestionamento de rede ou algo.

Em uma máquina virtual, no entanto, a porta serial e a porta ethernet (e todas as outras portas) são virtuais - então, realmente, há apenas um caminho de dados (correto?)

(Eu sei que o VMWare suporta cabos seriais físicos entre dispositivos, mas nossos VMs são hospedados remotamente, e cabos físicos impediriam migrações de host, o que não é aceitável.)

No nosso caso, estamos vendo tempos limites entre os pares de heartbeat, mesmo que eles estejam sendo executados na mesma máquina host.

Como posso configurar o drbd / heartbeat para ser mais robusto quando executado em máquinas virtuais

    

Answer 1

Você observou se as VMs reclamam de interrupções interrompidas ou coisas semelhantes - talvez o hardware host esteja sobrecarregado ou não haja recursos suficientes alocados para suas VMs?

Se é uma rede escamosa ou sobrecarregada, a coisa certa a fazer seria, claro, consertar isso; mas se o seu provedor de hospedagem não estiver interessado nisso, você pode usar vários caminhos físicos conectando várias redes em ponte a diferentes dispositivos host (esperançosamente, em switches diferentes)?

O uso de caminhos de rede redundantes via 802.3ad também não poderia prejudicar.

Um comentarista em outra pergunta mencionou o cérebro dividido - uma coisa que você quer evitar a todo custo: Normalmente, um script STONITH, por exemplo, desative uma faixa de PDU em rede no outro host para que o outro host esteja inativo com certeza ; em uma VM, você pode tentar um script que desliga a outra VM por meio da API do VMware.

Finalmente - talvez o DRBD não esteja certo para o seu cenário. Se você tiver uma SAN, convém abrir o mesmo dispositivo na malha nas duas VMs como um disco bruto e depois executar o OCFS2 ou um cluster FS semelhante nele. Os amigos viram o OCFS2 rodar como um todo em até quatro nós simultaneamente, o que o liberaria para fazer clusters de vários nós com heartbeat2 em vez de ficarem bloqueados com failover de dois nós, como no heartbeat 1 by drbd.

Caveat emptor: heartbeat 2 usa arquivos de configuração XML. Nem todo mundo (por exemplo, eu) gosta disso.

    

Answer 2

O DRBD não só não usa um cabo serial, como o não pode ! Eu não tenho ideia do que você está falando!

Além disso, ele não faz o agachamento sobre vários caminhos de dados, apenas se comunica com o outro nó por meio de uma simples conexão TCP antiga. O roteamento do kernel, os switches, roteadores e firewalls lidam com isso, o DRBD tem nada para fazer com ele.

    

Answer 3

A ideia de ter vários caminhos de dados não é nova. É um conceito básico para evitar situações de divisão cerebral.

Mas você enfrenta exatamente o mesmo problema em servidores físicos - não entendo por que você vincula essa pergunta a VMs?

Vários caminhos de dados podem ser estabelecidos com hardware de rede fisicamente distinto - o que também faz sentido em grandes ambientes, quando você separa o back-end do fim da fonte dos servidores. Isso lhe daria duas redes, que você também pode acessar em VMs.

Se o DRBD e o heartbeat entrarem em ação, uma terceira rede distinta pode fazer sentido para a replicação de dados dedicada de alta velocidade (também recomendada para o iSCSI) - esta também pode ser a terceira rede hb.

Agora, com base na minha própria experiência: temos essas três redes separadas - que estão presentes nos servidores de VM e estão sendo conectadas às VMs também - para que possam executar o heartbeat em três linhas separadas ...

Outra possibilidade para evitar falhas de rede seria ligar dispositivos para as mesmas redes. Se não houver SPOF no seu sistema de rede - também uma boa solução (que lhe dá pelo menos uma rede HA).