ถ่ายโอนไฟล์ขนาดเล็ก 15TB


79

ฉันกำลังเก็บข้อมูลจากเซิร์ฟเวอร์เครื่องหนึ่งไปยังเซิร์ฟเวอร์อื่น ตอนแรกฉันเริ่มrsyncงาน ใช้เวลา 2 สัปดาห์ในการสร้างรายการไฟล์สำหรับข้อมูล 5 TB และอีกหนึ่งสัปดาห์เพื่อถ่ายโอนข้อมูล 1 TB

จากนั้นฉันก็ต้องฆ่างานเนื่องจากเราต้องการเวลาหยุดทำงานบนเซิร์ฟเวอร์ใหม่

มีการตกลงกันว่าเราจะเก็บไว้เพราะเราอาจไม่จำเป็นต้องเข้าถึงอีกครั้ง ฉันคิดว่าจะแบ่งมันเป็นชิ้น ๆ 500 GB หลังจากที่ผมแล้วผมจะคัดลอกมันข้ามผ่านtar sshผมใช้tarและpigzแต่ก็ยังคงช้าเกินไป

มีวิธีที่ดีกว่าที่จะทำหรือไม่ ฉันคิดว่าเซิร์ฟเวอร์ทั้งสองอยู่ใน Redhat เซิร์ฟเวอร์เก่าคือ Ext4 และเซิร์ฟเวอร์ใหม่คือ XFS

ขนาดไฟล์มีตั้งแต่ไม่กี่ kb ถึงไม่กี่ mb และมี 24 ล้าน jpegs ใน 5TB ดังนั้นฉันคาดเดาประมาณ 60-80 ล้านสำหรับ 15TB

แก้ไข: หลังจากเล่นกับ rsync, nc, tar, mbuffer และ pigz สองสามวัน คอขวดจะเป็นดิสก์ IO ในขณะที่ข้อมูลถูกสไทรพ์กับดิสก์ SAS 500 ตัวและประมาณ 250 ล้าน jpegs อย่างไรก็ตามตอนนี้ฉันเรียนรู้เกี่ยวกับเครื่องมือดีๆเหล่านี้ที่ฉันสามารถใช้ได้ในอนาคต


1
เป็นไปได้ซ้ำซ้อนกับlinux to linux, โอน 10TB?
D34DM347

2
ทางเลือกหนึ่งคือการสร้างไฟล์ tar บีบอัดบนไดรฟ์ภายนอกและย้ายไปยังระบบใหม่ ดิสก์เสริมจะเพิ่มความเร็วในการสร้างไฟล์ tar (จะไม่ถูกเขียนลงดิสก์ที่มีอยู่ในระบบอาจเป็นไปได้ในขณะที่พยายามอ่าน 15TB จากพวกเขา) และไม่ผูกเซิร์ฟเวอร์ใหม่
Brian

4
มีวิธีที่ดีกว่าที่จะทำหรือไม่ - ใช่, Windows Server 2012 R2 การจำลองแบบ DFS จะเตรียมความพร้อมว่าในประมาณ 10 ชั่วโมง และมันจะซิงค์การเปลี่ยนแปลงและรับที่มันทิ้งไว้หลังจากรีบูต
TessellatingHeckler

27
@TessellatingHeckler: ดังนั้นคุณแนะนำให้โยกย้าย OP จาก Redhat ไปยัง Windows ก่อนเก็บถาวรหรือไม่
Thomas Weller

12
@ThomasWeller พวกเขาถามว่า "มีวิธีที่ดีกว่านี้ไหม" และมี ฉันไม่แนะนำเลยว่าพวกเขาใช้วิธีที่ดีกว่า พวกเขามีอิสระที่จะใช้คำสั่งในไพพ์ซึ่งไม่สามารถกู้คืนจากการขัดจังหวะไม่ตรวจสอบเนื้อหาของไฟล์ไม่สามารถรายงานสถานะการคัดลอกไม่สามารถใช้บล็อกที่คัดลอกไว้ก่อนหน้านี้เพื่อหลีกเลี่ยงการคัดลอกส่วนของไฟล์ สนับสนุนการคัดลอกที่มีลำดับความสำคัญต่ำไม่สามารถหยุดชั่วคราวไม่ต้องพูดถึงการคัดลอก ACL และต้องการให้ใครบางคนเข้าสู่ระบบเพื่อเรียกใช้ อย่างไรก็ตามใครก็ตามที่ติดตามอาจสนใจ - หรือขอให้บอกว่า "x ทำเช่นนั้นบน Linux"
TessellatingHeckler

คำตอบ:


64

ฉันได้มีผลดีมากในการใช้tar, pigz(gzip ขนาน) ncและ

เครื่องที่มา:

tar -cf - -C /path/of/small/files . | pigz | nc -l 9876

เครื่องปลายทาง:

วิธีแยก:

nc source_machine_ip 9876 | pigz -d | tar -xf - -C /put/stuff/here

หากต้องการเก็บถาวร:

nc source_machine_ip 9876 > smallstuff.tar.gz

หากคุณต้องการที่จะเห็นอัตราการถ่ายโอนเพียงท่อผ่านpvหลังจากpigz -d!


3
FYI คุณสามารถแทนที่pigzด้วยgzipหรือลบออกโดยสิ้นเชิง แต่ความเร็วจะช้าลงอย่างมาก
h0tw1r3

10
วิธีนี้สามารถรับการยอมรับหาก OP ได้พยายามแล้วtarและpigz? ฉันไม่เข้าใจ ...
โธมัสเวลเลอร์

5
@ThomasWeller คุณได้รับสิ่งที่เขาพยายามpigzหรือไม่ จากคำถามดูเหมือนว่าเขาจะพยายามมาrsyncถึงตอนนี้เท่านั้นและกำลังพิจารณาที่tarจะใช้เพื่อแยกและรวมข้อมูล โดยเฉพาะอย่างยิ่งถ้าเขาไม่ได้ใช้-z/ --compressตัวเลือกใน rsync ในpigzทางทฤษฎีสามารถช่วยได้อย่างมีนัยสำคัญ
Doktor J

1
@ThomasWeller ใช่แล้วฉันได้ลองใช้ tar และ pigz แล้ว แต่ไม่ใช่ nc ฉันใช้ ssh ดังนั้นมันจึงเพิ่มค่าใช้จ่ายให้มากขึ้น
lbanz

2
@lbanz ซึ่งก็หมายความtarว่าไม่ได้ให้ข้อมูลที่รวดเร็วเพียงพอสำหรับpigzการใช้งาน CPU ในการบีบอัด การอ่านไฟล์ขนาดเล็กจำนวนมากเกี่ยวข้องกับ syscalls อีกมากมายการค้นหาดิสก์จำนวนมากและเคอร์เนลค่าใช้จ่ายมากกว่าการอ่านไฟล์ขนาดใหญ่จำนวนไบต์เดียวกันและดูเหมือนว่าคุณกำลังติดขัดในระดับพื้นฐาน
ฮอบส์

21

ฉันจะใช้วิธีแก้ปัญหา rsync Modern (3.0.0+) rsync ใช้รายการไฟล์ที่เพิ่มขึ้นดังนั้นจึงไม่จำเป็นต้องสร้างรายชื่อแบบเต็มก่อนการถ่ายโอน ดังนั้นการรีสตาร์ทจึงไม่จำเป็นต้องให้คุณทำการถ่ายโอนทั้งหมดอีกครั้งในกรณีที่เกิดปัญหา การแยกการถ่ายโอนต่อไดเรกทอรีระดับบนสุดหรือที่สองจะปรับให้เหมาะสมยิ่งขึ้น (ฉันจะใช้rsync -a -Pและเพิ่ม--compressหากเครือข่ายของคุณช้ากว่าไดรฟ์ของคุณ)


ฉันใช้ rsync 2.6.8 บนเซิร์ฟเวอร์เก่า เนื่องจากเป็นหนึ่งในกล่องเหล่านั้นที่เราไม่ได้รับอนุญาตให้ติดตั้ง / อัปเดตสิ่งใด ๆ ตามที่ผู้ขายระบุหรือทำให้การรับประกันเป็นโมฆะ ฉันอาจอัปเดตและดูว่ามันเร็วกว่านี้หรือไม่
lbanz

18
ค้นหา (หรือสร้าง) ไบนารีที่เชื่อมโยงแบบคงที่ rsync และเพียงแค่เรียกใช้จากบ้านของคุณ หวังว่าจะไม่ทำลายไม่มีการรับประกัน
Fox

แล้วไงunisonล่ะ เปรียบเทียบได้rsyncอย่างไร?
Gwyneth Llewelyn

15

ตั้งค่า VPN (หากอินเทอร์เน็ต) สร้างไดรฟ์เสมือนจริงบางรูปแบบบนเซิร์ฟเวอร์ระยะไกล (ทำให้เป็น ext4) ติดตั้งบนเซิร์ฟเวอร์ระยะไกลแล้วเชื่อมต่อกับเซิร์ฟเวอร์ท้องถิ่น (โดยใช้โปรโตคอลระดับบล็อกเช่น iSCSI ) และใช้ dd หรือเครื่องมือระดับบล็อกอื่นเพื่อทำการถ่ายโอน จากนั้นคุณสามารถคัดลอกไฟล์จากไดรฟ์เสมือนไปยังไดรฟ์จริง (XFS) ได้ตามต้องการ

เหตุผลสองประการ:

  1. ไม่มีค่าใช้จ่ายระบบไฟล์ซึ่งเป็นตัวการประสิทธิภาพหลัก
  2. ไม่มีการค้นหาคุณกำลังดูการอ่าน / เขียนตามลำดับทั้งสองด้าน

3
การข้ามระบบไฟล์นั้นดี การคัดลอกระดับบล็อกของระบบไฟล์ที่เมาท์เพื่ออ่าน - เขียนเป็นความคิดที่แย่จริงๆ ถอนติดตั้งหรือเมานต์อ่านอย่างเดียวก่อน
JB

การมีสำเนา 15TB ก็เหมือนกัน หมายความว่าเซิร์ฟเวอร์ใหม่ต้องการขั้นต่ำ 30
Arthur Kay

3
หากเซิร์ฟเวอร์ใช้ LVM ผู้ใช้หนึ่งคนสามารถทำสแน็ปช็อตแบบอ่านอย่างเดียวของระบบไฟล์และคัดลอกมาแทน Space overhead สำหรับการเปลี่ยนแปลงในระบบไฟล์ที่เกิดขึ้นในขณะที่อ่าน snapshot
liori

9

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


2
มันเกี่ยวกับ 1PB ของไดรฟ์ 2TB ดังนั้นมันจึงมากเกินไป
lbanz

3

ใช้ mbuffer และหากอยู่ในเครือข่ายที่ปลอดภัยคุณสามารถหลีกเลี่ยงขั้นตอนการเข้ารหัสได้


3

(คำตอบที่แตกต่างกันสามารถทำงานได้นี่เป็นอีกคำตอบ)

สร้างรายชื่อไฟล์ที่มีfind -type f(นี้ควรทำให้เสร็จในสองสามชั่วโมง) แยกมันจะชิ้นเล็ก ๆ rsync --files-from=...และการถ่ายโอนแต่ละก้อนใช้


3

คุณเคยลองแอบดูบ้างไหม? ด้วยวิธีนี้ฉันหมายถึงการถ่ายโอนทุกอย่างไปยังไดรฟ์เดียวกันจากนั้นก็เคลื่อนย้ายไดรฟ์นั้นไป

ประมาณหนึ่งเดือนที่ผ่านมาซัมซุงได้เปิดตัวไดรฟ์ 16 TB (โดยทางเทคนิคคือ 15.36 TB) ซึ่งเป็น SSD: http://www.theverge.com/2015/8/14/9153083/samsung-worlds-largest-hard -drive-16TB

ฉันคิดว่าไดรฟ์นี้จะทำเพื่อสิ่งนี้ คุณยังคงต้องคัดลอกไฟล์ทั้งหมด แต่เนื่องจากคุณไม่มีความหน่วงแฝงของเครือข่ายและอาจใช้ SATA หรือเทคนิคที่รวดเร็วเหมือนกันดังนั้นจึงควรเร็วขึ้นมาก


2

หากมีโอกาสที่จะได้รับอัตราส่วนความสำเร็จสูงเมื่อหักข้อมูลซ้ำซ้อนฉันจะใช้บางอย่างเช่นborgbackupหรือ Attic

หากไม่ตรวจสอบโซลูชันnetcat + tar + pbzip2ปรับตัวเลือกการบีบอัดตามฮาร์ดแวร์ของคุณ - ตรวจสอบคอขวด (CPU? เครือข่าย? IO?) pbzip2 จะครอบคลุมอย่างทั่วถึงในซีพียูทั้งหมดซึ่งให้ประสิทธิภาพที่ดีกว่า


lzma ( xz) คลายการบีบอัดเร็วกว่า bzip2 และทำงานได้ดีกับอินพุตส่วนใหญ่ น่าเสียดายที่xzตัวเลือกมัลติเธรดยังไม่ได้ใช้งาน
Peter Cordes

โดยปกติแล้วขั้นตอนการบีบอัดต้องการแรงม้ามากกว่าการบีบอัดดังนั้นหาก CPU เป็นปัจจัย จำกัด pbzip2 จะส่งผลให้ประสิทธิภาพโดยรวมดีขึ้น การบีบอัดไม่ควรส่งผลกระทบต่อกระบวนการหากทั้งสองเครื่องเหมือนกัน
neutrinus

ใช่จุดของฉันคือมันเป็นความอัปยศที่ไม่มีกระแสเดียวแบบหลายเธรด lzma แม้ว่าสำหรับกรณีนี้การถ่ายโอนระบบไฟล์ทั้งหมดของข้อมูลpigzจะเป็นปัญหา เป็นคอมเพรสเซอร์ที่ช้าที่สุดที่คุณต้องการใช้ lz4หรือแม้กระทั่ง (มีเป็นlz4mtแบบมัลติเธรดสำหรับ-a-เดียวสตรีมที่มีอยู่มันไม่ด้ายอย่างมีประสิทธิภาพ (spawns กระทู้ใหม่ได้บ่อยมาก) แต่ก็ไม่ได้รับการเพิ่มความเร็วของแข็ง.)
ปีเตอร์ Cordes

2

คุณกำลังใช้ RedHat Linux ดังนั้นสิ่งนี้จะไม่ใช้ แต่เป็นตัวเลือกอื่น:

ฉันประสบความสำเร็จอย่างมากในการใช้ ZFS เพื่อเก็บไฟล์หลายล้านไฟล์เนื่องจาก inodes ไม่ใช่ปัญหา

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

ZFS เป็นระบบไฟล์ Solaris เป็นหลัก แต่สามารถพบได้ใน illumos (โอเพ่นซอร์ส fork ของ OpenSolaris ของ Sun) ฉันรู้ว่ายังมีโชคที่ใช้ ZFS ภายใต้ BSD และ Linux (ใช้ FUSE?) - แต่ฉันไม่มีประสบการณ์ในการลอง


3
มีพอร์ต Linux ดั้งเดิมที่ไม่ใช่ FUSE ของ ZFS มาพักหนึ่งแล้ว: zfsonlinux.org
EEAA

1

สตาร์ทrsyncdaemon บนเครื่องเป้าหมาย นี่จะเร่งกระบวนการถ่ายโอนให้เร็วขึ้นมาก


-1

คุณสามารถทำได้ด้วยแค่ tar และ ssh แบบนี้:

tar zcf - <your files> | ssh <destination host> "cat > <your_file>.tar.gz"

หรือถ้าคุณต้องการเก็บไฟล์แต่ละไฟล์:

tar zcf - <your files> | ssh <destination host> "tar zxf -"


1
มันจะไม่ซ้ำซ้อนไม่มีวิธีการดำเนินการบีบอัดโดยใช้เพียงหนึ่ง CPU
neutrinus
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.