SAS vs. SSD, Сравнительные тесты дисковых подсистем.

Помимо скоростных характеристик рэйды дают еще и отказоустойчивость. Мне тяжело себе представить НАДЕЖНУЮ систему хранения без аппаратного рэйда, в идеале с отказоустойчивостью N+1 по количеству онлайн контроллеров.

Софтрейды еще годятся для количества дисков 2...4, но когда их становится 24+, то какой тут софтрейд?!

Так что в моем понимании, пусть скорость SSD будет в 3 раза ниже номинала, но если при том гарантирована отказоустойчивость - это будет мой выбор.

На данный момент лично мне интересны энтерпрайзные диски на SLC и eMLC памяти.

Аппаратный рэйд это ещё один узел, который снижает надёжность системы. Поинтересуйтесь теорией вероятности, она обязательно для конструкторов всех уровней. Отказоустойчивость системы гарантрует админ, а не железка.

Тут виноват не софтовый рэйд, а тот факт что на материнке типично только 6 сата, из них только 2 на 6 гбпс остальные на 3. Но давайте честно, больше 6 дискоов испольауется в < 0.001% от всех случаев использования серверов. Так что просто игнорируем в статистике такие случаи, это на уровне исключений ;)

Хозяйн барин, каждая иделогия имеет право на жизнь. А которая правильнее рассудит время...

Естественно, задачи должны определять решения, а не наоборот :)

Так что если задача позволяет, можно и 1 SSD диск вообще без рейда воткнуть.

У меня закос под Энтерпрайз, а потому и подход такой. Естественно, не под все задачи это оптимально. Очень дорогим выходит решение и итоговый ценник :(

по цене за гиг ссд уже вплотную приблизились к сас, crucial m500 960gb стоят порядка 550-600 usd, это примерно 60 центов за 1gb. по скорости не чемпионы, но тоже неплохи

Не можно, а так и надо делать в общих ситуациях. SSD диск имеет выше надёжность как деталь чем любой аппаратный контролер. SSD если и втыкать в рэйд, то только в страйп. RAID1 или RAID10 есть смысл использовать только в исключительных случаях, но тогда и подход другой, сами диски подбирать надо для таких исключений. Фактически SSD в зеркале умрут в одно и тоже время... Коротко скажем так - всё что годилось для обычных дисков (грампластинок), то не годится для SSD.

И наконец надо один раз усвоить - RAID не для безопасности данных, а только для снижения вероятности непрогнозируемого доунтайма. Для сохранности данных служит бэкапы. Доунтаймы будут во всех системах, ребут кластера займёт на много больше времени, чем ребут одиночного компютера. А ребут обязателен для всех систем, по крайней мере раз в год для смены ядра. Лучше раз в пол года, общее время доунтайма в таком слуае получается меньше ;)

Пока еще не обнаружил, ведь теста с чистым программным raid еще нет.

sladkydze, raid-контроллер такого уровня без батарейки следует называть "интерфейсной картой sata с эмуляцией одного диска как массива для возможности загрузки ОС".

С точки зрения надежности, все то же самое делает драйвер md в линуксе. Ну, может быть, на некоторых этапах загрузки ОС, поведение будет отличаться. Совсем чуть-чуть надежнее.

По хорошему кластер не должен ребутаться :) А если это и делается, то онлайн.

Перестаньте, если я не использовал бы vmware ранее, может быть и поверил, но так как использовал, то не то что не верю, но знаю что есть апдейты требующие ребута... Это просто неизбежно, а бутится vmware дольше... иногда с проблемами... придёт время и сами убедитесь, бесмысленный спор.

LineHost, куски кластера перезагрузить по частям, не?

Всё зависит от ситуации и от проблемы которую надо решать. Если построенно на vmware, то у них на сайте очень много ситуаций расписанно. В общем все эти HA мифы это ровно тоже самое что и безлимитный хостинг. Ломаются все системы. Изначальное назначение кластера, это решение проблемы когда не хватает ресурсов одного мощного сервера. Но народ применил на обратное - создают мощный кластер и его потом делит на куски. По моему это не логично, но у каждого есть свои расчёты. К примеру, OVH уже допетрились, что слишком много проблем держать мелкие сайты на кластере, заниматся для них лоуд балансингом и так далее. В общем тут много расхождений, у каждого свой подход и каждый подход имеет свои плюсы, свои минусы. Лично мне кажется не логичным объединять сервера, каждый из которых и так спокойно несёт на себе около 30 средних впсок в кластер, на который можно посадить количество впсок умноженное на число членов в кластере. Это может быть оправданно желанием оверселить каких то параметров (за счёт умощнения ресурса и усреднения нагрузки) и облегчить свою повседневную жизнь, но учитывая возможные и неизбежные проблемы в эксплуатации такого кластера лично мне такое применение не нравится.