Bagaimana GitLab membantu membuat sandaran repositori NextCloud yang besar

Hai Habr!

Hari ini saya ingin berkongsi pengalaman kami mengautomasikan sandaran data besar untuk sistem storan Nextcloud dalam pelbagai konfigurasi. Saya bekerja sebagai CTO di Molniya AK, di mana kami mengendalikan pengurusan konfigurasi untuk sistem IT. Nextcloud digunakan untuk penyimpanan data, termasuk dengan struktur yang diedarkan dan redundansi.

Masalah yang berpunca daripada sifat khusus pemasangan ialah terdapat banyak data. Pemberian versi Nextcloud, redundansi, faktor subjektif dan faktor lain mencipta banyak pendua.

prasejarah

Apabila mentadbir Nextcloud, masalah mengatur sandaran yang berkesan menjadi akut. Ia mesti disulitkan, kerana data itu berharga.

Kami menawarkan pilihan storan sandaran sama ada di premis kami atau pada mesin pelanggan sendiri, berasingan daripada Nextcloud, yang memerlukan pendekatan pentadbiran yang fleksibel dan automatik.

Terdapat banyak pelanggan, semuanya dengan konfigurasi yang berbeza, dan masing-masing pada platform mereka sendiri dengan keperluan khusus mereka sendiri. Pendekatan standard untuk memiliki keseluruhan platform dan membuat sandaran daripada Cron adalah tidak sesuai.

Mari kita mulakan dengan melihat data input. Kami memerlukan:

• Kebolehskalaan: satu atau berbilang nod. Untuk pemasangan besar, kami menggunakan minio untuk penyimpanan.
• Ketahui tentang masalah dengan melakukan sandaran.
• Adalah perlu untuk menyimpan sandaran di pelanggan dan/atau di tempat kami.
• Tangani masalah dengan cepat dan mudah.
• Pelanggan dan pemasangan sangat berbeza antara satu sama lain, menjadikannya sukar untuk mencapai keseragaman.
• Kelajuan pemulihan hendaklah minimum dalam dua senario: pemulihan penuh (bencana), satu folder - tersalah dipadam.
• Ciri deduplikasi diperlukan.

Untuk menyelesaikan masalah pengurusan sandaran, kami menyepadukan GitLab. Butiran lanjut dalam artikel.

Sudah tentu, kami bukanlah orang pertama yang menyelesaikan masalah sedemikian, tetapi kami percaya bahawa pengalaman praktikal kami yang dimenangi dengan susah payah boleh menarik, dan kami bersedia untuk berkongsinya.

Memandangkan syarikat kami mempunyai dasar sumber terbuka, kami sedang mencari penyelesaian sumber terbuka. Kami juga berkongsi perkembangan kami dan menyediakannya. Sebagai contoh, kami mempunyainya di GitHub. pemalam kami untuk Nextcloud, yang kami sediakan kepada pelanggan kami, meningkatkan keselamatan data sekiranya berlaku pemadaman secara tidak sengaja atau sengaja.

Alat sandaran

Kami memulakan carian kami untuk penyelesaian dengan memilih alat sandaran.

Tar + gzip standard berfungsi dengan baik—data diduakan. Kenaikan selalunya mengandungi sedikit perubahan sebenar dan kebanyakan data dalam satu fail diulang.
Terdapat satu lagi masalah: lebihan storan data teragih. Kami menggunakan minio, dan datanya pada asasnya berlebihan. Sebagai alternatif, kita perlu membuat sandaran melalui minio itu sendiri—memuatkannya dan menggunakan semua penimbal sistem fail. Dan, sama pentingnya, terdapat risiko untuk melupakan beberapa baldi dan metadata. Atau kita boleh menggunakan deduplikasi.

Alat sandaran dengan pendua tersedia dalam sumber terbuka (ia ada di Habr Perkara mengenai topik ini) dan finalis kami ialah Borg и RestikKami akan membincangkan perbandingan kedua-dua apl di bawah, tetapi buat masa ini, mari kita bincangkan tentang cara kami mengatur keseluruhan skim.

Menguruskan penciptaan sandaran

Borg dan Restic bagus, tetapi kedua-dua produk tidak mempunyai mekanisme pengurusan terpusat. Untuk pengurusan dan kawalan, kami memilih alat yang telah kami sediakan dan tidak dapat membayangkan kerja kami tanpa, termasuk automasi—alat CI/CD yang terkenal GitLab.

Ideanya ialah ini: gitlab-runner dipasang pada setiap nod yang menyimpan data Nextcloud. Pelari menjalankan skrip berjadual yang memantau proses sandaran, yang kemudiannya melancarkan Borg atau Restic.

Apa yang kita dapat? Maklum balas tentang kemajuan, kawalan perubahan yang mudah dan butiran sekiranya berlaku ralat.

di sini ialah di sini di GitHub Kami menyiarkan skrip sampel untuk pelbagai tugas, dan kami akhirnya menggunakannya untuk sandaran bukan sahaja Nextcloud tetapi juga banyak perkhidmatan lain. Terdapat juga penjadual jika anda tidak mahu mengkonfigurasinya secara manual (yang kami tidak lakukan) dan .gitlab-ci.yml

API GitLab pada masa ini tidak membenarkan anda menukar tamat masa CI/CD, dan ia pendek. Ia perlu ditingkatkan, katakan, kepada 1d.

Nasib baik, GitLab boleh menjalankan replikasi bukan sahaja pada komit, tetapi juga mengikut jadual, iaitu apa yang kita perlukan.

Sekarang mengenai skrip pembalut.

Kami menetapkan syarat berikut untuk skrip ini:

• Ia harus dilancarkan oleh pelari dan secara manual dari konsol dengan fungsi yang sama.
• Pengendali ralat diperlukan:
• kembalikan kod.
• Cari rentetan dalam log. Sebagai contoh, bagi kami, ralat mungkin mesej yang program tidak anggap membawa maut.
• Pemprosesan tamat masa. Masa pelaksanaan mestilah munasabah.
• Kami memerlukan log yang sangat terperinci. Tetapi hanya sekiranya berlaku kesilapan.
• Beberapa siri ujian juga dijalankan sebelum permulaan.
• Berikut ialah beberapa ciri kemudahan kecil yang kami dapati membantu semasa proses sokongan kami:
• Masa mula dan tamat direkodkan dalam syslog mesin tempatan. Ini membantu memautkan ralat sistem kepada aktiviti sandaran.
• Sebahagian daripada log ralat, jika ada, adalah output kepada stdout, manakala keseluruhan log ditulis ke fail berasingan. Ini memudahkan untuk melihat ralat dalam CI dengan cepat dan menilai jika ia remeh.
• Mod nyahpepijat.

Log penuh disimpan sebagai artifak dalam GitLab; jika tiada ralat, log dipadamkan. Skrip ditulis dalam bash.

Kami mengalu-alukan sebarang cadangan atau komen mengenai sumber terbuka.

Как это работает

Pelari dengan pelaksana Bash dilancarkan pada nod yang disandarkan. Tugas CI/CD dilancarkan dalam repo khas menggunakan penjadual. Pelari menjalankan skrip, pembungkus universal untuk tugasan sedemikian, yang menyemak kesahihan repositori sandaran, titik lekap, dan apa-apa lagi yang diperlukan, kemudian melakukan sandaran dan membersihkan sandaran lama. Sandaran yang lengkap dihantar ke S3.

Kami bekerja dengan pendekatan ini: kami menggunakan pembekal luaran, AWS atau yang setara dengan Rusia (ia lebih pantas dan data tidak meninggalkan Rusia). Sebagai alternatif, kami menyediakan kluster minio yang berasingan di premis pelanggan untuk tujuan ini. Kami biasanya melakukan ini atas sebab keselamatan, apabila pelanggan sama sekali tidak mahu data meninggalkan premis mereka.

Kami memutuskan untuk tidak menggunakan ciri sandaran SSH. Ia tidak meningkatkan keselamatan, dan keupayaan rangkaian pembekal S3 jauh lebih baik daripada mesin SSH tunggal kami.

Untuk melindungi mesin tempatan anda daripada penggodam yang boleh memadamkan data pada S3, adalah penting untuk mendayakan versi.
Pencadang sentiasa menyulitkan sandaran.

Borg mempunyai mod tanpa penyulitan none, tetapi kami amat mengesyorkan agar tidak mendayakannya. Dalam mod ini, bukan sahaja tiada penyulitan, tetapi jumlah semak apa yang sedang ditulis tidak dikira, bermakna integriti hanya boleh disahkan secara tidak langsung, menggunakan indeks.

Penjadual berasingan digunakan untuk menyemak integriti indeks dan kandungan sandaran. Semakan ini lambat dan memakan masa, jadi kami menjalankannya secara berasingan sebulan sekali. Ia boleh mengambil masa beberapa hari.

Readme dalam bahasa Rusia

Fungsi utama

• prepare latihan
• testcheck pemeriksaan kesediaan
• maincommand pasukan utama
• forcepostscript Fungsi yang dilaksanakan pada akhir atau secara ralat. Kami menggunakannya untuk menyahlekap partition.

Fungsi perkhidmatan

• cleanup Kami merekodkan ralat atau memadam fail log.
• checklog menghuraikan log untuk kemasukan baris dengan ralat.
• ret pengendali keluar.
• checktimeout semak tamat masa.

alam Sekitar

• VERBOSE=1 Kami memaparkan ralat pada skrin serta-merta (stdout).
• SAVELOGSONSUCCES=1 kami menyimpan log apabila berjaya.
• INIT_REPO_IF_NOT_EXIST=1 Buat repositori jika ia tidak wujud. Dilumpuhkan secara lalai.
• TIMEOUT Masa maksimum untuk operasi utama. Anda boleh menetapkannya sebagai 'm', 'h' atau 'd' pada penghujungnya.

Mod storan untuk salinan lama. Lalai:

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

Pembolehubah dalam skrip

• ERROR_STRING — rentetan untuk log daftar masuk untuk ralat.
• EXTRACT_ERROR_STRING — ungkapan untuk menunjukkan rentetan jika ralat.
• KILL_TIMEOUT_SIGNAL — isyarat untuk membunuh jika tamat masa.
• TAIL — berapa banyak rentetan dengan ralat pada skrin.
• COLORMSG — warna mesej (kuning lalai).

Skrip yang dipanggil "Wordpress" adalah nama yang longgar, tetapi ciri khasnya ialah ia juga menyandarkan pangkalan data MySQL. Ini bermakna ia boleh digunakan untuk pemasangan Nexcloud nod tunggal, di mana anda juga boleh menyandarkan pangkalan data. Bukan sahaja semuanya mudah di satu tempat, tetapi kandungan pangkalan data juga hampir dengan kandungan fail, kerana perbezaan masa adalah minimum.

Restic lwn Borg

Terdapat juga perbandingan antara Borg dan Restic di sini di Habr, dan matlamat kami bukan untuk mencipta satu lagi, tetapi matlamat kami sendiri. Kami berminat dengan penampilannya berdasarkan data kami, berdasarkan spesifikasi kami. Kami menyediakan maklumat itu.

Kriteria pemilihan kami, sebagai tambahan kepada yang telah disebutkan (deduplikasi, pemulihan cepat, dll.):

• Toleransi terhadap kerja yang belum selesai. Semak untuk membunuh -9.
• Saiz pada cakera.
• Keperluan sumber (CPU, memori).
• Saiz gumpalan yang disimpan.
• Bekerja dengan S3.
• Pemeriksaan integriti.

Untuk ujian, kami mengambil satu pelanggan dengan data sebenar dan jumlah saiz 1,6 TB.
Syarat-syarat.

Borg tidak boleh berfungsi secara langsung dengan S3, dan kami memasangnya sebagai cakera fius, melalui goofysRestic menghantarnya ke S3 sendiri.

Goofys berfungsi dengan sangat pantas dan baik, dan ia disertakan bersama modul cache cakera, yang mempercepatkan lagi perkara. Ia masih dalam versi beta, dan terus terang, kami telah mengalami beberapa ranap dengan kehilangan data semasa ujian (orang lain). Tetapi kelebihannya ialah proses sandaran itu sendiri tidak memerlukan banyak bacaan, tetapi kebanyakannya menulis, jadi kami hanya menggunakan cache semasa pemeriksaan integriti.

Untuk mengurangkan impak rangkaian, kami menggunakan pembekal tempatan, Yandex Cloud.

Keputusan ujian perbandingan.

• Bunuh -9 dengan mulakan semula seterusnya kedua-duanya berjaya.
• Saiz pada cakera. Borg mampu memampatkan, jadi hasilnya seperti yang diharapkan.

Penyokong
saiz

Borg
562Gb

Restik
628Gb

• Oleh CPU
  Borg sendiri menggunakan sedikit kuasa, walaupun dengan pemampatan lalai, tetapi ia harus dinilai bersama-sama dengan proses goofys. Bersama-sama, mereka adalah setanding, menggunakan kira-kira 1,2 teras pada VM ujian yang sama.
• Ingatan. Restic adalah lebih kurang 0,5 GB, Borg adalah sekitar 200 MB. Tetapi ini semua tidak penting berbanding dengan cache fail sistem. Oleh itu, adalah dinasihatkan untuk memperuntukkan lebih banyak memori.
• Perbezaan dalam saiz gumpalan sangat ketara.

Penyokong
saiz

Borg
kira-kira 500 MB

Restik
kira-kira 5 MB

• Restic berfungsi hebat dengan S3. Borg berfungsi dengan baik dengan goofys, tetapi saya perhatikan bahawa adalah dinasihatkan untuk menyahlekap selepas sandaran untuk membersihkan cache sepenuhnya. Keistimewaan S3 ialah bahagian yang tidak lengkap tidak pernah dihantar ke baldi, bermakna data yang tidak dimuat naik secara lengkap boleh membawa kepada rasuah yang ketara.
• Pemeriksaan integriti berfungsi dengan baik dalam kedua-dua kes, tetapi kelajuannya berbeza dengan ketara.
  Berehat – Jam 3,5.
  Borg, dengan cache fail SSD 100GB – Jam 5Hasil kelajuan yang lebih kurang sama jika data terletak pada cakera tempatan.
  Borg membaca terus dari S3 tanpa caching Jam 33. Panjang sangat.

Intinya ialah Borg boleh memampatkan dan mempunyai gumpalan yang lebih besar, menjadikan penyimpanan dan operasi GET/PUT dalam S3 lebih murah. Walau bagaimanapun, ini melibatkan kos pengesahan yang lebih kompleks dan lebih perlahan. Bagi kelajuan pemulihan, kami tidak melihat sebarang perbezaan. Restic mengambil masa lebih lama untuk melakukan sandaran berikutnya (selepas yang pertama), tetapi tidak begitu ketara.

Saiz komuniti bukanlah faktor yang paling penting dalam pilihan.

Dan kami memilih borg.

Beberapa perkataan mengenai pemampatan

Borg mempunyai algoritma pemampatan baharu yang hebat, zstd. Kualiti mampatannya tidak lebih buruk daripada gzip, tetapi jauh lebih pantas. Ia juga setanding dari segi kelajuan dengan lz4 lalai.

Sebagai contoh, longgokan pangkalan data MySQL memampatkan dua kali ganda serta lz4 pada kelajuan yang sama. Walau bagaimanapun, data dunia sebenar menunjukkan bahawa terdapat sedikit perbezaan dalam nisbah mampatan pada nod Nextcloud.

Borg mempunyai mod pemampatan yang agak istimewa: jika fail mempunyai entropi tinggi, tiada pemampatan digunakan, yang meningkatkan kelajuan. Ini didayakan melalui pilihan semasa penciptaan.
-C auto,zstd
untuk algoritma zstd
Jadi dengan pilihan ini, berbanding dengan pemampatan lalai, kami dapat
560GB dan 562GB, masing-masing. Sebagai peringatan, hasil tidak dimampatkan daripada contoh di atas ialah 628GB. Perbezaan 2GB agak mengejutkan, tetapi kami memutuskan untuk menggunakan yang terakhir. auto,zstd.

Kaedah pengesahan sandaran

Penjadual melancarkan mesin maya terus di premis pembekal atau pelanggan, dengan ketara mengurangkan beban rangkaian. Sekurang-kurangnya, ia lebih murah daripada menyediakan dan mengurus trafik secara dalaman.

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/

Kami menggunakan pendekatan yang sama untuk mengimbas fail dengan perisian antivirus (post-factum). Lagipun, pengguna memuat naik pelbagai perkara ke Nextcloud, dan tidak semua orang mempunyai perisian antivirus. Mengimbas fail pada masa muat naik mengambil terlalu banyak masa dan menghalang perniagaan.

Kebolehskalaan dicapai dengan menjalankan pelari pada nod yang berbeza dengan tag yang berbeza.
Pemantauan kami mengumpul status sandaran melalui API GitLab dalam satu tetingkap, menjadikan masalah mudah dikenal pasti dan disetempatkan.

Kesimpulan

Akibatnya, kami tahu pasti bahawa kami membuat sandaran, sandaran kami adalah sah dan sebarang isu yang timbul dengannya diselesaikan dengan cepat dan mudah oleh pentadbir yang bertugas. Sandaran mengambil sedikit ruang berbanding tar.gz atau Bacula.

Sumber: www.habr.com