Многія знаёмыя з СКБД PostgreSQL, і яна выдатна зарэкамендавала сябе на невялікіх усталёўках. Аднак тэндэнцыя да пераходу на Open Source стала ўсё больш відавочнай, нават калі гаворка ідзе аб буйных кампаніях і enterprise патрабаваннях. У гэтым артыкуле мы распавядзем, як убудаваць Postgres у карпаратыўнае асяроддзе, і падзелімся досведам стварэння сістэмы рэзервовага капіявання (СРК) для гэтай базы дадзеных на прыкладзе сістэмы рэзервовага капіявання Commvault.
PostgreSQL ужо даказала сваю заможнасць – СКБД выдатна працуе, яе выкарыстоўваюць модныя лічбавыя бізнэсы тыпу Alibaba і TripAdvisor, а адсутнасць ліцэнзійных плацяжоў робіць яе панадлівай альтэрнатывай такіх монстраў, як MS SQL або Oracle DB. Але як толькі мы пачынаем разважаць пра PostgreSQL у ландшафце Enterprise, адразу ўпіраемся ў цвёрдыя патрабаванні: «А як жа адмоваўстойлівасць канфігурацыі? катастрофаўстойлівасць? дзе ўсебаковы маніторынг? а аўтаматызаванае рэзервовае капіраванне? а выкарыстанне істужачных бібліятэк як напрамую, так і другаснага сховішча?»
З аднаго боку, у PostgreSQL няма убудаваных сродкаў рэзервовага капіявання, як у "дарослых" СКБД тыпу RMAN у Oracle DB або SAP Database Backup. З іншага – пастаўшчыкі карпаратыўных сістэм рэзервовага капіявання (Veeam, Veritas, Commvault) хоць і падтрымліваюць PostgreSQL, але па факце працуюць толькі з пэўнай (звычайна standalone) канфігурацыяй і з наборам розных абмежаванняў.
Такія спецыяльна распрацаваныя для PostgreSQL сістэмы рэзервовага капіявання, як Barman, Wal-g, pg_probackup, вельмі папулярныя ў невялікіх усталёўках СКБД PostgreSQL ці там, дзе не патрэбныя цяжкія бэкапы іншых элементаў ІТ-ландшафту. Напрыклад, апроч PostgreSQL, у інфраструктуры могуць быць фізічныя і віртуальныя серверы, OpenShift, Oracle, MariaDB, Cassandra і г.д. Усё гэта пажадана бэкапіць агульным інструментам. Ставіць асобнае рашэнне выключна для PostgreSQL - няўдалая задума: дадзеныя будуць капіявацца кудысьці на дыск, а потым іх трэба прыбіраць на стужку. Такое задваенне рэзервовага капіявання павялічвае час бэкапу, а таксама, што больш крытычна, - аднаўлення.
У enterprise вырашэнні рэзервовае капіраванне інсталяцыі адбываецца з некаторым лікам нод выдзеленага кластара. Пры гэтым, напрыклад, Commvault умее працаваць толькі з двухнодавым кластарам, у якім Primary і Secondary цвёрда замацаваныя за вызначанымі нодамі. Ды і сэнс бэкапіцца ёсць толькі з Primary, таму што рэзервовае капіраванне з Secondary мае свае абмежаванні. З-за асаблівасцяў СКБД дамп на Secondary не ствараецца, і таму застаецца толькі магчымасць файлавага бэкапу.
Каб зменшыць рызыкі прастою, пры стварэнні адмоваўстойлівай сістэмы ўтворыцца «жывая» кластарная канфігурацыя, і Primary можа паступова міграваць паміж рознымі серверамі. Напрыклад, ПА Patroni само запускае Primary на рандомна абранай надзе кластара. У СРК няма спосабу адсочваць гэта "са скрынкі", і, калі змяняецца канфігурацыя, працэсы ламаюцца. Гэта значыць укараненне вонкавага кіравання мяшае СРК эфектыўна працаваць, таму што кіраўнік сервер проста не разумее, адкуль і якія дадзеныя трэба капіяваць.
Яшчэ адна праблема – рэалізацыя бэкапу ў Postgres. Яна магчыма праз dump, і на малых базах гэта працуе. Але ў вялікіх БД дамп робіцца доўга, патрабуе шмат рэсурсаў і можа прывесці да збою экзэмпляра БД.
Файлавы бэкап выпраўляе сітуацыю, але на вялікіх базах ён ідзе павольна, таму што працуе ў аднаструменным рэжыме. Да таго ж у вендараў з'яўляецца цэлы шэраг дадатковых абмежаванняў. То нельга адначасова выкарыстоўваць файлавы і дампавы бэкап, то не падтрымліваецца дэдуплікацыя. Праблем аказваецца шмат, і часцей за ўсё прасцей замест Postgres абраць дарагую, але правераную СКБД.
Адыходзіць няма куды! Ззаду Масква распрацоўшчыкі!
Аднак нядаўна наша каманда апынулася перад няпростым выклікам: у праекце стварэння АІС ОСАГО 2.0, дзе мы рабілі ІТ-інфраструктуру, распрацоўшчыкі для новай сістэмы выбралі PostgreSQL.
Буйным распрацоўнікам ПА нашмат прасцей выкарыстоўваць "модныя" open-source рашэнні. У штаце таго ж Facebook дастаткова спецыялістаў, якія падтрымліваюць працу гэтай СКБД. А ў выпадку з РСА усе задачы "другога дня" клаліся на нашы плечы. Ад нас патрабавалася забяспечыць адмоваўстойлівасць, сабраць кластар і, вядома, наладзіць рэзервовае капіраванне. Логіка дзеянняў была такая:
- Навучыць СРК рабіць бэкап з Primary-ноды кластара. Для гэтага СРК павінна знаходзіць яе - значыць, патрэбна інтэграцыя з тым ці іншым рашэннем па кіраванні кластарам PostgreSQL. У выпадку з РСА для гэтага выкарыстоўвалася праграмнае забеспячэнне Patroni.
- Вызначыцца з тыпам бэкапу, зыходзячы з аб'ёмаў дадзеных і патрабаванняў да аднаўлення. Напрыклад, калі трэба аднаўляць старонкі гранулярна, выкарыстоўваць дамп, а калі базы вялікія і гранулярнага аднаўлення не патрабуецца - працаваць на ўзроўні файлаў.
- Прыкруціць да рашэння магчымасць блокавага бэкапу, каб ствараць рэзервовую копію ў шматструменным рэжыме.
Пры гэтым першапачаткова мы задаліся мэтай стварыць эфектыўную і простую сістэму без монструознай абвязкі з дадатковых кампанентаў. Чым менш мыліц, тым менш нагрузка на персанал і ніжэй рызыка выхаду СРК са строю. Падыходы, у якіх выкарыстоўваліся Veeam і RMAN, мы адразу выключылі, таму што камплект з двух рашэнняў ужо намякае на ненадзейнасць сістэмы.
Трохі магіі для enterprise
Такім чынам, нам трэба было гарантаваць надзейнае рэзервовае капіраванне для 10 кластараў па 3 ноды кожны, пры гэтым у рэзервовым ЦАД люстрана размяшчаецца такая ж інфраструктура. ЦАД у плане PostgreSQL працуюць па прынцыпе active-passive. Агульны аб'ём баз даных складаў 50 ТБ. З гэтым лёгка справіцца любая СРК карпаратыўнага ўзроўню. Але нюанс у тым, што першапачаткова ў Postgres няма і зачэпкі для поўнай і глыбокай сумяшчальнасці з сістэмамі рэзервовага капіявання. Таму нам прыйшлося шукаць рашэнне, якое першапачаткова валодае максімумам функцыянальнасці ў звязку з PostgreSQL, і дапрацоўваць сістэму.
Мы правялі 3 унутраных «хакатона» — адгледзелі больш за паўсотні напрацовак, тэставалі іх, уносілі змены ў сувязі са сваімі гіпотэзамі, зноў правяралі. Прааналізаваўшы даступныя опцыі, мы абралі Commvault. Гэты прадукт ужо «са скрынкі» мог працаваць з найпростай кластарнай усталёўкай PostgreSQL, а яго адчыненая архітэктура выклікала надзею (якая апраўдалася) на паспяховую дапрацоўку і інтэграцыю. Таксама Commvault умее выконваць бэкап логаў PostgreSQL. Напрыклад, Veritas NetBackup у частцы PostgreSQL умее рабіць толькі поўныя бэкапы.
Падрабязней пра архітэктуру. Кіравальныя серверы Commvault былі ўсталяваныя ў кожным з двух ЦАД у канфігурацыі CommServ HA. Сістэма люстраная, кіруецца праз адну кансоль і з пункту гледжання HA адпавядае ўсім патрабаванням enterprise.
Таксама ў кожным ЦАД мы запусцілі па два фізічныя медыя-серверы, да якіх праз SAN па Fibre Channel падключылі выдзеленыя спецыяльна для бэкапаў дыскавыя масівы і істужачныя бібліятэкі. Расцягнутыя базы дэдуплікацыі забяспечылі адмоваўстойлівасць медыясервераў, а падлучэнне кожнага сервера да кожнага CSV - магчымасць бесперапыннай працы пры выхадзе са строю любы кампаненты. Архітэктура сістэмы дазваляе працягваць рэзервовае капіраванне, нават калі ўпадзе адзін з ЦАД.
Patroni для кожнага кластара вызначае Primary-ноду. Ёй можа апынуцца любая свабодная нода ў ЦАД - але толькі ў асноўным. У рэзервовым усе ноды - Secondary.
Каб Commvault разумеў, якая нода кластара з'яўляецца Primary, мы інтэгравалі сістэму (дзякуй адкрытай архітэктуры рашэння) з Postgres. Для гэтага быў створаны скрыпт, які паведамляе аб бягучым размяшчэнні Primary-ноды кіравальнаму серверу Commvault.
У цэлым, працэс выглядае так:
Patroni выбірае Primary → Keepalived паднімае IP-кластар і запускае скрыпт → агент Commvault на абранай нодзе кластара атрымлівае апавяшчэнне, што гэта Primary → Commvault аўтаматычна пераналаджвае бэкап у рамках псеўдакліента.
Плюс такога падыходу ў тым, што рашэнне не ўплывае ні на кансістэнтнасць, ні на карэктнасць логаў, ні на аднаўленне інстансу Postgres. Яно таксама лёгка маштабуецца, таму што зараз не абавязкова фіксаваць для Commvault Primary і Secondary-ноды. Досыць, што сістэма разумее, дзе Primary, і лік вузлоў можа быць павялічана практычна да любога значэння.
Рашэнне не прэтэндуе на ідэальнасць і мае свае нюансы. Commvault умее бэкапіць толькі інстанс цалкам, а не асобныя базы. Таму для кожнай БД створаны асобны інстанс. Рэальныя кліенты аб'яднаны ў віртуальныя псеўдакліенты. Кожны псеўдакліент Commvault уяўляе сабой UNIX кластар. У яго дадаюцца тыя ноды кластара, на якіх усталяваны агент Commvault для Postgres. У выніку ўсе віртуальныя ноды псеўдакліента бэкапяцца як адзін інстанс.
Унутры кожнага псеўдакліента пазначана актыўная нода кластара. Менавіта яе і вызначае наша інтэграцыйнае рашэнне для Commvault. Прынцып яго працы досыць просты: калі на нодзе паднімаецца кластарны IP, скрыпт усталёўвае ў бінарніку агента Commvault параметр "актыўная нода" - фактычна скрыпт ставіць "1" у патрэбнай частцы памяці. Агент перадае гэтыя дадзеныя на CommServe, і Commvault робіць бэкап з патрэбнага вузла. Акрамя гэтага, на ўзроўні скрыпту правяраецца карэктнасць канфігурацыі, дапамагаючы пазбегнуць памылак пры запуску рэзервовага капіявання.
Пры гэтым вялікія базы дадзеных бэкапяцца блокава ў некалькі струменяў, адказваючы патрабаванням RPO і вокны рэзервовага капіявання. Нагрузка на сістэму малаважная: Full-копіі адбываюцца не так часта, у астатнія дні збіраюцца толькі логі, прычым у перыяды нізкай нагрузкі.
Дарэчы, мы прымянілі асобныя палітыкі для рэзервовага капіявання архіўных часопісаў PostgreSQL - яны захоўваюцца па іншых правілах, капіююцца па іншым раскладзе і для іх не ўключаецца дэдуплікацыя, так як гэтыя часопісы нясуць у сабе унікальныя дадзеныя.
Каб забяспечыць кансістэнтнасць усёй ІТ-інфраструктуры, асобныя файлавыя кліенты Commvault устаноўлены на кожнай з нод кластара. Яны выключаюць з рэзервовых копій файлы Postgres і прызначаны толькі для бэкапу АС і прыкладных прыкладанняў. Для гэтай часткі звестак таксама прадугледжана свая палітыка, і свой тэрмін захоўвання.
Цяпер СРК не ўплывае на прадуктыўныя сэрвісы, але, калі сітуацыя зменіцца, у Commvault можна будзе ўключыць сістэму абмежавання нагрузкі.
Падыходзіць? Падыходзіць!
Такім чынам, мы атрымалі не проста працаздольны, але і цалкам аўтаматызаваны бэкап для кластарнай усталёўкі PostgreSQL, прычым які адпавядае ўсім патрабаваннямі выклікам enterprise.
Параметры RPO і RTO у 1 гадзіну і 2 гадзіны перакрыты з запасам, а значыць, сістэма будзе адпавядаць ім і пры значным росце аб'ёмаў захоўваемых дадзеных. Насуперак мноству сумневаў, PostgreSQL і enterprise-асяроддзе апынуліся суцэль сумяшчальныя. І зараз мы па сваім досведзе ведаем, што бэкап для падобных СКБД магчымы ў самых разнастайных канфігурацыях.
Вядома, на гэтым шляху нам прыйшлося зносіць сем пар жалезных ботаў, пераадолець шэраг цяжкасцяў, наступіць на некалькі грабляў і выправіць некаторую колькасць памылак. Але зараз падыход ужо апрабаваны і можа прымяняцца для ўкаранення Open Source замест прапрыетарных СКБД у суровых умовах enterprise.
А вы спрабавалі працаваць з PostgreSQL у карпаратыўным асяроддзі?
аўтары:
Алег Лаўрэнаў, інжынер-праекціроўшчык сістэм захоўвання дадзеных «Інфасістэмы Джэт»
Дзмітрый Ярыкін, інжынер-праекціроўшчык вылічальных комплексаў «Інфасістэмы Джэт»
Крыніца: habr.com