Динамическая конфигурация кластера

Динамическая конфигурация позволяет запускать динамические узлы, сконфигурировав их централизованно, без необходимости раскладывать файлы по узлам вручную. YDB выступает в роли системы управления конфигурациями, предоставляя инструменты для надёжного хранения, версионирования и доставки конфигурации, а так же DSL (Domain Specific Language) для переопределения её частей для определённых групп узлов. Конфигурация представляет собой YAML документ. Он является расширенной версией статической конфигурации:

описание конфигурации вынесено в поле config;
добавлено поле metadata, необходимое для валидации и версионирования;
добавлены поля allowed_labels и selector_config для гранулярного переопределения настроек.

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

переключать настройки журналирования компонентов как для всего кластера, так и для отдельных баз данных или групп узлов;
включать экспериментальную функциональность (feature flags) на отдельных базах данных;
изменять настройки акторной системы на конкретной базе данных, отдельном узле или на группе узлов.

Подготовка к использованию динамической конфигурации

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

Включите в кластере аутентификацию и авторизацию узлов баз данных.
Если ранее в кластере использовалось управление конфигурацией через CMS, выгрузите существующие настройки в формате YAML. Для этого выполните следующую команду:
```
./ydbd -s grpcs://<node1.ydb.tech>:2135 --ca-file ca.crt --token-file ydbd-token \
     admin console configs dump-yaml > dynconfig.yaml
```
Предварительно необходимо получить токен аутентификации с помощью команды ydb auth get-token, аналогично процедуре инициализации кластера.
Сформируйте первоначальный файл динамической конфигурации:
- Если ранее в CMS выполнялись настройки (экспортированные на предыдущем шаге), используйте полученный файл в качестве основы и:
  - добавьте секцию metadata по образцу из примера конфигурации;
  - в секцию config добавьте параметр yaml_config_enabled: true.
- Если ранее настройки через CMS не выполнялись, используйте минимальное наполнение файла динамической конфигурации.
- Если в кластере используется шифрование интерконнекта акторной системы, добавьте в секцию config соответствующие настройки TLS для интерконнекта.

Примените сформированный файл динамической конфигурации на кластер:

# Применить конфигурационный файл dynconfig.yaml на кластер
ydb admin config replace -f dynconfig.yaml

Примечание

После включения поддержки динамической конфигурации в кластере YDB устаревшая функция управления конфигурацией через CMS станет недоступной.

Примеры конфигурации

Пример минимальной динамической конфигурации для однодатацентрового кластера:

# Метаданные конфигурации.
# Поле управляется сервером
metadata:
  # Имя кластера из параметра cluster_uuid, выставляемом при установке кластера, или "", если параметр не выставлен
  cluster: ""
  # Идентификатор конфигурационного файла, всегда возрастает на 1 и начинается с 0.
  # Увеличивается автоматически при загрузке новой конфигурации на сервер.
  version: 0
# Основная конфигурация кластера, все значения из него применяются по-умолчанию, пока не переопределены селекторами.
# Содержание аналогично статической конфигурации кластера
config:
  # должен быть всегда выставлен в true для использования yaml конфигурации
  yaml_config_enabled: true
  # конфигурация актор-системы - поскольку по-умолчанию данная секция используется
  # только узлами БД, выставлена конфигурация именно для них
  actor_system_config:
    # автоматический подбор конфигурации для ноды на основе типа и количества доступных ядер
    use_auto_config: true
    # HYBRID || COMPUTE || STORAGE — тип ноды, для узлов баз данных всегда COMPUTE
    node_type: COMPUTE
    # количество выделенных ядер
    cpu_count: 14
allowed_labels: {}
selector_config: []

Подробнее параметры конфигурации описаны на странице Статическая конфигурация кластера.

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

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

---
metadata:
  kind: MainConfig
  cluster: ""
  version: 1
config:
  yaml_config_enabled: true
  table_profiles_config:
    table_profiles:
    - name: default
      compaction_policy: default
      execution_policy: default
      partitioning_policy: default
      storage_policy: default
      replication_policy: default
      caching_policy: default
    compaction_policies:
    - name: default
    execution_policies:
    - name: default
    partitioning_policies:
    - name: default
      auto_split: true
      auto_merge: true
      size_to_split: 2147483648
    storage_policies:
    - name: default
      column_families:
      - storage_config:
          sys_log:
            preferred_pool_kind: ssd
          log:
            preferred_pool_kind: ssd
          data:
            preferred_pool_kind: ssd
    replication_policies:
    - name: default
    caching_policies:
    - name: default
  interconnect_config:
    encryption_mode: REQUIRED
    path_to_certificate_file: "/opt/ydb/certs/node.crt"
    path_to_private_key_file: "/opt/ydb/certs/node.key"
    path_to_ca_file: "/opt/ydb/certs/ca.crt"
allowed_labels:
  node_id:
    type: string
  host:
    type: string
  tenant:
    type: string
selector_config:
- description: Custom settings for testdb
  selector:
    tenant: /cluster1/testdb
  config:
    shared_cache_config:
      memory_limit: 34359738368
    feature_flags: !inherit
      enable_views: true
    actor_system_config:
      use_auto_config: true
      node_type: COMPUTE
      cpu_count: 14

Обновление динамической конфигурации

# Получить конфигурацию кластера
ydb admin config fetch > dynconfig.yaml
# Отредактировать при помощи любого текстового редактора
vim dynconfig.yaml
# Применить конфигурационный файл dynconfig.yaml на кластер
ydb admin config replace -f dynconfig.yaml

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

Механизм работы

Обновление конфигурации c точки зрения администратора

Конфигурационный файл загружается пользователем при помощи grpc-вызова или YDB CLI в кластер.
Файл проверяется на валидность, проверяются базовые ограничения, корректность версии, корректность имени кластера, корректность конфигураций полученных после преобразования DSL.
Версия конфигурации в файле увеличивается на единицу.
Файл надёжно сохраняется в кластере таблеткой Console.
Обновления файла рассылаются по узлам кластера.

Обновление конфигурации с точки зрения узла кластера

Каждый узел при старте запрашивает полную конфигурацию.
Получив конфигурацию, узел генерирует конечную конфигурацию для своего набора лейблов.
Узел подписывается на обновления конфигурации, регистрируясь в таблетке Console.
В случае обновления конфигурации локальный сервис получает его и преобразует для лейблов узла.
Все локальные сервисы, подписанные на обновления, получают обновлённую конфигурацию.

Пункты 1,2 выполняются только для динамических узлов кластера.

Версионирование конфигурации

Данный механизм позволяет избежать конкурентной модификации конфигурации и сделать её обновление идемпотентным. При получении запроса на модификацию конфигурации сервер сравнивает версию полученной модификации с сохраненной. Если версия меньше на единицу, то конфигурации сравниваются — если они одинаковы, значит пользователь пытается загрузить конфигурацию повторно, пользователь получает ОК, а конфигурация на кластере не обновляется. Если версия равна текущей на кластере, то конфигурация заменяется на новую, при этом поле версии увеличивается на единицу. Во всех остальных случаях пользователь получает ошибку.

Динамически обновляемые настройки

Часть настроек системы обновляется без перезапуска узлов. Для их изменения достаточно загрузить новую конфигурацию и дождаться её распространения по кластеру.

Список динамически обновляемых настроек:

immediate_controls_config;
log_config;
memory_controller_config;
monitoring_config;
table_service_config;
tracing_config.external_throttling;
tracing_config.sampling.

В будущем список может быть расширен.

Ограничения

Использование более 30 различных лейблов в селекторах может привести к задержкам при валидации конфигурации в десятки секунд, т.к. YDB необходимо проверить валидность каждой возможной конечной конфигурации. При этом количество значений одного лейбла влияет намного меньше.
Использование объемных файлов (более 500KiB для кластера в 1000 узлов) конфигурации может привести к росту сетевого трафика в кластере при обновлении конфигурации. Объем трафика прямо пропорционален количеству нод и объему конфигурации.

Была ли статья полезна?

Статическая конфигурация кластера

DSL конфигурации кластера