GitLab үлкен NextCloud қоймаларының сақтық көшірмесін жасауға қалай көмектеседі

Эй Хабр!

Бүгін мен әртүрлі конфигурациялардағы Nextcloud қоймаларынан үлкен деректердің сақтық көшірмесін автоматтандыру бойынша тәжірибеміз туралы сөйлескім келеді. Мен Molniya AK компаниясында қызмет көрсету станциясы болып жұмыс істеймін, онда біз IT жүйелерінің конфигурациясын басқарамыз; Nextcloud деректерді сақтау үшін пайдаланылады. Соның ішінде бөлінген құрылымы бар, артықшылығы бар.

Орнату ерекшеліктерінен туындайтын мәселелер деректердің көптігі болып табылады. Nextcloud ұсынған нұсқа, артықшылық, субъективті себептер және т.б. көптеген көшірмелерді жасайды.

тарихын

Nextcloud-ты басқару кезінде тиімді сақтық көшірмені ұйымдастыру мәселесі туындайды, ол шифрлануы керек, өйткені деректер құнды.

Біз сақтық көшірмелерді өз жерімізде немесе тұтынушыда Nextcloud-тың бөлек машиналарында сақтау опцияларын ұсынамыз, бұл басқаруға икемді автоматтандырылған тәсілді қажет етеді.

Көптеген клиенттер бар, олардың барлығы әртүрлі конфигурациялары бар және барлығы өз сайттарында және өзіндік сипаттамалары бар. Бұл бүкіл сайт сізге тиесілі және сақтық көшірмелер тәждерден жасалған кезде стандартты әдіс; ол жақсы сәйкес келмейді.

Алдымен кіріс деректерін қарастырайық. Бізге керек:

• Бір немесе бірнеше түйін бойынша масштабтау. Үлкен қондырғылар үшін сақтау ретінде minio пайдаланамыз.
• Сақтық көшірмелерді орындау кезіндегі ақаулар туралы біліңіз.
• Клиенттеріңізбен және/немесе бізбен бірге сақтық көшірме жасауыңыз қажет.
• Мәселелерді тез және оңай шешіңіз.
• Клиенттер мен қондырғылар бір-бірінен өте ерекшеленеді - біркелкілікке қол жеткізу мүмкін емес.
• Қалпына келтіру жылдамдығы екі сценарийде минималды болуы керек: толық қалпына келтіру (апат), қателікпен жойылған бір қалта.
• Қайталау функциясы қажет.

Сақтық көшірмелерді басқару мәселесін шешу үшін біз GitLab орнаттық. Толығырақ мәліметтерді шешу арқылы.

Әрине, біз мұндай мәселені бірінші болып шешіп жатқан жоқпыз, бірақ біздің тәжірибелік, еңбекпен жинаған тәжірибеміз қызықты болуы мүмкін және біз онымен бөлісуге дайынбыз.

Біздің компанияда ашық бастапқы коды бар саясат болғандықтан, біз ашық бастапқы шешімді іздедік. Өз кезегімізде біз әзірлеген жаңалықтармен бөлісіп, жариялаймыз. Мысалы, GitHub-да бар NextCloud үшін плагинімізкездейсоқ немесе әдейі жойылған жағдайда деректер қауіпсіздігін арттыра отырып, біз клиенттерге береміз.

Сақтық көшірме құралдары

Біз шешім әдістерін іздеуді сақтық көшірме жасау құралын таңдау арқылы бастадық.

Тұрақты tar + gzip жақсы жұмыс істемейді - деректер қайталанады. Үстеме жиі өте аз нақты өзгерістерді қамтиды және бір файлдағы деректердің көп бөлігі қайталанады.
Тағы бір мәселе бар - таратылған деректерді сақтаудың артық болуы. Біз minio пайдаланамыз және оның деректері негізінен артық. Немесе сіз minio арқылы сақтық көшірме жасауыңыз керек болды - оны жүктеңіз және файлдық жүйе арасындағы барлық аралықтарды пайдаланыңыз, және маңызды емес, кейбір шелектерді және мета-ақпаратты ұмытып кету қаупі бар. Немесе дедупликацияны пайдаланыңыз.

Көшірмелері бар сақтық көшірме құралдары ашық көзде қол жетімді (Habré-де бар мақалалар осы тақырыпқа) және финалистеріміз болды Борг и Рестик. Біздің екі қосымшаны салыстыру төменде берілген, бірақ қазір біз бүкіл схеманы қалай ұйымдастырғанымызды айтып береміз.

Сақтық көшірмелерді басқару

Borg және Restic жақсы, бірақ ешбір өнімде орталықтандырылған басқару механизмі жоқ. Басқару және бақылау мақсатында біз қазірдің өзінде енгізген құралды таңдадық, онсыз жұмысымызды, оның ішінде автоматтандыруды елестету мүмкін емес – бұл белгілі CI/CD – GitLab.

Идея келесідей: gitlab-runner Nextcloud деректерін сақтайтын әрбір түйінге орнатылады. Жүгіруші сақтық көшірме жасау процесін бақылайтын кестеде сценарийді іске қосады және ол Borg немесе Restic іске қосады.

Біз не алдық? Орындаудан кері байланыс, өзгерістерді ыңғайлы бақылау, қате болған жағдайда егжей-тегжейлі.

осында мұнда GitHub сайтында біз әртүрлі тапсырмаларға арналған сценарий мысалдарын орналастырдық және біз оны тек Nextcloud ғана емес, сонымен қатар басқа да көптеген қызметтердің сақтық көшірмесіне тіркедік. Егер сіз оны қолмен конфигурациялағыңыз келмесе (және біз қаламаймыз) және .gitlab-ci.yml үшін жоспарлаушы бар.

Gitlab API-де CI/CD күту уақытын өзгертуге әлі ешқандай мүмкіндік жоқ, бірақ ол аз. Оны көбейту керек, айталық 1d.

GitLab, бақытымызға орай, міндеттеме бойынша ғана емес, кесте бойынша ғана іске қосыла алады, бұл бізге қажет нәрсе.

Енді қаптама сценарийі туралы.

Бұл сценарий үшін келесі шарттарды орнатамыз:

• Оны жүгіруші де, бірдей функционалдығы бар консольден қолмен де іске қосу керек.
• Қате өңдеушілер болуы керек:
• қайтару коды.
• журналдан жолды іздеңіз. Мысалы, біз үшін қате бағдарлама қауіпті деп санамайтын хабарлама болуы мүмкін.
• Өңдеу күту уақыты. Жеткізу уақыты ақылға қонымды болуы керек.
• Бізге өте егжей-тегжейлі журнал қажет. Бірақ қате болған жағдайда ғана.
• Бастамас бұрын бірқатар сынақтар да жүргізіледі.
• Қолдау процесінде пайдалы деп тапқан ыңғайлылық үшін шағын бонустар:
• Басталуы мен аяқталуы жергілікті машинаның сислогында жазылады. Бұл жүйе қателерін және сақтық көшірме жұмысын қосуға көмектеседі.
• Қате журналының бір бөлігі, егер бар болса, stdout жүйесіне шығарылады, бүкіл журнал бөлек файлға жазылады. CI-ге дереу қарап, қатені бағалау ыңғайлы, егер ол тривиальды болса.
• Түзету режимдері.

Толық журнал GitLab жүйесінде артефакт ретінде сақталады, егер қате болмаса, журнал жойылады. Біз сценарийді bash тілінде жазамыз.

Ашық дереккөзге қатысты кез келген ұсыныстар мен ескертулерді қарауға қуаныштымыз - қош келдіңіз.

Бұл қалай жұмыс істейді

Bash орындаушысы бар жүгіруші сақтық көшірме түйінінде іске қосылады. Жоспарлаушының айтуынша, CI/CD жұмысы арнайы репада іске қосылады. Жүгіруші осындай тапсырмалар үшін әмбебап орауыш сценарийін іске қосады, ол сақтық көшірме репозиторийінің жарамдылығын, орнату нүктелерін және біз қалағанның барлығын тексереді, содан кейін сақтық көшірме жасайды және ескісін тазартады. Аяқталған сақтық көшірменің өзі S3-ге жіберіледі.

Біз осы схема бойынша жұмыс істейміз - бұл сыртқы AWS провайдері немесе ресейлік баламасы (ол жылдамырақ және деректер Ресей Федерациясынан шықпайды). Немесе біз осы мақсаттар үшін оның сайтында клиент үшін бөлек шағын кластерді орнатамыз. Біз мұны әдетте қауіпсіздік мақсатында, клиент деректердің өз тізбегінен мүлде кеткенін қаламағанда жасаймыз.

Біз ssh арқылы сақтық көшірме жіберу мүмкіндігін пайдаланбадық. Бұл қауіпсіздікті арттырмайды және S3 провайдерінің желілік мүмкіндіктері біздің бір ssh құрылғысынан әлдеқайда жоғары.

Жергілікті компьютеріңізді хакерлерден қорғау үшін, ол S3 жүйесіндегі деректерді өшіре алатындықтан, нұсқаны қосу керек.
Сақтық көшірме әрқашан сақтық көшірмені шифрлайды.

Боргтың шифрланбаған режимі бар none, бірақ біз оны қосуды ұсынбаймыз. Бұл режимде тек шифрлау болмайды, бірақ жазылған нәрсенің бақылау сомасы есептелмейді, яғни тұтастықты индекстерді пайдаланып тек жанама түрде тексеруге болады.

Бөлек жоспарлаушы резервтік көшірмелерді индекстер мен мазмұнның тұтастығын тексереді. Тексеру баяу және ұзақ, сондықтан біз оны айына бір рет бөлек жүргіземіз. Бірнеше күн қажет болуы мүмкін.

Орыс тілінде Readme

Негізгі функциялар

• prepare дайындау
• testcheck дайындығын тексеру
• maincommand негізгі команда
• forcepostscript соңында немесе қате арқылы орындалатын функция. Біз оны бөлімді ажырату үшін қолданамыз.

Қызметтік функциялар

• cleanup Біз қателерді жазамыз немесе журнал файлын өшіреміз.
• checklog қатесі бар жолдың пайда болуы үшін журналды талдау.
• ret өңдеушіден шығу.
• checktimeout күту уақыты бар-жоғын тексеріңіз.

қоршаған орта

• VERBOSE=1 Біз қателерді экранда дереу көрсетеміз (stdout).
• SAVELOGSONSUCCES=1 Сәттілікке байланысты журналды сақтаңыз.
• INIT_REPO_IF_NOT_EXIST=1 Егер ол жоқ болса, репозиторий жасаңыз. Әдепкі бойынша өшірілген.
• TIMEOUT негізгі операцияның максималды уақыты. Оны соңында «m», «h» немесе «d» ретінде орнатуға болады.

Ескі көшірмелер үшін сақтау режимі. Әдепкі:

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

Сценарий ішіндегі айнымалылар

• ERROR_STRING — қатені тексеру журналына арналған жол.
• EXTRACT_ERROR_STRING — қате болса, жолды көрсету үшін өрнек.
• KILL_TIMEOUT_SIGNAL — күту уақыты бітсе, өлтіру сигналы.
• TAIL — экранда қателері бар қанша жол.
• COLORMSG — хабардың түсі (әдепкі сары).

Wordpress деп аталатын скрипттің шартты атауы бар, оның айласы - MySQL дерекқорының сақтық көшірмесін жасауында. Бұл оның дерекқордың сақтық көшірмесін жасауға болатын бір түйінді Nexcloud қондырғылары үшін пайдаланылуы мүмкін дегенді білдіреді. Ыңғайлылық барлығы бір жерде ғана емес, сонымен қатар деректер қорының мазмұны файлдардың мазмұнына жақын, өйткені уақыт айырмашылығы аз.

Рестик Боргқа қарсы

Борг пен Рестич арасында да салыстырулар бар мұнда Хабреде, және бізде басқасын жасау емес, өзіміздің міндетіміз болды. Біз үшін оның біздің деректерімізге, біздің ерекшеліктерімізге қалай қарайтыны маңызды болды. Біз оларды әкелеміз.

Біздің іріктеу критерийлері, жоғарыда аталғандарға қосымша (дедупликация, жылдам қалпына келтіру және т.б.):

• Аяқталмаған жұмысқа қарсылық. Өлтіруді тексеріңіз -9.
• Дискідегі өлшем.
• Ресурстарға қойылатын талаптар (CPU, жад).
• Сақталған блоктардың өлшемі.
• S3-пен жұмыс.
• Тұтастығын тексеру.

Тестілеу үшін біз нақты деректері бар және жалпы көлемі 1,6 ТБ болатын бір клиентті алдық.
Шарттары.

Борг S3-пен тікелей жұмыс істеуді білмейді, және біз дискіні сақтандырғыш ретінде орнаттық, арқылы ақымақ. Рестик оны S3-ге жіберді.

Goofys өте тез және жақсы жұмыс істейді, және бар дискінің кэш модулі, бұл жұмысты одан да тездетеді. Бұл бета сатысында және, шынын айтқанда, сынақтар кезінде деректердің жоғалуына байланысты апатқа ұшырадық (басқалар). Бірақ ыңғайлылығы, сақтық көшірме жасау процедурасының өзі көп оқуды қажет етпейді, бірақ негізінен жазуды қажет етеді, сондықтан біз кэшті тұтастықты тексеру кезінде ғана пайдаланамыз.

Желінің әсерін азайту үшін біз жергілікті провайдерді қолдандық - Yandex Cloud.

Тестілеу нәтижелерін салыстыру.

• Тағы қайта іске қосу арқылы Kill -9 екеуі де сәтті болды.
• Дискідегі өлшем. Борг қыса алады, сондықтан нәтиже күткендей болады.

Сақтық көшірмеші
мөлшері

Борг
562Gb

Рестик
628Gb

• CPU арқылы
  Боргтың өзі әдепкі қысу арқылы аз тұтынады, бірақ оны goofys процесімен бірге бағалау керек. Жалпы алғанда, олар салыстырмалы және бір сынақ виртуалды машинасында шамамен 1,2 ядроларды пайдаланады.
• Жад. Restic шамамен 0,5 ГБ, Borg шамамен 200 МБ. Бірақ мұның бәрі жүйелік файл кэшімен салыстырғанда шамалы. Сондықтан жадты көбірек бөлген жөн.
• Блоб өлшеміндегі айырмашылық таң қалдырды.

Сақтық көшірмеші
мөлшері

Борг
шамамен 500 МБ

Рестик
шамамен 5 МБ

• Рестиктің S3 тәжірибесі тамаша. Borg-пен goofys арқылы жұмыс істеу ешқандай сұрақ тудырмайды, бірақ кэшті толығымен қалпына келтіру үшін сақтық көшірме аяқталғаннан кейін umount әрекетін жасаған жөн деп атап өтілді. S3 ерекшелігі - аз сорылған бөліктер ешқашан шелекке жіберілмейді, бұл толық емес толтырылған деректер үлкен зақымға әкеледі.
• Тұтастықты тексеру екі жағдайда да жақсы жұмыс істейді, бірақ жылдамдық айтарлықтай ерекшеленеді.
  Рестик 3,5 сағат.
  Borg, 100 ГБ SSD файл кэшімен – 5 сағат.Дерек жергілікті дискіде болса, шамамен бірдей жылдамдық нәтижесі.
  Борг кэшсіз S3 жүйесінен тікелей оқиды 33 сағат. Жансыз ұзақ.

Түпнұсқа мынада: Борг қыса алады және үлкенірек бөртпелер бар - бұл S3 жүйесінде сақтау және GET/PUT операцияларын арзанырақ етеді. Бірақ бұл күрделірек және баяу тексеру құнына байланысты. Қалпына келтіру жылдамдығына келетін болсақ, біз ешқандай айырмашылықты байқамадық. Restic кейінгі сақтық көшірмелерді (біріншіден кейін) сәл ұзағырақ алады, бірақ айтарлықтай емес.

Соңғысы, бірақ таңдауда қауымдастықтың көлемі болды.

Ал біз боргты таңдадық.

Қысу туралы бірнеше сөз

Borg өзінің арсеналында тамаша жаңа қысу алгоритмі бар - zstd. Қысу сапасы gzip-тен жаман емес, бірақ әлдеқайда жылдам. Және жылдамдығы бойынша әдепкі lz4-пен салыстыруға болады.

Мысалы, MySQL дерекқорының демпі бірдей жылдамдықта lz4-ке қарағанда екі есе жақсы қысылады. Дегенмен, нақты деректермен тәжірибе Nextcloud түйінінің қысу коэффициентінде өте аз айырмашылық бар екенін көрсетеді.

Боргта өте бонустық қысу режимі бар - егер файлда жоғары энтропия болса, онда қысу мүлдем қолданылмайды, бұл жылдамдықты арттырады. Жасау кезінде опция арқылы қосылады
-C auto,zstd
zstd алгоритмі үшін
Осылайша, бұл опциямен әдепкі қысумен салыстырғанда біз алдық
560 Гб және 562 Гб. Жоғарыда келтірілген мысалдағы деректер, еске салайын, қысусыз нәтиже 628 Гб. 2 ГБ айырмашылықтың нәтижесі бізді таң қалдырды, бірақ біз оны таңдаймыз деп ойладық. auto,zstd.

Сақтық көшірмені тексеру әдісі

Жоспарлаушының айтуынша, виртуалды машина тікелей провайдерден немесе клиенттен іске қосылады, бұл желі жүктемесін айтарлықтай азайтады. Кем дегенде, бұл оны өзіңіз көтеруден және трафикті жүргізуден арзанырақ.

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/

Сол схеманы қолдана отырып, біз файлдарды антивируспен тексереміз (фактінен кейін). Ақыр соңында, пайдаланушылар Nextcloud-қа әртүрлі нәрселерді жүктейді және барлығында антивирус жоқ. Құю кезінде тексеру жүргізу тым көп уақытты алады және бизнеске кедергі келтіреді.

Масштабтылық әртүрлі тегтері бар әртүрлі түйіндерде жүгірушілерді іске қосу арқылы қол жеткізіледі.
Біздің мониторингіміз GitLab API арқылы сақтық көшірме күйлерін бір терезеде жинайды; қажет болған жағдайда проблемалар оңай байқалады және оңай локализацияланады.

қорытынды

Нәтижесінде біз сақтық көшірмелерді жасайтынымызды, сақтық көшірмелеріміздің жарамды екенін, олармен туындаған мәселелер аз уақытты қажет ететінін және кезекші әкімші деңгейінде шешілетінін нақты білеміз. Сақтық көшірмелер tar.gz немесе Bacula салыстырғанда өте аз орын алады.

Ақпарат көзі: www.habr.com