Memindahkan Volume Logical langsung dari satu server ke yang lain melalui jaringan?


13

Saya memiliki mesin host KVM dengan beberapa VM di atasnya. Setiap VM menggunakan Volume Logis pada host. Saya perlu menyalin LV ke mesin host lain.

Biasanya, saya akan menggunakan sesuatu seperti:

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

Untuk mengubah LV menjadi file gambar dan gunakan SCP untuk memindahkannya. Kemudian gunakan DD untuk menyalin file kembali ke LV baru di host baru.

Masalah dengan metode ini adalah Anda membutuhkan ruang disk dua kali lebih banyak dibandingkan VM yang digunakan pada kedua mesin. yaitu. 5GB LV menggunakan 5GB ruang untuk LV dan salinan dd juga menggunakan tambahan 5GB ruang untuk gambar. Ini bagus untuk LV kecil, tetapi bagaimana jika (seperti kasus saya) Anda memiliki LV 500GB untuk VM besar? Mesin host baru memiliki hard drive 1TB, sehingga tidak dapat menyimpan file gambar 500GB dd dan memiliki volume logis 500GB untuk menyalin ke dan memiliki ruang untuk OS host dan ruang untuk tamu kecil lainnya.

Yang ingin saya lakukan adalah sesuatu seperti:

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

Dengan kata lain, salin data secara langsung dari satu volume logis ke volume lainnya melalui jaringan dan lewati file gambar perantara.

Apakah ini mungkin?


Jawaban:


24

Tentu, tentu saja itu mungkin.

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

Ledakan.

Tolong, bantulah diri Anda sendiri, dan gunakan sesuatu yang lebih besar dari ukuran default. Mungkin tambahkan bs = 4M (baca / tulis dalam potongan 4 MB). Anda dapat melihat ada beberapa nitpicking tentang pemblokiran di komentar; jika ini adalah sesuatu yang sering Anda lakukan sendiri, luangkan sedikit waktu untuk mencobanya beberapa kali dengan pemblokiran berbeda dan lihat sendiri apa yang membuat Anda mendapatkan harga transfer terbaik.

Menjawab salah satu pertanyaan dari komentar:

Anda dapat menyalurkan transfer melalui pv untuk mendapatkan statistik tentang transfer. Ini jauh lebih bagus daripada output yang Anda dapatkan dari pengiriman sinyal dd.

Saya juga akan mengatakan bahwa walaupun tentu saja menggunakan netcat - atau apa pun yang tidak memaksakan overhead enkripsi - akan menjadi lebih efisien, saya biasanya menemukan bahwa kecepatan tambahan datang pada beberapa kehilangan kenyamanan. Kecuali saya bergerak di sekitar dataset yang sangat besar, saya biasanya tetap dengan ssh meskipun overhead karena dalam banyak kasus semuanya sudah diatur untuk Just Work.


1
Apakah bs hanya memengaruhi kecepatan penyalinan, atau apakah itu berpengaruh pada bagaimana data disimpan?
Nick

3
Ini tidak berpengaruh pada bagaimana data disimpan, tetapi jauh lebih efisien daripada menggunakan ukuran default blok (dari 512 byte) untuk membaca dan menulis.
larsks

3
@Nick: Di Linux, Anda dapat mengirim sinyal ddproses USR1untuk membuatnya menampilkan garis status dengan jumlah yang ditransfer. Dapatkan nomor proses dari ddproses Anda dengan sesuatu seperti ps aux | grep dddan kemudian gunakan PID ini dengan perintah kill -USR1 $PID. Pesan akan ditampilkan di terminal asli tempat Anda memulai dd.
Sven

3
Anda mungkin tidak ingin menggunakan bs yang besar karena itu hanya akan memblokir penulisan ke pipa untuk ssh sampai dapat mentransfer sebagian besar ke soket jaringan, selama waktu disk akan diam. Karena ukuran readahead default adalah 128k, Anda mungkin ingin tetap menggunakannya. Atau menambah ukuran readahead disk.
psusi

1
@psusi: Tautan yang diberikan Zoredache sebagai komentar di bawah pertanyaan menunjukkan sebaliknya, mereka mendapatkan hasil tercepat dengan ukuran blok 16M, tetapi menggunakan netcat daripada ssh sebagai metode transfer, yang selalu merupakan opsi yang lebih baik ketika enkripsi tidak diperlukan.
Sven

18

Berikut adalah versi yang dioptimalkan, yang menunjukkan kemajuan menggunakan pvdan menggunakan BS untuk potongan yang lebih besar dan juga digunakan gzipuntuk mengurangi lalu lintas jaringan.

Itu sempurna ketika memindahkan data antara koneksi yang lambat seperti server internet. Saya merekomendasikan untuk menjalankan perintah di dalam layar atau sesi tmux. Dengan begitu koneksi ssh ke host dari tempat Anda menjalankan perintah dapat terputus tanpa masalah.

$ 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
Anda bisa menggunakan ssh -Cbukan gzip. Saya tidak yakin apakah ada dampak kinerja, tetapi mengetik jauh lebih sedikit.
Samuel Edwin Ward

1
Saya juga menyarankan menggunakan pigz atau pxz -1 alih-alih gzip, multithreading sangat membantu pada server modern mana pun.
sCiphre

pvdapat menyebabkan masalah (berdasarkan pengalaman saya memindahkan lebih dari 500 vps ke server lain dengan sistem ini) dengan jumlah byte, dan setelah masalah ini, volume lvm tidak konsisten. Manfaat melihat kemajuan pekerjaan adalah null dan dangeorus. Jika Anda suka melihat progres buka aa konsol dengan ifto misalnya.
abkrim

4

Bagaimana kalau menggunakan teman lama untuk melakukan ini. NetCat.

Pada sistem yang kehilangan tipe volume logis

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

Kemudian pada sistem penerima. Tipe

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

Menerjemahkan, kotak orgin dd file ini dan pipa ke nc (netcat) yang akan mendengarkan port ini. Pada sistem penerima, netcat akan menunggu 10 detik jika tidak ada data sebelum ditutup ke [ip atau nama] pada [port] kemudian pipa data itu ke dd untuk menuliskannya.


2
Netcat tidak menggunakan UDP dengan opsi ini.
Samuel Edwin Ward

3

Pertama saya akan mengambil snapshot dari lv:

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

Setelah itu Anda harus membuat lv baru pada host baru (mis. Menggunakan lvcreate) dengan ukuran yang sama. Kemudian Anda bisa langsung menyalin data ke host baru. Ini adalah contoh saya dari perintah salin:

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

Saya menggunakan prosedur untuk menyalin VM proxmox pve dipertahankan ke host lain. Volume logis berisi beberapa LV tambahan yang dikelola oleh VM itu sendiri.


2

Pertama pastikan bahwa volume logis tidak di-mount. Jika ya dan Anda ingin membuat "salinan panas", buat snapshot terlebih dahulu dan gunakan ini sebagai gantinya: lvcreate --snapshot --name transfer_snap --size 1G

Saya harus mentransfer banyak data (7TB) antara dua Server yang terhubung 1Gbit, jadi saya perlu cara tercepat untuk melakukannya.

Haruskah Anda menggunakan SSH?

Menggunakan ssh tidak perlu dipertanyakan, bukan karena enkripsi (jika Anda memiliki CPU dengan dukungan AES-NI, itu tidak terlalu menyakitkan) tetapi karena buffer jaringannya. Itu tidak scaling dengan baik. Ada versi Ssh yang ditambal yang mengatasi masalah ini, tetapi karena tidak ada paket yang telah dikompilasi, itu tidak terlalu nyaman.

Menggunakan Kompresi

Saat mentransfer gambar disk mentah, selalu disarankan untuk menggunakan kompresi. Tetapi Anda tidak ingin kompresi menjadi hambatan. Kebanyakan alat kompresi unix seperti gzip adalah single-threaded, jadi jika kompresi memenuhi satu CPU, itu akan menjadi hambatan. Untuk alasan itu, saya selalu menggunakan pigz, varian gzip yang menggunakan semua core CPU untuk kompresi. Dan ini perlu Anda ingin naik ke dan di atas kecepatan GBit.

Menggunakan Enkripsi

Seperti yang dikatakan sebelumnya, ssh lambat. Jika Anda memiliki CPU AES-NI, ini seharusnya tidak menjadi hambatan. Jadi alih-alih menggunakan ssh, kita dapat menggunakan openssl secara langsung.

Kecepatan

Untuk memberi Anda Ide tentang dampak kecepatan komponen, berikut adalah hasil saya. Itu adalah kecepatan transfer antara dua sistem produksi membaca dan menulis ke memori. Hasil aktual Anda bergantung pada kecepatan jaringan, kecepatan HDD, dan kecepatan CPU sumber! Saya melakukan ini untuk menunjukkan bahwa setidaknya tidak ada penurunan kinerja yang besar. 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 Kesimpulan: menggunakan kompresi memberikan peningkatan yang nyata, karena mengurangi ukuran data banyak. Ini bahkan lebih penting jika Anda memiliki kecepatan jaringan yang lebih lambat. Saat menggunakan kompresi, perhatikan penggunaan cpu Anda. jika penggunaannya sudah maksimal, Anda dapat mencoba tanpanya. Menggunakan kompresi sebagai dampak kecil pada sistem AES-NI, hanya karena ia mencuri 30-40% cpu dari kompresi.

Menggunakan Layar

Jika Anda mentransfer banyak data seperti saya, Anda tidak ingin terganggu oleh pemutusan jaringan klien ssh Anda, jadi sebaiknya mulai dengan layar di kedua sisi. Ini hanya sebuah catatan, saya tidak akan menulis tutorial layar di sini.

Ayo Salin

Instal beberapa dependensi (pada sumber dan tujuan): apt install pigz pv netcat-openbsd

lalu buat volume pada tujuan dengan ukuran yang sama dengan sumbernya. Jika tidak yakin, gunakan lvdisplay pada sumber untuk mendapatkan ukuran dan buat target yaitu: lvcreate -n lvname vgname -L 50G

selanjutnya, siapkan tujuan untuk menerima data:

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

dan ketika siap, mulai transfer pada Sumber:

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

Catatan: Jika Anda mentransfer data secara lokal atau tidak peduli tentang enkripsi, cukup hapus bagian openssl dari kedua sisi. Jika Anda peduli, asdkjn2hb adalah kunci Enkripsi, Anda harus mengubahnya.


JANGAN PERNAH MELAKUKANNYA PADA SERVER PROXMOX ini: apt install netcat-openbsd Menginstal netcat-openbsd sepenuhnya menghapus ProxMox dari server dan menyebabkan 5+ jam downtime dan bekerja !!!
Zoltan
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.