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

Статическая конфигурация кластера задается в YAML-файле, передаваемом в параметре --yaml-config при запуске узлов кластера.

В статье приведено описание основных групп конфигурируемых параметров в данном файле.

host_configs — типовые конфигурации хостов

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

Синтаксис

host_configs:
- host_config_id: 1
  drive:
  - path: <path_to_device>
    type: <type>
  - path: ...
- host_config_id: 2
  ...

Атрибут host_config_id задает числовой идентификатор конфигурации. В атрибуте drive содержится коллекция описаний подключенных дисков. Каждое описание состоит из двух атрибутов:

• path : Путь к смонтированному блочному устройству, например /dev/disk/by-partlabel/ydb_disk_ssd_01
• type : Тип физического носителя устройства: ssd, nvme или rot (rotational - HDD)

Примеры

Одна конфигурация с идентификатором 1, с одним диском типа SSD, доступным по пути /dev/disk/by-partlabel/ydb_disk_ssd_01:

host_configs:
- host_config_id: 1
  drive:
  - path: /dev/disk/by-partlabel/ydb_disk_ssd_01
    type: SSD

Две конфигурации с идентификаторами 1 (два SSD диска) и 2 (три SSD диска):

host_configs:
- host_config_id: 1
  drive:
  - path: /dev/disk/by-partlabel/ydb_disk_ssd_01
    type: SSD
  - path: /dev/disk/by-partlabel/ydb_disk_ssd_02
    type: SSD
- host_config_id: 2
  drive:
  - path: /dev/disk/by-partlabel/ydb_disk_ssd_01
    type: SSD
  - path: /dev/disk/by-partlabel/ydb_disk_ssd_02
    type: SSD
  - path: /dev/disk/by-partlabel/ydb_disk_ssd_03
    type: SSD

Особенности Kubernetes

YDB Kubernetes operator монтирует NBS диски для Storage узлов на путь /dev/kikimr_ssd_00. Для их использования должна быть указана следующая конфигурация host_configs:

host_configs:
- host_config_id: 1
  drive:
  - path: /dev/kikimr_ssd_00
    type: SSD

Файлы с примерами конфигурации, поставляемые в составе YDB Kubernetes operator, уже содержат такую секцию, и её не нужно менять.

hosts — статические узлы кластера

В данной группе перечисляются статические узлы кластера, на которых запускаются процессы работы со Storage, и задаются их основные характеристики:

• Числовой идентификатор узла
• DNS-имя хоста и порт, по которым может быть установлено соединение с узлом в IP network
• Идентификатор типовой конфигурации хоста
• Размещение в определенной зоне доступности, стойке
• Инвентарный номер сервера (опционально)

Синтаксис

hosts:
- host: <DNS-имя хоста>
  host_config_id: <числовой идентификатор типовой конфигурации хоста>
  port: <порт> # 19001 по умолчанию
  location:
    unit: <строка с инвентарным номером сервера>
    data_center: <строка с идентификатором зоны доступности>
    rack: <строка с идентификатором стойки>
- host: <DNS-имя хоста>
  # ...

Примеры

hosts:
- host: hostname1
  host_config_id: 1
  node_id: 1
  port: 19001
  location:
    unit: '1'
    data_center: '1'
    rack: '1'
- host: hostname2
  host_config_id: 1
  node_id: 2
  port: 19001
  location:
    unit: '1'
    data_center: '1'
    rack: '1'

Особенности Kubernetes

При развертывании YDB с помощью оператора Kubernetes секция hosts полностью генерируется автоматически, заменяя любой указанный пользователем контент в передаваемой оператору конфигурации. Все Storage узлы используют host_config_id = 1, для которого должна быть задана корректная конфигурация.

domains_config — домен кластера

Данный раздел содержит конфигурацию корневого домена кластера YDB, включая конфигурации Blob Storage (хранилища бинарных объектов), State Storage (хранилища состояний) и аутентификации.

Синтаксис

domains_config:
  domain:
  - name: <имя корневого домена>
    storage_pool_types: <конфигурация Blob Storage>
  state_storage: <конфигурация State Storage>
  security_config: <конфигурация аутентификации>

Конфигурация Blob Storage

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

• Имя пула хранения
• Свойства устройств (например, тип дисков)
• Шифрование данных (вкл/выкл)
• Режим отказоустойчивости

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

Синтаксис

  storage_pool_types:
  - kind: <имя пула хранения>
    pool_config:
      box_id: 1
      encryption: <опциональный, укажите 1 для шифрования данных на диске>
      erasure_species: <имя режима отказоустойчивости - none, block-4-2, or mirror-3-dc>
      kind: <имя пула хранения - укажите то же значение, что выше>
      pdisk_filter:
      - property:
        - type: <тип устройства для сопоставления с указанным в host_configs.drive.type>
      vdisk_kind: Default
  - kind: <имя пула хранения>
  # ...

Каждой базе данных в кластере назначается как минимум один из доступных пулов хранения, выбираемый в операции создания базы данных. Имена пулов хранения среди назначенных могут быть использованы в атрибуте DATA при определении групп колонок в операторах YQL CREATE TABLE/ALTER TABLE.

Конфигурация State Storage

State Storage (хранилище состояний) — это независимое хранилище в памяти для изменяемых данных, поддерживающее внутренние процессы YDB. Оно хранит реплики данных на множестве назначенных узлов.

Обычно State Storage не требует масштабирования в целях повышения производительности, поэтому количество узлов в нём следует делать как можно меньшим с учетом необходимого уровня отказоустойчивости.

Доступность State Storage является ключевой для кластера YDB, так как влияет на все базы данных, независимо от того какие пулы хранения в них используются.Для обеспечения отказоустойчивости State Storate его узлы должны быть выбраны таким образом, чтобы гарантировать рабочее большинство в случае ожидаемых отказов.

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

При развертывании State Storage на кластерах, в которых применяется несколько пулов хранения с возможным сочетанием режимов отказоустойчивости, рассмотрите возможность увеличения количества узлов с распространением их на разные пулы хранения, так как недоступность State Storage приводит к недоступности всего кластера.

Синтаксис

state_storage:
- ring:
    node: <массив узлов StateStorage>
    nto_select: <количество реплик данных в StateStorage>
  ssid: 1

Каждый клиент State Storage (например, таблетка DataShard) использует nto_select узлов для записи копий его данных в State Storage. Если State Storage состоит из большего количества узлов чем nto_select, то разные узлы могут быть использованы для разных клиентов, поэтому необходимо обеспечить, чтобы любое подмножество из nto_select узлов в пределах State Storage отвечало критериям отказоустойчивости.

Для nto_select должны использоваться нечетные числа, так как использование четных чисел не улучшает отказоустойчивость по сравнению с ближайшим меньшим нечетным числом.

Конфигурация аутентификации

Режим аутентификации на кластере YDB задается в разделе domains_config.security_config.

Синтаксис

domains_config:
  ...
  security_config:
    enforce_user_token_requirement: Bool
  ...

Примеры

domains_config:
  domain:
  - name: Root
    storage_pool_types:
    - kind: ssd
      pool_config:
        box_id: 1
        erasure_species: block-4-2
        kind: ssd
        pdisk_filter:
        - property:
          - type: SSD
        vdisk_kind: Default
  state_storage:
  - ring:
      node: [1, 2, 3, 4, 5, 6, 7, 8]
      nto_select: 5
    ssid: 1

domains_config:
  domain:
  - name: Root
    storage_pool_types:
    - kind: ssd
      pool_config:
        box_id: 1
        erasure_species: block-4-2
        kind: ssd
        pdisk_filter:
        - property:
          - type: SSD
        vdisk_kind: Default
  state_storage:
  - ring:
      node: [1, 2, 3, 4, 5, 6, 7, 8]
      nto_select: 5
    ssid: 1
  security_config:
    enforce_user_token_requirement: true

domains_config:
  domain:
  - name: global
    storage_pool_types:
    - kind: ssd
      pool_config:
        box_id: 1
        erasure_species: mirror-3-dc
        kind: ssd
        pdisk_filter:
        - property:
          - type: SSD
        vdisk_kind: Default
  state_storage:
  - ring:
      node: [1, 2, 3, 4, 5, 6, 7, 8, 9]
      nto_select: 9
    ssid: 1

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
  state_storage:
  - ring:
      node:
      - 1
      nto_select: 1
    ssid: 1

domains_config:
  domain:
  - name: Root
    storage_pool_types:
    - kind: ssd
      pool_config:
        box_id: '1'
        erasure_species: block-4-2
        kind: ssd
        pdisk_filter:
        - property:
          - {type: SSD}
        vdisk_kind: Default
    - kind: rot
      pool_config:
        box_id: '1'
        erasure_species: block-4-2
        kind: rot
        pdisk_filter:
        - property:
          - {type: ROT}
        vdisk_kind: Default
    - kind: rotencrypted
      pool_config:
        box_id: '1'
        encryption_mode: 1
        erasure_species: block-4-2
        kind: rotencrypted
        pdisk_filter:
        - property:
          - {type: ROT}
        vdisk_kind: Default
    - kind: ssdencrypted
      pool_config:
        box_id: '1'
        encryption_mode: 1
        erasure_species: block-4-2
        kind: ssdencrypted
        pdisk_filter:
        - property:
          - {type: SSD}
        vdisk_kind: Default
  state_storage:
  - ring:
      node: [1, 16, 31, 46, 61, 76, 91, 106]
      nto_select: 5
    ssid: 1

Настройка акторной системы

Основной потребитель CPU — акторная система. Все акторы, в зависимости от своего типа, выполняются в одном из пулов (параметр name). Конфигурирование заключается в распределении ядер процессора узла по пулам акторной системы. При выделении процессорных ядер пулам нужно учитывать, что PDisk и gRPC API работают вне акторной системы и требуют отдельных ресурсов.

Вы можете использовать автоматическое или ручное конфигурирование акторной системы. В секции actor_system_config укажите:

• тип узла и количество ядер CPU, выделяемых процессу ydbd в случае использования автоматической конфигурирования;
• количество ядер CPU для каждой подсистемы кластера YDB при использовании ручного конфигурирования.

Автоматическое конфигурирование является адаптивным, т.е. подстраивается под текущую нагрузку системы. Его рекомендуется использовать в большинстве случаев.

Ручное конфигурирование может быть полезно в случае, когда какой-либо пул акторной системы в процессе работы оказывается перегружен и это влияет на общую производительность БД. Отслеживать нагрузку пулов можно на странице мониторинга в Embedded UI.

Автоматическое конфигурирование

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

actor_system_config:
  use_auto_config: true
  node_type: STORAGE
  cpu_count: 10

Ручное конфигурирование

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

actor_system_config:
  executor:
  - name: System
    spin_threshold: 0
    threads: 2
    type: BASIC
  - name: User
    spin_threshold: 0
    threads: 3
    type: BASIC
  - name: Batch
    spin_threshold: 0
    threads: 2
    type: BASIC
  - name: IO
    threads: 1
    time_per_mailbox_micro_secs: 100
    type: IO
  - name: IC
    spin_threshold: 10
    threads: 1
    time_per_mailbox_micro_secs: 100
    type: BASIC
  scheduler:
    progress_threshold: 10000
    resolution: 256
    spin_threshold: 0

Контроллер памяти

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

Примеры компонентов, управляемых контроллером памяти:

• Общий кеш: хранит недавно доступные страницы данных, считанные из распределённого хранилища, чтобы уменьшить количество операций ввода-вывода с диска и ускорить получение данных.
• MemTable: содержит данные, которые ещё не были записаны в SST.
• KQP: хранит промежуточные результаты обработки запросов.
• Кеши аллокатора: хранят блоки памяти, которые были освобождены, но ещё не возвращены операционной системе.

Лимиты памяти могут быть настроены для контроля общего использования памяти, обеспечивая эффективную работу базы данных в рамках доступных ресурсов.

Жёсткий лимит памяти

Жёсткий лимит памяти определяет общее количество памяти, доступное для процесса YDB.

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

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

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

Большинство других лимитов памяти можно настроить либо в абсолютных байтах, либо в процентах относительно жёсткого лимита памяти. Использование процентов удобно для управления кластерами с узлами разной ёмкости. Если указаны как абсолютные лимиты в байтах, так и процентные лимиты, контроллер памяти использует комбинацию обоих (максимум для нижних лимитов и минимум для верхних лимитов).

Пример секции memory_controller_config с указанным жёстким лимитом памяти:

memory_controller_config:
  hard_limit_bytes: 16106127360

Мягкий лимит памяти

Мягкий лимит памяти определяет опасный порог, который процесс YDB не должен превышать при нормальных обстоятельствах.

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

Целевое использование памяти

Целевое использование памяти определяет порог использования памяти процессом YDB, который считается оптимальным.

Гибкие размеры кешей рассчитываются в соответствии с их пределами, чтобы поддерживать потребление памяти процессом вблизи этого значения.

Например, в базе данных, которая расходует немного памяти на выполнение запросов, кеши используют память вблизи этого порога, а остальная память остаётся свободной. Если выполнение запросов начинает потреблять больше памяти, кеши начинают сокращать свои размеры до минимального порога.

Лимиты памяти для отдельных компонентов

Внутри YDB существует два разных типа компонентов.

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

Второй тип компонентов, или компоненты-активности, выделяют память для конкретных задач, таких как выполнение запросов или процесс компактизации. Каждый компонент-активность имеет фиксированный лимит памяти. Также существует дополнительный общий лимит памяти для таких компонентов, из которого они пытаются получить необходимую память.

Многие другие вспомогательные компоненты и процессы работают параллельно с процессом YDB, потребляя память. В настоящее время эти компоненты не имеют каких-либо лимитов памяти.

Лимиты памяти для кеш-компонентов

К кеш-компонентам относятся:

• Общий кеш;
• MemTable.

Лимиты каждого кеш-компонента динамически пересчитываются каждую секунду, чтобы каждый компонент потреблял память пропорционально своим предельным значениям, а общее потребление памяти оставалось около целевого использования памяти.

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

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

Пример секции memory_controller_config с указанными лимитами общего кеша:

memory_controller_config:
  shared_cache_min_percent: 10
  shared_cache_max_percent: 30

Лимиты памяти для компонентов-активностей

К компонентам-активностям относятся:

• KQP.

Лимит памяти для каждого из компонентов-активностей указывает максимальное количество памяти, которое он может попытаться использовать. Однако, чтобы предотвратить превышение процессом YDB мягкого лимита памяти, общее потребление компонентов-активностей ограничивается дополнительным лимитом, называемым лимитом памяти для активностей. Если общее использование памяти активными компонентами превышает этот лимит, любые дополнительные запросы на память будут отклонены.

Таким образом, хотя суммарные индивидуальные лимиты компонентов-активностей могут в совокупности превышать лимит памяти для активностей, индивидуальный лимит каждого компонента должен быть меньше этого общего предела. Кроме того, сумма минимальных лимитов памяти для кеш-компонентов плюс лимит памяти для активностей должна быть меньше мягкого лимита памяти.

Существуют и другие компоненты-активности, которые в настоящее время не имеют каких-либо индивидуальных лимитов памяти.

Пример секции memory_controller_config с указанным лимитом для KQP:

memory_controller_config:
  query_execution_limit_percent: 25

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

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

Как упоминалось ранее, ожидается, что сумма минимальных лимитов памяти для кеш-компонентов плюс лимит памяти для активностей должна быть меньше мягкого лимита памяти.

Это ограничение можно выразить в упрощённой форме:

$shared\_cache\_min\_percent + mem\_table\_min\_percent + activities\_limit\_percent < soft\_limit\_percent$

Или в детализированной форме:

$Max(shared\_cache\_min\_percent * hard\_limit\_bytes / 100, shared\_cache\_min\_bytes) + Max(mem\_table\_min\_percent * hard\_limit\_bytes / 100, mem\_table\_min\_bytes) + Min(activities\_limit\_percent * hard\_limit\_bytes / 100, activities\_limit\_bytes) < Min(soft\_limit\_percent * hard\_limit\_bytes / 100, soft\_limit\_bytes)$

blob_storage_config — статическая группа кластера

Укажите конфигурацию статической группы кластера. Статическая группа необходима для работы базовых таблеток кластера, в том числе Hive, SchemeShard, BlobstorageContoller.
Обычно данные таблетки не хранят много информации, поэтому мы не рекомендуем создавать более одной статической группы.

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

blob_storage_config:
  service_set:
    groups:
    - erasure_species: none
      rings:
      - fail_domains:
        - vdisk_locations:
          - node_id: 1
            path: /dev/disk/by-partlabel/ydb_disk_ssd_02
            pdisk_category: SSD
# ...

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

Конфигурирование провайдеров аутентификации

YDB позволяет использовать различные способы аутентификации пользователя. Конфигурирование провайдеров аутентификации задается в секции auth_config.

Конфигурация LDAP аутентификации

Одним из способов аутентификации пользователей в YDB является использование LDAP каталога. Подробнее о таком виде аутентификации написано в разделе про взаимодействие YDB с LDAP каталогом. Для конфигурирования LDAP аутентификации необходимо описать секцию ldap_authentication.

Пример секции ldap_authentication:

auth_config:
  #...
  ldap_authentication:
    hosts:
      - "ldap-hostname-01.example.net"
      - "ldap-hostname-02.example.net"
      - "ldap-hostname-03.example.net"
    port: 389
    base_dn: "dc=mycompany,dc=net"
    bind_dn: "cn=serviceAccaunt,dc=mycompany,dc=net"
    bind_password: "serviceAccauntPassword"
    search_filter: "uid=$username"
    use_tls:
      enable: true
      ca_cert_file: "/path/to/ca.pem"
      cert_require: DEMAND
  ldap_authentication_domain: "ldap"
  scheme: "ldap"
  requested_group_attribute: "memberOf"
  extended_settings:
      enable_nested_groups_search: true

  refresh_time: "1h"
  #...

Настройка стабильных имен узлов кластера

Присвоение имен узлам осуществляет Node Broker — системная таблетка, которая отвечает за регистрацию динамических узлов в кластере YDB.

Node Broker присваивает имена динамическим узлам при их регистрации в кластере. По умолчанию имя узла состоит из имени хоста и номера порта, на котором работает узел.

В динамической среде, где имена хостов часто меняются, например в Kubernetes, использование имени хоста и порта приводит к неконтролируемому росту количества уникальных имен узлов, даже для базы данных с небольшим количеством динамических узлов. Подобное поведение может быть нежелательным для системы time series мониторинга — количество метрик растет некотролируемо. Для решения этой проблемы администратор системы может настроить стабильные имена узлов.

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

Чтобы включить стабильные имена узлов, необходимо добавить в конфигурацию кластера следующее:

feature_flags:
  enable_stable_node_names: true

По умолчанию, префиксом является slot-. Для того, чтобы переопределить префикс, необходимо добавить в конфигурацию кластера следующее:

node_broker_config:
  stable_node_name_prefix: <новый префикс>

resource_broker_config — брокер ресурсов

Брокер ресурсов — это акторный сервис, контролирующий потребление ресурсов узла YDB, таких как:

• CPU — количество потоков;
• Memory — оперативная память.

Разные виды активностей (фоновые операции, удаление данных по TTL и т.д.) запускаются в разных очередях брокера ресурсов. Каждая такая очередь имеет лимитированное число ресурсов:

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

resource_broker_config: !inherit
  queues: !append
  - name: queue_ttl
    limit:
      cpu: 4

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

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