experimentação e virtualização DRBD

Question

Este foi um daqueles pensamentos que estavam fazendo cócegas no fundo da minha mente.

Estou trabalhando em um testbed caseiro de um cluster de alta disponibilidade que consiste em apenas computadores, não SAN ou NAS para armazenamento, apenas "se eu quisesse um servidor ou dois que estivessem disponíveis mesmo se o hardware falhasse e eu tivesse algumas máquinas antigas para fazer, posso fazer isso? " coisa. Pense no RAID-1 em um nível de hardware do sistema.

Eu estava pensando em tentar fazer isso instalando uma distribuição Linux, instalando o DRBD no modo primário / primário com o Pacemaker / STONITH e instalando o Xen para virtualizar o (s) servidor (es) que realmente forneceriam os sistemas para replicar.

Configurações recentes no trabalho com o VMWare ESXi fizeram com que eu me perguntasse se poderia haver algum tipo de vantagem ao usar o ESXi para instalar VMs Linux em algumas máquinas e usar o DRBD e o Pacemaker / STONITH para replicar os serviços do servidor entre máquinas virtuais dois sistemas VMWare ESXi (e remova o Xen da equação, já que eu poderia ativar outras VMs).

Na época, acho que estava gostando da maneira mais ou menos direta da interface de gerenciamento de fornecer estatísticas sobre desempenho, uso de disco, etc. no lado da VM, enquanto não vi nada sobre o gerenciamento de Xen ou DRBD além do linha de comando (embora eu odeie ter que usar um sistema Windows para monitorar o servidor VMWare).

O segundo pensamento me dizia que seria uma camada adicional de complexidade e provavelmente de dificuldade com a rede, já que eu provavelmente poderia executar mais facilmente a replicação Linux / DRBD com o hardware dedicado (cada máquina teria uma NIC para o switch, uma NIC para crossover para o outro para o disco de E / S) e eu queria descobrir o que eu poderia fazer para criar um cluster para "livre" ... e as soluções da VMWare além do ESXi definitivamente não são baratas.

Alguém mais tentou algo parecido com essa configuração, virtualizando a máquina executando o DRBD na VM em vez de hardware bare-metal? Há vantagens de configuração para isso além do monitoramento de desempenho / gerenciamento com o cliente vSphere gratuito (ou virtualização "livre" de escolha)?

    

Answer 1

Pelo menos com o Xen, minha experiência é que é melhor deixar o Dom0 manipular os dispositivos de bloco. Eu não lidei com o DRDB, mas com o iSCSI é melhor ter o Dom0 como o iniciador do iSCSI e depois fazer com que o DomU use o dispositivo de bloco resultante.

O DRBD não se preocupa com o sistema de arquivos que está sendo executado nos volumes, então eu diria que isso é provavelmente o melhor feito no DomO. Isso também lhe dá a capacidade de ter backup da janela de backup DOMUs.

Você também pode querer verificar esta questão , pois ela trata de alguns dos seus perguntas sobre a execução do heartbeat em uma VM.

    

Answer 2

Eu tenho trabalhado em configurar isso de uma maneira que você descreve e funciona muito bem! (XenServer)

Eu configurei um servidor antigo, mas capaz, como o host primário, isso executa uma VM somente de console para o DRBD. Esta VM, em seguida, serve um "SharedDRBD" SR de volta para o host Xen via NFS. O restante das VMs que trabalham fornecendo serviços são executados no SharedDRBD SR. O devedor DRBD da VM está em sua própria VDI em um RAID 1 de MDADM. Esse SharedDRBD SR hospeda o restante das VMs para vários serviços com uma matriz RAID10 maior local para o armazenamento de arquivos em massa.

Todo o trabalho do MDADM é feito pelo host, mas um lado do DRBD está em uma VM.

O DRBD executado em uma VM é sincronizado com um serviço DRBD em execução no servidor de backup de arquivos; o servidor de backup de arquivos NÃO é virtualizado intencionalmente, portanto, temos acesso bare-metal a todos os arquivos, uma vez que o XenServer é a maior peculiaridade com a qual geralmente lidamos.

Existe um servidor secundário que é virtualizado, mas não possui armazenamento local, exceto o que é necessário para o host. Esse servidor faz parte de um pool Xen com o servidor principal para simplificar o failover. O failover é manual, mas é rápido e fácil.

Primeiro, todas as VMs no SharedDRBD SR são desligadas enquanto o host secundário do XenServer é ligado. O DRBD no servidor de backup de arquivos é feito primário e montado conforme necessário. Em seguida, o SharedDRBD SR é apontado para o servidor de backup de arquivos e as VMs são iniciadas no servidor secundário; O XenCenter nem percebe que está servindo as VMs de um novo local porque ele vê o mesmo SR com os mesmos dados. As VMs são reativadas e as coisas estão de volta e funcionando.

Há muito mais em termos de configuração e matrizes, topologia de rede, etc; mas o jist é o DRBD é exibido em uma VM de volta ao seu próprio host .

No geral, é suficiente HA para o uso de SMB / Home; o tempo de inatividade durante uma falha catastrófica do servidor principal é de 10 a 20 minutos ou menos para o total retorno on-line e a perda de dados; DRBD significa que as VMs estão atualizadas! Além disso, fora do servidor primário, que é bastante robusto, há uma tonelada de redundância geral. A maior parte do servidor principal é redundante em si e, portanto, praticamente nos dá redundância tripla ou melhor para praticamente cada peça de hardware que você pode imaginar (PS, RAM, CPU , HDD, Controladores, NICs, etc) além da placa-mãe (s) que é apenas redundância dupla (hosts Xen primários / secundários).

E sim, o XenCenter está instalado no Windows, infelizmente, o resto é tudo Linux.

Eu sei, este Q's tem 8 anos.