GitLab sizga katta NextCloud omborlarini zaxiralashga qanday yordam beradi

Hey Xabr!

Bugun men turli xil konfiguratsiyalarda Nextcloud omborlaridan katta ma'lumotlarni zaxiralashni avtomatlashtirish bo'yicha tajribamiz haqida gapirmoqchiman. Men Molniya AKda xizmat ko'rsatish stantsiyasida ishlayman, u erda biz IT tizimlarining konfiguratsiyasini boshqaramiz; Nextcloud ma'lumotlarni saqlash uchun ishlatiladi. Shu jumladan, taqsimlangan tuzilishga ega, ortiqcha bilan.

O'rnatishlarning xususiyatlaridan kelib chiqadigan muammolar juda ko'p ma'lumotlar mavjud. Nextcloud tomonidan taqdim etilgan versiya, ortiqcha, sub'ektiv sabablar va boshqalar ko'plab dublikatlarni yaratadi.

Sana oldin

Nextcloud-ni boshqarishda samarali zaxirani tashkil qilish muammosi paydo bo'ladi, bu shifrlangan bo'lishi kerak, chunki ma'lumotlar qimmatlidir.

Biz ma'muriyatga moslashuvchan avtomatlashtirilgan yondashuvni talab qiladigan Nextcloud'dan alohida mashinalarda o'z joyimizda yoki mijozning zaxira nusxalarini saqlash variantlarini taklif qilamiz.

Ko'plab mijozlar mavjud, ularning barchasi turli xil konfiguratsiyalarga ega va barchasi o'z saytlarida va o'ziga xos xususiyatlarga ega. Agar butun sayt sizga tegishli bo'lsa va zaxira nusxalari tojlardan qilingan bo'lsa, bu standart usul; u yaxshi mos kelmaydi.

Birinchidan, kirish ma'lumotlarini ko'rib chiqaylik. Bizga kerak:

• Bir yoki bir nechta tugun bo'yicha miqyoslash. Katta o'rnatishlar uchun biz minio-dan saqlash sifatida foydalanamiz.
• Zaxira nusxalarini yaratish bilan bog'liq muammolar haqida bilib oling.
• Siz mijozlaringiz va/yoki biz bilan zaxira nusxasini saqlashingiz kerak.
• Muammolarni tez va oson hal qiling.
• Mijozlar va o'rnatishlar bir-biridan juda farq qiladi - bir xillikka erishib bo'lmaydi.
• Qayta tiklash tezligi ikki stsenariyda minimal bo'lishi kerak: to'liq tiklanish (falokat), bitta jild xatolik bilan o'chirilgan.
• Deduplikatsiya funksiyasi talab qilinadi.

Zaxira nusxalarini boshqarish muammosini hal qilish uchun biz GitLab-ni o'rnatdik. Batafsil ma'lumotlarni hal qilish orqali.

Albatta, biz bunday muammoni birinchi bo'lib hal qilmayapmiz, lekin bizning amaliy, mashaqqatli tajribamiz qiziqarli bo'lishi mumkin va biz buni baham ko'rishga tayyormiz.

Bizning kompaniyamiz ochiq manba siyosatiga ega bo'lganligi sababli, biz ochiq manbali echimni qidirdik. O'z navbatida biz o'z ishlanmalarimizni baham ko'ramiz va ularni joylashtiramiz. Masalan, GitHub-da mavjud Nextcloud uchun plaginimiz, biz mijozlarga taqdim etamiz, tasodifiy yoki qasddan o'chirilgan taqdirda ma'lumotlar xavfsizligini kuchaytiramiz.

Zaxira vositalari

Biz zaxira yaratish vositasini tanlash orqali yechim usullarini qidirishni boshladik.

Oddiy tar + gzip yaxshi ishlamaydi - ma'lumotlar takrorlanadi. O'sish ko'pincha juda kam haqiqiy o'zgarishlarni o'z ichiga oladi va bitta fayldagi ma'lumotlarning ko'pi takrorlanadi.
Yana bir muammo bor - tarqatilgan ma'lumotlarni saqlashning ortiqcha. Biz minio-dan foydalanamiz va uning ma'lumotlari asosan ortiqcha. Yoki siz minio-ning o'zi orqali zaxira nusxasini yaratishingiz kerak edi - uni yuklang va fayl tizimi orasidagi barcha ajratgichlardan foydalaning va bundan ham muhimi, ba'zi chelaklar va meta-ma'lumotlar haqida unutish xavfi mavjud. Yoki deuplikatsiyadan foydalaning.

Ko'paytirishli zaxira vositalari ochiq manbada mavjud (Habré-da bor edi maqolalar ushbu mavzu bo'yicha) va bizning finalchilarimiz Borg и Restik. Ikki dasturni taqqoslashimiz quyida keltirilgan, ammo hozircha biz butun sxemani qanday tashkil qilganimizni aytib beramiz.

Zaxira nusxalarini boshqarish

Borg va Restic yaxshi, lekin hech bir mahsulot markazlashtirilgan boshqaruv mexanizmiga ega emas. Boshqaruv va nazorat qilish uchun biz allaqachon amalga oshirgan vositani tanladik, ularsiz biz o'z ishimizni, shu jumladan avtomatlashtirishni tasavvur qila olmaymiz - bu taniqli CI/CD - GitLab.

G'oya quyidagicha: gitlab-runner Nextcloud ma'lumotlarini saqlaydigan har bir tugunga o'rnatiladi. Yuguruvchi skriptni zaxira jarayonini kuzatuvchi jadval bo'yicha ishga tushiradi va u Borg yoki Restic-ni ishga tushiradi.

Biz nima oldik? Bajarish bo'yicha fikr-mulohazalar, o'zgarishlarni qulay nazorat qilish, xatolik yuz bergan taqdirda tafsilotlar.

shu yerda bu erda GitHub-da biz turli xil vazifalar uchun skript namunalarini joylashtirdik va biz uni nafaqat Nextcloud, balki boshqa ko'plab xizmatlarning zaxira nusxasiga biriktirdik. Agar siz uni qo'lda sozlashni istamasangiz (va biz xohlamasak) va .gitlab-ci.yml uchun rejalashtiruvchi ham mavjud.

Gitlab API-da CI/CD kutish vaqtini o'zgartirishning imkoni yo'q, lekin u kichik. Uni oshirish kerak, deylik 1d.

GitLab, xayriyatki, nafaqat majburiyat bo'yicha, balki faqat jadval bo'yicha ishga tushirilishi mumkin, bu bizga kerak bo'lgan narsadir.

Endi o'rash skripti haqida.

Ushbu skript uchun quyidagi shartlarni o'rnatamiz:

• U yuguruvchi tomonidan ham, bir xil funksiyaga ega bo'lgan konsoldan qo'lda ham ishga tushirilishi kerak.
• Xato ishlov beruvchilari bo'lishi kerak:
• qaytarish kodi.
• jurnalda qatorni qidiring. Misol uchun, biz uchun xato dastur halokatli deb hisoblamaydigan xabar bo'lishi mumkin.
• Vaqt tugashi. Yetkazib berish muddati oqilona bo'lishi kerak.
• Bizga juda batafsil jurnal kerak. Lekin faqat xato bo'lgan taqdirda.
• Boshlashdan oldin bir qator sinovlar ham o'tkaziladi.
• Qo'llab-quvvatlash jarayonida foydali bo'lgan qulaylik uchun kichik bonuslar:
• Boshlanish va tugash mahalliy mashinaning syslogida qayd etiladi. Bu tizim xatolarini va zaxira ishini ulashga yordam beradi.
• Xatolar jurnalining bir qismi, agar mavjud bo'lsa, stdout-ga chiqariladi, butun jurnal alohida faylga yoziladi. Darhol CI ga qarash va agar u ahamiyatsiz bo'lsa, xatoni baholash qulay.
• Nosozliklarni tuzatish rejimlari.

To'liq jurnal GitLab-da artefakt sifatida saqlanadi, agar xato bo'lmasa, jurnal o'chiriladi. Biz skriptni bash-da yozamiz.

Ochiq manbaga oid har qanday taklif va mulohazalarni ko'rib chiqishdan mamnun bo'lamiz - xush kelibsiz.

U qanday ishlaydi

Zaxira tugunida Bash ijrochisi bilan yuguruvchi ishga tushiriladi. Rejalashtiruvchiga ko'ra, CI/CD ishi maxsus sholg'omda ishga tushiriladi. Yuguruvchi bunday vazifalar uchun universal o'rash skriptini ishga tushiradi, u zaxira omborining haqiqiyligini, o'rnatish nuqtalarini va biz xohlagan hamma narsani tekshiradi, so'ngra eskisini zaxiralaydi va tozalaydi. Tayyor zahiraning o'zi S3 ga yuboriladi.

Biz ushbu sxema bo'yicha ishlaymiz - bu tashqi AWS provayderi yoki ruscha ekvivalenti (bu tezroq va ma'lumotlar Rossiya Federatsiyasidan chiqmaydi). Yoki ushbu maqsadlar uchun mijoz uchun uning saytiga alohida minio klaster o'rnatamiz. Biz buni odatda xavfsizlik nuqtai nazaridan, mijoz maʼlumotlarning oʻz sxemasidan umuman chiqib ketishini istamasa, qilamiz.

Biz ssh orqali zaxira nusxasini yuborish xususiyatidan foydalanmadik. Bu xavfsizlikni qo'shmaydi va S3 provayderining tarmoq imkoniyatlari bizning bitta ssh mashinamizdan ancha yuqori.

Mahalliy kompyuteringizni xakerlardan himoya qilish uchun u S3-dagi ma'lumotlarni o'chirib tashlashi mumkinligi sababli, siz versiyani yoqishingiz kerak.
Zaxira har doim zaxirani shifrlaydi.

Borg shifrlanmagan rejimga ega none, lekin biz uni yoqishni qat'iyan tavsiya etmaymiz. Ushbu rejimda nafaqat shifrlash bo'lmaydi, balki yozilayotgan narsaning nazorat summasi hisoblanmaydi, ya'ni yaxlitlik indekslar yordamida faqat bilvosita tekshirilishi mumkin.

Alohida rejalashtiruvchi indekslar va kontentning yaxlitligi uchun zaxira nusxalarini tekshiradi. Tekshiruv sekin va uzoq, shuning uchun biz uni oyda bir marta alohida o'tkazamiz. Bu bir necha kun talab qilishi mumkin.

Readme rus tilida

Asosiy vazifalar

• prepare tayyorlash
• testcheck tayyorlikni tekshirish
• maincommand asosiy jamoa
• forcepostscript oxirida yoki xato bilan bajariladigan funksiya. Biz undan bo'limni o'chirish uchun foydalanamiz.

Xizmat funktsiyalari

• cleanup Biz xatolarni yozamiz yoki jurnal faylini o'chirib tashlaymiz.
• checklog xato bilan chiziq paydo bo'lishi uchun jurnalni tahlil qilish.
• ret chiqish ishlovchisi.
• checktimeout vaqt tugashini tekshiring.

Atrof-muhit

• VERBOSE=1 Biz xatolarni darhol ekranda ko'rsatamiz (stdout).
• SAVELOGSONSUCCES=1 muvaffaqiyat jurnalini saqlang.
• INIT_REPO_IF_NOT_EXIST=1 Agar u mavjud bo'lmasa, ombor yarating. Sukut bo'yicha o'chirilgan.
• TIMEOUT asosiy operatsiya uchun maksimal vaqt. Siz uni oxirida "m", "h" yoki "d" sifatida belgilashingiz mumkin.

Eski nusxalar uchun saqlash rejimi. Standart:

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

Skript ichidagi o'zgaruvchilar

• ERROR_STRING — xatolikni tekshirish jurnali uchun qator.
• EXTRACT_ERROR_STRING — xato bo'lsa, ko'rsatish satri uchun ifoda.
• KILL_TIMEOUT_SIGNAL - agar vaqt tugasa, o'ldirish uchun signal.
• TAIL — ekranda qancha xatoliklar bor.
• COLORMSG — xabar rangi (standart sariq).

Wordpress deb ataladigan o'sha skript shartli nomga ega, uning hiylasi shundaki, u MySQL ma'lumotlar bazasini ham zaxiralaydi. Bu shuni anglatadiki, u bitta tugunli Nexcloud o'rnatishlari uchun ishlatilishi mumkin, bu erda siz ma'lumotlar bazasini zaxiralashingiz mumkin. Qulaylik shundaki, nafaqat hamma narsa bir joyda, balki ma'lumotlar bazasi tarkibi ham fayllar tarkibiga yaqin, chunki vaqt farqi minimaldir.

Restik Borgga qarshi

Borg va Restic o'rtasida ham taqqoslashlar mavjud Habré-da, va bizda boshqasini qilish vazifasi yo'q edi, lekin o'zimizniki. Bu bizning ma'lumotlarimizga, o'ziga xos xususiyatlarimiz bilan qanday ko'rinishi biz uchun muhim edi. Biz ularni olib kelamiz.

Bizning tanlov mezonlarimiz, yuqorida aytib o'tilganlarga qo'shimcha ravishda (deuplikatsiya, tez tiklanish va hk):

• Tugallanmagan ishlarga qarshilik. O'ldirishni tekshiring -9.
• Diskdagi o'lcham.
• Resurslarga bo'lgan talab (CPU, xotira).
• Saqlangan bloblar hajmi.
• S3 bilan ishlash.
• Butunlikni tekshirish.

Sinov uchun biz haqiqiy ma'lumotlarga ega va umumiy hajmi 1,6 TB bo'lgan bitta mijozni oldik.
Shartlar.

Borg S3 bilan to'g'ridan-to'g'ri ishlashni bilmaydi va biz diskni sug'urta sifatida o'rnatdik, orqali ahmoqlar. Restic uni S3 ga yubordi.

Goofys juda tez va yaxshi ishlaydi va bor disk kesh moduli, bu esa ishni yanada tezlashtiradi. Bu beta-bosqichda va ochig'ini aytganda, biz sinovlar paytida (boshqalar) ma'lumotlar yo'qolishi bilan qulab tushdik. Ammo qulaylik shundaki, zaxiralash protsedurasining o'zi ko'p o'qishni talab qilmaydi, lekin asosan yozishni talab qiladi, shuning uchun biz keshdan faqat yaxlitlikni tekshirish vaqtida foydalanamiz.

Tarmoqning ta'sirini kamaytirish uchun biz mahalliy provayder - Yandex Cloud-dan foydalandik.

Taqqoslash test natijalari.

• Yana qayta ishga tushirish bilan -9ni o'ldirish ikkalasi ham muvaffaqiyatli bo'ldi.
• Diskdagi o'lcham. Borg siqilishi mumkin, shuning uchun natijalar kutilganidek bo'ladi.

Zaxirachi
hajmi

Borg
562Gb

Restik
628Gb

• CPU tomonidan
  Borgning o'zi sukut bo'yicha siqish bilan kam iste'mol qiladi, lekin uni goofys jarayoni bilan birgalikda baholash kerak. Hammasi bo'lib, ular solishtirish mumkin va bir xil sinov virtual mashinasida taxminan 1,2 yadrodan foydalanadi.
• Xotira. Restic taxminan 0,5 GB, Borg taxminan 200 MB. Ammo bularning barchasi tizim fayl keshi bilan solishtirganda ahamiyatsiz. Shuning uchun ko'proq xotira ajratish tavsiya etiladi.
• Blob o'lchamidagi farq hayratlanarli edi.

Zaxirachi
hajmi

Borg
taxminan 500 MB

Restik
taxminan 5 MB

• Resticning S3 tajribasi juda yaxshi. Borg bilan goofys orqali ishlash hech qanday savol tug'dirmaydi, ammo keshni to'liq qayta tiklash uchun zaxira tugallangandan so'ng umount qilish tavsiya etiladi. S3 ning o'ziga xos xususiyati shundaki, kam pompalanadigan qismlar hech qachon chelakka yuborilmaydi, ya'ni to'liq to'ldirilmagan ma'lumotlar katta zararga olib keladi.
• Butunlikni tekshirish ikkala holatda ham yaxshi ishlaydi, lekin tezlik sezilarli darajada farq qiladi.
  Restic 3,5 soat.
  Borg, 100 GB SSD fayl keshi bilan - 5 soat.Ma'lumotlar mahalliy diskda bo'lsa, taxminan bir xil tezlik natijasi.
  Borg keshsiz to'g'ridan-to'g'ri S3 dan o'qiydi 33 soat. Dahshatli uzoq vaqt.

Xulosa shuki, Borg siqishni va kattaroq bloblarga ega bo'lishi mumkin - bu S3-da saqlash va GET/PUT operatsiyalarini arzonlashtiradi. Ammo bu yanada murakkab va sekinroq tekshirish narxiga to'g'ri keladi. Qayta tiklash tezligiga kelsak, biz hech qanday farqni sezmadik. Restic keyingi zaxira nusxalarini (birinchisidan keyin) bir oz ko'proq vaqt oladi, lekin sezilarli darajada emas.

Tanlovda oxirgi, lekin eng muhimi, jamiyatning kattaligi edi.

Va biz borgni tanladik.

Siqish haqida bir necha so'z

Borg o'zining arsenalida ajoyib yangi siqish algoritmiga ega - zstd. Siqish sifati gzip dan yomonroq emas, lekin ancha tezroq. Va tezlikda standart lz4 bilan solishtirish mumkin.

Misol uchun, MySQL ma'lumotlar bazasi dump bir xil tezlikda lz4 dan ikki baravar yaxshiroq siqiladi. Biroq, haqiqiy ma'lumotlar bilan tajriba shuni ko'rsatadiki, Nextcloud tugunining siqish nisbatida juda kam farq bor.

Borg juda bonusli siqish rejimiga ega - agar fayl yuqori entropiyaga ega bo'lsa, unda siqish umuman qo'llanilmaydi, bu esa tezlikni oshiradi. Yaratishda opsiya bo'yicha yoqilgan
-C auto,zstd
zstd algoritmi uchun
Shunday qilib, ushbu parametr bilan standart siqish bilan solishtirganda, biz oldik
560 Gb va 562 Gb. Yuqoridagi misoldagi ma'lumotlar, sizga eslatib o'taman, siqilishsiz natija 628 Gb. 2 Gb farqning natijasi bizni biroz hayratda qoldirdi, lekin biz buni oxirigacha tanlaymiz deb o'yladik. auto,zstd.

Zaxira nusxasini tekshirish usuli

Rejalashtiruvchiga ko'ra, virtual mashina to'g'ridan-to'g'ri provayderdan yoki mijozdan ishga tushiriladi, bu tarmoq yukini sezilarli darajada kamaytiradi. Hech bo'lmaganda, uni o'zingiz ko'tarib, trafikni haydashdan ko'ra arzonroqdir.

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/

Xuddi shu sxemadan foydalanib, biz fayllarni antivirus bilan tekshiramiz (haqiqatdan keyin). Axir, foydalanuvchilar Nextcloud-ga turli narsalarni yuklaydilar va hamma ham antivirusga ega emas. To'kish vaqtida tekshirishlarni o'tkazish juda ko'p vaqtni oladi va biznesga aralashadi.

Masshtablilikka turli teglar bilan turli tugunlarda yuguruvchilarni ishga tushirish orqali erishiladi.
Bizning monitoringimiz GitLab API orqali zaxira holatini bir oynada to'playdi; agar kerak bo'lsa, muammolar osongina seziladi va xuddi shunday oson lokalizatsiya qilinadi.

xulosa

Natijada, biz aniq bilamizki, biz zaxira nusxalarini yaratamiz, bizning zaxiralarimiz amal qiladi, ular bilan yuzaga keladigan muammolar oz vaqtni oladi va navbatchi ma'mur darajasida hal qilinadi. Zaxira nusxalari tar.gz yoki Bacula bilan solishtirganda juda kam joy egallaydi.

Manba: www.habr.com