Avec les nouveaux tarifs d’OVH, il est très tentant de changer son bon vieux serveur contre un plus puissant, plus beau, plus mieux et plus plus. Au grand dam d’OVH qui n’avait pas prévu que autant de monde se jetterait en même temps sur leurs offres. Mais passons ce point noir.
Les problèmes
Changement de serveur
Changer de serveur n’est pas très compliqué (surtout si vous êtes sur un Linux), mais il faut quand même garder à l’esprit une contrainte de taille : le nom de domaine ne pointera pas sur votre nouveau serveur avant 48 heures (dans le pire des cas).
En d’autres termes, cela signifie que vos visiteurs iront soit sur le nouveau serveur, soit sur l’ancien, pendant 48 heures.
Rien de grave, finalement, si vous avez un site statique. Mais je suppose que si vous avez pris un serveur dédié, c’est pour vous amusez un peu et, comme on parle de jeu ici, pour installer votre jeu avec les classements, les actions des joueurs…
Les solutions
Si vous n’avez pas envie (ou ne pouvez pas) utiliser les IP Fail-Over, vous allez devoir passer par d’autres solutions.
La première consiste à croire qu’il existe un dieu des informaticiens et attendre que ça se passe. Mais je vous déconseille cette solution (ai-je besoin d’expliquer pourquoi ?).
Une autre solution consiste à passer par iptable. Mais comme je n’ai pas tenter le coup, je ne vous dirais pas comment faire.
La solution que je vous propose, c’est d’utiliser Apache pour aller mandater votre nouveau serveur.
Principe
Le principe est simple : l’utilisateur va être dirigé sur votre ancien serveur pendant 48 heures. Pendant ce laps de temps (et même plus par sécurité), Apache ne va pas utiliser le site en local, mais le site sur votre nouveau serveur. Passer le délais de 48 heures, normalement tout vos utilisateurs seront directement branchés sur votre nouveau serveur. C’est un reverse proxy. Simple et efficace.
Évidement, cette solution ne fonctionne pas si votre serveur vient de tomber. Il faut, dans ce cas, utiliser les IP Fail-Over (mais il faut aussi l’avoir prévu en avance).
Étapes
La première étape va consister à préparer votre nouveau serveur : installation d’Apache, Php, MySQL et tout ce dont vous avez besoin.
Faites pointer un sous-domaine sur votre nouveau serveur. Ce sous-domaine va vous permettre de tester votre installation.
Installez ensuite votre site en faisant une copie du site actuel : c’est juste pour vérifier que votre installation fonctionne et ainsi éviter les mauvaise surprise.
Testez votre site (notamment les emails, les droits d’accès aux fichiers, la base de données…). Si tout est ok, vous allez pouvoir commencer le transfert pour de bon.
Commencez par prévenir vos visiteurs en bloquant le site actuel avec un message « Site en maintenance, revenez d’ici 15 min ».
Faites le transfert des données à nouveau si c’est nécessaire (site + base de données).
Pour cela, vous pouvez le faire directement via SSH : scp -rp /var/www/mon-site/ user@adresse-IP:/var/www/
Et maintenant, le truc « magique » : modifiez votre fichier de configuration d’Apache concernant votre site et mettez cela à la place (sur l’ancien serveur) :
<VirtualHost *:80>
ServerName www.mon-site.fr
ServerAlias mon-site.fr www.mon-site.com mon-site.com
ProxyPreserveHost On
ProxyRequests off
ProxyPass / http://ip-nouveau-serveur/
ProxyPassReverse / http://ip-nouveau-serveur/
</VirtualHost>
Reste à installer 2 modules :
a2enmod proxy
a2enmod proxy_http
Et à redémarrer Apache :
service apache2 restart
Et voilà le travail.
Pour astuce, je place toujours un détail sur le nouveau site afin de savoir sur quel site je suis réellement. Ce peut-être un point « . » à la fin du titre des pages par exemple.
Il ne vous reste plus qu’à faire pointer votre nom de domaine sur votre nouveau serveur et d’attendre 2 ou 3 jours avant d’être certain que tout le monde ne passe plus par l’ancien pour supprimer définitivement l’ancien serveur.
Conclusion
Avec cette astuce, vous n’aurez pas perdu de données et vos utilisateurs n’y auront vu presque que du feu (hormis la page de maintenance).
N’oubliez pas d’adapter les étapes à votre situation. Et si vous n’utilisez pas Apache, vous pouvez faire de même, très certainement, avec votre serveur, mais ce ne sera pas les même commandes. Dans ce cas, renseignez vous sur le « reverse proxy ».
Salut,
Très bonne idée.
J’y aurai peut-être recours très prochainement.
SAUF QUE ce sera la dernière fois.
Vu les matériels proposés chez OVH par exemple, je vais réinstaller en virtuel via ESXi ma prochaine machine Debian. Ainsi, lorsque je changerai de serveur une prochaine fois, j’aurai juste une copie de fichier à faire. Et même plus de manips DNS car pour que mon Linux virtuel ait une IP publique, je dois en louer une supplémentaire (pas une failover d’OVH) et donc elle m’est propre. Donc l’IP de l’ESX changera à chaque changement de serveur, mais pas l’IP de la machine virtuelle.
Si le support ne m’a pas raconté des bobards sur la propriété de l’IP louée.
Next question: vu la pénurie en ce moment et mon serveur actuel mourant (2 HD cramés/changés mais accusant des perfs minables et des remontées SMART accablantes), j’hésite à prendre au Canada pour à peine plus cher (tant pis pour la latence, c’est pas pire que mes HD lents actuels) puis lorsqu’on pourra louer à nouveau => basculer vers un autre en France et copier ma machine virtuelle. J’ai juste un doute sur la 2è IP…. qu’elle puisse passer du Canada à la France comme ça, ça me ferait mal.
Je tâcherai de vous tenir au courant de ces solutions
Jacques
Bon, les plages d’IP du Canada ne pourront pas revenir en France. Ca c’est vu (et ça semblait logique).
Donc reste à louer n’importe quoi en Europe en attendant de pouvoir revenir sur le modèle que je veux….
Mais tout en sold out depuis milieu de matinée, késsessésbordel ?
Une explication claire du « Sold Out » total chez OVH : http://www.ovh.com/fr/a1186.pourquoi_160sold_out160
Article intéressant !
J’ai effectivement suivi votre méthode lors de la migration de mon serveur.
Juste un détail, j’ai du ajouter des droits supplémentaires pour que cela marche parfaitement.