Comment synchronisez-vous d'énormes fichiers épars (images de disque VM) entre les machines?


22

Existe-t-il une commande, telle que rsync, qui peut synchroniser des fichiers volumineux et clairsemés d'un serveur Linux à un autre?

Il est très important que le fichier de destination reste clairsemé. Il peut être plus long (mais pas plus gros) que le lecteur qui le contient. Seuls les blocs modifiés doivent être envoyés sur le câble.

J'ai essayé rsync, mais je n'ai eu aucune joie. https://groups.google.com/forum/#!topic/mailing.unix.rsync/lPOScZgFE9M

Si j'écris un programme pour ce faire, est-ce que je réinvente la roue? http://www.finalcog.com/synchronise-block-devices

Merci,

Chris.


rsync est extrêmement inefficace avec des fichiers volumineux. Même avec --inplace il va d' abord lire le fichier entier sur l'hôte cible et ALORS commencer à lire le fichier sur l'hôte local et transférer les différences ( il suffit d' exécuter dstat ou similaire lors de l' exécution rsync et observer)
ndemou

Réponses:


21
rsync --ignore-existing --sparse ...

Pour créer de nouveaux fichiers en mode clairsemé

Suivi par

rsync --inplace ...

Pour mettre à jour tous les fichiers existants (y compris les fichiers clairsemés précédemment créés) sur place.


3
Inversez-le pour avoir rsync --existing --inplace, puis rsync --ignore-existing --sparsepour avoir une accélération de synchronisation
Mike

2
Quelqu'un peut-il expliquer le commentaire de Mikes et comment cela devrait accélérer la synchronisation?
Preexo

Je pense que Mike signifie le premier changement sur place et ensuite ajouter de nouveaux, de sorte que les nouveaux n'ont pas besoin d'être à nouveau en place en raison de la différence de temps entre le premier et le deuxième appel. Cela n'est vrai que si vous rsync directement hors de la banque de données et que les machines virtuelles sont en cours d'exécution. A moins qu'il ne veuille autre chose?
Yuan

Je suis d'accord avec Yuan. La deuxième commande de Steves synchronisera à nouveau les nouveaux fichiers, vous pouvez le sécuriser en utilisant la séquence de commandes Mikes.
falstaff

rsync est extrêmement inefficace avec des fichiers volumineux. Voir mon commentaire sur la question.
ndemou

5

Rsync transfère uniquement les modifications dans chaque fichier et avec --inplace ne doit réécrire que les blocs modifiés sans recréer le fichier. Depuis leur page de fonctionnalités .

rsync est un programme de transfert de fichiers pour les systèmes Unix. rsync utilise "l'algorithme rsync" qui fournit une méthode très rapide pour synchroniser des fichiers distants. Pour ce faire, il envoie uniquement les différences dans les fichiers via le lien, sans exiger que les deux ensembles de fichiers soient présents à l'une des extrémités du lien.

L'utilisation de --inplace devrait vous convenir. Cela vous montrera la progression, compressera le transfert (au niveau de compression par défaut), transférera le contenu du répertoire de stockage local de manière récursive (cette première barre oblique importante), apportera les modifications aux fichiers en place et utilisera ssh pour le transport.

rsync -v -z -r --inplace --progress -e ssh /path/to/local/storage/ \
user@remote.machine:/path/to/remote/storage/ 

J'utilise souvent le drapeau -a également, ce qui fait encore quelques choses. C'est équivalent à -rlptgoD Je vous laisse le comportement exact à rechercher dans la page de manuel.


1
Le '-S' est pour les fichiers clairsemés, pas les 'haches longues lignes'. Depuis la page de manuel: -S, --sparse gère efficacement les fichiers épars. Je vais essayer, merci.
fadedbee

Merci, j'ai corrigé cela - Je m'éloignais de quelque chose qui était dit dans le lien que vous avez donné.
reconbot

Non, malheureusement, cela ne résout pas le problème. Il fait synchroniser le fichier, mais il transforme le fichier creux à l'extrémité dans un fichier non clairsemée. J'utilise ssh / rsync fourni avec Ubuntu 9.04.
fadedbee

Mon commentaire ci-dessus était incorrect. Le problème était que rsync crée des fichiers non clairsemés sur sa première copie. Le --inplace rsync fonctionne correctement, à condition que le fichier de destination existe déjà et soit aussi long (pas grand) que le fichier d'origine. J'ai maintenant une solution, mais il me faut vérifier si chaque fichier existe déjà sur le serveur cible. Si c'est le cas, je fais un --inplace, sinon, j'utilise --sparse. Ce n'est pas idéal, mais ça marche.
fadedbee

rsync est extrêmement inefficace avec des fichiers volumineux. Voir mon commentaire sur la question
ndemou

4

J'ai fini par écrire un logiciel pour faire ça:

http://www.virtsync.com

Il s'agit d'un logiciel commercial coûtant 49 $ par serveur physique.

Je peux maintenant répliquer un fichier clairsemé de 50 Go (qui contient 3 Go de contenu) en moins de 3 minutes sur le haut débit résidentiel.

chris@server:~$ time virtsync -v /var/lib/libvirt/images/vsws.img backup.barricane.com:/home/chris/
syncing /var/lib/libvirt/images/vsws.img to backup.barricane.com:/home/chris/vsws.img (dot = 1 GiB)
[........>.........................................]
done - 53687091200 bytes compared, 4096 bytes transferred.

real    2m47.201s
user    0m48.821s
sys     0m43.915s 

4
TBH, le moment où vous pouvez synchroniser n'a pas de sens car il dépend évidemment de la quantité de données modifiées. Ce qui serait plus précis à dire, c'est que cela prend 3 minutes à votre logiciel pour déterminer quels blocs ont changé, et même cette vitesse dépend probablement des E / S de votre disque et peut-être des cycles CPU disponibles.
Extracteur de réalité

6
Vous devez divulguer qu'il s'agit d'un logiciel commercial coûtant 98 $ ou plus pour la fonctionnalité réseau.
Reid

Merci de nous avoir indiqué un logiciel qui fonctionnait bien pour vous, que les gens peuvent désormais envisager et utiliser, ou ne pas utiliser à leur guise. Non merci pour les deux autres personnes pour leur contribution rien de nouveau.
Florian Heigl,

3

Jetez un oeil à Zumastor Linux Storage Project, il implémente la sauvegarde "snapshot" en utilisant "rsync" binaire via l' ddsnapoutil.

Depuis la page de manuel:

ddsnap fournit une réplication de périphérique de bloc grâce à une fonction d'instantané au niveau du bloc capable de contenir efficacement plusieurs instantanés simultanés. ddsnap peut générer une liste de blocs de snapshots qui diffèrent entre deux snapshots, puis envoyer cette différence sur le câble. Sur un serveur en aval, écrivez les données mises à jour sur un périphérique de bloc instantané.


2

lvmsync fait cela.

Voici une transcription d'utilisation . Il crée un instantané LVM sur la source, transfère la partition logique. Vous pouvez transférer les mises à jour incrémentielles des modifications depuis la création de l'instantané aussi souvent que vous le souhaitez.


Je l'ai essayé, mais cela ne fonctionne pas, et l'auteur n'est pas disposé à prendre en charge
user1007727

1
@ user1007727 pas disposé à soutenir, ou pas disposé à soutenir gratuitement?
fadedbee

J'ai utilisé lvmsync dans le passé, cela a fonctionné mais ce n'est pas un logiciel "prod grade" imo. :-)
Florian Heigl

1

La réplication de l'ensemble du système de fichiers pourrait-elle être une solution? DRBD? http://www.drbd.org/


Je ne pense pas que drbd soit une bonne solution ici, mais l'idée de rsyncing --inplace l'ensemble du fs, plutôt que les fichiers d'image disque, est intéressante. Je ne suis pas sûr que rsync le permette - je vais essayer de faire un rapport ...
fadedbee

1

Peut-être un peu étrange ici, mais j'ai découvert récemment que NFS gère très bien.

Vous exportez donc un répertoire sur une machine puis le montez sur l'autre et vous copiez simplement les fichiers avec des utilitaires de base comme cp. (Certains utilitaires anciens / anciens peuvent avoir des problèmes avec des fichiers épars.)

J'ai trouvé rsyncparticulièrement inefficace le transfert de fichiers épars.


1

Pour synchroniser des fichiers volumineux ou des blocs-périphériques avec des différences faibles à modérées, vous pouvez soit faire une copie simple ou utiliser bdsync , rsync n'est absolument pas adapté à ce cas particulier *.

bdsynca fonctionné pour moi, semble assez mature, son histoire de bugs est encourageante (petits problèmes, résolution rapide). Dans mes tests, sa vitesse était proche du maximum théorique que vous pourriez obtenir ** (c'est-à-dire que vous pouvez synchroniser environ le temps dont vous avez besoin pour lire le fichier). Enfin, c'est open source et ne coûte rien.

bdsynclit les fichiers des hôtes et échange des sommes de contrôle pour les comparer et détecter les différences. Tout cela en même temps . Il crée enfin un fichier patch compressé sur l'hôte source. Ensuite, vous déplacez ce fichier vers l'hôte de destination et exécutez bdsync une deuxième fois pour patcher le fichier de destination.

Lorsque vous l'utilisez sur une liaison plutôt rapide (par exemple, Ethernet 100 Mbit) et pour les fichiers avec de petites différences (comme c'est le plus souvent le cas sur les disques VM), cela réduit le temps de synchronisation avec le temps dont vous avez besoin pour lire le fichier. Sur une liaison lente, vous avez besoin d'un peu plus de temps car vous devez copier les modifications compressées d'un hôte à l'autre (il semble que vous puissiez gagner du temps en utilisant une astuce intéressante mais que vous n'avez pas testé).


*: rsync est extrêmement inefficace avec des fichiers volumineux. Même avec --inplace, il lira d'abord le fichier entier sur l'hôte de destination, AFTERWARDS commencera à lire le fichier sur l'hôte source et finalement transférera les différences (exécutez simplement dstat ou similaire tout en exécutant rsync et observez). Le résultat est que même pour les fichiers avec de petites différences, il faut environ le double du temps nécessaire pour lire le fichier afin de le synchroniser.

**: En supposant que vous n'avez aucun autre moyen de savoir quelles parties des fichiers ont changé. Les instantanés LVM utilisent des bitmaps pour enregistrer les blocs modifiés afin qu'ils puissent être extrêmement plus rapides (le fichier Lisezmoi de lvmsync contient plus d'informations).


0

Je ne connais pas un tel utilitaire, seulement des appels système qui peuvent le gérer, donc si vous écrivez un tel utilitaire, il pourrait être plutôt utile.

ce que vous pouvez réellement faire est d'utiliser qemu-img convert pour copier les fichiers, mais cela ne fonctionnera que si le FS de destination prend en charge les fichiers épars

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.