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

Як масштабувати рішення Dell BeeGFS High Performance Storage Solution з точки зору ємності або продуктивності, або і того, і іншого?

Дивіться інформацію в розділі Резолюція.

Зміст

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

---

Введення

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

---

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

Рішення BeeGFS Storage Solution, призначене для забезпечення високопродуктивної файлової системи 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 @ 2,90 ГГц, 24 ядра, 384 ГБ (12x 32 ГБ 2933 МТ/с RDIMM)
  • BOSS-карта з 2 твердотільними накопичувачами M.2 SATA по 240 ГБ у RAID 1 для ОС
  • 24x, Intel 1.6 ТБ, NVMe, експрес-пам'ять змішаного використання, 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 EMC HPC та AI Innovation Lab.

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

 

---

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

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

Корисний простір BeeGFS в TiB= (0.99* # дисків* розмір в ТБ * (10^12/2^40)

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

---

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

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

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

 

---

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

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


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


Рисунок 4 :  Прочитайте Продуктивність масштабованих конфігурацій

Примітка:

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

# beegfs-ctl --liststoragepools
Ідентифікатор пулу Опис пулу націлений на групи
друзів======= ================== ============================ ============================
1 Типове значення 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 EMC Ready Solutions для HPC BeeGFS Storage і підкреслювалася продуктивність для послідовного читання та запису пропускної здатності для різних конфігурацій. Слідкуйте за оновленнями до Частини 3 цієї серії блогів, в якій обговорюватимуться додаткові можливості BeeGFS та висвітлюватиметься використання "StorageBench", тесту вбудованих цілей зберігання даних BeeGFS. У рамках наступних кроків ми опублікуємо офіційний документ із характеристиками метаданих, оцінкою продуктивності IOR N-1 та додатковими подробицями щодо міркувань дизайну, налаштування та конфігурації. 

Посилання

[1] Готові рішення Dell EMC для зберігання 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