Ինչպես է GitLab-ն օգնում ձեզ կրկնօրինակել NextCloud-ի մեծ պահեստները

Հե՜յ Հաբր։

Այսօր ես ուզում եմ խոսել Nextcloud-ի տարբեր կոնֆիգուրացիաներով մեծ տվյալների կրկնօրինակման ավտոմատացման մեր փորձի մասին: Ես աշխատում եմ որպես սպասարկման կետ Molniya AK-ում, որտեղ մենք իրականացնում ենք ՏՏ համակարգերի կոնֆիգուրացիայի կառավարում; Nextcloud-ն օգտագործվում է տվյալների պահպանման համար: Այդ թվում՝ բաշխված կառուցվածքով, ավելորդությամբ։

Տեղադրումների առանձնահատկություններից բխող խնդիրներն այն են, որ շատ տվյալներ կան։ Nextcloud-ի կողմից տրամադրված տարբերակները, ավելորդությունը, սուբյեկտիվ պատճառները և այլն, ստեղծում են բազմաթիվ կրկնօրինակներ:

նախապատմությանը

Nextcloud-ը կառավարելիս առաջանում է արդյունավետ կրկնօրինակում կազմակերպելու խնդիր, որը պետք է կոդավորված լինի, քանի որ տվյալները արժեքավոր են։

Մենք առաջարկում ենք կրկնօրինակներ մեր տեղում կամ հաճախորդի մոտ Nextcloud-ի առանձին մեքենաներում պահելու տարբերակներ, ինչը պահանջում է ճկուն ավտոմատացված մոտեցում վարչարարությանը:

Շատ հաճախորդներ կան, բոլորն էլ տարբեր կոնֆիգուրացիաներով, բոլորն էլ իրենց սեփական կայքերում և իրենց առանձնահատկություններով: Սա ստանդարտ տեխնիկա է, երբ ամբողջ կայքը պատկանում է ձեզ, և կրկնօրինակները պատրաստվում են պսակներից, այն լավ չի տեղավորվում:

Նախ, եկեք նայենք մուտքային տվյալներին: Կարիք ունենք:

• Ընդարձակություն մեկ կամ մի քանի հանգույցի առումով: Խոշոր տեղադրումների համար մենք օգտագործում ենք Minio որպես պահեստ:
• Իմացեք կրկնօրինակումներ կատարելու հետ կապված խնդիրների մասին:
• Դուք պետք է պահեք ձեր հաճախորդների և/կամ մեզ մոտ:
• Արագ և հեշտությամբ լուծեք խնդիրները:
• Հաճախորդները և տեղադրումները շատ տարբեր են միմյանցից. միատեսակությունը հնարավոր չէ հասնել:
• Վերականգնման արագությունը պետք է լինի նվազագույն երկու սցենարներում՝ ամբողջական վերականգնում (աղետ), սխալմամբ ջնջված մեկ թղթապանակ:
• Պահանջվում է կրկնօրինակման գործառույթ:

Կրկնօրինակների կառավարման խնդիրը լուծելու համար մենք տեղադրեցինք GitLab-ը։ Լրացուցիչ մանրամասները ըստ ճարման:

Իհարկե, մենք առաջինը չենք, որ լուծում ենք նման խնդիր, բայց մեզ թվում է, որ մեր գործնական, դժվարությամբ ձեռք բերած փորձը կարող է հետաքրքիր լինել, և մենք պատրաստ ենք կիսվել դրանով։

Քանի որ մեր ընկերությունն ունի բաց կոդով քաղաքականություն, մենք փնտրում էինք բաց կոդով լուծում: Իր հերթին մենք կիսվում ենք մեր զարգացումներով և տեղադրում դրանք։ Օրինակ, GitHub-ում կա մեր plugin-ը 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-ը, բարեբախտաբար, կարող է գործարկել ոչ միայն ըստ commit-ի, այլ միայն ըստ ժամանակացույցի, սա հենց այն է, ինչ մեզ անհրաժեշտ է:

Հիմա փաթաթման սցենարի մասին։

Մենք սահմանել ենք հետևյալ պայմանները այս սցենարի համար.

• Այն պետք է գործարկվի ինչպես վազորդի կողմից, այնպես էլ ձեռքով նույն ֆունկցիոնալությամբ վահանակից:
• Պետք է լինեն սխալների մշակիչներ.
• վերադարձի կոդը:
• որոնել տող մատյանում: Օրինակ, մեզ համար սխալը կարող է լինել հաղորդագրություն, որը ծրագիրը չի համարում ճակատագրական:
• Մշակման ժամանակի ավարտ: Առաջատար ժամանակը պետք է լինի ողջամիտ:
• Մեզ պետք է շատ մանրամասն մատյան: Բայց միայն սխալի դեպքում։
• Սկսելուց առաջ կատարվում են նաև մի շարք թեստեր։
• Փոքր բոնուսներ հարմարության համար, որոնք մենք օգտակար գտանք աջակցության գործընթացում.
• Սկիզբը և ավարտը գրանցվում են տեղական մեքենայի syslog-ում: Սա օգնում է միացնել համակարգի սխալները և կրկնօրինակման գործողությունը:
• Սխալների գրանցամատյանի մի մասը, եթե այդպիսիք կան, դուրս է բերվում stdout-ում, ամբողջ գրանցամատյանը գրվում է առանձին ֆայլում: Հարմար է անմիջապես նայել CI-ին և գնահատել սխալը, եթե այն չնչին է:
• Վրիպազերծման ռեժիմներ.

Ամբողջական գրանցամատյանը պահպանվում է որպես արտեֆակտ GitLab-ում, եթե սխալ չկա, գրանցամատյանը ջնջվում է: Սցենարը գրում ենք բաշով։

Մենք ուրախ կլինենք դիտարկել ցանկացած առաջարկ և մեկնաբանություն բաց կոդով - ողջունում ենք:

Ինչպես է այն աշխատում

Պահուստային հանգույցի վրա գործարկվում է Bash կատարողով վազորդ: Ըստ ժամանակացույցի, աշխատանքի CI/CD-ն գործարկվում է հատուկ շաղգամով: Վազողը գործարկում է ունիվերսալ փաթաթման սցենար նման առաջադրանքների համար, այն ստուգում է պահուստային պահեստի վավերականությունը, ամրացման կետերը և այն ամենը, ինչ մենք ուզում ենք, այնուհետև կրկնօրինակում և մաքրում է հինը: Ավարտված կրկնօրինակն ինքնին ուղարկվում է S3:

Մենք աշխատում ենք այս սխեմայի համաձայն՝ դա արտաքին AWS մատակարար է կամ ռուսական համարժեք (դա ավելի արագ է, և տվյալները չեն հեռանում Ռուսաստանի Դաշնությունից): Կամ մենք տեղադրում ենք առանձին մինի կլաստեր հաճախորդի համար իր կայքում այդ նպատակների համար: Մենք սովորաբար դա անում ենք անվտանգության նկատառումներից ելնելով, երբ հաճախորդը չի ցանկանում, որ տվյալներն ընդհանրապես դուրս գան իրենց միացումից:

Մենք չենք օգտագործել ssh-ի միջոցով կրկնօրինակում ուղարկելու հնարավորությունը։ Սա չի ավելացնում անվտանգությունը, և S3 մատակարարի ցանցային հնարավորությունները շատ ավելի բարձր են, քան մեր մեկ ssh մեքենան:

Որպեսզի պաշտպանեք ձեր տեղական մեքենան հաքերից, քանի որ նա կարող է ջնջել տվյալները S3-ի վրա, դուք պետք է միացնեք տարբերակումը:
Կրկնօրինակը միշտ կոդավորում է կրկնօրինակը:

Borg-ն ունի չգաղտնագրված ռեժիմ none, բայց մենք կտրականապես խորհուրդ չենք տալիս միացնել այն: Այս ռեժիմում ոչ միայն գաղտնագրում չի լինի, այլև գրվածի ստուգման գումարը չի հաշվարկվում, ինչը նշանակում է, որ ամբողջականությունը կարող է ստուգվել միայն անուղղակիորեն՝ օգտագործելով ինդեքսները:

Առանձին ժամանակացույցը ստուգում է ինդեքսների և բովանդակության ամբողջականության կրկնօրինակները: Ստուգումը դանդաղ է և երկար, ուստի մենք այն իրականացնում ենք ամիսը մեկ անգամ առանձին: Դա կարող է տեւել մի քանի օր:

Կարդացեք ռուսերեն

Հիմնական գործառույթները

• 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, ունի պայմանական անուն, նրա հնարքն այն է, որ այն նաև back up է անում mysql տվյալների բազայից։ Սա նշանակում է, որ այն կարող է օգտագործվել մեկ հանգույցով Nexcloud տեղադրումների համար, որտեղ կարող եք նաև կրկնօրինակել տվյալների բազան: Հարմարավետությունը ոչ միայն այն է, որ ամեն ինչ մեկ տեղում է, այլ նաև տվյալների բազայի բովանդակությունը մոտ է ֆայլերի բովանդակությանը, քանի որ ժամանակի տարբերությունը նվազագույն է:

Ռեստիկ ընդդեմ Բորգի

Համեմատություններ կան նաև Բորգի և Ռեստիչի միջև այստեղ՝ Հաբրեում, և մենք խնդիր ունեինք ստեղծելու ևս մեկը, այլ մերը: Մեզ համար կարևոր էր, թե ինչպես այն կանդրադառնա մեր տվյալների վրա՝ մեր առանձնահատկություններով: Մենք բերում ենք դրանք:

Մեր ընտրության չափանիշները, ի լրումն արդեն նշվածների (կրկնօրինակում, արագ վերականգնում և այլն).

• Դիմադրություն անավարտ աշխատանքին. Ստուգեք սպանության համար -9:
• Չափը սկավառակի վրա:
• Պահանջը ռեսուրսների համար (CPU, հիշողություն):
• Պահպանված բշտիկների չափը:
• S3-ի հետ աշխատելը.
• Ամբողջականության ստուգում.

Փորձարկման համար մենք վերցրել ենք մեկ հաճախորդ՝ իրական տվյալներով և ընդհանուր 1,6 ՏԲ չափով:
Պայմանները:

Բորգը չգիտի, թե ինչպես աշխատել ուղղակիորեն S3-ի հետ, և մենք տեղադրեցինք սկավառակը որպես ապահովիչ՝ միջոցով հիմարներ. Restic-ն այն ուղարկել է S3-ին:

Goofys-ն աշխատում է շատ արագ և լավ, և կան սկավառակի քեշի մոդուլ, որն էլ ավելի է արագացնում աշխատանքը։ Այն գտնվում է բետա փուլում, և, անկեղծ ասած, մենք վթարի ենք ենթարկվել թեստերի ժամանակ տվյալների կորստով (մյուսները): Բայց հարմարությունն այն է, որ կրկնօրինակման պրոցեդուրան ինքնին պահանջում է ոչ թե շատ կարդալ, այլ հիմնականում գրել, ուստի մենք օգտագործում ենք քեշը միայն ամբողջականության ստուգումների ժամանակ։

Ցանցի ազդեցությունը նվազեցնելու համար մենք օգտագործել ենք տեղական մատակարար՝ Yandex Cloud:

Համեմատության փորձարկման արդյունքներ.

• Kill -9-ը հետագա վերագործարկմամբ երկուսն էլ հաջող էին:
• Չափը սկավառակի վրա: Բորգը կարող է սեղմել, ուստի արդյունքները սպասվում են:

Պահուստավորող
չափ

Բորգ
562Gb

Հանգիստ
628Gb

• Պրոցեսորի կողմից
  Բորգը ինքնին քիչ է սպառում, լռելյայն սեղմումով, բայց այն պետք է գնահատվի բութ գործընթացի հետ միասին: Ընդհանուր առմամբ, դրանք համեմատելի են և օգտագործում են մոտ 1,2 միջուկ նույն փորձնական վիրտուալ մեքենայի վրա:
• Հիշողություն. Restic-ը մոտավորապես 0,5 ԳԲ է, Բորգը՝ մոտավորապես 200 ՄԲ: Բայց այս ամենը աննշան է համակարգի ֆայլերի քեշի համեմատ: Այսպիսով, խորհուրդ է տրվում ավելի շատ հիշողություն հատկացնել:
• Բշտիկների չափի տարբերությունը ապշեցուցիչ էր։

Պահուստավորող
չափ

Բորգ
մոտ 500 ՄԲ

Հանգիստ
մոտ 5 ՄԲ

• Restic-ի S3-ի փորձը գերազանց է: Բորգի հետ աշխատելը goofys-ի միջոցով որևէ հարց չի առաջացնում, սակայն նշվել է, որ խորհուրդ է տրվում կրկնօրինակումն ավարտելուց հետո կատարել մեծացում՝ քեշը ամբողջությամբ վերականգնելու համար: S3-ի առանձնահատկությունն այն է, որ քիչ պոմպացված կտորները երբեք չեն ուղարկվի դույլ, ինչը նշանակում է, որ ոչ լրիվ լրացված տվյալները հանգեցնում են մեծ վնասների:
• Ամբողջականության ստուգումը երկու դեպքում էլ լավ է աշխատում, սակայն արագությունը զգալիորեն տարբերվում է:
  Ռեստիկ 3,5 ժամ.
  Borg, 100 ԳԲ SSD ֆայլի քեշով – 5 ժամ.Մոտավորապես նույն արագության արդյունքը, եթե տվյալները տեղային սկավառակի վրա են:
  Բորգը կարդում է անմիջապես S3-ից՝ առանց քեշի 33 ժամ. Հրեշավոր երկար.

Ներքևի գիծն այն է, որ Borg-ը կարող է սեղմել և ունի ավելի մեծ բշտիկներ, ինչն ավելի էժան է դարձնում S3-ում պահեստավորման և GET/PUT գործողությունները: Բայց սա գալիս է ավելի բարդ և դանդաղ ստուգման գնով: Ինչ վերաբերում է վերականգնման արագությանը, մենք տարբերություն չենք նկատել։ Restic-ը հետագա կրկնօրինակումները (առաջինից հետո) վերցնում է մի փոքր ավելի երկար, բայց ոչ էապես:

Վերջին, բայց ոչ պակաս կարևոր ընտրության մեջ համայնքի չափն էր:

Եվ մենք ընտրեցինք բորգը:

Մի քանի խոսք սեղմման մասին

Borg-ն իր զինանոցում ունի սեղմման նոր հիանալի ալգորիթմ՝ zstd: Սեղմման որակը ոչ ավելի վատ է, քան gzip-ը, բայց շատ ավելի արագ: Եվ արագությամբ համեմատելի է լռելյայն lz4-ի հետ:

Օրինակ, MySQL տվյալների բազայի աղբանոցը երկու անգամ ավելի լավ է սեղմվում, քան lz4-ը նույն արագությամբ: Այնուամենայնիվ, իրական տվյալների հետ կապված փորձը ցույց է տալիս, որ շատ քիչ տարբերություն կա Nextcloud հանգույցի սեղմման հարաբերակցության մեջ:

Borg-ն ունի բավականին բոնուսային սեղմման ռեժիմ. եթե ֆայլը ունի բարձր էնտրոպիա, ապա սեղմումն ընդհանրապես չի կիրառվում, ինչը մեծացնում է արագությունը։ Միացված է ընտրանքով՝ ստեղծելիս
-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-ում, և ոչ բոլորն ունեն հակավիրուս: Թափելու պահին ստուգումներ անցկացնելը չափազանց շատ ժամանակ է պահանջում և խանգարում է բիզնեսին:

Scalability-ը ձեռք է բերվում տարբեր պիտակներով տարբեր հանգույցների վրա վազորդներ գործարկելու միջոցով:
Մեր մոնիտորինգը հավաքում է կրկնօրինակի կարգավիճակները GitLab API-ի միջոցով մեկ պատուհանում, անհրաժեշտության դեպքում խնդիրները հեշտությամբ նկատվում են և նույնքան հեշտությամբ տեղայնացվում:

Ամփոփում

Արդյունքում մենք հաստատ գիտենք, որ մենք կրկնօրինակում ենք, որ մեր կրկնօրինակները վավեր են, դրանց հետ կապված խնդիրները քիչ ժամանակ են պահանջում և լուծվում են հերթապահ ադմինիստրատորի մակարդակով։ Պահուստավորումներն իսկապես քիչ տեղ են զբաղեցնում՝ համեմատած tar.gz-ի կամ Bacula-ի հետ:

Source: www.habr.com