Диагностирование проблем возможности соединения SAN (RHEL5)
Я сказал бы, что самые большие недостатки ПК являются надежностью, устойчивостью аппаратной платформы и доступностью аппаратных средств. ПК имеют тенденцию использовать более дешевые аппаратные средства и не дублирование реализации компонентов. ПК также имеют тенденцию иметь намного более широкий диапазон аппаратных компонентов, чем серверы, таким образом, встроенное микропрограммное обеспечение и обновления драйвера могут колебаться больше, чем с твердой аппаратной платформой сервера. ПК также имеют тенденцию не иметь дублирования, такие как вентиляторы, источники питания, аппаратные средства RAID, и т.д.
Но в конце, все это сводится к тому, что Вы работаете на поле. Я видел запущение легкого приложения сервера на ПК, если это - весь Ваш buget, предоставил Вам. Хотя виртуализация все еще была бы более оптимальным вариантом.
В Linux нет специальных журналов - обычно используйте dmesg / syslog.
Для коммутаторов SAN способ доступа к журналам зависит от производителя (в Brocade -> ssh admin @ x -> errdump).
Для дискового хранилища SAN способ доступа к журналам зависит от поставщика (в LSI -> GUI -> Журнал событий -> выключить show_critical_only -> обновить).
Прежде всего, убедитесь, что у вас есть ntp (или другая синхронизация времени) как для коммутаторов SAN, так и для хранилища SAN, иначе вы никогда не узнаете, какая ошибка является причиной, а какая следствием.
Проверьте наиболее вероятную причину, проверьте, как ваш multipath / GFS2 реагирует на случайный FC отсоединение кабеля.
Проверьте вторую вероятную причину, проверьте, как ваш multipath / GFS2 реагирует на случайное отключение контроллера дискового массива SAN.