Kepiye GitLab mbantu sampeyan nggawe serep panyimpenan NextCloud sing gedhe

Hey Habr!

Dina iki aku pengin ngomong babagan pengalaman kita ngotomatisasi serep data gedhe saka panyimpenan Nextcloud ing konfigurasi sing beda-beda. Aku kerja minangka stasiun layanan ing Molniya AK, ing ngendi kita nindakake manajemen konfigurasi sistem IT; Nextcloud digunakake kanggo panyimpenan data. Kalebu, kanthi struktur sing disebarake, kanthi redundansi.

Masalah sing muncul saka fitur panginstalan yaiku ana akeh data. Versi sing diwenehake dening Nextcloud, redundansi, alasan subyektif, lan liya-liyane nggawe akeh duplikat.

prasejarah

Nalika ngatur Nextcloud, masalah ngatur cadangan sing efektif, sing kudu dienkripsi, amarga data kasebut penting.

Kita nawakake pilihan kanggo nyimpen serep ing panggonan kita utawa ing pelanggan ing mesin sing kapisah saka Nextcloud, sing mbutuhake pendekatan otomatis sing fleksibel kanggo administrasi.

Ana akeh klien, kabeh padha karo konfigurasi beda, lan kabeh ing situs dhewe lan karo ciri dhewe. Iki minangka teknik standar nalika kabeh situs dadi duweke sampeyan, lan serep digawe saka mahkota; ora cocog.

Pisanan, ayo ndeleng data input. Dhewe butuh:

• Skalabilitas ing syarat-syarat siji simpul utawa saperangan. Kanggo instalasi gedhe kita nggunakake minio minangka panyimpenan.
• Temokake babagan masalah nalika nggawe serep.
• Sampeyan kudu nggawe serep karo klien lan/utawa karo kita.
• Ngatasi masalah kanthi cepet lan gampang.
• Klien lan instalasi beda banget saka saben liyane - keseragaman ora bisa digayuh.
• Kacepetan pemulihan kudu minimal ing rong skenario: pemulihan lengkap (bencana), siji folder dibusak kanthi ora sengaja.
• Fungsi deduplikasi dibutuhake.

Kanggo ngatasi masalah ngatur serep, kita nginstal GitLab. Rincian liyane kanthi nyegat.

Mesthine, kita dudu sing pertama ngrampungake masalah kasebut, nanging misale jek yen pengalaman praktis lan kerja keras bisa menarik lan kita siap nuduhake.

Amarga perusahaan kita duwe kabijakan sumber terbuka, kita golek solusi sumber terbuka. Sabanjure, kita nuduhake perkembangan lan ngirim. Contone, ing GitHub ana plugin kita kanggo Nextcloud, sing diwenehake marang klien, ningkatake keamanan data yen ana pambusakan sing ora disengaja utawa disengaja.

Piranti serep

Kita miwiti nggoleki cara solusi kanthi milih alat nggawe serep.

Tar biasa + gzip ora bisa digunakake - data diduplikasi. Tambah asring ngemot sawetara owah-owahan nyata, lan akeh data ing file siji sing diulang.
Ana masalah liyane - redundansi panyimpenan data sing disebarake. Kita nggunakake minio lan data kasebut pancen keluwih. Utawa sampeyan kudu nggawe serep liwat minio dhewe - mbukak lan nggunakake kabeh spacer antarane sistem file, lan, ora kurang penting, ana risiko lali bab sawetara saka ember lan meta-informasi. Utawa nggunakake deduplication.

Piranti serep kanthi duplikasi kasedhiya ing open source (ing Habré ana artikel ing topik iki) lan finalis kita padha kutha и Restic. Perbandingan loro aplikasi kasebut ana ing ngisor iki, nanging saiki kita bakal menehi pitutur marang kowe carane ngatur kabeh skema.

Ngatur serep

Borg lan Restic apik, nanging ora ana produk sing duwe mekanisme kontrol terpusat. Kanggo tujuan manajemen lan kontrol, kita milih alat sing wis ditindakake, sing tanpa kita ora bisa mbayangake karya kita, kalebu otomatisasi - iki CI / CD sing kondhang - GitLab.

Ide kasebut kaya ing ngisor iki: gitlab-runner diinstal ing saben simpul sing nyimpen data Nextcloud. Runner mbukak script ing jadwal sing ngawasi proses serep, lan miwiti Borg utawa Restic.

Apa sing kita entuk? Umpan balik saka eksekusi, kontrol sing trep babagan owah-owahan, rincian yen ana kesalahan.

kene kene ing GitHub kita dikirim conto script kanggo macem-macem tugas, lan kita rampung masang menyang serep ora mung Nextcloud, nanging uga akeh layanan liyane. Ana uga panjadwal yen sampeyan ora pengin ngatur kanthi manual (lan kita ora pengin) lan .gitlab-ci.yml

Ora ana cara kanggo ngganti wektu entek CI / CD ing API Gitlab, nanging cilik. Iku perlu kanggo nambah, ngandika kanggo 1d.

GitLab, untunge, bisa diluncurake ora mung miturut komitmen, nanging mung miturut jadwal, iki persis sing dibutuhake.

Saiki babagan script wrapper.

Kita nyetel kahanan ing ngisor iki kanggo skrip iki:

• Sampeyan kudu diluncurake dening pelari lan kanthi tangan saka konsol kanthi fungsi sing padha.
• Mesthi ana panangan kesalahan:
• kode bali.
• goleki senar ing log. Contone, kanggo kita kesalahan bisa dadi pesen sing program ora dianggep fatal.
• Pangolahan wektu entek. Wektu timbal kudu cukup.
• Kita butuh log sing rinci banget. Nanging mung yen ana kesalahan.
• Sawetara tes uga ditindakake sadurunge miwiti.
• Bonus cilik kanggo penak sing ditemokake migunani sajrone proses dhukungan:
• Wiwitan lan pungkasan dicathet ing syslog mesin lokal. Iki mbantu nyambungake kesalahan sistem lan operasi serep.
• Bagéyan saka log kesalahan, yen ana, output kanggo stdout, kabeh log ditulis menyang file kapisah. Iku trep kanggo langsung ndeleng CI lan ngevaluasi kesalahan yen ora pati penting.
• Mode debugging.

Log lengkap disimpen minangka artefak ing GitLab; yen ora ana kesalahan, log kasebut bakal dibusak. Kita nulis skrip ing bash.

Kita bakal seneng nimbang saran lan komentar babagan open source - welcome.

Carane ora karya iki

A runner karo eksekutor Bash dibukak ing simpul serep. Miturut jadwal, proyek CI / CD dibukak ing turnip khusus. Pelari ngluncurake skrip pambungkus universal kanggo tugas kasebut, mriksa kesahihan repositori serep, titik gunung lan kabeh sing dikarepake, banjur serep lan ngresiki sing lawas. Serep rampung dhewe dikirim menyang S3.

Kita kerja miturut skema iki - iku panyedhiya AWS eksternal utawa sing padha karo Rusia (luwih cepet lan data ora metu saka Federasi Rusia). Utawa kita nginstal kluster minio sing kapisah kanggo klien ing situs kasebut kanggo tujuan kasebut. Kita biasane nindakake iki kanggo alasan keamanan, nalika klien ora pengin data ninggalake sirkuit ing kabeh.

Kita ora nggunakake fitur ngirim serep liwat ssh. Iki ora nambah keamanan, lan kapabilitas jaringan panyedhiya S3 luwih dhuwur tinimbang mesin ssh siji.

Kanggo nglindhungi mesin lokal saka peretas, amarga bisa mbusak data ing S3, sampeyan kudu ngaktifake versi.
Serep tansah encrypts serep.

Borg duwe mode sing ora dienkripsi none, nanging ora dianjurake kanggo nguripake. Ing mode iki, ora mung ora ana enkripsi, nanging checksum saka apa sing ditulis ora diitung, tegese integritas mung bisa dicenthang kanthi ora langsung, nggunakake indeks.

Penjadwal sing kapisah mriksa serep kanggo integritas indeks lan konten. Priksa iku alon lan dawa, supaya kita mbukak dhewe sapisan sasi. Perlu sawetara dina.

Readme ing basa Rusia

Fungsi utama

• prepare pelatihan
• testcheck mriksa kesiapan
• maincommand tim inti
• forcepostscript fungsi sing kaleksanan ing mburi utawa dening kesalahan. Kita nggunakake kanggo unmount pemisahan.

Fungsi layanan

• cleanup Kita ngrekam kesalahan utawa mbusak file log.
• checklog parse log kanggo kedadean saka baris karo kesalahan.
• ret pawang metu.
• checktimeout mriksa wektu entek.

lingkungan

• VERBOSE=1 Kita langsung nampilake kesalahan ing layar (stdout).
• SAVELOGSONSUCCES=1 nyimpen log nalika sukses.
• INIT_REPO_IF_NOT_EXIST=1 Nggawe repositori yen ora ana. Dipateni kanthi gawan.
• TIMEOUT wektu maksimum kanggo operasi utama. Sampeyan bisa nyetel minangka 'm', 'h' utawa 'd' ing pungkasan.

Mode panyimpenan kanggo salinan lawas. Default:

• KEEP_DAILY=7
• KEEP_WEEKLY=4
• KEEP_MONTHLY=6

Variabel ing njero naskah

• ERROR_STRING - string kanggo mlebu log kanggo kesalahan.
• EXTRACT_ERROR_STRING - ekspresi kanggo nuduhake string yen kesalahan.
• KILL_TIMEOUT_SIGNAL - sinyal kanggo mateni yen wektu entek.
• TAIL - carane akeh strings karo kasalahan ing layar.
• COLORMSG - werna pesen (kuning standar).

Skrip kasebut, sing diarani wordpress, duwe jeneng kondisional, trik kasebut uga nggawe serep database mysql. Iki tegese bisa digunakake kanggo instalasi Nexcloud simpul siji, ing ngendi sampeyan uga bisa nggawe serep database. Penak ora mung kabeh ana ing sak panggonan, nanging uga isi database sing cedhak karo isi file, amarga beda wektu minimal.

Restic vs Borg

Ana uga perbandingan antarane Borg lan Restic kene ing Habré, lan kita ora duwe tugas nggawe mung siji liyane, nanging kita dhewe. Iku penting kanggo kita carane bakal katon ing data kita, karo spesifik kita. We nggawa wong-wong mau.

Kriteria pilihan kita, saliyane sing wis kasebut (deduplikasi, pemulihan cepet, lsp.):

• Resistance kanggo karya sing durung rampung. Priksa mateni -9.
• Ukuran ing disk.
• Requirement kanggo sumber daya (CPU, memori).
• Ukuran gumpalan sing disimpen.
• Kerja karo S3.
• Priksa integritas.

Kanggo testing, kita njupuk siji klien karo data nyata lan ukuran total 1,6 TB.
Kahanan

Borg ora ngerti carane bisa langsung karo S3, lan kita dipasang disk minangka sekring, liwat goofys. Restic dikirim menyang S3 dhewe.

Goofys dianggo cepet banget lan uga, lan ana modul cache disk, kang nyepetake karya malah luwih. Ana ing tahap beta, lan, terus terang, kita nabrak data nalika tes (liyane). Nanging penak iku prosedur serep dhewe ora mbutuhake akeh maca, nanging biasane nulis, supaya kita nggunakake cache mung sak mriksa integritas.

Kanggo nyuda pengaruh jaringan, kita nggunakake panyedhiya lokal - Yandex Cloud.

Hasil tes perbandingan.

• Mateni -9 kanthi restart luwih sukses.
• Ukuran ing disk. Borg bisa compress, supaya asil kaya samesthine.

Backuper
ukuran

kutha
562Gb

Restic
628Gb

• Miturut CPU
  Borg dhewe nganggo sethithik, kanthi kompresi standar, nanging kudu dievaluasi bebarengan karo proses goofys. In total, padha iso dibandhingke lan nggunakke bab 1,2 intine ing mesin virtual test padha.
• Memori. Restic kira-kira 0,5GB, Borg kira-kira 200MB. Nanging kabeh iki ora pati penting dibandhingake karo cache file sistem. Dadi disaranake kanggo nyedhiyakake memori luwih akeh.
• Bentenipun ing ukuran blob punika striking.

Backuper
ukuran

kutha
babagan 500MB

Restic
babagan 5MB

• Pengalaman S3 Restic apik banget. Operasi Borg liwat goofys ora mundhakaken pitakonan, nanging wis nyatet sing iku saranake kanggo nindakake umount sawise serep lengkap supaya rampung ngreset cache. Keanehan S3 yaiku potongan sing ora dipompa ora bakal dikirim menyang ember, tegese data sing ora diisi bisa nyebabake karusakan gedhe.
• Priksa integritas bisa digunakake kanthi apik ing kasus kasebut, nanging kacepetan beda banget.
  Restic Jam 3,5.
  Borg, kanthi cache file SSD 100GB - Jam 5.Kira-kira asil kacepetan padha yen data ing disk lokal.
  Borg maca langsung saka S3 tanpa cache Jam 33. Wektu sing dawa banget.

Ing ngisor iki Borg bisa compress lan blobs luwih gedhe - kang ndadekake panyimpenan lan operasi GET / PUT ing S3 luwih murah. Nanging iki teka kanthi biaya verifikasi sing luwih rumit lan luwih alon. Minangka kanggo kacepetan Recovery, kita ora sok dong mirsani prabédan. Restic njupuk serep sakteruse (sawise pisanan) sethitik maneh, nanging ora Ngartekno.

Pungkasan nanging paling ora ing pilihan yaiku ukuran komunitas.

Lan kita milih borg.

Sawetara tembung babagan kompresi

Borg duwe algoritma kompresi anyar sing apik banget ing arsenal - zstd. Kualitas kompresi ora luwih ala tinimbang gzip, nanging luwih cepet. Lan iso dibandhingke ing kacepetan kanggo standar lz4.

Contone, dump database MySQL dikompres kaping pindho luwih apik tinimbang lz4 kanthi kacepetan sing padha. Nanging, pengalaman karo data nyata nuduhake yen ana sethitik prabédan ing rasio kompresi saka simpul Nextcloud.

Borg nduweni mode komprèsi sing rada bonus - yen file nduweni entropi dhuwur, mula komprèsi ora ditrapake, sing nambah kacepetan. Diaktifake kanthi pilihan nalika nggawe
-C auto,zstd
kanggo algoritma zstd
Dadi kanthi pilihan iki, dibandhingake karo kompresi standar, kita entuk
560Gb lan 562Gb. Data saka conto ing ndhuwur, mugi kula ngelingake sampeyan, tanpa kompresi asil 628Gb. Asil saka prabédan 2GB Luwih kaget kita, nanging kita panginten sing kita bakal milih sawise kabeh. auto,zstd.

Metode verifikasi serep

Miturut jadwal, mesin virtual diluncurake langsung saka panyedhiya utawa saka klien, sing nyuda beban jaringan. Paling ora luwih murah tinimbang ngunggahake dhewe lan nyopir lalu lintas.

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

Nggunakake skema sing padha, kita mriksa file kanthi antivirus (sawise kasunyatan). Sawise kabeh, pangguna ngunggah macem-macem barang menyang Nextcloud lan ora kabeh wong duwe antivirus. Nindakake inspeksi ing wektu pouring mbutuhake wektu akeh lan ngganggu bisnis.

Skalabilitas digayuh kanthi mlaku pelari ing macem-macem simpul kanthi tag sing beda.
Pemantauan kita ngumpulake status serep liwat API GitLab ing siji jendhela; yen perlu, masalah gampang diweruhi lan gampang dilokalisasi.

kesimpulan

Akibaté, kita ngerti manawa kita nggawe serep, yen serep kita bener, masalah sing muncul karo wong-wong mau butuh wektu sethithik lan dirampungake ing tingkat administrator tugas. Serep njupuk munggah tenan sethitik papan dibandhingake tar.gz utawa Bacula.

Source: www.habr.com