VK Object Storage logo
Помощь
Обновлена 20 октября 2026 г. в 12:40

Операции с дисковым хранилищем

Добавление пары

  1. Подключите диски к Storage-серверам.

  2. Подключитесь к Storage-серверу с добавленными дисками.

  3. С помощью команды lsblk убедитесь, что диски определились, и запишите их имена (sda, vda, nvme*).

  4. Подключитесь к деплой-ноде и отредактируйте файл /deploy/installer/inventory.yml:

    1. В секции storage заполните последовательность mounts с правилами разметки дисков под пары, добавив записи о новых дисках. Например, в Системе два Storage-сервера (storage-1 и storage-2), на них добавили по одному новому диску /dev/vdd.

      storage:      hosts:        storage-[1:2]:          mounts:          - pair_number: 1            partition: 1            device: /dev/vdb            start: 0%            end: 100%          - pair_number: 2            partition: 1            device: /dev/vdc            start: 0%            end: 100%
    2. Добавьте информацию о третьей паре:

      - pair_number: 3            partition: 1            device: /dev/vdd            start: 0%            end: 100%
  5. Запустите установку для внесения изменений в конфигурацию Системы. При этом:

    • На дисках будет создан раздел, файловая система и назначены права.
    • Диски будут примонтированы через system unit к /storage/<НОМЕР_ПАРЫ>.
  6. После завершения работы установщика система перечитает конфигурацию в течение пары минут, и диски можно будет проверить командой hb pairdb list.

Если по каким-то причинам запустить установщик нельзя или нежелательно, выполните процедуру вручную:

  1. Подключите диски к Storage-серверам.

  2. Подключитесь к каждому Storage-серверу с добавленными дисками и выполните следующие действия:

    1. Утилитой gdisk создайте GPT-раздел, присвойте ему имя (команда c внутри gdisk) storage-<НОМЕР_ПАРЫ>.

    2. Отформатируйте раздел в ext4.

    3. Через blkid /dev/xxx1 убедитесь, что PARTLABEL имеет метку формата storage&uhyph<НОМЕР_ПАРЫ>.

    4. Скопируйте unit-файл уже существующего диска в новый, например:

      $ cp /etc/systemd/system/storage-2.mount /etc/systemd/system/storage-3.mount
    5. Отредактируйте unit-файл /etc/systemd/system/storage-3.

    6. Выполните команду:

      $ systemctl daemon-reload
    7. Создайте точку монтирования /storage/<НОМЕР_ПАРЫ>.

    8. Примонтируйте диск:

      $ systemctl start storage-3.mount
    9. Назначьте права:

      $ chown -R nobody:nobody /storage/<НОМЕР_ПАРЫ>/
  3. Добавьте в конфигурацию сервиса Nginx на Storage-серверах информацию о новой паре:

    1. В файле конфигурации /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;   ...}
    2. Запустите проверку конфигурации Nginx:

      $ nginx -tnginx: the configuration file /etc/nginx/nginx.conf syntax is oknginx: configuration file /etc/nginx/nginx.conf test is successful
    3. Если проверка закончилась удачно, перезагрузите конфигурацию Nginx командой systemctl reload nginx.

  4. Подключитесь к любому Metadata-серверу и добавьте пару:

    $ hb pairdb insert --id 3 --flags HOTBOX,REDUNDANT --storages=1<IP_АДРЕС_STORAGE-СЕРВЕРА1>:8088/<НОМЕР_ПАРЫ>,<IP_АДРЕС_STORAGE-СЕРВЕРА2>:8088/<НОМЕР_ПАРЫ>
  5. Для проверки корректности добавления пары выполните команду hb pairdb list. При корректном добавлении объемы Total и Free совпадают и отображают реальный объем данных.

Замена поврежденного диска

  1. Перед заменой диска выполните процедуру переноса данных (размиграцию):

    1. Подключитесь к деплой-ноде и проверьте режим работы пары с поврежденным диском:

      $ hb pairdb show <НОМЕР_ПАРЫ>
    2. Установите флаг READONLY для пары, если она в другом режиме:

      $ hb pairdb mark <НОМЕР_ПАРЫ> READONLY
    3. Убедитесь, что для пары выставлен флаг READONLY:

      $ hb pairdb show <НОМЕР_ПАРЫ>
    4. Запустите размиграцию:

      $ hb storage unit move --id <НОМЕР_ПАРЫ>

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

      • В Grafana в дашборде Moving.
      • По логу /var/log/razmove-worker/razmove-worker.log на серверах, где запущены процессы обработчиков размиграции.
    5. Проверьте статус задачи командой:

      $ hb storage razmove info --ids <ID_ЗАДАЧИ> -o yaml
    6. Флаг READONLY автоматически не снимается. Если необходимо, снимите флаг:

      $ hb pairdb unmark <НОМЕР_ПАРЫ> READONLY
  2. После физической замены поврежденного диска создайте в нем раздел, файловую систему и назначьте права, как описано в инструкции по ручному добавлению пар.

  3. Перезагрузите конфигурацию NGINX (даже если файл с его конфигурацией не изменялся):

    $ systemctl reload nginx
  4. Запустите компонент Haron принудительно:

    $ sudo -u nobody haron -f -c /etc/storage-daemons/config.yaml -pair_ids <НОМЕР_СИНХРОНИЗИРУЕМОЙ_ПАРЫ> mtime-skip-new="1m"

Очистка локальных пар после аварии

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

  1. Подключитесь к деплой-ноде и проверьте режим работы пары:

    hb pairdb show <НОМЕР_ПАРЫ>
  2. Переведите пару в режим read-only:

    hb pairdb mark <НОМЕР_ПАРЫ> READONLY
  3. Проверьте, что пара находится в режиме read-only:

    hb pairdb show <НОМЕР_ПАРЫ>
  4. Запустите размув:

    hb storage unit move --id <НОМЕР_ПАРЫ>

    В консоли появится идентификатор задачи, далее <id задачи>. Процедура выполняется в фоновом режиме, за ее работой можно наблюдать:

    • В Grafana в дашборде Moving.
    • По логу /var/log/razmove-worker/razmove-worker.log на серверах, где запущены razmove-worker процессы.
  5. Проверьте статус задачи по выводу команды:

    hb storage razmove info --ids <ИДЕНТИФИКАТОР_ЗАДАЧИ> -o yaml
  6. Флаг FAULT снимается автоматически после успешного прохождения проверки на работоспособность (healthcheck). Если флаг не снялся, снимите его вручную командой:

    hb pairdb unmark <НОМЕР_ПАРЫ> FAULT
  7. Убедитесь, что пара больше не помечена как FAULT и доступна для использования. Для этого выполните команду:

    hb pairdb list

Факторы репликации

Факторы репликации определяют, сколько реплик (копий) данных будет создано.

По умолчанию система выполняет репликацию Х2. В инструкции описывается последовательность шагов для изменения фактора репликации. Примечание: в рамках перехода на факторы репликации пара будет называться юнит, а диск или его часть (один из дисков пары) — парт.

Порядок действий для обновления до факторов репликации Х3:

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

    1. Выключите чтение из таблицы pairs командой (включение чтения юнитов):
    $ switchover -p hotbox e set "pairdb/common/app/api/disable_old_schema_read" true
    1. Выключите запись в таблицу pairs командой (включение записи юнитов):
    $ switchover -p hotbox e set "pairdb/common/app/api/disable_old_schema_write" true
    1. Проверьте изменения командой:
    $ switchover -p hotbox e getr "pairdb/common/app/api"
    1. Выполните рестарт кластера PairDB:
    $ switchover -p hotbox pr --cluster pairdb -y
  2. Измените конфигурацию Gostreamer в файле /etc/gostreamer/config.yaml (или по заданному пути):

    streamer:     redundancy:       enabled: true # для включения функциональности юнитов, значение по умолчанию – false       min_write: 2 # минимальное количество успешных записей, значение по умолчанию – 2
  3. Выполните рестарт компонента Gostreamer:

    $ sudo systemctl restart gostreamer
  4. Измените конфигурацию Haron в файле /etc/storage-daemons/config.yaml:

    haron:     redundancy:       enabled: true # использование новых версий API, значение по умолчанию – false
  5. Выполните рестарт компонента Haron:

    $ sudo systemctl restart haron
  6. Установите необходимое количество юнитов в PairDB командой:

    $ switchover -p hotbox e set "pairdb/common/app/storage_unit/size_limit" 3
  7. Проверьте изменения командой:

    $ switchover -p hotbox e getr "pairdb/common/app/storage_unit"
  8. Выполните рестарт кластера PairDB:

    $ switchover -p hotbox pr --cluster pairdb -y
  9. Добавьте недостающий парт или юнит соответствующей командой:

    • для добавления парта в существующий юнит используйте команду hb pairdb add_part, например:
    $ hb pairdb add_part --id=<ИДЕНТИФИКАТОР_ЮНИТА> --parts=<IP_ПАРТА1>:<ПОРТ_ПАРТА1>/<ИДЕНТИФИКАТОР_ЮНИТА>,<IP_ПАРТА2>:<ПОРТ_ПАРТА2>/<ИДЕНТИФИКАТОР_ЮНИТА>
    * для добавления юнита используйте команду `hb pairdb insert`, например:
    $ 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

Ответ:

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

За установку и снятие флага FAULT отвечает фоновый процесс PairDB — Fault. Он же обновляет информацию о свободном месте партов.

Процесс Fault обрабатывает только те юниты, задача на обработку которых попала в пространство tasks. Для проверки работоспособности (healthcheck) на каждом диске юнита процесс выполняет три HTTP-запроса к файлу http://<IP_АДРЕС_СЕРВЕРА>:<ПОРТ>/<НОМЕР_ПАРЫ>/tmp/temp_pairdb_healthcheck.txt:

  1. DELETE — удаление файла, оставшегося от предыдущей проверки.
  2. PUT — запись временного файла.
  3. DELETE — удаление временного файла.

Тайм-аут каждого запроса — 3 секунды (значение по умолчанию).

Если в ходе проверки удается получить информацию о свободном месте партов, процесс Fault обновляет значение Free и снимает флаг FAULT. Если на любом из дисков юнита возникла ошибка записи, удаления или тайм-аут, юниту выставляется флаг FAULT.

Снять флаг можно и вручную командой:

$ hb pairdb unmark <НОМЕР_ПАРЫ> FAULT

Просмотр наличия файлов на юните

Запрос:

hb storage unit count <ИДЕНТИФИКАТОР_ЮНИТА>

Ответ:

COUNT-------1530

Перевод юнита в состояние READONLY

Запрос:

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:-

Перевод юнита из состояния READONLY

Запрос:

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:-

Cоздание задачи на перенос файлов

Запрос:

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

Удаление задачи в статусе processing возможно только с ключом --force.

Запрос:

hb storage razmove delete --ids <ИДЕНТИФИКАТОР_ЗАДАЧИ> --force

Перевод задачи в статус waiting из статуса failed

Запрос:

hb storage razmove retry --ids <ИДЕНТИФИКАТОР_ЗАДАЧИ>
Была ли статья полезна?