ZFS dedupe (знову ж таки): Чи залежить використання пам'яті від фізичних (виведених, стислих) даних, що зберігаються чи використовуються логічно?

Я дуже багато в цьому гугла, але не можу отримати достатню інформацію про це. Як правило, правило становить 5 Гб оперативної пам’яті для 1 ТБ пам’яті. Але що таке сховище насправді? Фізичне чи логічне вживання?

Скажімо, у мене 6 ТБ жорсткого диска, ні дедупінгу, ні стиснення. У мене є 6TB фактичних даних. Припустимо, що це призведе до 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 обмежив метадані однією чвертю пам'яті. Яке б обґрунтування цього не було, воно зараз має серйозний негативний вплив на ефективність дедуптування. Оскільки DDT вважається метаданими, він підпадає під обмеження 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 до 1М, щоб відповідати розміру блоку, з яким працює наша програма для резервного копіювання.

Не впевнений, чому я щойно написав дисертацію PHD про кешування метаданих ZFS, але я сподіваюся, що це допомагає. :)

Розрахунок проводиться від фактичного розміру пулу до виведення даних або, точніше, від кількості збережених блоків у пулі (кожному блоку потрібно близько 320 байт простору в DDT, кількість необхідних блоків змінюється залежно від фактичних даних, що зберігаються). Тому ви вважаєте, що як правило, 6 * 5 = 30.

Але це ще не все, що потрібно, як сказано в цьому чудовому посібнику з дедупування :

Загальна вартість оперативної пам’яті дедуплікації

Але знати розмір таблиці дедупликації недостатньо: ZFS потрібно зберігати більше, ніж просто таблицю дедупірування, в пам’яті, наприклад, інших метаданих та, звичайно, кешованих даних блоку. Існує обмеження на те, яка частина кешу ZFS ARC може бути виділена для метаданих (а таблиця дедукцій підпадає під цю категорію), і вона обмежена на 1/4 розміру ARC .

Іншими словами: Який би ви не оцінювали розмір таблиці дедупінгу, вам знадобиться принаймні в чотири рази більше, ніж у оперативній пам’яті, якщо ви хочете зберегти всю свою таблицю заміщення в оперативній пам’яті. Плюс будь-яку додаткову оперативну пам’ять, яку ви хочете присвятити іншим метаданим, таким як покажчики блоків та інші структури даних, тому ZFS не повинен визначати шлях через структуру даних на пулі для кожного блоку, до якого він хоче отримати доступ.

Тому правило великих пальців поширюється:

• На кожну туберкульоз даних пулу слід очікувати 5 Гб даних таблиці таблиць, припускаючи середній розмір блоку 64 Кб.
• Це означає, що ви повинні планувати щонайменше 20 ГБ оперативної пам’яті на ТБ даних пулу, якщо ви хочете зберегти таблицю виведення в оперативну пам’ять, плюс будь-яку додаткову пам’ять для інших метаданих, а також додатковий ГБ для ОС.

У вашому випадку це приблизно 120+ ГБ оперативної пам’яті, тому не варто говорити про поточні серверні плати Xeon E5 (128 - 512 ГБ звичайного розміру оперативної пам’яті на процесор). Стаття також містить приклад із реального світу з доларами, які повинні вам добре служити.