Կան բազմաթիվ պահեստային համակարգեր, բայց ի՞նչ անել, եթե սպասարկվող սերվերները ցրված են տարբեր տարածաշրջաններում և հաճախորդներում, և դուք պետք է բավարարվեք օպերացիոն համակարգով:
Բարեւ, Կլինի!
Ես Նատալյա եմ: Ես NPO Krista-ում հավելվածների ադմինիստրատորների խմբի թիմի ղեկավարն եմ: Մենք Ops ենք մեր ընկերության նախագծային խմբի համար: Մենք ունենք բավականին եզակի իրավիճակ. մենք տեղադրում և պահպանում ենք մեր ծրագրակազմը ինչպես մեր ընկերության սերվերների, այնպես էլ հաճախորդների կայքերում տեղակայված սերվերների վրա: Այս դեպքում ամբողջ սերվերի կրկնօրինակման կարիք չկա: Կարևոր են միայն «հիմնական տվյալները»՝ DBMS-ը և ֆայլային համակարգի առանձին գրացուցակները: Իհարկե, հաճախորդներն ունեն (կամ չունեն) իրենց պահուստային կանոնակարգերը և հաճախ տրամադրում են ինչ-որ արտաքին պահեստ՝ այնտեղ պահուստավորում պահելու համար: Այս դեպքում, կրկնօրինակ ստեղծելուց հետո, մենք ապահովում ենք ուղարկումը արտաքին պահեստ:
Որոշ ժամանակ պահուստային նպատակների համար մենք բավարարվեցինք bash script-ով, բայց քանի որ կազմաձևման ընտրանքները մեծացան, այս սցենարի բարդությունը համաչափ աճեց, և մի պահ մենք եկանք «քանդելու այն գետնին, իսկ հետո». ...»:
Պատրաստի լուծումները հարմար չէին տարբեր պատճառներով՝ կրկնօրինակների ապակենտրոնացման անհրաժեշտության, հաճախորդի մոտ պահեստային պատճենները տեղում պահելու պահանջի, տեղադրման բարդության, ներմուծման փոխարինման, մուտքի սահմանափակումների պատճառով:
Մեզ թվում էր, թե ավելի հեշտ է գրել մեր սեփականը։ Միևնույն ժամանակ, ես ուզում էի ստանալ մի բան, որը կբավականացներ մեր իրավիճակին հաջորդ N տարիների համար, բայց պոտենցիալ շրջանակը ընդլայնելու հնարավորությամբ։
Առաջադրանքի պայմանները հետևյալն էին.
- հիմնական պահեստային օրինակն ինքնավար է և աշխատում է տեղական մակարդակում
- կրկնօրինակների և տեղեկամատյանների պահպանումը միշտ գտնվում է հաճախորդի ցանցում
- օրինակը բաղկացած է մոդուլներից՝ մի տեսակ «կոնստրուկտոր»
- Պահանջվում է համատեղելիություն Linux-ի ընթացիկ բաշխումների հետ, ներառյալ հնացածները, ցանկալի է պոտենցիալ միջպլատֆորմը
- Օրինակի հետ աշխատելու համար ssh-ի միջոցով մուտքը բավարար է, լրացուցիչ պորտեր բացելը անհրաժեշտ չէ
- տեղադրման և շահագործման առավելագույն հեշտությունը
- հնարավոր է (բայց ոչ անհրաժեշտ) ունենալ առանձին օրինակ, որը թույլ է տալիս կենտրոնացված կերպով դիտել տարբեր սերվերների կրկնօրինակների կարգավիճակը
Դուք կարող եք տեսնել, թե ինչի հետ ենք եկել այստեղ.
Ծրագիրը գրված է python3-ով; աշխատում է Debian, Ubuntu, CentOS, AstraLinux 1.6-ի վրա:
Փաստաթղթերը տեղադրվում են պահոցի փաստաթղթերի գրացուցակում:
Հիմնական հասկացությունները, որով գործում է համակարգը.
գործողություն – գործողություն, որն իրականացնում է մեկ ատոմային գործողություն (տվյալների բազայի կրկնօրինակում, գրացուցակի կրկնօրինակում, փոխանցում A գրացուցակից B գրացուցակ և այլն): Առկա գործողությունները գտնվում են հիմնական/գործողությունների գրացուցակում
առաջադրանք – առաջադրանք, գործողությունների մի շարք, որոնք նկարագրում են մեկ տրամաբանական «պահուստային առաջադրանք»
ժամանակացույց – ժամանակացույց, առաջադրանքների մի շարք՝ առաջադրանքի կատարման ժամանակի կամընտիր ցուցումով
Պահուստային կոնֆիգուրացիան պահվում է yaml ֆայլում; ընդհանուր կազմաձևման կառուցվածքը.
- Ընդհանուր կարգավորումներ
- գործողությունների բաժին. այս սերվերում օգտագործվող գործողությունների նկարագրությունը
- ժամանակացույցի բաժին. բոլոր առաջադրանքների նկարագրությունը (գործողությունների հավաքածու) և դրանց գործարկման ժամանակացույցը ըստ cron-ի, եթե այդպիսի գործարկում է պահանջվում
Ինչ կարող է անել հավելվածը ներկայումս.
- Մեզ համար հիմնական գործողությունները աջակցվում են. PostgreSQL կրկնօրինակում pg_dump-ի միջոցով, ֆայլային համակարգի գրացուցակի կրկնօրինակում tar-ի միջոցով; գործողություններ արտաքին պահեստով; rsync դիրեկտորիաների միջև; կրկնօրինակի ռոտացիա (հին պատճենների ջնջում)
- կանչելով արտաքին սցենար
- առանձին առաջադրանքի ձեռքով կատարում
/opt/KristaBackup/KristaBackup.py run make_full_dump - դուք կարող եք ավելացնել (կամ հեռացնել) մեկ առաջադրանք կամ ամբողջ ժամանակացույցը crontab-ում
/opt/KristaBackup/KristaBackup.py enable all - կրկնօրինակման արդյունքների հիման վրա գործարկիչ ֆայլի ստեղծում: Այս ֆունկցիան օգտակար է Zabbix-ի հետ համատեղ՝ կրկնօրինակումները վերահսկելու համար
- կարող է աշխատել ֆոնային ռեժիմում՝ webapi կամ վեբ ռեժիմում
/opt/KristaBackup/KristaBackup.py web start [--api]
Ռեժիմների միջև տարբերությունը. webapi-ն ինքնին չունի վեբ ինտերֆեյս, սակայն հավելվածը պատասխանում է մեկ այլ օրինակի հարցումներին: Վեբ ռեժիմի համար դուք պետք է տեղադրեք տափաշիշ և մի քանի լրացուցիչ փաթեթներ, և դա ընդունելի չէ ամենուր, օրինակ՝ հավաստագրված AstraLinux SE-ում:
Վեբ ինտերֆեյսի միջոցով դուք կարող եք դիտել միացված սերվերների կրկնօրինակների կարգավիճակը և տեղեկամատյանները. «վեբ օրինակը» API-ի միջոցով պահանջում է տվյալներ «պահուստային օրինակներից»: Համացանց մուտք գործելու համար անհրաժեշտ է թույլտվություն, իսկ webapi-ին՝ ոչ:
Սխալ կրկնօրինակների մատյանները նշված են գույներով՝ նախազգուշացում՝ դեղին, սխալ՝ կարմիր:
Եթե ադմինիստրատորը պարամետրերի վերաբերյալ խաբեության թերթիկի կարիք չունի, և սերվերի օպերացիոն համակարգերը միատարր են, կարող եք կազմել ֆայլը և տարածել պատրաստի փաթեթը:
Մենք տարածում ենք այս օգտակար ծրագիրը հիմնականում Ansible-ի միջոցով՝ այն սկզբում տարածելով ամենաքիչ կարևոր սերվերների վրա, իսկ փորձարկումից հետո մնացած բոլոր սերվերների վրա:
Արդյունքում մենք ստացանք կոմպակտ, ինքնուրույն պատճենահանման ծրագիր, որը կարող է ավտոմատացվել և կարող է օգտագործվել նույնիսկ անփորձ ադմինիստրատորների կողմից: Մեզ համար հարմար է, միգուցե դա ձեզ և՞ս օգտակար լինի:
Source: www.habr.com