Как в Red Hat Enterprise Linux 6 определить разницу между проблемой зонирования SAN (например, не удается достичь хранилища вообще) и проблемой маскирования LUN (например, LUN не назначены правильному WWN HBA)?
В HP-UX (да, я знаю ...) это довольно просто - дисковый массив представляет цели с другой строкой идентификатора SCSI в выводе "ioscan":
LUN из этого дискового массива показывают тип эмуляции виртуального LUN "OPEN-V" (путь вправо):
target 11 0/5/2/0/4/0.117.7.0.0.0 tgt CLAIMED DEVICE
disk 3 0/5/2/0/4/0.117.7.0.0.0.0 sdisk CLAIMED DEVICE HP OPEN-V
Сам дисковый массив показывает «DISK-SUBSYSTEM» вместо «OPEN-V» на каждой цели SCSI, даже если не назначены LUN:
target 16 0/5/2/0/4/0.117.7.0.0.5 tgt CLAIMED DEVICE
disk 29 0/5/2/0/4/0.117.7.0.0.5.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
Это также может быть просто результатом выбора для массива эмуляции, совместимой с HPUX. Я знаю, что древние версии HPUX очень разозлились, когда увидели цель SCSI без LUN 0, поэтому хранилище может заставлять себя представлять замещающий LUN 0 только в этом режиме эмуляции.
Существует ли в Linux аналогичный диагностический тест, который поможет определить, видно ли вообще хранилище (например, зонирование - это хорошо, назначения LUN плохие), по сравнению с хранилищем, которое не отображается вообще (например, зонирование - это плохо)?
"lsscsi","lsblk","blockdev --report", и "cat /proc/scsi/scsi"все, кажется, сообщают только тогда, когда все LUN видны полностью (и зонирование, и маскировка LUN хороши).
Я проткнул /sys/class/scsi_generic думая, что, возможно, цель, назначенная без дискового устройства, может появиться по крайней мере с универсальным устройством SCSI, но единственными устройствами sgX являются те, которые связаны с дисковыми блочными устройствами, что означает, что LUN работают нормально на всем пути от хранилища до хоста.
Что вы используете для выявления проблем с зонированием и назначением LUN в Linux?