Cách tốt nhất để chuyển một tệp lớn qua liên kết WAN tốc độ cao, độ trễ cao là gì?


21

Cái này có vẻ liên quan đến cái này , nhưng nó hơi khác.

Có liên kết WAN này giữa hai trang web của công ty và chúng tôi cần chuyển một tệp rất lớn (Oracle dump, ~ 160 GB).

Chúng tôi đã có băng thông 100 Mbps đầy đủ (đã thử nghiệm), nhưng có vẻ như một kết nối TCP duy nhất không thể tối đa hóa do cách thức hoạt động của TCP (ACK, v.v.). Chúng tôi đã thử nghiệm liên kết với iperf và kết quả thay đổi đáng kể khi tăng Kích thước cửa sổ TCP: với cài đặt cơ bản, chúng tôi nhận được thông lượng ~ 5 Mbps, với WS lớn hơn, chúng tôi có thể đạt tới ~ 45 Mbps, nhưng không nhiều hơn thế. Độ trễ mạng là khoảng 10 ms.

Vì tò mò, chúng tôi đã chạy iperf bằng cách sử dụng nhiều hơn một kết nối và chúng tôi thấy rằng, khi chạy bốn trong số chúng, chúng thực sự sẽ đạt tốc độ ~ 25 Mbps mỗi lần, lấp đầy tất cả băng thông có sẵn; Vì vậy, khóa có vẻ là trong việc chạy nhiều chuyển đồng thời.

Với FTP, mọi thứ trở nên tồi tệ hơn: ngay cả với các cài đặt TCP được tối ưu hóa (Kích thước cửa sổ cao, MTU tối đa, v.v.), chúng tôi không thể nhận được hơn 20 Mbps trên một lần chuyển. Chúng tôi đã thử FTP một số tệp lớn cùng một lúc và thực sự mọi thứ đã tốt hơn rất nhiều so với khi chuyển một tệp duy nhất; nhưng sau đó thủ phạm đã trở thành I / O đĩa, bởi vì đọc và ghi bốn tệp lớn từ cùng một nút cổ chai rất sớm; Ngoài ra, chúng tôi dường như không thể chia tệp lớn đó thành các tệp nhỏ hơn và sau đó hợp nhất lại, ít nhất là trong thời gian có thể chấp nhận được (rõ ràng chúng tôi không thể dành thời gian ghép / trộn lại tệp một thời gian có thể so sánh với chuyển nó).

Giải pháp lý tưởng ở đây sẽ là một công cụ đa luồng có thể chuyển các khối khác nhau của tệp cùng một lúc; giống như các chương trình ngang hàng như eMule hoặc BitTorrent đã làm, nhưng từ một nguồn duy nhất đến một đích duy nhất. Lý tưởng nhất, công cụ sẽ cho phép chúng ta chọn sử dụng bao nhiêu kết nối song song và tất nhiên tối ưu hóa I / O đĩa để không nhảy (quá) điên cuồng giữa các phần khác nhau của tệp.

Có ai biết một công cụ như vậy?

Hoặc, có ai có thể đề xuất một giải pháp tốt hơn và / hoặc một cái gì đó chúng tôi đã không thử không?

Tái bút: Chúng tôi đã nghĩ đến việc sao lưu băng / đĩa và gửi nó đến đích; đó sẽ là biện pháp cực đoan của chúng tôi nếu WAN không cắt nó, nhưng, như AS Tanenbaum nói, "Đừng bao giờ đánh giá thấp băng thông của một toa xe ga đầy băng từ trên đường cao tốc."


1
Vì tò mò, thời gian cần thiết có thực sự quan trọng không? Ngoài ra, việc bão hòa liên kết trong thời gian chuyển 160Gb sẽ không ảnh hưởng đến phần còn lại của mạng của bạn?
Bryan

6
Tôi nhớ việc cung cấp một số trình tải tự động DLT và vài trăm hộp mực cho Khách hàng trở lại vào năm 99. Chúng tôi đã tính toán dung lượng thô của xe tôi với khoảng 200 hộp mực DLT IV được nạp trong đó (mỗi hộp dung lượng 35 GB) vào khoảng 6,3TB. Tôi đã lái xe từ văn phòng của chúng tôi đến trang web của Khách hàng trong khoảng 55 phút, đưa ra cơ chế vận chuyển dự phòng "Evan trong Geo Metro như điên xuống Interstate" với tốc độ hiệu quả khoảng 118 GB / phút. Thông lượng tốt, nhưng độ trễ là một kẻ giết người ...> nụ cười <
Evan Anderson

Bryan: có, thời gian là rất quan trọng (phải mất khoảng HAI GIỜ với cài đặt mạng chuẩn và FTP tiêu chuẩn), và không, sẽ không có vấn đề gì trong việc bão hòa liên kết, vì việc chuyển tiền sẽ được lên lịch trong thời gian không hoạt động.
Massimo

Evan: đó chính xác là những gì tôi muốn nói ;-)
Massimo

Tôi đã xử lý một tình huống tương tự, với ~ 200GB SQL .bak, ngoại trừ cách duy nhất tôi có thể khiến liên kết WAN trở nên bão hòa là với FTP. Tôi đã kết thúc bằng cách sử dụng 7-zip với độ nén bằng 0 để chia nó thành các khối 512MB. Thời gian "nén" và "giải nén" rất ngắn; tất cả trong tất cả tốt hơn nhiều so với phương tiện truyền thông vật lý trên toàn quốc. (Các trang web nằm trên bờ biển đối diện của Hoa Kỳ)
Adrien

Câu trả lời:


15

Tìm kiếm "chuyển tập tin có độ trễ cao" mang lại rất nhiều lượt truy cập thú vị. Rõ ràng, đây là một vấn đề mà cả cộng đồng CompSci và cộng đồng thương mại đã đặt ra.

Một vài dịch vụ thương mại có vẻ phù hợp với dự luật:

  • FileC Lúc sinh có các sản phẩm có thể truyền dữ liệu qua các mạng có độ trễ cao bằng cách sử dụng UDP hoặc nhiều luồng TCP. Họ cũng có rất nhiều tính năng khác (nén nhanh, chuyển delta, v.v.).

  • Các fasp tập tin chuyển giao "công nghệ" từ Aspera dường như phù hợp với những hóa đơn cho những gì bạn đang tìm kiếm, là tốt.

Trong thế giới nguồn mở, dự án uftp có vẻ đầy hứa hẹn. Bạn không đặc biệt cần các khả năng phát đa hướng của nó, nhưng ý tưởng cơ bản là làm nổ một tệp cho người nhận, nhận NAK cho các khối bị bỏ lỡ khi kết thúc chuyển, và sau đó làm nổ các khối NAK (trễ, rửa, lặp lại) Nghe có vẻ như nó sẽ làm những gì bạn cần, vì không có ACK'ing (hoặc NAK'ing) từ người nhận cho đến khi quá trình truyền tệp hoàn tất một lần. Giả sử mạng chỉ là tiềm ẩn và không mất mát, điều này cũng có thể làm những gì bạn cần.


uftp trông thực sự hứa hẹn, tôi đã có thể đạt được 30 Mbps giữa hai máy tính để bàn (điều này chắc chắn không phải là quá tuyệt vời về hiệu suất đĩa); Tôi sẽ sớm kiểm tra nó trên các máy chủ "thực". Tôi đã không thể có được giấy phép demo FileC Lúc sinh do một số lỗi trong biểu mẫu đăng ký (nó vẫn nói rằng số yêu cầu đã được sử dụng) và fasp chỉ không cung cấp cho họ.
Massimo

60 Mbps giữa hai máy tính với đĩa thích hợp và bộ đệm nhận lớn. Tuyệt quá!
Massimo

Tôi yêu phần mềm miễn phí / nguồn mở! > mỉm cười <Tôi chắc chắn sẽ thử uftp với một số thứ tôi đang làm. Tôi đang tự hỏi làm thế nào nó sẽ làm trong một giải pháp hình ảnh đĩa đa hướng dựa trên Linux mà tôi đã kết hợp một vài năm trước bằng cách sử dụng "udpcast".
Evan Anderson

Một lúc trước, tôi đã hỏi serverfault.com/questions/173358/multicast-file-transifts Cuối cùng tôi đã đi đến kết luận rằng uftp và mrsync là công cụ được lựa chọn. Vui lòng gửi bình luận ở đó nếu bạn làm bất cứ điều gì hữu ích với uftp, vì tôi sẽ sử dụng cái này hoặc cái kia một lần nữa trong năm nay (chuẩn bị cho một hội nghị).
Jed Daniels

2
Khi tôi làm việc với UFTP, UDT và Tsunami UDP, UFTP có hiệu suất kém nhất trong ba. Tất nhiên, nó có lẽ là giao thức trưởng thành nhất. UDT chỉ cung cấp một giao thức chuyển đơn giản và được thiết kế để hoạt động như một thư viện để phát triển phần mềm tùy chỉnh và tác giả của Tsunami thực sự đã chỉ chúng tôi về UDT vì Tsunami đã không được phát triển tích cực gần đây do thiếu thời gian.
Thomas Owens

9

Đề xuất thực sự kỳ quặc này .. Thiết lập một máy chủ web đơn giản để lưu trữ tệp trên mạng của bạn (tôi đề nghị nginx, tình cờ), sau đó thiết lập một máy tính với firefox ở đầu bên kia và cài đặt tiện ích mở rộng DownThemAll .

Đây là một trình tăng tốc tải xuống hỗ trợ chunking và lắp ráp lại.
Bạn có thể chia mỗi lần tải xuống thành 10 phần để lắp ráp lại, và nó thực sự làm mọi thứ nhanh hơn!

(báo trước: Tôi chưa bao giờ thử nó trên bất kỳ thứ gì lớn tới 160 GB, nhưng nó hoạt động tốt với các tệp iso 20 GB)


40 Mbps giữa các máy tính giống nhau. Có vẻ thực sự tốt, quá.
Massimo

1
thay thế firefox bằng axel.alioth.debian.org và đó không phải là một gợi ý tồi.
Justin

7

Các UDT giao thông có lẽ là phương tiện giao thông phổ biến nhất cho truyền thông độ trễ cao. Điều này dẫn đến phần mềm khác của họ có tên là ngành / lĩnh vực "Hệ thống tệp phân tán hiệu suất cao và công cụ xử lý dữ liệu song song" có thể đáng để xem xét.


1
Tôi đã thực hiện một số công việc với UDT để chuyển qua các mạng có độ trễ cao và mất gói cao. UDT có khả năng phục hồi nhanh hơn đối với độ trễ và mất gói so với các giao thức dựa trên TCP, đặc biệt là khi bạn thay đổi thuật toán điều khiển tắc nghẽn cho phù hợp với địa hình mạng của bạn.
Thomas Owens

Thậm chí còn có một phiên bản rsync với UDT tích hợp, nó được gọi là "UDR". github.com/LabAdvComp/UDR
Tối đa

5

Câu trả lời của tôi là hơi muộn, nhưng tôi vừa tìm thấy câu hỏi này, trong khi tìm kiếm fasp. Trong quá trình tìm kiếm đó tôi cũng tìm thấy điều này: http://tsunami-udp.sourceforge.net/ , "Giao thức UDP của sóng thần".

Từ trang web của họ:

Giao thức truyền tệp không gian người dùng nhanh sử dụng điều khiển TCP và dữ liệu UDP để truyền qua các mạng đường dài tốc độ rất cao (G 1 Gbps và thậm chí 10 GE), được thiết kế để cung cấp nhiều thông lượng hơn khả năng với TCP trên cùng một mạng. mạng.

Về tốc độ, trang đề cập đến kết quả này (sử dụng liên kết giữa Helsinki, Phần Lan đến Bon, Đức qua liên kết 1GBit:

Hình 1 - chuyển khoản quốc tế qua Internet, trung bình 800 Mbit / giây

Nếu bạn muốn sử dụng một trình tăng tốc tải xuống, hãy xem lftp, đây là trình tăng tốc tải xuống duy nhất có thể làm một gương đệ quy, theo như tôi biết.


1
Trong dự án tôi đã nhận xét trước đó trong câu trả lời của Steve-o, chúng tôi đã điểm chuẩn UDT, Tsunami UDP và UFTP. Chúng tôi thấy rằng độ trễ có ảnh hưởng rất lớn đến hiệu suất, trong khi mất gói thì không (trái với tài liệu về Sóng thần). Thêm 100ms độ trễ vào mạng thử nghiệm đã làm giảm hiệu suất của Tsunami từ khoảng 250Mbit / giây xuống còn khoảng 50Mbit / giây (Tôi tin rằng tôi có số và đơn vị của mình ngay - đó là một thời gian, nhưng nó đã giảm rất nhiều). Thêm 10% mất gói không có mạng độ trễ tối thiểu, mặt khác, chỉ làm giảm hiệu suất từ ​​250Mbit / giây xuống còn khoảng 90Mbit / giây.
Thomas Owens

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.