Failover em diferentes sub-redes

Question

Implementamos uma comutação de failover no Linux usando DRBD e Heartbeat e ela funciona muito bem. Agora temos uma mudança no requisito que afirma que a replicação de nós está em sub-redes diferentes, não teremos um IP virtual comum que usamos quando o as máquinas estão na mesma sub-rede.

Quando temos nós em diferentes sub-redes, qual seria a melhor maneira de fazer failover?.

    

Answer 1

Existem várias abordagens para implementar o failover entre sub-redes; mas há muitas variantes dependendo dos requisitos exatos. Independentemente dos detalhes, o que você parece estar tentando alcançar é injeção de saúde de rota ; isto é, anunciar uma rota para um serviço específico (geralmente por meio de um VIP ) com base na saúde / disponibilidade desse serviço.

Algumas formas de implementar isso incluem:

aparelhos de terceiros

por exemplo. Citrix Netscaler ou F5 BIGIP . Esses dispositivos geralmente oferecem conjuntos de recursos muito ricos. Além do requisito de alta disponibilidade, eles também fornecem balanceamento de carga entre vários servidores, bem como alguns recursos avançados de verificação de integridade para protocolos de aplicativos conhecidos (por exemplo, HTTP, HTTPS, DNS, etc.). Eles são, no entanto, muito caros.

Daemons de roteamento baseados em host

por exemplo. Quagga ou XORP . Com um pouco de script, esses daemons podem fornecer um subconjunto da funcionalidade dos appliances acima, sem os custos associados. Se você configurar sua rede para aceitar roteamento de atualizações de roteamento dinâmico de seus hosts e inserir alguns scripts que verificam periodicamente a integridade de seus serviços, isso permitirá que você anuncie condicionalmente uma rota para um VIP em cada um dos seus servidores reais. Algumas considerações aqui:

• você precisará ter direitos administrativos em seu hardware de rede;
• você precisará de controles para garantir que o processo de roteamento baseado em host não cause impacto na infraestrutura da sua rede, por exemplo, através da configuração incorreta.

Algum esclarecimento dos requisitos / restrições em sua situação pode ser útil. Algumas perguntas:

• Você precisa de failover ativo / ativo ou ativo / em espera?
• Esses aplicativos estão voltados para a Internet ou apenas para uso interno?
• Você precisa de um failover automático?
• O balanceamento de carga é um requisito?
• Você preferiria uma solução anycast , em que os usuários se conectassem à instância 'mais próxima' de um serviço?
• Seus servidores back-end precisam ver conexões de clientes originadas de seu endereço IP de origem real ou um proxied solução seja aceitável?

Answer 2

Esta página da lista de discussão fala sobre o uso de anúncios de roteamento RIP para permitir que os servidores respondam a um endereço IP comum, mesmo que estejam em sub-redes diferentes. Você precisará de um pouco de mágica do roteador para fazer isso funcionar.

link

Alternativamente, se você não se incomodar com um pouco de tempo de inatividade, poderá usar entradas de DNS com TTLs curtos. Basta atualizar o registro DNS para alterar os servidores.

    

Answer 3

Conseguimos isso fazendo nossos servidores linux agindo como um roteador (usando zebra + ospf)
Aqui estão alguns detalhes, se alguém estiver interessado
-DRBD replicando usando uma sub-rede diferente anunciada na interface lo: 1 em ambas as máquinas | -have IP virtual configurado em lo: 2 que falha ao tentar - Para pulsação use unicast para falar com o outro nó

    

Answer 4

A última vez que tive este requisito, usei um IP por máquina, ligado à máquina e um "IP de serviço" (isto é, os clientes IP configuraram como o IP do servidor). Eu usei o ultramonkey para monitorar o serviço e lidar com o failover, Zebra para interagir com o protocolo de roteamento (injetando / 32 rotas para todos os serviços IPs; tivemos vários serviços que precisavam ser movidos, o host primário para cada serviço era baseado na proximidade física dos clientes ).

Os servidores estavam localizados em Londres, Reino Unido e em algum lugar na Califórnia, EUA (não, não me lembro exatamente onde, nunca ponho meus olhos neles), com túneis GRE fornecendo conectividade entre redes (ambos os sites tinham Acesso à Internet).

No entanto, não usamos replicação contínua de dados, pois o serviço funcionaria muito bem, com a replicação de dados ocorrendo a cada hora, ou algo assim (era basicamente lido, não era muito escrito). A replicação foi feita de "IP físico" para "IP físico".

    

Answer 5

Comutador de conteúdo?

    

Answer 6

Tudo o que você precisa e mais, www.openbsd.org - Eu não vou começar a escrever um livro sobre tudo isso, para ajudá-lo, mas comece com o FAQ e man pages e você ficará surpreso quando ver isso tem tudo que você precisa neste caso e muito mais.