Migration de serveur dédié : du Kimsufi 250G au Kimsufi 750G

En mars 2012, SkyMinds a quitté un serveur Kimsufi équipé d’un Celeron et de 2 Go de RAM pour un Kimsufi 750G doté d’un Core 2 Quad et de 4 Go. Cette migration avait nettement amélioré les performances du site, mais elle avait également provoqué environ une heure d’indisponibilité. Voici le retour d’expérience original, complété par les bonnes pratiques que j’appliquerais aujourd’hui.

Cet article appartient à l’histoire technique de SkyMinds. Il ne présente pas une offre Kimsufi actuelle et ne constitue pas un guide d’achat. Le Kimsufi 750G évoqué ici correspond à un serveur commercialisé par OVH au début des années 2010.

L’intérêt du récit reste pourtant intact. Une migration de serveur demande toujours de préparer la nouvelle machine, transférer les données, vérifier les services, basculer le trafic et conserver une solution de retour arrière.

Pourquoi migrer vers un nouveau serveur ?

Au début de l’année 2012, SkyMinds fonctionnait sur un serveur dédié devenu trop limité pour les services qu’il hébergeait.

L’ancienne machine disposait de la configuration suivante :

• processeur Intel Celeron 220 à 1,20 GHz ;
• 2 Go de mémoire vive ;
• stockage mécanique ;
• plusieurs services web et système ;
• Varnish comme cache HTTP devant le serveur web.

Le principal problème venait moins du stockage que du couple processeur-mémoire. Varnish occupait à lui seul une part importante des 2 Go disponibles. Les autres services devaient donc se partager une quantité de mémoire assez modeste.

Une promotion OVH m’a permis de passer au Kimsufi 750G. Malgré son nom, le véritable changement ne concernait pas seulement la capacité du disque.

La configuration du Kimsufi 750G

Le nouveau serveur proposait :

• un processeur Intel Core 2 Quad Q8300 à 2,50 GHz ;
• quatre cœurs physiques ;
• 4 Go de mémoire vive ;
• un disque dur de 750 Go.

Ces caractéristiques paraissent modestes aujourd’hui. À l’époque, le passage d’un Celeron monocœur à un Core 2 Quad représentait toutefois une amélioration considérable.

Le doublement de la mémoire permettait aussi de conserver davantage de données en cache et de limiter les accès au disque. Sur une pile web composée d’Apache, PHP, MySQL et Varnish, ce gain pouvait changer radicalement le comportement du serveur.

Afficher les caractéristiques d’un serveur Linux

Dans l’article original, j’utilisais la commande suivante pour consulter les informations du processeur :

less /proc/cpuinfo

Cette méthode fonctionne toujours. Toutefois, lscpu fournit une synthèse beaucoup plus lisible :

lscpu

Pour afficher seulement les informations les plus utiles :

lscpu | grep -E \
    'Architecture|CPU\(s\)|Model name|Socket|Core|Thread|CPU max MHz'Langage du code : JavaScript (javascript)

La mémoire disponible se vérifie avec :

free -h

Pour examiner les disques, leurs systèmes de fichiers et leurs points de montage :

lsblk \
    --output NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL

Enfin, la commande suivante résume l’espace réellement utilisé :

df -hT

Migrer n’est pas réinstaller à l’identique

Mon objectif consistait à reconstruire le nouveau serveur tout en réutilisant les configurations qui avaient fait leurs preuves sur l’ancien.

Il existe pourtant une différence importante entre copier une configuration et reproduire aveuglément une machine.

Les fichiers peuvent dépendre :

• de la version de Debian ou Ubuntu ;
• des versions de PHP, MySQL, Apache ou Nginx ;
• des chemins utilisés par les paquets ;
• des utilisateurs et groupes système ;
• des modules réellement installés ;
• des adresses IP et noms d’hôtes ;
• du système d’initialisation ;
• de la quantité de mémoire disponible.

J’avais donc repris mes procédures une par une, puis copié les fichiers personnalisés lorsque leur compatibilité était confirmée.

Cette approche reste préférable à une copie complète de /etc. Remplacer tous les fichiers système par ceux de l’ancien serveur peut écraser des réglages fournis par les nouveaux paquets et créer des incompatibilités particulièrement pénibles à diagnostiquer.

La méthode que j’utiliserais aujourd’hui

Une migration moderne peut être divisée en six phases distinctes.

1. Inventorier l’ancien serveur

Avant d’installer quoi que ce soit, il faut relever les services, versions, ports, tâches planifiées et volumes de données.

hostnamectl
cat /etc/os-release
systemctl --type=service --state=running
ss -lntup
df -hT
lsblk
free -h

Pour enregistrer la liste des paquets installés sous Debian ou Ubuntu :

dpkg-query \
    --show \
    --showformat='${binary:Package}\t${Version}\n' \
    > installed-packages.tsvLangage du code : JavaScript (javascript)

Cette liste sert de référence. Elle ne doit pas forcément être réinstallée intégralement sur la nouvelle machine.

2. Installer proprement le nouveau serveur

Le nouveau système doit être installé et sécurisé indépendamment de l’ancien. Il faut notamment configurer :

• les mises à jour de sécurité ;
• les comptes administrateurs ;
• l’authentification SSH par clé ;
• le pare-feu ;
• Fail2ban lorsque son usage est pertinent ;
• la synchronisation horaire ;
• les sauvegardes ;
• la supervision et les alertes.

Les services applicatifs peuvent ensuite être installés avec leurs fichiers de configuration actuels. Les anciennes personnalisations sont réintroduites progressivement, après comparaison.

3. Réaliser une première synchronisation

Une première copie peut être effectuée pendant que le serveur d’origine reste en production. Cette passe transfère le plus gros volume de données sans imposer une longue interruption.

rsync -aHAX \
    --numeric-ids \
    --info=progress2 \
    --partial-dir=.rsync-partial \
    /home/www/ \
    root@nouveau-serveur:/home/www/Langage du code : JavaScript (javascript)

Les options exactes doivent être adaptées aux données transférées. Les identifiants numériques, ACL et attributs étendus ne sont pas toujours nécessaires pour une simple arborescence web.

Une simulation permet de contrôler les chemins avant la première copie :

rsync -aHAX \
    --numeric-ids \
    --dry-run \
    --itemize-changes \
    /home/www/ \
    root@nouveau-serveur:/home/www/Langage du code : JavaScript (javascript)

La barre oblique finale de /home/www/ signifie que rsync transfère le contenu du répertoire, et non un nouveau répertoire www imbriqué dans la destination.

4. Migrer les bases de données proprement

Les fichiers internes de MySQL ou MariaDB ne doivent pas être copiés à chaud comme de simples documents. Une base active peut être modifiée pendant le transfert et produire un ensemble incohérent.

Pour une base de taille raisonnable, une exportation logique reste simple à contrôler :

mysqldump \
    --single-transaction \
    --routines \
    --triggers \
    --events \
    --default-character-set=utf8mb4 \
    database_name |
gzip > database_name.sql.gzLangage du code : JavaScript (javascript)

Le fichier peut ensuite être transféré et importé sur le nouveau serveur :

gzip -dc database_name.sql.gz |
mysql database_name

Pour un site WordPress unique, WP-CLI offre une interface pratique :

wp db export \
    ~/backup-before-migration.sql \
    --add-drop-tableLangage du code : JavaScript (javascript)

5. Effectuer une dernière synchronisation

Au moment de la bascule, les écritures doivent être temporairement interrompues. Pour un site WordPress, cela signifie généralement activer un mode maintenance et suspendre les tâches capables de modifier les fichiers ou la base.

Une seconde exécution de rsync ne transfère alors que les différences apparues depuis la première copie :

rsync -aHAX \
    --numeric-ids \
    --delete \
    --info=progress2 \
    /home/www/ \
    root@nouveau-serveur:/home/www/Langage du code : JavaScript (javascript)

--delete transforme la destination en miroir de la source. Il faut donc exécuter une simulation avant de l’utiliser :

rsync -aHAX \
    --numeric-ids \
    --delete \
    --dry-run \
    --itemize-changes \
    /home/www/ \
    root@nouveau-serveur:/home/www/Langage du code : JavaScript (javascript)

6. Basculer le trafic

La dernière étape consiste à modifier les enregistrements DNS ou la configuration du reverse proxy afin d’envoyer le trafic vers le nouveau serveur.

Le TTL détermine combien de temps les résolveurs peuvent conserver un ancien enregistrement. Il est donc utile de le réduire avant la migration lorsque le fournisseur DNS le permet.

Avec Cloudflare, les enregistrements proxifiés utilisent un TTL automatique de cinq minutes. Les enregistrements non proxifiés peuvent utiliser un TTL configurable selon l’offre.

Le serveur d’origine doit rester disponible après la bascule. Il constitue une solution de repli si une erreur apparaît sur la nouvelle machine.

Pourquoi le site avait-il été indisponible pendant une heure ?

Lors de cette migration, SkyMinds avait été indisponible pendant environ une heure.

À l’époque, cette durée restait acceptable pour un blog personnel. Elle serait beaucoup moins confortable pour une boutique WooCommerce, un site d’adhésion ou une plateforme professionnelle.

Les principales causes possibles d’une longue interruption sont toujours les mêmes :

• le transfert complet des données pendant la fenêtre de maintenance ;
• un TTL DNS encore élevé ;
• des services configurés seulement après la bascule ;
• une base de données exportée trop tard ;
• des certificats TLS absents ou invalides ;
• des différences de versions entre les deux serveurs ;
• des permissions incorrectes ;
• l’absence de tests locaux avant le changement DNS.

La première synchronisation anticipée réduit fortement cette fenêtre. Le jour de la bascule, seuls les derniers changements doivent encore être copiés.

Tester le nouveau serveur avant le changement DNS

Il n’est pas nécessaire d’attendre la propagation DNS pour vérifier le site. curl permet d’envoyer une requête au nouveau serveur tout en conservant le véritable nom de domaine.

curl \
    --resolve www.example.com:443:203.0.113.20 \
    --head \
    https://www.example.com/Langage du code : JavaScript (javascript)

Pour examiner la réponse complète :

curl \
    --resolve www.example.com:443:203.0.113.20 \
    --include \
    https://www.example.com/Langage du code : PHP (php)

L’option --resolve force ici le domaine à utiliser l’adresse IP du nouveau serveur. Le nom d’hôte HTTP et l’indication SNI TLS restent corrects.

On peut aussi ajouter temporairement une entrée au fichier /etc/hosts de son ordinateur afin de tester le site dans un navigateur :

203.0.113.20 example.com www.example.comLangage du code : CSS (css)

Cette entrée doit être supprimée après les tests. Dans le cas contraire, quelques semaines plus tard, on finit inévitablement par accuser le DNS d’un problème qu’on a soi-même soigneusement rangé dans /etc/hosts.

Vérifier les services après la migration

Le fait qu’une page d’accueil s’affiche ne prouve pas que la migration est terminée.

Il faut contrôler l’état général des services :

systemctl --failed
systemctl --type=service --state=running
journalctl --priority=err --boot

Vérifiez ensuite les ports en écoute :

ss -lntup

Pour une pile WordPress, la validation doit couvrir au minimum :

• les pages publiques et les archives ;
• la connexion à l’administration ;
• les formulaires ;
• les téléversements de médias ;
• les tâches WP-Cron ;
• l’envoi des courriels ;
• les sauvegardes ;
• le cache objet et le cache de page ;
• les paiements et webhooks WooCommerce ;
• les certificats TLS ;
• les journaux PHP, web et base de données.

Comparer les performances avant et après

Mon verdict de 2012 était simple : le nouveau serveur fonctionnait beaucoup mieux. Le gain de processeur et de mémoire se ressentait immédiatement.

Aujourd’hui, je documenterais cette amélioration avec des mesures prises avant et après la migration.

Pour surveiller la charge et la mémoire :

uptime
free -h
vmstat 1
pidstat 1

Pour examiner les entrées-sorties du stockage :

iostat -xz 1

Les outils pidstat et iostat sont généralement fournis par le paquet sysstat :

sudo apt install sysstat

Pour tester le temps de réponse HTTP sans lancer une charge agressive :

curl \
    --silent \
    --output /dev/null \
    --write-out \
    'DNS: %{time_namelookup}s
Connexion: %{time_connect}s
TLS: %{time_appconnect}s
Premier octet: %{time_starttransfer}s
Total: %{time_total}s
' \
    https://www.example.com/Langage du code : PHP (php)

Ces mesures doivent être répétées dans des conditions comparables. Une seule requête ne suffit pas pour conclure qu’un serveur est deux fois plus rapide.

Pourquoi certaines configurations fonctionnaient-elles mieux sans modification ?

À la fin de l’article original, je notais que certains services fonctionnaient beaucoup mieux alors que leurs fichiers de configuration avaient simplement été repris depuis l’ancien serveur.

Il n’y avait rien de mystérieux. Une même configuration peut se comporter très différemment selon les ressources disponibles.

Le nouveau serveur apportait notamment :

• davantage de cœurs pour exécuter plusieurs tâches simultanément ;
• une fréquence CPU supérieure ;
• deux fois plus de mémoire ;
• plus de place pour les caches du système et des applications ;
• moins de pression mémoire ;
• moins de risques d’utiliser le swap ;
• une meilleure réactivité pendant les tâches de maintenance.

Une configuration correcte mais contrainte par la mémoire peut sembler mauvaise. À l’inverse, ajouter des ressources peut masquer une configuration inefficace. Après une migration, il faut donc laisser le serveur fonctionner sous une charge représentative, puis ajuster les services à partir de mesures réelles.

Les leçons toujours valables de cette migration

Préparer le nouveau serveur avant la bascule

Les services, certificats, sauvegardes et règles réseau doivent fonctionner avant que le trafic public n’arrive.

Séparer la copie initiale de la synchronisation finale

Une première copie transfère le gros volume. La seconde ne traite que les changements récents et réduit l’indisponibilité.

Ne pas copier aveuglément toute la configuration

Il faut comprendre chaque personnalisation et l’adapter aux versions installées sur la nouvelle machine.

Conserver l’ancien serveur comme solution de repli

La résiliation ne doit intervenir qu’après plusieurs jours de fonctionnement stable et après vérification des sauvegardes.

Tester les restaurations, pas seulement les sauvegardes

Une archive créée avec succès ne garantit pas qu’elle contient toutes les données ni qu’elle peut être restaurée dans le temps disponible.

Mesurer avant d’optimiser

Le processeur, la mémoire, le stockage et la base de données peuvent chacun constituer le goulot d’étranglement. Il faut identifier le bon avant de modifier la configuration.

Checklist pour une migration de serveur dédiée

• inventorier les services et versions de l’ancien serveur ;
• vérifier les sauvegardes et réaliser un test de restauration ;
• installer et sécuriser le nouveau système ;
• configurer les services sans exposer immédiatement le serveur ;
• réduire le TTL DNS avant la migration lorsque c’est utile ;
• effectuer une première synchronisation des fichiers ;
• exporter et tester les bases de données ;
• tester les sites avec curl --resolve ou /etc/hosts ;
• préparer une procédure de retour arrière ;
• activer temporairement le mode maintenance ;
• effectuer la synchronisation finale ;
• basculer le DNS ou le reverse proxy ;
• surveiller les services et les journaux ;
• vérifier les sauvegardes sur le nouveau serveur ;
• conserver l’ancien serveur le temps de confirmer la stabilité.

Qu’est devenu l’hébergement de SkyMinds ?

Le Kimsufi 750G n’a évidemment pas été le dernier serveur de SkyMinds. Les besoins, les distributions Linux et l’architecture du site ont continué d’évoluer.

Cette migration reste néanmoins une étape importante. Elle a permis d’héberger davantage de services, de réduire la pression mémoire et de préparer les évolutions suivantes de l’infrastructure.

Vous pouvez poursuivre cette chronologie avec l’article consacré au serveur dédié Apollo.

Questions fréquentes

Le Kimsufi 750G est-il encore commercialisé ?

Non. Le Kimsufi 750G présenté dans cet article correspond à une ancienne gamme de serveurs OVH commercialisée au début des années 2010. Les offres et caractéristiques actuelles sont différentes.

Pourquoi conserver un article consacré à un ancien serveur ?

Il documente l’évolution de l’infrastructure de SkyMinds et présente des problèmes toujours pertinents : manque de mémoire, préparation de la migration, interruption de service et validation du nouveau serveur.

Peut-on copier directement tout le répertoire /etc ?

Ce n’est généralement pas recommandé. Les configurations dépendent des versions des logiciels, des paquets, des utilisateurs système et du réseau. Il vaut mieux installer proprement les services, puis réintroduire les personnalisations après comparaison.

Comment réduire l’interruption pendant une migration ?

Effectuez une première copie pendant que le serveur reste en ligne. Testez ensuite le nouveau serveur, suspendez brièvement les écritures, réalisez une synchronisation finale et basculez le trafic.

Faut-il supprimer immédiatement l’ancien serveur ?

Non. Conservez-le tant que le nouveau serveur, ses sauvegardes, ses tâches planifiées et ses services n’ont pas été validés sous une charge réelle.

Comment vérifier le processeur et la mémoire d’un serveur Linux ?

Utilisez lscpu pour le processeur, free -h pour la mémoire et lsblk pour les disques et points de montage.

Articles complémentaires

• Migration de serveur : Kimsufi 250G
• Transférer des fichiers entre deux serveurs avec rsync
• Nouveau serveur dédié OVH : Apollo
• Changer les DNS d’un domaine lors d’une migration
• Sécuriser un serveur dédié avec un pare-feu et Fail2ban
• Faire migrer un site WordPress sans interruption

Sources

• Manuel Linux : lscpu
• Manuel Linux : lsblk
• Documentation officielle de rsync
• Documentation WP-CLI : wp db export
• Documentation Cloudflare : durée de vie des enregistrements DNS

Report a typo