PowerStore. Эффективные методы оценки производительности массивов хранения данных

Примечание. Сравнительная оценка действительна только в том случае, если все настроено в соответствии с передовыми практиками PowerStore и отсутствуют проблемы с подключением или конфигурацией. В противном случае тест, скорее всего, выдаст нерелевантные данные.

• Выполните тестирование с использованием переменных, которые соответствуют реальной рабочей нагрузке или среде. Помните, что большинство инструментов являются симуляторами и никогда не позволяют на 100% смоделировать реальную рабочую нагрузку.
• Если рабочая нагрузка варьируется в широких пределах, рассмотрите возможность выполнения нескольких итераций тестов чтения/записи с различными размерами блоков и шаблонами доступа.
• Используйте многопоточные и асинхронные операции или тесты для обеспечения возможности параллельной или параллельной производительности и использования потенциала общей совокупной пропускной способности. 
• Рассмотрите и просмотрите стандартные отраслевые критерии оценки оцениваемого оборудования, поскольку они относятся к производственной рабочей нагрузке вашего предприятия.
• Избегайте тестирования для пустых файловых систем и/или томов с низким уровнем использования пространства. Если вы заранее не выделяете пространство для рабочих нагрузок записи, вы можете увидеть задержку из-за выделения пространства «на лету» во время тестирования.
• Не забудьте протестировать ввод-вывод чтения, так как обычно он является доминирующим в большинстве сред. Помните о потере пакетов/кадров в сетевой инфраструктуре во время тестирования.
• Убедитесь, что тестирование выполняется на нескольких устройствах, чтобы смоделировать типичную среду с большим количеством хостов или клиентов. Например, в PowerStore хорошим числом является 16 томов. Количество томов обычно соответствует количеству используемых хостов или клиентов (физических или виртуальных). Именно здесь достигается параллелизм.

 

Средства и симуляторы сравнительной оценки производительности
Имейте в виду, что большинство инструментов являются симуляторами и, скорее всего, никогда не смогут смоделировать на 100% реальную рабочую нагрузку. Эти инструменты сравнительной оценки используются, чтобы получить представление о том, какой может быть, должна или будет быть производительность в определенных ситуациях. Корпорация Dell не владеет этими инструментами и не несет ответственности за какие-либо вопросы или проблемы, которые могут быть с ними связаны.

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

• Универсальный тестер ввода-вывода (FIO)
• IOmeter
• Вдбенч (требуется учетная запись Oracle)
• NFSометр (Только Fedora/NFS)
• Контрольный список производительности сетевых систем хранения данных Intel

 

Избегайте следующих типов проверок:

• Копирование и вставка
• Перетаскивание
• Резервное копирование одной файловой системы на диск
• Тесты DD
• Увеличить
• Большая
• Mkfile
• Распаковка, извлечение и сжатие

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

 

 

IODepth (глубина очереди)
Низкая (или недостаточно большая) глубина ввода-вывода может ограничить потенциальную пропускную способность в зависимости от ситуации. Поэтому всегда проверяйте, чтобы глубина ввода-вывода была достаточно высокой, чтобы отражать или эмулировать требования к параллелизму рабочей нагрузки. Слишком низкая глубина ввода-вывода может неправильно использовать весь потенциал устройства. Кроме того, будьте осторожны со слишком большой глубиной ввода-вывода, это может привести к значительному образованию очереди на устройстве, и, в зависимости от времени обслуживания устройства, время отклика может увеличиться. Это может отражать то, как может выглядеть перегруженная система.

В этом тесте цифры значительно ниже, когда IOdepth равен единице, по сравнению с IOdepth чего-то более реального, например, 64. Имейте в виду, что речь идет о массиве класса All-Flash, и поэтому эта концепция рассматривается в ее крайней, но все более распространенной форме».

IOdepth=1" это около ~30 000 операций ввода-вывода в секунду (IOPS) в среднем для теста.

 

«IOdepth=64» соответствует примерно ~107 000 IOPS в среднем для теста.

 

 

«IOdepth=256» соответствует примерно ~142 000 IOPS в среднем для теста.

 

 

Как уже упоминалось, в большинстве конфигураций производительность выравнивается при определенной глубине ввода-вывода. Глубина очереди здесь составляет 512, а количество операций ввода-вывода в секунду незначительно увеличивается по сравнению с глубиной ввода-вывода 64».

IOdepth=512" это около ~146 000 IOPS в среднем для теста.

 

 


Асинхронная и синхронная
репликацияИспользуются два основных различных движка. Самым популярным и, безусловно, самым эффективным с точки зрения производительности является «асинхронный ввод-вывод». Менее эффективным и менее производительным типом модуля является синхронный ввод-вывод, который обычно используется в приложениях, предъявляющих строгие требования к целостности и надежности данных. Синхронный ввод-вывод также используется в технологиях репликации с целевой точкой восстановления (RPO), близкой к нулю. При тестировании производительности и сравнительной оценке с точки зрения хоста асинхронность означает, что для запроса следующего ввода-вывода не требуется подтверждение для одного ввода-вывода. При синхронных рабочих нагрузках перед выполнением следующего ввода-вывода требуется подтверждение для ввода-вывода, а для каждого последующего запроса ввода-вывода — подтверждение (ACK). Таким образом, синхронный ввод-вывод обычно имеет очередь 1 или меньше и никогда полностью не использует ресурс в полной мере. Объединение синхронных операций с малым или одним числом потоков может серьезно ограничить потенциальную производительность, поэтому всегда проверяйте, что вы выполняете асинхронное тестирование, а если вы используете синхронное тестирование, убедитесь, что вы используете несколько потоков, если среда приложения явно не указывает на это.

Async (Libaio - Linux native async) = синхронизация 1 потока



(синхронный ввод-вывод):  

 

 

Количество
потоковВажны потоки. Тестирование всегда должно выполняться с использованием нескольких потоков, особенно при синхронных тестах/рабочих нагрузках. Это делается для того, чтобы попытаться смоделировать несколько итераций задания/теста на основе поведения процесса корпоративного приложения. Благодаря нескольким потокам в сочетании с параллельной активностью достигается совокупная пропускная способность системы. Большинство асинхронных движков используют несколько потоков, поэтому вам не нужно беспокоиться о количестве потоков. Не имея достаточного количества потоков во время синхронных рабочих нагрузок, можно серьезно ограничить общую потенциальную пропускную способность нагрузочного тестирования системы».

«Многопоточный» означает наличие нескольких потоков, выполняющих работу параллельно. Например, если у вас есть одно устройство, которое может обслуживать 1000 IOPS в синхронной рабочей нагрузке, это означает, что устройство имеет время отклика 1 мс без очереди (поэтому без очереди время обслуживания и время отклика должны быть синонимами). Очевидно, что устройства со временем отклика 1 мс могут выполнять гораздо больше работы, чем 1000 IOPS, и это достигается путем объединения нескольких потоков или параллельных потоков одной и той же рабочей нагрузки. Таким образом, если вы увеличите количество потоков (или «вещей, выполняющих эту конкретную задачу») до 10, у вас будет 10 отдельных потоков, выполняющих ввод-вывод на устройстве с частотой 1 мс. Каждый отдельный поток рабочей нагрузки по-прежнему получает 1 мс, что означает, что каждый поток по-прежнему достигает только 1000 IOPS, но теперь весь «процесс» или «задание», выполняемое этими несколькими потоками, получает 10 000 IOPS.

Существуют инструменты и рабочие нагрузки, которые могут адекватно справиться с ограничениями устройства с помощью одного потока, а некоторым требуется больше. Таким образом, при моделировании синхронной нагрузки необходимо иметь как можно больше потоков/воркеров/потоков, не влияя на общее время отклика. Наступает момент, когда увеличение количества потоков перестает оказывать положительное влияние (когда устройство становится занятым на 100%). Как правило, при асинхронных рабочих нагрузках счетчик потоков обрабатывается по умолчанию. Например, ниже вы все еще можете увидеть разницу между 1 потоком и 10 для асинхронной рабочей нагрузки, хотя и незначительную. Мораль этой истории заключается в том, что при асинхронных рабочих нагрузках вам не нужно так сильно беспокоиться о потоках. 

Один поток здесь может достичь 68 000 IOPS с помощью движка "libaio" (асинхронный). 

 

Если увеличить количество потоков (numjobs) до 10, количество операций ввода-вывода в секунду все равно увеличится.

 

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

отправить ввод-вывод-1, дождаться ACK, отправить ввод-вывод, дождаться ACK и т.д.

 И невозможность объединить несколько потоков для одной цели. 

job1=отправка ввода-вывода-1 - задание2=отправка ввода-вывода-1 - job3=отправка ввода-вывода-1..... job1=получить подтверждение, послать ввод-вывод-2 - job2=получить подтверждение, послать ввод-вывод-2 - job3= получить подтверждение, послать ввод-вывод-2 и т.д.

Флаг Direct

В некоторых инструментах, особенно в *nix на основе инструментов/ОС, вы можете увидеть опцию «Direct I/O». Его можно использовать с «асинхронными» модулями, и его не следует путать с «синхронным» вводом-выводом. В некоторых инструментах без этого флага можно записывать данные в кэш сервера, а не непосредственно на диск. Хост хочет обойти собственный кэш и записать данные непосредственно на диск. Это важный фактор при тестировании систем хранения. Когда у вас установлен флаг "direct", технически вы записываете данные на диск, хотя "disk" в данном случае на самом деле является кэшем хранилища. Это по-прежнему приемлемо для целей тестирования, так как даже при правильной рабочей нагрузке вы все равно моделируете и точно имитируете поведение этой рабочей нагрузки в реальной среде, поскольку производственная нагрузка также попадет в кэш перед отправкой подтверждения. (Не чувствуйте себя обманутым только потому, что вы используете показатели производительности кэша, а не только внутренних шпинделей.)

 

Пропускная способность (Мбайт/с) и пропускная способность (IOPS)

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

Пропускная способность (Мбайт/с) - Пропускная способность - это мера данных, которые вы можете разместить одновременно (или в пределах интервала X, обычно "в секунду") в канале или системе. Это означает, что он измеряет, какой объем данных вы перенесли за определенный период времени. Хотя пропускная способность и IOPS не являются взаимоисключающими, вы можете иметь более высокие или меньшие значения пропускной способности при одинаковом количестве IOPS, все зависит от размера блока. Помните, что вы не измеряете скорость с помощью пропускной способности, скорость — это нечто совершенно другое, и хотя она влияет на пропускную способность, обычно это то, что вы не можете контролировать при рабочих нагрузках с высокой пропускной способностью. Поэтому при тестировании пропускной способности всегда используйте блоки большего размера (в разумных пределах), чтобы объем данных на операции ввода-вывода был больше, чем при тестировании IOPS, так как обработка больших блоков, естественно, займет больше времени. Если, например, вы хотите достичь скорости 1 Мбайт/с, но используете блоки размером 8 Кбайт, для этого необходимо увеличить скорость около 125 операций ввода-вывода в секунду. Однако при использовании блоков по 512 Кбайт потребуется всего два (2) IOPS.
(Если вы сохраните 125 операций ввода-вывода в секунду и увеличите размер блока с 8 до 512 КБ, то получите 64 МБ/с!)

Однако, поскольку в одном вводе-выводе содержится больше данных, обычно требуется больше времени для «упаковки» этого ввода-вывода (поиск, связывание и т. д.). Поэтому, естественно, время обслуживания может быть выше. Иногда у вас меньшая очередь, поэтому время отклика, хотя и выше, должно быть довольно близким. Имейте в виду, что, хотя время отклика действительно играет роль в пропускной способности, увеличение объема данных на один ввод-вывод обычно перевешивает любое небольшое увеличение времени отклика (RT) для этого типа ввода-вывода. Поскольку время отклика выше, не хочется, чтобы рабочие нагрузки больших блоков были случайными. Таким образом, рабочие нагрузки пропускной способности, как правило, являются последовательными. Когда вы вводите случайный характер в рабочую нагрузку больших блоков, стабильная скорость передачи данных постоянно прерывается, и вы начинаете ощущать последствия немного более высокого времени отклика на один ввод-вывод.

Пропускная способность (IOPS). Отношение пропускной способности к числу IOPS является наиболее распространенным показателем для рабочих нагрузок малых блоков, особенно по мере того, как они становятся более случайными. Все, что превышает 32–64 КБ, можно считать большим блоком. Для пропускной способности вышеупомянутые факторы являются наиболее важными (например, количество потоков, синхронизация или асинхронность, глубина очереди и т. д.). Здесь вы пытаетесь измерить не то, сколько общих данных вы можете передать в течение интервала X, а скорее количество отдельных пакетов (запросов ввода-вывода), несущих эти данные, которые вы пытаетесь обслужить (каждый интервал x). Такие среды, как OLTP (банковская), мало заботятся о том, какой объем данных они могут передавать, поскольку их объем данных обычно невелик. Тем не менее, эти небольшие наборы данных могут быть заняты и, как правило, заняты. Эти наборы данных имеют большое смещение (на него ссылаются на небольшой объем пространства, но они варьируются агрессивно и последовательно). Небольшие пакеты данных обычно содержат только запросы на изменение/обновление блоков с числовыми или меньшими строковыми значениями, поэтому большие пакеты ввода-вывода не требуются. Тем не менее, из-за характера транзакций и из-за того, что их очень много, мы хотим убедиться, что мы можем идти в ногу с каждым отдельным спросом. Как правило, чем меньше размер блока, тем больше IOPS можно достичь в данном сценарии. Хотя рабочие нагрузки малых блоков в основном связаны с произвольным доступом, можно достичь еще большей пропускной способности при последовательных рабочих нагрузках с малыми блоками. Однако последовательные рабочие нагрузки с малыми блоками специфичны и встречаются не так часто, поэтому тестируйте эти сценарии только в том случае, если это требуется в вашей среде.