Transfer 15 TB file kecil

79

Saya mengarsipkan data dari satu server ke server lain. Awalnya saya memulai rsyncpekerjaan. Butuh 2 minggu untuk membangun daftar file hanya untuk 5 TB data dan satu minggu lagi untuk mentransfer 1 TB data.

Kemudian saya harus mematikan pekerjaan karena kita perlu waktu luang di server baru.

Telah disepakati bahwa kami akan menambahkannya karena kami mungkin tidak perlu mengaksesnya lagi. Saya berpikir untuk memecahnya menjadi potongan 500 GB. Setelah saya tarlalu saya akan menyalinnya ssh. Saya menggunakan tardan pigztetapi masih terlalu lambat.

Apakah ada cara yang lebih baik untuk melakukannya? Saya pikir kedua server ada di Redhat. Server lama adalah Ext4 dan yang baru adalah XFS.

Ukuran file berkisar dari beberapa kb hingga beberapa mb dan ada 24 juta jpeg dalam 5TB. Jadi saya kira sekitar 60-80 juta untuk 15TB.

sunting: Setelah bermain dengan rsync, nc, tar, mbuffer dan pigz selama beberapa hari. Kemacetan akan menjadi IO disk. Seperti data yang dilucuti di 500 SAS disk dan sekitar 250 juta jpeg. Namun, sekarang saya belajar tentang semua alat bagus yang dapat saya gunakan di masa depan.

linux linux-networking file-transfer archive lbanz
sumber
1
mungkin duplikat linux ke linux, transfer 10TB?
D34DM347
2
Salah satu opsi adalah membuat file tar terkompresi pada drive eksternal dan memindahkannya ke sistem baru. Disk tambahan akan mempercepat pembuatan file tar (tidak akan menulis ke disk yang ada di sistem, mungkin saat mencoba membaca 15TB dari mereka) dan tidak mengikat server baru.
Brian
4
Apakah ada cara yang lebih baik untuk melakukannya? - Ya, replikasi DFS Windows Server 2012 akan menyiapkan itu dalam waktu sekitar 10 jam . Dan itu akan menyinkronkan perubahan, dan mengambil di mana ia tinggalkan setelah reboot.
TessellatingHeckler
27
@TessellatingHeckler: jadi Anda menyarankan OP bermigrasi dari Redhat ke Windows sebelum pengarsipan?
Thomas Weller
12
@ ThomasWeller Mereka bertanya "apakah ada cara yang lebih baik?", Dan ada. Saya tidak merekomendasikan mereka menggunakan cara yang lebih baik. Mereka bebas menggunakan perintah dalam pipa yang tidak dapat pulih dari gangguan, tidak akan memverifikasi konten file, tidak dapat melaporkan status salin, tidak dapat menggunakan blok yang disalin sebelumnya untuk menghindari menyalin bagian file, tidak memiliki implisit mendukung penyalinan dengan prioritas rendah, tidak dapat dijeda, tidak menyebutkan penyalinan ACL, dan membutuhkan seseorang untuk tetap masuk untuk menjalankannya. Orang lain yang mengikuti, mungkin tertarik - atau diminta untuk mengatakan "x melakukan itu di Linux".
TessellatingHeckler

Jawaban:

64

Saya memiliki hasil yang sangat baik menggunakan tar, pigz(gzip paralel) dan nc.

Mesin sumber:

tar -cf - -C /path/of/small/files . | pigz | nc -l 9876

Mesin tujuan:

Untuk mengekstrak:

nc source_machine_ip 9876 | pigz -d | tar -xf - -C /put/stuff/here

Untuk menyimpan arsip:

nc source_machine_ip 9876 > smallstuff.tar.gz

Jika Anda ingin melihat kecepatan transfer hanya pipa pvsetelah pigz -d!

h0tw1r3
sumber
3
FYI, Anda dapat mengganti pigzdengan gzipatau menghapusnya sama sekali, tapi kecepatan akan secara signifikan lebih lambat.
h0tw1r3
10
Bagaimana ini dapat diterima jika OP sudah mencoba tardan pigz? Saya tidak mengerti ...
Thomas Weller 915
5
@ ThomasWeller dari mana Anda mendapatkan bahwa dia sudah mencoba pigz? Dari pertanyaan itu sepertinya dia hanya mencoba rsyncsejauh ini, dan sedang mempertimbangkan menggunakan taruntuk membagi dan menggabungkan data. Terutama jika dia belum menggunakan opsi -z/ --compresspada rsync, pigzsecara teoritis dapat membantu secara signifikan.
Doktor J
1
@ ThomasWeller ya memang saya sudah mencoba tar dan pigz tetapi tidak nc. Saya menggunakan ssh sehingga menambahkan lebih banyak overhead.
lbanz
2
@banz itu hanya berarti bahwa tartidak menghasilkan data cukup cepat untuk pigzmenggunakan banyak CPU untuk kompresi. Membaca banyak file kecil melibatkan lebih banyak syscalls, lebih banyak disk mencari, dan lebih banyak overhead kernel daripada membaca jumlah byte yang sama dari file yang lebih besar, dan sepertinya Anda hanya mengalami bottlenecking pada level fundamental.
hobbs
21

Saya akan tetap berpegang pada solusi rsync. Modern (3.0.0+) rsync menggunakan daftar file tambahan, sehingga tidak harus membuat daftar lengkap sebelum transfer. Jadi memulai kembali itu tidak akan mengharuskan Anda melakukan seluruh transfer lagi jika terjadi masalah. Memisahkan transfer per direktori tingkat atas atau kedua akan mengoptimalkan ini lebih jauh. (Saya akan menggunakan rsync -a -Pdan menambahkan --compressjika jaringan Anda lebih lambat dari drive Anda.)

Rubah
sumber
Saya menggunakan rsync 2.6.8 di server lama. Karena ini adalah salah satu kotak di mana kita tidak diperbolehkan menginstal / memperbarui apa pun yang dinyatakan oleh vendor atau membatalkan garansi. Saya mungkin memperbarui dan melihat apakah itu lebih cepat.
lbanz
18
Temukan (atau bangun) biner rsync yang terhubung secara statis dan jalankan saja dari rumah Anda. Semoga itu tidak merusak garansi.
Fox
Bagaimana dengan unison? Bagaimana cara membandingkannya rsync?
Gwyneth Llewelyn
15

Siapkan VPN (jika internetnya), buat drive virtual dengan beberapa format pada server jarak jauh (buat ext4), pasang di server jauh, lalu pasang di server lokal (menggunakan protokol tingkat blok seperti iSCSI ), dan gunakan dd atau alat level blok lain untuk melakukan transfer. Anda kemudian dapat menyalin file dari drive virtual ke drive nyata (XFS) sesuka Anda.

Dua alasan:

  1. Tidak ada overhead sistem file, yang merupakan penyebab utama kinerja
  2. Tanpa mencari, Anda melihat membaca / menulis berurutan di kedua sisi
Arthur Kay
sumber
3
Memotong sistem file itu bagus. Menyalin level blok dari sistem file read-write mount adalah ide yang sangat buruk. Lepas atau pasang hanya-baca terlebih dahulu.
JB.
Memiliki salinan 15TB juga menyebalkan. Ini berarti server baru membutuhkan minimal 30.
Arthur Kay
3
Jika server menggunakan LVM, seseorang dapat melakukan snapshot read-only dari sistem file dan menyalinnya. Ruang overhead hanya untuk perubahan dalam sistem file yang terjadi saat snapshot dibaca.
liori
9

Jika server lama sedang dinonaktifkan dan file-file dapat offline selama beberapa menit maka seringkali paling cepat untuk hanya menarik drive keluar dari kotak lama dan kabel mereka ke server baru, pasang mereka (kembali online sekarang) dan salin file-file ke disk asli server baru.

Robin Hammond
sumber
2
Ini tentang 1PB drive 2TB sehingga terlalu banyak.
lbanz
3

Gunakan mbuffer dan jika berada di jaringan yang aman Anda dapat menghindari langkah enkripsi.

JamesRyan
sumber
3

(Banyak jawaban berbeda dapat bekerja. Ini satu lagi.)

Buat daftar file dengan find -type f(ini akan selesai dalam beberapa jam), pisahkan menjadi potongan-potongan kecil, dan transfer setiap potongan menggunakan rsync --files-from=....

Poin
sumber
3

Sudahkah Anda mempertimbangkan sneakernet? Dengan itu, maksud saya mentransfer semuanya ke drive yang sama, kemudian secara fisik memindahkan drive itu.

sekitar sebulan yang lalu, Samsung meluncurkan drive 16 TB (secara teknis, ini 15,36 TB), yang juga merupakan SSD: http://www.theverge.com/2015/8/14/9153083/samsung-worlds-largest-hard -drive-16tb

Saya pikir drive ini akan lakukan untuk ini. Anda masih harus menyalin semua file, tetapi karena Anda tidak memiliki latensi jaringan dan mungkin dapat menggunakan SATA atau teknik cepat yang serupa, itu harus jauh lebih cepat.

Nzall
sumber
2

Jika ada peluang untuk mendapatkan rasio keberhasilan yang tinggi saat deduplikasi, saya akan menggunakan sesuatu seperti borgbackup atau Attic.

Jika tidak, periksa solusi netcat + tar + pbzip2 , sesuaikan opsi kompresi sesuai dengan perangkat keras Anda - periksa apa hambatannya (jaringan CPU? IO?). Pbzip2 akan menjangkau semua CPU, memberikan kinerja yang lebih baik.

neutrinus
sumber
lzma ( xz) mendekompres lebih cepat dari bzip2, dan bekerja dengan baik pada sebagian besar input. Sayangnya, xzopsi multithread belum diimplementasikan.
Peter Cordes
Biasanya tahap kompresi membutuhkan lebih banyak tenaga kuda daripada dekompresi, jadi jika CPU adalah faktor pembatas, pbzip2 akan menghasilkan kinerja keseluruhan yang lebih baik. Dekompresi seharusnya tidak memengaruhi proses, jika kedua mesin serupa.
neutrinus
Ya, maksud saya adalah memalukan bahwa tidak ada lzma multi-aliran satu-aliran. Meskipun untuk kasus penggunaan ini, mentransfer seluruh filesystem data, pigzakan lebih baik. jadilah kompresor paling lambat yang ingin Anda gunakan. Atau bahkan lz4. (Ada lz4mtmulti-threaded-for-a-single-stream yang tersedia. Ini tidak thread sangat efisien (menelurkan thread baru sangat sering), tetapi memang mendapatkan speedup yang solid)
Peter Cordes
2

Anda menggunakan RedHat Linux, jadi ini tidak berlaku, tetapi sebagai opsi lain:

Saya sudah sangat sukses menggunakan ZFS untuk menyimpan jutaan file karena inode bukan masalah.

Jika itu pilihan bagi Anda, Anda kemudian dapat mengambil foto dan menggunakan zfs untuk mengirim pembaruan tambahan. Saya sudah banyak sukses menggunakan metode ini untuk mentransfer serta mengarsipkan data.

ZFS pada dasarnya adalah sistem file Solaris, tetapi dapat ditemukan di illumos (garpu open source dari Sun's OpenSolaris). Saya tahu ada juga sedikit keberuntungan dalam menggunakan ZFS di bawah BSD dan Linux (menggunakan FUSE?) - tapi saya tidak punya pengalaman mencoba itu.

sleepyweasel
sumber
3
Sudah ada port Linux asli non-FUSE dari ZFS untuk beberapa waktu sekarang: zfsonlinux.org
EEAA
1

Mulai rsyncdaemon di mesin target. Ini akan mempercepat proses transfer.

Heiko Wiesner
sumber
-1

Anda dapat melakukan ini hanya dengan tar dan ssh, seperti ini:

tar zcf - <your files> | ssh <destination host> "cat > <your_file>.tar.gz"

Atau, jika Anda ingin menyimpan file individual:

tar zcf - <your files> | ssh <destination host> "tar zxf -"

Fabio Brito
sumber
1
Itu tidak akan duplikat, tidak ada cara untuk melanjutkan, mengompresi hanya menggunakan satu CPU.
neutrinus