Настройка балансировки запросов к ClickHouse и PostgreSQL

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

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

Если вы установили PostgreSQL на одном сервере, действия, связанные с балансировкой запросов к PostgreSQL, выполнять не нужно.

Независимая балансировка запросов к ClickHouse и PostgreSQL

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

  • Для ClickHouse балансировка запросов осуществляется на уровне DNS-сервера по алгоритму Round-robin DNS: одно доменное имя (A-запись) сопоставляется с IP-адресами всех узлов кластера ClickHouse, и на каждый запрос к этому доменному имени возвращается IP-адрес нового узла.

  • Для PostgreSQL балансировка осуществляется с помощью сервиса keepalived по протоколу VRRP.

Преимущества:

  • Выделенные узлы балансировщика не требуются.

  • Для Round-robin DNS — простая настройка и минимальные расходы вычислительных ресурсов на балансировку.

Недостатки:

  • При использовании метода Round-robin DNS нагрузка и доступность узлов кластера ClickHouse не отслеживаются: если узел окажется перегружен или недоступен, часть запросов к ClickHouse по-прежнему будет направляться к нему.

  • Сервис keepalived разворачивается на узлах кластера PostgreSQL и создает дополнительную нагрузку на них.

Балансировка запросов к ClickHouse

Алгоритм Round-robin DNS позволяет производить циклическую ротацию адресов, возвращаемых сервером в ответ на запросы DNS Lookup. В контексте R-Vision SIEM это означает, что каждый последующий запрос системы к ClickHouse будет обрабатываться разными узлами кластера ClickHouse. В случае недоступности узла, указанного во время установки системы, запросы будут обработаны другими узлами кластера.

В данном разделе приведена инструкция по настройке Round-robin DNS для DNS-сервера на базе Windows Server. Для выполнения настройки на другом DNS-сервере обратитесь к официальной документации его производителя.

Чтобы настроить Round-robin DNS, выполните следующие действия на DNS-сервере вашей организации:

  1. Включите алгоритм Round-robin DNS:

    1. Откройте оснастку Диспетчер DNS, выполнив следующую команду:

      dnsmgmt.msc

    2. Откройте окно свойств DNS-сервера.

    3. Перейдите на вкладку Дополнительно.

    4. Установите флажок Включить циклическое обслуживание.

  2. В оснастке Диспетчер DNS добавьте доменное имя кластера ClickHouse.

    Выбранное доменное имя кластера ClickHouse потребуется указать в качестве имени хоста на этапе ClickHouse setup установки системы.

  3. Для вышеуказанного доменного имени добавьте A-записи для каждого узла кластера ClickHouse. Каждая из записей должна содержать IP-адрес определенного узла.

    Пример настройки A-записей для кластера ClickHouse с тремя узлами
    Имя Тип Данные

    clickhouse-cluster.example.local

    Host (A)

    192.168.0.1

    clickhouse-cluster.example.local

    Host (A)

    192.168.0.2

    clickhouse-cluster.example.local

    Host (A)

    192.168.0.3

  4. Чтобы каждый запрос к ClickHouse гарантированно обращался к новому узлу кластера, а не использовал IP-адрес из кэша DNS, отключите кэширование результатов DNS-запросов для созданных A-записей:

    1. В оснастке DNS-сервер включите режим Вид → Расширенный.

    2. В свойствах каждой из созданных A-записей установите свойство Срок жизни (TTL) записи равным нулю.

Балансировка запросов к PostgreSQL

Действия, описанные в этом разделе, необходимо выполнять, только если СУБД PostgreSQL установлена в выделенном кластере.
Для работы протокола VRRP нужны определенные сетевые условия: все узлы кластера PostgreSQL должны находиться в одном L2-сегменте (multicast).

Чтобы настроить балансировку запросов к узлам кластера PostgreSQL, выполните следующие действия на каждом узле кластера:

  1. Установите пакет keepalived:

    • РЕД ОС

    • Debian

    dnf install keepalived
    apt-get install -y keepalived

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

    VRRP_ADDRESS="<virtual_ip>"
VRRP_NETMASK="<virtual_netmask>"
VRRP_ROUTER_ID="<virtual_router_id>"
ETH_INTERFACE="<vrrp_interface>"
VRRP_AUTH_PASS="<auth_pass>"

    Здесь:

    • <virtual_ip> — выделенный IP-адрес, который будет привязан к сетевому интерфейсу на сервере, являющемся лидером VRRP, например, 10.99.57.50.

    • <virtual_netmask> — маска подсети для VRRP-адреса, например, 24.

    • <virtual_router_id> — индивидуальный идентификатор группы VRRP внутри L2-сегмента сети. Целое положительное число, например, 50.

    • <vrrp_interface> — имя интерфейса, к которому будет привязан VRRP-адрес. По умолчанию — ens192.

    • <auth_pass> — пароль для аутентификации в VRRP-сети.

  3. Создайте конфигурационный файл VRRP, выполнив команду ниже.

    Перед выполнением команды необходимо заменить шаблоны в угловых скобках (<>) на значения параметров, актуальные для вашего кластера. 
    echo -e """global_defs {
  router_id <postgres_node_name>
}
vrrp_script track_pgmaster {
  script \"/usr/local/bin/chk_master.sh\"
    interval 5
    rise 3
    fall 3
    weight -25
  }
vrrp_instance ${VRRP_ADDRESS} {
  state BACKUP
  interface ${ETH_INTERFACE}
  virtual_router_id ${VRRP_ROUTER_ID:?}
  priority 100
  preempt
  advert_int 1
  authentication {
    auth_type PASS
    auth_pass ${VRRP_AUTH_PASS}
  }
  virtual_ipaddress {
    ${VRRP_ADDRESS:?}/${VRRP_NETMASK:?} dev ${ETH_INTERFACE:?}
  }
  track_script {
    track_pgmaster
  }
}
""" > /etc/keepalived/keepalived.conf

    Здесь:

    • <postgres_node_name> — имя узла кластера PostgreSQL, например, postgres1.

  4. Создайте скрипт для отслеживания текущего лидера Patroni:

    echo '''#!/bin/bash
[ $(curl -s -X OPTIONS -o /dev/null --max-time 1 -w '%{http_code}' http://localhost:8008/master) -eq 200 ]
''' > /usr/local/bin/chk_master.sh
chmod +x /usr/local/bin/chk_master.sh

  5. Проверьте конфигурацию сервиса keepalived, выполнив следующую команду:

    keepalived -t

  6. Запустите сервис keepalived:

    systemctl enable --now keepalived

Предварительно настроенный балансировщик нагрузки

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

  • Для ClickHouse — по портам для взаимодействия системы и ClickHouse (по умолчанию 9100, 8123 и 8443).

  • Для PostgreSQL:

    • Трафик по порту 5432 должен направляться на порт 5432 master-узла Patroni.

    • Трафик по порту 5433 должен направляться на порт 5432 replica-узла Patroni.

    Чтобы проверить, является ли узел кластера PostgreSQL master-узлом или replica-узлом в кластере Patroni, можно выполнить в его терминале следующие команды:

    curl -s -o /dev/null -w "%{http_code}" localhost:8008/master
curl -s -o /dev/null -w "%{http_code}" localhost:8008/replica

    Если первая команда вернет ответ 200, то узел является master-узлом, иначе — replica-узлом.

Настройку следует производить согласно документации производителя балансировщика.

Преимущество: дополнительные узлы балансировщика не требуются.

Недостаток: настройку выделенного балансировщика необходимо производить самостоятельно.

Один сервер HAProxy

Балансировка с помощью выделенного сервера HAProxy обладает следующими свойствами:

Преимущества:

  • Балансировка выполняется для кластеров ClickHouse и PostgreSQL одновременно.

  • Реализован алгоритм проверки состояния узлов (healthcheck).

  • При балансировке запросов учитывается нагрузка на узлы.

Недостатки:

  • Узел, на котором расположен единственный балансировщик, может стать точкой отказа.

  • Для балансировщика требуется выделенный сервер.

Чтобы настроить балансировку запросов с помощью выделенного сервера HAProxy, выполните следующие действия:

  1. Перейдите в директорию с файлами распакованного архива clickhouse-cluster.tar.gz.

  2. Откройте файл inventory/hosts.ini и дополните его содержимое.

    В файле inventory/hosts.ini должны быть заполнены разделы [clickhouse], [clickhouse_keeper], [clickhouse_shard<shard_id>].

    Пример содержимого файла inventory/hosts.ini приведен в разделе документации Настройка нового кластера ClickHouse.

    1. В раздел [balancer] добавьте FQDN узла, на котором будет расположен сервер балансировщика.

    2. Если СУБД PostgreSQL установлена в выделенном кластере, в раздел [patroni] добавьте FQDN узлов кластера PostgreSQL.

    Пример конфигурации балансировщика в файле inventory/hosts.ini
    [balancer]
balancer.my.lan

[patroni]
postgres1.my.lan
postgres2.my.lan

  3. Если при настройке кластера ClickHouse было включено шифрование трафика между системой и кластером (в файле clickhouse.yml указан параметр dcc_clickhouse_ssl_enabled: true), необходимо настроить TLS-сертификат для узла балансировщика.

    По умолчанию роль generate_certificates, встроенная в плейбук, производит генерацию самоподписанного сертификата. Генерируемый сертификат и ключ сохраняются в директории <clickhouse_playbook_dir>/files/certs на хосте, с которого производится запуск плейбука.

    Здесь и далее: <clickhouse_playbook_dir> — полный путь к директории, в которую распакован архив плейбука.

    Если у вас есть заранее подготовленный TLS-сертификат, который вы хотите использовать для балансировщика, добавьте в директорию <clickhouse_playbook_dir>/files/certs файлы сертификата и ключа, соблюдая следующие правила именования:

    Имя файла Назначение

    ca-certificate.crt

    Сертификат доверенного центра сертификации.

    ca-certificate.key

    Ключ доверенного центра сертификации.

    Данный ключ используется для выпуска и подписания сертификатов, которые генерируются ролью generate_certificates при работе плейбука.

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

    <balancer_fqdn>_server.crt

    Сертификат узла балансировщика, выпущенный доверенным центром сертификации.

    <balancer_fqdn>_server.key

    Приватный ключ для сертификата <balancer_fqdn>_server.crt.

    Здесь:

    • <balancer_fqdn> — FQDN узла балансировщика, указанное в файле hosts.ini.

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

    Если установка системы будет производиться не с того же хоста, с которого выполняется развертывание ClickHouse, скопируйте сертификат доверенного центра сертификации <clickhouse_playbook_dir>/files/certs/ca-certificate.crt на этот хост.

    Путь к сертификату центра сертификации на хосте, с которого производится установка системы, потребуется указать на этапе ClickHouse setup установки системы.

  4. Если СУБД PostgreSQL установлена в выделенном кластере, в файл playbooks/deploy_balancer.yml добавьте конфигурацию для создания точек отслеживания состояния PostgreSQL:

    - name: "Deploying Balancer"
  hosts: balancer
  any_errors_fatal: true
  tasks:
    # ...
    - name: "Include role haproxy"
      ansible.builtin.include_role:
        name: haproxy
      vars:
        haproxy_cfg_configuration:
          # ...
          postgresql_master_tcp:
            frontend: |
              bind *:5432
              mode tcp
            backend: |
              option httpchk OPTIONS /master
              http-check expect status 200
              default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions
              {% for host in groups['patroni'] -%}
              server patroni{{ groups['patroni'].index(host) + 1 }} {{ host }}:5432 maxconn 3000 check port 8008
              {% endfor %}
          postgresql_slave_tcp:
            frontend: |
              bind *:5433
              mode tcp
            backend: |
              option httpchk OPTIONS /replica
              http-check expect status 200
              default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions
              {% for host in groups['patroni'] -%}
              server patroni{{ groups['patroni'].index(host) + 1 }} {{ host }}:5432 maxconn 3000 check port 8008
              {% endfor %}

  5. Запустите плейбук для развертывания балансировщика:

    cd ..
ansible-playbook -i inventory/hosts.ini playbooks/deploy_balancer.yml

Несколько серверов HAProxy и VRRP

Балансировка с помощью нескольких серверов HAProxy и протокола VRRP обладает следующими свойствами:

Преимущества:

  • Балансировка выполняется для кластеров ClickHouse и PostgreSQL одновременно.

  • Реализован алгоритм проверки состояния узлов (healthcheck).

  • При балансировке запросов учитывается нагрузка на узлы.

  • Серверы балансировщика не являются точками отказа.

Недостаток: для балансировщика требуется несколько выделенных серверов.

Для работы протокола VRRP нужны определенные сетевые условия: все узлы HAProxy должны находиться в одном L2-сегменте (multicast).

  1. Перейдите в директорию с файлами распакованного архива clickhouse-cluster.tar.gz.

  2. Откройте файл inventory/hosts.ini и дополните его содержимое.

    В файле inventory/hosts.ini должны быть заполнены разделы [clickhouse], [clickhouse_keeper], [clickhouse_shard<shard_id>].

    Пример содержимого файла inventory/hosts.ini приведен в разделе документации Настройка нового кластера ClickHouse.

    1. В раздел [balancer] добавьте FQDN узлов балансировщика.

    2. Если СУБД PostgreSQL установлена в выделенном кластере, в раздел [patroni] добавьте FQDN узлов кластера PostgreSQL.

    Пример конфигурации двух узлов балансировщика в файле inventory/hosts.ini
    [balancer]
balancer1.my.lan
balancer2.my.lan

[patroni]
postgres1.my.lan
postgres2.my.lan

  3. Если при настройке кластера ClickHouse было включено шифрование трафика между системой и кластером (в файле clickhouse.yml указан параметр dcc_clickhouse_ssl_enabled: true), необходимо настроить TLS-сертификаты для узлов балансировщика.

    По умолчанию роль generate_certificates, встроенная в плейбук, производит генерацию самоподписанных сертификатов. Генерируемые сертификаты и ключи сохраняются в директории <clickhouse_playbook_dir>/files/certs на хосте, с которого производится запуск плейбука.

    Здесь и далее: <clickhouse_playbook_dir> — полный путь к директории, в которую распакован архив плейбука.

    Если у вас есть заранее подготовленные TLS-сертификаты, которые вы хотите использовать для балансировщика, добавьте в директорию <clickhouse_playbook_dir>/files/certs файлы сертификатов и ключей, соблюдая следующие правила именования:

    Имя файла Назначение

    ca-certificate.crt

    Сертификат доверенного центра сертификации.

    ca-certificate.key

    Ключ доверенного центра сертификации.

    Данный ключ используется для выпуска и подписания сертификатов, которые генерируются ролью generate_certificates при работе плейбука.

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

    <balancer_fqdn>_server.crt

    Сертификат узла балансировщика, выпущенный доверенным центром сертификации.

    Сертификаты должны быть сгенерированы для каждого узла балансировщика.

    <balancer_fqdn>_server.key

    Приватный ключ для сертификата <balancer_fqdn>_server.crt.

    Приватные ключи должны быть сгенерированы для каждого узла балансировщика.

    Здесь:

    • <balancer_fqdn> — FQDN узла балансировщика, указанное в файле hosts.ini.

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

    Если установка системы будет производиться не с того же хоста, с которого выполняется развертывание ClickHouse, скопируйте сертификат доверенного центра сертификации <clickhouse_playbook_dir>/files/certs/ca-certificate.crt на этот хост.

    Путь к сертификату центра сертификации на хосте, с которого производится установка системы, потребуется указать на этапе ClickHouse setup установки системы.

  4. Если СУБД PostgreSQL установлена в выделенном кластере, в файл playbooks/deploy_balancer.yml добавьте конфигурацию для создания точек отслеживания состояния PostgreSQL:

    - name: "Deploying Balancer"
  hosts: balancer
  any_errors_fatal: true
  tasks:
    # ...
    - name: "Include role haproxy"
      ansible.builtin.include_role:
        name: haproxy
      vars:
        haproxy_cfg_configuration:
          # ...
          postgresql_master_tcp:
            frontend: |
              bind *:5432
              mode tcp
            backend: |
              option httpchk OPTIONS /master
              http-check expect status 200
              default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions
              {% for host in groups['patroni'] -%}
              server patroni{{ groups['patroni'].index(host) + 1 }} {{ host }}:5432 maxconn 3000 check port 8008
              {% endfor %}
          postgresql_slave_tcp:
            frontend: |
              bind *:5433
              mode tcp
            backend: |
              option httpchk OPTIONS /replica
              http-check expect status 200
              default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions
              {% for host in groups['patroni'] -%}
              server patroni{{ groups['patroni'].index(host) + 1 }} {{ host }}:5432 maxconn 3000 check port 8008
              {% endfor %}

  5. В файле inventory/group_vars/balancer.yml определите переменные для работы VRRP:

    vrrp_virtual_ipaddress: "<virtual_ip>"
vrrp_virtual_router_id: "<virtual_router_id>"
vrrp_interface: "<vrrp_interface>"

    Здесь:

    • <virtual_ip> — выделенный IP-адрес, который будет привязан к сетевому интерфейсу на сервере, являющемся лидером VRRP.

    • <virtual_router_id> — индивидуальный идентификатор группы VRRP внутри L2-сегмента сети. Целое положительное число.

    • <vrrp_interface> — имя интерфейса, к которому будет привязан VRRP-адрес. По умолчанию — ens192.

  6. Запустите плейбук для развертывания балансировщика:

    cd ..
ansible-playbook -i inventory/hosts.ini playbooks/deploy_balancer.yml

Была ли полезна эта страница?

+7 (499) 755 55 70 sales@rvision.ru

О компании Пользовательское соглашение Политика cookies

Обратная связь