Tek bir büyük dosyayı yüksek hızlı, yüksek gecikmeli bir WAN bağlantısı üzerinden aktarmanın en iyi yolu nedir?


21

Bu bakışlar ile ilgili bu bir , ama biraz farklı.

İki şirket sitesi arasında bu WAN bağlantısı var ve çok büyük bir dosya aktarmamız gerekiyor (Oracle dump, ~ 160 GB).

Tam 100 Mbps bant genişliğimiz var (test edildi), ancak TCP'nin nasıl çalıştığından (ACK'ler vb.) Tek bir TCP bağlantısı gibi görünmüyor. Bağlantıyı iperf ile test ettik ve sonuçlar TCP Pencere Boyutunu arttırırken büyük ölçüde değişiyor: temel ayarlarla ~ 5 Mbps verim elde ediyoruz, daha büyük bir WS ile ~ 45 Mbps'ye ulaşabiliyoruz, bundan daha fazlasını elde edemiyoruz. Ağ gecikmesi yaklaşık 10 ms'dir.

Merak etmeden, tek bir bağlantıdan daha fazlasını kullanmaya başladık ve dördünü çalıştırırken, gerçekten de mevcut bant genişliğini doldurarak her birinin ~ 25 Mb / sn hızında çalışacaklarını gördük; bu nedenle, anahtar aynı anda birden fazla aktarımı çalıştırıyor gibi görünüyor.

FTP ile işler daha da kötüye gidiyor: en iyileştirilmiş TCP ayarlarında bile (yüksek Pencere Boyutu, maksimum MTU, vb.) Tek bir aktarımda 20 Mbps'den fazla alamıyoruz. Bazı büyük dosyaları aynı anda FTP'ye göndermeyi denedik ve gerçekten de işler tek bir dosyayı aktarırken olduğundan çok daha iyi hale geldi; ama sonra suçlu disk G / Ç oldu, çünkü aynı diskteki dört büyük dosyayı çok kısa sürede okumak ve yazmak; Ayrıca, bu büyük dosyayı küçük dosyalara bölüp daha sonra tekrar birleştirebiliriz (en azından kabul edilebilir zamanlarda değil) (Açıkçası dosyayı dosyaya benzer bir zamana ekleyerek / birleştirerek harcayamazız) aktarılıyor).

Buradaki ideal çözüm, dosyanın çeşitli parçalarını aynı anda aktarabilen çok iş parçacıklı bir araç olacaktır; eMule veya BitTorrent gibi eşler arası programlar gibi, zaten tek bir kaynaktan tek bir hedefe kadar. İdeal olarak, araç kaç paralel bağlantı kullanacağımızı seçmemize ve tabii ki diskin I / O'yu dosyanın çeşitli bölümleri arasında delice atlamamasına (en iyi şekilde) izin verir.

Böyle bir araç bilen var mı?

Veya daha iyi bir çözüm ve / veya daha önce denemediğimiz bir şey önerebilir mi?

PS Biz zaten bunu bant / diske yedeklemeyi ve fiziksel olarak hedefe göndermeyi düşündük; WAN bunu kesmediyse bu bizim aşırı ölçütümüz olurdu, ancak AS Tanenbaum'un dediği gibi, "Karayolu üzerinde incinen bantlarla dolu bir vagonun bant genişliğini asla küçümseme."


1
Meraktan uzak, gerçekten bu kadar kritik geçen zaman mı? Ayrıca, bağlantıyı 160 Gb'lik bir transfer süresi boyunca doyurmak ağınızın geri kalanını etkilemez mi?
Bryan,

6
Bazı DLT oto-yükleyicilerini ve birkaç yüz kartuşu, '99'da Müşteriye geri verdiğimi hatırlıyorum. Aracımın ham kapasitesini, içinde yüklü olan 200 DLT IV kartuşla (her biri 35 GB ham kapasite) yaklaşık 6.3 TB'da hesapladık. Ofisimizden Müşterinin sitesine yaklaşık 55 dakika sonra çıktım, "Evan'ı bir Jeo Metro'da Interstate gibi delinmiş sürüş" yedek taşıma mekanizmasına yaklaşık 118 GB / dk'lık etkili bir verim verdim. İyi performans, ancak gecikme bir katildi ...> gülüş <
Evan Anderson

Bryan: evet, zaman kritik (standart FTP ve standart ağ ayarlarıyla birlikte YİRMİ SAAT sürüyor) ve hayır, bağlantının doyurulmasında sorun yaşanmayacak, çünkü aktarım çalışma zamanında yapılacak.
Massimo

Evan: Tam olarak kastettiğim şey buydu ;-)
Massimo

Benzer bir durumla uğraşıyorum, ~ 200GB SQL .bak ile, WAN bağlantısını doygun hale getirmenin tek yolu FTP ile. Ben 512 MB'lık parçalara ayırmak için sıfır sıkıştırma ile 7-zip kullanarak sona erdi. "Sıkıştırma" ve "dekompresyon" süreleri kabul edilebilir şekilde kısaydı; hepsi bir arada, ülke genelinde fiziksel medyayı kürekle gezmekten çok daha iyi. (Siteler ABD'nin zıt kıyılarında)
Adrien

Yanıtlar:


15

"Yüksek gecikmeli dosya aktarımı" aranıyor birçok ilginç isabet getiriyor. Açıkçası, bu hem CompSci topluluğunun hem de ticari topluluğun içine girmiş olduğu bir sorundur.

Tasarıya uygun görünen birkaç ticari teklif:

  • FileCatalyst , UDP veya birden fazla TCP akışı kullanarak yüksek gecikmeli ağlar üzerinden veri akışı yapabilen ürünlere sahiptir. Onlar da başka birçok özelliğe sahipler (anında sıkıştırma, delta transferleri, vb.).

  • FASP Aspera'da dosya transferi "teknoloji" sen de, aradığınızı için tasarıyı uygun görünmektedir.

Açık kaynaklı dünyada, UFTP projesi umut verici görünüyor. Özellikle çok noktaya yayın yeteneklerine ihtiyacınız yok, ancak alıcılara bir dosya çıkarma, aktarma sonunda kaybedilen bloklar için NAK alma ve ardından NAK'd bloklarını patlatma (köpürme, durulama, tekrarlama) gibi temel bir fikir İhtiyacınız olanı yapar gibi geliyor, çünkü dosya aktarımı bir kez tamamlanıncaya kadar alıcıdan ACK'laşmıyor (veya NAK'laşıyor). Ağın yalnızca gizli ve kayıp olmadığını varsayalım, bu da ihtiyacınız olanı yapabilir.


uftp gerçekten ümit verici görünüyor, iki masaüstü bilgisayar arasında 30 disk / sn hıza erişebildim (disk performansında kesinlikle çok iyi değil); Yakında "gerçek" sunucularda test edeceğim. Kayıt formundaki bazı hatalardan dolayı FileCatalyst demo lisansı alamadım (istek numarasının zaten kullanıldığını söylüyor) ve fasp bunları sunmuyor.
Massimo

Uygun disklere ve büyük bir alma arabelleğine sahip iki bilgisayar arasında 60 Mbps. Harika!
Massimo

Ücretsiz / açık kaynaklı yazılımı seviyorum! > gülümseyim <Kesinlikle kesinlikle yaptığım bazı şeyleri deneyeceğim. Birkaç yıl önce "udpcast" kullanarak bir araya getirdiğim Linux tabanlı çok noktaya yayın disk görüntüleme çözümünde bunun nasıl olacağını merak ediyorum.
Evan Anderson

bir süre önce serverfault.com/questions/173358/multicast-file-transfers diye sordum Sonunda uftp ve mrsync'in tercih edilen araçlar olduğu sonucuna vardım. Uftp ile yararlı bir şey yaparsanız, bu yıl tekrar kullanacağım gibi bir yorum yaparsanız, lütfen konferansa yazınız.
Jed Daniels

2
UFTP, UDT ve Tsunami UDP ile çalışırken, UFTP üçünün en kötü performansını sergilemiştir. Tabii ki, muhtemelen en olgun protokol. UDT sadece basit bir transfer protokolü sağlar ve özel yazılım geliştirmek için bir kütüphane görevi görecek şekilde tasarlandı ve Tsunami'nin yazarı bizi aslında UDT'ye yöneltti, çünkü Tsunami yakın zamanda aktif olarak geliştirildi.
Thomas Owens,

9

Bu gerçekten garip öneri .. Dosyayı ağınızda barındırmak için basit bir web sunucusu kurun (bu arada nginx'i öneririm), daha sonra diğer ucunda firefox ile bir bilgisayar kurun ve DownThemAll uzantısını kurun .

Parçalama ve yeniden montajı destekleyen bir indirme hızlandırıcısıdır.
Her yüklemeyi yeniden montaj için 10 parçaya bölebilirsiniz, ve aslında işleri daha da çabuklaştırıyor!

(ihmal: 160GB kadar büyük bir şey üzerinde hiç denemedim, ama 20GB iso dosyaları ile iyi çalışıyor)


Aynı bilgisayarlar arasında 40 Mbps. Gerçekten de iyi görünüyor.
Massimo

1
firefox yerine axel.alioth.debian.org ve bu bir öneri değil.
Justin,

7

UDT taşıma muhtemelen yüksek gecikme iletişim için en popüler ulaşım olduğunu. Bu, Sector / Sphere adlı "Yüksek Performanslı Dağıtılmış Dosya Sistemi ve Paralel Veri İşleme Motoru" adlı diğer yazılımlarına bakmaya değer olabilir.


1
Yüksek gecikmeli ve yüksek paket kaybı olan ağlar üzerinden yapılan transferler için UDT ile bazı çalışmalar yaptım. UDT, gecikme ve paket kaybına karşı TCP tabanlı protokollerden çok daha dayanıklıdır, özellikle ağ topografyaya uydurmak için tıkanıklık kontrolü algoritmasını değiştirdikten sonra.
Thomas Owens,

Dahili UDT ile bir rsync sürümü bile var, buna "UDR" deniyor. github.com/LabAdvComp/UDR
Maksimum

5

Cevabım biraz geç oldu ama bu soruyu yeni buldum, fasp'ı ararken. Bu arama sırasında şunu da buldum: http://tsunami-udp.sourceforge.net/ , "Tsunami UDP Protokolü".

Web sitelerinden:

Çok yüksek hızlı uzun mesafeli ağlar üzerinden (≥ 1 Gbps ve hatta 10 GE) aktarım için TCP kontrolü ve UDP verilerini kullanan, aynı ağlar üzerinden TCP ile mümkün olandan daha fazla verim sağlamak için tasarlanmış hızlı bir kullanıcı alanı dosya aktarım protokolü. ağlar.

Hız ilerledikçe, sayfa bu sonuçtan söz eder (1GBit bağlantı üzerinden Helsinki, Finlandiya ile Bonn, Almanya arasındaki bir bağlantıyı kullanarak:

Şekil 1 - İnternet üzerinden uluslararası transfer, ortalama 800 Mbit / saniye

Bir indirme hızlandırıcısı kullanmak istiyorsanız, lftp'ye bir bakın, bu bildiğim kadarıyla özyinelemeli bir ayna yapabilecek tek indirme hızlandırıcısı.


1
Daha önce Steve-o’nun cevabında yorum yaptığım projede, UDT, Tsunami UDP ve UFTP’yi kıyasladık. Gecikmenin performans üzerinde büyük bir etkisi olduğunu, paket kaybının olmadığını (Tsunami belgelerine aykırı olarak) bulduk. Test ağına 100ms gecikme süresi eklemek, Tsunami'nin performansını yaklaşık 250Mbit / saniye'den yaklaşık 50Mbit / saniye'ye düşürdü (sayılarım ve birimlerimin doğru olduğuna inanıyorum - bir süre oldu, ancak çok büyük bir düşüş oldu). Öte yandan,% 10'luk bir paket kaybı eklemek için minimum gecikme ağı yoktur, ancak performansı yalnızca 250Mbit / saniye'den yaklaşık 90Mbit / saniye'ye düşürmüştür.
Thomas Owens

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.