Como migrar sem problemas o DNS de um servidor Web de um endereço IP para outro?

Atualmente, tenho um nome de domínio registrado para um servidor Linux / Apache que vou substituir por outro em um novo endereço IP.

A migração dos dados será relativamente rápida e uma interrupção de 5 minutos durante esse processo é aceitável.

O registro DNS tem um TTL de 6 a 12 horas, aparentemente, o que não posso acelerar.

Quais são as conseqüências prováveis ​​dessa mudança? Presumivelmente, os usuários que ainda estiverem visualizando o endereço antigo continuarão atingindo o servidor antigo, enquanto os usuários cujo cache de DNS expirou ou está vazio verão o novo domínio.

É possível fazer algum tipo de redirecionamento do servidor antigo (com Apache ou iptables) para o novo IP? O servidor antigo pode continuar em execução pelo tempo necessário.

Você pode usar um proxy reverso no servidor da web antigo. Pode ser um pouco de trabalho para configurar, mas enquanto o ITS DNS estiver atualizado, você estará bem.

O que vai acontecer é:

1. O servidor da web antigo está configurado para ser Proxy Reverso
2. Troca de DNS
3. Novo servidor da web fornece hits de registros DNS atualizados
4. A Web antiga, quando é atingida, encaminha a solicitação para o DNS correto e, em seguida, gera o conteúdo literalmente.

Se você estiver executando o Apache, consulte mod_proxy. Se você estiver executando o IIS, consulte ISAPI Rewrite para obter esse tipo de funcionalidade.

(observe que o DNS no servidor Web antigo precisa estar atualizado se você deseja fazer proxy usando o nome de domínio. Caso contrário, faça o proxy diretamente para o endereço IP e verifique se o host está escutando o IP sem um nome de host)

Minha empresa fez isso com vários sites grandes. O procedimento básico que seguimos foi:

1. Diminua o TTL do domínio o máximo possível. Faça isso com antecedência por pelo menos o tempo que o TTL atual.
2. Configure o site no novo servidor exatamente como você deseja que o "produto final" seja
3. Adicione um nome alternativo ao site no novo servidor, como www2.domain.com ou www-new.domain.com. Com o Apache, você usaria a diretiva ServerAlias . Se o site tiver algum código dinâmico (PHP, mod_perl, RubyOnRails etc.), verifique se o site se comportará e responderá corretamente com esse novo nome.
4. No momento da transição, configure um redirecionamento no servidor antigo apontando para o novo servidor
5. Mude o DNS para www para ir para o novo IP.

Para o Apache, você provavelmente deve usar mod_rewrite para o redirecionamento, a fim de preservar os URIs solicitados pelo cliente. Uma implementação simples seria:

# old server
<VirtualHost 1.1.1.1:80>
    ServerName www.domain.com
    RewriteEngine on
    RewriteRule ^(.*)$ http://www-new.domain.com$1 [L]
</VirtualHost>

# new server
<VirtualHost 1.1.1.2:80>
    ServerName www.domain.com
    ServerAlias www-new.domain.com
</VirtualHost>

Isso fará um redirecionamento 302 temporário para www.domain.com/anything para www-new.domain.com/anything. Você deseja que seja temporário, porque provavelmente deseja que os mecanismos de pesquisa indexem apenas www.domain.com, não www-new.domain.com.

Depois que a alteração do DNS para www.domain.com for propagada para sua satisfação, você poderá despejar o www-new por completo ou facilitar com facilidade quem o usar de volta ao www com outro redirecionamento. É quase o mesmo processo acima; configure o servidor antigo para lidar com www-new, altere o DNS para www-new para apontar para o servidor antigo e configure um redirecionamento no servidor antigo enviando o tráfego www-new para www:

# old server
<VirtualHost 1.1.1.1:80>
   ServerName www-new.domain.com
   RewriteEngine on
   RewriteRule ^(.*)$ http://www.domain.com$1 [R=301,L]
</VirtualHost>

# new server
<VirtualHost 1.1.1.2:80>
    ServerName www.domain.com
    # ServerAlias removed, no longer needed
</VirtualHost>

Dessa vez, você deseja fazer um redirecionamento 301 permanente, novamente para descobrir nos rastreadores dos mecanismos de pesquisa que www.domain.com é o site que você deseja que eles indexem.

Ok, com base no que o @Farseeker recomendou, eu configurei a seguinte configuração no antigo servidor Apache para encaminhar solicitações para o novo servidor:

<VirtualHost *>
  UseCanonicalName Off
  ServerAdmin  [email protected]
  ServerName domain.com
  DocumentRoot /var/www/

  ProxyRequests Off

  <Proxy *>
    Order deny,allow
    Allow from all
  </Proxy>

  ProxyPass / http://domain.com/
  ProxyPassReverse / http://domain.com/
</VirtualHost>

Para garantir que o servidor antigo tenha o endereço correto, insira uma entrada em /etc/hosts:

1.2.3.4 domain.com

Eu também tive que habilitar o Apache mod_proxye os mod_proxy_httpmódulos e recarregar a configuração:

a2enmod proxy
a2enmod proxy_http
/etc/init.d/apache force-reload

É um tópico antigo, mas talvez ajude alguém:

Além das respostas de Mark Henderson (mod_proxy) OU James Sneeringer (redirecionamento 302.301 para novos subdomínios), mais uma coisa poderia ser adicionada em relação à sincronização de banco de dados ao mover aplicativos grandes.

Se o seu projeto da web usa um banco de dados (por exemplo, MySQL), antes de mudar o DNS, verifique se os aplicativos (por exemplo, PHP) dos dois servidores estão se conectando ao mesmo banco de dados. Para que as leituras e gravações estejam no mesmo local e você não precise lidar com diferentes ferramentas de sincronização de banco de dados posteriormente.

Isso (provavelmente) afetaria o tempo de carregamento em um servidor, mas, durante o período da troca, isso pode ser aceito.

Caso o servidor de banco de dados não seja acessível de fora, você também pode configurar o mysql_proxy no servidor da web que tem acesso a ele e é acessível a partir de IPs externos.

Eu uso o iptables para isso quando preciso fazer isso; um pouco rápido de DNAT / SNAT e todo o seu tráfego reaparecem magicamente onde deveriam estar. Se você realmente precisa manter os endereços IP de origem, um proxy reverso pode ajudar, definindo cabeçalhos apropriados, mas isso exige muito esforço nas duas extremidades para garantir que tudo corresponda, portanto, normalmente não me preocupo com isso. para algo como uma migração transitória, e a redução de TTLs lida com a maior parte.