- как насчет ZFS
Привет Шон,
Я не могу рассказать вам много о btrfs, он все еще в моем списке дел. Для ZFS доступно несколько решений, некоторые с графическим интерфейсом (обычно они предлагают версии, которые бесплатны для частного использования). Я также протестировал его с помощью командной строки в Solaris, OpenIndiana и OmniOS, но для простоты использования я бы рекомендовал использовать специальный дистрибутив NAS, такой как nexentastor (более ориентированный на бизнес, менее интуитивно понятный графический интерфейс) или в вашем случае, вероятно, FreeNAS (хорошо allrounder, webGUI, бесплатно).
Установка FreeNAS очень проста (например, записать образ на USB-накопитель (я предпочитаю микросхемы на основе SLC для лучшей устойчивости), вставить его на материнскую плату, загрузить, настроить сеть в командной строке и подключить к сети - после этого все остальное делается через Интернет -GUI) и сообщество довольно живое. И у него есть простая возможность установить (в качестве изолированного модуля) медиа-сервер (медиасервер plex) и позволить ему видеть выбранный каталог или файловую систему, опционально только для чтения.
И для меня самое важное: вы получаете (почти безграничные) снимки и репликацию на основе снимков на другой ящик. Значение: вы можете ввести задачу, которая периодически делает снимки, а затем копирует их в другое поле. Это поле не обязательно должно быть идентичным, это может быть недорогая конфигурация системы (даже на основе другой системы / ОС), которая служит только в качестве архива, или полноценный двойник.
Теперь, когда речь идет о конфигурации диска, требуется некоторая базовая информация, в основном о типе использования:
Медиа-файлы обычно большие, копирование их из одного хранилища в другое и обычно не является большой задачей для любой системы. Что еще тебе понадобится? Многократный одновременный доступ к различным носителям? Сильно пропуская вперед / назад? Или в принципе: насколько случайным является ваш доступ для чтения? То же самое касается доступа для записи. Однопользовательский, хранение файлов и просмотр время от времени не должно быть большой проблемой. Коробка домашнего кинотеатра, регулярно сканирующая все мультимедиа на NAS для создания индекса для каждого файла, или потоковая передача до 5 или 50 - это совершенно другая вещь. 20 человек, работающих над отдельными проектами, редактирование, вырезание и объединение медиа файлов - это совсем другая история.
Хорошая новость: ZFS может удовлетворить все вышеперечисленное. Даже все из них. Но затраты, естественно, будут варьироваться. Позвольте привести несколько примеров:
«Конфигурация входа» (в основном пропускная способность для одного пользователя), обеспечивающая 24 ТБ, может выглядеть следующим образом:
* один пул с конфигурацией RAIDZ2 или Z3 из 6 соответственно 7 жестких дисков по 6 ТБ (за «Z» следует количество дисков, которые могут выйти из строя без фактической потери данных, не более 3)
* 8 ГБ ОЗУ (4 ГБ немного не хватает, с ZFS обычно: чем больше, тем лучше!)
* один или несколько портов Ethernet 1 Гбит (лучше всего добавить одну выделенную сеть для репликации, если это необходимо / возможно)
Этой настройки (около 24 ТБ) должно хватить, в основном, для однопользовательского доступа: большие файлы копируются последовательно в коробку, а затем считываются / передаются по отдельности. В сочетании с соответствующим процессором (2-4 ядра последнего поколения, 2,5+ ГГц) он должен обеспечивать хорошую пропускную способность чтения и записи, но из-за монолитной структуры диска будет наблюдаться низкая производительность ввода-вывода (особенно запись). Ожидается, что пропускная способность останется ниже 4-кратной производительности на одном диске, но особенно ожидается, что число операций ввода-вывода в секунду при записи будет не больше, чем у одного диска (естественно, кроме операций чтения из кэша). Перестройка после сбоя диска, естественно, еще больше снизит производительность, но, поскольку реплицируются только используемые блоки, обычно она заканчивается намного быстрее (в зависимости от скорости заполнения пула), чем «обычная» перестройка RAID.
Чтобы повысить производительность параллельного чтения, вы можете добавить «производительный SSD» (высокая скорость ввода-вывода, хорошая пропускная способность) в качестве L2ARC, интеллектуального кэша чтения, который в противном случае полностью находится в оперативной памяти. Это должно значительно повысить производительность чтения, но L2ARC «очищается» при перезагрузке, аааик. Таким образом, после перезагрузки он должен будет постепенно «пополняться», основываясь на «рабочем наборе» файлов / шаблонов доступа.
Вот пример лучшего параллельного (чтение / запись) исполнителя:
* один пул, содержащий 6 зеркал с 3x 4ТБ дисками в каждом (это означает, что каждый диск зеркалируется ДВАЖДЫ для избыточности, уменьшая нагрузку при перестроении зеркала, когда одна копия может быть прочитана для повторного зеркалирования, а другая обслуживает запросы чтения)
* 32 ГБ ОЗУ
* 2x 200 ГБ + L2ARC
* один или несколько портов Ethernet 10 Гбит (снова добавьте один для репликации между ящиками)
Эта установка должна предлагать несколько раз (чтение и запись) ввода-вывода первой установки (данные распределены по 6 зеркалам вместо одного RAIDZ-устройства), производительность при перестройках должна быть намного лучше, время перестроения меньше (из-за меньших дисков) , А избыточность (ok-to-fail) составляет 2 диска - для каждого зеркала. Естественно, у вас есть больше дисков - & gt; более вероятно иметь неисправный диск в некоторый момент. Но восстановление происходит быстрее и оказывает гораздо меньшее влияние.
Естественно, IO также зависит от дисков: сравните 10.000 об / мин с & lt; 3 мс времени поиска до 5.400 об / мин с & gt; 12 мс времени поиска, не говоря уже о SSD с небольшой долей этого.
Говоря о твердотельных накопителях, существует также опция для ускорения работы с использованием отдельного устройства для «записи в журнал», называемого SLOG (Separate LOG), обычно с использованием одного или нескольких твердотельных накопителей (или карт PCIe), но это часто неправильно понимают и, следовательно, используют неправильно. Сейчас я не буду углубляться в эту тему, за исключением одного момента: он используется только в отношении СИНХРОННОЙ передачи данных (транзакции записи подтверждаются, как только данные фактически записываются в стабильное хранилище, например на диски, в смысле «I» 'm Закончено'), в отличие от асинхронных передач (транзакции записи подтверждаются, как только данные получены, но часть (или все) данных могут все еще находиться в кэш-памяти / ОЗУ, ожидая записи в стабильное хранилище, что означает «Я сделаю это как можно скорее»). Обычно, когда мы говорим об общих сетевых ресурсах для хранения файлов, мы говорим об асинхронных передачах. Без каких-либо «настроек» синхронная запись всегда медленнее, чем асинхронная. Если вам нужна такая целостность, просто вернитесь и попросите больше. ;-)
Почти забыли: для обеспечения целостности данных лучше всего использовать ECC-RAM (и совместимые материнскую плату и процессор), чтобы избежать повреждения данных из-за незаметного сбоя памяти. В производственной среде вы бы точно этого не хотели.
Несколько других функций, которые вы могли бы знать
* ZFS это вообще (но не всегда, вздох ) совместимы между дистрибутивами / ОС на основе одной и той же версии ZFS (если не активированы дополнительные «специальные функции»)
* несколько хороших «встроенных» вариантов сжатия - но, вероятно, не в вашем случае (предварительно сжатый носитель, я полагаю)
* целостность с авторемонтом
* Восстановление ZFS после сбоя диска реплицирует только текущие данные на диск, а не свободное место
интеграция с Active Directory (для использования в бизнесе)
* FreeNAS имеет встроенную опцию шифрования диска - лучше всего использовать с соответствующими процессорами (ускорение) - но будьте осторожны, это нарушает совместимость с другими дистрибутивами
Хорошо, так много для краткой рецензии на решение на основе ZFS ... Я надеюсь, что оно предлагает больше ответов, чем вызывает новые вопросы.
С Уважением,
Kjartan