Çoxları PostgreSQL verilənlər bazası idarəetmə sistemi ilə tanışdır və o, kiçik quraşdırmalarda özünü sübut etdi. Bununla belə, açıq mənbəyə doğru tendensiya, hətta böyük şirkətlər və müəssisə tələbləri üçün getdikcə daha aydın görünür. Bu yazıda Postgres-i korporativ mühitə necə inteqrasiya edəcəyimizi izah edəcəyik və nümunə olaraq Commvault ehtiyat nüsxə sistemindən istifadə edərək bu verilənlər bazası üçün ehtiyat nüsxə sistemi (BSS) yaratmaq təcrübəmizi paylaşacağıq.
PostgreSQL artıq öz dəyərini sübut edib – DBMS mükəmməl işləyir, ondan Alibaba və TripAdvisor kimi dəbdə olan rəqəmsal bizneslər tərəfindən istifadə olunur və lisenziya ödənişlərinin olmaması onu MS SQL və ya Oracle DB kimi behemotlara cəlbedici alternativ edir. Lakin biz müəssisə mənzərəsində PostgreSQL haqqında düşünməyə başlayan kimi dərhal ciddi tələblərlə qarşılaşırıq: "Bəs konfiqurasiya xətalarına dözümlülük? Bəs fəlakətin bərpası? Hərtərəfli monitorinq haradadır? Avtomatlaşdırılmış ehtiyat nüsxələri haqqında nə demək olar? Həm birbaşa, həm də ikinci dərəcəli yaddaş kimi lent kitabxanalarından istifadə haqqında nə demək olar?"
Bir tərəfdən, PostgreSQL-də Oracle DB-də RMAN və ya SAP Database Backup kimi "yetkin" DBMS kimi daxili ehtiyat alətləri yoxdur. Digər tərəfdən, korporativ ehtiyat sistem təminatçıları (Veeam, Veritas, Commvault) PostgreSQL-i dəstəkləsələr də, onlar yalnız xüsusi (adətən müstəqil) konfiqurasiya və bir sıra məhdudiyyətlərlə işləyirlər.
Barman, Wal-g və pg_probackup kimi PostgreSQL-ə xas ehtiyat nüsxə sistemləri kiçik PostgreSQL qurğularında və ya digər İT landşaft elementlərinin ağır ehtiyat nüsxələrinin tələb olunmadığı yerlərdə olduqca populyardır. Məsələn, PostgreSQL-ə əlavə olaraq, infrastruktur fiziki və virtual ola bilər. serverlər, OpenShift, Oracle, MariaDB, Cassandra və s. Bütün bunların ümumi bir yedəkləmə alətindən istifadə edərək yedəklənməsi ən yaxşısıdır. PostgreSQL üçün yalnız ayrı bir həll yolu yerləşdirmək pis bir fikirdir: məlumatlar bir yerə diskə kopyalanacaq və sonra lentə köçürülməlidir. Yedəkləmələrin bu cür təkrarlanması yedəkləmə müddətini və daha vacibi, bərpa müddətini artırır.
Müəssisə həllində quraşdırma ehtiyat nüsxəsi xüsusi klasterdə müəyyən sayda qovşaqda baş verir. Bununla belə, Commvault, məsələn, yalnız əsas və ikincil qovşaqların sərt şəkildə təyin olunduğu iki qovşaqlı klasterlə işləyə bilər. Bundan əlavə, yalnız əsas qovşağın ehtiyat nüsxəsini çıxarmaq məna kəsb edir, çünki ikinci dərəcəli qovşaqdan ehtiyat nüsxələrin öz məhdudiyyətləri var. DBMS-nin xüsusiyyətlərinə görə, ikinci dərəcəli qovşaqda dump yaradılmır, ona görə də yalnız fayl ehtiyat nüsxələri mövcuddur.
İşdən çıxma riskini azaltmaq üçün xətaya dözümlü sistem yaratarkən "canlı" klaster konfiqurasiyası yaradılır və ilkin müxtəlif serverlər arasında tədricən köçürülə bilər. Məsələn, Patroni proqramı təsadüfi seçilmiş klaster qovşağında birinciliyi avtomatik olaraq işə salır. SRK-nın bunu qutudan kənarda izləmək imkanı yoxdur və konfiqurasiya dəyişərsə, proseslər pozulur. Bu o deməkdir ki, xarici idarəetmənin həyata keçirilməsi SRK-nın effektivliyinə mane olur, çünki idarəedici server sadəcə olaraq hansı məlumatların haradan kopyalanması lazım olduğunu başa düşmür.
Digər bir məsələ Postgres-də ehtiyat nüsxələrin tətbiqidir. Bu dump vasitəsilə mümkündür və kiçik verilənlər bazaları üçün işləyir. Bununla belə, daha böyük verilənlər bazaları üçün dempinq uzun müddət tələb edir, çoxlu resurs tələb edir və verilənlər bazası nümunəsinin uğursuzluğuna səbəb ola bilər.
Fayl ehtiyat nüsxələri vəziyyəti yaxşılaşdırır, lakin böyük verilənlər bazalarında tək yivli rejimdə işlədikləri üçün yavaş olurlar. Bundan əlavə, satıcılar bir sıra əlavə məhdudiyyətlər qoyurlar. Məsələn, onlar fayl və ehtiyat nüsxələrini eyni vaxtda istifadə edə bilməzlər və ya təkmilləşdirməni dəstəkləmirlər. Problemlər çoxdur və Postgres əvəzinə bahalı, lakin sübut edilmiş DBMS seçmək daha asandır.
Geri dönüş yoxdur! Moskva tərtibatçıları arxamızdadır!
Bununla belə, komandamız bu yaxınlarda çətin problemlə üzləşdi: İT infrastrukturunu inkişaf etdirdiyimiz AIS OSAGO 2.0-ın yaradılması layihəsində tərtibatçılar yeni sistem üçün PostgreSQL-i seçdilər.
Böyük proqram tərtibatçıları moda açıq mənbəli həllərdən istifadə etməyi daha asan tapırlar. Məsələn, Facebook-da bu DBMS-i dəstəkləyən çoxlu sayda mütəxəssis var. Amma RSA məsələsində bütün “ikinci gün” vəzifələri bizim çiyinlərimizə düşdü. Bizdən səhvlərə dözümlülüyünü təmin etmək, klaster yığmaq və əlbəttə ki, ehtiyat nüsxələri qurmaq tələb olunurdu. Məntiq belə idi:
- SRK-ya klasterin əsas qovşağının ehtiyat nüsxəsini çıxarmağı öyrədin. Bunun üçün SRK onu tapa bilməlidir, yəni PostgreSQL klaster idarəetmə həlli ilə inteqrasiya tələb olunur. RSA vəziyyətində bunun üçün Patroni proqramından istifadə edilmişdir.
- Məlumat həcminə və bərpa tələblərinə əsasən ehtiyat nüsxə növünə qərar verin. Misal üçün, əgər dənəvər səhifə bərpası tələb olunursa, zibildən istifadə edin, verilənlər bazaları böyükdürsə və dənəvər bərpalar tələb olunmursa, fayl səviyyəsində bərpalardan istifadə edin.
- Çox yivli rejimdə ehtiyat nüsxə yaratmaq üçün həllə blok ehtiyat nüsxə imkanını əlavə edin.
İlkin məqsədimiz dəhşətli əlavə komponentlər dəsti olmadan səmərəli və sadə sistem yaratmaq idi. Daha az həll yolları işçilər üçün daha az iş və ehtiyat sisteminin nasazlığı riskinin azalması demək idi. Artıq sistemin etibarsızlığına işarə edən iki həllin birləşməsi kimi Veeam və RMAN-dan istifadə edən yanaşmaları dərhal istisna etdik.
Müəssisə üçün bir az sehr
Beləliklə, biz hər biri 3 qovşaqdan ibarət 10 klaster üçün etibarlı ehtiyat nüsxələrinə zəmanət verməli idik, eyni infrastruktur ehtiyat məlumat mərkəzində əks olunur. Məlumat mərkəzləri PostgreSQL üçün aktiv-passiv əsasda işləyir. Ümumi verilənlər bazası həcmi 50 TB idi. İstənilən korporativ səviyyəli məlumat mərkəzi bunu asanlıqla idarə edə bilər. Bununla belə, Postgres ehtiyat sistemləri ilə tam və dərin uyğunluğu təmin etmir. Buna görə də, PostgreSQL ilə birlikdə maksimum funksionallıq təklif edən və sistemi daha da inkişaf etdirən bir həll tapmalı olduq.
Biz üç daxili hakaton keçirdik, əllidən çox dizaynı nəzərdən keçirdik, onları sınaqdan keçirdik, fərziyyələrimiz əsasında dəyişikliklər etdik və yenidən sınaqdan keçirdik. Mövcud variantları təhlil etdikdən sonra Commvault-u seçdik. Bu məhsul sadə PostgreSQL klaster quraşdırılmasını qutudan çıxara bilərdi və onun açıq arxitekturası uğurlu fərdiləşdirmə və inteqrasiya üçün ümidlər artırdı (bu, doğru idi). Commvault həmçinin PostgreSQL qeydlərinin ehtiyat nüsxəsini çıxara bilər. Məsələn, Veritas NetBackup, PostgreSQL-ə gəldikdə, yalnız tam ehtiyat nüsxələrini yerinə yetirə bilər.
Memarlıq haqqında daha çox məlumat. Commvault idarəetmə serverləri CommServ HA konfiqurasiyasında iki məlumat mərkəzinin hər birində quraşdırılmışdır. Sistem əks olunur, tək konsol vasitəsilə idarə olunur və bütün müəssisənin HA tələblərinə cavab verir.
Biz həmçinin Fiber Kanal SAN vasitəsilə xüsusi disk massivlərinə və lent kitabxanalarına qoşulmuş iki fiziki media serverini hər bir məlumat mərkəzində yerləşdirdik. Genişləndirilmiş təkmilləşdirmə verilənlər bazaları media serverləri üçün nasazlığa dözümlülüyünü təmin etdi və hər bir serverin hər bir CSV-yə qoşulması hər hansı komponent uğursuz olsa belə, fasiləsiz işləməyi təmin etdi. Sistemin arxitekturası bir məlumat mərkəzi uğursuz olsa belə, davamlı ehtiyat nüsxəsini çıxarmağa imkan verir.
Patroni hər klaster üçün İlkin qovşaq təyin edir. Bu, məlumat mərkəzində hər hansı mövcud qovşaq ola bilər, lakin yalnız əsas çoxluqda. Ehtiyat klasterdə bütün qovşaqlar İkinci dərəcəlidir.
Commvault-un hansı klaster qovşağının əsas olduğunu başa düşməsini təmin etmək üçün sistemi (həll yolunun açıq arxitekturası sayəsində) Postgres ilə inteqrasiya etdik. Bu məqsədlə, əsas qovşağın cari yerini menecerə bildirən bir skript yaratdıq. server Komvault.
Ümumiyyətlə, proses belə görünür:
Patroni Primary seçir → Keepalived IP klasterini açır və skripti işə salır → seçilmiş klaster qovşağındakı Commvault agenti bunun İlkin olması barədə bildiriş alır → Commvault psevdo-müştəri daxilində ehtiyat nüsxəni avtomatik olaraq yenidən konfiqurasiya edir.
Bu yanaşmanın üstünlüyü ondan ibarətdir ki, o, ardıcıllığa, qeydlərin düzgünlüyünə və ya Postgres instansiyasının bərpasına təsir göstərmir. Commvault artıq sabit əsas və ikincil qovşaq tələb etmədiyi üçün o, həmçinin asanlıqla miqyaslana bilir. Sadəcə olaraq hansının əsas qovşaq olduğunu bilmək qovşaqların sayını demək olar ki, istənilən dəyərə artırmağa imkan verir.
Həll mükəmməl deyil və öz nüansları var. Commvault fərdi verilənlər bazalarını deyil, yalnız bütün nümunələri yedəkləyə bilər. Buna görə də hər bir verilənlər bazası üçün ayrıca instansiya yaradılır. Real müştərilər virtual psevdo-müştərilərə qruplaşdırılır. Hər bir Commvault psevdo-müştəri UNIX klasterini təmsil edir. Postgres üçün Commvault agenti quraşdırılmış klaster qovşaqları ona əlavə olunur. Nəticədə, psevdo-müştərinin bütün virtual qovşaqları tək nümunə kimi ehtiyat nüsxələnir.
Hər bir psevdo-müştəri aktiv klaster qovşağını təyin edir. Commvault üçün inteqrasiya həllimizin müəyyən etdiyi budur. Onun işləməsi olduqca sadədir: klaster IP-si qovşaqda qaldırılıbsa, skript Commvault agent binarında "aktiv node" parametrini təyin edir - effektiv şəkildə skript müvafiq yaddaş yerində "1" təyin edir. Agent bu məlumatları CommServe-ə ötürür və Commvault müvafiq qovşaqdan ehtiyat nüsxəsini həyata keçirir. Bundan əlavə, konfiqurasiya skript səviyyəsində yoxlanılır ki, bu da ehtiyat nüsxəni işə salarkən xətaların qarşısını almağa kömək edir.
Böyük verilənlər bazaları RPO və ehtiyat pəncərə tələblərinə cavab verən çoxsaylı axınlarda blok-blok ehtiyat nüsxəsini çıxarır. Sistem yükü əhəmiyyətsizdir: tam ehtiyat nüsxələri nadir hallarda baş verir və digər günlərdə, xüsusən də aşağı yük dövrlərində yalnız loglar toplanır.
Yeri gəlmişkən, biz PostgreSQL arxiv jurnallarının ehtiyat nüsxəsini çıxarmaq üçün ayrıca siyasətlər həyata keçirmişik — onlar müxtəlif qaydalara uyğun saxlanılır, fərqli cədvələ uyğun surətdə köçürülür və bu jurnallarda unikal məlumatlar olduğu üçün təkmilləşdirmə onlar üçün aktiv deyil.
Bütün İT infrastrukturunun ardıcıllığını təmin etmək üçün hər bir klaster qovşağında ayrıca Commvault fayl müştəriləri quraşdırılır. Onlar Postgres fayllarını ehtiyat nüsxələrindən xaric edir və yalnız OS və proqram ehtiyat nüsxələri üçün nəzərdə tutulub. Bu məlumatın da öz siyasəti və saxlama müddəti var.
Hazırda SRK istehsal xidmətlərinə təsir göstərmir, lakin vəziyyət dəyişərsə, Commvault yükün məhdudlaşdırılmasını aktivləşdirə biləcək.
Yaxşıdır? Bu yaxşıdır!
Beləliklə, biz bütün müəssisə tələblərinə cavab verən klasterləşdirilmiş PostgreSQL quraşdırması üçün təkcə işləyən deyil, həm də tam avtomatlaşdırılmış ehtiyat nüsxəsini almışıq.
1 saat və 2 saatlıq RPO və RTO parametrləri artıqlama ilə aşılmışdır, yəni sistem hətta saxlanılan məlumat həcmlərində əhəmiyyətli artımlar olsa belə, onları qarşılayacaqdır. Çoxlu şübhələrə baxmayaraq, PostgreSQL və müəssisə mühiti tam uyğun olduğunu sübut etdi. İndi isə öz təcrübəmizdən bilirik ki, bu cür DBMS-lərin ehtiyat nüsxəsi müxtəlif konfiqurasiyalarda mümkündür.
Təbii ki, bu yolda yeddi cüt dəmir çəkməni köhnəltməli, bir sıra çətinlikləri dəf etməli, bir neçə dırmıq basmalı, bir neçə səhvi düzəltməli olduq. Lakin indi yanaşma sınaqdan keçirilib və sərt müəssisə mühitlərində mülkiyyətli DBMS əvəzinə açıq mənbə tətbiq etmək üçün istifadə oluna bilər.
Korporativ mühitdə PostgreSQL ilə işləməyə cəhd etmisiniz?
Müəlliflər:
Oleq Lavrenov, Infosystems Jet-də məlumat saxlama sistemləri dizayn mühəndisi
Dmitri Erykin, Infosystems Jet-də hesablama sistemləri üzrə mühəndis
Mənbə: www.habr.com
