nav-img
Evolution

Администрирование Storage Cluster

MDS

Metadata-сервер (MDS) хранит все метаданные блочных устройств в RAFT-реплицированном хранилище типа ключ-значение. К таким данным относятся имена томов, чанки и их состояние, список чанк-серверов в кластере, пользовательские данные и другое.

Metadata-сервер управляет системными активностями — восстановлением чанков в случае отказа чанк-сервера, миграцией чанков между чанк-серверами для балансировки.

Примечание

Рекомендуется развертывать 3 или 5 экземпляров MDS сервера на кластер.

Создание первого MDS (инициализация кластера)

Команда создает новый кластер, метадата сервер и пользователя admin с заданным паролем:

sudo storage --cluster 123 mds make --init-cluster --password qwerty --address 192.168.0.1 --root /mnt/storage/mds --cluster.name mycluster123

Где:

  • --cluster 123 — уникальный ID нового кластера;

  • --password qwerty — пароль администратора кластера — пользователя admin;

  • --address 192.168.0.1 — адрес MDS из публичной сети;

  • --root /mnt/storage/mds — директория MDS для хранения метаданных;

  • --cluster.name — имя кластера.

Команда сохраняет secret (пароль) пользователя admin в файле /etc/storage/auth.yml для дальнейшей авторизации. MDS-конфигурация сохраняется в /etc/storage/mds.1/mds.yml.

Запуск MDS-сервиса и включение автозапуска:

systemctl start storage-mds@1.service
systemctl enable storage-mds@1.service

Добавление MDS в кластер

  1. Авторизуйте хост и сохраните secret пользователя admin в файле /etc/storage/auth.yml для дальнейшей авторизации:

    sudo storage --cluster 123 --mds.address 192.168.0.1 user login --name admin --password qwerty
  2. Создайте новый MDS в существующем кластере:

    sudo storage --cluster 123 --mds.address 192.168.0.1 mds make --address 192.168.0.2 --root /mnt/storage/mds

    Где:

    • --cluster 123 — кластер ID, к которому присоединяется новый MDS;

    • --mds.address 192.168.0.1 — адрес запущенного MDS в кластере;

    • --address 192.168.0.2 — адрес MDS из публичной сети;

    • --root /mnt/storage/mds — директория MDS для хранения метаданных.

Внимание

Проверьте, что владелец и группа у /mnt/storage/mds имеют значение storage.

Запуск MDS сервера и включение автозапуска

systemctl start storage-mds@{MDSID}.service
systemctl enable storage-mds@{MDSID}.service

Удаление MDS

  1. Укажите ID MDS сервера и выполните команду:

    # Пример для MDS ID=1
    storage mds rm --id 1
  2. Остановите systemd сервис на хосте, связанным с нужным MDS:

    systemctl stop storage-mds@1.service
    systemctl disable storage-mds@1.service
  3. При необходимости удалите данные сервиса из root директории MDS:

    rm -rf /mnt/storage/mds
    rm -rf /etc/storage/mds.1
    rm -f /var/log/storage/mds.1*
Примечание

При удалении MDS убедитесь, что кворум в кластере сохраняется.

Листинг MDS

storage mds list
ID ADDRESS NET-STATUS RAFT-STATUS UPTIME MAINTENANCE VERSION
1 172.255.50.58:60003 online ready 86h49m44s false 1.1.61
*2 172.255.50.59:60003 online ready 86h49m37s false 1.1.61
3 172.255.50.60:60003 online ready 63h28m40s false 1.1.61

Где:

  • ID — идентификатор тома (2 - идентификатор лидера);

  • ADDRESS — адрес MDS-сервера и его RPC-порт;

  • NET-STATUS — сетевое состояние MDS (подробнее в разделе Статусы MDS);

  • RAFT-STATUS — состояние RAFT (подробнее в разделе Статусы RAFT);

  • UPTIME — время работы MDS с последнего запуска;

  • maintenance — True/False, при значении True лидер перемещается на другой сервер;

  • VERSION — версия storage-mds пакета.

Конфигурационный файл MDS

Конфигурационный файл расположен по пути /etc/storage/mds.ID.yml.

mds_id: 1
cluster_id: 123
cluster_name: mycluster
cluster_uuid: 06ab88bc-915a-4245-a6ba-3aa363d6ff53
root: /mnt/storage/mds
address: 192.168.100.13
raft_port: 60001
grpc_port: 60002
rpc_port: 60003
prom_port: 60080
debug_port: 60081
tos: 16
trace_ip: 127.0.0.1
trace_port: 14268
trace_enabled: false
log_dir: /var/log/storage
log_level: info
syslog_enabled: false
syslog_network: ""
syslog_raddr: ""
syslog_tag: ""

Где:

  • mds_id — идентификатор MDS;

  • cluster_id — идентификатор кластера;

  • cluster_name — имя кластера;

  • cluster_uuid — уникальный идентификатор кластера (128bit UUID v4);

  • root — директория с данными сервера;

  • address — fqdn-адрес, на котором работает MDS;

  • raft_port, grpc_port, rpc_port, prom_port, debug_port — порты серверов;

  • tos — type of service для MDS трафика (по умолчанию 16 или 0x10 - minimize delay);

  • trace_ip, trace_port — endpoint коллектора трейсов;

  • trace_enabled — включено/выключено отправление трейсов;

  • log_dir — директория для логов;

  • log_level — уровень логирования (error, warn, info, debug, trace);

  • syslog_enabled — включено/выключено логирование в syslog. При включении логи из файла mds-audit.log будут также попадать в syslog;

  • syslog_network — UDP/TCP-протоко` для отправки в syslog по сети. Пустое значение означает запись в локальный файл /var/log/syslog;

  • syslog_raddr — IP-адрес удаленного syslog-сервера. Пустое значение означает запись в локальный файл /var/log/syslog;

  • syslog_tag — дополнительный тэг для логов.

Chunk-server (CS)

Chunk-сервер хранит данные тома и обрабатывает IO-запросы к нему.

Данные тома разбиваются на чанки и размещаются в кластере хранения SDS в нескольких копиях (репликах) или кодируются с помощью кодов Рида-Соломона. Каждый чанк-сервер — это служба, управляющая одним физическим диском в кластере или одной физической партицией диска.

Примечание

На один диск/партицию приходится один CS.

Создание гибридного CS (HDD+SSD)

sudo storage cs make --root /mnt/storage/nvme0n1p0 --root.cold /mnt/storage/sdb

Где:

  • --root /mnt/storage/nvme0n1p0 — директория CS для горячих данных (реплики);

  • --root.cold /mnt/storage/sdb — директория CS для холодных данных (erasure coding).

Команда storage cs make:
  • инициализирует новый репозиторий в указанной директории;

  • создает файлы конфигурации /etc/storage/cs.${CS_ID}/, /${ROOT/control/repo.yml;

  • регистрирует сервис в кластере на MDS;

  • регистрирует сервис в systemd.

Создание «AllFlash» CS(SSD)

sudo storage cs make --root /mnt/storage/nvme0n1p0

Где:

  • --root /mnt/storage/nvme0n1p0 — директория CS для горячих данных (реплики).

Запуск CS сервиса и включение автозапуска

systemctl start storage-csd@{CSID}.service
systemctl enable storage-csd@{CSID}.service

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

Узнать статус сервера:

storage cs list —-id $CSID

Удаление CS

Удаление CS из кластера требуется при замене вышедшего из строя диска или хоста.

Внимание

Перед удалением убедитесь, что:

  1. Количество оставшихся CS достаточно для хранения данных с текущим фактором репликации.

  2. Имеется достаточно свободного места для переноса чанков с удаляемого сервера.

  1. Получите список CS и их идентификаторов:

    storage cs list

    Пример вывода:

    ID HOST TIER MGMT-STATUS STATUS ADDRESS UPTIME LAST-SCRUB ISSCRUBBING COLD-SPACE HOT-SPACE VERSION
    1 985403c287ad0aa0 0 ok active 172.255.50.58:59001 70h27m0s never false 629.00GB/643.03GB 64.92GB/65.02GB 0.1.82
    2 f5854a8307e3e7be 0 ok active 172.255.50.59:59002 70h24m5s never false 626.98GB/643.03GB 64.73GB/65.02GB 0.1.82
    3 db9dc1a0a2dfe307 0 ok active 172.255.50.62:59003 70h28m8s never false 623.91GB/643.03GB 64.68GB/65.02GB 0.1.82
  2. Удалите CS из кластера (например, с ID=1):

    storage cs rm --id 1

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

  3. После завершения миграции CS перейдет в состояние DROPPED и пропадет из списка. Остановите systemd сервис на хосте:

    systemctl stop storage-csd@1.service
    systemctl disable storage-csd@1.service
  4. Данные сервиса остаются root директории CS. Удалите данные (при необходимости):

    rm -rf /mnt/storage/nvme0n1p0 \
    /etc/storage/cs.1 \
    /var/log/storage/cs.1*
Примечание

Не прерывайте процесс удаления (статус RELEASING) и не удаляйте его данные — это может привести к потере данных.

Листинг Chunk Server

Для просмотра списка чанк-серверов используйте:

storage cs list [--id $CSID]

Альтернативный вариант просмотра:

storage top # "cses"

Конфигурация Chunk Server

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

  • Статические (нельзя изменить после создания сервиса):

    --root value, -r value Root directory to store CS state and hot data
    --root.cold value, --rc value Root directory to store cold CS data (for hybrid setup)
    --tier value Storage tier (default: 0)
    --repo.block-size value Physical block size (default: 4096)
    --repo.cold-wal-size value Max size for the cold storage WAL (default: 1% of total space at filesystem at root.cold)
    --repo.hot-stor-size value Size for the hot storage. Includes data in replicas and WALs (default:AllFlash: 5% of total space at filesystem at root; Hybrid: 100% of total space at filesystem at root)
    --repo.hot-wal-size value Size for the hot storage WAL (default: 1% of hot storage size)
    --repo.prefill-cold-balloc Prefill block allocator with zeroes on CS initialization (default: false)
    --repo.prefill-cold-wal Prefill WAL with zeroes on CS initialization (default: false)
    --repo.prefill-hot-balloc Prefill block allocator with zeroes on CS initialization (default: false)
    --repo.prefill-hot-wal Prefill WAL with zeroes on CS initialization (default: false)
  • Динамические (задаются при создании, можно изменить в конфигурации, для этого потребуется рестарт сервиса):

    --port value CS port to listen on (default: 59000+CSID in [59000, 59999] range)
    --prometheus.port value Prometheus port for CS metrics (default: 58000+CSID in [58000, 58999] range)
    --log.dir value Log directory for CS (default: by default CS logs are stored at root.cold with symlinks at /var/log/storage)
    --log.level value Log level: error, warn, info, debug, trace (default: Default value is set by CS itself or by cs.conf)
    --cold.cache-capacity value Cold storage cache capacity (default: Default value is set by CS itself or by cs.conf)
    --cold.recovery-max-mem value Maximum memory for recovery tasks (default: Default value is set by CS itself or by cs.conf)
    --cold.scrub-max-mem value Maximum memory for scrub tasks (default: Default value is set by CS itself or by cs.conf)
    --hot.target-usage value % target range of hot storage usage, format: range (ex: "10-20") or single number (ex: "15") (default: Default value is set by CS itself or by cs.conf)
    --max-open-chunks value maximum number of open chunks at the same time (default: Default value is set by CS itself or by cs.conf)
    --seastar.cpuset value CPUs to use
    --seastar.disable-poll-aio Busy-poll for linux AIO operations (default: false)
    --seastar.loglevel value Default log level for log messages. Valid values are trace, debug, info, warn, error (default: "info")
    --seastar.memory value Memory to use (e.g. 4GB) (default: 4.00GB)
    --seastar.smp value Number of threads (default: 1)
    --seastar.thread-affinity Pin threads to their CPUs (default: false)
Примечание

Динамические параметры сохраняются в: - Локальный конфиг: /etc/storage/cs.$CSID/ - Общий конфиг хоста: /etc/storage/cs/

Локальные параметры имеют приоритет над общими.

С полным списком параметров можно ознакомиться в в Руководстве администратора Chunk Server.

Скраббинг (Scrub)

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

Существует 2 уровня:

  1. Обычный скраббинг:

    • Проверяет данные и CRC на диске.

    • Позволяет диску автоматически исправлять единичные ошибки.

    • При обнаружении неустранимых повреждений:

      • Передает информацию в MDS;

      • Инициирует миграцию данных;

      • Переводит CS в статус Failed;

      • Создает оповещение о необходимости замены диска.

  2. Глубокий скраббинг (deep-scrub): - Проверяет консистентность данных с учетом erasure-кодирования. - Сравнивает данные с восстановленными копиями из других CS.

Далее в разделе рассматривается обычный скраббинг, процесс глубокого скраббинга описан в разделе deep-scrub.

Скраббинг выполняется независимо для каждого чанк-сервера. Он автоматически возобновляется через заданное в конфигурации scrubber.scrub_pause_hour(default: 24h) время.

Примечание

Полный цикл скраббинга для кластера 12-18PB на HDD может занимать несколько месяцев.

Запуск скраббинга для конкретного CS (CS=1):

storage cs scrub start --id 1

Отмена активного скраббинга:

storage cs scrub cancel --id 1

Запуск нового цикла скраббинга:

storage cs scrub start --id 1

Просмотр даты последнего скраббинга (LAST-SCRUB), даты следующего скраббинга (NEXT-SCRUB) и текущий статус скраббинга (SCRUBBING):

Примечание

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

storage config set --name scrubber.<parameter> --value <value>

Настройка RDMA для RPC

RDMA (Remote Direct Memory Access) — технология прямого доступа к памяти по высокоскоростной сети. Использование требует специализированные сетевые устройства для Public и Internal сетей с включенной поддержкой протокола RoCE v2, минимальную версию SDS 1.3, а также внесение изменений в конфигурации CS. Подробнее о динамических параметрах rdma в в Руководстве администратора Chunk Server.

Volume

Volume (том) — это виртуальное блочное устройство, используемое iSCSI таргетом или QEMU/KVM. Том разбивается на чанки. Данные чанков хранятся на чанк-серверах.

Image — это том в состоянии только для чтения или удаления — frozen. Используя Image как шаблон, можно создавать новые тома путем клонирования.

Клонирование — это создание нового тома путем копирования Image.

Создание Volume

Рекомендуемый способ создания тома — использование предопределенных storage-class:

storage volume make --size 100GB --storage-class erasure

Где:

  • --size 100GB — логический размер тома;

  • --storage-class erasure — стандартный storage class для ec=4+2.

Кластер имеет заранее созданные storage class с параметрами:

storage storage-class list
NAME FAILURE-DOMAIN TIER ENCODING ENCRYPTION CHUNK-SIZE STRIP-SIZE OBJECT-SIZE MAXIOPS MAX-BW
erasure-disk disk 0 4+2/1 none 1GB 4KB 1MB N/A N/A
erasure-cold-disk disk 0 9+3/2 none 2GB 4KB 1MB N/A N/A
zero disk 0 1+0/0 none 1GB 4KB 1MB N/A N/A
replicated host 0 1+2/1 none 1GB 4KB 1MB N/A N/A
replicated-disk disk 0 1+2/1 none 1GB 4KB 1MB N/A N/A
erasure host 0 4+2/1 none 1GB 4KB 1MB N/A N/A
erasure-cold host 0 9+3/2 none 2GB 4KB 1MB N/A N/A

При необходимости можно создать собственный storage-class через команду storage storage-class make.

Расширенное создание тома с явным указанием параметров:

storage volume make --size 100GB --encoding "4+2/1" --failure-domain host --tier 0

Где:

  • --size 100GB — логический размер тома;

  • --encoding "4+2/1" — параметры erasure-coding в N+K/X формате,

    где:

    • N - stripe depth (количество data блоков),

    • K - redundancy (количество checksums блоков),

    • X - write tolerance (допустимое количество отказов CS для продолжения записи);

  • --failure-domain host — volume failure domain (для схемы 4+2 необходимо минимум 6 хостов);

  • --tier 0 — тир для хранения данных тома.

Failure Domain — мера защиты от потери данных, обеспечивающая изоляцию сбоя на соответствующем уровне топологии системы (disk|host|rack|pod|dc).

Tier — уровень производительности хранилища.

Уровни хранилища (Tiers)

Tier

Описание

Tier 0 (All-Flash)

Высокопроизводительные SSD для всех операций

Tier 1 (Hybrid)

Гибридное хранилище (SSD для журналов + HDD для данных)

Tier 2 (Capacity)

Экономичные HDD для хранения больших объемов данных

Возможно создание своего storage class с помощью команды storage-class make.

При создании тома можно задать ограничения на пропускную способность (MiB/sec) и/или число IO операций в секунду (IOPS) для операций с данным томом. Подробнее о лимитах читайте в Rate/bandwidth лимитирование.

Ограничения задаются следующими параметрами для команды storage volume make:

  • --limit.bw <value> — ограничение пропускной способности заданным целым числом <value> в MiB/sec По умолчанию 0 (без ограничений);

  • --limit.rate <value> — ограничение числа IO операций в секунду заданным числом <value>. По умолчанию 0 (без ограничений).

Минимальное ненулевое значение - 100, при указании <value> меньше 100, к тому будет применено значение 100.

Увеличение Volume

Размер тома можно увеличивать на значение кратное chunk-size:

storage volume grow --id 0x4ca25d689dfa1af0 --size 10GB

Заморозка Volume (cоздание image)

До создания image создайте том и запишите в него данные из файла:

storage volume make --size 1GB --storage-class erasure
Volume 0x4ca25d689dfa1af0 added
qemu-img convert -n -f raw -O raw cirros.img sbd:volume=0x4ca25d689dfa1af0

Где:

  • -n — обязательный параметр, пропускает «создание» тома силами qemu-img. В SDS тома создаются только утилитой storage, вызов qemu-img без параметра -n приведет к ошибке;

  • --size — размер тома (image), должен быть больше либо равен размеру cirros.img;

  • -f raw — формат cirros.img;

  • -O raw— output формат записи в 0x4ca25d689dfa1af0 volume.

Для заморозки тома выполните:

storage volume freeze --if 4ca25d689dfa1af0 --name new-volume-name

Где:

  • --id 0x4ca25d689dfa1af0 — идентификатор тома, который будет переведен в состояние frozen;

  • --name new-volume-name (опционально) — новое название тома.

Указанный том станет Image и больше не будет доступен для записи, но будет доступен для клонирования.

Клонирование Volume

Перед клонированием том необходимо заморозить по инструкции выше. Создание нового тома путем копирования данных из frozen тома:

storage volume clone --id 4ca25d689dfa1af0 --name new-cloned-volume

Где:

  • --id 4ca25d689dfa1af0 — идентификатор frozen Volume, который будет клонирован;

  • --name new-cloned-volume (опционально) — название нового тома.

Примечание

Storage Policy(encoding, failure-domain, tier) полученного тома совпадает со значением исходного тома.

Удаление Volume

Команда безвозвратно удаляет том без возможности восстановления:

storage volume rm --id 4ca25d689dfa1af0

Где:

  • --id 4ca25d689dfa1af0 — идентификатор тома, который будет удален.

Корзина Volume

Том может быть удален с возможностью восстановления через корзину. Перемещение тома в корзину для отложенного удаления:

storage volume trash mv --id 4ca25d689dfa1af0 --delete-after 1h

Где:

  • --id 4ca25d689dfa1af0 — идентификатор тома, который нужно переместить в корзину.

  • --delete-after 1h — время отложенного удаления. По умолчанию тома удалится через 24 часа после перемещения в корзину.

Получить список томов в корзине:

storage volume trash list
ID NAME VERSION STATE SIZE CHUNKS FAILURE-DOMAIN TIER ENCODING ENCRYPTION BLOCK-SIZE CHUNK-SIZE STRIP-SIZE OBJECT-SIZE SLICE-SIZE MAX-IOPS MAX-BW DELETE-AT
81b4075bc4b302f0 vol-81b4075bc4b302f0 1 active 4.0GB 0 disk 0 1+2/1 none 4096 1GB 4KB 1MB 0B N/A N/A 26.03.2025T10:42:33 MSK

Где DELETE-AT — время полного удаления тома из корзины.

Восстановление тома из корзины:

storage volume trash restore --id 4ca25d689dfa1af0

Листинг Volume

Получить список всех томов:

storage volume list

Получить информацию о конкретном томе по id:

storage volume list --id c2fd74b9e413ed21

Где:

  • --id c2fd74b9e413ed21 (опционально) — идентификатор нужного тома.

Пример вывода информации о томе:

ID NAME VERSION STATE SIZE CHUNKS FAILURE-DOMAIN TIER ENCODING ENCRYPTION BLOCK-SIZE CHUNK-SIZE STRIP-SIZE OBJECT-SIZE MAX-IOPS MAX-BW
c2fd74b9e413ed21 vol-c2fd74b9e413ed21 1 active 1GB 1 disk 0 4+2/1 none 4096 1GB 4KB 1MB N/A N/A

Где:

  • ID — идентификатор тома;

  • NAME — выбранное имя тома;

  • VERSION — версия тома;

  • STATE — состояние тома в данный момент:
    • deleting — том в процессе удаления;

    • cloning — том в процессе клонирования из Image;

    • frozen — том может быть использован в качестве источника для клонирования;

    • freezing — том находится в процессе перехода в Image;

    • active — том активен и может быть использован для выполнения IO команд;

  • SIZE — размер тома;

  • CHUNKS — число выделенных чанков у тома;

  • FAILURE-DOMAIN — уровень защиты от потери данных у тома;

  • TIER — уровень скорости тома;

  • ENCODING — схема кодирования данных тома;

  • ENCRYPTION — алгоритм шифрования тома;

  • BLOCK-SIZE — размер блока тома;

  • CHUNK-SIZE — размер чанка тома;

  • STRIP-SIZE — размер стрипа тома;

  • OBJECT-SIZE — размер объекта;

  • MAX-IOPS — максимальное число IOPS для тома;

  • MAX-BW — максимальное количество MB/sec для тома.

Примечание

Том, находящийся в переходных состояниях (cloning, freezing), недоступен для IO операций.

Глубокий скраббинг Volume (Deep Scrub)

Глубокий скраббинг (Deep Scrub) — процесс проверки целостности данных, закодированных с помощью erasure-coding в cold-storage. Выявляет испорченные в результате программных ошибок данные.

Глубокий скраббинг выполняется на мастер CS и запускается вручную:

  1. Чтение данных с Data CS и контрольных сумм с Checksum CS.

  2. Перекодирование данных с помощью erasure-coding.

  3. Сравнение полученных контрольных сумм с сохранёнными. При расхождении MDS помечает LAST-STATUS как failed.

Внимание

Автоматического восстановления не происходит — требуется ручное вмешательство.

Запустить глубокий скраббинг для конкретного тома:

storage volume scrub start --id 6641f9c25f689993

Запустить скраббинг для всех томов:

storage volume scrub start --all

Отменить скраббинг:

storage volume scrub cancel --id 6641f9c25f689993

Просмотр даты последнего скраббинга (LAST-SCRUB), статуса последнего скраббинга (LAST-STATUS), даты следующего скраббинга (NEXT-SCRUB) и активен ли сейчас скраббинг (SCRUBBING):

storage volume scrub list

Пример вывода:

ID LAST-SCRUB LAST-STATUS NEXT-SCRUB SCRUBBING
6641f9c25f689993 never ok never no

Ограничение пропускной способности (Rate/Bandwidth)

Томам в SDS можно задать: - Максимальную пропускную способность; - Максимальное количество IO-операций в секунду (IOPS).

Лимиты применяются на конечных клиентах, через которые осуществляется IO с кластером (libsbd, vhostd и т.д.). Контроль осуществляет конечный клиент, а не чанк-сервер.

Лимиты работают по принципу per-lease: - Каждый клиент имеет собственные лимиты; - Пример: при лимите 1000 IOPS и двух клиентах, каждый может выполнять до 1000 IOPS (суммарно 2000 IOPS).

Bandwidth/rate лимиты учитывают суммарный трафик (чтение + запись). Операции без «полезной нагрузки» (unmap, discard, flush и прочие) не учитываются.

Лимиты для тома задаются как при его создании (командой storage volume make), так и после (командой storage volume limit --id <volume_id>). Лимиты можно настраивать и отключать в процессе работы тома, даже если IO активен.

Задание лимитов:

  1. При создании тома:

    storage volume make --size 10GB --limit.bw 200 --limit.rate 1000 --storage-class erasure
  2. Для существующего тома:

    storage volume limit --id 0x5e995462e3abf960 --limit.rate 2000 --limit.bw 100

Где:

  • --limit.bw <value> — ограничение пропускной способности в MiB/sec (целое число).

  • --limit.rate <value> — ограничение числа IO операций в секунду (целое число).

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

storage config list | grep cluster.volume
# Bandwidth limit for volume in MB/s (0 - unlimited)
cluster.volume_bandwidth_limit = 200;
# Rate limit for volume in IO operations per second (0 - unlimited, 100 - min, 100000 - max)
cluster.volume_rate_limit = 2000;
Примечание

Явно заданные лимиты тома (--limit.bw и --limit.rate) переопределяют глобальные настройки кластера.

Листинг чанков тома

Просмотр чанков тома:

storage volume chunks --id 6f73cbeb60e9ad38
IDX UID STATUS FAILURE-DOMAIN STRIP#0 STRIP#1 STRIP#2
0 2 healthy OK CS=4 CS=2 CS=1
1 1 healthy OK CS=3 CS=1 CS=2

Где:

  • IDX — индекс чанка;

  • UID — уникальный идентификатор чанка;

  • STATUS — статус чанка (подробнее в Статус чанка);

  • FAILURE-DOMAIN — соответствие расположения чанклетов домену отказа (OK, FAILED). Для failure domain=host все чанклеты должны находиться на разных хостах.

  • STRIP#N — расположение чанклета, хранящего стрипы соответствующего индекса.

Листинг lease тома

Просмотр lease тома:

storage volume leases --id 6f73cbeb60e9ad38
UUID CLIENT ID VERSION TYPE
5d07c6a8-7167-4196-b9f3-d3f8321bd123 0x088c78b13e5f1314 0 exclusive

Где:

  • UUID — идентификатор lease;

  • CLIENT ID — идентификатор клиента, удерживающего lease;

  • VERSION — версия тома или снапшота, на который взята lease;

  • TYPE — тип lease (exclusive, shared rw, shared ro).

Шифрование тома

Шифрование при записи и расшифровка при чтении происходят на клиенте (vhost, nbd, fio и др.) Данные передаются по сети в зашифрованном виде. Ключи шифрования предоставляются MDS.

Настройка шифрования для тома происходит на этапе создания:

storage volume make --size 10GB --storage-class erasure --encryption.type AES256XTS [--encryption.keybase64_encoded_key]

Где:

  • encryption.type — алгоритм шифрования;

  • encryption.key — ключ шифрования (опционально). Если ключ не задан, то будет сгенерирован автоматически.

Поддерживаемые алгоритмы шифрования:

  • AES128XTS;

  • AES256XTS;

  • AEGIS128L;

  • AEGIS256.

Ключи шифрования хранятся в MDS и реплицируются с помощью алгоритма RAFT. Ключи зашифрованы мастер-ключом с помощью алгоритма AES256. Мастер-ключ генерируется автоматически во время создания кластера и сохраняется в файл /etc/storage/mds.ID/secret.env (В версии 1.3 и новее). Systemd сервис storage-mds@.service использует файл с секретом как EnvironmentFile и передает секрет в процесс через переменные окружения.

Для версий до 1.3:

  1. Создайте файл /etc/storage/mds.ID/secret.env вручную для каждого MDS.

  2. Файл должен содержать секрет AES256 длиной 32 байта в base64 формате:

    cat /etc/storage/mds.1/secret.env
    MASTER_SECRET_KEY="PbzhIklR/GlwGZfyVB4mf8Vm8yyKUvQhJKe19uIApY4="
    $ ll /etc/storage/mds.1/secret.env
    -rw------- 1 storage storage 64 Aug 6 15:49 /etc/storage/mds.1/secret.env

    Файл secret.env должен иметь rw права только для root пользователя.

  3. Обновите systemd сервис каждого MDS и добавить строку EnvironmentFile=-/etc/storage/mds.%i/secret.env:

    systemctl cat storage-mds@1.service
    # /lib/systemd/system/storage-mds@.service
    [Unit]
    Description=Storage Metadata Server
    PartOf=storage-mds.target
    After=network-online.target local-fs.target time-sync.target
    Before=storage-mds.target
    Wants=network-online.target local-fs.target time-sync.target storage-mds.target
    [Service]
    ExecStart=/usr/bin/mds --id %i
    User=storage
    Group=storage
    Environment="GOTRACEBACK=crash"
    EnvironmentFile=-/etc/storage/mds.%i/secret.env
    LimitCORE=infinity
    KillMode=process
    KillSignal=SIGINT
    SuccessExitStatus=100
    Restart=on-failure
    RestartSec=10
    StartLimitBurst=10
    StartLimitInterval=30min
    StandardOutput=append:/var/log/storage/mds.%i.stdout
    StandardError=append:/var/log/storage/mds.%i.stdout
    [Install]
    WantedBy=storage-mds.target

Snapshot

Snapshot — мгновенный снимок состояния тома. Снапшоты используются для создания консистентного состояния блочного девайса и резервного копирования данных. Система поддерживает full и inсremental снапшоты. Откат блочного девайса к предыдущему состоянию (снапшоту) не поддерживается.

Создание Snapshot

Создание снапшота:

storage snap make --id 4ca25d689dfa1af0
Snapshot #1 created

Где:

  • --id 4ca25d689dfa1af0 — идентификатор тома;

  • #1 — версия созданного снапшота.

Примечание

По умолчанию разрешено не более 4 снапшотов на том (настраивается через snapshot.max_number в конфигурационном файле).

Клонирование Snapshot

Создание нового тома путем копирования данных из снапшота исходного тома:

storage volume clone --id 4ca25d689dfa1af0 --name new-cloned-snapshot --version 1

Где:

  • --id 4ca25d689dfa1af0 — идентификатор исходного тома, который нужно клонировать;

  • --name new-cloned-snapshot (опционально) — имя нового тома;

  • --version 1 — версия снапшота для клонирования.

Примечание

Клонированный том наследует Storage Policy (encoding, failure-domain, tier) исходного тома.

Удаление Snapshot

Удаление снапшота version 1:

storage snap rm --id 4ca25d689dfa1af0 --version 1

Удаление всех снапшотов тома 4ca25d689dfa1af0:

storage snap purge --id 4ca25d689dfa1af0

Листинг Snapshot

Просмотр списка снапшотов:

storage snap list --id 4ca25d689dfa1af0
VERSION NAME DATE
1 snapshot-1 Mon, 19 Sep 2022 15:04:56 MSK

Экспорт Snapshot

Для выгрузки снапшотов на локальный диск используйте утилиту sbdctl. Подробное в Руководстве пользователя sbdctl.

Экспорт полного снапшота версии 1 в формате sbd:

sbdctl export --volume-id 0x670adb3d59bff77e --file-to snapshot-1.sbd --snapshot 1

Экспорт инкрементального снапшота версии 2 в формате sbd:

sbdctl export --volume-id 0x670adb3d59bff77e --file-to snapshot-2.sbd --snapshot 2 --incremental

Snapshot-2.sbd является инкрементальным снапшотом и содержит только изменения относительно предыдущей версии. В данном случае, версии 1.

Chunks

Chunks (чанки) — логический фрагмент данных тома. Первые 1 ГБ данных тома образуют чанк с индексом 0 (idx=0), который либо кодируется с помощью erasure-coding, либо реплицируется.

Информация о чанке

Для просмотра информации о чанклетах необходимо знать UID чанка. Выполните команду:

storage chunk info --uid 1
STRIP-IDX CSID TYPE STATE STATUS
0 3 data uptodate online
1 1 checksum uptodate online
2 2 checksum uptodate online

Где:

  • STRIP-IDX — индекс чанклета, который хранит соответсвующие стрипы;

  • CSID — место расположения чанклета;

  • TYPE — тип чанклета. Data чанклет хранит данные. Checksum чанклет хранит чексуммы для erasure coding;

  • STATE — состояние чанлета (uptodate, outdated);

  • STATUS — статус чанклета.

User

Система пользователей позволяет разграничивать права доступа в SDS. По умолчанию создается пользователь admin с полными правами.

Создание User

Создание нового пользователя:

storage user make --name username --password qwerty --cap.volume rw
User 'username' added

Где:

  • name — имя нового пользователя;

  • password — пароль пользователя. Если пароль не указан, пользователь получает статус nologin, аутентификация возможна только через secret ключ;

  • cap.volume — группа и capabilities пользователя. В данном примере пользователю установлены read/write capability на операции с томом.

Авторизация

Авторизация пользователя:

storage user login --name username --password qwerty

Команда сохраняет secret-ключ пользователя в файл /etc/storage/auth.yml с правами 0640(-rw-r-----). В дальнейшем этот файл используется утилитой storage для аутентификации и авторизации пользователя в кластере. Для чтения секрета из файла и авторизации в кластере пользователь должен иметь root права или находится в группе storage.

Права пользователя

Каждому пользователю можно назначить права (capabilities) для каждой группы операции, описывающей какие методы MDS API он может вызывать.

Типы прав:

  • r — только чтение;

  • w — только запись;

  • rw — чтение и запись.

Таблица 1. Группы capability

Группа

Write-действия

Read-действия

mds

storage mds make|rm

storage mds list

cs

storage cs add|rm|scrub|maintenance

storage cs list

volume

storage volume make|clone|rm|grow|freeze|unfreeze|limit|scrub storage snap make|rm|purge storage storage-class make|rm

storage volume list|leases|chunks storage snap list storage storage-class list

user

storage user make|rm|set

storage user list

host

storage host maintenance

storage host list

config

storage config set

storage config list

Управление пользователями

Просмотр списка пользователей:

storage user list
NAME LOGIN CAPABILITIES
admin true [config=rw cs=rw host=rw mds=rw user=rw volume=rw]
username true [volume=rw]

Где:

  • NAME — имя пользователя;

  • LOGIN:
    • true — пользователю доступна авторизация по паролю;

    • false — пользователь имеет статус nologin;

  • CAPABILITIES — права пользователя.

Удалить пользователя:

storage user rm --name username

Посмотреть информацию о текущем пользователе storage, авторизованном в кластере:

storage user who
NAME LOGIN SECRET CAPABILITIES
admin true humQqKFGWJNxY6JxSEbz9lAQmWqjLishVXARNoM1Yuo= [config=rw cs=rw host=rw mds=rw user=rw volume=rw]

Сменить пароль пользователя:

$ storage user set password --name admin --password qwerty
User 'admin' updated
Примечание

Для смены пароля другого пользователя требуются права capability user=rw.

Host

Просмотр хостов

Просмотр списка хостов:

$ storage host list
HOST-ID HOSTNAME PUBLIC-IP INTERNAL-IP LOCATION ONLINE-MDSES ONLINE-CSES MAINTENANCE
0xc65c22b781849edb storage1 10.10.50.71 10.10.40.71 [0:0:0] 1/1 3/3 off
0x4f5b942f91926a75 storage2 10.10.50.72 10.10.40.72 [0:0:0] 1/1 3/3 off
0x1706df20b1f99bc9 storage3 10.10.50.73 10.10.40.73 [0:0:0] 1/1 3/3 off

Где:

  • HOST-ID — идентификатор хоста из host.yml;

  • HOSTNAME — имя хоста из host.yml (по умолчанию /etc/hostname);

  • PUBLIC-IP — публичный адрес хоста;

  • INTERNAL-IP — внутренний адрес хоста;

  • LOCATION — [A:B:C], где A — идентификатор DC, B — идентификатор pod, C — идентификатор rack из host.yml;

  • ONLINE-MDSES — количество активных MDS-сервисов на хосте;

  • ONLINE-CSSES — количество активных CS-сервисов на хосте;

  • maintenance — статус обслуживания (on/off).

Режим обслуживания (Maintenance)

Включение maintenance режима:

storage host maintenance --maintenance-on

Все чанк-серверы на этом хосте перейдут в maintenance режим. MDS-лидер по возможности мигрирует на другой хост. Восстановление urgent-чанков приостанавливается на время maintenance_offline_period.

Отключение maintenance режима:

storage host maintenance --maintenance-off

Включение maintenance режима для удаленного хоста, недоступного в сети:

storage host maintenance --id 0xc65c22b781849edb --maintenance-on
Внимание

Нельзя переводить в maintenance:

  • более 1 хоста одновременно;

  • если это нарушит кворум MDS.

Для отключения всех проверок добавьте --force:

storage host maintenance --force --maintenance-on

Lease

Принудительное освобождение lease у клиента:

storage lease revoke --volume 48fb33816fadd178 --client 0x0a00000000000400

Используется при зависании клиента, блокирующего доступ к тому.

Clients

Просмотр подключенных к кластерам клиентов в версии 1.4 и выше:

storage client list
ID HOSTNAME TYPE STATUS UPTIME VERSION
0x0a00000000000018 N/A fio offline 0s 1.4.68
0x0811a464e7b31926 N/A sbdctl online 17h23m30s 1.4.68
0x2001a452d7944b63 pd32-srv-077.srv.mng.cloud.ru vhost online 17h11m10s 1.4.68

Где:

  • ID — идентификатор клиента (по умолчанию берется из host.yml на клиентском хосте);

  • HOSTNAME — имя хоста из host.yml (по умолчанию /etc/hostname), где расположен клиент;

  • TYPE — тип клиента (fio, sbd,sbdctl, vhost, tcmu, fuse, nbd);

  • STATUSonline, inactive (клиент не отправляет keepalive более 15 секунд), offline (клиент не отправляет keepalive более минуты);

  • UPTIME — продолжительность работы клиентского процесса;

  • VERSION— версия клиента.

Клиенты, находящиеся в статусе offline более 24 часов, удаляются из списка подключенных клиентов.

Конфигурирование Storage Cluster

Глобальная конфигурация кластера хранится в MDS и реплицируется через RAFT.

Просмотр параметров и их значений:

storage config list

Изменение значений параметров:

storage config set --name {parameter_name} --value {parameter_value}

Изменения применяются онлайн без перезагрузки сервисов.

Ниже приведена таблица с наиболее важными параметрами.

Таблица 2. Параметры конфигурирования

Название

Значение по умолчанию

Описание

Кластер

cluster.leader_grace_period_ms

10000

Период стабилизации кластера после выбора нового лидера. В течение этого периода запрещены процессы восстановления данных. Кластер находится в DEGRADED состоянии.

cluster.max_offline_hosts

3

Количество хостов, которые имеют OFFLINE чанк-сервера. При достижении данного количество кластер переходит в состояние FAILED. Восстановление данных не происходит.

cluster.ping_push_timeout_ms

1000

Таймаут на PushMap запрос от MDS к CS с флагом ping

cluster.push_timeout_ms

3000

Таймаут на PushMap запрос от MDS к CS

Чанк-серверы (CS)

cs.inactive_period_ms

10000

Время с последнего keepalive сообщения от CS, по истечении которого сервис переходит в INACTIVE. Происходит восстановление только тех чанков, в которые поступают IO-запросы, и клиент вернул в MDS ошибку, связанную с этим чанком. Восстановление остальных данных не начинается.

cs.offline_period_sec

900

Время с последнего keepalive сообщения от CS, по истечении которого сервис переходит в OFFLINE. Все данные с этого CS восстанавливаются.

cs.maintenance_offline_period_sec

86400

Увеличенный offline период у CS в режиме maintenance. Откладывает восстановление данных этого CS во время штатного обслуживания оборудования.

cs.reserved_free_space

5

Зарезервированное место на файловой системе чанк-сервера в %. При достижении данного порога заполнения файловой системы MDS перестает аллоцировать новые чанки на CS. CS переходит в NOSPACE состояние.

Восстановление данных

recoverer.jobs

4

Количество воркеров, которые занимаются планированием рекавери

recoverer.max_recovering

64

Максимальное количество чанков в кластере, которые находятся в recovering состоянии. Параметр позволяет увеличивать или уменьшать скорость восстановления данных. В случае увеличения количества recovering чанков, также увеличивается влияние на клиентское IO (увеличивается latency, уменьшаются IOPS).

recoverer.recovery_delay_sec

180

После того, как чанк получил статус urgent, MDS начинает восстановление чанка после истечения данного периода.

recoverer.recovery_timeout_ms

60000

Таймаут на операцию восстановления чанка. Если восстановление чанка не завершается в течение данного периода, то MDS перезапускает восстановление.

Балансировка

balancer.enabled

1

Включение/выключение балансировки данных по занимаемому месту

balancer.fill_threshold

5

Максимальное отклонение заполненности( fill) CS от целевого значения в процентах. MDS высчитывает целевое заполнение(target_fill) чанк сервера в процентах как used_space_bytes/total_space_bytes*100. В случае отклонения fill CS от целевого больше чем на 5%, начинается процесс балансировки. Если fill < target_fill - fill_threshold, то на CS будут мигрироваться чанки из других CS. Если fill > target_fill + fill_threshold, то c CS будут мигрироваться чанки на другие CS.

balancer.max_in_progress

8

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

Клонирование

cloner.clone_timeout_ms

60000

Таймаут на операцию клонирования чанклета. Если клонирование чанклета не завершается в течение данного периода, то MDS запускает клонирование заново.

cloner.max_chunklets_in_progress

32

Максимальное количество чанклетов в кластере, которые находятся в cloning состоянии.

cloner.max_cloning_per_chunk

4

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

Скраббинг

scrubber.enabled

1

Включение/выключение скраббинга CS

scrubber.bandwidth

64

Максимальная скорость чтения чанклета на CS во время скраббинга в MB/s

scrubber.jobs

10

Количество воркеров, которые занимаются планированием скраббинга

scrubber.begin_scheduling_hour

0

Скраббинг работает в [begin_scheduling_hour; end_scheduling_hour] интервале

scrubber.end_scheduling_hour

24

Скраббинг работает в [begin_scheduling_hour; end_scheduling_hour] интервале

scrubber.check_integrity_period_hour

168

Проверять чанклет скраббингом не чаще чем раз в заданный период

scrubber.scrub_delay_for_new_cs_hour

720

Начинать скраббинг на новом CS после истечения данного периода

scrubber.scrub_pause_hour

24

После полного завершения скраббинга CS ждать в течение заданного периода, прежде чем начинать новый раунд скраббинга

Прочие

snapshot.max_number

4

Максимальное количество снапшотов на volume

gc.jobs = 2

2

Количество воркеров, которые удаляют deleting чанки с CS

log.level

5

Уровни логирования: panic=0, fatal=1, error=2, warn=3, info=4, debug=5, trace=6

Утилита sbdctl

Полная документация доступна в Руководстве администратора sbdctl.

Ограничение пропускной способности на клиенте

Некоторые клиентские приложения поддерживают ограничение пропускной способности на своей стороне (per-process), вне зависимости от настроек тома. Число операций в секунду при этом не может быть ограничено. К таким приложениям относятся libsbd, vhostd, tcmud и другие.

Настройка ограничения пропускной способности:

  1. Запустите клиентское приложение.

  2. Передайте ему CLI-параметр --max-bandwidth=<value> или задайте его через соответствующий конфигурационный файл. Где <value> — лимит в байтах/секунду. По умолчанию — 0 (без ограничений). Минимальное ненулевое значение — 1000 (байт/сек).

Ограничение per-volume может быть обновлено в процессе работы приложения. Ограничение per-client-process нельзя обновить в процессе работы приложения, требуется перезапуск.

Допускается одновременное задание ограничений на клиенте и per-volume. Ограничение на клиенте первостепенно — максимальный трафик в секунду не может превышать значение max-bandwidth на клиенте, все ограничения для тома будут выполняться.

Примеры работы лимитов:

  1. Лимит клиента — max-bandwidth = 100 MiB/s, запущено два тома, лимит тома = 80 MiB/s → Реальный трафик при максимальной и одинаковой загрузке на каждый том составит ~50 MiB/s (достигнет максимального лимита max-bandwidth).

  2. Лимит клиента — max-bandwidth = 100 MiB/s, запущено два тома, лимит тома = 20 MiB/s → Реальный трафик ~20 MiB/s на volume (достигнет максимального лимита per-volume).