Pertanyaan Cara menyalin sejumlah besar file dengan cepat di antara dua server


Saya perlu mentransfer sejumlah besar MP3 antara dua servis (Ubuntu). Dengan besar saya maksud sekitar satu juta file yang rata-rata 300K. Saya mencoba dengan scp tapi itu akan memakan waktu sekitar satu minggu. (sekitar 500 KB / dtk) Jika saya mentransfer satu file dengan HTTP, saya mendapatkan 9-10 MB / s, tetapi saya tidak tahu cara mentransfer semuanya.

Apakah ada cara untuk mentransfer semuanya dengan cepat?


81
2018-06-02 19:55




Apa jenis jaringan yang Anda miliki di antara server. Saya telah menggunakan GB Ethernet crossover antara 1 NIC di setiap mesin. Saya berhasil melewati konfigurasi itu menggunakan SCP - Jim Blizard
Anda mungkin ingin menyelidiki mengapa scp sangat lambat. Hal ini mungkin lebih lambat maka hal-hal seperti ftp karena enkripsi tetapi seharusnya tidak terlalu lambat. - Zoredache
Saya memiliki 100 mbps di antara mereka. scp lebih lambat pada file kecil (kebanyakan dari mereka berukuran kecil) - nicudotro


Jawaban:


Saya akan merekomendasikan tar. Ketika pohon-pohon file sudah serupa, rsync berkinerja sangat baik. Namun, karena rsync akan melakukan banyak analisis pada setiap file, dan kemudian menyalin perubahan, itu jauh lebih lambat daripada tar untuk salinan awal. Perintah ini kemungkinan akan melakukan apa yang Anda inginkan. Ini akan menyalin file di antara mesin, serta mempertahankan kedua izin dan kepemilikan pengguna / grup.

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

Sesuai komentar Mackintosh di bawah ini adalah perintah yang akan Anda gunakan untuk rsync

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

109
2018-06-02 20:04



+1 Opsi tar jauh lebih efisien untuk sejumlah besar file kecil karena scp dan rsync akan memiliki lebih banyak putaran perjalanan per file di seluruh jaringan. - Sekenre
rsync bekerja lebih baik bagi saya daripada tar - nicudotro
Juga, jika Anda memiliki banyak CPU yang tersedia (pada kedua ujungnya), tetapi (setidaknya) sebuah penghubung yang lambat antara host, mungkin perlu dilakukan pemampatan kompresi (gzip atau bzip) dalam perintah tar. - Vatine
@Jamie: Jika Anda menggunakan ssh-agent, maka itu harus digunakan. Kalau tidak, gunakan saja opsi '-i' untuk menentukan di mana menemukan kunci privat. Lihat halaman manual untuk detailnya. - Scott Pack
@niXar The ~ karakter escape hanya diaktifkan jika SSH menggunakan terminal. Ini tidak terjadi ketika Anda menetapkan perintah jarak jauh (kecuali Anda meneruskannya -t pilihan). Jadi kekhawatiran Anda tidak valid. - Gilles


Harddisk eksternal dan pengiriman kurir yang sama.


32
2018-06-02 20:00



Heh heh ... tidak ada teknologi jaringan yang mengalahkan bandwidth dari station wagon yang diisi dengan kaset yang melakukan 90 MPH, eh? (Tertawa) Saya berasumsi dia ada di LAN karena dia mengatakan dia mendapatkan 9-10MB / detik dengan HTTP. - Evan Anderson
Saya mendapatkan kecepatan semacam itu melalui internet, tapi saya hanya beruntung di tempat saya tinggal! Jika di LAN, maka lebih murah lagi! - Adam
Ahh-- tidak melihat lokasimu. Ya, saya dengar konektivitas internet di Korea cukup spektakuler. Terjebak di sini di AS, saya senang mendapat 900KB / dt selama 'net ... - Evan Anderson
Ya, tetapi Anda bisa mendapatkan burrito lezat sambil menunggu unduhan selesai dan hanya ada sekitar tiga restoran Meksiko setengah-bahkan di Seoul ... - Adam


Saya akan menggunakan rsync.

Jika Anda mendapatkannya diekspor melalui HTTP dengan daftar direktori yang tersedia, Anda bisa menggunakan wget dan argumen --mirror juga.

Anda sudah melihat bahwa HTTP lebih cepat daripada SCP karena SCP mengenkripsi semuanya (dan dengan demikian bottlenecking pada CPU). HTTP dan rsync akan bergerak lebih cepat karena tidak dienkripsi.

Berikut ini beberapa dokumen tentang pengaturan rsync di Ubuntu: https://help.ubuntu.com/community/rsync

Dokumen-dokumen tersebut berbicara tentang tunneling rsync melalui SSH, tetapi jika Anda hanya memindahkan data di LAN pribadi, Anda tidak memerlukan SSH. (Saya mengasumsikan Anda berada di LAN pribadi. Jika Anda mendapatkan 9-10MB / sec melalui Internet, maka saya ingin tahu koneksi seperti apa yang Anda miliki!)

Berikut adalah beberapa dokumen dasar lainnya yang memungkinkan Anda untuk mengatur server rsync yang tidak aman (tanpa ketergantungan pada SSH): http://transamrit.net/docs/rsync/


16
2018-06-02 19:57



Sementara SCP menggunakan beberapa CPU untuk mengenkripsi data, saya tidak berpikir bahwa ia memiliki penggunaan CPU 100%, jadi CPU bukanlah penghambat. Saya telah memperhatikan terlalu banyak waktu bahwa SCP tidak efisien dalam hal transfer cepat. - Cristian Ciupitu
Mengingat bahwa ia melihat 300K untuk SCP dan 9MB untuk HTTP, saya berasumsi bahwa bottleneck yang berhubungan dengan SCP (biasanya CPU) ikut bermain. Tentu saja itu bisa menjadi sesuatu yang lain. Tanpa mengetahui spesifikasi perangkat keras yang dipertanyakan sulit untuk dikatakan. - Evan Anderson
rsync hampir pasti akan menggunakan ssh untuk transportasi, karena ini adalah perilaku default, sehingga setiap overhead yang disebabkan oleh enkripsi dalam scp juga akan hadir di rsync - Daniel Lawson
"Anda sudah melihat bahwa HTTP lebih cepat daripada SCP karena SCP mengenkripsi semuanya" → SALAH. Kecuali dia memiliki server 10 tahun, dia bukan CPU yang terikat pada tugas ini. - niXar
@RamazanPOLAT - Anda memiliki baris perintah yang terlalu panjang. Tentukan pemilihan file secara berbeda dan itu akan berfungsi dengan baik untuk Anda. Biasanya Anda bisa menentukan direktori sumber tanpa wildcard di bagian akhir. Anda juga bisa menggunakan --include dan --exclude argumen untuk lebih bernuansa. - Evan Anderson


Tanpa banyak diskusi, gunakan netcat, pisau swissarmy jaringan. Tanpa overhead protokol, Anda langsung menyalin ke soket jaringan. Contoh

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

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

14
2018-06-02 20:17



Sayangnya, dari apa yang saya perhatikan netcat sangat tidak efisien meskipun seharusnya tidak demikian. - Cristian Ciupitu
Aku menjatuhkanmu karena ini benar-benar, saran yang sangat buruk. Ada satu jawaban yang benar: rsync. Saya bisa mendaftar semua alasan mengapa itu lebih baik tetapi tidak muat di halaman ini, apalagi kotak komentar kecil ini. - niXar
@niXar: Jika semua yang ingin Anda lakukan adalah transfer file tunggal (tidak perlu untuk sinkronisasi lebih lanjut), maka tarpipe benar-benar semua yang Anda butuhkan. - Witiko
@niXar netcat baik-baik saja jika Anda melakukan ini di lingkungan yang aman seperti vlan pribadi dan / atau melalui VPN. - Lester Cheung


Dengan banyak file jika Anda menggunakan rsync, Saya akan mencoba mendapatkan versi 3 atau lebih di kedua ujungnya. Alasannya adalah bahwa versi yang lebih rendah akan menyebutkan setiap file sebelum memulai transfer. Fitur baru ini disebut inkremental-rekursi.

Algoritme rekurensi inkremental baru   sekarang digunakan ketika rsync sedang berbicara         ke versi 3.x lain. Ini memulai transfer lebih cepat         (sebelum semua file ditemukan), dan membutuhkan lebih sedikit memori.         Lihat opsi --recursive di halaman manual untuk beberapa pembatasan.


8
2018-06-02 20:41





rsync, seperti yang telah disarankan orang lain. Jika overhead CPU dari enkripsi adalah bottleneck, gunakan algoritma lain yang kurang intensif CPU, seperti blowfish. Misalnya. sesuatu seperti

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


7
2018-06-02 20:56



+1 untuk poin tentang mengubah cipher - Daniel Lawson
CPU tidak akan menjadi bottleneck, kecuali Anda memiliki 10G ethernet dan CPU 10 tahun. - niXar
hanya komentar: cipher "-c arcfour" lebih cepat. - Arman
@niXar: Tetapi jika Anda sudah memiliki tugas yang memakan CPU di komputer Anda, ini adalah masalah. - Isaac


Ketika menyalin sejumlah besar file, saya menemukan bahwa alat seperti tar dan rsync lebih tidak efisien daripada yang seharusnya karena overhead membuka dan menutup banyak file. Saya menulis sebuah alat open source yang disebut fast-archiver yang lebih cepat dari tar untuk skenario ini: https://github.com/replicon/fast-archiver; itu bekerja lebih cepat dengan melakukan beberapa operasi file bersamaan.

Berikut ini contoh pengarsip cepat vs. tar pada cadangan lebih dari dua juta file; fast-archiver membutuhkan waktu 27 menit untuk mengarsip, vs. tar mengambil 1 jam 23 menit.

$ 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

Untuk mentransfer file antar server, Anda dapat menggunakan pengarsip cepat dengan ssh, seperti ini:

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

4
2017-08-26 20:51