DRBD como DR: sincronizando datastores de 2 hosts ESXI, consistência vmdk?

Question

alguém tem experiência em usar o DRBD (protocolo C) para sincronizar partes dos datastores de 2 hosts esxi para recuperação de desastre de convidados selecionados?

Eu tenho de 2 a 3 convidados que devem se recuperar da falha de hardware do host no menor tempo possível, mas ainda com intervenção manual e sem perder muitos dados.

Gostaria de criar algo assim:

1 VM DRBD em cada um dos dois hosts esxi que sincronizam seu armazenamento SAS local (primário / secundário, ativo / passivo).

Esse armazenamento espelhado deve ser anexado a apenas 1 host esxi de cada vez via ISCSI ou NFS e ser usado para que os convidados tornem seus vmdks sincronizados com o segundo host esxi "passivo". No caso de uma falha de hardware, o segundo host esxi deve anexar o armazenamento DRBD para ligar essas VMs (feito manualmente, é claro).

Eu encontrei algumas informações sobre como fazer isso na net, mas o que eu não encontrei nenhuma informação é a consistência das vmdks.

Embora isso não seja um substituto dos backups, as ferramentas de backup dos hipervisores geralmente garantem que os sistemas de arquivos e os bancos de dados dos convidados sejam desativados antes de fazer a captura instantânea ou o backup.

Com essa sincronização contínua, isso não seria possível. É por isso que me pergunto se isso vale a pena.

E se as próprias vmdks forem danificadas porque a falha de hardware ocorre em um momento ruim. Eu sei que o DRBD descarta gravações que não são completas, mas é suficiente para ter um consistente (significando "trabalhar" do ponto de vista do esxi, além da consistência do sistema de arquivos convidado que obviamente não pode ser garantida desta forma) vmdk?

Espero que, no caso de um acidente, um convidado trazido no segundo esxi se comporte como se a VM simplesmente desligasse indevidamente (com todas as possíveis desvantagens que isso normalmente poderia ter em outros cenários), mas isso realmente é o caso? Os vmdks como um todo não foram danificados?

Muito obrigado pela leitura e pelos seus pensamentos.

Máximo

    

Answer 1

Eu fiz extensos testes com scenerio como você descreveu. Eu tentei ter um servidor de armazenamento com capacidade de failover usando DRBD, em seguida, usando iSCSI para anexar esse armazenamento a máquinas Debian que executam o Xen. Eu rapidamente desisti disso, porque eu tive muitos problemas. Parte deles poderia ser eu, no entanto. Um deles foi que os dispositivos de bloco iSCSI não foram criados .

Então eu tentei fazer duas máquinas Xen do Debian e ter os dispositivos de bloco LVM nos quais as VMs residem replicadas com o DRBD. Eu tive erros de barreira do sistema de arquivos para superar.

Então, meu desempenho foi ruim, o que rastreei até as opções al-extents . A versão do DRBD que eu usei, 8.3, tinha um valor padrão muito baixo. Eu aumentei para 3833, já que eu não me importo com o tempo de ressincronização ligeiramente maior.

Eu também fiz um monte de experimentos com poder de matar para nós. O DRBD foi muito gracioso com isso. A VM respondeu como você espera: colocar on-line no outro nó correu bem, apenas dizendo que estava recuperando seu diário. Reiniciar o nó também ressincronizou claramente o dispositivo. É claro que a falha real do nó é muitas vezes feia com discos que funcionam pela metade, tráfego de rede, etc., o que é difícil de prever. Você é inteligente para promover apenas um escravo manualmente.

Estou executando a configuração há cerca de dois anos. O nó ainda não falhou :), nem o DRBD.

Em meus testes, achei muito mais conveniente não ter um servidor de armazenamento central com failover, mas sim executar o Xen no primário e secundário do DRBD. A configuração do iSCSI é algo que eu gostaria de tentar novamente, mas isso não acontecerá tão cedo.

Além disso, não trabalho com arquivos de imagem, mas com dispositivos de bloco LVM. Isso se mostrou mais robusto para mim. Snapsnotting no LVM é possível, por um.

Uma coisa engraçada de se notar: o DRBD tem um modo que permite que ele seja executado sem disco no nó primário. Uma vez eu tive uma falha de disco no meu nó Xen primário que passou despercebido (o kernel MD não chutou a unidade, mas eu tinha erros constantes do ATA). Durante semanas sem saber, a VM funcionou bem no modo sem disco, usando o outro servidor como armazenamento:)