Пояснение содержимого шаблона jinja2 конфига для Haproxy

Этот шаблон Jinja2 для конфигурации HAProxy настраивает балансировщик нагрузки для управления соединениями с двумя типами PostgreSQL-кластеров через PgBouncer: для мастера (master) и для реплик (read-only). В шаблоне используются переменные Ansible для динамического создания конфигурации на основе данных о хостах. Рассмотрим ключевые элементы и их предназначение.

1. Глобальная секция (global)

• log 127.0.0.1 local0 — настраивает логирование на локальный syslog-сервер (127.0.0.1) с уровнем логирования local0. Это стандартная практика для записи логов HAProxy.
• maxconn 4096 — задаёт максимальное количество одновременных соединений, которые HAProxy может обрабатывать (4096 в данном случае).
• daemon — переводит HAProxy в режим фонового процесса (демона).

2. Секция defaults

• log global — указывает, что настройки логирования будут использовать глобальные параметры из секции global.
• option tcplog — включает запись логов для TCP-соединений.
• retries 3 — определяет количество попыток переподключения к бэкенду в случае неудачи.
• timeout connect 5000ms — время ожидания для установки соединения с бэкендом (5 секунд).
• timeout client 500000ms и timeout server 500000ms — время ожидания активности со стороны клиента и сервера (500 секунд), это важно для длительных транзакций.

3. Секция frontend pgbouncer_master

• *bind :6532 — связывает frontend с портом 6532 на всех доступных интерфейсах (*), чтобы HAProxy мог принимать входящие подключения для подключения к мастеру через PgBouncer.
• mode tcp — задаёт TCP-режим работы, так как HAProxy будет балансировать соединения на уровне TCP (PgBouncer работает на TCP).
• default_backend pgbouncer_master_backend — указывает, что все запросы, поступающие на этот frontend, будут перенаправляться в backend, который обрабатывает запросы к мастеру базы данных.

4. Секция backend pgbouncer_master_backend

• mode tcp — аналогично секции frontend, здесь балансировка также осуществляется на уровне TCP.
• option httpchk GET /master HTTP/1.1\r\nHost:\ localhost — активная проверка состояния (health check). HAProxy будет отправлять HTTP-запрос /master для проверки состояния мастера. Это полезно для определения доступности узла мастера PostgreSQL через API Patroni.
• http-check expect status 200 — указывает, что узел считается здоровым, если возвращает HTTP-статус 200 OK.
• default-server inter 1s fall 3 rise 2 on-marked-down shutdown-sessions — определяет параметры проверки состояния узлов:
  • inter 1s — интервал между проверками состояния (1 секунда).
  • fall 3 — узел считается недоступным, если 3 проверки подряд завершатся неудачей.
  • rise 2 — узел будет считаться снова доступным, если 2 проверки подряд будут успешными.
  • on-marked-down shutdown-sessions — завершает все активные сессии, когда узел помечается как недоступный.

5. Цикл по etcd_nodes для backend pgbouncer_master_backend

• Это динамически генерируемый список серверов на основе узлов etcd, которые перечислены в группе etcd_nodes в инвентаре Ansible.
• server {{ host }} — имя сервера (логический идентификатор).
• {{ hostvars[host].ansible_host }}:{{ pgbouncer_listen_port }} — IP-адрес и порт PgBouncer на каждом узле, берутся из переменных Ansible.
• maxconn 10000 minconn 10000 — задаёт минимальное и максимальное количество соединений, которые HAProxy может держать для этого узла.
• check port 8008 — указывает, что HAProxy должен проверять состояние узла через порт 8008, который обычно используется Patroni для health check.

6. Секция frontend pgbouncer_readonly

• *bind :6533 — связывает frontend с портом 6533 на всех доступных интерфейсах для обработки запросов к репликам базы данных через PgBouncer.
• mode tcp — используется TCP-режим для балансировки.
• default_backend pgbouncer_replica_backend — все запросы будут направляться в backend, обрабатывающий реплики.

7. Секция backend pgbouncer_replica_backend

• mode tcp — режим работы на уровне TCP.
• option httpchk GET /replica HTTP/1.1\r\nHost:\ localhost — активная проверка для реплик, HAProxy будет отправлять запросы к API Patroni с URI /replica, чтобы убедиться, что узел является здоровой репликой.
• http-check expect status 200 — узел считается здоровым, если возвращает HTTP-статус 200 OK.
• Остальные параметры идентичны секции pgbouncer_master_backend.

8. Цикл по etcd_nodes для backend pgbouncer_replica_backend

• Этот цикл аналогичен тому, что используется в секции pgbouncer_master_backend. Он динамически создает список серверов для реплик, используя те же узлы etcd и параметры соединений.

Заключение:

Этот шаблон конфигурации HAProxy, сгенерированный с помощью Jinja2, позволяет динамически настраивать балансировку нагрузки для кластера PostgreSQL, используя PgBouncer для двух целей:

• Балансировка подключений к мастеру через frontend на порту 6532.
• Балансировка подключений к репликам через frontend на порту 6533.

API Patroni используется для активной проверки состояния узлов как мастера, так и реплик, что обеспечивает высокую доступность кластера.