Вы можете добавить устройства в пул после того, как он был создан, но не совсем так, как вы представляете.
С ZFS единственная избыточная конфигурация, к которой вы можете добавить устройства, это зеркало. В настоящее время невозможно создать raidzN vdev с дополнительными устройствами после его создания. Добавление устройств к зеркалу увеличивает избыточность, но не доступную емкость хранилища.
Это можно обойти в некоторой степени, создав raidzN vdev требуемой конфигурации, используя разреженные файлы для устройств резервирования , затем удалив разреженные файлы перед заполнением vdev данными. Как только у вас появятся диски, вы можете zpool replace
использовать их (в настоящее время не существует). Проблема использования этого подхода в качестве не просто пути перехода к более идеальному решению состоит в том, что пул будет постоянно показывать, DEGRADED
что означает, что вам нужно смотреть гораздо внимательнее, чтобы распознать любое фактическое уменьшение хранилища; следовательно, я действительно не рекомендую это как постоянное решение.
Добавление устройств в пул ZFS на самом деле сопряжено с серьезным риском снижения устойчивости пула к сбоям, потому что все vdev-ы верхнего уровня должны быть функциональными, чтобы пул функционировал. Эти vdevs верхнего уровня могут иметь избыточные конфигурации, но не обязательно; вполне возможно запустить ZFS в конфигурации в стиле JBOD, и в этом случае сбой одного устройства с большой вероятностью приведет к разрушению пула. (Плохая идея, если вы можете избежать этого, но все же дает вам много возможностей ZFS даже в конфигурации с одним диском.) По сути, резервный пул ZFS состоит из комбинации JBOD одного или нескольких избыточных vdevs; не избыточный пул ZFS состоит из комбинации JBOD одного или нескольких vdevs JBOD.
Добавление vdevs верхнего уровня также не заставляет ZFS балансировать данные на новых устройствах; в конечном итоге это происходит для данных, которые перезаписываются (из-за характера копирования файлов при записи в системе и предпочитают vdevs с большим свободным пространством ), но это не происходит для данных, которые просто находятся там и читаются, но никогда не перезаписываются. Вы можете сделать это, переписав данные (например, с помощью zfs send | zfs recv
предположения, что дедупликация не включена для пула), но для этого необходимо предпринять определенные действия.
Исходя из чисел в вашем посте, у вас есть:
- 4 × 2 ТБ дисков
Диски 2 × 4 ТБ
примерно 8 ТБ данных
Поскольку вы говорите, что хотите иметь избыточную конфигурацию, учитывая эти ограничения (особенно набор доступных дисков), я бы, вероятно, предложил сгруппировать диски в виде зеркальных пар. Это даст вам макет пула, как это:
- бак
- зеркально-0
- зеркало 1
- зеркально-2
Эта установка будет иметь доступную для пользователя емкость хранения приблизительно 8 ТБ, передавать или принимать служебные данные метаданных (у вас есть два зеркала, обеспечивающие 2 ТБ каждое, плюс одно зеркало, обеспечивающее 4 ТБ, всего 8 ТБ). Вы можете добавить больше пар зеркал позже, чтобы увеличить емкость пула, или заменить пару дисков емкостью 2 ТБ на диски емкостью 4 ТБ (хотя учтите, что повторное резервное копирование в случае сбоя диска в паре зеркал создает серьезную нагрузку на остальные диски). ), в случае двусторонних зеркал значительно увеличивается риск полного выхода из строя зеркала). Недостатком этой конфигурации является то, что пул будет практически заполнен с самого начала, и общее предложение заключается в том, чтобы поддерживать пулы ZFS ниже примерно 75%. Если ваши данные в основном только когда-либо читаются, вы можете уйти с меньшим запасом, нопроизводительность сильно пострадает особенно на записи. Если ваш набор данных требует много записи, вы определенно хотите, чтобы с распределителем блоков работал некоторый запас. Таким образом, эта конфигурация будет «работать», для некоторого определения слова, но будет неоптимальной.
Поскольку вы можете свободно добавлять дополнительные зеркальные устройства в vdev, при некотором планировании должна быть возможность сделать это таким образом, чтобы вы не потеряли ни одну из ваших данных.
В принципе, вы могли бы заменить mirror-0 и mirror-1 выше на один raidz1 vdev, в конечном итоге состоящий из четырех жестких дисков по 2 ТБ (что дает вам полезную емкость хранения 6 ТБ, а не 4 ТБ) и возможность выжить на любом жестком диске 2 ТБ сбой до того, как ваши данные окажутся под угрозой), но это означает, что три из этих дисков были изначально подключены к ZFS. Учитывая Ваши показатели использования это звучит , как это может быть возможно с некоторыми данными перетасовки вокруг. Я бы не советовал смешивать vdevs с разными уровнями избыточности, и я думаю, что инструменты даже заставят вас в этом случае эффективно сказать «да, я действительно знаю, что делаю».
Смешивать диски разных размеров в пуле (и особенно в одном vdev, за исключением случаев перехода на диски большей емкости) не очень рекомендуется; В конфигурациях зеркала и raidzN vdev наименьший составляющий диск в vdev определяет емкость vdev. Смешивание vdevs различной емкости выполнимо, но приведет к несбалансированной настройке хранилища; однако, если большая часть ваших данных редко читается и когда чтение читается последовательно, последние не должны представлять серьезную проблему.
Лучшая конфигурация , вероятно, будет состоять в том, чтобы получить дополнительные три диска по 4 ТБ, затем создать пул, состоящий из одного raidz2 vdev, состоящего из этих пяти дисков по 4 ТБ, и эффективно отключить диски объемом 2 ТБ. Пять дисков емкостью 4 ТБ в raidz2 обеспечат вам 12 ТБ хранилища (оставляя достаточно места для роста), а raidz2 даст вам возможность пережить сбой любых двух из этих дисков, оставив настройку зеркала в пыли с точки зрения устойчивости к проблемам с диском. При некотором планировании и перетасовке данных будет легко перейти на такую установку без потери данных. Пять приводов raidz2 также близки к оптимальным с точки зрения затрат на хранение в соответствии с тестами, проведенными одним пользователем и опубликованными в дискуссионном списке ZFS On Linux в конце апреля, с показателем полезной емкости хранения на уровне 96,4% от оптимального при использовании устройств объемом 1 ТБ, побитых только шестью дисками. конфигурация per-vdev, которая дала 97,3% в том же тесте.
Я понимаю, что пять 4-ТБ накопителей могут быть непрактичными в домашних условиях, но имейте в виду, что ZFS является корпоративной файловой системой, и многие из ее ограничений (особенно в этом случае, ограничения на увеличение избыточных vdevs после создания) отражают это.
И всегда помните, ни один тип RAID не является резервным копированием . Вы оба должны быть достаточно защищены от потери данных.