Postgres Pro Enterprise Manager (PPEM) — комплексное решение для администрирования инфраструктуры баз данных. PPEM предоставляет удобный интерфейс для управления и мониторинга СУБД PostgreSQL, включая редакции Postgres Pro Standard и Postgres Pro Enterprise.
Инструменты PPEM позволяют выполнять самые разные регламентные операции по обслуживанию СУБД, обеспечивать комфортное управление экосистемой СУБД PostgreSQL во всех сферах эксплуатации, таких как резервное копирование и восстановление, отслеживание производительности и мониторинг, поиск и устранение неисправностей, и многое другое.
Чтобы начать работу с PPEM, воспользуйтесь инструкцией Быстрый старт.
Подробнее о компонентах и функциональности PPEM читайте в разделах Архитектура и Возможности.
Информация о новых выпусках и обновлениях функциональности находится в разделе Что нового.
Больше информации о работе с PPEM вы найдете в следующий разделах:
PPEM позволяет выполнять полный цикл задач развёртывания, эксплуатации и обслуживания баз данных PostgreSQL:
Автоматическое обнаружение экземпляров СУБД
PPEM обнаруживает активные экземпляры СУБД и автоматически добавляет их в веб-приложение, определяет используемые средства резервного копирования и синхронизирует конфигурацию резервного копирования в веб-приложение PPEM. Функции автоматического обнаружения минимизируют время на перенастройку экземпляров СУБД на работу с PPEM и оперативно начать использовать PPEM, а также облегчить миграцию с других средств управления.
Установка и запуск экземпляров СУБД
PPEM позволяет развернуть новые экземпляры СУБД с помощью браузера. Доступно развёртывание одиночных и кластерных конфигураций СУБД, а также развёртывание из резервных копий.
Конфигурирование экземпляров СУБД
Для новых и уже существующих экземпляров СУБД PPEM содержит средства просмотра и настройки параметров конфигурации. Это позволяет исключить необходимость подключения к экземпляру и прямого редактирования файлов конфигурации, что упрощает и ускоряет процесс настройки.
Просмотр и управление внутренними объектами схемы СУБД
PPEM предоставляет возможности для просмотра внутренней структуры экземпляров СУБД: табличные пространства, базы данных, таблицы, индексы и другие объекты. Также PPEM предоставляет средства для создания новых объектов СУБД.
Отслеживание внутренней активности экземпляров СУБД
PPEM взаимодействует с подсистемой статистики СУБД и предоставляет сведения о внутренней активности СУБД: активные и фоновые процессы, статистика выполнения запросов, ожидания и блокировки. Также с помощью PPEM можно отменять или принудительно завершать процессы СУБД.
Визуализация выполняющихся процессов и анализ планов запросов
PPEM интегрируется с коллектором pgpro-otel-collector, который собирает статистику и журналы активности СУБД и предоставляет метрики. PPEM выступает потребителем этой телеметрии и предоставляет графики для оценки и анализа работы СУБД.
Профилирование и интеграция с pgpro_pwr
PPEM интегрируется с pg_profile и pgpro_pwr, а также предоставляет удобный интерфейс для работы со снимками и отчётами.
Планирование, запуск и отслеживание работы регламентных операций
PPEM содержит инструменты для выполнения служебных операций, таких как очистка, сбор статистики планировщика, переиндексации и другие. Выполнение таких операций доступно как при необходимости, так и на регулярной основе с помощью планировщика заданий.
Обеспечение задач резервного копирования и восстановления
PPEM может автоматически обнаруживать инструменты резервного копирования (pg_probackup), интегрироваться с ними и предоставлять средства просмотра и управления. С помощью PPEM можно выполнять как непосредственное, так и регулярное резервное копирование по расписанию, а также создавать новые экземпляры СУБД из резервных копий. Используя средства PITR (Point-in-Time Recovery), можно более гибко решать задачи восстановления из резервных копий.
Прямой доступ к консоли экземпляров СУБД
PPEM позволяет подключаться к консоли экземпляра через web-psql. Этот инструмент PPEM предназначен для опытных экспертов-администраторов и позволяет оперативно подключиться и взаимодействовать с СУБД напрямую.
В этом разделе:
Архитектура PostgresPro Enterprise Manager включает следующие компоненты:
Веб-приложение — набор компонентов, которые обеспечивают пользовательский графический интерфейс, доступный через веб-браузер. Веб-приложение устанавливается на сервере с менеджером PPEM. Пользователь, используя браузер, выполняет различные действия, а веб-приложение преобразует эти действия в запросы и отправляет их менеджеру. Менеджер обрабатывает запросы и возвращает их веб-приложению. Веб-приложение преобразует ответ в различные представления и отображает в браузере.
Менеджер — служба, которая работает в фоновом режиме. Менеджер принимает запросы на обслуживание инфраструктуры СУБД и имеет собственный планировщик для выполнения регулярных служебных заданий. Менеджер принимает запросы от веб-приложения, согласно заложенной логике преобразует запросы в операции.
Для выполнения операций могут потребоваться:
Выполнив операцию, менеджер сообщает результат операции веб-приложению.
ПРИМЕЧАНИЕ
Операции, которые выполняет менеджер, могут быть синхронными и асинхронными. В случае синхронного выполнения клиент вынужден дождаться завершения операции, после чего получит ответ. В случае асинхронного выполнения клиент сразу получит ответ о том, что операция поставлена в очередь выполнения. При этом клиенту необходимо будет периодически проверять статус выполнения операции, но в большинстве случаев по завершению операции пользователю будет отправлено уведомление о завершении.
Репозиторий — база данных в отдельном экземпляре СУБД с набором схем и таблиц, в которых менеджер хранит служебную информацию, необходимую для работы. Менеджер при запуске устанавливает соединение с репозиторием и в процессе выполнения операций читает и записывает данные в репозиторий. Доступность репозитория носит критический характер — в случае недоступности репозитория дальнейшее продолжение работы менеджера невозможно.
Агенты — это службы, которые должны выполняться на управляемых серверах СУБД. Агенты принимают управляющие инструкции от менеджера и, в зависимости от типа инструкции, выполняют различные действия как в операционной системе, так и в экземпляре СУБД. В эти действия могут входить запуск команд, создание директорий и файлов, выполнение запросов и т.п. В процессе выполнения или по завершению действий результат выполнения отправляется менеджеру для регистрации результата в репозитории и/или последующей обработки согласно логике операции.
Агенты также имеют внутренний планировщик служебных заданий, который регулярно выполняет фоновые задания и результат выполнения отправляет менеджеру.
На одном отдельном сервере достаточно одного агента, который способен обслуживать один и более экземпляров СУБД на этом же сервере.
Экземпляр СУБД — это объект управления PPEM, то есть СУБД PostgreSQL в различных редакциях (Vanilla, Postgres Pro Standard/Enterprise). Несколько экземпляров СУБД могут объединяться в кластеры. Обычно это кластера потоковой репликации.
С отдельным экземпляром СУБД должен взаимодействовать только один агент PPEM. Не допускайте сценариев, когда несколько агентов работают с одним и тем же экземпляром СУБД, это может привести к путанице и неоднозначности поведения. С точки зрения экземпляра СУБД агент является обычным прикладным ПО, которое подключается к экземпляру через SQL-интерфейс, используя заранее определенную учетную запись СУБД.
Для расширения функций и возможностей PPEM может использовать различные внешние сервисы. Все эти сервисы являются необязательными и взаимодействие с ними настраивается отдельно.
ПРИМЕЧАНИЕ
PPEM не содержит инструменты для административного управления внешними сервисами (например, управление ресурсами и настройкам).
Поддерживаются следующие внешние сервисы:
Каталог LDAP — каталог пользователей и групп, который может использоваться для аутентификации пользователей в PPEM. PPEM поддерживает работу с сервисами OpenLDAP и Microsoft ActiveDirectory.
S3-совместимое объектное хранилище —
используется PPEM для размещения резервных копий, создаваемых
инструментом pg_probackup.
Пример верхнеуровневой архитектуры и взаимодействия компонентов представлен на схеме ниже:
Где:
pg_probackup.
Необязательный внешний
компонент.Пример архитектуры и взаимодействия менеджера и агента представлен на схеме ниже:
Где:
Для обеспечения функций мониторинга в контексте работы с Метриками и Журналами (далее — Телеметрия) PPEM использует коллектор pgpro-otel-collector от Postgres Pro.
Для работы с телеметрией используется внутреннее
хранилище в базе данных репозитория
— метрики хранятся в отдельной схеме monitoring, журналы —
в схеме logs.
Обязательным компонентом является коллектор
pgpro-otel-collector. Коллектор обеспечивает сбор
статистики и журналов, генерацию данных телеметрии и, в зависимости от
выбранного режима, экспорт данных менеджеру или во внешнюю систему
хранения.
Пример архитектуры мониторинга при использовании внутреннего хранилища представлен на схеме ниже:
Где:
pgpro-otel-collector подключается к экземпляру СУБД для
получения метрик, читает файлы журналов СУБД, обрабатывает полученные
данные и через REST API отправляет менеджеру. Агент
является отдельным компонентом, выполняет управляющие функции и не
занимается сбором метрик и журналов.Пример архитектуры резервного копирования представлен на схеме ниже:
Где:
pg_probackup. Резервное копия может быть сохранена как в
локальный каталог, так и в S3-совместимое объектное хранилище. Каталог
резервный копий должен быть предварительно подготовлен для работы с
pg_probackup.В случае восстановления резервная копии может
быть получена как из локального каталога, так и из объектного
хранилища.В этом разделе приведены аппаратные и программные требования для обеспечения работы PPEM, а также информация по расчёту ресурсов при масштабировании СУБД.
Ниже приведены минимально необходимые аппаратные и программные требования для серверов, где будут резвёрнуты менеджер и агент PPEM.
В качестве сервера может выступать:
ВАЖНО!
Использование PPEM при соблюдении минимальных требований не обеспечивает отказоустойчивость и рекомендуется только в пилотных или экспериментальных проектах, в средах с невысокой нагрузкой, без требований высокой доступности и отказоустойчивости.
Для менеджера:
Один сервер следующей минимальной конфигурации:
Для агента:
Один сервер следующей минимальной конфигурации:
Для менеджера:
Требуемые ресурсы для менеджера на 10 экземпляров СУБД с 10 тыс. объектов в отдельном экземпляре:
Минимальная конфигурация сервера, где будет размещен менеджер (до 10 экземпляров с 10 тыс. объектов в отдельном экземпляре):
Расчетная таблица:
| Количество экземпляров | CPU, шт. | RAM, ГБ | SSD, ГБ |
|---|---|---|---|
| 10 | 2 | 4 | 40 |
| 30 | 4 | 12 | 80 |
| 70 | 8 | 28 | 160 |
| 150 | 16 | 60 | 320 |
| 230 | 24 | 92 | 480 |
| 310 | 32 | 124 | 640 |
Для агента:
Требуемые ресурсы для агента на 1 экземпляр СУБД (до 100 тыс. объектов в экземпляре):
Минимальная конфигурация сервера с экземпляром СУБД, где будет размещен агент PPEM (до 100 тыс. объектов в экземпляре):
Расчетная таблица:
| Количество объектов СУБД | CPU, шт. | RAM, ГБ | SSD, ГБ |
|---|---|---|---|
| 100 тыс. | 2 | 2 | 10 |
| 200 тыс. | 3 | 4 | 20 |
| 400 тыс. | 4 | 8 | 20 |
Менеджер и агент PPEM поддерживают установку на операционные системы семейства Linux на платформе x86_64.
PPEM поддерживает установку и работу на следующих дистрибутивах Linux:
ПРИМЕЧАНИЕ
Работа PPEM c дистрибутивами, отличными от вышеперечисленных, не тестировалась и нормальная работа PPEM на них не гарантируется.
Работа PPEM на платформах, отличных от x86_64, не тестировалась и нормальная работа PPEM на них не гарантируется.
Менеджер PPEM поддерживает следующие версии PostgreSQL, включая редакции PostgresPro Standard и PostgresPro Enterprise:
Агент PPEM поддерживает следующие версии PostgreSQL, включая редакции PostgresPro Standard и PostgresPro Enterprise:
Агент PPEM поддерживает следующие версии pg_probackup, включая редакции Standard и Enterprise:
Агент PPEM поддерживает следующие версии pgpro-otel-collector:
Для оптимального пользовательского опыта при работе в веб-приложении PPEM рекомендуется:
Менеджер является обычным прикладным ПО и не требует привилегированного доступа к функциям операционной системы. Служба менеджера может полноценно функционировать при запуске от имени непривилегированного системного пользователя.
Для работы с репозиторием менеджеру требуется отдельная база данных, где будет храниться служебная информация. Также требуется пользователь СУБД со следующими правами:
Агент является обычным прикладным ПО, для полноценной работы которого требуется:
Для выполнения большинства функций агенту достаточно уровня доступа непривилегированного пользователя операционной системы. Есть небольшое количество функций, которым необходим привилегированный доступ. Для сохранения этой функциональности требуется дополнительная настройка системы и выдача необходимых прав. При отсутствии необходимых настроек и прав агент не сможет выполнить действия, что негативно скажется на функциональности PPEM. Рекомендуется выполнить все необходимые настройки перед запуском агента.
Доступ к управляемому экземпляру СУБД можно разделить на две части:
Доступ к файлам и каталогам экземпляра СУБД, который обеспечивается с помощью уровней доступа операционной системы — пользователь, от имени которого запущен агент, должен иметь доступ к основному каталогу данных.
ПРИМЕЧАНИЕ
По умолчанию инициализация основного каталога данных выполняется с владельцем
postgresи правами0600, поэтому большинство установок СУБД ограничивает доступ именно такой конфигурацией. Следовательно, оптимальным вариантом эксплуатации является запуск агента от имени системного пользователяpostgres.
Доступ к SQL-интерфейсу экземпляра СУБД, для которого агенту требуется пользователь СУБД:
pg_monitor,
pg_signal_backend.Сетевое взаимодействие между менеджером и агентом может инициироваться обеими сторонами:
Менеджер и агент для общения используют протокол HTTP(S). Менеджер по умолчанию использует порт tcp/8080, агент использует по умолчанию порт tcp/8081. Такое направление трафика следует учитывать при настройке правил сетевого доступа. Настройки адресов и портов задаются в основных файлах конфигурации менеджера и агента.
Для безопасной передачи данных рекомендуется использовать настройки TLS.
Работа пользователя с менеджером подразумевает аутентификацию и авторизацию. Аутентификация может выполняться следующими способами:
В случае использования встроенных средств PPEM данные о пользователях и группах хранятся в репозитории и управляются администратором PPEM. В случае использования внешнего каталога менеджер должен быть настроен на работу с этим каталогом. Все данные о пользователях и группах хранятся во внешнем каталоге и управляются отдельным администратором каталога LDAP.
API менеджера и агента защищено авторизацией. Для выполнения запросов к API менеджер и агент выполняют взаимную аутентификации и выдают токены доступа для последующей авторизации. Токены имеют ограниченное время жизни — менеджер и агенты самостоятельно отслеживают срок действия токенов и обновляют их при необходимости.
Управление доступом в PPEM реализуется RBAC-моделью (Role Based Access Control), которая определяет правила разграничения доступа с помощью ролей и привилегий. Модель устанавливает следующие базовые соглашения:
Базовые соглашения определяют расширенные соглашения:
ВАЖНО!
Привилегии не назначаются субъектам напрямую, а приобретаются субъектами только через роли.
Базовые утверждения:
Функциональность PPEM состоит из плагинов.
Каждый плагин позволяет управлять конкретным ресурсом.
Управление ресурсом включает в себя базовые CRUD-операции: create, view, edit, delete.
Дополнительно управление ресурсом может включать в себя различные RPC-операции, их имена зависят от операции по управлению ресурсом.
Доступ субъекта к различным операциям определяется привилегиями.
Таким образом, управление любым ресурсом управляется привилегиями (базовый минимум):
Привилегии включаются в роли.
Роли могут назначаться субъекту как в момент создания субъекта, так и позже.
При получении от субъекта запроса на выполнение операции плагин проверяет право субъекта на доступ к запрошенной операции.
Субъекты (пользователи) могут создавать собственные роли (при наличии прав) и назначать эти роли другим субъектам (пользователям).
Привилегии и роли могут быть объектно-привязанными. Это означает, что можно указать роль и привилегию, разрешающую доступ к ограниченному множеству объектов.
Привязка к объекту может осуществляться на уровне роли (все субъекты с этой ролью имеют доступ к объекту) или на уровне пользователя (доступ к объекту имеет только один пользователь).
Субъектами могут выступать:
Объектами могут выступать как ресурсы, так и представления ресурсов в репозитории, например: сервера, агенты, экземпляры СУБД, пользователи PPEM, группы PPEM и т.п.
При первом запуске PPEM выполняется инициализация репозитория, при
которой заполняются служебные таблицы (привилегии и роли). При
инициализации для каждого плагина устанавливается свой набор привилегий,
ролей и отношений "роль-привилегия". Так, например, для плагина
accounts создаются свои привилегии и роли для управления
доступом к объектам этого плагина. Так и для других плагинов создаются
свои наборы привилегий и ролей для управления доступом к объектам этих
плагинов.
При наличии необходимых привилегий пользователи могут создавать пользовательские роли, указывать набор привилегий и связывать роль с объектами. Пользовательская роль также может быть назначена на субъект.
Права доступа реализованы следующим набором таблиц (принадлежат
плагину accounts):
privileges
— привилегии с указанием класса объектов, к которым они регулируют
доступ;roles
— роли с указанием класса объектов, на которые нацелена роль;role_privileges
— отношение типа "роль-привилегия", устанавливает связь между ролью и
входящими в нее привилегиями;users
— пользователи системы (субъекты);user_roles —
отношение типа "пользователь-роль", устанавливает связь между
пользователем и назначенными на него ролями;user_privileges
— представление (view), отображающее связи
"пользователь-привилегия";groups
— группы системы;group_roles
— отношение типа "группа - роль", устанавливает связь между группой и
назначенными на нее ролями;group_users
— отношение типа "группа-пользователь", устанавливает связь между
группой и входящими в нее пользователями.privilegesТаблица имеет следующие поля:
Таблица заполняется менеджером PPEM с помощью миграций. Каждый плагин определяет собственный набор привилегий. Для проверки привилегий используется HTTP middleware-обработчик. Создание, изменение и удаление привилегий пользователем не предусмотрено, так как проверка привилегий реализуется в коде менеджера PPEM.
rolesТаблица имеет следующие поля:
user.Роли создаются менеджером с помощью миграций. Базовый набор ролей
устанавливается для плагина accounts. Пользователь через
API менеджера может создавать, изменять и удалять пользовательские роли,
но не может изменять или удалять роли установленные менеджером PPEM
(системные роли).
role_privilegesТаблица устанавливает отношения между ролями и привилегиями и имеет следующие поля:
privileges.class. Объявленный здесь идентификатор объекта
ограничивает действие привилегии, указанной в
role_privileges.privilege, одним объектом, и разрешает
доступ к объекту только участникам одной роли, указанной в
role_privileges.role (доступ разрешён пользователям в
user_roles.user, у которых user_roles.role =
role_privileges.role).Комбинация (role,privilege,object) является уникальным ключом с
условием object IS NOT NULL.
ПРИМЕЧАНИЕ
"Параметризованное" объектно-привязанное отношение "роль-привилегия" определяет доступ только к одному объекту (через указание
object). При необходимости выдать доступ на N объектов будет создано N записей вrole_privileges.
usersТаблица не имеет полей, имеющих отношение к RBAC.
При создании пользователя через API менеджера можно указать список идентификаторов ролей, которые будут назначены пользователю.
user_rolesТаблица устанавливает отношения между пользователем и ролями и имеет следующие поля:
privileges.class. Объявленный здесь идентификатор объекта
ограничивает действие привилегии, указанной в
role_privileges.privilege, одним объектом и разрешает
доступ к объекту пользователю, указанному в
user_roles.user.ПРИМЕЧАНИЕ
"Параметризованное" объектно-привязанное отношение "пользователь-роль" определяет доступ только к одному объекту (через указание object). При необходимости выдать доступ на N объектов будет создано N записей в
user_roles.
user_privilegesПредлагает удобный способ определения, какие роли и привилегии есть у пользователей. Представление используется для упрощения проверки привилегий у субъекта-пользователя:
groupsТаблица не имеет полей, имеющих отношение к RBAC.
При создании группы можно указать список идентификаторов ролей, которые будут назначены группе и, как следствие, всем входящим в нее пользователям.
group_rolesТаблица устанавливает отношения между группами и ролями и имеет следующие поля:
privileges.class. Объявленный здесь идентификатор объекта
ограничивает действие привилегии указанной в
role_privileges.privilege одним объектом и разрешает доступ
к объекту пользователю, указанному в
group_roles.role_id.ПРИМЕЧАНИЕ
"Параметризованное" объектно-привязанное отношение "группа-роль" определяет доступ только к одному объекту (через указание
object). При необходимости выдать доступ на N объектов будет создано N записей вgroup_roles.
group_usersТаблица устанавливает отношения между группами и пользователями и имеет следующие поля:
Отношения "группа-пользователь" не имеют объектных привязок.
В общем случае предполагается, что роли могут включать в себя привилегии, которые разрешают доступ ко всем объектам любого класса.
Для еще большей гранулярности выдачи прав доступа вместе с классом
можно указать и идентификатор объекта в
role_privileges.object. Так, действие роли и привилегии
будет распространяться только на объект с указанным идентификатором.
Объект можно указать в нескольких местах:
role_privileges.object, тогда все члены роли
смогут получить доступ к объекту;user_roles.object, тогда доступ
будет предоставлен только для одного пользователя;group_roles.object, тогда доступ будет
предоставлен только для пользователей группы.В процессе аутентификации субъекта выполняется создание сеанса и создание сессионных JWT-токенов. При создании access-токена в него вкладывается user_id. Пользователь, выполняя запросы на выполнение операций, прикладывает access-токен в заголовки запроса. Менеджер выполняет авторизацию, извлекает из access-токена user_id пользователя и через роли проверяет наличие необходимой привилегии. Если привилегия доступна, то доступ разрешается, если привилегии нет, запрос отклоняется.
Более подробно:
Для проверки, что субъект имеет право доступа на выполнение операции над объектом нужны:
user_id или agent_id — идентификатор
пользователя или агента;class — имя класса для объекта (по сути это тип
ресурса);object — идентификатор объекта (опционально).Клиент в запросе указывает заголовок
Authorization: Bearer и прикладывает access-токен.
Сервер получает запрос и извлекает данные, необходимые для проверки доступа:
user_id (или agent_id)
извлекается из access-токена.class определяется на основе привилегии.object:
/resources извлекается из URL
пути и параметров запроса (ids=?);/resources/objectID извлекается
из URL пути;/resources извлекается из тела
запросов (отдельное поле в объекте).Для проверки того, что у пользователя есть конкретная привилегия, обработчику может потребоваться карта соответствия идентификаторов операций и соответствующих им привилегий.
Проверка выполняется через репозиторий и представление
user_privileges.
Использование средств, усиливающих безопасность и добавляющих дополнительные уровни ограничений, могут нарушить работу некоторых функций PPEM, нормальная работа PPEM при использовании таких средств не гарантируется и не рекомендуется. К таким средствам относятся: