LINUX.ORG.RU

История изменений

Исправление Black_Shadow, (текущая версия) :

А формула какая-то есть для расчёта? 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 (без синхронной записи), и всё, что они теряют при некорректном выключении - последние несколько секунд работы системы.

Исходная версия Black_Shadow, :

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

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

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

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

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

Можно отделять на отдельный 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 (без синхронной записи), и всё, что они теряют при некорректном выключении - последние несколько секунд работы системы.