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

Discussion dans 'Administration d'un site Web' créé par Just, 2 Septembre 2009.

  1. Just
    Just Nouveau WRInaute
    Inscrit:
    7 Juin 2006
    Messages:
    41
    J'aime reçus:
    0
    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 !
     
  2. jcaron
    jcaron WRInaute accro
    Inscrit:
    13 Février 2004
    Messages:
    2 593
    J'aime reçus:
    0
    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.
     
  3. Just
    Just Nouveau WRInaute
    Inscrit:
    7 Juin 2006
    Messages:
    41
    J'aime reçus:
    0
    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.
     
  4. Just
    Just Nouveau WRInaute
    Inscrit:
    7 Juin 2006
    Messages:
    41
    J'aime reçus:
    0
    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é.
     
  5. jcaron
    jcaron WRInaute accro
    Inscrit:
    13 Février 2004
    Messages:
    2 593
    J'aime reçus:
    0
    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.
     
  6. Just
    Just Nouveau WRInaute
    Inscrit:
    7 Juin 2006
    Messages:
    41
    J'aime reçus:
    0
    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 !
     
  7. Just
    Just Nouveau WRInaute
    Inscrit:
    7 Juin 2006
    Messages:
    41
    J'aime reçus:
    0
    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.
     
  8. jcaron
    jcaron WRInaute accro
    Inscrit:
    13 Février 2004
    Messages:
    2 593
    J'aime reçus:
    0
    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.
     
  9. Just
    Just Nouveau WRInaute
    Inscrit:
    7 Juin 2006
    Messages:
    41
    J'aime reçus:
    0
    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".
     
  10. 5_legs
    5_legs WRInaute passionné
    Inscrit:
    30 Avril 2006
    Messages:
    1 550
    J'aime reçus:
    0
    Post très intéressant !

    Une reco pour les interventions de Jacques !

    et hop bookmarké
     
  11. jcaron
    jcaron WRInaute accro
    Inscrit:
    13 Février 2004
    Messages:
    2 593
    J'aime reçus:
    0
    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.
     
  12. Just
    Just Nouveau WRInaute
    Inscrit:
    7 Juin 2006
    Messages:
    41
    J'aime reçus:
    0
    Salut Jacques et merci encore pour ta réponse.

    J'ai bien mit en place une 301 mais G semble s'entêter :/.
     
  13. jcaron
    jcaron WRInaute accro
    Inscrit:
    13 Février 2004
    Messages:
    2 593
    J'aime reçus:
    0
    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.
     
  14. datch
    datch WRInaute impliqué
    Inscrit:
    16 Juin 2006
    Messages:
    897
    J'aime reçus:
    1
    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.
     
  15. jcaron
    jcaron WRInaute accro
    Inscrit:
    13 Février 2004
    Messages:
    2 593
    J'aime reçus:
    0
    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.
     
  16. datch
    datch WRInaute impliqué
    Inscrit:
    16 Juin 2006
    Messages:
    897
    J'aime reçus:
    1
    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.
     
  17. Leonick
    Leonick WRInaute accro
    Inscrit:
    8 Août 2004
    Messages:
    19 417
    J'aime reçus:
    0
    il suffit dans ce cas de bloquer le passage de commandes durant ce lap de temps, non ?
     
  18. datch
    datch WRInaute impliqué
    Inscrit:
    16 Juin 2006
    Messages:
    897
    J'aime reçus:
    1
    Oui tu peux mais bon...
    C'est rare d'avoir toutes les minutes 1 vente en heure creuse ...
     
  19. jcaron
    jcaron WRInaute accro
    Inscrit:
    13 Février 2004
    Messages:
    2 593
    J'aime reçus:
    0
    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.
     
Chargement...
Similar Threads - Changement hébergeur commerce Forum Date
Changement hébergeur boite mail Administration d'un site Web 3 Novembre 2016
Changement d’hébergeur Débuter en référencement 2 Février 2016
changement d'hebergeur Administration d'un site Web 14 Septembre 2015
Changement d'hébergeur et référencement Problèmes de référencement spécifiques à vos sites 30 Juillet 2015
Changement des packs de mon hébergeur : plus de FTP Droit du web (juridique, fiscalité...) 19 Juin 2015
Indexation apres changement d'hebergeur Crawl et indexation Google, sitemaps 6 Janvier 2015
problème changement d'hébergeur Administration d'un site Web 3 Mai 2014
Besoin de conseils pour changement d'hebergeur ! Administration d'un site Web 26 Février 2014
Changement d'hébergeur Débuter en référencement 27 Janvier 2014
Changement d'hébergeur et migration du MX Administration d'un site Web 26 Septembre 2013
  1. Ce site utilise des cookies. En continuant à utiliser ce site, vous acceptez l'utilisation des cookies.
    Rejeter la notice