1.2. Архитектура
Пред. НаверхГлава 1. Обзор Postgres Pro Enterprise ManagerНачало След.

1.2. Архитектура #

1.2.1. Описание компонентов
1.2.2. Верхнеуровневая архитектура
1.2.3. Архитектура менеджера и агента
1.2.4. Архитектура мониторинга
1.2.5. Архитектура резервного копирования
1.2.6. Сбор и постобработка данных экземпляров

1.2.1. Описание компонентов #

Архитектура Postgres Pro Enterprise Manager включает компоненты, перечисленные ниже.

Веб-приложение #

Веб-приложение обеспечивает пользовательский графический интерфейс, доступный через веб-браузер. Веб-приложение устанавливается на сервере с менеджером. Пользователи выполняют различные действия с помощью браузера, а веб-приложение преобразует эти действия в запросы и отправляет их менеджеру. Менеджер обрабатывает запросы и возвращает их веб-приложению. Веб-приложение преобразует ответ в различные представления и отображает в браузере.

Менеджер #

Менеджер PPEM (далее — менеджер) — служба, которая работает в фоновом режиме. Менеджер принимает запросы на обслуживание инфраструктуры СУБД и имеет собственный планировщик для выполнения регулярных служебных заданий. Менеджер принимает запросы от веб-приложения и преобразует их в операции согласно заложенной логике.

Для выполнения операций могут потребоваться:

  • различные служебные данные, которые, как правило (но необязательно), хранятся в репозитории

  • выполнение инструкций на стороне агентов

Выполнив операцию, менеджер сообщает результат операции веб-приложению.

Примечание

Операции, которые выполняет менеджер, могут быть синхронными и асинхронными. В случае синхронного выполнения менеджер вынужден дождаться завершения операции, чтобы получить ответ. В случае асинхронного выполнения менеджер сразу получает ответ о том, что операция поставлена в очередь выполнения. В этом случае менеджеру необходимо периодически проверять статус выполнения операции, однако в большинстве случаев пользователь получает уведомление по её завершении.

Репозиторий #

Репозиторий PPEM (далее — репозиторий) — база данных в выделенном экземпляре СУБД с набором схем и таблиц, в которых менеджер хранит необходимую для работы служебную информацию. Менеджер при запуске устанавливает соединение с репозиторием и в процессе выполнения операций читает и записывает данные в репозиторий. Доступность репозитория носит критический характер — в случае недоступности репозитория дальнейшая работа менеджера невозможна.

Агенты #

Агенты PPEM (далее — агенты) — службы, которые должны выполняться на управляемых серверах СУБД. Агенты принимают управляющие инструкции от менеджера и, в зависимости от типа инструкции, выполняют различные действия как в операционной системе, так и в экземпляре СУБД, например:

  • запуск команд

  • создание каталогов и файлов

  • выполнение запросов

Во время или по завершении действий результат выполнения отправляется менеджеру для записи в репозиторий и/или последующей обработки в соответствии с логикой операции.

Агенты также имеют внутренний планировщик служебных заданий, который регулярно выполняет фоновые задания и отправляет менеджеру результат выполнения.

На отдельном сервере достаточно одного агента, который способен обслуживать один и более экземпляров СУБД.

Экземпляр СУБД #

Экземпляр СУБД — объект управления PPEM, то есть СУБД Postgres Pro в различных редакциях (Postgres Pro Standard, Postgres Pro Enterprise). Несколько экземпляров СУБД могут объединяться в кластеры. Обычно это кластеры потоковой репликации.

С отдельным экземпляром СУБД должен взаимодействовать только один агент. Не допускайте сценариев, когда несколько агентов работают с одним и тем же экземпляром СУБД, это может привести к путанице и неоднозначности поведения. С точки зрения экземпляра СУБД агент является обычным прикладным ПО, которое подключается к экземпляру через интерфейс SQL, используя заранее определённую учётную запись СУБД.

Внешние службы #

Для расширения функций и возможностей PPEM может использовать различные внешние службы. Все эти службы являются необязательными и взаимодействие с ними настраивается отдельно.

Примечание

PPEM не содержит инструменты для административного управления внешними службами (например, управление ресурсами и настройками).

Поддерживаются следующие внешние службы:

  • Каталог LDAP — каталог пользователей и групп для аутентификации пользователей в PPEM. PPEM поддерживает работу со службами OpenLDAP и Microsoft Active Directory.

  • S3-совместимое объектное хранилище — используется PPEM для размещения резервных копий, создаваемых утилитой pg_probackup.

  • OTLP-совместимая система хранения метрик — система хранения метрик с поддержкой работы по push-модели с возможностью записи метрик по протоколу OTLP, например Victoriametrics, и/или по pull-модели, способной забирать метрики по протоколу HTTP, например Prometheus. PPEM может использовать такую систему для получения метрик, которые записываются туда коллектором pgpro-otel-collector. PPEM поддерживает работу как с Victoriametrics, так и с Prometheus.

  • OTLP-совместимая система хранения журналов — система хранения метрик, способная принимать журналы по протоколу OTLP. PPEM может использовать такую систему для получения журналов СУБД, которые записываются туда коллектором pgpro-otel-collector. PPEM поддерживает работу с Elasticsearch.

1.2.2. Верхнеуровневая архитектура #

Пример верхнеуровневой архитектуры и взаимодействия компонентов представлен на схеме ниже.

Рисунок 1.1. Архитектура PPEM


Где:

  • PPEM — служба по управлению инфраструктурой СУБД, состоящая из веб-приложения, менеджера, репозитория и агентов.

  • Выделенный экземпляр СУБД — объект управления PPEM, который представляет собой СУБД PostgreSQL, Postgres Pro Standard или Postgres Pro Enterprise.

  • Кластер репликации — несколько экземпляров СУБД, объединённых в кластер. Как правило, это кластер потоковой репликации.

  • Служба идентификации пользователей и групп — каталог пользователей и групп, который можно использовать для аутентификации пользователей в PPEM.

  • S3-совместимое объектное хранилище — система для хранения резервных копий, созданных с помощью pg_probackup.

  • OTLP-совместимая система мониторинга — система мониторинга, способная принимать метрики по протоколу OTLP или забирать их через HTTP. Может использоваться PPEM для получения метрик производительности СУБД.

Служба идентификации пользователей и групп, S3-совместимое объектное хранилище, а также OLTP-совместимая система мониторинга являются необязательными внешними службами.

1.2.3. Архитектура менеджера и агента #

Пример архитектуры и взаимодействия менеджера и агента представлен на схеме ниже.

Рисунок 1.2. Архитектура менеджера и агента


Где:

  • Пользователь может работать с PPEM как через веб-приложение в браузере, так и через инструменты автоматизации (IaC), которые могут взаимодействовать с PPEM через REST API.

  • В PPEM основным графическим интерфейсом пользователя является веб-приложение. Веб-приложение тесно связано с менеджером — оттуда веб-приложение получает данные и отправляет управляющие команды от пользователя. Менеджер предоставляет API для получения данных и управления инфраструктурой СУБД. Менеджер хранит промежуточное состояние инфраструктуры в базе данных репозитория и взаимодействует с агентом, который управляет экземпляром СУБД.

  • Операционная система — это рабочее окружение, в котором запущены экземпляр СУБД и агент. Агент взаимодействует с менеджером: отправляет ему данные об окружении (информация об ОС и экземплярах СУБД) и принимает управляющие команды.

1.2.4. Архитектура мониторинга #

Чтобы обеспечить функции мониторинга в контексте работы с метриками и журналами (далее — телеметрия), PPEM использует коллектор pgpro-otel-collector от Postgres Pro.

Работу с телеметрией можно организовать двумя способами:

  • Базы данных репозитория используются для хранения телеметрии: метрики хранятся в отдельной схеме monitoring, журналы — в схеме logs.

  • Внешние хранилище данных (по отношению к PPEM) можно использовать для хранения телеметрии.

В обоих случаях обязательным компонентом является коллектор pgpro-otel-collector. Коллектор обеспечивает сбор статистики и журналов, генерацию данных телеметрии и, в зависимости от выбранного режима, экспорт данных менеджеру или во внешнюю систему хранения.

Примечание

Не рекомендуется использовать внутреннее хранилище в производственной среде, так как оно обладает ограниченной масштабируемостью и может вызвать проблемы с производительностью при росте объёмов данных. Запись и чтение больших объёмов телеметрии может негативно влиять на общую производительность PPEM при обращении к базе данных репозитория.

1.2.4.1. Внутреннее хранилище #

Пример архитектуры мониторинга при использовании внутреннего хранилища представлен на схеме ниже.

Рисунок 1.3. Мониторинг при использовании внутреннего хранилища


Где:

  • Пользователи работают с PPEM через веб-приложение в браузере, где просматривают графики по метрикам и журналам.

  • В PPEM хранилищем метрик и журналов является репозиторий. Менеджер получает метрики и журналы от коллектора и сохраняет их в базах данных репозитория, а также запрашивает метрики и журналы из баз данных репозитория и отдаёт их потребителю через REST API. Веб-приложение запрашивает у менеджера метрики и журналы, а затем визуализирует полученные данные.

  • В операционной системе коллектор pgpro-otel-collector подключается к экземпляру СУБД для получения метрик, читает файлы журналов СУБД, обрабатывает полученные данные и через REST API отправляет менеджеру. Агент является отдельным компонентом, выполняет управляющие функции и не занимается сбором метрик и журналов.

1.2.4.2. Внешнее хранилище #

Пример архитектуры мониторинга при использовании внешнего хранилища представлен на схеме ниже.

Рисунок 1.4. Мониторинг при использовании внешнего хранилища


Где:

  • Пользователи работают с PPEM через веб-приложение в браузере, где просматривают графики по метрикам и журналам.

  • В PPEM менеджер запрашивает метрики и журналы из внешних хранилищ и отдаёт их потребителю через REST API. Веб-приложение запрашивает у менеджера метрики и журналы, а затем визуализирует полученные данные.

  • В операционной системе коллектор pgpro-otel-collectorподключается к экземпляру СУБД для получения метрик, читает файлы журналов СУБД, обрабатывает полученные данные и через REST API отправляет во внешние хранилища. Агент является отдельным компонентом, выполняет управляющие функции и не занимается сбором метрик и журналов.

  • Внешние хранилища метрик и журналов:

    • В качестве хранилища метрик может выступать выделенная система мониторинга. Поддерживаются Prometheus, Victoriametrics и OTLP-совместимые хранилища.

    • В качестве хранилища журналов может выступать отдельная система с OTLP-совместимым хранилищем. Поддерживается Elasticsearch.

1.2.5. Архитектура резервного копирования #

Пример архитектуры резервного копирования представлен на схеме ниже.

Рисунок 1.5. Архитектура резервного копирования


Где:

  • Пользователи через веб-приложение используют функции резервного копирования и восстановления.

  • В PPEM веб-приложение отправляет запросы к менеджеру. Менеджер отправляет запросы на резервное копирование и восстановление агентам.

  • В операционной системе агенты выполняют резервное копирование или восстановление с помощью утилиты pg_probackup. Резервная копия может быть сохранена как в локальный каталог, так и в S3-совместимое объектное хранилище. Каталог резервных копий необходимо предварительно настроить для работы с pg_probackup. В случае восстановления резервная копия может быть получена как из локального каталога, так и из объектного хранилища.

  • S3-совместимое объектное хранилище является внешней службой. Поддержка работы с конкретными объектными хранилищами обеспечивается средствами pg_probackup и не зависит от PPEM.

1.2.6. Сбор и постобработка данных экземпляров #

В этом разделе описано, как агенты собирают данные экземпляров и отправляют их менеджеру для постобработки.

1.2.6.1. Сбор данных экземпляра #

Сбор данных экземпляров агентами состоит из следующих этапов:

  1. Подключение к базе данных экземпляра по умолчанию.

  2. Сбор глобальных объектов:

    • роли

    • табличные пространства

    • базы данных

  3. Сбор локальных объектов для каждой базы данных:

    • расширения

    • схемы

    • таблицы

    • индексы

    • последовательности

    • функции

    • языки

  4. Отправка собранных объектов менеджеру.

  5. Отправка менеджеру запроса DELETE /instances/objects с указанным атрибутом instance_id и временем сбора данных для удаления устаревших объектов, например удалённых объектов.

  6. Отправка менеджеру запроса POST /instances/objects/post_processing для начала постобработки.

    Если менеджер уже выполняет постобработку, например, если она не была завершена после предыдущего цикла сбора данных, возвращается ошибка 429 Too Many Requests. В этом случае агент завершает текущий цикл сбора данных и откладывает постобработку на следующий цикл.

1.2.6.1.1. Важные аспекты #

  • Каждый экземпляр может содержать сотни тысяч объектов, поэтому агенты собирают данные пакетами.

    Размер пакетов можно указать в файле конфигурации агента ppem-agent.yml с помощью параметра collectors.instance_objects.batch_size: количество_объектов_в_каждом_пакете;.

  • Агенты отправляют расширенные запросы для сбора следующих данных таблиц и индексов:

    • Для таблиц:

      • размер таблиц по слоям main, vm и fsm в байтах

      • размер раздувания в байтах

      • размер TOAST в байтах

      • количество кортежей

      • количество страниц

      • общий размер индексов в байтах

      • параметры хранения

      • путь к файлу таблицы

    • Для индексов:

      • размер индекса в байтах

      • размер раздувания в байтах

      • параметры хранения

      • путь к файлу индекса

    Расширенные запросы могут быть ресурсоёмкими и отправляются один раз на каждые 5 циклов сбора данных, чтобы избежать перегрузки экземпляра. Частоту отправки расширенных запросов можно указать в файле конфигурации агента ppem-agent.yml с помощью следующих параметров:

    • collectors.instance_objects.extended.enabled: указывает, отправляются ли расширенные запросы.

      Возможные значения:

      • true

      • false

    • collectors.instance_objects.extended.interval: интервал времени для отправки расширенных запросов.

      Этот интервал времени также можно указать в формате crontab с помощью параметра collectors.instance_objects.extended.schedule. Этот параметр имеет приоритет перед collectors.instance_objects.extended.interval.

  • Агенты собирают информацию о зависимостях составных объектов, таких как базы данных, схемы и таблицы. На основании этой информации после завершения цикла сбора данных менеджер генерирует сводную информацию.

  • Агенты автоматически переподключаются к экземпляру СУБД Postgres Pro один раз на каждые 10 запросов, чтобы избежать раздувания кеша соответствующего обслуживающего процесса.

1.2.6.2. Постобработка #

Постобработка менеджером состоит из следующих этапов:

  1. Обновление поля size_bytes собранных объектов:

    • Для таблиц значение рассчитывается как:

      размер_отношения + размер_карты_видимости + размер_карты_свободного_пространства + размер_TOAST

    • Для индексов значение равно размер_отношения.

    • Для схем и баз данных значение — общий размер всех их зависимостей.

    Примечание

    Размер таблиц схемы pg_toast не учитывается, так как он включён в размер таблиц базы данных.

  2. Повторная генерация следующей сводной информации для всех составных объектов:

    • Для баз данных:

      • общая сумма размеров таблиц в байтах

      • общая сумма размеров индексов в байтах

      • количество таблиц

      • количество индексов

      • общее раздувание в байтах

      • available_xid_total и available_xid_percent

    • Для схем:

      • количество таблиц

      • количество индексов

      • размер и раздувание таблиц

      • размер и раздувание индексов

    • Для таблиц:

      • количество индексов

      • общая сумма размеров индексов

      • общая сумма размеров раздувания

    Сводная информация хранится в таблице instance_objects в виде столбца JSONB. Структура сводной информации зависит от типа составного объекта:

    database:
tables_count: INT
tables_all_size_bytes: BIGINT
tables_all_bloat_size_bytes: BIGINT
indexes_count: INT
indexes_all_size_bytes: BIGINT
indexes_all_bloat_size_bytes: BIGINT
available_xid_total: BIGINT
available_xid_percent: BIGINT

schema:
tables_count: INT
tables_all_size_bytes: BIGINT
tables_all_bloat_size_bytes: BIGINT
indexes_count: INT
indexes_all_size_bytes: BIGINT
indexes_all_bloat_size_bytes: BIGINT

table:
indexes_count: INT
indexes_all_size_bytes: BIGINT
indexes_all_bloat_size_bytes: BIGINT
Пред. Наверх След.
1.1. Возможности Начало 1.3. Аппаратные и программные требования

Чтобы сделать работу с сайтом удобнее, мы используем cookie и аналитический сервис «Яндекс.Метрика». Продолжая пользоваться сайтом, вы соглашаетесь с их использованием.