Обзор конфигурации V2

Для развёртывания кластера YDB, добавления в кластер новых узлов и изменения параметров требуется конфигурация.

Конфигурация кластера YDB V2 представляет собой текстовый файл в формате YAML. В минимальном варианте он содержит секцию config с различными параметрами, необходимыми для запуска и настройки узлов кластера, а также секцию с метаданными metadata. Расширенные возможности для гибкого конфигурирования описаны в статье Domain-specific language (DSL) конфигурации кластера. Подробнее о доступных параметрах можно узнать в справке по конфигурации.

metadata:
  cluster: ""
  version: 0
config:
  hosts:
    - host: localhost
  drive:
    - type: RAM
  grpc_config:
    port: 2136
  monitoring_config:
    monitoring_port: 8765

Управление конфигурацией

За управление состоянием конфигурационного файла отвечает сам кластер YDB, и он же является единственным источником правды о том, как он сейчас сконфигурирован. За надёжное сохранение текущего состояния, являющегося источником правды, отвечает механизм распределённой конфигурации; как это работает технически, подробнее описано в статье Устройство механизма конфигурации V2. Узнать текущее состояние конфигурации кластера можно с помощью консольной команды ydb admin cluster config fetch, а состояние каждого конкретного узла — через его Embedded UI.

Изменение конфигурации кластера YDB осуществляется администратором следующим образом:

1. Сохранение текущего состояния конфигурации кластера в локальный файл через ydb admin cluster config fetch.
2. Редактирование нужных параметров в файле в текстовом редакторе или любым другим удобным способом.
3. Загрузка изменений обратно на кластер посредством вызова команды ydb admin cluster config replace.

$ ydb -e grpc://<ydb.example.com>:2135 admin cluster config fetch > config.yaml     # 1
$ vim config.yaml                                                                   # 2
$ ydb -e grpc://<ydb.example.com>:2135 admin cluster config replace -f config.yaml  # 3

Загрузка изменений обратно на кластер не всегда проходит успешно. Помимо базовой валидации корректности конфигурационного файла, у системы есть защита от конкурентного изменения несколькими администраторами. Система инкрементирует поле metadata.version при каждом изменении конфигурации и отказывается принимать новую версию, если её номер не совпадает с ожидаемым, так как это означает, что между fetch и replace было другое изменение, и replace его бы стёр. Чтобы минимизировать такие конфликты, можно использовать подход «Инфраструктура как код»: хранить копию конфигурационного файла в репозитории системы управления версиями (например, Git) и запускать команды fetch и replace не вручную, а только из привязанной к этому репозиторию системы непрерывной интеграции и доставки (CI/CD), реагирующей на изменения конфигурационного файла YDB в репозитории и обеспечивающей последовательную отправку всех изменений на кластер YDB.

Каждый узел кластера YDB сохраняет локально копию конфигурации в директорию, указанную в аргументе запуска ydbd --config-dir. Эта локальная копия используется в следующих ситуациях:

1. Для применения настроек, которые нужны на самом старте работы узла, ещё до того, как у него появляется возможность начать общаться с другими узлами кластера. Изменение таких настроек может требовать перезапуска узла.
2. Для первоначального развёртывания и расширения кластера.
3. В случае форс-мажора, если с основным механизмом управления конфигурацией возникли проблемы, требующие ручного вмешательства.

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

Базовые сценарии использования конфигурации

Первоначальное развёртывание кластера YDB

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

• Развёртывание YDB кластера с помощью Ansible;
• Начало работы с YDB в Kubernetes;
• Развёртывание YDB кластера вручную.

Обновление конфигурации

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

• Обновление конфигурации кластеров YDB, развёрнутых с Ansible;
• Обновление конфигурации кластеров YDB, развёрнутых вручную.

Если изменения конфигурации затрагивают параметры, требующие перезапуска узлов кластера, воспользуйтесь процедурой rolling restart. Подробнее о ней в зависимости от способа развёртывания:

• Перезапуск кластера, развёрнутого с помощью Ansible;
• Перезапуск кластера, развёрнутого вручную.

Расширение кластера

При расширении кластера конфигурация доставляется на старые и новые узлы по-разному:

• На узлы, существовавшие до расширения, изменения доставляются автоматически при вызове ydb admin cluster config replace.
• Перед первым запуском новых узлов локальная копия доставляется специальной командой ydb admin node config init, а не самим узлом.

Смотрите также

• Справка по параметрам конфигурации
• Сравнение конфигураций кластера YDB: V1 и V2