С выдачей результата близкого к рилтаймовому

От кейсов зависит, это да.

Привет!

Это из чата KVM

ребят, а кто-нибудь юзает в продакшене zfs-on-linux под проксмоксом? думаю, стоит ли использовать zfs в качестве локального стораджа

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

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

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

Та все сложно :) Если коротко - не кэшед, но availiable. Система приехала из Unix мира, со своим взглядом, ну и прикрутили к линуховому мэнеджеру памяти. Я не готов глубоко технически обсуждать именно реализацию ZoL но выглядит это так, что при запуске например kvm, которому нужно больше памяти чем free+swap+cached - оно вас просто пошлёт куда подальше, несмотря на то что в avail показывает, например, 64GiB Но в случае, если памяти хватит и квм запустится (справедливо для любого очень крупного по памяти процесса), при этом свободной памяти станет меньше чем какой-то лимит, сработает триггер zfs и он тупо вытеснит весь не активный кэш (memory throttle на языке zfs). Т.е. у вас получится запущенная виртуалка, при вытесненном кэше и со 60GiB free RAM. При этом, естественно, будет тяжёлый IO, ну собственно сама же виртуалка запускается, а соседи работают, а их данных в основном в кэше уже нет... Т.е. начинается разогрев кэша при интенсивной нагрузке, со всеми вытекающими (не, если внизу ссд - оно норм, там больших wait io не будет). Так что вот такой у нас мэнеджмент памяти, нужно понимать при эксплуатации в гиперконвергентных окружениях (т.е. как локальный стораж на хосте с большой нагрузкой по памяти)

Минимаемый и максимальный объём памяти, занимаемый zfs arc, очень легко контроллируется системными переменными. Способ зависит от реализации.

еще немного )

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

Дейтвительно нужно достаточное количество памяти, это общая рекомендация для 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 на ZOL то же самое?

привет

Привет! это типа 16,0E в смысле? Ну возможно и из-за сжатия, я не видел такого

это превышение объёма диска и соответствующая хрень в расчётах - 16 экзабайт :D

-1 короче в результате

судя по всему

ну да, переполнение

О кто то с Одессы)))

ага )

не, слишком много общих групп

@guru_support

привет)

привет

ты в соседнем чатике обеспокоины судьбой ZFS

ты в соседнем чатике обеспокоины судьбой ZFS

+1 в proxmox чатике тоже переживают

лично меня беспокоит почти неработающее кеширование в FreeBSD 12-STABLE

В проксе там вообще чудеса с файловой системой

непонятно, кто IOPS потребялет в таких количествах

https://t.me/ru_proxmox

приходи

не

я планирую мигрировать в сторону cbsd

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

непонятно, кто IOPS потребялет в таких количествах

Как раз решаю данный вопрос с искази

Нюанс даже не проксмокса, а куему

Учу дтрейс 😁

у меня недорейд в сервере HP G8

Я вообще в хба

@guru_support я конечно понимаю что минимализм это хорошо но я бы сраницу всё же малость разбавил)))

в пике 1200 IOPS на запись

я не планирую вести там блог с советами

всем, чем хочу поделиться - делюсь на гитхабе

Сейм щит

всем, чем хочу поделиться - делюсь на гитхабе

да и серое на сером эх...

Даёшь больше лиссяр

Хотя домменное имя на каждый язык это вообще уникально))

и не на гитхабе

лично меня беспокоит почти неработающее кеширование в FreeBSD 12-STABLE

Они там уже в зол ушли?

хотя можно было извратиться

всем, чем хочу поделиться - делюсь на гитхабе

+1

Они там уже в зол ушли?

еще нет, но Team Core анонсировало планы

Насколько я помню, у прокса 3-4 ветки были проблемы с внешними iSCSI (на ZFS)

но имхо, тут виновато древное Линуксовое ядро

Уже 5 ветка

В 5 все стабильно

для этого надо на чем-то тестировать и уговаривать владельцев хостов на миграцию

Новое ядро товальд сделал, слышали?

Новое ядро товальд сделал, слышали?

Ну не то, что бы сделал

и точно не сам :)

привет!

Выпуск ZFS on Linux 0.8.0, реализации ZFS для ядра Linux https://opennet.ru/50730/

Развивается.

Добрый день! В проде использую zfs. У меня нет никаких специфичных кейсов (кроме сжатия и снапшотов), но периодически фэйлится scrub, находит "битые" файлы, и это очень печалит Вопрос в том, зависит это от того, сколько устройств под пулом zfs или нет У меня сейчас всегда одно - железный RAID10, как положено, с батарейками и резервным хардом. Улучшит ли ситуацию создание пула из N raid0 (мои LSI не умеют диски как raw)

Добрый день! В проде использую zfs. У меня нет никаких специфичных кейсов (кроме сжатия и снапшотов), но периодически фэйлится scrub, находит "битые" файлы, и это очень печалит Вопрос в том, зависит это от того, сколько устройств под пулом zfs или нет У меня сейчас всегда одно - железный RAID10, как положено, с батарейками и резервным хардом. Улучшит ли ситуацию создание пула из N raid0 (мои LSI не умеют диски как raw)

Привет! С одной стороны конечно пул будет лучше, но что конкретно ты понимаешь под фейлится scrub и находит косяки.

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

Частенько на SSD у меня scrub заканчивается с checksum error but applications are unnaffected - что связано с логикой работы системы коррекции CRC самих дисков, а scrub находит несоответствие эти и ругается. Страшно очень, но делаешь zfs clean rpool и живешь дальше :))

Привет! С одной стороны конечно пул будет лучше, но что конкретно ты понимаешь под фейлится scrub и находит косяки.

приблизительно, это: root@stockholm-host:~# zpool status -v pool: zfs state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://zfsonlinux.org/msg/ZFS-8000-8A scan: scrub repaired 0 in 5h15m with 1 errors on Sun May 12 05:39:29 2019 config: NAME STATE READ WRITE CKSUM zfs ONLINE 0 0 22 sda3 ONLINE 0 0 44 errors: Permanent errors have been detected in the following files: <0x124>:<0x7416> <0x147>:<0x7416> zfs/containers/stockholm:<0x7416> <0x16b>:<0x7416> <0x18b>:<0x7416> <0x1a8>:<0x7416>

Добрый день! В проде использую zfs. У меня нет никаких специфичных кейсов (кроме сжатия и снапшотов), но периодически фэйлится scrub, находит "битые" файлы, и это очень печалит Вопрос в том, зависит это от того, сколько устройств под пулом zfs или нет У меня сейчас всегда одно - железный RAID10, как положено, с батарейками и резервным хардом. Улучшит ли ситуацию создание пула из N raid0 (мои LSI не умеют диски как raw)

Либо райд подводит, либо оперативка

приблизительно, это: root@stockholm-host:~# zpool status -v pool: zfs state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://zfsonlinux.org/msg/ZFS-8000-8A scan: scrub repaired 0 in 5h15m with 1 errors on Sun May 12 05:39:29 2019 config: NAME STATE READ WRITE CKSUM zfs ONLINE 0 0 22 sda3 ONLINE 0 0 44 errors: Permanent errors have been detected in the following files: <0x124>:<0x7416> <0x147>:<0x7416> zfs/containers/stockholm:<0x7416> <0x16b>:<0x7416> <0x18b>:<0x7416> <0x1a8>:<0x7416>

кстати, для информации какой raid controller и версия OS? чисто для статистики

Зфс крайне не рекомендуется использовать с рейдами

Используешь - жди потери данных

То же самое и с оперативкой не ецц