Многи људи су упознати са ПостгреСКЛ ДБМС-ом и он се показао у малим инсталацијама. Међутим, тренд ка отвореном коду постаје све јаснији, чак и када су у питању велике компаније и захтеви предузећа. У овом чланку ћемо вам рећи како да интегришете Постгрес у корпоративно окружење и поделимо наше искуство у креирању система резервних копија (БСС) за ову базу података користећи Цоммваулт систем резервних копија као пример.
ПостгреСКЛ је већ доказао своју вредност – ДБМС ради одлично, користе га модерне дигиталне компаније као што су Алибаба и ТрипАдвисор, а недостатак накнада за лиценцирање чини га примамљивом алтернативом таквим чудовиштима као што су МС СКЛ или Орацле ДБ. Али чим почнемо да размишљамо о ПостгреСКЛ-у у окружењу предузећа, одмах наиђемо на строге захтеве: „Шта је са толеранцијом грешака у конфигурацији? отпорност на катастрофе? где је свеобухватно праћење? Шта је са аутоматским резервним копијама? Шта је са коришћењем библиотека трака и директно и на секундарном складишту?“
С једне стране, ПостгреСКЛ нема уграђене алате за прављење резервних копија, као што су „одрасли“ ДБМС-ови као што је РМАН у Орацле ДБ или САП Датабасе Бацкуп. С друге стране, добављачи корпоративних бацкуп система (Вееам, Веритас, Цоммваулт) иако подржавају ПостгреСКЛ, у ствари раде само са одређеном (обично самосталном) конфигурацијом и са скупом разних ограничења.
Системи за прављење резервних копија специфични за PostgreSQL, као што су Barman, Wal-g и pg_probackup, изузетно су популарни у малим PostgreSQL инсталацијама или тамо где нису потребне велике резервне копије других елемената ИТ пејзажа. На пример, поред PostgreSQL-а, инфраструктура може да укључује физичке и виртуелне сервери, OpenShift, Oracle, MariaDB, Cassandra, итд. Најбоље је направити резервне копије свих ових података помоћу заједничког алата за прављење резервних копија. Примена посебног решења искључиво за PostgreSQL је лоша идеја: подаци ће бити копирани негде на диск, а затим ће их требати преместити на траку. Ово дуплирање резервних копија повећава време прављења резервних копија и, што је још критичније, време опоравка.
У пословном решењу, резервна копија инсталације се дешава са одређеним бројем чворова у наменском кластеру. У исто време, на пример, Цоммваулт може да ради само са кластером са два чвора, у коме су примарни и секундарни стриктно додељени одређеним чворовима. И има смисла само правити резервну копију са примарног, јер резервна копија са секундарног има своја ограничења. Због специфичности ДБМС-а, думп се не креира на секундарном, па стога остаје само могућност прављења резервне копије датотеке.
Да би се смањио ризик од застоја, приликом креирања система отпорног на грешке, креира се „жива“ конфигурација кластера, а Примари може постепено да мигрира између различитих сервера. На пример, сам Патрони софтвер покреће Примари на насумично изабраном чвору кластера. ИБС нема начина да то прати из кутије, а ако се конфигурација промени, процеси се прекидају. Односно, увођење екстерне контроле онемогућава ИСР да ефикасно ради, јер контролни сервер једноставно не разуме одакле и које податке треба копирати.
Други проблем је имплементација резервне копије у Постгресу. Могуће је кроз думп, а ради на малим базама података. Али у великим базама података, думп траје дуго, захтева много ресурса и може довести до неуспеха инстанце базе података.
Резервна копија датотека исправља ситуацију, али на великим базама података је спора јер ради у једнонитном режиму. Поред тога, продавци имају низ додатних ограничења. Или не можете да користите резервне копије датотека и дампова истовремено, или дедупликација није подржана. Проблема је много, а најчешће је лакше изабрати скуп, али проверен ДБМС уместо Постгреса.
Нема где да се повучемо! Московски програмери су иза!
Међутим, недавно се наш тим суочио са тешким изазовом: у пројекту креирања АИС ОСАГО 2.0, где смо креирали ИТ инфраструктуру, програмери су изабрали ПостгреСКЛ за нови систем.
Великим програмерима софтвера је много лакше да користе „трендова“ решења отвореног кода. Фацебоок има довољно стручњака да подржи рад овог ДБМС-а. А у случају РСА, сви задаци „другог дана“ пали су на наша плећа. Од нас се захтевало да обезбедимо толеранцију грешака, саставимо кластер и, наравно, поставимо резервну копију. Логика акције је била следећа:
- Научите СРК да прави резервне копије са примарног чвора кластера. Да би то урадио, СРК га мора пронаћи – што значи да је потребна интеграција са једним или другим решењем за управљање кластером ПостгреСКЛ. У случају РСА, за ово је коришћен Патрони софтвер.
- Одлучите о врсти резервне копије на основу количине података и захтева за опоравак. На пример, када треба детаљно да вратите странице, користите думп, а ако су базе података велике и није потребно грануларно враћање, радите на нивоу датотеке.
- Приложите могућност блоковне резервне копије решењу да направите резервну копију у вишенитном режиму.
У исто време, првобитно смо кренули да креирамо ефикасан и једноставан систем без монструозног упртача додатних компоненти. Што је мање штака, то је мање оптерећење за особље и мањи је ризик од отказивања ИБС-а. Одмах смо искључили приступе који су користили Вееам и РМАН, јер скуп од два решења већ наговештава непоузданост система.
Мало магије за предузећа
Дакле, морали смо да гарантујемо поуздану резервну копију за 10 кластера од по 3 чвора, са истом инфраструктуром која се огледа у центру података резервних копија. Дата центри у смислу ПостгреСКЛ-а раде на активно-пасивном принципу. Укупна величина базе података била је 50 ТБ. Сваки систем контроле на нивоу предузећа може лако да се носи са овим. Али упозорење је да у почетку Постгрес нема појма о потпуној и дубокој компатибилности са системима резервних копија. Због тога смо морали да потражимо решење које је у почетку имало максималну функционалност у спрези са ПостгреСКЛ-ом и да усавршимо систем.
Одржали смо 3 интерна „хакатона“ – погледали смо више од педесет развоја, тестирали их, унели измене у вези са нашим хипотезама и поново их тестирали. Након прегледа доступних опција, изабрали смо Цоммваулт. Изван кутије, овај производ је могао да ради са најједноставнијом ПостгреСКЛ кластер инсталацијом, а његова отворена архитектура је будила наде (које су биле оправдане) у успешан развој и интеграцију. Цоммваулт такође може направити резервну копију ПостгреСКЛ дневника. На пример, Веритас НетБацкуп у смислу ПостгреСКЛ може да прави само потпуне резервне копије.
Више о архитектури. Цоммваулт сервери за управљање су инсталирани у сваки од два дата центра у ЦоммСерв ХА конфигурацији. Систем је пресликан, управља се преко једне конзоле и, са тачке гледишта ХА, испуњава све захтеве предузећа.
Такође смо покренули два физичка медијска сервера у сваком дата центру, на које смо повезали низове дискова и библиотеке трака намењене посебно за прављење резервних копија преко САН-а преко Фибер Цханнел-а. Проширене базе података за дедупликацију осигурале су толеранцију на грешке медијских сервера, а повезивање сваког сервера са сваким ЦСВ-ом омогућило је континуиран рад у случају квара било које компоненте. Архитектура система омогућава наставак прављења резервних копија чак и ако један од центара података падне.
Патрони дефинише примарни чвор за сваки кластер. То може бити било који слободни чвор у центру података - али само углавном. У резервној копији, сви чворови су секундарни.
Да бисмо осигурали да Commvault разуме који је чвор кластера примарни, интегрисали смо систем (захваљујући отвореној архитектури решења) са Postgres-ом. У ту сврху, креирали смо скрипту која менаџеру пријављује тренутну локацију примарног чвора. сервер Комволт.
Генерално, процес изгледа овако:
Патрони бира Примарни → Кеепаливед преузима ИП кластер и покреће скрипту → Цоммваулт агент на изабраном чвору кластера добија обавештење да је ово примарни → Цоммваулт аутоматски реконфигурише резервну копију унутар псеудо-клијента.
Предност овог приступа је у томе што решење не утиче на конзистентност, исправност евиденције или опоравак Постгрес инстанце. Такође је лако скалабилан, јер више није потребно поправљати Цоммваулт примарни и секундарни чвор. Довољно је да систем разуме где се налази Примари, а број чворова се може повећати на скоро било коју вредност.
Решење не претендује да буде идеално и има своје нијансе. Цоммваулт може направити резервну копију само целе инстанце, а не појединачних база података. Стога је за сваку базу података креирана посебна инстанца. Прави клијенти се комбинују у виртуелне псеудо-клијенте. Сваки Цоммваулт псеудо-клијент је УНИКС кластер. Додају се они чворови кластера на којима је инсталиран Цоммваулт агент за Постгрес. Као резултат, сви виртуелни чворови псеудо-клијента су направљени као једна инстанца.
Унутар сваког псеудо-клијента, означен је активни чвор кластера. То је оно што наше интеграцијско решење за Цоммваулт дефинише. Принцип његовог рада је прилично једноставан: ако се ИП кластера подигне на чвору, скрипта поставља параметар „активан чвор“ у бинарном агенту Цоммваулт - у ствари, скрипта поставља „1“ у потребан део меморије . Агент преноси ове податке у ЦоммСерве, а Цоммваулт прави резервну копију са жељеног чвора. Поред тога, исправност конфигурације се проверава на нивоу скрипте, што помаже да се избегну грешке приликом покретања резервне копије.
Истовремено, велике базе података се праве резервне копије у блоковима у више нити, испуњавајући захтеве РПО и прозора за прављење резервних копија. Оптерећење система је незнатно: пуне копије се не појављују тако често, другим данима се прикупљају само евиденције, а током периода малог оптерећења.
Иначе, применили смо посебне смернице за прављење резервних копија ПостгреСКЛ архивских дневника – они се чувају по различитим правилима, копирају по другачијем распореду, а дедупликација за њих није омогућена, пошто ови дневники садрже јединствене податке.
Да би се обезбедила конзистентност у целој ИТ инфраструктури, одвојени клијенти Цоммваулт фајлова су инсталирани на сваком од чворова кластера. Они искључују Постгрес датотеке из резервних копија и намењени су само за прављење резервних копија ОС и апликација. Овај део података такође има своју политику и период чувања.
Тренутно, ИБС не утиче на услуге продуктивности, али ако се ситуација промени, Цоммваулт може да омогући ограничавање оптерећења.
Да ли је добро? Добро!
Дакле, добили смо не само изводљиву, већ и потпуно аутоматизовану резервну копију за инсталацију кластера ПостгреСКЛ-а и испуњава све захтеве за позиве предузећа.
Параметри РПО и РТО од 1 сат и 2 сата покривени су маргином, што значи да ће их систем поштовати чак и уз значајно повећање обима ускладиштених података. Насупрот многим сумњама, испоставило се да су ПостгреСКЛ и пословно окружење прилично компатибилни. А сада знамо из сопственог искуства да је резервна копија за такве ДБМС могућа у великом броју конфигурација.
Наравно, на овом путу смо морали да истрошимо седам пари гвоздених чизама, савладамо низ потешкоћа, нагазимо неколико грабуља и исправимо низ грешака. Али сада је приступ већ тестиран и може се користити за имплементацију отвореног кода уместо власничког ДБМС-а у тешким условима предузећа.
Да ли сте покушали да радите са ПостгреСКЛ-ом у корпоративном окружењу?
Аутори:
Олег Лавренов, пројектант система за складиштење података, Јет Инфосистемс
Дмитриј Ерикин, дизајнер рачунарских система у компанији Јет Инфосистемс
Извор: ввв.хабр.цом
