Актуален ли железный рейд для пары SSD в raid1?

Автору вообще для его целей голые SSD противопоказаны. SOFT или HARD без разницы.

А SSD кэш имеет место быть в инфраструктурных системах виртуализации.

У ТС-а 2 SDD и RAID1. Коллеги, не забываем, что тут обсуждение конкретного случая идет. Мы не HiLoad-систему собираем, а вполне обычную.

Использовать RAID-1 стоит однозначно. Вопрос только в том, программный или аппаратный.

Но для того, что бы сравнивать надо хотя бы понять, какую ОС использует ТС?

В венде софтварный RAID - ужасен, во FreeBSD/Linux - немного лучше.

Но при любом раскладе если данные критичны и перезагрузка по питанию/сбою ядра возможна, а потеря даже 10-20 строк в таблицах - чревата проблемами с деньгами - ВАМ ОДНОЗНАЧНО НУЖЕН АППАРАТНЫЙ РЕЙД С БАТАРЕЙКОЙ.

Ибо что софтварный рейд, что аппаратный без батарейки, при перезагрузке могут потерять несколько сот мегабайт данных, которые будут потеряны безвозвратно.

Алсо, в данном случае от аппаратного рейда будет польза в первую очередь из-за кэша с батарейкой.

---------- Добавлено 09.09.2014 в 16:45 ----------

Кэш на дисках или кэш контроллера? Дисковый кэш отключает сам по себе почти любой серьезный RAID контроллер.

Pavel.Odintsov, Ну хоть 1 человек меня поддержал :)

Рейды с батарейкой отличная вещь спасшая не 1 тысячу моих нервных клеток, когда в Лизвебе мигал свет (увы и такое бывает).

kxk 😎

Жалко, кстати, что нет какой-нить быстрой-быстрой энергонезависимой памяти (типа кристаллов ZMC у Adaptec), чтобы прицепить ее для кэша софт рейда. Хотя, боюсь, в Linux с его страничным кэшем такое фиг интегрируешь.

Так никто не говорит, что аппаратный рейд - это плохо :) Но автор как бы намекнул, что не мешало бы скроить, если есть такая возможность. А в данном случае она есть.

По данным в кэше SSD дисков, так сейчас есть диски, сохраняющие этот кэш внутри себя при потере питания.

Это смотря что считать точкой отказа - если умрет сервер, то перенести плату рейда и диски на новый сервер куда быстрее, чем воскрешать софтовый рейд в новом сервере со старыми дисками.

Это slc диски, в них то ли кондсаторы стоят, то ли литиевые батарейки

Проблема не столько в кэше самих дисков, его можно отключить при желании, а в поведении страничного кэша почти любой современной ОС, когда данные пушатся блоками (когда наберется 10-20-50 записей или пройдет какое-то время), а не по мере реальной записи.

То есть, пишет тут MySQL что-то на диск раз запсисал - данные еще в памяти, два записал - снова в памяти, три записал - пошел пуш на диск. И ели до реального пуша данных еще не дошло и кончилось электричество - с данными можно прощаться. Ну и файловая система может разлететься, журнал ФС пишется зачастую даже чаще чем реальные данные.

Жалко открытого софта такого нет, который бы зеркалил кеш на двух нодах))