¿Cómo migro sin problemas el DNS de un servidor web de una dirección IP a otra?

Actualmente tengo un nombre de dominio registrado para un servidor Linux / Apache que voy a reemplazar por otro en una nueva dirección IP.

La migración de los datos será relativamente rápida y una interrupción de 5 minutos durante ese proceso es aceptable.

El registro DNS tiene un TTL de 6 a 12 horas aparentemente, que no puedo acelerar.

¿Cuáles son las posibles consecuencias de este cambio? Presumiblemente, los usuarios que todavía están mirando la dirección anterior continuarán accediendo al servidor anterior, mientras que los usuarios cuyo caché dns ha caducado o está vacío verán el nuevo dominio.

¿Es posible hacer algún tipo de redirección desde el servidor anterior (con Apache o iptables) a la nueva IP? El antiguo servidor puede continuar ejecutándose todo el tiempo que sea necesario.

Puede usar un proxy inverso en el antiguo servidor web. Puede ser un poco difícil de configurar, pero siempre que su DNS esté actualizado, estará bien.

Lo que sucederá es:

1. El antiguo servidor web está configurado para ser proxy inverso
2. Cambio de DNS
3. El nuevo servidor web sirve visitas de registros DNS actualizados
4. La web antigua cuando recibe un golpe, reenvía la solicitud al DNS correcto y luego muestra el contenido textualmente.

Si está ejecutando Apache, busque mod_proxy. Si está ejecutando IIS, busque ISAPI Rewrite para obtener este tipo de funcionalidad.

(tenga en cuenta que el DNS en el servidor web anterior debe estar actualizado si desea usar el proxy con el nombre de dominio. De lo contrario, conéctelo directamente a la dirección IP y asegúrese de que el host esté escuchando en la IP sin un nombre de host)

Mi compañía acaba de hacer esto con varios sitios web grandes. El procedimiento básico que seguimos fue:

1. Baje el TTL del dominio tanto como sea posible. Haga esto por adelantado al menos tanto tiempo como el TTL actual.
2. Configure el sitio web en el nuevo servidor exactamente como desea que sea el "producto final"
3. Agregue un nombre con alias al sitio en el nuevo servidor, como www2.domain.com o www-new.domain.com. Con Apache, usaría la directiva ServerAlias . Si el sitio tiene algún código dinámico (PHP, mod_perl, RubyOnRails, etc.), asegúrese de que el sitio se comportará y responderá correctamente con este nuevo nombre.
4. En el momento de la transición, configure una redirección en el servidor anterior que apunte al nuevo servidor
5. Cambiar DNS para www para ir a la nueva IP.

Para Apache, probablemente debería usar mod_rewrite para la redirección para poder preservar los URI solicitados por el cliente. Una implementación simple sería:

# 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>

Esto hará una redirección temporal 302 para www.domain.com/anything a www-new.domain.com/anything. Desea que sea temporal porque probablemente desee que los motores de búsqueda solo indexen www.dominio.com, no www-nuevo.dominio.com.

Una vez que el cambio de DNS para www.dominio.com se ha propagado a su satisfacción, puede volcar www-new por completo, o facilitar a cualquiera que lo use nuevamente a www con otra redirección. Es casi el mismo proceso que el anterior; configure el servidor antiguo para manejar www-new, cambie el DNS para www-new para que apunte al servidor antiguo y configure una redirección en el servidor antiguo que envía tráfico www-new a 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>

Esta vez desea hacer una redirección 301 permanente, nuevamente para dar una pista en los rastreadores de motores de búsqueda de que www.dominio.com es el sitio que desea que indexen.

De acuerdo con lo que @Farseeker recomendó, configuré la siguiente configuración en el antiguo servidor Apache para reenviar solicitudes al nuevo 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 asegurarme de que el servidor anterior tenía la dirección correcta, puse una entrada en /etc/hosts:

1.2.3.4 domain.com

También tuve que habilitar Apache mod_proxyy los mod_proxy_httpmódulos, y volver a cargar la configuración:

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

Es un hilo viejo pero tal vez ayude a alguien:

Además de las respuestas de Mark Henderson (mod_proxy) O James Sneeringer (redirección 302,301 a nuevos subdominios), se podría agregar una cosa más con respecto a la sincronización de la base de datos al mover aplicaciones grandes.

Si su proyecto web utiliza una base de datos (por ejemplo, MySQL), antes de cambiar el DNS, asegúrese de que las aplicaciones (por ejemplo, PHP) de ambos servidores estén conectadas a la misma base de datos. Para que las lecturas y escrituras vayan al mismo lugar y no tenga que lidiar con diferentes herramientas de sincronización de bases de datos después.

Esto (muy probablemente) afectaría el tiempo de carga en un servidor, pero para el período de cambio esto puede ser aceptado.

En caso de que el servidor de base de datos no sea accesible desde el exterior, también puede configurar mysql_proxy en el servidor web que tiene acceso a él y que es accesible desde IP externas.

Utilizo iptables para esto cuando necesito hacer esto; un poco de DNAT / SNAT y todo su tráfico reaparece mágicamente donde debería estar. Si tiene una necesidad real de mantener las direcciones IP de origen, un proxy inverso puede ayudar, al configurar los encabezados apropiados, pero eso requiere mucha atención en ambos extremos para asegurarse de que todo coincida, por lo que normalmente no me preocupo por eso para algo así como una migración, ya que es transitoria, y la reducción de TTL maneja la mayor parte.