LINUX.ORG.RU

raid5 - пара моментов


0

0

Всем привет.

В общем ощущаю необходимость создать raid, остановился на raid5, порыл интернет, и наткнулся на вот такую заметку http://m.habrahabr.ru/post/78311/ , для Ъ поясню что меня смущает. Автор утверждает что во время ребилда весь массив может нагнуться из-за BER(Bit Error Rate) на больших объемах данных. У меня в планах создать raid5 на 10Тб, где-то так. Само по себе время ребилда не так критично, пугает как раз эта «вероятностная» потеря данных массива целиком.

Может кто-нить прокомментировать эту ситуацию ?

На первом этапе планирую сделать массив из 3x2Tb, потом просто добавить.

★★★★

Начни с другой стороны.

Дано: 10Тб данных

Вопросы:
1. Ценность данных в случае потери?
2. Доступность (онлайн), допустимы ли простои на восстановление?
3. Приоритет: быстродействие или надежность?
4. Оборудование? Тремя дисками не обойдешься. Есть куда пихнуть 7-8 дисков? По питанию и охлаждению тянешь?
5. Бюджет?

А raid5 на трех дисках не рекомендуется по вышеуказанной причине.

sdio ★★★★★ ()

На самом деле ситуация хуже. RAID5 во время ребилда защищен не более, чем RAID0, и жутко тормозит, т.к. на каждый диск приходится в N раз большая нагрузка (где N - число оставшихся дисков) от приложений.

AEP ★★★★★ ()
Ответ на: комментарий от sdio

ну бюджет - 5-6 тыщ на диск в 2 Тб, на данный момент это WD2001FASS, на их основе собираюсь всё делать. В общем данные довольно ценные, но другие варианты довольно накладно выходят, тут я думал будет золотая середина. Быстродействие - особенных запросов тут нет. Куда пихать диски есть, под это дело специально покупался корпус и мощный блок питания, с охлаждением тоже вроде всё нормально должно быть. А начать решил с 3х дисков ибо минимум для raid5, дальше добавлю харды в процессе.

Смущают именно слова насчет того что есть нехилый шанс что во время ребилда все данные на рейде умрут... В принципе во время ребилда можно будет приостановить все текущие задачи.

Drolyk ★★★★ ()

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

Если в массиве есть место, лучше использовать диски меньшего объёма.

mikki ()
Ответ на: комментарий от Drolyk

Drolyk> Смущают именно слова насчет того что есть нехилый шанс что во время ребилда все данные на рейде умрут

На практике у меня диски в рейд5 никогда не умирали в процессе ребилда. Кроме того, не вижу разницы в объеме копируемых данных в сравнении с раид1, например. Вобщем можешь попробовать.

sdio ★★★★★ ()
Ответ на: комментарий от Drolyk

Drolyk> В общем данные довольно ценные, но другие варианты довольно накладно выходят

Домашний NAS для хранения фильмов немецких кинодокументалистов?

sdio ★★★★★ ()
Ответ на: комментарий от sdio

> Домашний NAS для хранения фильмов немецких кинодокументалистов?

ну не совсем домашний, но из этой серии

Ладно, погуглил, если что raid5 в raid6 довольно легко преобразуется, так что если нужно будет больше надежности, то придется выделить ещё бабла на диск %)

Drolyk ★★★★ ()

Юзать ZFS, там контрольная сумма на каждый блок данных (128кб), и ему побитовые ошибки непочём, проверено глючными винтами. Юзаю ZFS-FUSE на домашнем сервере (8 винтов), скорость вполне устраивает (140мб\сек чтение), но нужен мощный проц. Стабильность отличная, ни разу не падало за год. Раньше был рейд5 на хардварном контроллере адаптек, вроде тоже работало хорошо, пару раз ребилдил, но вот как раз из-за возможности скрытых ошибок перешел на ZFS.

blind_oracle ★★★★★ ()

Меньше надо читать хабру там еще не то напишут.

Несложная математика уровня calc.exe говорит нам, что 10^14 бит это всего лишь около 11TB данных. Это означает, что производитель жестких дисков говорит нам таким образом, что считав с диска с параметром BER 10^14, то есть обычного, десктопного класса диска, примерно 11TB, мы, с точки зрения производителя, наверняка получим где-нибудь сбойный бит.

Причем эту цифру этот хабраидиот взял из WD-шной PDF-ки:

Non-recoverable read errors per bits read <1 in 10E14

даже не подумав, почему написанно «Non-recoverable». Значит есть и «recoverable» ?

Собственно наивно думать что данные хранятся на пластинах диска в сыром виде. Они завернуты в жирный слой коррекции и восстановления ошибок. Реально «сырая» емкость диска намного больше той, которая указана на этикетке :-)

Да и вообще, ошибки в общем бывают трех типов(упрощенно):

Первая — ошиблись, и исправились.

Вторая — ошиблись, и восстановить не смогли. Например, участок сбоя достаточно обширен, чтобы на него не хватило помехоустойчивого кода. Ошибка вышла наружу, но она видна, контроллер говорит — «ошибка, ой».

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

Итог: Я так понял, что эти цифры в 10E14(хотя нужно конечно уточнить у Western Digital) относятся к третьей категории и просто определяют некий критический объем данных (те самые 11ТБ), свыше которых помехоустойчивое кодирование пропустит ошибку (не заметит ее).

А теперь, ТС, решай сам, будешь ли ты ставить в RAID 10ТБ диски ?

Хотя я думаю что механизмы помехоустойчивого кодирования будут усовершенствованы в новых моделях для такой емкости.

ef37 ★★ ()

Для примера к прошлому посту данные на FiberChannel-ную 36 Гб барракуду начала 200-х годов(просто PDF-ка по ней мне попалась первой в гугле):

Seek error rate: Less than 10 errors in 10E8 seeks

Жуть какая :-) Оказывается, диск на каждом сотом мегабайте не может с 10-го раза правильно спозиционировать головку.

Recoverable media error rate Less than 10 errors in 10E12 bits transferred (using OEM default settings):

АААА!! Страх и ужыс ! Система коррекции ошибок исправляет 10 ошибок в каждом прочитанном террабайте. Хана котенку, т.е. RAID-у.

Unrecovered media data: Less than 1 sector in 10E15 bits transferred

Это собственно те самые ошибки второго типа, заметьте, измеряются в секторах.

Miscorrected media data: Less than 1 sector in 10E21 bits transferred

Вот это самая цифра, свыше которой RAID-у действительно придет каюк, да.

ef37 ★★ ()
Ответ на: комментарий от ef37

Итог: Я так понял, что эти цифры в 10E14(хотя нужно конечно уточнить у Western Digital) относятся к третьей категории и просто определяют некий критический объем данных (те самые 11ТБ), свыше которых помехоустойчивое кодирование пропустит ошибку (не заметит ее).

Объём прочитанных данных, а не просто объём. Т.е. для полного чтения 1ТБ диска, грубо говоря, будет вероятность не более 0.1 (т.е. 10%) для одной однобитовой ошибки.

mikki ()
Ответ на: комментарий от ef37

ef37> Третья — ошиблись, но даже и не заметили. И контроллер пропустил. Ошибочный блок вышел наружу и попал в программу, или записался на диск незамеченным, потому что у помехоустойчивого кодирования тоже конечная надежность.

Как это получается?
Прочитали сырые данные с блина --> Посчитали контр. сумму --> (Сумма не совпала) --> запустили механизм восстановления --> (восстановили неудачно) --> Посчитали контр. сумму --> (Сумма совпала?) --> отдали порченные данные программе.

sdio ★★★★★ ()
Ответ на: комментарий от sdio

> Да ну?!

Действительно, ошибся. В режиме с одним битым диском с вероятностью (примерно) 1/N надо обратиться ко всем дискам и посчитать parity, а с вероятностью 1 - 1/N просто считать данные с нужного диска. Нагрузка возрастет примерно вдвое, а не в N раз.

AEP ★★★★★ ()
Ответ на: комментарий от AEP

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

Ну, да, и диски вращаются с удвоенной в N раз скоростью. :)))

iZEN ★★★★★ ()

10ТБ это страйп из:
первый RAID-5 (2ТБ, 2ТБ, 2ТБ) = 4ТБ
второй RAID-5 (2ТБ, 2ТБ, 2ТБ) = 4ТБ
третий RAID-1 (2ТБ, 2ТБ) = 2ТБ

Ещё совтую добавить хотя бы один Hot Spare на 2ТБ для горячей замены отказавшего диска в одном из массивов.

iZEN ★★★★★ ()
Ответ на: комментарий от iZEN

iZEN> с удвоенной в N раз скоростью

смешная, как всегда, фраза.

sdio ★★★★★ ()
Ответ на: комментарий от iZEN

а какой профит городить страйп ? получается 8 дисков нужно, если еще в каждый raid5 закинуть по hot-spare, то никакой экономии от raid5 не будет :) Raid5-6 и выбирался из-за своей экономичности :)

Drolyk ★★★★ ()
Ответ на: комментарий от Drolyk

Профит в том, что hot spare для всего хранилища, а не для каждого из подмассивов.

RAID-6 — тормоз.

iZEN ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.