Повысить надежность путем разбиения дисков разного размера?


8

Я понимаю, что ZFS предпочтет все диски одинакового размера. Однако в случае, если у меня есть два диска с разным размером (1 ТБ и 1,5 ТБ), я бы хотел иметь определенную избыточность, но не зеркальное отображение. Поэтому я нарезал два диска на 5 разделов, каждый из которых примерно по 500 ГБ, и создал пул "raidz" ... zfs с радостью согласился. Это действительно увеличивает надежность? Смысл в том, что, если диск не полностью сломан, и только часть его выходит из строя, я все равно могу получить доступ к данным?


5
Это не добавляет надежности и снижает производительность.
Майкл Хэмптон

1
Большинство ответов / комментариев, которые я получил, не были достаточно глубокими, чтобы понять причину. Простое «против лучших практик» или «равные диски просто имеют здравый смысл» на самом деле не имеет большого значения для меня. Очевидно, что с учетом этих специфических дисков, которые у меня есть, я не собираюсь выбирать лучших из лучших с точки зрения надежности и производительности. Я спрашиваю, что можно сделать, учитывая, что у меня есть. Кроме того, все меняется: в книге "Master FreeBSD ZFS" ... авторы ясно говорят, что в старые времена / соляриса подготовка всего диска считалась критической, а сейчас - нет. Предоставление на основе разделов так же хорошо или даже поощряется.
python152

Специально для избыточности на основе четности не существует абсолютных требований к одинаковому размеру (я смутно помню, что в книге zfs также говорилось, что один и тот же накопитель от разных производителей в конечном итоге имеет разный размер). Это зависит от того, как алгоритм размещения данных ZFS решит эту проблему, чтобы сбалансировать распределение битов четности и сбалансировать производительность.
python152

@ python152 Это всегда зависит от того, можете ли вы жить с минусами (ZFS действительно достаточно гибок, лучшие практики - это рекомендации, а не правила). Если вы можете принять время простоя и уверены в управлении разделами, замена частично неисправных дисков, например, не так критична. Я все еще опасался бы дыры в записи RAID5, которая существует независимо от того, являются ли ваши резервные устройства дисками, разделами или даже файлами.
user121391 10.10.16

1
@ user121391 ZFS raidz не страдает от дыры в записи RAID5. См. Blogs.oracle.com/bonwick/entry/raid_z и pthree.org/2012/12/05/zfs-administration-part-ii-raidz
nickcrabtree

Ответы:


3

Смысл в том, что, если диск не полностью сломан, и только часть его выходит из строя, я все равно могу получить доступ к данным?

В теории эта мысль верна. Пока вы сталкиваетесь с ошибкой на одном устройстве вашего RAIDZ1 vdev, ZFS может и будет информировать вас и исправлять ошибку, предполагая, что на других устройствах нет ошибок.

Что может отличаться в реальности, так это несколько вещей:

  • Ошибки могут распространяться на разделы, и поэтому будут затронуты два или более устройств, что может привести к неисправимым ошибкам или даже к потере всего пула (в зависимости от местоположения и количества ошибок). Вы можете использовать RAIDZ2 или Z3 для некоторого смягчения этого, но проблема всегда есть.
  • При повторном переносе раздела диск должен считывать (2 раза) и записывать (1 раз) на один и тот же диск одновременно и случайным образом. Если вы не используете Solaris 11.3 с последовательным изменением версии, это будет очень и очень медленно. Пока вы не закончите процесс восстановления, вы будете уязвимы для ошибок в других разделах. Если ваше время восстановления больше, ваш шанс встретить дополнительный URE увеличивается. Это также создает дополнительную нагрузку на накопитель, увеличивая вероятность полного отказа накопителя.
  • Представьте, что ваш третий раздел (последний на диске 1,5 ТБ) показывает достаточно ошибок, чтобы ухудшить пул и потребовать замены. Если вы не можете добавить другой диск, вы не можете выполнить замену без выключения / экспорта, и даже тогда это сложнее, чем обычно.

Исходя из этого, я бы посоветовал не делать этого, если ваша главная цель - надежность. Предполагая фиксированную аппаратную ситуацию, я бы сделал одно из следующего:

  1. Используйте зеркала и теряйте 500 ГБ, но получите простую настройку с возможностью легкого расширения в будущем
  2. Используйте два отдельных пула, и copies = 2если вам нужна некоторая устойчивость к небольшим ошибкам (полный отказ диска приведет к гибели всего 2/5 или 3/5 ваших данных по сравнению с вашей настройкой)
  3. Используйте другие файловые системы, отличные от ZFS, если вы хотите иметь свой торт и есть его тоже

5

То, что вы описываете, немного безвкусно.

ZFS хочет иметь полные диски одинакового размера и возможностей. Это важно по ряду причин, но также имеет смысл.

Все, что вы будете делать в описанной вами ситуации, - это усложнить среду и увеличить свой риск.


1
Не говоря уже о снижении производительности.
Майкл Хэмптон

@MichaelHampton Как это?
кот

2
@cat Потому что ZFS думает, что у вас есть пять шпинделей, а на самом деле их два.
Майкл Хэмптон

4

Скажем так:

  • Если у вас есть 1 ТБ данных на первом диске, вы можете скопировать их на второй диск, и вы можете позволить себе потерять любой из них.

  • Если у вас есть 1,5 ТБ данных на втором диске, вы можете реплицировать только первый 1 ТБ данных на первый диск. В этом случае, если диск два выйдет из строя, вы потеряете данные.

ZFS очень способна, но, как правило, согласно двум пунктам выше, смешанные настройки диска глупы и не являются супер-полезными. Если вы заботитесь о надежности и избыточности, представьте, что второй диск тоже всего 1 ТБ.


4
Я помещаю этот бит в комментарий, потому что я не чувствую, что он действительно вписывается в «ответ» как таковой, но если бы вы действительно хотели использовать все пространство на ваших дисках, я бы настроил зеркало размером 1 ТБ, и затем используйте последние 500 ГБ в качестве обычного тома без репликации для пустого пространства и временных файлов, которые меня не особо интересуют (например, папка для загрузки в браузере - приятно, что старые вещи кешируются там, но я бы ничего не сделал на самом деле скучаю если я его потерял).
Бенни Макни
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.