Planification d’une migration de serveur

Publié le 2 juillet 2014 à 10:23 par Sam Turner dans: Hébergement web

La planification d’une migration de serveur constitue une tâche complexe. Toutefois, vous pouvez profiter de cette occasion pour concevoir une architecture d’hébergement extensible qui comblera vos besoins futurs. Le succès de la migration vers votre nouvelle configuration réside dans la planification. Je vous conseille donc de lire attentivement cet article.

Cet article vous sera utile si vous planifiez de passer à une autre plateforme d’hébergement, de changer de fournisseur, de passer à un serveur dédié plus puissant ou bien de migrer vers une architecture en grappe de serveurs plus extensible. Nous aborderons les éléments à planifier et à considérer dès le début de votre projet de migration. Nous n’envisagerons pas de scénario précis ni ne fournirons d’instructions étape par étape, mais nous vous proposerons des liens vers d’autres ressources.

Contenu :

Partie un : préparation de la migration
Partie deux : outils et services
Partie trois : liste de vérification de la migration


Partie un : préparation de la migration

La migration la plus simple possible consiste à migrer un serveur dédié vers un autre. Il peut s’agir d’une mise à niveau, d’une impartition ou d’un changement de fournisseur d’hébergement. Mais vous pourriez également opter pour une migration plus complexe vers une architecture en grappe qui vous permettrait de tester les nouveaux serveurs, de mettre à jour vos bases de données et d’éviter (ou de réduire au minimum) les temps d’arrêt.

Nouvelle architecture de serveurs

Avouons-le : effectuer une migration est un processus complexe. Il s’agit néanmoins d’une excellente occasion de bien faire les choses, de sorte que vous n’ayez pas à refaire de migration de si tôt. Les architectes de système d’iWeb peuvent vous aider à effectuer la migration vers nos centres de données et à sélectionner la meilleure solution, à la fois extensible, redondante et rentable. Si vous avez des questions ou des doutes, n’hésitez pas à communiquer avec nous.

Si vous en êtes encore à sélectionner un type d’architecture, pensez à déployer une grappe de serveurs qui améliorera le rendement et qui simplifiera la gestion et la mise à niveau de votre architecture. Une grappe de serveur constitue la suite logique du serveur unique. Elle écartera une fois pour toutes de votre chemin les temps d’arrêt excessifs et d’autres migrations. Vous pouvez en savoir plus sur certains types courants de solutions avancées ou de serveurs en grappe :

Peu importe votre choix, vous devez réfléchir à certains aspects techniques avant de commencer le processus de migration. Vous devez vous assurer que vous avez suffisamment d’espace disque et de puissance de traitement sur vos nouveaux serveurs, en plus de 30 à 40 % de puissance en réserve, ou d’un plan plus détaillé de projection et d’extensibilité. En outre, assurez-vous de disposer d’une quantité suffisante d’adresses IP ainsi que d’un port réseau rapide d’au moins 100 Mbit/s.

Toute modification à votre architecture de serveurs, à votre système d’exploitation, aux versions de vos logiciels ou aux panneaux de configuration entraînera quelques changements à la configuration de vos serveurs. En fait, même si vous effectuez une mise à niveau vers un serveur plus puissant, il est probable que vous pourriez configurer vos services afin de tirer profit de mémoire RAM, d’une puissance CPU, de disques ou de systèmes RAID supplémentaires.

Une planification et une documentation soigneuses du déploiement et des exigences de configuration permettront à ce processus de fonctionner plus harmonieusement. De plus, elles vous faciliteront la tâche lorsque vous rechercherez une aide externe ou que vous vous munirez d’une équipe des opérations de développement se spécialisant dans votre application et votre processus de déploiement.

Stratégie de migration

La méthode de migration la plus simple consiste à recréer l’ensemble de votre site Web, de votre base de données ou de votre serveur de fichiers sur vos nouveaux serveurs, puis à les configurer et à faire une multitude d’essais pour finalement passer des anciens aux nouveaux serveurs.

Bien que cette méthode requière beaucoup d’essais et les connaissances d’administrateurs système compétents pour configurer les nouveaux serveurs, l’élaboration de la stratégie et du calendrier de la migration est relativement simple. Assurez-vous simplement de suspendre tout développement de site Web ou d’application pendant la configuration du nouveau serveur et de synchroniser les données entre votre ancienne et votre nouvelle base de données avant de modifier le DNS de l’adresse de votre site Web.

Toutefois, il est possible que votre stratégie de migration soit plus complexe si vous devez fournir des services normaux tout le long du processus de migration. Il est plutôt facile de déplacer un ensemble de fichiers, mais déplacer un service essentiel de votre entreprise ou mettre à jour en direct et de façon constante une base de données représente tout un défi. Vous devez éviter les temps d’arrêt, conserver l’accès et les autorisations des utilisateurs ainsi qu’assurer la continuité des données.

Pour contourner ce genre de problème, vous pouvez appliquer une stratégie de migration hybride, qui peut comprendre les éléments suivants :

  • Base de données : l’ancienne base de données représente la base de données maître et la nouvelle (testée et configurée) est l’esclave. Une fois que la nouvelle base de données (esclave) est mise à jour, les rôles sont inversés. La nouvelle base de données devient alors la base de données maître. Vous pouvez en apprendre davantage sur la duplication de bases de données pour MySQL ici.
  • Les serveurs de site Web et d’application : un équilibreur de charge envoie le trafic entre les nouveaux et les anciens serveurs. Une fois qu’ils fonctionnent comme prévu, l’équilibreur dirige tout le trafic vers les nouveaux serveurs.

Préparation de votre serveur actuel

Avant d’effectuer la migration, réfléchissez au moment sur l’incidence d’un arrêt du développement et à l’impossibilité pendant cette période de modifier les scripts, les fichiers et les configurations. Ne pas effectuer de modifications durant le processus de migration vous garantit que les fichiers ayant fait l’objet de la migration sont les mêmes que ceux qui se trouvent sur le serveur d’origine. Prévoyez le moment de la migration en fonction de vos exigences opérationnelles et ajoutez cette information à votre stratégie de migration.

Le même concept s’applique au verrouillage de vos bases de données, qui peut être difficile si celles-ci sont mises à jour par plusieurs utilisateurs différents de l’organisation (par exemple, un CMS), par divers clients ou par des utilisateurs externes (en ce qui concerne les renseignements relatifs aux comptes). S’il n’est pas possible de verrouiller vos bases de données, vous devrez prévoir une mise à jour finale dans votre stratégie de migration afin que votre base de données soit dupliquée et à jour lorsque vous changerez de serveur.

La plupart des stratégies de migration comprennent la sauvegarde de votre serveur aux fins de transfert à un nouvel emplacement. S’il s’agit de l’option préconisée, assurez-vous que la sauvegarde est complète avant la migration. Et ne fermez pas définitivement votre ancien serveur ni votre ancien compte d’hébergement avant que votre nouveau serveur ou site Web soit en service et fonctionne correctement. Vous devrez peut-être retourner à votre ancien serveur, ou il est possible que la date de la mise en service soit repoussée.

Avant d’effectuer la migration, vous pouvez également nettoyer votre serveur actuel en supprimant d’anciens sites Web, de vieilles sauvegardes et de vieux comptes de messagerie que vous n’utilisez plus. Durant la migration, il faut que votre serveur soit le moins rempli possible. De cette façon, vous avez une représentation adéquate de l’espace de stockage et de l’équipement dont vous avez besoin.


Partie deux : outils et services

En ce qui concerne des migrations simples entre des serveurs similaires (entre deux fournisseurs d’hébergement Web partagé, par exemple), certains outils et services peuvent vous aider à migrer un site Web sans comprendre en détail la configuration d’un site Web.

Des services de migration plus complexes font appel à l’expertise de spécialistes et ils peuvent coûter plusieurs centaines de dollars. Sachez que ce genre d’investissement est judicieux si vous n’êtes pas certain de posséder les ressources nécessaires pour gérer une migration, ou si vous désirez vous assurer que vous avez la solution la plus extensible à long terme pour votre application Web.

Panneaux de configuration

Si vous changez de fournisseur d’hébergement Web partagé sans apporter de modification au système d’exploitation ni au logiciel, des panneaux de configuration comme cPanel et Plesk peuvent vous être utiles dans la sauvegarde de vos fichiers et la restauration sur le nouveau serveur, et ce, sans que cela nécessite beaucoup de reconfiguration. Vous pouvez voir ce processus en action dans ce guide utile expliquant le changement de fournisseurs d’hébergement Web partagé.

Modules d’extension Wordpress

La migration de thèmes Wordpress et de CSS est très simple. Elle nécessite uniquement que le transfert des fichiers entre les anciens et les nouveaux serveurs soit effectué à l’aide du protocole FTP ou d’un programme de sauvegarde. Migrer une base de données constitue un processus un peu plus complexe, mais plusieurs modules d’extension automatisent le tout et vous rendent la tâche un peu plus facile. Consultez les avis sur quelques-uns de ces modules.

SSH et accès aux dossiers root

Le scénario le plus courant pour des configurations d’hébergement plus avancées consiste à utiliser la ligne de commande (accessible par l’intermédiaire de SSH) pour transférer l’ensemble d’une base de données d’un serveur à l’autre, suivi de toutes les autorisations et les données des utilisateurs. Pour MySQL (la base de données à code source libre la plus courante), vous pouvez y arriver en utilisant MySQLdump. Voici une étude de cas sur la question. Si vous utilisez Windows, SQL Server peut être migré entre les serveurs employant des outils intégrés, comme il est décrit ici dans la Base de connaissance Microsoft.

IaaS et fournisseurs d’hébergement

Faites appel à un professionnel en matière de IaaS ou à un fournisseur d’hébergement pour la migration de vos services, car vous tirerez profit de leur expertise lorsque viendra le temps de sélectionner la meilleure architecture de serveurs, d’effectuer la migration et de configurer vos nouveaux serveurs. Par ailleurs, il est possible que vous désiriez que votre développeur ou administrateur de système ou de base de données gère les divers services sur votre serveur, même si un bon fournisseur IaaS peut également assumer ces tâches.

Si vous demandez les services d’un fournisseur d’hébergement pour vous aider dans votre migration, vous possédez probablement une configuration plus avancée (ou au moins un hébergement dédié, peut-être une grappe de serveurs). La migration de ce type de configuration représente plusieurs heures de travail, ce qui pourrait coûter de 100 à 1000 $ selon la situation.

Services spécialisés

D’autres services se spécialisent dans la migration de sites Web, y compris le changement de fournisseur d’hébergement ou la migration d’architectures en grappe de serveurs. Semblables aux services de migration de sites Web offerts par les fournisseurs en IaaS à des prix similaires, ces services prennent entièrement en charge la migration et vous assurent que votre application fonctionnera comme avant. Le fournisseur le plus important de ces services est Website Movers.


Partie trois : liste de vérification de la migration

Tous ces points sont résumés sous forme de questions que vous devez vous poser avant de commencer la planification de votre migration.

Nouvelle architecture

  1. Devriez-vous changer l’architecture, la puissance de traitement, votre système d’exploitation, les versions de vos logiciels ou la structure de fichiers de vos serveurs?
  2. Disposez-vous des ressources nécessaires en personnel pour déterminer les exigences de la nouvelle architecture, configurer correctement vos nouveaux serveurs et tirer le maximum de votre nouvelle solution?
  3. Une fois que vous avez choisi cette nouvelle solution, votre fournisseur vous offre-t-il le stockage, la bande passante, la puissance de traitement et la fiabilité dont vous avez besoin maintenant et dans un avenir rapproché?
  4. À quel point votre nouvelle architecture d’hébergement est-elle extensible? Pouvez-vous l’améliorer, la mettre à jour ou la migrer au besoin?

Stratégie de migration

  1. Devriez-vous suspendre la modification des fichiers sur votre serveur existant, et à quel moment devriez-vous le faire de sorte que vous ayez assez de temps pour effectuer la migration (en plus des essais)?
  2. Quel est le temps d’arrêt cumulatif acceptable et comment votre stratégie peut-elle encore réduire ce temps? Le temps d’arrêt évité justifie-t-il un processus plus complexe et un investissement accru de ressources?
  3. De quelle façon mettrez-vous à jour ou gérerez-vous vos bases de données afin d’assurer la constance de vos services et l’intégrité de vos données modifiées pendant la migration? Devrez-vous verrouiller votre base de données afin d’y arriver?
  4. Avez-vous dressé un plan afin de veiller à ce que les utilisateurs disposent des privilèges d’accès adéquats au nouveau serveur?
  5. De quelle façon testerez-vous en profondeur vos nouveaux serveurs avec des charges raisonnables?
  6. Quelles seront les incidences des changements sur les utilisateurs de votre organisation et sur votre base de clients, et comment les gérerez-vous? Quelles personnes seront touchées, et quelles étapes devront-elles suivre?

Comments Off tags: , ,  | 
1 Star2 Stars3 Stars4 Stars5 Stars (Pas de votes)

Commentaires

Pas encore de commentaire.