Сначала убедитесь, что логический том не подключен. Если это так и вы хотите сделать «горячую копию», сначала создайте снимок и используйте вместо этого:
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 - это ключ шифрования, вы должны его поменять.