Настройка существующего кластера ClickHouse

Настройка существующего кластера ClickHouse состоит из следующих этапов:

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

Настройка конфигурации кластера ClickHouse

Действия выполняются на каждом узле кластера.

Чтобы настроить конфигурацию кластера ClickHouse, на каждом узле кластера перейдите в директорию config.d в директории установки сервера ClickHouse и настройте параметры кластера в конфигурационном файле config.xml.

Пример содержимого файла config.xml
<clickhouse>
 <access_control_improvements>
        <users_without_row_policies_can_read_rows>true</users_without_row_policies_can_read_rows>
        <on_cluster_queries_require_cluster_grant>false</on_cluster_queries_require_cluster_grant>
        <select_from_system_db_requires_grant>false</select_from_system_db_requires_grant>
        <select_from_information_schema_requires_grant>false</select_from_information_schema_requires_grant>
        <settings_constraints_replace_previous>false</settings_constraints_replace_previous>
        <role_cache_expiration_time_seconds>600</role_cache_expiration_time_seconds>
    </access_control_improvements>
     <jdbc_bridge>
        <host>127.0.0.1</host>
        <port>9019</port>
    </jdbc_bridge>
    <!-- API-порт для взаимодействия SIEM и ClickHouse. -->
    <grpc_port>9101</grpc_port>

      <allow_plaintext_password>1</allow_plaintext_password>
    <allow_no_password>1</allow_no_password>
    <allow_implicit_no_password>1</allow_implicit_no_password>
     <timezone>UTC</timezone>
    <interserver_http_host>localhost</interserver_http_host>
    <database_atomic_delay_before_drop_table_sec>10</database_atomic_delay_before_drop_table_sec>
    <!-- Шардирование и репликация узлов кластера. -->
    <remote_servers>
    <default>
        <shard>
            <internal_replication>true</internal_replication>
            <weight>1</weight>
            <replica>
                <host>IP или FQDN узла 1</host>
                <port>9000</port>
                <user>writer</user>
                <password>writer</password>
            </replica>
        </shard>
        <shard>
            <internal_replication>true</internal_replication>
            <weight>1</weight>
            <replica>
                <host>IP или FQDN узла 2</host>
                <port>9000</port>
                <user>writer</user>
                <password>writer</password>
            </replica>
        </shard>
    </default>
</remote_servers>
<macros>
    <cluster>default</cluster>
    <replica>IP или FQDN текущего узла</replica>
    <shard>Имя текущего узла</shard>
    <layer>clickhouse</layer>
</macros>

<prometheus>
      <endpoint>/metrics</endpoint>
      <port>9363</port>
      <metrics>true</metrics>
      <events>true</events>
      <asynchronous_metrics>true</asynchronous_metrics>
  </prometheus>
<listen_host>::</listen_host>

<!-- Параметры сервера ClickHouse. -->
<background_buffer_flush_schedule_pool_size>6</background_buffer_flush_schedule_pool_size>
<background_common_pool_size>4</background_common_pool_size>
<background_distributed_schedule_pool_size>8</background_distributed_schedule_pool_size>
<background_fetches_pool_size>4</background_fetches_pool_size>
<background_message_broker_schedule_pool_size>8</background_message_broker_schedule_pool_size>
<background_move_pool_size>4</background_move_pool_size>
<background_pool_size>8</background_pool_size>
<background_merges_mutations_concurrency_ratio>4</background_merges_mutations_concurrency_ratio>
<background_schedule_pool_size>64</background_schedule_pool_size>
<mark_cache_size>5368709120</mark_cache_size>
<max_concurrent_queries>0</max_concurrent_queries>
<max_server_memory_usage>0</max_server_memory_usage>
<!-- Параметры таблиц MergeTree. -->
<merge_tree>
    <max_bytes_to_merge_at_max_space_in_pool>2147483648</max_bytes_to_merge_at_max_space_in_pool>
    <merge_max_block_size>2048</merge_max_block_size>
    <number_of_free_entries_in_pool_to_lower_max_size_of_merge>4</number_of_free_entries_in_pool_to_lower_max_size_of_merge>
    <max_suspicious_broken_parts>500</max_suspicious_broken_parts>
</merge_tree>

<!-- Директории хранения данных. -->
<storage_configuration>
        <disks>
            <hot_disk_1>
                    <path>/var/lib/clickhouse/hot-1/</path>
            </hot_disk_1>
            <cold_disk_1>
                    <path>/var/lib/clickhouse/cold-1/</path>
            </cold_disk_1>
        </disks>
        <policies>
            <siem_storage_policy>
                <volumes>
                    <hot_volume>
                        <disk>hot_disk_1</disk>
                    </hot_volume>
                    <cold_volume>
                        <disk>cold_disk_1</disk>
                    </cold_volume>
                </volumes>
            </siem_storage_policy>
        </policies>
    </storage_configuration>

<users>
        <root>
            <access_management>1</access_management>
        </root>
    </users>
<!-- Настройка ClickHouse Keeper. -->
<keeper_server>
    <tcp_port>9181</tcp_port>
    <server_id>ID Текущего узла</server_id>
    <log_storage_path>/var/lib/clickhouse/coordination/log</log_storage_path>
    <snapshot_storage_path>/var/lib/clickhouse/coordination/snapshots</snapshot_storage_path>
    <coordination_settings>
        <operation_timeout_ms>10000</operation_timeout_ms>
        <session_timeout_ms>30000</session_timeout_ms>
        <raft_logs_level>trace</raft_logs_level>
    </coordination_settings>

    <raft_configuration>
        <server>
            <id>ID текущего узла</id>
            <hostname>FQDN текущего узла</hostname>
            <port>9234</port>
        </server>
    </raft_configuration>
</keeper_server>
        <distributed_ddl>
                <path>/var/lib/clickhouse/task_queue/ddl</path>
        </distributed_ddl>
   <profiles>
        <default>
           <allow_suspicious_ttl_expressions>1</allow_suspicious_ttl_expressions>
        </default>

        <readonly>
            <readonly>1</readonly>
        </readonly>
    </profiles>
</clickhouse>

Порт для взаимодействия SIEM и ClickHouse

API-порт для взаимодействия R-Vision SIEM и ClickHouse задается в блоке grpc_port.

По умолчанию установлен порт 9100. Порт 9100 используется для приложения Node Exporter на рабочих и управляющих узлах кластера, поэтому рекомендуется задать другой порт, например 9101.

Example 1. Пример настройки порта
<grpc_port>9101</grpc_port>

Шардирование и репликация узлов кластера

Шардирование позволяет разбивать данные БД на части и размещать их на разных узлах кластера (шардах). Репликация предназначена для управления копиями данных (репликами) в БД и их синхронизации. Эти механизмы обеспечивают отказоустойчивость работы кластера и повышают надежность хранения данных. Подробную информацию о них можно найти в разделе Структура кластера ClickHouse.

Шардирование и репликация узлов задаются в блоке remote_servers.

Example 2. Пример настройки шардирования и репликации
<remote_servers>
    <default>
        <!-- Параметры шарда 1. -->
        <shard>
            <internal_replication>true</internal_replication>
            <weight>1</weight>
            <replica>
                <host>IP-адрес или FQDN узла 1</host>
                <port>9000</port>
                <user>writer</user>
                <password>writer</password>
            </replica>
        </shard>
        <!-- Параметры шарда 2. -->
        <shard>
            <internal_replication>true</internal_replication>
            <weight>1</weight>
            <replica>
                <host>IP-адрес или FQDN узла 2</host>
                <port>9000</port>
                <user>writer</user>
                <password>writer</password>
            </replica>
        </shard>
        <!-- Здесь пропущены параметры промежуточных шардов. -->
        <!-- Параметры шарда N. -->
        <shard>
            <internal_replication>true</internal_replication>
            <weight>1</weight>
            <replica>
                <host>IP-адрес или FQDN узла N</host>
                <port>9000</port>
                <user>writer</user>
                <password>writer</password>
            </replica>
        </shard>
    </default>
</remote_servers>
<macros>
    <cluster>default</cluster>
    <replica>IP-адрес или FQDN текущего узла</replica>
    <shard>Имя текущего узла</shard>
    <layer>clickhouse</layer>
</macros>

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

<remote_servers>
    <default>
        <shard>
            <replica>
                <host>localhost</host>
                <port>9000</port>
                <user>writer</user>
                <password>writer</password>
            </replica>
        </shard>
    </default>
</remote_servers>
<macros>
        <cluster>default</cluster>
        <shard>1</shard>
        <replica>Имя узла</replica>
</macros>

Параметры сервера ClickHouse

Подробную информацию о параметрах сервера можно найти в официальной документации ClickHouse.

Вы можете настроить параметры сервера ClickHouse в следующих блоках:

  • background_buffer_flush_schedule_pool_size — количество потоков для выполнения фонового сброса данных.

    Рекомендуемое значение: (1—​2) * количество ядер процессора.

  • background_common_pool_size — количество потоков для освобождения памяти.

    Рекомендуемое значение: (0—​1) * количество ядер процессора.

  • background_distributed_schedule_pool_size — количество потоков для выполнения фоновых задач.

    Рекомендуемое значение: (1—​2) * количество ядер процессора.

  • background_fetches_pool_size — количество потоков для репликации данных.

    Рекомендуемое значение: (0—​1) * количество ядер процессора.

  • background_message_broker_schedule_pool_size — количество потоков для фонового вывода сообщений.

    Рекомендуемое значение: (1—​2) * количество ядер процессора.

  • background_move_pool_size — количество потоков для перемещений данных между дисками.

    Рекомендуемое значение: (0—​1) * количество ядер процессора.

  • background_pool_size — количество потоков для слияний и мутаций таблиц.

    Рекомендуемое значение: (1—​2) * количество ядер процессора.

  • background_merges_mutations_concurrency_ratio — отношение количества слияний и мутаций, которые могут выполняться одновременно, к количеству потоков background_pool_size. Например, если параметр принимает значение 2, а background_pool_size — 16, то сервер ClickHouse может одновременно выполнять 32 слияния.

  • background_schedule_pool_size — количество потоков для выполнения фоновых задач.

    Рекомендуемое значение: (8—​16) * количество ядер процессора.

  • mark_cache_size — приблизительный размер (в байтах) кэша меток.

    Рекомендуемое значение: 1—​5 ГБ.

  • max_concurrent_queries — максимальное количество одновременно обрабатываемых запросов. Если принимает значение "0", то ограничений нет.

    Рекомендуемое значение: (1—​2) * количество ядер процессора.

  • max_server_memory_usage — максимальный объем оперативной памяти (в байтах), используемой сервером ClickHouse. Если принимает значение "0", то объем памяти определяется автоматически следующим образом: memory_amount * max_server_memory_usage_to_ram_ratio.

    Здесь:

    • memory_amount — общий объем оперативной памяти.

    • max_server_memory_usage_to_ram_ratio — доля оперативной памяти, используемой сервером ClickHouse. Если принимает значение "0", то сервер может использовать всю оперативную память. По умолчанию параметр не задан и воспринимается системой равным "0.9".

    Рекомендуемое значение: 90% от доступного объема оперативной памяти.

Example 3. Пример настройки параметров ClickHouse
<background_buffer_flush_schedule_pool_size>6</background_buffer_flush_schedule_pool_size>
<background_common_pool_size>4</background_common_pool_size>
<background_distributed_schedule_pool_size>8</background_distributed_schedule_pool_size>
<background_fetches_pool_size>4</background_fetches_pool_size>
<background_message_broker_schedule_pool_size>8</background_message_broker_schedule_pool_size>
<background_move_pool_size>4</background_move_pool_size>
<background_pool_size>8</background_pool_size>
<background_merges_mutations_concurrency_ratio>4</background_merges_mutations_concurrency_ratio>
<background_schedule_pool_size>64</background_schedule_pool_size>
<mark_cache_size>5368709120</mark_cache_size>
<max_concurrent_queries>0</max_concurrent_queries>
<max_server_memory_usage>0</max_server_memory_usage>

Параметры таблиц MergeTree

Таблицы семейства MergeTree позволяют использовать механизм репликации данных. Подробную информацию о MergeTree-параметрах можно найти в официальной документации ClickHouse.

Параметры MergeTree-таблиц задаются в блоке merge_tree. Для настройки доступны следующие параметры:

  • max_bytes_to_merge_at_max_space_in_pool — максимальный общий размер (в байтах) таблиц, которые могут быть слиты.

    Рекомендуемое значение: 1—​4 ГБ.

  • merge_max_block_size — количество строк, которые считываются в память из слитых таблиц.

    Рекомендуемое значение: 1024—​4096.

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

    Рекомендуемое значение: 1—​4.

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

Example 4. Пример настройки параметров таблиц MergeTree
<merge_tree>
    <max_bytes_to_merge_at_max_space_in_pool>2147483648</max_bytes_to_merge_at_max_space_in_pool>
    <merge_max_block_size>2048</merge_max_block_size>
    <number_of_free_entries_in_pool_to_lower_max_size_of_merge>4</number_of_free_entries_in_pool_to_lower_max_size_of_merge>
    <max_suspicious_broken_parts>500</max_suspicious_broken_parts>
</merge_tree>

Директории хранения данных

Директории хранения данных ClickHouse задаются в блоке storage_configuration:

  • В блоке disks задаются диски, которые используются томами для хранения данных.

  • В блоке volumes задаются тома для хранения данных:

    • hot_volume — том для хранения часто используемых данных (горячее хранение);

    • cold_volume — том для хранения редко используемых данных (холодное хранение).

Если хранение событий планируется в корневой директории ClickHouse, то используйте следующие настройки:

<storage_configuration>
    <disks> <!-- Диски, используемые для хранения данных. -->
        <hot_disk_1> <!-- Пользовательское название диска. -->
            <path>/var/lib/clickhouse/hot-1/</path> <!-- Директория хранения данных. -->
        </hot_disk_1>
        <cold_disk_1>
            <path>/var/lib/clickhouse/cold-1/</path>
        </cold_disk_1>
    </disks>
    <policies> <!-- Политики хранения, задаваемые при создании таблицы. -->
    <siem_storage_policy> <!-- Название политики. -->
        <volumes> <!-- Тома хранения. Приоритет записи определяется порядком указания томов. -->
            <hot_volume> <!-- Том горячего хранения данных. -->
                <disk>hot_disk_1</disk> <!-- Диск из раздела disks. -->
            </hot_volume>
            <cold_volume> <!-- Том холодного хранения данных. -->
                <disk>cold_disk_1</disk>
            </cold_volume>
        </volumes>
    </siem_storage_policy>
    </policies>
</storage_configuration>

Если планируется хранить события в отдельной директории, то:

  1. Создайте необходимые директории под горячее и холодное хранение данных с помощью команды:

    mkdir путь/до/директории
  2. Выдайте права на созданные директории группе пользователей clickhouse с помощью команды:

    chown -R clickhouse:clickhouse путь/до/директории
  3. Укажите пути до созданных директорий в path блоков hot_disk_1 и cold_disk_1.

Пример настройки отдельных директорий

Представим, что вам необходимо хранить события ClickHouse в директориях /storage/hot (горячее хранение) и /storage/cold (холодное хранение).

Чтобы настроить хранение в этих директориях:

  1. Создайте директории с помощью команд:

    mkdir /storage/hot
    mkdir /storage/cold
  2. Выдайте права на директории группе пользователей clickhouse с помощью команд:

    chown -R clickhouse:clickhouse /storage/hot
    chown -R clickhouse:clickhouse /storage/cold

    Если в директории /storage планируется хранение только данных событий ClickHouse, то, вместо выдачи прав на каждую поддиректорию по отдельности, вы можете выдать права сразу на всю директорию /storage:

    chown -R clickhouse:clickhouse /storage
  3. Укажите пути до директорий в path блоков hot_disk_1 и cold_disk_1 в файле config.xml:

    <storage_configuration>
        <disks> <!-- Диски, используемые для хранения данных. -->
            <hot_disk_1> <!-- Пользовательское название диска. -->
                <path>/storage/hot/</path> <!-- Директория хранения данных. -->
            </hot_disk_1>
            <cold_disk_1>
                <path>/storage/cold/</path>
            </cold_disk_1>
        </disks>
        <policies> <!-- Политики хранения, задаваемые при создании таблицы. -->
        <siem_storage_policy> <!-- Название политики. -->
            <volumes> <!-- Тома хранения. Приоритет записи определяется порядком указания томов. -->
                <hot_volume> <!-- Том горячего хранения данных. -->
                    <disk>hot_disk_1</disk> <!-- Диск из раздела disks. -->
                </hot_volume>
                <cold_volume> <!-- Том холодного хранения данных. -->
                    <disk>cold_disk_1</disk>
                </cold_volume>
            </volumes>
        </siem_storage_policy>
        </policies>
    </storage_configuration>

Настройка ClickHouse Keeper

ClickHouse Keeper — это служба для управления шардированием и репликацией данных в кластере ClickHouse. Подробную информацию о службе можно найти в официальной документации ClickHouse.

Настройка ClickHouse Keeper выполняется в блоке keeper_server. Например:

<keeper_server>
    <tcp_port>9181</tcp_port>
    <server_id>ID текущего узла</server_id>
    <log_storage_path>/var/lib/clickhouse/coordination/log</log_storage_path>
    <snapshot_storage_path>/var/lib/clickhouse/coordination/snapshots</snapshot_storage_path>
    <coordination_settings>
        <operation_timeout_ms>10000</operation_timeout_ms>
        <session_timeout_ms>30000</session_timeout_ms>
        <raft_logs_level>trace</raft_logs_level>
    </coordination_settings>

    <raft_configuration>
        <!-- Параметры узла 1. -->
        <server>
            <id>ID узла 1</id>
            <hostname>FQDN узла 1</hostname>
            <port>9234</port>
        </server>
        <!-- Параметры узла 2. -->
        <server>
            <id>ID узла 2</id>
            <hostname>FQDN узла 2</hostname>
            <port>9234</port>
        </server>
        <!-- Здесь пропущены параметры промежуточных узлов. -->
        <!-- Параметры узла N. -->
        <server>
            <id>ID узла N</id>
            <hostname>FQDN узла N</hostname>
            <port>9234</port>
        </server>
    </raft_configuration>
</keeper_server>

Запуск кластера ClickHouse

Действия выполняются на каждом узле кластера.

Чтобы запустить кластер ClickHouse, необходимо запустить каждый его узел по отдельности:

  1. Запустите текущий узел кластера:

    systemctl start clickhouse-server

    Ошибки запуска можно посмотреть в файле clickhouse-server.err.log или clickhouse-server.log в директории /var/log/clickhouse-server/.

  2. Проверьте доступ к текущему узлу:

    clickhouse-client -q "select version()"

    Если запуск узла произошел успешно, в консоль выведется установленная версия ClickHouse.

    Доступ к другим узлам кластера можно проверить удаленно с помощью команды:

    clickhouse-client -h <имя узла> -q "select version()"

    Если запуск узла произошел успешно, в консоль выведется установленная версия ClickHouse.

Создание пользователей ClickHouse

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

Для работы системы необходимо, чтобы в кластере ClickHouse были настроены три пользователя с разным набором прав:

  • owner — пользователь с расширенным набором прав. Используется для создания, обновления и удаления таблиц (хранилищ событий), а также получения служебной информации.

  • writer — пользователь с правами на запись. Используется в коллекторах для записи событий в ClickHouse.

  • reader — пользователь с правами только на чтение. Используется для выполнения поисковых запросов.

Для создания требуемых пользователей и кластерных вариантов служебных таблиц используйте скрипт ниже. Выполните скрипт на любом экземпляре кластера ClickHouse:

-- Создать пользователя owner и выдать ему необходимые права.
CREATE USER IF NOT EXISTS owner ON CLUSTER '{cluster}' IDENTIFIED WITH <OwnerPassword> BY 'owner';
GRANT ON CLUSTER '{cluster}' ALL on default.* TO 'owner';
GRANT ON CLUSTER '{cluster}' REMOTE on *.* TO 'owner';
GRANT ON CLUSTER '{cluster}' CLUSTER on *.* TO 'owner';
GRANT ON CLUSTER '{cluster}' SELECT ON system.disks TO 'owner';
GRANT ON CLUSTER '{cluster}' SELECT ON system.storage_policies TO 'owner';
GRANT ON CLUSTER '{cluster}' SELECT ON system.parts TO 'owner';
GRANT ON CLUSTER '{cluster}' SELECT ON system.query_log TO 'owner';
GRANT ON CLUSTER '{cluster}' SELECT ON system.columns TO 'owner';

-- Создать пользователя writer и выдать ему необходимые права.
CREATE USER IF NOT EXISTS writer ON CLUSTER '{cluster}' IDENTIFIED WITH <WriterPassword> BY 'writer';
GRANT ON CLUSTER '{cluster}' SELECT ON default.* TO 'writer';
GRANT ON CLUSTER '{cluster}' INSERT ON default.* TO 'writer';
GRANT ON CLUSTER '{cluster}' ALTER UPDATE ON default.* TO 'writer';
GRANT ON CLUSTER '{cluster}' ALTER DELETE ON default.* TO 'writer';
GRANT ON CLUSTER '{cluster}' REMOTE on *.* TO 'writer';
GRANT ON CLUSTER '{cluster}' CLUSTER on *.* TO 'writer';
GRANT ON CLUSTER '{cluster}' SELECT ON system.disks TO 'writer';
GRANT ON CLUSTER '{cluster}' SELECT ON system.storage_policies TO 'writer';
GRANT ON CLUSTER '{cluster}' SELECT ON system.parts TO 'writer';
GRANT ON CLUSTER '{cluster}' SELECT ON system.query_log TO 'writer';
GRANT ON CLUSTER '{cluster}' SELECT ON system.columns TO 'writer';

-- Создать пользователя reader и выдать ему необходимые права.
CREATE USER IF NOT EXISTS reader ON CLUSTER '{cluster}' IDENTIFIED WITH <ReaderPassword> BY 'reader';
GRANT ON CLUSTER '{cluster}' SELECT ON default.* TO 'reader';
GRANT ON CLUSTER '{cluster}' REMOTE on *.* TO 'reader';
GRANT ON CLUSTER '{cluster}' CLUSTER on *.* TO 'reader';
GRANT ON CLUSTER '{cluster}' SELECT ON system.disks TO 'reader';
GRANT ON CLUSTER '{cluster}' SELECT ON system.storage_policies TO 'reader';
GRANT ON CLUSTER '{cluster}' SELECT ON system.parts TO 'reader';
GRANT ON CLUSTER '{cluster}' SELECT ON system.query_log TO 'reader';
GRANT ON CLUSTER '{cluster}' SELECT ON system.columns TO 'reader';

-- Создать необходимые распределенные таблицы.
CREATE TABLE IF NOT EXISTS default.disks ON CLUSTER '{cluster}' AS system.disks ENGINE = Distributed('{cluster}', system, disks);
CREATE TABLE IF NOT EXISTS default.storage_policies ON CLUSTER '{cluster}' AS system.storage_policies ENGINE = Distributed('{cluster}', system, storage_policies);
CREATE TABLE IF NOT EXISTS default.parts ON CLUSTER '{cluster}' AS system.parts ENGINE = Distributed('{cluster}', system, parts);
CREATE TABLE IF NOT EXISTS default.query_log ON CLUSTER '{cluster}' AS system.query_log ENGINE = Distributed('{cluster}', system, query_log);
CREATE TABLE IF NOT EXISTS default.columns ON CLUSTER '{cluster}' AS system.columns ENGINE = Distributed('{cluster}', system, columns);

Здесь <OwnerPassword>, <WriterPassword> и <ReaderPassword> — это пароли пользователей owner, write и reader соответственно. Пароли должны отвечать следующим требованиям:

  • Пароль может содержать только строчные латинские буквы (a-z), заглавные латинские буквы (A-Z) и цифры (0-9).

  • Минимальная длина пароля: 8 знаков.