PowerStore: Ефективні методи оцінки продуктивності масиву зберігання

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

• Тестуйте за допомогою змінних, які нагадують реальне навантаження/середовище. Пам'ятайте, що більшість інструментів — це симулятори, і вони ніколи не досягають 100% справжнього виробничого навантаження.
• Якщо навантаження дуже різноманітне, розгляньте можливість виконання кількох ітерацій тестів читання/запису з різними розмірами блоків і патернами доступу.
• Використовуйте багатопотокові та асинхронні операції або тести для забезпечення паралельної або паралельної продуктивності та забезпечення загальних потенціалів пропускної здатності. 
• Розгляньте та перегляньте галузеві стандарти для обладнання, яке оцінюється, відповідно до виробничого навантаження вашого бізнесу.
• Уникайте тестування з порожнею або малозавантаженою файловою системою та/або томами. Якщо ви не виділяєте місце на робочих навантаженнях Write, можна побачити затримку через миттєве виділення місця під час тесту.
• Не забудьте протестувати Read I/O, оскільки це зазвичай домінуючий з двох у більшості середовищ. Звертайте увагу на втрати пакетів/кадрів у мережевій інфраструктурі під час тестування.
• Переконайтеся, що ви тестуєте на кількох пристроях, щоб змоделювати типове середовище з багатьма хостами або клієнтами. Наприклад, у PowerStore хороша кількість — 16 томів. Кількість обсягів зазвичай відповідає кількості хостів або клієнтів, які використовуються (фізичні чи віртуальні); Саме тут досягається спільність.

 

Інструменти бенчмаркінгу та симулятори
Майте на увазі, що більшість інструментів — це симулятори і, ймовірно, ніколи не змоделюють 100% справжнього виробничого навантаження. Ці інструменти бенчмаркінгу використовуються для отримання уявлення про те, якою продуктивністю може бути, повинна або має бути в певних ситуаціях. Dell не володіє цими інструментами і не несе відповідальності за будь-які проблеми чи проблеми, пов'язані з ними.

У будь-якій ситуації тестування продуктивності переконайтеся, що використовуються інструменти з асинхронними та багатопотоковими можливостями. Прикладами таких інструментів:

• Гнучкий тестер введення/виведення (FIO)
• IOmeter
• Vdbench (потрібен обліковий запис Oracle)
• NFSometer (Тільки Fedora/NFS)
• Контрольний список продуктивності NAS від Intel

 

Уникайте таких типів тестів:

• Копіюй і вставляй
• Перетягування і скидання
• Резервне копіювання однієї файлової системи на диск
• Тести DD
• Rlarge
• Ларж
• Mkfile
• Розстібка, витягування та стиснення

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

 

 

IODepth (глибина черги)
Низька глибина входу (або недостатньо висока) може обмежити вашу потенційну пропускну здатність залежно від ситуації. Тому завжди перевіряйте, що глибина сполучення сполучення достатньо велика, щоб відобразити або імітувати вимоги паралелізації робочого навантаження. IOdepth, який занадто низький, може неправильно використовувати пристрій на повну потужність. Також будьте обережні з надто високою глибиною IO, це може спричинити значну чергу на пристрої, і залежно від часу обслуговування може бути більший час реакції. Це може відображати те, як може виглядати перевантажена система.

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

» IOdepth=1" це приблизно ~30 000 вхідних і вихідних операцій за секунду (IOPS) у середньому для тесту.

 

"IOdepth=64" — це приблизно ~107 000 IOPS у середньому для тесту.

 

 

"IOdepth=256" — це близько ~142 000 IOPS у середньому для тесту.

 

 

Як уже згадувалося, продуктивність у більшості конфігурацій вирівнюється на певній глибині IO. Тут глибина черги становить 512, і лише невелике збільшення IOPS з IOdepth 64.

» IOdepth = 512" — це приблизно ~146 000 IOPS у середньому для тесту.

 

 


Async проти Sync
Використовуються два основні різні двигуни. Найпопулярнішими і безперечно найефективнішими з точки зору продуктивності є «асинхронний ввод/вивод». Менш ефективним і менш продуктивним типом двигуна є синхронний I/O, який зазвичай використовується у застосунках із суворими вимогами до цілісності та забезпечення даних. Синхронний ввод/вивід також можна знайти в майже нульових технологіях реплікації Recovery Point Objective (RPO). У тестуванні продуктивності та бенчмаркінгу, з точки зору хоста, асинхронний означає, що підтвердження для одного I/O не потрібне для запиту наступного I/O. У синхронних робочих навантаженнях потрібне підтвердження для введення/виводу перед наступним і підтвердження (ACK) для кожного наступного запитаного введення/виведення. Тому синхронний I/O зазвичай має чергу 1 або менше і ніколи не використовує ресурс повною мірою. Поєднання синхронних операцій з малою або однією кількістю потоків може суттєво обмежити потенціал продуктивності, тому завжди перевіряйте, що ви проводите асинхронне тестування, а якщо використовуєте синхронне тестування — обов'язково використовуйте кілька потоків, якщо середовище додатку явно не вказує на це

.Async (Libaio - Linux native async) = 1 поток



Синхронізація (синхронний I/O):  

 

 

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

» Багатопотоковий» означає кілька потоків, які працюють паралельно. Наприклад, якщо у вас є один пристрій, який може обслуговувати 1000 IOPS у синхронному робочому навантаженні, це означає, що пристрій має 1 мс часу відповіді без черги (тобто без черги час обслуговування та час відгуку мають бути синонімами). Очевидно, що пристрої з часом відгуку 1 мс можуть виконувати набагато більше роботи, ніж 1000 IOPS, і це досягається шляхом накладання кількох потоків або паралельних потоків однакового навантаження. Отже, якщо збільшити кількість потоків (або «пристрої, що виконують цю конкретну роботу») до 10, то у вас буде 10 окремих потоків, які здійснюють ввод/вивід на пристрій на 1 мс. Кожен окремий потік робочого навантаження все ще отримує 1 мс, тобто кожен потік досі досягає лише 1000 IOPS, але тепер весь «процес» або «робота», який виконується цими кількома потоками, отримує 10 000 IOPS.

Існують інструменти та робочі навантаження, які можуть адекватно досягти меж пристрою одним потоком, і деякі потребують більшого. Підсумовуючи, при симуляції синхронного навантаження потрібно мати якомога більше потоків/працівників/потоків, не впливаючи на загальний час відповіді. Є момент, коли збільшення кількості ниток перестає мати позитивний ефект (коли пристрій стає повністю завантаженим). Загалом, при асинхронних навантаженнях кількість потоків відповідає за замовчуванням. Наприклад, нижче ви все ще можете побачити різницю між 1 потоком і 10 для асинхронного навантаження, хоча й не суттєвою. Мораль цієї історії полягає в тому, що при асинхронних навантаженнях не варто так сильно турбуватися про нитки. 

Один потік тут може досягти 68 000 IOPS за допомогою «libaio» (асинхронного) движка. 

 

Якщо збільшити кількість потоків (numjobs) до 10, можна побачити збільшення IOPS.

 

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

відправити I/O-1, чекати на ACK, відправити I/O-2, чекати на ACK і так далі

 І неможливість накладати кілька потоків для однієї мети. 

job1=відправити I/O-1 - job2=відправити I/O-1 - job3=відправити I/O-1..... job1=отримати ack, надіслати I/O-2 - job2=отримати ack, відправити I/O-2 - job3=отримати ack, надіслати I/O-2 і так далі

Прямий прапор

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

 

Пропускна здатність (MB/s) проти пропускної здатності (IOPS)

Є дві основні точки зору, які можна перевірити. Пропускна здатність у світі мереж і продуктивності зазвичай стосується передачі даних, однак у SAN/блочному середовищі зазвичай використовують «пропускну здатність» для представлення IOPS. Тому спочатку потрібно зрозуміти характеристики навантаження, які ви тестуєте.

Пропускна здатність (MB/s) — це міра даних, які можна вмістити одночасно (або в межах інтервалу X зазвичай «за секунду») у трубу або систему. Це означає, що він вимірює, скільки даних ви передали за певний період часу. Хоча пропускна здатність і IOPS не є взаємовиключними, при однаковій кількості IOPS можуть бути вищі або нижчі показники, все залежить від розміру блоку. Пам'ятайте, ви не вимірюєте швидкість через пропускну здатність, швидкість зовсім інша, і хоча це впливає на пропускну здатність, зазвичай це те, що неможливо контролювати при великих навантаженнях. Тому, якщо ви тестуєте пропускну здатність, завжди використовуйте більші блоки (у розумних межах), щоб ваші дані на кожен I/O були більшими, ніж при тестуванні на IOPS, адже більші блоки природно обробляють більше часу. Якщо, наприклад, ви хочете досягти 1 МБ/с, але використовуєте блоки по 8 КБ, потрібно використати близько 125 IOPS, щоб це досягти. Однак, якщо ви використовуєте блоки по 512 КБ, то потрібно лише два (2) IOPS.
(Якщо ви залишите 125 IOPS і все одно збільшите розмір блоку з 8 КБ до 512 КБ, це вже буде 64 МБ/с!)

Однак, оскільки в одному введенні/виведенні більше даних, зазвичай потрібно більше часу на «пакування» (пошук, поєднання тощо). Тому терміни служби можуть природно бути довшими. Іноді черга менша, тому час відповіді, хоч і більший, має бути досить близьким. Майте на увазі, що хоча час відгуку впливає на те, скільки пропускної здатності ви можете досягти, збільшення обсягу даних на один I/O зазвичай переважає будь-яке незначне збільшення часу відповіді (RT) для такого типу I/O. Оскільки час відгуку вищий, не хочеться, щоб навантаження на великі блоки були випадковими. Отже, навантаження на пропускну здатність зазвичай є послідовними. Коли ви вводите випадковий характер у велике блочне навантаження, ваша стабільна швидкість передачі даних постійно переривається, і ви починаєте відчувати наслідки трохи більшого часу відгуку на кожен I/O.

Пропускна здатність (IOPS) — Пропускна здатність/IOPS є найпоширенішим аспектом для навантажень малих блоків, особливо коли вони стають більш випадковими. Все, що перевищує 32 КБ-64 КБ, можна вважати великим блоком. Щодо пропускної здатності, найважливішими є згадані вище фактори (наприклад, кількість потоків, синхронізація, асинхронність, глибина черги тощо). Тут ви намагаєтеся виміряти не всю кількість даних за інтервал X, а скільки окремих пакетів (запитів на введення/виведення), які містять ці дані, які ви намагаєтеся обслуговувати (кожен інтервал X). Середовища на кшталт OLTP (банкінг) мало переймаються тим, скільки даних вони можуть передавати, оскільки їхній обсяг даних зазвичай невеликий. Однак ці невеликі набори даних можуть бути зайняті і зазвичай є зайнятими. Ці набори даних мають великий зсув (посилається на невеликий простір, але він змінюється агресивно і послідовно). Малі пакети даних зазвичай містять лише запити на зміну/оновлення блоків числовими або меншими рядковими значеннями, тому великі пакети введення/виведення не потрібні. Однак через характер транзакцій і їх велику кількість ми хочемо переконатися, що можемо задовольнити кожен окремий попит. Зазвичай, чим менший розмір блоку, тим більше IOPS можна досягти в конкретному сценарії, і хоча невеликі робочі навантаження здебільшого пов'язані з випадковим доступом, ще більшу пропускну здатність можна досягти при малих послідовних блокових навантаженнях. Однак послідовні навантаження з малими блоками є специфічними і не такими поширеними, тому тестуйте ці сценарії лише якщо це вимагає ваше середовище.