Настройка кластера СУБД ClickHouse в Docker с поддержкой репликацииLTS

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

Запуск Docker служб кластера СУБД ClickHouse

Перед запуском Docker служб на каждой ноде кластера выполните те же настройки, что и при запуске ClickHouse в некластерном режиме.

Для конфигурации кластера ClickHouse при старте Docker служб на каждой ноде необходимо дополнительно указать следующие переменные окружения:

• CLUSTER_NODE_ID — индивидуальный порядковый номер ноды
• CLUSTER_NODES — список всех нод кластера (переменная должна быть одинаковой на всех нодах), в виде массива в формате:

  [{"id":1,"host":"node1.example.com","replica":"01-01"},{"id":2,"host":"node2.example.com","replica":"01-02"},{"id":3,"host":"node3.example.com","replica":"01-03"}]
  

  Где:
  • id — порядковый номер ноды кластера
  • host — адрес хоста ноды кластера
  • replica — макрос, указывающий на номер реплики, в формате 01-<номер_реплики>

Допустимо использовать в качестве хранилища данных только две ноды кластера. Третья нода не хранит данные, но обязательно требуется для обеспечения кворума — она выступает в роли арбитра, позволяя кластеру сохранять согласованность и избегать «расщепления» (split-brain) при временной недоступности одной из нод.

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

В этом случае в переменной CLUSTER_NODES значение replica указывается только для нод, участвующих в хранении данных, а для арбитра — опускается. Например:

[{"id":1,"host":"node1.example.com","replica":"01-01"}, {"id":2,"host":"node2.example.com","replica":"01-02"}, {"id":3,"host":"node3.example.com"}]

Защищенное взаимодействие между нодами кластера

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

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

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

Чтобы задать секрет кластера ClickHouse, создайте Docker секрет командой:

echo -n "Secure_secret_123@" | docker secret create cluster_secret -

Где Secure_secret_123@ — установленный секрет.

Пример команды для запуска Docker служб на одной из нод кластера:

docker service create --name infomaximum-clickhouse-node1 \
--secret infomaximum_app_user \
--secret infomaximum_app_user_password_hash \
--secret infomaximum_external_user \
--secret infomaximum_external_user_password_hash \
--secret infomaximum_clickhouse_dhparam.pem \
--secret infomaximum_clickhouse.crt \
--secret infomaximum_clickhouse.key \
--secret cluster_secret \
--publish published=8123,target=8123,mode=host \
--publish published=9000,target=9000,mode=host \
--publish published=2181,target=2181,mode=host \
--publish published=2180,target=2180,mode=host \
--mount type=volume,src=infomaximum-clickhouse,target=/var/lib/clickhouse/ \
--mount type=volume,src=infomaximum-clickhouse-log,target=/var/log/clickhouse-server \
-e CLUSTER_NODE_ID=1 \
-e CLUSTER_NODES='[{"id":1,"host":"node1.example.com","replica":"01-01"},{"id":2,"host":"node2.example.com","replica":"01-02"},{"id":3,"host":"node3.example.com","replica":"01-03"}]' \
--restart-max-attempts 5 \
--restart-condition "on-failure" \
infomaximum/infomaximum-clickhouse:25.3.2.39

После запуска Docker служб на всех нодах кластера настройте кластерное подключение в Proceset. В качестве имени кластера укажите default.

Шардирование для масштабных установок

При росте количества агентов мониторинга нагрузка на запись и запросы к активности в ClickHouse сосредоточена на одной ноде. При шардировании хранение и запросы распределяются по нескольким нодам ClickHouse (шардам), и нагрузка с одной ноды снимается.

Режим включается настройкой на стороне мониторинга. По умолчанию шардирование выключено, и установка работает без изменений.

Расчет числа шардов

Число шардов рассчитывается по количеству агентов мониторинга:

• Базовый расчет — 1 шард на 25 000 агентов
• С запасом на 2–3 года вперед — 2 шарда на 25 000 агентов

Рост объема накопленных данных при неизменном числе агентов не требует пересчета шардов — в этом случае достаточно увеличить дисковое пространство на шардах.

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

Ориентировочное соответствие числа агентов и параметров установки:

Порядок настройки

Чтобы включить шардирование:

1. Разверните нужное число нод ClickHouse.
2. Убедитесь, что имя кластера (cluster_name) на хранилище данных мониторинга совпадает с полем Имя кластера, которое задается при подключении ClickHouse в кластерном режиме.
3. В конфигурационном файле com.infomaximum.subsystem.monitoring.json задайте карту распределения данных по шардам и параметры подключения к каждому шарду, затем перезапустите корневую ноду мониторинга.

Пример блока sharding на два шарда — корзинки 0–99 поровну разделены между шардами, у каждого свое подключение к ClickHouse:

{
  "sharding": {
    "shards": [
      {
        "shard": 1,
        "buckets": [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49],
        "connections": [
          {
            "host": "clickhouse-shard1.example.com",
            "port": 8123,
            "user": "default",
            "password": "secret"
          }
        ]
      },
      {
        "shard": 2,
        "buckets": [50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99],
        "connections": [
          {
            "host": "clickhouse-shard2.example.com",
            "port": 8123,
            "user": "default",
            "password": "secret"
          }
        ]
      }
    ]
  }
}

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

Учетная запись сотрудника целиком относится к одному шарду — данные по ней не делятся между шардами. Если в пространстве используются запросы с объединением активности и справочника (JOIN), загрузите справочник на каждый шард отдельно.

Реплики

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