Переміщення логічного тома безпосередньо з одного сервера на інший по мережі?


13

У мене хост-машина KVM з декількома VM на ньому. Кожен VM використовує логічний том на хості. Мені потрібно скопіювати НН на інший хост-апарат.

Зазвичай я б використовував щось на кшталт:

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

Щоб перетворити LV у файл зображення та використати SCP для його переміщення. Потім використовуйте DD, щоб скопіювати файл назад у новий LV на новому хості.

Проблема цього методу полягає в тому, що вам потрібно вдвічі більше місця на диску, ніж VM займає на обох машинах. тобто. 5 Гб ЛВ використовує 5 ГБ місця для НН, а копія ДД також використовує додаткові 5 ГБ місця для зображення. Це нормально для малих НН, але що робити, якщо (як у моєму випадку) у вас є 500 Гб ЛВ для великого ВМ? Новий хост-апарат має жорсткий диск розміром 1 Тб, тому він не може вмістити файл зображення 500 Гб dd і мати логічний об'єм 500 ГБ для копіювання та мати місце для хост-операційної системи та приміщення для інших менших гостей.

Я хотів би зробити щось на зразок:

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

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

Чи можливо це?


Відповіді:


24

Звичайно, звичайно це можливо.

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

Бум.

Зробіть собі прихильність і скористайтеся чимось більшим, ніж розмір за замовчуванням. Можливо, додайте bs = 4M (читати / писати шматками 4 Мб). Ви можете бачити, що в коментарях є певна думка про блокові розміри; якщо це щось, що ви робите досить часто, знайдіть трохи часу, щоб спробувати це кілька разів із різними розмірами, і переконаєтесь у тому, що дає вам найкращі швидкості передачі.

Відповідаючи на одне із запитань із коментарів:

Ви можете передавати передачу через pv, щоб отримати статистику про передачу. Це набагато приємніше, ніж вихід, який ви отримуєте від надсилання сигналів dd.

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


1
Чи впливає лише на швидкість копіювання, чи впливає це на збереження даних?
Нік

3
Це не впливає на спосіб зберігання даних, але це набагато ефективніше, ніж використання блочного розміру за замовчуванням (512 байт) для читання та запису.
larsks

3
@ Nick: В Linux ви можете надіслати сигнал ddпроцесу, USR1щоб він відображав рядок стану із перерахованою сумою. Отримайте номер вашого ddпроцесу з чимось подібним, ps aux | grep ddа потім використовуйте цей PID з командою kill -USR1 $PID. Повідомлення відображатиметься на початковому терміналі, з якого ви розпочали роботу dd.
Свен

3
Ви, мабуть, не хочете використовувати велику величину bs, оскільки вона просто заблокує запис у трубу до ssh, поки вона не зможе перенести більшу частину її в мережевий сокет, за цей час диск не працює. Оскільки розмір для читання за замовчуванням становить 128 к, ви, ймовірно, хочете дотримуватися цього. Або збільшити розмір читання диска на дисках.
psusi

1
@psusi: Посилання Zoredache, поставлене як коментар нижче питання, показало зворотне, вони отримали найшвидший результат із розмірами блоку 16M, але використовували netcat замість ssh як метод передачі, що завжди кращий варіант, коли шифрування не потрібно.
Sven

19

Ось оптимізована версія, яка показує прогрес використання 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'

2
Ви можете використовувати ssh -Cзамість цього gzip. Я не впевнений, чи є вплив на продуктивність, але введення тексту набагато менше.
Семюел Едвін Уорд

1
Я також пропоную використовувати замість gzip або pigz, або pxz -1, багатопотоковість дійсно допомагає на будь-якому сучасному сервері.
sCiphre

pvможе спричинити проблеми (на мій досвід перенесення більше 500 vps на інші сервери з цією системою) з кількістю байтів, і після цієї проблеми обсяги lvm несумісні. Переваги бачити прогрес роботи є нульовими та небезпечними. Якщо вам подобається, наприклад, відкрийте консоль aa з ifto, наприклад.
abkrim

4

Як щодо використання старого фрейнда для цього. 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 dd, цей файл та передає його в nc (netcat), який буде слухати цей порт. У приймальній системі netcat буде чекати 10 секунд, якщо він не отримає даних, перш ніж закрити [ip або ім'я] у [port], а потім передасть ці дані в dd, щоб виписати їх.


2
Netcat не використовує UDP з цими параметрами.
Семюель Едвін Уорд

3

Спочатку я б зробив знімок 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'

Я скористався процедурою, щоб скопіювати Vx-файл, який підтримує VM, до іншого хоста. Логічний об'єм містив кілька додаткових НН, які підтримував сам ВМ.


3

Спочатку переконайтеся, що логічний том не встановлений. Якщо це так, і ви хочете зробити "гарячу копію", спершу створіть знімок і скористайтеся цим: lvcreate --snapshot --name transfer_snap --size 1G

Мені потрібно передати багато даних (7 ТБ) між двома серверами, підключеними 1 Гбіт, тому мені потрібні були швидкі способи зробити це.

Чи варто використовувати SSH?

Використання ssh не викликає сумнівів, не через його шифрування (якщо у вас процесор із підтримкою AES-NI, це не зашкодить), а через мережеві буфери. Вони не масштабують добре. Існує виправлена ​​версія Ssh, яка вирішує цю проблему, але оскільки немає попередньо складених пакетів, це не дуже зручно.

Використання стиснення

При передачі зображень із необробленого диска завжди доцільно використовувати стиснення. Але ви не хочете, щоб компресія стала вузьким місцем. Більшість інструментів стиснення Unix, таких як gzip, є однопотоковими, тому якщо стиснення наситить один процесор, це буде вузьким місцем. З цієї причини я завжди використовую pigz, варіант gzip, який використовує всі ядра CPU для стиснення. І це необхідно для того, щоб ви хотіли піднятись до і вище швидкості 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, але тільки тому, що воно викрадає 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

і коли будете готові, почніть передачу на Джерело:

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 - це ключ шифрування, вам слід змінити його.


НІКОЛИ НЕ РОБИТИ ЦЕ НА ПРОГРАМНІЙ СЕРВЕРІ: apt встановити netcat-openbsd Встановлення netcat-openbsd повністю витерло ProxMox з сервера і спричинило 5+ годин простою та роботи !!!
Золтан

-1

Решта відповідей не спрацьовує і не відповідає вимогам запитання, оскільки це не створює логічний том на цільовому сервері, а натомість створює файл у / dev / mygroup / myvol на кореневому диску, який також призводить до того, що скопійований том не відображається на таких інструментах, як LV lvdisplay.

Я створив сценарій bash, який автоматизує весь процес: https://github.com/daniol/lvm-ssh-transfer

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.