Déplacer un volume logique directement d'un serveur à un autre sur le réseau?


13

J'ai une machine hôte KVM avec plusieurs machines virtuelles dessus. Chaque machine virtuelle utilise un volume logique sur l'hôte. J'ai besoin de copier les LV sur une autre machine hôte.

Normalement, j'utiliserais quelque chose comme:

dd if=/the/logical-volume of=/some/path/machine.dd

Pour transformer le LV en un fichier image et utiliser SCP pour le déplacer. Utilisez ensuite DD pour copier le fichier vers un nouveau LV sur le nouvel hôte.

Le problème avec cette méthode est que vous avez besoin de deux fois plus d'espace disque que la machine virtuelle prend sur les deux machines. c'est à dire. un LV de 5 Go utilise 5 Go d'espace pour le LV et la copie dd utilise également 5 Go d'espace supplémentaire pour l'image. C'est bien pour les petits LV, mais que se passe-t-il si (comme dans mon cas) vous avez un LV de 500 Go pour une grande VM? La nouvelle machine hôte a un disque dur de 1 To, elle ne peut donc pas contenir un fichier image dd de 500 Go et avoir un volume logique de 500 Go pour copier et avoir de la place pour le système d'exploitation hôte et de la place pour d'autres petits invités.

Ce que je voudrais faire, c'est quelque chose comme:

dd if=/dev/mygroup-mylv of=192.168.1.103/dev/newvgroup-newlv

En d'autres termes, copiez les données directement d'un volume logique à l'autre sur le réseau et ignorez le fichier image intermédiaire.

Est-ce possible?


Réponses:


24

Bien sûr, c'est possible.

dd if=/dev/mygroup-mylv | ssh 192.168.1.103 dd of=/dev/newvgroup-newlv

Boom.

Faites-vous une faveur, cependant, et utilisez quelque chose de plus grand que la taille de bloc par défaut. Ajoutez peut-être bs = 4M (lecture / écriture par blocs de 4 Mo). Vous pouvez voir qu'il y a quelques détails sur les tailles de blocs dans les commentaires; Si c'est quelque chose que vous faites assez souvent, prenez un peu de temps pour l'essayer à différentes reprises avec différentes tailles de blocs et voyez par vous-même ce qui vous permet d'obtenir les meilleurs taux de transfert.

Répondre à l'une des questions des commentaires:

Vous pouvez diriger le transfert via pv pour obtenir des statistiques sur le transfert. C'est beaucoup plus agréable que la sortie que vous obtenez en envoyant des signaux dd.

Je dirai également que, bien que l'utilisation de netcat - ou de toute autre chose qui n'impose pas la surcharge de cryptage - soit plus efficace, je trouve généralement que la vitesse supplémentaire s'accompagne d'une certaine perte de commodité. À moins que je ne me déplace dans des ensembles de données très volumineux, je m'en tiens généralement à ssh malgré les frais généraux, car dans la plupart des cas, tout est déjà configuré pour Just Work.


1
Le bs affecte-t-il uniquement la vitesse de copie ou a-t-il un effet sur la façon dont les données sont stockées?
Nick

3
Cela n'a aucun effet sur la façon dont les données sont stockées, mais il est beaucoup plus efficace que l'utilisation de la taille de bloc par défaut (de 512 octets) pour la lecture et l'écriture.
larsks

3
@Nick: Sous Linux, vous pouvez envoyer au ddprocessus le USR1signal pour lui faire afficher une ligne d'état avec le montant transféré. Obtenez le numéro de processus de votre ddprocessus avec quelque chose comme ps aux | grep dd, puis utilisez ce PID avec la commande kill -USR1 $PID. Le message sera affiché sur le terminal d'origine où vous avez commencé dd.
Sven

3
Vous ne voudrez probablement pas utiliser un bs aussi grand car il bloquera simplement l'écriture dans le canal vers ssh jusqu'à ce qu'il puisse en transférer la majeure partie vers le socket réseau, période pendant laquelle le disque deviendra inactif. Étant donné que la taille de lecture anticipée par défaut est de 128 Ko, vous voudrez probablement vous en tenir à cela. Ou augmentez la taille de lecture anticipée du disque.
psusi

1
@psusi: Le lien que Zoredache a mis en commentaire sous la question a démontré le contraire, ils ont obtenu le résultat le plus rapide avec des tailles de bloc de 16M, mais ont utilisé netcat au lieu de ssh comme méthode de transfert, ce qui est toujours une meilleure option lorsque le cryptage n'est pas requis.
Sven

18

Voici une version optimisée, qui montre la progression de l'utilisation pvet de l'utilisation de BS pour les gros morceaux et permet également gzipde réduire le trafic réseau.

C'est parfait lorsque vous déplacez les données entre des connexions lentes comme des serveurs Internet. Je recommande d'exécuter la commande dans un écran ou une session tmux. De cette façon, la connexion ssh à l'hôte à partir duquel vous exécutez la commande peut être déconnectée sans problème.

$ dd if=/dev/volumegroupname/logicalvolume bs=4096 | pv | gzip | \
    ssh root@78.46.36.22 'gzip -d | dd of=/dev/volumegroupname/logicalvolume  bs=4096'

2
Vous pouvez utiliser à la ssh -Cplace de gzip. Je ne sais pas s'il y a un impact sur les performances, mais c'est beaucoup moins de frappe.
Samuel Edwin Ward

1
Je suggère également d'utiliser pigz ou pxz -1 au lieu de gzip, le multithreading aide vraiment sur n'importe quel serveur moderne.
sCiphre

pvpeut causer des problèmes (selon mon expérience, déplacer plus de 500 vps vers d'autres serveurs avec ce système) avec le nombre d'octets, et après ce problème, les volumes lvm sont incohérents. Les avantages de voir l'avancement des travaux sont nuls et dangeorus. Si vous aimez voir la progression, ouvrez une console avec ifto par exemple.
abkrim

4

Que diriez-vous d'utiliser un ancien ami pour ce faire. NetCat.

Sur le système qui perd le type de volume logique

  • $ dd if=/dev/[directory]/[volume-name] | nc -l [any high number port]

Puis sur le système récepteur. type

  • $ nc -w 10 [ip or name] [port] | dd of=/dev/[directory/[volume name]

Traduction, boîte d'origine dd ce fichier et le diriger vers nc (netcat) qui écoutera ce port. Sur le système de réception, netcat attendra 10 secondes s'il n'obtient aucune donnée avant de se fermer sur [ip ou nom] sur [port], puis dirigera ces données vers dd pour les écrire.


2
Netcat n'utilise pas UDP avec ces options.
Samuel Edwin Ward

3

Je prendrais d'abord un instantané du lv:

lvcreate --snapshot --name my_shot --size <thesize> /dev/<name of vg>/<name of lv>

Après cela, vous devez créer un nouveau lv sur le nouvel hôte (par exemple en utilisant lvcreate) avec la même taille. Vous pouvez ensuite copier directement les données vers le nouvel hôte. Voici mon exemple de la commande de copie:

dd if=/dev/vg0/my_shot bs=4096 | pv | ssh root@some_host -C 'dd of=/dev/vg1/<created lv> bs=4096'

J'ai utilisé la procédure pour copier une machine virtuelle maintenue par proxmox pve sur un autre hôte. Le volume logique contenait plusieurs LV supplémentaires gérés par la machine virtuelle elle-même.


2

Assurez-vous d'abord que le volume logique n'est pas monté. Si c'est le cas et que vous souhaitez faire une "copie à chaud", créez d'abord un instantané et utilisez-le à la place: lvcreate --snapshot --name transfer_snap --size 1G

Je dois transférer beaucoup de données (7 To) entre deux serveurs connectés à 1 Gbit, donc j'avais besoin des moyens les plus rapides pour le faire.

Devriez-vous utiliser SSH?

L'utilisation de ssh est hors de question, non pas à cause de son cryptage (si vous avez un CPU avec support AES-NI, cela ne fait pas trop mal) mais à cause de ses tampons réseau. Ceux-ci ne évoluent pas bien. Il existe une version corrigée de Ssh qui résout ce problème, mais comme il n'y a pas de packages précompilés, ce n'est pas très pratique.

Utilisation de la compression

Lors du transfert d'images de disque brutes, il est toujours conseillé d'utiliser la compression. Mais vous ne voulez pas que la compression devienne un goulot d'étranglement. La plupart des outils de compression Unix comme gzip sont mono-thread, donc si la compression sature un CPU, ce sera un goulot d'étranglement. Pour cette raison, j'utilise toujours pigz, une variante gzip qui utilise tous les cœurs de processeur pour la compression. Et cela est nécessaire si vous souhaitez augmenter et dépasser les vitesses GBit.

Utilisation du cryptage

Comme dit précédemment, ssh est lent. Si vous avez un processeur AES-NI, cela ne devrait pas être un goulot d'étranglement. Ainsi, au lieu d'utiliser ssh, nous pouvons utiliser openssl directement.

Vitesses

Pour vous donner une idée de l'impact de la vitesse des composants, voici mes résultats. Ce sont des vitesses de transfert entre deux systèmes de production lisant et écrivant en mémoire. Vos résultats réels dépendent de la vitesse du réseau, de la vitesse du disque dur et de la vitesse du processeur source! Je fais cela pour montrer qu'il n'y a au moins aucune baisse de performance énorme. Simple nc dd: 5033164800 bytes (5.0 GB, 4.7 GiB) copied, 47.3576 s, 106 MB/s +pigz compression level 1 (speed gain depends on actual data): network traffic: 2.52GiB 5033164800 bytes (5.0 GB, 4.7 GiB) copied, 38.8045 s, 130 MB/s +pigz compression level 5: network traffic: 2.43GiB 5033164800 bytes (5.0 GB, 4.7 GiB) copied, 44.4623 s, 113 MB/s +compression level 1 + openssl encryption: network traffic: 2.52GiB 5033164800 bytes (5.0 GB, 4.7 GiB) copied, 43.1163 s, 117 MB/s Conclusion: l'utilisation de la compression donne une accélération notable, car elle réduit considérablement la taille des données. Ceci est encore plus important si vous avez des vitesses de réseau plus lentes. Lorsque vous utilisez la compression, surveillez votre utilisation du processeur. si l'utilisation est au maximum, vous pouvez essayer sans. L'utilisation de la compression n'est qu'un faible impact sur les systèmes AES-NI, à mon humble avis uniquement car elle dérobe 30 à 40% de cpu à la compression.

Utilisation de l'écran

Si vous transférez beaucoup de données comme moi, vous ne voulez pas qu'elles soient interrompues par une déconnexion réseau de votre client ssh, il vaut donc mieux le démarrer avec un écran des deux côtés. Ceci est juste une note, je n'écrirai pas de tutoriel d'écran ici.

Permet de copier

Installez certaines dépendances (sur la source et la destination): apt install pigz pv netcat-openbsd

puis créez un volume sur la destination avec la même taille que la source. En cas de doute, utilisez lvdisplay sur la source pour obtenir la taille et créer la cible, c'est-à-dire: lvcreate -n lvname vgname -L 50G

ensuite, préparez la destination pour la réception des données:

nc -l -p 444 | openssl aes-256-cbc -d -salt -pass pass:asdkjn2hb | pigz -d | dd bs=16M of=/dev/vgname/lvname

et lorsque vous êtes prêt, démarrez le transfert sur la source:

pv -r -t -b -p -e /dev/vgname/lvname | pigz -1 | openssl aes-256-cbc -salt -pass pass:asdkjn2hb | nc <destip/host> 444 -q 1

Remarque: Si vous transférez les données localement ou que vous ne vous souciez pas du chiffrement, retirez simplement la partie Openssl des deux côtés. Si vous vous en souciez, asdkjn2hb est la clé de chiffrement, vous devez la changer.


NE JAMAIS LE FAIRE SUR UN SERVEUR PROXMOX: apt install netcat-openbsd L'installation de netcat-openbsd a complètement effacé ProxMox du serveur et a causé plus de 5 heures de temps d'arrêt et de travail !!!
Zoltan
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.