RAID не панацея или как повысить безопасность?

Question

[zzapp]

Доброго времени, хабравчане.

История не из приятных, поэтому прощу помощи. Был линуксовый сервак на 5-ом рейде из 4-х винтов. В один прекрасный день отчалило два диска из рейда, рейд поднять не удалось. На сервере хранились большие объемы данных, ~5 TB.

Вопрос в следующем: Что можно предпринять в плане безопасности и отказоустойчивости, кроме бекапов, чтобы подобное больше не повторилось?


Upd: Вобщем, как и думал, лучшее решение в данной ситуации — бекапы. Всем спасибо.

Answer 1

[lesha_penguin]

1) SMART-мониторинг. Если бы вы хоть иногда смотрели, что вам говорит smart вы бы предприняли меры задолго до столь внезапной кончины.
2) Не использовать 5 рейд. Плохое решение во всех отношениях, скупой платит дважды.
3) Бекапы (Капитан Очевидность, извините, не удержался)
4) Когда выбираете диски для сервака, смотрите такую характеристику, как наработка на отказ. Учтите, что те говновинты, что заполонили все прилавки никак не расчитаны на жесткую эксплуатацию 24x7.
5) У винтов должно быть хорошее охлаждение, они не любят перегрева. В идеале же винты должны стоять в вентилируемых корзинах.

Comments

[zzapp]

1) Все нормально было в смарте, контроллер бы запищал. какую то роль сыграл человеческий фактор, при перебросе на другую платформу рейда и контроллера. в итоге имеем два сдохших физически диска. мистика, но это правда.
2) То что?
3) Это да.
4) Диски не самое уг, 2 млн часов на отказ, рейдовые.
5) Продувка винтов стоит, не сказать что идеальная.

[lesha_penguin]

1) Насчет SMARTа. Когда контроллер «запищит» — зачастую уже поздняк метаться. Как только начали появлятся первые релокейты — это повод подготовить диск на замену. А когда количество релокейтов начнет расти — то надо просто брать и менять не дожидаясь когда что-то «запищит».
2) Почему 5рейд не стоит использовать я вам могу расписать лекцию на полчаса. В частности всяческие «мистические» истории про внезапное подыхание, про назкую производительность, повышенный износ, а также про почти полную неремонтопригодность.
4) Диски не уг — это, простите, если не секрет что? :) Количество часов наработки на отказ сразу разделите на 10 если собираетесь эксплуатировать 24x7 и на 100 если 24x7 в режиме жесткой эксплуатации высоконагруженного ввода-вывода. А уж какие-нибудь сигейтовские 2000000 часов сразу смело делите на 100500 (ихние часы считаются походу отделом маркетинга).
5) Плохо, кстати, тот же смарт покажет насколько у вас продувка работает по температуре винтов.

Answer 2

[dbmaster]

Добавить ещё серваков с репликацей в том же (HA) или в другом но недалёком (DR) дата центрах.

Answer 3

[Пума Тайланд]

Бекапы полностью решают эту проблему с минимальными финансовыми и трудозатратами, зачем костыли?

Answer 4

[Влад Животнев]

Собирайте 10ку, не экономьте. Смотрите в smart, читайте отчеты mdadm (он начинает ресинк, если нашлись битые кластеры. А главное — сообщит об убитом диске). Не используйте хардварные рейды. Активно читаемое кешируйте на ssd или в память, если её много. Не используйте десктопные hdd (особенно грины). В смысле совсем десктопные. Есть те, что позинционируют как «для настольного ПК», но хорошо чуствуют себя в серверах soho — caviar black, например.

Ну и да — если данные совсем важные — храните их где-нибудь ещё. Хотя бы даже на внешних дисках в другом помещении (главное, не там же, где сервер). Пожары, грабеж… нувыпонели.

Comments

[ranzhe]

Извините, но почему хардверные рейды-то не использовать? Даже если выйдет из строя контроллер (что довольно редко случается), то те же адаптеки спокойно могут считать метаданные с дисков в случае замены контроллера.

Answer 5

[Cyrill]

Давноо на хабре была статья, почему RAID-5 — не торт. По существу могу предложить таки реализовать политику резервного копирования и не экономить на дисках.

Тру-параноики вообще реплицируют данные между разными серверными, которые, бывает, расположены на разных материках ;)

Answer 6

[Григорий]

Если несколько серваков посмотрите в сторону DRBD,GlusterFS.