5 votes

Comment copier un grand nombre (> 1 million) de petits fichiers entre deux serveurs ?

Je dois migrer environ 1 To de données composées de petits fichiers (la plupart de moins de 100 Ko) vers un autre serveur. Je n'ai pas encore fait l'inventaire complet des fichiers, mais les estimations se situent entre 1 et 2 millions.

La copie initiale à l'aide de SCP a pris plus d'une semaine. Maintenant, nous devons synchroniser les changements. Des centaines, voire des milliers de fichiers sont ajoutés chaque jour.

J'ai essayé d'utiliser rsync (v3) mais cela prend trop de temps. Le temps que cela se termine, nous aurons à nouveau des données non synchronisées.

J'ai vu des questions similaires ici mais elles sont un peu plus anciennes et je me demande s'il existe de nouveaux outils pour faciliter ce processus.

Les problèmes sont d'autant plus compliqués que les données sources se trouvent sur un système iSCSI partagé dont les performances de lecture sont médiocres.

La dernière stratégie consiste peut-être à refaire la migration des données et à demander aux développeurs d'écrire un outil pour enregistrer tous les nouveaux fichiers ajoutés pendant le processus de migration. La structure des répertoires est basée sur un identifiant unique et est très large et profonde. Les nouveaux fichiers sont donc dispersés dans cette structure et réécrire l'application pour placer les nouveaux fichiers dans un répertoire spécifique ne fonctionnera pas.

Toute stratégie est la bienvenue.

Le système d'exploitation est RHEL 5 et va devenir RHEL 6.

0 votes

Au lieu de copier sur un nouveau serveur, pourquoi ne pas utiliser un NAS que les deux serveurs montent ?

0 votes

Avez-vous besoin d'une synchronisation en temps réel ou quasi réel, ou la machine secondaire n'est-elle qu'une sauvegarde ?

0 votes

Cela ressemble à une migration complète d'un système à un autre.

6voto

Stephane Points 6344

Je serais tenté de répondre "arrêtez d'abuser du système de fichiers en le traitant comme une base de données" mais je suis sûr que cela ne vous aiderait pas beaucoup ;)

Tout d'abord, vous devez comprendre que si votre limitation se situe au niveau de la bande passante disponible en lecture, il n'y a rien que vous puissiez faire pour améliorer les performances en utilisant une simple commande de synchronisation. Dans ce cas, vous devrez diviser les données lors de leur écriture, soit en changeant la façon dont les fichiers sont créés (ce qui signifie, comme vous l'avez deviné, demander aux développeurs de changer le programme source), soit en utilisant un produit qui fait du géomirroring (comme par exemple double prise Il s'agit d'un exemple, et je suis sûr que vous trouverez d'autres solutions.)

Dans des cas similaires, la cause principale du problème n'est généralement pas les données du fichier mais plutôt l'accès aux méta-données. Votre première stratégie sera donc de diviser la charge en plusieurs processus qui agissent sur des répertoires (complètement) différents : cela devrait aider le système de fichiers à continuer à vous fournir les méta-données dont vous avez besoin.

Une autre stratégie consiste à utiliser votre système de sauvegarde pour cela : rejouez vos dernières sauvegardes incrémentielles sur la cible pour maintenir la base de données synchronisée.

Enfin, il existe des stratégies plus exotiques qui peuvent être appliquées dans des cas spécifiques. Par exemple, j'ai résolu un problème similaire sur un site Windows en écrivant un programme qui chargeait les fichiers dans le système de fichiers toutes les quelques minutes, gardant ainsi le FS propre.

0 votes

Il s'agit d'une mission de conseil avec une contribution limitée à la conception de l'application, nous travaillons donc un peu à l'aveuglette sur ce plan. J'espère que la base de données enregistre le chemin d'accès au nouveau fichier. Si c'est le cas, alors une synchronisation initiale suivie d'une liste de la base de données et du déplacement de ces fichiers. Nous répéterons ce processus jusqu'à ce que la synchronisation soit terminée en moins de 24 heures. Nous pourrons alors inverser le DNS et déplacer l'hébergement de ces fichiers vers le nouveau système.

0 votes

+1 pour la recommandation d'exécution parallèle. Je l'avais envisagé mais j'évitais d'avoir à le script.

2voto

ewwhite Points 193555

Je ne pense pas que quelque chose ait changé. Si vous pouvez mettre sous silence les données sur le système source, je pense que certaines variante du goudron sera le plus rapide. Sinon, rsync reste la meilleure solution, en veillant à utiliser le commutateur de fichiers entiers et un algorithme de compression moins gourmand en ressources CPU (par exemple arcfour). Avez-vous la possibilité d'effectuer une copie au niveau du bloc ? Vous mentionnez le stockage iSCSI. Le nouveau système sera-t-il également doté d'un stockage iSCSI ?

0 votes

Le nouveau système est RAID 10 SATA qui est en fait 3x plus rapide que le système iSCSI partagé. Nous avons une sauvegarde au niveau des blocs mais le processus de restauration est assez lent lorsqu'il s'agit d'une restauration au niveau des fichiers. Les restaurations de type bare metal ou partition complète sont plus rapides. C'est une option que nous envisageons.

0voto

jeffatrackaid Points 4092

Cela se fait par étapes :

1) transer initial en utilisant scp 2) quelques données rafraîchies avec rsync 3) les développeurs écrivent un script pour tirer les fichiers ajoutés depuis l'étape 1 au système 4) les données seront transmises par proxy du serveur d'origine au nouveau serveur pendant le changement de DNS 5) changer le dns et se débarrasser des services iSCSI partagés sous-performants.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X