ZFS Sync lebih dari tidak dapat diandalkan, WAN lambat. Replikasi ZFS, atau rsync?

10

Saya telah ditugaskan untuk membuat backup di luar situs melalui WAN. Kedua kotak penyimpanan tersebut adalah kotak NAS berbasis FreeBSD yang menjalankan ZFS.

Sekali atau dua kali seminggu, 15-60 pertunjukan data fotografi akan dibuang ke kantor NAS. Tugas saya adalah mencari tahu bagaimana cara mendapatkan data ini di luar situs sebanyak mungkin dengan menggunakan koneksi DSL SANGAT LAMBAT (~ upload 700Kb / dtk). Kotak penerima berada dalam kondisi yang jauh lebih baik, pada 30 MB / detik ke bawah, 5 MB / detik ke atas.

Saya tahu, membawa hard drive di luar situs akan memindahkan data lebih cepat, tetapi ini bukan opsi dalam hal ini.

Pilihan saya sepertinya:

ZFS incremental send ssh
Rsync

rsync adalah solusi yang dihormati waktu, dan memiliki kemampuan yang sangat penting untuk melanjutkan pengiriman jika sesuatu terganggu. Ini memiliki kelemahan dari iterasi beberapa file dan tidak tahu tentang dedup.

Pengiriman snapshot ZFS mungkin mentransfer data sedikit lebih sedikit (ia tahu lebih banyak tentang sistem file, dapat melakukan dedup, dapat mengemas perubahan metadata lebih efisien daripada rsync) dan memiliki keuntungan menduplikasi keadaan sistem file dengan benar, daripada hanya menyalin file secara individual (yang lebih intensif disk).

Saya khawatir tentang kinerja replikasi ZFS [1] (meskipun artikel itu berumur satu tahun). Saya juga khawatir akan dapat memulai kembali transfer jika terjadi sesuatu - kemampuan snapshot sepertinya tidak termasuk itu. Seluruh sistem harus benar-benar lepas tangan.

[1] http://wikitech-static.wikimedia.org/articles/z/f/s/Zfs_replication.html

Menggunakan salah satu opsi, saya harus dapat memprioritaskan lalu lintas dengan merutekannya melalui port yang ditentukan, kemudian menggunakan QOS pada router. Saya perlu menghindari dampak negatif utama pada pengguna di kedua situs selama setiap transfer, karena akan memakan waktu beberapa hari.

Jadi ... itulah pemikiran saya tentang masalah ini. Apakah saya melewatkan opsi bagus? Adakah orang lain yang mengatur sesuatu yang serupa?

— Paul McMillan
sumber

Pertimbangkan Serempak .

— sampablokuper

8

Jika Anda dapat mentransfer maksimum 6GB per hari (dengan asumsi nol overhead dan nol lalu lintas yang bersaing) dan Anda perlu memindahkan "15-60 pertunjukan" pada frekuensi "sekali atau dua kali per minggu," yang bekerja pada 15-120 GB per minggu, atau di mana saja dari 2-17 GB per hari. Karena itu perlu untuk merencanakan permintaan puncak, dan 17 GB jauh melebihi bahkan maksimum teoritis Anda 6 GB, kemungkinan Anda memiliki masalah bandwidth yang sangat serius. Apa yang diperlukan untuk meningkatkan koneksi? Jika memutakhirkan koneksi tidak mungkin, silakan pertimbangkan opsi mengirim media fisik secara terjadwal (mis. Mingguan).
Dengan asumsi bahwa Anda bisa mendapatkan matematika bandwidth untuk membuat sedikit lebih masuk akal, rsync kemungkinan akan menjadi pilihan terbaik. Kesadaran deduplikasi akan sangat berharga ketika mereplikasi data yang sangat berlebihan (misalnya gambar mesin virtual), tetapi seharusnya memiliki sedikit atau tidak ada manfaat ketika datang ke konten digital yang unik (audio, video, foto) ... kecuali, tentu saja, pengguna secara tidak sengaja menyimpan salinan duplikat dari file yang identik.

— Skyhawk
sumber

Saya pikir saya bisa menggunakan bandwidth yang tersedia, dan sebagian besar kesedihan data cenderung mengarah ke ujung rentang yang lebih kecil. Praktis, itu akan menjadi sekitar 2-3 gigs rata-rata sehari, dilihat dari data bulan lalu. Saya tidak perlu replikasi segera.

— Paul McMillan

Dan ya, mengirimkan media fisik jauh lebih baik ... Saya berharap itu pilihan.

— Paul McMillan

Poin bagus tentang dedup. Sebagian besar yang disalin tidak akan diduplikasi - pengguna tidak sepadat itu.

— Paul McMillan

1

Satu-satunya hal yang saya tambahkan adalah mungkin tidak menggunakan rsync. Saya juga mengalami kelambatan rsync karena saya menggunakannya sebagai proses transfer, bukan proses sinkronisasi. Kemudian saya menyadari sebagian besar data saya yang ada tidak berubah dan hanya data baru yang perlu disalin, bagi saya, saya menggunakan cp hanya pada file baru dan itu jauh lebih cepat. Jika saya memiliki file yang berubah (atau hanya sebagian file) maka saya akan menggunakan rsync. Jadi saya sarankan memisahkan file baru dan memilih metode transfer yang dapat dilanjutkan. Juga, kompresi akan menjadi trade-off CPU & RAM / bandwidth (di kedua ujungnya).

— Scott McClenning

Hmm ... Saya sudah membaca bahwa dengan konfigurasi yang tepat, rsync dapat dibuat untuk berjalan relatif cepat. Berapa banyak pengoptimalan yang Anda coba?

— Paul McMillan

13

Setelah melakukan riset, saya yakin Anda benar tentang mengirim foto. ZFS SENDdan RECEIVEperintah dapat disalurkan ke bzip2 dan kemudian file tersebut dapat di-rsync-ed ke mesin lain.

Berikut adalah beberapa sumber yang saya gunakan:

The Oracle Solaris ZFS Administrator Panduan halaman 211 (atau versi web di sini ) mulai berbicara tentang hal ini.
Saya juga menemukan posting blog yang memberikan contoh sederhana ini. Blog ini juga menunjukkan pemipaan bit stream melalui bzip2 dan mengirimkannya.

Saya belum menemukan posting dengan skrip replikasi yang diposting, tetapi saya menemukan seseorang yang memposting skrip cadangan mereka . Yang mengatakan, saya tidak memahaminya jadi mungkin sampah.

Banyak situs web berbicara tentang mengatur tugas cron untuk melakukan hal ini sering. Jika demikian, Anda dapat mereplikasi / mencadangkan dengan dampak yang lebih kecil pada bandwidth dan pengguna dan menjadi fitur pemulihan bencana yang baik karena data di luar kantor lebih terkini. (Yaitu, setelah potongan data awal saat memulai.)

Sekali lagi, saya pikir Anda memiliki ide yang tepat mengirim snapshot sepertinya ada banyak keuntungan menggunakan SEND/ RECEIVE.

EDIT: Baru saja menonton video1 video2 yang dapat membantu mendukung penggunaan SEND/ RECEIVEdan berbicara tentang rsync (dimulai pada 3m49s). Ben Rockwood adalah pembicara dan di sini ada tautan ke blog - nya .

— Scott McClenning
sumber

1

Saya kira penggunaan rsync ada terbatas pada fungsi pause / resume, daripada perbedaan file yang sebenarnya. Ini masuk akal, karena sistem file itu sendiri (dan perubahan file yang dihasilkannya) lebih tahu daripada rsync apa yang terjadi.

— Paul McMillan

Sebagai catatan tambahan: ZSTD, pengganti modern yang lebih cepat untuk gzip dan bzip, mendukung banyak utas, dan lebih dari 20 level kompresi. Ini juga memiliki fitur opsional yang berkontribusi yang disebut 'kompresi adaptif'. Dengan mode ini, level kompresi secara otomatis disetel ke atas dan ke bawah sesuai kebutuhan untuk menjaga pipa jaringan tetap penuh, sambil melakukan kompresi sebanyak mungkin untuk menghemat waktu. Ini mencegah Anda melakukan begitu banyak kompresi sehingga menjadi hambatan, atau kehilangan kompresi yang bisa Anda lakukan karena jaringan terlalu lambat.

— Allan Jude

2

Apa tujuan dari backup dan bagaimana mereka perlu diakses?

Jika cadangan Anda sebagian besar untuk pemulihan bencana maka snapshot ZFS mungkin lebih disukai karena Anda akan bisa mendapatkan sistem file kembali ke keadaan yang tepat pada saat penambahan terakhir.

Namun, jika cadangan Anda juga seharusnya memberikan pengguna akses ke file yang mungkin telah terhapus secara tidak sengaja, rusak, dll. Maka rsync bisa menjadi pilihan yang lebih baik. Pengguna akhir mungkin tidak memahami konsep foto-foto atau mungkin NAS Anda tidak memberikan akses kepada pengguna akhir ke foto-foto sebelumnya. Dalam kedua kasus, Anda dapat menggunakan rsync untuk menyediakan cadangan yang mudah diakses oleh pengguna melalui sistem file.

Dengan rsync Anda dapat menggunakan flag --backup untuk menyimpan cadangan file yang telah diubah, dan dengan flag --suffix Anda dapat mengontrol bagaimana versi file yang lama diubah namanya. Ini membuatnya mudah untuk membuat cadangan di mana Anda mungkin memiliki tanggal file versi lama suka

file_1.jpg
file_1.jpg.20101012
file_1.jpg.20101008
etc.

Anda dapat dengan mudah menggabungkan ini dengan cronjob yang berisi perintah find untuk membersihkan semua file lama sesuai kebutuhan.

Kedua solusi harus dapat mempertahankan metainformation yang cukup tentang file agar berfungsi sebagai cadangan (rsync memberikan flag --perms, --owner etc.). Saya menggunakan rsync untuk mencadangkan sejumlah besar data antara pusat data dan saya sangat senang dengan pengaturannya.

— Deutsch
sumber

2

ZFS harus menerima fitur 'resumable send', yang akan memungkinkan melanjutkan replikasi terputus sekitar Maret tahun ini. Fitur ini telah diselesaikan oleh Matt Ahrens dan beberapa orang lainnya, dan harus segera di-upstream.

— Allan Jude
sumber

Hanya sebuah catatan bahwa 'resumable send' telah ada di OpenZFS (di FreeBSD, Linux, MacOS, dll) untuk beberapa waktu sekarang. Ada juga fitur 'pengiriman terkompresi' sekarang, di mana data akan tetap terkompresi seperti pada disk, sebagai bagian dari aliran replikasi.

— Allan Jude

0

Mungkin perangkat kompresi WAN akan menjadi solusi ...? kami menggunakan Riverbed dan kami cukup senang dengannya (mis. NetApp SnapMirror sedang dikompresi dengan sangat baik, hingga 80-90%)

— toffitomek
sumber