İki sunucu arasında çok sayıda dosyayı hızlıca kopyalama

İki porsiyon arasında büyük miktarda mp3 aktarmam gerekiyor (Ubuntu). Çok büyük, ortalama olarak 300.000 dosya olan milyonlarca dosyayı kastediyorum. Denedim scpama yaklaşık bir hafta sürerdi. (yaklaşık 500 KB / sn) Tek bir dosyayı HTTP ile aktarırsam, 9-10 MB / sn alırım, ancak hepsinin nasıl aktarılacağını bilmiyorum.

Hepsini hızlı bir şekilde transfer etmenin bir yolu var mı?

Katran tavsiye ederim. Dosya ağaçları zaten benzer olduğunda, rsync çok iyi performans gösterir . Ancak, rsync her dosya üzerinde birden fazla analiz geçişi yapacağından ve değişiklikleri kopyaladığından, ilk kopya için tar'dan çok daha yavaştır. Bu komut muhtemelen ne istersen onu yapacak. Dosyaları makineler arasında kopyalamanın yanı sıra hem izinleri hem de kullanıcı / grup sahipliğini korur.

tar -c /path/to/dir | ssh remote_server 'tar -xvf - -C /absolute/path/to/remotedir'

Mackintosh'un aşağıdaki yorumuna göre bu, rsync için kullanacağınız komuttur.

rsync -avW -e ssh /path/to/dir/ remote_server:/path/to/remotedir

Harici sabit disk ve aynı gün kargo teslimatı.

Ben rsync kullanırdım.

Bunları HTTP üzerinden dizin listeleri ile birlikte verdirdiyseniz, wget ve --mirror argümanlarını da kullanabilirsiniz.

Zaten HTTP’nin SCP’den daha hızlı olduğunu görüyorsunuz, çünkü SCP her şeyi şifreliyor (ve böylece CPU’da tıkanıyor). HTTP ve rsync daha hızlı hareket edecek çünkü şifrelenmiyorlar.

İşte Ubuntu'da rsync'i kurmaya ilişkin bazı dokümanlar: https://help.ubuntu.com/community/rsync

Bu dokümanlar SSH üzerinden rsync tünelini anlatmaktan bahseder, ancak verileri yalnızca özel bir LAN'da dolaştırıyorsanız, SSH'ye ihtiyacınız yoktur. (Özel bir LAN'da olduğunuzu farz ediyorum. İnternet üzerinden 9-10 MB / sn alıyorsanız, o zaman ne tür bağlantılara sahip olduğunuzu bilmek istiyorum!)

Göreceli olarak güvensiz bir rsync sunucusu (SSH'ye bağımlılık olmadan) kurmanıza izin verecek diğer bazı temel belgeler: http://transamrit.net/docs/rsync/

Çok tartışma olmadan, netcat, ağ swissarmy bıçağı kullanın. Protokol yükü yok, doğrudan ağ soketine kopyalıyorsunuz. Örnek

srv1$ tar cfv - *mp3 | nc -w1 remote.server.net 4321

srv2$ nc -l -p 4321 |tar xfv -

Eğer rsync ile giderseniz , her iki uçta da sürüm 3 veya üstü elde etmeye çalışırım . Bunun nedeni, daha düşük bir sürümün aktarım başlamadan önce her dosyayı numaralandırmasıdır. Yeni özelliğe artımlı özyineleme denir .

Rsync başka bir 3.x sürümüyle konuşurken şimdi yeni bir artımlı özyinelemeli algoritma kullanılıyor. Bu, aktarımı daha hızlı işlemeye başlar (tüm dosyalar bulunmadan önce) ve daha az bellek gerektirir. Bazı kısıtlamalar için kılavuzdaki --recursive seçeneğine bakın.

rsync, diğerleri gibi zaten tavsiye etti. Şifrelemeden gelen CPU ek yükü bir tıkanıklıksa, blowfish gibi başka bir daha az CPU yoğun algoritması kullanın. Örneğin bir şey

rsync -ax -e 'ssh -c blowfish' /local/path user@host:/remote/path

Geçiş verilere dün (minik dosyaların milyonlarca), 80 TB hareketli olarak rsynchiç tar kanıtladı çok daha hızlı olması için biz çalışıyorum durdu olarak,

# slow
rsync -av --progress /mnt/backups/section01/ /mnt/destination01/section01

ve tarbunun yerine ...

# fast
cd /mnt/backups/
tar -cf - section01 | tar -xf - -C /mnt/destination01/ 

Bu sunucular aynı LAN’da bulunduğundan, hedef, itme işlemini yapan kaynak sistemde NFS takılıdır. Hayır daha hızlı hale getirin atime, dosyaların korunmamasına karar verdik :

mount -o remount,noatime /mnt/backups
mount -o remount,noatime /mnt/destination01

Aşağıdaki grafik rsync'den tar 'ya yapılan değişimi göstermektedir. Bu benim oldu patronun fikri ve benim meslektaşım hem de infaz ve büyük yapılan blogunda writeup . Ben sadece güzel resimlerden hoşlanırım . :)

Çok sayıda dosyayı kopyalarken, tar ve rsync gibi araçların birçok dosyayı açma ve kapama yükü nedeniyle olmaları gerekenden daha yetersiz olduğunu buldum. Bu senaryolar için katrandan daha hızlı olan fast-archiver adlı bir açık kaynak aracı yazdım: https://github.com/replicon/fast-archiver ; aynı anda birden fazla dosya işlemi gerçekleştirerek daha hızlı çalışır.

İşte iki milyondan fazla dosyanın yedeğinde hızlı arşivleyici ve tar örneği; hızlı arşivleme, arşivlemeye 27 dakika, katranla 1 saat 23 dakika sürüyor.

$ time fast-archiver -c -o /dev/null /db/data
skipping symbolic link /db/data/pg_xlog
1008.92user 663.00system 27:38.27elapsed 100%CPU (0avgtext+0avgdata 24352maxresident)k
0inputs+0outputs (0major+1732minor)pagefaults 0swaps

$ time tar -cf - /db/data | cat > /dev/null
tar: Removing leading `/' from member names
tar: /db/data/base/16408/12445.2: file changed as we read it
tar: /db/data/base/16408/12464: file changed as we read it
32.68user 375.19system 1:23:23elapsed 8%CPU (0avgtext+0avgdata 81744maxresident)k
0inputs+0outputs (0major+5163minor)pagefaults 0swaps

Sunucular arasında dosya aktarmak için ssh ile fast-archiver kullanabilirsiniz:

ssh postgres@10.32.32.32 "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x

Ben katran netcatyaklaşımı yoluyla da kullanıyorum, kullanmayı tercih etmem dışında socat- durumunuzu optimize etmek için çok daha fazla güç - örneğin, mss tweaking yaparak. (İsterseniz gülün, ama socattutarlı olduklarından argümanları hatırlamayı daha kolay buluyorum ). Bu yüzden benim için, son zamanlarda çok yaygın bir şey çünkü yeni şeyleri yeni sunuculara taşıdım:

host1$ tar cvf - filespec | socat stdin tcp4:host2:portnum

host2$ socat tcp4-listen:portnum stdout | tar xvpf -

Takma adlar isteğe bağlıdır.

Diğer bir alternatif ise Unison . Bu durumda Rsync'ten biraz daha verimli olabilir ve bir dinleyiciyi kurmak biraz daha kolaydır.

En iyi yanıtta birkaç yazım hatası olabilir. Bu daha iyi işe yarayabilir:

tar -cf - /path/to/dir | ssh remote_server 'tar -xvf - -C /path/to/remotedir'

• Ağ Dosya Sistemi (NFS) ve daha sonra istediğiniz şekilde kopyalayın, örneğin Midnight Commander (mc), Nautilus (gnome'dan). NFS v3'ü iyi sonuçlarla kullandım.
• Samba (CIFS) ve daha sonra istediğiniz şekilde dosyaları kopyalayın, ancak ne kadar etkili olduğu konusunda hiçbir fikrim yok.
• HTTP ile wget --mirrorolarak Evan Anderson önerilen veya herhangi diğer http istemci gelmiştir. Kötü bir sembolik link veya aldatıcı indeks dosyalarının olmamasına dikkat edin. Tek sahip olduğunuz MP3 ise, güvende olmalısınız.
• RSync . Oldukça iyi sonuçlarla kullandım ve hoş özelliklerinden biri de aktarımı daha sonra kesip devam ettirebilmeniz.

Diğer kişilerin netcat kullanmasını önerdiğini fark ettim . Bununla ilgili tecrübelerime dayanarak , diğer çözümlerle kıyaslandığında yavaş olduğunu söyleyebilirim.

Scott Pack'in harika cevabı sayesinde (bunu daha önce ssh ile nasıl yapacağımı bilmiyordum), bu iyileştirmeyi önerebilirim ( bashkabuğunuz varsa ). Bu paralel sıkıştırma, bir ilerleme göstergesi ekleyecek ve ağ bağlantısı boyunca bütünlüğü kontrol edecektir:

tar c file_list |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        tar xC /directory/to/extract/to
    '

pvborunuz için güzel bir ilerleme görüntüleme programıdır ve pigzCPU'nuzun varsayılan olarak sahip olduğu kadar çok iş parçacığı kullanan paralel bir gzip programıdır (8 max'a kadar inanıyorum). Sen ayar sıkıştırma seviyesi daha iyi bant genişliği ağ ile takas etmek CPU oranı uyacak şekilde yapabilirsiniz pxz -9eve pxz -dsize bant genişliği çok daha fazla CPU varsa. Sadece iki toplamın tamamlandığında eşleştiğini doğrulamanız gerekir.

Bu seçenek çok fazla miktarda veri ve yüksek gecikmeli ağlar için kullanışlıdır, ancak bağlantı kararsızsa ve düşerse çok yararlı olmaz. Bu gibi durumlarda, rsync muhtemelen devam edebildiği en iyi seçimdir.

Örnek çıktı:

6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -                     ]
 176MiB [9.36MiB/s] [9.36MiB/s] [                                            <=>                                                                        ]
6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -

Blok cihazlar için:

dd if=/dev/src_device bs=1024k |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        dd of=/dev/src_device bs=1024k
    '

Açıkçası, count =, skip =, seek =, vb. İle aynı boyutta veya sınırda olduklarından emin olun.

Dosya sistemlerini bu şekilde kopyaladığımda, çoğu zaman ilk önce dd if=/dev/zero of=/thefs/zero.dat bs=64k && sync && rm /thefs/zero.dat && umount /thefsxfer'i hızlandıran, kullanılmayan alanın sıfırını alırım.

Daha hızlı ağ kartları takmadığınız sürece scp'den daha iyisini yapacağınızı sanmıyorum. Bunu internet üzerinden yapıyorsanız, bunun bir yardımı olmaz.

Rsync kullanmanızı tavsiye ederim . Daha hızlı olmayabilir, ama en azından başarısız olursa (veya çok uzun sürdüğü için kapattıysanız), bir dahaki sefere kaldığınız yerden devam edebilirsiniz.

2 makineyi doğrudan gigabit ethernet kullanarak bağlayabilirseniz, muhtemelen en hızlısı olacaktır.

100Mb / s için teorik verim 12.5 MB / s, yani 10MB / s'de gayet iyi gidiyorsunuz.

Ayrıca, muhtemelen ssh aracılığıyla rsync yapma önerisini de yankıladım. Gibi bir şey:

rsync -avW -e ssh $SOURCE $USER@$REMOTE:$DEST

100Mb / s'de CPU'larınız veri hızını önemli ölçüde etkilemeden şifrelemeyi / şifresini çözebilmelidir. Veri akışını keserseniz, kaldığınız yerden devam edebilmeniz gerekir. Dikkat edin, "milyonlarca" dosyayla, başlangıçta bir şey aktarılmadan önce biraz zaman alacaktır.

Oracle loglarını aktarmam dışında, bununla karşılaştım.

İşte dağılım

• scp

  inefficient and encrypted (encrypted = slower than unencrypted 
  depending on the link and your processor) 
  

• rsync

  efficient but typically encrypted (though not necessarily)
  

• FTP / HTTP

  both seem to be efficient, and both are plaintext. 
  

FTP'yi büyük başarı ile kullandım (büyük başarının Gb ağında ~ 700Mb / s'ye eşit olduğu). 10 MB alıyorsanız (80 MB / sn'ye eşit), muhtemelen bir sorun var.

Verilerin kaynağı ve hedefi hakkında bize ne söyleyebilirsiniz? Tek sürücüye tek sürücü mü? RAID USB'ye mi?

Bu sorunun zaten bir cevabı olduğunu biliyorum, ancak ağınız bir Gb / s geçit kablosunda bu kadar yavaş gidiyorsa, kesinlikle düzeltilmesi gereken bir şey var.

İki makinenin aynı LAN’da olup olmadığını veya güvenli bir kanalın (yani SSH kullanarak) zorunlu olup olmadığını söylemediniz, ancak kullanabileceğiniz başka bir araç da netcat .

Alıcı makinede aşağıdakileri kullanırdım:

cd <destdir>
netcat -l -p <port> | gunzip | cpio -i -d -m

Sonra gönderen tarafta:

cd <srcdir>
find . -type f | cpio -o | gzip -1 | netcat <desthost> <port>

Aşağıdaki avantajlara sahiptir:

• Ssh'nin sahip olduğu şifreleme için CPU ek yükü yok.
• gzip -1Maksimum verim korurken sıkıştırma biraz vererek iyi bir trade-off yapar böylece bir CPU doyurmaksızın ışık sıkıştırma sağlar. (Muhtemelen MP3 verisi için bu kadar avantajlı değil, ama acı vermiyor.)
• Dosyaları gruplara ayırabilirseniz, iki veya daha fazla sayıda boruyu paralel olarak çalıştırabilir ve gerçekten ağ bant genişliğinizi doyurduğunuzdan emin olabilirsiniz.

Örneğin,

find <dir1> <dir2> -type f | cpio -o | gzip -1 | netcat <desthost> <portone>
find <dir3> <dir4> -type f | cpio -o | gzip -1 | netcat <desthost> <porttwo>

Notlar:

• Her ne şekilde transfer olursanız olun, muhtemelen herşeyi aldığınızdan emin olmak için rsync ya da birlik kuracağım .
• İsterseniz taryerine kullanabilirsiniz cpio.
• Ssh kullanmaya başlasanız bile, herhangi bir sıkıştırma kullanmamasını ve gzip -1CPU doygunluğunu önlemek için kendiniz içinden boru kullanmamasını temin ederim . (Ya da en azından CompressionLevel'i 1'e ayarlayın.)

Uygun seçeneklere sahip basit bir scp, LAN üzerinden 9-10 MB / s'ye kolayca ulaşabilir:

scp -C -c arcfour256 ./local/files.mp3 remoteuser@remoteserver:/opt/remote

Bu seçeneklerle, verimin, seçeneklerden daha fazla 4x veya 5 kat daha hızlı olması olasıdır (varsayılan)

Eğer src tarafında ftp sunucusu varsa, kullanabilirsiniz ncftpget gelen ncftp sitede . Dahili olarak tar kullandığı için küçük dosyalar ile mükemmel çalışır.

Bir karşılaştırma bunu gösteriyor: 1.9GB küçük dosyaları taşıma (33926 dosya)

1. Scp kullanımı 11m59s alır
2. Rsync kullanmak 7m10s sürer.
3. Ncftpget kullanmak 1m20s sürer.

Transferinizi yapmak için BBCP komutunu kullanmayı da deneyebilirsiniz. Gerçekten çığlık atan tamponlu bir paralel ssh. Boruyu besleyebilmemiz koşuluyla genellikle% 90 + hat oranı elde ederiz.

$ bbcp -s 8 -w 64M -N io 'tar -cO srcdirectory' desthostname:'tar -x -C destdir'

Normalde, yeterince hareket etmemek için çok çaba sarfederiz. Her zaman sadece daha fazla disk alanı ekleyebileceğimiz ZFS havuzlarını kullanıyoruz. Ama bazen ... bir şeyleri taşımak zorundasın. Tam patlamaya devam ederken bile kopyalanması saatler (veya günler) alabilen "canlı" bir dosya sistemimiz varsa .. iki adım zfs rutin gönderir:

1. Bir ZFS anlık görüntüsü alın ve yeni makinedeki yeni havuza aktarın. Sürdüğü kadar sürsün.
2. İkinci bir anlık görüntü alın ve artımlı olarak gönderin. Artımlı anlık görüntü yalnızca ilkinden beri (çok daha küçük) değişiklik kümesini içerir, bu nedenle nispeten hızlı geçer.
3. Artımlı anlık görüntü tamamlandıktan sonra orijinali döndürebilir ve yeni kopyaya kesebilirsiniz; "çevrimdışı çalışmama süresi" minimumda tutulur.

Ayrıca BBF üzerinden zfs dökümlerimizi de gönderiyoruz ... ağ kullanımımızı en üst düzeye çıkarır ve aktarma sürelerini en aza indirir.

BBCP serbestçe kullanılabilir, Google'a gidebilirsiniz ve doğrudan bir derlemedir. Sadece hem src hem de hedef makinelerde / usr / local / bin dizinine kopyalayın ve hemen hemen işe yarayacaktır.

Sanırım cevabım burada biraz geç kaldı, ancak SFTP üzerinden diğer sunucuya bağlanmak için bir sunucuda mc (Midnight Commander) kullanarak iyi deneyimler yaptım.

FTP yoluyla bağlanma seçeneği, "Sol" ve "Sağ" menülerinde şöyle bir adres girerek yapılır:

/#ftp:name@server.xy/

veya

/#ftp:name@ip.ad.dr.ess/

Neredeyse yerel bir dosya sistemindeki gibi gezinebilir ve dosya işlemlerini yapabilirsiniz.

Kopyalamayı arka planda yapmak için yerleşik bir seçeneğe sahiptir, ancak mc komutunu kopyalarken ekran komutunu kullanmayı ve ekrandan ayırmayı tercih ediyorum (sanırım daha sonra hızlı çalışıyor).

RSync seçeneğinin scottpack yanıtını vermek için

Yüklemenin ilerlemesini görüntülemek için, aşağıda gösterilen komutta -avW'dan sonra seçenek olarak '--progess' komutunu kullanın.

rsync -avW --progress -e ssh /path/to/dir/ remote_server:/path/to/remotedir

İşte bazı teknikleri karşılaştırmak için hızlı bir kriter.

• Kaynak, 250 Mbps ve SATA sürücülü 3.60GHz'de 4 çekirdekli Intel (R) Xeon (R) İşlemci E5-1620
• Hedef, 1 Gbps bant genişliğine ve SSD sürücüye sahip 6 çekirdekli Intel (R) Xeon (R) İşlemci E-2136 @ 3.30GHz'dir

Dosya sayısı: 9632, Toplam boyut: 814 MiB, Ort. Boyut: 84 KiB

• RSYNC: 1m40.570s
• RSYNC + KOMPRESYON: 0m26.519s
• TAR + NETCAT: 1m58.763'ler
• TAR + KOMPRESYON + NETCAT: 0m28.009s

Tar / netcat için komut şuydu:

Source : tar -cf - /sourcedir/ | nc -v 11.22.33.44 5000
Dest : nc -v -l 5000 | tar -xf -

rsync ya da hepsini bir dosya içinde tarmak isteyebilirsiniz ve sonra scp. Eğer boş disk alanı yoksa, tar yapılırken doğrudan tarı ssh üzerinden geçirebilirsiniz.

MP3'leri ve diğer sıkıştırılmış dosyaları gönderiyorsanız, bu dosyaları daha fazla sıkıştırmaya çalışan herhangi bir çözümden fazla bir şey elde edemezsiniz. Çözüm, her iki sunucu arasında birden fazla bağlantı oluşturabilen ve böylece iki sistem arasındaki bant genişliğine daha fazla baskı yapan bir çözüm olabilir. Bu maksimuma çıktığında, donanımınızı geliştirmeden kazanılabilecek pek bir şey yoktur. (Örneğin, bu sunucular arasında daha hızlı ağ kartları.)

1GB'lik bir dosyayı kopyalamak için birkaç araç denedim. Sonuç şudur: en hızlı HTTP, wc -c nc ikinci satırda scp ile en yavaş ve birkaç kez başarısız oldu. Rsync'i devam ettirmenin bir yolu arka uç olarak ssh kullanmıyor, dolayısıyla aynı sonuç. Sonuç olarak, http için wget -bqc ile gidip biraz zaman verecektim. Umarım bu yardımcı olur

BackupPC diskini başka bir makineye kopyalamak zorunda kaldım.

Ben rsync kullandım.

Makine 256 MB belleğe sahipti.

İzlediğim prosedür şuydu:

• rsyncolmadan yürütülen -H(9 saat sürdü)
• rsync bittiğinde, cpooldizini senkronize ettim ve dizine başladım pc; Transferi kestim.
• Daha sonra yeniden rsyncile -Hbayrak ve sabit bağlı tüm dosyaları pc(prosedür tüm gerçek bulunan dosyalar dizin doğru transfer edildi cpoolve sonra bağlanmış pc(3 saat sürdü) dizini).

Sonunda df -mfazladan boş yer kalmadığını doğrulayabilirdim .

Bu sayede hatıra ve rsync probleminden kaçınırım. Her zaman üst ve üst kısımdaki performansı doğrulayabilirim ve sonunda 165 GB veri aktardım.