Avamar. Сбои приостановленных разделов, чередования и hfscheck в Avamar

1. В пользовательском интерфейсе сервера администраторов Avamar может появиться следующая ошибка. Это сообщение может создать запрос на обслуживание домашнего вызова (SR):

Symptom Code: 22632, Desc: A server disk has become suspended.

2. WARN-сообщения, связанные с perfbeat на узлах хранения данных в /data01/cur/gsan.log.

WARN: <0968> perfbeat::outoftolerance mbpersec=0.31 average=5.66
WARN: <1051> tperfstatechanger::execute server_exception(MSG_ERR_UNNECESSARY) diskid=0 newstate=suspended
WARN: <1084> changing disk 0 on node 0.3 to suspended state

3. Переменная status.dpn Вывод показывает, что чередование диска приостановлено:
(Этот вывод создается только при возникновении «WARN <1084>».)

Например:

0.8 10.10.10.10 7.3.1-125 ONLINE fullaccess mhpu+0hpu+0hpu 1 false 7.36 16350564 3401334 56.0% 66%(onl:1,SUS:2374) 50%(onl:2439) 50%(onl:2433) 

Эти выходные данные показывают, что имеется 2374 подвешенных полосы.

4. Переменная hfscheck завершается сбоем, если раздел приостанавливается, а hfscheck работает. Пример ошибки из /data01/hfscheck/err.log или /data01/cur/err.log ар: 

ERROR: <0001> indexstripe::hfschecksweepbody stripe=0.0-1209 proxy=0.0-1209 indexelem([hash=ee9b2fe66b4bd472e28c4f41c5097dbeaba7131a stripe=0.1-DF8 offset=1285]) goodowner=true goodelem=false

Периодически, каждые пять минут по умолчанию, gsan «тестирует» I/O подсистемы, выполняя небольшие операции чтения из разделов данных.

Он проверяет, составляет ли производительность чтения на 10% от нормальной производительности.

В приведенном ниже примере сообщение указывает на то, что на конкретном узле, создавшем предупреждение, средняя производительность чтения за продолжительное количество попыток при hfscheck примерно 54,03 МБ/с. Однако в этом конкретном тесте фактическая производительность составила 0,57 МБ/с, что ниже «предела» в 10% от среднего значения, или 5,4029 МБ/с.

Event Summary = perfbeat::outoftolerance mask=[hfscheck] average=54.03 limit=5.4029 mbpersec=0.57

Первоначальная цель этого теста состояла в том, чтобы предупредить о наличии проблемы с I/O подсистема, которая приводит к чрезмерно низкой производительности чтения. 

В этом случае медленнее, чем 10% «среднего» диска I/O производительность.

Переменная perftriallimit Указывает количество последовательных тестов чтения диска, перед которыми должен выйти допустимый допуск perfbeat Есть подозрение, что производительность диска возможна.

Переменная perfinterval (по умолчанию 300 с или 5 минут) указывает, сколько времени должно ожидаться между perftriallimit тест.

Когда? perfbeat подозревая, что диск деградировал, он сообщает gsan , чтобы перейти в холодное состояние (остановить все операции, связанные с диском). 

Он ожидает не более 20 минут (проводно), пока gsan , чтобы войти в это состояние до истечения времени ожидания и без приостановки диска.

Если достигнуто холодное состояние, то perfbeat Выполняет perfcoldtriallimit (по умолчанию 4) Увеличено количество тестов чтения perfcoldinterval (по умолчанию 30) с интервалом.

Работа диска будет приостановлена только в том случае, если все эти тесты покажут, что его производительность все еще ограничена.

Возможные причины приостановки работы дисков.

• При попытке перейти в холодное состояние gsan всегда ждет, по крайней мере, одну минуту (запрограммировано). Он также ожидает все ожидающие диски gsan I/O для завершения или приостановления их деятельности. Однако после перехода в «холодное» состояние операционная система может продолжать работать с диском I/O, например, очистив кэш. Эта операция очистки является одним из возможных объяснений того, почему диски приостанавливаются без необходимости. Чем больше объем памяти, тем больше данных кэш-памяти нужно сбрасывать.

• Другое возможное объяснение заключается в том, что информация журнала производительности не позволяет точно предсказать ожидаемую производительность чтения с диска во время различных gsan деятельности, потому что gsan's Поведение менялось слишком быстро, чтобы история могла отразить его (история представляет собой среднее значение измерений производительности за последние 10 дней).

• Другое возможное объяснение заключается в том, что может возникнуть проблема, например, если вы не будете ждать всех gsan диск I/O действий по завершению или приостановке их работы до перехода в холодное состояние.

Кроме того, исследования показали, что во время hfscheck »indexsweep" (когда все хеши в индексных полосах считываются, а затем выполняются массовые произвольные записи во множество файлов DRL (Data Referenced Log, DRL)) I/O Производительность снижается в течение значительного периода времени.

В Avamar Data Store 4-го, 4-го и 4-го поколений операции записи имеют приоритет над операциями чтения, и важность тестирования производительности чтения I/O подсистема намного ниже. Кроме того, некоторые накопители (например, Seagate Megalodon drives) использовать некоторые другие методы, которые могут запутать тесты, выполняемые тестом perfbeat нить.

Предпосылка.

Как правило, в меню отображается три различных предупреждающих сообщения gsan Журналы:

WARN: <0968> perfbeat::outoftolerance mbpersec=0.31 average=5.66

Предупреждение <0968> указывает на то, что gsan I/O Тест был медленным.

Это сообщение можно игнорировать.

WARN: <1051> tperfstatechanger::execute server_exception(MSG_ERR_UNNECESSARY) diskid=0 newstate=suspended

Предупреждение <1051> указывает на то, что медленных операций чтения было достаточно, чтобы gsan рассматривали возможность перевода раздела данных в приостановленное состояние, но решили этого не делать. Именно об этом MSG_ERR_UNNECESSARY и говорит.

Это сообщение можно игнорировать.

WARN: <1084> changing disk 0 on node 0.3 to suspended state

Предупреждение <1084> указывает на то, что gsan перевела раздел данных в «приостановленное состояние».

Это сообщение нельзя игнорировать.

Разрешение.

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

Чтобы определить расположение приостановленного раздела, выполните следующие действия:

1. Войдите в Avamar Utility Node в качестве пользователя «admin».

2. Повышение до привилегий root.

3. Загрузка корневых ключей для Avamar: Как выполнить вход в Avamar Server и загрузить разные ключи.

4. Выполните следующую команду, чтобы определить расположение приостановленного раздела:

mapall --noerror 'grep -i "suspended" /data01/cur/err.log'

5. Просмотрите сценарии, поскольку они относятся к приведенным выше результатам:

• • Никаких действий не требуется. Полосы автоматически возвращаются в оперативный режим. Весьма вероятно, что hfscheck бежали. 

• • Если полосы данных автоматически возвращаются в оперативный режим, весьма вероятно, что сборка мусора или hfscheck бежали.
  • ВАЖНО! Это может указывать на проблему с диском или на какую-либо скрытую неполадку.
  • Несмотря на то, что сбой накопителя еще не обнаружен, его все равно следует проверить, выполнив следующие действия.

1. Определите, какие физические диски связаны с диском, деятельность которого была приостановлена в Avamar. Основной причиной приостановки могут быть проблемы с физическим диском в виртуальном диске:

avsysreport pdisk vdisk=x 

Где x — номер виртуального диска (раздела данных), работа которого была приостановлена. Например, если в первом разделе данных обнаружены приостановленные полосы, запросите vdis=0.

2. Убедитесь в отсутствии сбоев дисков, прогнозируемых сбоев или других ошибок на уровне физического диска.

3. Убедитесь в отсутствии ошибок SCSI на физических дисках, представляющих виртуальный диск на рассматриваемом узле (определяется на шаге 1). 

grep -i "MRMON\|scsi|Adaptec" /var/log/messages

4. Виртуальные диски в режиме сквозной записи могут приводить к приостановке диска из-за низкого I/O. Проверьте политику записи на контроллере:

mapall --noerror --all+ 'avsysreport vdisk | grep "Write Policy"'  

Если на шагах 2–4 обнаружены какие-либо проблемы, откройте SR в службе поддержки Dell Technologies Avamar для дальнейшего изучения.

Сценарий# 3: Проверьте значение по умолчанию perftriallimit Параметры:

1. Убедитесь, что perftriallimit установлено в 0:

avmaint config --ava | grep perftriallimit 

perftriallimit="0"

2. Если perftriallimit является чем-либо, отличным от нуля:

avmaint config --ava perftriallimit=0

avmaint config --ava | grep perftriallimit 

perftriallimit="0"