Я правильно понимаю, что RAID5 уже не актуален?
Уже пять лет не актуален
http://www.zdnet.com/blog/storage/why-raid-5-stops-working-i...
http://www.zdnet.com/blog/storage/why-raid-5-stops-working-i...
use ZFS, Luke
Вероятность неправильно посчитана, но для больших дисков не актуален, да.
Актуален, например, для 3-6 x600Gb 15krpm.
Правда актуальность таких винтов сама по себе под вопросом.
Правда актуальность таких винтов сама по себе под вопросом.
use ZFS, Luke+1
ZFS замечательно спасает от единичных ошибок чтения/записи, веротяности которых автор и взял для расчётов вероятности сбоя при перестроении RAID5.
память, конечно, нужна
Полгода крутится помойка на RAID Z из 5х4ТБ=16ТБ - пока всё отлично. Хотя упса не стоит, а свет частенько отрубают.
Полгода крутится помойка на RAID Z из 5х4ТБ=16ТБ - пока всё отлично. Хотя упса не стоит, а свет частенько отрубают.
Путем увеличения все той же избыточности. Чудес не бывает...
Вероятность неправильно посчитана, но для больших дисков не актуален, да.Не актуален в каком контексте?
Правильно ли я понял, что не актуален для 100% сохранности данных, но всё еще актуален для сохранности 99.99% данных?
Никогда не понимал этих расчетов. ОК, люди считают, какая вероятность получить неустранимую ошибку при ребилде массива, что эквивалентно, грубо говоря, вероятности появления ошибки при *последовательном* двукратном считывание (если говорить о raid 5 из 3 дисков при одном отказавшем) объема данных равного объему диска. Но постойте! Разве в процессе обычного использования диска на чтение не должно происходить того же самого? Грубо говоря, ваша система должна ругаться каждые 30 дней (предполагая ежедневный трафик обмена с диском в 100 Гб) об обнаружении некорректируемой ошибки диска? Что-то не замечал я что хотя бы за 2 года наработки хотя бы моего лаптопного диска была хоть однократная залогированная подобная ошибка.
Тут исходят из предпосылки, что если ты просто тупо возьмешь любой диск размером 4Тб, и попытаешься весь прочитать, то с вероятностью в районе 33% ты наткнешься на хотя бы одну URE.
Если все так, то имхо смысла в таких дисках как-то не очень много, и вообще непонятно, как же мы вообще живем с этим всем на декстопах без рейда...
Подозреваю, что с этими вероятностями что-то не так.
Если все так, то имхо смысла в таких дисках как-то не очень много, и вообще непонятно, как же мы вообще живем с этим всем на декстопах без рейда...
Подозреваю, что с этими вероятностями что-то не так.
с вероятностью 10^-14*8*6*10^12 = 48%Представь, что у тебя диски не 2Тб (хранилище 6Tb), а 6Tb (хранилище 18Tb), тогда по твоей формуле получаем 48*3=144%! Ты почти догнал Чурова. :-D
По терверу что было в
Если у события вероятность X, то вероятность получить хотя бы 1 раз из N попыток будет не X*N, а 1-(1-X)^N.
1- (1 - 10^-14)^(8*6*10^12)
По моим расчётам получается ~0.38, но я не уверен в достаточной точности вычислений утилиткой bc из состава FreeBSD:
$ echo '(1-1/10^14)'|bc -l
.99999999999999000000
$ echo '.99999999999999^48'|bc -l
.99999999999952000000 <===== вот здесь явно не хватает точности
$ echo '.99999999999952^10000'|bc -l
.99999999520000001151
$ echo '.99999999520000001151^10000'|bc -l
.99995200115198146822
$ echo '.99995200115198146822^10000'|bc -l
.61878339180552203246
$ echo 1-.61878339180552203246|bc -l
.38121660819447796754
Путем увеличения все той же избыточности. Чудес не бывает...Кэп 80ого уровня?
Это к тому, что я не понимаю "замечательности" предлагаемого солюшена.
не, ну понятно что надо считать (1-P)...
всё равно цифры 38% - это удручающе
всё равно цифры 38% - это удручающе
вероятность ошибки сейчас у дисков примерно 10^-14 на 1 битЧто такое вероятность ошибки у дисков? Все сектора защищены контрольными суммами на уровне железа и все возможные ошибки отслеживаются и исправляются тоже на уровне железа.
Что-то не замечал я что хотя бы за 2 года наработки хотя бы моего лаптопного диска была хоть однократная залогированная подобная ошибка.
Актуален, например, для 3-6 x600Gb 15krpm.Это не большие диски.
Что такое вероятность ошибки у дисков? Все сектора защищены контрольными суммами на уровне железа и все возможные ошибки отслеживаются и исправляются тоже на уровне железа.Конктретно тут имеется в виду вероятность получения URE, как уже упомянули, что есть Unrecoverable Read Error. Т.е. диск пытался прочитать блок, но контрольная сумма не сошлась. Пытался он скорее всего несколько раз, после этого сдался и выдал ошибку. В принципе эту область скорее всего можно успешно перезаписать и пользоваться дальше, но вот прочитать уже не получилось и можно считать, что этот блок данных потерян. В случае восстановления массива если на одном из дисков произойдёт такая ошибка, то мы теряем этот метаблок, конечно же, а не полный писец приходит. Но это может быть тоже невесело, т.к. мы надеемся, что RAID наши данные "защищает".
с вероятностью 10^-14*8*6*10^12 = 48% мы получим фейлА почему 8*6 у тебя же 4*2TB диска в рейде? И читаться будут 3. Т.е. будет 3*2 вроде?
Итого вероятность потери метаблока 5.8%. Не очень велика, но это уже достаточно, чтобы так не делать.
А почему 8*6 у тебя же 4*2TB диска в рейде? И читаться будут 3. Т.е. будет 3*2 вроде?8 - это бит в байте. 6 - это сколько TBytes необходимо прочитать при ребилде, чтобы из них получить данные для записи на новый винт.
Это не большие диски.Да. Не большие и быстрые диски. Собственно это я как пример того, что RAID5 в некоторых случаях всё ещё актуален.
А для 1+Tb 5400rpm не актуален чуть более чем полностью.
В случае восстановления массива если на одном из дисков произойдёт такая ошибка, то мы теряем этот метаблок, конечно же, а не полный писец приходит.зависит от рейда, может просто выкинуть диск из него и пипец всему рейду
Ну значит с этой оценкой что-то не то. По ней выходит что после 3 циклов перезаписи на 2TB диске с вероятностью 50% вылезет бэд сектор. Если бы это внезапно стало правдой, то все вокруг упало бы прямо сейчас.
Мне приходится работать с террабайтами постоянно обновляющихся данных на сотнях драйвов без использования рейдов, причем важно следить за их неизменностью хэшированием. Никаких подобных проблем не наблюдается. Если вдруг вылезает бэд, то он никогда не будет один, обычно сразу тыщи их на драйве, и такой драйв выкидывается.
Мне приходится работать с террабайтами постоянно обновляющихся данных на сотнях драйвов без использования рейдов, причем важно следить за их неизменностью хэшированием. Никаких подобных проблем не наблюдается. Если вдруг вылезает бэд, то он никогда не будет один, обычно сразу тыщи их на драйве, и такой драйв выкидывается.
8 - это бит в байте. 6 - это сколько TBytes необходимо прочитать при ребилде, чтобы из них получить данные для записи на новый винт.Да. Чего-то затупил. Сам сначала так считал же.
Ну значит с этой оценкой что-то не то. По ней выходит что после 3 циклов перезаписи на 2TB диске с вероятностью 50% вылезет бэд сектор. Если бы это внезапно стало правдой, то все вокруг упало бы прямо сейчас.Ну может они всё же не в таких количествах обновляются у тебя. Потом вероятность URE разная может быть - посмотри спеки на свои диски.
Мне приходится работать с террабайтами постоянно обновляющихся данных на сотнях драйвов без использования рейдов, причем важно следить за их неизменностью хэшированием. Никаких подобных проблем не наблюдается. Если вдруг вылезает бэд, то он никогда не будет один, обычно сразу тыщи их на драйве, и такой драйв выкидывается.
Можно так же проверить попробовать если у кого есть лишние диски.
Так же у меня свой пример есть. В хецнере диски постоянно приходится менять из-за возникающих ошибок чтения.
Да. Не большие и быстрые диски. Собственно это я как пример того, что RAID5 в некоторых случаях всё ещё актуален.Я сразу сказал, что зависит от размера.
А для 1+Tb 5400rpm не актуален чуть более чем полностью.
А скорость тут прт чём не очень понятно. Число ошибок только косвенно от неё зависит. Типа серверные дорогие диски имеют лучше характеристики по веротности ошибки и быстрее.
Так же у меня свой пример есть. В хецнере диски постоянно приходится менять из-за возникающих ошибок чтения.у меня в хетцнере был 1 комп на котором 4 раза меняли диски (и один из них - 2 диска одновременно)
и были остальные примерно 10 той же конфигурации, в которых за тот же период ничего не меняли
может и вероятность так рассчитывается - в одном случае из 100 диск дохнет после чтения 10^46 бит, остальные 99 нормальные и без ошибок отдают >>10^50 бит - в среднем пишем 10^48
А скорость тут прт чём не очень понятно. Число ошибок только косвенно от неё зависит. Типа серверные дорогие диски имеют лучше характеристики по веротности ошибки и быстрее.RAID-ы дохнут не только от невозможности чтения сектора на одном из винтов во время ребилда, но и от просто сдохшего "от времени" 2ого винта. Т.е. вероятность подыхания за более продолжительный период ребилда выше. RAID из быстрых дисков быстрее отребилдится, чем из медленных того же объёма. Значит вероятность выхода из строя 2ого диска во время ребилда ниже.
Собственно это основное, на что надо смотреть при оценке вероятности потери RAID при ребилде, а не на вероятность ошибки при чтения 1 бита.
BTW, тут уже говорили, что рассматривать ошибку чтения одного бита бессмыслено, т.к. контрольные суммы секторов на диске как раз позволяют исправлять несколько ошибочно считанных бит. Пример подобной "контрольной" суммы проходят на первом курсе ВМК в "Дискретной математике" - "Код Хэмминга". Так что вопрос сам по себе поставлен некорректно - если даже в каждом секторе будет считано неверно не более допустимых N бит, то вся информация с диска считается верно.
В таком случае надо посчитать вероятность того, что при считывании одного сектора будет ошибочно считано более N бит. Из этого можно вывести и общую вероятность наворачивания RAID при ребилде.
RAID-ы дохнут не только от невозможности чтения сектора на одном из винтов во время ребилда, но и от просто от времени сдохшего 2ого винта. Т.е. вероятность подыхания за более продолжительный период ребилда выше. RAID из быстрых дисков быстрее отребилдится, чем из медленных того же объёма. Значит вероятность выхода из строя 2ого диска во время ребилда ниже.Да, такая вероятность есть, но она ниже появления URE. Плюс скорость линейного чтения с диска зависит не только от скорости вращения, но и от плотности.
Собственно это основное, на что надо смотреть при оценке вероятности потери RAID при ребилде, а не на вероятность ошибки при чтения 1 бита.
BTW, тут уже говорили, что рассматривать ошибку чтения одного бита бессмыслено, т.к. контрольные суммы секторов на диске как раз позволяют исправлять несколько ошибочно считанных бит.Описанное тобой - это исправимая ошибка чтения. А URE на то и unrecoverable, что значит, что данные восстановить не получилось. Иначе бы вопрос стоял просто про read error.
Мне вообще кажется, что избыточность в дисках уже давно используется не на крайний случай, а постоянно.
Уже пять лет не актуаленНе понятно высказывание автора, что и RAID 6 скоро станет не актуальным. Вероятность, что на втором диске URE будет для этого же блока очень мала. Пока представляется, что RAID 6 будет ещё актуален достаточно долго.
http://www.zdnet.com/blog/storage/why-raid-5-stops-working-i...
Да, такая вероятность есть, но она ниже появления URE.Совсем не очевидно. Не раз встречал винты, которые просто брали и дохли, а до этого не выдали ни одного URE.
Плюс скорость линейного чтения с диска зависит не только от скорости вращения, но и от плотности.Ты тоже кэп 80ого уровня? Речь о более-менее современных дисках - среди них больший RPM однозначно означает большую линейную скорость чтения/записи.
Описанное тобой - это исправимая ошибка чтения. А URE на то и unrecoverable, что значит, что данные восстановить не получилось.Тогда объясни почему эта ошибка измеряется в битах, а сектор у нас как минимум 512*8 полезных бит?
А лучше покажи как из этого всего посчитать вероятность отказа при перестроении RAID5.
Иначе бы вопрос стоял просто про read error.С чего ты взял что речь изначально о чём-то другом? Автор ни слова не сказал об URE.
Мне вообще кажется, что избыточность в дисках уже давно используется не на крайний случай, а постоянно.Для тебя это новость? Чё серьёзно?!
А прикинь, что у серверных винтов 15krpm больше recovery-data на каждый сектор, чем у десктопных 7200/5400rpm!
Совсем не очевидно. Не раз встречал винты, которые просто брали и дохли, а до этого не выдали ни одного URE.Из этого не следует, что это событие более вероятное. Потом это зависит от использования этих дисков. Если с них мало читать, то и вероятность, что ошибка возникнет, тоже маленькая. А сломаться они могут от времени и т.п. Так же бывают всякие бракованые серии — у них вероятность сломаться вполне может быть больше.
Ты тоже кэп 80ого уровня? Речь о более-менее современных дисках - среди них больший RPM однозначно означает большую линейную скорость чтения/записи.Мне кажется, что спектр достаточно велик. Кстати, вот ещё не знаю как там у быстрых, но маленьких SAS-дисков дела обстоят — они не весь блин используют что ли?
Тогда объясни почему эта ошибка измеряется в битах, а сектор у нас как минимум 512*8 полезных бит?Потому что сектор не обязательно 512 байт. Как ты там говоришь? Для тебя это новость, что во многих современных винтах секторы по 4096 байт?
А лучше покажи как из этого всего посчитать вероятность отказа при перестроении RAID5.
Ошибка измеряется в битах, т.к. это сравнимая для всех величина. На самом деле, конечно, у нас есть не вероятность получить неправильный бит, а сразу неправильный сектор с вероятностью P=1-(1-p)^(512*8). Ну т.е. исходная величина, конечно, P, но сравнивать удобнее p.
Из-за этого вероятность получения сбойного RAID5 посчитанная побитово — приближённая. Но там вроде погрешность не очень большая выходит.
С чего ты взял что речь изначально о чём-то другом? Автор ни слова не сказал об URE.Я не знаю где это "там". Я про это в нескольких местах читал.
Для тебя это новость? Чё серьёзно?!Не то, чтобы новость. Я в подробности не вдавался просто, но для меня это кажется само собой разумеющимся. А может и слышал где-то. И да, у серверных винтов в спеках вероятность URE ниже на порядок или несколько может быть. Наверняка не из-за того, что у них технологии более совершенные.
А прикинь, что у серверных винтов 15krpm больше recovery-data на каждый сектор, чем у десктопных 7200/5400rpm!
как минимум 512
Потому что сектор не обязательно 512 байт.Учу читать внимательно. Дорого.
Мы с тобой на 80% говорим одно и тоже, но каждый твой пост выглядит, как будто ты со мной споришь. Причём с самого первого моего поста.
Мы с тобой на 80% говорим одно и тоже, но каждый твой пост выглядит, как будто ты со мной споришь. При чём с самого первого моего поста.Я не спорю, а занудствую и вношу уточнения.
Основная проблема - огромное время ребилда и катастрофическая деградация скорости массива на это время
Оставить комментарий
yolki
вероятность ошибки сейчас у дисков примерно 10^-14 на 1 битпри ёмкостях харда в 2 терабайта, допустим имеем 4 харда в пятом рейде. (хранилище на 6тб)
при выходе из строя одного харда и при замене на другой, у нас запустится перестроение массива и с вероятностью 10^-14*8*6*10^12 = 48% мы получим фейл на одном из дисков и придёт большой и пушистый всему массиву.