ZFS довольно требовательна к тому, на каком оборудовании она работает.
Не в том смысле, что вы должны иметь именно тот набор микросхем, видеокарту, версию прошивки диска и т.д., А в смысле возможностей, предоставляемых оборудованием. Помните, ZFS была разработана как серверное решение высокого класса, и некоторые предположения, которые она делает, отражают это.
Основная часть того, что делает ZFS настолько хорошим для хранения данных, о которых вы заботитесь, заключается в том, что вы можете настроить его так, чтобы он мог как обнаруживать, так и исправлять ошибки в хранилище. Это могут быть тривиальные ошибки, такие как однократный переворот, или катастрофические ошибки, например, сбой нескольких дисков одновременно. До тех пор, пока вы превышаете пороговое значение избыточности вашего хранилища (например, не более двух дисков одновременно испытывают проблемы в raidz2 vdev), ZFS может исправить любую ошибку, используя избыточные данные. Дальнейшие ошибки, в зависимости от того, где и как они возникают, могут привести к (полу) изящной системной панике или простой ошибке ввода-вывода.
Если вы все сделаете правильно, вы также настроите свою систему на регулярную очистку пула (ов) ZFS. Это перехватит деградацию до того, как возникнет проблема, и уведомит вас об этом, чтобы вы могли рассмотреть вопрос о замене запоминающих устройств, на которых возникли проблемы с сохранением ваших данных, прежде чем это станет проблемой.
Однако это величие зависит от того факта, что оперативной памяти можно доверять. Вся эта проверка, исправление, переписывание и так далее происходит в основном в оперативной памяти. На высокопроизводительных серверах вы не найдете ничего, кроме ECC RAM.
ZFS защищает (и обрабатывает) метаданные пула, метаданные файловой системы и пользовательские данные одинаково. Здесь нет никакой разницы.
Если ваша рабочая станция испытывает переворот в битах ОЗУ, то когда вы записываете битовые данные в ZFS, битовые данные будут основой для того, что ZFS в конечном итоге записывает на диск. Это, очевидно, плохо, потому что это означает, что ваш файл будет поврежден. Тем не менее, битовые данные будут правильными в отношении ZFS. Это на самом деле хорошо, потому что это означает, что все нормальные методы восстановления ZFS будут работать. Да, самая последняя копия рассматриваемого файла будет повреждена, но она все равно будет повреждена, независимо от того, какую файловую систему вы использовали. Вы можете использовать моментальные снимки ZFS, чтобы, по крайней мере, вернуться в исходное состояние к нетленной копии. Установите что-то вроде zfs-auto-snap, чтобы снимать ваши файловые системы через регулярные, короткие промежутки времени, сохранять более грубую историю в обратном направлении и забывать об этом, пока они вам не понадобятся. (Например, сохраняйте десять снимков с интервалом в десять минут; 50 снимков с интервалом в один час; 30 снимков с интервалом в шесть часов; и т.д.) Снимки практически бесплатны в ZFS; если вы используете ZFS, используйте также снимки.
Если ваш сервер хранения данных, на котором работает ZFS, испытывает проблемы с ОЗУ, будь то перевёрнутый бит или зависание (один или несколько) битов, и у вас есть ECC RAM на сервере хранения, это будет обнаружено, и событие будет зарегистрировано, или система будет быть остановленным (если ошибка не может быть исправлена). В любом случае, целостность данных, хранящихся на сервере, сохраняется. Если ваш сервер хранения ZFS имеет оперативную память не-ECC, то ошибка может распространяться по всем вашим данным и метаданным, поскольку ZFS пытается "исправить" ошибки, которые на самом деле являются всего лишь плодом воображения компьютера. В худшем случае, который действительно случается с людьми, весь ваш пул будет разрушен из-за этого, и все ваши данные будут удалены. Резервирование уровня хранения / уровня vdev здесь тоже не поможет. В большинстве других файловых систем (без функции автокоррекции) будет повреждено только одно место, на которое непосредственно повлиял переворот, и если это произойдет с метаданными файловой системы, то их легко исправить с помощью традиционных средств проверки файловой системы и восстановления. инструменты. ZFS не имеет этого аварийного люка; fsck.zfs нет. (Существует zpool scrub, но он не работает, если пул не работает).
Что я не смог найти в Google, так это: какой смысл иметь максимально надежный хостинг файлов NAS (или в качестве резервной копии), когда я работаю с файлами на менее надежных компьютерах?
Это означает, что у вас есть надежное хранилище данных. Вы знаете, что как только данные попадут на ваш NAS, они будут защищены от повреждения. Любое повреждение либо будет устранено автоматически, либо вы будете проинформированы о проблеме (в случае ZFS - из-за ошибки ввода-вывода). Данные могут все еще быть повреждены, пока они работают с использованием менее надежных систем, но у вас будет возможность найти известную не поврежденную копию. Это является преимуществом, даже если только система NAS имеет ECC RAM, ZFS и высококачественные системы мониторинга и оповещения.
Затем вы можете, при желании, добавить (в частности) ECC RAM к другим системам, если позволяет ваш бюджет, чтобы закрыть последнюю дыру.
Нужно ли (образно) выбрасывать мои текущие системы и заменять их (мини) серверным оборудованием, если я не хочу беспокоиться о гниении и т.д.? И если я пойду по этому пути, могу ли я разумно ожидать, что у меня будут ресурсы для чего-либо кроме запуска ZFS? Не тратя тысячи долларов?
Во-первых, вам не нужно аппаратное обеспечение серверного уровня. В первую очередь вам нужна ECC RAM (и контроллер / чипсет ЦП и памяти, поддерживающий ECC RAM), достаточно надежное постоянное хранилище и, в идеале, случай, когда легко добавлять и удалять диски во время работы системы. Это не должно быть очень дорого, и, конечно, не должно стоить "тысячи долларов".
Во-вторых, ZFS любит оперативную память, но в основном для кеширования. При большинстве рабочих нагрузок 8–16 ГБ ОЗУ должно быть вполне достаточно, а 24–32 ГБ (легко достижимо даже с "потребительскими" материнскими платами) по-прежнему по разумным ценам даже при покупке высококачественной ОЗУ ECC под маркой. ZFS не сильно жаден до процессора; Вы можете сделать так, чтобы ему потребовалось много ресурсов ЦП (как в случае с ZoL, путем настройки sha256, сжатия gzip-9 и, возможно, дедупликации в комбинации), но это не обязательно. Моя собственная система работает на ZFS, но не слишком мощная (процессор FX-6100 отключен), я использую sha256 везде, и даже при чисто последовательном вводе / выводе диски являются ограничивающим фактором: как только он преодолевает начальный Часть скраба с произвольным чтением, я получаю примерно такую же пропускную способность для скрубов, как и на сыром dd с базового устройства хранения, с резервированием ЦП.
