Администрирование 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.servicesystemctl enable storage-mds@1.service
Добавление MDS в кластер
Авторизуйте хост и сохраните secret пользователя admin в файле /etc/storage/auth.yml для дальнейшей авторизации:
sudo storage --cluster 123 --mds.address 192.168.0.1 user login --name admin --password qwertyСоздайте новый 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}.servicesystemctl enable storage-mds@{MDSID}.service
Удаление MDS
Укажите ID MDS сервера и выполните команду:
# Пример для MDS ID=1storage mds rm --id 1Остановите systemd сервис на хосте, связанным с нужным MDS:
systemctl stop storage-mds@1.servicesystemctl disable storage-mds@1.serviceПри необходимости удалите данные сервиса из root директории MDS:
rm -rf /mnt/storage/mdsrm -rf /etc/storage/mds.1rm -f /var/log/storage/mds.1*
При удалении MDS убедитесь, что кворум в кластере сохраняется.
Листинг MDS
storage mds listID ADDRESS NET-STATUS RAFT-STATUS UPTIME MAINTENANCE VERSION1 172.255.50.58:60003 online ready 86h49m44s false 1.1.61*2 172.255.50.59:60003 online ready 86h49m37s false 1.1.613 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: 1cluster_id: 123cluster_name: myclustercluster_uuid: 06ab88bc-915a-4245-a6ba-3aa363d6ff53root: /mnt/storage/mdsaddress: 192.168.100.13raft_port: 60001grpc_port: 60002rpc_port: 60003prom_port: 60080debug_port: 60081tos: 16trace_ip: 127.0.0.1trace_port: 14268trace_enabled: falselog_dir: /var/log/storagelog_level: infosyslog_enabled: falsesyslog_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}.servicesystemctl enable storage-csd@{CSID}.service
Первый старт сервиса может быть медленным, так как требуется доинициализация репозитория.
Узнать статус сервера:
storage cs list —-id $CSID
Удаление CS
Удаление CS из кластера требуется при замене вышедшего из строя диска или хоста.
Перед удалением убедитесь, что:
Количество оставшихся CS достаточно для хранения данных с текущим фактором репликации.
Имеется достаточно свободного места для переноса чанков с удаляемого сервера.
Получите список CS и их идентификаторов:
storage cs listПример вывода:
ID HOST TIER MGMT-STATUS STATUS ADDRESS UPTIME LAST-SCRUB ISSCRUBBING COLD-SPACE HOT-SPACE VERSION1 985403c287ad0aa0 0 ok active 172.255.50.58:59001 70h27m0s never false 629.00GB/643.03GB 64.92GB/65.02GB 0.1.822 f5854a8307e3e7be 0 ok active 172.255.50.59:59002 70h24m5s never false 626.98GB/643.03GB 64.73GB/65.02GB 0.1.823 db9dc1a0a2dfe307 0 ok active 172.255.50.62:59003 70h28m8s never false 623.91GB/643.03GB 64.68GB/65.02GB 0.1.82Удалите CS из кластера (например, с ID=1):
storage cs rm --id 1После выполнения операции CS перейдет в статус RELEASING. Кластер начнет перенос чанков на другие серверы. Процедура может занять продолжительное время.
После завершения миграции CS перейдет в состояние DROPPED и пропадет из списка. Остановите systemd сервис на хосте:
systemctl stop storage-csd@1.servicesystemctl disable storage-csd@1.serviceДанные сервиса остаются 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 уровня:
Обычный скраббинг:
Проверяет данные и CRC на диске.
Позволяет диску автоматически исправлять единичные ошибки.
При обнаружении неустранимых повреждений:
Передает информацию в MDS;
Инициирует миграцию данных;
Переводит CS в статус Failed;
Создает оповещение о необходимости замены диска.
Глубокий скраббинг (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 listNAME FAILURE-DOMAIN TIER ENCODING ENCRYPTION CHUNK-SIZE STRIP-SIZE OBJECT-SIZE MAXIOPS MAX-BWerasure-disk disk 0 4+2/1 none 1GB 4KB 1MB N/A N/Aerasure-cold-disk disk 0 9+3/2 none 2GB 4KB 1MB N/A N/Azero disk 0 1+0/0 none 1GB 4KB 1MB N/A N/Areplicated host 0 1+2/1 none 1GB 4KB 1MB N/A N/Areplicated-disk disk 0 1+2/1 none 1GB 4KB 1MB N/A N/Aerasure host 0 4+2/1 none 1GB 4KB 1MB N/A N/Aerasure-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 — уровень производительности хранилища.
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 erasureVolume 0x4ca25d689dfa1af0 addedqemu-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 listID 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-AT81b4075bc4b302f0 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-BWc2fd74b9e413ed21 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 и запускается вручную:
Чтение данных с Data CS и контрольных сумм с Checksum CS.
Перекодирование данных с помощью erasure-coding.
Сравнение полученных контрольных сумм с сохранёнными. При расхождении 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 SCRUBBING6641f9c25f689993 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 активен.
Задание лимитов:
При создании тома:
storage volume make --size 10GB --limit.bw 200 --limit.rate 1000 --storage-class erasureДля существующего тома:
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 6f73cbeb60e9ad38IDX UID STATUS FAILURE-DOMAIN STRIP#0 STRIP#1 STRIP#20 2 healthy OK CS=4 CS=2 CS=11 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 6f73cbeb60e9ad38UUID CLIENT ID VERSION TYPE5d07c6a8-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:
Создайте файл /etc/storage/mds.ID/secret.env вручную для каждого MDS.
Файл должен содержать секрет AES256 длиной 32 байта в base64 формате:
cat /etc/storage/mds.1/secret.envMASTER_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 пользователя.
Обновите 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 ServerPartOf=storage-mds.targetAfter=network-online.target local-fs.target time-sync.targetBefore=storage-mds.targetWants=network-online.target local-fs.target time-sync.target storage-mds.target[Service]ExecStart=/usr/bin/mds --id %iUser=storageGroup=storageEnvironment="GOTRACEBACK=crash"EnvironmentFile=-/etc/storage/mds.%i/secret.envLimitCORE=infinityKillMode=processKillSignal=SIGINTSuccessExitStatus=100Restart=on-failureRestartSec=10StartLimitBurst=10StartLimitInterval=30minStandardOutput=append:/var/log/storage/mds.%i.stdoutStandardError=append:/var/log/storage/mds.%i.stdout[Install]WantedBy=storage-mds.target
Snapshot
Snapshot — мгновенный снимок состояния тома. Снапшоты используются для создания консистентного состояния блочного девайса и резервного копирования данных. Система поддерживает full и inсremental снапшоты. Откат блочного девайса к предыдущему состоянию (снапшоту) не поддерживается.
Создание Snapshot
Создание снапшота:
storage snap make --id 4ca25d689dfa1af0Snapshot #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 4ca25d689dfa1af0VERSION NAME DATE1 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 1STRIP-IDX CSID TYPE STATE STATUS0 3 data uptodate online1 1 checksum uptodate online2 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 rwUser '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 — чтение и запись.
Группа |
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 listNAME LOGIN CAPABILITIESadmin 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 whoNAME LOGIN SECRET CAPABILITIESadmin true humQqKFGWJNxY6JxSEbz9lAQmWqjLishVXARNoM1Yuo= [config=rw cs=rw host=rw mds=rw user=rw volume=rw]
Сменить пароль пользователя:
$ storage user set password --name admin --password qwertyUser 'admin' updated
Для смены пароля другого пользователя требуются права capability user=rw.
Host
Просмотр хостов
Просмотр списка хостов:
$ storage host listHOST-ID HOSTNAME PUBLIC-IP INTERNAL-IP LOCATION ONLINE-MDSES ONLINE-CSES MAINTENANCE0xc65c22b781849edb storage1 10.10.50.71 10.10.40.71 [0:0:0] 1/1 3/3 off0x4f5b942f91926a75 storage2 10.10.50.72 10.10.40.72 [0:0:0] 1/1 3/3 off0x1706df20b1f99bc9 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 listID HOSTNAME TYPE STATUS UPTIME VERSION0x0a00000000000018 N/A fio offline 0s 1.4.680x0811a464e7b31926 N/A sbdctl online 17h23m30s 1.4.680x2001a452d7944b63 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);
STATUS — online, 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}
Изменения применяются онлайн без перезагрузки сервисов.
Ниже приведена таблица с наиболее важными параметрами.
Название |
Значение по умолчанию |
Описание |
---|---|---|
Кластер |
||
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 и другие.
Настройка ограничения пропускной способности:
Запустите клиентское приложение.
Передайте ему CLI-параметр --max-bandwidth=<value> или задайте его через соответствующий конфигурационный файл. Где <value> — лимит в байтах/секунду. По умолчанию — 0 (без ограничений). Минимальное ненулевое значение — 1000 (байт/сек).
Ограничение per-volume может быть обновлено в процессе работы приложения. Ограничение per-client-process нельзя обновить в процессе работы приложения, требуется перезапуск.
Допускается одновременное задание ограничений на клиенте и per-volume. Ограничение на клиенте первостепенно — максимальный трафик в секунду не может превышать значение max-bandwidth на клиенте, все ограничения для тома будут выполняться.
Примеры работы лимитов:
Лимит клиента — max-bandwidth = 100 MiB/s, запущено два тома, лимит тома = 80 MiB/s → Реальный трафик при максимальной и одинаковой загрузке на каждый том составит ~50 MiB/s (достигнет максимального лимита max-bandwidth).
Лимит клиента — max-bandwidth = 100 MiB/s, запущено два тома, лимит тома = 20 MiB/s → Реальный трафик ~20 MiB/s на volume (достигнет максимального лимита per-volume).
- MDS
- Chunk-server (CS)
- Volume
- Snapshot
- Chunks
- User
- Host
- Конфигурирование Storage Cluster
- Утилита sbdctl
- Ограничение пропускной способности на клиенте