วิธีที่ดีที่สุดในการถ่ายโอนไฟล์ขนาดใหญ่หนึ่งไฟล์ผ่านลิงค์ WAN ความเร็วสูงและความล่าช้าสูงคืออะไร


21

ดูเหมือนว่าจะเกี่ยวข้องกับอันนี้แต่ก็ค่อนข้างแตกต่างกัน

มีลิงค์ WAN นี้ระหว่างเว็บไซต์ของ บริษัท สองแห่งและเราจำเป็นต้องถ่ายโอนไฟล์ที่มีขนาดใหญ่มาก (การถ่ายโอนข้อมูล Oracle, ~ 160 GB)

เรามีแบนด์วิดท์เต็ม 100 Mbps (ทดสอบแล้ว) แต่ดูเหมือนว่าการเชื่อมต่อ TCP เดียวจะไม่สามารถทำได้สูงสุดเนื่องจากการทำงานของ TCP (ACKs ฯลฯ ) เราทดสอบการเชื่อมโยงกับiperfและผลลัพธ์จะเปลี่ยนไปอย่างมากเมื่อเพิ่มขนาดหน้าต่าง TCP: ด้วยการตั้งค่าพื้นฐานเราจะได้รับปริมาณข้อมูล ~ 5 Mbps ด้วย WS ที่ใหญ่กว่าเราสามารถเพิ่มได้ถึง ~ 45 Mbps แต่ไม่มากไปกว่านั้น เวลาแฝงเครือข่ายอยู่ที่ประมาณ 10 ms

จากความอยากรู้เราใช้ iperf โดยใช้การเชื่อมต่อมากกว่าหนึ่งครั้งและเราพบว่าเมื่อใช้งานสี่การเชื่อมต่อพวกเขาจะประสบความสำเร็จในความเร็วที่ ~ 25 Mbps ต่อการเติมแบนด์วิดท์ที่มีอยู่ทั้งหมด ดังนั้นคีย์ดูเหมือนจะทำงานหลายการโอนพร้อมกัน

ด้วย FTP สิ่งที่เลวร้ายยิ่ง: แม้จะมีการตั้งค่า TCP ที่เหมาะสม (ขนาดหน้าต่างสูง, MTU สูงสุด ฯลฯ ) เราไม่สามารถรับมากกว่า 20 Mbps ต่อการถ่ายโอนครั้งเดียว เราลอง FTPing ไฟล์ขนาดใหญ่ในเวลาเดียวกันและสิ่งต่าง ๆ ก็ดีกว่าเมื่อถ่ายโอนไฟล์เดียว แต่ผู้ร้ายกลายเป็นดิสก์ I / O เพราะการอ่านและเขียนไฟล์ขนาดใหญ่สี่ไฟล์จากคอขวดดิสก์เดียวกันเร็ว ๆ นี้ และดูเหมือนว่าเราจะไม่สามารถแยกไฟล์ขนาดใหญ่นั้นออกเป็นไฟล์เล็ก ๆ แล้วรวมมันกลับคืนมาอย่างน้อยก็ไม่ได้ในเวลาที่ยอมรับได้ (เห็นได้ชัดว่าเราไม่สามารถใช้ splicing / ผสานไฟล์กลับในเวลาที่เทียบเคียงได้กับ กำลังถ่ายโอน)

ทางออกที่ดีในที่นี้คือเครื่องมือแบบมัลติเธรดที่สามารถถ่ายโอนไฟล์จำนวนมากในเวลาเดียวกัน การเรียงลำดับของโปรแกรมเพียร์ทูเพียร์เช่น eMule หรือ BitTorrent ได้ทำไปแล้ว แต่จากแหล่งเดียวไปยังปลายทางเดียว เครื่องมือจะช่วยให้เราสามารถเลือกได้ว่าจะใช้การเชื่อมต่อแบบขนานจำนวนเท่าใดและแน่นอนว่าการเพิ่มประสิทธิภาพดิสก์ I / O จะไม่กระโดด (เช่นกัน) อย่างบ้าคลั่งระหว่างส่วนต่าง ๆ ของไฟล์

ไม่มีใครรู้ว่าเครื่องมือดังกล่าวหรือไม่?

หรือใครสามารถแนะนำวิธีแก้ปัญหาที่ดีกว่าและ / หรือบางสิ่งบางอย่างที่เราไม่ได้ลองมาแล้ว?

ป.ล. เราคิดว่าจะสำรองข้อมูลไว้ที่เทป / ดิสก์แล้วส่งไปยังปลายทาง นั่นจะเป็นมาตรการที่รุนแรงของเราหาก WAN ไม่ตัดมัน แต่อย่างที่ Tanenbaum กล่าวว่า "อย่าประมาทแบนด์วิดธ์ของรถบรรทุกสถานีที่เต็มไปด้วยเทปที่พุ่งชนทางหลวง"


1
จากความอยากรู้อยากเห็นเวลาที่สำคัญจริงๆหรือไม่? อีกทั้งการเชื่อมโยงระหว่างช่วงเวลาของการถ่ายโอน 160Gb จะไม่ส่งผลกระทบต่อส่วนที่เหลือของเครือข่ายของคุณหรือไม่
ไบรอัน

6
ฉันจำได้ว่ามีการส่งออโต้โหลด DLT และตลับหมึกสองร้อยตลับให้กับลูกค้าในปี 99 เราคำนวณความสามารถของรถของฉันที่มีคาร์ทริดจ์ 200 DLT IV ที่บรรจุอยู่ในนั้น (ความจุดิบ 35GB ต่อหน่วย) ที่ประมาณ 6.3TB ฉันขับรถจากสำนักงานของเราไปยังเว็บไซต์ของลูกค้าในเวลาประมาณ 55 นาทีให้ "Evan ใน Geo Metro ขับรถอย่างบ้าคลั่งในอินเตอร์สเตต" กลไกการขนส่งสำรองมีอัตราความเร็วที่ 118GB / นาที อัตราความเร็วที่ดี แต่เวลาแฝงนั้นเป็นนักฆ่า ... > ยิ้ม <
Evan Anderson

ไบรอัน: ใช่เวลามีความสำคัญ (ใช้เวลาประมาณยี่สิบชั่วโมงด้วยการตั้งค่า FTP มาตรฐานและเครือข่ายมาตรฐาน) และไม่ไม่มีปัญหาในการเชื่อมโยงลิงก์เนื่องจากการถ่ายโอนจะถูกกำหนดเวลาทำงานนอกเวลา
Massimo

Evan: นั่นคือสิ่งที่ฉันหมายถึง ;-)
Massimo

ฉันได้รับการจัดการกับสถานการณ์ที่คล้ายกันกับ ~ 200GB ของ SQL. bak ยกเว้นวิธีเดียวที่ฉันสามารถรับลิงค์ WAN เพื่ออิ่มตัวคือด้วย FTP ฉันลงเอยด้วยการใช้ 7-zip โดยไม่มีการบีบอัดเพื่อแบ่งเป็น 512MB ชิ้น "การบีบอัด" และ "คลายการบีบอัด" ครั้งนั้นสั้นพอสมควร all-in-all ดีกว่า shoveling สื่อทางกายภาพทั่วประเทศ (สถานที่ตั้งอยู่บนฝั่งตรงข้ามของสหรัฐอเมริกา)
Adrien

คำตอบ:


15

การค้นหา "การถ่ายโอนไฟล์ที่มีความหน่วงสูง" นั้นมีจำนวนเพลงที่น่าสนใจมากมาย เห็นได้ชัดว่านี่เป็นปัญหาที่ชุมชน CompSci และชุมชนการค้าได้นำมาใช้

ข้อเสนอเชิงพาณิชย์เล็กน้อยที่ดูเหมือนจะพอดีกับใบเสร็จ:

  • FileCatalystมีผลิตภัณฑ์ที่สามารถสตรีมข้อมูลผ่านเครือข่ายเวลาแฝงสูงโดยใช้ UDP หรือหลายสตรีม TCP พวกเขามีคุณสมบัติอื่น ๆ มากมายเช่นกัน (การบีบอัดข้อมูลแบบทันทีทันใดการถ่ายโอนเดลต้า ฯลฯ )

  • การถ่ายโอนไฟล์fasp "เทคโนโลยี" จาก Aspera นั้นดูเหมือนว่าจะพอดีกับสิ่งที่คุณกำลังมองหาเช่นกัน

ในโลกโอเพนซอร์โครงการuftp นั้นดูมีแนวโน้ม คุณไม่ต้องการความสามารถแบบมัลติคาสต์เป็นพิเศษ แต่ความคิดพื้นฐานของการกระจายไฟล์ให้กับผู้รับรับ NAKs สำหรับบล็อกที่ไม่ได้รับเมื่อสิ้นสุดการถ่ายโอนจากนั้นจึงพ่นบล็อก NAK'd ออก ดูเหมือนว่ามันจะทำในสิ่งที่คุณต้องการเนื่องจากไม่มี ACK'ing (หรือ NAK'ing) จากผู้รับจนกว่าจะเสร็จสิ้นการถ่ายโอนไฟล์ครั้งเดียว สมมติว่าเครือข่ายนั้นแฝงอยู่และไม่สูญเสียสิ่งนี้อาจทำในสิ่งที่คุณต้องการเช่นกัน


uftp ดูมีความหวังดีมากฉันสามารถบรรลุ 30 Mbps ระหว่างคอมพิวเตอร์เดสก์ท็อปสองเครื่อง (ซึ่งไม่ดีเท่าที่ประสิทธิภาพของดิสก์); ฉันจะทดสอบบนเซิร์ฟเวอร์ "ของจริง" ในไม่ช้า ฉันไม่สามารถรับใบอนุญาตการสาธิต FileCatalyst เนื่องจากข้อผิดพลาดบางอย่างในแบบฟอร์มการลงทะเบียน (มันยังคงบอกว่าหมายเลขคำขอได้ถูกใช้ไปแล้ว) และ fasp ก็ไม่ได้ให้พวกเขา
Massimo

60 Mbps ระหว่างคอมพิวเตอร์สองเครื่องที่มีดิสก์ที่เหมาะสมและบัฟเฟอร์รับขนาดใหญ่ ที่ดี!
Massimo

ฉันชอบซอฟต์แวร์โอเพนซอร์ซฟรี /! > Smile <ฉันจะลองทำบางอย่างที่ฉันทำ ฉันสงสัยว่ามันจะทำอย่างไรในโซลูชั่นการสร้างภาพดิสก์มัลติคาสต์บนลีนุกซ์ที่ฉันรวบรวมเมื่อสองสามปีก่อนโดยใช้ "udpcast"
Evan Anderson

สักพักฉันถามserverfault.com/questions/173358/multicast-file-transfersในที่สุดฉันก็สรุปว่า uftp และ mrsync เป็นเครื่องมือที่ดีที่สุด กรุณาโพสต์ในความคิดเห็นที่นั่นถ้าคุณทำสิ่งที่มีประโยชน์กับ uftp เช่นฉันจะใช้อย่างใดอย่างหนึ่งอีกครั้งในปีนี้ (เตรียมสำหรับการประชุม)
Jed Daniels

2
เมื่อฉันทำงานกับ UFTP, UDT และสึนามิ UDP, UFTP มีประสิทธิภาพที่แย่ที่สุดของทั้งสามคน แน่นอนมันอาจเป็นโปรโตคอลที่โตที่สุด UDT ให้โปรโตคอลการถ่ายโอนอย่างง่ายเท่านั้นและได้รับการออกแบบให้ทำหน้าที่เป็นห้องสมุดเพื่อพัฒนาซอฟต์แวร์ที่กำหนดเองและผู้เขียนสึนามิได้ชี้ให้เราเห็นถึง UDT เนื่องจากสึนามิไม่ได้รับการพัฒนาอย่างแข็งขันเมื่อเร็ว ๆ นี้เนื่องจากไม่มีเวลา
โธมัสโอเวนส์

9

ข้อเสนอแนะที่แปลกจริง ๆ ข้อนี้ตั้งค่าเว็บเซิร์ฟเวอร์แบบง่าย ๆ เพื่อโฮสต์ไฟล์บนเครือข่ายของคุณ (ฉันแนะนำ nginx โดยบังเอิญ) จากนั้นตั้งค่าพีซีที่มี firefox ที่ปลายอีกด้านและติดตั้งส่วนขยาย DownThemAll

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

(ข้อแม้: ฉันไม่เคยลองสิ่งใดที่มีขนาดใหญ่ถึง 160GB แต่ใช้งานได้ดีกับไฟล์ iso 20GB)


40 Mbps ระหว่างคอมพิวเตอร์เครื่องเดียวกัน ดูดีมากเช่นกัน
Massimo

1
แทนที่ firefox ด้วยaxel.alioth.debian.orgและไม่ใช่ข้อเสนอแนะที่แย่
จัสติน

7

การขนส่งUDTน่าจะเป็นการขนส่งที่นิยมที่สุดสำหรับการสื่อสารที่มีความหน่วงสูง สิ่งนี้นำไปสู่ซอฟต์แวร์อื่น ๆ ของพวกเขาที่ชื่อว่าSector / Sphere "ระบบไฟล์แบบกระจายที่มีประสิทธิภาพสูงและเครื่องมือประมวลผลข้อมูลแบบขนาน" ซึ่งอาจคุ้มค่าที่จะดู


1
ฉันทำงานกับ UDT เพื่อถ่ายโอนผ่านเครือข่ายที่มีความหน่วงแฝงสูงและการสูญเสียแพ็กเก็ตสูง UDT มีความยืดหยุ่นต่อความหน่วงและการสูญหายของแพ็คเก็ตมากกว่าโปรโตคอลแบบ TCP โดยเฉพาะเมื่อคุณเปลี่ยนอัลกอริธึมการควบคุมความแออัดเพื่อให้เหมาะสมกับภูมิประเทศของเครือข่ายของคุณ
โธมัสโอเวนส์

แม้จะมี rsync เวอร์ชันหนึ่งที่มี UDT ในตัวเรียกว่า "UDR" github.com/LabAdvComp/UDR
สูงสุด

5

คำตอบของฉันสายไปหน่อย แต่ฉันเพิ่งพบคำถามนี้ในขณะที่มองหา fasp ในระหว่างการค้นหานั้นฉันก็พบสิ่งนี้: http://tsunami-udp.sourceforge.net/ , "โปรโตคอลสึนามิ UDP"

จากเว็บไซต์ของพวกเขา:

โปรโตคอลการถ่ายโอนไฟล์พื้นที่ผู้ใช้ที่รวดเร็วซึ่งใช้การควบคุม TCP และข้อมูล UDP สำหรับการถ่ายโอนผ่านเครือข่ายทางไกลความเร็วสูงมาก (≥ 1 Gbps และแม้แต่ 10 GE) ออกแบบมาเพื่อให้ปริมาณงานผ่านได้มากกว่า TCP ในเครือข่ายเดียวกัน เครือข่าย

หน้าเว็บจะกล่าวถึงผลลัพธ์นี้ (โดยใช้ลิงก์ระหว่างเฮลซิงกิฟินแลนด์ไปบอนน์ประเทศเยอรมนีผ่านลิงก์ 1GBit:

รูปที่ 1 - การถ่ายโอนระหว่างประเทศผ่านอินเทอร์เน็ตโดยเฉลี่ยอยู่ที่ 800 Mbit / วินาที

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


1
ในโครงการที่ฉันแสดงความคิดเห็นก่อนหน้านี้ในคำตอบของ Steve-o เราได้ทำการทดสอบ UDT, สึนามิ UDP และ UFTP เราพบว่าเวลาแฝงมีผลกระทบอย่างมากต่อประสิทธิภาพในขณะที่การสูญหายของแพ็คเก็ตไม่ได้ (ตรงกันข้ามกับเอกสารสึนามิ) การเพิ่มความล่าช้า 100ms ในเครือข่ายการทดสอบทำให้ประสิทธิภาพการทำงานของสึนามิลดลงจากประมาณ 250Mbits / วินาทีเป็นประมาณ 50Mbits / วินาที (ฉันเชื่อว่าฉันมีตัวเลขและหน่วยที่ถูกต้อง - มันผ่านไประยะหนึ่งแล้ว การเพิ่มแพ็กเก็ตข้อมูลสูญหาย 10% ไม่มีเครือข่ายเวลาแฝงน้อยที่สุดในทางกลับกันประสิทธิภาพลดลงจาก 250Mbits / วินาทีเป็นประมาณ 90Mbits / วินาที
โทมัสโอเวนส์

4

bbcpยูทิลิตี้จากหน้าเว็บที่เกี่ยวข้องมาก'วิธีการถ่ายโอนข้อมูลจำนวนมากผ่านเครือข่าย'น่าจะเป็นทางออกที่ง่ายที่สุด


ฉันไม่คิดว่า bbcp เหมาะสำหรับเวลาแฝงที่สูง ฉันได้รับ ~ 20 MB / วินาทีผ่านลิงค์มหาสมุทรแอตแลนติกในขณะนี้ด้วยการตั้งค่าเริ่มต้น
Max
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.