ZFS дедупликация (снова): зависит ли использование памяти от физических (дедуплицированных, сжатых) данных или от логического использования?


5

Я много гуглил, но не могу получить достаточно информации об этом. Эмпирическое правило, кажется, 5 ГБ ОЗУ на 1 ТБ памяти. Но что такое хранилище на самом деле? Физический или логический?

Допустим, у меня есть жесткий диск объемом 6 ТБ, без дедупликации, без сжатия. У меня есть 6 ТБ фактических данных. Давайте предположим, что он будет дедуплицировать 2: 1, до 3 ТБ данных. Нам (приблизительно) потребуется 3 * 5 ГБ памяти или 6 * 5 ГБ?

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

Дело в том, что мы хотели бы рассчитать, что дешевле: заменить диски размером 6 * 6 ТБ (3х локальное хранилище / зеркало / оперативный резерв, 3х стороннее, у нас больше нет доступных слотов в этих коробках) большими для резервных копий, или купить ОЗУ для обеих коробок.

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


Как вы говорите, это эмпирическое правило, вероятно, он будет работать с меньшим объемом доступной оперативной памяти. Это займет больше времени. Кроме того, это будет зависеть от того, сколько вы на самом деле собираетесь восстановить с помощью дедупликации. Может быть, это может помочь вам?
Сет

Я попытался запустить его на виртуальной машине для тестирования в 16 ГБ ОЗУ. Импортировано около месяца резервных копий, и все застопорилось :) Коэффициент дедупликации был впечатляющим, хотя для полного набора данных он оценивается в 2,3.
Даниил

Ответы:


4

Хотя ответ пользователя user121391 в основном правильный, ограничение 1/4 для метаданных больше не имеет место / не было в течение длительного времени:

Существует ограничение на объем кэша ZFS ARC, который может быть выделен для метаданных (и таблица дедупликации подпадает под эту категорию), и он ограничен размером 1/4 размера ARC.

Прежде всего, zfs_arc_meta_limit (объем кэшируемой памяти, который может использоваться для метаданных, включая таблицу дедупликации) всегда был настраиваемым (iirc). Поэтому даже в очень старых версиях ZFS, где 25% могли быть значениями по умолчанию, вы можете использовать этот параметр для настройки объема кэша, доступного для метаданных. В случае системы резервного копирования, где к большинству пользовательских данных редко обращаются,> = 75% для метаданных + <= 25% для пользовательских данных может быть более подходящим. Пожалуйста, имейте в виду, что указанная переменная - это доступное количество памяти в байтах, а не процент.

В зависимости от вашей реализации ZFS, пожалуйста, обратите внимание на следующее:


Для ZFS в Oracle Solaris 11 ограничение уже давно полностью удалено по умолчанию:

До внедрения этого изменения ARC ограничивала метаданные одной четвертью памяти. Каким бы ни было обоснование для этого, когда-то это могло иметь серьезное негативное влияние на производительность дедупликации. Поскольку ДДТ считается метаданными, на него распространяется ограничение 1/4. На данный момент этот предел является анахронизмом; это может быть устранено (или, скорее, установлено в arc_c).

Таким образом, хотя вы МОЖЕТЕ установить предел, он больше не рекомендуется.


Для ZFS в Linux до 0.6.x , например в Ubuntu 16.04, значение по умолчанию составляет 75%:

zfs_arc_meta_limit (ulong) : максимально допустимый размер в байтах, который буфера метаданных разрешено использовать в ARC. Когда этот предел будет достигнут, буферы метаданных будут восстановлены, даже если общий arc_c_max не был достигнут. Это значение по умолчанию равно 0, что указывает на то, что 3/4 ARC можно использовать для метаданных.

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

zfs_arc_meta_min (ulong) : минимально допустимый размер в байтах, который буферы метаданных могут потреблять в ARC. Это значение по умолчанию равно 0, что отключает минимальное количество выделенных метаданных ARC.

В ZFS в Linux 0.7.0 кажется, что есть способ настроить объем памяти с процентным пределом:

zfs_arc_meta_limit_percent (ulong) : процент буфера ARC, который можно использовать для метаданных. Смотрите также zfs_arc_meta_limit, который служит аналогичной цели, но имеет более высокий приоритет, если задано ненулевое значение.


Если вы планируете использовать реализацию ZFS на основе Linux, прежде чем тратить много $$$ на оборудование, подумайте о том, чтобы смоделировать ваш вариант использования на виртуальной машине. Я бы порекомендовал проверить наихудший случай для дедупликации (= 100% случайных данных). Если у вас нет необходимых ресурсов виртуализации под рукой, имейте в виду, что вы всегда можете просто раскрутить безумно огромные экземпляры у большинства облачных провайдеров за пару часов за очень небольшие деньги.

И последнее, на что нужно обратить внимание: вы всегда можете настроить размер записей ZFS. Вообще говоря, небольшие размеры записи дадут лучшие коэффициенты дедупликации (но, очевидно, требуют больше оперативной памяти для таблицы дедупликации). Большие размеры записи приведут к худшим коэффициентам дедупликации, но потребуют меньше оперативной памяти для таблицы дедупликации. Например: хотя в настоящее время мы не используем дедупликацию в нашем хранилище резервных копий ZFS, я установил размер записи ZFS равным 1M, чтобы соответствовать размеру блока, с которым работает наше приложение резервного копирования.

Не уверен, почему я только что написал докторскую диссертацию о кешировании метаданных ZFS, но надеюсь, что это поможет. :)


Это на самом деле очень помогло! Спасибо! 1/4-ая вещь была главным убийством жужжания. Это определенно сделало бы его дешевле, чем больше жестких дисков для нашего варианта использования.
Даниил

3

Вычисление производится по фактическому размеру пула до дедупликации, или, точнее, по количеству сохраненных блоков в пуле (каждому блоку требуется около 320 байт пространства в ДДТ, количество необходимых блоков зависит от фактических хранимых данных). Поэтому вы бы предпочли 6 * 5 = 30, как правило.

Но это еще не все, что указано в этом превосходном руководстве по дедупликации :

Общая стоимость оперативной памяти при дедупликации

Но знать размер вашей таблицы дедупликации недостаточно: ZFS должна хранить в памяти больше, чем просто таблицу дедупликации, такую ​​как другие метаданные и, конечно, кэшированные данные блока. Существует ограничение на то, сколько кэша ZFS ARC может быть выделено для метаданных (и таблица дедупликации подпадает под эту категорию), и оно ограничено 1/4 размера ARC .

Другими словами: каким бы ни был ваш предполагаемый размер таблицы дедупликации, вам потребуется как минимум в четыре раза больше оперативной памяти, если вы хотите сохранить всю свою таблицу дедупликации в оперативной памяти. Кроме того, любая дополнительная оперативная память, которую вы хотите выделить для других метаданных, таких как указатели блоков и другие структуры данных, позволяет ZFS не определять путь через структуру данных в пуле для каждого блока, к которому он хочет получить доступ.

Поэтому правило больших пальцев распространяется:

  • Для каждого ТБ данных пула следует ожидать 5 ГБ данных таблицы дедупликации, предполагая, что средний размер блока составляет 64 КБ.
  • Это означает, что вы должны планировать как минимум 20 ГБ системной ОЗУ на ТБ данных пула, если вы хотите сохранить таблицу дедупликации в ОЗУ, плюс любую дополнительную память для других метаданных, а также дополнительный ГБ для ОС.

В вашем случае это примерно 120+ ГБ ОЗУ, так что не может быть и речи о текущих серверных платах Xeon E5 (128 - 512 ГБ обычного объема ОЗУ на процессор). Статья также содержит реальный пример с долларами, которые должны хорошо служить вам.


Ах, спасибо! Наконец понял это. Мы провели оценку ДДТ, и мы на самом деле были бы ближе к 5,5 ГБ / ТБ. Если предположить, что загрузка будет ниже 80% (дедупликация будет около 2,3, сжатие 1,5 => достаточно данных), то 128 ГБ вполне подойдет. Хотя мы могли бы пропустить это, и пока просто запустить RaidZ1 в обоих местах. Меньше избыточности, на самом деле меньше места, но, к сожалению, деньги - это проблема. И последнее: мы могли бы запустить L2ARC. Это может содержать таблицу дедупликации. Так как нам не нужно быть чрезмерно производительным, возможно, на самом деле все будет в порядке. Но сколько памяти достаточно тогда? 16 ГиБ нет :)
Даниил

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

1
Наконец-то у меня появились ценности :) Мы купили дополнительную систему с 64 ГБ памяти ECC, 4x жесткими дисками по 10 ТБ, без L2ARC, работающие в зеркальном режиме, систему Debian Stretch с включенной версией ZFS (0.6.something) поверх luks. Дедуп и сжатие включены. Работа с 3 годами частично прореженных данных rsnapshot в основном виртуальных машин Debian, включая сгенерированные пользователем данные, такие как тонна изображений, которые, скорее всего, время от времени переименовывались, копировались, перемещались, таким образом, не перехватывались с помощью rsnapshot.
Даниэль

1
Мы получили в общей сложности 25,4M выделенных блоков, коэффициент дедупликации 2,45х, коэффициент сжатия 1,6х (по сравнению с 1,8х для недедедированных данных). Логические данные - 7,28 т, физические данные на дисках - 2,24 т. Если я сделал расчет правильно, мы сидим только на 7,6 ГБ, используемых для ДДТ. Я установил zfs_arc_max на 58 ГБ. Я больше не делал никаких дополнительных настроек. Если вы хотите узнать что-нибудь еще, я с радостью помогу.
Даниэль
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.