Bonjour,
 
Je dois transférer le contenu d'un serveur web (Sites web + Bdd MySQL) en production depuis un vieux serveur vers un nouveau (il s'agit de 2 serveur dédiés chez 2 fournisseurs différents), le tout en causant le moins d'interruptions possible sur les sites.
 
À priori j'aurais pensé à faire ça dans cet ordre :
- Écrire directive dans un .htaccess qui redirige tout le trafic vers une page expliquant que le site est en maintenance
- rsync (avec les options qui vont bien) de tous les sites vers le nouveau serveur
- Export BDD de l'ancien serveur, import dans le nouveau
- Écriture d'une directive sur le vieux serveur qui lui fait interroger le nouveau serveur concernant le contenu de la page (on demande www.vieuxserveur.com/page, le vieux serveur demande la page à nouveau.serveur.hebergeur.com/page et la rend de manière transparente à l'utilisateur)
- Mise à jour des DNS
- 24h plus tard : Extinction de l'ancien serveur
 
Qu'en pensez vous? La seule étape que j'ai jamais faite est celle de rediriger le flux d'un serveur à l'autre, mais sauf erreur c'est possible non?
Sinon vous avez mieux?
 
Merci d'avance

pour la redirection tu as la directive http 301 qui est faite pour ça

sinon, fait un rsync avant pour faire le gros du boulot, et un une fois que tu auras mis ta page de maintenance en place (et si ton contenu ne change pas, pas besoin de le refaire)

Pour la MaJ des DNS selon ton temps d'export / copie / import tu peux le faire avant au vu des délais de propagation du DNS

Et attendre un peu plus de 24h, ceinture bretelles.

+le slip en zinc  
mais normalement ça passe, n'oublie pas de te faire un cahier de migration technique
afin de ne rien louper sur chaque service que tu proposes.
par contre j'aurais rsync également les données mysql sauf concernant le passwd "root"
sauf si tes 2 versions de mysql sont trop éloignées  
 
ya toujours des p'tis trucs à la con qu'on peut oublier, genre :
"recoder entièrement le site d'un client car les chemins sont en absolus/relatif et vice versa"  
"faut resigner le ssl d'un module terminal de paiement"  
"recopier en pleine nuit de la migration, le répertoire mail du directeur de gestion de la boite untel"

Salut,
 
Concernant le http301, la migration sera donc visible car le client se verra redirigé vers nouveau.serveur.hebergeur.com/page, ou bien c'est apache qui fait tout "en interne" et le client n'y voit que du feu?
 
Une fois j'ai lu un topic ici sur rsync où quelqu'un disait que rsync sur une base de donnée c'est pas une bonne idée, et qu'il faut plutôt voir pour un export "dans les règles". De toutes façons, quel serait le problème de faire un export + import bdd MySQL, à part que je suppose que c'est plus long (et encore ... on parle pas de base de données de XGo pièce )

Probleme de charset entre les 2 machines qui fait que qd tu reimport toutes les lettres accentuées sont ko

un import et export est donc envisageable en txt.
après clair qu'il faut faire attention au charset, mois j'en retrouve encore de temps en temps dans mes bdd
j'ai même été obligé de demander à un client de ne plus utiliser le ' dans son export de bdd, ça se passe pas bien
avec sa version d'oracle de son main ibm ==> csv ==> ftp ==> chargement mysql  tout ça pour un pov' champ de commentaire
hérité qui n'est quasiment jamais utilisé

D'accord ..
Par contre pour ce qui en est du HTTP301? Est-ce que les clients verront la redirection ?

Edit : Ok je viens de tester sur ma machine et effectivement on voit la redirection. Est-ce qu'il n'y a pas une manière de le faire "en interne" (le client demande www.vieuxserveur.com/page, le serveur lui retourne le contenu de nouveau.serveur.hebergeur.com/page, mais sans le rediriger?

je ne pense pas  
sinon tu peux demander à ton nouveau presta. de te donner une p'ti coup de pouce dans les prérogatives
d'une migration de serveur.

je ne vois qu'un montage de partition à travers les 2 serveurs pour cela.
sinon pourquoi ne pas opérer sur la zone du(des) dns?

J'avais pensé au montage de partition mais j'ai peur que ce soit trop lent ( et donc qu'on risque de se prendre des timeout PHP/... en travers de la gueule ) .. Mais peut-être c'est juste une impression non fondée?
 
Tu entends quoi par opérer sur la zone des DNS (faut savoir qu'il y a plus que 40 adresses web pointant sur le serveur)

oui c'est certainement trop lent via un montage de partitions. mais j'essayais de répondre directement à ta question.

s'il y a 40 nom de domaine pointant sur ton serveur et autant Vhosts, alors il faut modifier l'ip primary à ce niveau (au niveau du registrar de tes dns).
la propagation se fera "toute seule". ceux dont le cache dns sera encore l'ancienne ip pointeront sur ton ancien serveur,
ceux disposant du nouveau cache-dns pointeront sur ton nouveau serveur.

Oui bien entendu, mais ceci causera des problèmes étant donné qu'une majorité des sites en question sont des boutiques, et que donc leur contenu ( disponibilité du matériel, nombre de commandes, ... ) va évoluer pendant le laps de temps qui séparera la migration du "switchage" des DNS.

Edit: Une idée qui me vient serait (ça sera très chiant pour moi mais bon...) de créer un sousdomaine (new.vieille-adresse-du-site.com) pour chaque site qui pointent directement vers l'adresse du site sur le nouveau serveur, et de mettre la redirection HTTP301 pointant vers ces sous-domaines...

ok, ton pb se situe à la mise à jours temps réel des bdd.
dans ce cas, il faudra faire la bascule de tes bdd en derniers.
en attendant la migration des dns, il faut que ton nouveau serveur http attaque tes bdd sur ton ancien serveur (si possible).
à la fin de la propagation, tu synchronises tes bdd et tu fais une bascule genre à 3h du mat.

Ok merci.
Je vais voir ce que le boss en pense.

Normalement les accents sont des codes HTML, et les bases de données tu spécifies le charset à l'import. Si les serveurs (surtout le nouveau) sont bien gérés c'est flawless

Le 301 c'est surtout fait quand on change d'adresse (de nom de domaine) et pas d'IP. laisse faire le DNS...

Vu que les contenus sont en BDD, tu peux rsyncer les fichiers, et "figer" les fichiers. Oublie les sous domaines, c'est une usine à gaz...

Est ce que tu as tout tes domaines chez le même registrar ? parce que si ils sont genre chez gandi, c'est facile d'utiliser leur API pour tout changer en qq secondes.

Sinon ton problème c'est la réplication des bases. Tu peux monter un VPN inter sites, et mettre en place une réplication master (ancien) => slave (nouveau) à travers ce VPN. Une fois que tes DNS sont propagés alors tu peux passer ton slave en "standalone" (là je suppose que tu n'utilises pas de réplication).

Les 2 contraintes : que ton lien soit assez rapide (normalement ça devrait aller) et que tes DNS changent tous en même temps (c'est d'ailleurs surtout ça l'écueil principal).

EDIT : fin du fin, tu peux ruser sur le délai de propagation des DNS, mais à une condition : que chaque site aie sa base de données dans ton MySQL. Exemple :

Quelques jours avant la migration tu descends le TTL DNS de tes enregistrements à une valeur ridiculement petite, du style 5 minutes, ainsi les caches ne te feront pas de mauvaise surprise. Si tu fais ça la nuit, 5 minutes ne devraient pas causer d'incohérence dans la base.

• Site1a lit/écrit sur Base1a.
• Base1a est répliquée vers Base1b
• l'adresse IP pointe sur Site1a (qui travaille à priori sur 127.0.0.1) jusqu'à ce que tu fasses ta modif
• Quelques minutes après ton changement, l'IP pointe sur Site1b, qui est une réplique de Site1a et qui lui aussi travaille sur 127.0.0.1 sauf que là l'IP représente Base1b et là magie, tout se passe sur le nouveau site.

Gare aux caches DNS (qui te feront chier de toute façon) qui ne respectent pas ton TTL. Pour ceux là, des mesures radicales : tu mets un message sur les "anciens vhosts" après la modification du DNS. Ton apache ne servira alors plus qu'une seule page, dynamique indiquant à tes clients que le site X est actuellement en maintenance et que les serveurs de son FAI seront bientot mis à jour.

Voila, c'est la méthode que j'utiliserai

mod-proxy
 
Mais c'est la tannée à configurer je trouve

 
ça on verra après le déploiement je pense
 
 
 

 
Non on a des .com et .ch .. Donc pas tous au même endroit
 

Non effectivement, et là comme ça je ne saurais pas la mettre en place (ni le VPN). Y aurait pas moyen de faire passer ça par un tunnel SSH? Comme ça je devrais "juste" apprendre à mettre en place cette réplication.
 

 
Ok donc dans ce cas là ce que je devrai faire (dans l'ordre):  
- descendre le TTL DNS  
(attendre quelques jours, ce qui me donne le temps de voir pour cette histoire de réplication)
- mettre en oeuvre la réplication de la base de donnée de chaque site (chaque site a son propre schemas mysql)
A 3h du mat :  
- Redirection de tout le flux vers une page "Site Offline, be back soon"
- rsync de tout le contenu (histoire qu'il change pas à cause d'éventuels uploads & co)  
- changement des DNS  
Quelques jours plus tard
- Fermeture du site.
 
J'ai juste?
 
e_esprit : Je vais regarder ça aussi  
 
En tous cas merci beaucoup pour vos réponses!

Bonjour,
 
Entre temps je me suis renseigné sur la réplication MySQL ( merci http://www.howtoforge.com/mysql_database_replication ). Par contre j'ai vu plusieurs sites qui expliquent comment mettre en place la réplication à travers un tunnel SSL (ce qui me semble quand même plus simple que de configurer un VPN).
 
Vous avez un avis sur ça?

c'est du temporaire donc y'a pas de "vraie" raison de dire non

edit : un openvpn c'est qq minutes de taff hein

C'est juste que des tunnel SSL, j'en fais 2 par jour. Par contre j'ai jamais configuré un VPN.. Donc je préfère ne pas faire mes tests sur un serveur en prod Ceci dit si tu as une doc là dessus, je suis preneur.
 
Je pense que je vais utiliser ta méthode (toujours que le boss n'ait pas vu que ce se serait de mauvais augure dans le vol des oiseaux/ feuilles de thé). Par contre il y a une raison pour laquelle tu n'as pas utilisé le mod_proxy en lieu et place de toute cette procédure? Parce que d'un point de vue conceptuel (et donc probablement faux vu mon niveau dans la matière ) ça me semble beaucoup plus "évident" et DNS-delay-proof ... Je me trompe ou?

ah oui tu as qd même des uploads (forums??) dans ton contenu aussi?
dans ce cas, il faut tout faire d'un bloc (pour les .ch et autres .fr et bien mettre en place
effectivement un message de maintenance unique sur ton ancien serveur);
m'enfin le faire un dimanche à 3h du mat devrait minimiser les pb avec les clients pros.  
 
anecdote :
me souvient d'une fois où notre presta (tiscali sans faire de pub) en lien direct a mis trop de temps à changer l'ip .fr chez l'afnic en attendant le transfert de registrar  
et il a fallu faire machine arrière    
pendant 3jours du lundi au mercredi, le téléphone n'a pas arreté de sonner

La majorité des sites sont des boutiques en ligne, donc là suffira de dire aux proprios de pas commencer à uploader la collection printemps en plein milieu de la migration. Mais il y a plusieurs sites où les utilisateurs peuvent uploader des documents, et donc là faut qu'on coupe.
 
Ceci dit, ma question à propos de mod_proxy reste, parce que je suis tombé sur une page ( http://www.apachetutor.org/admin/reverseproxies ) qui explique comment ça fonctionne, et même si c'est effectivement un peu un calvaire de lui faire parser toutes les URL dans tous les sens, je me dis que ça pourrait être tout de même une bonne façon intéressante de résoudre le problème des DNS, non? Il me suffirait de couper tout les Vhosts pendant le temps que je migre la base de donnée + rsync le contenu des directories, ensuite je relance apache avec les règles proxy en place et ordonne la modification des DNS.
Si tous va bien les utilisateurs auront 5 min de coupure et après que le DNS switch 5 min après ou 24h après, ils ne verront aucune différence.
 
Qu'en pensez vous?

 
parce que je l'ai encore jamais utilisé  

 
que c'est une bonne idée d'utiliser un reverse proxy.

oui, il faut bien couper un jour de toute façon. prévenir avant les pros, il faut... pour les autres (persos), ils feront avec.  
tu peux faire un rsync régulier des nouveaux fichiers créés dans ce sens (de l'ancien vers le nouveau juste sur le contenu d'upload) pendant les 24-48h suivants.