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

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

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

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

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

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

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

# Метаданные конфигурации.
# Поле управляется сервером
metadata:
  # Имя кластера из параметра cluster_uuid, выставляемом при установке кластера, или "", если параметр не выставлен
  cluster: unknown
  # Идентификатор конфигурационного файла, всегда возрастает на 1 и начинается с 1.
  # Увеличивается автоматически при загрузке новой конфигурации на сервер.
  version: 1
# Основная конфигурация кластера, все значения из него применяются по-умолчанию, пока не переопределены селекторами.
# Содержание аналогично статической конфигурации кластера
config:
# должен быть всегда выставлен в true для использования yaml конфигурации
  yaml_config_enabled: true
# конфигурация актор-системы, т.к. по-умолчанию данная секция используется только дин-нодами
# выставлена конфигурация именно для ни
  actor_system_config:
# автоматический подбор конфигурации для ноды на основе типа и количества доступных ядер
    use_auto_config: true
# HYBRID || COMPUTE || STORAGE — тип ноды
    node_type: COMPUTE
# число ядер
    cpu_count: 4
# конфигурация корневого домена кластера YDB
  domains_config:
    domain:
    - name: Root
      storage_pool_types:
      - kind: ssd
        pool_config:
          box_id: 1
          erasure_species: none
          kind: ssd
          pdisk_filter:
          - property:
            - type: SSD
          vdisk_kind: Default
      explicit_mediators: [72075186232426497, 72075186232426498, 72075186232426499]
      explicit_coordinators: [72075186232360961, 72075186232360962, 72075186232360963]
      explicit_allocators: [72075186232492033, 72075186232492034, 72075186232492035]
    state_storage:
    - ssid: 1
      ring:
        nto_select: 5
        node: [1, 2, 3, 4, 5, 6, 7, 8]
    hive_config:
    - hive_uid: 1
      hive: 72057594037968897
# конфигурация профилей каналов таблеток
  channel_profile_config:
    profile:
    - profile_id: 0
      channel:
      - &default_channel
        erasure_species: block-4-2
        pdisk_category: 1
        vdisk_category: Default
      - *default_channel
      - *default_channel
allowed_labels: {}
selector_config: []

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ограничения

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