/ DOCS
nav-img
Evolution
SDS

Решение проблем

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

  1. В конфигурационном файле измените значение log-level на debug.

  2. Перезагрузите сервис одним из способов:

     
    systemctl reload storage-csd@${cs_id}

    или

     
    kill -SIGHUP $pid

Типичные проблемы можно условно разделить на несколько классов.

Падение сервиса (crash, assertion failure, etc)

При падении сервиса обычно остаются кордампы и логи сервиса /var/log/storage/cs.{CS_ID}/*.zst. Иногда подсистема логирования не может или не успевает записать буфер на диск, тогда в логе будут отсутствовать последние строки. В таком случае, стоит проверить stdout файл в той же директории.

При падении сервиса:

  1. Проанализируйте coredump стандартными средствами.

  2. Установите пакет storage-csd-dbg той же версии, что и дамп.

  3. Для анализа бэктрейса выполните:

     
    cat backtrace.txt | seastar/scripts/seastar-addr2line -e /usr/bin/csd

Ошибка сервиса

CS может вернуть ошибку клиентской библиотеки или MDS, это будет отражено в логах. Если ошибка признана критической, CS может получить статус failed.

При ошибке клиентской библиотеки:

  1. Найдите момент возникновения ошибки в логах.

  2. Для поиска записей по чанку используйте подстроку {0xa4c}, где A4C — id чанка в hex. Не все строки следуют данному форматированию, но это позволит получить первое приближение.

Пример логирования входящих и завершенных запросов:

 
INFO  2024-03-12 16:36:21.611558 csd0 - [0000000000000022;53e3f] WriteReq f:0xd {0x5} (0x208000+0x6000x2) sn: 2 2 frags: [ca..]
# расшифровка:
#   INFO - важность сообщения
#   локальное время записи
#   csd0 - логгер сервис, в данном случае общий логгер csd
#   0000000000000022 - UID источника запроса в hex, в старших битах кодируется тип (08 в начале означает libsbd клиента)
#   53e3f - UID запроса в hex, монотонно возрастает для каждого исходящего запроса у каждого источника (сбрасывается при рестарте)
#   WriteReq - тип запроса
#   0xd - флаги запроса в hex
#   {0x5} - UID чанка
# далее идут поля специфичные для конкретного типа
#   0x208000 - смещение записи в чанке
#   0x6000 - длина записи
#   х2 - запись должна быть повторена 2 раза (WRITE_SAME семантика)
#   sn: 2 - внутренний порядковый номер записи, может быть 0 (не назначен)
#   2 frags: [ca..] - сколько фрагментов содержит буфер записи и первый байт запроса в hex


DEBUG 2024-03-12 16:36:21.612449 csd0 - [0000000000000022;53e3f] WriteReq success (lat=886us, local)
# реквест [22;53e3f] завершился успешно за 886 микросекунд, локально (Write запрос также может включать в себя фазу пересылки данных на другие CS в чанк группе и их ожидание, в таком случае задержка будет указана "with fwd")


INFO  2024-03-12 16:36:22.173607 csd0 - [080000000000042c;53faf] ReadReq f:0x1 {0x5} vol 1 (0x7000+0x4000)
# аналогично, реквест 53faf от клиента 42c с флагом 1 в чанк 0x5, в volumeid 1, по смещению 0x7000 размером 0x4000


DEBUG 2024-03-12 16:36:22.173927 csd0 - [080000000000042c;53faf] ReadReq success (lat=317us, local)
# завершился успехом за 317 микросекунд

Таймауты

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

Если сервис не получает ответ от других сервисов, в логах будут отражены соответствующие ошибки:

 
ERR_TIMEOUT               = 9; // Request was timeouted
ERR_NET                   = 20; // Miscellaneous network error
ERR_NET_CLOSED            = 21; // RPC call aborted due to closed connection

Если сервис не получает ответа от соседних CS, он выведет сообщения вида:

 
host 1.2.3.4 is unreachable    # где 1.2.3.4 - IP адрес недоступного сервиса

После восстановления связи:

 
host 1.2.3.4 is reachable again    # где 1.2.3.4 - IP адрес недоступного сервиса

Проверьте наличие строк с keepalive. Они могут свидетельствовать о закрытии соединения по таймауту.

Таймауты могут быть следствием перегрузки сервиса. При этом:

  1. Исследуйте метрики в Grafana:

    • Загрузка CPU;

    • Количество и latency запросов;

    • Нетипичная активность (например, высокая скорость recovery).

  2. Найдите аномальную активность и устраните проблему.

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