Ужасающе долго перестраивается raid5
Модераторы: Trinity admin`s, Free-lance moderator`s
Ужасающе долго перестраивается raid5
Здравствуйте! Есть такая вот конфигурация:
-платформа Supermicro
-Adapteck 2020SA (zero-channel)
-RAID5 на 5 SATA дисках Seagate ST330083, Model 1AS, Firmware 3.03 общим объемом 1TB.
На прошлой еще неделе, в среду "вылетел" один из дисков, после чего автоматически контроллер начала делать rebuild на hot-spare диск. Процесс продолжается до сих пор. Т.е. прошло уже больше недели, а выполнено всего 86%. Во внерабочее время, успевает восстановиться всего 6-7%, в рабочее же время (с 9 до 18\19 часов) -- 1-2%.
Основная функция сервера -- контроллер AD+ файл-сервер. Нагрузка, я бы не сказал что очень большая: в пике активности пользователями открыто 110 сессий, 90% из них -- чтение документов.
Вопрос: является ли столь долгое время "ребилда" нормальным явлением или тут что-то не так? Спасибо.
-платформа Supermicro
-Adapteck 2020SA (zero-channel)
-RAID5 на 5 SATA дисках Seagate ST330083, Model 1AS, Firmware 3.03 общим объемом 1TB.
На прошлой еще неделе, в среду "вылетел" один из дисков, после чего автоматически контроллер начала делать rebuild на hot-spare диск. Процесс продолжается до сих пор. Т.е. прошло уже больше недели, а выполнено всего 86%. Во внерабочее время, успевает восстановиться всего 6-7%, в рабочее же время (с 9 до 18\19 часов) -- 1-2%.
Основная функция сервера -- контроллер AD+ файл-сервер. Нагрузка, я бы не сказал что очень большая: в пике активности пользователями открыто 110 сессий, 90% из них -- чтение документов.
Вопрос: является ли столь долгое время "ребилда" нормальным явлением или тут что-то не так? Спасибо.
- exLH
- Сотрудник Тринити
- Сообщения: 5061
- Зарегистрирован: 11 фев 2004, 15:49
- Откуда: Москва
- Контактная информация:
Проверьте, чтобы прошивка наконтроллере была последней версии (7370), разумеется, после того, как все ребилд будет закончен.
Как вариант, попробуйте понизить приоритет ребилда, подождать минут 20 и вернуть обратно на максимум. Также проверьте, что ASM установлен послдней версии (тоже после ребилда).
Как вариант, попробуйте понизить приоритет ребилда, подождать минут 20 и вернуть обратно на максимум. Также проверьте, что ASM установлен послдней версии (тоже после ребилда).
Спасибо, попробую поменять приоритет.
ASM последней версии, а вот с прошивкой ситуация довольно странная: ASM демонстрирует наличие Bios 7673 и Firmware 7673, т.е. по идее стоит версия более новая, нежели имеющаяся на сайте адаптека 7370.
Но в принципе возможна такая низкая производительность по причине "нуль-канальности" адаптера или рэйда на больших sata-дисках?
ASM последней версии, а вот с прошивкой ситуация довольно странная: ASM демонстрирует наличие Bios 7673 и Firmware 7673, т.е. по идее стоит версия более новая, нежели имеющаяся на сайте адаптека 7370.
Но в принципе возможна такая низкая производительность по причине "нуль-канальности" адаптера или рэйда на больших sata-дисках?
- exLH
- Сотрудник Тринити
- Сообщения: 5061
- Зарегистрирован: 11 фев 2004, 15:49
- Откуда: Москва
- Контактная информация:
Посмотрите дату прошивки (я кажется видел такое - реально прошивка более старая).
Кроме того, вот отсюда можно скачать еще более новую версию:
ftp://ftp.supermicro.com/CDR-ASR-SA_1.0 ... lease_7384
Кроме того, вот отсюда можно скачать еще более новую версию:
ftp://ftp.supermicro.com/CDR-ASR-SA_1.0 ... lease_7384
Сообщаю об итогах, может кому-то пригодится.
Итак, полное перестроение массива на 1,09TB заняло с 19:09 6 июня по ~4:00 17 июня = 11 дней.
После того, как ASM отрапортовал, что массив в состоянии OPTIMAL, ситуация с производительностью изменилась, но не сказать, чтобы в лучшую сторону: вместо сильно замедленного доступа к серверу появились частые "замирания" на минуту, а то и все 3-4, когда сервер переставал реагировать на какие-либо обращения к нему.
В Perfomance monitor это выглядело, как постоянные пиковые всплески на графике average disk queuing. На бывшем же hot spare диске, переведенном в состояние Normal (ASM->"delete hot spare"), постоянно горел индикатор активности. Не мерцал, а именно горел.
Смена прошивки, обновление версии ASM (все таки выяснилось, что на данном конкретном сервере программа была очень старой (2й версии), так что был не прав, когда утверждал обратное) ситуации не изменили.
Было принято решение попробовать перестроить массив еще раз, т.к. возникло подозрение в неадекватной работе нового члена массива -- hot spare диска.
На место прежнего сбойного диска установлен новый; бывший hot spare через ASM был принудительно помечен как failed, после чего, всего за одну ночь (начало rebuild'а в 21:53, окончание между 5 и 8 часами утра) массив перешел в состояние optimal. Все проблемы с производительностью исчезли. Ура!
Так что, отвечая на свой вопрос о нормальности перестроения терабайтного массива почти 2 недели, можно ответить НЕТ, это не нормально (хотя, конечно, многое зависит и от нагрузки).
Ну и коненчо, спасибо за советы сотрудникам Тринити!
Итак, полное перестроение массива на 1,09TB заняло с 19:09 6 июня по ~4:00 17 июня = 11 дней.
После того, как ASM отрапортовал, что массив в состоянии OPTIMAL, ситуация с производительностью изменилась, но не сказать, чтобы в лучшую сторону: вместо сильно замедленного доступа к серверу появились частые "замирания" на минуту, а то и все 3-4, когда сервер переставал реагировать на какие-либо обращения к нему.
В Perfomance monitor это выглядело, как постоянные пиковые всплески на графике average disk queuing. На бывшем же hot spare диске, переведенном в состояние Normal (ASM->"delete hot spare"), постоянно горел индикатор активности. Не мерцал, а именно горел.
Смена прошивки, обновление версии ASM (все таки выяснилось, что на данном конкретном сервере программа была очень старой (2й версии), так что был не прав, когда утверждал обратное) ситуации не изменили.
Было принято решение попробовать перестроить массив еще раз, т.к. возникло подозрение в неадекватной работе нового члена массива -- hot spare диска.
На место прежнего сбойного диска установлен новый; бывший hot spare через ASM был принудительно помечен как failed, после чего, всего за одну ночь (начало rebuild'а в 21:53, окончание между 5 и 8 часами утра) массив перешел в состояние optimal. Все проблемы с производительностью исчезли. Ура!
Так что, отвечая на свой вопрос о нормальности перестроения терабайтного массива почти 2 недели, можно ответить НЕТ, это не нормально (хотя, конечно, многое зависит и от нагрузки).
Ну и коненчо, спасибо за советы сотрудникам Тринити!
Кто сейчас на конференции
Сейчас этот форум просматривают: Google [Bot] и 55 гостей