VPLEX. Диск помечен как аппаратно мертвый из-за условия проверки SCSI 3/11/0 из массива хранения данных

Это событие возникает, когда VPLEX выполняет запрос на чтение в LUN базового массива хранения данных и массив не может обслуживать операции ввода-вывода для этого блока LUN, что вызывает условие проверки 3/11/0 (плохой блок в массиве).

Это обычно наблюдается в ситуациях интенсивного ввода-вывода при чтении, например:

• Миграция экстента VPLEX/устройства
• Операции резервного копирования
• Проверки целостности баз данных

Том хранилища VPLEX помечен как «hardware-dead», но отображается как работоспособный интерфейс массива хранения.

Пример выходных данных команды 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) в массив хранения, массив не может успешно обслужить этот запрос ввода-вывода и отвечает условием проверки 3/11/0 для «невосстановленной ошибки чтения».

VPLEX пытается прочитать поврежденный блок в массиве хранения, и, поскольку массив хранения данных не может обслуживать этот ввод-вывод, VPLEX помечает хранилище как работавшее.

Это не относится к массиву или коду массива.

Причина этого является внешней для VPLEX и заключается в проблеме в массиве хранения с LUN.

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

Необходимо обратиться в службу поддержки VNX.

Чтобы получить список из 50 основных логических устройств, на которые влияют условия проверки 3/11/0, можно выполнить следующую команду интерфейса командной строки на сервере управления VPLEX:

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


Пример.

Это проблема блочного уровня в массиве хранения данных, которую можно устранить, только выполнив действия с самим массивом хранения данных.

Проблема не связана с VPLEX, а VPLEX сообщает о признаке, наблюдаемом из внутреннего дискового массива.

Здесь нельзя использовать команду «storage-volume resurrect --force».
Эта команда заставляет неработающий том хранения отображаться как «живой» в VPLEX независимо от его текущего состояния ввода-вывода или проблем в базовом массиве хранения.
Эта команда заставляет том хранения данных вернуться в оперативный режим до тех пор, пока не произойдет сбой следующего ввода-вывода в базовом массиве хранения.
Когда хост запрашивает тот же блок данных, который вызвал проблему 3/11/0 в базовом массиве хранения, том хранения данных снова будет помечен как мертвый.
Это ожидаемое поведение, а не признак проблемы с VPLEX.


Представление проблемного тома хранения данных хосту непосредственно из массива хранения данных (в обход VPLEX) может привести к тому, что хост сможет использовать некоторые данные. Однако это действие напрямую сообщает хосту о возможном повреждении данных. Хост по-прежнему испытывает проблемы с чтением определенных блоков с проблемой условия проверки 3/11/0.