Analisando o uso do DRBD ou de um sistema de arquivos em cluster para ajudar no tempo de atividade quando ocorre um tempo de inatividade em um ambiente de pequena empresa.
Atualmente usamos uma server box para um servidor de arquivos usando Linux e samba, rodando então o servidor web e banco de dados em uma VM. Estava pensando em adicionar um segundo servidor e colocar os arquivos e a VM no sistema de arquivos distribuído. O sistema operacional base é mais estático e pode ser facilmente gerenciado manualmente (copiar arquivos de configuração no momento da alteração, copiar o sistema operacional base, se necessário, de backups completos, etc.)
A pergunta é sobre o cenário de failover, se feito manualmente. Se o servidor 1 ficar inativo 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 está inativo e precisaria de reparo), iniciando o Samba e iniciando a VM que teria os mesmos IPs estáticos que tinham ao executar no servidor 1 e iniciar os serviços de backup?
Parece um processo rápido e simples, quase simples demais. Estou esquecendo de algo? Isso também poderia ser facilmente automatizado por meio de um script ou algo que alguém com pouca proficiência pudesse executar em caso de falha.
O tempo de inatividade se tivermos uma falha de hardware pode facilmente ser de dias sem o suporte de TI de plantão 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 não um é o escritório proficiente o suficiente para realizar tais operações, minutos se alguém fosse)
Responder1
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 failover atual mencionado pode ser facilmente automatizado porMarcapasso/Corosyncpara que não haja necessidade de intervenção manual. Eu preferiria scripts escritos por mim mesmo, pois também cuida de cercar nós não funcionais, para que você não se depare com um cenário de divisão cerebral (o que poderia estragar todos os seus dados).
Tenha em mente que o HA "real" requer separação completa (ou pelo menos arquivável) dos sistemas (sala separada (ou pelo menos rack), USV diferente, comutação redundante etc.). Um único ponto de falha geralmente atrapalha todo o seu esforço para otimizar a disponibilidade.