Готове рішення Dell EMC для зберігання HPC PixStor – розширення ємності

Ніхто

Зміст

1. Введення
   1. Архітектура рішення
   2. Компоненти розчину
2. Характеристика продуктивності
   1. Послідовна продуктивність IOzone N клієнтів до N файлів
   2. Послідовний IOR Performance N клієнтів до 1 файлу
   3. Випадкові маленькі блоки IOzone Performance N клієнтів до N файлів
   4. Продуктивність метаданих за допомогою MDtest з використанням порожніх файлів
   5. Продуктивність метаданих за допомогою MDtest з використанням 4 файлів KiB
3. Висновки і подальша робота

 

---

Введення

Сучасні середовища HPC висувають підвищені вимоги до дуже високошвидкісного сховища, яке також часто вимагає великої ємності та розподіленого доступу через кілька стандартних протоколів, таких як NFS, SMB та інші. Ці високі вимоги до HPC зазвичай покриваються паралельними файловими системами, які забезпечують одночасний доступ до одного файлу або набору файлів з кількох вузлів, дуже ефективно та безпечно розподіляючи дані між кількома LUN на кількох серверах.

 

---

Архітектура рішення

Цей блог є продовженням рішення Parallel File System (PFS) для середовищ HPC, DellEMC Ready Solution for HPC PixStor Storage, де масиви PowerVault ME484 EBOD використовуються для збільшення ємності рішення. Малюнок 1 представлена еталонна архітектура, що зображує розширення ємності SAS до існуючих масивів зберігання даних PowerVault ME4084.
Рішення PixStor включає широко поширену загальну паралельну файлову систему, також відому як Spectrum Scale як компонент PFS, на додаток до багатьох інших програмних компонентів Arcastream, таких як розширена аналітика, спрощене адміністрування та моніторинг, ефективний пошук файлів, розширені можливості шлюзу та багато інших.


Малюнок 1: Еталонна архітектура.

 

---

Компоненти розчину

Це рішення планується випускати з новітніми процесорами Intel Xeon 2-го покоління Scalable Xeon, також відомими як процесори Cascade Lake, і деякі з серверів будуть використовувати найшвидшу доступну їм оперативну пам'ять (2933 МТ/с). Однак, у зв'язку з поточним апаратним забезпеченням, доступним для роботи над прототипом рішення для характеристики продуктивності, сервери з процесорами Intel Xeon 1-го покоління Scalable Xeon, також відомими як Для характеристики цієї системи використовувалися процесори Skylake, а в деяких випадках і більш повільна оперативна пам'ять. Оскільки вузьке місце рішення знаходиться в контролерах SAS масивів DellEMC PowerVault ME40x4, не очікується значної різниці в продуктивності після заміни процесорів і оперативної пам'яті Skylake на передбачені процесори Cascade Lake і швидшу оперативну пам'ять. Крім того, рішення було оновлено до останньої версії PixStor (5.1.1.4), яка підтримує RHEL 7.7 та OFED 4.7 для характеристики системи.

У зв'язку з описаною раніше ситуацією в таблиці 1 є перелік основних компонентів для рішення, але коли були виявлені розбіжності, перший стовпець опису містить компоненти, які використовувалися на момент випуску і, отже, доступні для клієнтів, а останній стовпець - компоненти, фактично використані для характеристики продуктивності рішення. Диски, перелічені для даних (12 ТБ NLS) і метаданих (SSD 960 ГБ), використовуються для характеристики продуктивності, а швидші диски можуть забезпечити кращі випадкові IOP і можуть покращити операції створення/видалення метаданих.

Нарешті, для повноти картини був включений список можливих жорстких дисків для даних і твердотільних накопичувачів-метаданих, який базується на підтримуваних накопичувачах, перелічених на матриці підтримки DellEMC PowerVault ME4, доступній в Інтернеті.

Таблиця 1 Компоненти, що використовуються під час випуску, і компоненти, що використовуються на випробувальному стенді

Компонент рішення		На момент випуску	Випробувальний стенд
Внутрішнє підключення		Dell Networking S3048-ON Gigabit Ethernet
Підсистема зберігання даних		Від 1x до 4x Dell EMC PowerVault ME4084 Від 1x до 4x Dell EMC PowerVault ME484 (по одному на ME4084) 80–12 ТБ 3,5-дюймові жорсткі диски NL SAS3 Опції 900 ГБ @15K, 1,2 ТБ @10K, 1,8 ТБ @10K, 2,4 ТБ @10K, 4 ТБ NLS, 8 ТБ NLS, 10 ТБ NLS, 12 ТБ NLS.     8 ЛУН, лінійний 8+2 RAID 6, розмір фрагмента 512КіБ. 4 твердотільні накопичувачі SAS3 ємністю 1,92 ТБ для метаданих – 2 RAID 1 (або 4 – глобальні жорсткі диски, якщо використовується додатковий модуль метаданих високого попиту)
Додаткова підсистема зберігання метаданих з високим попитом		Від 1x до 2x Dell EMC PowerVault ME4024 (4x ME4024, якщо потрібно, лише велика конфігурація) 24-кратний SSD-накопичувач SAS3 об'ємом 960 ГБ 2.5" (опції 480 ГБ, 960 ГБ, 1,92 ТБ) 12 ЛУН, лінійний RAID 1.
Контролери сховищ RAID		SAS 12 Гбіт/с
Ємність відповідно до налаштувань		Сировина: 8064 ТБ (7334 TiB або 7,16 PiB) у форматі ~ 6144 ГБ (5588 TiB або 5,46 PiB)
Процесор	Шлюз	2x Intel Xeon Gold 6230 2.1G, 20C/40T, 10,4 ГТ/с, 27,5 МБ кеш-пам'яті, турбо, HT (125 Вт) DDR4-2933	Н/Д
	Метадані високого попиту		2x Intel Xeon Gold 6136 @ 3.0 ГГц, 12 ядер
	Вузол зберігання		2x Intel Xeon Gold 6136 @ 3.0 ГГц, 12 ядер
	Вузол управління	2x Intel Xeon Gold 5220 2.2G, 18C/36T, 10.4GT/s, 24.75 МБ кеш-пам'яті, турбо, HT (125 Вт) DDR4-2666	2x Intel Xeon Gold 5118 @ 2.30 ГГц, 12 ядер
Пам'ять	Шлюз	12x 16 ГБ, 2933 МТ/с RDIMM (192 ГБ)	Н/Д
	Метадані високого попиту		24x 16 Гб, 2666 МТ/с RDIMM (384 ГБ)
	Вузол зберігання		24x 16 Гб, 2666 МТ/с RDIMM (384 ГБ)
	Вузол управління	12 модулів DIMM по 16 ГБ, 2666 МТ/с (192 ГБ)	12x 8 ГБ, 2666 МТ/с RDIMM (96 ГБ)
Операційна система		Red Hat Enterprise Linux 7.6	Red Hat Enterprise Linux 7.7
Версія ядра		3.10.0-957.12.2.el7.x86_64	3.10.0-1062.9.1.el7.x86_64
Програмне забезпечення PixStor		5.1.0.0	5.1.1.4
Шкала спектру (GPFS)		5.0.3	5.0.4-2
Високопродуктивне підключення до мережі		Mellanox ConnectX-5 з двома портами InfiniBand EDR/100 GbE та 10 GbE	Mellanox ConnectX-5 InfiniBand EDR
Високопродуктивний перемикач		2x Mellanox SB7800 (HA – резервний)	1x Mellanox SB7700
Версія OFED		Мелланокс ОФЕД-4,6-1,0,1.0	Мелланокс ОФЕД-4,7-3,2,9
Локальні диски (ОС та аналіз/моніторинг)		Всі сервери, крім вузла управління 3x 480 ГБ SSD SAS3 (RAID1 + HS) для ОС RAID-контролер PERC H730P Вузол управління 3x 480 ГБ SSD SAS3 (RAID1 + HS) для ОС RAID-контролер PERC H740P	Всі сервери, крім вузла управління 2x 300 ГБ 15K SAS3 (RAID 1) для ОС RAID-контролер PERC H330 Вузол управління 5x 300 ГБ 15K SAS3 (RAID 5) для ОС та аналізу/моніторингу RAID-контролер PERC H740P
Управління системами		iDRAC 9 Enterprise + DellEMC OpenManage	iDRAC 9 Enterprise + DellEMC OpenManage

 

---

Характеристика продуктивності

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

• IOзона від N до N послідовна
• IOR N до 1 послідовно
• IOзона випадкова
• MDtest

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

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

Кількість клієнтських вузлів	16
Клієнтський вузол	С6320
Процесори на вузол клієнта	2 x Intel(R) Xeon(R) Gold E5-2697v4 18 ядер @ 2.30 ГГц
Пам'ять на вузол клієнта	12 x 16 ГБ, 2400 МТ/с RDIMM
BIOS	2.8.0
Ядро ОС	3.10.0-957.10.1
Версія GPFS	5.0.3

 

---

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

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

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

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

Малюнок 2:  Послідовне виконання


від N до NЗ результатів ми можемо спостерігати, що продуктивність дуже швидко зростає зі збільшенням кількості використовуваних клієнтів, а потім досягає стабільного плато, поки не буде досягнуто максимальної кількості потоків, дозволених IOzone, і, отже, послідовна продуктивність великих файлів стабільна навіть для 1024 одночасних клієнтів. Зверніть увагу, що продуктивність читання та запису виграла від подвоєння кількості дисків. Максимальна продуктивність зчитування була обмежена пропускною здатністю двох каналів IB EDR, що використовуються на вузлах зберігання, починаючи з 8 потоків, і масиви ME4 можуть мати деяку додаткову продуктивність. Так само зверніть увагу, що максимальна продуктивність запису зросла з максимальних 16,7 до 20,4 ГБ/с при 64 і 128 потоках, і це ближче до максимальних характеристик масивів ME4 (22 ГБ/с).

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

 

---

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

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

Наступні команди були використані для виконання тесту для записів і читань, де 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 128G 

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 128G

Малюнок 3: Від N до 1 Послідовна продуктивність

З результатів ми знову можемо помітити, що додаткові диски підвищують продуктивність читання та запису. Продуктивність знову зростає дуже швидко зі збільшенням кількості використовуваних клієнтів, а потім досягає плато, яке є досить стабільним для читання та запису аж до максимальної кількості потоків, що використовуються в цьому тесті. Зверніть увагу, що максимальна продуктивність читання становила 24,8 ГБ/с при 16 потоках, а вузьким місцем був інтерфейс InfiniBand EDR, при цьому масиви ME4 все ще мали деяку додаткову продуктивність. З цього моменту продуктивність читання знизилася від цього значення до досягнення плато на позначці 23,8 ГБ/с. Аналогічно, зверніть увагу, що максимальна продуктивність запису 19.3 була досягнута при 8 потоках і досягла плато.
 

---

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

Продуктивність випадкових N клієнтів до N файлів вимірювалася за допомогою FIO версії 3.7 замість традиційного Iozone. Намір, як зазначено в попередньому блозі, полягав у тому, щоб скористатися більшою глибиною черги, щоб дослідити максимально можливу продуктивність, яку можуть забезпечити масиви ME4084 (попередні тести для різних рішень ME4 показали, що масиви ME4084 потребують більшого тиску вводу-виводу, який може забезпечити Iozone, щоб досягти своїх випадкових меж вводу-виводу).

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

Ефекти кешування знову були зведені до мінімуму завдяки встановленню пулу сторінок GPFS з можливістю налаштування на 16 Гбіт і використанню файлів, які вдвічі більші за розміром. Перший розділ тестування продуктивності містить більш повне пояснення того, чому це ефективно на GPFS.

 
Малюнок 4:  Випадкова продуктивність від N до N З результатів ми можемо побачити, що продуктивність

запису починається з високого значення 29,1 Кбайт IOps і неухильно зростає до 64 потоків, де, здається, вона досягає плато на позначці близько 40 тисяч IOps. З іншого боку, продуктивність зчитування починається з 1,4 Кбайт входів і збільшує продуктивність майже лінійно з кількістю використовуваних клієнтів (майте на увазі, що кількість потоків подвоюється для кожної точки даних) і досягає максимальної продуктивності 25,6 К IOPS при 64 потоках, де, здається, близько до досягнення плато. Використання більшої кількості потоків вимагатиме більше, ніж 16 обчислювальних вузлів, щоб уникнути нестачі ресурсів і нижчої видимої продуктивності, де масиви могли б фактично підтримувати продуктивність.

 

---

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

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

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

Наступна команда була використана для виконання тесту, де 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

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

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

Кількість ниток	Кількість каталогів у потоці	Загальна кількість файлів
1	2048	2,097,152
2	1024	2,097,152
4	512	2,097,152
8	256	2,097,152
16	128	2,097,152
32	64	2,097,152
64	32	2,097,152
128	16	2,097,152
256	8	2,097,152
512	4	2,097,152
1024	2	2,097,152

Малюнок 5: Продуктивність метаданих - порожні файли

По-перше, зверніть увагу, що обрана шкала була логарифмічною з основою 10, щоб дозволити порівнювати операції, які мають різницю в кілька порядків; В іншому випадку деякі операції виглядали б як плоска лінія, близька до 0 на нормальному графіку. Логарифмічний графік з основою 2 може бути більш доречним, оскільки кількість потоків збільшується в степенях 2, але графік буде виглядати дуже схожим, і люди, як правило, обробляють і запам'ятовують кращі числа на основі степенів 10.
Система отримує дуже хороші результати: операції статистики та читання досягають свого пікового значення при 64 потоках з майже 11 млн операцій/с та 4,7 млн операцій/с відповідно. Операції видалення досягли максимуму 170,6 Кбайт операцій/с при 16 потоках, а операції Create досягли свого піку в 32 потоки з 222,1 Кбайт операцій/с. Операції статистики та читання мають більшу варіативність, але як тільки вони досягають свого пікового значення, продуктивність не падає нижче 3 млн операцій/с для статистики та 2 млн операцій/с для читання. Створення та видалення стають більш стабільними, коли вони досягають плато, і залишаються вище 140 Кб операцій/с для Видалення та 120 Кбайт операцій/с для Створення. Зауважте, що додаткові диски не дуже впливають на більшість операцій з метаданими з порожніми файлами, як і очікувалося.
 

---

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

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

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

Малюнок 6:  Продуктивність метаданих – невеликі файли (4K)

Система отримує дуже хороші результати для операцій статистики та видалення, досягаючи свого пікового значення при 256 потоках з 8,2 Мб операцій/с та 400 Кбайт операцій/с відповідно. Операції зчитування досягли максимуму 44,8 тис./с, а операції Create досягли свого піку з 68,1 тис./с, обидва при 512 потоках. Операції статистики та видалення мають більшу варіативність, але як тільки вони досягають свого пікового значення, продуктивність не опускається нижче 3 млн операцій/с для статистики та 280 тис. операцій/с для видалення. Create і Read мають меншу варіативність і продовжують збільшуватися зі зростанням кількості потоків. Як можна помітити, додаткові диски розширення ємності забезпечують лише незначні зміни у швидкодії метаданих.
Оскільки ці числа вказані для модуля метаданих з одним ME4024, продуктивність буде збільшуватися для кожного додаткового масиву ME4024, однак ми не можемо просто припустити лінійне збільшення для кожної операції. Якщо весь файл не вміщується в індексний дескриптор для такого файлу, для зберігання файлів 4K будуть використовуватися цілі даних на ME4084s, що певною мірою обмежує продуктивність. Оскільки розмір індексного дескриптора становить 4 КіБ, і він все ще потребує зберігання метаданих, лише файли розміром близько 3 КіБ помістяться всередині, а будь-який файл, більший за це, використовуватиме цілі даних.
 

---

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

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

Таблиця 4  Максимальна та стійка продуктивність

	Максимальна продуктивність		Стабільна продуктивність
	Написати	Читати	Написати	Читати
Великі послідовні N клієнтів до N файлів	20,4 ГБ/с	24,2 ГБ/с	20,3 ГБ/с	24 ГБІТ/с
Великі послідовні N клієнтів до одного спільного файлу	19,3 ГБ/с	24,8 ГБ/с	19,3 ГБ/с	23,8 ГБ/с
Випадкові малі блоки N клієнтів до N файлів	40 кіло-секундних операцій	25,6 кіло-піксів	40,0 кіло-активних секунд	19.3KIOps
Метадані Створення порожніх файлів	169,4 тис.		123,5 тис.
Метадані Статистика порожніх файлів	11 МЛН IOps		3,2 млн IOps
Метадані Читання порожніх файлів	4,7 млн IOps		2,4 млн IOps
Метадані Вилучити порожні файли	170,6 тис.		156,5 тис входів-виходів
Метадані Створення файлів 4KiB	68,1 тис.		68,1 тис.
Метадані Статистика файлів 4KiB	8,2 млн входів/с		3 млн входів
Метадані Читання файлів 4KiB	44,8 тис входів-виходів		44,8 тис входів-виходів
Метадані Вилучити файли 4KiB	400 тис.		280 тис.

Оскільки рішення планується випустити з процесорами Cascade Lake і швидшою оперативною пам'яттю, після того, як система отримає остаточну конфігурацію, буде проведено деякі вибіркові перевірки продуктивності. І протестуйте додатковий модуль метаданих високого попиту з принаймні 2 файлами ME4024 і 4 КіБ, щоб краще задокументувати, як продуктивність метаданих масштабується, коли йдеться про цільові дані даних. Крім того, продуктивність вузлів шлюзу буде вимірюватися та повідомлятися разом із будь-якими відповідними результатами вибіркових перевірок у новому блозі або білій книзі. Нарешті, планується протестувати та випустити більше компонентів рішення, щоб забезпечити ще більше можливостей.