[PostgreSQL, Резервное копирование] Как вписать «свободную» PostgreSQL в суровое enterprise окружение
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Многие знакомы с СУБД 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— неудачная затея: данные будут копироваться куда-то на диск, а потом их нужно убирать на ленту. Такое задвоение резервного копирования увеличивает время бэкапа, а также, что более критично, — восстановления.
В enterprise решении резервное копирование инсталляции происходит с некоторым числом нод выделенного кластера. При этом, например, 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
===========
Похожие новости:
- [IT-инфраструктура, Сетевое оборудование, Сетевые технологии] Что нового в линейке высокопроизводительных маршрутизаторов NetEngine
- [Oracle, PHP, PostgreSQL] Кто победит: человек — венец творения или обратный слэш?
- [PostgreSQL, Администрирование баз данных, Серверное администрирование] Инкрементальные бэкапы PostgreSQL с pgBackRest. Часть 2. Шифрование, загрузка в S3, восстановление на новый сервер, PITR
- [PostgreSQL, Администрирование баз данных, Системное администрирование] Типичные ошибки при построении высокодоступных кластеров и как их избежать. Александр Кукушкин
- [Восстановление данных, Резервное копирование, Серверное администрирование, Системное администрирование] Политики хранения Veeam B&R — распутываем бэкапные цепи вместе с техподдержкой
- [PostgreSQL] Postgresso 24
- [PostgreSQL, SQL, Алгоритмы, Ненормальное программирование] SQL HowTo: курсорный пейджинг с неподходящей сортировкой
- [PostgreSQL, SQL] Хроники пэйджинга
- [PostgreSQL, SQL, Администрирование баз данных, Визуализация данных] PostgreSQL Query Profiler: как сопоставить план и запрос
- [Oracle, Администрирование баз данных] AWR: насколько «экзадатится» работа базы данных?
Теги для поиска: #_postgresql, #_rezervnoe_kopirovanie (Резервное копирование), #_postgresql, #_enterprise, #_blog_kompanii_infosistemy_dzhet (
Блог компании Инфосистемы Джет
), #_postgresql, #_rezervnoe_kopirovanie (
Резервное копирование
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 23:53
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Многие знакомы с СУБД 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— неудачная затея: данные будут копироваться куда-то на диск, а потом их нужно убирать на ленту. Такое задвоение резервного копирования увеличивает время бэкапа, а также, что более критично, — восстановления. В enterprise решении резервное копирование инсталляции происходит с некоторым числом нод выделенного кластера. При этом, например, Commvault умеет работать только с двухнодовым кластером, в котором Primary и Secondary жестко закреплены за определенными нодами. Да и смысл бэкапиться есть только с Primary, потому что резервное копирование с Secondary имеет свои ограничения. Из-за особенностей СУБД дамп на Secondary не создается, и поэтому остается только возможность файлового бэкапа. Чтобы снизить риски простоя, при создании отказоустойчивой системы образуется «живая» кластерная конфигурация, и Primary может постепенно мигрировать между разными серверами. Например, ПО Patroni само запускает Primary на рандомно выбранной ноде кластера. У СРК нет способа отслеживать это «из коробки», и, если меняется конфигурация, процессы ломаются. То есть внедрение внешнего управления мешает СРК эффективно работать, потому что управляющий сервер просто не понимает, откуда и какие данные нужно копировать. Еще одна проблема — реализация бэкапа в Postgres. Она возможна через dump, и на малых базах это работает. Но в больших БД дамп делается долго, требует много ресурсов и может привести к сбою экземпляра БД. Файловый бэкап исправляет ситуацию, но на больших базах он идет медленно, потому что работает в однопоточном режиме. К тому же у вендоров появляется целый ряд дополнительных ограничений. То нельзя одновременно использовать файловый и дамповый бэкап, то не поддерживается дедупликация. Проблем оказывается много, и чаще всего проще вместо Postgres выбрать дорогую, но проверенную СУБД. Отступать некуда! Позади Москва разработчики! Однако недавно наша команда оказалась перед непростым вызовом: в проекте создания АИС ОСАГО 2.0, где мы делали ИТ-инфраструктуру, разработчики для новой системы выбрали PostgreSQL. Крупным разработчикам ПО намного проще использовать «модные» open-source решения. В штате того же Facebook достаточно специалистов, поддерживающих работу этой СУБД. А в случае с РСА все задачи «второго дня» ложились на наши плечи. От нас требовалось обеспечить отказоустойчивость, собрать кластер и, конечно, наладить резервное копирование. Логика действий была такая:
При этом изначально мы задались целью создать эффективную и простую систему без монструозной обвязки из дополнительных компонентов. Чем меньше костылей, тем меньше нагрузка на персонал и ниже риск выхода СРК из строя. Подходы, в которых использовались 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 =========== Похожие новости:
Блог компании Инфосистемы Джет ), #_postgresql, #_rezervnoe_kopirovanie ( Резервное копирование ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 23:53
Часовой пояс: UTC + 5