Көптеген адамдар PostgreSQL ДҚБЖ-мен таныс және ол шағын қондырғыларда өзін дәлелдеді. Дегенмен, Open Source тенденциясы, тіпті ірі компаниялар мен кәсіпорынның талаптарына қатысты болса да, барған сайын айқын бола бастады. Бұл мақалада біз Postgres-ті корпоративтік ортаға қалай біріктіру керектігін айтамыз және мысал ретінде Commvault сақтық көшірме жүйесін пайдаланып осы дерекқордың сақтық көшірме жүйесін (BSS) жасау тәжірибемізбен бөлісеміз.
PostgreSQL қазірдің өзінде өзінің құндылығын дәлелдеді - ДҚБЖ тамаша жұмыс істейді, оны Alibaba және TripAdvisor сияқты сәнді цифрлық бизнестер пайдаланады және лицензиялық алымдардың болмауы оны MS SQL немесе Oracle DB сияқты құбыжықтарға қызықты балама етеді. Бірақ біз Enterprise ландшафтында PostgreSQL туралы ойлана бастағанда, біз бірден қатаң талаптарға тап боламыз: «Конфигурация ақауларына төзімділік туралы не деуге болады? апатқа қарсы тұру? жан-жақты мониторинг қайда? Автоматтандырылған сақтық көшірмелер туралы не деуге болады? Таспа кітапханаларын тікелей және қосымша жадта пайдалану туралы не деуге болады?
Бір жағынан, PostgreSQL-де Oracle DB жүйесіндегі RMAN немесе SAP Database Backup сияқты «ересек» ДҚБЖ сияқты кірістірілген сақтық көшірме құралдары жоқ. Екінші жағынан, корпоративтік сақтық көшірме жүйелерін жеткізушілер (Veeam, Veritas, Commvault) PostgreSQL-ді қолдағанымен, олар тек белгілі (әдетте дербес) конфигурациямен және әртүрлі шектеулер жиынтығымен жұмыс істейді.
Barman, Wal-g, pg_probackup сияқты PostgreSQL үшін арнайы әзірленген сақтық көшірме жүйелері PostgreSQL ДҚБЖ шағын қондырғыларында немесе АТ ландшафтының басқа элементтерінің күрделі сақтық көшірмелерін қажет етпейтін жерлерде өте танымал. Мысалы, PostgreSQL-тен басқа, инфрақұрылым физикалық және виртуалды серверлерді, OpenShift, Oracle, MariaDB, Cassandra және т.б. Мұның барлығының сақтық көшірмесін ортақ құралмен жасаған жөн. Жеке шешімді тек PostgreSQL үшін орнату жаман идея: деректер дискіге бір жерге көшіріледі, содан кейін оны таспаға алып тастау керек. Бұл қосарланған сақтық көшірме сақтық көшірме жасау уақытын, сонымен қатар, ең маңыздысы, қалпына келтіру уақытын арттырады.
Кәсіпорын шешімінде орнатудың сақтық көшірмесі арнайы кластердегі түйіндердің белгілі бір санымен орындалады. Сонымен қатар, мысалы, Commvault тек екі түйінді кластермен жұмыс істей алады, онда Негізгі және Қосымша белгілі түйіндерге қатаң түрде тағайындалады. Бастапқыдан сақтық көшірме жасаудың мәні бар, себебі екіншіден сақтық көшірме жасаудың шектеулері бар. ДҚБЖ ерекшеліктеріне байланысты Екіншілікте дамп жасалмайды, сондықтан файлдың сақтық көшірмесін жасау мүмкіндігі ғана қалады.
Ақауларға төзімді жүйені жасау кезінде тоқтап қалу қаупін азайту үшін «тірі» кластер конфигурациясы жасалады және Негізгі әр түрлі серверлер арасында біртіндеп тасымалдана алады. Мысалы, Patroni бағдарламалық құралының өзі кездейсоқ таңдалған кластер түйінінде Бастапқы параметрді іске қосады. IBS оны қораптан тыс қадағалай алмайды және конфигурация өзгерсе, процестер бұзылады. Яғни, сыртқы басқаруды енгізу ISR тиімді жұмыс істеуіне кедергі жасайды, өйткені басқару сервері қайдан және қандай деректерді көшіру керектігін түсінбейді.
Тағы бір мәселе - Postgres-те сақтық көшірмені енгізу. Бұл демп арқылы мүмкін және ол шағын дерекқорларда жұмыс істейді. Бірақ үлкен дерекқорларда демп ұзақ уақыт алады, көп ресурстарды қажет етеді және дерекқор данасының істен шығуына әкелуі мүмкін.
Файлдың сақтық көшірмесін жасау жағдайды түзетеді, бірақ үлкен дерекқорларда ол баяу, себебі ол бір ағынды режимде жұмыс істейді. Сонымен қатар, сатушыларда бірқатар қосымша шектеулер бар. Не файл мен көшірменің сақтық көшірмелерін бір уақытта пайдалана алмайсыз немесе көшірмеге қолдау көрсетілмейді. Көптеген мәселелер бар және көбінесе Postgres орнына қымбат, бірақ дәлелденген ДҚБЖ таңдау оңайырақ.
Шегінетін жер жоқ! Мәскеулік әзірлеушілер артта қалды!
Дегенмен, жақында біздің команда күрделі мәселеге тап болды: AIS OSAGO 2.0 құру жобасында біз IT инфрақұрылымын құрдық, әзірлеушілер жаңа жүйе үшін PostgreSQL-ті таңдады.
Ірі бағдарламалық жасақтаманы әзірлеушілер үшін «сәнді» ашық бастапқы шешімдерді пайдалану әлдеқайда оңай. Facebook-та осы ДҚБЖ жұмысын қамтамасыз ететін мамандар жеткілікті. Ал RSA жағдайында «екінші күннің» барлық міндеттері біздің иығымызға түсті. Бізден ақауларға төзімділікті қамтамасыз ету, кластерді жинау және, әрине, сақтық көшірме жасау талап етілді. Іс-әрекеттің логикасы келесідей болды:
- СРК кластердің Бастапқы түйінінен сақтық көшірме жасауды үйрету. Ол үшін SRK оны табуы керек - бұл PostgreSQL кластерін басқарудың сол немесе басқа шешімімен интеграция қажет екенін білдіреді. RSA жағдайында бұл үшін Patroni бағдарламалық құралы пайдаланылды.
- Деректердің көлемі мен қалпына келтіру талаптары негізінде сақтық көшірме түрін шешіңіз. Мысалы, беттерді түйіршікті түрде қалпына келтіру қажет болғанда, дампты пайдаланыңыз және дерекқорлар үлкен болса және түйіршікті қалпына келтіру қажет болмаса, файл деңгейінде жұмыс істеңіз.
- Көп ағынды режимде сақтық көшірме жасау үшін блоктың сақтық көшірмесін жасау мүмкіндігін шешімге тіркеңіз.
Сонымен бірге, біз бастапқыда қосымша құрамдас бөліктердің құбыжық жиынтығынсыз тиімді және қарапайым жүйені құруға кірістік. Таяқшалар аз болған сайын, қызметкерлердің жұмыс жүктемесі азаяды және IBS істен шығу қаупі азаяды. Біз Veeam және RMAN пайдаланатын тәсілдерді бірден алып тастадық, өйткені екі шешімнің жиынтығы жүйенің сенімсіздігіне нұсқайды.
Кәсіпорын үшін кішкене сиқыр
Осылайша, бізге сақтық көшірме деректер орталығында бірдей инфрақұрылымы бар әрқайсысы 10 түйіннен тұратын 3 кластер үшін сенімді сақтық көшірмеге кепілдік беру керек болды. PostgreSQL тұрғысынан деректер орталықтары белсенді-пассивті принцип бойынша жұмыс істейді. Дерекқордың жалпы көлемі 50 ТБ болды. Кез келген корпоративтік деңгейдегі басқару жүйесі мұны оңай жеңе алады. Бірақ ескерту мынада, бастапқыда Postgres резервтік жүйелермен толық және терең үйлесімділік туралы түсінікке ие емес. Сондықтан бізге PostgreSQL-пен бірге ең жоғары функционалдығы бар шешімді іздеуге және жүйені нақтылауға тура келді.
Біз 3 ішкі «хакатон» өткіздік - біз елуден астам әзірлемелерді қарастырдық, оларды сынап көрдік, гипотезаларымызға байланысты өзгерістер енгіздік және оларды қайтадан сынадық. Қол жетімді опцияларды қарап шыққаннан кейін біз Commvault таңдадық. Қораптан тыс бұл өнім ең қарапайым PostgreSQL кластерін орнатумен жұмыс істей алады және оның ашық архитектурасы сәтті даму мен интеграцияға үміт артты (олар ақталды). Commvault сонымен қатар PostgreSQL журналдарының сақтық көшірмесін жасай алады. Мысалы, PostgreSQL тұрғысынан Veritas NetBackup тек толық сақтық көшірмелерді жасай алады.
Сәулет туралы толығырақ. Commvault басқару серверлері CommServ HA конфигурациясындағы екі деректер орталығының әрқайсысында орнатылды. Жүйе шағылыстырылған, бір консоль арқылы басқарылады және HA тұрғысынан кәсіпорынның барлық талаптарына сәйкес келеді.
Біз сондай-ақ әрбір деректер орталығында екі физикалық медиа серверді іске қостық, оларға Fiber Channel арқылы SAN арқылы сақтық көшірме жасау үшін арнайы арналған диск массивтері мен таспа кітапханаларын қостық. Кеңейтілген деупликация дерекқорлары медиа серверлердің ақауларға төзімділігін қамтамасыз етті және әрбір серверді әрбір CSV-ге қосу кез келген құрамдас сәтсіз болған жағдайда үздіксіз жұмысты қосады. Жүйе архитектурасы деректер орталықтарының бірі құлап қалса да сақтық көшірмені жалғастыруға мүмкіндік береді.
Patroni әрбір кластер үшін Бастапқы түйінді анықтайды. Бұл деректер орталығындағы кез келген бос түйін болуы мүмкін - бірақ көбінесе. Сақтық көшірмеде барлық түйіндер Қосымша болып табылады.
Commvault қай кластер түйіні Бастапқы екенін түсіну үшін біз жүйені (шешімнің ашық архитектурасының арқасында) Postgres-пен біріктірдік. Осы мақсатта Commvault басқару серверіне Негізгі түйіннің ағымдағы орнын есеп беретін сценарий жасалды.
Жалпы алғанда, процесс келесідей көрінеді:
Patroni Негізгі таңдайды → Keepalived IP кластерін таңдайды және сценарийді іске қосады → таңдалған кластер түйініндегі Commvault агенті бұл Бастапқы → Commvault псевдоклиент ішінде сақтық көшірмені автоматты түрде қайта конфигурациялайтыны туралы хабарлама алады.
Бұл тәсілдің артықшылығы мынада: шешім журналдардың жүйелілігіне, дұрыстығына немесе Postgres данасын қалпына келтіруге әсер етпейді. Ол сондай-ақ оңай масштабталады, себебі Commvault Бастапқы және Қосымша түйіндерін түзету қажет емес. Жүйе Бастапқы қай жерде екенін түсінсе жеткілікті және түйіндер санын кез келген мәнге дейін көбейтуге болады.
Шешім идеалды болып көрінбейді және өзіндік нюанстарға ие. Commvault жеке дерекқорлардың емес, тек бүкіл дананың сақтық көшірмесін жасай алады. Сондықтан әрбір дерекқор үшін жеке данасы жасалды. Нақты клиенттер виртуалды псевдоклиенттерге біріктірілген. Әрбір Commvault псевдоклиент UNIX кластері болып табылады. Postgres үшін Commvault агенті орнатылған кластер түйіндері оған қосылады. Нәтижесінде псевдоклиенттің барлық виртуалды түйіндерінің сақтық көшірмесі бір дана ретінде жасалады.
Әрбір псевдоклиент ішінде кластердің белсенді түйіні көрсетіледі. Commvault үшін интеграциялық шешіміміз осылай анықтайды. Оның жұмыс істеу принципі өте қарапайым: кластер IP түйінде көтерілсе, сценарий Commvault агентінің екілік жүйесінде «белсенді түйін» параметрін орнатады - іс жүзінде сценарий жадтың қажетті бөлігінде «1» орнатады. . Агент бұл деректерді CommServe қызметіне жібереді және Commvault қалаған түйіннен сақтық көшірме жасайды. Сонымен қатар, конфигурацияның дұрыстығы сценарий деңгейінде тексеріліп, сақтық көшірме жасау кезінде қателерді болдырмауға көмектеседі.
Бұл ретте үлкен дерекқорлардың сақтық көшірмесі бірнеше ағындар бойынша блоктарда RPO және сақтық көшірме терезесінің талаптарын қанағаттандырады. Жүйедегі жүктеме шамалы: толық көшірмелер жиі болмайды, басқа күндері тек журналдар жиналады, ал жүктеме аз кезеңдерінде.
Айтпақшы, біз PostgreSQL мұрағат журналдарының сақтық көшірмесін жасау үшін бөлек саясаттарды қолдандық - олар әртүрлі ережелерге сәйкес сақталады, басқа кестеге сәйкес көшіріледі және олар үшін қайталану қосылмаған, өйткені бұл журналдарда бірегей деректер бар.
Бүкіл АТ-инфрақұрылымында сәйкестікті қамтамасыз ету үшін кластер түйіндерінің әрқайсысында бөлек Commvault файл клиенттері орнатылады. Олар Postgres файлдарын сақтық көшірмелерден алып тастайды және тек ОЖ мен қолданбаның сақтық көшірмелеріне арналған. Деректердің бұл бөлігінің де өз саясаты мен сақтау мерзімі бар.
Қазіргі уақытта IBS өнімділік қызметтеріне әсер етпейді, бірақ жағдай өзгерсе, Commvault жүктемені шектеуді қоса алады.
Бұл жақсы ма? Жақсы!
Осылайша, біз PostgreSQL кластерін орнату үшін тек жұмыс істейтін ғана емес, сонымен қатар толық автоматтандырылған сақтық көшірмені алдық және ол кәсіпорын қоңырауларына қойылатын барлық талаптарға сәйкес келеді.
1 сағат және 2 сағаттық RPO және RTO параметрлері маржамен жабылған, бұл жүйе сақталған деректер көлемінің айтарлықтай ұлғаюымен де оларға сәйкес келетінін білдіреді. Көптеген күмәндерге қарамастан, PostgreSQL және кәсіпорын ортасы өте үйлесімді болып шықты. Ал енді біз өз тәжірибемізден осындай ДҚБЖ резервтік көшірмелері әртүрлі конфигурацияларда мүмкін болатынын білеміз.
Әрине, бұл жолда жеті жұп темір етік тоздырып, талай қиындықты жеңіп, бірнеше тырма басып, біраз қателіктерді түзеуге тура келді. Бірақ қазір әдіс сыналған және қатал кәсіпорын жағдайында меншікті ДҚБЖ орнына Ашық бастапқы кодты енгізу үшін пайдаланылуы мүмкін.
Корпоративтік ортада PostgreSQL-пен жұмыс істеп көрдіңіз бе?
Авторлар:
Олег Лавренов, Jet Infosystems деректерді сақтау жүйелерінің инженер-конструкторы
Дмитрий Ерыкин, Jet Infosystems компьютерлік жүйелердің инженері
Ақпарат көзі: www.habr.com