Ka kemi shumë sisteme kopjimi, por çfarë bëni nëse serverët që menaxhohen janë të shpërndarë në rajone të ndryshme dhe klientë dhe duhet të përdoren mjetet e sistemit operativ?
Përshëndetje, Habr!
Më quajnë Natalja. Unë jam lideri i grupit të administratorëve të aplikacioneve në NPO "Krista". Ne jemi ops për grupin e projekteve të kompanisë sonë. Kemi një situatë mjaft të veçantë: ne instalojmë dhe mbajmë softuerin tonë si në serverët e kompanisë sonë, ashtu edhe në ato që ndodhen tek klientët. Në këtë rast, nuk është e nevojshme të kopjohet serveri në tërësi. Atyre u interesojnë vetëm "të dhënat thelbësore": DB dhe kataloge të veçanta të sistemit të skedarëve. Natyrisht, klientët kanë (ose nuk kanë) rregullat e tyre për kopjimin dhe shpesh ofrojnë ndonjë ruajtje të jashtme për ruajtjen e kopjeve rezervë. Në këtë rast, pas krijimit të kopjes rezervë, ne sigurojmë dërgimin në ruajtjen e jashtme.
Një kohë të gjatë për qëllimet e kopjimit ne u mjaftuam me një skenar bash, por me rritjen e opsioneve të konfigurimit, e njëjta ka ndodhur me kompleksitetin e këtij skripti dhe në një moment të bukur arritëm në nevojën për ta "shembur atë deri në themel dhe pastaj....".
Zgjidhjet e gatshme nuk ishin të përshtatshme për arsye të ndryshme: për shkak të nevojës për decentralizimin e kopjeve, detyrimit për të ruajtur kopjet lokalë tek klienti, vështirësive në konfigurim, zëvendësimit të importeve dhe kufizimeve të aksesit.
Na duket se është më e thjeshtë të shkruajmë diçka tonën. Në të njëjtën kohë do të donim të ishim me diçka të tillë që do të mjaftonte për situatën tonë për N vitet e ardhshme, por me një mundësi të potenciale për zgjerimin e fushës së aplikimit.
Kushtet e problemit ishin si në vazhdim:
- instanca bazë e kopjimit është autonome, punon lokalshëm
- ruajtja e kopjeve rezervë dhe logëve gjithmonë brenda rrjetit të klientit
- instanca përbëhet nga module - një lloj "ndërtuesi"
- nevojitet përputhshmëri me distribucionat përkatëse të Linux, duke përfshirë ato të vjetra, dhe është e dëshirueshme potencialisht që të jetë ndër-platformës
- për të punuar me instancën mjafton aksesimi përmes ssh, nuk është e nevojshme hapja e porteve të tjera
- maksimalisht thjeshtësi në konfigurim dhe përdorim
- mundësia (por jo e detyrueshme) për të pasur një instancë të veçantë, që lejon të shikohet në mënyrë qendrore gjendja e kopjeve rezervë nga serverë të ndryshëm
Atë që arritëm ta realizojmë, mund ta shihni këtu:
Programi është shkruar në python3; funksionon në Debian, Ubuntu, CentOS, AstraLinux 1.6.
Dokumentacioni është publikuar në katalogun docs të depoes.
Koncepte kryesore me të cilat operon sistemi:
veprim â njĂ« veprim, qĂ« realizon njĂ« operacion atomik (backup i DB, backup i njĂ« katalogu, transfer nga katalogu A nĂ« katalogun B etj.). Veprimet ekzistuese ndodhen nĂ« katalogun core/actions
detyrĂ« â njĂ« pĂ«rcaktim, njĂ« grup veprimesh, qĂ« pĂ«rshkruan njĂ« "detyrĂ« backup" logjike
orari â njĂ« program, njĂ« grup detyrash me njĂ« caktim opsional tĂ« kohĂ«s sĂ« realizimit tĂ« detyrĂ«s
Konfigurimi i backup-it ruhet në një skedë yaml; struktura e përgjithshme e konfigurimit:
- caktimet e përbashkëta
- seksioni veprime: përshkrimi i veprimeve, që përdoren në këtë server
- seksioni orari: përshkrimi i të gjitha detyrave (grupet e veprimeve) dhe orari i fillimit të tyre përmes cron, nëse ky fillim kërkohet
ĂfarĂ« mund tĂ« bĂ«jĂ« aplikacioni aktualisht:
- kanë mbështetje për operacionet kryesore: backup i PostgreSQL përmes pg_dump, backup i katalogut të sistemit të skedarëve përmes tar; operacione me ruajtjen e jashtme; rsync midis katalogëve; rotacioni i backup-eve (fshirja e kopjeve të vjetra)
- thirrja e një skripti të jashtëm
- ekzekutimi manual i një detyre të veçantë
/opt/KristaBackup/KristaBackup.py run make_full_dump - mund të shtoni (apo hiqni) një detyrë të veçantë ose tërë orarin në crontab
/opt/KristaBackup/KristaBackup.py enable all - generaimi i një skedari trigger sipas rezultateve të backup-it. Kjo funksion është e dobishme në lidhje me Zabbix për monitorimin e backup-eve
- mund të punojë në sfond në modalitetin webapi ose web
/opt/KristaBackup/KristaBackup.py web start [--api]
Dallimi midis modaliteteve: në webapi nuk ka një ndërfaqe web, por aplikacioni përgjigjet në kërkesat e një instance tjetër. Për modalitetin web, nevojitet instalimi i flask dhe disa paketa të tjera, dhe kjo nuk është e pranueshme kudo, për shembull në AstraLinux SE të certifikuar.
PĂ«rmes ndĂ«rfaqes web mund tĂ« shikoni gjendjen dhe regjistrat e backup-eve tĂ« serverĂ«ve tĂ« lidhur: "instance web" kĂ«rkon tĂ« dhĂ«na nga "instance backup" pĂ«rmes API. Q accĂšs nĂ« web kĂ«rkon autentikim, q accĂšs nĂ« webapi â jo.
Regjistrat e backup-eve qĂ« nuk kalojnĂ« siç duhet tregon me ngjyrĂ«: warning â e verdhĂ«, error â e kuqe.
Nëse administratorit nuk i nevojitet një shënim mbi parametrat dhe sistemet operuese të serverëve janë homogjene, mund të kompiloni skedarin dhe të shpërndani një paketë të gatshme.
Ne shpërndajmë këtë utilitar kryesisht përmes Ansible, duke e vendosur fillimisht në një pjesë të serverëve më pak të rëndësishëm, dhe pas testimit në të tjerët.
Si nĂ« fund morĂ«m njĂ« utilitar kompakt, autonom pĂ«r kopjimin, tĂ« cilin mund ta automatizojmĂ« dhe qĂ« Ă«shtĂ« i pĂ«rshtatshĂ«m pĂ«r t'u pĂ«rdorur edhe nga administratorĂ« pak mĂ« me pĂ«rvojĂ«. Ne e gjejmĂ« tĂ« dobishĂ«m â ndoshta do t'ju shĂ«rbej edhe juve?
Burimi: habr.com
