Le meilleur moyen de changer l'adresse IP du site - du point de vue de l'utilisateur final?

10

J'ai lu un tas de questions / réponses pertinentes ici, mais je ne sais toujours pas quelle est la meilleure réponse.

Je déplace quelques sites de l'adresse IP "1.abc" vers "2.def". À partir de maintenant dans le DNS existant, j'ai défini tous les TTL à 300 secondes, et j'ai une nouvelle zone DNS prête à être utilisée (sur AWS Route 53), avec de nouveaux serveurs de noms et tous les TTL à 60 secondes. Je pense donc que je suis prêt, du point de vue DNS. Après le déménagement, après quelques jours, je fixerai TTL à des nombres plus raisonnables sur la Route 53.

J'ai averti tous mes utilisateurs du déménagement et j'ai une fenêtre de temps définie pour le déménagement. Je leur ai dit qu'une fois le déménagement terminé et si 24 heures se sont écoulées et qu'ils voient toujours les anciens sites (verrouillés), ils devraient redémarrer leur ordinateur pour forcer le vidage du cache DNS local.

Je ne comprends pas comment le navigateur (cache) de l'utilisateur joue un rôle à cet égard. Mes propres expériences avec un fichier d'hôtes local (Win7) me disent qu'il y a quelque chose dans le navigateur qui ne laisse pas disparaître l'ancienne adresse IP - j'ai dû aller à l' historique -> tout effacer pour obtenir le nouvel emplacement du site à afficher , même aprèsipconfig /flushdns

(EDIT) - Je n'ai pas d'accès root à l'ancien serveur, donc je ne peux pas implémenter la réponse acceptée à cette question .

Question: Je ne veux vraiment pas que mes utilisateurs soient confrontés à cela, alors y a-t-il quelque chose que je puisse faire pour forcer tous les navigateurs à se remettre en cache? Et si oui, combien de temps dois-je le laisser allumé?

Merci...

domain-name-system migration

— CC
source

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

Pouvez-vous fournir quelques informations à ce sujet? Afaik, les navigateurs ne mettent pas en cache les enregistrements DNS pendant plus d'une minute.

— Tanmay

Pas sûr, mais après plusieurs ipconfig / flushdns et "ctrl-F5" (dans Firefox), je continuais à obtenir un mélange de pages de l'ancien site et du nouveau site ... finalement j'ai dû effacer "tout" et redémarrer navigateur. Je ne veux pas que mes utilisateurs fassent de même ...

— CC

JBTW, la solution dans le lien que vous avez fourni peut également fonctionner si vous avez un accès root au nouveau serveur. Mettez à jour les enregistrements DNS et transférez tout le trafic du nouveau serveur vers l'ancien, jusqu'à ce que le DNS se propage correctement.

— Tanmay

merci ... mais il faudrait que je synchronise l'ancien vers le nouveau (bases de données, etc.) plus tard, non?

— CC

Vous devrez synchroniser la base de données une fois, juste avant de désactiver le transfert.

— Tanmay,

15

Non, tu ne peux pas. Le problème est que la réponse DNS peut être mise en cache n'importe où entre l'utilisateur et le serveur DNS et il n'y a aucun moyen de les invalider.

Ce que vous pouvez cependant faire - dès que vous avez des données synchronisées et que votre deuxième site est prêt, vous pouvez reconfigurer le serveur d'origine pour qu'il se comporte comme un proxy et transmette toutes les demandes au nouvel emplacement.

De cette façon, vous pouvez atteindre presque 0s de temps d'arrêt de votre site Web.

Mettre à jour

Si vous ne disposez pas d'un accès root, il existe plusieurs options:

Effectuer un proxy en PHP
Configurez le proxy sur le deuxième serveur (si vous y avez un accès root), changez DNS et lorsque vous êtes prêt, changez le proxy en serveur Web
Cette méthode peut être source de problèmes Avoir 2 adresses (www.domain.tld et www2.domain.tld). Configurez www2 (qui est identique à www) et définissez les enregistrements DNS corrects. Préparez ensuite la version www de votre site et faites le basculement du DNS. Définissez la redirection de toutes les demandes sur l'ancien serveur vers le sous-domaine www2.

— Yarik Dot
source

Pourriez-vous développer un peu ce point, ou avec un pointeur sur un article ou une Q / A que je pourrais lire? Je n'ai pas d'accès root au serveur existant, donc je ne peux pas manipuler directement les tables IP ... alors peut-être qu'il existe une autre façon?

— CC

@CC peut-être avez-vous accès pour remplacer votre application par une instance HAProxy? Ou remplacer votre code d'application par un autre qui transmet purement la demande au nouveau serveur?

— Jason Martin

@JasonMartin - J'ai accès à .htaccess et au code d'application. Donc, oui, je pourrais probablement saisir l'URL demandée et la transmettre à la nouvelle adresse IP - peut-être devrais-je essayer cela?

— CC

@CC qui semble prometteur alors. Le DNS est un outil `` finalement cohérent '', et certains serveurs DNS fixent des étages dans leur TTL et ignoreront vos 300. Si vous souhaitez éviter toute interruption, un proxy de transfert est le meilleur choix.

— Jason Martin

4

En théorie, la définition du TTL du domaine à quelque chose de bas et l'attente de ce changement, puis la modification de l'IP, devraient entraîner une migration presque transparente. Après tout, c'est tout l'intérêt du TTL qui est configurable.

Dans la pratique, les gens mal configurent les choses et les outils se cassent. C'est pourquoi vous devrez peut-être fournir des instructions à vos utilisateurs pour effacer leur cache local si les choses ne fonctionnent pas correctement.

Mais vous ne faites rien de mal.

— Courses de légèreté en orbite
source

Dois-je passer immédiatement au nouveau DNS AWS Route 53 - avec l' ancienne adresse IP - puis, une fois la migration terminée, changez simplement l'adresse IP par la nouvelle? - ou simplement changer le DNS pour le nouveau et changer l'IP en même temps?

— CC

1

@CC: Je ne suis pas un administrateur réseau, alors prenez cela avec une pincée de sel (et je suis heureux d'entendre le contraire des gourous de ServerFault), mais je recommanderais personnellement de ne pas changer les deux à la fois. Obtenez votre DNS trié, puis effectuez le changement d'IP et laissez le nouveau DNS faire son travail en vous aidant avec cette dernière partie.

— Courses de légèreté en orbite

1

Eh bien, j'ai essayé une expérience. Un site, j'ai changé les heures DNS au préalable, puis changé l'adresse IP d'enregistrement A plus tard. Fonctionne parfaitement. L'autre site que j'ai changé à la fois. Il se débattait entre l'ancienne et la nouvelle adresse IP pendant des heures - J'ai finalement supprimé la zone AWS Route 53 et l'ai fait de la même manière que le premier site. Fonctionne parfaitement. Donc pas besoin d'une pincée de sel - vous étiez sur place!

— CC

1

Inévitablement, votre ancienne adresse sera mise en cache et utilisée pendant longtemps - principalement par des bots.

Comment je le ferais:

Créez un enregistrement A, par exemple www2.yourdomain.com, pointant vers une nouvelle adresse IP. Ce dossier n'aurait jamais dû être utilisé auparavant; donc jamais mis en cache.
Rediriger les requêtes sur l'ancien serveur vers www2.yourdomain.com
Surveillez les redirections et lorsque le trafic diminue à un niveau acceptable, supprimez l'ancien serveur.
Et enfin, une fois l'ancien serveur supprimé, redirigez www2.yourdomain.comvers www.yourdomain.com.

Assurez-vous d'utiliser 301 redirections permanentes. https://en.wikipedia.org/wiki/HTTP_301

— ClickLabs
source

Mon intuition est qu'il ne devrait pas utiliser 301 pour le premier tour de redirections, mais seulement pour le second. Y a-t-il une raison particulière pour laquelle il ne devrait être connu que d'une personne ayant la sagesse SEO ésotérique?

— Random832

@ Random832 Un permanent indique à l'agent utilisateur d'oublier l'ancienne URL et, par exemple, de mettre à jour les signets pour pointer vers la nouvelle URL (donc la prochaine fois, ils pourraient accéder directement à la nouvelle URL). Il n'y a aucun mal à rediriger plus tard (ou même à revenir à l'URL d'origine). En revanche, une redirection temporaire indique à l'utilisateur-agent de conserver l'URL d'origine (car la redirection peut arriver à une cible différente ou pas du tout la prochaine fois). Ainsi, avec des redirections temporaires, la surveillance de la redirection ne tomberait jamais à un "niveau acceptable".

— Hagen von Eitzen

@HagenvonEitzen Elle tombera à un niveau acceptable car les navigateurs cesseront d'obtenir l'adresse IP de l'ancien serveur pour www.votredomaine.com, qui est une chose DNS et ne sera pas affectée par le type de redirection HTTP utilisée. Et "parce que la redirection pourrait se produire ... pas du tout la prochaine fois" est donc précisément vrai.

— Random832

0

On dirait que vous envisagez de changer vos serveurs de noms en même temps? En raison de la façon dont les serveurs de noms sont découverts, leur mise à jour prend beaucoup plus de temps qu'un enregistrement régulier - souvent environ 24 heures ou plus.

Je vous recommande fortement de mettre à jour le DNS chez votre fournisseur actuel avant de changer de DNS, ou de changer vos serveurs de noms 7 jours avant de changer l'adresse IP du site Web.

Les ordinateurs et les navigateurs modernes sont assez fiables pour obéir aux TTL avec DNS, mais vous devez comprendre toute la chaîne pour obtenir les meilleurs résultats.

— codatoire
source

Merci, et oui, cela reflète mon commentaire sous la réponse de Lightness, ci-dessus. Les résolveurs ont actualisé les serveurs de noms assez rapidement - en quelques minutes. La clé était de le faire d'abord, puis d'attendre quelques heures avant de changer l'adresse IP de destination. Les deux à la fois étaient mauvais ... très mauvais.

— CC