Comment migrer un serveur Linux vers un nouveau matériel

0
356
Shutterstock/asharkyu

Que vous soyez Lors de la mise à niveau vers des serveurs plus puissants, du déplacement vers de nouvelles régions ou de l'ajout de nouvelles instances, la migration d'un serveur Linux peut être facilitée en mettant en œuvre les stratégies appropriées et en connaissant les bonnes commandes. Nous verrons comment déplacer votre serveur vers une nouvelle machine avec un minimum de tracas.

Stratégies de migration

Le plus simple et la stratégie la plus efficace est un déploiement bleu-vert—mettre le nouveau serveur en service, puis lorsqu'il est prêt pour la production, transférer le trafic vers celui-ci et supprimer l'ancien serveur une fois que vous avez vérifié qu'il existe pas d'issues. Avec l'équilibrage de charge, ce processus peut se dérouler de manière incrémentielle, ce qui réduit encore les risques de problèmes de disponibilité.

Un déploiement bleu-vert implique la copie de tous les fichiers, packages et code de l'ancien serveur vers le nouveau. Cela peut être aussi simple que d'installer manuellement les packages nécessaires, tels qu'un serveur Web NGINX, puis de copier la configuration à partir du serveur existant. Vous pouvez également effectuer une sauvegarde complète du disque et créer un nouveau serveur à partir de cela.

Bien sûr, c'est le moment idéal pour déterminer si vous pouvez utiliser des conteneurs ou une mise à l'échelle automatique. Les conteneurs Docker peuvent être facilement arrêtés, démarrés et migrés en copiant les volumes de données sous-jacents (ou en utilisant un magasin de données partagé comme EFS). La mise à l'échelle automatique diffère selon les fournisseurs, mais si vous ajoutez une nouvelle copie de votre serveur pour répondre à la demande croissante, cela peut convenir à votre entreprise. Vous pouvez également utiliser la mise à l'échelle automatique avec les conteneurs Docker sur de nombreuses plateformes comme AWS ECS.

Publicité

La configuration des conteneurs et de la mise à l'échelle automatique vous oblige à effectuer une grande partie du travail que vous devrez effectuer pour transférer le serveur manuellement, comme l'automatisation de l'installation des packages et de votre propre code, donc si vous prévoyez de migrer à nouveau dans l'avenir, vous devriez considérer maintenant si vous feriez mieux de passer aux conteneurs ou de configurer la mise à l'échelle automatique.

Si vous êtes intéressé par les conteneurs, vous pouvez lire notre guide pour démarrer avec Docker pour en savoir plus, ou lire notre guide d'utilisation de l'auto-scaling sur AWS ou Google Cloud Platform.

CONNEXION : Comment emballer l'infrastructure de votre application avec Docker

Installation des packages

Si vous n'êtes pas sûr de ce que vous avez installé sur l'ancien serveur, la meilleure méthode pour vérifier est d'obtenir une liste de tous les services installés. Cela montrera la plupart des éléments principaux que vous aurez besoin d'installer :

service –status-all

La raison de préférer les services de liste est que la liste des packages installés peut être très longue, chaque dépendance mineure étant également installée. Mon serveur de test Ubuntu avait plus de 72000 packages installés, donc la liste d'entre eux n'est pas très utile étant donné qu'ils seront tous installés de toute façon lors de l'installation des principaux services dont le nouveau serveur a besoin.

Si vous le souhaitez, vous pouvez tous les lister avec la commande suivante :

sudo apt list –installed

Pour rechercher dans la liste des packages un package spécifique, vous pouvez utiliser :

sudo apt -qq list program_name — installé

Dans tous les cas, vous souhaiterez faire une liste des packages que vous devez installer et les installer sur le nouveau serveur.

Transfert du Disque du serveur avec rsync

Vous pouvez archiver le disque avec tar, mais tar est généralement destiné à archiver des fichiers ou des répertoires uniques, pas un disque entier. Si vous déplacez beaucoup de données, il se peut que vous n'ayez pas assez d'espace pour effectuer une sauvegarde localement (c'est peut-être même la raison de la mise à niveau !).

Publicité

Dans ce cas, vous souhaiterez utiliser la commande rsync pour télécharger les données directement sur le serveur cible. rsync se connectera via SSH et synchronisera les deux répertoires ; dans ce cas, nous voulons pousser le répertoire local vers le serveur distant, comme ceci :

rsync -azAP /etc/nginx username@remote_host:/etc/nginx

C'est toute la commande, vous devriez voir une barre de progression pendant le transfert (en utilisant la compression avec l'indicateur -z), et quand c'est fait, vous verrez les fichiers dans la cible répertoire sur le nouveau serveur. Vous devrez peut-être l'exécuter plusieurs fois pour copier chaque répertoire ; vous pouvez utiliser ce générateur de commandes rsync en ligne pour générer la commande pour chaque exécution.

Si vous le souhaitez, vous pouvez essayer de copier l'intégralité du système de fichiers racine sur le nouveau serveur, à l'exception de certains fichiers système :

sudo rsync -azAP/–exclude={“/dev/*”,”/proc/*”,”/sys/*”,”/tmp/*”,”/run/*”,”/mnt/*” ,”/media/*”,”/lost+found”} username@remote_host :/

Si vous cherchez simplement à faire une sauvegarde de quelques répertoires, vous pouvez utiliser une simple commande tar à la place pour générer une archive de fichier unique :

tar -czvf nginxconfig.tar.gz /etc/nginx

 Cela génère un fichier que vous pouvez transférer vers le serveur cible avec scp ou via FTP. Ensuite, extrayez le fichier dans le répertoire cible :

tar -xzvf nginxconfig.tar.gz -C /etc/nginx

Transfert d'une base de données

Si vous devez transférer une base de données, vous souhaiterez sauvegarder et vider la base de données source. Pour MySQL, ce serait :

mysqldump -uUser -pPass -hHost –base de données à transaction unique > backup.bak

Pour MongoDB, ce serait :

mongodump –host=mongodb.example.net –port=27017 Publicité

Ensuite, vous devrez restaurer la base de données sur le serveur cible. Pour MySQL, ce serait :

mysql -u [utilisateur] -p [nom_base_de_données] < [nom de fichier].sql

et pour MongoDB, ce serait :

mongorestore <options> <chaîne-connexion> <répertoire ou fichier à restaurer>

Pour les autres bases de données, vous devriez pouvoir trouver les commandes pertinentes en ligne.

Basculement des IP vers le nouveau système

Bien sûr, vous voudrez vérifier que tout fonctionne comme prévu avant de continuer, mais une fois que c'est le cas, vous voudrez transférer le trafic vers le nouveau serveur.

La façon la plus simple de le faire est pour modifier vos enregistrements DNS. Une fois mis à jour, les clients et services seront envoyés au nouveau serveur. Cependant, cela se produit tout d'un coup, donc si vous avez un équilibreur de charge, il serait préférable de transférer lentement le trafic vers la nouvelle instance.

Si vous êtes sur AWS, ou un fournisseur similaire avec Elastic Adresses IP, vous pouvez échanger l'adresse pour pointer vers le nouveau serveur, qui ne nécessitera pas de mise à jour DNS. Dans l'onglet IP Elastic de la console EC2, Action > Associer l'adresse IP Elastic.

Publicité

Cela vous permettra de modifier l'association, qui échangera instantanément le trafic vers la nouvelle instance.