Комментарии 53
Вторая статья от хостера про бэкапы и zfs. Если все так хорошо, зачем хардварный raid тогда нужен? Или ресурсов на zfs требуется сильно много и это не всем подходит?
У ZFS есть две киллер-фичи для резервного копирования:
1. Дешевые снимки состояния, с возможностью доступа во внутрь. Вы можете делать checkpoint-ы тысячами, без какого-либо влияния на производительность. Можете их сотнями одномоментно удалять, не заметно для текущих операций чтения/записи.Можете зайти в каталог .zfs/snapshots/имя-снимка и получить копию файловой системы этого снимка.
2. Возможность репликации снимков по сети.
Обычные RAID контроллеры, да и дисковые массивы начального-среднего ценового уровня такого не умеют. Поэтому, нет ничего зазорного в том, чтобы собрать RAID массив с помощью контроллера (ради скорости) и сделать на нём файловой системой ZFS (ради снимков и репликации), решая каждым элементом свою задачу. Естественно возможностей у ZFS сильно больше, но в контексте резервного копирования важны эти две.
Если не секрет, поделитесь в комментарии или статье причинами подтолкнувшими к dattobd и опытом работы с ним?
Использую для создания резервных копий (инкрементальных) образов виртуальных машин на тонких томах независимо от используемых там файловых систем/шифрования.
Статья в профиле есть соответствующая. Со скриптами.
Поэтому, нет ничего зазорного в том, чтобы собрать RAID массив с помощью контроллера (ради скорости) и сделать на нём файловой системой ZFS (ради снимков и репликации), решая каждым элементом свою задачу.
Есть. Для домашнего бэкапчика может и ладно, но нормальный пул категорически не рекомендуется ставить поверх железного рейда. В лучшей книге по zfs это просто обозначено в примерно такой фразе: "Never! Never install ZFS on hardware RAID!"
ZFS не рекомендуют использовать поверх RAID, из-за того, что это нивелирует многочисленные технические ухищрения в ней, направленные на борьбу с ошибками, в том числе аппаратного характера. Из-за того, что выход из строя аппаратного контроллера, в некоторых, редких сценариях может разрушить массив. Из-за большей гибкости в управлении томами, которую может давать ZFS для сложных сценариев.
И всё это никак не соотносятся с другими функциями ZFS, вроде снимков состояния или сжатия.
При этом ZFS в режиме JBOD будет существенно медленней, чем обычный RAID контроллер, с батарейкой, Write-Back и осознанием рисков такого сценария. Или можно функциональностью ZFS дополнить дисковую полку, в которой в принципе нет режима JBOD — и это тоже будет быстрей, чем делать по отдельному LUN на каждый диск. Поэтому нет ничего зазорного, в том, что бы делать пул поверх RAID, если вы понимаете, что при этом теряете и что приобретаете, а не слепо следуете какой-либо книге.
Я задумывался, но вы же в своём комментарии написали просто "нет ничего зазорного". Зазорного нет только в очень ограниченном наборе кейсов и при полном понимании того, что делаешь. А кто-то может прочитать ваш коммент и решит, что нормально будет всегда. Я просто сталкивался с такими пулами, а потом народ хаит ZFS, что тормозит и тп.
При этом, в целом, я в большей степени сторонник наличия резервного копирование данных. Т.е. в ситуациях серьезных сбоев (если это что-то больше горячей замены диска) вы не занимаетесь починкой массива, или файловой системы, а просто пересоздаёте их и развертываете одну из резервных копий. К сожалению, даже CoW ФС можно ввести в полностью не поддерживаемое состояние, когда извлечь с них данные оказывается крайне затруднительно.
Ну а насчёт тормозов и хая — он в значительной мере вызван тем, что функционал не подкреплен адекватными инструментами диагностики и простым описанием последствий для производительности. И пытаясь использовать сложную комбинацию разных функций (а сами ФС это скорей поощряют) можно иногда получить падение производительности в совершенно неожидаемых масштабах.
Нет, киллер фич не две, а намного больше. В новых версиях, например, это возможность инкрементального бэкапа зашифрованного диска без необходимости переливать весь диск. Т.е бэкап сервер не имеет доступа к данным, но имеет возможность бэкапить только разницу!
А ещё ZFS не подвержен ошибкам write hole. А еще не придется бегать и искать точно такой же контроллер, чтобы получить доступ к данным, когда сгорит ваш. Еще гибко настраиваемая прозрачная компрессия из коробки, когда свои параметры сжатия можно применять чуть ли не к каждому диру. В общем… перечислять еще можно долго.
ЗЫ Еще сам не щупал, а только в анонсах читал про новый механизм для решения проблемы ребилдинга z2/z3, когда при замене сбойнутого диска не требуется перечитать пол массива. На больших пулах (а мы же тут не в бирюльки играем?) это просто бомбическая фича. D-RAID чтоли? Вот тут все дешманские (и не очень) железки будут просто курить в стороне. Может кто уже пробовал, будет очень интересно.
Плюс нет дефрагментации и через время выходом будет только ребилд.(насколько я помню)
Не понял, о чем речь про объем? У меня, например, обратная ситуация — LZ компрессия дает мне выигрыш 34% от объема пула, что при пуле 300Тб выливается в заметную экономию.
Дефрагментация там не нужна, в некотором смысле она заложена в принципы cow fs. Хотя в той же xfs тоже нет явной дефраг, и она великолепно живет у меня на десятках нагруженых серверов уже 10+ лет. Дефраг и тп это боль ntfs и другого старья, которое застряло в 90ых )
Кстати, компрессия, помимо объема, даёт прирост в скорости R/W и меньшей утилизации диска. Это неявный момент упускают, а он есть, засчёт того, что диску нужно читать/писать меньше данных с блинов. Конечно, за это платим CPU, но на современных процах нагрузка малозаметна, да и в большинстве случаев баттлнеком является io, а не cpu, поэтому не жалко.
Если все так хорошо, зачем хардварный raid тогда нужен?чтобы его покупали верующие в гарантию и силу бренда, например :)
Оставив конкурента (btrfs) далеко позади
С этого момента поподробнее, плиз.
Недавно сам рассматривал идею поднять на одном из серверов btrfs в raid5 режиме, но подобные проблемы заставили использовать консервативный md, а поверх уже накатил btrfs.
zfs send -R rpool/send-remote@test0 | ssh my-vps-host zfs receive -A hotspare/receive-remote(задумчиво глядя на груду btrfs снапшотов на втором винте)
А вот интересно, по сети так же можно передавать через ssh туннель? Проверить, конечно, можно, но несколько геморройно.
Именно поэтому весь кровавый энтерпрайз до сих пор, несмотря на наличие резервных ЦОД, в том числе бекапит по старинке файлы на ленту, а ленты старается отнести куда подальше.
zfs send старательно отреплицирует битые блоки
Нет, send сломается.
зато он умеет превращать данные в кашу даже на исправных фс, например:
https://github.com/openzfs/zfs/issues/10342
Из того, что видно в обсуждении, выходит, что не превращать в кашу а дописать мусор в конец, и не всегда, а при специфичных условиях.
Вы молодец, что их нашли, конечно. И особенно, что завели issue и сделали reproduce.
Но в подавляющем большинстве инсталляций этот баг не проявится, так ведь?
не превращать в кашу а дописать мусор в конец
И как вы предлагаете восстанавливать файлы?
Актуальная же копия на момент выявления проблемы у вас была?
Проблема в сжатых данных и несжатом arc, что порождает неконсистентность в записываемых данных файлов; очевидно что нужно обеспечить консистентность или отменой вашей специфической настройки или повторно передать уже декомпрессированный снепшот.
Должно помочь.
Актуальная же копия на момент выявления проблемы у вас была?
увы, нет. к счастью, сохранился вывод zfs send, поэтому данные удалось восстановить. сохранился, в общем-то, по случайности: данные из дампа развернули, файлы выборочно проверили, его можно было удалять.
а через какое-то время оказалось, что некоторые файлы «битые».
Зато стало понятно, почему отменили передачу дедуплицированных и сжатых снепшотов.
Кстати, тут не мог бы помочь вариант scrub, если бы его можно было делать не для пула а для данных снепшота? Или при сверке чексумм ошибок в пуле не было?
Зато стало понятно, почему отменили передачу дедуплицированных и сжатых снепшотов.
сомневаюсь, что дело в этом. просто когда вводили compressed arc где-то что-то просмотрели.
многие говорят, что качество нового куда ниже, чем было в сановском zfs. хотя и интересных фич напилили, не поспоришь.
Или при сверке чексумм ошибок в пуле не было?
нет, конечно. чексуммы считаются по записанным на диски данным (а они будут различаться в зависимости от типа vdev, компрессии, recordsize).
Так и не знаю, в чём именно была проблема, думаю, что в оперативной памяти, но немного подозрительно, что проблема проявилась только в одной из структур, но ни разу в содержимом файлов или других местах. Память так же никогда не вызывала нареканий в нормальном процессе работы ни до, ни после этого случая, ФС не билась.
На каждом этапе проверяются контрольные суммы, так что вероятность развития предложенного вами сценария пренебрежимо мала. Ну и да, ZFS создавалась для использования на серверах, а там обычно и память с ECC.
На ZFS с памятью без ЕСС тоже можно получить проблемы, но с большое вероятностью можно заметить ошибки если хоть немного следить за системой…
Но если не следить, то как разница на какой системе в итоге граблями получать?
В любой системе возникаю ошибки: софтовые, аппаратные, комбинации софт+железо, действия пользователя…
В разных системах и сценариях использования каких-то ошибок можно избежать, но появляется возможность возникновения других ошибок. Которые тоже можно компенсировать, но опять могут возникнуть другие ошибки… и т.д…
В итоге все упирается в стоимость мер по устранению ошибок… Кому-то хватит что-то типа NasFree на старом железе, а кто-то дома устанавливает промышленные СХД…
А корпоративное использование — это вообще отдельный разговор…
Из опыта скажу что удалось восстановить почти все инфу с raidz когда начали сыпаться почти одновременно два диска из трех (хотя комп работал пару суток). NAS собранный из обычного офисного компа. На аппаратном или софтовом рейде восстановить не удалось бы… Ну или стоимость восстановления у профессионалов была бы такой что никто не стал бы с этим заморачиваться…
Только вот во всех бенчмарках и реальном использовании для чего-то кроме хранилища (т.е. NAS и бэкапы) ZFS далеко позади Ext4 — как по скорости, так и по IOPS.
Ставить на неё БД или что-то другое кому нужна хороша производительность (особенно со случайым доступом) — просто бессмысленно, все супер-пупер фичи начисто убиваются никакой производительностью, более того, NVMe SSD на ZFS превращаются в обычные SATA SSD (и то если повезёт).
www.percona.com/blog/2018/05/15/about-zfs-performance
Пацаны из Percona прямо говорят что "всё круто если есть куча кэша", и почему-то сравнивают ZFS с XFS, которая сама по себе не особо-то и шустрая (по сравнению с ext4).
Вы свою базу погоняйте на ext4 и расскажите про ощущения — при прочих равных (память etc) ZFS останется в хвосте. Cжатие конечно потеряете — но с учётом стоимости дисков это не особо-то и проблема, особенно когда нужна скорость.
Но спасибо за идею, попробую ext4.
Для Oracle родная как раз Btrfs, они её стартовали как альтернативу ZFS ещё до покупки Sun. А после покупки, и до сих пор вроде не спешат делать двойную лицензию для ZFS, что бы получить совместимость с GPL и возможность включения в ядро.
Насчёт PostgreSQL — база данных не бенчмарк, основные операции чтение/запись блоков в существующих файлах, поэтому, в общем случае прямо какой-то невероятной разницы между разными файловыми системами не будет. Возможно даже наоборот, отсутствие сжатие уменьшит TPS.
Отсутствие сжатия может уменьшить TPS только на очень специфичных нагрузках и на очень медленных устройствах.
Проблема с ZFS это огромный объём метаданных (и сама их структура) плюс необходимость поддерживать их при каждой записи — если база в основном только читается то это может и не быть существенным, но если там ощутимая доля записи — уже всё, TPS проседает только так.
Ну и требования к ресурсам — то что можно получить по производительности на паре NVMe накопителей с ext4 и 32G RAM вы никогда не получите с ZFS — даже если увеличить память в два раза. Если же накопители совсем не SSD, то всё становится вообще очень печально, особенно для постоянно нагруженных по вводу-выводу приложений.
Не скажу за всю Одессу, но на сравнительно небольшой базе (~150G, около 200 клиентов и в среднем ~300 TPS, примерно 80% чтение 20% запись, HDD RAID-5) эксперимент был проведен — на ZFS (которой дали ровно такие же HDD для RAIDZ) среднее время отклика увеличилось в 4 с чём-то раза для записи и примерное вдвое для чтения, общая загрузка сервера выросла (CPU и I/O) — при том же самом железе (Xeon E5-2630, 96GB RAM). База правда примерно в пару раз ужалась, да — но это как бы не совсем важно уже было — так что всё вернули как было.
Но даже это не отменяет мой комментарий, относительно вклада файловой системы, выигрыш от замены RAID-5 на RAID-10 будет существенней, чем от замены файловой системы. Для меня даже как-то дико, что кто-то держит базу на 5-м, учитывая вполне осязаемый риск вылета второго HDD раньше окончания перестроения тома и не очень высокую скорость.
В общем-то то что ZFS добавляет нехилый оверхед из-за метаданных — это как бы факт, исходящий из её архитектуры, она в принципе не может дать производительность на уровне близком к Ext4 — по определению, особенно при записи (когда метаданные расчитываются + производится компрессия и дедупликация). COW также не добавляет производительности — данные сильно фрагментируются в итоге, что сильно бьет если это не SSD.
Ext4 поверх softraid5 не сильно повышает использование CPU — для современных процессоров расчёт-проверка паритета это ничто (особенно когда много ядер), проблемой это было лет 10-15 назад, в ZFS намного больше нагрузки и без паритета (она несущественна только при чтении при условии что данные уже в кэше).
В любом случае — как я уже говорил — при прочих равных ZFS сожрёт больше ресурсов и уменьшит производительность (насколько — зависит от нагрузки), без вариантов.
С базой на RAID5 всё ок — она с репликами, а диски там небольшие (150G Velociraptor) так что ребилд очень шустрый, хотя ещё ни один не умер (меняли один раз с упреждением по истечении гарантии).
Насчёт softraid5 — размер блока у ZFS по умолчанию 128Кб, у softraid5, если не ошибаюсь 32Кб. При случайной записи ZFS будет ~4 раза медленней просто из-за отсутствия адаптации к рабочей нагрузке, без относительно её собственных характеристик. Выше, вы кстати жаловались на рост латентности в 4 раза. У большинства аппаратных RAID дефолтный размер stripe блока тоже 32 Кб.
Если что, то на серверах СУБД у нас XFS и я не агитирую там использовать ZFS, но сравнение у вас действительно некорректно.
Если не использовать дедупликацию и компрессию, то что остается от ZFS? Журналирование всего и удобные снапшоты? Ну так и XFS и btrfs тоже их имеют. Опять-таки, все три (ZFS/XFC/btrfs) всё равно проигрывают ext4 в iops и скорости записи (при прочих равных) — даже без дедупликации и компрессии.
Вот только что провел эксперимент для наглядности — создал в памяти pool (zpool create tank /dev/shm/zps, zps размером 16GB, без компрессии и дедупликации) и тупо писал на него нули:
# time -p dd if=/dev/zero of=/zfs/nulls oflag=direct bs=1M status=progress count=8192
8264876032 bytes (8.3 GB, 7.7 GiB) copied, 15 s, 551 MB/s
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB, 8.0 GiB) copied, 15.6483 s, 549 MB/sЭто память. Просто память — и всего 549 MB/s? При этом всё время проц был нагружен на 50%, если учесть что это Core i7-6700 то де-факто все четыре ядра были использованы на 100%.
А теперь с ext4 (тот же файл что и для пула но уже с ext4):
# time -p dd if=/dev/zero of=/zfs/nulls oflag=direct bs=1M status=progress count=8192
6994001920 bytes (7.0 GB, 6.5 GiB) copied, 2 s, 3.5 GB/s
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB, 8.0 GiB) copied, 2.44143 s, 3.5 GB/sКак говорится, почувствуйте разницу — и это банальная последовательная запись.
Думаете, с дисками будет иначе? Особенно если это NVMe? Вы потеряете существенную долю их производительности, а в случае HDD RAIDZ — скорее всего тоже, да ещё и проц будет нагружен — то есть меньше чем на 8 ядер это вообще ставить стрёмно.
Идеальный бэкап за пять минут с ZFS