Как диагностировать storWize V7000 — Alert: 1630 — run FIX?
Ссылка скопирована
Сейчас ситуация такая: в системе висит старая ошибка: Alert: "StorWize V7000 error 1630: number of device logins reduced"
По вводным: рекомендация - выполнить FIX, что бы пересканировать пути и при необходимости восстановить. Дисковая полка под нагрузкой, порты FC без ошибок, все LUN в online, на виртуализации чисто, потери путей нет.
Нужно понять: вопрос - выполнение FIX не приведет к сбою в работе с данными? Или, если все rомпоненты в норме просто снять этот Alert, не выполняя рекомендаций?
Нужно решить такую задачу?
Заказать помощь
Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.
Лучший ответ
1
Backend-редакция
Ответ
Другие ответы (0)
Пока нет других ответов. Будьте первым, кто поможет автору.
Ответить на вопроскомментарий
Вам также может быть интересно
VPN
Как правильно настроить vless для Android TV?
1 ответ
Pyrogram
Как правильно зарегистрировать юзер бота в Telegram?
1 ответ
печатные-платы
Как заставить запускаться программу M3.exe от компании Hanxing AOI в инспекционной машине на Windows 7 Pro?
1 ответ
Аккумуляторные батареи
Почему при зарядке автостарта слышен писк, где искать причину?
1 ответ
Для Storwize V7000 alert 1630 “number of device logins reduced” обычно означает, что система видела больше путей/логинов к устройствам, а теперь их стало меньше. Это может быть старый след после работ на SAN, перезагрузки хоста, временной потери FC-порта или zoning-изменений. Нажимать FIX вслепую на нагруженной системе я бы не советовал, пока не понятно, что именно будет пересканироваться.
Сначала соберите факты:
Проверьте со стороны хостов multipath. На Linux:
multipath -ll sanlun lun show -p dmesg | grep -iE "fc|scsi|multipath|path"
На VMware смотрите paths к datastore/LUN: все ли active/standby как ожидается. Если потерь путей нет, LUN online и на FC-коммутаторах чисто, alert может быть устаревшим.
FIX в интерфейсе IBM часто запускает рекомендуемую процедуру восстановления/перепроверки. Обычно она не должна ронять данные, но может инициировать rediscovery и создать дополнительную нагрузку или кратковременные изменения состояния путей. Поэтому для production лучше делать это в окно минимальной нагрузки или после подтверждения по документации IBM именно для вашего уровня прошивки.
Если все компоненты в норме, безопаснее сначала сохранить support package, зафиксировать текущее состояние путей и только потом выполнять recommended action. Просто “снять alert” можно, если вы уверены, что причина устранена, но это маскирует проблему, если один путь реально потерян.
Итог: не начинайте с кнопки FIX. Сначала проверьте multipath на хостах, FC switch counters, события Storwize и соответствие ожидаемому числу путей. Если всё стабильно и alert старый, выполняйте FIX/clear в согласованное окно или после проверки IBM docs по конкретному alert 1630.