Ka shumë sisteme rezervë, por çfarë të bëni nëse serverët e shërbyer janë të shpërndarë nëpër rajone dhe klientë të ndryshëm dhe ju duhet të mjaftoheni me sistemin operativ?
Mirë pasdite, Shkoz!
Emri im është Natalya. Unë jam drejtuesi i ekipit të grupit të administratorëve të aplikacioneve në NPO Krista. Ne jemi Ops për grupin e projektit të kompanisë sonë. Ne kemi një situatë mjaft unike: ne instalojmë dhe mirëmbajmë softuerin tonë si në serverët e kompanisë sonë ashtu edhe në serverët e vendosur në faqet e klientëve. Në këtë rast, nuk ka nevojë të kopjoni të gjithë serverin. Vetëm "të dhënat thelbësore" janë të rëndësishme: DBMS dhe drejtoritë individuale të sistemit të skedarëve. Sigurisht, klientët kanë (ose nuk kanë) rregulloret e tyre rezervë dhe shpesh ofrojnë një lloj ruajtjeje të jashtme për ruajtjen e kopjeve rezervë atje. Në këtë rast, pas krijimit të një kopje rezervë, ne sigurojmë dërgimin në ruajtje të jashtme.
Për disa kohë, për qëllime rezervë, ne u mjaftuam me një skenar bash, por ndërsa opsionet e konfigurimit u rritën, kompleksiteti i këtij skripti u rrit proporcionalisht dhe në një moment erdhëm në nevojën për ta "shkatërruar atë në tokë, dhe më pas ...”.
Zgjidhjet e gatshme nuk ishin të përshtatshme për arsye të ndryshme: për shkak të nevojës për të decentralizuar kopjet rezervë, kërkesën për të ruajtur kopjet rezervë në nivel lokal te klienti, kompleksitetin e konfigurimit, zëvendësimin e importit, kufizimet e aksesit.
Na dukej se ishte më e lehtë të shkruanim diçka tonën. Në të njëjtën kohë, doja të merrja diçka që do të mjaftonte për situatën tonë për N vitet e ardhshme, por me mundësinë e zgjerimit potencial të fushës.
Kushtet e detyrës ishin si më poshtë:
- instanca bazë rezervë është autonome dhe funksionon në nivel lokal
- ruajtja e kopjeve rezervë dhe regjistrave është gjithmonë brenda rrjetit të klientit
- një shembull përbëhet nga module - një lloj "konstruktori"
- kërkohet përputhshmëria me shpërndarjet aktuale të Linux, duke përfshirë ato të vjetruara, është e dëshirueshme ndër-platforma e mundshme
- Për të punuar me shembullin, qasja përmes ssh është e mjaftueshme; hapja e porteve shtesë nuk është e nevojshme
- lehtësia maksimale e konfigurimit dhe funksionimit
- është e mundur (por jo e nevojshme) të keni një shembull të veçantë që ju lejon të shikoni në mënyrë qendrore statusin e kopjeve rezervë nga serverë të ndryshëm
Ju mund të shihni se çfarë kemi arritur këtu:
Softueri është i shkruar në python3; punon në Debian, Ubuntu, CentOS, AstraLinux 1.6.
Dokumentacioni është postuar në dosjen e dokumenteve të depove.
Konceptet bazë që funksionon sistemi:
veprim - një veprim që zbaton një operacion atomik (kopje rezervë e bazës së të dhënave, kopjimi i drejtorisë, transferimi nga drejtoria A në drejtorinë B, etj.). Veprimet ekzistuese ndodhen në direktorinë bërthamë/veprime
detyrë - detyrë, një grup veprimesh që përshkruajnë një "detyrë rezervë" logjike
orar – orar, një grup detyrash me një tregues opsional të kohës së ekzekutimit të detyrës
Konfigurimi rezervë ruhet në një skedar yaml; Struktura e përgjithshme e konfigurimit:
- Cilësimet e përgjithshme
- seksioni i veprimeve: përshkrimi i veprimeve të përdorura në këtë server
- seksioni i orarit: përshkrimi i të gjitha detyrave (grupe veprimesh) dhe plani për nisjen e tyre nga cron, nëse kërkohet një nisje e tillë
Çfarë mund të bëjë aplikacioni aktualisht:
- Operacionet kryesore për ne mbështeten: Rezervimi i PostgreSQL përmes pg_dump, kopjimi i dosjeve të sistemit të skedarëve përmes tar; operacionet me ruajtje të jashtme; rsync ndërmjet drejtorive; rrotullimi rezervë (fshirja e kopjeve të vjetra)
- duke thirrur një skenar të jashtëm
- ekzekutimi manual i një detyre të veçantë
/opt/KristaBackup/KristaBackup.py run make_full_dump - ju mund të shtoni (ose hiqni) një detyrë të vetme ose të gjithë orarin në crontab
/opt/KristaBackup/KristaBackup.py enable all - gjenerimi i një skedari nxitës bazuar në rezultatet rezervë. Ky funksion është i dobishëm në lidhje me Zabbix për monitorimin e kopjeve rezervë
- mund të funksionojë në sfond në modalitetin webapi ose ueb
/opt/KristaBackup/KristaBackup.py web start [--api]
Dallimi midis mënyrave: webapi nuk ka vetë një ndërfaqe në internet, por aplikacioni u përgjigjet kërkesave nga një shembull tjetër. Për modalitetin në internet, ju duhet të instaloni flask dhe disa paketa shtesë, dhe kjo nuk është e pranueshme kudo, për shembull në AstraLinux SE të certifikuar.
Nëpërmjet ndërfaqes së uebit, mund të shikoni statusin dhe regjistrat e kopjeve rezervë të serverëve të lidhur: "instance ueb" kërkon të dhëna nga "instancat rezervë" nëpërmjet API-së. Qasja në ueb kërkon autorizim, qasja në webapi jo.
Regjistrat e kopjeve rezervë të pasaktë janë shënuar me ngjyra: paralajmërim - i verdhë, gabim - i kuq.
Nëse administratori nuk ka nevojë për një fletë mashtrimi për parametrat dhe sistemet operative të serverit janë homogjenë, mund të përpiloni skedarin dhe të shpërndani paketën e gatshme.
Ne e shpërndajmë këtë mjet kryesisht përmes Ansible, duke e shpërndarë atë fillimisht në disa nga serverët më pak të rëndësishëm dhe pas testimit në të gjithë të tjerët.
Si rezultat, ne morëm një mjet kopjimi kompakt, të pavarur që mund të automatizohet dhe mund të përdoret edhe nga administratorë të papërvojë. Është i përshtatshëm për ne - ndoshta do të jetë i dobishëm edhe për ju?
Burimi: www.habr.com