როგორ მოვათავსოთ „უფასო“ PostgreSQL მკაცრი საწარმოს გარემოში

ბევრი ადამიანი იცნობს PostgreSQL DBMS-ს და მან თავი დაამტკიცა მცირე ინსტალაციაში. თუმცა, ღია წყაროსკენ მიმართული ტენდენცია სულ უფრო მკაფიო ხდება, მაშინაც კი, როდესაც საქმე ეხება დიდ კომპანიებსა და საწარმოთა მოთხოვნებს. ამ სტატიაში ჩვენ გეტყვით, თუ როგორ გავაერთიანოთ Postgres კორპორატიულ გარემოში და გავუზიაროთ გამოცდილება ამ მონაცემთა ბაზისთვის სარეზერვო სისტემის (BSS) შექმნის შესახებ, მაგალითად Commvault სარეზერვო სისტემის გამოყენებით.

PostgreSQL-მა უკვე დაამტკიცა თავისი ღირსება - DBMS მშვენივრად მუშაობს, მას იყენებენ მოდური ციფრული ბიზნესები, როგორიცაა Alibaba და TripAdvisor, და ლიცენზირების საფასურის ნაკლებობა მას მაცდუნებელ ალტერნატივად აქცევს ისეთი მონსტრების, როგორიცაა MS SQL ან Oracle DB. მაგრამ როგორც კი ჩვენ დავიწყებთ ფიქრს PostgreSQL-ზე Enterprise-ის ლანდშაფტში, მაშინვე წავაწყდებით მკაცრ მოთხოვნებს: „რაც შეეხება კონფიგურაციის ხარვეზების ტოლერანტობას? კატასტროფების წინააღმდეგობა? სად არის ყოვლისმომცველი მონიტორინგი? რაც შეეხება ავტომატურ სარეზერვო ასლებს? რაც შეეხება ფირის ბიბლიოთეკების გამოყენებას როგორც პირდაპირ, ასევე მეორად საცავში?”


ერთის მხრივ, PostgreSQL-ს არ აქვს ჩაშენებული სარეზერვო ინსტრუმენტები, როგორიცაა „ზრდასრული“ DBMS, როგორიცაა RMAN Oracle DB-ში ან SAP მონაცემთა ბაზის სარეზერვო ასლი. მეორეს მხრივ, კორპორატიული სარეზერვო სისტემების მომწოდებლები (Veeam, Veritas, Commvault), თუმცა მხარს უჭერენ PostgreSQL-ს, სინამდვილეში ისინი მუშაობენ მხოლოდ გარკვეული (ჩვეულებრივ დამოუკიდებელი) კონფიგურაციით და სხვადასხვა შეზღუდვებით.

PostgreSQL-სთვის სპეციალურად შექმნილი სარეზერვო სისტემები, როგორიცაა Barman, Wal-g, pg_probackup, ძალიან პოპულარულია PostgreSQL DBMS-ის მცირე ინსტალაციაში ან სადაც არ არის საჭირო IT ლანდშაფტის სხვა ელემენტების მძიმე სარეზერვო ასლები. მაგალითად, PostgreSQL-ის გარდა, ინფრასტრუქტურა შეიძლება შეიცავდეს ფიზიკურ და ვირტუალურ სერვერებს, OpenShift, Oracle, MariaDB, Cassandra და ა.შ. მიზანშეწონილია ამ ყველაფრის სარეზერვო ასლის შექმნა საერთო ხელსაწყოთი. ცალკეული გადაწყვეტის დაყენება ექსკლუზიურად PostgreSQL-ისთვის ცუდი იდეაა: მონაცემები სადღაც დისკზე დაკოპირდება და შემდეგ საჭიროა მისი ამოღება ფირზე. ეს ორმაგი სარეზერვო ასლი ზრდის სარეზერვო ასლის დროს და ასევე, რაც მთავარია, აღდგენის დროს.

საწარმოს გადაწყვეტაში, ინსტალაციის სარეზერვო ასლი ხდება კვანძების გარკვეული რაოდენობით გამოყოფილ კლასტერში. ამავდროულად, მაგალითად, Commvault-ს შეუძლია იმუშაოს მხოლოდ ორკვანძიან კლასტერთან, რომელშიც Primary და Secondary მკაცრად არის მინიჭებული გარკვეულ კვანძებზე. და აზრი აქვს მხოლოდ სარეზერვო ასლის შექმნას Primary-დან, რადგან სარეზერვო ასლს მეორეულიდან აქვს თავისი შეზღუდვები. DBMS-ის თავისებურებების გამო, ნაგავსაყრელი არ იქმნება მეორადზე და, შესაბამისად, რჩება მხოლოდ ფაილის სარეზერვო ასლის შესაძლებლობა.

შეფერხების რისკის შესამცირებლად, შეცდომის ტოლერანტული სისტემის შექმნისას იქმნება „ცოცხალი“ კლასტერის კონფიგურაცია და Primary-ს შეუძლია თანდათან გადაინაცვლოს სხვადასხვა სერვერებს შორის. მაგალითად, Patroni პროგრამული უზრუნველყოფა თავად იწყებს Primary-ს შემთხვევით შერჩეულ კლასტერულ კვანძზე. IBS-ს არ აქვს საშუალება თვალყური ადევნოს ამას და თუ კონფიგურაცია შეიცვლება, პროცესები იშლება. ანუ, გარე კონტროლის დანერგვა ხელს უშლის ISR-ს ეფექტურად მუშაობას, რადგან საკონტროლო სერვერს უბრალოდ არ ესმის, საიდან და რა მონაცემების კოპირებაა საჭირო.

კიდევ ერთი პრობლემა არის სარეზერვო ასლის განხორციელება Postgres-ში. ეს შესაძლებელია dump-ის საშუალებით და მუშაობს მცირე მონაცემთა ბაზებზე. მაგრამ დიდ მონაცემთა ბაზებში, ნაგავსაყრელი დიდი დრო სჭირდება, მოითხოვს უამრავ რესურსს და შეიძლება გამოიწვიოს მონაცემთა ბაზის ინსტანციის წარუმატებლობა.

ფაილის სარეზერვო ასლი ასწორებს სიტუაციას, მაგრამ დიდ მონაცემთა ბაზებზე ის ნელია, რადგან მუშაობს ერთნაკადის რეჟიმში. გარდა ამისა, გამყიდველებს აქვთ დამატებითი შეზღუდვები. ან არ შეგიძლიათ ერთდროულად გამოიყენოთ ფაილების და სარეზერვო ასლების ამოღება, ან დუბლირება არ არის მხარდაჭერილი. ბევრი პრობლემაა და ყველაზე ხშირად უფრო ადვილია Postgres-ის ნაცვლად ძვირადღირებული, მაგრამ დადასტურებული DBMS-ის არჩევა.

უკან დასახევი არსად არის! მოსკოვის დეველოპერები ჩამორჩებიან!

თუმცა, ახლახან ჩვენს გუნდს რთული გამოწვევა შეექმნა: AIS OSAGO 2.0-ის შექმნის პროექტში, სადაც ჩვენ შევქმენით IT ინფრასტრუქტურა, დეველოპერებმა აირჩიეს PostgreSQL ახალი სისტემისთვის.

მსხვილი პროგრამული უზრუნველყოფის დეველოპერებისთვის ბევრად უფრო ადვილია გამოიყენონ „მოდური“ ღია კოდის გადაწყვეტილებები. Facebook-ს ჰყავს საკმარისი სპეციალისტები ამ DBMS-ის მუშაობის მხარდასაჭერად. ხოლო RSA-ს შემთხვევაში, „მეორე დღის“ ყველა დავალება ჩვენს მხრებზე დაეცა. ჩვენ დაგვევალა შეცდომების ტოლერანტობის უზრუნველყოფა, კლასტერის შეკრება და, რა თქმა უნდა, სარეზერვო ასლის შექმნა. მოქმედების ლოგიკა ასეთი იყო:

• ასწავლეთ SRK-ს შექმნას სარეზერვო ასლები კლასტერის ძირითადი კვანძიდან. ამისათვის SRK-მ უნდა იპოვნოს ის - რაც ნიშნავს, რომ საჭიროა ინტეგრაცია PostgreSQL კლასტერის მართვის ამა თუ იმ გადაწყვეტილებთან. RSA-ს შემთხვევაში ამისთვის გამოიყენებოდა Patroni პროგრამული უზრუნველყოფა.
• გადაწყვიტეთ სარეზერვო ასლის ტიპი მონაცემთა მოცულობისა და აღდგენის მოთხოვნების მიხედვით. მაგალითად, როდესაც გჭირდებათ გვერდების მარცვლოვანი აღდგენა, გამოიყენეთ dump და თუ მონაცემთა ბაზები დიდია და მარცვლოვანი აღდგენა არ არის საჭირო, იმუშავეთ ფაილის დონეზე.
• გადაწყვეტას მიამაგრეთ სარეზერვო ბლოკის შესაძლებლობა, რომ შექმნათ სარეზერვო ასლი მრავალ ხრახნიან რეჟიმში.

ამავდროულად, ჩვენ თავდაპირველად დავიწყეთ ეფექტური და მარტივი სისტემის შექმნა დამატებითი კომპონენტების ამაზრზენი აღკაზმულობის გარეშე. რაც უფრო ნაკლები ყავარჯნებია, მით ნაკლებია პერსონალის დატვირთვა და ნაკლებია IBS-ის უკმარისობის რისკი. ჩვენ მაშინვე გამოვრიცხეთ მიდგომები, რომლებიც იყენებდნენ Veeam და RMAN, რადგან ორი გადაწყვეტის ნაკრები უკვე მიუთითებს სისტემის არასანდოობაზე.

პატარა მაგია საწარმოსთვის

ასე რომ, ჩვენ გვჭირდებოდა საიმედო სარეზერვო ასლის გარანტია თითოეული 10 კვანძის 3 კლასტერისთვის, იგივე ინფრასტრუქტურით ასახული სარეზერვო მონაცემთა ცენტრში. მონაცემთა ცენტრები PostgreSQL-ის თვალსაზრისით მუშაობენ აქტიური-პასიური პრინციპით. მონაცემთა ბაზის მთლიანი ზომა იყო 50 ტბ. ნებისმიერი კორპორატიული დონის კონტროლის სისტემა ადვილად უმკლავდება ამას. მაგრამ სიფრთხილე ის არის, რომ თავდაპირველად Postgres-ს არ აქვს წარმოდგენა სარეზერვო სისტემებთან სრული და ღრმა თავსებადობის შესახებ. ამიტომ, ჩვენ უნდა ვეძებოთ გამოსავალი, რომელსაც თავდაპირველად მაქსიმალური ფუნქციონირება ჰქონდა PostgreSQL-თან ერთად და დახვეწა სისტემა.

ჩვენ ჩავატარეთ 3 შიდა „ჰაკათონი“ - გადავხედეთ ორმოცდაათზე მეტ განვითარებას, გამოვცადეთ ისინი, შევიტანეთ ცვლილებები ჩვენს ჰიპოთეზებთან დაკავშირებით და ხელახლა გამოვცადეთ ისინი. ხელმისაწვდომი ვარიანტების განხილვის შემდეგ, ჩვენ ავირჩიეთ Commvault. ამ პროდუქტს შეუძლია იმუშაოს უმარტივესი PostgreSQL კლასტერის ინსტალაციასთან და მისმა ღია არქიტექტურამ გააჩინა იმედები (რაც გამართლდა) წარმატებული განვითარებისა და ინტეგრაციის შესახებ. Commvault-ს ასევე შეუძლია PostgreSQL ჟურნალების სარეზერვო ასლის შექმნა. მაგალითად, Veritas NetBackup-ს PostgreSQL-ის თვალსაზრისით მხოლოდ სრული სარეზერვო ასლების გაკეთება შეუძლია.

მეტი არქიტექტურის შესახებ. Commvault მართვის სერვერები დაინსტალირებული იყო თითოეულ მონაცემთა ცენტრში CommServ HA კონფიგურაციაში. სისტემა ასახულია, იმართება ერთი კონსოლის მეშვეობით და, HA-ს თვალსაზრისით, აკმაყოფილებს საწარმოს ყველა მოთხოვნას.

ჩვენ ასევე გავუშვით ორი ფიზიკური მედია სერვერი თითოეულ მონაცემთა ცენტრში, რომლებთანაც დავაკავშირეთ დისკის მასივები და ფირის ბიბლიოთეკები, რომლებიც სპეციალურად გამოყოფილია სარეზერვო ასლისთვის SAN-ის მეშვეობით Fiber Channel-ის მეშვეობით. გაფართოებული დედუბლიკაციის მონაცემთა ბაზები უზრუნველყოფდა მედიის სერვერების შეცდომის ტოლერანტობას და თითოეული სერვერის დაკავშირება თითოეულ CSV-სთან გაააქტიურებდა უწყვეტ მუშაობას, თუ რომელიმე კომპონენტი ვერ მოხერხდა. სისტემის არქიტექტურა საშუალებას აძლევს სარეზერვო ასლს გაგრძელდეს მაშინაც კი, თუ მონაცემთა ერთ-ერთი ცენტრი ჩამოვარდება.

პატრონი განსაზღვრავს ძირითად კვანძს თითოეული კლასტერისთვის. ეს შეიძლება იყოს ნებისმიერი თავისუფალი კვანძი მონაცემთა ცენტრში - მაგრამ მხოლოდ ძირითადად. სარეზერვოში, ყველა კვანძი არის მეორადი.

იმისათვის, რომ Commvault-მ გაიგოს, რომელი კლასტერული კვანძია პირველადი, ჩვენ გავაერთიანეთ სისტემა (გადაწყვეტის ღია არქიტექტურის წყალობით) Postgres-თან. ამ მიზნით შეიქმნა სკრიპტი, რომელიც აცნობებს პირველადი კვანძის მიმდინარე მდებარეობას Commvault მართვის სერვერს.

ზოგადად, პროცესი ასე გამოიყურება:

პატრონი ირჩევს Primary → Keepalived აიღებს IP კლასტერს და აწარმოებს სკრიპტს → Commvault აგენტი არჩეულ კლასტერულ კვანძზე იღებს შეტყობინებას, რომ ეს არის Primary → Commvault ავტომატურად ახორციელებს სარეზერვო ასლის კონფიგურაციას ფსევდოკლიენტში.

ამ მიდგომის უპირატესობა ის არის, რომ გამოსავალი არ ახდენს გავლენას ჟურნალების თანმიმდევრულობაზე, სისწორეზე ან პოსტგრესის ინსტანციის აღდგენაზე. ის ასევე ადვილად მასშტაბირებადია, რადგან აღარ არის საჭირო Commvault პირველადი და მეორადი კვანძების დაფიქსირება. საკმარისია სისტემამ გაიგოს სად არის Primary და კვანძების რაოდენობა შეიძლება გაიზარდოს თითქმის ნებისმიერ მნიშვნელობამდე.

გამოსავალი არ არის პრეტენზია იდეალურად და აქვს თავისი ნიუანსი. Commvault-ს შეუძლია მხოლოდ მთელი ინსტანციის სარეზერვო ასლი და არა ცალკეული მონაცემთა ბაზების შექმნა. ამიტომ, თითოეული მონაცემთა ბაზისთვის შეიქმნა ცალკე ინსტანცია. რეალური კლიენტები გაერთიანებულია ვირტუალურ ფსევდო კლიენტებად. თითოეული Commvault ფსევდოკლიენტი არის UNIX კლასტერი. მას ემატება ის კლასტერული კვანძები, რომლებზეც დაყენებულია Commvault აგენტი Postgres-ისთვის. შედეგად, ფსევდოკლიენტის ყველა ვირტუალური კვანძი იქმნება სარეზერვო ასლის სახით, როგორც ერთი ინსტანცია.

თითოეულ ფსევდოკლიენტში მითითებულია კლასტერის აქტიური კვანძი. ეს არის ის, რასაც ჩვენი ინტეგრაციის გადაწყვეტა განსაზღვრავს Commvault-ისთვის. მისი მოქმედების პრინციპი საკმაოდ მარტივია: თუ კლასტერული IP ამაღლებულია კვანძზე, სკრიპტი ადგენს "აქტიური კვანძის" პარამეტრს Commvault აგენტის ორობით - ფაქტობრივად, სკრიპტი ადგენს "1" მეხსიერების საჭირო ნაწილში. . აგენტი ამ მონაცემებს გადასცემს CommServe-ს და Commvault აკეთებს სარეზერვო ასლს სასურველი კვანძიდან. გარდა ამისა, კონფიგურაციის სისწორე მოწმდება სკრიპტის დონეზე, რაც ხელს უწყობს შეცდომების თავიდან აცილებას სარეზერვო ასლის დაწყებისას.

ამავდროულად, დიდი მონაცემთა ბაზების სარეზერვო ასლი ხდება ბლოკებში მრავალ ძაფებში, რაც აკმაყოფილებს RPO და სარეზერვო ფანჯრის მოთხოვნებს. სისტემაზე დატვირთვა უმნიშვნელოა: სრული ასლები არც ისე ხშირად ხდება, სხვა დღეებში გროვდება მხოლოდ ჟურნალები და დაბალი დატვირთვის პერიოდში.

სხვათა შორის, ჩვენ გამოვიყენეთ ცალკეული პოლიტიკა PostgreSQL არქივის ჟურნალების სარეზერვო ასლისთვის - ისინი ინახება სხვადასხვა წესების მიხედვით, კოპირებულია სხვა გრაფიკის მიხედვით და მათთვის არ არის ჩართული დუბლირება, რადგან ეს ჟურნალები შეიცავს უნიკალურ მონაცემებს.

მთელი IT ინფრასტრუქტურის თანმიმდევრულობის უზრუნველსაყოფად, ცალკეული Commvault ფაილის კლიენტები დამონტაჟებულია თითოეულ კლასტერულ კვანძზე. ისინი გამორიცხავენ Postgres ფაილებს სარეზერვო ასლებიდან და განკუთვნილია მხოლოდ OS და აპლიკაციების სარეზერვო ასლისთვის. მონაცემთა ამ ნაწილს ასევე აქვს საკუთარი პოლიტიკა და შენახვის პერიოდი.

ამჟამად, IBS გავლენას არ ახდენს პროდუქტიულობის სერვისებზე, მაგრამ თუ სიტუაცია შეიცვლება, Commvault-ს შეუძლია ჩართოს დატვირთვის შეზღუდვა.

კარგია? კარგი!

ამრიგად, ჩვენ მივიღეთ არა მხოლოდ სამუშაო, არამედ სრულად ავტომატიზირებული სარეზერვო ასლი PostgreSQL კლასტერის ინსტალაციისთვის და ის აკმაყოფილებს ყველა მოთხოვნას საწარმოს ზარებისთვის.

RPO და RTO 1 საათისა და 2 საათის პარამეტრები დაფარულია ზღვარით, რაც ნიშნავს, რომ სისტემა შეასრულებს მათ შენახული მონაცემების მოცულობის მნიშვნელოვანი ზრდის შემთხვევაშიც კი. ბევრი ეჭვის საწინააღმდეგოდ, PostgreSQL და საწარმოს გარემო საკმაოდ თავსებადი აღმოჩნდა. ახლა კი საკუთარი გამოცდილებიდან ვიცით, რომ ასეთი DBMS-ების სარეზერვო ასლის შექმნა შესაძლებელია მრავალფეროვან კონფიგურაციებში.

რა თქმა უნდა, ამ გზაზე მოგვიწია შვიდი წყვილი რკინის ჩექმის ტარება, მთელი რიგი სიძნელეების დაძლევა, რამდენიმე თაიგულზე დადგმა და რიგი შეცდომების გამოსწორება. მაგრამ ახლა მიდგომა უკვე გამოცდილია და შეიძლება გამოყენებულ იქნას ღია წყაროს დანერგვისთვის, საკუთრების DBMS-ის ნაცვლად, საწარმოს მკაცრი პირობებში.

სცადეთ თუ არა PostgreSQL-თან მუშაობა კორპორატიულ გარემოში?

Ავტორები:

ოლეგ ლავრენოვი, Jet Infosystems მონაცემთა შენახვის სისტემების დიზაინერი

დიმიტრი ერიკინი, კომპიუტერული სისტემების დიზაინის ინჟინერი Jet Infosystems-ში

წყარო: www.habr.com