Migration : gérer la propagation DNS sur un site transactionnel

[Boulbi1]

Bonjour,

A l'occasion de la sortie d'une V2, je vais migrer un site transactionnel en .fr sur une nouvelle machine (sans changer de nom de domaine).

Pendant le temps de propagation DNS (estimé à une dizaine d'heures), certains clients vont donc se retrouver sur l'ancienne machine avec la V1 du site.

Pour des raisons de synchronisation des bases avec la V2, je ne souhaite pas qu'ils fassent certaines transactions et créations de compte sur cet ancien site mais je ne voudrais pas non plus fermer complètement le service pendant ce laps de temps.

Je me proposais d'afficher un message indiquant la migration en cours avec un lien en dur vers le nouveau site comprenant l'IP de la nouvelle machine à la place du nom de domaine. (on peut aussi faire un refresh html ou une redirection provisoire par htaccess 302,303, 307 ? )

quelle est la pratique la plus conseillée pour ce cas ? y-a-til d'autres solutions ?

Merci

[Kioob]

Bonjour,

la technique que je préfère pour ma part (ainsi que mes clients) est d'installer un "reverse proxy" sur l'ancienne machine, de façon à ce que les requêtes soient dirigées vers la nouvelle dans tous les cas.

[jcaron]

La première chose à faire, c'est, plusieurs jours avant la migration (en fait la durée actuelle du TTL), réduire le TTL sur l'enregistrement DNS concerné. Habituellement je le baisse à 1 heure quelques jours avant, puis quelques heures avant la migration je descends à 300 secondes. Tu peux ensuite le remonter une fois la migration faite. Ca ne garantit pas que tout le monde bascule en 300 secondes (tout le monde n'honore pas les TTL), mais ça permet déjà de traiter l'essentiel.

Ensuite suivant les cas de figure exacts il y a pas mal de méthodes (pour une simple migration de machine sans changement de contenu, il suffit généralement de basculer les accès de base de données de l'ancien serveur vers le nouveau - à condition que tout ce qui est dynamique soit en base bien sûr, i.e. pas de fichiers temporaires, d'uploads dans des fichiers, etc. Mais ça n'a pas l'air d'être ton cas).

Dans ton cas, un petit proxy genre pound est effectivement la solution la plus efficace pour que les connexions qui restent sur l'ancien serveur soient rebasculées sur le nouveau de façon transparente. Attention cependant si tu as besoin des adresses IP des clients à bien gérer X-Forwarded-For (avec un module comme mod_extract_forwaded sur le serveur cible ça se fait tout seul).Si tu as du SSL ça peut aussi réclamer un peu de boulot pour s'assurer que tout se passe bien.

Jacques.

[mtcocktail]

+1 pour jcaron. Il faut siminuer le TTL de ton domaine pour la migration. à 300 seconde on a vraiment l'impression que la migration est instantané. Pour le mysql j ne m'embêterais pas j'enlèverais les droit de UPDATE INSERT à ton user mysql tous simplement.

[Boulbi1]

Merci bcp : j'ignorais cela. Si je comprends bien le problème de la propagation ne se pose que lorsqu on change les DNS chez son registrar mais pas lorsquon change de machine puisquun seul DNS (lautoritaire) est à mettre à jour dans ce cas ?

Le pb cest que je ne suis pas sûr du DNS autoritaire : En effet, chez mon registrar les DNS déclarés sont ceux de mon hébergeur mais j'ai également paramétré localement ma zone sur mon serveur dédié. Quand je fais un zonecheck, il a lair de trouver tout seul (comment ?) que cest bien ma machine qui est autoritaire.

Si je modifie le TTL de ma zone locale cela sera donc suffisant ? pas besoin dalerter mon hébergeur pour quil change ce paramètre sur ses DNS ni de changer les DNS chez mon registrar pour être cohérent en indiquant ma machine comme primaire ?

Il y a quand même un mystère : pour linstant je vais conserver mes 2 serveurs. Lancien va donc servir de DNS autoritaire pour tous mes domaines. Le jour où je vais abandonner lancien serveur (quand jaurai transféré tous mes sites sur le nouveau), il faudra bien que je recrée avant mes zones DNS sur le nouveau serveur ? il va donc y avoir un conflit dautorité pendant ce temps non ?

Sinon, pour interdire l'écriture sur les bases mySQL, il faut que je sois sûr que les autres sites web hébergés sur le même serveur n'utilisent pas le même user : en plus cela me paraît un peu rude de ne pas prévenir le client avant (il remplit son panier ou remplit un formulaire complet pour publier une annonce puis au moment de passer à l'enregistrement, ça ne marche pas...). L'idée est aussi de permettre la continuité du service.

A partir de là, j'ai trouvé d'autres articles ou discussions intéressants sur le web à ce sujet :

http://www.sens-interdit.fr/2008/07/12/237...s-prise-de-tete

http://forum.webrankinfo.com/changer-sans-...dns-t90000.html

Mais Je n'ai pas vraiment trouvé d'exemple utilisant Pound pour le cas d'une migration d' un seul domaine. J'imagine que le fichier de config doit ressembler à cela :

ListenHTTP
	Address 1.1.1.1
	Port	80
	Client 15
	LogLevel 0
	Service
		URL ".*www.domaine-a-migrer.fr.*"
		BackEnd
			Address 2.2.2.2
			Port	80
		End
	End
End

Si l'URL ne correspond pas, Pound laisse passer ou faut-il prévoir les autres cas ?

Je vais aussi me pencher sur la possibilité de l'IP fail-over.

[jcaron]

Merci bcp : j'ignorais cela. Si je comprends bien le problème de la propagation ne se pose que lorsqu’ on change les DNS chez son registrar mais pas lorsqu’on change de machine puisqu’un seul DNS (l’autoritaire) est à mettre à jour dans ce cas ?

A tous les niveaux, il y a deux problèmes qui peuvent se poser:

- le temps que les mises à jour de l'enregistrement soient répercutées sur l'ensemble des serveurs pour la zone concernée

- le temps que les informations restent en cache à divers endroits (dans les serveurs DNS utilisés par les utilisateurs, dans les clients DNS, les browsers...).

Pour le premier cas, il fut un temps les serveurs secondaires ne récupéraient la zone auprès du primaire qu'à intervalles réguliers (cf valeurs dans SOA), généralement de l'ordre de quelques heures. Maintenant il y a des mécanismes qui permettent au primaire de prévenir les secondaires qu'il y a eu une mise à jour, donc si c'est correctement configuré ça va très vite.

Pour le deuxième problème, c'est basé sur le TTL de l'enregistrement concerné (même si, comme je l'ai déjà dit, ils ne sont pas forcément honorés par tout le monde). Si tu veux changer un enregistrement dans ta zone (genre www.monsite.com) alors tu as le contrôle du TTL et ça peut aller vite. Si tu veux changer de serveurs de noms par exemple, c'est plus problématique, parce que les enregistrements correspondants sont les NS dans la zone supérieure (genre com pour monsite.com). Et ces enregistrements sont contrôlés par le registry pour ce TLD, qu imposent des TTL assez élevés. Donc dans ce cas ça peut effectivement prendre un certain temps (voire un temps certain).

Le pb c’est que je ne suis pas sûr du DNS autoritaire : En effet, chez mon registrar les DNS déclarés sont ceux de mon hébergeur mais j'ai également paramétré localement ma zone sur mon serveur dédié. Quand je fais un zonecheck, il a l’air de trouver tout seul (comment ?) que c’est bien ma machine qui est autoritaire.

Les serveurs DNS de ton hébergeur sont informés que le primaire c'est ta machine? Si c'est le cas pas de souci, si tu fais un changement il sera pris en compte. Tu peux faire un test en ajoutant un enregistrement genre toto.monsite.com et en regardant s'il est pris en compte.

Si je modifie le TTL de ma zone locale cela sera donc suffisant ? pas besoin d’alerter mon hébergeur pour qu’il change ce paramètre sur ses DNS ni de changer les DNS chez mon registrar pour être cohérent en indiquant ma machine comme primaire ?

Si le test ci-dessus fonctionne, pas de souci (n'oublie pas d'incrémenter le serial dans le SOA pour les secondaires voient qu'il y a eu un changement). Avec dig ou nslookup tu peux voir ce que chaque serveur répond. Par exemple:

dig toto.monsite.com. _AT_monserveurdns

dig toto.monsite.com. _AT_serveurdnssecondaire

Tu verras ainsi (ou en regardant l'évolution du serial du SOA) à quelle vitesse l'update est pris en compte (i.e. immédiat si tout est bien configuré ou plus lent sinon).

Il y a quand même un mystère : pour l’instant je vais conserver mes 2 serveurs. L’ancien va donc servir de DNS autoritaire pour tous mes domaines. Le jour où je vais abandonner l’ancien serveur (quand j’aurai transféré tous mes sites sur le nouveau), il faudra bien que je recrée avant mes zones DNS sur le nouveau serveur ? il va donc y avoir un conflit d’autorité pendant ce temps non ?

Il va évidemment falloir que tu créés tes zones sur ton nouveau serveur. Et il va falloir que tu indiques à ton hébergeur quel serveur est le primaire pour la zone.

Mais Je n'ai pas vraiment trouvé d'exemple utilisant Pound pour le cas d'une migration d' un seul domaine. J'imagine que le fichier de config doit ressembler à cela :

ListenHTTP
	Address 1.1.1.1
	Port	80
	Client 15
	LogLevel 0
	Service
		URL ".*www.domaine-a-migrer.fr.*"
		BackEnd
			Address 2.2.2.2
			Port	80
		End
	End
End

Non, URL ne "matche" que la partie après le nom de domaine. Il faut utiliser:

HeadRequire "^Host:.*www.domaine.fr"

Si l'URL ne correspond pas, Pound laisse passer ou faut-il prévoir les autres cas ?

Il ne peut pas "laisser passer", il n'y a pas d'endroit où envoyer quoi que ce soit (il faut évidemment que tu aies déplacé le serveur http existant sur un autre port ou une autre adresse, sinon tu ne pourras pas lancer pound). Il faut lui mettre un autre service sans Headrequire qui prendra tout le reste et l'enverra au serveur d'origine.

Sinon ça doit être possible aussi directement avec Apache, mais je n'ai jamais essayé.

Jacques.

[Boulbi1]

Merci bcp pour toutes ces infos.

En effet mon pb est en passe d'être résolu.

Je vais d'abord déclarer une nouvelle zone du type ns1.mondomaine.tld* sur mon nouveau serveur en la faisant pointer sur l'IP de l'ancien serveur puis je vais changer les DNS chez mon registrar vers cette zone. Ce premier changement sera donc transparent.

Il y avait bien une autre entrée chez le DNS de mon hébergeur : ils vont donc me la supprimer.

J'aurai ensuite la main sur le TTL et pour changer d'IP au moment venu et faire basculer sur la nouvelle machine.

*A noter : quand on crée un nouveau serveur DNS du type ns1.mondomaine.tld, il ne faut pas oublier de le déclarer chez son registrar en indiquant son IP sinon il ne voudra jamais l'accepter comme serveur primaire : je crois que ça s'appelle un "glue record".