PowerEdge: Готові рішення Dell для високопродуктивних сховищ HPC BeeGFS

Стаття написана Нірмалою Сундарараджан з Dell HPC та AI Innovation Lab у листопаді 2019 року

Зміст

1. Введення
2. Еталонна архітектура рішення
3. Конфігурація апаратного та програмного забезпечення
4. Деталі конфігурації рішення
   • Послуга управління
   • Сервіс метаданих
   • Сервіс зберігання
   • Обслуговування клієнтів
5. R740xd, 24 диски NVMe, подробиці про відображення процесора
6. Характеристика продуктивності
   • Послідовне читання і запис N-N
   • Випадкове читання і запис Н-Н
7. Висновок і подальша робота
    

Введення

Команда Dell HPC з гордістю оголошує про випуск «Dell EMC Ready Solutions for HPC BeeGFS Storage», який є останнім доповненням до портфоліо сховищ HPC. Це рішення використовує сервери R740xd, кожен з яких має 24 флеш-накопичувачі Intel P4600 1.6TB NVMe, Mixed-Use Express Flash та два адаптери Mellanox ConnectX-5 InfiniBand EDR. У цій конфігурації з 24 NVMe-накопичувачами 12 твердотільних накопичувачів NVMe підключаються до комутатора PCIe, і кожен комутатор підключається до одного процесора за допомогою карти розширювача x16 PCIe. При цьому кожен інтерфейс IB підключений до одного центрального процесора. Така збалансована конфігурація з підключенням кожного CPU до одного адаптера InfiniBand і роботою з 12 NVMe SSD забезпечує максимальну продуктивність, гарантуючи, що процесори однаково зайняті обробкою запитів введення-виведення на диски NVMe і з них.

Основна увага в рішенні приділяється високопродуктивному вводу/виводу, і воно було розроблено як високошвидкісне рішення для видалення подряпин. В основі рішення лежить використання високошвидкісних твердотільних накопичувачів NVMe, які пропонують високу пропускну здатність і низьку затримку за рахунок видалення планувальника і вузьких місць в черзі з блокового шару. Файлова система BeeGFS також підтримує високу сукупну пропускну здатність вводу/виводу.

Еталонна архітектура рішення

На рисунку 1 показана еталонна архітектура рішення. Сервер керування підключено лише за допомогою Ethernet до серверів метаданих і зберігання даних. Кожен сервер метаданих і зберігання даних мають два канали InfiniBand і підключені до приватної мережі через Ethernet. Клієнти мають один канал InfiniBand і підключені до приватного інтерфейсу через Ethernet.

Малюнок 1:  Готові рішення Dell для зберігання даних HPC BeeGFS - еталонна архітектура

Конфігурація апаратного та програмного забезпечення

У таблицях 1 і 2 описано технічні характеристики апаратного забезпечення сервера керування та сервера метаданих/сховища відповідно. У таблиці 3 описано версії програмного забезпечення, які використовуються для рішення.

Деталі конфігурації рішення

Архітектура BeeGFS складається з чотирьох основних сервісів:

• Послуга управління
• Сервіс метаданих
• Сервіс зберігання
• Обслуговування клієнтів

За винятком клієнтської служби, яка є модулем ядра, служби керування, метаданих та зберігання є процесами простору користувача. На малюнку 2 показано, як еталонна архітектура Dell EMC Ready Solutions for HPC BeeGFS Storage відображається із загальною архітектурою файлової системи BeeGFS.

Малюнок 2:  Файлова система BeeGFS на PowerEdge R740xd з твердотільними накопичувачами NVMe

Послуга управління

Кожна файлова система або простір імен BeeGFS має лише одну службу керування. Служба керування – це перша служба, яку потрібно налаштувати, оскільки коли ми налаштовуємо всі інші служби, вони повинні зареєструватися в службі керування. В якості сервера управління використовується PowerEdge R640. Крім хостингу сервісу управління (beegfs-mgmtd.service), на ньому також розміщується служба моніторингу (beegfs-mon.service), яка збирає статистичні дані з системи і надає її користувачеві, використовуючи базу даних часових рядів InfluxDB. Для візуалізації даних beegfs-mon надає попередньо визначені панелі Grafana, які можна використовувати з коробки. Сервер управління має 6 жорстких дисків по 300 ГБ, налаштованих в RAID 10 для операційної системи та InfluxDB.

Сервіс метаданих

Сервіс метаданих є масштабованим сервісом, що означає, що у файловій системі BeeGFS може бути багато служб метаданих. Однак кожен сервіс метаданих має лише одну ціль метаданих для зберігання метаданих. Для цілі метаданих BeeGFS створює один файл метаданих на кожен файл, створений користувачем. Метадані BeeGFS розподіляються на основі кожного каталогу. Сервіс метаданих надає клієнтам інформацію про чергування даних і не бере участі в доступі до даних між відкриттям і закриттям файлів.

Для зберігання метаданих використовуються накопичувачі PowerEdge R740xd з 24 дисками Intel P4600 1.6TB NVMe. Оскільки вимоги до ємності сховища для метаданих BeeGFS дуже малі, замість використання виділеного сервера метаданих лише 12 дисків у зоні NUMA 0 використовувалися для розміщення Tаргетів метаданих (MDT), тоді як решта 12 дисків на хостів зони NUMA Storage Targets (STs).

На рисунку 3 показаний сервер метаданих. 12 дисків, укладених у жовтий прямокутник, є MDT у зоні NUMA 0, тоді як 12 дисків, укладених у зелений прямокутник, є STs у зоні NUMA 1. Ця конфігурація не тільки дозволяє уникнути проблем з NUMA, але й забезпечує достатнє сховище метаданих для полегшення масштабування ємності та продуктивності за потреби.

Малюнок 3:  Сервер

метаданих На малюнку 4 показана конфігурація RAID сервера метаданих. У ньому показано, як на сервері метаданих диски в зоні NUMA 0 розміщують MDT, а диски в зоні NUMA 1 — дані зберігання, тоді як сервери зберігання розміщують STs в обох зонах NUMA.

Малюнок 4:  Конфігурація дисків у сервері

метаданих 12 дисків, які використовуються для метаданих, налаштовані як 6 дисків RAID 1 група з двох дисків, кожен з яких виконує функцію MDT. Існує шість служб метаданих, кожна з яких обробляє один MDT. Решта 12 дисків сконфігуровані в 3 групи дисків RAID 0 по чотири диски в кожній. У зоні NUMA 1 працюють три служби зберігання, по одному сервісу для кожного ST. Таким чином, сервер, на якому розміщуються метадані та цілі зберігання, має 6 MDT та 3 ST. Він також використовує шість служб метаданих і три служби зберігання даних. Кожен MDT – це файлова система ext4, заснована на конфігурації RAID 1. STs базуються на файловій системі XFS, налаштованій у RAID 0.
 

Сервіс зберігання

Як і служба метаданих, служба зберігання даних також є масштабованою послугою. У файловій системі BeeGFS може бути багато екземплярів служби зберігання. Однак, на відміну від сервісу метаданих, на одну службу зберігання може бути кілька цілей зберігання. Служба зберігання зберігає вміст файлів користувача в смугах, також відомих як файли фрагментів даних.

На малюнку 5 показані 5 серверів PowerEdge R740xd, які використовуються як сервери зберігання даних.

Малюнок 5:  Виділені сервери

зберігання даних Кожен сервер зберігання налаштований з 6 групами RAID 0, кожна з чотирьох дисків, таким чином розміщуючи 6 STs на сервер (3 на зону NUMA), як показано на малюнку 6, наведеному нижче:

Малюнок 6:  Конфігурація дисків у серверах

зберігання даних Загалом конфігурація базової еталонної архітектури містить 6 MDT та 33 ST. Наявність п'яти виділених серверів зберігання даних забезпечує необроблену ємність 211 ТБ і корисну ємність 190 ТБ. Розрахункова корисна ємність у TiB = Кількість дисків x Ємність на диск у ТБ x 0,99 (накладні витрати на файлову систему) x (10^12/2^40). Це було б ідеальним скретч-рішенням середнього класу з достатньою кількістю сховища метаданих, щоб полегшити додавання більшої кількості серверів зберігання в міру зростання вимог до ємності.

З огляду на наступні фактори, для цілей зберігання було обрано конфігурацію RAID 0, а не конфігурацію RAID 10.

1. Продуктивність запису вимірювалася за допомогою команди dd шляхом створення файлу розміром 10 ГБ з розміром блоку 1 МБ і прямим введенням-виведенням для даних, для пристроїв RAID 0 середнє значення становило близько 5,1 ГБ/с на кожен пристрій, тоді як для пристроїв RAID 10 середнє значення становило 3,4 ГБ/с на кожен пристрій.
2. Бенчмарк-тести StorageBench показали, що максимальна пропускна здатність становить 5,5 ГБ/с для конфігурації RAID 0, тоді як для конфігурації RAID 10 вона становить 3,4 ГБ/с. Ці результати схожі на ті, що були отримані за допомогою команд dd.
3. RAID 10 забезпечує 50% використання ємності диска та аналогічне зниження продуктивності запису на 50%. Використання RAID 10 є дорогим способом отримання резервування сховища.
4. NVMe-накопичувачі коштують дорого і пропонують прискорення, яке найкраще використовувати в конфігурації RAID 0

Обслуговування клієнтів

Клієнтський модуль BeeGFS повинен бути завантажений на всі хости, які повинні отримати доступ до файлової системи BeeGFSs. Коли beegfs-client завантажується, він монтує файлові системи, визначені у файлі/etc/beegfs-mounts.conf , замість звичайного підходу, заснованого на /etc/fstab. Застосування цього підходу запускає beegfs-client, як і будь-яку іншу службу Linux, за допомогою сценарію запуску служби. Він також дозволяє автоматично перекомпілювати клієнтський модуль BeeGFS після оновлень системи. 

Коли клієнтський модуль завантажується, він монтує файлові системи, визначені в beegfs-mounts.conf. Можна змонтувати декілька екземплярів beegfs на одному клієнті, як показано нижче:

$ cat /etc/beegfs/beegfs-mounts.conf
/mnt/beegfs-medium /etc/beegfs/beegfs-client-medium.conf
/mnt/beegfs-small /etc/beegfs/beegfs-client-small.conf

Наведений вище приклад показує дві різні файлові системи, змонтовані на одному клієнті. Для цього тестування в якості клієнтів було використано 32 вузли C6420.

R740xd, 24 диски NVMe, подробиці про відображення процесора

У конфігурації 24xNVMe сервера PowerEdge R740xd є дві мостові карти x16 NVMe, що живлять перемикач PCIe на задній панелі, який віялом відключає та живить накопичувачі (диски x4) спереду, як показано на малюнку 7 нижче:


Малюнок 7:  R740xd, 24x NVMe Подробиці про відображення

процесора У неоднорідному доступі до пам'яті (NUMA) системна пам'ять розділена на зони, які називаються вузлами, які розподіляються між центральними процесорами або сокетами. Доступ до локальної для центрального процесора пам'яті швидший, ніж до пам'яті, підключеної до віддалених центральних процесорів системи. Потоковий додаток зазвичай працює найкраще, коли потоки звертаються до пам'яті на одному вузлі NUMA. Вплив промахів NUMA на продуктивність є значним, як правило, починаючи з 10% зниження продуктивності або вище. Для підвищення продуктивності сервіси налаштовані на використання конкретних зон NUMA, щоб уникнути непотрібного використання перехресних зв'язків UPI, тим самим зменшуючи затримку. Кожна зона NUMA обробляє 12 дисків і використовує один з двох інтерфейсів InfiniBand EDR на серверах. Цей поділ NUMA досягається ручним налаштовуванням балансування NUMA шляхом створення нетипових файлів модулів systemd та налаштовуванням мультихомінгу. Отже, автоматичне балансування NUMA вимкнено, як показано нижче:

# cat /proc/sys/kernel/numa_balancing
0

На малюнку 8 показаний тестовий стенд, де виділені з'єднання InfiniBand із зоною NUMA. Кожен сервер має два IP-канали, і трафік через зону NUMA 0 передається інтерфейсом IB0, а трафік через зону NUMA 1 обробляється інтерфейсом IB1.

Малюнок 8:  Конфігурація тестового стенду
 

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

У цьому розділі представлена оцінка продуктивності, яка допомагає охарактеризувати Dell EMC Ready Solution для високопродуктивного рішення для зберігання даних HPC BeeGFS. Для отримання додаткової інформації та оновлень, будь ласка, шукайте білу книгу, яка буде опублікована пізніше. Продуктивність системи оцінювалася за допомогою бенчмарку IOzone. Рішення тестується на пропускну здатність послідовного читання та запису, а також випадковий IOPS зчитування та запису. У таблиці 4 описана конфігурація серверів C6420, які використовувалися в якості клієнтів BeeGFS для досліджень продуктивності в цьому блозі.
 

Послідовний запис і читання Н-Н

Для оцінки послідовних читань і записів використовувався бенчмарк IOzone в режимі послідовного читання і запису. Ці тести проводилися на кількох відрахунках потоків, починаючи з одного потоку і збільшуючи степені 2, до 1024 потоків. При кожному підрахунку потоків генерувалася однакова кількість файлів, оскільки цей тест працює з одним файлом на потік або з N клієнтами до N файлу (N-N). Процеси були розподілені між 32 фізичними вузлами клієнтів за круговою системою або циклічно, завдяки чому запити розподіляються рівномірно та відбувається балансування навантаження. Було обрано загальний розмір файлу 8 ТБ, який був порівну розділений між кількістю потоків у кожному конкретному тесті. Розмір сукупного файлу був обраний досить великий, щоб мінімізувати наслідки кешування з серверів і від клієнтів BeeGFS. IOzone була запущена в комбінованому режимі запису з подальшим читанням (-i 0, -i 1), щоб дозволити йому координувати межі між операціями. Для цього тестування та результатів ми використовували розмір запису 1 МБ для кожного забігу. Команди, що використовуються для послідовних N-N тестів, наведені нижче:

Послідовний запис і читання: iozone -i 0 -i 1 -c -e -w -r 1m -I -s $Size -t $Thread -+n -+m /path/to/threadlist

Кеші ОС також скидалися або очищалися на вузлах клієнта між ітераціями та між тестами запису та читання шляхом виконання команди:

# sync && echo 3 > /proc/sys/vm/drop_caches

Кількість страйпів за замовчуванням для Beegfs дорівнює 4. Однак розмір фрагмента та кількість цілей у файлі можна налаштувати для кожного каталогу. Для всіх цих тестів розмір смуги BeeGFS був обраний як 2 МБ, а кількість страйпів була обрана як 3, оскільки у нас є три цілі на зону NUMA, як показано нижче:

$ beegfs-ctl --getentryinfo --mount=/mnt/beegfs /mnt/beegfs/benchmark --verbose
EntryID: 0-5D9BA1BC-1
ParentID: root
Metadata node: node001-numa0-4 [ID: 4]
Stripe pattern details:
+ Type: RAID0
+ Chunksize: 2M
+ Number of storage targets: desired: 3
+ Storage Pool: 1 (Default)
Inode hash path: 7/5E/0-5D9BA1BC-1

Прозорі величезні сторінки були відключені, а на серверах метаданих і зберігання є наступні параметри налаштування:

vm.dirty_background_ratio = 5 
vm.dirty_ratio = 20 
vm.min_free_kbytes = 262144 
vm.vfs_cache_pressure = 50
vm.zone_reclaim_mode = 2 
kernel.numa_balancing = 0

Крім перерахованого вище, були використані наступні варіанти тюнінгу BeeGFS: 

• tuneTargetChooser У файлі конфігурації метаданих було встановлено параметр "roundrobin" 
• tuneNumWorkers було встановлено значення 24 для метаданих і 32 для зберігання 
• connMaxInternodeNum було встановлено значення 32 для метаданих і 12 для сховища та 24 для клієнтів

Малюнок 9:  Сукупний розмір файлу послідовної IOзони 8 ТБ.

На рисунку 9 ми бачимо, що пікова продуктивність читання становить 132 ГБ/с при 1024 потоках, а піковий запис становить 121 ГБ/с при 256 потоках. Кожен накопичувач може забезпечити пікову продуктивність читання 3,2 ГБ/с і пікову продуктивність запису 1,3 ГБ/с, що дозволяє теоретично досягти піку 422 ГБ/с для читання та 172 ГБ/с для запису. Однак тут обмежуючим фактором є мережа. Загалом у нас є 11 посилань InfiniBand EDR для серверів зберігання даних у налаштуваннях. Кожен канал може забезпечити теоретичну пікову продуктивність 12,4 ГБ/с, що дозволяє теоретично досягти пікової продуктивності 136,4 ГБ/с. Досягнута пікова продуктивність читання та запису становить 97% та 89% відповідно від теоретичного піку продуктивності.

Продуктивність однопотокового запису становить ~3 ГБ/с, а читання – ~3 ГБ/с. Ми спостерігаємо, що продуктивність запису масштабується лінійно, досягає піку на рівні 256 потоків, а потім починає знижуватися. При меншій кількості потоків продуктивність читання та запису однакова. Тому що до восьми потоків у нас є вісім клієнтів, які записують вісім файлів у 24 цілях, що означає, що не всі цілі зберігання використовуються повністю. У нас є 33 цілі зберігання даних у системі, і, отже, для повноцінного використання всіх серверів потрібно щонайменше 11 потоків. Продуктивність зчитування реєструє стійке лінійне зростання зі збільшенням числа одночасних потоків, і ми спостерігаємо майже однакову продуктивність на 512 і 1024 потоках.

Ми також спостерігаємо, що продуктивність читання нижча, ніж запис для кількості потоків від 16 до 128, а потім продуктивність читання починає масштабуватися. Це пов'язано з тим, що в той час як операція зчитування PCIe є неопублікованою операцією, яка вимагає як запиту, так і завершення, операція запису PCIe є операцією «вистрілив і забув». Як тільки пакет рівня транзакцій передається на рівень каналів передачі даних, операція завершується. Операція запису – це операція "Розміщено", яка складається лише із запиту.

Пропускна здатність зчитування зазвичай нижча, ніж пропускна здатність запису, оскільки для зчитування потрібні дві транзакції замість одного запису для того самого обсягу даних. PCI Express використовує модель розділеної транзакції для зчитування. Прочитана транзакція включає в себе наступні етапи:

• Запитувач надсилає запит на читання пам'яті (MRR).
• Заповнювач надсилає підтвердження до МРР.
• Завершувач повертає Доповнення з Даними.

Пропускна здатність зчитування залежить від затримки між часом видачі запиту на зчитування та часом, необхідним заповнювачу для повернення даних. Однак, коли програма видає достатню кількість запитів на читання, щоб покрити цю затримку, то пропускна здатність максимізується. Саме тому, хоча продуктивність читання менша, ніж у запису від 16 до 128 потоків, ми вимірюємо підвищену пропускну здатність при збільшенні кількості запитів. Нижча пропускна здатність вимірюється, коли запитувач чекає на завершення, перш ніж видавати наступні запити. Більш висока пропускна здатність реєструється, коли видається кілька запитів на амортизацію затримки після повернення перших даних.

Випадковий запис і зчитування N-N

Для оцінки випадкової продуктивності вводу-виводу використовувалася IOzone у випадковому режимі. Випробування проводилися на кількості потоків від 4 потоків до 1024 потоків. Опція прямого вводу-виводу (-I) використовувалася для запуску IOzone, щоб всі операції обходили буферний кеш і йшли безпосередньо на диск. У BeeGFS використовувалася кількість страйпів 3 і розмір фрагмента 2 МБ. У IOzone використовується розмір запиту 4KiB. Продуктивність вимірюється в операціях вводу/виводу за секунду (IOPS). Кеш ОС скидався між запусками на серверах BeeGFS і клієнтах BeeGFS. Команда, яка використовується для виконання випадкових записів і читань, наведена нижче:

Випадкове читання і запис: iozone -i 2 -w -c -O -I -r 4K -s $Size -t $Thread -+n -+m /path/to/threadlist

Малюнок 10:  Продуктивність випадкового читання та запису за допомогою IOzone із загальним розміром файлу 8 ТБ.

Випадковий запис досягає піку ~3,6 мільйона IOPS при 512 потоках, а випадковий пік зчитування становить ~3,5 мільйона IOPS при 1024 потоках, як показано на малюнку 10. Як продуктивність запису, так і читання демонструють вищу продуктивність, коли є більша кількість запитів вводу-виводу. Це пов'язано з тим, що стандарт NVMe підтримує до 64K черги вводу/виводу та до 64K команд на чергу. Цей великий пул черг NVMe забезпечує більш високий рівень паралелізму введення-виведення, і, отже, ми спостерігаємо IOPS, що перевищує 3 мільйони.

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

У цьому блозі повідомляється про випуск рішення для зберігання даних Dell EMC High Performance BeeGFS і висвітлюються його експлуатаційні характеристики. Рішення має пікову продуктивність послідовного читання та запису ~132 ГБ/с та ~121 ГБ/с відповідно, а пік випадкового запису становить ~3,6 мільйона IOPS, а випадкові зчитування – ~3,5 мільйона IOPS.

Цей блог є першою частиною "BeeGFS Storage Solution", яке було розроблено з акцентом на простір для нуля з високою продуктивністю. Слідкуйте за оновленнями 2 частини серії блогів, в якій буде описано, як можна масштабувати рішення, збільшуючи кількість серверів для збільшення продуктивності та потужності. У частині 3 серії блогів будуть обговорюватися додаткові функції BeeGFS і висвітлюватися використання "StorageBench", тесту BeeGFS для цілей вбудованого сховища.

У рамках наступних кроків ми пізніше опублікуємо офіційний документ із продуктивністю метаданих і N-потоками до одного файлу IOR продуктивності, а також з додатковими подробицями про міркування дизайну, налаштування та конфігурацію.

Посилання

[1] Документація BeeGFS: 
https://www.beegfs.io/wiki/[2] Як з'єднати два інтерфейси в одній підмережі:  https://access.redhat.com/solutions/30564