Как да вместим „безплатния“ PostgreSQL в сурова корпоративна среда

Много хора са запознати с PostgreSQL DBMS и тя се е доказала в малки инсталации. Тенденцията към отворен код обаче става все по-ясна, дори когато става въпрос за големи компании и корпоративни изисквания. В тази статия ще ви кажем как да интегрирате Postgres в корпоративна среда и ще споделим нашия опит в създаването на система за архивиране (BSS) за тази база данни, като използваме системата за архивиране Commvault като пример.

PostgreSQL вече е доказал своята стойност - СУБД работи страхотно, използва се от модни дигитални бизнеси като Alibaba и TripAdvisor, а липсата на лицензионни такси го прави примамлива алтернатива на такива чудовища като MS SQL или Oracle DB. Но веднага щом започнем да мислим за PostgreSQL в Enterprise пейзажа, веднага се натъкваме на строги изисквания: „Ами толерантността към грешки в конфигурацията? устойчивост на бедствия? къде е комплексният мониторинг? Какво ще кажете за автоматизираните архиви? Какво ще кажете за използването на лентови библиотеки както директно, така и във вторично хранилище?“


От една страна, PostgreSQL няма вградени инструменти за архивиране, като СУБД за „възрастни“, като RMAN в Oracle DB или SAP Database Backup. От друга страна, доставчиците на корпоративни системи за архивиране (Veeam, Veritas, Commvault), въпреки че поддържат PostgreSQL, всъщност работят само с определена (обикновено самостоятелна) конфигурация и с набор от различни ограничения.

Системите за архивиране, специално проектирани за PostgreSQL, като Barman, Wal-g, pg_probackup, са изключително популярни в малки инсталации на СУБД PostgreSQL или където не са необходими тежки архиви на други елементи от ИТ пейзажа. Например, освен PostgreSQL, инфраструктурата може да включва физически и виртуални сървъри, OpenShift, Oracle, MariaDB, Cassandra и др. Препоръчително е да архивирате всичко това с общ инструмент. Инсталирането на отделно решение изключително за PostgreSQL е лоша идея: данните ще бъдат копирани някъде на диск и след това трябва да бъдат премахнати на лента. Това двойно архивиране увеличава времето за архивиране, а също и, което е по-критично, времето за възстановяване.

В корпоративно решение архивирането на инсталацията се извършва с определен брой възли в специален клъстер. В същото време, например, Commvault може да работи само с клъстер с два възела, в който Primary и Secondary са строго присвоени на определени възли. И има смисъл да архивирате само от Primary, защото архивирането от Secondary има своите ограничения. Поради особеностите на СУБД, дъмп не се създава на вторичен и следователно остава само възможността за архивиране на файл.

За да се намали рискът от прекъсване, когато се създава система, устойчива на грешки, се създава „жива“ конфигурация на клъстер и Primary може постепенно да мигрира между различни сървъри. Например самият софтуер Patroni стартира Primary на произволно избран клъстерен възел. IBS няма начин да проследи това от кутията и ако конфигурацията се промени, процесите се прекъсват. Тоест въвеждането на външен контрол пречи на ISR да работи ефективно, тъй като контролният сървър просто не разбира откъде и какви данни трябва да бъдат копирани.

Друг проблем е внедряването на архивиране в Postgres. Възможно е чрез dump и работи на малки бази данни. Но в големите бази данни дъмпът отнема много време, изисква много ресурси и може да доведе до повреда на екземпляра на базата данни.

Архивирането на файлове коригира ситуацията, но при големи бази данни е бавно, защото работи в еднонишков режим. Освен това продавачите имат редица допълнителни ограничения. Или не можете да използвате архивиране на файл и дъмп едновременно, или дедупликацията не се поддържа. Има много проблеми и най-често е по-лесно да изберете скъпа, но доказана СУБД вместо Postgres.

Няма къде да се отстъпи! Московските разработчици изостават!

Наскоро обаче нашият екип се изправи пред трудно предизвикателство: в проекта за създаване на AIS OSAGO 2.0, където създадохме ИТ инфраструктурата, разработчиците избраха PostgreSQL за новата система.

За големите разработчици на софтуер е много по-лесно да използват „модерни“ решения с отворен код. Facebook разполага с достатъчно специалисти, които да поддържат работата на тази СУБД. А в случая с RSA всички задачи на „втория ден“ паднаха на нашите рамене. От нас се изискваше да осигурим устойчивост на грешки, да съберем клъстер и, разбира се, да настроим резервно копие. Логиката на действие беше следната:

• Научете SRK да прави резервни копия от основния възел на клъстера. За да направи това, SRK трябва да го намери - което означава, че е необходима интеграция с едно или друго решение за управление на PostgreSQL клъстер. В случая на RSA за това е използван софтуер Patroni.
• Решете вида на архивирането въз основа на обема на данните и изискванията за възстановяване. Например, когато трябва да възстановите детайлно страници, използвайте дъмп, а ако базите данни са големи и не е необходимо детайлно възстановяване, работете на ниво файл.
• Прикрепете възможността за блоково архивиране към решението, за да създадете резервно копие в многонишков режим.

В същото време ние първоначално се заехме да създадем ефективна и проста система без чудовищна комбинация от допълнителни компоненти. Колкото по-малко са патериците, толкова по-малко е натоварването на персонала и по-малък е рискът от неуспех на IBS. Веднага изключихме подходи, които използват Veeam и RMAN, тъй като набор от две решения вече загатва за ненадеждността на системата.

Малко магия за предприятието

И така, трябваше да гарантираме надеждно архивиране за 10 клъстера от по 3 възела всеки, със същата инфраструктура, отразена в резервния център за данни. Центровете за данни по отношение на PostgreSQL работят на активно-пасивен принцип. Общият размер на базата данни беше 50 TB. Всяка система за контрол на корпоративно ниво може лесно да се справи с това. Но предупреждението е, че първоначално Postgres няма представа за пълна и дълбока съвместимост със системите за архивиране. Затова трябваше да потърсим решение, което първоначално имаше максимална функционалност във връзка с PostgreSQL, и да прецизираме системата.

Проведохме 3 вътрешни „хакатона“ - разгледахме повече от петдесет разработки, тествахме ги, направихме промени във връзка с нашите хипотези и ги тествахме отново. След като прегледахме наличните опции, избрахме Commvault. Извън кутията този продукт можеше да работи с най-простата инсталация на PostgreSQL клъстер, а отворената му архитектура породи надежди (които бяха оправдани) за успешно развитие и интеграция. Commvault може също да архивира регистрационните файлове на PostgreSQL. Например Veritas NetBackup по отношение на PostgreSQL може да прави само пълни архиви.

Повече за архитектурата. Сървърите за управление на Commvault бяха инсталирани във всеки от двата центъра за данни в конфигурация CommServ HA. Системата е огледална, управлява се през една конзола и от гледна точка на HA отговаря на всички корпоративни изисквания.

Пуснахме и два физически медийни сървъра във всеки център за данни, към които свързахме дискови масиви и лентови библиотеки, предназначени специално за архивиране чрез SAN чрез Fibre Channel. Разширените бази данни за дедупликация гарантират устойчивост на грешки на медийните сървъри и свързването на всеки сървър към всеки CSV позволява непрекъсната работа, ако някой компонент се повреди. Архитектурата на системата позволява архивирането да продължи дори ако един от центровете за данни падне.

Patroni дефинира първичен възел за всеки клъстер. Това може да бъде всеки свободен възел в центъра за данни - но само повечето. В резервното копие всички възли са вторични.

За да може Commvault да разбере кой клъстерен възел е първичен, ние интегрирахме системата (благодарение на отворената архитектура на решението) с Postgres. За тази цел е създаден скрипт, който отчита текущото местоположение на основния възел на сървъра за управление на Commvault.

Като цяло процесът изглежда така:

Patroni избира Основен → Keepalived взема IP клъстера и изпълнява скрипта → Commvault агентът на избрания клъстерен възел получава известие, че това е Основният → Commvault автоматично преконфигурира резервното копие в рамките на псевдо-клиента.

Предимството на този подход е, че решението не засяга последователността, коректността на регистрационните файлове или възстановяването на екземпляра на Postgres. Освен това е лесно мащабируем, тъй като вече не е необходимо да се коригират основните и вторичните възли на Commvault. Достатъчно е системата да разбере къде е Primary и броят на възлите може да бъде увеличен до почти всяка стойност.

Решението не претендира за идеалност и има своите нюанси. Commvault може да архивира само целия екземпляр, а не отделни бази данни. Следователно за всяка база данни беше създаден отделен екземпляр. Реалните клиенти се комбинират във виртуални псевдоклиенти. Всеки псевдо-клиент на Commvault е UNIX клъстер. Тези клъстерни възли, на които е инсталиран агентът Commvault за Postgres, се добавят към него. В резултат на това всички виртуални възли на псевдо-клиента се архивират като един екземпляр.

Във всеки псевдо-клиент се посочва активният възел на клъстера. Това дефинира нашето интеграционно решение за Commvault. Принципът на неговата работа е доста прост: ако IP адрес на клъстер е повдигнат на възел, скриптът задава параметъра „активен възел“ в двоичния файл на агента на Commvault - всъщност скриптът задава „1“ в необходимата част от паметта . Агентът предава тези данни на CommServe и Commvault прави резервно копие от желания възел. В допълнение, коректността на конфигурацията се проверява на ниво скрипт, което помага да се избегнат грешки при стартиране на архивиране.

В същото време големите бази данни се архивират на блокове в множество нишки, отговаряйки на изискванията за RPO и прозорец за архивиране. Натоварването на системата е незначително: пълните копия не се появяват толкова често, в други дни се събират само регистрационни файлове и в периоди на ниско натоварване.

Между другото, ние сме приложили отделни политики за архивиране на архивни журнали на PostgreSQL - те се съхраняват по различни правила, копират се по различен график и дедупликацията не е активирана за тях, тъй като тези журнали съдържат уникални данни.

За да се осигури съгласуваност в цялата ИТ инфраструктура, отделни файлови клиенти Commvault са инсталирани на всеки от възлите на клъстера. Те изключват файловете на Postgres от резервни копия и са предназначени само за архивиране на ОС и приложения. Тази част от данните също има собствена политика и период на съхранение.

В момента IBS не засяга услугите за производителност, но ако ситуацията се промени, Commvault може да активира ограничаване на натоварването.

Добро е? Добре!

И така, ние получихме не само работещ, но и напълно автоматизиран бекъп за инсталация на PostgreSQL клъстер, който отговаря на всички изисквания за корпоративни разговори.

Параметрите RPO и RTO от 1 час и 2 часа са покрити с резерв, което означава, че системата ще ги спазва дори при значително увеличение на обема на съхраняваните данни. Противно на много съмнения, PostgreSQL и корпоративната среда се оказаха доста съвместими. И сега знаем от нашия собствен опит, че архивирането за такива СУБД е възможно в голямо разнообразие от конфигурации.

Разбира се, по този път трябваше да износим седем чифта железни ботуши, да преодолеем редица трудности, да стъпим на няколко гребла и да коригираме редица грешки. Но сега подходът вече е тестван и може да се използва за внедряване на отворен код вместо собствена СУБД в тежки корпоративни условия.

Опитвали ли сте да работите с PostgreSQL в корпоративна среда?

Автори:

Олег Лавренов, инженер-конструктор на системи за съхранение на данни, Jet Infosystems

Дмитрий Ерикин, инженер-конструктор на компютърни системи в Jet Infosystems

Източник: www.habr.com