По какво се различава тестването за съхранение от тестването за обем?

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

Какво е тестване на съхранение? Видове, Concepts & Пример

⚡ Умно обобщение

Тестването на съхранението проверява дали приложението записва данните си в правилните директории и има достатъчно дисково пространство, за да избегне неочаквани прекъсвания, като същевременно измерва колко бързо реагира базовото хранилище при реалистично натоварване.

💾 Също наричан: Тестване на производителността на съхранението, защото скоростта е толкова важна, колкото и правилното разположение.
⚠️ Защо това е важно: Бавното съхранение води до бавно време за реакция, продължителни заявки и по-ниска наличност на приложенията.
🧩 Три вида: Тестване на приложения, симулация на приложения и бенчмаркинг, всяко със свои собствени дейности.
📏 Основни показатели: IOPS, латентност, пропускателна способност и дълбочина на опашката винаги се четат заедно, а не изолирано.
🧪 Как работи: Дефинирайте цели, оразмерете набора от данни, изберете реалистични комбинации от четене/запис и след това увеличете натоварването.
🛠️ Инструментална: Синтетичните генератори на входно/изходни данни генерират повтарящи се числа, които командите за копиране на файлове никога не могат.
🚫 Често срещани грешки: Мониторинг на грешен сървър, пропуснетеping изчистване на кеша и игнориране на използването на процесора.

Прочетете повече

Какво е тестване на съхранение?

Тестване на съхранение е вид софтуерно тестване, използвано за проверка дали тестваното софтуерно приложение съхранява съответните данни в подходящи директории и дали има достатъчно място, за да предотврати неочаквани прекъсвания поради недостатъчно дисково пространство. Нарича се още тестване на производителността на съхранението.

Техниката се намира от нефункционалната страна на дисциплината: подобно на други форми на нефункционално тестване, не казва нищо за това дали дадена функция генерира правилния отговор, а всичко е за това дали системата може да продължи да генерира отговори с нарастване на обема на данните и натоварването от входно/изходни операции.

Защо тестване на съхранение?

Паметта е най-бавният слой, до който повечето приложения се докосват, така че слабостта му се проявява навсякъде другаде. Четири причини оправдават специален тестов цикъл.

Бавното съхранение означава бавно време за реакция, продължителни заявки и по-ниска наличност на приложенията.
Бавното съхранение е допълнително натоварване за поддръжката на сървърната инфраструктура.
Помага да се намерят практическите ограничения за съхранение на системата преди внедряването ѝ.
Полезно е да се разбере как системата реагира, когато хардуерно устройство бъде подменено или надстроено.

Диаграмата по-долу поставя тестването на съхранението в този контекст – приложението, файловата система и физическото устройство се намират на един и същ път и забавяне навсякъде по него достига до потребителя.

Видове тестове за съхранение

Използват се три подхода, които се различават главно по това доколко работното натоварване наподобява реалното приложение.

Тестване на приложението: Тестване на приложения с примерни заявки в среда, подобна на продукционна.
Симулация на приложение: Провеждане на тестването с помощта на стандартен софтуер, който се държи подобно на целевото приложение.
Сравнителен анализ: Провеждане на тестването с помощта на стандартен софтуер за бенчмаркинг, който генерира синтетично, повтаряемо работно натоварване.

Първият дава най-реалистичния резултат и най-малко преносимия; третият дава числа, които могат да се сравняват между различни устройства и доставчици, но казва малко за това как ще се държи самото приложение.

Общо тестване Concepts Участник по време на тестване на съхранението

Всеки от тези три вида се свързва с отделен набор от дейности, както е обобщено по-долу.

Видове тестове за съхранение	Пример за общи дейности за тестване на съхранение
Тестване на приложения	Сравнете времето за отговор на OLTP Сравнете времето за изпълнение на партиди Сравнете постоянните скорости на поточно предаване
Симулация на приложения	Тествайте IOPS при пиково съхранение за бази данни Тествайте пиковата пропускателна способност за съхранение за среди за стрийминг на данни Тествайте латентността на съхранението за съобщения или други еднонишкови приложения
Сравнителният анализ	Тестване за повреда на данните

Ключови показатели при тестване на съхранение

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

метричен	Какво измерва	Където е най-важно
IOPS	Операции за четене и запис, извършвани в секунда, независимо от размера	Транзакционни бази данни и малки произволни записи
латентност	Времето между началото и завършването на една входно/изходна операция	Пътища за съобщения и еднонишкови приложения
магистрала	Обем на данните, преместени в секунда, обикновено в MB/s	Пакетни изпълнения, архивиране и стрийминг натоварвания
Дълбочина на опашката	Брой неизпълнени заявки, издадени едновременно	Всяко изпълнение, което трябва да отразява реална паралелност

Дълбочината на опашката заслужава специално внимание. Издаването на една заявка наведнъж води до точна латентност за единична заявка, но изкуствено ниски стойности за IOPS и пропускателна способност, поради което едно устройство може да изглежда бавно в тест и бързо в производствена среда или обратното.

Как да извършите тестване на съхранението

Тестът за съхранение е надежден само дотолкова, доколкото са надеждни условията, при които е проведен. Последователността по-долу осигурява повторяемост на резултатите.

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

Тъй като същата дисциплина се прилага за всяко измерване, управлявано от натоварване, тези изпълнения обикновено се планират заедно с тестване на производителността и е планирано преди замразяването на кандидата за освобождаване.

Инструменти за тестване на съхранение

Инструментите се разделят на две групи и повечето екипи се нуждаят и от двете.

Синтетични генератори на входно/изходни данни. Комунални услуги като например Fio, Iometer и sysbench издават точно описано работно натоварване — декларирани са размер на блока, комбинация от четене/запис, дълбочина на опашката и продължителност, така че изпълнението може да се повтори точно на друго устройство.
Инструменти за зареждане на ниво приложение. Шофьори като например JMeter упражнете самото приложение, така че хранилището да вижда същия модел на достъп, който реалните потребители създават, включително плановете за заявки и поведението на индексите, които синтетичен инструмент не може да възпроизведе.

OperaСистемните броячи на ting допълват картината. Независимо кой инструмент генерира натоварването, данните за паметта трябва да се прочетат редом с броячите на процесора, паметта и мрежата – няколко техники за тестване на паметта, включително бенчмарк тестване намлява обемно тестване, разчитайте на този пълен изглед, за да интерпретирате правилно резултата.

Грешки при извършване на тестове за съхранение

Повечето невалидни резултати от съхранението tracобратно към малък брой грешки, които могат да бъдат избегнати.

Мониторинг на производителността на грешния сървър, така че числата описват машина, която не е тествана.
Сравняване на устройства за съхранение без първо изчистване на кеша на сървъра, което измерва паметта, а не дисковата памет.
Забравяне да се следи използването на процесора по време на тестване, което крие свързано с процесора затруднение зад симптом, свързан със съхранението.
Тестване на производителността на съхранението с команди за копиране на файлове, които са еднонишкови, кеширани и неповторими.

Въпроси и Отговори

Обемно тестване увеличава количеството данни, което приложението съхранява, и наблюдава как поведението се влошава. Тестването на съхранението е насочено към слоя на устройството под него, измервайки колко бързо тези данни могат да бъдат записани и прочетени обратно.

Всяко място, където приложението записва: директории с данни, папки за лог файлове и временни папки, цели за качване и пътища за архивиране. Всяко от тях изисква проверка дали файлът е разположен на правилното място и дали свободното пространство е отчетено правилно.

Метриките остават същите, но се добавят зададени IOPS лимити, burst кредити и шумни съседи. Да се изпълнява достатъчно дълго, за да се изчерпи burst кредитът, в противен случай измерената стойност отразява временно ограничение, а не стабилно състояние.

Моделите за машинно обучение извеждат изходните нормални криви на IOPS и латентност, след което маркират изпълнения, които се отклоняват, преди да бъде достигнат праг. Същите модели прогнозират растеж на капацитета, така че изчерпването на диска се предвижда, а не се открива в производствения процес.

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

Това е валиден тестов случай, а не инцидент. Приложението трябва да предупреди, да деградира коректно и да регистрира състоянието, вместо да прекрати. Възстановяването от състояние на пълен диск е част от... тестване за възстановяване.

Обикновено състоянието на кеша, дълбочината на опашката или дължината на изпълнение се различаваха между тях. Кондиционирането на устройството също има значение - прясно форматиран SSD записва по-бързо от такъв, който е бил запълван и презаписван няколко пъти.

Обикновено се изпълнява от тестери за производителност, като администраторите на инфраструктура или база данни предоставят конфигурацията на устройството и моделите за достъп до производствения процес. Резултатът е оправдан само когато и двете страни са съгласни, че работното натоварване е било реалистично.