Altere o IP do servidor com tempo de inatividade zero

Question

Estou mudando os servidores do meu site, example.org. O IP do servidor antigo não pode ser usado para o novo. Eu quero substituir o servidor antigo pelo novo sem tempo de inatividade.

Existem muitos serviços diferentes em execução no example.org, não é apenas um aplicativo de servidor da Web, é também um servidor de e-mail, git server, mumble server, etc.

Minha ideia é:

1. Obter dados dos servidores em sincronia, para que o novo servidor tenha dados que sejam uma cópia idêntica do servidor antigo
2. Atualize o nome do domínio para que o exemplo.org aponte para o novo IP
3. No servidor antigo, configure as regras do iptables para redirecionar todo o tráfego de http, https, smtp, etc. para o novo servidor. Não tenho certeza de quais regras de IP usar para isso, portanto, poderia usar alguma ajuda com isso.

Agora, isso parece bom e tudo, mas parece que haverá um problema com o SSL.

Por exemplo, se um usuário Alice navegar para example.org em seu navegador e ele for resolvido para o IP antigo, já que a alteração de DNS ainda não foi propagada para ela, o IP antigo a redirecionará para o novo IP. Eu acho que o navegador dela enlouqueceria. Ele veria o novo IP usando o certificado SSL para example.org, enquanto o example.org obviamente resolve um IP diferente, o IP antigo, já que o cache do DNS não é atualizado para Alice. Então a Alice seria saudada com um enorme aviso vermelho SSL em seu navegador dizendo que o novo IP não é do exemplo.org.

Um problema semelhante acontecerá com o servidor de correio (SSL smtp) e outros serviços em execução no example.org. Como eu resolvo isso?

Uma solução ideal seria, de alguma forma, usar o iptables, de modo que o servidor antigo procuraria o novo servidor, em vez de redirecionar o usuário para o novo servidor. Dessa forma, os usuários cujo cache DNS ainda não foi atualizado se comunicariam assim: [usuário] < --- > [servidor antigo] < --- > [novo servidor]. Eles não sabem que o novo servidor existe, para eles, parece a comunicação usual com o servidor antigo. Meu único problema com essa solução de proxy é que o novo servidor verá os IPs de origem do servidor antigo, em vez dos usuários. Isso pode quebrar muitas coisas, por exemplo, o Fail2Ban pode firewallizar o IP do servidor antigo por 10 minutos porque alguns usuários digitaram a senha de email incorreta algumas vezes, essencialmente negando acesso ao servidor de e-mail a todos os outros usuários que não possuem DNS atualizado. use o proxy.

    

Answer 1

A maneira mais fácil de fazer isso não envolve o proxy no servidor antigo:

1. Menor TTL para algo como 300 segundos.
2. Aguarde pelo menos o antigo TTL para os caches expirarem.
3. Altere o IP quando houver menos tráfego.
4. Modifique o TTL de volta para seu valor original.

Seu tempo de inatividade máximo agora é extremamente baixo.

Para suas preocupações:

• SSL / TLS não se importam com os endereços IP, mas apenas com nomes de host. É possível até mesmo ter um cluster multi-IP atendendo o mesmo site com o mesmo certificado. Nenhum problema com qualquer navegador.
• O Fail2ban tem lista de permissões : use ignoreip = para abrir uma exceção para seu servidor antigo.
• Você não precisa replicar o SQL em tempo real para esse cenário. Mova seu banco de dados antecipadamente e crie sites no servidor antigo para usar o SQL a partir do novo.
• Não faça proxy SMTP. Você pode retransmitir todos os emails pelo servidor antigo para o novo com o seu MTA antes mesmo da alteração do DNS. Basta configurar o servidor antigo como se fosse um MX secundário e fazer com que o novo servidor confie nele.

Answer 2

Você pode examinar o tunelamento ssh para enviar suas solicitações de serviço para o novo servidor. Eu vi isso onde hostname resolve para o servidor antigo e, em seguida, encaminha o tráfego para o novo servidor via ssh. Se no novo servidor o IP do servidor antigo for ignorado, então o fail2ban não deverá ter problemas.