ZFS на виртуалках это кошмар или нет?

ZFS на виртуалках

zfs в виртуалке не нужна, zfs полезна на хосте.

zfs в виртуалке не нужна, zfs полезна на хосте.

Это все понятно. Но меня интересует случай наоборот. Что если хост (это может быть гипервизор или система виртуализации) изначально не имеет ZFS по какой-то причине? А виртуалки на нем работают.

А виртуалки на нем работают.

Смотря какие виртуалки, если freebsd или solaris, то норм, если linux, то двойной жор памяти.

Да, забыл сказать. Моя виртуалка это FreeBSD и про нее я спрашиваю. Хотя про linux тоже интересно, спасибо)

Эээ, а связь какая, внутри виртуалки fs определяет виртуалка, а не хост

Мне иногда говорят, что ZFS на виртуалках иногда ведёт себя странно.

А кто говорит?

гонял под KVM, Hyper-V FreeBSD 12,13 устанавливал потестить например 13-ю ставил в 10-й рейд на 4 диска. Никаких странностей. Нагрузок никаких кроме разве что развёртывания дерева (via portsnap) портов на 10-й рейд при том, что все виртуальные диски находились на одном физическом из-за чего оно всё работало медленно но. никаких ошибок и странностей..

Я знаю гениев, у которых система развалилась за час при большой дисковой активности. Но это было ZFS на ZFS.

А с ZFS на другой ФС мне самому интересно какая связь.

А кто говорит?

Коллега по работе

А была возможность протестить сборкой LLVM или qt5-webengine или rust. В общем, чем-нибудь жЫрным?

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

А была возможность протестить сборкой LLVM или qt5-webengine или rust. В общем, чем-нибудь жЫрным?

Автор утилиты работал над реализацией i/o в linux и сделал себе тул для замеров https://github.com/axboe/fio

И btrfs, и zfs плохо ведут себя на нагрузке не адаптированной под их специфику. На random write они очень конкретно сливают обычным ФС. То есть размещать на них меняющиеся данные я бы не рекомендовал - там построение такое, что любая единичная операция записи менее блока аллокации превращается в атракцион множества чтений и записи (например обновление дерева хэшей), которые конечно немного нивелируются кэшированием, но именно что немного

Хм, как бы померить, в принципе журналируемая на журналируемой тоже должна быть не бесплатной , особенно на HDD

zfs в виртуалке не нужна, zfs полезна на хосте.

Нужно уточнять на каком хосте она полезна. А то на локалхостах лоровских васянов она скорее всего бесполезна, как прочие «рейд массивы», «эл-вэ-эмы» и остальные потуги на обогрев атмосферы и ЧСВ подкроватным хостингом «чтоб Ъ-ынтерпрайзно» (пока не женятся, конешшшно :)).

что любая единичная операция записи менее блока аллокации превращается в атракцион множества чтений и записи

странно. это точно относится к блокам накопителя. там да. хотим записать - читаем, меняем, сбрасываем на диск блок.

У «блока накопителя» размер 4K. У блока аллокации типичной ZFS - 16 … 64K. Операции внутри диска не прокатываются через PCI, через очереди I/O, через модификацию дерева хэшей ZFS.

Впрочем, не вижу смысла рассказывать что-то. Просто запусти fio блоком 4K и посмотри iostat.

У «блока накопителя» размер 4K

512байт, 512е, 4К но с ССД ситуация не настолько простая как с механикой https://www.delkin.com/blog/the-effect-of-data-write-size-and-patterns-on-solid-state-drive-performance/

Операции внутри диска не прокатываются через PCI, через очереди I/O, через модификацию дерева хэшей ZFS.

все операции записи «прокатываются» через кеш обратной записи что структур ФС что непосредственно данных. Времени сейчас нет раскатывать на железо и что-то там тестить. Верю на слово ), хотя про «тормоза с модификацией дерева хэшей» хочется подробностей что там не так. Вдруг кто-то шашкой махнёт развернуть zfs на прод чтоб было на что опираться и чтоб не делать двойную работу по возврату всё на классическую ФС..

Потому что виртуалка пишет в файл (типа виртуальный диск), который управляется файловой системой хочта, те самое тормозное решение

А то на локалхостах лоровских васянов она скорее всего бесполезна

у меня Btrfs и я периодически что-то удаляю нужное, а потом из снапшота восстанавливаю. Либо вот решу попробовать новый гном, а потом вернуться на нормальную систему, и чтобы не чистить хвосты (у кед и гнома конфликт, например, курсор себя начинает странно вести, так как гномик перезаписывает конфиги), я беру @ и @home на снапшоты заменяю. Недавно я удалил 1000 закладок браузера, тож восстанавливал. Я так как я быдлокодер, то у меня хранятся гигабайты логов, но занимают они 10-15% от реального размера из-за сжатия. ZFS используют аналогично, но с ней, конечно, имеет место какая-то слепая вера сродни в Apple «программы оптимизированы под железо»

как прочие «рейд массивы»

ну два HDD в рейде пишут с двойной скоростью

подкроватным хостингом «чтоб Ъ-ынтерпрайзно»

я тоже не вижу смысла в виртуалках, но потому что есть docker

Вот совсем как для школьников объясняю. В ZFS пространство распределяется фрагментами по 16K. И ZFS не меняет блок в таком фрагменте - она его пишет в новое место - все 16К. Поэтому если ты меняешь 512 байт - операционка читает 16K, записывает их в новое место, вычисляет контрольную сумму, контрольную сумму пишет в узел дерева контрольных сумм, и пишет блок с контрольными суммами тоже в новое место, потом контрольную сумму блока пишет в вышестоящий узел и его также в новое место, его контрольную сумму рекурсивно в вышестоящий блок ии так до корня дерева. То есть у тебя вместо записи 512 байт пролетает запись килобайт этак 100. И сравни это с обычной ФС - даже с data=journal обычная ФС выигрывает.

512байт, 512е, 4К но с ССД ситуация не настолько простая как с механикой

Пофиг. Это все внутри SSD и операционка этим не занимается.

все операции записи «прокатываются» через кеш обратной записи что структур ФС

Операции имзенения данных в классических ФС приводят к модификации иноды которая просто пишется через журнал и перезаписи измененного объема. Это в разы (если не на порядок) проще и быстрей. Кроме того, у ZFS очень большие проблемы с параллельной модификацией одного файла несколькими потоками.

К нам приходил один клиент с ZFS внутри виртуалки. Оно работало конечно - но по по скорости записи сливало XFS и EXT4 в разы, особенно когда дело дошло до модификации данных.

Но в профиле «записал один раз и потом только читаешь» ZFS неплоха - держится на уровне конкурентов. Поэтому ZFS под БД и образы дисков ВМ - нет пути. Под файлопомойку - отлично

Спасибо посмотрю может быть, если время будет документацию по ZFS..

Пофиг. Это все внутри SSD и операционка этим не занимается.

Не совсем. Когда все кеши заюзаны под очереди перезаписи лэйтенси просядает. Особенно если база под 3Тб. Но да в контексте проблемы с перезаписью всего блока с уровня ОС в ZFS это менее существенно. А где, если у тебя есть под рукой, эта документация по zfs? Чтоб долго не искать.

Когда все кеши заюзаны

Так вот «обычные» ФС перезаписывают на диске только метаданные (4K) через журнал (2x4K) + сами данные (4K) - итого 12K. А ZFS перезаписывает под 100K.

Вопрос уровня «только для PhD CS»: под какой ФС этот внутренний кэш SSD быстрей кончится?

А ZFS перезаписывает под 100K.

Мне интересно где это описано. Вот здесь немного по-другому описано https://www.tritondatacenter.com/blog/bruning-questions-zfs-record-size

И btrfs, и zfs плохо ведут себя на нагрузке не адаптированной под их специфику. На random write они очень конкретно сливают обычным ФС.

ZIL решает эту проблему.

Это про компрессию в основном статья

OK/

ZIL решает эту проблему.

Каким местом?

ZIL (как и SLOG) вообще читается когда-либо кроме импорта пула после внезапного ребута, краша и т.п.?

IMHO у ZFS основные проблемы с очень быстрой фрагментацией из-за CoW. Теоретически можно постоянно расширять пул, добавляя новые пустые vdevs, только где их столько набрать?

На практике для дефрагментации можно делать send | receive в другой пул, но это ессно добавляет дополнительную нагрузку :(

А какой software defined RAID местные гуру используют вместо ZFS под базы данных? LVM? Что там с чексуммами ? dm-integrity? А после включения снэпшотов начинается такой же CoWшмар с производительностью ?

Еще вопросик про ZFS, имеет ли смысл периодически приостанавливать SMR диск в скрипте во время attach resilvering, чтобы дать ему про*ться при ресилверинге?

Как это можно решить практически?

cryptsetup luksSuspend / luksResume ?

Какие еще варианты?

А 10% диска на UFS тебе не жалко? Мне вот на 2тб диске, например, 200гб живого места прям очень жалко.

ZIL (как и SLOG) вообще читается когда-либо кроме импорта пула после внезапного ребута, краша и т.п.?

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

Ээ чо?

RTFM

Вынесение zil на mlc-ssd всегда дает буст.

Ничего не перепутал, воен?

Вынесение zil на mlc-ssd всегда дает буст.

Дает по текущим рандомным iops которые СУБД постоянно синкает на каждый commit.

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

Пользоваться крупной базой данных, расположенной на ZFS пуле, состоящим из HDD хоть и с SSD кэшем, абсолютно нереально, пока не прогреется достаточно большой L2ARC размером, равным примерно активной части базы, нередко около половины базы. Даже прогрев кэша самой СУБД не спасает, приходится ждать прогрева L2ARC, а это несколько часов. Наверно, хорошо, что в новых версиях ZFS есть persistent L2ARC.

Можно раскидывать части базы по разным пулам. Причем более нагруженные типа активного лога (например, у Db2) на более быстрый, но небольшой пул, собранный только из SSD, который можно еще и дефрагментировать (через send | receive) чаще другого большого HDD пула.

Ничего не перепутал Нет, ничего не перепутал.

https://www.truenas.com/docs/references/slog/

A separate high-speed SLOG device provides the performance improvements so ZIL-based writes are not limited by pool input/outputs per second (IOPS) or penalized by the RAID configuration. Using a SLOG for ZIL is recommended for database applications, NFS environments, virtualization, and data backups. In general, a storage environment with heavy synchronous writes benefits from using a SLOG for the pool ZIL

воен

Оттягиваешь спереди резинку трусов и громко, с выражением говоришь такое туда.

Ок, непробиваемый.

Посмотри кому и на что отвечаешь.

Наверно, хорошо, что в новых версиях ZFS есть persistent L2ARC.

Да. Не плохая штука. Сделал большой кеш в ОЗУ, сделал l2arc. Из ОЗУ читается 90% из l2arc - всего 10%. Но, это специфика моей нагрузки. На обычных HDD (7200 оборотов) в 10м рейде, вполне не плохо zimbra на пару сотен людей и терабайты данных поживает. :)

Разве всегда? При async с настройками по умолчанию, не должно же писаться ничего в zil. Могу сказать, что я понял, что такое zil на СУБД… - Земля и небо. :)

А зачем дефрагментировать пул на SSD?

А зачем дефрагментировать пул на SSD?

Чтобы быстрее работал, иногда в разы. По крайне мере по моему опыту с Samsung SSD на обычном персональном компе.

Чтобы быстрее работал SSD, нужно включать TRIM, а не заниматься фигнёй с дефрагментацией.

Возможно, пока не пробовал на том SSD. В то время на ZOL v0.6.x трима вроде еще не было даже?