Введение

В рамках темы будут рассмотрены:

• предназначение Pangolin Pooler;
• режимы работы Pangolin Pooler;
• аутентификация в Pangolin Pooler;
• сквозная аутентификация.

Предназначение Pangolin Pooler

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

Такая модель обслуживания клиентов имеет несколько негативных особенностей:

• на порождение обслуживающего серверного процесса уходит значимое время;
• каждый обслуживающий процесс затрачивает системные ресурсы процессора и памяти;
• в интерактивных приложениях соединение клиента с СУБД подавляющее время простаивает, а не выполняет реальную работу;
• операционная система чаще всего накладывает ограничения на максимальное количество процессов (смотрите man 3 ulimit и help ulimit).

Более того, сам СУБД Pangolin имеет параметр настройки max_connections:

postgres=# SHOW max_connections;

 max_connections
-----------------
 100
(1 строка)

Этот параметр, даже если его установить в большое значение, все равно ограничивает максимальное количество одновременно работающих клиентов.

Пул соединений

Общепринятый способ избежать указанные выше недостатки заключается в использовании пула соединений. Пул соединений реализуется с помощью специальной программы — пулера, являющейся своеобразным посредником между клиентом и СУБД. С точки зрения СУБД пулер — это клиент, а для клиента пулер выглядит как сервер. Для того, чтобы клиент "ничего не заподозрил" при общении с пулером, выдающим себя за сервер, пулер должен взаимодействовать с клиентом с помощью обычного клиентского протокола PostgreSQL.

Самое главное, ради чего в общение клиента и сервера встраивается пулер — количество сессий, создаваемых между пулером и СУБД, должно быть значительно меньше количества клиентов, установивших соединение с пулером. То есть, по одному соединению между пулером и СУБД выполняется взаимодействие сразу нескольких сессий с СУБД. Такой подход напоминает мультиплексирование.

Pangolin Pooler является переработанной версией популярного пулера PgBouncer, реализующего специфичные для Pangolin улучшения.

Режимы работы Pangolin Pooler

Pangolin Pooler способен работать в трех режимах:

• Пул сеансов (по умолчанию);
• Пул транзакций;
• Пул операторов.

Пул сеансов

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

Пул сеансов работает при настройке параметра pool_mode=session.

Пул транзакций

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

Включить режим пула транзакций можно, настроив параметр pool_mode=transaction.

Пул операторов

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

Режим пула операторов включается настройкой параметра pool_mode=statement.

Аутентификация в Pangolin Pooler

Поскольку Pangolin Pooler является посредником между клиентом и СУБД, то при подключении клиента выполняются два шага:

1. Клиент подключается к Pangolin Pooler и аутентифицируется в нем.
2. Если клиент аутентифицирован Pangolin Pooler успешно, то пулер должен установить соединение с СУБД.

Установка соединения между пулером и СУБД может выполняться путем передачи аутентификаторов клиента серверу (имени пользователя и пароля). Возможен также и иной сценарий: пулер может аутентифицироваться в СУБД от имени специальной роли вне зависимости от клиента.

Способы аутентификации клиентов в Pangolin Pooler напоминают аналогичные методы PostgreSQL. Существует даже возможности использовать файл настроек разрешений для подключения, задаваемых в формате HBA (Host Based Authentication), аналогичному pg_hba.conf.

Pangolin Pooler имеет специальную настройку, задаваемую параметром auth_type. Возможные значения параметра auth_type:

• cert - аутентификация с помощью сертификатов SSL/TLS;
• md5 - использование MD5 паролей;
• scram-sha-256 - пароли SCRAM-SHA-256 (Salted Challenge Response Authentication Mechanism);
• plain - нешифрованные пароли (метод неактуален);
• trust - доверие без аутентификации;
• any - аналогичен trust, но без передачи имени пользователя СУБД;
• hba - использует тип аутентификации из файла auth_hba_file;
• pam - аутентификация средствами ОС PAM (Pluggable Authentication Method).

Pangolin Pooler вполне можно эксплуатировать в обычном режиме, унаследованном из PgBouncer, когда пулер использует перечисленные выше способы аутентификации. Но (в разной степени) методы аутентификации в этом унаследованном подходе обладают существенными недостатками:

• при передаче аутентификаторов от клиента через пулер на СУБД должны порождаться обслуживающие процессы, выполняющие аутентификацию;
• некоторые методы аутентификации явно небезопасны;
• при использовании файла userlist.txt пароли могут храниться в нешифрованном виде;
• возможна потрея целостности информации, связанной с аутентификацией пользователя;
• сложность применения аудита.

Сквозная аутентификация

Для устранения указанных выше проблем, возникающих в обычном (унаследованном) режиме аутентификации, Pangolin Pooler обладает механизмом сквозной аутентификации. Если в обычном режиме аутентификация клиента выполняется дважды: в самом пулере, а затем в СУБД, то механизм сквозной аутентификации выполняет проксирование аутентификации, включаемый параметром auth_proxy = on.

В режиме проксирования запросы на аутентификацию перенаправляются на специальный порт TCP, который задается параметром auth_port. Клиент об этом перенаправлении информации не имеет и взаимодействует только с пулером.

Особый случай, когда клиент подключается с помощью соединения, защищенного SSL/TLS. В этом случае пулер передает СУБД следующую информацию:

• данные о сертификате;
• IP-адрес клиента.

Порт аутентификации прослушивается специальным дочерним процессом Pangolin AuthProc. Клиентское подключение всегда выполняется к конкретной базе данных, причем для подключения могут быть заданы специфические параметры.

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

Если аутентификация была успешной, то СУБД передает пулеру контекст аутентификации, содержащий два компонента:

• token — выполняет роль пропуска, разрешающий для этого клиента соединение между пулером и СУБД;
• verifier — для исключения повторной аутентификации в течении заданного параметром auth_activity_period периода времени.

Для предотвращения зависания пользовательских сессий также предусмотрен специальный таймер authentication_timeout.