Операции с дисковым хранилищем
-
Подключите диски к Storage-серверам.
-
Подключитесь к Storage-серверу с добавленными дисками.
-
С помощью команды
lsblkубедитесь, что диски определились, и запишите их имена (sda,vda,nvme*). -
Подключитесь к деплой-ноде и отредактируйте файл
/deploy/installer/inventory.yml:-
В секции
storageзаполните последовательностьmountsс правилами разметки дисков под пары, добавив записи о новых дисках. Например, в Системе два Storage-сервера (storage-1иstorage-2), на них добавили по одному новому диску/dev/vdd.storage:hosts:storage-[1:2]:mounts:- pair_number: 1partition: 1device: /dev/vdbstart: 0%end: 100%- pair_number: 2partition: 1device: /dev/vdcstart: 0%end: 100% -
Добавьте информацию о третьей паре:
- pair_number: 3partition: 1device: /dev/vddstart: 0%end: 100%
-
-
Запустите установку для внесения изменений в конфигурацию Системы. При этом:
- На дисках будет создан раздел, файловая система и назначены права.
- Диски будут примонтированы через system unit к
/storage/<НОМЕР_ПАРЫ>.
-
После завершения работы установщика система перечитает конфигурацию в течение пары минут, и диски можно будет проверить командой
hb pairdb list.
Если по каким-то причинам запустить установщик нельзя или нежелательно, выполните процедуру вручную:
-
Подключите диски к Storage-серверам.
-
Подключитесь к каждому Storage-серверу с добавленными дисками и выполните следующие действия:
-
Утилитой
gdiskсоздайте GPT-раздел, присвойте ему имя (командаcвнутриgdisk)storage-<НОМЕР_ПАРЫ>. -
Отформатируйте раздел в
ext4. -
Через
blkid /dev/xxx1убедитесь, чтоPARTLABELимеет метку форматаstorage&uhyph<НОМЕР_ПАРЫ>. -
Скопируйте unit-файл уже существующего диска в новый, например:
$ cp /etc/systemd/system/storage-2.mount /etc/systemd/system/storage-3.mount -
Отредактируйте unit-файл
/etc/systemd/system/storage-3. -
Выполните команду:
$ systemctl daemon-reload -
Создайте точку монтирования
/storage/<НОМЕР_ПАРЫ>. -
Примонтируйте диск:
$ systemctl start storage-3.mount -
Назначьте права:
$ chown -R nobody:nobody /storage/<НОМЕР_ПАРЫ>/
-
-
Добавьте в конфигурацию сервиса Nginx на Storage-серверах информацию о новой паре:
-
В файле конфигурации
/etc/nginx/vhosts.d/30_storage.confскопируйте секцию существующей пары и замените номер пары на новый:Примерlocation /<НОМЕР_ПАРЫ>/{...location ~ ^/<НОМЕР_ПАРЫ>/[0-9A-F][0-9A-F]/[0-9A-F][0-9A-F]/[0-9A-F]+...location ~ ^/<НОМЕР_ПАРЫ>/tmp/...client_body_temp_path /storage/<НОМЕР_ПАРЫ>/incoming;...} -
Запустите проверку конфигурации Nginx:
$ nginx -tnginx: the configuration file /etc/nginx/nginx.conf syntax is oknginx: configuration file /etc/nginx/nginx.conf test is successful -
Если проверка закончилась удачно, перезагрузите конфигурацию Nginx командой
systemctl reload nginx.
-
-
Подключитесь к любому Metadata-серверу и добавьте пару:
$ hb pairdb insert --id 3 --flags HOTBOX,REDUNDANT --storages=1<IP_АДРЕС_STORAGE-СЕРВЕРА1>:8088/<НОМЕР_ПАРЫ>,<IP_АДРЕС_STORAGE-СЕРВЕРА2>:8088/<НОМЕР_ПАРЫ> -
Для проверки корректности добавления пары выполните команду
hb pairdb list. При корректном добавлении объемыTotalиFreeсовпадают и отображают реальный объем данных.
-
Перед заменой диска выполните процедуру переноса данных (размиграцию):
-
Подключитесь к деплой-ноде и проверьте режим работы пары с поврежденным диском:
$ hb pairdb show <НОМЕР_ПАРЫ> -
Установите флаг
READONLYдля пары, если она в другом режиме:$ hb pairdb mark <НОМЕР_ПАРЫ> READONLY -
Убедитесь, что для пары выставлен флаг
READONLY:$ hb pairdb show <НОМЕР_ПАРЫ> -
Запустите размиграцию:
$ hb storage unit move --id <НОМЕР_ПАРЫ>В консоли появится идентификатор задачи. Процедура размиграции выполняется в фоновом режиме, за ее работой можно наблюдать:
- В Grafana в дашборде
Moving. - По логу
/var/log/razmove-worker/razmove-worker.logна серверах, где запущены процессы обработчиков размиграции.
- В Grafana в дашборде
-
Проверьте статус задачи командой:
$ hb storage razmove info --ids <ID_ЗАДАЧИ> -o yaml -
Флаг
READONLYавтоматически не снимается. Если необходимо, снимите флаг:$ hb pairdb unmark <НОМЕР_ПАРЫ> READONLY
-
-
После физической замены поврежденного диска создайте в нем раздел, файловую систему и назначьте права, как описано в инструкции по ручному добавлению пар.
-
Перезагрузите конфигурацию NGINX (даже если файл с его конфигурацией не изменялся):
$ systemctl reload nginx -
Запустите компонент Haron принудительно:
$ sudo -u nobody haron -f -c /etc/storage-daemons/config.yaml -pair_ids <НОМЕР_СИНХРОНИЗИРУЕМОЙ_ПАРЫ> mtime-skip-new="1m"
После аварийной ситуации, если требуется очистка локальной пары, выполните следующие шаги:
-
Подключитесь к деплой-ноде и проверьте режим работы пары:
hb pairdb show <НОМЕР_ПАРЫ> -
Переведите пару в режим read-only:
hb pairdb mark <НОМЕР_ПАРЫ> READONLY -
Проверьте, что пара находится в режиме read-only:
hb pairdb show <НОМЕР_ПАРЫ> -
Запустите размув:
hb storage unit move --id <НОМЕР_ПАРЫ>В консоли появится идентификатор задачи, далее <id задачи>. Процедура выполняется в фоновом режиме, за ее работой можно наблюдать:
- В Grafana в дашборде
Moving. - По логу
/var/log/razmove-worker/razmove-worker.logна серверах, где запущены razmove-worker процессы.
- В Grafana в дашборде
-
Проверьте статус задачи по выводу команды:
hb storage razmove info --ids <ИДЕНТИФИКАТОР_ЗАДАЧИ> -o yaml -
Флаг
FAULTснимается автоматически после успешного прохождения проверки на работоспособность (healthcheck). Если флаг не снялся, снимите его вручную командой:hb pairdb unmark <НОМЕР_ПАРЫ> FAULT -
Убедитесь, что пара больше не помечена как
FAULTи доступна для использования. Для этого выполните команду:hb pairdb list
Факторы репликации определяют, сколько реплик (копий) данных будет создано.
По умолчанию система выполняет репликацию Х2. В инструкции описывается последовательность шагов для изменения фактора репликации. Примечание: в рамках перехода на факторы репликации пара будет называться юнит, а диск или его часть (один из дисков пары) — парт.
Порядок действий для обновления до факторов репликации Х3:
-
Выполните переход на новую схему работы (миграцию) в указанном порядке:
- Выключите чтение из таблицы pairs командой (включение чтения юнитов):
$ switchover -p hotbox e set "pairdb/common/app/api/disable_old_schema_read" true- Выключите запись в таблицу pairs командой (включение записи юнитов):
$ switchover -p hotbox e set "pairdb/common/app/api/disable_old_schema_write" true- Проверьте изменения командой:
$ switchover -p hotbox e getr "pairdb/common/app/api"- Выполните рестарт кластера PairDB:
$ switchover -p hotbox pr --cluster pairdb -y -
Измените конфигурацию Gostreamer в файле
/etc/gostreamer/config.yaml(или по заданному пути):streamer:redundancy:enabled: true # для включения функциональности юнитов, значение по умолчанию – falsemin_write: 2 # минимальное количество успешных записей, значение по умолчанию – 2 -
Выполните рестарт компонента Gostreamer:
$ sudo systemctl restart gostreamer -
Измените конфигурацию Haron в файле
/etc/storage-daemons/config.yaml:haron:redundancy:enabled: true # использование новых версий API, значение по умолчанию – false -
Выполните рестарт компонента Haron:
$ sudo systemctl restart haron -
Установите необходимое количество юнитов в PairDB командой:
$ switchover -p hotbox e set "pairdb/common/app/storage_unit/size_limit" 3 -
Проверьте изменения командой:
$ switchover -p hotbox e getr "pairdb/common/app/storage_unit" -
Выполните рестарт кластера PairDB:
$ switchover -p hotbox pr --cluster pairdb -y -
Добавьте недостающий парт или юнит соответствующей командой:
- для добавления парта в существующий юнит используйте команду
hb pairdb add_part, например:
* для добавления юнита используйте команду `hb pairdb insert`, например:$ hb pairdb add_part --id=<ИДЕНТИФИКАТОР_ЮНИТА> --parts=<IP_ПАРТА1>:<ПОРТ_ПАРТА1>/<ИДЕНТИФИКАТОР_ЮНИТА>,<IP_ПАРТА2>:<ПОРТ_ПАРТА2>/<ИДЕНТИФИКАТОР_ЮНИТА>$ hb pairdb insert --id=<ИДЕНТИФИКАТОР_ЮНИТА> --flags=HOTBOX,REDUNDANT --storages=1<АДРЕС_STORAGE_СЕРВЕРА1>:8088/<ИДЕНТИФИКАТОР_ЮНИТА>,<АДРЕС_STORAGE_СЕРВЕРА2>:8088/<ИДЕНТИФИКАТОР_ЮНИТА>,<АДРЕС_STORAGE_СЕРВЕРА3>:8088/<ИДЕНТИФИКАТОР_ЮНИТА> - для добавления парта в существующий юнит используйте команду
Начиная с версии razmove-worker-1.3.7 доступен режим razmove.ignore_move_errors с параметрами. При данном режиме ошибка переноса (move) отдельного хеша не прерывает выполнение всей задачи размиграции.
Логика работы:
- При
enabled: trueзадача не прерывается со статусомfailedпри возникновении ошибок переноса. Это отличается от поведения по умолчанию, когда задача останавливается на первой ошибке. Курсор обработки проходит до конца, счетчик ошибок при этом только растет. - Если по завершении прохода остались необработанные из-за ошибок (
IsEmptyPair) хеши (проверяется через Nylon), курсор и счетчик ошибок сбрасываются и запускается новый проход по хешам с ошибками. Число таких проходов ограничено параметромmax_passes(по умолчанию 10). - В режиме
ignore_move_errorsменяется семантика поляhashes_to_retry: вместо массива хешей в нем хранится количество ошибок за каждый полный проход. - Ошибка Nylon (
select hashesилиIsEmptyPair) приводит к немедленному завершению прохода независимо от режимаignore_move_errors.
- Проверка дисковых пар (
hb pairdb list). - Просмотр наличия файлов на юните (
hb storage unit count). - Перевод юнита в состояние READONLY (
hb pairdb mark). - Перевод юнита из состояния READONLY (
hb pairdb unmark). - Контроль состояния юнита (
hb pairdb show). - Cоздание задачи на перенос файлов (
hb storage unit move). - Просмотр состояния задачи (
hb storage razmove info). - Просмотр всех задач (
hb storage razmove list). - Удаление успешно выполненной задачи (
hb storage razmove delete). - Удаление задачи в статусе processing (
hb storage razmove delete --force). - Перевод задачи в статус waiting из статуса failed (
hb storage razmove retry).
Запрос:
$ hb pairdb list
Ответ:
ID | CLASS | KARMA | MAINTENANCE | FLAGS | STORAGE1 | STORAGE2---|--------|-------|-------------|------------------|-------------------------|--------------------------1 | HOTBOX | 4 | - | HOTBOX,REDUNDANT | 10.1.0.59:8088/1 | 10.2.0.59:8088/1| | | | | Free:17.967G | Free:17.967G| | | | | Total:29.403G | Total:29.402G| | | | | Err:2024-02-28:12:33:35 | Err:2024-02-26:06:16:412 | HOTBOX | 4 | - | HOTBOX,REDUNDANT | 10.1.0.59:8088/2 | 10.2.0.59:8088/2| | | | | Free:12.051G | Free:12.050G| | | | | Total:29.402G | Total:29.402G| | | | | Err:2024-02-26:06:17:54 | Err:2024-02-26:06:17:543 | HOTBOX | 4 | - | HOTBOX,REDUNDANT | 10.1.0.60:8088/3 | 10.2.0.60:8088/3| | | | | Free:24.319G | Free:12.745G| | | | | Total:29.402G | Total:29.402G| | | | | Err:2024-02-28:14:03:36 | Err:2024-02-28:12:30:294 | HOTBOX | 4 | - | HOTBOX,REDUNDANT | 10.1.0.60:8088/4 | 10.2.0.60:8088/4| | | | | Free:12.024G | Free:12.025G| | | | | Total:29.402G | Total:29.402G| | | | | Err:2024-02-28:12:30:29 | Err:2024-02-28:12:30:295 | HOTBOX | 4 | - | HOTBOX,REDUNDANT | 10.1.0.59:8088/5 | 10.2.0.59:8088/5| | | | | Free:27.295G | Free:27.295G| | | | | Total:29.403G | Total:29.403G
В ответе проблемные пары будут помечены флагами FAULT и временем возникновения ошибки.
Ошибка может быть как с одним диском, так и с двумя сразу — это видно по статусу. Также в выводе показаны уже решенные ошибки пар.
За установку и снятие флага FAULT отвечает фоновый процесс PairDB — Fault. Он же обновляет информацию о свободном месте партов.
Процесс Fault обрабатывает только те юниты, задача на обработку которых попала в пространство tasks. Для проверки работоспособности (healthcheck) на каждом диске юнита процесс выполняет три HTTP-запроса к файлу http://<IP_АДРЕС_СЕРВЕРА>:<ПОРТ>/<НОМЕР_ПАРЫ>/tmp/temp_pairdb_healthcheck.txt:
DELETE— удаление файла, оставшегося от предыдущей проверки.PUT— запись временного файла.DELETE— удаление временного файла.
Тайм-аут каждого запроса — 3 секунды (значение по умолчанию).
Если в ходе проверки удается получить информацию о свободном месте партов, процесс Fault обновляет значение Free и снимает флаг FAULT. Если на любом из дисков юнита возникла ошибка записи, удаления или тайм-аут, юниту выставляется флаг FAULT.
Снять флаг можно и вручную командой:
$ hb pairdb unmark <НОМЕР_ПАРЫ> FAULT
Запрос:
hb storage unit count <ИДЕНТИФИКАТОР_ЮНИТА>
Ответ:
COUNT-------1530
Запрос:
hb pairdb mark <НОМЕР_ПАРЫ> READONLY
Ответ:
ID | CLASS | KARMA | MAINTENANCE | FLAGS | STORAGE 1 | STORAGE 2---|--------|-------|-------------|-----------------|-------------------|-------------------3 | HOTBOX | 3 | - | HOTBOX,READONLY | 10.3.0.101:8088/3 | 10.3.0.102:8088/3| | | | REDUNDANT | Free:20.0GiB | Free:20.0GiB| | | | | Total:29.4GiB | Total:29.4GiB| | | | | Err:- | Err:-
Запрос:
hb pairdb unmark <НОМЕР_ПАРЫ> READONLY
Ответ:
ID | CLASS | KARMA | MAINTENANCE | FLAGS | STORAGE 1 | STORAGE 2---|--------|-------|-------------|------------------|-------------------|-------------------3 | HOTBOX | 4 | - | HOTBOX,REDUNDANT | 10.3.0.101:8088/3 | 10.3.0.102:8088/3| | | | | Free:20.0GiB | Free:20.0GiB| | | | | Total:29.4GiB | Total:29.4GiB| | | | | Err:- | Err:-
Запрос:
hb pairdb show <НОМЕР_ПАРЫ>
Ответ:
ID | CLASS | KARMA | MAINTENANCE | FLAGS | STORAGE 1 | STORAGE 2---|--------|-------|-------------|-----------------|-------------------|-------------------3 | HOTBOX | 3 | - | HOTBOX,READONLY | 10.3.0.101:8088/3 | 10.3.0.102:8088/3| | | | REDUNDANT | Free:20.0GiB | Free:20.0GiB| | | | | Total:29.4GiB | Total:29.4GiB| | | | | Err:- | Err:-
Запрос:
hb storage unit move --id <НОМЕР_ПАРЫ>
Ответ:
TASK IDS---------[31]
Запрос:
hb storage razmove info --ids <ИДЕНТИФИКАТОР_ЗАДАЧИ> -o yaml
Ответ:
task_id: 31status: processingmtime: 2026-05-13T10:30:41+03:00taken: 2026-05-13T10:31:28+03:00taken_count: 4ext_id: 8qPzSrxAHR2bL4rb3T9UnkiVsbefore: 0priority: 99src_pair_id: 3limit: 1000total: 3205who: mono01.local.razmove-workermoved: 3000last_hash: ed82551eda6123f721f54d539635788fbfc4c289
Здесь:
task_id— идентификатор задачи.status— может принимать значения:waiting— задача создана, но еще не выбрана для исполнения.processing— задача выбрана для исполнения и обрабатывается.done— задача успешно выполнена.failed— в ходе выполнения задачи возникли ошибки, выполнение прервано.
mtime— время создания задачи.taken— время последнего принятия на исполнение.taken_count— сколько раз задача взята на выполнение. Обрабатывается блоками по 1000 (limit) файлов.ext_id— уникальный идентификатор задачи (отличается от task_id: task_id также уникален, но имеет типintegerи присваивается JetQueue автоматически как порядковый номер).before— количество задач в очереди, стоящих перед данной задачей.priority— повышает/понижает приоритет выполнения задачи (priorityне подлежит изменению, установлено значение99).src_pair_id— номер пары, с которой выполняется перенос данных.limit— сколько всего файлов обрабатывается за одну итерацию. Фактически задает гранулярность изменения поляmoved, например, будет последовательно изменяться следующим образом: 0 -> 1000 -> 2000 -> 3000 -> 3205.total— сколько всего файлов (хешей) необходимо переместить.who— каким именно инстансом сервисаrazmove-workerзадача последний раз была принята на исполнение.moved— сколько файлов уже перенесено, прогресс операции.last_hash— последний обработанный хеш.
Запрос:
hb storage razmove list
Ответ:
TASKID | STATUS | SRC PAIRID | M TIME | TAKEN | TOTAL | MOVED | COUNT | WHO-------|--------|------------|-------------------------------|-------------------------------|-------|-------|-------|----------------------------31 | done | 3 | 2026-05-13 10:30:41 +0300 MSK | 2026-05-13 10:31:28 +0300 MSK | 3205 | 3205 | 0 | mono03.local.razmove-worker
Запрос:
hb storage razmove delete --ids <ИДЕНТИФИКАТОР_ЗАДАЧИ>
Удаление задачи в статусе processing возможно только с ключом --force.
Запрос:
hb storage razmove delete --ids <ИДЕНТИФИКАТОР_ЗАДАЧИ> --force
Запрос:
hb storage razmove retry --ids <ИДЕНТИФИКАТОР_ЗАДАЧИ>