¿La mejor manera de cambiar la dirección IP del sitio, desde la perspectiva del usuario final?

10

Leí un montón de preguntas y respuestas relevantes aquí, pero todavía no estoy seguro de cuál es la mejor respuesta.

Estoy moviendo un par de sitios de la dirección IP "1.abc" a "2.def". A partir de ahora en el DNS existente configuré todos los TTL a 300 segundos, y tengo una nueva zona DNS lista para ser utilizada (en la Ruta 53 de AWS), con nuevos servidores de nombres y todos los TTL en 60 segundos. Así que creo que estoy listo, desde una perspectiva de DNS. Después de la mudanza, después de unos días estableceré TTL en números más razonables en la ruta 53.

He advertido a todos mis usuarios sobre el movimiento y tengo un período de tiempo definido para el movimiento. Les dije que una vez que el movimiento se haya completado y que hayan transcurrido 24 horas y todavía vean los sitios antiguos (bloqueados), deberían reiniciar su computadora para forzar un vaciado de caché de DNS local.

No entiendo cómo el navegador del usuario (caché) juega un papel en esto. Mis propios experimentos con un archivo de hosts locales (Win7) me dicen que hay algo en el navegador que no permite que la antigua dirección IP se vaya: tuve que ir al historial-> borrar todo para obtener la nueva ubicación del sitio para mostrar arriba, incluso despuésipconfig /flushdns

(EDITAR): no tengo acceso de root al servidor anterior, por lo que no puedo implementar la respuesta aceptada a esta pregunta .

Pregunta: Realmente no quiero que mis usuarios tengan que lidiar con eso, entonces, ¿hay algo que pueda hacer para forzar a todos los navegadores a volver a almacenar en caché? Y si es así, ¿cuánto tiempo lo dejo encendido?

Gracias...

domain-name-system migration

— CC
fuente

My own experiments with a local hosts file (Win7) tell me there is something about the browser that is not letting the old IP address go

¿Me puede dar alguna información sobre esto? Afaik, los navegadores no almacenan en caché los registros DNS durante más de 1 minuto.

— Tanmay

No estoy seguro, pero después de múltiples ipconfig / flushdns y "ctrl-F5" (en Firefox), seguía obteniendo una combinación de páginas tanto del sitio antiguo como del nuevo ... finalmente tuve que borrar "todo" y reiniciar navegador. No quiero que mis usuarios tengan que hacer algo similar ...

— CC

JBTW, la solución en el enlace que proporcionó también puede funcionar si tiene acceso de root al nuevo servidor. Actualice los registros DNS y reenvíe todo el tráfico del nuevo servidor al antiguo, hasta que el DNS se haya propagado correctamente.

— Tanmay

gracias ... pero luego tendría que sincronizar lo antiguo con lo nuevo (bases de datos, etc.) nuevamente más tarde, ¿no?

— CC

Tendrá que sincronizar la base de datos una vez, justo antes de desactivar el reenvío.

— Tanmay

15

No puedes. El problema es que la respuesta DNS se puede almacenar en caché en cualquier lugar entre el usuario y el servidor DNS y no hay forma de invalidarlos.

Sin embargo, lo que puede hacer: tan pronto como tenga los datos sincronizados y su segundo sitio esté listo, puede volver a configurar el servidor original para que se comporte como un proxy y pasar todas las solicitudes a la nueva ubicación.

De esta manera, puede lograr casi 0 segundos de tiempo de inactividad de su sitio web.

Actualizar

Si no tiene acceso de root, hay varias opciones:

Realizar proxy en PHP
Configure el proxy en el segundo servidor (si tiene acceso raíz allí), cambie DNS y cuando esté listo cambie el proxy a servidor web
Este método puede ser fuente de problemas. Tiene 2 direcciones (www.dominio.tld y www2.domain.tld). Configure www2 (que es lo mismo que www) y establezca registros DNS correctos. Luego prepare la versión www de su sitio y realice el cambio del DNS. Establezca la redirección de todas las solicitudes en el servidor anterior al subdominio www2.

— Yarik Dot
fuente

¿Te importaría ampliar un poco sobre esto, o con un puntero a un artículo o Q / A que podría leer? No tengo acceso de root al servidor existente, así que no puedo manipular directamente las tablas de IP ... ¿entonces quizás hay una forma alternativa?

— CC

¿@CC quizás tenga acceso para reemplazar su aplicación con una instancia de HAProxy? ¿O reemplaza su código de aplicación con otro que reenvía la solicitud al nuevo servidor?

— Jason Martin

@JasonMartin: tengo acceso a .htaccess y al código de la aplicación. Entonces, sí, probablemente podría obtener la URL solicitada y reenviarla a la nueva dirección IP, ¿tal vez debería intentar eso?

— CC

@CC que suena prometedor entonces. DNS es una herramienta 'eventualmente consistente', y algunos servidores DNS establecen pisos en su TTL e ignorarán sus 300. Si desea evitar cualquier interrupción allí, un proxy de reenvío es la mejor opción.

— Jason Martin

4

En teoría, establecer el TTL del dominio en algo bajo y esperar a que se produzca ese cambio, luego cambiar la IP, debería dar como resultado una migración casi transparente. Después de todo, ese es el punto de que el TTL sea configurable.

En la práctica, las personas configuran mal las cosas y las herramientas se rompen. Es por eso que es posible que deba proporcionar instrucciones a sus usuarios para borrar su caché local si las cosas no funcionan correctamente.

Sin embargo, no estás haciendo nada malo.

— Carreras de ligereza en órbita
fuente

Me debería inmediatamente cambiar a la nueva ruta 53 AWS DNS - con la antigua dirección IP - a continuación, después de la migración se hace simplemente cambiar la dirección IP para el nuevo? ¿O simplemente cambia el DNS al nuevo y cambia la IP al mismo tiempo?

— CC

1

@CC: no soy administrador de red, así que tómalo con pizca de sal (y me alegra saber lo contrario de los gurús de ServerFault), pero personalmente recomendaría no cambiar ambos a la vez. Ordena tu DNS, luego realiza el cambio de IP y deja que el nuevo DNS haga su trabajo ayudándote con esa última parte.

— Carreras de ligereza en órbita

1

Bueno, intenté un experimento. En un sitio, cambié el DNS horas antes, luego cambié la dirección IP del registro A más tarde. Funcionó perfectamente. El otro sitio lo cambié a la vez. Se revolvió entre la dirección IP antigua / nueva durante horas: finalmente eliminé la zona de la ruta 53 de AWS y lo volví a hacer de la misma manera que el primer sitio. Funcionó perfectamente. Así que no se necesita una pizca de sal, ¡estabas en el clavo!

— CC

1

Inevitablemente, su dirección anterior se almacenará en caché y se utilizará durante mucho tiempo, principalmente por bots.

Cómo lo haría:

Cree un registro A, por ejemplo www2.yourdomain.com, apuntando a una nueva IP. Este registro nunca debería haberse usado antes; Por lo tanto, nunca en caché.
Redirigir consultas en el servidor anterior a www2.yourdomain.com
Supervise las redirecciones y, cuando el tráfico disminuya a un nivel aceptable, elimine el servidor anterior.
Y, finalmente, una vez que se elimine el servidor anterior, redirija www2.yourdomain.coma www.yourdomain.com.

Asegúrese de utilizar redireccionamientos permanentes 301. https://en.wikipedia.org/wiki/HTTP_301

— ClickLabs
fuente

Mi sensación es que debe no utilizar 301 para la primera ronda de redirecciones, pero sólo para el segundo. ¿Hay alguna razón particular por la que él debería ser conocida solo por alguien con sabiduría SEO esotérica?

— Random832

@ Random832 Un permanente le dice al agente de usuario que se olvide de la antigua url y, por ejemplo, actualice los marcadores para que apunten a la nueva url (por lo que la próxima vez, podrían acceder a la nueva url directamente). No hay ningún daño en redirigir más tarde (o incluso volver a la URL original). Una redirección temporal, por otro lado, le dice al usuario-agente que mantenga la URL original (porque la redirección podría suceder a un objetivo diferente o no la próxima vez). Por lo tanto, con redireccionamientos temporales, el monitoreo de redireccionamiento nunca caería a un "nivel aceptable".

— Hagen von Eitzen

@HagenvonEitzen Caerá a un nivel aceptable a medida que los navegadores dejen de obtener la dirección IP del servidor anterior para www.yourdomain.com, que es un DNS y no se verá afectado por el tipo de redireccionamiento HTTP utilizado. Y "porque la redirección podría suceder ... no la próxima vez" es, por lo tanto, precisamente cierto.

— Random832

0

¿Parece que estás planeando cambiar tus servidores de nombres al mismo tiempo? Debido a la forma en que se descubren los servidores de nombres, tardan mucho más en actualizarse que un registro normal, a menudo alrededor de 24 horas o más.

Le recomiendo que actualice el DNS en su proveedor actual antes de cambiar el DNS, o cambie sus servidores de nombres 7 días antes de cambiar la IP del sitio web.

Las computadoras y navegadores modernos son bastante confiables para obedecer TTL con DNS, pero debe comprender toda la cadena para obtener los mejores resultados.

— codatorio
fuente

Gracias, y sí, esto refleja mi comentario bajo la respuesta de Lightness, arriba. Los resolutores actualizaron los servidores de nombres bastante rápido, en cuestión de minutos. La clave era hacer eso primero, luego esperar unas horas antes de cambiar la dirección IP de destino. Ambos a la vez fueron malos ... muy malos.

— CC