Оптимальный объём RAM для использования ZFS в Proxmox

Для файлового сервера есть понятие минимального объёма ОЗУ. Всё что больше, он с удовольствием отъест.

Я когда-то из 32 Гб доступных оставлял порядка 10 Гб свободной ОЗУ прокмоксу. Хранилище, правда, где-то 1 Тб суммарно было, но ехало все нормально (по «субъективным ощущениям»).

Нет каких-то жёстких требований. По дефолту arc жрёт половину оперативной памяти, если ты считаешь, что это много, можно поменять. Думаю, 4 Гб на 3Tb зеркало хватит (я имею ввиду только под arc), но если у тебя есть возможность отдать больше, хуже от этого точно не будет.

Это как на заправке. Мне полный бак. Чем больше тем лучше. Ну а если проблемы то мне всего на 1000 руб. залейте. Ну а если серьезней. Память под кеш можно ограничить. ZFS а точнее arc если его не ограничивать то как уже написали старается забить на 50% память, так что думай ограничивать или нет.

Нет каких-то жёстких требований. По дефолту arc жрёт половину оперативной памяти, если ты считаешь, что это много, можно поменять. Думаю, 4 Гб на 3Tb зеркало хватит (я имею ввиду только под arc), но если у тебя есть возможность отдать больше, хуже от этого точно не будет.

1. А формула какая-то есть для расчёта? Cейчас на сервере 16 Мб, условно из них 8 Гб на сам прохмокс и ВМ, оставшихся 8 Гб на хранилище 3Тб видимо хватит.

А если я захочу к этому тому ещё добавить зеркало 6 Тб - сколько надо будет памяти в сервер добавить?

2. Сама ОС сервера находится на NVMe диске 256 Гб. На нём есть свободное место. Я читал, что кэш и журнал zfs можно разместить отдельно от данных на SDD для увеличения производительности.

Т.е. я вижу как вариант - взять отдельный чистый раздел на системном NVMe диске и разместить там кэш и журнал zfs тома.

Вопросы: а) стоит ли так делать в принципе? б) как вычислить необходимый размер этого раздела? в) стоит ли это делать, если это одиночный NVMe диск, а не зеркало?

а) нестоит если умрет твой NVMe от использования L2ARC по быстрый умрет все. Но ессли умрет ssd с L2ARC то zfs переживет это и даже не поморщится.
б) ну у меня и 256 гб стоит (самый дешманский) потеря этого бойца не сильно влияет на всю работу в целом
в) не стоит смотри ответ а)

а) не стоит если умрет твой NVMe от использования L2ARC по быстрый умрет все. Но ессли умрет ssd с L2ARC то zfs переживет это и даже не поморщится.

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

2. насколько это вообще необходимо - ssd для размещения L2ARC? В каком случае это нужно делать?

Может быть проще дополнительную планку памяти в сервер воткнуть и будет тот же результат?)

Когда-то давно, во времена zfs 0.6, писалось про оптимальный 1Gb RAM на каждый 1Tb хранилища. Без дедупликации, разумеется.

Может быть проще дополнительную планку памяти в сервер воткнуть и будет тот же результат?)

и это правильная мысль. с лучшим результатом.
если в твоём юзкейсе преобладает синхронная запись - делай log на ssd, но он должен быть enterprise level.

ARC - это адаптивный кэш, в зависимости от «просьб» ОС он может ужиматься от zfs_arc_max до zfs_arc_min. Т е ты выставляешь нижнюю и верхнюю границы и он живет в этих границах, динамически меняя свой размер

он называется «Адаптивный» совсем не потому что он динамический.

Может быть проще дополнительную планку памяти в сервер воткнуть и будет тот же результат?)

и это правильная мысль. с лучшим результатом. если в твоём юзкейсе преобладает синхронная запись - делай log на ssd, но он должен быть enterprise level.

1. Почему здесь именно enterprise level? Для надёжности или производительности?

Что будет, если этот ssd с логом сдохнет? zfs том разрушится или автоматически перенесёт log на другой диск?

2. Правильно ли я понимаю, что минимальный надор дисков для моего случая такой:

а) NVMe/SSD 2 шт - системный диск/зеркало

б) NVMe/SSD 1 шт - диск для лога zfs

в) HDD 2 шт - зеркало для хранилища данных, zfs

В свзи с этим ещё вопросы

3. как лучше организовать зеркало на системном (загрузочном) NVMe диске - средствами mdam или zfz?

4. если на ssd хранить не L2ARC, а только log zfs, то в этом случае можно объединить а) и б) - т.е. этот лог будет в отдельном разделе системного диска?

да - все правильно, не по тому, что он динамический. Адаптивный он внутри, все так

1 и да и нет это вопрос филосовский.
2 ну кто запретил гугол или яндекс прочитай про кешироване zfs и потом подумай, а нужет тебе L2ARC или хватит ARC в памяти

Для комфортного использования требуется 4 Гбайт ОЗУ, но конкретная нагрузка может сильно различаться.

А формула какая-то есть для расчёта? Cейчас на сервере 16 Мб, условно из них 8 Гб на сам прохмокс и ВМ, оставшихся 8 Гб на хранилище 3Тб видимо хватит.

Формул нет, всё зависит от конкретно твоего случая. ZFS будет работать и с 1 Gb arc.

А если я захочу к этому тому ещё добавить зеркало 6 Тб - сколько надо будет памяти в сервер добавить?

Тебе никто не ответит на этот вопрос. Смотри статистику, каков % попаданий в кэш, устраивает ли тебя текущая скорость чтения.

Сама ОС сервера находится на NVMe диске 256 Гб. На нём есть свободное место. Я читал, что кэш и журнал zfs можно разместить отдельно от данных на SDD для увеличения производительности.

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

SSD можно использовать в качестве l2arc и slog. l2arc - кэш чтения второго уровня. Всё, что вытесняется из arc, попадает в l2arc. Под l2arc тоже расходуется оперативка. Вот, например, здесь видно, как l2arc отожрал 2.3 гига:

L2ARC size (adaptive):                                         583.2 GiB
        Compressed:                                    93.0 %  542.6 GiB
        Header size:                                    0.4 %    2.3 GiB
        MFU allocated size:                            26.4 %  143.3 GiB
        MRU allocated size:                            73.6 %  399.3 GiB
        Prefetch allocated size:                      < 0.1 %   52.2 MiB
        Data (buffer content) allocated size:          99.7 %  540.9 GiB
        Metadata (buffer content) allocated size:       0.3 %    1.7 GiB

Теперь про slog. Есть такая штука, как zil (ZFS intent log). Zil используется для синхронной записи. Запись бывает синхронной и асинхронной. При асинхронной записи транзакции собираются в группы, и, через некоторое время пишутся в пул. При синхронной записи транзакции пишутся в zil, и остаются в оперативной памяти, чтобы потом быть обработанными так же, как и в случае с асинхронной записью, то есть, быть записанными в пул. В результате, получается так, что в случае нормальной работы zil никогда не читается, а нужен только при некорректном завершении работы, чтобы восстановить не записанные в пул синхронные транзакции. По умолчанию, zil находится на тех же устройствах, что и данные пула, но для него можно выделить отдельное устройство, это называется slog. В качестве slog вполне можно использовать раздел на устройстве, которое уже используется для l2arc.

Теперь про необходимость enterprise ssd. Конечно, для того, чтобы максимально избежать потери нужных данных, нужен enterprise ssd (отличается от обычного наличием конденсаторов, подпитывающих кэш внутри ssd). При использовании обычного SSD, при отключении питания могут пропасть последние несколько транзакций, которые SSD не успел записать во флэш память. Надо понимать, что это, как правило, данные, которые были сгенерированы за последние доли секунды перед отключением питания. Если у тебя какая-нибудь база данных, куда постоянно пишутся новые данные, и нельзя потерять ни одного байта при некорректном отключении питания, то да, тебе нужен enterprise ssd. В остальных случаях, и с обычными, домашними SSD всё прекрасно работает.

Размер slog маленький, зависит от интенсивности записи, обычно несколько гигабайт.

В случае потери slog, пул по умолчанию не запустится, но потеряются только те данные, которые были в slog, пул можно будет импортировать вручную и удалить отсутствующий slog.

Так что, если у тебя критически важная система с постоянной записью, то нужно зеркало. Но, некоторые даже в продакшн прекрасно живут без slog с sync=disabled (без синхронной записи), и всё, что они теряют при некорректном выключении - последние несколько секунд работы системы.

arc можно указывать любые кол-ва ОЗУ и ПЗУ

128

Это сильно зависит от того, насколько Вам нужно кэширование при чтении контента. Если не нужно - ограничьте arc 1Гб. Если нужно и можно перезагружать сервер - то смотрите на % попаданий в кэш и увеличивайте его размер потихоньку. Если кеэировать нужно, а перезагружать сервер нельзя - выдайте сколько можете (4-8 Гб).

По поводу “enterprise ssd”, мне кажется, есть некоторое недопонимание его назначения. При fsync, enterprise ssd может отрапортовать системе «ОК» сразу, как только данные попали в его кэш (так как он их запишет в любом случае за счёт конденсаторов). А десктопный ssd вынужден сначала записать данные, и только потом он может ответить «ОК» на fsync.

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

Ну… товарищ чёрная тень тебе почти правильно всё разъяснил.

Enterprise level это не только конденсатор, это ещё и больший ресурс ячеек, раз этак в 10+.

Я бы очень не рекомендовал размещать лог на системном диске.
Согласись, будет неприятно потерять загрузочный диск.
А вот l2arc на системном диске сделать можно.
Также можно на отдельном диске сделать и лог и l2arc.

Сейчас zfs легко переносит внезапно умерший лог, раньше пул немедленно вставал раком, поэтому для лога использовали 2 диска.
Хотя я видел сетап с 3 дисками под лог. 😏

Насчёт зеркала на системном диске.
Если у тебя загрузка с zfs, нафига тебе mdadm?

Вот такой девайс использовали под лог в одном из сетапов.
Стоил тогда конских денег.
https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/pub...

Насчёт зеркала на системном диске. Если у тебя загрузка с zfs, нафига тебе mdadm?

у меня сейчас 1 системный диск (NVMe), без zfs.

хочу докупить ещё один и сделать зеркало.

желательно без переустановки proxmox с нуля.

пишут некоторые, что всё же зеркало на mdadm для системного диска лучше тем, что:

1. ext4 в случае проблем с рейдом можно легко подключить к другому хосту и восстановить данные
2. работает быстрее, не нужно много памяти.

как из одиночного простого диска сделать зеркало я примерно понял

1. установить в сервер второй диск
2. поднять на нём при помощи mdadm зеркало с отсутствующим вторым диском
3. создать на этом зеркале такие же разделы, как на исходном системном диске и скопировать туда все данные с 1го диска
4. добавить зеркало в загрузчик, чтобы система загружалась с него
5. добавить в зеркало 1ый диск

а можно ли преобразовать обычный системный одиночный диск в zfs-зеркало без потери системы?

Можно.