Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 222
Спасибо! Отличная статья.
Ясно, подробно, со ссылками.
Ясно, подробно, со ссылками.
У RAID-10 есть одна маааленькая проблема, его нельзя увеличить в размере докинув 1-2 веника :-)
Если рейд через mdadm — то скоростью ребилда можно управлять, и мой 2Тб Raid-5 массив перестраивается за 2.5 часа.
BER — указывается производителями для чтения секторов, а не бит.
Ну и конечно, RAID-6 рулит, через 0.5-1 год когда буду расширять массив, будет 4Тб Raid-6.
О bad-блоке в cold-данных во время ребилда узнавать не приходится, во всех современных вениках есть offline surface scan, и блок reallocated даже если вы его не читаете как только на нем будет увеличение ошибок чтения, без потери данных.
Если рейд через mdadm — то скоростью ребилда можно управлять, и мой 2Тб Raid-5 массив перестраивается за 2.5 часа.
BER — указывается производителями для чтения секторов, а не бит.
Ну и конечно, RAID-6 рулит, через 0.5-1 год когда буду расширять массив, будет 4Тб Raid-6.
О bad-блоке в cold-данных во время ребилда узнавать не приходится, во всех современных вениках есть offline surface scan, и блок reallocated даже если вы его не читаете как только на нем будет увеличение ошибок чтения, без потери данных.
Да и RAID-5 тоже не вот прямо легко добить дисками! :)
Про «enlarge your raid»: В последних ядра (с 2.6.28 по 2.6.31) в линуксе починили древнее позорище — теперь при использовании LVM есть честные barriers, которые доходят до железа. То есть, использование LVM стало осмысленным, а не просто, потому, что это модно, или «как у взрослых». То есть, если смотреть на софтверный RAID-10, то можно сделать кучку из RAID-1, которые слеплены в единое пространство через LVM. Плюс LVM дает огромную гибкость в управлении разделами, и самое приятное — snapshots, возможность сохранять и бекапить точный образ раздела на какой-то момент времени.
Я попробовал… и подсел :) Реализовал у себя на сервере такую стему (RAID-1 * X + LVM).
Про «enlarge your raid»: В последних ядра (с 2.6.28 по 2.6.31) в линуксе починили древнее позорище — теперь при использовании LVM есть честные barriers, которые доходят до железа. То есть, использование LVM стало осмысленным, а не просто, потому, что это модно, или «как у взрослых». То есть, если смотреть на софтверный RAID-10, то можно сделать кучку из RAID-1, которые слеплены в единое пространство через LVM. Плюс LVM дает огромную гибкость в управлении разделами, и самое приятное — snapshots, возможность сохранять и бекапить точный образ раздела на какой-то момент времени.
Я попробовал… и подсел :) Реализовал у себя на сервере такую стему (RAID-1 * X + LVM).
RAID — это инструмент и как всякий инструмент его надо уметь использовать. Например, под файлопомойки — RAID5 самое оно.
А что до ребилда — то обязательно надо иметь HotSpore диск, на который пойдет автоматический ребилд.
И последнее — RAID бекапов не отменяет. Никакой. Бекапы надо делать всегда и хранить в темном недоступном месте, защищенном от юзверей.
А что до ребилда — то обязательно надо иметь HotSpore диск, на который пойдет автоматический ребилд.
И последнее — RAID бекапов не отменяет. Никакой. Бекапы надо делать всегда и хранить в темном недоступном месте, защищенном от юзверей.
всёже Hot Spare
Hot Spare это только средство сократить до нуля интервал между выходом из строя диска с данными и началом ребилда.
В противном случае ребилд начнется только тогда когда вы руками замените диск в RAID на новый, то может наступить, например утром рабочего дня, или когда такой диск завезут на склад вашего поставщика
Сам ребилд как таковой, HotSpare диск не отменяет и не сокращает.
В противном случае ребилд начнется только тогда когда вы руками замените диск в RAID на новый, то может наступить, например утром рабочего дня, или когда такой диск завезут на склад вашего поставщика
Сам ребилд как таковой, HotSpare диск не отменяет и не сокращает.
странная статья, не понятно для кого
в организации где это важно ставят нормальные рейд контролеры, и проблемы типа:
нет
для домашнего контролера, выпадение одного харда и последующий ребилд тоже не проблема, так как дома уж ради такого можно на денек отказаться от просмотра парнушки и отключить торренты… ;)
Нужно все таки наверно корректно сравнивать рейды разных уровней, так как время ребилда raid10, скажем тоже не равно нулю, а при ошибки в этот момент опасность потери всех данных даже больше чем при ребилде raid5 (если в пятом рейде больше 3 хардов), а производительность raid6 вызывает некоторые сомнения ;)
Скажем так ред5 как был так и остается золотой серединой между рейд10 и рейд6, он надежнее, но менее производителен чем рейд10 + больший полезный объем, производительнее но менее надежен чем рейд6…
Для организаций однозначный выбор сделать сложно, в разных случаях выбор будет на разные рейды, но мое имхо лучше RAID5 для домашнего наса врятли что то есть…
в организации где это важно ставят нормальные рейд контролеры, и проблемы типа:
Большие и «умные» системы хранения обычно постоянно занимаются в секунды простоя так называемым disk scrubbing-ом, постоянно считывая и контролируя характеристики чтения для всего объема дисков. Но уверен, что ваш недорогой «домашний» RAID-контроллер этого не делает.
нет
для домашнего контролера, выпадение одного харда и последующий ребилд тоже не проблема, так как дома уж ради такого можно на денек отказаться от просмотра парнушки и отключить торренты… ;)
Нужно все таки наверно корректно сравнивать рейды разных уровней, так как время ребилда raid10, скажем тоже не равно нулю, а при ошибки в этот момент опасность потери всех данных даже больше чем при ребилде raid5 (если в пятом рейде больше 3 хардов), а производительность raid6 вызывает некоторые сомнения ;)
Скажем так ред5 как был так и остается золотой серединой между рейд10 и рейд6, он надежнее, но менее производителен чем рейд10 + больший полезный объем, производительнее но менее надежен чем рейд6…
Для организаций однозначный выбор сделать сложно, в разных случаях выбор будет на разные рейды, но мое имхо лучше RAID5 для домашнего наса врятли что то есть…
Далеко не все RAID-контроллеры делают скраббинг. Я, к сожалению, не спец по серверным RAID, я по «железным» девайсам спец. Но в статье стремился в эмпиреи железок, которые подавляющее большинство читателей хабра не увидят, не лезть. :)
«Железки» — умеют чекать пространство, они все свободное время этим занимаются, а вот насчет внутренних серверных контроллеров — не уверен.
> для домашнего контролера, выпадение одного харда и последующий ребилд тоже не проблема
Вы невнимательны. Основной посыл статьи как раз в том, что именно «выпадение одного харда и последующий ребилд» для RAID-5 это настоящая проблема, так как вероятность вторичного сбоя при этом возрастает многократно, прежде всего из за конечной надежности чтения массовых винтов (см абзац про BER и его величины).
> так как время ребилда raid10, скажем тоже не равно нулю,
Не равно, но в сотни раз быстрее ребилда RAID-5, так как ребилд RAID-10 происходит со скоростью примерно 100MB/s, скоростью линейного последовательного чтения диска.
И для этого не нужно читать _весь_ массив дисков, как в случае RAID-5.
«Железки» — умеют чекать пространство, они все свободное время этим занимаются, а вот насчет внутренних серверных контроллеров — не уверен.
> для домашнего контролера, выпадение одного харда и последующий ребилд тоже не проблема
Вы невнимательны. Основной посыл статьи как раз в том, что именно «выпадение одного харда и последующий ребилд» для RAID-5 это настоящая проблема, так как вероятность вторичного сбоя при этом возрастает многократно, прежде всего из за конечной надежности чтения массовых винтов (см абзац про BER и его величины).
> так как время ребилда raid10, скажем тоже не равно нулю,
Не равно, но в сотни раз быстрее ребилда RAID-5, так как ребилд RAID-10 происходит со скоростью примерно 100MB/s, скоростью линейного последовательного чтения диска.
И для этого не нужно читать _весь_ массив дисков, как в случае RAID-5.
Боюсь вы малость ошибаетесь.
При ребилде зеркала идет копирование данных с 1 диска, а при ребилде 5-го рейда — со всех дисков в массиве. Для считывания 1-4TB указанные BER дают сравнительно небольшую вероятность потери данных.
А для домашнего NAS никто не мешает использовать JBOD. Во всяком случае мат. ожидание потери данных для 4x2TB дисков у него меньше :)
При ребилде зеркала идет копирование данных с 1 диска, а при ребилде 5-го рейда — со всех дисков в массиве. Для считывания 1-4TB указанные BER дают сравнительно небольшую вероятность потери данных.
А для домашнего NAS никто не мешает использовать JBOD. Во всяком случае мат. ожидание потери данных для 4x2TB дисков у него меньше :)
не совсем понял вашу мысль, то есть, мат ожидания потери каких либо данных, на 4х2TB дисков на jbod меньше чем на raid5?
> Даже если при чтении поймали ошибку, то она детектируется и производится повторное чтение и её уже нет.
Вот только как к этой самодеятельности диска отнесется RAID-контроллер?
Я вам скажу — плохо отнесется. Именно поэтому и существуют специальные серии дисков для RAID, отличающиеся от десктопных отключенной «самодеятельностью».
Вот только как к этой самодеятельности диска отнесется RAID-контроллер?
Я вам скажу — плохо отнесется. Именно поэтому и существуют специальные серии дисков для RAID, отличающиеся от десктопных отключенной «самодеятельностью».
Насколько я понял из статьи автора, проблема только косвенно стоит во времени ребилда. А так проблема комплексная и шансы в 22% потерять данные при ребилде не очень воодушевляют.
Я в данной области более теоретик, если кто поправит, буду рад:
1. мелочь, а все-таки — RAID-1 позволяет читать данные в 2 раза быстрее за счет распараллеливания между зеркалами;
2. Скорость вращения != скорость чтения данных. Не совсем корректно указывать, мол, объем вырос в стопицот раз, а скорость вращения только вдвое, так как некоторые поторопятся и подумают, что скорость чтения/записи выросла всего вдвое. Сравнивать лучше скорость чтения/записи (которая пропорциональна скорости вращения и плотности размещения данных), которая выросла как бы больше, чем в 2 раза (не в последнюю очередь за счет кэша и оптимизации операций чтения в самой железке) =)
3. Ребилд (равно как и чтение/запись) в старших рейдах являются тривиальной операций на основе xor, т.е. они будут медленными для софтовой реализации, а в случае нормальной железки она вроде как очень скоростная.
Вообще, статья очень хорошая. Над некоторыми вещами не задумывался ранее (в том числе недоумевал над популярностью raid10), так что спасибо за культурпросвет.
1. мелочь, а все-таки — RAID-1 позволяет читать данные в 2 раза быстрее за счет распараллеливания между зеркалами;
2. Скорость вращения != скорость чтения данных. Не совсем корректно указывать, мол, объем вырос в стопицот раз, а скорость вращения только вдвое, так как некоторые поторопятся и подумают, что скорость чтения/записи выросла всего вдвое. Сравнивать лучше скорость чтения/записи (которая пропорциональна скорости вращения и плотности размещения данных), которая выросла как бы больше, чем в 2 раза (не в последнюю очередь за счет кэша и оптимизации операций чтения в самой железке) =)
3. Ребилд (равно как и чтение/запись) в старших рейдах являются тривиальной операций на основе xor, т.е. они будут медленными для софтовой реализации, а в случае нормальной железки она вроде как очень скоростная.
Вообще, статья очень хорошая. Над некоторыми вещами не задумывался ранее (в том числе недоумевал над популярностью raid10), так что спасибо за культурпросвет.
1. Да, но иногда жалко терять половину пространства
2. Теоретически большая скорость вращения позволяет более быстро получить доступ к области диска. Отсюда, какой-то прирост скорости чтения есть (цифрами не владею, не буду вводить в заблуждение)
3. Не на всех контроллерах она скоростная. Кроме прочего, во время ребилда производительность дисковой подсистемы сильно снижается. По крайне мере, на HP NetRaid это очень сильно было заметно (не пинайте, сам знаю, что железка старая)
2. Теоретически большая скорость вращения позволяет более быстро получить доступ к области диска. Отсюда, какой-то прирост скорости чтения есть (цифрами не владею, не буду вводить в заблуждение)
3. Не на всех контроллерах она скоростная. Кроме прочего, во время ребилда производительность дисковой подсистемы сильно снижается. По крайне мере, на HP NetRaid это очень сильно было заметно (не пинайте, сам знаю, что железка старая)
1. Да, но только в два раза. А RAID-10 из, например, 8 дисков — в 8 раз, и эта величина пропорционально увеличивается при добавлении дисков.
2. Там в статье приведена ссылка на iXBT-шное тестирование дисков разных лет, самый старый из которых — 160GB Samsung Spinpoint 2004 года, в сравнении с новым сигетовским терабайтником. Посмотрите, очень показательно.
3. Нет :) Все не так просто как вам кажется.
Я же привел график и ссылку на PDF адаптека по времени ребилда. Не ленитесь проверять, если не верите на слово.;)
2. Там в статье приведена ссылка на iXBT-шное тестирование дисков разных лет, самый старый из которых — 160GB Samsung Spinpoint 2004 года, в сравнении с новым сигетовским терабайтником. Посмотрите, очень показательно.
3. Нет :) Все не так просто как вам кажется.
Я же привел график и ссылку на PDF адаптека по времени ребилда. Не ленитесь проверять, если не верите на слово.;)
1. Если зеркалировать 8 дисков под RAID-1, то тоже получится прирост в 8 раз на чтение :D
2. ненене, 160Гб и 1Тб в данном контексте сравнивать как бы некорректно. Давайте искать данные по тому самому, на 21Мб =)
3. я верю — просто сомневаюсь. Касательно графиков от известных фирм-производителей (даже тех, которые люблю и уважаю) — я им редко доверяю, так как любое испытание содержит тыщщи допущений и тонкостей, которые могут все с ног на голову перевернуть, ибо маркетинг.
2. ненене, 160Гб и 1Тб в данном контексте сравнивать как бы некорректно. Давайте искать данные по тому самому, на 21Мб =)
3. я верю — просто сомневаюсь. Касательно графиков от известных фирм-производителей (даже тех, которые люблю и уважаю) — я им редко доверяю, так как любое испытание содержит тыщщи допущений и тонкостей, которые могут все с ног на голову перевернуть, ибо маркетинг.
1. Нет :) Без чередования ускорения не будет. А с чередованием это и будет RAID-10.
2. Я привел сравнение. Скорость диска на 21 MB была примерно 600KB/s
При увеличении в 50 тысяч раз, пропорционально увеличению емкости, это было бы 30GB/s
3. Ответ 3ware на измерения Adaptec. У них свой получился лучше, но все равно 10 часов
3ware.com/products/pdf/3ware_Adaptec_SPEEDComp_9650SE-vs-31605_121107c.pdf
2. Я привел сравнение. Скорость диска на 21 MB была примерно 600KB/s
При увеличении в 50 тысяч раз, пропорционально увеличению емкости, это было бы 30GB/s
3. Ответ 3ware на измерения Adaptec. У них свой получился лучше, но все равно 10 часов
3ware.com/products/pdf/3ware_Adaptec_SPEEDComp_9650SE-vs-31605_121107c.pdf
1) гм… по моему многие рейды умеют работать с зеркалом на чтение с нескольких хардов… то есть по сути при записи у вас обычный рейд1, при чтении рейд0
1. зависит от объема данных. Для небольших (несколько блоков) — не будет. Для больших (много блоков, возможно — в разных местах диска) — за счет распараллеливания запросов можно ускорить.
У нас RAID5 из сейчас уже 15 дисков Seagate SATA по 500Gb как раз на таком контроллере. Могу сказать, что добавление диска влечёт за собой перестройку массива сроком до 5 суток.
Был случай, станция видеомонтажа, но люди денег на нее тратить не хотели, мать была асус не шипко хорошая, с рейд-контроллером на борту. В один самый не подходящий день один диск умер. Поставили свежий, а рейд данные не копирует. Настроек и команд никаких нет. Уже и кабель проверил и питание. Новый диск он так и не принял, после сотой попытки заработал умерший винт, данные удалось утянуть. Такой не дорогой рейд-контроллер.
Обычно в биосе RAID надо явно указать для этого диска что он hotspare, после этого RAID его понимает и начинает его использовать для ребилда. Просто неназначнный и присутствующий как нераспределенный в RAID MAanager диск обычно не берется (мало ли что, вдруг он используется как-то иначе, лучге не трогать).
Хорошая статья — аргументированно и по делу :)
Разве что не хватает экзотических вариантов RAID-5EE и ему подобных
Разве что не хватает экзотических вариантов RAID-5EE и ему подобных
Да я то же хотел как раз спросить на тему Raid5E и Raid5EE, еще если честно не хватает Raid6E :)
А еще есть raid50/60 :)
А еще есть raid50/60 :)
Насколько я помню, это все какие-то проперитарные реализации в серверных контроллерах IBM, не?
Не, я конечно могу вообще пост про все RAID по порядку написать.
Но пока сошлюсь на вот это:
blog.aboutnetapp.ru/archives/22
blog.aboutnetapp.ru/archives/24
Не, я конечно могу вообще пост про все RAID по порядку написать.
Но пока сошлюсь на вот это:
blog.aboutnetapp.ru/archives/22
blog.aboutnetapp.ru/archives/24
Проблема увеличения скорости жестких дисков лежит в их архитектуре.
Ждем и надеемся на быстрое развитие SSD-дисков. Вот там поле еще не перепахано.
Ждем и надеемся на быстрое развитие SSD-дисков. Вот там поле еще не перепахано.
не приводит один кластер к потере ВСЕХ данных… максимум к более геморройному ребилду… минимум так же к испорченному файлу…
В невнимательности ishua ;)
преувеличение автором… ;) на практике была ситуация ребилд нормально проходил, когда в процессе ребилда два раза свет выключали, то есть сервер тупа отрубался от розетки… При этом массив был заполнен на 90% и серверу уже было лет 6 ( собственно за все 6 лет упсу не меняли по этому сервер то и отрубался при отключении света) :)
1. Использовать RAID-6. В случае RAID-6 в случае отказа одного диска у вас все равно остается защита избыточностью на время ребилда.
2. Использовать RAID-10. На нем ребилд происходит гораздо быстрее (простым линейным копированием с одного диска на другой).
ЗЫ. Чувствую, что ниасилившие ниасилили даже вывод :)
2. Использовать RAID-10. На нем ребилд происходит гораздо быстрее (простым линейным копированием с одного диска на другой).
ЗЫ. Чувствую, что ниасилившие ниасилили даже вывод :)
RAID10 не более надёжен, чем RAID5.
Это не так.
RAID-10 с вероятностью 50% дохнет от потери 2-х винтов, в случае RAID-5 вероятность 100% :-)
В принципе, это утешает :-)
В принципе, это утешает :-)
Опять же, какова вероятность сдохнуть 2-ум винтам за время восстановления RAID?
Она есть. Это главное. Потому я лично предпочитаю RAID-6 :-)
Вероятность сообщает одну цифру, а закон подлости — другую :)
С таким подходом нужно не RAID пользоваться, в иконы по стенам вешать и святой водой запасаться.
диски имеют определенный ресурс жизни => винты одинаковые, их ресурс тоже => падения одного винта признак того, что второй винт тоже скоро откажет(если проблема в ресурсе, а не в проблеме с питанием например). в то время как raid0 за очень быстрые сроки позволяет создать 100% копию массива но свежем диске, и поломка второго диска уже не так страшка.
Автомобили имеют определённый ресурс жизни=>автомобили одинаковые=>если соседское авто поломалось, то моё тоже пора везти на свалку.
Странна логика. Винт может прожить 15 лет, а может умереть через минуту после установки. Они вообще мрут волнами — сначала сразу после установки, затем в течении года, а затем уже сугубо от старости.
Странна логика. Винт может прожить 15 лет, а может умереть через минуту после установки. Они вообще мрут волнами — сначала сразу после установки, затем в течении года, а затем уже сугубо от старости.
не правильно рассуждаете, вы ездите с сосед практически синхронно? одинаковый пробег в одно и тоже время по тем же дорогам? винты в raid'e используются одинаково и тратят они свой ресурс практически синхронно.
p.s.
у моих соседей одинаковые hond'ы CRV, оба с разницей в неделю поменяли тормозные колодки, копили они приблизительно в одно и тоже время :)
p.s.
у моих соседей одинаковые hond'ы CRV, оба с разницей в неделю поменяли тормозные колодки, копили они приблизительно в одно и тоже время :)
У нас в Латвии был показательный случай у редакции нашего местого IT журнала Digital Times, когда у них на сервере сдох RAID-5 сразу в 2 диска. В итоге они всё подымали из бекапов, т.к. у них ещё был простой HTML хостинг, на котором очень даже много сайтов. Вроде бы сервер, вроде аппаратный райд, вроде SCSI диски — а всё равно сдохло сразу и намертво.
У меня был случай, случай, когда сдохло три накопителя подряд от разных производителей в разный системных блока.
Сдох винт. Взял замену (новую!) — вставил. При восстановлении замена приказала долго жить. Вытащил винт вставил в другую систему, взял ещё замену (тоже новую другого производителя). Сдохла сразу после восстановления. Отдал другому человеку, он поставил третью замену и всё заработало.
В таких случаях — камлания, иконы, святая вода и резервные копии.
Сдох винт. Взял замену (новую!) — вставил. При восстановлении замена приказала долго жить. Вытащил винт вставил в другую систему, взял ещё замену (тоже новую другого производителя). Сдохла сразу после восстановления. Отдал другому человеку, он поставил третью замену и всё заработало.
В таких случаях — камлания, иконы, святая вода и резервные копии.
Очень таки немалая… Имею печальный опыт сдыхания RAID10, с которого после плясок с бубном удалось вытащить конфиги.
Посчитайте вероятность.
Можете просто прикинуть из соображений здравого смысла какая вероятность больше — отказа одного диска из 4-х или одного диска из 3-х?
Можете просто прикинуть из соображений здравого смысла какая вероятность больше — отказа одного диска из 4-х или одного диска из 3-х?
RAID5 гарантированно умирает при одновременной потере двух дисков. RAID10 может не умереть, если один потеряный диск не является зеркалом другого.
После потери одного диска у RAID10 остаётся три диска, а у RAID5 — два. Где вероятность отказа больше?
Raid10 = (A, B) (C, D)
Raid5 = (Z, X, C)
Сдох диск C.
Вероятность отказа одного из трех дисков в Raid 10 больше, но какова при этом вероятность потерять данные? ,-)
Raid5 = (Z, X, C)
Сдох диск C.
Вероятность отказа одного из трех дисков в Raid 10 больше, но какова при этом вероятность потерять данные? ,-)
Вероятность потерять данные больше в RAID5, т.к. потеряв любой диск из оставшихся двух потеряешь данные. А в RAID10 из оставшихся 3-х дисков ты можешь потерять еще один диск (любой из двух который не зеркало вылетевшего)
Не правда ваша. В Raid0+1 у вас осталось три диска из них два — хранят одинаковые данные. Какова вероятность потерять весь массив? Вероятность выше чем в RAID5, т.к. потеря диска с уникальными данными однозначно приводит к потере массива. Плюс, вероятность потери дублирующихся данных.
Это я к тому, что нельзя вот так однозначно утверждать :)
Это я к тому, что нельзя вот так однозначно утверждать :)
спасибо, определился с выбором для себя
Что-то как-то весьма хрень.
Массив RAID1 объёмом 1TB тоже будет восстанавливаться часов 5-10. Это раза в четыре меньше чем RAID5. Если же применяется «честный» контроллер RAID5 с восстановлением «на лету», то он по производительности практически не будет отличаться от RAID1. Более того, он ещё и имеет все шансы обогнать RAID1. Да, он денег стоит. Но тут уж или восстанавливаться двое суток или денежку платить.
По надёжности тоже как-то не понятно. Честный RAID5 быстрее чем один диск на линейный операциях при более высокой надёжности. RAID1 — надёжнее, но медленнее чем RAID5. RAID0 — быстрее но намного менее надёжен, чем RAID5. RAID10 — быстрее, но всё ещё менее надёжен, чем RAID5. Отсюда получаем, что RAID5 — хороший компромис между надёжности и быстродействием. А рассказы о том, что на время восстановления он, о ужас! теряет в надёжности можно отнести к любому RAID с небольшим количеством дисков. И почему-то не рассматривается вариант RAID5+1, который даёт полное счастье. Однако, есть мнение, что в большинстве случаем более оптимальным будет хранение бэкапов на отдельном массиве.
Короче говоря, а какой смысл-то? Всем сидеть на RAID10 и пожертвовать надёжностью?
Массив RAID1 объёмом 1TB тоже будет восстанавливаться часов 5-10. Это раза в четыре меньше чем RAID5. Если же применяется «честный» контроллер RAID5 с восстановлением «на лету», то он по производительности практически не будет отличаться от RAID1. Более того, он ещё и имеет все шансы обогнать RAID1. Да, он денег стоит. Но тут уж или восстанавливаться двое суток или денежку платить.
По надёжности тоже как-то не понятно. Честный RAID5 быстрее чем один диск на линейный операциях при более высокой надёжности. RAID1 — надёжнее, но медленнее чем RAID5. RAID0 — быстрее но намного менее надёжен, чем RAID5. RAID10 — быстрее, но всё ещё менее надёжен, чем RAID5. Отсюда получаем, что RAID5 — хороший компромис между надёжности и быстродействием. А рассказы о том, что на время восстановления он, о ужас! теряет в надёжности можно отнести к любому RAID с небольшим количеством дисков. И почему-то не рассматривается вариант RAID5+1, который даёт полное счастье. Однако, есть мнение, что в большинстве случаем более оптимальным будет хранение бэкапов на отдельном массиве.
Короче говоря, а какой смысл-то? Всем сидеть на RAID10 и пожертвовать надёжностью?
Откуда у вас такие цифры? Я 2Тб Raid-5 перестраиваю за 2.5-3 часа.
С потолка :) я тоже перестраиваю 2 часа, но вот автор топика рассказывает об огромных сутках. Поэтому я говорю о крайних случаях, когда у вас программный RAID5, слабый процессор и кривой софт :)
Специально на новом сервере попробовал собрать 5й раид из 4х 150гб дисков, порушил его — восстанавливалось все минут 20-25. Контроллер аппаратный.
Не согласен автором. Какие-то мудрствования.
У нас есть 1 диск. Есть некая вероятность отказа в произвольный момент Т.
За некоторый период времени N он может отказать один раз.
Теперь у нас есть 8 дисков, у каждого из них вероятность отказа также в момент Т.
За тот же момент времени в этой группе может произойти 8 отказов, в каждом из дисков.
Следовательно в RAID-0 едином целом, состоящем из 8 дисков надежность ниже в 8 раз.
Это если на пальцах, еще не забывшие тервер поправят меня, но вряд ли сильно.
У нас есть 1 диск. Есть некая вероятность отказа в произвольный момент Т.
За некоторый период времени N он может отказать один раз.
Теперь у нас есть 8 дисков, у каждого из них вероятность отказа также в момент Т.
За тот же момент времени в этой группе может произойти 8 отказов, в каждом из дисков.
Следовательно в RAID-0 едином целом, состоящем из 8 дисков надежность ниже в 8 раз.
Это если на пальцах, еще не забывшие тервер поправят меня, но вряд ли сильно.
Мне не за это платят. :)
А если серьезно, то раз вы сециалист — то и расскажите, чтобы неспециалисту стало понятно, в чем я не прав с RAID-0.
А если серьезно, то раз вы сециалист — то и расскажите, чтобы неспециалисту стало понятно, в чем я не прав с RAID-0.
Почему?
Ну я попросил вас объяснить, чтобы неспециалисту, то есть мне, стало понятно. А вы встали на броневик и произнесли какую-то загадочную фразу.
Откуда она у вас взялась я не понимаю, моим ощущениям она противоречит.
Не убедили. Попробуйте все же.
Я серьезно.
Откуда она у вас взялась я не понимаю, моим ощущениям она противоречит.
Не убедили. Попробуйте все же.
Я серьезно.
Да, откуда появилась именно эта формула, а не моя?
ну я думаю потому что если у вас 2 одинаковых диска и вероятность того что 1 диск в период год сгорит 0.01, то вероятность того что сгорит второй диск уже меньше… ;)
Это если события абсолютно независимы :) а выход из строя дисков одинаковой конструкции или, тем более, из одной партии после совершения практически одинакового количества схожих операций, по моему, имеет определенную связь :)
p примерно одинаковое, но можно предположить наличие связи между этими событиями. Наглядный пример — бросок монеты дает 0.5 вероятности выпадения одной стороны. Но если монету бросает не человек, а механизм со строго определенным вектором силы, то после того, как монета упала решкой, то вероятность выпадения решки на втором броске будет больше чем 0.5
Спасибо, обязательно прочту.
Вы все перевернули с ног на голову. Умножение вероятностей происходит, когда события должны выполниться одновременно. Например, если для сбоя RAID необходимо было бы, чтобы все диски вышли из строя одновременно. Тогда нужно было бы умножить вероятности выхода из строя каждого диска.
В случае RAID0 выход из строя может произойти из-за сбоя хотя бы одного (любого) из дисков. В этом случае вероятности необходимо просуммировать.
Возвращаясь к вашей проверочной задаче. Мы имеем: для работы RAID необходимо, чтобы каждый диск работал. Вероятность НЕвыхода из строя одного диска — 0.99. Значит вероятность ОДНОВРЕМЕННОГО НЕвыхода из строя всех дисков 0.99^8 = 0.922744694. Значит, вероятность выхода из строя RAID 0,077255306, что в свою очередь равно сумме вероятностей выхода из строя 8-ми дисков (ПОЧТИ из-за погрешности округления моего калькулятора)
В случае RAID0 выход из строя может произойти из-за сбоя хотя бы одного (любого) из дисков. В этом случае вероятности необходимо просуммировать.
Возвращаясь к вашей проверочной задаче. Мы имеем: для работы RAID необходимо, чтобы каждый диск работал. Вероятность НЕвыхода из строя одного диска — 0.99. Значит вероятность ОДНОВРЕМЕННОГО НЕвыхода из строя всех дисков 0.99^8 = 0.922744694. Значит, вероятность выхода из строя RAID 0,077255306, что в свою очередь равно сумме вероятностей выхода из строя 8-ми дисков (ПОЧТИ из-за погрешности округления моего калькулятора)
На самом деле меньше. Вы не учитываете множественных отказов. Но не на много.
не все так просто
при вылете массива теряются все 8 ГБ, что при 8 отдельных дисках практически не возможно — 10^-14 %
при вылете массива теряются все 8 ГБ, что при 8 отдельных дисках практически не возможно — 10^-14 %
Спасибо, отлично расписали. RAID для меня еще недавно был темным лесом, но при сборке нового компьютера пару месяцев занимался вопросом — думал собрать как раз RAID5 из нескольких 500GB дисков. Но в итоге решил, что слишком много геморроя для обычного домашнего компа — видимо, правильно решил.
RAID-1 рулит :) Использую и доволен :) Благо, диски нынче дешевые, а мегаобъемы мне не нужы, лучше уж скорость…
RAID1 скорости ни чуточку не прибавляет.
ru.wikipedia.org/wiki/RAID#RAID_1 википедия говорит об обратном, график загрузки винтов на машине почему-то тоже (у меня только чтение с дисков, сервер раздает файлы с 3-х дисков в raid-1, 62 мб в сек случайного чтения, несколько тысяч файлов, 500 мбит, около 1500 потоков скачивания)
ну статья конечно хорошая, но факты то зачем так перевирать и гиперболизировать?
к примеру: сравнивается скорость вращения а не скорость считывания (которая выросла не в два раза а в десятки раз, как и скорость записи)
к примеру2: объем десктопных дисков внезапно стал равен 11 терабайт (или даже 110 терабайт)
к примеру3: нелады с тервером — производитель не ожидает что сто процентов к чтению 10^14 бит таки один сбойный но будет. Совсем нет. Это может означать например что первые три года гарантии не будет ни одного сбойного бита на 10^20 прочитанных бит, а в оставшиеся 2 года гарантии будет 10^8 вероятность сбойного бита. Или еще какая другая математика. Но никак не означает что к 10^14 биту вероятность непрочтения равна 100%.
к примеру: сравнивается скорость вращения а не скорость считывания (которая выросла не в два раза а в десятки раз, как и скорость записи)
к примеру2: объем десктопных дисков внезапно стал равен 11 терабайт (или даже 110 терабайт)
к примеру3: нелады с тервером — производитель не ожидает что сто процентов к чтению 10^14 бит таки один сбойный но будет. Совсем нет. Это может означать например что первые три года гарантии не будет ни одного сбойного бита на 10^20 прочитанных бит, а в оставшиеся 2 года гарантии будет 10^8 вероятность сбойного бита. Или еще какая другая математика. Но никак не означает что к 10^14 биту вероятность непрочтения равна 100%.
Рекомендую прочитать сосланную статью из первого абзаца, вот эту:
blogs.netapp.com/msenviro/2009/08/raid-5-reliability-sata-quality-and-the-easter-bunny.html
Я и так старался не углубляться в математику, а то бы читатели заснули еще раньше того, как они заснули сейчас ;)
blogs.netapp.com/msenviro/2009/08/raid-5-reliability-sata-quality-and-the-easter-bunny.html
Я и так старался не углубляться в математику, а то бы читатели заснули еще раньше того, как они заснули сейчас ;)
RAID-Z2 в ZFS например. Там она еще и тормозить не особо должна, по специфике работы с дисками.
ZFSv13 на FreeBSD поддерживает вариации отказоустойчивых массивов RAID-5 (raidz) и RAID-6 (raidz2).
У ZFS тоже есть подводные камни, например: расход памяти на ARC (кеш); в некоторых задачах без серьезного тюнинга можно получить приличный overhead по IOPS и по скорости чтения; ну и самая неактуальная «для дома, для семьи» — расчет xor и cheksumming грузит проц и увеличивает латентность операций.
> а у нас есть хоть одна программная реализация RAID-6
Linux Software RAID (aka LSR).
Он также умеет делать (и это рекомендуется) data scrub для (это к вопросу о RAID-5), плюс, ко всему прочему, как и другие внеконтроллерные-RAID'ы, прекрасно работает не только с полным объёмом диска, но и его разделами, позволяя сделать небольшой, но очень надёжный RAID-1 и, на этих же дисках, RAID-5, или что там вам больше нравится.
Из других вкусностей: on-line re-shape (это когда был RAID-5 на N дисках, а стал на N+1), перестройка RAID-5 → RAID-6.
Лично мой выбор пока — RAID-5. Делать RAID-6 имеет смысл, как минимум, при кол-ве дисков > 5 (на 4-х вы отдадите те же 2-а, как и в случае с RAID-10, а по быстродействию и нагрузке на кэш L2 явно проиграете). Вообще, есть заблуждение, что «программные» RAID'ы значительно уступают в быстродействии «аппаратным» (не люблю этот термин, ибо в любом «аппаратном» есть программа, просто выполняется она на отдельном процессоре), но это, всё же, миф. Если говорить о производительности операции XOR (основа для RAID-5), то с этим всё более, чем прекрасно, да и RAID-6 арифметика тоже хорошо бы если оказалась bottle-neck'ом. Вообще, у каждого из RAID-решений свои ±'ы, их просто нужно знать.
Linux Software RAID (aka LSR).
Он также умеет делать (и это рекомендуется) data scrub для (это к вопросу о RAID-5), плюс, ко всему прочему, как и другие внеконтроллерные-RAID'ы, прекрасно работает не только с полным объёмом диска, но и его разделами, позволяя сделать небольшой, но очень надёжный RAID-1 и, на этих же дисках, RAID-5, или что там вам больше нравится.
Из других вкусностей: on-line re-shape (это когда был RAID-5 на N дисках, а стал на N+1), перестройка RAID-5 → RAID-6.
Лично мой выбор пока — RAID-5. Делать RAID-6 имеет смысл, как минимум, при кол-ве дисков > 5 (на 4-х вы отдадите те же 2-а, как и в случае с RAID-10, а по быстродействию и нагрузке на кэш L2 явно проиграете). Вообще, есть заблуждение, что «программные» RAID'ы значительно уступают в быстродействии «аппаратным» (не люблю этот термин, ибо в любом «аппаратном» есть программа, просто выполняется она на отдельном процессоре), но это, всё же, миф. Если говорить о производительности операции XOR (основа для RAID-5), то с этим всё более, чем прекрасно, да и RAID-6 арифметика тоже хорошо бы если оказалась bottle-neck'ом. Вообще, у каждого из RAID-решений свои ±'ы, их просто нужно знать.
Спасибо, познавательная статья.
немного позанудствую:
«BER это только вероятность, которая стремится к 100 к 11-му терабайту%» — криво написано. На самом деле если говорить что это за вероятность в вероятностной оценке, то получиться, что BER — это вероятность, которая может быть принята в какое-то внимание в районе 11го терабайта. Скорее всего эту мысль хотел сказать автор.
Если же говорить по честному — ничего вам эта цифра не скажет при маленькой выборке. надо хотя бы сотню 11-титерабайтных операций проделать, чтобы что-то сказать.
по теме:
в статье мешаются домашнее и промышленное (десктопы и сервера) применения. для промышленных решений хранение данных всегда выводиться в отдельную дисковую систему. там же всё очень и очень зависит от комплексных задач. может быть эффективнее и десятый рейд сделать.
«BER это только вероятность, которая стремится к 100 к 11-му терабайту%» — криво написано. На самом деле если говорить что это за вероятность в вероятностной оценке, то получиться, что BER — это вероятность, которая может быть принята в какое-то внимание в районе 11го терабайта. Скорее всего эту мысль хотел сказать автор.
Если же говорить по честному — ничего вам эта цифра не скажет при маленькой выборке. надо хотя бы сотню 11-титерабайтных операций проделать, чтобы что-то сказать.
по теме:
в статье мешаются домашнее и промышленное (десктопы и сервера) применения. для промышленных решений хранение данных всегда выводиться в отдельную дисковую систему. там же всё очень и очень зависит от комплексных задач. может быть эффективнее и десятый рейд сделать.
Если она происходит в момент ребилда — она приведет к потере всего RAID.
Про что, собсно, и спич.
Про что, собсно, и спич.
Куда делась многоуровневая коррекция данных?!
Более того, она будет парирована коррекцией ошибок.
С фигли? С чего это у них совпала контрольная сумма? Какова вероятность такого совпадения? Куда делись алгоритмы коррекции множественных ошибок? Одиночный бит вообще никаким образом не может повредиться данные где бы ни произошла ошибка. И два бита тоже. А теперь посчитайте вероятность одновременного отказа трёх битов в одном секторе. Да ещё чтобы это было воспроизводимо при повторном чтении.
«Это вероятность сбоя, из расчета некоего объема прочитанных головками диска бит»
Вы чувствуете разницу между «считанными головками» и «выданную жёстким диском»?
«Это вероятность сбоя, из расчета некоего объема прочитанных головками диска бит»
Вы чувствуете разницу между «считанными головками» и «выданную жёстким диском»?
Ещё раз — Вы это с чего взяли? Почитайте определение BSR по вашей же ссылке. Это вероятность ошибочного чтения бита головкой. Дальше идёт могучая коррекция ошибок. Вероятность некорректируемой или необнаружимой ошибки будет неизмеримо меньше. Вам нужно чтобы в пределах одного сектора произошли множественные ошибки. При этом вероятность одной ошибки ~10^14. Вероятность двух ошибок подряд ~10^28. При этом такая ошибка будет однозначно скорректирована. даже если произойдёт некорректируемая ошибка, то она с большой вероятностью будет обнаружена, т.к. алгоритмы коррекции позволяют определять больше ошибок, чем корректировать. Произойдёт повторное чтение данных. Короче говоря, нужно, чтобы при множественных повторных чтениях возникали некорректируемые ошибки, либо, чтобы чтобы произошла намного (на десятки порядков!) менее вероятная необнаружимая ошибка. Сдаётся мне, что вероятность такого события приближается к вероятности пролёта заряженной частицы через кристалл процессора.
Нет, с Miscorrected это отдельный случай. Речь идет о простой ошибке, которая случилась, а вот насчет исправить ее тут начинаются сложности.
Вариантов исправления есть не один, и не все они между собой и контролнером RAID хорошо взаимодействуют. Например такие вещи как RAID-specific, time-limited error recovery (TLER) в RAID-сериях WD, по отзывам скорее мешают, чем помогают.
Вообще использование не-RAID винтов в RAID, как и наоборот RAID в десктопах, это тоже благодатная тема для разбора.
Вариантов исправления есть не один, и не все они между собой и контролнером RAID хорошо взаимодействуют. Например такие вещи как RAID-specific, time-limited error recovery (TLER) в RAID-сериях WD, по отзывам скорее мешают, чем помогают.
Вообще использование не-RAID винтов в RAID, как и наоборот RAID в десктопах, это тоже благодатная тема для разбора.
Все верно. Действительно существует три (ну, в общем) типов ошибки. Первая — ошиблись, и исправились. Никто ничего не заметил снаружи диска. Ошибка не ушла дальше контроллера на винте.
Вторая — ошиблись, и восстановить не смогли. Времени не хватило, или участок сбоя достаточно обширен, чтобы на него не хатило помехоустойчивого кода. Ошибка вышла наружу, но мы ее видим, контроллер говорит — «вот, ошибка, упс».
Третья — ошиблись, но не заметили. И никто не заметил. Ошибочный блок вышел наружу и попал в программу, или записался на диск незамеченным, потому что у всяких CRC тоже есть конечная надежность.
Вероятность невелика, да, но она есть.
В данном топике рассматриваем проблему с ошибкой 2.
Вторая — ошиблись, и восстановить не смогли. Времени не хватило, или участок сбоя достаточно обширен, чтобы на него не хатило помехоустойчивого кода. Ошибка вышла наружу, но мы ее видим, контроллер говорит — «вот, ошибка, упс».
Третья — ошиблись, но не заметили. И никто не заметил. Ошибочный блок вышел наружу и попал в программу, или записался на диск незамеченным, потому что у всяких CRC тоже есть конечная надежность.
Вероятность невелика, да, но она есть.
В данном топике рассматриваем проблему с ошибкой 2.
Да сейчас, как впрочем и лет 10 назад всё держится именно на алгоритмах коррекции ошибок. раньше, винты имели такую характристику в SMART как RAW_READ_ERROR, так этот параметр крутится как вентилятор, это показывает то что ошибки возникают постоянно и алгоритмы их корректируют. С приближением грозы, частота таких ошибок увеличивается раз в 100(сам наблюдал), что как бы намекает. Это только вопрос лишь времени(а иногда и условий!) когда возникнет ситуация что алгоритмы пропустят ошибочные данные либо не смогут скорректировать ошибку. Вот именно эту вероятность производитель и оценивает в 10^-14…10^-16
Откуда возникает «для архива домашней видеоколлекции потеря ее в считанные секунды и не будет такой уж большой катастрофой»? Почему из-за одного бита летит вся инфа?
Если это произойдет в момент ребилда RAID-5, когда он не защищен ничем — то операция rebuild остановится, и станет не degraded, а failed, и массив можно будет восстановить только (может быть) руками, у всяких «мастеров-волшебников».
Вы никогда не видели RAID-5
Это стандартное поведение и никак нельзя заново запустить rebuild? Так делают все контроллеры или только хорошие\плохие? Потому что выглядит это достаточно глупо, из-за одного бита клинить весь процесс, ведь часто этот бит особой роли не играет и уж точно не так критичен, как недоступность всех данных :)
Как вообще девайс определяет сбой по BER? Если просто неправильно читает бит, то это должно быть незаметно для винта. Если вываливаются какие-то внутринние сообщения об ошибке, то почему не перечитать ещё раз?
Как вообще девайс определяет сбой по BER? Если просто неправильно читает бит, то это должно быть незаметно для винта. Если вываливаются какие-то внутринние сообщения об ошибке, то почему не перечитать ещё раз?
Почему? Сбойный бит может находиться либо в блоке контроля чётности, либо в блоке данных.
В случае, если в блоке контроля чётности — будет искажён 1 бит (который был на утеряном винте).
В случае, если он встретится в блоке данных, будет искажён 1 бит, если потерян винт с блоком контроля чётности и 2 бита, если потерян винт с блоком данных.
А теперь объясните, как искажение максимум 2х бит приведёт к потере всех данных.
В случае, если в блоке контроля чётности — будет искажён 1 бит (который был на утеряном винте).
В случае, если он встретится в блоке данных, будет искажён 1 бит, если потерян винт с блоком контроля чётности и 2 бита, если потерян винт с блоком данных.
А теперь объясните, как искажение максимум 2х бит приведёт к потере всех данных.
Только не бит, а сектор, размером 512 байт — раз.
А искаженный блок (сектор) диска потому, что диск оперирует секторами. Это минимальный квант для контроллера диска.
Однако RAID также работает не с секторами, а со своими блоками.
Вот тут у меня под руками в доке указан размер элемента RAID равный по умолчанию 64KB. Помножаем на число дисков, то есть sripe size, например 8, и получаем итог. Один сбойный бит делает неверной информацию в, примерно, 512 килобайтах данных.
А искаженный блок (сектор) диска потому, что диск оперирует секторами. Это минимальный квант для контроллера диска.
Однако RAID также работает не с секторами, а со своими блоками.
Вот тут у меня под руками в доке указан размер элемента RAID равный по умолчанию 64KB. Помножаем на число дисков, то есть sripe size, например 8, и получаем итог. Один сбойный бит делает неверной информацию в, примерно, 512 килобайтах данных.
«Контрольная сумма» считается не с сектора, а вот с этого вот блока.
Контрольная сумма для блока считается и хранится на диске, именно эта информация используется для определения бэдблоков (сбоев секторов).
Просто она доступна только для контроллера самого диска.
Просто она доступна только для контроллера самого диска.
Не просто и не только контрольная сумма! Там Циклическая контрольная сумма с коррекцией ошибок! да старых добрый винтах в пределах сектора гарантировалось исправление одиночных ошибок и обнаружение сдвоенных! На современных будет уместно считать, что исправляются все двойные ошибки и обнаруживаются все тройные и четверные!
Ну сектор или бит — смотря как это реализовано. Я рассматривал худший вариант — искажение данных вместо ошибки чтения. Хотя, полагаю, сейчас это невозможно, ибо наверняка винты имеют средство контроля чётности для секторов, и если чётность нарушается, то детектируют ошибку чтения всего сектора. Но я не понимаю, как потеря 512 килобайт может привести к «массив можно будет восстановить только (может быть) руками».
> у всяких «мастеров-волшебников».
В случае с Linux Software RAID всё волшебство сведётся к
1) 2-м новым дискам (если один вообще издох, а второй сбоит)
2) dd_rescue со собойного на один из новых.
— и можно запускать rebuild-заново. Да, конечно, чуда не случится, и где-то могут оказаться неправильные 512 bytes (ну, или больше — смотря как глубоко зашёл сбойный диск); но это далеко не всегда значит, что всей информации массива пришёл конец…
В случае с Linux Software RAID всё волшебство сведётся к
1) 2-м новым дискам (если один вообще издох, а второй сбоит)
2) dd_rescue со собойного на один из новых.
— и можно запускать rebuild-заново. Да, конечно, чуда не случится, и где-то могут оказаться неправильные 512 bytes (ну, или больше — смотря как глубоко зашёл сбойный диск); но это далеко не всегда значит, что всей информации массива пришёл конец…
Вставлю свои 5коп насчёт двух мифов о RAID-10 vs RAID-5 (6):
1. RAID-10 намного надёжней RAID-5: Нифига подобного. Часто забывают уточнить, что в случае ребилда RAID-10 не намного надёжней чем RAID-5. Ведь если в процессе ребилда RAID-10 массива умрёт диск, зеркальный к только что умершему то весь массив ляжет. Причём вероятность умирания этого диска достаточно высока т.к. именно с него в данный момент будут считываться данные для ребилда, не считая текущую работу.
2. RAID-10 намного быстрее RAID-5: Аналогично нифига подобного. Если взять в рассчёт массивы, составленные из одинакового количества дисков, то скорость линейного чтения всегда будет выше на RAID-5 т.к. данные читаются параллельно с n-1 дисков в то время как на RAID-10 с n/2. А вот скорость записи и время доступа сильно зависят от производительности контроллера и если скорость записи зачастую выше, то время доступа обычно тоже выше. т.е. на производительных контроллерах RAID-5 уступает RAID-10 только по времени доступа, и если данный показатель не актуален, то RAID-5 — однозначно лучший выбор.
Из практики могу сказать что я более 3х лет назад собирал машинку где RAID-6 из 16-ти SATA 400Gb дисков (на тот момент самые дешёвые десктопные Samsung'и) крутится на Areca ARC-1160. За 3 года умер один диск, который сразу поменяли и массив ребилдился несколько дней (приоритет фоновым процессам я выставил 5%). Машина работает под постоянной нагрузкой — пишет данные в round robin базу потоком в 2 гигабита. В общем, главное — правильно выбрать контроллер ;)
1. RAID-10 намного надёжней RAID-5: Нифига подобного. Часто забывают уточнить, что в случае ребилда RAID-10 не намного надёжней чем RAID-5. Ведь если в процессе ребилда RAID-10 массива умрёт диск, зеркальный к только что умершему то весь массив ляжет. Причём вероятность умирания этого диска достаточно высока т.к. именно с него в данный момент будут считываться данные для ребилда, не считая текущую работу.
2. RAID-10 намного быстрее RAID-5: Аналогично нифига подобного. Если взять в рассчёт массивы, составленные из одинакового количества дисков, то скорость линейного чтения всегда будет выше на RAID-5 т.к. данные читаются параллельно с n-1 дисков в то время как на RAID-10 с n/2. А вот скорость записи и время доступа сильно зависят от производительности контроллера и если скорость записи зачастую выше, то время доступа обычно тоже выше. т.е. на производительных контроллерах RAID-5 уступает RAID-10 только по времени доступа, и если данный показатель не актуален, то RAID-5 — однозначно лучший выбор.
Из практики могу сказать что я более 3х лет назад собирал машинку где RAID-6 из 16-ти SATA 400Gb дисков (на тот момент самые дешёвые десктопные Samsung'и) крутится на Areca ARC-1160. За 3 года умер один диск, который сразу поменяли и массив ребилдился несколько дней (приоритет фоновым процессам я выставил 5%). Машина работает под постоянной нагрузкой — пишет данные в round robin базу потоком в 2 гигабита. В общем, главное — правильно выбрать контроллер ;)
> Ведь если в процессе ребилда RAID-10 массива умрёт диск, зеркальный к только что умершему то весь массив ляжет.
Да, но время ребилда для RAID-10 меньше в десятки раз, следовательно опасность выхода из строя диска в период ребилда для RAID-10 также ниже.
> Причём вероятность умирания этого диска достаточно высока т.к. именно с него в данный момент будут считываться данные для ребилда, не считая текущую работу.
Практика это не подтверждает.
blog.aboutnetapp.ru/archives/397
> то скорость линейного чтения всегда будет выше на RAID-5
1. Random-Запись на RAID-5 примерно втрое-вчетверо медленнее записи на RAID-10, а в реальной рабочей нагрузке записей достаточно много.
2. Практически все нормальные современные контрорллеры умеют распараллеливать чтение RAID-10 по _всем_ дискам, а не только по одной их половине.
3. Топик вообще не о быстродействии RAID. :)
Да, но время ребилда для RAID-10 меньше в десятки раз, следовательно опасность выхода из строя диска в период ребилда для RAID-10 также ниже.
> Причём вероятность умирания этого диска достаточно высока т.к. именно с него в данный момент будут считываться данные для ребилда, не считая текущую работу.
Практика это не подтверждает.
blog.aboutnetapp.ru/archives/397
> то скорость линейного чтения всегда будет выше на RAID-5
1. Random-Запись на RAID-5 примерно втрое-вчетверо медленнее записи на RAID-10, а в реальной рабочей нагрузке записей достаточно много.
2. Практически все нормальные современные контрорллеры умеют распараллеливать чтение RAID-10 по _всем_ дискам, а не только по одной их половине.
3. Топик вообще не о быстродействии RAID. :)
Время ребилда RAID-5 не больше в десятки раз, что за цифры блин.
Скорость ребилда устанавливается контроллером, и может равнятся максимальной скорости чтения/записи.
Скорость ребилда устанавливается контроллером, и может равнятся максимальной скорости чтения/записи.
Практически все нормальные контроллеры умеют работать с RAID на скорости чтения, т.е. время ребилда будет равно таковому для RAID1. Нормальные контроллеры — это те, которые не нагружают ЦП.
Выше в посте я привел на мой взгляд достаточно примеров.
В приведенном графике
указаны часы ребилда, а буквы и цифры слева это название контроллеров, что нормальнее некуда.
www.adaptec.com/en-US/support/raid/sas_raid/SAS-31605/
Affordable Unified Serial RAID controllers support both SATA and SAS devices. Ideal for workstations, and entry to mid-range servers.
Note: This Adaptec card contains a powerful RAID processor
www.3ware.com/products/serial_ata2-9650.asp
On-board I/O RISC processor and RAID offload provides true hardware RAID.
В приведенном графике
указаны часы ребилда, а буквы и цифры слева это название контроллеров, что нормальнее некуда.
www.adaptec.com/en-US/support/raid/sas_raid/SAS-31605/
Affordable Unified Serial RAID controllers support both SATA and SAS devices. Ideal for workstations, and entry to mid-range servers.
Note: This Adaptec card contains a powerful RAID processor
www.3ware.com/products/serial_ata2-9650.asp
On-board I/O RISC processor and RAID offload provides true hardware RAID.
В результате этого альянса RAID-0 получает отказоустойчивость, а RAID-1 — быстродействие. Как правило, такая комбинация называется RAID-0+1 или RAID-10, или «чередование с зеркалированием».
RAID-0+1 и RAID-10 — это всё-таки разные RAID. И не надо их мешать в одну кучу.
блин, а у нас на emc хранилищах в 90% случаев используются именно raid5. причем проблема недостатка места стоит очень остро, ибо дорого это все. если бы было 10 везде, то предприятия разорились бы наверное.
Хорошая статья. Но нам, «ораклоидам», эту светлую мысль уже донесли примерно лет 8 назад «по-сИкрету» :)
Автору — спасибо!
Автору — спасибо!
огромное спасибо, статья высший класс
взяли вселили панику мне.
Пациент скорей жив, чем мертв…
Во первых нужно было рассматривать 5E и 5EE, раз уже хороните 5.
Цитата:
RAID level-5E Enhanced (RAID level-5EE) подобен уровню RAID level-5E, но он имеет более эффективное распределение spare drive и, как следствие, – более быстрое время восстановления. Как и уровень RAID5E, этот уровень RAID распределяет в рядах блоки данных и контрольных сумм. Но он также распределяет и свободные блоки spare drive, а не просто оставляет под эти цели часть объема диска. Это позволяет уменьшить время, необходимое на реконструкцию целостности тома RAID5EE. Входящий в том резервный диск нельзя делить с другими томами – как и в предыдущем случае. Том RAID 5EE строится минимум на четырех физических дисках. Полезный объем логического тома вычисляется по формуле N-2. (http://www.timcompany.ru/article4.html)
Итого 5E и Raid 10 очень походи, все зависит от удачи. (на 10 ее нужно меньше).
Опыт почему RAID 10 не использую:
После прочтения данных статей мы сразу решили переходить на RAID 10 и терять в пространстве, ведь надежность лучше места думали мы. Затем в течение года выходит из строя сразу 3 RAID 10 (разные диски, контроллеры) причем мрут сразу 2 диска и нет никаких закономерностей.
Около 40 RAID и моя статистика такова:
потеряно RAID 10 — 3
потеряно RAID 5 — 1
потеряно RAID 5E и RAID 5EE — 0
Сейчас от 10 почти отказались.
Во первых нужно было рассматривать 5E и 5EE, раз уже хороните 5.
Цитата:
RAID level-5E Enhanced (RAID level-5EE) подобен уровню RAID level-5E, но он имеет более эффективное распределение spare drive и, как следствие, – более быстрое время восстановления. Как и уровень RAID5E, этот уровень RAID распределяет в рядах блоки данных и контрольных сумм. Но он также распределяет и свободные блоки spare drive, а не просто оставляет под эти цели часть объема диска. Это позволяет уменьшить время, необходимое на реконструкцию целостности тома RAID5EE. Входящий в том резервный диск нельзя делить с другими томами – как и в предыдущем случае. Том RAID 5EE строится минимум на четырех физических дисках. Полезный объем логического тома вычисляется по формуле N-2. (http://www.timcompany.ru/article4.html)
Итого 5E и Raid 10 очень походи, все зависит от удачи. (на 10 ее нужно меньше).
Опыт почему RAID 10 не использую:
После прочтения данных статей мы сразу решили переходить на RAID 10 и терять в пространстве, ведь надежность лучше места думали мы. Затем в течение года выходит из строя сразу 3 RAID 10 (разные диски, контроллеры) причем мрут сразу 2 диска и нет никаких закономерностей.
Около 40 RAID и моя статистика такова:
потеряно RAID 10 — 3
потеряно RAID 5 — 1
потеряно RAID 5E и RAID 5EE — 0
Сейчас от 10 почти отказались.
«Но скорость вращения при этом увеличилась всего вдвое.»
Более интересует увеличение скорости чтения, а не вращения. Посчитайте, во сколько раз больше информации теперь размещено на дорожках диска. А также не забудьте о скорости перемещения считывающей головки (влияет больше, чем скорость вращения).
Более интересует увеличение скорости чтения, а не вращения. Посчитайте, во сколько раз больше информации теперь размещено на дорожках диска. А также не забудьте о скорости перемещения считывающей головки (влияет больше, чем скорость вращения).
Если нужна надежность данных, то нужно:
— RAID-5E, RAID-6 (и еще несколько маркетинговых наименований одного и того-же от разных производителей)
— надежный и быстрый бэкап, соответствующий определенным заранее, до покупки, параметрам качества обслуживания для подсистемы хранения (и снапшоты для сокращения окон бэкапа)
— использование дисковых подсистем с соответствующим образом оттестированными дисками (стоимость одного и того же диска, купленного по «десктопному» партномеру и «серверному» партномеру может отличаться в разы, и это не пустой развод клиента). Например, винчестеры дисковых подсистем класса high-end одного авторитетного производителя тестируются 72 часа в термокамере.
— использование территориально-распределенных дублирующих систем хранения с организацией асинхронной или синхронной репликации данных
— и т.п., увеличивающее бюджет решения до бесконечности. :)
Поэтому, начинать надо с оценки рисков (простоя, потери данных и пр.) и перевода их в денежное исчисление. И только потом углубляться в технические детали.
— RAID-5E, RAID-6 (и еще несколько маркетинговых наименований одного и того-же от разных производителей)
— надежный и быстрый бэкап, соответствующий определенным заранее, до покупки, параметрам качества обслуживания для подсистемы хранения (и снапшоты для сокращения окон бэкапа)
— использование дисковых подсистем с соответствующим образом оттестированными дисками (стоимость одного и того же диска, купленного по «десктопному» партномеру и «серверному» партномеру может отличаться в разы, и это не пустой развод клиента). Например, винчестеры дисковых подсистем класса high-end одного авторитетного производителя тестируются 72 часа в термокамере.
— использование территориально-распределенных дублирующих систем хранения с организацией асинхронной или синхронной репликации данных
— и т.п., увеличивающее бюджет решения до бесконечности. :)
Поэтому, начинать надо с оценки рисков (простоя, потери данных и пр.) и перевода их в денежное исчисление. И только потом углубляться в технические детали.
Цитата:
Когда RAID-5 появился, в 1987 году, типичный жесткий диск был размером 21MB, и имел скорость вращения 3600 RPM. Сегодня типичный диск SATA это 1TB, то есть прирост емкости составил 50 тысяч раз! Но скорость вращения при этом увеличилась всего вдвое.
Автору нужно что бы диск вращался с нереальной скоростью или он хочет увеличить скорость передачи данных? :) Если взять его диск на 21МБ и современную бюджетную модельку например хитачи на 1ТБ, то он увидит реальную разницу в скорости передачи данных :) Важна же скорость, а не как рычит твой винт :)
Когда RAID-5 появился, в 1987 году, типичный жесткий диск был размером 21MB, и имел скорость вращения 3600 RPM. Сегодня типичный диск SATA это 1TB, то есть прирост емкости составил 50 тысяч раз! Но скорость вращения при этом увеличилась всего вдвое.
Автору нужно что бы диск вращался с нереальной скоростью или он хочет увеличить скорость передачи данных? :) Если взять его диск на 21МБ и современную бюджетную модельку например хитачи на 1ТБ, то он увидит реальную разницу в скорости передачи данных :) Важна же скорость, а не как рычит твой винт :)
Автору хотелось бы, чтобы скорость передачи данных с диска была выше, чем сейчас, когда емкость за несколько лет увеличилась в разы, а скорость передачи данных — в проценты.
скорость тоже в разы. Помню было время когда 100 мегабитная карточка могла повесить комп, т.к. винт «не успевал» считывать с такой скоростью что сетевуха запрашивала. Т.е. копирование с винта на тот же винт было заметно медленнее чем копирование по сети. Может не так сильно скорость и возросла как объем, но уж точно возросла в разы.
Даже более того: если скорость вращения оставлять ту же, но увеличивать плотность записи (что собственно мы и наблюдаем при неизменном размере винта увеличивается его емкость) то скорость полного забития винта информацией теоретически будет неизменной. На практике будут влиять другие факторы, но не скорость же вращения?!
Я согласен с автором что есть ошибки чтения и их вероятность весьма высока, но на современных контроллерах описанной ошибки для загубления всего массива недостаточно. А поскольку ошибки такие носят непостоянный характер с ними достаточно хорошо справляются контроллеры. Я читал несколько статей о ложном детекте ошибок, но на практике проблемные области в cold data не приводили к потере всех данных — максимум к лишнему ребилду.
В статье заострено внимание на порчу одного бита, но с пятым рейдом обычно бывает не так. В основном диски летят или от старости (но тут понятно, что доводить их до такого состояния на важных данных не стоит) или же от бракованной партии, что гораздо чаще. Поскольку для рейда винчестеры покупаются обычно скопом, то получаем набор из практически идентичных винчестеров. И эти идентичные винчестеры будут дохнуть примерно в одно и тоже время. Т.е. сдох один, остальные уже на издыхании, в это время получаем безумную нагрузку на ребилд и работу в degraded режиме, и получаем выход ещё одного винчестера из строя, и прощаемся с данными. У 10-ого рейда, всвязи с меньшей нагрузкой (в degraded режиме, ничего фатального, ребилд простой), шансы выжить больше.
Кроме того, у пятого рейда есть нехорошее свойство при записи небольшого количества данных, что приводит к тому, что необходимо прочитать данные со всех других дисков проксорить и записать, что на перфомансе тоже не очень отражается (я знаю, что кэш и все дела, но идеологически тут неприятная ситуация).
Кроме того, у пятого рейда есть нехорошее свойство при записи небольшого количества данных, что приводит к тому, что необходимо прочитать данные со всех других дисков проксорить и записать, что на перфомансе тоже не очень отражается (я знаю, что кэш и все дела, но идеологически тут неприятная ситуация).
Зачем так сложно? результат xor можно получить зная старые данные и новые. Т.е. в RAID5 из любого кол-ва диска читаем 1 блок и записываем 2 блока на 1 операцию записи.
Упс, извиняюсь, действительно забыл про этот стандартный оптимизационный финт ушами. Тем не менее, всё равно нужно ещё проводить дополнительные операции чтения при записи.
Зато головку дергать не надо :) В одном месте считала и тут же записала. Это мизерный оверхед. Вот запись блока контрольных данных — это да, но она на другом диске происходит.
Раз уже пошел такой разговор… если один диск дает X IOPS, то для массива из 4х дисков RAID10 даст 4X IOPS на чтение и 2X IOPS на запись, RAID5 3X IOPS на чтение и 2X IOPS на запись, а RAID6 2X 1.3X
Для массива из 8 дисков
RAID10 8X 4X
RAID5 7X 4X
RAID6 6X 2.6X
RAID50 6X 4X
При этом линейная скорость чтения/записи даже для массива из 4х дисков упрется в PCI-x шину, ну а гигабайты для задачи, критично относящейся к производительности вы получите в любом варианте массива «for free», набрав нужное количество IOPS.
Раз уже пошел такой разговор… если один диск дает X IOPS, то для массива из 4х дисков RAID10 даст 4X IOPS на чтение и 2X IOPS на запись, RAID5 3X IOPS на чтение и 2X IOPS на запись, а RAID6 2X 1.3X
Для массива из 8 дисков
RAID10 8X 4X
RAID5 7X 4X
RAID6 6X 2.6X
RAID50 6X 4X
При этом линейная скорость чтения/записи даже для массива из 4х дисков упрется в PCI-x шину, ну а гигабайты для задачи, критично относящейся к производительности вы получите в любом варианте массива «for free», набрав нужное количество IOPS.
Да, и кстати многие почему-то уверены, что каждый раз читается весь chun-ksize (aka stripe-size). Может когда-то в особо тупых контроллерах так и делалось, но очень давно…
> Поскольку для рейда винчестеры покупаются обычно скопом
Никогда так не делал. «Не храните все яйца в одной корзине» ©
Никогда так не делал. «Не храните все яйца в одной корзине» ©
Спасибо
Я немного еретическую мысль выскажу, но 99% процентам домашних пользователей рейд (любого уровня) совсем не нужен, даже вреден.
Наличие рейда создаст больше проблем, чем решит.
Ведь рейд решает только одну проблему сохранности информации на диске — сохранность при выходе из строя диска.
Проблему с неисправностью другой аппаратуры, ошибок ОС и софта, деятельностью вирусов и самого пользователя :) рейд не решит.
Еще возможны проблемы самого рейда, например софтовый рейд5 иногда саморазваливается, много на форумах об этом говорили.
Чего же делать, если информация реально дорога — хорошо продумать стратегию бекапов. Дома это, на мой взгляд, самый правильный путь.
Подчеркиваю — дома, не для сервисов, которые обязаны функционировать 24/7
Наличие рейда создаст больше проблем, чем решит.
Ведь рейд решает только одну проблему сохранности информации на диске — сохранность при выходе из строя диска.
Проблему с неисправностью другой аппаратуры, ошибок ОС и софта, деятельностью вирусов и самого пользователя :) рейд не решит.
Еще возможны проблемы самого рейда, например софтовый рейд5 иногда саморазваливается, много на форумах об этом говорили.
Чего же делать, если информация реально дорога — хорошо продумать стратегию бекапов. Дома это, на мой взгляд, самый правильный путь.
Подчеркиваю — дома, не для сервисов, которые обязаны функционировать 24/7
Дочитал сюда:
> И это не означает, что надо прочитать ровно 11TB, BER это только вероятность, которая стремится к 100% к 11-му терабайту. На меньших объемах она просто пропорционально уменьшается.
Это бред. Учите математику (теор. вер.)
Получение неверного бита при чтении не зависит от того, сколько до этого было бит прочитано.
> И это не означает, что надо прочитать ровно 11TB, BER это только вероятность, которая стремится к 100% к 11-му терабайту. На меньших объемах она просто пропорционально уменьшается.
Это бред. Учите математику (теор. вер.)
Получение неверного бита при чтении не зависит от того, сколько до этого было бит прочитано.
Да, вообще в статье конечно вопросы с математикой… Цифры подгонялись под желаемый вывод.
AnatolyB, я совершенно без малейшей иронии хотел бы пропросить вас написать пост-статью об этих вопросах, в которых я лично не компетентен, увы, так как практик-«эксплуатант», а не математик.
Думаю оно будет всем чрезвычайно полезно, если у вас кармы не хватает на это, то я могу опубликовать это со ссылкой на вас.
Тема интересная, но сами видите порождающая просто буйство некомпетентности.
Хотелось бы хоть чуть ситуацию поправить.
Думаю оно будет всем чрезвычайно полезно, если у вас кармы не хватает на это, то я могу опубликовать это со ссылкой на вас.
Тема интересная, но сами видите порождающая просто буйство некомпетентности.
Хотелось бы хоть чуть ситуацию поправить.
Спасибо, открыли мне глаза на RAID5
Отличная статья, спасибо.
Одна из лучших статей на Хабре, наверное, за весь уходящий год!
Ну ещё к минусу всех аппаратных рэйдов можно добавить неизбежные трудности при гибели самого аппаратного RAID-контроллера. После этого для восстановления данных с массива придётся искать точно такой же контроллер, а это не всегда возможно (а если и возможно, то может быть небыстро).
В этом смысле софт-рэйд гораздо менее уязвим.
На самом деле RAID 10 (или 1+0) это не тоже, что RAID 0+1 (или 01).
Порядок имеет значение.
Даже если в теоретических статьях про RAID и пишут, что в теории RAID-5 должен быть быстрее, но практика показывает, что на реальных массивах, с реальными дисками и с реальными задачами чтения/записи RAID-5 массив оказывается медленнее. Это факт, многократно проверенный на практике.
Как вообще можно понятие Fibre Channel ставить в один ряд с SATA или SAS? Это вообще несравнимые понятия совершенно разных категорий. А уж писать рядом с FC какую-то частоту вращения это вообще феерический бред.
Вы вообще работали на практике с сетями хранения данных (SAN)? С инфраструктурой Fibre Channel (FC-адаптеры, FC-патч-корды, FC-коммутаторы) или с iSCSI? С дисковыми стораджами (не обязательно Enterprise-уровня Hi-End, хотя бы Low-end типа HP MSA)? Если нет, то об этом вообще, наверное, даже не стоило упоминать. Потому что получается что-то вроде «слышал звон, а не знает, где он». Уж извините за прямоту.
Ну и моё резюме:
Статья, хоть и набрала кучу плюсов, но мне в целом не понравилась.
Текст состоит из хорошо известных (даже очевидных) фактов о RAID-массивах, плюс добавлены какие-то домыслы, явные ошибки вычисления, и мистификации, притянутые за уши.
Сложилось впечатление, что автор знаком с предметом обсуждения очень поверхностно. Возможно, сам попробовал на практике парочку типов рэйд-массивов (на домашнем десктопе?), а основную часть информации почерпнул в виде голой теории из книжек, википедии и хардварных статей и обзоров.
Мне было бы приятнее прочесть статью от многоопытного практика, а не от теоретика.
В этом смысле софт-рэйд гораздо менее уязвим.
такая комбинация называется RAID-0+1 или RAID-10У вас в статье это прозвучало так, как будто это одно и тоже.
На самом деле RAID 10 (или 1+0) это не тоже, что RAID 0+1 (или 01).
Порядок имеет значение.
Правда обычно быстродействие дисковой группы резко падает, так как при чтении и записи выполняются дополнительные операции вычислений избыточности и восстановления целостности данных.Вы здесь упоминаете только о падении скорости чтения/записи RAID-5 массива в режиме восстановления. Но немаловажным аргументом против RAID-5 также является низкая скорость чтения/записи даже в обычном штатном режиме. Эта скорость у RAID-5 заметно ниже, чем даже у одиночного диска.
Даже если в теоретических статьях про RAID и пишут, что в теории RAID-5 должен быть быстрее, но практика показывает, что на реальных массивах, с реальными дисками и с реальными задачами чтения/записи RAID-5 массив оказывается медленнее. Это факт, многократно проверенный на практике.
В случае любого отказа, даже самого маленького, даже, быть может, не отказа диска целиком, а просто сбоя чтения из за помехи, или проблем с кабелями, вы теряете всю на нем информацию.Это не так. Из-за единичной ошибки чтения не будет потери всех данных (разве что искажение или потеря одного файла, куда входит сбойный сектор).
диски класса Enterprise также делятся на диски SATA (скорость оборотов 7200RPM) и SAS или FC (со скоростями вращения 10K и 15K RPM).Что вы здесь называете дисками FC? Под аббревиатурой FC вы имели в виду Fibre Channel? Но причём тут вообще Fibre Channel? FC — это всего лишь среда передачи команд/данных между сервером и дисковым массивом, а внутри самого дискового массива набиты всё те же диски SCSI, SAS ил даже SATA.
Как вообще можно понятие Fibre Channel ставить в один ряд с SATA или SAS? Это вообще несравнимые понятия совершенно разных категорий. А уж писать рядом с FC какую-то частоту вращения это вообще феерический бред.
Вы вообще работали на практике с сетями хранения данных (SAN)? С инфраструктурой Fibre Channel (FC-адаптеры, FC-патч-корды, FC-коммутаторы) или с iSCSI? С дисковыми стораджами (не обязательно Enterprise-уровня Hi-End, хотя бы Low-end типа HP MSA)? Если нет, то об этом вообще, наверное, даже не стоило упоминать. Потому что получается что-то вроде «слышал звон, а не знает, где он». Уж извините за прямоту.
Ну и моё резюме:
Статья, хоть и набрала кучу плюсов, но мне в целом не понравилась.
Текст состоит из хорошо известных (даже очевидных) фактов о RAID-массивах, плюс добавлены какие-то домыслы, явные ошибки вычисления, и мистификации, притянутые за уши.
Сложилось впечатление, что автор знаком с предметом обсуждения очень поверхностно. Возможно, сам попробовал на практике парочку типов рэйд-массивов (на домашнем десктопе?), а основную часть информации почерпнул в виде голой теории из книжек, википедии и хардварных статей и обзоров.
Мне было бы приятнее прочесть статью от многоопытного практика, а не от теоретика.
У вас в статье это прозвучало так, как будто это одно и тоже.
На самом деле RAID 10 (или 1+0) это не тоже, что RAID 0+1 (или 01).
Я в курсе различий, но так как статья называется не «Почему RAID-10 — »мастхэв", и основная тема не о том, «что такое RAID?», все эти подробности было принято опустить. Я и так, в процессе редактирования перед публикаций сократил статью примерно на треть.
Ну ещё к минусу всех аппаратных рэйдов можно добавить неизбежные трудности при гибели самого аппаратного RAID-контроллера.
Снова повторю, это детали, которые не относятся к основной теме статьи. Статья на хабре это не статья в научном журнале, и не книга «о RAID». Многие детали, не касаюшиеся напрямую главной темы изложены только поверхностно, для общего понимания, а на темы жестких лисков можно говорить часами, вот только всем ли хватит тепрения слушать. «Научпоп» диктует определенную поверхностность и сжатость.
Вы здесь упоминаете только о падении скорости чтения/записи RAID-5 массива в режиме восстановления. Но немаловажным аргументом против RAID-5 также является низкая скорость чтения/записи даже в обычном штатном режиме.
Эти детали вновь не относятся к основной теме статьи.
> Это не так. Из-за единичной ошибки чтения не будет потери всех данных (разве что искажение или потеря одного файла, куда входит сбойный сектор).
У меня есть другие сведения :)
то вы здесь называете дисками FC? Под аббревиатурой FC вы имели в виду Fibre Channel? Но причём тут вообще Fibre Channel?
При том, что так эти диски называют производители, и так они известны пользователям.
FC — это всего лишь среда передачи команд/данных между сервером и дисковым массивом,
SCSI это тоже всего лишь «среда передачи команд/данных между сервером и дисковым массивом» ;)
Тем не менее принято называть диски с интерфейсом SCSI именно SCSI-дисками.
Как вообще можно понятие Fibre Channel ставить в один ряд с SATA или SAS? Это вообще несравнимые понятия совершенно разных категорий. А уж писать рядом с FC какую-то частоту вращения это вообще феерический бред.
Запросто. Вы в каком-то мистическом плену относительно FC. Это довольно распространенное заблуждение, как я заметил.
На самом деле дествительно существует физическая разница между дисками «SATA» и «SAS/FC», правда проиводители обычно называют их диски Desktop-class (первые) и Enterprise-class (вторые). Но раз уж в народе закрепилось называть диски «по интерфейсу», последовал этим и я.
В общем «спасибо вам за ваще мнение» (с) Бобук ;)
ЗЫ. Тема о разнице между дисками в планах. Возможно в той статье вы найдете для себя что-то боле подходящее ;)
Я конечно понимаю, что комменту более пяти лет, но не могу не заметить, что бывают диски непосредственно с интерфейсом FC, при этом не оптическим, как мы привыкли в случае с SAN, а медным. Смысл в том, что не нужно транслировать FC в SCSI при общении полки с диском.
Математик-вероятностник а не вероятнист:)
сорри, немного слух режет
сорри, немного слух режет
Ogromnoe spasibo!
У нас таки умерло 2 диска из RAID-5 с интервалом в 1 час что положило всю систему, дополнительно к этому немного подвела резервная копия, данные за недельный срок канули в лету. Так что… ВЕРОЯТНОСТЬ — великая сила.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему RAID-5 — «mustdie»?