Déplacer un site entier d'un serveur (ou hébergeur) à un autre n'est pas toujours chose aisée, surtout quand il s'agit d'un site dynamique et actif.

Beaucoup ignorent le fonctionnement de la propagation des zones DNS (et des TTLs ou durées de vie). L'erreur numéro 1 à ne surtout pas commettre est de changer les serveurs DNS, leur pointage et le serveur en même temps. L'erreur est fréquente et conduit au mieux à des sites "parallèles" : deux versions à gérer, et des interactions aléatoires avec les utilisateurs. Au pire : le site disparaît, les mails n'arrivent plus et le monde s'écroule.

J'ai récemment vu plusieurs fois ce genre d'annonce de service :

Bon allez, c’est parti, la copie du blog est en place sur le nouveau serveur et la base remontée, je modifie le DNS et la propagation devra se faire dans les 24, 48h. Demain [le blog] aura donc changé de serveur si tout est Ok. [...]

Les éventuels commentaires postés sur l’ancien serveur pendant la période de migration ne seront pas présent sur le nouveau serveur. Ce post ne sera pas visible non plus sur le nouveau serveur.

(bold ajouté par mes soins)

Même si prévenir ses utilisateurs, lecteurs et clients est une bonne chose, je trouve dommage de s'avouer si vite vaincu par un outil technique inconnu. Et de leur faire subir, également.

Voici quelques exemples de migrations mal planifiées malgré une certaine notoriété des sites et/ou de leur responsable :

• Jeremie Berrebi change son blog de serveur : ... Bon, c'est pas trop grave, seulement quelques commentaires perdus. Le contenu était toujours accessible (en dehors des nouveaux articles bien sûr)
• Eric Dupin déménage Fuzz, domaine, DNS et serveur en même temps. Résultat : plus de 72 heures de downtime... Et autant de frustration pour les utilisateurs de ce service web.
• Mathilde décide de déménager Bagatelles.fr : catastrophe ! Outre l'indisponibilité du site, l'export se passe mal (visiblement un problème d'encodage), mais surtout pendant plusieurs jours, pas de commande ni d'email... Dans le e-commerce, non seulement la perte est quantifiable, mais c'est aussi le sérieux, l'image et la confiance de l'enseigne qui est remise en cause.

Heureusement, tous les déménagements de serveur ne se passent pas aussi mal et tout un chacun (un minimum réceptif à la technique) peut parvenir à déplacer son site sans problème et surtout sans le classique délai inexploitable de 24 à 48 heures... Il suffit de faire les choses dans le bon ordre !

Voilà ma procédure :

On suppose que :

• le domaine est configuré pour recevoir ses emails (MX) sur un serveur tiers (Google Apps, par exemple), le contraire étant pour moi une hérésie.
• on n'a pas de solution type "IP fail-over" permettant de basculer le routage d'une adresse IP instantanément (et annulant la problématique des DNS)

Y a-t-il transfert de domaine ?

OUI : S'il y a transfert du domaine d'un registrar à un autre, il faut prévoir au moins 2 à 4 semaines pour avoir la certitude que le transfert sera fait au bon moment. Pour un .com, c'est plus rapide, pour un .fr, ça peut être plus lent... La procédure varie selon l'extension du domaine et les registrars entrant et sortant, je ne la détaille donc pas plus. Attention toutefois à bien laisser les mêmes serveurs DNS que précédemment, sans quoi le domaine risque d'être "parké"...

NON : Rien à faire pour l'instant.

Y a-t-il changement de serveurs DNS ?

OUI : Il faut s'y prendre au moins une semaine à l'avance. Dans un premier temps, configurer la nouvelle zone à l'identique de l'ancienne. Seuls les champs SOA et NS diffèrent, puisqu'ils doivent contenir l'identité des nouveaux serveurs DNS. Ensuite, lancer la procédure au niveau du registrar. Il peut se passer plusieurs heures (habituellement entre 6 et 48 heures) avant que le changement soit bien pris en compte partout. Toutefois, même pendant la transition, le site est accessible et fonctionnel. Zéro coupure.

Note : S'il y a transfert de domaine ET changement de serveurs DNS, la procédure au niveau du registrar peut n'être effectuée que sur le nouveau registrar au moment du transfert, tant que les nouveaux serveurs DNS sont configurés correctement. D'une pierre deux coups, et toujours aucune coupure malgré une transition un peu longue.

NON : Rien à faire pour l'instant.

Étapes préliminaires

Le nouveau serveur

Il faut bien le faire à un moment, ça peut être fait bien avant les transferts de domaine et DNS, ou pendant, ou après.

Commander, installer, configurer, et tester le nouveau serveur (ou hébergement). Mais surtout, y installer une copie du site : si le site crée/supprime des fichiers (upload d'images/vidéos par exemple), on utilisera de préférence rsync. Si les fichiers sont statiques (comme un blog : aucun fichier n'est créé en dehors des images ajoutées aux billets), une copie pure et dure à coup de scp ou via FTP est également possible. rsync est nettement plus souple (ne copie que ce qui diffère) et rapide (liaison serveur à serveur vs serveur vers client vers serveur), mais ne peut pas toujours être utilisé (il faut un accès SSH et/ou un hébergeur sympa).

Y installer une copie de la base de données. Un réimport de backup à peu près à jour peut faire l'affaire. J'ai une commande magique et extrêmement rapide pour ça, mais c'est secret défense :) Ce qui compte, c'est que la structure SQL soit à jour, peu importe pour les données elles-mêmes.

Pour pouvoir tester correctement le nouveau site sur le nouveau serveur, la meilleure solution à mon goût est de modifier temporairement son fichier hosts (ce fichier permet de passer outre les serveurs DNS pour résoudre un nom en adresse IP) pour tester le site sur le nouveau serveur et ajuster les petis détails si besoin (un module oublié, une permission mal remise, etc.). L'emplacement du fichier dépend du système d'exploitation, mais Google a la réponse.

Cette étape de test permet un passage en production sans aucun problème.

Réduire les TTLs au niveau de la zone DNS

Malgré des acronymes barbares, les TTLs (pour Time To Live) sont de précieux alliés s'ils sont bien utilisés, mais sont aussi la cause de tous les problèmes cités plus haut quand ils ne sont pas compris et maîtrisés. La propagation, ennemie jurée ? Je dirais plutôt amie incomprise...

Une fois les transferts administratifs effectués et effectifs (soit minimum 48h après l'application du changement de serveurs DNS et au moins autant après la notification de fin de changement de registrar), il faut donc réduire les TTLs. La procédure change du tout au tout selon l'entité qui gère les DNS : interface d'administration ou fichier de configuration... Le principe reste le même : il faut que chaque enregistrement dans la zone expire le plus vite possible. Par défaut, la valeur est souvent de 86400 secondes (24 heures). Je recommande une valeur de 5 minutes maximum (300 secondes), 1 minute si possible (60 secondes). Il ne faut surtout pas modifier le pointage des enregistrements pour l'instant.

Cela aura pour effet de rendre les prochains changements rapides, et de réduire la période de propagation à quelques minutes... Et pour l'instant toujours rien de visible par les utilisateurs, lecteurs et clients.

Transfert des données

Quand toutes les étapes précédentes sont terminées et vérifiées, on peut passer au transfert réel des données.

Afin de conserver l'intégrité des données, il convient de passer l'ancien site en lecture seule, sans quoi des évènements aléatoires peuvent se produire. Il faut ensuite mettre à jour les fichiers (rsync ou FTP) et la base de données. C'est pendant cette étape que la migration apparaît aux utilisateurs, puisqu'ils ne peuvent plus intéragir. Dans certains cas (média), cela peut tout à fait passer inaperçu. La durée de la copie est variable et dépend directement de la taille du site.

Une fois le transfert effectué, vérifier (toujours grâce au fichier hosts) une dernière fois que le nouveau site est en état, puis changer le pointage DNS sans modifier les TTLs (au cas où un problème survient, le retour en arrière doit rester possible rapidement). Le changement sera propagé en quelques minutes seulement (penser à retirer la ligne du fichier hosts pour confirmer...), le nouveau site est en production.

Finalisation

S'il n'y a toujours pas de problème après quelques minutes ou heures, il faut remettre les choses en mode croisière : remettre des TTLs longs (1 jour / 86400 secondes), lancer une première backup sur le nouveau serveur et récupérer (et conserver) la dernière backup de l'ancien serveur.

Conclusion

Zéro coupure, zéro bizarrerie, seulement un passage en lecture seule de quelques minutes (durée égale au temps de la mise à jour des données).

Tout ça parce que la transition a été planifiée, surtout pas précipitée, et que les choses ont été faites dans l'ordre.