Реалізація SSD кешування в СГД QSAN XCubeSAN

Технології підвищення продуктивності, засновані на використанні SSD та широко застосовувані в СГД, вже давно винайдені. Насамперед – це застосування SSD як простір зберігання, що на 100% ефективно, але дорого. Тому в хід йдуть технології тирингу та кешування, де SSD використовуються тільки для найбільш затребуваних (гарячих) даних. Тиринг хороший для сценаріїв довготривалого (дні-тижня) використання «гарячих» даних. А кешування, навпаки, для короткострокового (хвилини-години) використання. Обидва ці варіанти реалізовані в СГД QSAN XCubeSAN. У статті ми розглянемо реалізацію другого алгоритму – SSD кешування.

Суть технології SSD кешування – це використання SSD як проміжний кеш між жорсткими дисками та оперативною пам'яттю контролера. Продуктивність SSD, звичайно ж, нижча, ніж продуктивність власного кешу контролера, зате обсяг на порядок вищий. Тому отримуємо якийсь компроміс між швидкістю та обсягом.

Показання для використання SSD кешу для читання:

• Переважання операцій читання над операціями запису (найчастіше притаманно баз даних і web додатків);
• наявність вузького місця у вигляді продуктивності масиву жорстких дисків;
• Об'єм затребуваних даних менший за обсяг SSD кешу.

Показами для використання SSD кешу на читання+запис є ті самі причини, за винятком характеру операцій – змішаний тип (наприклад, сервер файл).

Більшість вендорів СГД використовують у своїх продуктах SSD кеш лише операцій читання. Принциповою відмінністю QSAN від них є можливість використання кешу також для запису. Для активації функціоналу SSD кешування в СГД QSAN потрібно придбати окрему ліцензію (постачається в електронному вигляді).

SSD кеш у XCubeSAN фізично реалізований у вигляді окремих SSD кеш пулів. У системі їх може бути чотири. Кожен пул, очевидно, використовує власний набір SSD. І вже у властивостях віртуального диска ми визначаємо, чи використовуватиме він кеш пул і який саме. Увімкнення та вимкнення використання кешу для томів можна здійснювати в режимі online без зупинки вводу/виводу. Також на гарячу можна додавати SSD в пул і прибирати їх звідти. При створенні SSD кеша пула необхідно вибрати, в якому режимі він працюватиме: лише читання чи читання+запис. Від цього залежить його фізична організація. Якщо кеш пулів може бути кілька, то функціонал у них може бути різний (тобто в системі можуть бути одночасно кеш пули для читання та для читання+запису).

У разі використання кеш-пулу тільки для читання він може складатися з 1-8 SSD. Диски не обов'язково мають бути одного об'єму та одного вендора, оскільки вони об'єднуються у структуру NRAID+. Усі SSD у пулі використовуються спільно. Система самостійно намагається розпаралелити запити, що надходять між усіма SSD для досягнення максимальної продуктивності. У разі виходу з ладу одного із SSD нічого страшного не станеться: адже кеш містить лише копію даних, що зберігаються на масиві із жорстких дисків. Просто обсяг доступного SSD кешу зменшиться (або стане нульовим у разі використання початкового SSD кешу з одного накопичувача).

Якщо ж кеш використовується для операцій читання + запису, то кількість SSD у пулі має бути кратно двом, оскільки вміст дзеркається на парах накопичувачів (використовується структура NRAID 1+). Дублювання кешу необхідно через те, що в ньому можуть бути дані, які ще не встигли записатися на жорсткі диски. І в цьому випадку вихід з ладу SSD із кеш пулу призвів би до втрати інформації. У разі ж NRAID 1+ відмова SSD просто призведе до переведення кешу у стан роботи «тільки на читання» зі скиданням незаписаних даних на масив із жорстких дисків. Після заміни несправного SSD кеш повернеться до свого початкового режиму роботи. До речі, для більшої безпеки кешу, який працює на читання + запис, можна призначити виділені hot spare.

При використанні функції SSD кешування в XCubeSAN є низка вимог щодо обсягу пам'яті контролерів СГД: чим більше системної пам'яті, тим більший обсяг кеш пулу буде доступним.

На відміну знову ж таки від більшості виробників СГД, які як налаштування SSD кешу пропонують лише опцію включити/вимкнути, QSAN надає більші можливості. Зокрема, можна вибрати режим роботи кешу в залежності від характеру навантаження. Є три попередньо встановлені шаблони, найбільш близькі по роботі до відповідних сервісів: база даних, файлова система, web сервіс. Крім цього, адміністратор може створити власний профіль, задавши необхідні значення параметрів:

• Розмір блоку (Cache Block Size) – 1/2/4 МБ
• Число запитів на читання блоку, щоб він був скопійований до кешу (Populate-on-Read Threshold) – 1..4
• Кількість запитів на запис блоку, щоб він був скопійований у кеш (Populate-on-Write Threshold) – 0..4

Профілі можна міняти "на льоту", але, зрозуміло, з обнуленням вмісту кешу та його новим "прогрівом".

Розглядаючи принцип роботи SSD кешу, можна виділити основні операції під час роботи з ним:

• Читання даних, коли вони відсутні у кеші;
• Читання даних, коли присутні в кеші;
• Запис даних під час використання кешу на читання;
• Запис даних під час використання кешу для читання + запис.

Читання даних, коли вони відсутні в кеші

1. Запит від хоста надходить у контролер;
2. Так як запитуваних немає в кеші SSD, вони зчитуються з жорстких дисків;
3. Зчитані дані надсилається хосту. Одночасно триває перевірка, чи ці блоки є «гарячими»;
4. Якщо так, вони копіюються в SSD кеш для подальшого використання.

Читання даних, коли вони присутні в кеші

1. Запит від хоста надходить у контролер;
2. Оскільки дані, що запитуються, є в SSD кеші, вони зчитуються звідти;
3. Зчитані дані надсилається хосту.

Запис даних під час використання кешу для читання

1. Запит на запис від хоста надходить у контролер;
2. Дані записуються на жорсткі диски;
3. Хосту повертається відповідь про успішний запис;
4. Одночасно перевіряється, чи є блок гарячим (порівняється параметр Populate-on-Write Threshold). Якщо так, то він копіюється в SSD кеш для подальшого використання

Запис даних під час використання кешу для читання+запис

1. Запит на запис від хоста надходить у контролер;
2. Дані записуються у SSD кеш;
3. Хосту повертається відповідь про успішний запис;
4. Дані з SSD кеша у фоновому режимі записуються на жорсткі диски;

Перевірка у справі

Тестовий стенд

2 сервери (CPU: 2 x Xeon E5-2620v3 2.4Hz/RAM: 32GB) підключені двома портами через Fibre Channel 16G безпосередньо до СХД XCubeSAN XS5224D (16GB RAM/контролер).

Використовувалися 16 x Seagate Constellation ES, ST500NM0001, 500GB, SAS 6Gb/s, об'єднані в RAID5 (15+1), для масиву з даними та 8 x HGST Ultrastar SSD800MH.B, HUSMH8010BSS200G, 100

Було створено 2 томи: по одному для кожного сервера.

Тест 1. SSD кеш тільки на читання з 1-8 SSD

Кеш SSD

• I/O Type: Customization
• Cache Block Size: 4MB
• Populate-on-read Threshold: 1
• Populate-on-write Threshold: 0

I/O Pattern

• Tool: IOmeter V1.1.0
• Робітників: 1
• Outstanding (Queue Depth): 128
• Access Specifications: 4KB, 100% Read, 100% Random

Теоретично, що більше SSD в кеш пулі, то вище продуктивність. Насправді це і підтвердилося. Єдине, значне збільшення кількості SSD при малій кількості томів не призводить до вибухового ефекту.

Тест 2. SSD кеш в режимі читання + запис з 2-8 SSD

Кеш SSD

• I/O Type: Customization
• Cache Block Size: 4MB
• Populate-on-read Threshold: 1
• Populate-on-write Threshold: 1

I/O Pattern

• Tool: IOmeter V1.1.0
• Робітників: 1
• Outstanding (Queue Depth): 128
• Access Specifications: 4KB, 100% Write, 100% Random

Той самий результат: вибухове зростання продуктивності та масштабування зі збільшенням кількості SSD.

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

Тепер повернемося з небес на землю і перевіримо більш життєву ситуацію, коли обсяг даних більший за розмір кешу. Щоб тест пройшов за осудний час (термін «прогрівання» кеша сильно зростає при збільшенні розміру тома), обмежимося розміром тома в 120ГБ.

Тест 3. Емуляція роботи бази даних

Кеш SSD

• I/O Type: Database
• Cache Block Size: 1MB
• Populate-on-read Threshold: 2
• Populate-on-write Threshold: 1

I/O Pattern

• Tool: IOmeter V1.1.0
• Робітників: 1
• Outstanding (Queue Depth): 128
• Access Specifications: 8KB, 67% Read, 100% Random

Вердикт

Як очевидний висновок, звичайно, напрошується непогана ефективність використання SSD кешу для підвищення продуктивності будь-якої СГД. Стосовно до QSAN XCubeSAN дане твердження відноситься повною мірою: функція SSD кешування реалізована чудово. Це стосується підтримки режимів читання та читання + запису, гнучкого налаштування роботи для будь-яких сценаріїв використання, а також підсумкової продуктивності системи загалом. Тому за дуже розумну вартість (ціна ліцензії можна порівняти з вартістю 1-2 SSD) можна помітно підвищити загальну продуктивність.

Джерело: habr.com