Ka shumë sisteme backup, por çfarë të bëni nëse serverat që menaxhohen janë të shpërndara në zona të ndryshme dhe tek klientët dhe duhet të përdorni burimet e sistemit operativ?
Përshëndetje, Habr!
Më quajnë Natalia. Jam liderja e 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ë: instalojmë dhe mbështesim softuerin tonë si në serverat e kompanisë sonë, ashtu edhe në serverat e vendosur te klientët. Në këtë rast, nuk është e nevojshme të bëhet backup i serverit të tërë. Ajo që është e rëndësishme janë vetëm "të dhënat thelbësore": DB dhe direktorët e veçantë të sistemit të files. Sigurisht, klientët kanë (ose nuk kanë) rregullat e tyre për backup dhe shpesh ofrojnë ndonjë magazinë të jashtme për të depozituar atje backup-et. Në këtë rast, pas krijimit të backup-it, ne sigurojmë dërgimin në magazinë të jashtme.
Një kohë për qëllime backup-i, ne përdorëm një skript bash, por me rritjen e opsioneve të konfigurimeve, kompleksiteti i këtij skripti gjithashtu u rrit, dhe në një moment të bukur arritëm në nevojën për ta "shkatërruar për të ndërtuar përsëri, 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 backups, detyrimin për të mbajtur backups lokalisht te klienti, kompleksitetin e konfigurimit, importin e zëvendësimit, kufizimin e aksesit.
Na dukej më e lehtë të shkruajmë diçka tonën. Në të njëjtën kohë dëshironim të merrnim diçka që do të ishte e mjaftueshme për situatën tonë për vitet N në vijim, por me mundësi potenciale për zgjerimin e aplikacionit.
Kushtet e detyrës ishin si më poshtë:
- instance bazike e backup-it është autonome, funksionon lokalisht
- ruajtja e kopjeve rezervë dhe logëve gjithmonë brenda rrjetit të klientit
- instance pĂ«rbĂ«het nga modula â njĂ« lloj "ndĂ«rtuesi"
- nevojitet përputhshmëri me distribucionet e përdorura të Linux, duke përfshirë ato të vjetra, preferohet potencialiteti i ndërlikueshmërisë
- për të punuar me instancën, është e mjaftueshme të kesh akses përmes ssh, hapja e porteve të tjera nuk është e nevojshme
- maksimalisht thjeshtësi në konfigurim dhe përdorim
- mund të ekzistojë (por nuk është e nevojshme) një instancë e veçantë që lejon që të shikohet centralisht gjendja e kopjeve rezervë nga serverë të ndryshëm
Ajo që kemi arritur mund të shihet këtu:
Softueri është shkruar në python3; punon në Debian, Ubuntu, CentOS, AstraLinux 1.6.
Dokumentacioni është publikuar në katalogun docs të depozitës.
Koncepat kryesore me të cilat operon sistemi:
action â veprimi qĂ« realizon njĂ« operacion tĂ« vetĂ«m (kopje rezervĂ« DB, kopje rezervĂ« tĂ« katalogut, transferimi nga katalogu A nĂ« katalogun B, etj.). Veprimet ekzistuese ndodhen nĂ« katalogun core/actions
task â detyra, njĂ« grup actions qĂ« pĂ«rshkruan njĂ« "detyrĂ« logjike tĂ« kopjes rezervĂ«"
schedule â orari, njĂ« grup task me mundĂ«sinĂ« e caktimit tĂ« kohĂ«s pĂ«r kryerjen e detyrĂ«s
Konfigurimi i kopjeve rezervë ruhet në një skedar yaml; struktura e përgjithshme e konfigurimit:
- caktimet e përgjithshme
- pjesa actions: përshkrimi i veprimeve përdorura në këtë server
- pjesa schedule: përshkrimi i të gjitha detyrave (grupeve të veprimeve) dhe orari i nisjes së tyre sipas kronit, nëse një fillim i tillë kërkohet
ĂfarĂ« mund tĂ« bĂ«jĂ« aplikacioni pĂ«r momentin:
- mbështeten operacionet kryesore për ne: backup PostgreSQL përmes pg_dump, backup i katalogut të sistemit të skedarëve përmes tar; operacione me magazinën e jashtme; rsync midis katalogëve; rotacioni i bakupeve (fshirja e kopjeve të vjetra)
- thirrja e skenarit të jashtëm
- ekzekutimi manual i një detyre të veçantë
/opt/KristaBackup/KristaBackup.py run make_full_dump - mund të shtoni (ose të hiqni) një detyrë të veçantë ose të gjithë orarin në crontab
/opt/KristaBackup/KristaBackup.py enable all - generaimi i një skedari trigger në përputhje me rezultatet e backup-it. Kjo funksion është e dobishme në lidhje me Zabbix për monitorimin e bakupeve
- mund të punojë në sfond në modalitetin webapi ose web
/opt/KristaBackup/KristaBackup.py web start [--api]
Dallimi mes modaliteteve: në webapi nuk ka vetë ndërfaqe webi, por aplikacioni përgjigjet në kërkesat e një instancë tjetër. Për modalitetin web duhet të shkarkoni flask dhe disa paketa shtesë, dhe kjo nuk është gjithmonë e pranueshme, për shembull në AstraLinux SE të certifikuar.
PĂ«rmes ndĂ«rfaqes web mund tĂ« shikohet gjendja dhe logĂ«t e bakupeve tĂ« serverĂ«ve tĂ« lidhur: 'instanca web' kĂ«rkon tĂ« dhĂ«na nga 'instancat e backup-it' pĂ«rmes API. Qasja nĂ« web kĂ«rkon autentikim, qasja nĂ« webapi â jo.
LogĂ«t e backup-eve tĂ« papĂ«rshtatshme shĂ«nohen me ngjyrĂ«: warning â e verdhĂ«, error â e kuqe.
Nëse administratori nuk i nevojitet një shpjegues për parametrat dhe sistemet operative të serverëve janë homogjene, mund të kompilohet një skedar dhe të shpërndahet një paketë e gatshme.
Kjo utilitare e shpërndajmë kryesisht përmes Ansible, duke e nxjerrë fillimisht në një pjesë të serverëve më pak të rëndësishëm, dhe pas testimit në të gjithë të tjerët.
Si rezultat, morëm një utilitare kompakte dhe autonome për kopjim, që mund të automatizohet dhe është e përshtatshme për përdorim edhe nga administratortë e pak përvojë. Na pëlqen, ndoshta do t'ju nevojitet dhe juve?
Burimi: habr.com
