Багато хто знайомий з СУБД PostgreSQL, і вона чудово зарекомендувала себе на невеликих інсталяціях. Однак тенденція до переходу на Open Source стала все більш явною, навіть коли йдеться про великі компанії та enterprise вимоги. У цій статті ми розповімо, як вбудувати Postgres у корпоративне середовище, та поділимося досвідом створення системи резервного копіювання (СРК) для цієї бази даних на прикладі системи резервного копіювання Commvault.
PostgreSQL вже довела свою спроможність - СУБД чудово працює, її використовують модні цифрові бізнеси типу Alibaba та TripAdvisor, а відсутність ліцензійних платежів робить її спокусливою альтернативою таких монстрів як MS SQL або Oracle DB. Але як тільки ми починаємо розмірковувати про PostgreSQL в ландшафті Enterprise, відразу впираємося в жорсткі вимоги: «А як же стійкість до відмови конфігурації? катастрофостійкість? де всебічний моніторинг? а автоматизоване резервне копіювання? а використання стрічкових бібліотек як безпосередньо, так і вторинного сховища?
З одного боку, PostgreSQL не має вбудованих засобів резервного копіювання, як у «дорослих» СУБД типу RMAN у Oracle DB або SAP Database Backup. З іншого боку, постачальники корпоративних систем резервного копіювання (Veeam, Veritas, Commvault) хоч і підтримують PostgreSQL, але за фактом працюють тільки з певною (зазвичай standalone) конфігурацією та з набором різних обмежень.
Такі спеціально розроблені для PostgreSQL системи резервного копіювання, як Barman, Wal-g, pg_probackup, дуже популярні в невеликих інсталяціях СУБД PostgreSQL або там, де не потрібні важкі бекапи інших елементів ІТ-ландшафту. Наприклад, крім PostgreSQL, в інфраструктурі можуть бути фізичні та віртуальні сервери, OpenShift, Oracle, MariaDB, Cassandra тощо. Все це бажано бекапит загальним інструментом. Ставити окреме рішення виключно для PostgreSQL - невдала витівка: дані копіюватимуться кудись на диск, а потім їх потрібно прибирати на стрічку. Таке задвоєння резервного копіювання збільшує час бекапу, а також більш критично — відновлення.
У процесі рішення резервне копіювання інсталяції відбувається з деяким числом нід виділеного кластера. При цьому, наприклад, Commvault вміє працювати тільки з двонодовим кластером, у якому Primary та Secondary жорстко закріплені за певними нодами. Та й сенс бекапитися є тільки з Primary, тому що резервне копіювання з Secondary має свої обмеження. Через особливості СУБД дамп на Secondary не створюється, і тому залишається лише можливість файлового бекапу.
Щоб знизити ризики простою, при створенні системи відмови від утворюється «жива» кластерна конфігурація, і Primary може поступово мігрувати між різними серверами. Наприклад, ПЗ Patroni саме запускає Primary на рандомно обраній ноді кластера. СРК немає способу відстежувати це «з коробки», і, якщо змінюється конфігурація, процеси ламаються. Тобто впровадження зовнішнього управління заважає СРК ефективно працювати, тому що керуючий сервер просто не розуміє, звідки та які дані потрібно копіювати.
Ще одна проблема - реалізація бекапу в Postgres. Вона можлива через dump і на малих базах це працює. Але у великих БД дамп робиться довго, вимагає багато ресурсів і може призвести до збою екземпляра БД.
Файловий бекап виправляє ситуацію, але на великих базах він йде повільно, тому що працює в однопотоковому режимі. До того ж у вендорів з'являється низка додаткових обмежень. То не можна одночасно використовувати файловий та дамповий бекап, то не підтримується дедуплікація. Проблем виявляється багато, і найчастіше простіше замість Postgres вибрати дорогу, але перевірену СУБД.
Відступати нема куди! Позаду Москва розробники!
Проте нещодавно наша команда постала перед непростим викликом: у проекті створення АІС ОСАГО 2.0, де ми робили ІТ-інфраструктуру, розробники для нової системи обрали PostgreSQL.
Великим розробникам програмного забезпечення набагато простіше використовувати «модні» open-source рішення. У штаті того ж таки Facebook достатньо фахівців, які підтримують роботу цієї СУБД. А у випадку з РСА всі завдання другого дня лягали на наші плечі. Від нас вимагалося забезпечити стійкість до відмов, зібрати кластер і, звичайно, налагодити резервне копіювання. Логіка дій була така:
- Навчити СРК робити бекап з Primary-ноди кластера. Для цього СРК повинна знаходити її, отже, потрібна інтеграція з тим чи іншим рішенням щодо управління кластером PostgreSQL. У випадку РСА для цього використовувалося програмне забезпечення Patroni.
- Визначитись з типом бекапу, виходячи з обсягів даних та вимог до відновлення. Наприклад, коли треба відновлювати сторінки гранулярно, використовувати дамп, а якщо бази великі та гранулярного відновлення не потрібно працювати на рівні файлів.
- Прикрутити до вирішення можливість блокового бекапу, щоб створювати резервну копію в багатопотоковому режимі.
При цьому спочатку ми поставили собі за мету створити ефективну і просту систему без монструозної обв'язки з додаткових компонентів. Чим менше милиць, тим менше навантаження на персонал і нижче ризик виходу СРК з ладу. Підходи, у яких використовувалися Veeam та RMAN, ми одразу виключили, бо комплект із двох рішень вже натякає на ненадійність системи.
Трохи магії для enterprise
Отже, нам потрібно було гарантувати надійне резервне копіювання для 10 кластерів по 3 ноди кожен, причому в резервному ЦОД дзеркально розташовується така ж інфраструктура. ЦОД у плані PostgreSQL працюють за принципом active-passive. Загальний обсяг бази даних становив 50 ТБ. З цим легко впорається будь-яка СРК корпоративного рівня. Але нюанс у тому, що спочатку у Postgres немає і зачіпки для повної та глибокої сумісності із системами резервного копіювання. Тому нам довелося шукати рішення, яке спочатку має максимум функціональності у зв'язці з PostgreSQL, і доопрацьовувати систему.
Ми провели 3 внутрішні «хакатони» — переглянули понад півсотні напрацювань, тестували їх, вносили зміни у зв'язку зі своїми гіпотезами, знову перевіряли. Проаналізувавши доступні опції, ми обрали Commvault. Цей продукт вже «з коробки» міг працювати з найпростішою кластерною інсталяцією PostgreSQL, а його відкрита архітектура викликала надію (яка виправдалася) на успішне доопрацювання та інтеграцію. Також Commvault вміє виконувати бекап логів PostgreSQL. Наприклад, Veritas NetBackup у частині PostgreSQL вміє робити лише повні бекапи.
Докладніше про архітектуру. Керуючі сервери Commvault були встановлені в кожному з двох ЦОД конфігурації CommServ HA. Система дзеркальна, керується через одну консоль і з погляду HA відповідає всім вимогам enterprise.
Також у кожному ЦОД ми запустили по два фізичні медіа-сервери, до яких через SAN по Fibre Channel підключили виділені спеціально для бекапів дискові масиви та стрічкові бібліотеки. Розтягнуті бази дедуплікації забезпечили стійкість до відмов медіасерверів, а підключення кожного сервера до кожного CSV — можливість безперервної роботи при виході з ладу будь-якої компоненти. Архітектура системи дозволяє продовжувати резервне копіювання, навіть якщо впаде один із ЦОД.
Patroni для кожного кластера визначає Primary-ноду. Їй може виявитись будь-яка вільна нода в ЦОД — але тільки в основному. У резервному всі ноди - Secondary.
Щоб Commvault розумів, яка нода кластера є Primary, ми інтегрували систему (дякую відкритій архітектурі рішення) з Postgres. Для цього було створено скрипт, який повідомляє про поточне розташування Primary-ноди керуючому серверу Commvault.
Загалом процес виглядає так:
Patroni вибирає Primary → Keepalived піднімає IP-кластер і запускає скрипт → агент Commvault на вибраній ноді кластера отримує повідомлення, що це Primary → Commvault автоматично переналаштовує бекап у рамках псевдоклієнта.
Плюс такого підходу в тому, що рішення не впливає на консистентність, ні на коректність логів, ні на відновлення інстансу Postgres. Воно також легко масштабується, тому що тепер не обов'язково фіксувати Commvault Primary і Secondary-ноди. Досить, що система розуміє, де Primary, і кількість вузлів може бути збільшено майже будь-якого значення.
Рішення не претендує на ідеальність та має свої нюанси. Commvault вміє бекапити тільки інстанс цілком, а не окремі бази. Тож кожної БД створено окремий інстанс. Реальні клієнти об'єднані у віртуальні псевдоклієнти. Кожен псевдоклієнт Commvault є UNIX кластер. До нього додаються ті ноди кластера, у яких встановлено агент Commvault для Postgres. В результаті всі віртуальні ноди псевдоклієнта бекапаються як один інстанс.
Всередині кожного псевдоклієнта вказано активну ноду кластера. Саме її і визначає наше інтеграційне рішення Commvault. Принцип роботи досить простий: якщо на ноді піднімається кластерний IP, скрипт встановлює в бінарнику агента Commvault параметр «активна нода» — фактично скрипт ставить «1» у потрібній частині пам'яті. Агент передає ці дані на CommServe і Commvault робить бекап з потрібного вузла. Крім цього, на рівні скрипта перевіряється коректність конфігурації, допомагаючи уникнути помилок під час запуску резервного копіювання.
При цьому великі бази даних блокуються блоково в кілька потоків, відповідаючи вимогам RPO і вікна резервного копіювання. Навантаження на систему незначне: Full-копії відбуваються не так часто, в решту днів збираються лише логи, причому в періоди низького навантаження.
До речі, ми застосували окремі політики для резервного копіювання архівних журналів PostgreSQL — вони зберігаються за іншими правилами, копіюються за іншим розкладом і для них не включається дедуплікація, оскільки ці журнали мають унікальні дані.
Для забезпечення консистентності всієї ІТ-інфраструктури окремі файлові клієнти Commvault встановлені на кожній з нод кластера. Вони виключають із резервних копій файли Postgres і призначені лише для бекапу ОС та прикладних програм. Для цієї частини даних також передбачена своя політика та свій термін зберігання.
Зараз СРК не впливає на продуктивні сервіси, але якщо ситуація зміниться, в Commvault можна буде включити систему обмеження навантаження.
Чи годиться? Годиться!
Отже, ми отримали не просто працездатний, але й повністю автоматизований бекап для кластерної інсталяції PostgreSQL, який відповідає всім вимогам викликів enterprise.
Параметри RPO та RTO в 1 годину та 2 години перекриті із запасом, а значить, система буде відповідати їм і при значному зростанні обсягів даних, що зберігаються. Всупереч безлічі сумнівів, PostgreSQL і enterprise-середовище виявилися цілком сумісні. І тепер ми з власного досвіду знаємо, що бекап для подібних СУБД можливий у найрізноманітніших конфігураціях.
Звичайно, на цьому шляху нам довелося зносити сім пар залізних чобіт, подолати низку труднощів, наступити на кілька граблів та виправити кілька помилок. Але тепер підхід вже випробуваний і може застосовуватися для впровадження Open Source замість пропрієтарних СУБД у суворих умовах enterprise.
А ви пробували працювати з PostgreSQL у корпоративному середовищі?
Автори:
Олег Лавренов, інженер-проектувальник систем зберігання даних «Інфосистеми Джет»
Дмитро Єрикін, інженер-проектувальник обчислювальних комплексів «Інфосистеми Джет»
Джерело: habr.com