ZFS vs mdadm

но что-то многие пишут про ошибки чексумм с не-ECC памятью

По моему только один здесь такое писал, с разогнанным вусмерть железом, де ещё м пруфов не предоставил.

ещё ZFS vs mdadm (комментарий) в это верится больше.
Но имхо, даже для 36ТБ многовато, тем более, если прошёл только 1 квартал

С ZFS это особенно актуально потому-что с ZoL и тюнить нечего, оно что с prefetch, что без - тормозит почти одинаково. А в ядре всего где-то 10-15 параметров в /sys/module/zfs/parameters/, и еще не во все можно писать.
К слову раз уже начал у меня zpool c loop файла под ext4 работал даже быстрее чем раздел под ZFS на том же диске, такого же размера как файл.

с ZoL и тюнить нечего, оно что с prefetch, что без - тормозит почти одинаково.

Не только в префетче дело. Например, volblocksize на zvol очень сильно влияет на производительность.

zpool c loop файла под ext4 работал даже быстрее чем раздел под ZFS

Работал быстрее с какими данными и в каком паттерне нагрузки?

у меня гента с корнем на

Кстати, монолитно в ядро собирать не приходилось?

у меня гента с корнем на

Кстати, монолитно в ядро собирать не приходилось?

Пробовал, собралось. Но без initramfs делать нечего — userspace-утилиты необходимы, потому вообще пофиг как собирать.

Работал быстрее с какими данными и в каком паттерне нагрузки?

Копирование мелких файлов, таких как .so, файлы конфигурации и т.д., в основном то, что было в самом образе контейнера (базовая система) в корень под xfs, на другом физическом диске. Этот тест делал чисто ради лулзов (когда уже стал готовиться выносить все с ZFS), думая что оно будет тормозить еще больше, но внезапно оно тормозило меньше (порядка на 40-50% быстрее копирование было).

имхо, это не совсем типичная нагрузка, обычно чтение преобладает и горячие данные в arc zfs (и l2arc, если есть) работают отлично и показывают лучшую производительность, чем классические ФС. Но, конечно многое зависит от железа, от объёма ОЗУ, в частности.

Ну у меня обычная нагрузка это несколько LXD-контейнеров, в которых в каждом работают свои стандартные службы, бэкап (как раз таки обычно мелких файлов конфигурации и логов), плюс еще в каждом могут крутиться свои совершенно разные сервисы, плюс еще один контейнер который проксирует и кэширует сайты. При этом это все еще и постоянно в автоматическом режиме обновляется, и где-то работает репликация с другими контейнерами, который находятся весьма далеко географически. Но в общем то было на очень бюджетном железе, правда и на десктопе с 8гб памяти и мобильным i7, ZFS тоже у меня примерно также сильно тормозила в подобной нагрузке (минимум все в два раза медленней чем с ext4/xfs/btrfs).

LXD-контейнеров, в которых в каждом работают свои стандартные службы

Скорость ФС, в этом случае, не имеет никакого влияния.

бэкап(как раз таки обычно мелких файлов конфигурации и логов)

Нужно сделать снапшот средствами ZFS и передать снапшот (инкремент) на бэкап-сервер. Нет никаких мелких файлов.

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

Допустим между географически распределёнными контейнерами скорость аж 100Мбит/сек, есть вопрос, сколько контейнеров, их размер и периодичность репликации?

Скорость ФС, в этом случае, не имеет никакого влияния.

Более чем влияет, особено когда она в 2-3 раза ниже (у меня было почти 8 раз!) с ZFS. Даже банальное обновление с unattended-upgrades тогда превращается в ад. Т.е. это практически при любой емкой дисковой операции все встает, дикий iowait и т.д вплоть до того, что ты по ssh не зайдешь.

Нужно сделать снапшот средствами ZFS и передать снапшот (инкремент) на бэкап-сервер. Нет никаких мелких файлов.

Помимо снапшотов контейнеров, делаются и бэкапы файлов. Потому-что снапшоты сам LXD-хост не покидают. Если делать передать снапшоты контейнеров, то это будет примерно по 30 минут - часу на каждый контейнер. Это не приемлимо. А так у меня уже через 5 минут последняя копия файла, если были изменения.
Репликация только postgresql у меня, и там master-master, так что можно сказать что постоянная. Но есть некоторые сервисы которые постоянно передают мелкие файлы между контейнерами.

Помимо снапшотов контейнеров, делаются и бэкапы файлов. Потому-что снапшоты сам LXD-хост не покидают. Если делать передать снапшоты контейнеров, то это будет примерно по 30 минут - часу на каждый контейнер. Это не приемлимо. А так у меня уже через 5 минут последняя копия файла, если были изменения.

Я не совсем понял, что у тебя происходит, но могу уверенно сказать, что передать инкрементный снапшот zfs будет всегда быстрее передачи отдельных файлов.

Более чем влияет, особено когда она в 2-3 раза ниже (у меня было почти 8 раз!) с ZFS.

Есть в хозяйстве ферма контейнеров lxc, лежат на zfs, скорость выше, чем на любой классической ФС, практически всё в горячем кэше.

инкрементный снапшот

Это надо где-то полный хранить тоже. Я могу хранить вообще 20мб на контейнер и меньше в файлах, если в нем нету баз данных никаких.

Это надо где-то полный хранить тоже.

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

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

Опять не до конца понял. Кто мешает сделать lxc-контейнер (или любой другой) на zfs, затем сделать необходимое количество клонов, с некоторыми изменениями, и бэкапить их через снапшоты?
Размер бэкапа будет равен базовому снапшоту + инкременты всех контейнеров оптом. Это наиболее экономичный, с точки дискового пространства, способ резервного копирования.

Так бэкапы будут только на самом LXD-хосте. Это означает, что если что-то случится с оборудованием, то ты потеряешь все включая снапшоты. Потом из снапшота не очень удобно вытаскивать специфичный файл и т.д

Так бэкапы будут только на самом LXD-хосте.

Через zfs send-recieve передаём снапшоты на другой хост.

Потом из снапшота не очень удобно вытаскивать специфичный файл и т.д

Очень удобно, снапшот монтируется.

Я не знаю, как тебе уже объяснять, но тебе все равно придется хранить полный образ, на другом хосте в таком случае. Потом контейнер может очутиться соврешенно на другом LXD хосте, где не будет btrfs или zfs (которой у меня нигде нет), или контейнер понадобится передать кому-то другому для исследования, в таком случае независимая система бэкапа, которая будет работать сразу после того как контейнер включат в любом другом месте где есть доступ в интернет, сыграет на руку. Почему у тебя такая неприязнь бэкапов в файлах и архивах, я не знаю.

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

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

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

Чем файлы контейнера отличаются от снапшота контейнера, в плане занимаемого диского пространства?

rootfs контейнера это обычная базовая система без ядра + твой установленный софт + конфиги софта которые ты установил + «пользовательские данные», ну и логи. Если ты знаешь какой софт используется в контейнере, то тебе достаточно сделать бэкап только нужных тебе файлов конфигурации и пользовательских данных, ну и возможно нужных логов, но копировать базовую систему и установленный софт тебе не нужно, потому-что это легко воссоздать обратно. Так что как правило если в контейнере нету базы данных, то тебе достаточно скопировать всего-лишь несколько файлов.

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

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

если в контейнере нету базы данных

Такое редко бывает.

Вообще, как работает ZFS переваривает много мелких файлов, относительно той же ext4?

Я не следил и не сравнивал. Каких-то критичных проблем с производительностью не было.

Это сколько винтов, и какого уровня рейд?

Raid-Z2 из 8+2 дисков по 4 Тб

Много - понятие растяжимое, для кого-то и 1000 файлов много.

У кого ещё ZFS, вопрос остаётся, сколько на разделе файлов (мелких), и как она справляется?

Такое редко бывает.

У меня большинство контейнеров без баз данных.

По мне, это никчёмный геморрой с развёртыванием в случае факапа.

Определенный есть, но учитывая что большинство вещей уже забиты в salt-рецепты, то он определенно меньше. Зато место очень сильно экономится, а оно дорогое. В будущем когда оно будет готово я вообще планирую использовать сeph, тогда у меня будут доступны все контейнеры с каждого LXD хоста, это позволит сэкономить место еще больше, и будет моментальное «копирование» на всех LXD хостах, это если сeph не будет слишком медленным.

Зато место очень сильно экономится, а оно дорогое

Это, кстати, не очевидно. Во-первых, на zfs включено сжатие, во-вторых, как я уже отмечал выше, все контейнеры клонированы из одного снапшота и фактически каждый контейнер отличается от базового только набором пользовательских данных и логов.

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

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

Нет. При передаче на другой хост будет точно такая же структура, один базовый снапшот + разница каждого контейнера от базового + изменения по времени.

Btrfs можно все тоже самое, только она в отличии от сабжа оно у меня не тормозит.

Если коротко, то не надо использовать btrfs, тем более в продакшене.

Нет. При передаче на другой хост будет точно такая же структура, один базовый снапшот + разница каждого контейнера от базового + изменения по времени.

Будет передаваться целый контейнер, потом уже с него да можно будет снапшоты делать, уже на другом хосте. По-другому: Разве что только ты скопируешь весь pool, но это уже получится копия хоста, а не бэкап. В любом случае у тебя бэкап никак меньше чем, место которое все контейнеры занимают на pool'е не будет.

Разве что только ты скопируешь весь pool

И снова нет. Я передам только нужные ФС, но не весь пул. Почитай доки к zfs, ты оперируешь домыслами, когда есть факты. Держи https://docs.oracle.com/cd/E19253-01/819-5461/

Я просто знаю как работает lxc copyl, мне даже доки ZFS для этого не нужны.

чтобы работало быстро, здесь и сейчас - ставь mdadm

mdadm собирал мне raid5 всю ночь и это только для установки ОС на чистой конфигурации, от чего я дико офигел и после этого им не пользовался.

А за остальную инфу спасибо.