Авамар: Підвішені розділи, смуги та збої 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. The 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. The 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 Продуктивність.

The perftriallimit визначає кількість послідовних тестів зчитування диска, які мають бути поза допустимим допуском перед тим, як perfbeat підозрює, що диск може бути пошкоджений.

The 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" фаза (коли всі хеши в індексних смугах зчитуються і потім виконуються масові випадкові записи у багато файлів Data Referenced Log (DRL)) — це тестувалося I/O Продуктивність падає на значний час.

У Avamar Data Store Gen4, Gen4 та Gen4T операції запису мають пріоритет над операціями читання, а також важливість тестування продуктивності читання I/O Підсистема значно нижча. Також деякі диски (наприклад, Seagate Megalodon приводи) використовують деякі інші методики, які можуть заплутати тести, що проводяться, з приводами 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 як адміністратор.

2. Піднесіть до кореневої привілеї.

3. Завантажте кореневі ключі для Avamar: Як увійти на сервер Avamar і завантажити різні ключі.

4. Виконайте наступну команду для визначення розташування призупиненого розділу:

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

5. Перегляньте сценарії відповідно до наведених вище результатів:

• • Дії не потрібні. Stripes автоматично повертається онлайн. Дуже ймовірно, що 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"