Можливості Data Reduction в Dell Compellent

Раніше ми вже розповідали про реалізацію технології QoS в системах Dell Compellent, але на цьому нововведення в SCOS версії 7 не закінчуються і сьогодні кілька слів про них.

У системах Compellent технологія багаторівневого зберігання (Data Progression) з'явилася вже досить давно, коли для багатьох систем зберігання midrange класу не було про неї навіть і мови. Як і тоді, переміщення блоків даних між рівнями зараз також відбувається за розкладом, а не в онлайн-режимі. Це дозволяє контролювати навантаження на систему, уникаючи деградації продуктивності через виконуваних процесів міграції. Хоча, враховувати активність навантаження потрібно завчасно при плануванні. Організація даних в системах Compellent заснована на сторінках даних розміром від 512КБ до 4МБ (дефолтний розмір сторінки 2МБ). Міграція також здійснюється на рівні окремих сторінок. За рахунок цього дані можуть більш вибірково розподілятися за рівнями зберігання. Запис нових даних завжди відбувається на найшвидший рівень («швидкі» диски в RAID10 або ssd) і це також потрібно враховувати при початковому плануванні.
image

Починаючи з версії SCOS 6.5.1 була додана можливість компресії даних. Вона також відбувається в офлайні, паралельно з перерозподілом сторінок за рівнями зберігання. Щоб пояснити принцип роботи Data Reduction у СГД Dell Compellent, необхідно сказати, що сторінки даних, якими оперує система, бувають трьох видів:

● «Active» (активні сторінки) — нещодавно записані дані. Ці сторінки завжди знаходяться на самому швидкому рівні зберігання і дані в них можуть бути як прочитані, так і перезаписані.
● «Frozen accessible» (заморожені доступні) — сторінки після створення миттєвого знімка. Дані в них ще не перезаписувати, тому вони доступні для читання, але як тільки буде спроба змінити їх, буде створена нова active page, а ця сторінка буде переведена в режим «frozen inaccessible».
● «Frozen inaccessible» (заморожені недоступні) сторінки, які були перезаписані після створення знімка. Дані з них вже не можуть бути прочитані при зверненні до того (без відновлення снапшота), а перезаписані блоки знаходяться в активних сторінках на найвищому рівні зберігання.

У всіх процесах Data Progression і Data Reduction беруть участь тільки «заморожені» сторінки. Щодня за розкладом створюється черговий миттєвий знімок (в цей момент всі активні сторінки «заморожуються») і починається міграція між рівнями. Стиснення завжди працює з блоками розміром 64КБ, незалежно від розміру сторінки. Якщо після застосування алгоритмів стиснення виявляється, що стислі дані разом з необхідним набором метаданих займають більше місця, ніж стиснені, компресія для даної сторінки не застосовується. Так як система оперує саме сторінками, то на фінальному етапі процесу Data Progression відбувається об'єднання частково зайнятих сторінок з метою звільнити місце на дисках. SCOS також вміє розпізнавати та замінювати посиланнями блоки, заповнені нулями, що дозволяє досягти ще більш високих показників стиснення.

Але використання SSD дисків і поширення All-Flash систем вимагає більш активного використання технологій оптимізації даних для зниження вартості зберігання. Тому у версії SCOS 7 Data Reduction доповнився ще й дедупликацией. Так як всі оптимізації відбуваються паралельно з переміщенням даних між рівнями, то й для компресії, і для дедуплікаціі потрібна ліцензія на Data Progression. All Flash масиви з єдиним рівнем зберігання є винятком і для них можна цю ліцензію не купувати. Відзначимо, що якщо у масиві не використовуються ssd-диски, то ні стиснення, ні дедупликацию використовувати неможливо. На перший погляд це досить дивно — адже обидві ці технології працюють на сторінках, які могли бути переміщені з самого швидкого рівня зберігання на звичайні диски. Все вірно — стислі дані можуть зберігатися на звичайних дисках, але для доступу до них нам завжди потрібне додаткове звернення до службових метаданих. І тому SSD диски (мінімум 6 дисків) необхідні в тому числі і для зберігання цієї інформації, так як якщо б ми розміщували метадані на звичайних дисках, спостерігалася б значна деградація продуктивності при зверненні до стисненим даними.

Дедупликация підтримується тільки на контролерах, які володіють достатньою продуктивністю процесора — SC4020, SC7000, SC8000, SC9000. Системи на базі SC40 і SCv2000 не підтримуються. Для оптимізації даних використовуються виділені ядра процесорів в контролерах, тому в більшості випадків немає помітного впливу фонових процесів на продуктивність введення-виведення. Але в будь-який момент ви можете поставити на паузу процеси Data Reduction, якщо раптом вони дійсно стали впливати на швидкість роботи системи.

Процеси оптимізації є фоновими і можуть запускатися або за розкладом, або, як тільки ви зробите новий знімок тома. Після створення знімка запускається процес «on-demand data progression» і, як наслідок, компресія і дедупликация (якщо вони включені для даного томи). Між цими двома варіантами є серйозне відмінність — щоденна оптимізація обробляє всі заморожені сторінки, а «швидкий» варіант тільки ті, які з'явилися під час створення знімка. Як наслідок, такий фоновий процес менше завантажує систему в робочі години.

Дедупликация, на відміну від компресії, працює вже з блоками розміром 4КБ. Принцип реалізації стандартний — як і в інших системах вважається хеш від блоку і порівнюється зі словником. Якщо такий хеш в словнику вже є, то блок даних замінюється посиланням, за рахунок чого і відбувається економія дискового простору. Потім, вже після дедуплікаціі, запускається компресія. На цьому етапі стискуються вже тільки залишилися унікальні 4К блоки. Все, що було сказано про стиснення раніше, залишається в силі — в ряді випадків компресія може не дати бажаного ефекту і тоді сторінка буде записана на диск «як є».

Для кожного тому можна вибрати, які саме технології використовувати — компресію, компресію в парі з дедупликацией або взагалі відключити Data Reduction. Включити дедупликацию без компресії неможливо. В залежності від того, які рівні зберігання використовуються, оптимізація може працювати по-різному:
image
image

Як це зазвичай і буває, при розробці нового рішення, необхідно пам'ятати про деякі особливості реалізації. Реплікація на рівні СГД підтримується для стислих і дедуплицированных томів, але в момент фактичної передачі даних відбувається декомпресія переданих даних в пам'яті контролера (дані на дисках залишаються стислими) і “назовні" передаються тільки стиснені дані. Так, при налаштуванні реплікації можна окремо включити дедупликацию даних, але цей процес буде працювати тільки при відправці даних на віддалену систему, а самі дані будуть попередньо «регидрированы». Якщо ви хочете змінити контролер, який володіє томом з Data Reduction, потрібно попередньо вимкнути стиснення і дедупликацию, дочекатися повного відновлення (після чергового циклу Data Progression) і вже потім змінити власника на іншого контролер.

Так, був час, коли багаторівневе зберігання Dell Compellent могло позиціонуватися як нове і унікальне рішення. Але зараз, коли All-Flash набирають популярність, не можна залишати систему без можливості оптимізації даних — занадто високою стає ціна за ГБ порівняно з конкурентами. Поява нового функціоналу в SCOS не може не радувати, а враховуючи, що оновлення підтримується і на вже використовуваних контролерах, замовники отримують можливість почати більш оптимально використовувати вже наявні СГД. Наскільки періодична дедупликация гірше або краще постійної питання відкрите і для кожного окремого проекту буде своя відповідь. Правильний шлях — тестувати обладнання перед придбанням і слухати не тільки маркетингові заяви вендорів при виборі рішення.

Інженери Трініті будуть раді проконсультувати вас з питань віртуалізації серверів, систем зберігання даних, робочих місць, додатків, мереж.

Відвідайте популярний технічний форум Трініті або замовте консультацію.

Інші статті Трініті можна знайти на блог і хабі Трініті. Підписуйтесь!
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.