logo

Конфигурация ZDS

Общая информация

Конфигурация задаётся для каждого узла и определяет:

  • идентификацию узла и режим работы (nodeName, mode, при необходимости protocolPrefix);
  • параметры логирования (log);
  • внешний и внутренний HTTP API (server, clusterServer);
  • настройки исходящего HTTP-клиента к другим узлам (client);
  • схему хранения данных (providers для EC и FC);
  • фоновые процессы синхронизации, журнала, сканирования и восстановления (workers);
  • расписание и состояние вакуума (vacuum);
  • локальный реестр метаданных (registry);
  • состав кластера (nodes);
  • диски узла: пороги, бенчмарки и список точек монтирования (drive).

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

Когда требуется настраивать конфигурацию

Настройка актуальна:

  • при первичном развёртывании кластера;
  • при добавлении узлов или дисков;
  • при изменении сетевых адресов или TLS;
  • при подборе производительности фоновых задач и ограничений клиента.

Изменения параметров схемы EC/FC, состава nodes и привязки дисков к группам хранения следует планировать отдельно и оценивать влияние на уже размещённые данные.

Обязательные параметры

Для согласованной работы кластера обычно задаются следующие группы параметров.

Параметры текущего узла

  • nodeName — имя текущего узла. Должно совпадать с одним из элементов списка nodes (поле name).

Режим работы

  • mode — режим работы: ec.

Список узлов кластера

  • nodes — описание узлов кластера.

Для каждого элемента:

  • nodes[i].name — имя узла в кластере;
  • nodes[i].driveCount — количество дисков на узле;
  • nodes[i].hostPort — адрес и порт узла для внешних запросов;
  • nodes[i].clusterHostPort — адрес и порт узла для внутренней коммуникации кластера (необязательный параметр).

Диски узла

  • drive.list — список монтируемых дисков/томов на данном узле.
  • drive.defaultStorageClass — класс хранения по умолчанию для вольюмов, созданных без явного указания класса (необязательный параметр).

Для каждого элемента:

  • drive.list[i].index — индекс диска;
  • drive.list[i].path — путь к директории хранения;
  • drive.list[i].storageGroup — индекс группы хранения;
  • drive.list[i].storageClass — класс хранения (необязательный параметр).

Параметры провайдеров хранения

В зависимости от режима и политики размещения задаётся секция providers:

Erasure coding (providers.ec):

  • dataPart — количество частей данных для кодирования;
  • parityPart — количество частей чётности для восстановления;
  • blockSize — размер блока в байтах для EC-кодирования;
  • cleanup — удаление загруженных партов при неуспешной загрузке или восстановлении.

Full copy (providers.fc):

  • replicaCount — максимальное число реплик для групп хранения по умолчанию. Указывается, если EC отключён глобально (параметры dataPart и parityPart не заданы);
  • maxFullCopySize — максимальный размер файла в байтах, при котором используется FC;
  • cleanup — удаление загруженных партов при неуспешной загрузке или восстановлении.

Параметры сервера

Внешний API узла:

  • server.host — хост для API сервера;
  • server.port — порт для API сервера;
  • server.accessKey — ключ доступа;
  • server.secretKey — секретный ключ.

TLS (внешний API)

  • server.tls.enable — включение TLS (true / false);
  • server.tls.key — путь к TLS-ключу (обязательно при enable=true);
  • server.tls.crt — путь к TLS-сертификату (обязательно при enable=true).

Параметры внутреннего взаимодействия

Внутренний API для межузлового обмена:

  • clusterServer.host — хост для API внутренних взаимодействий кластера;
  • clusterServer.port — порт этого API;
  • clusterServer.accessKey — ключ доступа;
  • clusterServer.secretKey — секретный ключ.

TLS (внутренний API)

  • clusterServer.tls.enable — включение TLS;
  • clusterServer.tls.key — путь к ключу (при включённом TLS);
  • clusterServer.tls.crt — путь к сертификату (при включённом TLS).

Межузловые запросы разумно направлять на выделенный внутренний порт, не смешивая их с внешним API.

Доступ к узлам и протокол

  • protocolPrefix — префикс протокола для доступа к узлам (по умолчанию http://). Необязательный параметр.

Параметры HTTP-клиента

Настройки клиента при обращении к другим узлам:

  • client.maxIdleConnsPerHost — максимальное число неактивных соединений на хост;
  • client.maxConnsPerHost — максимальное общее число открытых соединений на хост;
  • client.timeout — таймаут на выполнение запроса;
  • client.dialTimeout — таймаут на установку TCP-соединения;
  • client.accessKey — ключ доступа;
  • client.secretKey — секретный ключ.

Параметры кластера и фоновых процессов

Фоновая логика задаётся в секции workers.

Синхронизация узлов и томов (workers.nodeSync)

  • period — интервал выполнения запроса получения статуса внешнего узла (необязательный параметр);
  • heartbeat — интервал выполнения heartbeat (необязательный параметр);
  • statusReqTimeout — таймаут выполнения запроса статуса (необязательный параметр);
  • volumeSyncPeriod — интервал выполнения синхронизации вольюмов (необязательный параметр);
  • volumeSyncRetryPeriod — интервал ретрая при неуспешном запросе вольюмов с внешнего узла (необязательный параметр);
  • volumeSyncReqTimeout — таймаут выполнения запроса вольюмов (необязательный параметр);
  • destroyedVolumesCleanupPeriod — интервал, через который запись о вольюме со статусом DESTROYED, подтверждённым на всех узлах кластера, удаляется из реестра (необязательный параметр).

Обрезка журнала изменений (workers.changelogCut)

  • period — интервал выполнения проверки размера ченджлога (необязательный параметр);
  • cutBatchCount — количество записей, удаляемых за одну операцию удаления (необязательный параметр);
  • maxSize — максимальный размер ченджлога;
  • cutSize — количество записей, удаляемое при переполнении с конца (в несколько операций по cutBatchCount).

Синхронизация ченджлога (workers.changelog)

  • period — интервал выполнения синхронизации ченджлога (необязательный параметр);
  • workersCount — количество воркеров, выполняющих синхронизацию отдельных операций;
  • syncBatchSize — размер пачки операций, обрабатываемой параллельно для каждого внешнего узла;
  • operationsReqTimeout — таймаут выполнения запроса получения операций (необязательный параметр);
  • metadataReqTimeout — таймаут выполнения запроса получения метаданных (необязательный параметр);
  • fileReqTimeout — таймаут выполнения синхронизации файла (необязательный параметр).

Сканирование (workers.scan)

  • timeout — таймаут одного цикла сканирования (необязательный параметр);
  • workersCount — количество воркеров, выполняющих локальное сканирование (необязательный параметр);
  • queueCapacity — размер буфера канала очереди задач сканирования (необязательный параметр);
  • schedule — расписание временных окон автозапуска. Сканирование запускается только внутри заданных окон, при выходе из окна останавливается и сохраняет checkpoint. Элементы могут включать:
    • dayOfWeek — день недели (0 — воскресенье, 1 — понедельник и т.д., необязательный параметр);
    • hour — час запуска, по умолчанию 0 (необязательный параметр);
    • minute — минута запуска, по умолчанию 0 (необязательный параметр);
    • second — секунда запуска, по умолчанию 0 (необязательный параметр).

Ручной запуск через POST /admin/scan/start работает независимо от расписания и сбрасывает checkpoint. Подробнее см. API ZDS.

Восстановление (workers.repair)

  • timeout — таймаут на восстановление одного файла (необязательный параметр);
  • workersCount — количество воркеров для восстановления повреждённых файлов (необязательный параметр).

Параметры реестра и журнала на диске

Секция registry задаёт локальное хранилище метаданных и параметры работы с журналом:

  • registry.path — путь для хранения данных регистра;
  • registry.commitInterval — период автоматического коммита изменений;
  • registry.batchLimit — максимальное число изменений в одном батче;
  • registry.changelogListPageSize — число отдаваемых при листинге записей по каждой группе хранения.

Эти параметры влияют на синхронизацию и на восстановление состояния после сбоев.

Вакуум

  • vacuum.enabled — включение работы вакуума в технологические окна;
  • vacuum.storePath — путь для хранения данных вакуума;
  • vacuum.windows — список временных окон автозапуска. Вакуум запускается только внутри заданных окон, при выходе из окна останавливается и сохраняет checkpoint:
    • days — список дней недели, в которые выполняется вакуум (0 — воскресенье, 1 — понедельник и т.д.);
    • start — время начала окна;
    • duration — длительность окна.

Ручной запуск через POST /admin/vacuum/start работает независимо от расписания и сбрасывает checkpoint. Подробнее см. API ZDS.

Диски: пороги и бенчмарки

Общие параметры дисков:

  • drive.pingTimeout — таймаут выполнения операции пинга диска, после которого он переходит в ERROR (необязательный параметр);
  • drive.capacityThreshold — минимальный процент свободного места по inode и вместимости, после которого диск перейдёт в FULL (0–100, необязательный параметр).

Бенчмарк перед инициализацией (drive.bench)

  • enabled — включение снятия бенчмарков перед инициализацией дисков (необязательный параметр);
  • test_directory — директория, в которой будут создаваться файлы во время проведения бенчмарка (необязательный параметр);
  • cleanup_after_benchmark — очищать директорию после проведения бенчмарка (необязательный параметр).

Последовательная запись (sequential_write):

  • enabled — включение бенчмарка на sequential write (необязательный параметр);
  • file_size — размер файла для sequential write в байтах (необязательный параметр);
  • block_size — размер одной операции записи в байтах (необязательный параметр);
  • concurrency — количество одновременных горутин в бенчмарке (необязательный параметр).

Последовательное чтение (sequential_read):

  • enabled — включение бенчмарка на sequential read (необязательный параметр);
  • file_size — размер файла для sequential read в байтах (необязательный параметр);
  • block_size — размер одной операции чтения в байтах (необязательный параметр);
  • concurrency — количество одновременных горутин в бенчмарке (необязательный параметр).

IOPS (iops):

  • enabled — включение бенчмарка на IOPS (необязательный параметр);
  • duration — длительность бенчмарка на IOPS (необязательный параметр);
  • file_size — размер файла для бенчмарка на IOPS в байтах (необязательный параметр);
  • block_size — размер одной операции для бенчмарка на IOPS в байтах (необязательный параметр);
  • concurrency — количество одновременных горутин в бенчмарке (необязательный параметр);
  • random_access — использовать случайный или последовательный доступ для бенчмарка (необязательный параметр).

Дополнительные параметры

Логирование

  • log.format — формат вывода логов (text, json);
  • log.level — уровень логирования (debug, info, warn, error);
  • log.title — название сервиса в логах.

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

Минимальный пример конфигурации приложения ZDS для запуска

1nodeName: zds-0.zds-headless:8080
2protocolPrefix: "http://"
3mode: "ec"
4log:
5  format: json
Развернутьarrow

В примере не отражены все возможные необязательные поля (например, workers.scan.workersCount или clusterHostPort у узлов); их следует добавлять по необходимости.

Политики хранения групп (storagePolicyOverrides)

По умолчанию все группы хранения поддерживают как EC, так и FC политики. Параметр storagePolicyOverrides позволяет переопределить это поведение для конкретных групп.

Пример: отключить EC для группы хранения 2 и ограничить FC фактором репликации не более 4:

1storagePolicyOverrides:
2  - groups: [2]
3    policy:
4      allowEC: false
5      maxReplicas: 4
  • groups — список индексов групп хранения, для которых применяется переопределение.
  • policy.allowEC — разрешить EC-политики для группы (true по умолчанию). При значении false группа поддерживает только FC-политики.
  • policy.maxReplicas — максимальный фактор репликации для группы. Обязателен, если allowEC: false. Доступный диапазон FC для группы: от 1 до maxReplicas.

Для групп с включённым EC указывать maxReplicas не нужно — диапазон FC определяется автоматически из параметров EC: от parityPart + 1 до dataPart + parityPart.

Изменение схемы EC на существующем кластере

Начиная с ZDS v2.1.0, в рамках одного кластера можно одновременно использовать несколько схем EC. Это позволяет перейти на новую схему (например, с dataPart: 2, parityPart: 1 на dataPart: 3, parityPart: 1) без полного переноса данных на отдельный кластер.

Для добавления новой схемы создаётся новая группа хранения (storageGroup) с нужными параметрами EC. Записи в существующие группы при этом продолжаются без прерывания.

Способ 1: новые диски на существующих узлах

Если на узлах кластера есть свободные диски:

  1. В конфигурации каждого узла добавьте новые диски в drive.list с новым индексом storageGroup:
1drive:
2  list:
3    - index: 1
4      path: /mnt/ps/data/volume1
5      storageGroup: 1        # существующая группа
6    - index: 4
7      path: /mnt/ps/data/volume4
8      storageGroup: 2        # новая группа с новой схемой
  1. В секции providers.ec задайте параметры новой схемы:
1providers:
2  ec:
3    dataPart: 3
4    parityPart: 1

Параметры providers.ec применяются к записям в новую группу хранения. Данные в существующих группах продолжают обслуживаться по прежней схеме.

  1. Выполните последовательный перезапуск узлов кластера (по одному). Repair не требуется: новые группы хранения имеют нулевые смещения на всех узлах и не нуждаются в синхронизации данных.

Способ 2: добавление нового узла

Если новые диски добавляются вместе с новым узлом:

  1. Запустите новый узел ZDS с конфигурацией, в которой диски привязаны к новому storageGroup. Новые группы хранения на нём будут в статусе ERROR — это ожидаемое состояние.
  2. Новый узел выполняет repair: загружает метаданные кластера с существующих узлов.
  3. После завершения repair выполните последовательный перезапуск остальных узлов с обновлённой конфигурацией, в которой указан новый узел и добавлена новая группа хранения на их дисках.

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

Связанные статьи

Для состояний компонентов см. Кластер ZDS и состояния компонентов.

Для API см. API ZDS.

Смотрите также
Кластер ZDS и состояния компонентов
API ZDS
Рекомендации к подбору схемы Erasure Coding