Qanday qilib "bepul" PostgreSQL-ni qattiq korporativ muhitga moslashtirish mumkin

Ko'pchilik PostgreSQL DBMS bilan yaxshi tanish va u kichik o'rnatishlarda o'zini isbotladi. Biroq, Ochiq manba tendentsiyasi, hatto yirik kompaniyalar va korxonalar talablari haqida gap ketganda ham, tobora aniq bo'lib bormoqda. Ushbu maqolada biz Postgres-ni korporativ muhitga qanday integratsiya qilishni aytib beramiz va misol sifatida Commvault zaxira tizimidan foydalangan holda ushbu ma'lumotlar bazasi uchun zaxira tizimini (BSS) yaratish tajribamiz bilan o'rtoqlashamiz.

PostgreSQL allaqachon o'zining qadr-qimmatini isbotlagan - DBMS ajoyib ishlaydi, undan Alibaba va TripAdvisor kabi zamonaviy raqamli bizneslar foydalanadi va litsenziyalash to'lovlarining yo'qligi uni MS SQL yoki Oracle DB kabi yirtqich hayvonlarga jozibali muqobil qiladi. Ammo biz Enterprise landshaftida PostgreSQL haqida o'ylay boshlaganimizdan so'ng, biz darhol qat'iy talablarga duch kelamiz: "Konfiguratsiya xatolariga bardoshliligi haqida nima deyish mumkin? ofatga qarshilik? keng qamrovli monitoring qayerda? Avtomatlashtirilgan zaxiralar haqida nima deyish mumkin? To'g'ridan-to'g'ri va ikkilamchi xotirada lenta kutubxonalaridan foydalanish haqida nima deyish mumkin?


Bir tomondan, PostgreSQL-da Oracle DB-dagi RMAN yoki SAP Database Backup kabi "kattalar" ma'lumotlar bazasi kabi o'rnatilgan zaxira vositalari mavjud emas. Boshqa tomondan, korporativ zaxira tizimlari (Veeam, Veritas, Commvault) etkazib beruvchilari PostgreSQL-ni qo'llab-quvvatlasalar ham, aslida ular faqat ma'lum (odatda mustaqil) konfiguratsiya va turli cheklovlar to'plami bilan ishlaydi.

Barman, Wal-g, pg_probackup kabi PostgreSQL uchun maxsus ishlab chiqilgan zaxira tizimlari PostgreSQL DBMS ning kichik o'rnatishlarida yoki IT landshaftining boshqa elementlarining og'ir zaxira nusxalari kerak bo'lmagan joylarda juda mashhur. Masalan, PostgreSQL-dan tashqari, infratuzilma jismoniy va virtual serverlarni, OpenShift, Oracle, MariaDB, Cassandra va boshqalarni o'z ichiga olishi mumkin. Bularning barchasini umumiy vosita bilan zaxiralash tavsiya etiladi. Faqat PostgreSQL uchun alohida yechim o'rnatish noto'g'ri fikr: ma'lumotlar diskka biron joyga ko'chiriladi va keyin uni lentaga olib tashlash kerak. Bu ikki marta zahira nusxasi zaxira vaqtini, shuningdek, qayta tiklash vaqtini oshiradi.

Korxona yechimida o'rnatishning zaxira nusxasi ajratilgan klasterdagi ma'lum miqdordagi tugunlar bilan amalga oshiriladi. Shu bilan birga, masalan, Commvault faqat ikkita tugunli klaster bilan ishlashi mumkin, unda birlamchi va ikkilamchi ma'lum tugunlarga qat'iy tayinlangan. Va faqat birlamchidan zaxiralash mantiqiy, chunki Ikkilamchidan zaxiralash o'z cheklovlariga ega. DBMSning o'ziga xos xususiyatlaridan kelib chiqqan holda, ikkinchi darajali damp yaratilmaydi va shuning uchun faqat faylni zaxiralash imkoniyati qoladi.

Ishlamay qolish xavfini kamaytirish uchun nosozliklarga chidamli tizimni yaratishda "jonli" klaster konfiguratsiyasi yaratiladi va birlamchi turli serverlar o'rtasida asta-sekin o'tishi mumkin. Misol uchun, Patroni dasturining o'zi birlamchini tasodifiy tanlangan klaster tugunida ishga tushiradi. IBS buni qutidan tashqarida kuzatishning imkoni yo'q va agar konfiguratsiya o'zgarsa, jarayonlar buziladi. Ya'ni, tashqi boshqaruvning joriy etilishi ISRning samarali ishlashiga to'sqinlik qiladi, chunki boshqaruv serveri qayerdan va qanday ma'lumotlarni nusxalash kerakligini tushunmaydi.

Yana bir muammo - Postgres-da zaxiralashni amalga oshirish. Bu dump orqali mumkin va u kichik ma'lumotlar bazalarida ishlaydi. Ammo katta ma'lumotlar bazalarida dump uzoq vaqt oladi, juda ko'p resurslarni talab qiladi va ma'lumotlar bazasi instansiyasining ishdan chiqishiga olib kelishi mumkin.

Faylning zahira nusxasi vaziyatni to'g'irlaydi, lekin katta ma'lumotlar bazalarida u sekin ishlaydi, chunki u bitta oqim rejimida ishlaydi. Bundan tashqari, sotuvchilar bir qator qo'shimcha cheklovlarga ega. Yoki siz bir vaqtning o'zida fayl va zahira nusxalarini ishlata olmaysiz yoki nusxa ko'chirish qo'llab-quvvatlanmaydi. Ko'p muammolar mavjud va ko'pincha Postgres o'rniga qimmat, ammo tasdiqlangan DBMSni tanlash osonroq.

Orqaga chekinadigan joy yo'q! Moskva ishlab chiquvchilari orqada!

Biroq, yaqinda bizning jamoamiz qiyin muammoga duch keldi: biz IT infratuzilmasini yaratgan AIS OSAGO 2.0 ni yaratish loyihasida ishlab chiquvchilar yangi tizim uchun PostgreSQL ni tanladilar.

Katta dasturiy ta'minot ishlab chiquvchilari uchun "moda" ochiq manbali echimlardan foydalanish ancha oson. Facebookda ushbu DBMS ishlashini qo'llab-quvvatlash uchun etarli mutaxassislar mavjud. Va RSA holatida "ikkinchi kun" ning barcha vazifalari bizning yelkamizga tushdi. Bizdan nosozliklarga chidamliligini ta'minlash, klasterni yig'ish va, albatta, zaxira nusxasini o'rnatish talab qilindi. Harakat mantig'i quyidagicha edi:

• SRKni klasterning birlamchi tugunidan zahira nusxalarini yaratishga o'rgating. Buning uchun SRK uni topishi kerak - ya'ni u yoki bu PostgreSQL klasterni boshqarish yechimi bilan integratsiya zarur. RSA misolida buning uchun Patroni dasturi ishlatilgan.
• Ma'lumotlar hajmi va tiklash talablaridan kelib chiqib, zaxira turini tanlang. Misol uchun, sahifalarni granulyar tarzda tiklashingiz kerak bo'lganda, dumpdan foydalaning va agar ma'lumotlar bazalari katta bo'lsa va granulyar tiklash talab qilinmasa, fayl darajasida ishlang.
• Ko'p tarmoqli rejimda zaxira nusxasini yaratish uchun blokning zaxira nusxasini yaratish imkoniyatini biriktiring.

Shu bilan birga, biz dastlab qo'shimcha komponentlarning dahshatli jabduqlarisiz samarali va sodda tizim yaratishga kirishdik. Qo'ltiq tayoqchalari qancha kam bo'lsa, xodimlarning ish yuki shunchalik kam bo'ladi va IBS ishdan chiqish xavfi shunchalik past bo'ladi. Biz darhol Veeam va RMAN-dan foydalanadigan yondashuvlarni chiqarib tashladik, chunki ikkita yechim to'plami allaqachon tizimning ishonchsizligiga ishora qiladi.

Korxona uchun bir oz sehr

Shunday qilib, biz har birida 10 ta tugunli 3 ta klaster uchun ishonchli zaxiralashni kafolatlashimiz kerak edi, bunda zaxira ma'lumotlar markazida bir xil infratuzilma aks ettirilgan. PostgreSQL nuqtai nazaridan ma'lumotlar markazlari faol-passiv printsipda ishlaydi. Ma'lumotlar bazasining umumiy hajmi 50 TB edi. Har qanday korporativ darajadagi boshqaruv tizimi buni osonlikcha engishi mumkin. Ammo ogohlantirish shundaki, dastlab Postgres zaxira tizimlari bilan to'liq va chuqur muvofiqlik haqida ma'lumotga ega emas. Shuning uchun biz PostgreSQL bilan birgalikda dastlab maksimal funksionallikka ega bo'lgan yechimni izlashimiz va tizimni takomillashtirishimiz kerak edi.

Biz 3 ta ichki "hakaton" o'tkazdik - biz ellikdan ortiq ishlanmalarni ko'rib chiqdik, ularni sinab ko'rdik, farazlarimiz bilan bog'liq holda o'zgartirishlar kiritdik va ularni yana sinab ko'rdik. Mavjud variantlarni ko'rib chiqqach, biz Commvault ni tanladik. Ushbu mahsulot eng oddiy PostgreSQL klasterini o'rnatish bilan ishlashi mumkin edi va uning ochiq arxitekturasi muvaffaqiyatli ishlab chiqish va integratsiyaga umid uyg'otdi (ular oqlandi). Commvault shuningdek, PostgreSQL jurnallarini zaxiralashi mumkin. Misol uchun, PostgreSQL nuqtai nazaridan Veritas NetBackup faqat to'liq zaxira nusxalarini yaratishi mumkin.

Arxitektura haqida ko'proq. Commvault boshqaruv serverlari CommServ HA konfiguratsiyasidagi ikkita ma'lumot markazlarining har biriga o'rnatildi. Tizim aks ettirilgan, bitta konsol orqali boshqariladi va HA nuqtai nazaridan barcha korxona talablariga javob beradi.

Biz, shuningdek, har bir ma'lumot markazida ikkita jismoniy media serverni ishga tushirdik, ularga Fiber Channel orqali SAN orqali zaxiralash uchun maxsus ajratilgan disk massivlari va lenta kutubxonalarini uladik. Kengaytirilgan deuplikatsiya ma'lumotlar bazalari media-serverlarning xatolarga chidamliligini ta'minladi va har bir serverni har bir CSV ga ulash, agar biron bir komponent muvaffaqiyatsiz bo'lsa, uzluksiz ishlashni ta'minladi. Tizim arxitekturasi ma'lumotlar markazlaridan biri tushib ketgan taqdirda ham zaxiralashni davom ettirishga imkon beradi.

Patroni har bir klaster uchun birlamchi tugunni belgilaydi. Bu ma'lumotlar markazidagi har qanday bepul tugun bo'lishi mumkin - lekin faqat asosan. Zaxirada barcha tugunlar Ikkilamchi hisoblanadi.

Commvault qaysi klaster tugunining asosiy ekanligini tushunishi uchun biz tizimni (yechimning ochiq arxitekturasi tufayli) Postgres bilan birlashtirdik. Shu maqsadda Commvault boshqaruv serveriga Asosiy tugunning joriy joylashuvi haqida xabar beruvchi skript yaratildi.

Umuman olganda, jarayon quyidagicha ko'rinadi:

Patroni Birlamchi ni tanlaydi → Keepalived IP klasterini tanlaydi va skriptni ishga tushiradi → tanlangan klaster tugunidagi Commvault agenti bu Asosiy → Commvault psevdo-mijoz ichidagi zaxira nusxasini avtomatik ravishda qayta sozlashi haqida bildirishnoma oladi.

Ushbu yondashuvning afzalligi shundaki, yechim jurnallarning mustahkamligiga, to'g'riligiga yoki Postgres misolining tiklanishiga ta'sir qilmaydi. Bundan tashqari, u osonlik bilan kengaytiriladi, chunki endi Commvault birlamchi va ikkilamchi tugunlarini tuzatish shart emas. Tizim birlamchi qaerda ekanligini tushunishi kifoya va tugunlar sonini deyarli har qanday qiymatga oshirish mumkin.

Yechim o'zini ideal deb ko'rsatmaydi va o'ziga xos nuanslarga ega. Commvault alohida ma'lumotlar bazalarini emas, balki faqat butun nusxani zaxiralashi mumkin. Shuning uchun har bir ma'lumotlar bazasi uchun alohida namuna yaratildi. Haqiqiy mijozlar virtual psevdo-mijozlarga birlashtirilgan. Har bir Commvault psevdo-klienti UNIX klasteridir. Postgres uchun Commvault agenti o'rnatilgan klaster tugunlari unga qo'shiladi. Natijada, pseudo-mijozning barcha virtual tugunlari bitta nusxa sifatida zaxiralanadi.

Har bir psevdo-mijoz ichida klasterning faol tugunlari ko'rsatilgan. Commvault uchun bizning integratsiya yechimimiz shuni belgilaydi. Uning ishlash printsipi juda oddiy: agar IP klasteri tugunga o'rnatilsa, skript Commvault agent ikkilik faylida "faol tugun" parametrini o'rnatadi - aslida skript xotiraning kerakli qismida "1" ni o'rnatadi. . Agent ushbu ma'lumotlarni CommServe-ga uzatadi va Commvault kerakli tugundan zaxira nusxasini yaratadi. Bundan tashqari, konfiguratsiyaning to'g'riligi skript darajasida tekshiriladi, bu zaxirani boshlashda xatolardan qochishga yordam beradi.

Shu bilan birga, katta ma'lumotlar bazalari RPO va zaxira oynasi talablariga javob beradigan bir nechta ish zarralari bo'ylab bloklarda zaxiralanadi. Tizimdagi yuk unchalik katta emas: To'liq nusxalar tez-tez uchramaydi, boshqa kunlarda faqat jurnallar yig'iladi va yuk kam bo'lgan davrlarda.

Aytgancha, biz PostgreSQL arxiv jurnallarining zaxira nusxasini yaratish bo'yicha alohida siyosatlarni qo'lladik - ular turli qoidalarga muvofiq saqlanadi, boshqa jadval bo'yicha ko'chiriladi va ular uchun deuplikatsiya yoqilmaydi, chunki bu jurnallarda noyob ma'lumotlar mavjud.

Butun AT infratuzilmasi bo'ylab izchillikni ta'minlash uchun klaster tugunlarining har biriga alohida Commvault fayl mijozlari o'rnatiladi. Ular Postgres fayllarini zaxira nusxalaridan chiqarib tashlaydi va faqat OS va ilovalarning zaxira nusxalari uchun mo'ljallangan. Ma'lumotlarning bu qismi ham o'z siyosati va saqlash muddatiga ega.

Hozirgi vaqtda IBS mahsuldorlik xizmatlariga ta'sir qilmaydi, ammo agar vaziyat o'zgarsa, Commvault yukni cheklashni yoqishi mumkin.

Bu yaxshimi? Yaxshi!

Shunday qilib, biz PostgreSQL klasterini o'rnatish uchun nafaqat ishlaydigan, balki to'liq avtomatlashtirilgan zaxira nusxasini oldik va u korporativ qo'ng'iroqlar uchun barcha talablarga javob beradi.

1 soat va 2 soatlik RPO va RTO parametrlari chegara bilan qoplangan, ya'ni tizim saqlangan ma'lumotlar hajmi sezilarli darajada oshgan taqdirda ham ularga mos keladi. Ko'pgina shubhalardan farqli o'laroq, PostgreSQL va korporativ muhit juda mos bo'lib chiqdi. Va endi biz o'z tajribamizdan bilamizki, bunday ma'lumotlar bazasini zaxiralash turli xil konfiguratsiyalarda mumkin.

Albatta, bu yo‘lda biz yetti juft temir etik kiyib, bir qancha qiyinchiliklarni yengib o‘tishimiz, bir necha rakkaga qadam bosishimiz, qator xatolarni tuzatishimiz kerak edi. Ammo endi yondashuv allaqachon sinovdan o'tgan va og'ir korporativ sharoitlarda xususiy DBMS o'rniga Ochiq manbani amalga oshirish uchun ishlatilishi mumkin.

PostgreSQL bilan korporativ muhitda ishlashga harakat qildingizmi?

Mualliflar:

Oleg Lavrenov, Jet Infosystems ma'lumotlarni saqlash tizimlari muhandisi

Dmitriy Erikin, Jet Infosystems kompyuter tizimlari bo'yicha muhandis

Manba: www.habr.com