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

Стаття написана Маріо Гальєгосом з HPC та AI Innovation Lab у жовтні 2019 року

Зміст

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

Введення

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

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

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

•     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 потоків. 
  Ефекти кешування були зведені до мінімуму завдяки встановленню пулу сторінок GPFS з можливістю налаштування на 16 ГБ і використанню файлів, більших за вдвічі більший за розмір. Важливо відзначити, що для GPFS, що налаштовується, встановлюється максимальний обсяг пам'яті, що використовується для кешування даних, незалежно від обсягу встановленої та вільної оперативної пам'яті. Крім того, важливо відзначити, що в той час як у попередніх рішеннях Dell EMC 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 одночасних клієнтів. Зверніть увагу, що максимальна продуктивність читання становила 23 ГБ/с при 32 потоках, і, швидше за все, вузьким місцем був інтерфейс InfiniBand EDR, тоді як масиви ME4 все ще мали додаткову продуктивність. Так само зауважте, що максимальна продуктивність запису 16.7 була досягнута трохи раніше при 16 потоках, і вона, очевидно, низька в порівнянні зі специфікаціями масивів ME4.
  Тут важливо пам'ятати, що бажаний режим роботи GPFS – це розсіяний, і рішення було відформатоване для його використання. У цьому режимі блоки розподіляються з самого початку псевдовипадковим чином, розподіляючи дані по всій поверхні кожного жорсткого диска. Хоча очевидним недоліком є менша початкова максимальна продуктивність, ця продуктивність залишається досить постійною незалежно від того, скільки місця використовується у файловій системі. Це на відміну від інших паралельних файлових систем, які спочатку використовують зовнішні доріжки, які можуть вмістити більше даних (секторів) за оберт диска, і, отже, мають максимально можливу продуктивність, яку можуть забезпечити жорсткі диски, але оскільки система використовує більше місця, використовуються внутрішні доріжки з меншою кількістю даних за оберт, що призводить до зниження продуктивності. 
  
   

  ---

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

  Продуктивність послідовних N клієнтів до одного спільного файлу була виміряна за допомогою IOR версії 3.3.0 за допомогою OpenMPI v4.0.1 для запуску тесту на 16 обчислювальних вузлах. Виконані тести варіювалися від одного потоку до 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 З результатів ми можемо побачити, що продуктивність знову зростає дуже швидко з кількістю використовуваних клієнтів, а потім досягає плато, яке є напівстабільним для читання і дуже стабільним для записів аж до максимальної кількості потоків, що використовуються в цьому тесті. Таким чином, послідовна продуктивність великих спільних файлів стабільна навіть для 1024 одночасних клієнтів. Зверніть увагу, що максимальна продуктивність читання становила 23,7 ГБ/с при 16 потоках, і, швидше за все, вузьким місцем був інтерфейс InfiniBand EDR, тоді як масиви ME4 все ще мали деяку додаткову продуктивність. Крім того, продуктивність читання знизилася від цього значення до досягнення плато на позначці 20,5 ГБ/с, з миттєвим зниженням до 18,5 ГБ/с при 128 потоках. Аналогічно, зверніть увагу, що максимальна продуктивність запису 16.5 була досягнута при 16 потоках, і вона, очевидно, низька в порівнянні зі специфікаціями масивів ME4.
   

  ---

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

  Продуктивність випадкових N клієнтів до N файлів була виміряна за допомогою IOzone версії 3.487. Виконані тести варіювалися від одного потоку до 1024 потоків. У цьому бенчмарк-тесті використовувалися 4 блоки KiB для емуляції трафіку невеликих блоків.
  Ефекти кешування були зведені до мінімуму завдяки встановленню пулу сторінок GPFS з можливістю налаштування на 16 Гбіт і використанню файлів вдвічі більшого розміру. Перший розділ тестування продуктивності містить більш повне пояснення того, чому це ефективно на GPFS. 
  Наступна команда була використана для виконання тесту у випадковому режимі вводу-виводу як для запису, так і для читання, де Threads була змінною з кількістю використаних потоків (від 1 до 1024 збільшено в степенях двох), а threadlist був файлом, який виділяв кожен потік на іншому вузлі, використовуючи кругову систему для рівномірного розподілу їх між 16 обчислювальними вузлами.

  ./iozone -i2 -c -o -w -r 4K -s 32G -t $Threads -+n -+m ./threadlist

  
  Малюнок 4:  Випадкова продуктивність
  
  від N до N З результатів ми можемо помітити, що продуктивність запису починається з високого значення майже 8,2 K IOPS і неухильно зростає до 128 потоків, де вона досягає плато і залишається близькою до максимального значення 16,2 K IOP. З іншого боку, продуктивність зчитування починається з дуже маленької з понад 200 IOPS і збільшує продуктивність майже лінійно з кількістю використовуваних клієнтів (майте на увазі, що кількість потоків подвоюється для кожної точки даних) і досягає максимальної продуктивності 20,4K IOPS при 512 потоках без ознак досягнення максимуму. Однак, використання більшої кількості потоків на поточних 16 обчислювальних вузлах з двома процесорами в кожному і де кожен процесор має 18 ядер, має обмеження, яке полягає в тому, що ядер недостатньо для виконання максимальної кількості потоків IOzone (1024) без перемикання контексту (16 x 2 x 18 = 576 ядер), що значно обмежує продуктивність. Майбутній тест з більшою кількістю обчислювальних вузлів може перевірити, якої випадкової продуктивності читання можна досягти за допомогою 1024 потоків з IOzone, або IOR може бути використаний для дослідження поведінки з більш ніж 1024 потоками.
  
   

  ---

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

  Продуктивність метаданих була виміряна за допомогою MDtest версії 3.3.0 за допомогою OpenMPI v4.0.1 для запуску тесту на 16 обчислювальних вузлах. Виконані тести варіювалися від одного потоку до 512 потоків. Бенчмарк використовувався лише для файлів (без метаданих каталогів), отримуючи кількість створень, статистику, читання та видалення, з якими може впоратися рішення.
  Щоб правильно оцінити рішення в порівнянні з іншими рішеннями для зберігання даних Dell EMC 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.
  
  
  Система отримує дуже хороші результати, коли операції Stat і Read досягають свого пікового значення при 64 потоках з 11,2 Мб операцій / с і 4,8 М операцій / с відповідно. Операції видалення досягли максимуму 169,4 Кбайт операцій/с при 16 потоках, а операції Create досягли свого піку в 512 потоків при 194,2 Кбайт операцій/с. Операції статистики та читання мають більшу варіативність, але як тільки вони досягають свого пікового значення, продуктивність не падає нижче 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)
  
  Система отримує дуже хороші результати для операцій статистики та видалення, досягаючи свого пікового значення при 128 потоках з 7,7 Мб операцій/с та 1 М операцій/с відповідно. Операції видалення досягли максимуму 37,3 тис./с, а операції Create досягли свого піку з 55,5 тис./с, обидва при 512 потоках. Операції статистики та видалення мають більшу варіативність, але як тільки вони досягають свого пікового значення, продуктивність не опускається нижче 4 млн операцій/с для статистики та 200 тис. операцій/с для видалення. Create і Read мають меншу варіативність і продовжують збільшуватися зі зростанням кількості потоків.
  Оскільки ці числа наведені для модуля метаданих з одним ME4024, продуктивність буде збільшуватися для кожного додаткового масиву ME4024, однак ми не можемо просто припустити лінійне збільшення для кожної операції. Якщо весь файл не вміщується в індексний дескриптор для такого файлу, для зберігання файлів 4K будуть використовуватися цілі даних на ME4084s, що певною мірою обмежує продуктивність. Оскільки розмір індексного дескриптора становить 4 КіБ, і він все ще потребує зберігання метаданих, всередину помістяться лише файли, розміром близько 3 КіБ, а будь-який файл, більший за це, використовуватиме цілі даних.
   

  ---

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

  Цей тест майже повністю ідентичний попереднім, за винятком того, що використовувалися невеликі файли розміром 3КіБ. Основна відмінність полягає в тому, що ці файли повністю поміщаються всередині inode. Тому вузли зберігання даних та їх ME4084 не використовуються, що підвищує загальну швидкість за рахунок використання лише SSD-носіїв для зберігання та меншої кількості доступів до мережі. 
  Наступна команда була використана для виконання тесту, де 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 3K -e 3K

   

  
  Малюнок 7: Продуктивність метаданих - невеликі файли (3K)
  
  Система отримує дуже хороші результати для операцій статистики та читання, досягаючи свого пікового значення при 256 потоках з 8,29 млн операцій/с та 5,06 млн операцій/с відповідно. Операції видалення досягли максимуму 609 Кбайт операцій/с при 128 потоках, а операції Create досягли свого піку з 78 Кбайт операцій/с при 512 потоках. Операції статистики та читання мають більшу варіативність, ніж операції створення та видалення. Видалення має невелике падіння продуктивності для двох точок вищих потоків, що свідчить про те, що стійка продуктивність після 128 потоків становитиме трохи більше 400 тисяч операцій/с. Кількість створень продовжувала збільшуватися до 512 потоків, але, схоже, досягає плато, тому максимальна продуктивність все ще може бути нижче 100 Кбайт операцій/с.
  Оскільки такі невеликі файли повністю зберігаються в модулі метаданих на основі SSD, програми, що вимагають високої продуктивності малих файлів, можуть використовувати один або кілька додаткових модулів метаданих високого попиту для підвищення продуктивності малих файлів. Однак файли, які вміщуються в inode, за сучасними стандартами крихітні. Крім того, оскільки цілі метаданих використовують RAID1 з відносно невеликими SSD (максимальний розмір становить 19,2 ТБ), ємність буде обмежена порівняно з вузлами зберігання. Тому слід бути обережним, щоб уникнути заповнення цілей метаданих, що може спричинити непотрібні збої та інші проблеми.
   

  ---

  Розширена аналітика

  Серед можливостей PixStor моніторинг файлової системи за допомогою розширеної аналітики може бути важливим для значного спрощення адміністрування, допомагаючи проактивно або реактивно знаходити проблеми чи потенційні проблеми. Далі ми коротко розглянемо деякі з цих можливостей.
  На рисунку 8 показана корисна інформація на основі ємності файлової системи. Ліворуч показано загальний обсяг використаного простору файлової системи та десятку найкращих користувачів за обсягом використаної файлової системи. З правого боку — історичний перегляд із місткістю, що використовується протягом багатьох років, потім десять найпопулярніших типів файлів і десять найкращих наборів файлів, обидва на основі використаної ємності, у форматі, подібному до діаграм Парето (без рядків для кумулятивних підсумків). Маючи цю інформацію, можна легко знайти користувачів, які отримують більше, ніж належить, частку файлової системи, тенденції використання ємності для прийняття рішень щодо майбутнього зростання ємності, які файли займають більшу частину простору або які проекти займають більшу частину ємності.
  
  
  Малюнок 8:  PixStor Analytics - Перегляд
  
  потужностей На рисунку 9 представлено перегляд кількості файлів з двома дуже корисними способами пошуку проблем. У першій половині екрана показано першу десятку користувачів на круговій діаграмі, а також десять найкращих типів файлів і десять найкращих наборів файлів (наприклад, проєкти) у форматі, подібному до діаграм Парето (без рядків для кумулятивних підсумків), усі на основі кількості файлів. Ця інформація може бути використана для відповіді на деякі важливі питання. Наприклад, які користувачі монополізують файлову систему, створюючи занадто багато файлів, який тип файлу створює кошмар метаданих або які проекти використовують більшу частину ресурсів.
  У нижній частині розташовано гістограму з кількістю файлів (частотою) для розмірів файлів, використовуючи 5 категорій для різних розмірів файлів. Цим можна скористатися, щоб отримати уявлення про розміри файлів, які використовуються у файловій системі, які можна використовувати відповідно до типів файлів, щоб вирішити, чи буде стискання корисним.
  
  
  Малюнок 9:  PixStor Analytics - Перегляд кількості файлів

  
  
   

  ---

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

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

  	Максимальна продуктивність		Стабільна продуктивність
  	Написати	Читати	Написати	Читати
  Великі послідовні N клієнтів до N файлів	16,7 ГБ/с	23 ГБІТ/с	16,5 ГБ/с	20,5 ГБ/с
  Великі послідовні N клієнтів до одного спільного файлу	16,5 ГБ/с	23,8 ГБ/с	16,2 ГБ/с	20,5 ГБ/с
  Випадкові малі блоки N клієнтів до N файлів	15,8 кіло-сі	20,4 кіло-секундних операцій	15,7 кіло-секундних операцій	20,4 кіло-секундних операцій
  Метадані Створення порожніх файлів	169,4 тис.		127,2 тис.
  Метадані Статистика порожніх файлів	11,2 МБ IOps		3,3 млн IOps
  Метадані Читання порожніх файлів	4,8 млн IOps		2,4 млн IOps
  Метадані Вилучити порожні файли	194,2 тис.		144,8 тис.
  Метадані Створення файлів 4KiB	55,4 тис.		55,4 тис.
  Метадані Статистика файлів 4KiB	6,4 млн IOps		4 млн входів-виходів
  Метадані Читання файлів 4KiB	37,3 тис.		37,3 тис.
  Метадані Вилучити файли 4KiB	1 млн IOps		219,5 тис входів-виходів

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

  ---