Конфигурация кластера (discovery)#
CedrusData — это распределенная система, в которой несколько узлов работают над выполнением пользовательских запросов. Кластер CedrusData состоит из одного координатора и одного или нескольких воркеров. Координатор получает SQL-запрос от пользователя, формирует план выполнения запроса, и координирует выполнение отдельных частей запроса на воркерах.
Данный раздел описывает параметры конфигурации узлов, которые отвечают за процесс формирования кластера CedrusData.
Общая информация#
Все узлы CedrusData (координатор, воркеры) взаимодействуют друг с другом посредством протокола HTTP.
Каждый узел содержит HTTP-сервер, который принимает HTTP-запросы на определенном сетевом интерфейсе. Детальная конфигурация HTTP-сервера приведена в документе Конфигурация HTTP-сервера.
Другие узлы взаимодействуют с HTTP-сервером текущего узла с помощью собственных HTTP-клиентов. Детальная конфигурация HTTP-клиента приведена в документе Конфигурация HTTP-клиента.
Для успешной работы кластера CedrusData, каждый узел должен иметь возможность подключиться через собственный HTTP-клиент к HTTP-серверу любого другого узла. Для этого узлы должны обменяться собственными адресами. При это необходимо учесть, что узлы могут быть доступны по адресам, отличным от их собственных. Например, для связи с узлом, запущенным в Docker-контейнере, обычно необходимо использовать не собственный адрес контейнера, а интерфейс хоста, зачастую с указанием отдельного порта, опубликованного контейнером на хосте.
Для формирования кластера, все узлы должны знать сетевой адрес координатора,
который необходимо задать через параметр конфигурации discovery.uri
.
После запуска воркера, он подключается к координатору, и анонсирует собственный сетевой адрес.
По изложенным выше причинам, данный адрес может быть отличен от адреса интерфейса, на котором запущен HTTP-сервер воркера.
Обратите внимание, что в некоторых случаях координатор может совмещать роль воркера (если задан параметр node-scheduler.include-coordinator=true
).
В этом случае координатор анонсирует собственный адрес самому себе, аналогично другим воркерам.
Воркеры также анонсируют собственный уникальный идентификатор, а также environment
— произвольную строку,
которая уникально идентифицирует кластер. Узел не может подключиться к координатору, если у них не совпадает значение environment
.
Когда координатор получает SQL-запрос от пользователя, он определяет, на каких воркерах его необходимо выполнить. После этого координатор рассылает на воркеры команды на выполнение отдельных частей запроса. Среди прочего, данные команды содержат сетевые адреса других воркеров, которые были анонсированы координатору. Таким образом, в процессе выполнения SQL-запроса, каждый воркер знает сетевые адреса других воркеров.
Конфигурация#
discovery.uri
#
Тип: string
URI координатора в формате http(s)://host[:port]
. Параметр должен быть указан на всех узлах, включая координатор.
URI координатора на всех узлах должен указывать на один и тот же координатор. Однако, конкретные значения на разных узлах
могут отличаться в зависимости от того, как настроено разрешение имен на конкретном узле.
Параметр должен быть указан в файле etc/config.properties
.
Пример:
discovery.uri=http://example_coordinator:8080
node.environment
#
Type: string
Значение по умолчанию:
cedrus
при запуске из архива,docker
при запуске из Docker-образа
Произвольная строка, которая задает название кластера. Все узлы одного и того же кластер должны иметь одинаковое значение данного параметра. Значение данного параметра обычно используется для мониторинга и настройки ресурсных групп.
Значение должно начинаться с буквы в нижнем регистре или цифры, и содержать только буквы в нижнем регистре, цифры или символ подчеркивания (_
).
Мы рекомендуем задавать значение, которое отражает назначение кластера. Например, sales_prod
, etl_cluster
.
Параметр должен быть указан в файле etc/node.properies
(рекомендуемый вариант) или etc/config.properties
.
node.id
#
Type: string
Значение по умолчанию: произвольный UUID
Уникальный идентификатор узла. Все узлы кластера должны иметь отличные друг от друга идентификаторы. При наличии возможности мы рекомендуем задавать идентификатор узла явно, чтобы он сохранял одно и то же значение между перезапусками узла. Это облегчает мониторинг, а также повышает эффективность некоторых компонентов, например, локального дискового кэша для озер данных.
Идентификатор узла должен начинаться с буквы или цифры, и состоять только из букв, цифр и символов _
и -
.
Если значение идентификатора не задано, узлу будет присвоен идентификатор, равный произвольному UUID.
Параметр должен быть указан в файле etc/node.properies
(рекомендуемый вариант) или etc/config.properties
.
node.bind-ip
#
Type: string
Значение по умолчанию:
0.0.0.0
Имя сетевого интерфейса, на котором будет запущен HTTP-сервер узла.
Параметр должен быть указан в файле etc/node.properies
(рекомендуемый вариант) или etc/config.properties
.
node.internal-address
#
Type: string
Значение по умолчанию: в зависимости от значения параметра
node.internal-address-source
(см. ниже)
Задает имя хоста текущего узла, которое будет анонсировано другим узлам.
В процессе анонсирования адрес будет дополнен протоколом (http
или https
) и портом в соответствии с конфигурацией HTTP-сервера.
Например, если вы задали следующую конфигурацию:
node.internal-address=my_host
http-server.http.port=8081
То координатору будет анонсирован адрес http://my_host:8081
. В процессе выполнения запросов координатор и другие воркеры будут пытаться связаться с текущим узлом
по данному адресу.
Если вы не укажите явно значение данного параметра, то имя текущего хоста будет определено
автоматически на основании значения параметра node.internal-address-source
(см. ниже).
Параметр должен быть указан в файле etc/node.properies
(рекомендуемый вариант) или etc/config.properties
.
node.internal-address-source
#
Type: string
Значение по умолчанию:
IP
Задает стратегию определения имени хоста текущего узла, которое будет анонсировано другим узлам, если не задан node.internal-address
параметр.
Допустимые значения:
IP
(значение по умолчанию) — использовать IP адрес одного из активных сетевых интерфейсов. Сначала происходит попытка выбрать IPv4 активный интерфейс, который не является loopback, multicast или link-интерфейсом. Если подходящий интерфейс не найден, происходит попытка выбрать IPv6 интерфейс, который не является loopback, multicast или link-интерфейсом. Если подходящий интерфейс не найден, будет использован loopback-интерфейс (localhost
или127.0.0.1
)HOSTNAME
— использовать IP адрес loopback-интерфейса, использовать имя хоста, полученное путем обратного DNS-lookup адреса локального хостаIP_ENCODED_AS_HOSTNAME
— получить значение IP-адреса аналогично стратегииIP
и представить его в виде имени хоста, заменив некоторые специальные символы, и добавив суффикс.ip
. Например, значение192.168.10.5
будет представлено как192-168-10-5.ip
FQDN
— использовать fully-qualified domain name локального хоста