Remarque : Cet article est un guide et non un processus étape par étape. Il suppose que vous êtes familiarisé avec l'administration système Linux® et le rsync N'exécutez pas les commandes de cet article si vous ne les maîtrisez pas parfaitement. Dans tous les cas, assurez-vous d'avoir sauvegardé vos données avant de suivre les étapes de ce guide. Des frais de bande passante standard s'appliquent.
Ce guide vous aide à raccourcir les délais de migration des serveurs. Si les applications de votre serveur correspondent à l'une des caractéristiques mises en évidence dans cet article, lisez la suite. Cet article peut rendre les temps de rsync plus courts et plus prévisibles pour vous. Cela montre également comment réduire les temps de migration en prenant des mesures préventives avant de le faire.
Accélérer le processus rsync
Le volume d'espace disque utilisé sur un serveur détermine les temps de rsync. Autrement dit, plus il y a de données à copier, plus la tâche prend de temps. En règle générale, une rsync de système d'exploitation vide prend 10 à 15 minutes. Les cas d'utilisation de serveur suivants peuvent considérablement prolonger le temps de rsync :
- Serveurs contenant de nombreux petits fichiers, tels que des fichiers de session Ruby, des fichiers de cache, des fichiers de messages de serveur de messagerie ou des vignettes d'image de serveur Web . La migration de ces données à l'aide de rsync prend plus de temps que prévu. Cela signifie qu'une synchronisation initiale prend plus de temps, mais qu'une seconde passe en mode de secours (avec temps d'arrêt associé) est plus courte.
- Serveurs contenant plusieurs fichiers mis à jour lors de la synchronisation en direct . En règle générale, il s'agit de fichiers de table MySQL® MyISAM ou de serveurs Web hébergeant plusieurs domaines, chacun étant configuré pour se connecter à des fichiers distincts. La nécessité de mettre à jour ces fichiers activement écrits après la copie rsync de première passe prolonge le temps d'arrêt entre un redémarrage et la fin d'une seconde passe du processus rsync.
- Serveurs contenant un ou plusieurs fichiers volumineux mis à jour lors de la migration . Les exemples incluent les bases de données MySQL utilisant le format InnoDB, les serveurs de messagerie avec des journaux de messagerie volumineux et les serveurs Web qui se connectent à des fichiers uniques et volumineux. La mise à jour de ces fichiers activement écrits avec un deuxième rsync après la copie rsync de premier passage peut considérablement prolonger le temps d'arrêt associé.
Le secret pour réduire les temps de rsync est de gérer les données sur votre serveur et d'identifier toutes les applications qui écrivent sur le disque pendant la migration en direct.
Problème :surcharge des petits fichiers
Bien qu'ils n'occupent pas beaucoup d'espace disque individuel, les serveurs hébergeant de nombreux petits fichiers forcent le processus rsync à effectuer de nombreux file-open , file-copy , et file-check processus.
Par exemple, un fichier de données d'un gigaoctet nécessite un ensemble de processus d'ouverture, de copie et de vérification de fichier. Comparez cela avec un bloc de données d'un gigaoctet réparti sur 10 000 fichiers individuels qui nécessite 10 000 ensembles individuels de processus de fichiers. C'est beaucoup plus de surcharge système et réseau.
La liste suivante répertorie les applications qui créent de nombreux petits fichiers et dont les temps de préparation à la migration sont plus longs :
- Serveurs Web diffusant de nombreuses vignettes ou fichiers image de petite taille
- Mise en cache des serveurs qui mettent en cache sur le disque avec de petits fichiers
- Serveurs de messagerie avec de grandes archives d'e-mails non supprimés
- Les serveurs Ruby ou Rails, qui ont tendance à créer plusieurs petits fichiers de session et à ne pas les supprimer
- dépôts git
- Serveurs d'applications personnalisés qui créent mais ne suppriment pas les fichiers de session pour chaque visiteur
Le problème des petits fichiers rend le rsync moins prévisible et prend plus de temps.
Comment migrer
Vérifiez vos applications serveur par rapport à la liste précédente. Si vos applications sont sur la liste, faites ce que vous pouvez pour élaguer les petits fichiers indésirables avant d'exécuter le véritable rsync commande. Si vous utilisez Ruby ou Rails, imaginez le pire et recherchez dans les forums de la communauté les emplacements typiques des fichiers de session et de cache, ainsi que la manière d'identifier ceux que vous pouvez supprimer en toute sécurité. Envisagez de stocker les données de session dans MySQL avec la commande suivante :
rake db:sessions:create
Tronquer les fichiers journaux dans log/ à zéro octet avec la commande suivante :
rake log:clear
Si vous exécutez un serveur de mise en cache qui met en cache sur le disque au lieu de la RAM, identifiez son répertoire de stockage de fichiers et élaguez de manière agressive. Vérifiez votre système de fichiers pour les petits fichiers de session et de cache créés par des applications personnalisées. Encore une fois, taillez avec vigueur. Si vous migrez un serveur de messagerie avec un agent de distribution de courrier (MDA) tel que Dovecot, demandez d'abord à vos utilisateurs de messagerie de nettoyer leurs archives de messagerie d'oldemail.
Problème :Modification constante des fichiers
Vous devez copier à nouveau les fichiers qui changent entre le début et la fin d'un rsync avec un rsync de suivi pour une migration complète du serveur. Ce processus prolonge le temps d'exécution de la migration.
Les serveurs de base de données sont les coupables les plus fréquents qui mettent à jour des fichiers de données volumineux entre le début et la fin d'une migration. Ces modifications obligent le système à recopier l'intégralité du fichier de base de données dans un deuxième processus rsync que vous pourriez effectuer lors d'une migration.
Certaines combinaisons de structure et de type de base de données ont tendance à exacerber ce type de problème. Par exemple, supposons que vous disposiez d'une base de données MyISAM multi-tables MySQL avec de nombreux fichiers de table mis à jour dans des transactions SQL individuelles. Dans ce cas, de nombreux fichiers de table, sinon tous, devront peut-être être copiés à nouveau lors de la deuxième opération rsync en mode de secours.
Étant donné que les fichiers de base de données peuvent être volumineux, les implications de ces mises à jour pour le temps de migration deviennent claires. Il est difficile de prédire avec précision la durée d'une migration rsync. Après tout, comment pouvons-nous prévoir quelles mises à jour SQL et combien de mises à jour SQL auront lieu entre le début et la fin de la migration ?
Comment migrer
Si votre base de données contient beaucoup de données obsolètes, envisagez d'archiver ces données, puis de les supprimer de la base de données active avant de migrer votre serveur. MySQL, par exemple, vous permet d'archiver des données en utilisant le mysqldump script, après quoi vous pouvez supprimer les données obsolètes dans la livedatabase. Le grand mysqldump le fichier de sortie contenant les données obsolètes ne prolonge pas un deuxième rsync car il n'aura pas changé depuis la première passe.
Une autre option si vous avez des applications qui écrivent dans de nombreux fichiers pendant le redimensionnement consiste à définir l'application en mode lecture seule immédiatement avant d'exécuter le rsync commande. Vous pouvez généralement définir les bases de données en mode lecture seule temporaire. Avec d'autres applications, votre kilométrage peut varier. Vous pouvez également empêcher les écritures dans plusieurs fichiers en désactivant les applications, mais la configuration des applications en mode lecture seule est généralement l'option préférée.
Problème :Fichiers volumineux constamment mis à jour
Les fichiers très volumineux (10 Go ou plus) mis à jour lors d'une rsync posent des problèmes de temps de migration similaires à ceux des fichiers plus petits, constamment mis à jour mais sur les stéroïdes. Si votre serveur héberge des fichiers fréquemment écrits, cette section est pour vous.
Un deuxième rsync doit recopier complètement ces gros fichiers constamment mis à jour pour capturer toutes les mises à jour effectuées après le début d'un processus de migration ou de redimensionnement. Cela prolonge considérablement le temps de migration en raison de la taille de cette deuxième copie rsync.
Les serveurs de base de données MySQL qui utilisent le format de fichier de données InnoDB écrivent des données dans un seul fichier qui devient vraiment très volumineux. De même, MySQL en mode InnoDB se connecte à un seul fichier journal volumineux.
Une mise à jour d'un grand fichier de données ou de journal InnoDB MySQL, tel que /var/lib/mysql/ibdata1 , force le processus rsync à recopier l'intégralité du fichier lors d'une seconde passe. Si ces fichiers sont volumineux, la recopie peut prendre un certain temps, ce qui maintient la base de données hors ligne.
Une autre source de fichiers volumineux est constituée par les journaux d'application, y compris les journaux produits par les serveurs de messagerie et certains serveurs Web. Apache® peut produire des fichiers journaux de 16 Go ou plus, il n'est donc pas sûr de supposer que la journalisation par défaut d'Apache vous aide à éviter ce problème de fichiers volumineux.
Les journaux de transactions MySQL peuvent également devenir volumineux si vous avez activé la journalisation des transactions. Les gens le font rarement, et il est encore plus rare qu'ils activent la journalisation des transactions sans manquer d'espace disque par la suite. Néanmoins, il est sage de garder un œil sur cette possibilité.
Comment migrer
Comme décrit précédemment, l'élagage des bases de données cruft peut aider à réduire le temps total de rsync. Archivez et supprimez les bases de données anciennes ou obsolètes avant de tenter une migration.
Encore une fois, la désactivation des écritures de base de données, si possible, réduit le temps de migration. La désactivation de la journalisation peut également aider les bases de données InnoDB.
Si vous avez activé la journalisation des transactions MySQL et que le fichier journal des transactions est volumineux, cela vaut la peine de le désactiver, de l'archiver, puis de le supprimer sur la tranche avant de démarrer une rsyncmigration.
Sur les serveurs de messagerie, vérifiez la taille de /var/log/mail.log ou /var/log/maillog avant la migration. Pensez à désactiver le serveur de messagerie avant la migration, en particulier si vous disposez d'un serveur de messagerie de secours pour prendre en charge la charge.
De même, vérifiez comment Apache se connecte. S'il enregistre toutes les requêtes dans un seul fichier, vérifiez la taille de ce fichier et envisagez de l'archiver et de le supprimer ou de désactiver Apache avant de démarrer le processus de migration. Le même conseil s'applique à toute autre application dont vous savez qu'elle écrit dans un fichier journal volumineux.
Pour ces applications et toutes les autres, passez en revue votre logrotate politique (si vous en avez une) pour vérifier qu'elle surveille la taille de vos fichiers journaux. Cela vous évite les temps d'arrêt pendant la migration et facilite la vie avec n'importe quel serveur Linux.
Emballez votre sac à outils
Bien sûr, il est difficile de suivre les fichiers créés après avoir configuré le serveur. Cela est vrai pour les applications qui créent des fichiers de session. Il est payant de trouver et d'éliminer ces grandes collections de petits fichiers.
Vous pouvez identifier les dix répertoires et fichiers les plus volumineux en exécutant la commande suivante en tant que root :
du -a / | sort -n -r | head -n 10
Changez ce dernier 10 à n'importe quel autre nombre pour modifier le nombre de fichiers et de répertoires renvoyés par la recherche. Cette commande est un bon outil intermédiaire pour identifier les grands répertoires de petits fichiers et de gros fichiers. Si vous souhaitez uniquement rechercher des fichiers volumineux, essayez cet outil de recherche de fichiers volumineux (en tant que root ):
find ~/ -mount -type f -ls|sort -rnk7 |head -30|awk '{printf "%10d MB\t%s\n",($7/1024)/1024,$NF}'
Si vous souhaitez uniquement rechercher des répertoires volumineux, essayez cet outil de recherche de répertoires volumineux (en tant que root ):
du -x --max-depth=4 ~/|sort -rn|head -n30|awk '{printf "%10d MB\t%s\n",$1/1024,$2}'
Détails techniques
Supposons que votre serveur ne corresponde à aucun des types courants que nous avons examinés ci-dessus. Dans ce cas, vous pouvez évaluer à quoi pourrait ressembler son temps de migration si vous considérez vos applications avec une compréhension du fonctionnement du processus de migration (rsync).
La première étape typique d'une migration est une synchronisation en direct, qui est essentiellement une copie de l'ensemble du système de fichiers du serveur. Toutes les applications sont laissées en cours d'exécution pendant cette étape.
C'est là que la prévision du temps de migration rencontre sa première incertitude. Sans une connaissance détaillée de votre utilisation du système de fichiers de votre serveur, vous ne pouvez pas prédire avec précision la durée de la file-copy l'étape d'une rsync prendra pour se terminer.
Cette imprévisibilité est vraie pour le répertoire final sur les systèmes de fichiers Linux :le /var/ annuaire. Il s'appelle var parce que la taille des données qu'il contient est variable et change pendant que les applications du serveur sont en cours d'exécution.
La deuxième incertitude est que la phase finale d'une migration comprend un composant de mode de secours (temps d'arrêt). Au cours de cette phase, le processus copie à nouveau tous les fichiers mis à jour après le début de la phase rsyncfirst en direct. La durée du temps d'arrêt dépend de la taille et du nombre de fichiers mis à jour. Encore une fois, le processus rsync ne peut pas dire à l'avance combien de mises à jour des applications comme MySQL écrivent dans les fichiers de données, il est donc difficile de prédire la durée de ce sauvetage final. mode rsync copier.
Les informations précédentes s'appliquent à un processus de migration manuelle typique. Notre Cloud change le processus de redimensionnement pour arrêter le serveur pour une seule rsync, augmentant les temps d'arrêt et augmentant la fiabilité de la synchronisation.
Résumé
Si vous savez comment vos applications utilisent l'espace disque et écrivent dans des fichiers, vous pourrez peut-être déterminer si une migration prendra plus de temps que prévu et vous préparer en conséquence. À tout le moins, vous pouvez utiliser vos nouvelles connaissances en matière de migration pour mieux planifier les migrations en fonction de vos impératifs de calendrier.
Utilisez l'onglet Commentaires pour faire des commentaires ou poser des questions. Vous pouvez également démarrer une conversation avec nous.