RAIDZ1 хуже отказоустойчивости для массива 4 ТБ дисков?


1

На этот вопрос , Майкл Кьёрлинг а также user121391 похоже, что дело в том, что RAIDZ1 (эквивалент ZFS для RAID5) не надежен, и что я должен использовать RAIDZ2 (эквивалент RAID6 для ZFS). user121391 комментирует там:

При восстановлении неисправного диска все данные со всех дисков должны быть   читать. Это увеличивает нагрузку на диски (особенно если они   в основном бездействует нормально) и поэтому шанс другого драйва   терпит неудачу. Кроме того, при чтении всех данных вы можете получить URE от   один из дисков без второго диска для компенсации, что означает файлы   может быть поврежден / потерян. В-третьих, чем больше ваши диски, тем дольше ваши   окно уязвимости становится не только для этих проблем, но и для любого   проблемы, которые могут возникнуть на дисках или в системе (отключение питания и т. д.)

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

Мой вопрос - является ли RAIDZ1 постепенным улучшением отсутствия отказоустойчивости, учитывая, что я не хочу жертвовать более чем 25-33% общего размера пула на службу отказоустойчивости, или это резко увеличит шансы на то, что в случае сбоя одного диска весь пул полностью выйдет из строя, что приведет к полной потере данных.

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


1
Для полноты, особенно для тех, кто не знаком с ZFS: RAIDZ1 примерно эквивалентен RAID 5 (с чередованием с одинарной четностью).
a CVn

Логика в вашем цитируемом ответе не удалась. Как может быть RAIDZ1 Меньше Надежнее, чем нет отказоустойчивости? Без отказоустойчивости любой сбой диска делает пул непригодным для использования. В случае RAIDZ1 время восстановления может быть долгим после замены диска, а восстановление пула создает нагрузку на существующие диски еще принимает два сбои, вызывающие сбой пула. Несмотря ни на что, пул RAIDZ1 Можно пережить отказ одного привода. Не отказоустойчивый пул просто не может ,
Andrew Henle

@AndrewHenle Пожалуйста, обратитесь к связанному потоку для большего контекста, вопрос был «Вероятнее ли, что у меня разовьются два отказа дисковода, если я использую RAIDZ1, чем если я не использую RAID?». Таким образом, ответ был о вероятности отказа двух дисков без учета первой ошибки. В этом случае может быть лучше разрешить всем дискам работать как базовые vdevs (отдельные пулы, не чередующиеся), чем создавать один пул Z1 (в то время как ваш ответ остается верным для Z1 против базовых vdevs в одном пуле для первой ошибки диска ).
user121391

Ответы:


1

Я думаю, что это было недоразумение в старой теме. Я сравнивал вероятность сбоя для двух дисков подряд при использовании либо рейда с проверкой четности Z1, либо без RAID (как вы указали в комментариях в другом потоке). На мой взгляд, это никогда не касалось Z1 против полосатого пула базовых vdevs, потому что эта игра, по сути, окончена после первой ошибки, поэтому Z1, конечно, лучше.

Но если вы просто сравниваете несколько независимых пулов с одним пулом с одним vdev Z1, тогда проблема увеличения нагрузки при пересчете информации о четности сохраняется.

При сравнении Z1 против Z2, о котором в основном говорил Михаил, применимы два других пункта. Я должен был быть более четким в комментариях, но, к сожалению, они ограничены в пространстве. Я надеюсь, что этот ответ кое-что прояснит.

Я думал о том же, но я не осознавал, что URE не просто переворачивает, он портит весь бассейн

Если мы упростим все это, у вас будет диск с микросхемой контроллера внизу и аппаратное обеспечение (контроллер RAID) или программное обеспечение (например, ZFS) сверху.

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

Некоторые диски имеют функцию под названием TLER (восстановление с ограничением по времени), которая является жестким тайм-аутом, который ограничивает это время исправления ошибок до 6-9 секунд, потому что традиционно большинство аппаратных RAID-контроллеров сбрасывают весь диск через 9 секунд, поэтому один плохой Сектор не должен делать весь диск недоступным, но должен исправляться «хорошим» сектором на других дисках (функция, на которую не может положиться один диск в настольной системе, поэтому предпочтителен длительный тайм-аут).

Теперь давайте посмотрим на сторону программного обеспечения: если вы сконфигурируете свой raid-контроллер или файловую систему ZFS с избыточностью, например, используя зеркальные диски или зеркало vdev в качестве основы для вашего пула, ваш URE можно исправить. Если вы не используете избыточность, данные по этому сектору исчезнут. Это могут быть данные, которые вас интересуют, или просто случайные старые временные данные или ничего, в зависимости от вашей удачи. То же самое относится и к битовым переворотам, хотя вероятность их возникновения, похоже, больше зависит от внешних воздействий (например, космического излучения).

Поскольку RAID0 не подлежит URE, вопрос заключается в том, "что более вероятно, URE в RAIDZ или сбой диска в RAID0?"

Я не принял этот ответ, потому что я не думаю, что он адекватно объясняет соответствующие моменты, но я планировал создать свой собственный ответ, как только я пойму, почему URE разрушают весь пул, если никто другой не доберется до него первым.

Я предлагаю вам прочитать базовое объяснение структуры пула ZFS. Подводя итог наиболее важных битов:

  • Вы можете создавать виртуальные устройства (vdevs) из дисков, разделов или файлов. Каждый vdev может быть создан с разной избыточностью: базовая (без резервирования), зеркальная (от 1 до N дисков может выйти из строя), рейд контроля четности Z1 / Z2 / Z3 (1/2/3 диски могут выйти из строя). Все резервирование работает на уровне vdev.
  • Вы создаете пулы хранения из одного или нескольких vdevs. Они всегда чередуются, поэтому потеря одного vdev означает потерю всего пула.
  • Вы можете иметь любое количество независимых пулов. Если один пул потерян, другие пулы продолжают функционировать.

Поэтому вы можете обосновать следующее:

  • Если возможно, предпочтите Z2 вместо Z1 из-за увеличенной нагрузки и большого (отрицательного) шанса при восстановлении больших дисков (большие из которых больше чем 1 ТБ приблизительно)
  • Если вам нужно выбрать между Z1 и несколькими базовыми vdevs, предпочтите Z1 из-за исправления битовых ошибок, что невозможно с базовыми vdevs
  • Если вы можете принять частичную потерю пула, сегментируйте свой пул на несколько меньших пулов, каждый из которых поддерживается одним vdev, чтобы вы получали информацию о контрольной сумме и быстрее восстанавливали время при неисправимых сбоях.

В любом из вышеперечисленных случаев вам необходимо иметь резервную копию. Если вы не можете или не хотите позволить себе какую-либо резервную копию, это то, что вам удобнее потерять - некоторые части пула с большей вероятностью или все с меньшей вероятностью. Я лично выбрал бы первый вариант, но вы можете решить иначе.


1

В ответе, который вы цитировали, подразумевается, что с увеличением емкости хранилища вероятность сбоя увеличивается соответственно не только для восстановления работы, но и для нормальной работы. Итак, по статистике, RAIDZ1 не более отказоустойчив, чем Raid 0, когда речь идет о современных дисках емкостью 4 ТБ, даже если это доказано на первый взгляд.

Поэтому некоторые утверждают, что RAIDZ1, на самом деле, не увеличивает защиту от потери данных на жестких дисках большой емкости. Это имеет меньшее отношение к механическому отказу привода (ов) или, по крайней мере, к критическому отказу. URE, проще говоря (и очень упрощенно), - это неспособность читать. Будь то из-за длительного чтения из плохого сектора диска, из-за отсутствия диска в свободных секторах или по любой другой причине - это не проблема. Это случится, нравится вам это или нет. Затем давайте возьмем пример с плохим сектором. Обычно это обрабатывается внутренним накопителем, но если их достаточно, или накопителю понадобится время, чтобы исправить, что контроллер RAIDZ может интерпретировать задержку как сбой накопителя и извлечь его. Теперь давайте представим, что это ВТОРОЙ жесткий диск в пуле, и это произошло при восстановлении ... Единственное жизнеспособное решение - очистить массив от этих ошибок - если обнаружится раньше, ошибка будет просто отрыжкой - пул легко восстановит данные. Но это означает, что нагрузка на накопители довольно велика, что резко увеличивает статистические шансы URE (помните: возраст, запись, объем данных - все это уже значительно увеличивается, без увеличения чтения на порядок при обычных операциях; все для каждого диска отдельно).

Таким образом, ответ на ваш вопрос ( is a RAIDZ1 an incremental improvement on no fault tolerance ) это: не совсем. Если мы используем логику цитаты, вы сталкиваетесь с 50% -ной вероятностью (я думаю) достаточного количества сбоев диска, чтобы данные не могли быть восстановлены в течение первых двух лет работы диска

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


Я не очень понимаю это. Как это менее отказоустойчиво, чем RAID0? Согласно числу «один сбой в 10e14», существует вероятность 1/10000 одновременного сбоя в дисках на чтение ТБ. Это приведет к перевороту в пуле. Даже при выходе из строя одного диска, разве вы не ожидаете примерно 1% вероятности на терабайт, что один бит перевернется во время исправления ошибки? Похоже, я бы восстановил большую часть диска, явное улучшение по сравнению с «потерян весь пул»
Paul

@Paul - Извините, если я покажусь ироничным или хуже, но здесь идет речь: с каких пор "не более отказоустойчивый, чем" равно "менее отказоустойчивый, чем"? Что касается отдыха: по статистике вы можете ожидать, что из каждых 4 дисков большой емкости, которые вы используете, 2 выйдут из строя в течение 2 лет (необязательно катастрофически - достаточно URE). Подсчитайте для себя, как RAIDZ1 защитит вас от этого (согласно 25-33% экономии памяти, которую вы указали)? Не говоря уже о том факте, что аппаратный сбой на самом деле не является типом сбоя, о котором вам следует беспокоиться с таким маленьким массивом ...
AcePL

RAIDZ1 не более отказоустойчив, чем Raid 0, если говорить о современных дисках объемом 4 ТБ Это просто не может быть правдой. Поскольку вы утверждаете, что после сбоя диска в массиве RAIDZ1, состоящем из 4 ТБ дисков, второй БУДУТ потерпеть неудачу до завершения восстановления.
Andrew Henle

1
Нет, я утверждаю, что существует статистически высокая вероятность ЛЮБОГО вида неисправностей (механический из которых меньше всего беспокоит), который выше в зависимости от емкости диска, возраста, количества операций чтения и т. Д., Которые могут быть не поддающимися исправлению, ДО диска уже не удалось. Проблема с URE состоит в том, что, если они не будут активно следить за массивом, у них будет неприятная привычка высовываться при перестройке.
AcePL

@AndrewHenle Я думал о том же, но я не понимал, что URE - это не просто переворот, это портит весь пул. Поскольку RAID0 не подлежит URE, вопрос заключается в том, "что более вероятно, URE в RAIDZ или сбой диска в RAID0?" Я не принял этот ответ, потому что я не думаю, что он адекватно объясняет соответствующие моменты, но я планировал создать свой собственный ответ, как только я пойму, почему URE разрушают весь пул, если никто другой не доберется до него первым.
Paul
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.