PostgreSQL DBMS-ийг олон хүмүүс мэддэг бөгөөд энэ нь жижиг суулгацуудад өөрийгөө нотолсон. Гэсэн хэдий ч томоохон компаниуд болон аж ахуйн нэгжийн шаардлагуудын талаар ярихад ч Нээлттэй эхийн чиг хандлага улам бүр тодорхой болж байна. Энэ нийтлэлд бид Postgres-ийг корпорацийн орчинд хэрхэн нэгтгэж, Commvault нөөцлөлтийн системийг ашиглан энэхүү мэдээллийн санд нөөцлөх систем (BSS) бий болгосон туршлагаа хуваалцах болно.
PostgreSQL нь өөрийн үнэ цэнийг аль хэдийн нотолсон - DBMS нь маш сайн ажилладаг, үүнийг Алибаба, TripAdvisor зэрэг моод дижитал бизнесүүд ашигладаг бөгөөд лицензийн хураамжгүй байгаа нь MS SQL эсвэл Oracle DB зэрэг мангасуудын сэтгэл татам хувилбар болгож байна. Гэхдээ бид Enterprise ландшафт дээр PostgreSQL-ийн талаар бодож эхэлмэгц бид тэр даруй хатуу шаардлага тавьдаг: "Тохиргооны алдааг тэсвэрлэх талаар яах вэ? гамшигт тэсвэртэй? иж бүрэн хяналт хаана байна? Автомат нөөцлөлтийн талаар юу хэлэх вэ? соронзон хальсны сангуудыг шууд болон хоёрдогч санах ойд ашиглах талаар юу хэлэх вэ?
Нэг талаас, PostgreSQL-д Oracle DB дахь RMAN эсвэл SAP Database Backup гэх мэт "насанд хүрэгчдийн" DBMS гэх мэт нөөцлөх хэрэгслүүд байдаггүй. Нөгөөтэйгүүр, корпорацийн нөөцлөх системийн нийлүүлэгчид (Veeam, Veritas, Commvault) хэдийгээр PostgreSQL-ийг дэмждэг ч үнэн хэрэгтээ тэд зөвхөн тодорхой (ихэвчлэн бие даасан) тохиргоо, янз бүрийн хязгаарлалттай ажилладаг.
Barman, Wal-g, pg_probackup зэрэг PostgreSQL-д тусгайлан зориулсан нөөцлөлтийн системүүд нь PostgreSQL DBMS-ийн жижиг суулгацуудад эсвэл мэдээллийн технологийн ландшафтын бусад элементүүдийн хүнд нөөцлөлт шаардлагагүй тохиолдолд маш их алдартай байдаг. Жишээлбэл, PostgreSQL-ээс гадна дэд бүтцэд физик болон виртуал серверүүд, OpenShift, Oracle, MariaDB, Cassandra гэх мэт багтаж болно. Энэ бүгдийг нийтлэг хэрэгслээр нөөцлөхийг зөвлөж байна. Зөвхөн PostgreSQL-д зориулсан тусдаа шийдлийг суулгах нь муу санаа юм: өгөгдлийг хаа нэгтээ диск рүү хуулж, дараа нь соронзон хальс руу буулгах шаардлагатай. Энэхүү давхар нөөцлөлт нь нөөцлөх хугацааг уртасгаж, мөн хамгийн чухал нь сэргээх хугацааг нэмэгдүүлдэг.
Байгууллагын шийдэлд суулгацын нөөцлөлт нь тусгайлсан кластерт тодорхой тооны зангилаагаар хийгддэг. Үүний зэрэгцээ, жишээлбэл, Commvault нь зөвхөн хоёр зангилаатай кластертай ажиллах боломжтой бөгөөд үүнд Анхан болон Хоёрдогч нь тодорхой зангилаанууд дээр хатуу хуваарилагдсан байдаг. Хоёрдогч хувилбараас нөөцлөх нь хязгаарлалттай тул зөвхөн Үндсэн хэсгээс нөөцлөх нь утга учиртай. DBMS-ийн онцлогоос шалтгаалан хоёрдогч дээр дамп үүсдэггүй тул зөвхөн файлыг нөөцлөх боломж л үлддэг.
Сул зогсолтын эрсдлийг бууруулахын тулд алдааг тэсвэрлэх чадвартай системийг бий болгохдоо "амьд" кластерийн тохиргоог бий болгодог бөгөөд Үндсэн хэсэг нь өөр өөр серверүүдийн хооронд аажмаар шилжиж болно. Жишээлбэл, Patroni програм хангамж нь өөрөө санамсаргүй байдлаар сонгосон кластерийн зангилаа дээр анхдагч програмыг ажиллуулдаг. IBS үүнийг хайрцагнаас нь хянах ямар ч боломжгүй бөгөөд хэрэв тохиргоо өөрчлөгдвөл процессууд эвдэрнэ. Өөрөөр хэлбэл, гадны хяналтыг нэвтрүүлэх нь ISR-ийг үр дүнтэй ажиллуулахаас сэргийлдэг, учир нь хяналтын сервер нь хаанаас, ямар өгөгдлийг хуулах шаардлагатайг ойлгодоггүй.
Өөр нэг асуудал бол Postgres дахь нөөцлөлтийг хэрэгжүүлэх явдал юм. Энэ нь dump-ээр боломжтой бөгөөд жижиг мэдээллийн сан дээр ажилладаг. Гэхдээ том мэдээллийн санд хог хаягдал нь удаан хугацаа шаардагддаг, маш их нөөц шаарддаг бөгөөд өгөгдлийн сангийн жишээний бүтэлгүйтэлд хүргэж болзошгүй юм.
Файлын нөөцлөлт нь нөхцөл байдлыг засдаг боловч том өгөгдлийн сан дээр энэ нь нэг урсгалтай горимд ажилладаг тул удаан байдаг. Үүнээс гадна борлуулагчид хэд хэдэн нэмэлт хязгаарлалттай байдаг. Та файл болон нөөцлөлтийг нэгэн зэрэг ашиглах боломжгүй, эсвэл хуулбарлахыг дэмждэггүй. Олон асуудал тулгардаг бөгөөд Postgres-ийн оронд үнэтэй боловч батлагдсан DBMS сонгох нь илүү хялбар байдаг.
Ухрах газар байхгүй! Москвагийн хөгжүүлэгчид хоцорч байна!
Гэсэн хэдий ч саяхан манай баг хүнд сорилттой тулгарсан: бид мэдээллийн технологийн дэд бүтцийг бий болгосон AIS OSAGO 2.0-ийг бий болгох төсөлд хөгжүүлэгчид шинэ системд PostgreSQL-ийг сонгосон.
Томоохон програм хангамж хөгжүүлэгчдэд нээлттэй эхийн "трэнд" шийдлүүдийг ашиглах нь илүү хялбар байдаг. Facebook-д энэхүү DBMS-ийн үйл ажиллагааг дэмжих хангалттай мэргэжилтнүүд бий. RSA-ийн хувьд "хоёр дахь өдрийн" бүх ажил бидний мөрөн дээр унасан. Бид алдааг тэсвэрлэх чадварыг баталгаажуулж, кластер угсарч, мэдээж нөөцлөлтийг бий болгох шаардлагатай байсан. Үйлдлийн логик нь дараах байдалтай байв.
- Кластерын анхдагч зангилаанаас нөөцлөлт хийхийг SRK-д заа. Үүнийг хийхийн тулд SRK үүнийг олох ёстой - энэ нь нэг эсвэл өөр PostgreSQL кластерын удирдлагын шийдэлтэй нэгтгэх шаардлагатай гэсэн үг юм. RSA-ийн хувьд Patroni програм хангамжийг үүнд ашигласан.
- Мэдээллийн хэмжээ болон сэргээх шаардлагад үндэслэн нөөцлөлтийн төрлийг шийдээрэй. Жишээлбэл, та хуудсуудыг хэсэгчлэн сэргээх шаардлагатай бол дамп ашиглах, хэрэв мэдээллийн сан нь том бөгөөд бөөнөөр нь сэргээх шаардлагагүй бол файлын түвшинд ажиллана уу.
- Олон урсгалтай горимд нөөц хуулбар үүсгэхийн тулд блок нөөцлөлт хийх боломжийг хавсаргана уу.
Үүний зэрэгцээ бид эхлээд нэмэлт бүрэлдэхүүн хэсгүүдийн аймшигт бэхэлгээгүйгээр үр дүнтэй, энгийн системийг бий болгохыг зорьсон. Суга таяг бага байх тусам ажилтнуудын ачаалал багасч, IBS-ийн бүтэлгүйтлийн эрсдэл бага байдаг. Бид Veeam болон RMAN-ийг ашигласан хандлагыг нэн даруй хассан, учир нь хоёр шийдлийн багц нь системийн найдваргүй байдлыг илтгэж байна.
Аж ахуйн нэгжийн хувьд бага зэрэг ид шид
Тиймээс бид нөөц мэдээллийн төвд ижил дэд бүтэцтэй тус бүр 10 зангилаа бүхий 3 кластерын найдвартай нөөцлөлтийг баталгаажуулах шаардлагатай болсон. PostgreSQL-ийн хувьд дата төвүүд идэвхтэй-идэвхгүй зарчмаар ажилладаг. Өгөгдлийн сангийн нийт хэмжээ 50 TB байсан. Аливаа корпорацийн түвшний хяналтын систем үүнийг амархан даван туулж чадна. Гэхдээ анхааруулга нь эхлээд Postgres нь нөөц системтэй бүрэн, гүнзгий нийцтэй байх талаар ойлголтгүй байдаг. Тиймээс бид PostgreSQL-тэй хамт хамгийн их ажиллагаатай шийдлийг хайж, системийг боловсронгуй болгох шаардлагатай болсон.
Бид 3 дотоод "хакатон" зохион байгуулсан - бид тавь гаруй хөгжүүлэлтийг үзэж, туршиж, таамаглалтайгаа уялдуулан өөрчлөлт хийж, дахин туршиж үзсэн. Боломжтой сонголтуудыг шалгасны дараа бид Commvault-ийг сонгосон. Энэхүү бүтээгдэхүүн нь хамгийн энгийн PostgreSQL кластер суулгацтай ажиллах боломжтой бөгөөд түүний нээлттэй архитектур нь амжилттай хөгжүүлэлт, интеграцчлалын найдварыг (үндэслэлээ) төрүүлсэн. Commvault мөн PostgreSQL бүртгэлийг нөөцлөх боломжтой. Жишээлбэл, PostgreSQL-ийн хувьд Veritas NetBackup нь зөвхөн бүрэн нөөцлөлт хийх боломжтой.
Архитектурын талаар дэлгэрэнгүй. CommServ HA тохиргооны хоёр өгөгдлийн төв тус бүрт Commvault удирдлагын серверүүдийг суулгасан. Систем нь толин тусгалтай, нэг консолоор удирддаг бөгөөд HA үүднээс авч үзвэл аж ахуйн нэгжийн бүх шаардлагыг хангадаг.
Мөн бид мэдээллийн төв бүрт хоёр физик медиа сервер ажиллуулж, Fiber сувгаар дамжуулан SAN-аар дамжуулан нөөцлөхөд зориулагдсан дискний массив болон соронзон хальсны сангуудыг холбосон. Өргөтгөсөн давхардлын мэдээллийн сангууд нь медиа серверүүдийн алдааг тэсвэрлэх чадварыг баталгаажуулж, сервер бүрийг CSV бүртэй холбосноор аливаа бүрэлдэхүүн хэсэг амжилтгүй болсон тохиолдолд тасралтгүй ажиллагааг идэвхжүүлдэг. Системийн бүтэц нь мэдээллийн төвүүдийн аль нэг нь унасан ч нөөцлөлтийг үргэлжлүүлэх боломжийг олгодог.
Патрони нь кластер бүрийн үндсэн зангилааг тодорхойлдог. Энэ нь өгөгдлийн төвд ямар ч үнэгүй зангилаа байж болно - гэхдээ зөвхөн ихэвчлэн. Нөөцлөлтийн хувьд бүх зангилаа хоёрдогч байна.
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 болон аж ахуйн нэгжийн орчин нь нэлээд нийцтэй болсон. Ийм DBMS-ийн нөөцлөлтийг олон төрлийн тохиргоонд хийх боломжтой гэдгийг одоо бид өөрсдийн туршлагаас мэдэж байна.
Мэдээж энэ замд бид долоон хос төмөр гутлыг өмсөж, олон бэрхшээлийг даван туулж, хэд хэдэн тармуур дээр гишгэж, хэд хэдэн алдаагаа засах ёстой байв. Харин одоо энэ аргыг аль хэдийн туршиж үзсэн бөгөөд хатуу ширүүн аж ахуйн нэгжийн нөхцөлд өмчийн DBMS-ийн оронд Нээлттэй эхийг хэрэгжүүлэхэд ашиглаж болно.
Та PostgreSQL-тэй корпорацийн орчинд ажиллаж үзсэн үү?
Зохиогчид:
Олег Лавренов, Jet Infosystems компанийн өгөгдөл хадгалах системийн дизайнер
Дмитрий Эрыкин, Jet Infosystems компанийн компьютерийн системийн дизайнер
Эх сурвалж: www.habr.com