Сістэм рэзервовага капіявання мноства, але што рабіць, калі абслугоўваныя серверы раскіданыя па розных рэгіёнах і кліентам і трэба абыходзіцца сродкамі аперацыйнай сістэмы?
Добры дзень, Habr!
Мяне клічуць Наталля. Я тымлід групы адміністратараў прыкладанняў у НВА "Крыста". Мы Ops для групы праектаў нашай кампаніі. У нас даволі своеасаблівая сітуацыя: мы ўсталёўваем і суправаджаем нашае ПЗ як на серверах нашай кампаніі, так і на серверах, размешчаных у кліентаў. Пры гэтым бэкапіць сервер цалкам няма неабходнасці. Важныя толькі "істотныя дадзеныя": СКБД і асобныя каталогі файлавай сістэмы. Вядома, кліенты маюць (ці не маюць) свае рэгламенты рэзервовага капіявання і часта падаюць нейкае вонкавае сховішча для складання туды рэзервовых дзід. У гэтым выпадку пасля стварэння бэкапу мы забяспечваем адпраўку ў вонкавае сховішча.
Нейкі час для мэт бэкапу мы абыходзіліся bash-скрыптам, але па меры разрастання варыянтаў налад прапарцыйна расла і заблытанасць гэтага скрыпту, і аднойчы мы прыйшлі да неабходнасці яго «разбурыць да падставы, а затым….».
Гатовыя рашэнні не падышлі па розных прычынах: з-за неабходнасці дэцэнтралізацыі бэкапаў, абавязковасці захоўвання бэкапаў лакальна ў кліента, складанасці наладкі, імпартазамяшчэння, абмежавання доступу.
Нам падалося, што прасцей напісаць нешта сваё. Пры гэтым жадалася атрымаць нешта такое, чаго хопіць для нашай сітуацыі на наступныя N гадоў, але з магчымасцю патэнцыйнага пашырэння вобласці ўжывання.
Умовы задачы былі наступныя:
- базавы інстанс бэкапу аўтаномны, працуе лакальна
- захоўванне рэзервовых копій і логаў заўсёды ў межах сеткі кліента
- інстанс складаецца з модуляў – такі своеасаблівы "канструктар"
- неабходна сумяшчальнасць з выкарыстоўванымі дыстрыбутывамі Linux, уключаючы састарэлыя, пажаданая патэнцыйная кросплатформеннасць
- для працы з інстансам дастаткова доступу па ssh, адкрыццё дадатковых партоў неабавязкова
- максімальная прастата наладкі і эксплуатацыі
- магчыма (але не абавязкова) існаванне асобнага інстансу, які дазваляе цэнтралізавана прагледзець стан бэкапаў з розных сервераў
Тое, што ў нас атрымалася, можна паглядзець тут:
ПЗ напісана на python3; працуе на Debian, Ubuntu, CentOS, AstraLinux 1.6.
Дакументацыя выкладзена ў каталогу docs рэпазітара.
Асноўныя паняцці, якімі аперуе сістэма:
action – дзеянне, якое рэалізуе адну атамарную аперацыю (бэкап БД, бэкап каталога, перанос з каталога А ў каталог Б і т. д.). Існуючыя actions ляжаць у каталогу core/actions
task - заданне, набор actions, які апісвае адну лагічную «задачу бэкапу»
schedule - расклад, набор task з апцыянальным указаннем часу выканання задачы
Канфігурацыя бэкапу захоўваецца ў yaml-файле; агульная структура канфіга:
- агульныя налады
- раздзел actions: апісанне дзеянняў, якія выкарыстоўваюцца на гэтым серверы
- раздзел schedule: апісанне ўсіх заданняў (набораў дзеянняў) і расклад іх запуску па кроне, калі такі запуск патрабуецца
Што ўмее дадатак на бягучы момант:
- падтрымліваюцца асноўныя для нас аперацыі: бэкап PostgreSQL праз pg_dump, бэкап каталога файлавай сістэмы праз tar; аперацыі са знешнім сховішчам; rsync паміж каталогамі; ратацыя бэкапаў (выдаленне старых копій)
- выклік знешняга скрыпту
- выкананне ўручную асобнага задання
/opt/KristaBackup/KristaBackup.py run make_full_dump - можна дадаць (або прыбраць) у кронтабе асобнае заданне або ўвесь расклад
/opt/KristaBackup/KristaBackup.py enable all - генерацыя трыгер-файла па выніках бэкапу. Гэтая функцыя карысная ў звязку з Zabbix для маніторынгу бэкапаў
- можа працаваць у фоне ў рэжыме webapi ці web
/opt/KristaBackup/KristaBackup.py web start [--api]
Розніца паміж рэжымамі: у webapi няма ўласна вэб-інтэрфейсу, але прыкладанне адказвае на запыты іншага інстансу. Для рэжыму web трэба ўсталяваць flask і некалькі дадатковых пакетаў, а гэта не ўсюды прымальна, напрыклад у сертыфікаванай AstraLinux SE.
Праз вэб-інтэрфейс можна паглядзець стан і логі бэкапаў падлучаных сервераў: "вэб-інстанс" запытвае дадзеныя з "бэкап-інстансаў" праз API. Доступ да web патрабуе аўтарызацыі, доступ да webapi - не.
Логі некарэктна якія прайшлі бэкапаў пазначаюцца колерам: warning - жоўтым, error - чырвоным.
Калі адміністратару не патрэбна шпаргалка па параметрах і серверныя АС аднастайныя, можна скампіляваць файл і распаўсюджваць ужо гатовы пакет.
Распаўсюджваем мы гэтую ўтыліту ў асноўным праз Ansible, выкочваючы спачатку на частку найменш важных сервераў, а пасля тэставання на ўсе астатнія.
У выніку мы атрымалі кампактную аўтаномную ўтыліту капіявання, якая паддаецца аўтаматызацыі і прыдатную для эксплуатацыі нават маладасведчанымі адміністратарамі. Нам зручна - можа, спатрэбіцца і вам?
Крыніца: habr.com