Короткий ответ
- Сам по себе FIX не приводит к «потере данных» или порче файловой системы. Он инициирует пересканирование/пере‑логин путей в контроллере — при корректной настройке мультипути на хостах это вызывает только кратковременные переходы (failover) и/или повышение задержек.
- Тем не менее FIX может вызвать кратковременные прерывания I/O (переподключения путей), поэтому его лучше запускать в окно обслуживания или после проверки причин предупреждения.
- Просто «снять» старый Alert без выяснения причины не рекомендуется — вы можете замаскировать реальную проблему.
Что именно проверить перед выполнением FIX
1. Определить, к каким устройствам/хостам относится Alert 1630. Посмотреть детали события и какие device logins уменьшились (какие порты, какие WWN/hosts).
2. Проверить состояние путей в системе StorWize и на хостах:
- в GUI/CLI StorWize — логи событий, статус портов, статус путей/устройств;
- на коммутаторах FC — ошибки на портах, сбойные зонинги;
- на хостах — статистику HBA (link down/up), состояние multipath (paths active/failed), логи ОС.
3. Оценить нагрузку: вы пишете, что шельф под нагрузкой — выполнение операции при высокой нагрузке повышает вероятность заметных задержек.
4. Если признаки проблем отсутствуют (все LUN online, никаких потерянных путей, FC-порты без ошибок) — можно отложить вмешательство, но продолжать мониторинг и собрать данные для анализа (логи, время появления события, корреляция с изменениями в сети).
Рекомендации по действию
- Если есть возможность — выполнить FIX в запланированное окно обслуживания/время низкой нагрузки.
- Перед выполнением — обеспечить, что на хостах включён корректный multipath/failover; подготовить контакты техподдержки и план отката на случай неожиданных проблем.
- Если вы хотите сначала минимизировать риск — выполнить тестовый FIX на одном контроллере/одном хосте или для одного LUN (если есть такая гранулярность) — посмотреть поведение.
- Если у вас нет уверенности в интерпретации логов или причина неясна — открыть обращение в IBM/поддержку поставщика и согласовать шаги с ними.
Когда можно просто удалить Alert
- Только если вы понимаете, что это старое/стихийное событие, и собрали доказательства отсутствия проблемы (логи, длительная стабильность). Даже в этом случае лучше не удалять, а архивировать/закрыть предупреждение с пометкой о расследовании и планом действий. Полное игнорирование/удаление предупреждений без расследования — плохая практика.
Итог
FIX сама по себе не должна привести к потере данных, но может вызвать кратковременные I/O перерывы или повышение задержек. Рекомендую: не удалять Alert «вслепую», выполнить предварительную диагностику, и при необходимости запускать FIX в окно обслуживания (или согласовать с IBM Support). Если хотите — пришлите детали события (время, полные тексты логов/какие порты/host WWN затронуты) — подскажу более конкретно.