Soru ABD'den İngiltere veri merkezine 10 TB dosya aktarma


Sunucumu ABD'den İngiltere'ye bir veri merkezinden diğerine taşıyorum. Ev sahibim saniyede 11 megabayt elde edebilmem gerektiğini söyledi.

İşletim sistemi her iki uçta Windows Server 2008'dir.

Ortalama dosya boyutum yaklaşık 100 MB'tır ve veriler beş adet 2 TB'lık sürücüye bölünmüştür.

Bu dosyaları aktarmak için önerilen yol ne olurdu?

  • FTP
  • SMB
  • Rsync / Robocopy
  • Diğer?

Güvenlik hakkında çok fazla rahatsız değilim, çünkü bunlar genel dosyalar olsa da, toplam transfer süresini en aza indirmek için tam 11 MB / s aktarım hızını zorlayabilecek bir çözüm istiyorum.


91
2017-10-03 20:03


Menşei


11 MB / sn veya 11 Mb / sn? - wim
verileri ikili zımba kartına aktarın ve bir taşıyıcı güvercin kullanın :) - enterzero
Detay vermelisin. Ne kadar taşıyıcı güvercin alacağını düşünüyorsun? İşini göster. - Evik James
@Evik Avrupa veya Afrika mı? - wim
Bir kenara göre, Wolfram Alpha hesaplamayı yapmanın en uygun yolu, "11MB / s 'de 10 TB". wolframalpha.com/input/?i=10+TB+at+11MB%2Fs - pufferfish


Cevaplar:


Okyanus yerine sabit diskleri gönderin.

Tam kullanımla birlikte 11 Mbps'de, 10 TB'yi aktarmak için 90 gün süren utangaç bir duruma bakıyorsunuz.


11 Mbps = 1.375 MBps = 116.015 GB / gün.

10240 GB / 116.015 GB / gün = ~ 88.3 gün.


171
2017-10-03 20:14



İçin +1 Sneakernet. Ayrıca, TCP / IP ek yükünü de unutmuştunuz. İdeal koşullar altında ~ 100 gün gibi daha fazla. - Chris S
Bilge bir adam bir keresinde "Otoyoldan aşağı düşen kasetlerle dolu bir istasyon vagonu bant genişliğini asla hafife almaz" dedi. Bu denklem çok doğrudur ve bir tekne için istasyon vagonu değiştirilerek büyük ölçüde değiştirilmemiştir. (bpfh.net/sysadmin/never-underestimate-bandwidth.html) - Rob Moir
Sürücülerden ziyade bantları veya blueray diskleri göndermek daha iyidir. Sürücülerle giderseniz, orijinallerin her durumda güvenli ve kullanılabilir durumda olduğundan emin olun. Sürücülere kendim giderdim (Ultrium 4 sürücülerim olmadıkça) çünkü 10 TB = 410 tek katmanlı blueray disk! - Allen
Sadece 11Mbps yazdığımı fark ettim, ancak aslında 11MB / s olduğunu söyledim. Sanırım bu oldukça büyük bir fark yaratıyor, hesaplamalarım yaklaşık 11-14 gün civarında kabaca ... bu doğru mu? - Paul Hinett
hala resmi disk hala çalışıyor sonra bir kez 10TB yedekleme ile bir adam nezaret gönderiyor, o zaman kurulum yapıldıktan sonra, yeni sunucu herhangi bir değişiklik için güncelleştirmek için bir rsync öğle yemeği yiyebilirsiniz. Makinenizi yaklaşık bir gün içinde çalıştırıyorsunuz. - Loïc Faure-Lacroix


Rsync diyorum, 11 MB / s'de 10-14 güne bakarsınız ve kesintiye uğruyor olsanız bile, rsync kolayca son durağı nerede duracaktır.

11 Mbps'de yukarıda önerildiği gibi sabit diskleri gönderirdim :)


25
2017-10-03 22:00



Tahmininiz, başkalarının gönderdiğilerden çok farklıdır (ve kimin doğru olduğunu bilmiyorum). Bu rakamlara ulaşmak için metodolojinizi temin edebilir misiniz? - John Gardeniers
Bu fark aslında 11 MBps anlamına geldiği zaman 11 MB / sn hızaşırtmadır - ki bu 8 kat daha hızlıdır. BTW, bir kesinti durumunda 10 TB'lik bir rsync'i yeniden başlatmaya muhtemelen bir süre kalacaktır, değil mi? Saat mi, daha mı uzun? - Frank Farmer
@FrankFarmer: rsync'in yeniden başlatılması konusunda endişelenmem; 30Mbps kablosuz hat üzerinden ~ 20TB'lik bir site dışı kopyasını saklıyorum ve yeniden başlatmak saniye aralığında. İlk kopya birkaç hafta sürdü, ancak gece güncellemesi genellikle birkaç saat sürüyor. - Javier
@FrankFarmer - rsync çok iyi görünüyor. Sneakernet ile initalised bir kırsal ADSL1 hattı üzerinde ~ 2TB var, ama hiçbir şey değişmezse her gece rsync için ~ 5 dakika sürer. - Flexo
rsync restart zamanı dosya sayısı ile ölçeklendirilir. stat Zaman, benim deneyimimde), toplam veri ile değil. Önemli bir bekleme beklemem (en fazla birkaç dakika). Rsync ile deneyimlerim 5 TB'ın biraz altında olsa da. - derobert


Elbette Rsync.

En azından bir aradan sonra herhangi bir zamanda devam edebilirsiniz, ve hiç acı çekmeden.


14
2017-10-03 20:07



% 100 kullanımda kopyalamak için 3+ ay. Üzgünüm, ama bu kadar veri aktarmanın korkunç bir yolu. - Chris S
Kullanarak @ChrisS ile katılıyorum rsync sadece büyük dosyaları kopyalamak için verimli değildir. Eşyalarım için bitti tar üzerinde netcat veya ssh ilk transfer için. Çok daha hızlıdır ve hemen aktarılmaya başlar. rsync Önce tüm dosyaları tarar, zaman alır. Bu kesintiye uğruyorsa hala kullanabilirsiniz rsync sonradan. Aslında bunu bazen sonra yaparım tar Yine de tüm izinleri, soket dosyalarını vb. sağlamak için doğrudur. - Martin Scharrer
OP, 100Mb bağlantıya sahip olduğunu doğruladıktan sonra, 11Mb değil, rsync daha mantıklı. İlk bahsetmek için +1. - Chris S


Bantlarla dolu bir istasyon vagonunun bant genişliğini asla hafife almayın

- Trad.

Sizin durumunuzda, kurye ile gönderilen diskler veya şeritler, ancak prensip hala geçerlidir. Gecikme konusunda endişe duymuyorsanız, bu, ağ bant genişliğinden 10 TB veriyi makul bir süre içinde aktarmak için çok daha ucuz olacaktır.


11
2017-10-04 11:32



Jeff Atwood, eski Coding Horror mesajlarından birinde numarayı koştu. codinghorror.com/blog/2007/02/the-economics-of-bandwidth.html - tardate


Rsync kullanmalısın. Olacak kompres veri ve de-yinelenen göndermeden önce. Ayrıca, büyük transferler için çok önemli olan kısmi transferleri de başlatabilir.

Muhtemelen 10 TB transfer etmez; eğer kütükler ve metinler varsa ve 1 TB'ın altında olabilir; belki de 1 TB'nin altında.

Rsync'ten daha iyi bir sıkıştırma işi yapan ve muhtemelen daha fazla eşleşme bulabileceğiniz araçlar vardır. Kullanabilirsin lrzip, vb.

İyi sıkıştırılmamış ve edebi kopyaları içermeyen belirli türde veriler vardır - örneğin videolar ve diğer ortamlar. Bu durumlarda, FTP ve rsync aynı çabayı gösteriyorlar.


9
2017-10-04 08:02



RSync verileri tekrarlar mı? Bunun sadece dosya düzeyinde olduğunu düşünüyorum, yani tekilleştirme bu durumda çoğunlukla işe yaramaz. - devicenull


Bunun zaten kabul edildiğini biliyorum, ancak disklerinizi daha fazla bant genişliği alabileceğiniz bir veri merkezine / sağlayıcısına / ana bilgisayarına almayı düşündünüz mü? Muhtemelen biraz paraya mal olacak ama yedek disklere 10240Gb kopyalama ve gönderme hem zaman hem de paraya mal olacak (2 x para).

Ayrıca disklerin nakliye sırasında kırılmadığından emin olursunuz.


5
2017-10-04 07:13



Bu cevap kabul edilen cevaptan farklı mıdır? - Chris S
@Chris Bu cevap, disklerin aynı kıtada daha büyük bir boruya taşınmasını öneriyor. - Alex Jasmin


11Mbps? Bu, burada sahip olduğunuz bir sınırlama. Durumunda ben basitçe:

  • Verileri kopyalayın
  • Sıkıştır
  • Her iki uçtaki sunucuları, en az 10 kat daha fazla bant genişliği ile kiralayın (aynı veri merkezlerinde veya yakınınızdaki bir veri merkezinde).
  • Dosyaları aktar
  • Verileri yeni sunucuya uygulayın.

Bant genişliğini artırmak için gerçekten bir çözümünüz yoksa ... Daha sonra bir fiziksel sürücü göndermek daha hızlı olacaktır.

Acı verici deneyimimden, sabit sürücüler postada kırılma eğilimindedir ... USB flash sürücüler, sık veri aktarımları için daha iyi bir çözümdür. Durumunuzda bunlardan birkaçını gerektirecektir :) Bu yüzden verilerinizin 2 kopyasını birden çok sabit sürücüye gönderin.

Sahip olduğunuz veri miktarını göz önünde bulundurarak, sürücülerinizi takmak için diğer donanım ve yazılımlara sahipseniz, bir RAID 5 veya RAID 6 dizisinden sürücüler gönderebilirsiniz. Ancak bu durumda, sürücülerinizin sırasını işaretlemeyi unutmayın. ve seri numaraları, yeniden konfigüre edilirken karışıklaşmazlar.


4
2017-10-04 00:15



Üzgünüm, 11Mbps bir mistype oldu, 11MB / s ... Yukarıdaki yorumlardan birinde bahsetti. - Paul Hinett


Bu davada "harddrives kullanarak gönder" cevabını kabul etmem gerekirken, burada büyük miktarlarda dosyaları ilk defa kopyalamak zorunda kaldığımda kullanacağım bir kopya çözümü:

Süre rsync iki veri deposunu senkronize tutmak iyi bir şeydir, ilk transfer için oldukça fazla gereksiz ek yük getirir. En hızlı yolun tar hangi boruların üzerinden geçiyor netcat. Alıcı sitesinde de kullanabilirsiniz netcat içinde dinlemek gelen veriyi ayıklamaya yönlendiren mod tar. Faydası tar hemen göndermeye başlar ve netcat ekstra bir üst düzey protokol ek yükü olmadan düz TCP akışı olarak gönderir. Bu, aldığı kadar hızlı olmalı. Bununla birlikte, son konumda kesintili bir aktarımı tekrar başlatmak mümkün değildir.

Aktarım için verileri doğru kullanarak sıkıştırmak da kolayca mümkündür. tar Seçenekler veya borularda bir sıkıştırma aracı ekleyin. Bunu not et netcat şifrelenmemiş tarihi gönderir. Bunun bir seçenek olmadığı durumlarda, şifreli ssh bağlantı yerine kullanılabilir (tar <options> | ssh <target> -c 'tar -x <options>').

Tüm veriler aktarılırsa rsync Bu arada güncellenen tüm dosyaların senkronize edildiğinden emin olmak için kullanılabilir. Ayrıca IIRC tar Aksi halde kaybolacak olan yuva oluşturmaz, ancak veri merkezi verileri için gerçekten kullanılmazlar.


3
2017-10-04 07:36



Dezavantajı, intersttions toleransı değil - Joel Coel


Düşündün mü IPoAC?

Tek bir güvercin, gigabaytlarca veriyi yaklaşık bir saat içinde taşıyabilmektedir; bu, ortalama bant genişliği temelinde, kayıp disklerin hesaplanmasında bile geçerli ADSL standartlarına oldukça uygundur.


2
2017-10-04 02:08



Güvercinler OP tarafından açıklanan mesafede sinyal kaybına uğrayacaktı. - Roy Tinker
@RoyTinker Temizle IPoAC ihtiyaçları bir pencere oluşturma işlemi kullanılarak gerçekleştirilmelidir. - JamesBarnett