Нужен совет по организации ZIL и L2ARC в ZFS

Под L2ARC достаточно одного диска (выход его из строя не приведёт к потери данных).

Под ZIL - нужно два (для надежности). ZIL обычно не занимает большой объем (достаточно гигабайт 8-16).

Для ZIL лучше брать SSD с конденсаторами - у них latency ниже. См. https://www.reddit.com/r/Proxmox/comments/sui2iv/consumer_nvme_vs_enterprise_sata_ssds_for_vm/ и https://habr.com/ru/companies/selectel/articles/521168/

А под какие задачи будет использоваться массив?

L2ARC зеркалить совершенно бессмысленно, так как смерть диска приведёт всего лишь к перечитыванию данных с диска в ARC (который в RAM). Всё. Увидел смерть cache-ноды в пуле, заменил диск физически (предварительно разметив, само собой), снова забыл. Никаких дополнительных телодвижений не нужно.

А вот ZIL нужно беречь.

нормальных, но недорогих на TLC типо Samsung EVO или A-DATA

нормальных

A-DATA

Ха-ха. Ну то есть они, конечно, под консьюмерское пойдут, там ведь ничего важного у юзера нет. Но если оно сдохнет, то оно сдохнет окончательно. Впрочем, под кэши — самое оно, ибо не жалко.

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

Для видео, и изображений - ни, то, ни другое, не поможет. В твоём случае только ARC. Под l2arc - нужно расчитывать так же кеш ОЗУ (расчитаешь не корректно, можешь хоть на сто терабайт поставить ssd - толку будет ноль).

zil для баз данных имеет смысл, l2arc - для мелких файлов, при условии, что ОЗУ под ARC выделено достаточно.

Имеется ZFS пул на 8 SAS дисках объединенных в raidz3

raidz вообще, и raidz3 в частности — сильно тормознутая штука, имейте в виду. Ещё и не расширяется путём добавления дисков (в будущих версиях планируют сделать, но пока не сделали).

Во всех мануалах упоминается такая вещь как ZIL и L2ARC. Я хочу выделить на эти вещи по отдельному SSD диску, что как я понимаю увеличит скорость работы рейда в целом.

Уменьшит задержки синхронной записи и увеличит кеш чтения.

Ещё упоминается ARC (не L2) — кеш в ОЗУ. Сколько у Вас ОЗУ в сервере и сколько Вы планируете выделить под ARC?

ZIL и L2ARC крайне желательно разводить на отдельные SSD, а не делать их на одном. Так ли это?

Технически, их можно разместить на одном/одних устройствах. Производительность, в этом случае, будет ниже. Вопрос (к Вам) — какая производительность нужна.

Также, как я понял, рекомендуют как под ZIL так и под L2ARC отводить отдельные vdev в которых по 2 ssd объеденены в mirror. т.е. под ZIL отвести 2 SSD в режиме mirror, и под L2ARC отвести 2 SSD в режиме mirror. Так ли это? Или в принципе достаточно под каждую их них отвести по одном отдельному SSD и будет норм.

Уже ответил выше, дополню ответ (в части ZIL). Зависит от класса устройств (их производительности в части синхронной записи) и требования к надёжности. Я, например, на серверах под ZIL обычно выделяю кусок (LVM LV) одного серверного Optane (т.е. не делаю под это mirror).

Планирую на эти цели добавить M.2 SSD диски. Нужно ли для этого использовать какие-то более дорогие SSD скажем на MLC памяти или достаточно нормальных, но недорогих на TLC типо Samsung EVO или A-DATA.

В целом, лучше в серверах не использовать потребительские SSD — они сильно сливают по синхронной записи серверным дискам. И дело тут не (только) в типе памяти (MLC/TLC). См. ссылки из моего сообщения выше.

ZIL и L2ARC крайне желательно разводить на отдельные SSD, а не делать их на одном. Так ли это?

Желательно, но не обязательно. Это могут быть, например, LVM LV из с одного диска/одонго mirror’a. На производительности, это, естественно, скажется. Хватит ли оставшейся производительности Вам или нет - отдельный вопрос.

Ну если сравнивать с тем же mdadm понятно что это будет не страйп что тут, что там. Оперативки 32гига щас

Задачи массива это хранение и работа с различными видеоматериалами, секвенциями изображений, графикой и т.п. т.е. чтение и запись в массив во время работы будет нормальная.

Сначала написал предыдущее сообщение, потому увидел Ваш ответ.

У меня сейчас похожий кейс — хранилище для дизайнеров (фото в основном). Раньше всё было на SSD, сейчас перевёл на HDD (в связи с ростом объема данных 1,5 ТБ -> 5 ТБ). Сейчас их не удовлетворяет скорость записи. Учитывая, что в ZFS нет кеширования записи (ZIL это как бы не кеш), планирую попробовать что-то ещё (ZFS over bcache, например).

Под ZIL - нужно два (для надежности).

Два под ZIL как-то избыточно. Насколько я помню, случае смерти диска потеряются лишь данные которые не успеши флашнутся на диск и только. Сама ФС должна остаться целой.

Два под ZIL как-то избыточно. Насколько я помню, случае смерти диска потеряются лишь данные которые не успеши флашнутся на диск и только. Сама ФС должна остаться целой.

ФС (CoW) остаётся целой при любом хард-ресете by-desing. Вопрос именно в целостности данных. Если целостность не принципиальна, то да, можно экономить на надёжности ZIL.

Просто у ZFS (и у архитекторов ZFS и у пользователей ZFS) целостность данных обычно стоит на первом месте.

Ну если сравнивать с тем же mdadm понятно что это будет не страйп что тут, что там.

«Не страйп» — Вы имеете в виду не raid1/raid10?

Сейчас их не удовлетворяет скорость записи. Учитывая, что в ZFS нет кеширования записи

Это как? Фото должны записываться в режиме async. Т.е. все программы должны получать ответ об успешной записи сразу. Как же должны быть заняты диски, что бы и это было долго? Ну, попробуйте: always=sync + zil. - Но, блин, в Вашем случае, это точно не то.

Сейчас их не удовлетворяет скорость записи.

Смотря через что они туда льют данные. Можно сделать кеш на уровне софта который непосредственно пишет данные на диск.

А какая нафиг разница, через что, если оно должно быть записано в async режиме? :)

А какая нафиг разница, через что, если оно должно быть записано в async режиме? :)

Кто тебе сказал что оно кому-то что-то должно? Вдруг у него проприетарная софтина которая это не умеет и никак ее этому не научить.

Смотря через что они туда льют данные

Пользователи нажимают «CTRL + S» в Photoshop/Illustrator/etc.

Файловый ресурс организован так: ZFS POOL (mirror 2*16 Tb SAS 7200) -> zvol -> VM -> xfs -> samba

samba

Давно с ней дела не имел. Может у нее есть функция кеширования в отдельной диретории.

Спасибо за идею, посмотрю, как самбоводы кеширование организуют.

Вообще, samba пишет в async (если специально не настроить иначе).

https://blog.csdn.net/QTM_Gitee/article/details/127331768

ZFS POOL (mirror 2*16 Tb SAS 7200) -> zvol -> VM -> xfs -> samba

Да вполне.

Пользователи нажимают «CTRL + S» в Photoshop/Illustrator/etc.

Да, тоже вполне. У меня всё аналогично. Никто, никогда не жаловался.

Возможно, нашёл причину. У меня мало ОЗУ выделено под VM, в которой живёт Samba. Попробую увеличить.

Да, вот нужно смотреть на каждую полку этой антресоли. Но, в целом samba не требовательная

Насколько я понимаю, если софтина чего-то особо не умеет, всегда будет async.

У неё свой write cache есть (по умолчанию отключен). Так себе решение, конечно (при сбое могут данные потеряться).

https://serverfault.com/questions/734124/samba-share-write-performance

Вы меня натолкнули на идею: погонять fio изнутри виртуалки в sync режиме и посмотреть, какое влияние оказывают параметры ZFS на производительность записи.

Если диски SATA, то следует помнить, что оно не дуплексное, мы или пишем, или читаем. В остальном, на Вашем случае, ну я не вижу особых проблем. Всё должно работать.

Вы меня натолкнули на идею

Не забудь написать результаты тестов. Интересно же)

И еще советую сравнить с производительностью дисков на хосте. Бывало сталкивался со случаями когда при определенном ворклоде скорость в виртуалке была существенно ниже чем при том же ворклоде на железке.

Если диски SATA, то следует помнить, что оно не дуплексное, мы или пишем, или читаем. В остальном, на Вашем случае, ну я не вижу особых проблем. Всё должно работать.

Именно так — мы упираемся в производительность дисков на запись (диски при этом ещё чем-то заняты).

Я вижу такие варианты ускорения записи:

• добавить special device — часть данных будет на SSD, что снизит нагрузку на HDD
• отказ от использования HDD для этой задачи; выделение под неё SSD достаточного объема
• кеширование на диске (bcache или lvm-cache)
• кеширование в памяти (samba write cache или writeback в VM)

Есть ещё идеи (или соображения, как лучше сделать)?

Не забудь написать результаты тестов. Интересно же)

Да, конечно!

Бывало сталкивался со случаями когда при определенном ворклоде скорость в виртуалке была существенно ниже чем при том же ворклоде на железке.

Да, спасибо за совет!

ZFS over bcache, например

Если в голову лезут мысли о подобных извращениях, что б не сразу bcachefs? )
У неё вообще красиво: «Foreground devices accept writes, whose data is copied to background devices asynchronously, and the hot subset of which is copied to the promote devices for performance.»

Почитал. Можно попробовать (с частыми бэкапами).

Вопрос

Скажите, а почему когда я скажем в ZFS удаляю папку на 100гигов с, скажем, десятком тысяч файлов это занимает какое-то время? Несколько минут как минимум.

Ведь по идее он просто должен указатель на эту папку удалить или типо того, а новые данные он будет писать в свободные ячейки памяти. Соответственно удаление по идее должно быть мгновенное практически. Разве не так?

Ребята, еще вопрос.

Вот я настроил scrubing еженедельный, как написано в мануале, включив соответствующий сервис

А именно

sudo systemctl enable zfs-scrub-weekly@zdata.timer

sudo systemctl start zfs-scrub-weekly@zdata.timer

где zdata это мой зпул

Вопрос, а в какое время он будет это делать? Да, я понимаю, что раз в неделю, но это будет в будний день в рабочее время или на выходных. Как он будет время выбирать?

Мне нужно чтобы он это делал в выходные, когда сервак не используется в работе людьми. Где это настраивается?

Увидел смерть cache-ноды в пуле, заменил диск физически (предварительно разметив, само собой),

Размечать диски для ZFS (а также ZIL, L2ARC), по-возможности, не нужно.

Ребята, еще одну вещь заметил.

У меня собственно пул шарится через nfs, по средством zfs set sharenfs.

Если глянуть вывод exportfs -v, то вывод такой

/mnt/zdata 192.168.0.0/24(sync,wdelay,hide,crossmnt,no_subtree_check,mountpoint,anonuid=1000,anongid=1000,sec=sys,rw,insecure,root_squash,all_squash)

Как видно root_squash и all_squash включены Если я создаю любым юзером или через sudo на шаре директорию, то она имеет владельцем 1000:1000. Кажись все верно.

Но если я захожу непосредственно на сервак физически или скажем через ssh и там в той папке, что я шарю создаю создаю директорию с владельцем 0:0, т.е. root, то глядя через клиентские машины, я да она появляется и я вижу что владелец папки root, но какого мое удивление было когда я смог ее удалить будучи обычным пользователем, хотя права на ней самые стандартные 755. И получается что squash вроде и работает и не работает. Не пойму почему.

Подскажите плиз. По идее же я не должен иметь возможность удалять папки в шаре, владелец которых root и права на которых 755?

Размечать диски для ZFS (а также ZIL, L2ARC), по-возможности, не нужно.

Если ZFS скормить диск целиком, оно его разметит по-соляровски. Солярочная разметка за пределами солярки не упёрлась вот вообще.

Когда диск нужен будет под другие цели - его переразметят.

Если диск нужен и под zfs и под что-то еще одновременно - можно взять lvm и разместить zfs поверх lv.

А какие права при этом были на папку уровнем выше?

Вот вроде разобрался. Да там права позволяли

разместить zfs поверх lv

🤦

Солярочная разметка за пределами солярки не упёрлась вот вообще.

В чём это выразится и на чём отразится т.н. «солярочная» разметка?

Если диск нужен и под zfs и под что-то еще одновременно - можно взять lvm и разместить zfs поверх lv.

А зачем на диске с ZFS что-то ещё?

Ребята, еще вопрос.

Вот я настроил scrubing еженедельный, как написано в мануале, включив соответствующий сервис

А именно

sudo systemctl enable zfs-scrub-weekly@zdata.timer

sudo systemctl start zfs-scrub-weekly@zdata.timer

где zdata это мой зпул

Вопрос, а в какое время он будет это делать? Да, я понимаю, что раз в неделю, но это будет в будний день в рабочее время или на выходных. Как он будет время выбирать?

Мне нужно чтобы он это делал в выходные, когда сервак не используется в работе людьми. Где это настраивается?

Я бы советовал убедиться, что есть упор именно в async запись. Виртуальая машина, то точно пробрасывает async до блочного устройство? А то, может в настройках выставлен жесткий sync?

Если при этом есть большое чтение, то, увеличение ОЗУ для ARC, даст прирост колоссальный. Я весьма удивлен, что на файлопомойке, прямо такие объемы на запись. И да: не забывайте, что один процесс в zfs mirror, читает только с одного диска. Т.е., если Ваша VM, это один процесс kvm, то и читать оно будет только с одного диска из raid массива. В общем, нужно вникать. Ну и по записи смотреть какое количество операций записи имеет место быть, iowait и т.п.

В чём это выразится

ZFS создаст специфичрые для Solaris разделы (помимо 516e7cba-6ecf-11d6-8ff8-00022d09712b), которые занимают немного, но никем не используются за пределами Solaris.

на чём отразится

На SSD износ будет неравномерным, например.

Вопрос, а в какое время он будет это делать? Да, я понимаю, что раз в неделю, но это будет в будний день в рабочее время или на выходных. Как он будет время выбирать?

Загляни в этот таймер и сам всё увидишь.

На SSD износ будет неравномерным, например.

Это как? Разве не контроллер принимает решение в какую ячейку писать в SSD?

И да и нет. SSD жонглирует блоками при (пере)записи, но так как раздел не используется, то и блоки (пусть не все, но как минимум часть, которая была записана ZFS при создании раздела, он не может быть абсолютно пустым, даже примитивный FAT пишет метаданные при создании) никогда больше никем не перезаписывается, потому что за пределами Solaris раздел не используется совсем.

Честно говоря полазил, но не нашел где устанавливается время проверки.

Дай наводку плиз

Дай наводку

Могу только на пиво — у меня FreeBSD и systemd здесь в принципе быть не может. ☺

не нашел где устанавливается время проверки.

Открой файл таймера, он лежит где-то то ли в /usr/share/systemd, то ли ещё где-то (смотри файлы пакета zfs, или как он называется у тебя в дистрибутиве на предмет systemd), там должно быть указано время (а ещё оно может быть указано ежедневно, а сама логика вынесена в скрипт, который дёргается из таймера в сервисе, с этим таймером связанным).

ZFS создаст специфичрые для Solaris разделы

Не знал об этом. С OpenZFS на RAW-дисках тоже создаются специфичные для Solaris разделы, которые никакими системными утилитами не видны (и не используются системой)?