F.67. proxima — комбинация прокси и пула соединений
Пред. НаверхПриложение F. Дополнительно поставляемые модули и расширения, поставляемые в postgrespro-ent-17-contribНачало След.

F.67. proxima — комбинация прокси и пула соединений #

F.67.1. Обзор
F.67.2. Особенности и ограничения
F.67.3. Управление расширением proxima
F.67.4. Параметры конфигурации

proxima — это расширение Postgres Pro Enterprise, объединяющее функциональность прокси-сервера и пула соединений.

F.67.1. Обзор #

Расширение proxima можно использовать на одноузловом сервере Postgres Pro Enterprise, в стандартном кластере Postgres Pro Enterprise конструкции ведущий-ведомый, а также в BiHA-кластере. Расширение предоставляет следующие возможности:

  • Прокси-сервер: proxima становится единой точкой клиентских подключений и перенаправляет запросы на ведущий сервер или лидеру BiHA-кластера.

  • Пул соединений: proxima управляет обслуживающими процессами, чтобы сократить потребление системных ресурсов и предотвратить снижение производительности.

  • Поддержка SSL: расширение proxima можно настроить для работы с SSL-соединениями.

  • Динамический выделенный сеанс: proxima поддерживает сеанс между клиентом и обслуживающим процессом на протяжении всего времени существования клиентского подключения.

F.67.1.1. Аутентификация #

Расширение proxima использует правила аутентификации, указанные в файле pg_hba.conf. Поддерживаются следующие методы аутентификации:

F.67.1.2. Работа в BiHA-кластере #

В расширении proxima есть специальный режим работы для BiHA-кластера. При установке в BiHA-кластере proxima автоматически получает от biha все необходимые конфигурационные параметры, например:

  • количество узлов кластера

  • идентификаторы, адреса и порты узлов

  • роли узлов (лидер или последователь)

При использовании в BiHA-кластере proxima регистрирует ряд функций-обработчиков для получения информации о событиях в кластере. Например, если лидер кластера изменяется, proxima получает уведомление об этом событии и автоматически перенаправляет трафик на нового лидера.

F.67.1.3. Динамический выделенный сеанс #

При выполнении запросов обслуживающий процесс может хранить временное состояние и создавать объекты, такие как временные таблицы, временные представления и так далее, в рамках одного сеанса. Эта информация и объекты недоступны другим обслуживающим процессам. Если пул соединений перенаправляет клиента на другой обслуживающий процесс после создания такого объекта, клиент теряет доступ к этому объекту. Чтобы избежать этого, в proxima применяется функциональность динамического выделенного сеанса, позволяющая удерживать сеансы между клиентами и отдельными обслуживающими процессами на протяжении времени жизни клиентского подключения.

Примечание

Если вы используете расширения, которые хранят своё состояние в рамках сеанса, вам нужно вручную включить принудительный динамический выделенный сеанс. За дополнительной информацией обратитесь к Подразделу F.67.3.3.

Расширение proxima автоматически устанавливает динамический выделенный сеанс, если запрос содержит следующие объекты или функции SQL:

  • временные таблицы

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

  • временные представления

  • подготовленные запросы

  • курсоры

  • механизмы уведомления

  • SET SESSION

  • SET SESSION AUTHORIZATION

  • SET ROLE

  • pg_advisory_lock

  • SET SESSION CHARACTERISTICS AS TRANSACTION

Сеанс остаётся выделенным, пока упомянутые выше объекты не будут удалены.

Функция DISCARD удаляет объекты сеанса. После выполнения функции DISCARD ALL обслуживающий процесс выходит как из динамического выделенного сеанса, так и принудительного динамического выделенного сеанса.

F.67.2. Особенности и ограничения #

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

  • Расширение proxima не управляет репликацией между узлами кластера. Для обеспечения согласованности данных на всех узлах используйте biha или настройте репликацию вручную.

  • IPv6 не поддерживается.

  • Процессорные архитектуры Эльбрус, ppc64le и s390x не поддерживаются.

  • При использовании в BiHA-кластере proxima регистрирует ряд функций-обработчиков для получения информации о событиях в кластере. Функции-обработчики размещаются в таблице biha.callbacks базы данных biha_db на узлах BiHA-кластера. Не удаляйте функции-обработчики, так как в этом случае proxima не сможет реагировать на события в кластере.

  • На текущий момент в proxima отсутствует механизм автоматической установки динамических выделенных сеансов при использовании расширений, которые хранят своё состояние в рамках сеанса. В таких случаях необходимо вручную включить принудительный динамический выделенный сеанс.

  • Чтобы пул соединений обрабатывал большое число клиентских подключений, установите предел количества открытых файлов, превышающий число планируемых подключений:

    sudo echo '* soft nofile {значение}' >> /etc/security/limits.conf
sudo echo '* hard nofile {значение}' >> /etc/security/limits.conf
ulimit -n {значение}

    Например, если планируемое число клиентских подключений — 10000, в {значении} укажите 11000.

F.67.3. Управление расширением proxima #

В этом разделе описана установка, настройка и использование proxima.

F.67.3.1. Установка и настройка #

Расширение proxima — это встроенное расширение Postgres Pro Enterprise. Чтобы включить и настроить proxima, выполните следующие действия:

  1. Остановите сервер Postgres Pro Enterprise:

    pg_ctl stop -D каталог_PGDATA

  2. Добавьте proxima в shared_preload_libraries в файле postgresql.conf:

    shared_preload_libraries = 'proxima'

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

  3. В зависимости от конфигурации Postgres Pro Enterprise задайте параметры конфигурации proxima в postgresql.conf:

    • Для одноузлового сервера задайте следующий параметр конфигурации:

      proxima.cluster_mode = 'standalone'

    • Для стандартного кластера конструкции ведущий-ведомый задайте следующие параметры конфигурации:

      proxima.cluster_mode = 'guc'
proxima.cluster_config = 'id_узла0,адрес_узла0,порт_узла0,роль_узла0;id_узла1,адрес_узла1,порт_узла1,роль_узла1;
proxima.cluster_node_id = id_узла

      Например:

      proxima.cluster_mode = 'guc'
proxima.cluster_config = '0,192.168.0.57,4590,P;1,192.168.0.77,4590,S;'
proxima.cluster_node_id = 0

      Убедитесь, что на всех узлах указаны одинаковые значения proxima.cluster_config, а значения proxima.cluster_node_id уникальны для каждого узла.

    • Для BiHA-кластера задайте следующий параметр конфигурации:

      proxima.cluster_mode = 'biha'

      При использовании proxima с biha не требуется указывать параметры конфигурации кластера, так как proxima получает эту информацию напрямую от biha.

  4. (Необязательно) При необходимости задайте прочие параметры конфигурации.

    Если никакие параметры не заданы, proxima использует значения по умолчанию. За подробной информацией о конфигурационных параметрах и их значениях по умолчанию обратитесь к Подразделу F.67.4.

  5. Запустите узел:

    pg_ctl start -D каталог_PGDATA

F.67.3.2. Настройка SSL #

Настройте поддержку SSL-соединений в proxima.

  1. Сгенерируйте сертификат и закрытый ключ с помощью утилиты OpenSSL:

    openssl req -x509 -newkey rsa:4096 -keyout путь_к_ключу -out путь_к_сертификату -sha256 -days срок_действия -nodes -subj "/CN=домен_сертификата"

    Например:

    openssl req -x509 -newkey rsa:4096 -keyout ./key.pem -out ./cert.pem -sha256 -days 256 -nodes -subj "/CN=localhost"

  2. В postgresql.conf укажите пути к сгенерированному сертификату и закрытому ключу:

    proxima.ssl_key = '/путь/к/key.pem'
proxima.ssl_cert = '/путь/к/cert.pem'

    Если параметры proxima.ssl_cert и proxima.ssl_key не заданы, proxima использует сертификат и ключ, настроенные для Postgres Pro в ssl_cert_file и ssl_key_file.

  3. Включите SSL для proxima, указав значение on для proxima.ssl_enabled:

    proxima.ssl_enabled = on

Все клиентские подключения к порту proxima теперь защищены SSL.

F.67.3.3. Управление динамическим выделенным сеансом вручную #

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

Чтобы включить принудительный динамический выделенный сеанс:

SET proxima.force_dedicated = true;

Отключать принудительный выделенный динамический сеанс не нужно.

F.67.3.4. Удаление proxima #

Чтобы отключить использование proxima:

  1. На всех узлах кластера удалите расширение из shared_preload_libraries в файле postgresql.conf.

  2. Перезапустите узлы с помощью команды pg_ctl.

F.67.4. Параметры конфигурации #

Параметры расширения proxima задаются в файле конфигурации postgresql.conf.

F.67.4.1. Общие параметры #

proxima.address (text) #

Указывает IP-адрес сетевого интерфейса, принимающего входящие подключения. Если указано значение 0.0.0.0, то входящие подключения принимаются на всех сетевых интерфейсах узла. Значение по умолчанию — 0.0.0.0. Значение этого параметра должно быть одинаковым на всех узлах кластера.

proxima.port (integer) #

Указывает TCP-порт, через который proxima принимает входящие клиентские подключения. Диапазон допустимых значений: от 0 до 65535. Значение по умолчанию — 4545. Рекомендуется указать одинаковое значение для параметра proxima.port на всех узлах кластера.

proxima.ssl_enabled (boolean) #

Включает или выключает SSL для входящих клиентских подключений к proxima.port. Значение по умолчанию — off. Если включить SSL и не задать параметры proxima.ssl_key и proxima.ssl_cert, proxima будет использовать SSL-сертификат, настроенный для Postgres Pro.

proxima.ssl_cert (text) #

Указывает путь к сертификату, который будет использоваться для SSL-соединения через proxima.port. Если значение не указано, proxima использует сертификат, указанный в ssl_cert_file. Если параметр задан, вам также нужно указать значение для proxima.ssl_key.

proxima.ssl_key (text) #

Указывает путь к файлу закрытого ключа. Если параметр не задан, proxima использует ключ, указанный в ssl_key_file. Если параметр задан, вам также нужно указать значение для proxima.ssl_cert.

proxima.log_level (enum) #

Указывает уровень детализации сообщений proxima. Возможные значения: error, warning, info, verbose, debug. Значение по умолчанию — info.

proxima.workers (integer) #

Указывает число потоков, запускаемых для обработки запросов обслуживающим процессом proxima. Диапазон допустимых значений: от 1 до 65535. Чем выше значение, тем больше запросов может быть обработано. Значение по умолчанию — 4.

F.67.4.2. Конфигурирование кластера #

proxima.cluster_mode (text) #

Устанавливает режим работы кластера. Возможные режимы:

  • standalone — режим для одноузловой базы данных Postgres Pro.

  • guc — режим для стандартного кластера Postgres Pro конструкции ведущий-ведомый. Конфигурация кластера определяется параметрами proxima.cluster_config и proxima.cluster_node_id.

  • biha — режим для BiHA-кластера. В этом режиме конфигурация кластера передаётся расширением biha.

Значение по умолчанию — standalone. Значение этого параметра должно быть одинаковым на всех узлах кластера.

proxima.cluster_config (text) #

Устанавливает конфигурацию кластера для режима работы кластера guc. Значение этого параметра должно быть одинаковым на всех узлах кластера. Параметры подключения и идентификации необходимо указать для каждого узла следующим образом:

'id_узла,адрес_узла,порт_узла,роль_узла'

где:

  • id_узла — это идентификатор узла, в качестве которого необходимо указать значение в диапазоне от 0 до 255. Идентификатор узла должен быть уникальным для каждого узла в кластере.

  • адрес_узла — это IP-адрес узла для внутреннего соединения между узлами кластера.

  • порт_узла — это порт узла для внутреннего соединения между узлами кластера. Этот порт должен отличаться от proxima.port.

  • роль_узла — это роль узла в кластере. Возможные значения P (Primary, ведущий) и S (Standby, ведомый).

Пример значения proxima.cluster_config для кластера, состоящего из трёх узлов:

'0,127.0.0.1,4090,P;1,127.0.0.1,4091,S;2,127.0.0.1,4092,S;'
proxima.cluster_node_id (integer) #

Указывает уникальный идентификатор узла для режима работы кластера guc. Этот параметр не должен изменяться после запуска и до остановки кластера. Идентификатор узла должен быть уникальным для каждого узла кластера. Значение можно указать в диапазоне от 0 до 255. Значение по умолчанию — 0.

Список идентификаторов узлов должен всегда начинаться с 0 и заканчиваться n-1, где n — общее число узлов. Например, для кластера из трёх узлов идентификаторы узлов должны быть 0, 1, 2.

F.67.4.3. Настройка локального пула обслуживающих процессов #

Следующие параметры устанавливают ограничения для пула локальных обслуживающих процессов — Postgres Pro, обрабатывающих клиентские запросы.

proxima.backend_pool_local_total_limit (integer) #

Устанавливает максимальное число обслуживающих процессов, которые могут быть созданы на узле. Диапазон допустимых значений: от 1 до MAX_BACKENDS. Значение по умолчанию — 100.

proxima.backend_pool_local_bucket_limit (integer) #

Устанавливает максимальное число обслуживающих процессов, которые могут быть созданы в рамках подключений, идентифицированных связкой user + database. Диапазон допустимых значений: от 1 до значения, указанного в proxima.backend_pool_local_total_limit. Значение по умолчанию — 100.

proxima.backend_pool_local_overdue_interval (float) #

Устанавливает время бездействия локального обслуживающего процесса в секундах. Если локальный обслуживающий процесс не используется клиентами дольше, чем установлено этим параметром, обслуживающий процесс будет остановлен. Диапазон допустимых значений: от 1.0 до 86400.0. Значение по умолчанию — 10.0.

F.67.4.4. Настройка пула удалённых обслуживающих процессов #

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

proxima.backend_pool_remote_total_limit (integer) #

Устанавливает максимальное число логических каналов между узлами кластера для проксирования запросов клиента. Диапазон допустимых значений: от 1 до 2^32-1. Значение по умолчанию — 100000.

proxima.backend_pool_remote_bucket_limit (integer) #

Устанавливает максимальное число логических каналов между узлами кластера для проксирования клиентских запросов в рамках подключений, идентифицированных связкой user + database. Диапазон допустимых значений: от 1 до значения, указанного в proxima.backend_pool_remote_total_limit. Значение по умолчанию — 1000.

proxima.backend_pool_remote_overdue_interval (float) #

Устанавливает время бездействия удалённого обслуживающего процесса в секундах. Если удалённый обслуживающий процесс не используется клиентами дольше, чем установлено этим параметром, логическое соединение между узлами кластера будет разорвано. Диапазон допустимых значений от 1.0 до 86400.0. Значение по умолчанию — 60.0.

Пред. Наверх След.
F.66. postgres_fdw — обращение к данным, находящимся на внешних серверах Postgres Pro Начало F.68. ptrack — механизм резервного копирования базы Postgres Pro на уровне блоков