Чем отличается тестирование на хранение от тестирования на объем?

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

Что такое тестирование хранилища данных? Типы, Concepts & Пример

⚡ Умное резюме

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

💾 Также называемый: Тестирование производительности хранилища, поскольку скорость имеет такое же значение, как и правильное размещение.
⚠️ Почему это важно: Медленное хранилище данных приводит к медленному времени отклика, длительным запросам и снижению доступности приложений.
🧩 Три типа: Тестирование приложений, моделирование приложений и сравнительный анализ производительности — каждый из этих процессов включает в себя свои особенности.
📏 Основные показатели: Показатели IOPS, задержка, пропускная способность и глубина очереди всегда считываются вместе, а не по отдельности.
🧪 Как это работает: Определите цели, определите размер набора данных, выберите реалистичное соотношение операций чтения/записи, а затем постепенно увеличивайте нагрузку.
🇧🇷 оснастка: Генераторы синтетического ввода-вывода выдают воспроизводимые значения, чего никогда не смогут достичь команды копирования файлов.
???? Распространенные ошибки: Отслеживание не того сервера, пропустить.ping Очистка кэша и игнорирование загрузки процессора.

Читать

Что такое тестирование хранилища?

Тестирование хранилища Это тип тестирования программного обеспечения, используемый для проверки того, хранит ли тестируемое программное приложение необходимые данные в соответствующих каталогах и достаточно ли у него места для предотвращения неожиданных сбоев из-за недостатка дискового пространства. Его также называют тестирование производительности хранилища.

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

Зачем проводить тестирование хранилища?

Хранилище данных — это самый медленный слой, с которым взаимодействует большинство приложений, поэтому его уязвимость проявляется во всех остальных областях. Четыре причины оправдывают выделение отдельного цикла тестирования.

Медленная работа хранилища приводит к медленному времени отклика, длительным запросам и снижению доступности приложений.
Медленная работа системы хранения данных приводит к дополнительным затратам на обслуживание серверной инфраструктуры.
Это помогает определить практические пределы объема памяти системы до ее развертывания.
Это помогает понять, как система реагирует на замену или модернизацию аппаратного устройства.

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

Типы тестирования хранилища

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

Тестирование приложений: Тестирование приложения с использованием тестовых запросов в среде, максимально приближенной к производственной.
Моделирование приложения: Проведение тестирования с использованием стандартного программного обеспечения, которое ведет себя аналогично целевому приложению.
бенчмаркинг: Проведение тестирования с использованием стандартного программного обеспечения для бенчмаркинга, генерирующего синтетическую, воспроизводимую рабочую нагрузку.

Первый метод дает наиболее реалистичный результат, но наименее переносимый; третий же предоставляет данные, которые можно сравнивать на разных устройствах и у разных производителей, но мало что говорит о том, как будет вести себя само приложение.

Общее тестирование Concepts Применяется во время испытаний на хранение.

Каждый из этих трех типов соответствует определенному набору действий, как это суммировано ниже.

Типы тестирования хранилища	Пример обычного тестирования хранилища
Тестирование приложений	Сравните время ответа OLTP Сравните время пакетного выполнения Сравните постоянную скорость потоковой передачи
Моделирование приложений	Тестирование пикового числа операций ввода-вывода в секунду для баз данных Проверка пиковой пропускной способности хранилища в средах потоковой передачи данных. Проверка задержки хранения данных для приложений обмена сообщениями или других однопоточных приложений.
Производительность системы	Тестирование на повреждение данных

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

Результаты анализа данных о хранении информации представляются в виде небольшого набора чисел. Чтение любого из этих чисел само по себе — самый быстрый способ прийти к неверному выводу, поскольку они взаимосвязаны.

Метрика	Что он измеряет	Там, где это наиболее важно.
IOPS	Количество операций чтения и записи в секунду, независимо от размера.	Транзакционные базы данных и небольшие случайные записи
Задержка	Время между началом и завершением одной операции ввода-вывода	Обмен сообщениями и однопоточные пути выполнения приложений
Увеличить пропускную способность	Объем передаваемых данных в секунду, обычно в МБ/с.	Пакетные запуски, резервное копирование и потоковые рабочие нагрузки
Глубина очереди	Количество одновременно обработанных невыполненных запросов	Любой запуск, который должен отражать реальную параллельность.

Глубина очереди заслуживает особого внимания. Отправка одного запроса за раз обеспечивает точную задержку для отдельного запроса, но искусственно заниженные показатели IOPS и пропускной способности, поэтому устройство может выглядеть медленным в тесте и быстрым в рабочей среде, или наоборот.

Как провести тестирование хранилища данных

Надежность теста на хранение зависит от условий его проведения. Приведенная ниже последовательность действий обеспечивает воспроизводимость результатов.

Шаг 1) Определите цель. Определите, для чего предназначен запуск: для проверки готовности базы данных, для определения предельной пропускной способности или для сравнения двух устройств. Каждая цель подразумевает разную рабочую нагрузку, а их сочетание приводит к результатам, на основе которых невозможно будет принимать решения.
Шаг 2) Реалистично оцените размер набора данных. Размер рабочего набора данных, достаточный для размещения в кэше, измеряет объем кэша, а не хранилища. Необходимо сопоставить объем данных с объемом производственных данных или, по крайней мере, значительно превысить размер кэша.
Шаг 3) Выберите комбинацию чтения/записи и шаблон. Произвольный и последовательный доступ ведут себя совершенно по-разному на одном и том же устройстве, как и соотношения чтения и записи 70/30 и пакетной записи только в режиме записи. Лучше брать параметры соотношения из системы мониторинга производства, а не из настроек по умолчанию.
Шаг 4) Установите глубину очереди и количество потоков. Эти параметры определяют, какой объем параллельной обработки данных поступает на устройство, поэтому записывайте их вместе с каждым результатом — цифра, приведенная без них, не может быть воспроизведена.
Шаг 5) Очистите кэш и прогрейтесь. Между запусками удаляйте кэши сервера и устройства, затем отбрасывайте первый интервал, чтобы сравнивались показатели в установившемся режиме, а не показатели первого касания.
Шаг 6) Бегите достаточно долго. Короткие циклы работы скрывают «обрыв записи», который появляется, когда SSD-накопитель исчерпывает свой буфер записи. Длительные циклы работы выявляют его.
Шаг 7) Отслеживайте состояние всего стека. Необходимо фиксировать загрузку процессора, памяти и сети наряду со счетчиками хранилища, чтобы узкое место в другом месте не было ошибочно воспринято как ограничение объема хранилища.
Шаг 8) Повторите и сравните. Запустите идентичную конфигурацию несколько раз и сохраните логи; изменение производительности между сборками будет заметно только по сравнению с сохраненным базовым уровнем.

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

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

Инструменты делятся на две группы, и большинству команд нужны оба.

Синтетические генераторы ввода-вывода. Утилиты, такие как нитьIometer и sysbench выдают точно описанную рабочую нагрузку — размер блока, соотношение чтения/записи, глубина очереди и длительность — все это указывается, поэтому запуск можно точно повторить на другом устройстве.
Инструменты загрузки на уровне приложений. Такие факторы, как JMeter Запустите само приложение, чтобы хранилище видело тот же шаблон доступа, который создают реальные пользователи, включая планы запросов и поведение индексов, которые синтетический инструмент не может воспроизвести.

OperaСчетчики системы хранения данных дополняют картину. Независимо от того, какой инструмент генерирует нагрузку, показатели объема памяти необходимо считывать вместе со счетчиками процессора, памяти и сети — для этого используются различные методы тестирования памяти, включая эталонное тестирование и объемное тестированиеДля корректной интерпретации результата необходимо полагаться на это комплексное представление.

Ошибки при проведении тестирования хранилищ

Большинство некорректных результатов хранения tracвернуться к небольшому числу предотвратимых ошибок.

Отслеживание производительности сервера осуществляется некорректно, поэтому полученные данные описывают работу машины, которая не проходила тестирование.
Сравнение устройств хранения данных без предварительной очистки кэша сервера, что позволяет измерять объем памяти, а не дискового пространства.
Забывание отслеживать загрузку процессора во время тестирования скрывает узкое место, обусловленное производительностью процессора, за симптомом, связанным с нехваткой памяти.
Тестирование производительности хранилища с помощью команд копирования файлов, которые являются однопоточными, используют кэширование и не позволяют воспроизвести результаты.

Часто задаваемые вопросы (FAQ)

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

Приложение записывает данные во все места: каталоги данных, папки журналов и временные папки, целевые папки для загрузки и пути к архивам. Для каждого из них необходимо проверить, что файл попадает в нужное место и что свободное место отображается корректно.

Основные показатели остаются прежними, но добавляются выделенные лимиты IOPS, кредиты на пиковую нагрузку и шумные соседи. Запустите программу достаточно долго, чтобы кредиты на пиковую нагрузку были исчерпаны, иначе измеренное значение будет отражать временное разрешение, а не стабильное состояние.

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

Второй пилот GitHub Быстро создает файлы заданий, обертки для очистки кэша и скрипты для анализа результатов. Тестировщик по-прежнему предоставляет размер блока, глубину очереди и продолжительность, поскольку эти данные поступают из системы мониторинга производственной среды, а не из шаблона.

Это корректный тестовый пример, а не случайность. Приложение должно выдавать предупреждения, корректно реагировать на ухудшение состояния и регистрировать ошибку, а не завершать работу. Восстановление после переполнения диска должно осуществляться с помощью... тестирование восстановления.

Обычно состояние кэша, глубина очереди или длина последовательности различались между ними. Важно также состояние устройства — свежеотформатированный SSD-накопитель записывает данные быстрее, чем тот, который был заполнен и перезаписан несколько раз.

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