Яка ємність SSD відповідає вимогам до обробки корпоративних даних?

Розуміння реальних показників ємності твердотільних накопичувачів: «сирі», корисні та ефективні обсяги

Як резервування (over-provisioning) та накладні витрати прошивки зменшують корисну ємність твердотільних накопичувачів

Цифри, вказані на корпоративних твердотільних накопичувачах (SSD), зазвичай стосуються необробленої NAND-пам’яті всередині них, а не того обсягу, до якого користувачі можуть отримати фактичний доступ. Коли виробники згадують про надлишкове забезпечення (over-provisioning), вони резервують приблизно 28 % цього необробленого простору для таких функцій, як збирання сміття (garbage collection) та вирівнювання зносу (wear leveling), що забезпечують стабільну роботу пристрою під час інтенсивного запису даних. Крім того, прошивка займає ще 7–10 % обсягу для таких завдань, як виправлення помилок, керування пошкодженими блоками та зберігання інформації контролера. Усі ці виділення означають, що фактичний корисний обсяг значно зменшується. Наприклад, накопичувач, рекламований як 1 ТБ, зазвичай надає близько 930 ГБ корисного простору. Ця різниця має велике значення під час планування ІТ-інфраструктури. Будь-хто, хто працює з базами даних або віртуальними машинами, добре знає, що стабільна продуктивність операцій введення/виведення — це не просто бажана характеристика, а безпосередній чинник, що визначає, чи будуть дотримані угоди про рівень обслуговування (SLA) чи порушаться під час пікового навантаження.

Ефективне збільшення ємності SSD за рахунок апаратного прискорення стиснення та дедуплікації

Сьогодні корпоративні твердотільні накопичувачі (SSD) борються з втратою ємності за допомогою апаратно прискорених методів стиснення та дедуплікації, які автоматично виконуються безпосередньо в контролері. Метод стиснення LZ4 дуже ефективно працює з текстовими файлами та записами журналів, часто скорочуючи їхній розмір приблизно наполовину або на дві третини. Дедуплікація застосовується, коли існують дублюючі блоки даних у різних віртуальних машинах або образах контейнерів. Коли обидві ці технології працюють разом, вони створюють так звану ефективну ємність, яка насправді в 1,5–2 рази перевищує фізичний обсяг NAND-пам’яті. Наприклад, стандартний 15 ТБ QLC SSD завдяки цим оптимізаціям може ефективно зберігати до 27 ТБ логічних даних. Ми спостерігали вражаючі результати при роботі з наборами даних для навчання штучного інтелекту, які часто містять багато повторюваних патернів — наприклад, контрольні точки моделей та пакунки синтетичних даних. У таких випадках економія місця може досягати 80 %, що дозволяє використовувати рішення з високою щільністю зберігання для архівування та підготовки даних без помітного впливу на такі метрики продуктивності, як затримка або пропускна здатність.

Підбір обсягу SSD під основні корпоративні робочі навантаження

СУБД SQL: балансування щільності IOPS, обсягу журналів і обсягу SSD

Планування ємності SSD для транзакційних баз даних є дуже важливим, якщо ми хочемо задовольняти вимоги до випадкових IOPS і одночасно керувати зростаючими журналами транзакцій. У разі роботи з навантаженням OLTP, що переважно спрямоване на запис, ці журнали можуть займати близько 20–30 % доступного простору сховища. Якщо додаткового місця недостатньо, система починає інтенсивніше працювати над керуванням операціями запису, що призводить до швидшого зносу SSD і уповільнення відгуків. Згідно з галузевими стандартами, більшість систем, що обробляють приблизно 50 тисяч транзакцій на хвилину, потребують щонайменше в 1,5 раза більшої ємності порівняно з обсягом «сирої» даних — лише для цих журналів, а також для буферного простору й тимчасових операцій з базою даних. Залишення додаткової ємності в обсязі приблизно 15–20 % справді має значний вплив: це забезпечує стабільність продуктивності під час піків навантаження та збільшує термін служби накопичувачів. Це має велике значення, оскільки існує чіткий зв’язок між достатнім запасом стійкості (endurance headroom) та здатністю забезпечувати надійну роботу протягом тривалого часу, особливо в критично важливих бізнес-середовищах, де простої ведуть до фінансових втрат.

Віртуалізовані середовища (vSphere/Hyper-V): масштабування потужності залежно від щільності віртуальних машин та політик створення знімків

Коли компанії переходять на віртуалізацію, їм потрібно значно більше місця для зберігання даних через велику кількість віртуальних машин (VM), розташованих разом, а також через те, що кожна гостьова операційна система займає певний обсяг простору. І навіть не починайте говорити про знімки (snapshots), які множаться всюди. Більшість віртуальних машин потребує від 40 до 100 гігабайт лише для самої операційної системи та програмного забезпечення. Але будьте обережні зі знімками під час оновлення програмного забезпечення або резервного копіювання — у цей час обсяг використаного сховища може збільшитися вдвічі. Якщо в середовищі працює понад 50 віртуальних машин, фахівцям ІТ-відділу слід виділити додатково приблизно ще чверть обсягу SSD-простору спеціально для зберігання метаданих знімків, тимчасових клонів і тих неприємних файлів підкачки (swap files), що накопичуються з часом. Тонке забезпечення (thin provisioning) справді допомагає заощадити місце на початковому етапі, але ніхто не хоче несподівано стикнутися з нестачею сховища пізніше, тому регулярний моніторинг обов’язковий, щоб уникнути проблем із продуктивністю. Для досягнення найкращих результатів частоту створення знімків слід узгоджувати з типом робочих навантажень. Критичні виробничі системи, можливо, потребують знімків щогодини, тоді як середовища розробки та тестування, ймовірно, можуть обійтися знімками раз на добу. Такий підхід скорочує кількість надлишкових копій даних, не позбавляючи нас можливості відновитися після виникнення проблем, коли це потрібно.

Сервери для зберігання файлів та об’єктів: накладні витрати на метадані порівняно з вимогами до послідовної пропускної здатності

Зберігання на SSD розділяється між обробкою метаданих та переміщенням фактичних даних під час роботи з файловим і об'єктним сховищем. Системи, що працюють з великою кількістю метаданих — наприклад, архіви медичних зображень або масивні колекції юридичних документів — часто повинні виділяти приблизно чверть–третину загального обсягу простору лише для таких завдань, як індексування файлів, навігація по каталогах та управління правами доступу. Такі системи дійсно потребують щонайменше 15 000 операцій вводу-виводу на секунду (IOPS) на кожні десять терабайт, щоб забезпечити швидку відповідь при роботі з великою кількістю невеликих файлів. З іншого боку, конфігурації, орієнтовані на швидке переміщення даних, а не на їх довільний доступ — наприклад, робочі станції для відеомонтажу або пули довготривалого зберігання даних — надають перевагу прямої пропускної здатності. Їм зазвичай потрібно забезпечувати стабільну швидкість запису понад 1,5 гігабайта на секунду. SSD на основі технології QLC дійсно є економічно вигідним варіантом для зберігання такого типу архівних даних, але тут є важливий нюанс. Якщо накопичувачі переписуються щодня більше, ніж приблизно на три десятих від їхньої повної ємності, вони набагато швидше зношуються, ніж очікувалося.

Стійкість та архітектура SSD: чому обсяг накопичувача має відповідати навантаженню на запис

Вплив TBW, DWPD та типу NAND: SSD з пам’яттю SLC, TLC та QLC у виробничих умовах

Тривалість роботи твердотільних накопичувачів (SSD) залежить від трьох основних факторів: кількості терабайтів, які можна записати (TBW), щоденної ємності запису (DWPD) та типу технології NAND, що використовується всередині. SSD із пам’яттю SLC мають значно більший термін служби порівняно з іншими: вони витримують від 50 000 до 100 000 циклів запису до виходу з ладу. Недолік? Вони коштують набагато дорожче, тому їх використовують переважно в кеш-системах, де найважливішою є швидкість, наприклад, у платформах високочастотного трейдингу в фінансовій сфері. TLC займає проміжне положення: її термін служби становить приблизно 1 000–3 000 циклів. Це робить її достатньо надійною для звичайних корпоративних систем зберігання даних, де часто відбуваються як операції читання, так і запису. І, нарешті, QLC — це технологія, що дозволяє розмістити значно більше даних у меншому об’ємі та забезпечує нижчу вартість за гігабайт. Але є й недолік: її термін служби коротший — максимум приблизно 1 000 циклів. Цього достатньо для завдань, де операції читання переважають над записом, наприклад, для резервних копій файлів, системних журналів або тимчасових кешів вебсайтів, що надають контент.

Пайплайни навчання ШІ/МШ: оцінка доцільності використання QLC-накопичувачів з високою ємністю за умов тривалих записів

Пайплайни навчання ШІ/МШ створюють унікально вимогливі, тривалі шаблони запису — часто з повторним завантаженням, перемішуванням та створенням контрольних точок наборів даних обсягом у кілька терабайт. За таких умов QLC-накопичувачі піддаються прискореному зносу: безперервний запис 24/7 може вичерпати їх ресурс стійкості за місяці замість років.

Надлишкове виділення (over-provisioning) сприяє подовженню терміну служби QLC-накопичувачів, але не може компенсувати фундаментальні архітектурні обмеження. Для продуктивної інфраструктури ШІ важливо вибирати тип NAND з урахуванням очікуваної інтенсивності записів — а не лише потреб у ємності — щоб уникнути незапланованих замін, різкого падіння продуктивності або ризиків порушення цілісності даних.