/ DOCS
nav-img
Evolution

Порядок проверки работоспособности системы

Команды для проверки работоспособности системы:

  • storage stat;

  • storage top.

  1. Создайте том для тестирования с выбранными параметрами:

     
    $ storage volume make --size 100GB --storage-class erasure
    Volume 0xbf89676ba3e4fc2e added

  2. Запустите Fio для созданного тома с плагином sbd.

     
    fio -ioengine=/usr/lib/libfio_sbd.so -name=test -bs=4k -direct=1 -iodepth=128 -rw=write -size=1G -volume=bf89676ba3e4fc2e

    Где:

    • --volume bf89676ba3e4fc2e — id тома в hex формате.

Опциональные параметры плагина sbd:

  • client-id 111 — client id (default: random);

  • tout 3 — io timeout (default: 3s);

  • ram — run fio over ram block device (default: 0);

  • log-level [trace, debug, info, warn, error] — уровень логирования (default: error);

  • log-to-file — параметр для включения логирования sbd в файл. По умолчанию все логи sbd пишутся в stdout;

  • log-dir /dir — ддиректория логирования sbd (default: /var/log/storage).

Примечание

Важно! Данная команда должна быть выполнена без ошибок. Для дальнейших проверок используйте storage stat или storage top.

При включенном log-level уровня debug или подробнее, а также при высокой задержке запросов, в лог сохранятся записи, по которым можно судить о времени выполнения:

 
DEBUG 2025-03-26 11:24:08,058 [shard 0:main] sds/client/remote_block_device - 0x176fb73dfb685fd1: write [1] 0x4000+0x2000
DEBUG 2025-03-26 11:24:08,058 [shard 0:main] sds/client/chunk_server - call [1] [0ae8d6baf7318a65;2] WriteReq f:0x29 {0x29} (0x4000+0x2000) sn: 0 1 frags: [35..] -> cs: 3, timeout: 60000ms
DEBUG 2025-03-26 11:24:08,059 [shard 0:main] sds/client/remote_block_device - 0x176fb73dfb685fd1: write [1] done in 1122us; lats D:{cs#3:[944,129]}; I:{cs#2:[575,135]; cs#4:[631,107]}




DEBUG 2025-03-26 13:43:05,363 [shard 0:main] sds/client/remote_block_device - 0x176fb73dfb685fd1: read_fragments [1] 0x4000+0x2000
DEBUG 2025-03-26 13:43:05,363 [shard 0:main] sds/client/chunk_server - call [1] [0a426c4feaa2f9ee;3] ReadReq f:0x1 {0x29} vol 1 (0x4000+0x1000) -> cs: 4, timeout: 60000ms
DEBUG 2025-03-26 13:43:05,363 [shard 0:main] sds/client/chunk_server - call [1] [0a426c4feaa2f9ee;4] ReadReq f:0x1 {0x29} vol 1 (0x5000+0x1000) -> cs: 2, timeout: 60000ms
DEBUG 2025-03-26 13:43:05,364 [shard 0:main] sds/client/remote_block_device - 0x176fb73dfb685fd1: sparse_read [1]: [0a426c4feaa2f9ee;3] ReadReq f:0x1 {0x29} vol 1 (0x4000+0x1000), read_request_offset: 0x0, chunk_idx: 0, strip_idx: 0, result: [0: [off: 0x0, size: 0x1000, crc_sz: 0x0]]
DEBUG 2025-03-26 13:43:05,364 [shard 0:main] sds/client/remote_block_device - 0x176fb73dfb685fd1: sparse_read [1]: [0a426c4feaa2f9ee;4] ReadReq f:0x1 {0x29} vol 1 (0x5000+0x1000), read_request_offset: 0x1000, chunk_idx: 0, strip_idx: 1, result: [0: [off: 0x0, size: 0x1000, crc_sz: 0x0]]
DEBUG 2025-03-26 13:43:05,364 [shard 0:main] sds/client/remote_block_device - 0x176fb73dfb685fd1: sparse_read [1]: issued 2 requests, got 2 fragments, glued to 1
DEBUG 2025-03-26 13:43:05,364 [shard 0:main] sds/client/remote_block_device - 0x176fb73dfb685fd1: read [1] done in 1296us; lats D:{cs#2:[766,154]; cs#4:[1113,130]}

Например:

 
write [1] done in 1122us

Общее время выполнения составило 1122 микросекунд.

 
lats D:{cs#3:[944,129]}; I:{cs#2:[575,135]; cs#4:[631,107]}

Где:

  • lats D (direct): — latency чанк-серверов, на которые поступают запросы от пользователя. Мастер чанк-сервера используется для записи, дата чанк-сервера — для чтения. Данные выводятся в следующем порядке:

    • CS id;

    • время выполнения на чанк-сервере в микросекундах;

    • сетевая задержка — RTT, полное время запроса минус время локального выполнения. Если чанк-сервер перегружен запросами, к задержке добавляется время ожидания в RPC очереди.

  • I (indirect): — latency чанк-серверов, на которые пересылался запрос.

    Предоставляет данные также, как и lats D (direct):.

В примере выше запрос был отправлен на чанк-сервер CS#3. Он переслал его на чанк-сервера CS#2 и CS#4. Локальное выполнение на них заняло 575 и 631 мкс соответственно. Пересылка с CS#3 и обратно заняла 135 и 107 мкс соответственно. На CS#3 локальная фаза заняла 944 мкс, передача данных с клиента и обратно заняла 129 мкс.

Команда storage stat

Введите команду:

 
storage stat

Утилита отображает статистику работоспособности кластера. На рисунке ниже представлены показатели:

  • status (при отображении статуса healthy — система работает без ошибок);

  • mds (при отображении 3 of 3 up — все лидеры кластера доступны и работоспособны);

  • cs (при отображении 30 of 30 up, active: 30 — все чанк-сервера доступны и активны).

Пример выводимых данных по команде Storage stat.

Команда storage top

Введите команду:

 
storage top

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

  • Cluster Status (при отображении статуса healthy — система работает без ошибок);

  • MDS availability (отображает 3/3 — все лидеры кластера доступны и работоспособны).

Пример выводимых данных по команде Storage top.
Примечание

При изменении статуса healthy на degraded проверьте сеть для репликации SDS.

Предыдущая статья
Руководство по эксплуатации Storage Cluster
Следующая статья
Сборка coredumps и их передача
Была ли эта статья полезна?
Поддержка Юридические документы
© 2025 Cloud.ru