Що відбувається, коли диск заповнюється під час тесту?

Це дійсний тестовий випадок, а не випадковість. Додаток має попереджати, коректно деградувати та записувати умову в журнал, а не завершувати роботу. Відновлення після стану повного диска належить до тестування відновлення.

Що таке тестування сховища? Типи, Concepts & Приклад

⚡ Розумний підсумок

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

💾 Також називається: Тестування продуктивності сховища, оскільки швидкість має таке ж значення, як і правильне розміщення.
⚠️ Чому це важливо: Повільне сховище призводить до повільного часу відгуку, тривалого виконання запитів та зниження доступності програм.
🧩 Три типи: Тестування додатків, моделювання додатків та бенчмаркінг, кожне зі своїми власними видами діяльності.
📏 Основні показники: IOPS, затримка, пропускна здатність та глибина черги завжди зчитуються разом, а не окремо.
🧪 Як це працює: Визначте цілі, оберіть розмір набору даних, виберіть реалістичні комбінації читання/запису, а потім збільште навантаження.
🛠️ інструменти: Синтетичні генератори вводу/виводу створюють повторювані числа, які команди копіювання файлів ніколи не можуть створювати.
🚫 Поширені помилки: Моніторинг неправильного сервера, пропуститиping очищення кешу та ігнорування використання процесора.

Детальніше

Що таке тестування сховища?

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

Ця техніка знаходиться на нефункціональній стороні дисципліни: як і інші форми нефункціональне тестування, це нічого не говорить про те, чи функція видає правильну відповідь, і все говорить про те, чи може система продовжувати видавати відповіді зі зростанням обсягу даних та навантаження на операції вводу/виводу.

Чому тестування зберігання?

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

Повільне сховище означає повільний час відгуку, тривалі запити та нижчу доступність програм.
Повільне сховище є накладними витратами на обслуговування серверної інфраструктури.
Це допомагає визначити практичні межі сховища системи перед розгортанням.
Це допомагає зрозуміти, як система реагує на заміну або оновлення апаратного пристрою.

На діаграмі нижче тестування сховища даних розглядається в цьому контексті — програма, файлова система та фізичний пристрій знаходяться на одному шляху, і користувач досягає певної затримки на будь-якій його ділянці.

Типи тестування зберігання

Використовуються три підходи, і вони відрізняються головним чином тим, наскільки робоче навантаження відповідає реальному застосуванню.

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

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

Загальне тестування Concepts Залучений під час тестування зберігання

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

Типи тестування зберігання	Приклад типових дій з тестування сховища
Тестування додатків	Порівняйте час відповіді OLTP Порівняйте час виконання партії Порівняйте стабільні швидкості потокового передавання
Моделювання застосування	Тестування максимальної кількості IOPS для зберігання даних для баз даних Тестування пікової пропускної здатності сховища для середовищ потокової передачі даних Тестування затримки сховища для обміну повідомленнями або інших однопотокових програм
порівняльний аналіз	Тестування на пошкодження даних

Ключові показники тестування сховища

Результати зберігання даних повідомляються за допомогою невеликого набору чисел. Читання будь-якого з них окремо – це найшвидший спосіб дійти неправильного висновку, оскільки вони взаємодіють один з одним.

Metric	Що він вимірює	Де це найважливіше
IOPS	Операції читання та запису, що виконуються за секунду, незалежно від розміру	Транзакційні бази даних та невеликі випадкові записи
Затримка	Час між початком і завершенням однієї операції вводу-виводу	Шляхи обміну повідомленнями та однопотокових програм
Пропускна здатність	Обсяг даних, що передаються за секунду, зазвичай у МБ/с	Пакетні запуски, резервні копії та потокові навантаження
Глибина черги	Кількість нерозглянутих запитів, поданих одночасно	Будь-який запуск, який має відображати реальну паралельність

Глибина черги заслуговує на особливу увагу. Виконання одного запиту за раз призводить до точної затримки для одного запиту, але штучно занижених показників IOPS та пропускної здатності, через що пристрій може виглядати повільним у тесті та швидким у робочому середовищі, або навпаки.

Як виконати тестування сховища

Тест зберігання є настільки надійним, наскільки надійними є умови, за яких він проводився. Наведена нижче послідовність забезпечує повторюваність результатів.

Крок 1) Визначте мету. Визначте, чи це запуск, який перевіряє готовність бази даних, знаходить граничну пропускну здатність чи порівнює два пристрої. Кожна мета передбачає різне робоче навантаження, а їх поєднання призводить до цифр, на які ніхто не може вплинути.
Крок 2) Реалістично визначте розмір набору даних. Робочий набір, достатньо малий, щоб поміститися в кеш, вимірює кеш, а не сховище. Дотримуйтесь обсягу виробничих даних або принаймні значно перевищуйте розмір кешу.
Крок 3) Виберіть комбінацію читання/запису та шаблон. Випадковий та послідовний доступ поводяться дуже по-різному на одному пристрої, як і суміші читання-запису 70/30 та пакети лише для запису. Візьміть суміш з моніторингу виробництва, а не з налаштувань за замовчуванням.
Крок 4) Встановіть глибину черги та кількість потоків. Вони контролюють, скільки паралельних операцій досягає пристрою, тому записуйте їх з кожним результатом — цифру, наведену без них, неможливо відтворити.
Крок 5) Очистіть кеш та розігрійте систему. Видаляйте кеші сервера та пристрою між запусками, а потім відкидайте перший інтервал, щоб порівнювалися стаціонарні значення, а не ті, що були отримані першим.
Крок 6) Біжіть достатньо довго. Короткі запуски приховують обрив запису, який з'являється, коли SSD вичерпує свій буфер запису. Тривалі запуски його викривають.
Крок 7) Контролюйте весь стек. Фіксуйте використання процесора, пам'яті та мережі разом із лічильниками сховища, щоб вузьке місце в іншому місці не було помилково інтерпретовано як обмеження сховища.
Крок 8) Повторіть та порівняйте. Запустіть ідентичну конфігурацію кілька разів і збережіть журнали; дрейф продуктивності між збірками видно лише на збереженому базовому рівні.

Оскільки та сама дисципліна застосовується до будь-якого вимірювання, керованого навантаженням, ці прогони зазвичай плануються разом із тестування працездатності та заплановано до заморожування реліз-кандидата.

Інструменти для тестування сховищ

Інструменти поділяються на дві групи, і більшості команд потрібні обидві.

Синтетичні генератори вводу/виводу. Такі комунальні послуги, як ниткаIometer та sysbench видають точно описане робоче навантаження — розмір блоку, поєднання читання/запису, глибина черги та тривалість декларуються, тому запуск можна повторити точно на іншому пристрої.
Інструменти завантаження на рівні програми. Такі водії, як JMeter випробувати саму програму, щоб сховище бачило той самий шаблон доступу, який створюють реальні користувачі, включаючи плани запитів та поведінку індексу, яку синтетичний інструмент не може відтворити.

OperaЛічильники ting-system доповнюють картину. Який би інструмент не генерував навантаження, показники пам'яті необхідно зчитувати поруч із лічильниками процесора, пам'яті та мережі — кілька методів тестування пам'яті, включаючи бенчмарк-тестування та об'ємне тестування, покладатися на це повноцінне представлення, щоб правильно інтерпретувати результат.

Помилки під час тестування сховища

Більшість недійсних результатів зберігання tracповернемося до невеликої кількості помилок, яких можна уникнути.

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

Поширені запитання

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

Кожне місце, куди програма записує дані: каталоги даних, папки журналів та тимчасові папки, цільові об'єкти завантаження та шляхи архівів. Кожне з них потребує перевірки, чи файл знаходиться в правильному місці, а також чи правильно повідомляється про вільний простір.

Метрики залишаються незмінними, але додаються виділені ліміти IOPS, кредити пакетної передачі та шумні сусіди. Запускається достатньо довго, щоб кредит пакетної передачі був вичерпаний, інакше виміряний показник відображає тимчасовий ліміт, а не стабільний стан.

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

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

Це дійсний тестовий випадок, а не випадковість. Додаток має попереджати, коректно деградувати та реєструвати стан, а не завершувати роботу. Відновлення зі стану повного диска належить... тестування відновлення.

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

Зазвичай його виконують тестувальники продуктивності, а адміністратори інфраструктури або бази даних надають конфігурацію пристрою та шаблони доступу до виробничої мережі. Результат є виправданим лише тоді, коли обидві сторони погоджуються, що робоче навантаження було реалістичним.