PowerEdge: Масштабованість готових рішень Dell для зберігання HPC BeeGFS

Зміст

1. Введення
2. Базові конфігурації
3. Розрахунок корисного простору BeeGFS
4. Масштабовані конфігурації
5. Характеристика продуктивності
6. Висновок і подальша робота
    

Введення

У цьому блозі обговорюється масштабованість Dell Ready Solutions для зберігання HPC BeeGFS , про яку було нещодавно оголошено. Архітектура BeeGFS складається з чотирьох основних сервісів: служби управління, служби метаданих, служби зберігання даних і клієнтського сервісу. Можна запустити будь-яку комбінацію цих чотирьох основних сервісів, включаючи їх усі, на одному сервері, оскільки у випадку з BeeGFS ролі та апаратне забезпечення не тісно інтегровані. У «гіперконвергентному рішенні» всі чотири служби працюють на одному сервері. Ця конфігурація не рекомендується для середовищ, критичних до продуктивності, оскільки клієнтські програми зазвичай споживають ресурси, що може вплинути на продуктивність служб зберігання. Рішення Dell використовує виділені сервери зберігання даних і сервер метаданих і зберігання подвійного призначення, щоб забезпечити високопродуктивне масштабоване рішення для зберігання даних. Є можливість масштабувати систему шляхом додавання додаткових серверів зберігання даних до існуючої системи. У цьому блозі ми представляємо конфігурації з різною кількістю серверів зберігання даних і продуктивність, яку можна очікувати від цих конфігурацій.

Базові конфігурації

Рішення для зберігання даних BeeGFS, призначене для забезпечення високопродуктивної файлової системи Scratch, використовує наступні апаратні компоненти:

• Сервер керування
  • R640, два пристрої Intel Xeon Gold 5218 2,3 ГГц, 16 ядер, 96 ГБ (12 x 8 ГБ RDIMM, 2666 МТ/с), 6 x 15 об/хв, 300 ГБ SAS, H740P
• Сервери метаданих і зберігання
  • R740xd, 2x Intel Xeon Platinum 8268 CPU @ 2.90 ГГц, 24 ядра, 384 ГБ (12x 32 ГБ 2933 MT/s RDIMM)
  • BOSS карта з 2 твердотільними накопичувачами M.2 SATA на 240 ГБ у RAID 1 для ОС
  • 24x, Intel 1,6 ТБ, NVMe, багатофункціональний Express Flash, 2,5 SFF диски, програмний RAID

На сервері управління працює служба моніторингу BeeGFS. Сервер метаданих використовує 12 дисків у зоні NUMA 0 для розміщення цільових метаданих (MDT), тоді як решта 12 дисків у зоні NUMA 1 розміщують цілі зберігання (ST). Виділений сервер метаданих не використовується, оскільки вимоги до ємності сховища для метаданих BeeGFS невеликі. Метадані та цілі зберігання та сервіси ізольовані на окремих вузлах NUMA, що дозволяє встановити значний розподіл робочих навантажень. Сервери зберігання даних, використані в конфігурації, мають три служби зберігання даних, запущені на кожну зону NUMA, всього шість на сервер. Детальніше дивіться у блозі анонсу. На малюнку 1 показані дві базові конфігурації, які були протестовані та підтверджені в лабораторії Dell EMC, HPC та AI Innovation Lab.

Малюнок 1: Базові конфігурації

Невелика конфігурація складається з трьох серверів R740xd. Він має 15 цілей для зберігання. Середня конфігурація має сервери 6xR740xd і має 33 цілі зберігання даних. Користувач може почати з «Маленької» конфігурації або з «Середньої» конфігурації та може додавати сховище або сервери метаданих, якщо це необхідно, щоб збільшити простір для зберігання та загальну продуктивність, або продуктивність кількості файлів та метаданих, відповідно. У таблиці 1 наведено дані про продуктивність базових конфігурацій, які були протестовані та ретельно перевірені в Dell HPC та AI Innovation Lab.

Таблиця 1: Деталі: місткість і продуктивність базових конфігурацій

Розрахунок корисного простору BeeGFS

Приблизний корисний простір розраховується в TiB (оскільки більшість інструментів показують корисний простір у двійкових одиницях) за такою формулою:

BeeGFS Usable Space in TiB= (0.99* # of Drives* size in TB * (10^12/2^40)

У наведеній вище формулі 0,99 є коефіцієнтом, до якого можна прийти шляхом консервативного припущення, що накладні витрати файлової системи становлять 1%. Для підходу до числа накопичувачів для зберігання також включено 12 дисків від MDS. Це пов'язано з тим, що в MDS 12 дисків у зоні NUMA 0 використовуються для метаданих, а 12 дисків у зоні NUMA 1 використовуються для зберігання даних. Останнім фактором у формулі 10^12/2^40 є перетворення корисного простору з TB в TiB.

Масштабовані конфігурації

Рішення для високопродуктивного зберігання даних BeeGFS розроблено таким чином, щоб бути гнучким, і можна легко та безперешкодно масштабувати продуктивність та/або ємність, додаючи додаткові сервери, як показано нижче:

Малюнок 2: Приклади масштабованих конфігурацій 

Частина метаданих стека залишається незмінною для всіх вищезазначених конфігурацій, описаних у цьому блозі. Це пов'язано з тим, що вимоги до місткості сховища для метаданих BeeGFS зазвичай становлять від 0,5% до 1% від загальної ємності сховища. Однак насправді це залежить від кількості каталогів і файлів у файловій системі. Як правило, користувач може додати додатковий сервер метаданих, коли відсоток місткості метаданих у сховищі падає нижче 1%. У таблиці 2 наведені дані про продуктивність для різних гнучких конфігурацій рішення для зберігання даних BeeGFS.

 

Таблиця 2: Місткість і деталі продуктивності масштабованих конфігурацій

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

Працездатність різних конфігурацій була перевірена шляхом створення пулів зберігання. Невелика конфігурація має 15 цілей зберігання, і кожен додатковий сервер зберігання додає додаткові шість цілей зберігання. Так, з метою перевірки продуктивності різних конфігурацій, були створені пули зберігання від 15 до 39 цілей зберігання (крок шість для малого, малого+1, малого+2, середнього+1, середнього+1). Для кожного з цих пулів було запущено три ітерації бенчмарку IOzone, кожна з яких мала від одного до 1024 потоків (у степенях з двома кроками). Прийнята методика тестування така ж, як і описана в блозі анонсів . На малюнках 3 і 4 показана продуктивність запису і читання масштабованих конфігурацій відповідно, з виділенням пікової продуктивності кожної з конфігурацій для довідки:


 
Малюнок 3:  Продуктивність запису масштабованих конфігурацій.


Малюнок 4:  Читання продуктивності масштабованих конфігурацій.

Примітка:

Згаданий пул зберігання був створений лише з явною метою охарактеризувати продуктивність різних конфігурацій. Під час проведення оцінки продуктивності середньої конфігурації, детально описаної в блозі анонсів, усі 33 цілі були лише в «Пулі за замовчуванням». Вихід файлу beegfs-ctl --liststoragepools Наведена нижче команда показує призначення цілей зберігання:

# beegfs-ctl --liststoragepools
Pool ID   Pool Description                      Targets                 Buddy Groups
======= ================== ============================ ============================
1       Default             1,2,3,4,5,6,7,8,9,10,11,12,                                                                                                                              
                            13,14,15,16,17,18,19,20,21,                                                                                                                              
                            22,23,24,25,26,27,28,29,30,                                                                                                                              
                            31,32,33

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

У цьому блозі обговорювалася масштабованість Dell Ready Solutions для зберігання HPC BeeGFS і підкреслювалася продуктивність для послідовного читання та запису пропускної здатності для різних конфігурацій. Слідкуйте за оновленнями до Частини 3 цієї серії блогів, в якій обговорюватимуться додаткові функції BeeGFS та висвітлюватиметься використання "StorageBench", еталону вбудованих сховищ BeeGFS. У рамках наступних кроків ми пізніше опублікуємо офіційний документ із характеристиками метаданих, оцінкою продуктивності IOR N-1 та додатковими подробицями щодо міркувань дизайну, налаштування та конфігурації. 

Посилання

[1] Готові рішення Dell для зберігання HPC BeeGFS:  
https://www.dell.com/support/article/sln319381/[2] Документація BeeGFS: 
https://www.beegfs.io/wiki/[3] Як підключити два інтерфейси в одній підмережі: 
https://access.redhat.com/solutions/30564[4] Еталонна конструкція прямого доступу до пам'яті PCI Express із використанням зовнішньої пам'яті: https://www.intel.com/content/www/us/en/programmable/documentation/nik1412547570040.html#nik1412547565760