TL; DR У меня есть три диска по 2 ТБ и один диск на 500 ГБ на машине под управлением Ubuntu 20.04 с установкой ZFS по умолчанию на небольшой диск. Мой план состоит в том, чтобы разделить большие диски на два раздела каждый, по 2 ГБ (размер раздела bpool по умолчанию) и оставшиеся 2046 ГБ, и сделать мой bpool четырехсторонним зеркалом на 2 ГБ, а мой rpool - гораздо большим RAIDz1 (> 5 ГБ) или RAIDz2 (<3 ТБ). Возможно ли это / разумно, или есть соображения, о которых я не знаю?
Я только что установил Ubuntu 20.04 на машину, чтобы поиграть с возможностями ZFS, и пытаюсь найти лучший способ ее настройки. В машине есть четыре диска (3x 2 ТБ и 1x 500 ГБ). Я использовал установку ZFS по умолчанию с наименьшим диском, поэтому сейчас три больших диска не используются, а маленький диск имеет два раздела, один из которых используется в качестве vdev для одного устройства в bpool, а другой - для rpool. Как только я выясню, как я хочу все настроить, я планирую использовать эту машину как небольшой частный файл, git и веб-сервер. Нагрузка на сервер будет низкой, и любые критические файлы будут по-прежнему копироваться за пределами площадки, поэтому я обычно предпочитаю емкость хранилища производительности и избыточности, но в настоящее время я использую старые диски, поэтому я определенно хочу учитывать отказоустойчивость. Я немного знаком с работой ZFS и использовал ее в прошлом, но у меня нет особого опыта.
Поскольку я понимаю настройку ZFS в Ubuntu и интеграцию с GRUB, мне нужно опасаться возиться с bpool, но, по крайней мере, я хочу, чтобы он имел некоторую избыточность на нескольких физических дисках. Для этого мне, очевидно, нужно добавить больше устройств к vdev bpool, используя другие диски, но поскольку bpool должен оставаться независимым, и я не хочу отдавать весь диск 2 ТБ для пула, который выиграл не требует много места, я подозреваю, что это означает, что лучше всего разбить один (или несколько) из оставшихся дисков и использовать новый раздел (разделы), чтобы превратить vdev bpool в зеркало или RAIDz. Учитывая природу bpool и тот факт, что четыре диска, которые я использую, являются буквально самыми большими дисками, которые у меня были, разного возраста и разной истории, я думаю, что путь к bpool - это просто зеркало через разделы на всех четырех дисках, чтобы свести к минимуму риск отказа сервера.
В остальном, и поскольку я обязательно буду иметь дело с гетерогенными устройствами, если я не хочу тратить пространство впустую, я думаю, что все оставшиеся разделы со всех дисков можно использовать для изменения моей конфигурации rpool на RAIDz vdev, и это Здесь мои знания начинают исчерпывать свои возможности, и у меня есть несколько вопросов:
Конфигурация по умолчанию, которую мне предоставил установщик Ubuntu, - это раздел размером 2 ГБ для bpool и оставшиеся 498 ГБ для rpool. Если я буду следовать приведенному выше плану, моя окончательная конфигурация будет представлять собой четырехкратный резервный пул на 2 ГБ и rpool с одним vdev, состоящим из одного раздела размером 498 ГБ и трех разделов объемом 2044 ГБ, что, как я думаю, при конфигурации RAIDz1 должно - оставьте мне чуть менее 5 ТБ полезного пространства (или чуть более 3 ТБ с RAIDz2).
Есть ли какие-то сложности, которые мне не хватает, или технические ограничения, которые мне следует учитывать?
Проведя дополнительные исследования ситуации, я понял, что у меня есть фундаментальное непонимание того, как работает RAIDz. По какой-то причине я думал, что он будет работать с разнородными устройствами, не тратя впустую пространство, но на самом деле это не так (я, должно быть, только что думал о пуле хранения без избыточности, который я не хочу рассматривать в этом приложении).
Мой новый план состоит в том, чтобы вместо этого просто купить еще один диск на 2 ТБ (не так, как будто они стали дорогими) и заменить им диск на 500 ГБ, чтобы у меня был должным образом однородный набор устройств для работы. Это должно позволить эффективно использовать пространство, не прибегая к экзотической топографии. Если у меня возникнут другие сложности, я создам для них новый вопрос и буду считать, что на него ответ.