คัดลอกไฟล์ขนาดใหญ่จากเซิร์ฟเวอร์ Linux หนึ่งไปยังอีกเซิร์ฟเวอร์หนึ่ง

ฉันพยายามที่จะคัดลอก 75 กิกะไบต์ tgz (mysql lvm snapshot) จากเซิร์ฟเวอร์ Linux ในศูนย์ข้อมูล LA ของเราไปยังเซิร์ฟเวอร์ Linux อีกแห่งในศูนย์ข้อมูล NY ของเราผ่านลิงก์ขนาด 10MB

ฉันได้รับประมาณ 20-30Kb / s ด้วย rsync หรือ scp ซึ่งมีความผันผวนระหว่าง 200-300 ชั่วโมง

ในขณะนี้มันเป็นลิงค์ที่ค่อนข้างเงียบเนื่องจากศูนย์ข้อมูลที่สองยังไม่เปิดใช้งานและฉันได้รับความเร็วที่ยอดเยี่ยมจากการถ่ายโอนไฟล์ขนาดเล็ก

ฉันได้ทำตามคำแนะนำการปรับแต่ง tcp ต่าง ๆ ที่ฉันพบผ่านทาง google เพื่อประโยชน์ (บางทีฉันกำลังอ่านคำแนะนำที่ไม่ถูกต้องได้รับที่ดี?)

ฉันเห็นเคล็ดลับช่องสัญญาณ tar + netcat แต่ความเข้าใจของฉันคือมันดีสำหรับไฟล์ขนาดเล็กจำนวนมากและไม่อัปเดตคุณเมื่อไฟล์ถ่ายโอนเสร็จสิ้นอย่างมีประสิทธิภาพ

ก่อนที่ฉันจะจัดส่งฮาร์ดไดรฟ์ใครบ้างมีอินพุตที่ดีบ้าง?

อัปเดต: อืม ... มันอาจจะเป็นลิงค์หลังจากนั้น :( ดูการทดสอบของฉันด้านล่าง ...

โอนจาก NY ถึง LA:

รับไฟล์เปล่า

[nathan@laobnas test]$ dd if=/dev/zero of=FROM_LA_TEST bs=1k count=4700000
4700000+0 records in
4700000+0 records out
4812800000 bytes (4.8 GB) copied, 29.412 seconds, 164 MB/s
[nathan@laobnas test]$ scp -C obnas:/obbkup/test/FROM_NY_TEST .
FROM_NY_TEST                                    3%  146MB   9.4MB/s   07:52 ETA

รับ tarball ภาพรวม

[nathan@obnas db_backup]$ ls -la db_dump.08120922.tar.gz
-rw-r--r-- 1 root root 30428904033 Aug 12 22:42 db_dump.08120922.tar.gz

[nathan@laobnas test]$ scp -C obnas:/obbkup/db_backup/db_dump.08120922.tar.gz .
db_dump.08120922.tar.gz            0%   56MB 574.3KB/s 14:20:40 ET

โอนจาก LA ถึง NY:

รับไฟล์เปล่า

[nathan@obnas test]$ dd if=/dev/zero of=FROM_NY_TEST bs=1k count=4700000
4700000+0 records in
4700000+0 records out
4812800000 bytes (4.8 GB) copied, 29.2501 seconds, 165 MB/s
[nathan@obnas test]$ scp -C laobnas:/obbkup/test/FROM_LA_TEST .
FROM_LA_TEST                                    0% 6008KB 497.1KB/s 2:37:22 ETA

gettting tarball snapshot

[nathan@laobnas db_backup]$ ls -la db_dump_08120901.tar.gz
-rw-r--r-- 1 root root 31090827509 Aug 12 21:21 db_dump_08120901.tar.gz

[nathan@obnas test]$ scp -C laobnas:/obbkup/db_backup/db_dump_08120901.tar.gz .
db_dump_08120901.tar.gz                0%  324KB  26.8KB/s 314:11:38 ETA

ฉันเดาว่าฉันจะเอามันไปกับคนที่ดูแลสถานที่ของเราลิงก์นั้นมีป้ายกำกับว่าเป็นลิงก์ MPLS / Ethernet 10MB (ยัก)

แอบดูทุกคน?

สมมติว่านี่เป็นเพียงการคัดลอกครั้งเดียวฉันไม่คิดว่ามันจะเป็นไปได้ที่จะคัดลอกไฟล์ไปยังซีดี (หรือสื่ออื่น ๆ ) และข้ามคืนไปยังปลายทางที่นั่นหรือไม่

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

rsync

ตัวเลือก / ความพยายามครั้งที่สองของฉันจะเป็น rsync เนื่องจากตรวจพบการถ่ายโอนที่ล้มเหลวการถ่ายโอนบางส่วน ฯลฯ และสามารถรับได้จากที่ที่มันค้าง

rsync --progress file1 file2 user@remotemachine:/destination/directory

ธง - ความคืบหน้าจะให้ข้อเสนอแนะแก่คุณแทนที่จะแค่นั่งตรงนั้นและปล่อยให้คุณเดาตัวเองเป็นครั้งที่สอง :-)

Vuze (bittorrent)

ตัวเลือกที่สามน่าจะลองใช้ Vuze เป็นเซิร์ฟเวอร์ฝนตกหนักและจากนั้นให้สถานที่ห่างไกลของคุณใช้ไคลเอนต์ bitorrent มาตรฐานเพื่อดาวน์โหลด ฉันรู้จักผู้อื่นที่ทำสิ่งนี้ แต่คุณรู้ ... ตามเวลาที่พวกเขาได้รับการตั้งค่าทั้งหมดทำงาน ฯลฯ ... ฉันสามารถข้ามคืนข้อมูลได้ ...

ขึ้นอยู่กับสถานการณ์ของคุณฉันเดา

โชคดี!

UPDATE:

คุณรู้ไหมฉันคิดถึงปัญหาของคุณอีกเล็กน้อย ทำไมไฟล์ถึงต้องเป็น tarball ขนาดใหญ่เดียว? ทาร์สามารถแยกไฟล์ขนาดใหญ่ออกเป็นไฟล์เล็ก ๆ ได้อย่างสมบูรณ์ (เพื่อขยายสื่อเป็นต้น) ทำไมไม่แยกทาร์บอลขนาดใหญ่นั้นออกเป็นชิ้นที่จัดการได้มากขึ้นแล้วโอนชิ้นส่วนแทน?

ฉันเคยทำมาแล้วในอดีตด้วยไฟล์ 60GB tbz2 ฉันไม่มีสคริปต์อีกต่อไป แต่ควรเขียนใหม่ได้ง่าย

ก่อนอื่นแบ่งไฟล์ของคุณเป็นส่วน ๆ ~ 2GB:

split --bytes=2000000000 your_file.tgz

สำหรับแต่ละชิ้นให้คำนวณ MD5 hash (เพื่อตรวจสอบความสมบูรณ์) และเก็บไว้ที่ใดที่หนึ่งจากนั้นเริ่มคัดลอกชิ้นส่วนและ md5 ของพวกเขาไปยังไซต์ระยะไกลด้วยเครื่องมือที่คุณเลือก (me: netcat-tar-pipe ในหน้าจอ เซสชั่น)

หลังจากผ่านไปสักครู่ตรวจสอบกับ md5 ว่าชิ้นส่วนของคุณโอเคหรือไม่จากนั้น:

cat your_file* > your_remote_file.tgz

หากคุณได้ทำ MD5 ของไฟล์ต้นฉบับด้วยให้ตรวจสอบด้วย หากไม่เป็นไรคุณสามารถปลดไฟล์ได้ทุกอย่างก็โอเค

(ถ้าฉันหาเวลาฉันจะเขียนสคริปต์ใหม่)

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

คำแนะนำของฉัน? FTP หรือ HTTP พร้อมเซิร์ฟเวอร์และไคลเอนต์ที่สนับสนุนการเริ่มต้นการดาวน์โหลดต่อเนื่อง โพรโทคอลทั้งสองมีความรวดเร็วและมีน้ำหนักเบาหลีกเลี่ยงการทำโทษ ssh-tunnel Apache + wget จะกรีดร้องอย่างรวดเร็ว

เคล็ดลับท่อ netcat ก็จะทำงานได้ดี ไม่จำเป็นต้องใช้ tar เมื่อถ่ายโอนไฟล์ขนาดใหญ่เพียงไฟล์เดียว และเหตุผลที่ไม่แจ้งให้คุณทราบเมื่อดำเนินการเสร็จแล้วก็เพราะคุณไม่ได้บอก เพิ่มการ-q0ตั้งค่าสถานะไปยังฝั่งเซิร์ฟเวอร์และจะทำงานตามที่คุณคาดหวัง

เซิร์ฟเวอร์ $ nc -l -p 5000> outfile.tgz

ไคลเอ็นต์ $ nc -q0 server.example.com 5000 <infile.tgz

ข้อเสียของวิธีการ netcat คือจะไม่อนุญาตให้คุณกลับมาทำงานต่อหากการถ่ายโอนของคุณเสียชีวิตถึง 74GB ใน ...

ให้ netcat (บางครั้งเรียกว่า NC) การทำงานต่อไปนี้ในไดเรกทอรี แต่ควรง่ายพอที่จะปรับแต่งเพียงแค่จัดการไฟล์เดียว

บนกล่องปลายทาง:

netcat -l -p 2342 | tar -C /target/dir -xzf -

บนกล่องซอร์ส:

tar czf * | netcat target_box 2342

คุณสามารถลองลบตัวเลือก 'z' ในทั้งคำสั่ง tar เพื่อดูความเร็วเพิ่มอีกเล็กน้อยเนื่องจากไฟล์ถูกบีบอัดแล้ว

ค่าเริ่มต้นของ SCP และ Rsync (ซึ่งใช้ SCP) นั้นช้ามากสำหรับไฟล์ขนาดใหญ่ ฉันเดาว่าฉันจะพิจารณาใช้โปรโตคอลที่มีค่าใช้จ่ายที่ต่ำกว่า คุณเคยลองใช้ Cypher เข้ารหัสที่ง่ายขึ้นหรือไม่? ลองดู--rshตัวเลือกสำหรับ rsync เพื่อเปลี่ยนวิธีการถ่ายโอน

ทำไมไม่ใช้ FTP หรือ HTTP

แม้ว่ามันจะเพิ่มค่าใช้จ่ายเล็กน้อยให้กับสถานการณ์ BitTorrent เป็นทางออกที่ดีจริงๆในการถ่ายโอนไฟล์ขนาดใหญ่ BitTorrent มีคุณสมบัติที่ดีมากมายเช่นการแยกไฟล์และการตรวจสอบแต่ละอันซึ่งสามารถส่งซ้ำได้หากเกิดความเสียหาย

โปรแกรมอย่างAzureus [ที่รู้จักกันในชื่อ Vuze] มีชิ้นส่วนทั้งหมดที่คุณจะต้องสร้างเซิร์ฟเวอร์และดาวน์โหลดเพลงในแอพเดียว Bean ในใจ Azureus ไม่ได้เป็นโซลูชั่นที่สามารถใช้งานได้มากที่สุดสำหรับ BitTorrent และฉันคิดว่าต้องใช้ GUI ด้วยเช่นกัน - มีเครื่องมือฝนตกหนักบรรทัดคำสั่งมากมายสำหรับ Linux

ส่วนตัวแล้ว 20-30Kb / s นั้นค่อนข้างต่ำสำหรับลิงก์ 10Mb (สมมติว่า 10Mb และไม่ใช่ 10MB)

ถ้าฉันเป็นคุณฉันจะทำหนึ่งในสองสิ่ง (สมมติว่าไม่มีการเข้าถึงทางกายภาพ)

ฉันแนะนำให้คุณแบ่งไฟล์ขนาดใหญ่ออกเป็นชิ้นเล็ก ๆ ประมาณ 500MB เพียงเพราะความเสียหายระหว่างการขนส่ง

เมื่อคุณมีชิ้นเล็ก ๆ ให้ใช้ rsync อีกครั้งหรือฉันต้องการใช้ Secure ftp session ส่วนตัวแล้ว CRC ไฟล์เมื่อเสร็จสิ้น

คำถามสองสามข้ออาจช่วยในการอภิปราย: การถ่ายโอนข้อมูลมีความสำคัญเพียงใด? นี่คือการกู้คืนความเสียหายการสำรองข้อมูลยอดนิยมการจัดเก็บแบบออฟไลน์หรือเปล่า คุณต้องการสำรองฐานข้อมูลในขณะที่มันกำลังขึ้นหรือลง? สิ่งที่เกี่ยวกับการตั้งค่าฐานข้อมูลที่ระบบระยะไกลและทำให้พวกเขาในการซิงค์โดยใช้การจัดกลุ่มหรือการปรับปรุงผ่าน changelogs (ฉันไม่ได้เชี่ยวชาญในความสามารถของระบบฐานข้อมูล MySql ทั้งหมด) สิ่งนี้อาจช่วยลดปริมาณข้อมูลที่ต้องโอนผ่านลิงค์

bbcp จะส่งไฟล์ให้คุณและคัดลอกด้วยสตรีมหลายรายการ

คำตอบสำหรับผู้ที่ล่าช้า:

เมื่อถ่ายโอนชุดข้อมูลขนาดใหญ่สามารถใช้ rsync เพื่อเปรียบเทียบแหล่งที่มาและปลายทางจากนั้นเขียนไฟล์แบตช์ไปยังสื่อบันทึกข้อมูลแบบถอดได้ในเครื่องโดยใช้แฟล็ก --only-write-batch จากนั้นคุณจัดส่งสื่อท้องถิ่นไปยังตำแหน่งที่ตั้งระยะไกลเสียบเข้าและเรียกใช้ rsync อีกครั้งโดยใช้ - อ่านแบทช์เพื่อรวมการเปลี่ยนแปลงในชุดข้อมูลระยะไกล

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

(Ref: ฉันเป็นหนึ่งในผู้เขียนของคุณลักษณะนี้ใน rsync - สำหรับพื้นหลังและกรณีการใช้งานเพิ่มเติมดูการสนทนาของการใช้ต้นแบบ: https://lists.samba.org/archive/rsync/2005-March/011964 .html )