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

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

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

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

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

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

Хотя ответ пользователя 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, но надеюсь, что это поможет. :)

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

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

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

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

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

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

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

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