Сьогодні йтиметься про цікаву технологію, реалізовану в СГД Unity/Unity XT, – FAST VP. Якщо ви вперше почули про Unity, за посиланням наприкінці статті можна ознайомитися з характеристиками системи. У проектній команді Dell EMC я працював над FAST VP понад рік. Сьогодні хочу розповісти про цю технологію детальніше та розкрити деякі деталі її реалізації. Зрозуміло, лише ті, які можна розкрити. Якщо ви цікавитеся питаннями ефективного зберігання даних або просто не до кінця розібралися з документацією, то ця стаття напевно буде корисною та цікавою.
Відразу скажу про те, чого у матеріалі не буде. Не буде пошуку конкурентів та порівняння з ними. Також не планую розповідати про схожі технології з open source, тому що цікавий читач і так про них знає. І, звісно, я не збираюся нічого рекламувати.
Storage Tiering. Цілі та завдання FAST VP
FAST VP розшифровується як Fully Automated Storage Tiering for Virtual Pool. Складно? Нічого, зараз розберемося. Tiering – це спосіб організації зберігання даних, у якому є кілька рівнів (tiers), де ці дані зберігаються. Кожен має свої характеристики. Найважливіші: продуктивність, обсяг та ціна зберігання одиниці інформації. Зрозуміло, з-поміж них є взаємозв'язок.
Важлива особливість tiering полягає в тому, що доступ до даних надається однаково незалежно від того, на якому рівні зберігання зараз вони знаходяться, а розмір пулу дорівнює сумі розмірів ресурсів, що входять до нього. Тут криються відмінності від кешу: розмір кешу не додається до загального обсягу ресурсу (пула в даному випадку), а дані кешу дублюють будь-який фрагмент даних основного носія (або дублюватимуть, якщо дані з кешу ще не записані). Також розподіл даних за рівнями прихований від користувача. Тобто він не бачить, які саме дані розташовані на кожному рівні, хоча й може впливати на це опосередковано, шляхом завдання політик (про них пізніше).
Тепер подивимося на особливості реалізації storage tiering'а в Unity. У Unity виділяють 3 рівні, або tier'а:
- Extreme performance (SSDs)
- Performance (SAS HDD 10k/15k RPM)
- Capacity (NL-SAS HDD 7200 RPM)
Вони представлені в порядку зменшення продуктивності та ціни. У Extreme performance входять виключно твердотільні накопичувачі (SSD). У два інших tier'а - накопичувачі на магнітних дисках, що відрізняються швидкістю обертання і, відповідно, продуктивністю.
Носії інформації з одного рівня та одного розміру поєднуються в RAID-масив, утворюючи RAID-групу (RAID group, скорочено – RG); про доступні та рекомендовані рівні RAID можна прочитати в офіційній документації. З RAID-груп з одного або кількох рівнів формуються пули зберігання даних (Storage pool), з яких потім і розподіляється вільне місце. А вже з пулу виділяється місце під файлові системи та LUN'и.
А навіщо мені Tiering?
Якщо коротко та абстрактно: щоб досягти більшого результату, використовуючи мінімум ресурсів. Якщо більш конкретно, то під результатом зазвичай розуміють сукупність характеристик СГД – швидкість та час доступу, вартість зберігання та інші. Під мінімумом ресурсів маються на увазі найменші витрати: грошей, енергії тощо. FAST VP реалізує механізми перерозподілу даних за різними рівнями в СГД Unity/Unity XT. Якщо ви мені вірите, можна пропустити наступний абзац. Для решти розповім трохи докладніше.
Правильне розподілення даних за рівнями зберігання дозволяє заощадити на загальній вартості СГД, пожертвувавши швидкістю доступу до деякої рідко використовуваної інформації, і підвищити продуктивність, переміщуючи дані, що часто використовуються, на більш швидкі носії. Тут хтось може заперечити, що і без tiering'а нормальний адмін знає, куди які дані помістити, які бажані характеристики СГД під його завдання тощо. Безперечно, це так, але розподіл даних «вручну» має свої недоліки:
- вимагає часу та уваги адміністратора;
- не завжди вдається «перекроїти» ресурси СГД під умови, що змінилися;
- зникає важлива перевага: уніфікований доступ до ресурсів на різних рівнях зберігання.
Щоб storage-адміни менше турбувалися про job security, додам, що грамотне планування ресурсів тут необхідно. Тепер, коли завдання tiering'а коротко змальовані, давайте подивимося, чого можна очікувати від FAST VP. Тут саме час повернутися до визначення. Перші два слова – Fully Automated – дослівно перекладаються як «цілком автоматизований» і означають, що розподіл за рівнями відбувається автоматично. А Virtual Pool – це пул даних, до якого входять ресурси з різних рівнів зберігання. Ось як це виглядає:
Забігаючи наперед, скажу, що FAST VP переміщає дані лише всередині одного пулу, а не між кількома пулами.
Завдання, які вирішуються FAST VP
Спочатку поговоримо абстрактно. У нас є пул та якийсь механізм, який може перерозподіляти дані всередині цього пулу. Пам'ятаючи, що наше завдання – досягнення максимальної продуктивності, запитаємо себе: якими способами її можна досягти? Їх може бути кілька, і тут FAST VP є що запропонувати користувачеві, тому що технологія є чимось більшим, ніж просто storage tiering. Ось якими способами FAST VP може збільшити продуктивність пулу:
- Розподіл даних за різними типами дисків, рівнями
- Розподіл даних серед дисків одного типу
- Розподіл даних при розширенні пулу
Перш ніж розбирати те, як ці завдання вирішуються, нам потрібно знати деякі необхідні факти роботи FAST VP. FAST VP оперує блоками певного розміру – 256 мегабайт. Це мінімальний безперервний "шматок" даних, який може бути переміщений. У документації його і називають: slice. З точки зору FAST VP, всі RAID-групи складаються з набору таких «шматків». Відповідно, вся статистика введення-виведення накопичується для таких блоків даних. Чому обраний саме такий розмір блоку і чи буде зменшений? Блок досить великий, але це компроміс між гранулярністю даних (менший розмір блоку – точніше розподіл) та наявними обчислювальними ресурсами: при існуючих жорстких обмеженнях на оперативну пам'ять та велику кількість блоків дані статистик можуть займати занадто багато, і кількість розрахунків зросте пропорційно.
Як FAST VP розміщує дані у пулі. Політики
Щоб керувати розміщенням даних у пулі з увімкненим FAST VP існують такі політики:
- Highest Available Tier
- Auto-Tier
- Start High then Auto-Tier (за замовчуванням)
- Lowest Available Tier
Вони впливають як на початкове розміщення блоку (дані записані вперше), так і на подальше перерозподіл. Коли дані вже розміщені на дисках, перерозподіл буде ініційовано за розкладом або вручну.
Highest Available Tier намагається розмістити новий блок на найпродуктивнішому рівні. При нестачі місця на ньому – на наступному за продуктивністю, але потім дані можуть бути переміщені на продуктивніший рівень (за наявності місця або витіснивши інші дані). Auto-Tier розміщує нові дані різних рівнях залежно від розміру доступного простору, а перерозподіляються вони залежно від затребуваності і вільного місця. Start High then Auto-Tier – політика за замовчуванням і рекомендована. При початковому розміщенні працює як Highest Available Tier, а далі відбувається переміщення даних залежно від їхньої статистики використання. Політика Lowest Available Tier прагне розмістити дані на найменш продуктивному рівні.
Перенесення даних йде з низьким пріоритетом, щоб не заважати корисній роботі СГД, проте є налаштування «Data relocation rate», яке змінює пріоритет. Тут є особливість: в повному обсязі блоки даних мають однакову черговість перерозподілу. Наприклад, блоки, позначені як метадані, будуть переміщені на швидший рівень насамперед. Метадані – це, якщо можна так висловитися, «дані про дані», якась додаткова інформація, яка не є даними користувача, але зберігає їх опис. Наприклад, інформація у файловій системі про те, у якому блоці знаходиться конкретний файл. Значить швидкість доступу до даних залежить від швидкості доступу до метаданих. Враховуючи, що метадані зазвичай набагато менші за розміром, виграш від їхнього переміщення на більш продуктивні диски очікується більше.
Критерії, які Fast VP використовує у роботі
Основний критерій кожного блоку, якщо дуже грубо, – характеристика «затребуваності» даних, що залежить кількості операцій читання і запису фрагмента даних. Ця характеристика називається «Температура». Є потрібні (hot) дані, які «гарячі» незатребуваних. Обчислюється вона періодично за замовчуванням з інтервалом в одну годину.
Функція обчислення температури має такі властивості:
- За відсутності введення-виводу дані згодом «остигають».
- При більш-менш однаковій у часі навантаженні температура спочатку зростає і потім стабілізується у певному діапазоні.
Далі враховуються політики, описані вище, та вільне місце на кожному tier'і. Для наочності наведу картинку з документації. Тут червоним, жовтим та синім кольорами позначені блоки з високою, середньою та низькою температурою відповідно.
Але повернемось до завдань. Отже, можна приступати до аналізу те, що робиться на вирішення завдань FAST VP.
А. Розподіл даних за різними типами дисків, рівнями
Власне це основне завдання FAST VP. Інші, в якомусь сенсі, є похідними від неї. Залежно від обраної політики дані розподілятимуться за різними рівнями зберігання. Насамперед враховується політика розміщення, потім температура блоків та розмір/швидкість RAID-груп.
Для політик Highest/Lowest Available Tier все досить просто. Для решти двох справа йде так. За різними рівнями дані розподіляються з урахуванням розміру та продуктивності RAID-груп: так, щоб відношення сумарної температури блоків до умовної максимальної продуктивності кожної RAID-групи було приблизно однаковим. Таким чином, навантаження розподіляється більш-менш рівномірно. Більш затребувані дані переміщаються на швидкі носії, рідко використовувані – більш повільні. В ідеалі розподіл має вийти приблизно таким:
Б. Розподіл даних серед дисків одного типу
Пам'ятайте, на початку я писав, що носії інформації з одного або декількох рівнів поєднуються в один пул? У випадку з єдиним рівнем для FAST VP також є робота. Щоб продуктивність якогось рівня була максимальною, бажано розподілити дані рівномірно між дисками. Це дозволить (теоретично) отримати максимальну кількість IOPS. Дані всередині RAID-групи можна вважати рівномірно розподіленими по дисках, а ось між RAID-групами це далеко не завжди так. У разі дисбалансу FAST VP переміщатиме дані між RAID-групами пропорційно їх обсягу та «умовній продуктивності» (у числовому вираженні). Для наочності покажу схему ребалансування серед трьох RAID-груп:
В. Розподіл даних при розширенні пулу
Це завдання є окремим випадком попередньої і виконується, коли в пул додають RAID-групу. Щоб додана RAID-група не простоювала, частина даних буде перенесена на неї, а значить і навантаження на всі RAID-групи перерозподілиться.
Вирівнювання зносу SSD
За допомогою вирівнювання зношування FAST VP може продовжити життя SSD, хоча ця функція і не відноситься безпосередньо до Storage Tiering. Так як дані про температуру вже є, кількість операцій запису також враховується, блоки даних ми переміщати вміємо, то логічно було б для FAST VP вирішити і це завдання.
Якщо кількість записів в одну RAID-групу значно перевищує кількість записів в іншу, то FAST VP перерозподілить дані відповідно до кількості операцій запису. З одного боку, це знімає навантаження і зберігає ресурс одних дисків, з іншого боку, додає роботи для менш навантажених, підвищуючи загальну продуктивність.
Таким чином, FAST VP бере на себе традиційні завдання Storage Tiering і робить ще трохи більше. Все це дозволяє досить ефективно зберігати дані у СГД сімейства Unity.
Декілька порад
- Не нехтуйте читанням документації. Є best practices, і вони працюють досить добре. Якщо їм слідувати, то серйозних проблем, як правило, не виникає. Інші поради переважно повторюють чи доповнюють їх.
- Якщо ви налаштували та увімкнули FAST VP, то краще залиште увімкненим. Нехай розподіляє дані у відведений для нього час і потроху, ніж раз на рік і серйозно впливає на продуктивність інших завдань. У разі перерозподіл даних може затягнутися надовго.
- Уважно поставитися до вибору вікна релокації. Хоч це і очевидно, але постарайтеся вибрати час із найменшим навантаженням на Unity та виділіть достатній проміжок часу.
- Плануйте розширення СГД, робіть це вчасно. Це загальна рекомендація, яка є важливою і для FAST VP теж. Якщо обсяг вільного місця дуже малий, то й переміщення даних уповільниться чи стане неможливим. Особливо, якщо ви нехтували пунктом 2.
- Розширюючи пул із включеним FAST VP, не слід починати з найповільніших дисків. Тобто або додаємо всі заплановані RAID-групи відразу, або спочатку додаємо найшвидші диски. У цьому випадку перерозподіл даних на нові швидкі диски підніме загальну швидкість пула. В іншому випадку, почавши з «повільних» дисків, можна отримати дуже неприємну ситуацію. Спочатку відбудеться перенесення даних на нові, відносно повільні диски, а після при додаванні більш швидких у зворотному напрямку. Тут є нюанси, пов'язані з різними політиками FAST VP, але загалом подібна ситуація можлива.
Якщо Ви придивляєтеся до цього продукту, спробувати Unity у справі можна і безкоштовно, завантаживши Unity VSA virtual appliance.
На завершення матеріалу ділюся кількома корисними посиланнями:
- Сторінка
- – короткий опис функції
- , формат PDF
Висновок
Хочеться написати багато про що, але я розумію, що не всі подробиці будуть цікаві читачеві. Наприклад, можна докладніше розповісти про критерії, за якими FAST VP приймає рішення про перенесення даних, процеси аналізу статистики введення-виведення. Також зовсім не порушена тема взаємодії з а це тягне на окрему статтю. Можна навіть пофантазувати щодо розвитку цієї технології. Сподіваюся, було не нудно, і я вас не втомив. До нових зустрічей!
Джерело: habr.com