Для всіх контрольних показників, перерахованих вище, на випробувальному стенді були клієнти, як описано в таблиці 2 нижче. Оскільки кількість обчислювальних вузлів, доступних для тестування, становила лише 16, коли було потрібно більше потоків, ці потоки були рівномірно розподілені на обчислювальних вузлах (тобто 32 потоки = 2 потоки на вузол, 64 потоки = 4 потоки на вузол, 128 потоків = 8 потоків на вузол, 256 потоків = 16 потоків на вузол, 512 потоків = 32 потоки на вузол, 1024 потоки = 64 нитки на вузол). Намір полягав у тому, щоб змоделювати більшу кількість одночасних клієнтів при обмеженій кількості доступних обчислювальних вузлів. Оскільки деякі бенчмарки підтримують велику кількість потоків, використовувалося максимальне значення до 1024 (вказується для кожного тесту), уникаючи надмірного перемикання контексту та інших пов'язаних побічних ефектів, що впливають на результати продуктивності.

Таблиця 2 Випробувальний стенд клієнта

Послідовна продуктивність IOzone: N клієнтів до N файлів

Продуктивність послідовних N клієнтів до N файлів була виміряна за допомогою версії IOzone 3.487. Виконувані тести варіювалися від одного потоку до 1024 потоків з кроком степенів у два.

Ефекти кешування на серверах були зведені до мінімуму завдяки встановленню пулу сторінок GPFS на 16 Гібіт і використанню файлів, більших за вдвічі більший за розмір. Важливо відзначити, що для GPFS, що налаштовується, встановлюється максимальний обсяг пам'яті, що використовується для кешування даних, незалежно від обсягу встановленої та вільної оперативної пам'яті. Крім того, важливо зазначити, що в той час як у попередніх рішеннях DellEMC HPC розмір блоку для великих послідовних передач становив 1 МіБ, GPFS форматувалася з 8 МіБ блоками, і тому це значення використовується в тесті для оптимальної продуктивності. Це може виглядати занадто великим і, очевидно, витрачати занадто багато місця, але GPFS використовує розподіл субблоків, щоб запобігти такій ситуації. У поточній конфігурації кожен блок був розділений на 256 підблоків по 32 КіБ кожен.

Наступні команди були використані для виконання тесту для запису та читання, де $Threads була змінною з кількістю використаних потоків (від 1 до 1024 з інкрементом у степенях двох), а список потоків був файлом, який виділяв кожен потік на іншому вузлі, використовуючи кругову систему для однорідного розподілу їх між 16 обчислювальними вузлами.

Щоб уникнути будь-яких можливих ефектів кешування даних від клієнтів, загальний розмір даних файлів був удвічі більшим, ніж загальний обсяг оперативної пам'яті в використовуваних клієнтах. Тобто, оскільки кожен клієнт має 128 ГіБ оперативної пам'яті, для кількості потоків, що дорівнює або перевищує 16 потоків, розмір файлу становив 4096 ГіБ, поділений на кількість потоків (для керування цим значенням використовувалася змінна $Size нижче). У тих випадках, коли містилося менше 16 потоків (що означає, що кожен потік виконувався на різних клієнтах), розмір файлу був зафіксований на рівні вдвічі більшого обсягу пам'яті на клієнт, або 256 ГіБ.

iozone -i0 -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./threadlist
iozone -i1 -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./threadlist

Рисунок 2: Послідовне виконання від N до N

З результатів ми можемо спостерігати, що продуктивність запису зростає зі збільшенням кількості використаних потоків, а потім досягає плато приблизно 64 потоки для запису та 128 потоків для читання. Потім продуктивність читання також швидко зростає зі збільшенням кількості потоків, а потім залишається стабільною до досягнення максимальної кількості потоків, дозволених IOzone, і, отже, продуктивність великих послідовних файлів стабільна навіть для 1024 одночасних клієнтів. Продуктивність запису падає приблизно на 10% при 1024 потоках. Однак, оскільки клієнтський кластер має менше цієї кількості ядер, невідомо, чи падіння продуктивності пов'язане зі свопом і подібними накладними витратами, які не спостерігаються на обертових носіях (оскільки затримка NVMe дуже низька в порівнянні з обертовими носіями), або ж синхронізація даних RAID 10 стає вузьким місцем. Щоб уточнити цей момент, потрібно більше клієнтів. Аномалія зчитування спостерігалася на 64 потоках, де продуктивність не масштабувалася з тією швидкістю, яка спостерігалася для попередніх точок даних, а потім на наступній точці даних переходить до значення, дуже близького до стійкої продуктивності. Щоб знайти причину такої аномалії, потрібні додаткові тестування, але це виходить за рамки цього блогу.

Максимальна продуктивність зчитування для зчитування була нижчою за теоретичну продуктивність пристроїв NVMe (~102 ГБ/с) або продуктивність EDR-каналів, навіть якщо припустити, що один канал в основному використовувався для NVMe через тканинний трафік (4x EDR BW ~96 ГБ/с).
Втім, це не дивно, оскільки апаратна конфігурація не збалансована щодо пристроїв NVMe та IB HCA під кожним процесорним роз'ємом. Один адаптер CX6 знаходиться під CPU1, тоді як CPU2 має всі пристрої NVMe і другі адаптери CX6. Будь-який трафік зберігання даних, що використовує перший HCA, повинен використовувати UPI для доступу до пристроїв NVMe. Крім того, будь-яке ядро в CPU1, що використовується, повинно звертатися до пристроїв або пам'яті, призначеної CPU2, тому локальність даних страждає, і використовуються UPI-зв'язки. Це може пояснити зниження максимальної продуктивності в порівнянні з максимальною продуктивністю пристроїв NVMe або швидкістю лінії для CX6 HCA. Альтернативою для вирішення цього обмеження є збалансована апаратна конфігурація, яка передбачає зменшення щільності вдвічі за рахунок використання R740 з чотирма слотами x16 і використання двох розширювачів x16 PCIe для рівномірного розподілу пристроїв NVMe на двох процесорах і наявності одного CX6 HCA під кожним процесором.

Послідовний IOR Performance N клієнтів до 1 файлу

Продуктивність послідовних N клієнтів до одного спільного файлу була виміряна за допомогою IOR версії 3.3.0 за допомогою OpenMPI v4.0.1 для запуску тесту на 16 обчислювальних вузлах. Виконувані тести варіювалися від одного потоку до 512 потоків, оскільки ядер не вистачало на 1024 і більше потоків. У цьому бенчмарк-тесті використовувалися 8 блоків МіБ для оптимальної продуктивності. Попередній розділ тестування продуктивності містить більш повне пояснення, чому це важливо.

Ефекти кешування даних були зведені до мінімуму завдяки встановленню пулу сторінок GPFS з можливістю налаштування на 16 Гб, а загальний розмір файлу вдвічі перевищував загальний обсяг оперативної пам'яті у використовуваних клієнтах. Тобто, оскільки кожен клієнт має 128 ГіБ оперативної пам'яті, для кількості потоків, що дорівнює або перевищує 16 потоків, розмір файлу становив 4096 ГіБ, і рівна сума цієї суми була розділена на кількість потоків (для керування цим значенням використовувалася змінна $Size нижче). У тих випадках, коли було менше 16 потоків (що означає, що кожен потік виконувався на різних клієнтах), розмір файлу вдвічі перевищував обсяг пам'яті на одного клієнта, помноженого на кількість потоків, або, іншими словами, кожен потік просив використовувати 256 ГіБ.

Наступні команди були використані для виконання тесту для запису та читання, де $Threads була змінною з кількістю використаних потоків (від 1 до 1024 з кроком у степенях двох), а my_hosts.$Threads — це відповідний файл, який розподіляв кожен потік на іншому вузлі, використовуючи кругову систему для їх однорідного розподілу між 16 обчислювальними вузлами.

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -w -s 1 -t 8m -b $ G

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -r -s 1 -t 8m -b $ G

Рисунок 3 N до 1 Послідовне виконання

З результатів ми можемо спостерігати, що продуктивність читання та запису висока, незалежно від неявної потреби в механізмах блокування, оскільки всі потоки звертаються до одного файлу. Продуктивність знову зростає дуже швидко зі збільшенням кількості використовуваних потоків, а потім досягає плато, яке є відносно стабільним для читання та запису аж до максимальної кількості потоків, використаних у цьому тесті. Зверніть увагу, що максимальна продуктивність зчитування становила 51,6 ГБ/с при 512 потоках, але плато в продуктивності досягається приблизно на рівні 64 потоків. Аналогічно, зверніть увагу, що максимальна продуктивність запису 34,5 ГБ/с була досягнута при 16 потоках і досягла плато, яке можна спостерігати до максимальної кількості використаних потоків.

Випадкові маленькі блоки IOzone Performance N клієнтів до N файлів

Продуктивність випадкових N клієнтів до N файлів була виміряна за допомогою версії IOzone 3.487. Виконувані тести варіювалися від одного потоку до 1024 потоків з кроком степенів у два.

Виконувані тести варіювалися від одного потоку до 512 потоків, оскільки не вистачало клієнт-ядер на 1024 потоки. Кожен потік використовував окремий файл, і потоки призначалися за круговою системою на вузлах клієнта. У цьому бенчмарк-тесті використовувалися 4 блоки KiB для емуляції трафіку невеликих блоків і з використанням глибини черги 16. Порівнюються результати від рішення для великих розмірів і розширення потужності.

Ефекти кешування знову були зведені до мінімуму завдяки встановленню настроюваного пулу сторінок GPFS на 16 Гб, а щоб уникнути будь-яких можливих ефектів кешування даних від клієнтів, загальний розмір даних файлів був удвічі більшим, ніж загальний обсяг оперативної пам'яті у використовуваних клієнтах. Тобто, оскільки кожен клієнт має 128 ГіБ оперативної пам'яті, для кількості потоків рівної або понад 16 потоків розмір файлу становив 4096 ГіБ, поділений на кількість потоків (для керування цим значенням використовувалася змінна $Size нижче). У тих випадках, коли містилося менше 16 потоків (що означає, що кожен потік виконувався на різних клієнтах), розмір файлу був зафіксований на рівні вдвічі більшого обсягу пам'яті на клієнт, або 256 ГіБ.

iozone -i0 -I -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./nvme_threadlist <= Створюйте файли послідовно
iozone -i2 -I -c -O -w -r 4k -s G -t $Threads -+n -+m ./nvme_threadlist <= Виконуйте випадкові читання та записи.

Рисунок 4 Від N до N Випадкова продуктивність

З результатів ми можемо спостерігати, що продуктивність запису починається з високого значення 6K IOps і неухильно зростає до 1024 потоків, де, здається, досягається плато з більш ніж 5M IOPS, якщо можна використовувати більше потоків. З іншого боку, продуктивність зчитування починається з 5K IOPS і неухильно зростає з кількістю використаних потоків (майте на увазі, що кількість потоків подвоюється для кожної точки даних) і досягає максимальної продуктивності 7,3 Мб IOPS при 1024 потоках без ознак досягнення плато. Використання більшої кількості потоків вимагатиме більше, ніж 16 обчислювальних вузлів, щоб уникнути нестачі ресурсів і надмірного обміну, який може знизити видиму продуктивність, де вузли NVMe фактично могли б підтримувати продуктивність.

Продуктивність метаданих за допомогою MDtest з використанням 4 KiB файлів

Продуктивність метаданих була виміряна за допомогою MDtest версії 3.3.0, за допомогою OpenMPI v4.0.1 для запуску тесту на 16 обчислювальних вузлах. Виконувані тести варіювалися від одного потоку до 512 потоків. Бенчмарк використовувався лише для файлів (без метаданих каталогів), отримуючи кількість створень, статистику, читання та видалення, з якими може впоратися рішення, а результати контрастували з рішенням великого розміру.

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

Оскільки той самий модуль High Demand Metadata використовувався для попереднього бенчмаркінгу рішення DellEMC Ready Solution for HPC PixStor Storage, результати метаданих будуть дуже схожими порівняно з попередніми результатами блогу. З цієї причини дослідження з порожніми файлами не проводилося, а замість цього було використано 4 KiB-файли. Оскільки файли 4KiB не можуть поміститися в індексний дескриптор разом з інформацією про метадані, вузли NVMe будуть використовуватися для зберігання даних для кожного файлу. Таким чином, MDtest може дати приблизне уявлення про продуктивність невеликих файлів для читання та інших операцій з метаданими.

Для виконання тесту була використана наступна команда, де $Threads — змінна з кількістю використаних потоків (від 1 до 512 з кроком степенів двох), а my_hosts.$Threads — це відповідний файл , який розподіляв кожен потік на іншому вузлі, використовуючи кругову систему для однорідного розподілу їх між 16 обчислювальними вузлами. Подібно до бенчмарку Random IO, максимальна кількість потоків була обмежена 512, оскільки ядер не вистачає для 1024 потоків і перемикання контексту вплинуло б на результати, повідомляючи про число нижче, ніж реальна продуктивність рішення.

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefix /mmfs1/perftest/ompi --mca btl_openib_allow_ib 1 /mmfs1/perftest/lanl_ior/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F -w 4K -e 4K

Оскільки на результати продуктивності може впливати загальна кількість IOPS, кількість файлів на каталог і кількість потоків, було вирішено залишити фіксованою загальну кількість файлів до 2 файлів MiB (2^21 = 2097152), кількість файлів на каталог зафіксована на рівні 1024, а кількість каталогів змінювалася зі зміною кількості потоків, як показано в таблиці 3.

Таблиця 3 MDtest розподіл файлів по каталогах

Рисунок 5: Продуктивність метаданих – 4 файли KiB

По-перше, зверніть увагу, що обрана шкала була логарифмічною з основою 10, щоб дозволити порівнювати операції, які мають відмінності з декількома порядками; В іншому випадку деякі операції виглядали б як плоска лінія, близька до 0 в лінійному масштабі. Логарифмічний графік з основою 2 міг би бути більш відповідним, оскільки кількість потоків збільшується в степенях 2, але графік виглядав би дуже схожим, і люди схильні обробляти та запам'ятовувати кращі числа на основі степенів 10.

Система отримує дуже хороші результати, як повідомлялося раніше, операції Stat досягають пікового значення на 64 потоки з майже 6,9 млн операцій/с, а потім зменшуються для більшої кількості потоків, досягаючи плато. Операції створення досягають максимуму в 113 Кб операцій/с при 512 потоках, тому очікується, що вони продовжать зростати, якщо використовується більше клієнтських вузлів (і ядер). Операції читання та видалення досягли свого максимуму в 128 потоків, досягнувши свого піку майже в 705 тисяч операцій/с для читання та 370 тисяч операцій/с для видалень, а потім вони досягли плато. Операції зі статистикою мають більшу варіативність, але як тільки вони досягають свого пікового значення, продуктивність не падає нижче 3,2 млн операцій/с для статистики. Створення та Видалення стають більш стабільними, як тільки вони досягають плато та залишаються вище 265 Кб операцій/с для Видалення та 113 Кбайт операцій/с для Створення. Нарешті, читання досягають плато з продуктивністю вище 265 тис.

Висновки і подальша робота

Вузли NVMe є важливим доповненням до рішення для зберігання даних HPC, оскільки забезпечують дуже високопродуктивний рівень, з хорошою щільністю, дуже високою продуктивністю довільного доступу та дуже високою послідовною продуктивністю. Крім того, рішення лінійно масштабується за ємністю та продуктивністю в міру додавання більшої кількості модулів вузлів NVMe. Продуктивність вузлів NVMe можна розглянути в таблиці 4, очікується, що вона буде стабільною, і ці значення можуть бути використані для оцінки продуктивності для різної кількості вузлів NVMe.
Однак майте на увазі, що кожна пара вузлів NVMe забезпечить половину будь-якого числа, показаного в таблиці 4.
Це рішення надає клієнтам HPC дуже надійну паралельну файлову систему, яка використовується багатьма кластерами Top 500 HPC. Крім того, він надає виняткові можливості пошуку, розширений моніторинг і управління, а додавання додаткових шлюзів дозволяє обмінюватися файлами через всюдисущі стандартні протоколи, такі як NFS, SMB та інші, для будь-якої кількості клієнтів, скільки потрібно.

Таблиця 4: Пікова та стійка продуктивність для 2 пар вузлів NVMe

Оскільки вузли NVMe використовувалися лише для даних, можлива майбутня робота може включати їх використання для даних та метаданих і мати автономний рівень на основі флеш-пам'яті з кращою продуктивністю метаданих завдяки вищій пропускній здатності та меншій затримці пристроїв NVMe порівняно з SSD SAS3 за контролерами RAID. З іншого боку, якщо клієнт має надзвичайно високі вимоги до метаданих і вимагає рішення більш щільного, ніж те, що може забезпечити модуль метаданих високого попиту, деякі або всі розподілені пристрої RAID 10 можуть використовуватися для метаданих так само, як зараз використовуються пристрої RAID 1 на ME4024s.
Ще один блог, який незабаром вийде у світ, буде характеризувати вузли PixStor Gateway, які дозволяють підключати рішення PixStor до інших мереж за допомогою протоколів NFS або SMB і можуть масштабувати продуктивність. Крім того, дуже скоро рішення буде оновлено до HDR100, і очікується, що про цю роботу розповість ще один блог.