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

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?

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.

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 [email protected] 'gzip -d | dd of=/dev/volumegroupname/logicalvolume  bs=4096'

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.

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.

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.