Я рассматриваю FreeNAS и хочу заранее убедиться, что мое понимание того, что я могу/не могу делать с хранилищем в нем, верно.
Первоначальная конфигурация: 1 пул хранения с 2 дисками по 6 ТБ, зеркально отображающими друг друга; общая эффективная емкость составляет 6 ТБ (без учета округления и накладных расходов).
Первое расширение (через 2,5–3 года): Добавить 2 диска по 12 ТБ на сервер. Настроить их как вторую зеркальную пару и добавить их в существующий пул хранения; увеличить доступное хранилище до 18 ТБ.
Вторая фаза расширения 1 (через 5,5–7,5 лет): Добавить 2 диска по 24 ТБ на сервер. Настроить их как зеркальную пару и добавить их в существующий пул хранения; увеличить доступное хранилище до 42 ТБ.
Вторая фаза расширения 2 (сразу после фазы 1): Перенести все данные с дисков по 6 ТБ, удалить их из пула, а затем физически с сервера. Оставшийся доступный объем хранилища 36 ТБ.
Мои мысли по этому поводу таковы:
Удвоение необходимой емкости хранилища каждые почти 3 года — это продолжение моего опыта работы с серверами WHS с 2008 года по настоящее время.
После добавления дисков на 24 ТБ, диски на 6 ТБ обеспечат лишь незначительную часть общего хранилища (1/7) и уже достаточно устарели, так что надежность станет более серьезной проблемой, если я оставлю их (неправильная сторона кривой ванны). Если они выживут, то при моих темпах роста это лишь увеличит время до того, как мне понадобится покупать диски на 48 ТБ, чуть больше, чем на полгода; так что они не дадут мне много времени.
Ограничившись четырьмя дисками, я могу использовать компактный форм-фактор mini-ITX для своего NAS. Если я выберу больше, то это будет более крупная и дорогая установка. (2 диска, стоящие наверху открытого корпуса с торчащими проводами, приемлемы на день-два переходного периода, но не на более длительный срок.)
Я также предполагаю, что дела по-прежнему будут идти по нарастающей относительно доступности дисков большего объема, как это было в моих предыдущих обновлениях примерно 3 года назад: 1,5-3 ТБ (2012) и 3-6 ТБ (сейчас/в ближайшем будущем). И что любые новые диски, которые появятся, будут достаточно надежными, чтобы их можно было использовать (т. е. рейд-апокалипсис никогда не случится).
решение1
Прежде всего:Я не собираюсь строить предположения о развитии событий на 6-7 лет вперед.Речь идет о сегодняшнем дне и ближайшем будущем.TL;DR, см. конец этого ответа.
ZFS сегодня не позволяет вам удалить vdev из пула. Он также не имеет собственной функциональности "перебалансировки" (поискпереписывание указателя блока,переписать бпилипереписать bpoчтобы узнать больше об этом). ZFSделаетпозволяют снизить уровень избыточности зеркалируемого, но не raidzN, vdev, но это не то, что вам нужно. (В ZFS чередование — это то, что вы получаете, когда ничего не говорите.)
В принципе, пулы можно рассматривать как чередующиеся наборы, состоящие из одного или нескольких устройств хранения каждый, только последние из которых (vdev) могут быть организованы в избыточной конфигурации. Вы можете настроить каждый vdev для произвольно высоких уровней избыточности, нокаждыйvdev в пуле должен оставаться выше своего порога избыточности, чтобы пул был полностью функциональным. Если vdev выходит из строя,в лучшем случаевы теряете только те данные, которые хранились на этом vdev, и нет возможности активно контролировать, какие данные сохраняются на тех или иных vdev (кроме помещения их в отдельные пулы, что имеет другие недостатки).
Когда у вас есть "зеркальный" пул, такой как тот, который вы описали после первого расширения, на самом деле у вас есть два vdev, каждый из которых состоит из зеркальной пары физических устройств хранения, где два vdev чередуются для формирования пула. Пул из двух vdev, два диска-каждый-зеркало, может быть выведен из строя одним отказавшим диском иодиндосадная ошибка на другом диске в этом наборе зеркал, даже если другой набор зеркал работает идеально. В случае такого сбоя, независимо от того, что еще произойдет, вы потеряете некоторые данные.
Обычный способ увеличения емкости пула ZFS —замените диски на местес большими, позвольте пулу перенести данные на новый диск, а затем физически удалите старый диск, который больше не используется. Обычно zpool replaceдля этого хотят использовать как старый, так и новый подключенный диск, чтобы поддерживать желаемый уровень избыточности на протяжении всего процесса. Обычная альтернатива — добавлять vdev с тем же уровнем избыточности, что и существующие vdev в пуле. Опять же, обратите внимание, что поскольку ZFS не поддерживает удаление части чередующегося набора, а пулы состоят исключительно из чередующихся vdev, вы не можете удалить vdev после того, как вы его добавили. Многие новички в ZFS попадают в эту ловушку, и легко ошибиться, если не обращать внимания на точные команды, которые вы используете.
Из-за того, как работают ZFS resilver, resilvering является мучительно болезненным для задействованных дисков. В то время как традиционные RAID resilver обычно в основном последовательны с небольшим количеством случайных операций ввода-вывода, перемежающихся с действиями пользователя, ZFS resilver — это почти полностью случайные операции ввода-вывода, перемежающиеся со случайными операциями ввода-вывода, перемежающимися с действиями пользователя. Зеркальный набор видел в основном одну и ту же активность на протяжении всей своей жизни; если один диск является маргинальным или даже умер, вполне возможно, что другой диск также в лучшем случае является маргинальным. Если он будет страдать от сурового испытания resilvering в течение нескольких дней подряд, это может очень легко вывести его из строя. (Основываясь на личном опыте, я бы предположил, что для resilvering 6 ТБ данных вы смотрите на процесс resilvering продолжительностью примерно в неделю. Даже если вы повернете все ручкидо 11, основываясь на чистой последовательной пропускной способности (что совершенно нереально, учитывая формат ZFS на диске и стратегию переноса избыточности), вы смотрите напо меньшей мере(около 17 часов чистого ужаса для диска. Я думаю, что не будет способа уменьшить 6 ТБ resilver до менее чем вдвое большего, или полутора дней прямого издевательства над диском.)
Я бы также имел очень серьезные сомнения относительно конфигурации зеркала 2x24 ТБ или даже 2x12 ТБ, если предположить, что такие диски материализуются; мы уже немного раздвигаем границы физики (без каламбура) с текущими размерами дисков. Предполагая надежность дисков, с точки зренияУРЕ, остается похожим на сегодняшний день (от 10^-14 до 10^-15 ошибок сектора на бит чтения, что является показателем, который завис на протяжении целой вечности в технических характеристиках производителей), статистически вы не сможете выполнить полное чтение вашего диска объемом 12 ТБ, не столкнувшись хотя бы с одной ошибкой (12 ТБ — это примерно 9×10^13 бит, что округляется до 10^14). К тому времени, как вы перейдете на диски объемом 24 ТБ, статистически вы столкнетесь спо меньшей мереодна или две ошибки полного сектора за один полный проход чтения (потому что вы считываете около 2*10^14 бит). Даже если вы используете диски 10^-15 URE, это не принесет вам многого (тогда вы смотрите на пять проходов чтения, а не на половину прохода чтения). Это, конечно, статистика и спецификации; на практике ошибки чтения имеют тенденцию группироваться вместе, и диск может безотказно работать в течение многих, многих полных считываний, прежде чем он в какой-то момент начнет выдавать ошибки слева, справа и в центре.
Учитывая, что большинство несерверных спиннеров имеют гарантию всего 1-3 года, я бы не рассчитывал на то, что какой-либо комплект проработает намного дольше, в то время как ваш план требует, чтобы они оставались функциональными по крайней мере шесть лет до замены. Даже серверные спиннеры обычно имеют гарантию только пять лет, хотя обычно это пять лет круглосуточной работы. Мой личный опыт показывает, что высококлассные потребительские диски, такие как серия Constellation ES от Seagate, могут обеспечить почти такой уровень нагрузки, прежде чем сдаться и отправиться в рай для данных. (Личный анекдот: у меня был Constellation ES.2 емкостью 1 ТБ, который я использовал примерно 4 года 9-10 месяцев к тому времени, как он начал странно себя вести, хотя я никогда не доводил его до отказа.)
В общем, учтите, что многие люди, использующие ZFS, переходят на двойную избыточность, как только размеры spinner достигают отметки 3-4 ТБ или меньше для более важных данных. Для этого есть веская причина:устройства хранения данных выходят из строяи этопроисходит с тревожной частотой. В случае ZFS вы также смотрите на гораздо более дорогие услуги по восстановлению данных, если вы хотите что-то большее, чем возврат сырых битов, которые все еще можно прочитать с пластин, и я не знаю ни одного программного обеспечения для восстановления данных, которое может даже удаленно управлять пулами ZFS. Если ZFS не может импортировать ваш пул, наиболее практичным ответом часто является то, что любые данные на нем, которые вы не сделали резервной копии, считаются потеряннымив другом месте.
Чтобы ответить на вопрос заголовка и TL;DR
Позволит ли FreeNAS/ZFS управлять моим хранилищем таким образом?
В строго техническом смысле, да, должно быть. Однако, яДействительновообще не рекомендовал бы.Вы слишком сильно превышаете эксплуатационные возможности оборудования.чтобы я чувствовал себя комфортно с ней, не говоря уже о том, чтобы одобрять ее. (Обратите внимание, что этот ответ будет практически одинаковым, независимо от того, о какой файловой системе вы спрашиваете.)