Büyük dosyayı bir Linux sunucusundan diğerine kopyala

LA veri merkezimizde bir Linux sunucusundan NY veri merkezimizde 10MB bağlantı üzerinden başka bir Linux sunucusuna 75 gigabayt tgz (mysql lvm anlık görüntüsü) kopyalamaya çalışıyorum.

200-300 saat arasında dalgalanan rsync veya scp ile yaklaşık 20-30Kb / s alıyorum.

Şu anda nispeten sessiz bir bağlantı çünkü ikinci veri merkezi henüz aktif değil ve küçük dosya aktarımlarından mükemmel hızlar aldım.

Ben google üzerinden boşuna buldum farklı tcp ayar kılavuzları izledim (belki yanlış kılavuzları okuyorum, iyi bir tane var?).

Tar + netcat tünel ipucunu gördüm, ama benim anlayışım sadece küçük dosyalar LOTS için iyi bir dosya etkili aktarma bittiğinde sizi güncellemiyor.

Bir sabit diski göndermeye başlamadan önce, iyi bir girişi olan var mı?

GÜNCELLEME: Şey ... şu bağlantı olabilir :( Aşağıdaki testlerime bakın ...

NY'dan LA'ya transferler:

Boş bir dosya alınıyor.

[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

Anlık görüntü tarball elde ediliyor.

[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'dan NY'ye transferler:

Boş bir dosya alınıyor.

[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

Anlık görüntü tarball'ı gettting.

[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

Sanırım tesislerimizi işleten insanlarla bağlantı kuracağım, bağlantı MPLS / Ethernet 10MB bağlantısı olarak etiketlendi. (Silkme)

Sneakernet Kimse?

Bunun tek seferlik bir kopya olduğunu varsayarsak, dosyayı bir CD'ye (veya başka bir ortama) kopyalamayı ve bir gecede hedefe varmayı düşünmüyorum?

Bu boyuttaki bir dosya aktarımı, bu bağlantı üzerinden doğru şekilde kopyalanmayabileceğinden aslında en hızlı seçeneğiniz olabilir ... bu durumda baştan başlayabilirsiniz.

rsync

İkinci tercihim / denemem başarısız transferleri, kısmi transferleri vb. Tespit ettiğinden ve kaldığı yerden devam edebildiğinden rsync olacaktır.

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

--Progress flag sadece orada oturmak ve ikinci tahmininizi bırakmak yerine size geri bildirim verecektir. :-)

Vuze (bittorrent)

Üçüncü seçenek muhtemelen Vuze'yi torrent sunucusu olarak kullanmayı denemek ve daha sonra uzak konumunuzun indirmek için standart bir bitorrent istemcisi kullanmasını sağlamaktır. Bunu yapan başkalarını biliyorum ama biliyorsunuz ... herşeyi kurduklarında, vb. Veriyi abartmış olabilirim ...

Durumunuza bağlı sanırım.

İyi şanslar!

GÜNCELLEŞTİRME:

Bilirsiniz, sorununuzu biraz daha düşünmeye başladım. Dosya neden tek bir dev tarball olmalı? Tar, büyük dosyaları daha küçük dosyalara bölebilir (örneğin, medyayı yaymak için), bu yüzden neden bu büyük tarball'ı daha yönetilebilir parçalara bölmüyor ve bunun yerine parçaları aktarmıyorsunuz?

Bunu geçmişte 60GB'lık bir tbz2 dosyasıyla yaptım. Artık betiğim yok ama yeniden yazmak kolay olmalı.

İlk olarak, dosyanızı ~ 2GB parçalara bölün:

split --bytes=2000000000 your_file.tgz

Her parça için bir MD5 karması hesaplayın (bu bütünlüğü kontrol etmek içindir) ve bir yerde saklayın, ardından parçaları ve md5'lerini seçtiğiniz araçla uzak siteye kopyalamaya başlayın (ben: bir ekranda netcat-tar-pipe oturum, toplantı, celse).

Bir süre sonra parçalarınızın iyi olup olmadığını md5 ile kontrol edin, sonra:

cat your_file* > your_remote_file.tgz

Orijinal dosyanın MD5'ini de yaptıysanız, dosyayı da kontrol edin. Sorun yoksa, dosyanızı açabilirsiniz, her şey yolunda olmalıdır.

(Zamanı bulursam senaryoyu yeniden yazacağım)

Normalde rsync'in büyük bir savunucusuyum, ancak tek bir dosyayı ilk kez aktarırken çok mantıklı görünmüyor. Bununla birlikte, dosyayı sadece küçük farklılıklar ile yeniden aktarıyorsanız, rsync açık kazanan olacaktır. Yine de rsync kullanmayı seçerseniz --daemon, performans öldüren ssh tünelini ortadan kaldırmak için modda bir uç çalıştırmanızı şiddetle tavsiye ederim . Kılavuz sayfasında bu mod ayrıntılı olarak açıklanmaktadır.

Benim önerim? Kesilen indirmeleri sürdürmeyi destekleyen sunucular ve istemcilerle FTP veya HTTP. Her iki protokol de ssh-tünel cezasından kaçınarak hızlı ve hafiftir. Apache + wget hızlı bir şekilde çığlık atardı.

Netcat boru hilesi de iyi çalışır. Tek bir büyük dosyayı aktarırken katran gerekli değildir. Ve bittiğinde bunu size bildirmemesinin nedeni, bunu söylemediğiniz için. -q0Sunucu tarafına bir bayrak ekleyin , tam olarak beklediğiniz gibi davranacaktır.

sunucu $ nc -l -p 5000> outfile.tgz

istemci $ nc -q0 server.example.com 5000 <infile.tgz

Netcat yaklaşımının dezavantajı, transferiniz 74GB'da ölürse devam etmenize izin vermemesidir ...

Netcat'e (bazen nc de denir) bir şans verin. Aşağıdakiler bir dizinde çalışır, ancak yalnızca bir dosyayla başa çıkmak için ince ayar yapmak yeterince kolay olmalıdır.

Hedef kutusunda:

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

Kaynak kutusunda:

tar czf * | netcat target_box 2342

Dosya zaten sıkıştırılmış olduğundan biraz daha fazla hız görmek için her iki tar komutundaki 'z' seçeneğini kaldırmayı deneyebilirsiniz.

Varsayılan SCP ve Rsync (SCP kullanan) büyük dosyalar için çok yavaştır. Ben daha düşük yük ile bir protokol kullanarak bakmak istiyorum sanırım. Daha basit bir şifreleme şifrelemesi kullanmayı denediniz mi yoksa hiç kullanmadınız mı? --rshAktarım yöntemini değiştirmek için rsync seçeneğine bakmayı deneyin .

Neden FTP veya HTTP olmasın?

Duruma biraz ek yük getirmesine rağmen, BitTorrent aslında büyük dosyaları aktarmak için gerçekten güzel bir çözümdür. BitTorrent, bir dosyayı yerel olarak parçalamak ve her bir yığını kontrol etmek gibi birçok güzel özelliğe sahiptir, bu da bozuksa yeniden iletilebilir.

Azureus [şimdi Vuze olarak bilinen] gibi bir program , torrentleri tek bir uygulamada oluşturmak, sunucuya indirmek ve indirmek için ihtiyacınız olan tüm parçaları içerir. Bean akılda Azureus, BitTorrent için mevcut çözümlerin en yalın değil ve sanırım onun GUI'sini de gerektiriyor - linux için çok fazla komut satırı tahrikli torrent aracı var.

Kişisel olarak, 20-30Kb / s, 10 Mb (10 MB ve 10 MB değil) bağlantısı için oldukça düşük görünüyor.

Ben olsaydım, iki şeyden birini yapardım (fiziksel erişimin olmadığı varsayılarak) -

Ya biri, büyük dosyayı daha küçük parçalara bölmenizi tavsiye ederim, yaklaşık 500MB Sadece transit yolsuzluk durumunda.

Daha küçük parçalara sahip olduğunuzda, ya rsync'i tekrar kullanın ya da ben şahsen özel bir Güvenli ftp oturumu kullanmayı ve sonra da tamamlandıktan sonra dosyaları CRC'yi tercih ederim.

Tartışmalarda birkaç soru yardımcı olabilir: Verilerin aktarılması ne kadar kritik? Bu olağanüstü durum kurtarma, etkin yedekleme, çevrimdışı depolama veya ne için? Veritabanını yukarı veya aşağıyken yedeklemeyi mi planlıyorsunuz? Peki ya uzak sistemde bir veritabanı ayarlamak ve kümeleme veya changelogs üzerinden güncelleme kullanarak senkronize tutmak hakkında (Ben tamamen bir MySql veritabanı sisteminin yetenekleri konusunda bilgili değilim). Bu, bağlantı yoluyla aktarılması gereken veri miktarını azaltmaya yardımcı olabilir.

bbcp dosyayı sizin için yığınlar ve çoklu akışlarla kopyalar.

Google çalışanları için geç cevap:

Büyük veri kümelerini aktarırken, rsync kaynağı ve hedefi karşılaştırmak için kullanılabilir, ardından --only-write-batch bayrağını kullanarak yerel bir çıkarılabilir ortama bir toplu iş dosyası yazar. Daha sonra değişiklikleri uzak veri kümesine dahil etmek için --read-batch komutunu kullanarak yerel ortamı uzak konuma gönderip, takın ve rsync'i yeniden çalıştırın.

Fiziksel aktarım sırasında kaynak dosyalar değişirse veya aktarım ortamı dolarsa, --only-write-batch | gemi | - hedef yakalanana kadar ok-toplu işlem döngüsü.

(Ref: rsync'de bu özelliğin yazarlarından biriydim - daha fazla arka plan ve kullanım örneği için, prototip uygulamasının şu tartışmasına bakın: https://lists.samba.org/archive/rsync/2005-March/011964 .html )