Geekly articles weekly

Cadangan, Bagian 2: Tinjauan Umum dan Pengujian alat pencadangan berbasis rsync


Artikel ini berlanjut

siklus cadangan
  1. Cadangan, bagian 1: Mengapa Anda memerlukan cadangan, tinjauan umum metode, teknologi
  2. Cadangan, Bagian 2: Tinjauan Umum dan Pengujian alat pencadangan berbasis rsync
  3. Cadangan, Bagian 3: Gambaran Umum dan Pengujian duplikasi, dupati
  4. Cadangan, Bagian 4: Tinjauan Umum dan Pengujian zbackup, restic, borgbackup
  5. Cadangan, Bagian 5: Menguji Bacula dan Cadangan Veeam untuk Linux
  6. Cadangan, Bagian 6: Membandingkan Alat Cadangan
  7. Cadangan Bagian 7: Kesimpulan


Seperti yang sudah kami tulis di artikel pertama, ada sejumlah besar program cadangan berdasarkan rsync.

Dari mereka yang paling cocok untuk kondisi kita, saya akan mempertimbangkan 3: rdiff-backup, rsnapshot dan bersendawa.

Set File Uji


Kumpulan file uji akan sama untuk semua kandidat, termasuk artikel mendatang.

Set pertama : 10 GB file media, dan sekitar 50 MB - kode sumber untuk situs dalam php, ukuran file dari beberapa kilobyte untuk kode sumber, hingga puluhan megabyte untuk file media. Tujuannya adalah untuk mensimulasikan situs dengan statika.

Set kedua : diperoleh dari yang pertama saat mengganti nama subdirektori dengan file media 5 GB. Tujuannya adalah untuk mempelajari perilaku sistem cadangan saat mengganti nama direktori.

Set ketiga : diperoleh dari yang pertama dengan menghapus 3GB file media dan menambahkan 3GB file media baru. Tujuannya adalah untuk mempelajari perilaku sistem cadangan selama operasi pembaruan situs yang khas.

Mendapatkan Hasil


Cadangan apa pun dilakukan setidaknya 3 kali dan disertai dengan reset cache sistem file dengan sync dan perintah echo 3 > /proc/sys/vm/drop_caches pada server uji dan server penyimpanan cadangan.

Di server yang akan menjadi sumber cadangan, perangkat lunak pemantauan diinstal - netdata, yang dengannya beban di server akan diperkirakan selama cadangan, ini diperlukan untuk menilai beban di server dengan proses pencadangan.

Saya juga berpikir bahwa server penyimpanan cadangan lebih lambat dari server utama, tetapi memiliki disk lebih luas dengan kecepatan tulis acak yang relatif rendah - situasi yang paling umum ketika membuat cadangan, dan karena fakta bahwa server cadangan tidak boleh melakukan hal yang baik Saya tidak akan memonitor beban selain cadangan, saya tidak akan memonitor bebannya menggunakan netdata.

Juga, server saya telah berubah, di mana saya akan memeriksa berbagai sistem untuk cadangan.

Sekarang mereka memiliki karakteristik sebagai berikut
CPU

 sysbench --threads=2 --time=30 --cpu-max-prime=20000 cpu run sysbench 1.0.17 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 2 Initializing random number generator from current time Prime numbers limit: 20000 Initializing worker threads... Threads started! CPU speed: events per second: 1081.62 General statistics: total time: 30.0013s total number of events: 32453 Latency (ms): min: 1.48 avg: 1.85 max: 9.84 95th percentile: 2.07 sum: 59973.40 Threads fairness: events (avg/stddev): 16226.5000/57.50 execution time (avg/stddev): 29.9867/0.00

RAM, membaca ...

 sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=read memory run sysbench 1.0.17 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 4 Initializing random number generator from current time Running memory speed test with the following options: block size: 1KiB total size: 102400MiB operation: read scope: global Initializing worker threads... Threads started! Total operations: 104857600 (5837637.63 per second) 102400.00 MiB transferred (5700.82 MiB/sec) General statistics: total time: 17.9540s total number of events: 104857600 Latency (ms): min: 0.00 avg: 0.00 max: 66.08 95th percentile: 0.00 sum: 18544.64 Threads fairness: events (avg/stddev): 26214400.0000/0.00 execution time (avg/stddev): 4.6362/0.12

... dan merekam

 sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=write memory run sysbench 1.0.17 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 4 Initializing random number generator from current time Running memory speed test with the following options: block size: 1KiB total size: 102400MiB operation: write scope: global Initializing worker threads... Threads started! Total operations: 91414596 (3046752.56 per second) 89272.07 MiB transferred (2975.34 MiB/sec) General statistics: total time: 30.0019s total number of events: 91414596 Latency (ms): min: 0.00 avg: 0.00 max: 1022.90 95th percentile: 0.00 sum: 66430.91 Threads fairness: events (avg/stddev): 22853649.0000/945488.53 execution time (avg/stddev): 16.6077/1.76

Disk pada server sumber data

 sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run sysbench 1.0.17 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 4 Initializing random number generator from current time Extra file open flags: (none) 128 files, 8MiB each 1GiB total file size Block size 4KiB Number of IO requests: 0 Read/Write ratio for combined random IO test: 1.50 Periodic FSYNC enabled, calling fsync() each 100 requests. Calling fsync() at the end of test, Enabled. Using synchronous I/O mode Doing random r/w test Initializing worker threads... Threads started! File operations: reads/s: 4587.95 writes/s: 3058.66 fsyncs/s: 9795.73 Throughput: read, MiB/s: 17.92 written, MiB/s: 11.95 General statistics: total time: 60.0241s total number of events: 1046492 Latency (ms): min: 0.00 avg: 0.23 max: 14.45 95th percentile: 0.94 sum: 238629.34 Threads fairness: events (avg/stddev): 261623.0000/1849.14 execution time (avg/stddev): 59.6573/0.00

Disk di server penyimpanan cadangan

 sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run sysbench 1.0.17 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 4 Initializing random number generator from current time Extra file open flags: (none) 128 files, 8MiB each 1GiB total file size Block size 4KiB Number of IO requests: 0 Read/Write ratio for combined random IO test: 1.50 Periodic FSYNC enabled, calling fsync() each 100 requests. Calling fsync() at the end of test, Enabled. Using synchronous I/O mode Doing random r/w test Initializing worker threads... Threads started! File operations: reads/s: 11.37 writes/s: 7.58 fsyncs/s: 29.99 Throughput: read, MiB/s: 0.04 written, MiB/s: 0.03 General statistics: total time: 73.8868s total number of events: 3104 Latency (ms): min: 0.00 avg: 78.57 max: 3840.90 95th percentile: 297.92 sum: 243886.02 Threads fairness: events (avg/stddev): 776.0000/133.26 execution time (avg/stddev): 60.9715/1.59

Kecepatan jaringan antar server

 iperf3 -c backup Connecting to host backup, port 5201 [ 4] local xxxx port 59402 connected to yyyy port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 419 MBytes 3.52 Gbits/sec 810 182 KBytes [ 4] 1.00-2.00 sec 393 MBytes 3.30 Gbits/sec 810 228 KBytes [ 4] 2.00-3.00 sec 378 MBytes 3.17 Gbits/sec 810 197 KBytes [ 4] 3.00-4.00 sec 380 MBytes 3.19 Gbits/sec 855 198 KBytes [ 4] 4.00-5.00 sec 375 MBytes 3.15 Gbits/sec 810 182 KBytes [ 4] 5.00-6.00 sec 379 MBytes 3.17 Gbits/sec 765 228 KBytes [ 4] 6.00-7.00 sec 376 MBytes 3.15 Gbits/sec 810 180 KBytes [ 4] 7.00-8.00 sec 379 MBytes 3.18 Gbits/sec 765 253 KBytes [ 4] 8.00-9.00 sec 380 MBytes 3.19 Gbits/sec 810 239 KBytes [ 4] 9.00-10.00 sec 411 MBytes 3.44 Gbits/sec 855 184 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec 8100 sender [ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec receiver


Metodologi pengujian


  1. Sistem file dengan set uji pertama disiapkan di server uji, dan repositori diinisialisasi pada server penyimpanan cadangan jika perlu.
    Proses pencadangan dimulai dan waktunya diukur.
  2. File dimigrasikan ke suite uji kedua di server tes. Proses pencadangan dimulai dan waktunya diukur.
  3. Server tes bermigrasi ke suite tes ketiga. Proses pencadangan dimulai dan waktunya diukur.
  4. Set tes ketiga yang dihasilkan diterima oleh yang pertama; poin 1-3 diulang 2 kali lebih banyak.
  5. Data dimasukkan ke dalam tabel pivot, grafik dengan netdata ditambahkan.
  6. Laporan disiapkan menggunakan metode cadangan terpisah.

Hasil yang Diharapkan


Karena ketiga kandidat didasarkan pada teknologi yang sama (rsync), diharapkan hasilnya akan mendekati rsync biasa, termasuk semua keunggulannya, yaitu:

  1. File dalam repositori akan disimpan "sebagaimana adanya".
  2. Ukuran repositori hanya akan tumbuh termasuk perbedaan antara cadangan.
  3. Akan ada beban yang relatif besar pada jaringan selama transfer data, serta beban kecil pada prosesor.

Uji coba rsync biasa akan digunakan sebagai referensi, hasilnya

ini adalah


Hambatannya adalah pada server penyimpanan cadangan dalam bentuk disk berbasis HDD, yang cukup jelas terlihat pada grafik dalam bentuk gergaji.

Data disalin dalam 4 menit dan 15 detik.


Menguji rdiff-backup


Kandidat pertama adalah rdiff-backup, skrip python yang membuat cadangan satu direktori ke yang lain. Pada saat yang sama, salinan cadangan saat ini disimpan "sebagaimana adanya", dan cadangan yang dibuat sebelumnya disimpan dalam subdirektori khusus secara bertahap, dan dengan demikian ruang disimpan.

Kami akan memeriksa mode operasi yang umum, yaitu dimulainya proses pencadangan dimulai oleh klien sendiri, dan di sisi server, proses yang menerima data diluncurkan untuk cadangan.

Ayo lihat
apa yang dia mampu dalam kondisi kita
.



Waktu berjalan dari setiap percobaan:

Peluncuran pertamaPeluncuran keduaPeluncuran ketiga
Set pertama16m32s16m26s16m19-an
Set kedua2h5m2j10m2j8m
Set ketiga2h9m2j10m2j10m


Rdiff-backup bereaksi sangat menyakitkan terhadap perubahan data besar, dan juga tidak sepenuhnya memanfaatkan jaringan.

Menguji rsnapshot


Kandidat kedua, rsnapshot, adalah skrip perl yang persyaratan utama untuk kerja efektif adalah dukungan untuk tautan keras. Ini menghemat ruang disk. Pada saat yang sama, file yang tidak berubah sejak cadangan sebelumnya akan dirujuk ke file asli menggunakan tautan keras.

Logika dari proses pencadangan juga terbalik: server secara aktif "berjalan" pada kliennya sendiri dan mengambil data.

Hasil tes

berikut ini


Peluncuran pertamaPeluncuran keduaPeluncuran ketiga
Set pertama4m22s4m19-an4m16s
Set kedua2m6s2m10s2m6s
Set ketiga1 m18-an1m10s1m10s

Ini bekerja sangat, sangat cepat, jauh lebih cepat daripada rdiff-backup dan sangat dekat dengan rsync murni.

Pengujian bersendawa


Pilihan lain adalah implementasi C di atas librsync - burp, yang memiliki arsitektur client-server termasuk otorisasi klien, serta antarmuka web (tidak termasuk dalam paket dasar). Fitur menarik lainnya adalah cadangan tanpa hak pemulihan dari klien.

Mari lihat
kinerja
.



Peluncuran pertamaPeluncuran keduaPeluncuran ketiga
Set pertama11m21s11m10s10m56s
Set kedua5m37-an5m40-an5m35s
Set ketiga3m33s3m24d3m40-an

Ini bekerja 2 kali lebih lambat dari rsnapshot, tetapi juga cukup cepat, dan tentu saja rdiff-backup lebih cepat. Grafiknya sedikit gigi gergaji - kinerja lagi bersandar pada subsistem disk dari server penyimpanan cadangan, meskipun ini tidak diucapkan seperti rsnapshot.

Hasil


Ukuran repositori untuk semua kandidat kira-kira sama, yaitu, pada pertumbuhan pertama hingga 10 GB, kemudian tumbuh hingga 15 GB, kemudian tumbuh hingga 18 GB, dll., Karena kekhasan rsync. Perlu juga dicatat bahwa semua kandidat adalah single-threaded (utilisasi CPU sekitar 50% dengan mesin dual-core). Semua 3 kandidat memberikan kesempatan untuk mengembalikan cadangan terakhir "sebagaimana adanya", yaitu, dimungkinkan untuk mengembalikan file tanpa menggunakan program pihak ketiga, termasuk yang digunakan untuk membuat repositori. Ini juga merupakan "warisan generik" dari rsync.

Kesimpulan


Semakin kompleks sistem cadangan dan semakin beragam fitur yang dimilikinya, semakin lambat kerjanya, tetapi untuk proyek yang tidak terlalu menuntut, salah satu dari mereka akan melakukan, kecuali, mungkin, rdiff-backup.

Pengumuman


Catatan ini melanjutkan siklus cadangan.

Cadangan, bagian 1: Mengapa Anda memerlukan cadangan, tinjauan umum metode, teknologi
Cadangan, Bagian 2: Tinjauan Umum dan Pengujian alat pencadangan berbasis rsync
Cadangan, Bagian 3: Gambaran Umum dan Pengujian duplikasi, dupati
Cadangan, Bagian 4: Tinjauan Umum dan Pengujian zbackup, restic, borgbackup
Cadangan, Bagian 5: Menguji Bacula dan Cadangan Veeam untuk Linux
Cadangan: bagian yang diminta oleh pembaca: ulasan AMANDA, UrBackup, BackupPC
Cadangan, Bagian 6: Membandingkan Alat Cadangan
Cadangan Bagian 7: Kesimpulan

Diposting oleh Finnix

Source: https://habr.com/ru/post/id452630/

More articles:


All Articles