Bir çox insan PostgreSQL DBMS ilə tanışdır və o, kiçik quraşdırmalarda özünü yaxşı sübut etdi. Bununla belə, hətta böyük şirkətlərə və müəssisə tələblərinə gəldikdə belə, Açıq Mənbə meyli getdikcə daha aydın olur. Bu yazıda Postgres-i korporativ mühitə necə inteqrasiya edəcəyimizi təsvir edəcəyik və nümunə olaraq Commvault ehtiyat nüsxə sistemindən istifadə edərək bu verilənlər bazası üçün ehtiyat sistem (BMS) yaratmaq təcrübəmizi bölüşəcəyik.
PostgreSQL artıq öz dəyərini sübut edib – əla işləyir, Alibaba və TripAdvisor kimi dəbdə olan rəqəmsal bizneslər tərəfindən istifadə olunur və qonorarların olmaması onu MS SQL və ya Oracle DB kimi canavarlara cazibədar alternativ edir. Lakin Müəssisə mənzərəsində PostgreSQL haqqında düşünməyə başlayan kimi dərhal sərt tələblərlə qarşılaşırıq: “Bəs konfiqurasiya xətalarına dözümlülük haqqında nə demək olar? fəlakətə dözümlülük? hərtərəfli monitorinq haradadır? Avtomatlaşdırılmış ehtiyat nüsxələri haqqında nə demək olar? Lent kitabxanalarından həm birbaşa, həm də ikinci dərəcəli yaddaşda istifadə haqqında nə demək olar?
Bir tərəfdən, PostgreSQL-də Oracle DB və ya SAP Database Backup-dan "böyüklər" RMAN tipli DBMS kimi daxili ehtiyat alətləri yoxdur. Digər tərəfdən, korporativ ehtiyat sistemlərinin təchizatçıları (Veeam, Veritas, Commvault), PostgreSQL-i dəstəkləsələr də, əslində yalnız müəyyən (adətən müstəqil) konfiqurasiya və müxtəlif məhdudiyyətlər dəsti ilə işləyirlər.
Barman, Wal-g, pg_probackup kimi PostgreSQL üçün xüsusi olaraq hazırlanmış ehtiyat nüsxə sistemləri kiçik PostgreSQL qurğularında və ya İT landşaftının digər elementlərinin ağır ehtiyat nüsxələrinə ehtiyac olmadığı yerlərdə olduqca populyardır. Məsələn, PostgreSQL-ə əlavə olaraq, infrastruktura fiziki və virtual serverlər, OpenShift, Oracle, MariaDB, Cassandra və s. Bütün bunları ümumi bir vasitə ilə ehtiyat nüsxə etmək arzu edilir. Yalnız PostgreSQL üçün ayrıca bir həllin qoyulması pis fikirdir: məlumatlar diskə bir yerə kopyalanacaq və sonra onları lentə çıxarmaq lazımdır. Ehtiyat nüsxənin bu ikiqat artması ehtiyat vaxtını və daha kritik olaraq bərpa müddətini artırır.
Müəssisə həllində quraşdırma ehtiyat nüsxəsi xüsusi klasterin müəyyən sayda qovşaqları ilə baş verir. Eyni zamanda, məsələn, Commvault yalnız iki qovşaqlı klasterlə işləyə bilər, burada Primary və Secondary müəyyən qovşaqlara sərt şəkildə təyin olunur. Bəli və yalnız Əsas ilə ehtiyat nüsxə nüsxəsini çıxarmaq məntiqlidir, çünki İkinci dərəcəli ilə ehtiyat nüsxəsinin öz məhdudiyyətləri var. DBMS-nin xüsusiyyətlərinə görə, ikincildə zibil yaradılmır və buna görə də yalnız fayl ehtiyat nüsxəsinin mümkünlüyü qalır.
İşdən çıxma riskini azaltmaq üçün uğursuzluq sistemi yaratarkən, "canlı" klaster konfiqurasiyası formalaşır və İlkin müxtəlif serverlər arasında tədricən köçürülə bilər. Məsələn, Patroni proqram təminatının özü Təsadüfi seçilmiş klaster qovşağında Primary-i işə salır. RMS-nin bunu qutudan kənarda izləmək imkanı yoxdur və konfiqurasiya dəyişərsə, proseslər pozulur. Yəni, kənar nəzarətin tətbiqi RMS-nin effektiv işləməsinə mane olur, çünki idarəetmə serveri sadəcə olaraq harada və hansı məlumatların kopyalanması lazım olduğunu başa düşmür.
Digər problem Postgres-də ehtiyat nüsxəsinin həyata keçirilməsidir. Dump vasitəsilə mümkündür və kiçik bazalarda işləyir. Lakin böyük verilənlər bazalarında dempinq uzun müddət tələb edir, çoxlu resurs tələb edir və verilənlər bazası instansiyasının sıradan çıxmasına səbəb ola bilər.
Fayl ehtiyat nüsxəsi vəziyyəti düzəldir, lakin böyük verilənlər bazalarında bu, tək yivli rejimdə işlədiyi üçün yavaş olur. Bundan əlavə, satıcıların bir sıra əlavə məhdudiyyətləri var. Ya siz eyni zamanda fayl və ehtiyat nüsxələrindən istifadə edə bilməzsiniz, ya da təkmilləşdirmə dəstəklənmir. Bir çox problem var və çox vaxt Postgres əvəzinə bahalı, lakin sübut edilmiş DBMS seçmək daha asandır.
Geri çəkilmək üçün heç bir yer yoxdur! Moskva tərtibatçılarının arxasında!
Lakin bu yaxınlarda komandamız çətin problemlə üzləşdi: İT infrastrukturunu hazırladığımız 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ı üçün "dəbdə olan" açıq mənbəli həllərdən istifadə etmək daha asandır. Eyni Facebook əyalətində bu DBMS-nin işini dəstəkləyən kifayət qədər mütəxəssislər var. Və RSA vəziyyətində "ikinci günün" bütün vəzifələri çiyinlərimizə düşdü. Bizdən səhvlərə qarşı dözümlülük təmin etmək, klaster qurmaq və əlbəttə ki, ehtiyat nüsxələri qurmaq tələb olunurdu. Hərəkətlərin məntiqi belə idi:
- SRK-ya klasterin Əsas qovşağından ehtiyat nüsxə çıxarmağı öyrət. Bunun üçün RMS onu tapmalıdır, yəni bu və ya digər PostgreSQL klaster idarəetmə həlli ilə inteqrasiya lazımdır. PCA vəziyyətində bunun üçün Patroni proqram təminatı istifadə edilmişdir.
- Məlumatın miqdarına və bərpa tələblərinə əsasən ehtiyat nüsxəsinin növünə qərar verin. Məsələn, səhifələri dənəvər şəkildə bərpa etmək lazım olduqda, zibildən istifadə edin və verilənlər bazası böyükdürsə və dənəvər bərpa tələb olunmursa, fayl səviyyəsində işləyin.
- Çox yivli rejimdə ehtiyat nüsxə yaratmaq üçün blokun ehtiyat nüsxəsinin mümkünlüyünü həllə əlavə edin.
Eyni zamanda, ilkin olaraq biz əlavə komponentlərdən dəhşətli bağlamalar olmadan effektiv və sadə bir sistem yaratmağa başladıq. Dəstək nə qədər az olarsa, heyətin yükü bir o qədər az olar və İBS-nin uğursuzluq riski bir o qədər az olar. Biz dərhal Veeam və RMAN-dan istifadə edən yanaşmaları istisna etdik, çünki iki həll yolu artıq sistemin etibarsızlığına işarə edir.
Müəssisə üçün bir az sehr
Beləliklə, hər biri 10 qovşaqdan ibarət 3 klaster üçün etibarlı ehtiyat nüsxəsinə zəmanət verməli idik, eyni infrastruktur ehtiyat məlumat mərkəzində əks olunur. PostgreSQL baxımından məlumat mərkəzləri aktiv-passiv prinsipi ilə işləyir. Məlumat bazalarının ümumi həcmi 50 TB idi. İstənilən korporativ səviyyəli RMS bunu asanlıqla idarə edə bilər. Ancaq nüans budur ki, əvvəlcə Postgres-də ehtiyat sistemlərlə tam və dərin uyğunluq üçün heç bir çəngəl yoxdur. Buna görə də, biz PostgreSQL ilə birlikdə ilkin olaraq maksimum funksionallığa malik olan bir həll axtarmalı və sistemi təkmilləşdirməli olduq.
Biz 3 daxili "hackathon" keçirdik - əllidən çox inkişafa baxdıq, sınaqdan keçirdik, fərziyyələrimizlə bağlı dəyişikliklər etdik və yenidən yoxladıq. Mövcud variantları təhlil etdikdən sonra Commvault-u seçdik. Bu məhsul artıq "qutudan kənarda" ən sadə PostgreSQL klaster quraşdırması ilə işləyə bilərdi və onun açıq arxitekturası uğurlu təkmilləşdirmə və inteqrasiya üçün ümid yaratdı (bu gerçəkləşdi). Commvault həmçinin PostgreSQL qeydlərinin ehtiyat nüsxəsini çıxara bilər. Məsələn, PostgreSQL hissəsindəki Veritas NetBackup yalnız tam ehtiyat nüsxələri edə bilər.
Memarlıq haqqında daha çox. 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 güzgülüdür, bir konsol vasitəsilə idarə olunur və HA nöqteyi-nəzərindən müəssisənin bütün tələblərinə cavab verir.
Biz həmçinin hər bir məlumat mərkəzində iki fiziki media serverini işə saldıq, onlara Fiber Kanal vasitəsilə SAN vasitəsilə xüsusi ehtiyat nüsxələri üçün ayrılmış disk massivlərini və lent kitabxanalarını birləşdirdik. Genişləndirilmiş təkmilləşdirmə verilənlər bazaları media serverlərinin nasazlıqlara dözümlülüyünü təmin etdi və hər bir serverin hər bir CSV-yə qoşulması hər hansı komponentin nasazlığı zamanı fasiləsiz işləmə imkanını təmin etdi. Sistemin arxitekturası məlumat mərkəzlərindən biri uğursuz olsa belə, ehtiyat nüsxələrin davam etdirilməsinə imkan verir.
Patroni hər klaster üçün İlkin qovşaq təyin edir. Məlumat mərkəzində istənilən pulsuz node ola bilər - ancaq əsasda. Ehtiyatda 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əsi üçün sistemi (həllin açıq arxitekturası sayəsində) Postgres ilə inteqrasiya etdik. Bunun üçün Commvault idarəetmə serverinə Primary node-un cari yerini bildirən skript yaradıldı.
Ümumiyyətlə, proses belə görünür:
Patroni Primary seçir → Keepalived IP klasterini qaldırır və skripti işə salır → klasterin seçilmiş qovşağındakı Commvault agenti bu İlkin → Commvault-un psevdo-müştəri daxilində ehtiyat nüsxəni avtomatik olaraq yenidən konfiqurasiya etməsi barədə bildiriş alır.
Bu yanaşmanın üstünlüyü ondan ibarətdir ki, həll nə logların ardıcıllığına, nə düzgünlüyünə, nə də Postgres instansiyasının bərpasına təsir etmir. O, həmçinin asanlıqla miqyaslanır, çünki Commvault İlkin və İkincil qovşaqları üçün düzəltməyə artıq ehtiyac yoxdur. Sistemin Primary-nin harada olduğunu başa düşməsi kifayətdir və qovşaqların sayı demək olar ki, istənilən dəyərə qədər artırıla bilər.
Həll ideal olduğunu iddia etmir və öz nüanslarına malikdir. Commvault fərdi verilənlər bazalarını deyil, yalnız bütöv bir nümunənin ehtiyat nüsxəsini çıxara bilər. Buna görə də hər bir verilənlər bazası üçün ayrıca instansiya yaradılmışdı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 klasteridir. 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ı bir nümunə kimi ehtiyat nüsxəsini çıxarır.
Hər bir psevdo-müştəri daxilində klasterin aktiv nodu göstərilir. Commvault üçün inteqrasiya həllimiz məhz bunu müəyyən edir. Onun işləmə prinsipi olduqca sadədir: əgər klaster IP node üzərində yüksəlirsə, skript Commvault agent binarında "aktiv node" parametrini təyin edir - əslində skript yaddaşın sağ hissəsinə "1" qoyur. Agent bu məlumatları CommServe-ə göndərir və Commvault istədiyiniz qovşaqdan ehtiyat nüsxəsini çıxarır. Bundan əlavə, konfiqurasiyanın düzgünlüyü skript səviyyəsində yoxlanılır, ehtiyat nüsxəyə başladıqda səhvlərdən qaçınmağa kömək edir.
Eyni zamanda, böyük verilənlər bazaları RPO və ehtiyat pəncərəsinin tələblərinə cavab verən bir neçə axınlarda bloklar üzrə ehtiyat nüsxələnir. Sistemdəki yük əhəmiyyətsizdir: Tam nüsxələr o qədər də tez-tez baş vermir, digər günlərdə yalnız loglar yığılır və yükün az olduğu dövrlərdə.
Yeri gəlmişkən, PostgreSQL arxivləşdirilmiş qeydlərinin ehtiyat nüsxəsini çıxarmaq üçün ayrıca siyasətlər tətbiq etdik - onlar fərqli qaydalara uyğun olaraq saxlanılır, fərqli cədvələ uyğun surətdə kopyalanır və təkmilləşdirmə onlar üçün aktiv deyil, çünki bu qeydlər unikal məlumatları daşıyır.
Bütün İT infrastrukturunun ardıcıllığını təmin etmək üçün klaster qovşaqlarının hər birində 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. Məlumatların bu hissəsinin də öz siyasəti və öz saxlama müddəti var.
Hazırda RMS məhsuldar xidmətlərə təsir göstərmir, lakin vəziyyət dəyişərsə, Commvault-da yükü məhdudlaşdıran sistemi işə salmaq mümkün olacaq.
yaxşıdır? Yaxşı!
Beləliklə, biz müəssisə zənglərinin bütün tələblərinə cavab verən PostgreSQL klaster quraşdırması üçün təkcə işlək deyil, həm də tam avtomatlaşdırılmış ehtiyat nüsxəsini əldə etdik.
1 saat və 2 saatda RPO və RTO parametrləri bir marja ilə üst-üstə düşür, yəni sistem saxlanılan məlumatların həcminin əhəmiyyətli dərəcədə artması ilə belə onlara uyğun olacaq. Bir çox şübhələrin əksinə olaraq, PostgreSQL və müəssisə mühiti olduqca uyğun olduğu ortaya çıxdı. İndi biz öz təcrübəmizdən bilirik ki, belə DBMS-nin ehtiyat nüsxəsi müxtəlif konfiqurasiyalarda mümkündür.
Təbii ki, bu yolda biz 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 sıra səhvləri düzəltməli olduq. Ancaq indi yanaşma artıq sınaqdan keçirilib və müəssisənin sərt mühitində mülkiyyət DBMS əvəzinə Açıq Mənbə tətbiq etmək üçün istifadə edilə bilər.
Korporativ mühitdə PostgreSQL ilə işləməyə cəhd etmisiniz?
Müəlliflər:
Oleq Lavrenov, Jet Infosystems, Məlumat Saxlama Sistemlərinin Dizayn Mühəndisi
Dmitri Erykin, Jet Infosystems Computing Systems şirkətinin layihə mühəndisi
Mənbə: www.habr.com