A migração do servidor minimiza as pesquisas de DNS erradas

Question

Eu gerencio um site grande (500 mil únicos por dia) e estou prestes a me mudar para outro hoster.

Minha nova máquina é configurada e testada, todos os arquivos são copiados, por isso estou quase pronto para alterar o endereço IP do meu domínio no meu registrador.

Agora, gostaria de saber se existe uma alternativa para minimizar a quantidade de pessoas que acessam o servidor antigo, porque as informações de DNS ainda não estão atualizadas.

Às vezes, pode demorar muito tempo para atualizar e as pessoas que acessam o servidor antigo deixam meu site fora de sincronia.

Existe uma maneira de forçar o encaminhamento de pessoas para a nova máquina da minha máquina antiga?

    

Answer 1

Não, bem, sim, mas na realidade não.

Defina seu TTL de DNS muito baixo antes da migração (como 5 minutos), isso diz aos clientes para armazenar em cache o DNS por 5 minutos e atualizar. Em teoria, depois de alterar o IP em seu DNS, deve levar apenas 5 minutos para os clientes começarem a acessar o novo IP do servidor.

Infelizmente, a teoria não é realidade. Alguns ISPs e provedores DNS armazenam registros em cache por mais tempo do que o conjunto TTL (vi alguns ISPs armazenarem TTLs de 5 minutos por 48 horas) e, em resumo, não há nada que você possa fazer do ponto de vista técnico para impedi-los de fazer isso, mesmo embora eles não devam. E, infelizmente, persuadir todos os seus usuários a migrar para o OpenDNS pode não ser a melhor ideia.

Quando eu mudoi sites maiores antes que este seja geralmente o processo que eu sigo;

Configure a sincronização entre os dois (novos e antigos) servidores de banco de dados.

Se o banco de dados que você usa suportar replicação mestre-mestre (as gravações I.E. no nó ether serão propagadas para o outro), execute o servidor antigo e o novo servidor lado a lado até que todos os clientes tenham sido atualizados. Isso significa que os clientes podem acessar o servidor ether e o site estará totalmente funcional.

Se o banco de dados apenas suportar master-slave / log shipping, etc. sua única opção real para manter o site ativo é ter o servidor antigo executando uma cópia "somente leitura" do banco de dados, ele ainda teria os dados mais recentes, mas apenas para ler, não escrever / atualizar. Dependendo do seu site, isso pode não ser um problema muito grande.

Outra opção, e provavelmente a mais fácil de conseguir, é colocar um proxy no servidor antigo que encaminha quaisquer solicitações para o novo servidor. Os usuários no servidor antigo terão alguma latência devido aos saltos extras no proxy, mas com uma configuração de cache inteligente, você provavelmente poderá minimizar isso.

Com qualquer uma das opções acima, monitore o servidor antigo e quando todos / a maioria dos clientes foram descomissionados como você faria normalmente.

Claro, tudo isso poderia ser evitado se todos seguissem os padrões que deveriam seguir.

    

Answer 2

Pensamento de duas minúsculas adições às sam's: Se o acesso ao banco de dados puder tolerar a latência entre os dois servidores, você também poderá definir ambos para usar o banco de dados na nova máquina. (Se você precisar de segurança, você pode usar o túnel SSH ou VPN).

Outra opção seria configurar a máquina antiga para responder a todas as consultas com redirecionamentos HTTP temporários (307) para o novo IP (ou você pode configurar algum nome de domínio temporário como www1.yoursite.com com o novo IP, e use isso em redirecionamentos).

    

Answer 3

Use um proxy reverso

Se você tiver acesso root ao sistema, você pode fazer proxy do tráfego do servidor antigo para o novo usando o mod_proxy do Apache.

Com o mod_proxy, você pode configurar um proxy reverso do antigo para o novo. Desta forma, todas as atividades do cliente acontecem no mesmo servidor. Quando programado com cuidado, você pode ter um tempo de inatividade mínimo (por exemplo, o tempo necessário para reiniciar o apache).

Eu gosto dessa abordagem, pois permite que você teste as coisas antes de alterar o DNS. Um bom teste de sanidade de última hora.

Você também pode ter que usar um módulo chamado mod_rpaf para obter o verdadeiro endereço IP dos visitantes, caso tenha ferramentas que exijam essas informações.

Alguns sites usam URLs canônicos que podem causar um problema. Um truque é definir o IP do novo servidor em seu arquivo / etc / hosts no servidor antigo. Você pode colocar algo assim em sua configuração de proxy:

ProxyPass / http://www.domain.com/
ProxyPassReverse / http://www.domain.com/

É isso. Você também pode fazer isso para HTTPS.

Observe também que muitos ISPs ignoram os valores de TTL. Comcast, ATT e outros atualizarão seus caches de DNS apenas algumas vezes por dia.