ZFS используем. Можно использовать, хотя есть нюансы: память ECC нужно (так как считаются чексумы, могут побиться данные в случае проблем с памятью), следить за памятью ZFS ARC, нужно понимать, что он будет стремиться занять 50% всего объёма RAM, так что если интенсивно запускать/создавать вм на узле где zfs - может быть out of memory (можно динамически менять размер ARC, т.е. освобождать память, но руками придётся). Бывают проблемы с командой sync системной (используется в скрипте update-initramfs например, может команда зависнуть в ожидании ответа от zfs в uninterruptable state) , встречал несколько раз на старых версиях. Swap на zfs - плохая идея (по умолчанию прокс больше не создаёт swap на zfs). Не используйте дедубликацию (справедливо для всех реализаций zfs, не только ZoL). По причине использования механизма CoW, не щадит ssd, что особенно существенно для десктопных (там ещё и sync операции на них медленные), на "взрослых" ssd (серверных) все хорошо и ровно (они умеют нормально управлять своим кэшем, так как он у них энергонезависимый, а значит и не так агрессивно его сбрасывают на запросы zfs)

В остальном все работает нормально. Сжатие на лету, thin provision, "бесплатные" снэпшоты, инкрементальная репликация... Все за что любим zfs

Привет, Есть вопрос по опции detect-zeroes=on|unmap & discard-mode=unmap какой из данных вариантов оптимальнее всего для SATA/SSD на базе LUKSv1/ext4? Флаг discard не задействован.

Спасибо за инфу! Жаль, не выглядит как "вариант для ленивых".

Linstor

Только овирт его не умеет, не хочешь OpenNebula попробовать?

- ecc нужен, как и для любой ФС. Как раз за счёт чексумм у zfs выжить в случае подыхающей оперативки больше.
- размер arc настраивается, по дефолту - 50%, но никто не мешает сделать меньше

А эта оперативка считается как кешед или как резидент

Спасибо, почитаю

Та все сложно :) Если коротко - не кэшед, отображается как used, но отрабатывает как cached, т.е. постепенно отдает память по мере нарастания нагрузки на память. Система приехала из Unix мира со своим взглядом на работу памяти, ну и прикрутили к линуховому мэнеджеру памяти так, как получилось.
Я не готов глубоко технически обсуждать именно реализацию ZoL но выглядит это так, что при запуске например kvm, которому нужно больше памяти чем available - оно вас просто пошлёт куда подальше, несмотря на то что arc_summary показывает (можно просто в /proc/spl/kstat/zfs/arcstats посмотреть), например, что у вас кэшем занято 64GiB

Но в случае, если памяти хватит и квм запустится (справедливо для любого очень крупного по памяти процесса), при этом свободной памяти станет меньше чем какой-то лимит, сработает триггер zfs и он тупо вытеснит весь не активный кэш (memory throttle на языке zfs). Т.е. у вас получится запущенная виртуалка, при вытесненном кэше и со 60GiB free RAM. При этом, естественно, будет тяжёлый IO, ну собственно сама же виртуалка запускается, а соседи работают, а их данных в основном в кэше уже нет... Т.е. начинается разогрев кэша при интенсивной нагрузке, со всеми вытекающими (конечно, если внизу ссд - оно норм выдержит, там больших wait io не будет, но на шпиндельных дисках — это очень чувствительно).

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

Подтверждаю , сталкиваюсь иногда с такой ситуацией

Получается нужно дофига рам, спасибо за инфу

Дейтвительно нужно достаточное количество памяти, это общая рекомендация для ZFS.  Но стоит понимать, что дело даже не в RAM, сам по себе ZFS будет занимать столько, сколько установлено в параметре модуля zfs_arc_max (динамические можно менять параметр через изменение /sys/module/zfs/parameters/zfs_arc_max), значение которой по умолчанию 50% от всего RAM. Причем, для того чтобы все активное было в кэше, нужно зачастую не очень много памяти (хотя зависит от профиля использования и разношертности работающих ВМ, естественно). В обычной практике, логика занимать всю доступную память под кэш - очень правильная, так как "Unused memory is wasted memory", и zfs даже в Linux умеет аккуратно возвращать занятую в ARC (кэше) память по мере необходимости системе, но! профиль работы хоста гипервизора таков, что там нагрузка  по памяти возрастает не "гладко", а скачкообразно, например, вы запускаете гостя с 32GiB RAM, а значит KVM пытается сразу замапить 32 ГБ в системе, что приведет к резкому уменьшению available памяти и возникает ситуация, по логике мэнеджера кэша ZFS, требующая срочного и агрессивного вытеснения всего кэша (мол, ужас кошмар, памяти свободной резко не стало, надо срочно возращать системе все что сможем).
Конечно, можно ограничить ZFS просто каким-то минимально необходимым объемом и жить с 60-70 GiB свободной памяти на хосте и даже не дуть в ус (хотя, даже в этой ситуации вы не застрахованы, что при запуске очередной VM большой вы попадете в лимит и ZFS проделает то же самое, т.е. вытеснит весь КЭШ до zfs_arc_min, просто вероятность этого меньше), но опять же жалко, что память проставивает.
Как  вариант, можно отрабатывать эту ситуацию самим, не дожидаясь действий ZFS, т.е. перед размещением крупного гостя, подвигать парамет zfs_arc_max на нужную величину, предупреждая работу логики ZFS, а после возращать обратно параметр (там же еще есть KSM, который постепенно дедуплицирует занятую гостями память и постепенно отдает системе)

Поправлюсь, занятая в ZFS ARC память считается ядром Linux не как cached (и, соответсвенно, не попадает в подсчет available), а как занятая, таким образом в выводе free она used:
Because of how ZFS on Linux is implemented, the ARC memory behaves like cache memory (for example, it is evicted if the system comes under memory pressure), but is aggregated by the kernel as ordinary memory allocations. This can lead to confusion as the system appears to have far less free memory than would be expected given the current system workload, but is normal.

Собственно поэтому KVM скажет out of memory, так как оно смотрит на количество доступной памяти (available), а память занятая ARC будет суммироваться в used

Постараюсь подытожить, ZFS можно использовать на хосте гипервизора, как локальное хранилище, работает это в достаточной степени надежно, но есть целый ворох нюансов, которые нужно учитывать. Потому, при наличии сколь-нибудь хорошей сети и нескольких хостов гипервизоров, более целесообразным выглядит использование выделенного под хранилище хоста, а уже на нем можно ZFS (причем лучше на какой-то соляре) и iSCSI (comstar на соляре хвалят). Кстати, в том же  Proxmox, например, даже есть реализация програмная возможности использовать ZFS over iSCSI (т.е. оно скриптом заходит на хранилище, создает ZVOL и потом экспортирует его через iSCSI taget подключая к создаваемому гостю). В результате получаем одновременно преимущества ZFS, отпадают нюансы гиперконвергентной системы (и при использовании соляры, еще и нюансы ZoL отпадают), кроме того появляется возможность использовать shared storage (т.е. можно по живому мигрировать машинки между хостами).
Но iSCSI — это уже другая история и, как я понимаю, спрашивающие про ZFS как локальное хранилище, не ищут совета по созданию многоуровневой инфраструктуры с выделенным слоем хранения данных 😊

и какой таргет под линупсом использовать тогда?

@PavelTacid
Спасибо за бесценные знания 🤝

эх... ) есть мнение, что под линуксом как-то не очень сложилось с iSCSI target-ами. Я бы и сам хотел услышать предложения. На текущий момент видел 3 живых варианта: 1) tgt в юзерспейсе (http://stgt.sourceforge.net/) 2) ядерный LIO (http://linux-iscsi.org/) 3) scst (http://scst.sourceforge.net/)

Из недавнего опыта, пробовал LIO — ну... оно может подвесить хранилище, у меня получилось за не очень долго, правда при интенсивных тестах и попытках завести iSER (т.е. iSCSI Extensions for RDMA) на qemu + libiscsi

Кстати, тут есть умельцы, которые смогли libiscsi 1.18 с поддержкой RDMA использовать с qemu для запуска виртуалок? Поделитесь, пожалуйста, опытом. Уж TCP реализация в libiscsi очень унылая, имхо, либо я ее не умею готовить. Ибо получается, что использование напрямую qemu + libiscsi монтирование iscsi lun работает медленнее, чем open-iscsi на хосте, сверху LVM, а его уже монтировать в qemu

попробуй istgt - он просто огонь!🔥

я просто тупо юзаю tgt уже 4-й год