ВПЛЕКС: Диск позначено як апаратний глухий через умову перевірки SCSI 3/11/0 від storage-array

Ця подія спрацьовує, коли VPLEX виконує запит на читання до базового масиву зберігання LUN, і масив не може обслуговувати введення-виведення на цьому блоці LUN, що викликає умову перевірки 3/11/0 (поганий блок на масиві)Це

зазвичай спостерігається в ситуаціях для часів інтенсивного читання-введення-виведення, таких як:

• Міграція VPLEX/пристрою
• Операції резервного копіювання
• Перевірка цілісності бази даних

Том сховища VPLEX позначений як "hardware-dead", але відображається справним в інтерфейсі storage-array.

Приклад виводу з команди cli ll /clusters/cluster-2/storage-elements/storage-volumes/storage-volume name>
 

Міграція пристроїв/екстентів VPLEX (робота з мобільності) застрягає на певному відсотку.

Приклад виводу з команди cli ll data-migrations/device-migrations/<device_migration_name>
 

Хост бачить, що сховище VPLEX переходить в автономний режим або позначається як мертве, а обсяг сховища VPLEX також позначається як критичний збій або апаратно мертвий.

Зразкові дані, як зазначено в журналі прошивки,
amf/45 disk VPD83T3:xxxxxxxxxxxxxxx: read failure: marking this in-use disk dead

Журнали прошивки VPLEX показують потокове або переривчасте scsi/27 (Check Condition) із записами SCSI Sense Code для 3/11/0, що перекладається як «Medium Error - unrecovered read error«

Вихід зразка, як зазначено в журналі прошивки під час інциденту,

2016/06/09 02:46:23.67: scsi/27 tgt VPD83T3:6006016011663200b058c25a984de511 cmd 0x28 status 0x2 valid 0 resp 0x70 seg 0x0 bits 0x0 key 0x3 info 0x0 alen 10 csi 0x0 asc 0x11 ascq 0x0 fru 0x0 sks 0x0
2016/06/09 02:46:23.68: scsi/27 tgt VPD83T3:6006016011663200b058c25a984de511 cmd 0x28 status 0x2 valid 0 resp 0x70 seg 0x0 bits 0x0 key 0x3 info 0x0 alen 10 csi 0x0 asc 0x11 ascq 0x0 fru 0x0 sks 0x0
2016/06/09 02:46:23.69: scsi/27 tgt VPD83T3:6006016011663200b058c25a984de511 cmd 0x28 status 0x2 valid 0 resp 0x70 seg 0x0 bits 0x0 key 0x3 info 0x0 alen 10 csi 0x0 asc 0x11 ascq 0x0 fru 0x0 sks 0x0

Щоб підтвердити цю проблему, завжди буде вірно наступне:
key   = 0x3
asc   =  0x11
ascq = 0x0

Коли VPLEX надсилає запит на читання вводу/виводу (0x28) до storage-масиву, масив не може успішно обслуговувати запит на введення-виведення та відповідає умовою перевірки 3/11/0 за «невідновлену помилку читання».

VPLEX намагається прочитати з пошкодженого блоку на масиві storage, і оскільки storage-array не може обслуговувати цей IN/O VPLEX позначає сховище як мертве.

Це не залежить від масиву або коду масиву.

Причиною цього є зовнішнє по відношенню до VPLEX і є проблема на storage-масиві з LUN.

Масив сховища, який надсилає умову перевірки scsi, 3/11/0, до VPLEX, повинен бути досліджений відповідним постачальником масиву. Ця проблема виникає через те, що масив не може обслуговувати запит введення-виведення на читання через проблему «невідновленого читання» на масиві storage.

Необхідно задіяти підтримку VNX.

Наступна команда cli може бути виконана на VPLEX Management-Server, щоб отримати список з 50 найкращих логічних одиниць, на які впливають умови перевірки 3/11/0:

grep "key 0x3 " /var/log/VPlex/cli/firmware.log_* | awk '{print $3,$5,$18,$19,$26,$27,$28,$29}' | sort | uniq -c | sort -nr | head -50


Приклад:

Це проблема блокового рівня на масиві storage, яка може бути вирішена лише шляхом виконання дій щодо самого масиву сховища.

Це не проблема VPLEX, а VPLEX повідомляє про симптом, який видно з серверного масиву.

Використання "storage-volume resurrect --force" тут не є коректним.
Ця команда змушує мертвий том сховища відображатися як "живий" у VPLEX, незалежно від його поточного статусу вводу-виводу або проблем на базовому масиві сховища.
Ця команда змушує том сховища повертатися в мережу до тих пір, поки наступний IO не вийде з ладу в базовому масиві сховища.
Коли хост запитує той самий блок даних, який має проблему 3/11/0 на базовому масиві сховища, том сховища знову буде позначено як мертвий.
Це очікувана поведінка, а не ознака проблеми з VPLEX.


Представлення проблемного тома сховища безпосередньо з масиву сховища хосту (в обхід VPLEX) може дозволити хосту використовувати частину даних. Однак ця дія безпосередньо вказує на можливе пошкодження даних хосту. У хоста продовжують виникати проблеми зі зчитуванням конкретних блоків з проблемою умови перевірки 3/11/0.