Ужасающе долго перестраивается raid5

Поломалось, посыпалось, не работает...

Модераторы: Trinity admin`s, Free-lance moderator`s

Ответить
mcorvax
Junior member
Сообщения: 4
Зарегистрирован: 15 июн 2006, 08:45

Ужасающе долго перестраивается raid5

Сообщение mcorvax » 15 июн 2006, 09:30

Здравствуйте! Есть такая вот конфигурация:
-платформа 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
Откуда: Москва
Контактная информация:

Сообщение exLH » 15 июн 2006, 09:43

Вообще, в ASM можно выставить приоритет ребилда, что позволит радикально сократить это время.

mcorvax
Junior member
Сообщения: 4
Зарегистрирован: 15 июн 2006, 08:45

Сообщение mcorvax » 15 июн 2006, 10:00

Совсем забыл: с самого начала установлен приоритет High -- наивысший из 3х возможных...

Аватара пользователя
exLH
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 5061
Зарегистрирован: 11 фев 2004, 15:49
Откуда: Москва
Контактная информация:

Сообщение exLH » 15 июн 2006, 10:07

Проверьте, чтобы прошивка наконтроллере была последней версии (7370), разумеется, после того, как все ребилд будет закончен.
Как вариант, попробуйте понизить приоритет ребилда, подождать минут 20 и вернуть обратно на максимум. Также проверьте, что ASM установлен послдней версии (тоже после ребилда).

mcorvax
Junior member
Сообщения: 4
Зарегистрирован: 15 июн 2006, 08:45

Сообщение mcorvax » 15 июн 2006, 10:43

Спасибо, попробую поменять приоритет.
ASM последней версии, а вот с прошивкой ситуация довольно странная: ASM демонстрирует наличие Bios 7673 и Firmware 7673, т.е. по идее стоит версия более новая, нежели имеющаяся на сайте адаптека 7370.

Но в принципе возможна такая низкая производительность по причине "нуль-канальности" адаптера или рэйда на больших sata-дисках?

Аватара пользователя
exLH
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 5061
Зарегистрирован: 11 фев 2004, 15:49
Откуда: Москва
Контактная информация:

Сообщение exLH » 15 июн 2006, 10:57

Посмотрите дату прошивки (я кажется видел такое - реально прошивка более старая).
Кроме того, вот отсюда можно скачать еще более новую версию:
ftp://ftp.supermicro.com/CDR-ASR-SA_1.0 ... lease_7384

mcorvax
Junior member
Сообщения: 4
Зарегистрирован: 15 июн 2006, 08:45

Сообщение mcorvax » 21 июн 2006, 11:01

Сообщаю об итогах, может кому-то пригодится.
Итак, полное перестроение массива на 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 недели, можно ответить НЕТ, это не нормально (хотя, конечно, многое зависит и от нагрузки).

Ну и коненчо, спасибо за советы сотрудникам Тринити! :-)

Ответить

Вернуться в «Массивы - Технические вопросы, решение проблем.»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 11 гостей