Перемещение логического тома напрямую с одного сервера на другой по сети?

У меня есть хост-машина KVM с несколькими виртуальными машинами. Каждая виртуальная машина использует логический том на хосте. Мне нужно скопировать LV на другой хост-компьютер.

Обычно я бы использовал что-то вроде:

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

Чтобы превратить LV в файл изображения и использовать SCP для его перемещения. Затем используйте DD, чтобы скопировать файл обратно в новый LV на новом хосте.

Проблема этого метода в том, что вам нужно вдвое больше дискового пространства, чем виртуальной машине на обеих машинах. то есть. LV 5 ГБ использует 5 ГБ пространства для LV, а копия dd также использует дополнительные 5 ГБ пространства для изображения. Это хорошо для небольших LV, но что, если (как в моем случае) у вас есть 500 ГБ LV для большой виртуальной машины? Новый хост-компьютер имеет жесткий диск емкостью 1 ТБ, поэтому он не может содержать файл образа dd объемом 500 ГБ и имеет логический том объемом 500 ГБ для копирования, а также место для основной ОС и место для других небольших гостей.

То, что я хотел бы сделать, это что-то вроде:

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

Другими словами, скопируйте данные напрямую с одного логического тома на другой по сети и пропустите промежуточный файл изображения.

Это возможно?

Конечно, конечно, это возможно.

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

Boom.

Сделайте себе одолжение, и используйте что-то большее, чем размер блока по умолчанию. Возможно добавьте bs = 4M (чтение / запись кусками по 4 МБ). Вы можете видеть, что в комментариях есть придирки к размерам блоков; если это то, что вы делаете довольно часто, потратьте немного времени, чтобы попробовать это несколько раз с разными размерами блоков, и посмотрите сами, что дает вам лучшие скорости передачи.

Отвечая на один из вопросов из комментариев:

Вы можете передать передачу через pv, чтобы получить статистику о передаче. Это намного лучше, чем результат, который вы получаете от отправки сигналов dd.

Я также скажу, что хотя использование netcat - или чего-либо еще, что не накладывает накладных расходов на шифрование - будет более эффективным, я обычно нахожу, что дополнительная скорость приходит с некоторой потерей удобства. Если я не перемещаюсь по действительно большим наборам данных, я обычно придерживаюсь ssh, несмотря на накладные расходы, потому что в большинстве случаев все уже настроено на Just Work.

Вот оптимизированная версия, которая показывает прогресс с использованием pvи использует BS для больших кусков, а также использует gzipдля уменьшения сетевого трафика.

Это прекрасно при перемещении данных между медленными соединениями, такими как интернет-серверы. Я рекомендую запустить команду внутри сеанса экрана или tmux. Таким образом, соединение ssh с хостом, с которого вы выполняете команду, может быть без проблем отключено.

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

Как насчет использования старого друга для этого. NetCat.

В системе, которая теряет тип логического тома

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

Затем на приемной системе. тип

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

Переводя, orgin box dd этого файла и передайте его в nc (netcat), который будет прослушивать этот порт. В принимающей системе netcat будет ждать 10 секунд, если не получит данных, прежде чем закрыться на [ip или name] на [port], а затем направить эти данные в dd для их записи.

Сначала я бы сделал снимок lv:

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

После этого вы должны создать новый lv на новом хосте (например, используя lvcreate) с тем же размером. Затем вы можете напрямую скопировать данные на новый хост. Вот мой пример команды копирования:

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

Я использовал процедуру, чтобы скопировать виртуальную машину Proxmox Pve на другой хост. Логический том содержал несколько дополнительных LV, которые поддерживались самой VM.

Сначала убедитесь, что логический том не подключен. Если это так и вы хотите сделать «горячую копию», сначала создайте снимок и используйте вместо этого: lvcreate --snapshot --name transfer_snap --size 1G

Я должен передать много данных (7 ТБ) между двумя подключенными серверами 1 Гбит, поэтому мне нужен был самый быстрый способ сделать это.

Вы должны использовать SSH?

Использование ssh не подлежит сомнению не из-за его шифрования (если у вас есть процессор с поддержкой AES-NI, это не так уж больно), а из-за его сетевых буферов. Это плохо масштабируется. Существует исправленная версия Ssh, которая решает эту проблему, но поскольку нет предварительно скомпилированных пакетов, это не очень удобно.

Использование сжатия

При передаче необработанных образов дисков всегда рекомендуется использовать сжатие. Но вы не хотите, чтобы сжатие стало узким местом. Большинство инструментов сжатия Unix, таких как gzip, являются однопоточными, поэтому, если сжатие насыщает один процессор, это будет узким местом. По этой причине я всегда использую pigz, вариант gzip, который использует все ядра процессора для сжатия. И это необходимо, если вы хотите подняться до и выше скорости GBit.

Использование шифрования

Как уже было сказано, ssh работает медленно. Если у вас процессор AES-NI, это не должно быть узким местом. Поэтому вместо использования ssh мы можем использовать openssl напрямую.

Скорости

Чтобы дать вам представление о быстродействии компонентов, вот мои результаты. Это скорость передачи данных между двумя производственными системами: чтение и запись в память. Ваши реальные результаты зависят от скорости сети, скорости жесткого диска и скорости процессора источника! Я делаю это, чтобы показать, что, по крайней мере, нет огромного падения производительности. 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 Вывод: использование сжатия дает заметное ускорение, так как значительно уменьшает размер данных. Это еще более важно, если у вас медленная скорость сети. При использовании сжатия следите за использованием процессора. если использование становится максимальным, вы можете попробовать без него. Использование сжатия в качестве лишь небольшого воздействия на системы AES-NI, imho только потому, что оно отнимает около 30-40% процессорного времени от сжатия.

Использование экрана

Если вы передаете много таких данных, как я, вы не хотите, чтобы они прерывались сетевым отключением вашего ssh-клиента, поэтому лучше запустить его с экрана с обеих сторон. Это всего лишь примечание, я не буду писать урок экрана здесь.

Позволяет копировать

Установите некоторые зависимости (от источника и места назначения): apt install pigz pv netcat-openbsd

затем создайте том в месте назначения того же размера, что и источник. Если вы не уверены, используйте lvdisplay для исходного кода, чтобы получить размер и создать цель, т.е. lvcreate -n lvname vgname -L 50G

Далее подготовим пункт назначения для получения данных:

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

и когда будете готовы, начните передачу на 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

Примечание. Если вы передаете данные локально или не заботитесь о шифровании, просто удалите часть Openssl с обеих сторон. Если вам важно, asdkjn2hb - это ключ шифрования, вы должны его поменять.