Pull to refresh

Comments 19

Мой опыт общения с LSI'ями (как и прочими околоинтеловскими MegaRAID'ами) показывает только одно — чем от них дальше находится сервер, тем спокойнее спать админу.
Я сталкивался только с одним случаем потери данных по вине контроллера LSI, и то его можно было избежать, вовремя обновив прошивку на сервере. Хотя этому серверу уже 7 лет, а за 7 лет, я думаю, инженеры LSI учли ошибки. Так что я считаю их контроллеры вполне надёжным, хоть и не лучшим вариантом. Да и бакапы никто не отменял
Я не сталкивался с потерей данных, зато я сталкивался с вышей степенью идиотизма логики контроллеров. Например, репликация на отсутствующие хотспары (не проверяется наличие перед началом репликации), недокументированные и различающиеся строки состояния рейда в megacmd и т.д. Другими словами, спасибо, но не надо.
Оу, сочувствую. К счастью с такой глупой логикой я еще не сталкивался. Я чаще работал с ОЕМ версиями этого контроллера, вроде Dell Perc5/i, и они показали себя более понятными и быстрыми, по сравнению с оригиналом от LSI
А что еще использовать? Кроме LSI/3Ware нормальной поддержки FreeBSD/Linux нет ни у кого.
У адаптека прекрасные дрова под линукс, между прочим. И софтинка мониторинга, за исключением того, что на яве, тоже замечательная. И она даже без шелловых костылей способна написать о том, что бо-бо диску стало.
А как обстоят дела с FreeBSD?

Софтинки мониторинга на яве меня совсем не интересуют, т.к. ставить яву ради мониторинга — идиотизм(на серверах не php + MySQL, в основном C/C++ с собственной СУБД).

Без костылей, это по SNMP?
И snmp тоже, мне хватает просто письма на почту.

Что там с BSD — не имею ни малейшего представления. Это же головная проблема Juniper/apple, не правда ли? Ах, там же не GPL… Ну пусть мучаются сами.
> И snmp тоже, мне хватает просто письма на почту.

отправка писем — 4 строчки, которые копируются вместе с образом. Не такая уж и большая проблема, т.к. парк серверов однородный.

> Что там с BSD — не имею ни малейшего представления. Это же головная проблема Juniper/apple, не правда ли? Ах, там же не GPL… Ну пусть мучаются сами.

Нет, это проблема производителя, т.к. LSI поддерживается FreeBSD(не все чипсеты, но все же) и теперь уже LSI/3Ware.
Я буквально чуть выше написал, что я LSI-и не люблю, потому что «скрипт из 4х строчек» переодически обламывается на очередном статусе рейда, который приходится выковыивать из омерзительного аутпута megacmd.
> Встроенная логика для дисков IM/IS отключает кеш по-умолчанию
Спасибо, LSI за уточнение, но это всё же не решение моей задачи. Далее были поиски утилит, которые позволили бы мне изменить эту досадную ситуацию и включить кеш.

Извините, автор, а у вас хотя бы на секунду не возникла мысль, что LSI отключила кэш на дисках не из-за мифических «глюков прошивки», и не для того, чтобы вас позлить, а намеренно, с какой-то целью, что у этого отключеня была важная причина, которой вы не понимаете?
Так может стоит сначала понять эту причину, чем идти дербанить «регистры памяти контроллера»?

Ох, кулибины, вечные посташики работы конторам «восстановление информации с дисков»…
Не считайте меня наивным ребёнком, конечно я понимаю зачем он отключен. Это сделано для того, чтобы обеспечить целостность данных в NVRAM контроллера.

Случаи, когда данные в нём могут оказаться не полными это: внезапное отключение электричества на сервере и выход из строя единственного блока питания.
Просто в моём случае это маловероятно, так как сервер подключен к ИБП, и не критично, из-за приложений которые на нём работают. Целью было именно повышение производительности, учитывая риски.
Спасибо за комментарий, сейчас добавлю в статью почему же он действительно отключен по-умолчанию
> Просто в моём случае это маловероятно

Ну-ну. «Маловероятно». Вы телефончик-то конторы по «восстановлнию информации с дисков» запишите заранее. Пригодится.

Тот, кто давал вам деньги на сервер для хранения там своей информации в курсе, что потерять содержимое дисков сервера после вашего кудесничества теперь «маловероятно»?
Сервер, как и данные на нём мои. Не будьте настолько критичным. И к тому же всегда есть ежедневные бакапы. Я отношусь с типу администраторов, которые УЖЕ делают бакапы :)
И да, я понимаю, что данные зачастую многократно дороже, чем оборудование. Но не в данном случае. Будь это какой-нибудь сервер с SLA, то я бы полностью следовал всем рекомендациям вендора оборудования и ПО для обеспечения надёжности и сохранности данных. Но повторюсь, что это сервер для личных нужд, с организованным и проверенным резервным копированием и восстановлением данных, где стоимость данных многократно меньше, чем стоимость сервера
Вообще же получилась очень хорошая иллюстрация того, о чем я не устаю говорить, что хороший софтверный RAID обычно куда лучше, чем плохой хардверный.
С этим утверждением я абсолютно согласен. Но так как мне необходимо было иметь в RAID диск hot-spare + hot-swap, а бесплатных и надёжных решений под MS Windows, которые позволили бы мне это получить я не знаю, то и получилась эта статья
А я всегда специально отключаю этот кэш. И никогда такой низкой скорости не бывает.
Возможно мне просто не повезло :) Но у меня два абсолютно разных сервера с такой проблемой, причём даже версии firmware на контроллерах разные и скорость записи данных 40%write/60%read, 100% random, 4k блоки на площадь в 400Гб заставляет плакать, пока не включен кэш на дисках
Sign up to leave a comment.

Articles