Зависает сервер при сбоях scsi-подсистемы
Модераторы: Trinity admin`s, Free-lance moderator`s
Зависает сервер при сбоях scsi-подсистемы
Кофигурация:
корпус Intel SR2300 + mb Intel Westville SE7501WV2SCSI
2 XEON 2.8, 2GB памяти
RAID 10 на LSI Logic MegaRAID SCSI 320-1 с BBU + 4 HDD Seagate ST336607LC
Windows 2000 server.
Завис без видимых причин.
Внешне это выглядит так: сегодня утром сервер стоит намертво, на экране чернота, на клавиатуру/мышку не реагирует. Контроллер пищит, на трех дисках из четырех горит оранжевый сигнал, четвертый - не горит вообще. После выключения/включения один из дисков сигналит желтым, контроллер продолжает пищать, естественно при старте пишет, что массив деградировал. В BIOS контроллера VIEW CONFIGURATION показывает этот же диск как failed. После передергивания диска автоматом запустился rebuild, который успешно прошел. Система загрузилась без проблем - ни одной ошибки. Контроллер запустил фоновую иницилизацию.
В логах Виндов - ничего, кроме сообщения о неожиданном завершении работы, в ISM тоже пусто. Единственный след - в NVRAM логах контроллера:
SeqNo=8 ctl=0 chn=0 tgt=3 lun=0 Event= 24:MLXEV_PHYSDEV_REMOVED_DEAD
logged at Nov 28 04:50:53 2004
SeqNo=9 ctl=0 chn=0 tgt=3 lun=0 Event= 24:MLXEV_PHYSDEV_REMOVED_DEAD
logged at Nov 28 04:50:54 2004
SeqNo=10 ctl=0 chn=0 tgt=5 lun=0 Event= 24:MLXEV_PHYSDEV_REMOVED_DEAD
logged at Nov 28 04:50:55 2004
SeqNo=11 ctl=0 chn=0 tgt=0 lun=0 Event= 24:MLXEV_PHYSDEV_REMOVED_DEAD
logged at Nov 28 04:51:05 2004
SeqNo=12 ctl=0 chn=0 tgt=0 lun=0 Event= 24:MLXEV_PHYSDEV_REMOVED_DEAD
logged at Nov 28 04:51:05 2004
SeqNo=13 ctl=0 chn=0 tgt=0 lun=0 Event= 3C:MLXEV_PHYSDEV_OFFLINE_DEVICE_MADE_ONLINE
logged at Nov 28 08:37:21 2004
SeqNo=14 ctl=0 chn=0 tgt=5 lun=0 Event= 3C:MLXEV_PHYSDEV_OFFLINE_DEVICE_MADE_ONLINE
logged at Nov 28 08:37:21 2004
SeqNo=15 ctl=0 chn=0 tgt=0 lun=0 Event= 3C:MLXEV_PHYSDEV_OFFLINE_DEVICE_MADE_ONLINE
logged at Nov 28 08:38:25 2004
SeqNo=16 ctl=0 chn=0 tgt=5 lun=0 Event= 3C:MLXEV_PHYSDEV_OFFLINE_DEVICE_MADE_ONLINE
logged at Nov 28 08:38:25 2004
SeqNo=17 ctl=0 chn=0 tgt=0 lun=0 Event= 3C:MLXEV_PHYSDEV_OFFLINE_DEVICE_MADE_ONLINE
logged at Nov 28 08:39:23 2004
SeqNo=18 ctl=0 chn=0 tgt=5 lun=0 Event= 3C:MLXEV_PHYSDEV_OFFLINE_DEVICE_MADE_ONLINE
logged at Nov 28 08:39:23 2004
Если ко времени в логе добавить примерно сутки, то тогда оно совпадет со временем когда сервер встал и был запущен.
Похожая ситуация была с месяц назад, тогда тоже, сначала сбойнул диск, а потом сервер встал. Тогда было подозрение на температуру, в серверной было прохладно; в этот раз с температурой было все в порядке - мониторинг сервера молчит.
Один раз - случайность, два - уже похоже на систему. Если при каждом сбое сервер будет вставать насмерть, "защищая" тем самым данные, то на :?: мне такая защита .
А теперь вопрос к спецам: что под подозрением в первую очередь?
Первая мысль была, что это scsi-backplain шалит, раз ошибки гуляют, но разве ей по силам завесить систему?
Где и как искать, посоветуйте пожалуйста!
корпус Intel SR2300 + mb Intel Westville SE7501WV2SCSI
2 XEON 2.8, 2GB памяти
RAID 10 на LSI Logic MegaRAID SCSI 320-1 с BBU + 4 HDD Seagate ST336607LC
Windows 2000 server.
Завис без видимых причин.
Внешне это выглядит так: сегодня утром сервер стоит намертво, на экране чернота, на клавиатуру/мышку не реагирует. Контроллер пищит, на трех дисках из четырех горит оранжевый сигнал, четвертый - не горит вообще. После выключения/включения один из дисков сигналит желтым, контроллер продолжает пищать, естественно при старте пишет, что массив деградировал. В BIOS контроллера VIEW CONFIGURATION показывает этот же диск как failed. После передергивания диска автоматом запустился rebuild, который успешно прошел. Система загрузилась без проблем - ни одной ошибки. Контроллер запустил фоновую иницилизацию.
В логах Виндов - ничего, кроме сообщения о неожиданном завершении работы, в ISM тоже пусто. Единственный след - в NVRAM логах контроллера:
SeqNo=8 ctl=0 chn=0 tgt=3 lun=0 Event= 24:MLXEV_PHYSDEV_REMOVED_DEAD
logged at Nov 28 04:50:53 2004
SeqNo=9 ctl=0 chn=0 tgt=3 lun=0 Event= 24:MLXEV_PHYSDEV_REMOVED_DEAD
logged at Nov 28 04:50:54 2004
SeqNo=10 ctl=0 chn=0 tgt=5 lun=0 Event= 24:MLXEV_PHYSDEV_REMOVED_DEAD
logged at Nov 28 04:50:55 2004
SeqNo=11 ctl=0 chn=0 tgt=0 lun=0 Event= 24:MLXEV_PHYSDEV_REMOVED_DEAD
logged at Nov 28 04:51:05 2004
SeqNo=12 ctl=0 chn=0 tgt=0 lun=0 Event= 24:MLXEV_PHYSDEV_REMOVED_DEAD
logged at Nov 28 04:51:05 2004
SeqNo=13 ctl=0 chn=0 tgt=0 lun=0 Event= 3C:MLXEV_PHYSDEV_OFFLINE_DEVICE_MADE_ONLINE
logged at Nov 28 08:37:21 2004
SeqNo=14 ctl=0 chn=0 tgt=5 lun=0 Event= 3C:MLXEV_PHYSDEV_OFFLINE_DEVICE_MADE_ONLINE
logged at Nov 28 08:37:21 2004
SeqNo=15 ctl=0 chn=0 tgt=0 lun=0 Event= 3C:MLXEV_PHYSDEV_OFFLINE_DEVICE_MADE_ONLINE
logged at Nov 28 08:38:25 2004
SeqNo=16 ctl=0 chn=0 tgt=5 lun=0 Event= 3C:MLXEV_PHYSDEV_OFFLINE_DEVICE_MADE_ONLINE
logged at Nov 28 08:38:25 2004
SeqNo=17 ctl=0 chn=0 tgt=0 lun=0 Event= 3C:MLXEV_PHYSDEV_OFFLINE_DEVICE_MADE_ONLINE
logged at Nov 28 08:39:23 2004
SeqNo=18 ctl=0 chn=0 tgt=5 lun=0 Event= 3C:MLXEV_PHYSDEV_OFFLINE_DEVICE_MADE_ONLINE
logged at Nov 28 08:39:23 2004
Если ко времени в логе добавить примерно сутки, то тогда оно совпадет со временем когда сервер встал и был запущен.
Похожая ситуация была с месяц назад, тогда тоже, сначала сбойнул диск, а потом сервер встал. Тогда было подозрение на температуру, в серверной было прохладно; в этот раз с температурой было все в порядке - мониторинг сервера молчит.
Один раз - случайность, два - уже похоже на систему. Если при каждом сбое сервер будет вставать насмерть, "защищая" тем самым данные, то на :?: мне такая защита .
А теперь вопрос к спецам: что под подозрением в первую очередь?
Первая мысль была, что это scsi-backplain шалит, раз ошибки гуляют, но разве ей по силам завесить систему?
Где и как искать, посоветуйте пожалуйста!
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Контроллер встает в позу не защищая информацию, а просто потому, что более одного винта вылетело из массива. И это правильно.
В чем причина - очень большой вопрос. Вы бы хоть GAM поставили - были бы логи дисковой системы.
Возможно кабельная система кривовата, возможно у диска(ов) электроника на грани (сдохший шинный буфер диска в состоянии полностью подвесить шину - тогда контроллер честно скажет, что все умерло).
Перевешивайте дисковый кабель с контроллера на простую сказю и гоните утилиту Ситулз.
В чем причина - очень большой вопрос. Вы бы хоть GAM поставили - были бы логи дисковой системы.
Возможно кабельная система кривовата, возможно у диска(ов) электроника на грани (сдохший шинный буфер диска в состоянии полностью подвесить шину - тогда контроллер честно скажет, что все умерло).
Перевешивайте дисковый кабель с контроллера на простую сказю и гоните утилиту Ситулз.
exLH
controller - MegaRAID SCSI320-1, Firmware 1L26, BIOS G112
backplane - SCA HSBP M16 Revision 0.005
HDD - ST336607LC Revision 007 BIOS ???
Сервер в работе, а как посмотреть версию BIOS диска, не выводя его в оффлайн, что не могу сообразить . Впрочем... могу попробовать чуть позже посмотреть на ранее снятом диске, он из того же комплекта.
a_shats
А диски-то были разные... и разных местах. Тот что первый раз сбойнул, я заменил. Поленился проверять, просто переформатировал, и поставил на другой сервер - работает. Да и не похоже это на диски, по моему... разве что все дохлые? Что может сделать диск, ну завесит всю шину, ну по таймауту отвалятся остальные - сдохнет массив, а контроллер должен работать.
gs
GAM - стоит, это через него были получены логи в первом сообщении.
Переключить на простой SCSI диски нельзя - сервер в работе, то есть конечно можно, но только как последняя мера.
controller - MegaRAID SCSI320-1, Firmware 1L26, BIOS G112
backplane - SCA HSBP M16 Revision 0.005
HDD - ST336607LC Revision 007 BIOS ???
Сервер в работе, а как посмотреть версию BIOS диска, не выводя его в оффлайн, что не могу сообразить . Впрочем... могу попробовать чуть позже посмотреть на ранее снятом диске, он из того же комплекта.
a_shats
А диски-то были разные... и разных местах. Тот что первый раз сбойнул, я заменил. Поленился проверять, просто переформатировал, и поставил на другой сервер - работает. Да и не похоже это на диски, по моему... разве что все дохлые? Что может сделать диск, ну завесит всю шину, ну по таймауту отвалятся остальные - сдохнет массив, а контроллер должен работать.
gs
Позвольте с вами категорически не согласиться. Контроллер таки ни при каких условиях не должен "вставать в позу", его дело обработать ошибки, выдать их в систему и _в крайнем случае_ заблокировать работу с массивом, imho. А про защиту системы - это был, однако, совсем черный юморКонтроллер встает в позу не защищая информацию, а просто потому, что более одного винта вылетело из массива. И это правильно.
GAM - стоит, это через него были получены логи в первом сообщении.
Переключить на простой SCSI диски нельзя - сервер в работе, то есть конечно можно, но только как последняя мера.
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Со мной можно не соглашаться, а вот с контроллером - придется
Рэйд системы не защищены от приколов со стороны дискового интерфейса. Все рэйд контроллеры априори считают дисковый интерфейс работоспособным. И если что не так - могут просто отбрыкнуться.
Можете не верить, но мы тут недавно чинили сервер, в котором дисковую систему дико плющило по причине малость подбитого внешнего кабеля.
Рэйд системы не защищены от приколов со стороны дискового интерфейса. Все рэйд контроллеры априори считают дисковый интерфейс работоспособным. И если что не так - могут просто отбрыкнуться.
Можете не верить, но мы тут недавно чинили сервер, в котором дисковую систему дико плющило по причине малость подбитого внешнего кабеля.
В это - запросто. А вот, что дохлая scsi-подсистема может (= имет возможность) вешать сервер - это вещь недопустимая! BSOD, перезагрузка, что угодно, но машина аппаратно вставать не должна....в котором дисковую систему дико плющило по причине малость подбитого внешнего кабеля.
И ваша реплика будит во мне ужасные подозрения - неужели такое поведение часто бывает у MegaRAID'ов?
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Это может быть у любых контроллеров. По крайней мере я за свою долгую практику много таких приколов видел. Рэйд контроллер рассчитан на обеспечение работоспособности системы при выходе из строя диска. Но дребезг на шине может его запросто в ступор ввести.
У мегарэйдов это лечится клиар конфигом, а у майлексов иногда вообще приходилось батарейку NVRAM сдергивать.
Бывало даже внешние файберные системы впадали в маразм. Но их конечно намного сложнее вышибить - но по крайней мере однажды проблемы с питанием (молния) свихнули весьма серьезный аппарат - пришлось с бубном целый день плясать, слава Богу успешно.
У мегарэйдов это лечится клиар конфигом, а у майлексов иногда вообще приходилось батарейку NVRAM сдергивать.
Бывало даже внешние файберные системы впадали в маразм. Но их конечно намного сложнее вышибить - но по крайней мере однажды проблемы с питанием (молния) свихнули весьма серьезный аппарат - пришлось с бубном целый день плясать, слава Богу успешно.
Вот, нашел, это - оно?
MegaRAID подпадает под это описание?
Ultra 320 Time-Out Firmware Upgrade
Some Seagate Cheetah 10K.6 hard drives with OEM firmware up to 0006 and Cheetah 15K.3 hard drives with OEM firmware up to 0005 on Ultra 320 SCSI host adapters are experiencing time out issues when running RAID 0, 1 and 5 with some host adapters. This issue has been observed using U320 Adaptec and LSI SCSI controllers, but may not limited to these host adapter manufacturers.
gs
Как по вашей практике, при множественных отказах дисков, MegaRAID'ы действительно могут ввести сервер в полный ступор? (или это я такой везучий?) Это как-нибудь лечится (я про контроллер )?
MegaRAID подпадает под это описание?
Ultra 320 Time-Out Firmware Upgrade
Some Seagate Cheetah 10K.6 hard drives with OEM firmware up to 0006 and Cheetah 15K.3 hard drives with OEM firmware up to 0005 on Ultra 320 SCSI host adapters are experiencing time out issues when running RAID 0, 1 and 5 with some host adapters. This issue has been observed using U320 Adaptec and LSI SCSI controllers, but may not limited to these host adapter manufacturers.
gs
Как по вашей практике, при множественных отказах дисков, MegaRAID'ы действительно могут ввести сервер в полный ступор? (или это я такой везучий?) Это как-нибудь лечится (я про контроллер )?
- exLH
- Сотрудник Тринити
- Сообщения: 5061
- Зарегистрирован: 11 фев 2004, 15:49
- Откуда: Москва
- Контактная информация:
Диски у Вас, похоже, как раз с правильной прошивкой (Rev 0007 это именно она). А вот прошивку бэкплейна надо обновлять, ибо (выдержка с Intelа):
- In some rare cases, drives would spontaneously go offline and not come back online. HSC 0.06 extends the power on delay from 50 milliseconds to 1 second to avoid this. Note that this change requires a boot block update.
Качать отсюда.
- In some rare cases, drives would spontaneously go offline and not come back online. HSC 0.06 extends the power on delay from 50 milliseconds to 1 second to avoid this. Note that this change requires a boot block update.
Качать отсюда.
- exLH
- Сотрудник Тринити
- Сообщения: 5061
- Зарегистрирован: 11 фев 2004, 15:49
- Откуда: Москва
- Контактная информация:
А сигейт так просто прошивки не раздает - надо написать письмо, указав проблему, текущую прошивку, серийный номер и номер партии. После этого, если Ваша прошивка имеет обновление, Вам дадут ссылку (короткоживущую) на новую прошивку.
Впрочем, как я уже выше писал, у Вас скорее всего дело не в прошивке дисков.
Впрочем, как я уже выше писал, у Вас скорее всего дело не в прошивке дисков.
Прошу прощения, позновато проснулся:)
Имеется аналогичный LSI 320-1 (без батарейки) Firmware 1L26, BIOS G112, 4 SCSI Seagate ST336607LW , сделан 3хRAID5 + 1xHotSpare , "сервер" собран на ASUS P4P800 DG, БП 420Ватт Чифтек. Та же самая проблемма - периодически отваливаются диски #0 и #1, приводя сервак в состояние "черного экрана",помогает только резет. Не часто так, раз в 4-6 месяцев. Сами винты #0 или #1 отваливаются немного чаще, без общего зависания.
Общался по этому поводу с gs и S.Kourdikov , причин так и не нашли, сошлись на подозрении на плохой SCSI кабель, а на тестирование сервак дать не мог... Была у меня еще одна смешная версия с подозрением на сквозняк.. ) похоже дело было в этом - сервак стоял под окном и случаи "зависания"/отваливания винтов иногда совпадали с проветриванием помещения (зимой). Сервак быстро остывал, моток SCSI шлейфа чуток коробился, разъемы чуток выгибались и т.д..После переезда в нормальное помещение сервак проработал как часы 6 месяцев, и опять подвис с тем же результатом Теперь уже подозрение на питание -очень здорово скачет и проваливается напряжение, но сервак же подключен через УПС.. Т.е. опять непонятки..
Имеется аналогичный LSI 320-1 (без батарейки) Firmware 1L26, BIOS G112, 4 SCSI Seagate ST336607LW , сделан 3хRAID5 + 1xHotSpare , "сервер" собран на ASUS P4P800 DG, БП 420Ватт Чифтек. Та же самая проблемма - периодически отваливаются диски #0 и #1, приводя сервак в состояние "черного экрана",помогает только резет. Не часто так, раз в 4-6 месяцев. Сами винты #0 или #1 отваливаются немного чаще, без общего зависания.
Общался по этому поводу с gs и S.Kourdikov , причин так и не нашли, сошлись на подозрении на плохой SCSI кабель, а на тестирование сервак дать не мог... Была у меня еще одна смешная версия с подозрением на сквозняк.. ) похоже дело было в этом - сервак стоял под окном и случаи "зависания"/отваливания винтов иногда совпадали с проветриванием помещения (зимой). Сервак быстро остывал, моток SCSI шлейфа чуток коробился, разъемы чуток выгибались и т.д..После переезда в нормальное помещение сервак проработал как часы 6 месяцев, и опять подвис с тем же результатом Теперь уже подозрение на питание -очень здорово скачет и проваливается напряжение, но сервак же подключен через УПС.. Т.е. опять непонятки..
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 27 гостей