Changement hébergeur site e-commerce : méthodologie ?

[Just]

Bonjour à tous !

J'ai en charge le déménagement d'un site e-commerce à audience moyenne (10 000 visite/jour, 30Gb de bande passante/jour).

Je suis en train d'élaborer les procédures qui vont encadrer ce déménagement (d'un serveur dédié chez le prestataire X, vers un serveur dédié chez le prestataire Y).
Le point sensible est bien entendu le passage de relais entre l'un et l'autre.
J'ai bien ma petite idée sur la chose, mais je cherche des avis pour confronter les façon de faire.

Donc, vous, comment vous-y prendriez vous svp ?

Merci d'avance pour vos contribution !

 

[jcaron]

La difficulté, c'est généralement le transfert de la partie dynamique d'une machine à l'autre en minimisant la coupure. Si les choses sont bien faites, la partie dynamique c'est uniquement la bdd, mais il y a souvent d'autres choses (en particulier les images des produits, mais là c'est un processus qui est facilement maîtrisable).

Une méthode:

- réduire le TTL à 5 minutes sur les enregistrements DNS quelques jours avant
- ajouter un enregistrement genre www2.domaine.tld qui pointe vers le nouveau serveur
- copier tout le site et toute la base de données sans réfléchir, le configurer pour qu'il accepte le www2, tester que tout va bien sur la nouvelle machine (de préférence en ajoutant en local un filtre qui empêche l'accès à l'ancien serveur, éventuellement tout bêtement en ajoutant dans le fichiers hosts une entrée vers une IP bidon pour son nom)
- tout effacer sur le serveur de destination
- au moment de la migration:
- bloquer les accès au serveur initial
- copier le contenu statique
- copier la bdd
- changer le DNS
- faire une redirection vers www2 sur le serveur initial (pour ceux qui ont encore l'adresse de www en cache)
- attendre qu'il n'y ait plus aucune connexion sur l'ancienne machine
- remonter le TTL

Avec de la réplication de bdd tu peux réduire le downtime à pratiquement 0, le tout est de savoir si le jeu en vaut la chandelle. A la place de la redirection il y aussi la possibilité d'utiliser un reverse proxy (genre pound), mais il faut préparer un peu la chose à l'avance.

Jacques.

 

[Just]

Merci beaucoup Jacques !
Tout ça va m'être très utile.

Beaucoup de terme technique que je ne maitrise pas ou peu, mais je vais fouiller avant de poser des questions.

Tout autres avis/méthode est bon à prendre, donc n'hésitez pas à participer au TOPIC.

 

[Just]

Bonjour,

@ Jacques : je reviens vers toi, le jour J approchant.
Quelques questions :
- Réduire le TTL à quelques minutes aura pour conséquence des temps d'accès plus long à mon site, non ? Étant donné que les FAI seront obligé de faire une résolution de nom quasi à chaque chargement du NDD (si j'ai bien compris le principe) ?
- Dans ton processus, tu ne précises pas quand est-ce que le www redirige sur le nouveau serveur. J'imagine que cela intervient au moment de la migration ? A quoi sert exactement le www2 ? Est-ce uniquement pour pouvoir faire les tests (pour ça je me suis débrouillé avec un NDD fictif et en bidouillant le fichiers host de windows en local) ?

Merci d'avance pour tes précieuses lumières qui m'ont déjà énormément aidé.

 

[jcaron]

La résolution DNS reste quand même très rapide, mais c'est vrai que ça va prendre un tout petit peu plus de temps (ça reste quand même très très inférieur à 1 seconde, hein) pour le premier chargement de l'utilisateur qui tombe sur un resolver qui ne l'a pas/plus en cache (après ça va quand même rester en cache sur le PC de l'utilisateur pendant au moins le TTL, généralement un peu plus, et ça reste en cache dans le resolver en question aussi), et ça va faire plus de boulot pour les serveurs DNS, c'est pour ça qu'il ne faut pas en abuser et ne pas laisser un TTL faible en permanence, mais le temps d'une migration ce n'est généralement pas gênant du tout.

Pour le www2, il a deux utilités:
- tester le nouveau serveur, mais là effectivement un nom fictif et/ou un changement dans le /etc/hosts suffit, mais comme il va servir après, c'est toujours bien de le tester "en vrai" aussi (pour vérifier qu'il n'y a pas par exemple une redirection vers www qui posera problème quand on fera la redirectin).

- permettre de forcer la redirection de l'ancien serveur vers le nouveau pour ceux qui récupèrent encore l'ancienne adresse IP via le DNS (donc pendant au moins la durée du TTL, prévoir plutôt plusieurs heures en pratique). Effectivement ça se fait au moment de la migration, c'était précisé dans ma liste.

Jacques.

 

[Just]

Merci pour ta réactivité Jacques !
OK je n'avais donc pas tout compris.

Mon soucis est que mon site détecte le sous-domaine par lequel le site est accédé.
"www" dans le cas de l'accès au site par la "porte principale". Réécrire les scripts pour qu'ils prennent en compte "www2" serait un réel casse tête :s.
Il faut donc que je trouve une alternative à cela.

Merci pour ton aide !

 

[Just]

Finalement je vais opter pour créer un www2. C'est la seule solution qui permet de réel test et une bascule sûr, comme l'indiquait Jacques.

 

[jcaron]

Evidemment tu peux l'appeler "new" au lieu "www2" si tu as envie

En fait il y a une autre solution, mais ça complique un peu: tu utilises un reverse proxy sur la machine d'origine (mod_proxy de Apache, pound, il doit y en avoir d'autres...), et au moment de la bascule tu lui dis d'envoyer le trafic de l'autre côté. Avec une config adaptée (un cookie par exemple) tu peux tester le setup avant, et personne ne verra jamais de nom différent.

Si tu utilises un proxy "externe" (par opposition à mod_proxy) ça t'oblige à déplacer ton serveur d'origine sur un autre port que le port 80, mais ça n'a pas forcément que des inconvénients (ça permet même de lancer ton serveur http sans être root, par exemple, si tu vas sur un port > 1024).

Jacques.

 

[Just]

Le déménagement c'est bien passé . Merci !

Une question : peut-on interdire à google d'indexer un sous-domaine ? Par exemple le fameux "www2".

 

[5_legs]

Post très intéressant !

Une reco pour les interventions de Jacques !

et hop bookmarké

 

[jcaron]

Sachant que le www2 et le www sont au même endroit, il va falloir faire un robots.txt "dynamique" à mon avis. I.e. tu le génères en php (et là tu testes $_SERVER['HTTP_HOST']) et tu fais un alias ou un rewriterule qui renvoie robots.txt vers le php, ou tu fais deux versions, et un rewriterule avec un rewritecond sur http_host pour choisir la "bonne".

Ceci dit le www2 n'a pas besoin de rester vivant très longtemps (en général 24 à 48 heures le temps que tous les caches aient expiré, les logs de l'ancien serveur te diront quand tout le monde a "oublié" l'ancienne valeur), après quoi tu peux mettre un 301 du www2 vers le www, donc si jamais G a trouvé quelques pages de www2, il va vite les oublier en faveur des www.

Jacques.

 

[Just]

Salut Jacques et merci encore pour ta réponse.

J'ai bien mit en place une 301 mais G semble s'entêter :/.

 

[jcaron]

C'est quoi les dates (migration, mise en place du 301)? Il faut laisser un petit peu de temps à Google pour recrawler et réindexer...

Jacques.

 

[datch]

Bonjour à tous

Pour simplifier la chose comment je fais en 4 étapes :

Transfert des fichiers sur le nouveau serveur
Transfert de la base via commande ssh ( 30 mega transféré en 10 secondes)
Réglage des configures de l'ancien site (adresse de la base vers le nouveau serveur)
Changement de l'IP pour le ndd.

Voila
Avec cette méthode 0 perte de commande.

 

[jcaron]

Ca me paraît une bonne méthode, mais dans certains cas l'accès distant à la bdd n'est pas possible (mutualisés...), ce qui empêche l'utilisation de cette méthode-là.

Et si tu ne coupes pas ton serveur pendant le moment où tu fais la copie et celui où tu lui dis d'aller utiliser la base sur le nouveau serveur, tu peux avoir des modifs sur l'ancienne base entre les deux, qui seront alors perdues (ou plus compliquées à récupérer).

Jacques.

 

[datch]

Le seul moment ou tu peux perdre des données c'est pendant les 30s -2min de transfert de base et de la configuration sur la nouvelle base.

Pour le transfert de bdd pour les mutualisés bigdump est pas trop mal.

 

[Leonick]

il suffit dans ce cas de bloquer le passage de commandes durant ce lap de temps, non ?

 

[datch]

Oui tu peux mais bon...
C'est rare d'avoir toutes les minutes 1 vente en heure creuse ...

 

[jcaron]

Il y a aussi la création de compte, l'ajout d'objets dans le panier si c'est géré en base, les mises à jour d'information du compte... En général il vaut mieux couper l'ensemble du site pendant le bref laps de temps du déplacement/reconfig de la base (quelques minutes si tu as bien préparé ton coup).

Si tu veux faire sans coupure (ou avec une coupure encore plus petite), il faut envisager une réplication de base, et faire un switchover maître/esclave en même temps que la reconfig. Ca réduit généralement l'indisponbilité à queqlues secondes.

Et évidemment cette méthode n'est valable qu'à partir du moment où toutes les données dynamiques sont en base (pas de fichier temporaires, de sessions, d'upload de fichiers...).

Jacques.