Прежде всего: я не собираюсь рассуждать о развитии через 6-7 лет. Это о сегодняшнем дне и ближайшем будущем. Для TL; DR см. Нижнюю часть этого ответа.
ZFS сегодня не позволяет вам удалить vdev из пула. Он также не имеет никакой встроенной функции "перебалансировки" (ищите перезапись блочного указателя, переписывание bp или переписывание bpo, чтобы узнать больше об этом). ZFS это позволяет снизить уровень резервирования Зеркалированного, но не raidzN, VDEV, но это не то , что вы хотите. (В ZFS чередование - это то, что вы получаете, когда ничего не говорите.)
По сути, пулы могут рассматриваться как чередующиеся наборы, состоящие из одного или нескольких запоминающих устройств каждое, только последнее из которых (vdevs) может быть расположено в избыточной конфигурации. Вы можете настроить каждый vdev для произвольно высокого уровня избыточности, но каждый vdev в пуле должен оставаться выше порогового значения избыточности, чтобы пул был полностью функциональным. Если происходит сбой vdev, в лучшем случае вы теряете только те данные, которые были сохранены на этом vdev, и нет никакого способа активно контролировать, какие данные будут храниться на каком vdevs (кроме размещения их в отдельных пулах, что имеет другие недостатки).
Когда у вас есть "зеркальный" пул, такой как тот, который вы описали после первого расширения, у вас действительно есть два vdevs, каждый из которых состоит из зеркальной пары физических устройств хранения, где два vdevs чередуются для формирования пула. Пул с двумя-vdev два диска-каждого-зеркала может быть отключен одним неисправным диском и одной неудачной ошибкой на другом диске в этом наборе зеркал, даже если другой комплект зеркал работает отлично. В случае такого сбоя, что бы ни случилось, вы потеряете некоторые данные.
Обычный способ увеличения емкости в пуле ZFS - заменить имеющиеся на месте диски более крупными, разрешить повторное размещение пула на новом диске и затем физически удалить старый диск, который больше не используется. Обычно для этого требуется использовать zpool replace как со старым, так и с новым подключенным диском, чтобы поддерживать желаемый уровень избыточности на протяжении всего процесса. Обычная альтернатива - добавить vdevs с тем же уровнем избыточности, что и существующие vdevs в пуле. Опять же, обратите внимание, что поскольку ZFS не поддерживает удаление части чередующегося набора, а пулы состоят строго из чередующихся vdevs, вы не можете удалить vdev, как только добавите его. Многие новички в ZFS попадают в эту ловушку, и легко запутаться, если вы не обращаете внимания на те команды, которые вы используете.
Из-за того, как работают ресиверы ZFS, резильвертинг мучительно болезнен для задействованных накопителей. В то время как традиционные преобразователи RAID обычно в основном последовательные, с небольшим количеством случайных операций ввода-вывода, чередующихся с пользовательской активностью, повторные серверы ZFS являются практически полностью случайными операциями ввода-вывода, чередующимися со случайными операциями ввода-вывода от пользовательских действий. Зеркальный набор видел в течение своей жизни в основном одну и ту же деятельность; если один диск маргинальный или даже умер, вполне возможно, что другой диск также в лучшем случае маргинальный. То, что оно будет страдать от повторяющихся испытаний в течение многих дней, может очень легко толкнуть его через край. (Исходя из личного опыта, я бы предположил, что для восстановления 6 ТБ данных вы смотрите примерно на неделю процесса восстановления. Даже если вы повернете все ручки до 11, основываясь на чистой последовательной пропускной способности - что совершенно нереально, учитывая формат диска ZFS и стратегию переноса данных, - вы ожидаете по меньшей мере около 17 часов ужаса для накопителя. Мое лучшее предположение состоит в том, что не было бы никакого способа снизить сопротивляемость 6 ТБ до уровня, который может быть вдвое меньше, или полтора дня, от прямого злоупотребления драйвом.)
У меня также были бы очень серьезные сомнения относительно конфигурации зеркала 2x24 ТБ или даже 2x12 ТБ, предполагая, что такие диски материализуются; мы уже немного раздвигаем границы физики (без каламбура) с текущими размерами дисков. Если предположить, что надежность диска, с точки зрения URE, остается схожей с сегодняшней (от 10 ^ -14 до 10 ^ -15 ошибок сектора на чтение бита, и это то же самое, что и навсегда, как указано в листах данных производителя), статистически вы не будете возможность выполнить полное чтение диска 12 ТБ, не обнаружив хотя бы одной ошибки (12 ТБ - это примерно 9 × 10 ^ 13 бит, что хорошо округляется до 10 ^ 14). К тому времени, когда вы добавите это на диски емкостью 24 ТБ, по статистике вы получите по крайней мере одну или две ошибки полного сектора за один проход полного чтения (потому что вы читаете около 2 * 10 ^ 14 бит). Даже если вы используете 10 ^ -15 дисков URE, это не будет вам дорого стоить (тогда вы смотрите на пять проходов чтения, а не половину прохода чтения). Это, конечно, статистика и спецификации; на практике ошибки чтения имеют тенденцию к кластеризации вместе, и накопитель может обеспечить бесперебойную работу для многих, многих полных операций чтения, прежде чем он в какой-то момент начнет выдавать ошибки влево и вправо и в центр.
Учитывая, что большинство несерверных спиннеров имеют гарантию только на 1-3 года, я бы не стал рассчитывать, что какой-либо набор будет продолжать работать гораздо дольше этого, в то время как ваш план требует, чтобы они оставались работоспособными в течение как минимум шести лет, прежде чем их заменят. , Даже серверные счетчики обычно имеют гарантию только на пять лет, хотя обычно на работу в режиме 24x7 обычно пять лет. Мой личный опыт показывает, что потребительские диски высокого класса, такие как серия Constellation ES от Seagate, могут обеспечить почти такой уровень обязанностей, прежде чем отдать призрака и попасть в рай для данных. (Личный анекдот: Созвездие 1 ТБ ES.2 У меня было что-то вроде 4 лет 9-10 месяцев к тому моменту, когда он начал вести себя забавно, хотя я никогда не доводил это до отказа.)
В общем, учтите, что многие люди, использующие ZFS, используют двойную избыточность после того, как размеры счетчика достигают отметки 3-4 ТБ или меньше для получения более важных данных. Для этого есть веская причина: устройства хранения данных выходят из строя, и это происходит с пугающей частотой. В случае ZFS вы также обращаете внимание на гораздо более дорогие сервисы восстановления данных, если вам нужно что-то помимо того, чтобы возвращать вам необработанные биты, которые все еще доступны для чтения с пластин, и я не знаю ни о каком программном обеспечении для восстановления данных, которое может даже удаленно обрабатывать пулы ZFS. Если ZFS не может импортировать ваш пул, наиболее практичным ответом часто будет считать потерянные данные, которые вы не создавали в другом месте.
Ответить на заглавный вопрос и TL; DR
Позволит ли FreeNAS/ZFS мне управлять моим хранилищем таким образом
В чисто техническом смысле да, так и должно быть. Однако я действительно не рекомендовал бы это вообще. Вы слишком сильно раздвигаете операционную оболочку оборудования, чтобы я чувствовал себя комфортно с ним, не говоря уже об одобрении. (Обратите внимание, что этот ответ будет практически одинаковым независимо от файловой системы, о которой вы спрашивали.)
