Смотря на каких диска ты будешь это запускать.. Современные консьюмерские SSD настолько упороты, что когда заканчиваются ячейки сконфигурированные в SLC режиме, и начинается запись в QLC ячейки - наступает жопа. В этом режиме они медленнее старых HDD. А SLC ячейки заканчиваются крайне быстро. Т.к. максимальное их количество может быть не больше 1\4 от оставшегося объема диска (это при условии что весь остаток диска в этом режиме, но тогда у него будет уменьшенная в 4 раза емкость. А если этот объем превышен, нужно будет еще успевать "расфигачивать" уже записанные в SLC режиме данные туда же, но уже в QLC режиме, иначе места просто не будет, хотя пользователь видит, что 60% диска еще свободно

У меня на днях появились первые в моей жизни сервера с Enterprise SSD, и это просто чудо какое то. Даже SSD от Samsung рядом не стояли.

ZFS скидывает каждые 5 сек. Но приложение IMHO не будет ждать этого скидывания данных на диск, ZFS его обманет и скажет заранее, что уже усе готово даже еще ДО записи в ZIL. Я про режим sync=none.

разве sync=none не отключает журналирование вообще?

Вероятно отключает как минимум честную синхронизацию для определенного датасет, а зачем отключать что-еще типа журнала?

пушо журнал в зфс средство быстро зафиксировать синхронные записи

Зачем торопиться их фиксировать, если есть договоренность, что они асинхронны на самом деле?

ну я и говорю, если sync=none то и журнал он же zil не нужен

Почему? А вдруг при записи питание пропадет. Речь о целостности вообще, а не с точки зрения программы, которая писала.

потому что cow )

если взять год 2015, то zol действительно был нестабильный и мог рассыпаться (расползались индексы внутри пула).

c 0.7 с таким не сталкивался. с 2019 года

интересно, у меня сервер работает на 0.7.5 , там починили уже или надо ждать что все может развалится?

не совсем понимаю ваши опасения. ждать можно все что угодно - землятресения, цунами, мировой войны.. вероятность наступления любого события !=0..

кстати, какие рекомендации есть по поводу железа для создания файл сервера на ~ 400тб ? (статью на openzfs docs читал).

нагрузка какая будет?

будет NFS сервер для обслуживания кластера для обработки научных данных. Ожидается что будет ~ 10 compute node, соединённых через 10gbe. В основном все операции последователое чтение и запись файлов по 20-100мб.

Впечатление такое, что вы можете упереться в скорость обмена данными с дисками. Нужно продумать способ соединения дисков с сервером. 400ТБ, - это условно 80 дисков в mirror. Я конечно с такими конфигурациями не сталкивался, но могу лишь посоветовать обратить внимание на уменьшение полосы пропускания из-за использования экспандеров. Используйте 16-портовые HBA и не увлекайтесь экспандерами. Разместите метаданные на SSD, вам потребуется несколько ТБ SSD. Подойдёт что-то вроде intel P4610 в mirror разумеется. По процессору, могу предположить, что должно быть пару десятков ядер, напрашивается AMD EPYC2. Заполняйте все каналы памяти. Настройки по умолчанию подходят под ваши данные. Можно, на мой взгляд не значительно, повысить скорость на некоторых видах нагрузки используя 1М recordsize но это усложнить модификацию фалов. Я не знаю упретесь ли вы в какое нибудь внутренне ограничение zfs по линейной скорости.

вот кстати. recordsize это МИНИМАЛЬНЫЙ или МАКСИМАЛЬНЫЙ размер блока? с 1M у меня любой мелкий 2к файл займет мегабайт или с 128к файлопомойка с фотками нарезана будет по 128к?

сейчас есть сервер с 55*14TB дисками, используется как cold storage, поэтому скорость работы не критичная. железо: supermicro 6049p-e1cr60l , 2*xeon 4114 , 128gb ram , для новой системы думаю на то тему supermicro 6049sp-e1cr60 с дисками на 18тб и кэш на быстрых ssd и памяти побольше

для начала спрашиваю у экспертов (тут)

special alloc class - must have

для начала спрашиваю у экспертов (тут)

будет NFS сервер для обслуживания кластера для обработки научных данных. Ожидается что будет ~ 10 compute node, соединённых через 10gbe. В основном все операции последователое чтение и запись файлов по 20-100мб.

сейчас там 0.7 крутится, вроде эта фича только у 0.8 есть?

лучше имхо для таких целей развернуть lustre поверх zfs хотя бы на трех-четырех нодах. один сервер под nfs с большой долей вероятности не справиться при записи одновременно со всех нод. плюс nfs плохо обрабатывает шары с большим количеством файлов (> нескольких млн). распределенная файловая система оптимальна для таких кейсов. причем lustre поверх zfs это рекомендованная конфигурация

да, lustre как раз для научных данных и используется обычно

Впечатление такое, что вы можете упереться в скорость обмена данными с дисками. Нужно продумать способ соединения дисков с сервером. 400ТБ, - это условно 80 дисков в mirror. Я конечно с такими конфигурациями не сталкивался, но могу лишь посоветовать обратить внимание на уменьшение полосы пропускания из-за использования экспандеров. Используйте 16-портовые HBA и не увлекайтесь экспандерами. Разместите метаданные на SSD, вам потребуется несколько ТБ SSD. Подойдёт что-то вроде intel P4610 в mirror разумеется. По процессору, могу предположить, что должно быть пару десятков ядер, напрашивается AMD EPYC2. Заполняйте все каналы памяти. Настройки по умолчанию подходят под ваши данные. Можно, на мой взгляд не значительно, повысить скорость на некоторых видах нагрузки используя 1М recordsize но это усложнить модификацию фалов. Я не знаю упретесь ли вы в какое нибудь внутренне ограничение zfs по линейной скорости.

лучше имхо для таких целей развернуть lustre поверх zfs хотя бы на трех-четырех нодах. один сервер под nfs с большой долей вероятности не справиться при записи одновременно со всех нод. плюс nfs плохо обрабатывает шары с большим количеством файлов (> нескольких млн). распределенная файловая система оптимальна для таких кейсов. причем lustre поверх zfs это рекомендованная конфигурация

ну 10 клиентов это в будущем, сначала там будет 4. Люстру я наблюдаю как пользователь на большом кластере, где иногда свои задачи считаю, там 1000 нод и петабайты данных и целая команда сисадминов.

А имеет ли смысл поднять CEPH поверх ZFS? или ZFS поверх CEPH? или даже так ZFS (со снэпшотами) -> CEPH -> несколько узлов ZFS (без снэпшотов - просто софт пулы zmirror и логическими zvol для CEPH)? IMHO обслуживать zpool на bare metal куда приятнее, чем что-либо еще, всевозможные аппаратные рейды и т.п.

Но и поверх CEPH тоже был бы удобен привычный ZFS с send | receive

Добрый вечер, пожалуйста, подскажите, стоит ли ждать еще полгода-год для повышения надежности ветки OpenZFS v2.0.x ? Хотелось бы уже воспользоваться persistent L2ARC. Но как говорится и хочется и колется. Больше всего опасаюсь если ZFS начнет опять отправлять глючные send | receive потоки как в версии 0.6.x. (hole burn или типа того). Краш пула - не самое страшное, самое страшное остаться без бэкапов после этого.

special alloc class - must have

А имеет ли смысл поднять CEPH поверх ZFS? или ZFS поверх CEPH? или даже так ZFS (со снэпшотами) -> CEPH -> несколько узлов ZFS (без снэпшотов - просто софт пулы zmirror и логическими zvol для CEPH)? IMHO обслуживать zpool на bare metal куда приятнее, чем что-либо еще, всевозможные аппаратные рейды и т.п.

Чем Lustre лучше, чем CEPH для подобного конфига. Я знаю, что сами разработчики ZOL использовали Lustre в своем сетапе, но все же, сейчас, когда CEPH уже повзрослел?

А имеет ли смысл поднять CEPH поверх ZFS? или ZFS поверх CEPH? или даже так ZFS (со снэпшотами) -> CEPH -> несколько узлов ZFS (без снэпшотов - просто софт пулы zmirror и логическими zvol для CEPH)? IMHO обслуживать zpool на bare metal куда приятнее, чем что-либо еще, всевозможные аппаратные рейды и т.п.

Разве у ceph нет своего аналога send | receive для инкрементальной репликации? Вроде было.

чтобы что? Чтобы было больше точек отказа и мест где можно потерять данные?

ну это спорно, это держать еще зеркало из нвме, дрожать за него и бекапить всё целиком на еще один такой же сервер без special alloc class

А что спорно то? Special alloc class это тот же vdev технически, какая разница что на бекапном сервере его не будет, а перформанс очень хорошо добавит.

на мой вкус - гораздо больше имеет смысл большой slog и большой l2arc, но возможно я чего-то в этом не понимаю

например, его надо как минимум зеркалить например, в силу интенсивности использования или перегрева оба ссд/нвме диска умирают одновременно

на мой вкус - гораздо больше имеет смысл большой slog и большой l2arc, но возможно я чего-то в этом не понимаю

а Special alloc class, которые в любой момент могут пропасть вместе со всеми данными - это какой-то еще один способ выстрелить себе в ногу

если мы делаем просто миррор на двух нвме и они умирают от износа флеша - они умирают в один день, верно?

а если у них хронический перегрев то они умирают в один день контроллером

если он зеркало из двух - происходит. В остальных случаях все лучше

т.е. я про самый распространненый сценарий - когда special allocation class - это один или два нвме