Servidores Linux Redundantes em Datacenters Separados

Question

Eu tenho 2 servidores Linux CentOS em data centers separados em cada site do país. Essas máquinas Linux executam pequenos sites no Apache com um backend do MySQL. Atualmente, não há conectividade VPN entre eles neste momento e a única maneira de se comunicar é através do espaço IP público.

A pergunta que tenho é qual seria a melhor maneira de torná-los redundantes no caso de um deles falhar o outro assumirá (relação mestre / escravo)? Eu gostaria de poder fazer isso com os dois servidores que tenho atualmente sem adicionar um terceiro. Eu estou supondo que eu precisaria criar uma VPN entre os dois, então use algo como DRDB para MySQL.

O que você recomendaria?

    

Answer 1

O MySQL possui recursos de replicação embutidos - sem necessidade de DRBD. Consulte aqui .

Esta replicação ocorre sobre o protocolo normal do MySQL, na porta TCP 3306. O protocolo nativo suporta a criptografia TLS, mas uma VPN pode não ser uma má idéia, sob a luz de Variabilidades recentes . Até você!

De lá, você precisará apenas que seu aplicativo que está utilizando o MySQL esteja ciente de ambos os servidores de alguma forma ou desenvolva algum outro tipo de mecanismo de failover dependendo do seu aplicativo - parece que você tem uma instância local de seu aplicação web em cada local, então apenas apontando cada um para sua instância local do MySQL pode fazer o truque.

Tenha cuidado, porém - se você estiver replicando nos dois sentidos, provavelmente não quer que os dois servidores MySQL sejam gravados ao mesmo tempo; mudanças conflitantes podem ser feitas nos diferentes servidores.

    

Answer 2

O DRDB só funciona como uma solução de failover. Como diz Shane, a replicação do MySQL é uma abordagem muito mais sensata. Enquanto você poderia implementar isso como mestre / escravo, então você tem as complicações de promover o escravo quando detecta uma interrupção. Uma solução melhor é usar a replicação mestre-mestre.

Mas há limites para a eficácia deste - escritas replicadas são implementadas por um único encadeamento - então o 'escravo' tem que trabalhar mais do que o mestre para aplicá-las. Há inevitavelmente um atraso - embora geralmente isso seja pequeno o suficiente para não ser um problema.

Embora o mysql suporte criptografia SSL, ele não oferece muita funcionalidade para ajustar o controle de acesso. É trivial configurar stud ou stunnel para envolver uma porta específica em SSL. E a (s) conexão (ões) de replicação são mantidas abertas, portanto a sobrecarga de largura de banda é muito baixa. Ou apenas restringir o acesso à porta do MySQL para o endereço IP remoto usando o iptables.

Mas você ainda precisa resolver o problema de detectar falhas e cercar o nó com falha. Presumivelmente, você está fazendo o balanceamento round-robin nos servidores HTTP - nesse caso, os clientes tendem a permanecer nos mesmos servidores durante a duração da sessão. Os servidores da Web obterão o melhor desempenho da instância do DBMS local - portanto, devem tentar acessar o sistema remoto somente quando você detectar uma interrupção no sistema local. Não se preocupe em tentar automatizar a recuperação - contanto que você possa fazer o script.

Faça uma leitura cuidadosa da replicação do MySQL - se você fizer o trabalho de base, as gravações conflitantes deverão ser muito, muito raras.

    

Answer 3

O DRBD tem a principal desvantagem de a comunicação não ser criptografada. Então vá para a replicação mySQL.

Na sua configuração, eu não usaria nenhum agrupamento automático, pois não vejo nenhuma maneira segura de evitar situações de divisão de cérebros.

Mas você pode acionar manualmente um script que será

• Promova o MySQL secundário para o Master
• Coloque seu IP lógico usado para contatar seu serviço
• Inicie seu servidor da Web nesse IP

Por outro lado, você tem que impedir a inicialização se ela voltar a ficar online - e você precisa de uma estratégia para o fallback.