Comments 177
RAID0+1
Ёмкость массива будет равна удвоенной ёмкости используемых дисков;
А разве не половинной?
Ёмкость массива будет равна удвоенной ёмкости используемых дисков;
А разве не половинной?
Пара замечаний по скорости:
Правильный контроллер на RAID 0+1 с использованием read ahead может читать на суммарной скорости всех дисков, а писать на половине суммы.
На Raid-5 3 диска — читать на 2x одного диска, и писать тоже на 2x одного диска, пока хватает процессора.
Если скорости меньше — значит кривой контроллер, и не может писать/читать на все диски с макс.скоростью, упирается где-то в полосу пропускания.
Правильный контроллер на RAID 0+1 с использованием read ahead может читать на суммарной скорости всех дисков, а писать на половине суммы.
На Raid-5 3 диска — читать на 2x одного диска, и писать тоже на 2x одного диска, пока хватает процессора.
Если скорости меньше — значит кривой контроллер, и не может писать/читать на все диски с макс.скоростью, упирается где-то в полосу пропускания.
Только что проверил на домашнем сервере (RAID-5 из 3-х дисков)
sdb1: 80Mb/s
sdc1: 80Mb/s
sdd1: 95Mb/s (разные веники)
Весь массив: 157Mb/s
Мерялось через hdparam -t /dev/xxx
sdb1: 80Mb/s
sdc1: 80Mb/s
sdd1: 95Mb/s (разные веники)
Весь массив: 157Mb/s
Мерялось через hdparam -t /dev/xxx
UFO just landed and posted this here
«… Если говорить о производительности операции XOR (основа для RAID-5), то с этим всё более, чем прекрасно, да и RAID-6 арифметика тоже хорошо бы если оказалась bottle-neck'ом. Вообще, у каждого из RAID-решений свои ±'ы, их просто нужно знать. …»
(по-ссылкам есть замеры производительности, которые выполняет Linux-ядро при каждой загрузке LSR-подсистемы.)
(по-ссылкам есть замеры производительности, которые выполняет Linux-ядро при каждой загрузке LSR-подсистемы.)
проверяли на разных дисках, от 5400rpm «green», до SAS'ов, при правильном построении 10ка и 5й дают скорости примерно на 5-10% отличимые. но количества сэкономленного места на 5м не может не радовать, особенно при дорогих SAS'ах.
что касается железный или софтовый — в данный момент только zfs даёт хороший софтовый рейд, всё остальное заткнётся на 10-20 паралельных потоках. те кто тестирует тут скорости софтрейдов — вы в один поток не тестируйте, в один оно завсегда железный обгонит. вообще конечно 400мгц powerpc завсегда медленней современного ксеона, даже с самой заточенной firmware, но на практике вот такие пироги получаются.
тем не менее на HBA экономить тоже нечего, большой кеш и ADRA часто решают. что касается soft vs hard, нужна независимость от HBA — raidz, критичны 5% попугаев на скорость — hardware.
что касается железный или софтовый — в данный момент только zfs даёт хороший софтовый рейд, всё остальное заткнётся на 10-20 паралельных потоках. те кто тестирует тут скорости софтрейдов — вы в один поток не тестируйте, в один оно завсегда железный обгонит. вообще конечно 400мгц powerpc завсегда медленней современного ксеона, даже с самой заточенной firmware, но на практике вот такие пироги получаются.
тем не менее на HBA экономить тоже нечего, большой кеш и ADRA часто решают. что касается soft vs hard, нужна независимость от HBA — raidz, критичны 5% попугаев на скорость — hardware.
все очень просто — все RAID — это инструменты. Разные инструменты!
Просто нужно использовать каждый инструмент по его назначению, дабы не испытывать внезапных разочарований и стрессов.
Просто нужно использовать каждый инструмент по его назначению, дабы не испытывать внезапных разочарований и стрессов.
UFO just landed and posted this here
2. Вот стоит в 5 метрах от меня soft-raid-5, на 150Мб/сек нагрузка процессора при чтении около 0, при записи — около 15% на Opteron 165 (1.8Ghz).
Так что думаю вопрос нагрузки процессора неактуален.
Так что думаю вопрос нагрузки процессора неактуален.
UFO just landed and posted this here
Ну, мне как бы нагрузку снижать некуда :-) Затраты на RAID и Samba — единственное что хоть сколько-то жрет.
Всякие торренты и WebServer — копейки.
Более того, скоро апгрейд сервера до C2D E8600 — считай в 3 раза быстрее.
А вот возможность расширить рейд на лету без бэкапа на 2-3Тб — бесценно :-)
Всякие торренты и WebServer — копейки.
Более того, скоро апгрейд сервера до C2D E8600 — считай в 3 раза быстрее.
А вот возможность расширить рейд на лету без бэкапа на 2-3Тб — бесценно :-)
UFO just landed and posted this here
Частота 3.33Ghz vs 1.8Ghz
Кеш 6Мб vs 1Мб
Ну и гигагерцы у интела пожирнее.
Кеш 6Мб vs 1Мб
Ну и гигагерцы у интела пожирнее.
UFO just landed and posted this here
Насчет соседа согласен. Но это то, что приходится платить ради того, чтобы за те же деньги иметь массив 3Тб а не 2Тб, и иметь возможность расширить его на лету когда возникнит необходимость.
Насчет производительности — естественно все не так просто (все помнят дутые Мгц P4), но на очень многих задачах отрыв будет именно таким, а на некоторых — и больше (там где задача в 1Мб кеша не лезет, а в 6 — лезет).
Насчет производительности — естественно все не так просто (все помнят дутые Мгц P4), но на очень многих задачах отрыв будет именно таким, а на некоторых — и больше (там где задача в 1Мб кеша не лезет, а в 6 — лезет).
UFO just landed and posted this here
Простите, а производительность видеокарт вы в мегабайтах измеряете?)
Персонально он — в FLOPS, наверное ;) Он статью по HPC писал :)
Размер кеша имеет очень большое значение, особенно в серверных приложениях.
Но лично вы можете использовать Celeron E1400 — они от E8600 отличаются в основном только кешем, зачем платить в 4 раза больше за совершенно ненужный кеш :-)
Но лично вы можете использовать Celeron E1400 — они от E8600 отличаются в основном только кешем, зачем платить в 4 раза больше за совершенно ненужный кеш :-)
А еще у АМД даж современных 1 сложение 1 умножение 1 универсальное, а у интела все универсальные за такт идут вроде. У самого core2quad q9550 (2.86@3.00, 12mb кеша l2), он просто в клочья дерет четырехядерники атлона под нагрузкой.
UFO just landed and posted this here
UFO just landed and posted this here
Есть, но они работают не «внутри», а «снаружи», на внешнем антивирусном сервере, для такого даже специальный протокол (ICAP) написан.
Нет, на таком дохлом камне — ОТ. ;)
Антивирус то ещё зачем?
> А RAID5 в общем случае очень даже обеспечивает — если один из трёх
> накопителей вернёт неверные данные, то будет однозначно известно, что
> они не достоверны.
> Как такое (недостоверность данных) может случиться?
Вот это сюрприз! К сведению, RAID-5 не использует parity до тех пор, пока один из дисков не вылетел из «связки». Или, иными словами RAID-5 защищает от одного отказа (но не от ошибки), в то время как RAID-6 — от двух отказов, или одной ошибки (IIRC).
> накопителей вернёт неверные данные, то будет однозначно известно, что
> они не достоверны.
> Как такое (недостоверность данных) может случиться?
Вот это сюрприз! К сведению, RAID-5 не использует parity до тех пор, пока один из дисков не вылетел из «связки». Или, иными словами RAID-5 защищает от одного отказа (но не от ошибки), в то время как RAID-6 — от двух отказов, или одной ошибки (IIRC).
Откуда информация? Совершенно точно говорю, что все вменяемые платы аппаратного RAID5 обеспечивают контроль достоверности данных. Для этого, кстати, не нужно читать с трёх дисков — достаточно двух. Я не уверен насчёт программного, но сильно подозреваю, что тоже должен обеспечивать.
> Откуда информация?
ОБС (шучу). Не скажу точно, просто по-моему об этом информации хватает. Я почитываю Linux Software RAID рассылку, время-от-времени (иногда пописываю туда).
> Совершенно точно говорю, что все вменяемые
> платы аппаратного RAID5 обеспечивают контроль достоверности
> данных.
А зачем? Во-1-х, это существенно увеличит накладные расходы, а во-2-х, ну вот обнаружили эти «вменяемые платы аппаратного RAID5» несовпадение записанной parity и фактической, и что теперь? Невозможно ответить «где косяк», более того, вполне вероятно, что следущая же операция записи перезапишет этот ранее несовпадающий блок. Что должна эта плата-то сделать? Сказать операционке «ты знаешь, у тебя больше нет дискового массива, поскольку нашлось несоответствие»? Или просто поднять флаг «косяк обнаружен, полундра»? :-)
Вобщем, в RAID-5 с этим такая ситуация «by design».
(В том же LSR есть отдельная операция и scrub'а и проверки соответствия parity, обе проводятся в background, относятся к maintaining-процедурам, поскольку весьма дорогие в плане потребления ресурсов.)
> Для этого, кстати, не нужно читать с трёх дисков — достаточно двух.
Я не буду проверять арифметику, но смею заметить, что это, видимо, в случае с 3-я дисками в массиве. А если там их 8?
ОБС (шучу). Не скажу точно, просто по-моему об этом информации хватает. Я почитываю Linux Software RAID рассылку, время-от-времени (иногда пописываю туда).
> Совершенно точно говорю, что все вменяемые
> платы аппаратного RAID5 обеспечивают контроль достоверности
> данных.
А зачем? Во-1-х, это существенно увеличит накладные расходы, а во-2-х, ну вот обнаружили эти «вменяемые платы аппаратного RAID5» несовпадение записанной parity и фактической, и что теперь? Невозможно ответить «где косяк», более того, вполне вероятно, что следущая же операция записи перезапишет этот ранее несовпадающий блок. Что должна эта плата-то сделать? Сказать операционке «ты знаешь, у тебя больше нет дискового массива, поскольку нашлось несоответствие»? Или просто поднять флаг «косяк обнаружен, полундра»? :-)
Вобщем, в RAID-5 с этим такая ситуация «by design».
(В том же LSR есть отдельная операция и scrub'а и проверки соответствия parity, обе проводятся в background, относятся к maintaining-процедурам, поскольку весьма дорогие в плане потребления ресурсов.)
> Для этого, кстати, не нужно читать с трёх дисков — достаточно двух.
Я не буду проверять арифметику, но смею заметить, что это, видимо, в случае с 3-я дисками в массиве. А если там их 8?
Да, вики говорит, что не читается… Но жизненный опыт говорит обратное… Чёрт его знает. В любом случае в Recovery Mode все будет работать :)
Никто не мешает производителям конкретного контроллера это имплементировать и страшно понтоваться повышенной надежностью, правда скорость чуток просядет — если не читать с 3 дисков, то третий в это время уже может заниматься read-ahead…
Вообще-то точное место, где произошла ошибка, должны вычислять «горизонтальные» CRC или другие ECC-коды на самом носителе. Сектор либо имеет контрольную сумму, либо данные на физическом уровне записаны на носитель прямо с кодом коррекции. Но на практике, к сожалению, я сталкивался (и не раз в жизни) с ситуацией, когда с диска читаются искаженные данные, а ECC-контроль на уровне самого диска не срабатывает. Однако я до сих пор не знаю, отчего это раз в несколько лет случается. Если это сбой в операционной системе, в RAM или где-то на шинах еще при записи, то от такой проблемы не защитит и RAID в большинстве случаев.
Данные могли просто не попасть на один из накопителей. Пропали питание. Один накопитель успел записать данные, а второй нет. Или зависла система с программным RAID — на один накопитель успели записать, а на другой нет. На серверах это бывает сказочно редко, но бывает.
Один раз в жизни я наблюдал реальный «битовый распад». На диске лежал файл, который никто не трогал несколько лет. Оптимизаторы диска не запускались на этой машине. Но при бинарном сравнении этого диска с backup вдруг выяснилось, что один байт в одном из файлов искажен. При этом формально сектор читался без проблем.
Вряд ли данные исказились на самом носителе таким образом, что изменение в одном байте не заметили ECC-коды. Одно из двух — либо не смотря на то, что диск был дорогой, коварный производитель схалтурил и не проверял там контрольные суммы, либо была какая-то перезапись этого участка диска по какой-то причине и в ходе этого процесса произошел глюк в RAM, в ОС или на шине. Например, может быть Windows читает данные с диска большими блоками, или сама что-то релоцирует даже если никто не запускал оптимизаций. И глючит при этом.
Но я больше склонен думать, что производители даже для дорогих дисков иногда обманывают нас, покупателей, и реально не реализуют нормального контроля целостности при чтении. Так как диск через пару месяцев стал глючить уже с обнаружимыми ECC-ошибками и был выброшен целиком.
Вряд ли данные исказились на самом носителе таким образом, что изменение в одном байте не заметили ECC-коды. Одно из двух — либо не смотря на то, что диск был дорогой, коварный производитель схалтурил и не проверял там контрольные суммы, либо была какая-то перезапись этого участка диска по какой-то причине и в ходе этого процесса произошел глюк в RAM, в ОС или на шине. Например, может быть Windows читает данные с диска большими блоками, или сама что-то релоцирует даже если никто не запускал оптимизаций. И глючит при этом.
Но я больше склонен думать, что производители даже для дорогих дисков иногда обманывают нас, покупателей, и реально не реализуют нормального контроля целостности при чтении. Так как диск через пару месяцев стал глючить уже с обнаружимыми ECC-ошибками и был выброшен целиком.
> не использует parity до тех пор, пока один из дисков не вылетел из «связки»
Кстати, уточню, что не использует для восстановления информации, или обнаружения ошибки, ибо в пр-цпе, данные parity могут использоваться в некоторых ситуациях для более оптимальной обработки данных.
Кстати, уточню, что не использует для восстановления информации, или обнаружения ошибки, ибо в пр-цпе, данные parity могут использоваться в некоторых ситуациях для более оптимальной обработки данных.
> Начнём конечно же с вероятности отказа — отнимем вероятность отказа
> RAID5 от вероятности отказа RAID0+1:
> 4n^2+3n^3+n^4-(3n^2+n^3)=n^2+2n^3+n^4
> Не трудно видеть, что получилось положительно число, а значит
> вероятность отказа RAID0+1 однозначно (и заметно) выше вероятности
> отказа RAID5.
Epic Fail. Посчитайте, что будет при n = 0.01
> RAID5 от вероятности отказа RAID0+1:
> 4n^2+3n^3+n^4-(3n^2+n^3)=n^2+2n^3+n^4
> Не трудно видеть, что получилось положительно число, а значит
> вероятность отказа RAID0+1 однозначно (и заметно) выше вероятности
> отказа RAID5.
Epic Fail. Посчитайте, что будет при n = 0.01
Что плохо в RAID-5, RAID-6 и прочих схемах с коррекцией ошибок, так это то, что перед записью небольшой порции новых данных мы должны считать с диска старые данные или контрольную сумму. Без этого никак нельзя изменить контрольную сумму. При массовой записи этой проблемы нет, но для баз данных она актуальна и сильно снижает скорость записи по сравнению с зеркалированием.
Но не смотря на это я полностью поддерживаю Ваше мнение. Я считаю, что скорость работы дисков в реальных задачах не так важна, как надежность! Там, где не хватает скорости работы дисков, часто нужно искать другое решение, а не просто RAID другого уровня. Поэтому RAID-6 рулит. :)
Но не смотря на это я полностью поддерживаю Ваше мнение. Я считаю, что скорость работы дисков в реальных задачах не так важна, как надежность! Там, где не хватает скорости работы дисков, часто нужно искать другое решение, а не просто RAID другого уровня. Поэтому RAID-6 рулит. :)
> Вердикт прост — если не нужны лишние проблемы на ровном месте, то не нужно городить ни RAID1 ни RAID0+1 — нужно смотреть в сторону RAID5, 5E, 6.
Согласен с вердиктом касательно RAID-6, если бы не одно НО:
RAID-6 очень медленный на запись. Настолько, что ни один из производителей систем хранения не рекомендует его использовать в качестве primary-хранилища, то есть того, на котором лежат оперативные «боевые» данные.
А уж они-то, производители, в таки вещах разбираются побольше нашего.
Ну а про RAID-5 все что я думаю я уже сказал в своем посте ;)
Согласен с вердиктом касательно RAID-6, если бы не одно НО:
RAID-6 очень медленный на запись. Настолько, что ни один из производителей систем хранения не рекомендует его использовать в качестве primary-хранилища, то есть того, на котором лежат оперативные «боевые» данные.
А уж они-то, производители, в таки вещах разбираются побольше нашего.
Ну а про RAID-5 все что я думаю я уже сказал в своем посте ;)
Сказочно медленный по сравнению с чем? Да, RAID-6 медленнее, чем RAID-5 на том же числе дисков, но однозначно не медленнее чем один диск. наука гласит, что скорость RAID-6 равно скорости RAID-5 с количеством диском на один меньше чем у RAID-6. Категорически не понимаю, кто может не рекомендовать его использование.
Он медленнее чем RAID-5, который и сам-то далеко не молния.
Даже RAID-5 часто неприемлимо медленный, а что уж говорить про -6.
В общем я знаю только одну быструю и нетормозящую реализацию RAID-6, это RAID-DP в системах хранения NetApp. Все остальные, увы, не для primary.
А, да, возможно RAID-Z2 тоже ничего, по той же причине, что и RAID-DP, но тут ничего не могу сказать, не мерял, не держал.
Даже RAID-5 часто неприемлимо медленный, а что уж говорить про -6.
В общем я знаю только одну быструю и нетормозящую реализацию RAID-6, это RAID-DP в системах хранения NetApp. Все остальные, увы, не для primary.
А, да, возможно RAID-Z2 тоже ничего, по той же причине, что и RAID-DP, но тут ничего не могу сказать, не мерял, не держал.
Hitachi does not recommend using RAID 6 drives with high performance applications where extreme random writes are being performed. In some cases, the use of RAID 1 or RAID 1+0 is essential.
From a performance standpoint, the performance of RAID 5 and RAID 6 is pretty similar when we talk about Random Read, Sequential Read and Sequential Write workloads. There is added penalty when we talk about Random Write workloads, that is because of the two dimensional parity. Compared to RAID 5, RAID 6 takes a 33% Performance hit on Hitachi with Random Write workloads.
storagenerve.com/2009/02/09/hitachis-hds-raid-6/
Since there is an additional parity calculation associated with RAID-6, HP’s recommendation is to use RAID-6 ADG with lower writes and high reads only. If you have an application performing random writes, RAID 6 (ADG) might not be an option for you.
storagenerve.com/2009/02/13/hp%E2%80%99s-raid-6-adg-advanced-data-guarding/
From a performance standpoint, the performance of RAID 5 and RAID 6 is pretty similar when we talk about Random Read, Sequential Read and Sequential Write workloads. There is added penalty when we talk about Random Write workloads, that is because of the two dimensional parity. Compared to RAID 5, RAID 6 takes a 33% Performance hit on Hitachi with Random Write workloads.
storagenerve.com/2009/02/09/hitachis-hds-raid-6/
Since there is an additional parity calculation associated with RAID-6, HP’s recommendation is to use RAID-6 ADG with lower writes and high reads only. If you have an application performing random writes, RAID 6 (ADG) might not be an option for you.
storagenerve.com/2009/02/13/hp%E2%80%99s-raid-6-adg-advanced-data-guarding/
Если нужно записать много данных, например, сразу мегабайт, то практически все равно, писать ли их в формате RAID-5, RAID-6 или с зеркалированием. Дело в том, что при аппаратной или даже очень хорошей программной реализации обсчет контрольных сумм занимает ничтожно малое время по сравнению со скоростью работы железа. Но вот если мы меняем 1 сектор в уже записанных данных — тогда при зеркалировании вообще не нужно никакого дополнительного чтения, в RAID-5 нужно читать и менять одну контрольную сумму, а в RAID-6 нужно читать и менять две контрольных суммы. Однако так как эти операции происходят параллельно, то при идеальном контроллере RAID-6 не будет существенно медленнее RAID-5 по пропускной способности. А вот latency да, вырастет…
Немного не в тему:
По своему опыту скажу что головняка с софтовыми рейдами меньше. Что вы будете делать если сгорит ваш мега-крутой контроллер за 5к? Не факт что диски поднимутся на новом таком же, не говоря о других вендорах. И т.д. и т.п.
По своему опыту скажу что головняка с софтовыми рейдами меньше. Что вы будете делать если сгорит ваш мега-крутой контроллер за 5к? Не факт что диски поднимутся на новом таком же, не говоря о других вендорах. И т.д. и т.п.
Согласен на 100% )
Уже был переезд на другое железо — софтовый рейд (не fake) поднялся вообще без движений рук.
Уже был переезд на другое железо — софтовый рейд (не fake) поднялся вообще без движений рук.
Ну, во-первых, если там стандартный уровень RAID, то заработает на другом и даже на софтовом.
А во-вторых, «мега-крутой контроллер за 5к» как правило имеет встроенное ОЗУ с батарейкой и позволяет спокойнее относиться к пропаданиям питания (кэш записи находится в ОЗУ контроллера и подпитывается батарейкой). В некоторых приложениях, где запрещена отложенная запись, такая фишка повышает производительность на порядок. Более того они как правило ещё и знатно оптимизируют доступ к диску «на лету», что тоже сильно повышает производительность.
А во-вторых, «мега-крутой контроллер за 5к» как правило имеет встроенное ОЗУ с батарейкой и позволяет спокойнее относиться к пропаданиям питания (кэш записи находится в ОЗУ контроллера и подпитывается батарейкой). В некоторых приложениях, где запрещена отложенная запись, такая фишка повышает производительность на порядок. Более того они как правило ещё и знатно оптимизируют доступ к диску «на лету», что тоже сильно повышает производительность.
речь идет не о пропаже питания, а о самом контроллере, который может накрыться медным тазом
и там может быть не«стандартный уровень RAID» ;)
и там может быть не«стандартный уровень RAID» ;)
> если там стандартный уровень RAID, то заработает на другом и даже на софтовом.
И да, и нет — у разных массивов свои meta-данные, поэтому так вот просто взять и запустить может не выйти. Но вообще, делается, да: «… По P.S. — и не говори, до сих пор с ужасом вспоминаю 36 часов подряд на работе и исследования содержимого дисков — помер у одного клиента AMI MegaRaid старенький, к которому была прицеплена древняя же корзинка на 12 дисков SCSI 3,5". Ребус под названием «ну и как же этот долбанный контроллер перемежал RAID50 на 12 дисках» решить удалось, и загнать в аналогичный режим работы linux software raid тоже, однако повторения подобного ой как не хочется. …»
И да, и нет — у разных массивов свои meta-данные, поэтому так вот просто взять и запустить может не выйти. Но вообще, делается, да: «… По P.S. — и не говори, до сих пор с ужасом вспоминаю 36 часов подряд на работе и исследования содержимого дисков — помер у одного клиента AMI MegaRaid старенький, к которому была прицеплена древняя же корзинка на 12 дисков SCSI 3,5". Ребус под названием «ну и как же этот долбанный контроллер перемежал RAID50 на 12 дисках» решить удалось, и загнать в аналогичный режим работы linux software raid тоже, однако повторения подобного ой как не хочется. …»
Если нормальный контроллер класса >$200 то он все служебные данные хранит на всех дисках и массив поднимется на любом другом контроллере того-же класса (или выше) того-же вендора. Плюс никто ещё не отменял программные лечилки.
Плюс взрослых контроллеров в том что там XOR считается отдельным чипом (XOR процессор) и абсолютно не грузит центральный проц и проц контроллера вычислениями контрольных сумм для RAID-5/6.
Ещё одним плюсом многих взрослых контроллеров является возможность его администрирования мимо операционки. Контроллеры Areca начиная с 12-портовых версий имеют свой Ethernet порт с Web-конфигуратором. Можно даже настроить оповещения по электронной почте об упавшем диске или каких-либо других событиях.
Плюс взрослых контроллеров в том что там XOR считается отдельным чипом (XOR процессор) и абсолютно не грузит центральный проц и проц контроллера вычислениями контрольных сумм для RAID-5/6.
Ещё одним плюсом многих взрослых контроллеров является возможность его администрирования мимо операционки. Контроллеры Areca начиная с 12-портовых версий имеют свой Ethernet порт с Web-конфигуратором. Можно даже настроить оповещения по электронной почте об упавшем диске или каких-либо других событиях.
Игры разума!
А теперь немного практики.
Итак — скорость чтения это хорошо, но на серьезных серверах большое значение имеет скорость записи.
Скорость записи на RAID-5 составляет от 3/5 до 1/3 от скорости записи RAID0+1
Далее, имеем 3 винта. Если выходит из строя один — все нормально. Но если выходит из строя 2 — то теряем всю информацию однозначно. На RAID0+1 выходит из строя 2 — с высокой долей вероятности (в зависимости от вышедших из строя дисков или контроллера) мы будем иметь нашу информацию в сохранности!!!
Далее — вы пробовали восстанавливать RAID-5 на практике? Многочасовой процесс я вам скажу!
Лично для меня эти факторы и являются теми — по которым я отказываюсь от применения RAID-5. Ну разве что для домашнего сервера для фото, видеофайлов.
А теперь немного практики.
Итак — скорость чтения это хорошо, но на серьезных серверах большое значение имеет скорость записи.
Скорость записи на RAID-5 составляет от 3/5 до 1/3 от скорости записи RAID0+1
Далее, имеем 3 винта. Если выходит из строя один — все нормально. Но если выходит из строя 2 — то теряем всю информацию однозначно. На RAID0+1 выходит из строя 2 — с высокой долей вероятности (в зависимости от вышедших из строя дисков или контроллера) мы будем иметь нашу информацию в сохранности!!!
Далее — вы пробовали восстанавливать RAID-5 на практике? Многочасовой процесс я вам скажу!
Лично для меня эти факторы и являются теми — по которым я отказываюсь от применения RAID-5. Ну разве что для домашнего сервера для фото, видеофайлов.
Вы видели расчёт вероятности в тексте?
Замечания по нему есть?
Тогда не нужно говорить про «высокую долю вероятности». Все доли вероятности, включая бОльшую на стороне RAID-5. Если не согласны, то будьте любезны подтвердить расчётами или указать на ошибку.
Да, я восстанавливал RAID5 — не могу сказать, что сильно медленнее RAID1. А «Многочасовой» это даже если просто 1ТБ скопировать. Уж такие сейчас объёмы пошли.
Замечания по нему есть?
Тогда не нужно говорить про «высокую долю вероятности». Все доли вероятности, включая бОльшую на стороне RAID-5. Если не согласны, то будьте любезны подтвердить расчётами или указать на ошибку.
Да, я восстанавливал RAID5 — не могу сказать, что сильно медленнее RAID1. А «Многочасовой» это даже если просто 1ТБ скопировать. Уж такие сейчас объёмы пошли.
Вы видели расчет вероятности у меня в тексте? По нему замечания есть?
Я на серверном железе восстанавливал RAID5 — мало по времени не показалось.
Я на серверном железе восстанавливал RAID5 — мало по времени не показалось.
Вы о чём? Повторяю — вам всё посчитали. С учётом всего что Вы сказали — «выходит из строя один» и «выходит из строя 2». RAID-5 оказался надёжнее. В чём проблема?
Проблема в том, что если на RAID5 выйдет из строя 2 диска — то информация умрет. Если на RAID1+0 выйдет из строя 2 диска — то информация жива.
А ваш расчет из серии вероятность встретить динозавра 50/50
А ваш расчет из серии вероятность встретить динозавра 50/50
Вероятность того, что к RAID5 умрёт два или три диска МЕНЬШЕ чем вероятность того что в RAID0+1 умрёт два диска с разными данными, три диска или четыре диска. Меньше из-за того, что в RAID5 банально диском меньше.
Вы же мне упрямо твердите, что «если выйдет из строя 2 диска — то информация умрет». А вы посчитайте вероятность, что эти ва диска выйдут из строя! И учтите, что если на RAID0+1 выйдут из строя два диска, то он тоже отлично может умереть.
Вы же мне упрямо твердите, что «если выйдет из строя 2 диска — то информация умрет». А вы посчитайте вероятность, что эти ва диска выйдут из строя! И учтите, что если на RAID0+1 выйдут из строя два диска, то он тоже отлично может умереть.
Хорошо мир, но минус кто-то все таки поставил.
Смотрите в чем получается ньюанс и почему нельзя просто использовать формулу для расчета вероятности.
Вероятность выхода из строя диска выше в RAID0+1 потому что их просто там больше.
Вероятность выхода из строя 2ого диска на RAID1+0 так чтобы информация была невостановима — 1/3. То есть довольно высокий шанс по сравнению с абсолютным нулем у RAID5.
Общая надежность массива нас мало волнует, потому что нас волнует момент первого сбоя, а он будет рано или поздно — это неизбежно.
И сохранность информации зависит только от того выйдет ли из строя второй диск пока не поменян первый.
И в случае с RAID1+0 такой шанс гораздо выше.
Согласен?
Смотрите в чем получается ньюанс и почему нельзя просто использовать формулу для расчета вероятности.
Вероятность выхода из строя диска выше в RAID0+1 потому что их просто там больше.
Вероятность выхода из строя 2ого диска на RAID1+0 так чтобы информация была невостановима — 1/3. То есть довольно высокий шанс по сравнению с абсолютным нулем у RAID5.
Общая надежность массива нас мало волнует, потому что нас волнует момент первого сбоя, а он будет рано или поздно — это неизбежно.
И сохранность информации зависит только от того выйдет ли из строя второй диск пока не поменян первый.
И в случае с RAID1+0 такой шанс гораздо выше.
Согласен?
Прошу прощеня что вмешался в дискуссию, но хотел бы обратить внимание на тезис:
Я могу строить массив из 4 дисков. Как raid5 так и raid10.
Меньше из-за того, что в RAID5 банально диском меньше.
Я могу строить массив из 4 дисков. Как raid5 так и raid10.
Корректно, и если сравнивать надежность массивов из 4х дисков, то здесь RAID5 проигрывает по всем параметрам.
У него так и остается выход из строя только одного диска возможен без потери информации.
Хотя в случае с RAID1+0 ситуация немного лучше, приходится молиться чтобы если диск второй и сгорел то это не был не тот диск который понесет уничтожение всей инфорамации в массиве. И хотя вероятность здесь всего 1/3 что такое случится, все равно это довольно большой процент.
У него так и остается выход из строя только одного диска возможен без потери информации.
Хотя в случае с RAID1+0 ситуация немного лучше, приходится молиться чтобы если диск второй и сгорел то это не был не тот диск который понесет уничтожение всей инфорамации в массиве. И хотя вероятность здесь всего 1/3 что такое случится, все равно это довольно большой процент.
Кроме того в той статье на которую вы написали ответ описана проблема:
Вот вставлены диски у вас из одной партии — и выийти из строя они могут примерно одновременно. И что во время ребилда неистово молиться богам рейда, чтобы не вышел из строя еще один винт?
Дело в том, и это надо себе трезво уяснить, что на время ребилда RAID-5 вы остаетесь не просто с RAID лишенным отказоустойчивости. Вы получаете на все время ребилда RAID-0, надежность и отказоустойчивость которого меньше надежности и отказоустойчивости одного диска в n раз, где n — это количество дисков в группе.
Вот вставлены диски у вас из одной партии — и выийти из строя они могут примерно одновременно. И что во время ребилда неистово молиться богам рейда, чтобы не вышел из строя еще один винт?
Не кажется ли вам, что вы путаете RAID-0+1 с RAID-10?
Для массива RAID-0+1 выход из строя двух дисков фатален, если они находятся в разных страйпах.
Для массива RAID-10 выход из строя двух дисков фатален, если они принадлежат одному зеркалу.
Причём, в случае RAID-0+1 при выходе из строя одного диска мы получаем неработающий страйп и, соответственно, простаивающий живой диск в этом страйпе, а сам массив превращается в RAID-0 из двух дисков.
В случае RAID-10 при выходе из строя одного диска получаем одно всё же работающее зеркало, которое, тем не менее, находится в критическом состоянии, но массив превращается в RAID-0: из одного всё ещё живого диска и второго целого зеркала. В RAID-0+1 нагрузка на винчестеры поднимается от 25% до 50%, а в RAID-10 нагрузка так же поднимается только для одного винчестера — из разбитого зеркала. Так что шансы инфы на выживание в RAID-10 выше, чем в RAID-0+1.
Для массива RAID-0+1 выход из строя двух дисков фатален, если они находятся в разных страйпах.
Для массива RAID-10 выход из строя двух дисков фатален, если они принадлежат одному зеркалу.
Причём, в случае RAID-0+1 при выходе из строя одного диска мы получаем неработающий страйп и, соответственно, простаивающий живой диск в этом страйпе, а сам массив превращается в RAID-0 из двух дисков.
В случае RAID-10 при выходе из строя одного диска получаем одно всё же работающее зеркало, которое, тем не менее, находится в критическом состоянии, но массив превращается в RAID-0: из одного всё ещё живого диска и второго целого зеркала. В RAID-0+1 нагрузка на винчестеры поднимается от 25% до 50%, а в RAID-10 нагрузка так же поднимается только для одного винчестера — из разбитого зеркала. Так что шансы инфы на выживание в RAID-10 выше, чем в RAID-0+1.
UFO just landed and posted this here
В карму нагадить лучший аргумент. Удачи вам!
Прощаюсь
Прощаюсь
> значит отказ двух любых накопителей ведёт к потере данных
у нас вышли из строя 2 диска (Seagate) в RAID10 из 4х, нам повезло информацию не потеряли и массив после замены дисков вернулся в состояние OPTIMAL (контроллер Adapteс 3405)
сначала сломался один, спустя неделю подобрали замену, заменили и буквально еще через несколько минут выпал еще один (ребилд еще не успел начаться)
у нас вышли из строя 2 диска (Seagate) в RAID10 из 4х, нам повезло информацию не потеряли и массив после замены дисков вернулся в состояние OPTIMAL (контроллер Adapteс 3405)
сначала сломался один, спустя неделю подобрали замену, заменили и буквально еще через несколько минут выпал еще один (ребилд еще не успел начаться)
Ну, знаете ли… Неделю без резерва работать это не пять часов массив восстанавливать :)
резерв в виде бэкапов естественно есть
время поиска замены зависит от поставщика сервера
я работал с разными поставщиками, везде замена серверных
комплектующих не мгновенно происходит.
время поиска замены зависит от поставщика сервера
я работал с разными поставщиками, везде замена серверных
комплектующих не мгновенно происходит.
Хочу еще добавить при восстановлении массива здорово помогли инженеры Adaptec-а. Не ожидал такой теплой, искренней и профессиональной поддержки
не часто приходится заниматься всякими ребилдами, ресканами, хотспэрам и их помощь была очень полезна… когда одно лишнее движение и все к чертовой матери :)
не часто приходится заниматься всякими ребилдами, ресканами, хотспэрам и их помощь была очень полезна… когда одно лишнее движение и все к чертовой матери :)
народ надо определятся, если хотите быстро и надежно, то получится дорого. Например Raid50 или 60.
Но опять же, лично я с данными параноик, и как мнимум и у backup должен быть backup =)
Но опять же, лично я с данными параноик, и как мнимум и у backup должен быть backup =)
Предпочитаю файло помойки организации ставить два сервера (основной, резервный) с raid-5:
а) Если под windows — и включенным теневым копированием на обоих, второй с первым синхронизируется по сети с помощью robocopy, по часам, 2 раза в сутки (в обед и в полночь).
б) Если под linux — drbd, хорошей замены теневому копированию пока не нашел (пока присматриваюсь к btrfs и nilfs2).
а) Если под windows — и включенным теневым копированием на обоих, второй с первым синхронизируется по сети с помощью robocopy, по часам, 2 раза в сутки (в обед и в полночь).
б) Если под linux — drbd, хорошей замены теневому копированию пока не нашел (пока присматриваюсь к btrfs и nilfs2).
UFO just landed and posted this here
Отказ жёсткого диска вообще вещь маловероятная. Но весь смысл RAID сводится к снижению этой вероятности. И RAID5 с этой задачей справляется лучше.
UFO just landed and posted this here
Это если он дома стоит. А если двадцать систем на сто жёстких дисков в проекте на пол-миллиарда, то уверяю, что эта разница становится весьма заметной и ощутимой.
Грубо говоря разница в вероятностях больше чем вероятность выхода из строя двух жёстких дисков.
Можно провести такой мысленный эксперимент — мысленно выбрать (назначить) два любых жёстких диска. Если через год они оба сдохнут, то и наша система сдохнет. Лично для меня такая вероятность сильно отлична от ноля.
Грубо говоря разница в вероятностях больше чем вероятность выхода из строя двух жёстких дисков.
Можно провести такой мысленный эксперимент — мысленно выбрать (назначить) два любых жёстких диска. Если через год они оба сдохнут, то и наша система сдохнет. Лично для меня такая вероятность сильно отлична от ноля.
А если двадцать систем на сто жёстких дисков в проекте на пол-миллиардаВ этом случае, скорее всего, дешевле и надёжнее окажется не RAID, а что-то вроде «серверов» гугла.
Требования по надёжности не всегда позволяют — снижается надёжность к множественным отказам. Иногда лучше поставить 20 серверов со своими RAID и ИБП, чем один супер-пупер резервированный (в разумных пределах). Например, это справедливо для случая, когда сервера могут разделять общую нагрузку и т.п.
Вы вообще о чём? У гугла как раз мелкие дешёвые сервера. В каждом по два IDE винта, и я пока не могу найти информацию о том, используют ли они вообще RAID. Но если и используют, то скорее всего исключительно для ускорения, а не для надёжности.
ИМХО отказ жесткого диска — одна из самых вероятных вещей, которые могут случится с сервером. А смысл RAID в первую очередь — позволить серверу остаться «на ходу» после такого сбоя, и во вторую — получить нужную производительность дисковой подсистемы не покупаю диски за X килобаксов. Короче Redundant Array of Inexpensive Disks
UFO just landed and posted this here
а можно пояснить вот эту формулу?
4n^2+3n^3+n^4
у меня расчеты такие: пусть P вероятность отказа 1 диска, тогда С — вероятность нормальной работы (надежность)
очевидно что Р=1-С, тогда для надежность RAID0=C*C=(1-P)*(1-P), тогда вероятность отказа RAID0=1-(1-P)*(1-P)
таким образом, вероятность отказа RAID0+1=(1-(1-P)*(1-P))*(1-(1-P)*(1-P))
если допустить что вероятность отказа 1 диска 0.01, то по моей формуле вероятность отказа RAID0+1 0,00039601
а по вашей 0,00040301
4n^2+3n^3+n^4
у меня расчеты такие: пусть P вероятность отказа 1 диска, тогда С — вероятность нормальной работы (надежность)
очевидно что Р=1-С, тогда для надежность RAID0=C*C=(1-P)*(1-P), тогда вероятность отказа RAID0=1-(1-P)*(1-P)
таким образом, вероятность отказа RAID0+1=(1-(1-P)*(1-P))*(1-(1-P)*(1-P))
если допустить что вероятность отказа 1 диска 0.01, то по моей формуле вероятность отказа RAID0+1 0,00039601
а по вашей 0,00040301
Я считал, что отказом RAID0+1 является отказ четырёх дисков, трёх дисков, или двух дисков с одними и теме же данными.
P=C(2,4)*n^2+C(3,4)*n^3+C(4,4)*n^4 — 2*n^2.
Где C(a,b) кол-во сочетаний по a из b.
Последнее вычитаемое значение компенсирует случай, когда отказали два диска с различными данным.
P=C(2,4)*n^2+C(3,4)*n^3+C(4,4)*n^4 — 2*n^2.
Где C(a,b) кол-во сочетаний по a из b.
Последнее вычитаемое значение компенсирует случай, когда отказали два диска с различными данным.
вероятность отказа raid 10 из 4 дисков равна 2n^2+3n^3+n^4, а не 4n^2+3n^3+n^4
вероятно Вы забыли учесть, что нужно вычитать 4*n^2, а не 2*n^2. То есть в 4 случаях из 6 при вылете 2 дисков данные сохраняются в рейд 10
и тогда вероятность отказа рейд 10 (2n^2+3n^3+n^4) ниже вероятности отказа рейд 5 из 3 дисков (3n^2+n^3) почти в 1,5 раза
не холивара ради, а точности расчетов для.
p.s. raid X холивар. ппц.
вероятно Вы забыли учесть, что нужно вычитать 4*n^2, а не 2*n^2. То есть в 4 случаях из 6 при вылете 2 дисков данные сохраняются в рейд 10
и тогда вероятность отказа рейд 10 (2n^2+3n^3+n^4) ниже вероятности отказа рейд 5 из 3 дисков (3n^2+n^3) почти в 1,5 раза
не холивара ради, а точности расчетов для.
p.s. raid X холивар. ппц.
почему? RAID0+1 только два варианта выхода из строя двух дисков не приводит к потере всего массива. Всего есть 6 вариантов выхода из строя двух дисков.
из 6 возможных вариантов есть только 2 варианта, что сломаются те самые 2 диска, на которых содержатся одинаковые данные и 4 варианта, что сломаются диски, на которых разные данные.
на пальцах:
есть диски a1, a2, b1 b2
диски с одинаковой буквой содержат одинаковые данные
имеем 6 вариантов поломок из 2 дисков: a1a2, a1b1, a1b2, a2b1 a2b2 b1b2
вариантов, что мы теряем данные(то есть в котором содержаться две одинаковых буквы) только два: a1a2 и b1b2. во всех остальных случаях данные сохраняются.
как-то так.
на пальцах:
есть диски a1, a2, b1 b2
диски с одинаковой буквой содержат одинаковые данные
имеем 6 вариантов поломок из 2 дисков: a1a2, a1b1, a1b2, a2b1 a2b2 b1b2
вариантов, что мы теряем данные(то есть в котором содержаться две одинаковых буквы) только два: a1a2 и b1b2. во всех остальных случаях данные сохраняются.
как-то так.
Это ещё что… Вот если положить n->1, то вероятности отказа рейдов получаются значительно больше 1, что совсем никуда не годится ;)
Raid5 + spare наше всё.
Негодится.
Представляем, выходит из строя один винт, пока его содержимое восстанавливается на spare, выходит из строя еще один.
Ресурс винтов примерно одинаков, условия работы тоже, поэтому вполне возможен, да так и случается выход из строя одного винта за другим.
И в этом случае наш RAID5+spare не спасает.
Какая жаль!
Впрочем и у RAID1+0 шансы на спасение составят более 66%, ну и плюс быстрее spare диск восстановится, что тоже дает форы.
Представляем, выходит из строя один винт, пока его содержимое восстанавливается на spare, выходит из строя еще один.
Ресурс винтов примерно одинаков, условия работы тоже, поэтому вполне возможен, да так и случается выход из строя одного винта за другим.
И в этом случае наш RAID5+spare не спасает.
Какая жаль!
Впрочем и у RAID1+0 шансы на спасение составят более 66%, ну и плюс быстрее spare диск восстановится, что тоже дает форы.
Слушайте, а я вот как-то выпал из жизни — куда и чем нынче делают резервные копии терабайтных винтов? Я тут отснятое видеокамерой забекапил — заняло полную ночь, 120 Гб.
UFO just landed and posted this here
UFO just landed and posted this here
Вообще использовать вероятность отказа в такой задаче — вообще не правильно.
Нужно использовать интенсивность отказов. Т.е. предел отношения вероятности отказа за промежуток времени к этому промежутку времени, при стремлении его к нулю.
Для рейд 1+0 эта величина будет в 4 раза больше чем у одного жесткого диска,
для рейд 5 — в 3 раза больше. Но это просто отказ. Выход из строя одного из дисков не влечёт за собой потерю данных.
Про потерю данных надо считать более углублённо, а это лениво, да и для рейда 1+0 кажется мне довольно трудоёмкой задачей.
А если ещё глубже думать — то с увеличением наработки интенсивность отказов одного харда растёт. В массиве все харды нагружены примерно одинаково, а значит вполне возможно, что за короткий промежуток времени произойдёт отказ 2х жёстких дисков.
Нужно использовать интенсивность отказов. Т.е. предел отношения вероятности отказа за промежуток времени к этому промежутку времени, при стремлении его к нулю.
Для рейд 1+0 эта величина будет в 4 раза больше чем у одного жесткого диска,
для рейд 5 — в 3 раза больше. Но это просто отказ. Выход из строя одного из дисков не влечёт за собой потерю данных.
Про потерю данных надо считать более углублённо, а это лениво, да и для рейда 1+0 кажется мне довольно трудоёмкой задачей.
А если ещё глубже думать — то с увеличением наработки интенсивность отказов одного харда растёт. В массиве все харды нагружены примерно одинаково, а значит вполне возможно, что за короткий промежуток времени произойдёт отказ 2х жёстких дисков.
UFO just landed and posted this here
проведите
а откуда n^4?
Пусть p — вероятность норм. работы 1 хдд => q=1-p -вер-ть отказа
P(Raid0) = P*P => Q(Raid0) = 1-p^2
Q(Raid0+1) = (1-p^2)^2 = (1-(1-q)^2)^2=(q(q-2))^2=(q^2)*(q^2-4*q+4)=q^4 — 4*q^3 + 4*q^2
Пусть p — вероятность норм. работы 1 хдд => q=1-p -вер-ть отказа
P(Raid0) = P*P => Q(Raid0) = 1-p^2
Q(Raid0+1) = (1-p^2)^2 = (1-(1-q)^2)^2=(q(q-2))^2=(q^2)*(q^2-4*q+4)=q^4 — 4*q^3 + 4*q^2
но вообще так конечно считать нельзя, зачем заново открывать велосипед, если есть вполне себе сформированная наука о надежности автоматических устройств, с идеально подведенной математической базой?
У Вас ошибочные рассуждения во второй строке. Вы считаете вероятность отказа raid0+1 как вероятность одновременного отказа двух raid0, а это неверно. В первом рейд0 может сломаться первый диск, а втором — второй. Тогда, следуя Вашим рассуждениям, получается, что весь массив отказал, но на деле это не так. Думаю, ясно почему.
Ответ 2n^2 — n^4 правильный. Массив raid0+1 выходит из строя тогда, когда ломаются два соответствующих диска. Пусть массив состоит из четырёх дисков A, B, C и D, причем B является зеркалом A, а D — зеркалом C.
Тогда возможны следующие ситуации отказа:
1) отказали оба диска A и B
2) отказали оба диска C и D.
И первый, и второй случай происходят с вероятностью n^2. Однако складывать вероятности тут нельзя, потому что эти два события пересекаются. Приведем их к не пересекающемуся виду:
1) отказали оба диска A и B
2) событие 1 не произошло, однако отказали сразу C и D
Итак, вероятность первого события есть n^2, второго — (1 — n^2)*n^2 = n^2 — n^4. Так как события не пересекаются, их вероятности можно сложить, и получим ровно 2n^2 — n^4.
Ответ 2n^2 — n^4 правильный. Массив raid0+1 выходит из строя тогда, когда ломаются два соответствующих диска. Пусть массив состоит из четырёх дисков A, B, C и D, причем B является зеркалом A, а D — зеркалом C.
Тогда возможны следующие ситуации отказа:
1) отказали оба диска A и B
2) отказали оба диска C и D.
И первый, и второй случай происходят с вероятностью n^2. Однако складывать вероятности тут нельзя, потому что эти два события пересекаются. Приведем их к не пересекающемуся виду:
1) отказали оба диска A и B
2) событие 1 не произошло, однако отказали сразу C и D
Итак, вероятность первого события есть n^2, второго — (1 — n^2)*n^2 = n^2 — n^4. Так как события не пересекаются, их вероятности можно сложить, и получим ровно 2n^2 — n^4.
UFO just landed and posted this here
Провел бы!
Мы б поучились!
Мы б поучились!
UFO just landed and posted this here
UFO just landed and posted this here
расцеловал в карму!
Не делая ошибок ничему не научишься…
Ну… «Хабрахабр, сэээр!» :)
С другой стороны радуе что тема вообще поднялась, и заставила людей задуматься.
С другой стороны радуе что тема вообще поднялась, и заставила людей задуматься.
Люди доверчивы. Поправил. Грубых ошибок теперь вроде нет.
Вот постоянно показывают цифры, говорят, что вероятность выхода из строя дисков и потери всех данных постоянно растёт (это я больше по предыдущему топику «must die»). Отчасти я согласен с этими данными, но только отчасти. В теории все эти цифры верные, но насколько они относятся к реальности? Например имеем четыре диска, вероятность сбоя в четыре раза больше чем если бы у нас был один диск. НО! Допустим, что один диск проработает стабильно при не очень сильной нагрузке два года. Это же не значит, что при четырёх дисках один из них сломается через полгода (вероятность в четыре раза больше).
Это неправильный подход к обсуждаемой проблеме, но при подсчёте вероятностей надо учитывать и этот факт тоже. Т.е. (если очень грубо) мы так же продолжаем зависеть от одного диска, этот один диск (в массиве) проработает столько же, сколько бы проработал если бы работал один, а может и дольше, так как данные распределяются по нескольким дискам, но при этом при его отказе у нас есть шанс восстановить все данные без потерь. Что получается в итоге — в «массивах» растёт и скорость и надёжность, но при этом в цифрах надёжность только ухудшается…
В общем цифры — это хорошо, и я со многими согласен, но цифры эти означают немного другое. Так как обсуждаются программные массивы (и в статье и в комментах), а не только аппаратные, значит по большому счёту речь идёт о домашних «файлопомойках»… и тут уже тем более кроме теории с процентами будет совсем не бесполезным расчёт в других единицах измерения — деньги, время, объём данных, скорость…
Это неправильный подход к обсуждаемой проблеме, но при подсчёте вероятностей надо учитывать и этот факт тоже. Т.е. (если очень грубо) мы так же продолжаем зависеть от одного диска, этот один диск (в массиве) проработает столько же, сколько бы проработал если бы работал один, а может и дольше, так как данные распределяются по нескольким дискам, но при этом при его отказе у нас есть шанс восстановить все данные без потерь. Что получается в итоге — в «массивах» растёт и скорость и надёжность, но при этом в цифрах надёжность только ухудшается…
В общем цифры — это хорошо, и я со многими согласен, но цифры эти означают немного другое. Так как обсуждаются программные массивы (и в статье и в комментах), а не только аппаратные, значит по большому счёту речь идёт о домашних «файлопомойках»… и тут уже тем более кроме теории с процентами будет совсем не бесполезным расчёт в других единицах измерения — деньги, время, объём данных, скорость…
От надёжности одного диска никуда не деться. И чем сложней система — тем больше в ней вероятность чему-то сломаться. Но при этом потери данных в массивах уменьшается
> Так как обсуждаются программные массивы (и в статье и в комментах), а не только аппаратные
Почему вы так решили?
Все сказанное равно относится и к «аппаратным», и к «программным» RAID-контроллерам.
Собственно вся разница между ними в том, что программа обработки данных для RAID в первом случае выполняется отдельным подпроцессором, а во втором — работает как задача на общем процессоре системы, и только.
Почему вы так решили?
Все сказанное равно относится и к «аппаратным», и к «программным» RAID-контроллерам.
Собственно вся разница между ними в том, что программа обработки данных для RAID в первом случае выполняется отдельным подпроцессором, а во втором — работает как задача на общем процессоре системы, и только.
Я не утверждал, что речь в топике идёт только о «программных массивах», Вы меня не правильно поняли. Основные различия между программным и аппаратным контроллером мне известны. Кроме указанной Вами разницы есть ещё достаточно ощутимая разница в скорости/качестве работы и цене, именно поэтому я и предположил, что статья подразумевает не только корпоративное применение «массивов».
>> Вердикт прост — если не нужны лишние проблемы на ровном месте, то не нужно городить ни RAID1 ни RAID0+1 — нужно смотреть в сторону RAID5, 5E, 6, ZFS
Да что же это творится такое??? Друзья, коллеги, да это же бред полнейший!
Завтра эту статью прочитает человек, ответственный, скажем, за СХОД, убьет 0+1-рейд, перейдет на пятый, а вдруг что случится и тот навернется, думайте же что пишете на подобном ресурсе.
Ну откуда такой бредовый пост набрал такое количество положительных отзывов??
Да что же это творится такое??? Друзья, коллеги, да это же бред полнейший!
Завтра эту статью прочитает человек, ответственный, скажем, за СХОД, убьет 0+1-рейд, перейдет на пятый, а вдруг что случится и тот навернется, думайте же что пишете на подобном ресурсе.
Ну откуда такой бредовый пост набрал такое количество положительных отзывов??
ждем продолжение линейки статей про рейд —
«RAID 10 или 10 способов убить винты»
«Занимательная теория вероятности. RAID 0, 1, 5, 6, 10 — я иду искать»
а также «FAT или файловая система-панацея»
«RAID 10 или 10 способов убить винты»
«Занимательная теория вероятности. RAID 0, 1, 5, 6, 10 — я иду искать»
а также «FAT или файловая система-панацея»
Сравнение не верное, подсчеты не корректны, пост честно говоря — шлак, а вот коментарии гораздо поучительнее. Позабавило, что в выводах замалчивается скорость записи, кто поднимал СУБД или почтовые системы на 5-м а потом на 10-м рейдах меня поймет :)
Ага, одна из основных причин RAID — это повышения количества IOPS на одном разделе. Как никогда актуально для СУБД и почты. А сохранность данных должен обеспечивать бекап, а не массив.
Причем тут бэкапы? мы о сохранности вообще не говорим, а отказоустойчивость дает и простое зеркало, а вот 10-й в отличии от mirror'а дает еще и большую ёмкость с достаточной производительностью, 5-й только может похвастать только ёмкостью. В эпоху терабайтных дисков расходы на лишнее место — это копейки, а вот IOPS очень даже важный показатель, хотя конечно если мылить уровнем «домашней файлопомойки» то Raid5 вполне себя оправдывает.
Из жизни: Простейший 10-й рейд собранный на 2-х Xeon (HP DL380) вытянул более 12к почтовых ящиков именно благодаря скорости, в отличии от 5-го, который просел на запись, одни и теже диски, одно железо, а функцию не выполняет, кроме как места стало больше.
Из жизни: Простейший 10-й рейд собранный на 2-х Xeon (HP DL380) вытянул более 12к почтовых ящиков именно благодаря скорости, в отличии от 5-го, который просел на запись, одни и теже диски, одно железо, а функцию не выполняет, кроме как места стало больше.
УЧИТЕ ТЕРВЕР!!!
+1 Волосы на голове дыбом от таких выкладок. Даже если не учитывать спорность исходных посылок.
А о них хотелось бы сказать:
НЕЛЬЗЯ считать выход из строя дисков в массиве независимыми событиями.
Выход из строя 1 диска сразу дает большую нагрузку на остальные.
При расчете вероятности выхода из строя 2-го и последующих дисков нужно учитывать время, которое массив проводит в degraded режиме. Если вы вовремя будете заменять диски, или держать hot spare — это намного понижает вероятность сбоя, чем если вы узнаете о сбое первого диска только после второго сбоя и мертвого массива.
А о них хотелось бы сказать:
НЕЛЬЗЯ считать выход из строя дисков в массиве независимыми событиями.
Выход из строя 1 диска сразу дает большую нагрузку на остальные.
При расчете вероятности выхода из строя 2-го и последующих дисков нужно учитывать время, которое массив проводит в degraded режиме. Если вы вовремя будете заменять диски, или держать hot spare — это намного понижает вероятность сбоя, чем если вы узнаете о сбое первого диска только после второго сбоя и мертвого массива.
виноват — поправил. результат не изменился.
поправили с ошибками: RAID 10 is a stripe of mirrors. это означает что их 6 случаев когда выходят из строя 2 диска, только в 2х мы теряем данные, когда оба диска на одном и том же зеркале. (а не в 4х из 6, как с raid0+1)
p10 = P(raid10) = 2p^2 — p^4
p5 = P(raid5) = 3p^2 — 2p^3
p5 — p10 = p^2( (3 — 2p) — (2-p^2) ) = p^2(p^2 — 2p +1) = p^2(p-1)^2 — величина неотрицательная при любых p.
Вывод: RAID10 дает меньшую вероятность полной потери данных чем RAID5, при условии что используем 4 диска и 3 соответсвенно.
другой вопрос что так мерять вероятность отказа смысла нету совсем. но даже если предположить что есть, ваши выкладки ничего не доказывают.
p.s. и максимальная (теоритическая) скорость чтения у raid10 будет такая же как у суммы скоростей всех дисков, а не половина, потому что зеркало при чтении тоже распараллеливает.
p10 = P(raid10) = 2p^2 — p^4
p5 = P(raid5) = 3p^2 — 2p^3
p5 — p10 = p^2( (3 — 2p) — (2-p^2) ) = p^2(p^2 — 2p +1) = p^2(p-1)^2 — величина неотрицательная при любых p.
Вывод: RAID10 дает меньшую вероятность полной потери данных чем RAID5, при условии что используем 4 диска и 3 соответсвенно.
другой вопрос что так мерять вероятность отказа смысла нету совсем. но даже если предположить что есть, ваши выкладки ничего не доказывают.
p.s. и максимальная (теоритическая) скорость чтения у raid10 будет такая же как у суммы скоростей всех дисков, а не половина, потому что зеркало при чтении тоже распараллеливает.
Виноват — выучил.
UFO just landed and posted this here
>> Итак — RAID0+1:
>> когда контроллер реализует RAID1+0 как единую матрицу и умеет комбинировать накопители произвольным образом)
Похоже автор вообще не особо различает RAID 10 и RAID 0+1.
>> когда контроллер реализует RAID1+0 как единую матрицу и умеет комбинировать накопители произвольным образом)
Похоже автор вообще не особо различает RAID 10 и RAID 0+1.
Если мы допускаем, что в случае отказа контроллер может комбинировать накопители произвольным образом, то «RAID0+1» эквивалентен «RAID1+0». Но правильным было бы конечно писать RAID10 — поправил в тексте.
UFO just landed and posted this here
Любопытно, что все кинулись обсуждать очередного «сферического коня в вакууме», забыв про реальные задачи — а именно, зачем вообще нужен RAID?
Как известно, сохранность данных RAID не гарантирует вообще, никакой. Программные сбои, вирусы под виндой и «ашипка одмина» rm -rf / под линухом могут грохнуть все данные — RAID может разве что ускорить выполнение этой операции, чтобы уничтожение данных прошло как можно быстрее и незаметнее. :)
Реально RAID может:
С первым случаем всё просто — вариант RAID-а выбирается исходя из потребностей по скорости чтения/записи.
Второй случай — когда действительно очень важно избежать перебоя в работе (в реальности он встречается так часто, как хотелось бы). И в этом случае RAID не спасает — выйти из строя может любое железо, поэтому нужен полноценный резервный сервер с полной копией всех актуальных данных. А если резервного сервера нет, то RAID может только дать шанс, что простоя удастся избежать.
Разница в этом шансе между разными вариантами RAID достаточно незначительна, чтобы её имело смысл учитывать. Судя по накопленной статистике, из сообщений админов о сбоях RAID в разных maillist-ах, гораздо большее значение имеют такие факторы, как использование разных или одинаковых моделей винтов в RAID и личный lucky skill админа. Кроме того, есть ещё один момент, который надо учитывать при расчёте вероятностей в этом случае — возможность реально продолжать работу сервера после замены вышедшего из строя винта — некоторые варианты RAID дико тормозят систему пока пересоздают массив инициализируя новый винт, и фактически всё это время сервер нормально работать не может и перебоя в работе избежать не удаётся.
Третий случай, пожалуй, действительно лучше всего решается некоторыми вариантами RAID. Но и в этом случае факторы использования разных/одинаковых винтов и lucky админа по-прежнему влияют на выживание данных сильнее, чем различия между вариантами RAID. И, в любом случае, шанс всегда остаётся шансом — это не гарантия. И незначительные отличия в этом шансе не являются определяющими при выборе варианта RAID-а.
Резюмируя: реально RAID стоит использовать только тогда, когда необходимо намного ускорить чтение и/или запись данных на винт. В качестве побочного эффекта вы можете получить незначительное уменьшение или увеличение надёжности хранения данных, которое в абсолютном большинстве случаев можно игнорировать. В качестве исключения, стоит иметь в виду, что если вы делаете RAID 0, да на много винтов, да ещё используя одинаковые модели винтов, то вам придётся восстанавливать все данные из бэкапов чаще, чем вы бы того хотели.
Как известно, сохранность данных RAID не гарантирует вообще, никакой. Программные сбои, вирусы под виндой и «ашипка одмина» rm -rf / под линухом могут грохнуть все данные — RAID может разве что ускорить выполнение этой операции, чтобы уничтожение данных прошло как можно быстрее и незаметнее. :)
Реально RAID может:
- 1) изменить скорость работы с дисками (напр. сильно ускорить чтения и немного замедлить запись — варианты есть разные, поэтому и пишу «изменить», а не «ускорить»)
- 2) предоставить шанс на горячую (или просто быструю) замену вышедшего из строя винта(ов), чтобы избежать длительного перебоя в работе, пока данные восстанавливаются из бэкапа
- 3) предоставить шанс избежать потери самых последних данных, которых ещё нет в бэкапе
С первым случаем всё просто — вариант RAID-а выбирается исходя из потребностей по скорости чтения/записи.
Второй случай — когда действительно очень важно избежать перебоя в работе (в реальности он встречается так часто, как хотелось бы). И в этом случае RAID не спасает — выйти из строя может любое железо, поэтому нужен полноценный резервный сервер с полной копией всех актуальных данных. А если резервного сервера нет, то RAID может только дать шанс, что простоя удастся избежать.
Разница в этом шансе между разными вариантами RAID достаточно незначительна, чтобы её имело смысл учитывать. Судя по накопленной статистике, из сообщений админов о сбоях RAID в разных maillist-ах, гораздо большее значение имеют такие факторы, как использование разных или одинаковых моделей винтов в RAID и личный lucky skill админа. Кроме того, есть ещё один момент, который надо учитывать при расчёте вероятностей в этом случае — возможность реально продолжать работу сервера после замены вышедшего из строя винта — некоторые варианты RAID дико тормозят систему пока пересоздают массив инициализируя новый винт, и фактически всё это время сервер нормально работать не может и перебоя в работе избежать не удаётся.
Третий случай, пожалуй, действительно лучше всего решается некоторыми вариантами RAID. Но и в этом случае факторы использования разных/одинаковых винтов и lucky админа по-прежнему влияют на выживание данных сильнее, чем различия между вариантами RAID. И, в любом случае, шанс всегда остаётся шансом — это не гарантия. И незначительные отличия в этом шансе не являются определяющими при выборе варианта RAID-а.
Резюмируя: реально RAID стоит использовать только тогда, когда необходимо намного ускорить чтение и/или запись данных на винт. В качестве побочного эффекта вы можете получить незначительное уменьшение или увеличение надёжности хранения данных, которое в абсолютном большинстве случаев можно игнорировать. В качестве исключения, стоит иметь в виду, что если вы делаете RAID 0, да на много винтов, да ещё используя одинаковые модели винтов, то вам придётся восстанавливать все данные из бэкапов чаще, чем вы бы того хотели.
стоит иметь в виду, что если вы делаете RAID 0, да на много винтов, да ещё используя одинаковые модели винтов, то вам придётся восстанавливать все данные из бэкапов чаще, чем вы бы того хотели.Боюсь себе представить адитивный Zpool на нескольких винчестерах без объединений устройств верхнего уровня (mirror, raidz*, hot-spare), но, чёрт возьми, кому-то действительно важна скорость за дешёвые деньги… :)
реально RAID стоит использовать только тогда, когда необходимо намного ускорить чтение и/или запись данных на винт.Что можно сделать из двух-четырёх почти одинаковых винчестеров? Для начала их лучше разбить на разделы, а уже сами разделы нужно комбинировать в тот или иной тип массива RAID (-1, -10, -3, -5, -6).
В этом вся соль предоставляемых решений.
хмм, зато raid1 дает нам одноразовый снэпшот :) я когда проводил массовый апдейт и оптимизацию боего сервера на всякий случай один из винтов вытащил, чтобы если косяк потом его использовать для всотановления системы :)
Мне кажется корректной такая постановка задачи: у меня есть N дисков. Какая схема работы даст мне наилучшее соотношение скорость/поломка?
Рассмотреть для примера один случай с 10-ю дисками.
Спасибо за интересную полемику между статьями.
Успехов.
Рассмотреть для примера один случай с 10-ю дисками.
Спасибо за интересную полемику между статьями.
Успехов.
Sign up to leave a comment.
Почему RAID5 — «must have»?