Готові рішення Dell EMC для високопродуктивного зберігання даних HPC BeeGFS

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

Готові рішення Dell EMC для високопродуктивного зберігання даних HPC BeeGFS

Зміст

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

Введення

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

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

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

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

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

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

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

Малюнок 3:  Сервер метаданих На

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

Послуга зберігання

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

Клієнтський сервіс

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

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

# cat /proc/sys/kernel/numa_balancing
0

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

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

Для оцінки послідовних читань і записів використовувався бенчмарк IOzone в режимі послідовного читання і запису. Ці випробування проводилися на кількох потоках, починаючи з 1 потоку і збільшуючи степені 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 /шлях/до/списку ниток

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

# 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
Ідентифікатор батьків: корінь
Вузол метаданих: node001-numa0-4 [ID: 4]
Деталі візерунка смуги:
+ Тип: Розмір фрагмента RAID0
+: 2M
+ Кількість об'єктів зберігання: бажано:
3+ Накопичувальний басейн: 1 (За замовчуванням)
Шлях до хешу inode: 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 ми бачимо, що пікова продуктивність читання становить 132 ГБ/с при 1024 потоках, а пікова швидкість запису становить 121 ГБ/с при 256 потоках. Кожен накопичувач може забезпечити пікову продуктивність читання 3,2 ГБ/с і пікову продуктивність запису 1,3 ГБ/с, що дозволяє теоретично досягти піку 422 ГБ/с для читання та 172 ГБ/с для запису. Однак тут обмежуючим фактором є мережа. Загалом у нас є 11 посилань InfiniBand EDR для серверів зберігання даних у налаштуваннях. Кожен канал може забезпечити теоретичну пікову продуктивність 12,4 ГБ/с, що дозволяє теоретично досягти пікової продуктивності 136,4 ГБ/с. Досягнута пікова продуктивність читання та запису становить 97% та 89% відповідно від теоретичної пікової продуктивності.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Посилання