ZFS

Когда дело дошло до расширения, встал вопрос о том какой делать массив накопителей?

Начинается всё с количества накопителей. В моём случае жизнь началась с 12 терабайтных накопителей. С одного такого накопителя. Когда он заполнился под завязку, принято решение, и накоплены средства на еще 2 таких же. Итого имеется 3 накопителя Toshiba MG07ACA12TE. Вот и поднимается вопрос какой же массив из них сделать. Объединение объема в одно пространство отпадает сразу, хоть и заманчиво по части объема. Зеркало из 3х накопителей бесполезная трата одно накопителя. Даже если их было бы 4, массив десятого уровня, всеми любимый, слишком расточительная потеря 50 процентов объема.

Конечно же взгляд упал в сторону пятёрки. Казалось бы ну идеальная система, 3 накопителя и полезный объем двух. В целом так это и работает. И при выходе из строя одного, данные сохраняются. Но если почитать интернет, получается что все считают данный массив ненадёжным. Меня это поначалу удивило. Но ведь сохраняется работа, при выходе одно накопителя, что еще нужно? Но изучение темы дало некоторые ответы, такого отношения к массиву пятого уровня.

Первый фактор который все приводят в пример, при отказе накопителя производительность массива сильно падает, мало кто показывает насколько, но это факт. И самое плохое, то что при установке в замен вышедшего накопителя нового начинается перестроение массива. Особенностью перестроения именно массива пятого уровня является чтение всех данных от начала и до конца. То есть реально высокая нагрузка, на массив. И если объем большой, то время такого перестроения велико. Технически равно скорости считывания всего объёма массива. Это сильно снижает производительность массива.

Второй фактор нагрузка на ЦП или контроллер. Так как с данными производится сложная операция распределения, а также создается специальный файл метаданных, тот самый из которого можно получить разницу между оставшейся информацией и утерянной. Именно так работает этот массив. Ведет к серьезной вычислительной мощности. Она уж является фактором реальной производительности массива.

Третий фактор следует из первого. В момент перестроения массива считываются все данные на накопителях от и до. Может случится так, что некоторые данные к которым не было обращений длительное время, уже находятся на сбойных секторах. И при обращении к такому файлу, операция чтения закончится ошибкой. Такая ошибка приводит к разрушению массива. Данные стандартными методами уже не получить. То есть само по себе перестроение массива с повышенной вероятностью создает еще один сбойный накопитель, что влечет к разрушению массива. Есть даже немало подсчетов такой вероятности. В реальности такие массивы могут работать 10 лет, при постоянной замене сбойных накопителей, но в какой то момент может случиться описание выше.

Три основных фактора неприязни к массиву пятого уровня. И я бы не сказал, что безосновательные. Решается в классическом виде применением массива шестого уровня. Работает по тому же принципу, но метаданные хранятся на двух накопителях. Что означает возможность выхода из строя до двух любых накопителей в массиве, без потери данных. Но это не входит в рамки условий в которых нахожусь я, в данный момент времени.

Энтузиазм немного упал, особенно после сборки реального массива, и тестировании производительности. Моей целью является построение системы, в которой будет единое хранилище в рамках Proxmox, на котором будет базироваться, как основной пул размером близким к максимальному объёму доступного пространства, так и область (виртуальный) накопитель для облака, у которого также появится возможность расширения.

К примеру в массиве из трёх 12 терабайтных накопителей, полезный объем будет 24 терабайта. Из него я возьму 22 терабайта на накопитель для машины выполняющей задачи NAS, и 2 терабайта на виртуальный накопитель для машины с облаком.

Ранее машина с облачным сервисом Nextcloud использовало хранилище на основе одной SSD. При переносе на массив накопителей, заметно снижение производительности, при синхронизации мелких файлов в особенности.