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
