Резервирования под ZFS

[Maksim Shulga]

Чисто консультативный момент. Уже несколько систем запустил, и тут вдруг задумался, правильно ли я делаю...

При создании pool делаю дефолтное резервирование 20%, на примере SSD 960Gb pool создается примерно 722 GiB.

Дальше создаю zvol чтоб отдать по iSCSI, и тут тоже резервирование просит 20%, тоже даю, получаю на выходе объем примерно 577 GiB.

Все правильно, или в каком-то месте не нужно делать это резервирование ? а то реально я понимаю, что от массива использование получается грубо говоря 60% :)

цифры очень приблизительные, и тут не входит расчет накладных расходов под всякие RAID-Z, поэтому для примера взял единичный диск

 

[mav@]

Самому по себе zvol резервирование не нужно. Нужно чтобы на пуле было достаточно свободного места чтобы фрагментация не росла слишком быстро. Но в целом да, для блочного хранилища которое будет активно и случайно перезаписываться 40% свободного места на пуле это нормально. Выше стоит лезть только если это что-то что будет писаться линейно и однократно. А если пул на SSD то можешь назвать это взносом в его долговечность.

 

[Maksim Shulga]

ы-ы- :) ответ такой получился... неоднозначный
то что экономия SSD, это конечно понятно

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

а вот тут непонятно :) в пуле резерв 20% (не 40), а потом еще 20% при создании zvol, это ж уже не к пулу %
что-то я запутался

создание pool система по-умолчанию резервирует 20%, при создании внутри него zvol есть опция форсировать размер/объем, но! очень четкое предупреждение прям на самом интерфейсе

The system restricts creating a zvol that brings the pool to over 80% capacity. Set to force creation of the zvol (NOT Recommended)

Если это имеет значение: вся система All-Flash, поэтому нет никаких Zill/Arc, по iSCSI отданы диски на SQL Server, FreeNAS выступает в роли хранилища БД внешнего SQL Server

так нужен резерв в zvol или нет ? как он тут используется вообще... по iSCSI раздел на zvol размечается в NTFS разумеется, под БД SQL Server

 

[mav@]

Все на самом деле просто -- на пуле должно быть свободное место для работы аллокатора, минимум 20%, а лучше 40. Как эту будет достигнуто -- не важно. Можно ставить везде резервы и тогда ZFS не даст за них выйти, вызвращая ошибки. А если данные ожидаются хорошо сжимаемые, то можно и наоборот -- резервации убрать (поставить галочку тонкого провижионинга в zvol) и даже сделать zvol больше пула, но тогда надо строго следить за свободным местом. Ну или компромисный вариант -- создать zvol чуть меньше, создать пустой dataset с резервом как крайнюю меру, а свободное место освободившее в результате сжатия использовать для снапшотов.

 

[Maksim Shulga]

я на пуле под БД SQL сжатие вообще отключаю, зачем лишние накладные расходы
короче, вывод делаю, что :
1) нужно резерв 20% и при создании пула (в моем случае mirror ssd из 2х)
2) нужно резерв 20% и при создании zvol и подключении по iscsi

т.к. проброшенный в винду раздел будет ntfs, то пул делаю кластер 4К, zvol делаю 4К, а при создании раздела под виндой делаю выравнение и кластер 64К, как рекомендация MS. я пробовал играться на пуле и zvol делать более 4К, не помню, то ли винда, то ли SQL не понимает и не может с этим работать. вроде все-таки SQL

 

[mav@]

4KB блок zvol напрочь убьет последовательную производительность за счет накладных расходов на обработку отдельных блоков. Я не спец по MSSQL, но рекомендовал бы подумать нельзя ли увеличить.

 

[mav@]

MSSQL и правда не любит хранилища с большим блоком, но для того в настройках iSCSI extent есть параметр скрывать физичкский блок от инициатора.

 

[Maksim Shulga]

4KB блок zvol напрочь убьет последовательную производительность за счет накладных расходов на обработку отдельных блоков

да, думаю да... но дело в том, что в MSSQL последовательная производительность, это только работа с бекапами или копирование/перенос БД ... а сам SQL в работе с БД больше работает грубо говоря "рандомно"
я думаю эта тема вообще интересна будет многим и наверное я ее выведу в отдельный топик, как раз экспериментирую, и нужно в продакшн выложить на iscsi БД 1,3ТБ ... конечно может кого насмешу, но для меня это очень большая БД :)

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

а я вот экспериментировал с этим параметром, и что-то не сложилось... но наверное еще на ветке freenas-11.2, может нужно повторить эксперименты на 11.3 , думаю таки отдельный топик сделать

 

[Maksim Shulga]

Я конечно прошу прощения, наверное еще раз эту тему подыму...

Вопрос на примере:
- сервер с отдельным загрузочным DOM и 4 HDD по 4 TB , RAM 32 GB
- плановая функция - массив под бекапы Veeam (вирт. машины + БД), а если конкретно, нужно диски отдать по ISCSI на сервер LINUX, который выступает в роли прокси-linux для Veeam

Вопрос в оптимальности использования дисков, максимизация полезного объема.

Плановая платформа - TrueNAS 12
Создаем ZFS Pool из всех дисков RAID-Z1, пересчет - 1 диск 3,64 TiB x4 = 14,56 TiB zpool storage capacity, Enable Atime-Off, Exec-Off, RecordSize -128KiB, на выходе получаем 10,24 TiB (11,2 TB) , мин. резервирование соблюдено

Дальше нужно для отдачи всего массива по ISCSI создать на весь объем новый ZVol. Этот ZVol по ISCSI при монтировании в Linux-систему будет размечен как Ext4. Вот по этой операции с указанными целями применения сервера и вопрос.

При создании ZVol по-умолчанию еще резервируется 20%. Нужно ли вот здесь это ? или можно пренебречь, включить ForceSize-On и использовать всё, или меньший % ? По-умолчанию максимальный объем создается 8,19 TiB, хотелось был 9-10 TiB

 

[mav@]

10,24 TiB -- это не резервирование (вернее очень малая часть, только под административные нужды), большая часть места ушла под контрольные суммы RAIDZ1. Поверх этого надо зарезрвировать по крайней мере 10-20% если данные будут писаться линейно, большими блоками и редко перезаписываться. Потому 8-9TiB после сжатия -- это абсолютный максимум, который превышатьне стоит. Я не знаю какой характер использования предполагается, но как правило использование iSCSI предполагает случайный доступ, потому во избежание быстрого роста фрагментации рекомендуется не использовать более 50-60% от доступного пространства (5-6TiB после сжатия), а для ускорения доступа использовать mirror и volbloсksize поменьше. Хотя если писать предполагается только линейно и большими блоками, а данные будут сжимаемые, то некоторые послабления возможны.

Это не значит что нельзя создать ZVOL больше. Ограничение размера ZVOL -- это простая мера предосторожности. Если iSCSI инициатор поддерживает UNMAP, а админ бдит, то просто пустое место на ZVOL тоже пойдет в плюс.

 

[Maksim Shulga]

10,24 TiB -- это не резервирование (вернее очень малая часть, только под административные нужды), большая часть места ушла под контрольные суммы RAIDZ1

во-о-о! вот это то что я не понимал... это хороший ответ, т.е. тут резервирования практически нет, "Ага" сказали партизаны

 

[Maksim Shulga]

не знаю какой характер использования предполагается, но как правило использование iSCSI предполагает случайный доступ, потому во избежание быстрого роста фрагментации рекомендуется не использовать более 50-60% от доступного пространства (5-6TiB после сжатия), а для ускорения доступа использовать mirror и volbloсksize поменьше. Хотя если писать предполагается только линейно и большими блоками, а данные будут сжимаемые, то некоторые послабления возможны

использование такое - массив по ISCSI отдается на Ubuntu Server, в нем монтируется и размечается Ext4
Veeam (на другом Win-хосте) цепляется к этому ресурсу на Ubuntu Server. и делает там свой репозиторий
в него делаются бекапы виртуалок раз в неделю полный, а между ними разностные, хранение до 14 дн., т.е. подразумевается перезапись, ну как минимум удаление старше 2х недель. Операционный изменяемый объем данных репозитория примерно 1 TiB, и т.к. это бекапы то практически всегда идет линейная запись на этот массив, чтение нужно только при восстановлении, что бывает редко и сумасшедшей производительности не требуется.

Единственное но! если знаете как функционирует Veeam, полный бекап делается синтетический, т.е. складывание всех разностных в единый полный, это разгружает сеть и хост ESXi, а полный активный только 1 числа. Полный синтетический бекап как раз перекладывает нагрузку на дисковый ресурс с репозиторием... потому как чтоб слепить разностные бекапы в 1 полный, это все нужно перечитать...

вот так вот пойдет ? :) или 7% маловато все-таки ?

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

 

[mav@]

Цифра фрагментации в `zpool list` сильно выростает, скорость последовательных операций сильно падает, при записи больших блоков может оказаться что их придется резать на куски (gang blocks), так как последовательных пустых областей уже нет, что дополнительно снижает производительность и увеличивает процент места для контрольных сумм RAIDZ. Когда дойдет дело до восстановления из бакапа может оказаться что терабайт будешь читать пару дней.

 

[Maksim Shulga]

т.е. блоки лучше уменьшать... а то вроде в начале было так...

4KB блок zvol напрочь убьет последовательную производительность за счет накладных расходов на обработку отдельных блоков

а где мониторится "цифра фрагментации"? надо так понимать это показатель, типа коэффициент фрагментации...

 

[mav@]

т.е. блоки лучше уменьшать... а то вроде в начале было так...

Истина как всегда в середине. 4KB -- это дикая крайность, плохо работающая даже для mirror и совсем безумие для RAIDZ. Большие блоки лучше работают на больших последовательных операциях, мелкие на мелких и случайных. Для случайного FreeNAS по умолчанию предлагает 16KB для mirror и 32KB для небольшого RAIDZ и 64KB и больше для большого. Но большой RAIDZ и случайный доступ это вещи плохо совместимые. Теоретически iSCSI может значить и последовательный доступ, но надо внимательно смотреть по ситуации.

а где мониторится "цифра фрагментации"? надо так понимать это показатель, типа коэффициент фрагментации...

Это некая величина отражающая стредний размер пустых блоков на пуле. Где-то было конкретно описано, но не вспомню сходу. Если помню верно, то 100% значит что все свободные блоки на пуле имеют размер 512 байт, что есть полный П для аллокации. На самом деле современный ZFS имеет внутри более детальные гисторгаммы распределения пустых блоков для более детального распределения нагрузки, но они так легко не выводятся.

 

[Maksim Shulga]

так а как же мониторить это всё хозяйство ?

 

[mav@]

"FRAG" в `zpool list`, я вроде сказал выше.