- как насчет зфс
Привет Шон,
Я не могу рассказать вам много о 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 диска - для каждого зеркала. Естественно, у вас есть больше дисков -> больше вероятности, что в какой-то момент будет отказавший диск. Но восстановление происходит быстрее и оказывает гораздо меньшее влияние.
Естественно, IO также зависит от дисков: сравните 10 000 об / мин с временем поиска <3 мс с 5,400 об / мин с временем поиска> 12 мс, не говоря уже о SSD с небольшой долей.
Говоря о твердотельных накопителях, есть также опция для ускорения работы с использованием отдельного устройства для «записи в журнал», называемого SLOG (Separate LOG), обычно использующего один или несколько твердотельных накопителей (или карт PCIe), но это часто неправильно понимается и, следовательно, используется неправильно. Сейчас я не буду углубляться в эту тему, за исключением одного момента: он используется только в отношении СИНХРОННЫХ передач данных (транзакции записи подтверждаются, как только данные фактически записываются в стабильное хранилище, например на диски, в смысле «I»). 'm Закончено'), в отличие от асинхронных передач (транзакции записи подтверждаются, как только данные получены, но часть (или все) данных могут все еще находиться в кэш-памяти / ОЗУ, ожидая записи в стабильное хранилище, что означает «Я сделаю это как можно скорее»). Обычно, когда мы говорим об общих сетевых ресурсах для хранения файлов, мы говорим об асинхронных передачах. Без каких-либо «твиков» синхронная запись всегда медленнее, чем асинхронная. Если вам нужна такая целостность, просто вернитесь и попросите больше. ;-)
Почти забыли: для обеспечения целостности данных лучше всего использовать ECC-RAM (и совместимую материнскую плату и процессор), чтобы избежать повреждения данных из-за незаметного сбоя памяти. В производственной среде вы бы точно этого не хотели.
Несколько других функции вы можете знать * ZFS , как правило (но не всегда, вздыхать) совместим между распределениями / операционками на основе того же версии ZFS (если нет дополнительных «специальных функций не» активизируются) * несколько вариантов хорошо «инлайн» сжатия - но, вероятно, не в вашем случае (предварительно сжатые носители, я полагаю) * целостность с автоматическим восстановлением * восстановление ZFS после сбоя диска реплицирует только живые данные на диск, а не интеграцию свободного пространства с Active Directory (для использования в бизнесе) * FreeNAS имеет опция встроенного шифрования диска - лучше всего использовать с соответствующими процессорами (ускорение) - но будьте осторожны, это нарушает совместимость с другими дистрибутивами
Хорошо, так много для краткой рецензии на решение на базе ZFS ... Я надеюсь, что он предлагает больше ответов, чем вызывает новые вопросы.
С уважением, Кьяртан
