การย้ายโลจิคัลวอลุ่มโดยตรงจากเซิร์ฟเวอร์หนึ่งไปยังเซิร์ฟเวอร์อื่นผ่านเครือข่าย


13

ฉันมีเครื่องโฮสต์ KVM ที่มี VMs หลายตัว แต่ละ VM ใช้ Logical Volume บนโฮสต์ ฉันต้องการคัดลอก LVs ไปยังเครื่องโฮสต์อื่น

โดยปกติฉันจะใช้สิ่งที่ชอบ:

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

ในการแปลงค่า LV ให้เป็นไฟล์ภาพและใช้ SCP เพื่อย้าย จากนั้นใช้ DD เพื่อคัดลอกไฟล์กลับไปที่ LV ใหม่บนโฮสต์ใหม่

ปัญหาของวิธีนี้คือคุณต้องการพื้นที่ว่างดิสก์มากกว่าสองเท่าตามที่ VM ใช้กับทั้งสองเครื่อง กล่าวคือ 5GB LV ใช้พื้นที่ 5GB สำหรับ LV และสำเนา dd ยังใช้พื้นที่ 5GB เพิ่มเติมสำหรับภาพ นี่เป็นเรื่องปกติสำหรับ LVs ขนาดเล็ก แต่ถ้าหาก (เช่นกรณีของคุณ) คุณมี 500GB LV สำหรับ VM ขนาดใหญ่ เครื่องโฮสต์ใหม่มีฮาร์ดไดรฟ์ 1TB ดังนั้นจึงไม่สามารถเก็บไฟล์ภาพขนาด 500GB dd และมีโลจิคัลวอลุ่ม 500GB เพื่อคัดลอกและมีพื้นที่สำหรับโฮสต์ระบบปฏิบัติการและห้องสำหรับแขกที่มีขนาดเล็กกว่า

สิ่งที่ฉันต้องการทำคือ:

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 MB) คุณสามารถเห็นมี nitpicking เกี่ยวกับ blockizes ในความคิดเห็น; หากนี่คือสิ่งที่คุณพบว่าตัวเองทำค่อนข้างบ่อยลองใช้เวลาสักครู่เพื่อลองหลาย ๆ ครั้งด้วยบล็อคขนาดต่างๆและดูด้วยตัวคุณเองว่าอะไรคือสิ่งที่ทำให้คุณได้รับอัตราการถ่ายโอนที่ดีที่สุด

ตอบคำถามหนึ่งข้อจากความคิดเห็น:

คุณสามารถไพพ์การถ่ายโอนผ่านpvเพื่อรับสถิติเกี่ยวกับการถ่ายโอน ddมันเป็นดีกว่ามากกว่าการส่งออกที่คุณได้รับจากการส่งสัญญาณไปยัง

ฉันจะบอกว่าในขณะที่แน่นอนว่าการใช้เน็ตแคท - หรืออะไรก็ตามที่ไม่ได้กำหนดค่าใช้จ่ายในการเข้ารหัส - จะมีประสิทธิภาพมากขึ้นฉันมักจะพบว่าความเร็วที่เพิ่มขึ้นนั้นทำให้เสียความสะดวกสบาย ถ้าฉันไม่ย้ายชุดข้อมูลที่มีขนาดใหญ่มากฉันมักจะยึดติดกับ ssh แม้จะมีค่าใช้จ่ายเพราะในกรณีส่วนใหญ่ทุกอย่างถูกตั้งค่าเป็น Just Work แล้ว


1
bs มีผลกับความเร็วในการคัดลอกเท่านั้นหรือมีผลต่อวิธีการจัดเก็บข้อมูล?
นิค

3
ไม่มีผลกระทบต่อวิธีการจัดเก็บข้อมูล แต่มีประสิทธิภาพมากกว่าการใช้ขนาดเริ่มต้นบล็อก (จาก 512 ไบต์) สำหรับการอ่านและการเขียน
larsks

3
@ Nick: บน Linux คุณสามารถส่งddกระบวนการUSR1สัญญาณที่จะทำให้มันแสดงบรรทัดสถานะที่มีจำนวนเงินที่โอน ได้รับหมายเลขกระบวนการที่คุณddกระบวนการกับสิ่งที่ต้องการps aux | grep ddแล้วใช้ PID kill -USR1 $PIDนี้กับคำสั่ง ddข้อความที่จะปรากฏบนขั้วเดิมที่คุณเริ่มต้น
สเวน

3
คุณอาจไม่ต้องการใช้ bs ที่มีขนาดใหญ่เนื่องจากมันจะบล็อกการเขียนไปยังไปป์ที่ ssh จนกว่ามันจะสามารถถ่ายโอนส่วนใหญ่ไปยังซ็อกเก็ตเครือข่ายในช่วงเวลาที่ดิสก์จะไม่ทำงาน เนื่องจากขนาด readahead ที่เป็นค่าเริ่มต้นคือ 128k คุณอาจต้องการติดกับสิ่งนั้น หรือเพิ่มขนาดหัวอ่านดิสก์
psusi

1
@psusi: ลิงค์ Zoredache ใส่ความคิดเห็นด้านล่างคำถามแสดงให้เห็นตรงข้ามพวกเขาได้ผลลัพธ์ที่เร็วที่สุดด้วยขนาดบล็อก 16M แต่ใช้ netcat แทน ssh เป็นวิธีการโอนซึ่งเป็นตัวเลือกที่ดีกว่าเมื่อไม่จำเป็นต้องเข้ารหัส
สเวน

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
ฉันยังแนะนำให้ใช้อย่างใดอย่างหนึ่งหรือ pigz pxz -1 แทน gzip ที่ multithreading จริงๆช่วยบนเซิร์ฟเวอร์ใด ๆ ที่ทันสมัย
sCiphre

pvอาจทำให้เกิดปัญหา (ใน exprience ของฉันย้ายมากกว่า 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 หรือชื่อ] บน [พอร์ต] จากนั้นไพพ์ข้อมูลไปยัง dd เพื่อเขียนออกมา


2
Netcat ไม่ได้ใช้ UDP กับตัวเลือกเหล่านี้
ซามูเอลเอ็ดวินวอร์ด

3

ก่อนอื่นฉันจะถ่ายรูปของ lv:

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

หลังจากนั้นคุณต้องสร้าง lv ใหม่บนโฮสต์ใหม่ (เช่นใช้ lvcreate) ที่มีขนาดเท่ากัน จากนั้นคุณสามารถคัดลอกข้อมูลไปยังโฮสต์ใหม่ได้โดยตรง นี่คือตัวอย่างของคำสั่ง copy ของฉัน:

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

ฉันใช้โพรซีเดอร์เพื่อคัดลอก proxmox pve ที่บำรุงรักษา VM ไปยังโฮสต์อื่น โลจิคัลวอลุ่มมี LVs เพิ่มเติมหลายอย่างที่ดูแลโดย VM เอง


3

ก่อนอื่นตรวจสอบให้แน่ใจว่าไม่ได้ติดตั้งโลจิคัลวอลุ่มไว้ ถ้าเป็นและคุณต้องการสร้าง "สำเนาร้อน" ให้สร้างสแนปชอตก่อนและใช้สิ่งนี้แทน: lvcreate --snapshot --name transfer_snap --size 1G

ฉันต้องถ่ายโอนข้อมูลจำนวนมาก (7TB) ระหว่างสองเซิร์ฟเวอร์ที่เชื่อมต่อกับ 1Gbit ดังนั้นฉันจึงต้องการวิธีที่รวดเร็วที่สุดเท่าที่จะทำได้

คุณควรใช้ SSH

การใช้ ssh นั้นไม่ได้เกิดจากการเข้ารหัสของมัน (ถ้าคุณมีซีพียูที่รองรับ AES-NI มันก็ไม่ได้ทำร้ายอะไรมากมาย) แต่เป็นเพราะบัฟเฟอร์ของเครือข่าย สิ่งเหล่านี้ไม่ได้ปรับขนาดได้ดี มีเวอร์ชั่น Sshที่ได้รับการแก้ไขซึ่งแก้ไขปัญหานี้ แต่เนื่องจากไม่มีแพ็คเกจที่คอมไพล์แล้วจึงไม่สะดวก

ใช้การบีบอัด

เมื่อทำการถ่ายโอนอิมเมจดิสก์แบบดิบขอแนะนำให้ใช้การบีบอัดเสมอ แต่คุณไม่ต้องการให้การบีบอัดกลายเป็นคอขวด เครื่องมือบีบอัดยูนิกซ์ส่วนใหญ่เช่น gzip เป็นเธรดเดี่ยวดังนั้นหากการบีบอัดอิ่มตัวหนึ่ง CPU มันจะเป็นคอขวด ด้วยเหตุนี้ฉันจึงใช้ pigz ซึ่งเป็นตัวแปร gzip ที่ใช้แกนประมวลผล CPU ทั้งหมดสำหรับการบีบอัดเสมอ และนี่เป็นสิ่งที่จำเป็นสำหรับคุณที่ต้องการความเร็วสูงสุดและสูงกว่า GBit

ใช้การเข้ารหัส

ดังที่ได้กล่าวไว้ก่อนหน้านี้ ssh ช้า หากคุณมี CPU AES-NI สิ่งนี้ไม่ควรเป็นปัญหาคอขวด ดังนั้นแทนที่จะใช้ ssh เราสามารถใช้ openssl โดยตรง

ความเร็ว

เพื่อให้คุณทราบถึงผลกระทบของความเร็วของส่วนประกอบนี่คือผลลัพธ์ของฉัน สิ่งเหล่านี้คือความเร็วในการถ่ายโอนระหว่างสองระบบการผลิตที่อ่านและเขียนไปยังหน่วยความจำ ผลลัพธ์ที่แท้จริงของคุณขึ้นอยู่กับความเร็วของเครือข่ายความเร็วของ HDD และความเร็วของ CPU ที่มา! ฉันกำลังทำสิ่งนี้เพื่อแสดงให้เห็นว่าอย่างน้อยก็ไม่มีการลดลงของประสิทธิภาพอย่างมาก 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 สรุป: การใช้การบีบอัดจะช่วยเพิ่มความเร็วอย่างเห็นได้ชัดเนื่องจากช่วยลดขนาดข้อมูลลงได้มาก สิ่งนี้สำคัญกว่าหากคุณมีความเร็วเครือข่ายที่ช้าลง เมื่อใช้การบีบอัดดูการใช้งาน cpu ของคุณ หากการใช้งานได้รับการ maxed out คุณสามารถลองโดยไม่ใช้มัน การใช้การบีบอัดเป็นเพียงผลกระทบเล็กน้อยต่อระบบ AES-NI เพียงเท่านั้นเพราะจะขโมยซีพียู 30-40% จากการบีบอัด

การใช้งาน Screen

หากคุณกำลังถ่ายโอนข้อมูลจำนวนมากเช่นฉันคุณไม่ต้องการให้มันถูกขัดจังหวะโดยการตัดการเชื่อมต่อเครือข่ายของลูกค้า 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 เป็นคีย์เข้ารหัสคุณควรเปลี่ยนรหัส


อย่าทำอย่างนี้กับเซิร์ฟเวอร์ PROXMOX: ติดตั้ง netcat-openbsd การติดตั้ง netcat-openbsd เช็ด ProxMox จากเซิร์ฟเวอร์อย่างสมบูรณ์และทำให้หยุดทำงาน 5 ชั่วโมงขึ้นไป !!!
Zoltan
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.