DRBD com failover manual

Question

Analisar o uso do DRBD ou de um sistema de arquivos em cluster para ajudar no tempo de atividade quando o tempo de inatividade ocorrer em um ambiente de pequena empresa.

Atualmente, usamos uma caixa de servidor para um servidor de arquivos usando o Linux e o samba, em seguida, executando o servidor da Web e o Banco de dados em uma VM. Estava olhando para adicionar um segundo servidor e colocar os arquivos e a VM no sistema de arquivos distribuídos. O sistema operacional básico é mais estático e pode ser gerenciado com mais facilidade (copiar arquivos de configuração no momento da alteração, copiar o SO base, se necessário, a partir de backups completos, etc.)

A pergunta é sobre o cenário de failover, se feito manualmente. Se o servidor 1 falhar e o failover for feito manualmente, o failover será concluído simplesmente configurando o IP estático do servidor 2 para o servidor 1 (novamente o servidor 1 estará inativo e precisando de reparos), iniciando o Samba e iniciando a VM que teria os mesmos IPs estáticos que tinham quando executados no servidor 1 e iniciando os serviços de backup?

Isso parece um processo rápido e simples, quase simples demais. Estou esquecendo de algo? Isso poderia facilmente ser automatizado também por meio de um script ou algo que alguém com pouca proficiência poderia ser direcionado a executar em caso de falha.

Tempo de inatividade se tivermos uma falha de hardware pode facilmente ser dias sem o suporte de suporte de TI e as peças necessárias sem um segundo servidor, mas com o segundo servidor, o tempo de inatividade seria no máximo uma questão de horas (se ninguém for o consultor suficientemente competente para realizar tais operações, minutos se alguém estiver)

    

Answer 1

O processo de failover que você está descrevendo é tão simples quanto correto. Usar o DRBD é a etapa principal para criar redundância, pois você elimina um único ponto de falha, como um armazenamento compartilhado.

O atual failover que você mencionou pode ser facilmente automatizado pelo Pacemaker / Corosync , para que não haja necessidade de intervenção manual. Eu preferiria escrever scripts auto-escritos, pois ele também cuida de cercar nós não-funcionais, para que você não se deparasse com um cenário de divisão de cérebro (o que poderia estragar todos os seus dados).

Lembre-se de que a HA "real" requer separação completa (ou pelo menos máxima possível) de sistemas (sala separada (ou pelo menos rack), USV diferente, comutação redundante etc.). Um ponto único de falhas geralmente estraga todo o seu esforço para otimizar a disponibilidade.