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

Статическая конфигурация кластера задается в 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

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:
    host: "ldap-hostname.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"
  refresh_time: "1h"
  #...

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

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

Режимы отказоустойчивости

Для промышленных инсталляций YDB рекомендуется использовать следующие [режимы отказоустойчивости](../concepts /topology.md):

• block-4-2 — если кластер расположен в одной зоне доступности.
• mirror-3-dc — если кластер расположен в трех зонах доступности.

В модели отказа YDB различаются понятия домена отказа и области отказа.

Домен отказа (fail domain)

Набор оборудования, для которого вероятен одновременный отказ.

Например, доменом отказа можно считать диски одного сервера (в связи с вероятной недоступностью всех дисков сервера при отказе блока питания или сетевого контроллера сервера). Также доменом отказа можно считать серверы, расположенные в одной серверной стойке (в связи с вероятной недоступностью всего оборудования в стойке при проблемах с питанием или сетевым оборудованием, расположенным в той же стойке).

Обработка любых отказов домена осуществляется автоматически, без остановки работы системы.

Область отказа (fail realm)

Набор доменов отказа, для которого вероятен одновременный отказ.

Например, областью отказа можно считать оборудование, расположенное в одном центре обработки данных (ЦОД), который может выйти из строя в результате стихийного бедствия.

Обычно под доменом отказа подразумевается серверная стойка, а под областью отказа – ЦОД.

При создании групп хранения YDB объединяет в группы VDisk, расположенные на PDisk из разных доменов отказа. Таким образом, для режима block-4-2 необходимо распределение PDisk по не менее чем 8 доменам отказа, а для режима mirror-3-dc — по 3 областям отказа с не менее чем 3 доменами отказа в каждой.

Аппаратная конфигурация

При отказе диска YDB может автоматически переконфигурировать группу хранения так, чтобы вместо расположенного на отказавшем оборудовании VDisk использовался новый VDisk, который система пытается расположить на работающем в момент реконфигурации оборудовании. При этом соблюдается то же правило, что и при создании группы — VDisk создается в домене отказа, отличном от доменов отказа всех остальных VDisk этой группы (и в той же области отказа, что и отказавший VDisk для mirror-3-dc).

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

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

Если же в кластере доступно хотя бы на 1 домен отказа больше, чем минимально необходимо для создания групп хранения (9 доменов для block-4-2 и по 4 домена в каждой области отказа для mirror-3-dc), то при отказе части оборудования нагрузка может быть перераспределена по всему оставшемуся в строю оборудованию.

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

Например, в кластере с режимом отказоустойчивости block-4-2 имеется 15 стоек. В первой из 15 стоек расположено 20 серверов, а в остальных 14 стойках — по 10. Для полноценной утилизации всех 20 серверов из первой стойки YDB будет создавать группы так, что в каждой из них будет участвовать 1 диск из этого самого большого домена отказа. В результате при выходе из строя оборудования в любом другом домене отказа нагрузка не сможет быть распределена на оборудование в первой стойке.

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

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

• Кластер в 1 зоне доступности — использует режим отказоустойчивости block4-2 и состоит из 9 или более стоек с равным количеством одинаковых серверов в каждой.
• кластер в 3 зонах доступности — использует режим отказоустойчивости mirror3-dc и расположен в 3 ЦОД с 4 или более стойками в каждом, стойки укомплектованы равным количеством одинаковых серверов.

Смотрите также Упрощенные аппаратные конфигурации.

Восстановление избыточности

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

После реконфигурации новый VDisk автоматически наполняется данными для восстановления требуемой избыточности хранения в группе. При этом возникает повышенная нагрузка на остальные VDisk группы и на сеть. Для снижения влияния восстановления избыточности на производительность системы суммарная скорость репликации данных ограничивается как на стороне VDisk-источника так и на стороне VDisk-получателя.

Время восстановления избыточности при этом зависит от объема данных и от производительности оборудования. Например, репликация на быстрых NVMe SSD может завершиться за час, а на больших HDD репликация может длиться более суток. Для того, чтобы реконфигурация в принципе была возможной, в кластере должны быть свободные слоты для создания VDisk в разных доменах отказа. При расчете количества оставляемых свободными слотов следует учитывать вероятность отказа оборудования, длительность репликации, время, необходимое на замену отказавшего оборудования.

Упрощенные аппаратные конфигурации

В случаях, когда невозможно использовать рекомендованное количество оборудования, можно разделить серверы одной стойки на 2 фиктивных домена отказа. В такой конфигурации отказ 1 стойки будет означать отказ не 1, а сразу 2 доменов. В обоих режимах отказоустойчивости YDB сохранит работоспособность при отказе 2 доменов. При использовании конфигурации с фиктивными доменами отказа минимальное количество стоек в кластере для режима block-4-2 составляет 5, для mirror-3-dc — по 2 в каждом ЦОД.

Уровень отказоустойчивости

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

Конфигурация Node Broker

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

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

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

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

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

feature_flags:
  enable_stable_node_names: true

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

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

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

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