Многу луѓе се запознаени со 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 или каде што не се потребни тешки резервни копии на други елементи од ИТ пејзажот. На пример, покрај PostgreSQL, инфраструктурата може да вклучува физички и виртуелни сервери, OpenShift, Oracle, MariaDB, Cassandra итн. Препорачливо е да направите резервна копија на сето ова со заедничка алатка. Инсталирањето на посебно решение исклучиво за PostgreSQL е лоша идеја: податоците ќе бидат копирани некаде на дискот, а потоа треба да се отстранат на лента. Оваа двојна резервна копија го зголемува времето на резервна копија, а исто така, покритично, времето за обновување.
Во претпријатието решение, резервната копија на инсталацијата се јавува со одреден број јазли во посветен кластер. Во исто време, на пример, Commvault може да работи само со кластер со два јазли, во кој Примарниот и Секундарниот се строго доделени на одредени јазли. И има смисла само да се направи резервна копија од Примарна, бидејќи резервната копија од секундарно има свои ограничувања. Поради особеностите на DBMS, на Secondary не се создава депонија и затоа останува само можноста за резервна копија на датотеката.
За да се намали ризикот од прекини, кога се создава систем толерантен за грешки, се создава конфигурација на кластерот „во живо“ и Примарниот може постепено да мигрира помеѓу различни сервери. На пример, софтверот Патрони самиот ја лансира Примарната на случајно избраниот јазол на кластерот. IBS нема начин да го следи ова надвор од кутијата, и ако се промени конфигурацијата, процесите се прекинуваат. Односно, воведувањето надворешна контрола го спречува ISR да работи ефективно, бидејќи контролниот сервер едноставно не разбира од каде и од кои податоци треба да се копира.
Друг проблем е имплементацијата на резервната копија во Postgres. Тоа е можно преку депонија, а работи на мали бази на податоци. Но, во големите бази на податоци, депонијата трае долго време, бара многу ресурси и може да доведе до неуспех на примерот на базата на податоци.
Резервната копија на датотеката ја коригира ситуацијата, но на големи бази на податоци е бавна бидејќи работи во режим со една нишка. Покрај тоа, продавачите имаат голем број дополнителни ограничувања. Или не можете да користите резервни копии од датотеки и да исфрлате истовремено, или дедупликацијата не е поддржана. Има многу проблеми, а најчесто е полесно да се избере скап, но докажан DBMS наместо Postgres.
Нема каде да се повлечеш! Московските програмери заостануваат!
Меѓутоа, неодамна нашиот тим се соочи со тежок предизвик: во проектот за создавање на AIS OSAGO 2.0, каде што ја создадовме ИТ инфраструктурата, програмерите го избраа PostgreSQL за новиот систем.
Многу е полесно за големите развивачи на софтвер да користат „трендовски“ решенија со отворен код. Facebook има доволно специјалисти за поддршка на работата на овој DBMS. И во случајот со РСА, сите задачи од „вториот ден“ паднаа на нашите раменици. Од нас се бараше да обезбедиме толеранција на грешки, да составиме кластер и, се разбира, да поставиме резервна копија. Логиката на дејствување беше следнава:
- Научете го SRK да прави резервни копии од Примарниот јазол на кластерот. За да го направите ова, SRK мора да го пронајде - што значи дека е потребна интеграција со едно или друго решение за управување со кластерот PostgreSQL. Во случајот со RSA, софтверот Patroni беше користен за ова.
- Одлучете за типот на резервна копија врз основа на обемот на податоци и барањата за обновување. На пример, кога треба да ги обновувате страниците грануларно, користете депонија и ако базите на податоци се големи и не е потребна грануларна реставрација, работете на ниво на датотека.
- Прикачете ја можноста за блокирање резервна копија на решението за да креирате резервна копија во режим со повеќе нишки.
Во исто време, првично се зафативме да создадеме ефективен и едноставен систем без монструозно прицврстување на дополнителни компоненти. Колку помалку патерици, толку помал обем на работа на персоналот и помал ризик од неуспех на IBS. Веднаш ги исклучивме пристапите што користеа Veeam и RMAN, бидејќи збир од две решенија веќе укажува на несигурноста на системот.
Малку магија за претпријатие
Значи, требаше да гарантираме сигурна резервна копија за 10 кластери од по 3 јазли, со истата инфраструктура пресликана во резервниот центар за податоци. Центрите за податоци во однос на PostgreSQL работат на принципот активно-пасивно. Вкупната големина на базата на податоци беше 50 ТБ. Секој систем за контрола на корпоративно ниво може лесно да се справи со ова. Но, предупредувањето е што првично Postgres нема поим за целосна и длабока компатибилност со резервните системи. Затоа, моравме да бараме решение кое првично има максимална функционалност во врска со PostgreSQL и да го усовршиме системот.
Одржавме 3 внатрешни „хакатони“ - погледнавме повеќе од педесет случувања, ги тестиравме, направивме промени во врска со нашите хипотези и повторно ги тестиравме. Откако ги разгледавме достапните опции, избравме Commvault. Надвор од кутијата, овој производ може да работи со наједноставната инсталација на кластерот PostgreSQL, а неговата отворена архитектура поттикна надежи (кои беа оправдани) за успешен развој и интеграција. Commvault исто така може да направи резервна копија на дневниците на PostgreSQL. На пример, Veritas NetBackup во однос на PostgreSQL може да прави само целосни резервни копии.
Повеќе за архитектурата. Серверите за управување со Commvault беа инсталирани во секој од двата центри за податоци во конфигурација на CommServ HA. Системот е пресликан, управуван преку една конзола и, од гледна точка на HA, ги исполнува сите барања на претпријатието.
Исто така, лансиравме два физички медиумски сервери во секој центар за податоци, на кои поврзавме низи на дискови и библиотеки со касети наменети специјално за резервни копии преку SAN преку канал со оптички влакна. Проширените бази на податоци за дедупликација обезбедија толеранција на грешки на медиумските сервери, а поврзувањето на секој сервер со секој CSV овозможи континуирано работење доколку некоја компонента не успее. Архитектурата на системот овозможува резервната копија да продолжи дури и ако падне еден од центрите за податоци.
Патрони дефинира Примарен јазол за секој кластер. Може да биде кој било слободен јазол во центарот за податоци - но само најмногу. Во резервната копија, сите јазли се секундарни.
За да може Commvault да разбере кој јазол на кластерот е Примарен, го интегриравме системот (благодарение на отворената архитектура на решението) со Postgres. За таа цел, создадена е скрипта која ја известува моменталната локација на Примарниот јазол на серверот за управување со Commvault.
Во принцип, процесот изгледа вака:
Патрони избира Примарно → Keepalived го зема IP-кластерот и ја извршува скриптата → агентот Commvault на избраниот јазол на кластерот добива известување дека ова е Примарно → Commvault автоматски ја реконфигурира резервната копија во псевдоклиентот.
Предноста на овој пристап е што решението не влијае на конзистентноста, исправноста на дневниците или обновувањето на примерот на Postgres. Исто така, лесно може да се скалира, бидејќи повеќе не е неопходно да се поправаат примарните и секундарните јазли Commvault. Доволно е системот да разбере каде е Примарното, а бројот на јазли може да се зголеми на речиси секоја вредност.
Решението не се преправа дека е идеално и има свои нијанси. Commvault може да направи резервна копија само на целата инстанца, а не на поединечни бази на податоци. Затоа, за секоја база на податоци беше креиран посебен пример. Вистинските клиенти се комбинираат во виртуелни псевдоклиенти. Секој псевдоклиент на Commvault е кластер на UNIX. Кон него се додаваат оние кластерски јазли на кои е инсталиран Commvault агентот за Postgres. Како резултат на тоа, сите виртуелни јазли на псевдо-клиентот се поддржани како еден пример.
Во секој псевдо-клиент, се означува активниот јазол на кластерот. Ова е она што го дефинира нашето интеграциско решение за Commvault. Принципот на неговото функционирање е прилично едноставен: ако IP на кластерот се подигне на јазол, скриптата го поставува параметарот „активен јазол“ во бинарниот агент Commvault - всушност, скриптата поставува „1“ во потребниот дел од меморијата . Агентот ги пренесува овие податоци до CommServe, а Commvault прави резервна копија од саканиот јазол. Покрај тоа, исправноста на конфигурацијата се проверува на ниво на скрипта, помагајќи да се избегнат грешки при стартување на резервна копија.
Во исто време, големите бази на податоци се поддржани во блокови низ повеќе нишки, исполнувајќи ги барањата за RPO и резервниот прозорец. Оптоварувањето на системот е незначително: целосните копии не се појавуваат толку често, во другите денови се собираат само дневници и за време на периоди на мало оптоварување.
Патем, применивме посебни политики за правење резервни копии на дневниците на архивата на PostgreSQL - тие се складираат според различни правила, се копираат според различен распоред и за нив не е овозможено дедупликација, бидејќи овие дневници содржат уникатни податоци.
За да се обезбеди конзистентност низ целата ИТ инфраструктура, одделни клиенти на датотеки Commvault се инсталирани на секој од јазлите на кластерот. Тие ги исклучуваат датотеките на Postgres од резервните копии и се наменети само за резервни копии на ОС и апликации. Овој дел од податоците има и своја политика и период на складирање.
Во моментов, IBS не влијае на услугите за продуктивност, но ако ситуацијата се промени, Commvault може да овозможи ограничување на оптоварувањето.
Дали е добро? Добро!
Значи, добивме не само функционална, туку и целосно автоматизирана резервна копија за инсталација на кластерот PostgreSQL и таа ги исполнува сите барања за повици на претпријатија.
Параметрите RPO и RTO од 1 час и 2 часа се покриени со маржа, што значи дека системот ќе се усогласи со нив дури и со значително зголемување на обемот на складирани податоци. Наспроти многу сомнежи, PostgreSQL и претпријатието опкружување се покажаа како доста компатибилни. И сега знаеме од нашето сопствено искуство дека резервната копија за такви DBMS е можна во широк спектар на конфигурации.
Секако, по оваа патека моравме да истрошиме седум пара железни чизми, да надминеме голем број тешкотии, да нагазиме неколку гребла и да исправиме голем број грешки. Но, сега пристапот е веќе тестиран и може да се користи за имплементирање на софтвер со отворен код наместо заштитени DBMS во тешки услови на претпријатието.
Дали сте се обиделе да работите со PostgreSQL во корпоративно опкружување?
Авторите:
Олег Лавренов, дизајнерски инженер за системи за складирање податоци, Jet Infosystems
Дмитриј Ерикин, дизајнерски инженер за компјутерски системи во Jet Infosystems
Извор: www.habr.com