PowerScale, Isilon OneFS: Тестування продуктивності HBase на Isilon

Не обов'язково

Не обов'язково

Вступ

Серія тестів бенчмаркінгу продуктивності була проведена на кластері Isilon X410 із використанням бенчмаркінгу YCSB та CDH 5.10.

Лабораторне тестове середовище було налаштоване з п'ятьма вузлами Isilon x410, що працювали під OneFS v8.0.0.4 та пізніше v8.0.1.1. Були проведені бенчмарки потокового моніторингу Network File System (NFS) Large Block. Очікуваний теоретичний загальний максимум для тестів становив ~700 МБ/с (3,5 ГБ/с) записів і ~1 ГБ/с читання (5 ГБ/с) на вузол.

(9) обчислювальних вузлів — це сервери Dell PowerEdge FC630 під CentOS v7.3.1611, кожен з яких налаштований на 2x18C/36T-Intel Xeon® CPU E5-2697 v4 @ 2.30GHz з 512GB оперативної пам'яті. Локальне сховище — це 2xSSD у RAID 1, відформатований як XFS, як для операційної системи, так і для scratch space або spill файлів.

Також існували три додаткові Edge-сервери, які використовувалися для керування навантаженням YCSB.

Бекенд-мережа між обчислювальними вузлами та Isilon становить 10 Гбіт/с із встановленими Jumbo Frames (MTU=9162) для мережевих карт і портів комутатора.
CDH 5.10 була налаштована для роботи в зоні доступу на кластері Isilon. Сервісні облікові записи створювалися у локальному провайдері Isilon та локально у файлах клієнта /etc/passwd. Усі тести виконувалися за допомогою базового тестового клієнта без спеціальних привілеїв.

Статистика Isilon відстежувалася як за допомогою IIQ, так і пакету Grafana/Data Insights. Статистика CDH відстежувалася за допомогою Cloudera Manager, а також Grafana.

Початкове тестування

Перша серія тестів мала визначити відповідні параметри на стороні HBASE, які впливали на загальний результат. Інструмент YCSB використовувався для генерації навантаження HBASE. Цей початковий тест проводився з використанням одного клієнта (edge server) з використанням фази «завантаження» YCSB і 40 мільйонів рядків. Цю таблицю видаляли перед кожним запуском.
 

ycsb load hbase10 -P workloads/workloada1 -p table='ycsb_40Mtable_nr' -p columnfamily=family -threads 256 -p recordcount=40000000

• hbase.regionserver.maxlogs - Максимальна кількість файлів Write-Ahead Log (WAL) - Це значення, помножене на розмір блоку HDFS (dfs.blocksize), — це розмір WAL, який потрібно відтворити у разі краху сервера. Це значення обернено пропорційне частоті промивань на диск.
• hbase.wal.regiongrouping.numgroups — При використанні кількох HDFS WAL як WALProvider це встановлює, скільки записів на випередження кожен RegionServer має запускати. Результати показують кількість HDFS-конвеєрів. Записи для певного регіону йдуть лише в один конвеєр, розподіляючи загальне навантаження на RegionServer.

   
Філософія тут полягала в тому, щоб паралелізувати якомога більше творів. Збільшення кількості WAL, а потім кількості потоків (конвеєра) на WAL досягає цього. Два попередні графіки показують, що для заданого числа для «макслогів» — 128 або 256 — жодної реальної зміни не відображається. Це свідчить про те, що тест насправді не впливає на результати з боку клієнта. Кількість «конвеєрів» у кожному файлі була варіативною, що показувало тенденцію, що вказувала на параметр, чутливий до паралелізації. Наступне питання — де кластер Isilon «заважає» — це Disk I/O, Network, CPU або OneFS. Щоб відповісти на це питання, подивіться на статистичний звіт Isilon.
Графіки мережі та процесорів показують, що кластер Isilon недостатньо використовується і має простор для подальшої роботи. Процесор буде > 80%, а пропускна здатність мережі — понад 3 ГБ/с.
 
Ці графіки показують статистику протоколу HDFS і те, як OneFS транслює результати. HDFS-оператори — це кратні dfs.blocksize, який тут становить 256 МБ. Цікаво, що графік «Heat» показує операції з файлом OneFS, а також кореляція записів і блокувань. У цьому випадку HBase додає файли до WAL, тому OneFS блокує файл WAL для кожного доданого запису. Саме це і очікується від стабільних записів у кластеризованій файловій системі. Вони, ймовірно, сприяють обмежувальному фактору в цьому наборі тестів.

Оновлення HBase

Наступний тест мав на меті провести більше експериментів, щоб з'ясувати, що відбувається у масштабі. Створюється таблиця з 1 мільярдом рядків, на створення якої йде година. Проводиться тест YCSB, який оновлює 10 мільйонів рядків за налаштуваннями 'workloada' (50/50 читання/запис). Цей тест проводився на одному клієнті. Тест виконувався як функція кількості потоків YCSB, щоб отримати максимальну пропускну здатність. Також було внесено певне налаштування, і OneFS оновили до версії 8.0.1.1, яка має налаштування продуктивності для сервісу Data node. Наступний графік показує зростання результатів порівняно з попереднім набором результатів. Для таких запусків hbase.regionserver.maxlogs встановлено на 256, а hbase.wal.regiongrouping.numgroups — на 20.    
Огляд цих тестових запусків показує очевидне зниження при великій кількості потоків, що може бути як проблемою з Isilon, так і на стороні клієнта. Тестування показує і вражає 200 тисяч операцій на секунду при затримці оновлення < 3 мс. Кожен із тестових запусків оновлень був швидким і міг запускатися послідовно. Графік нижче показує рівномірний баланс між вузлами Isilon для кожного тестового запуску.
Граф Heat показує, що операції з файлами — це записи та блокування, що відповідають природі додатків процесів WAL.

Масштабування регіонального сервера

Наступним тестом було визначити, як вузли Isilon (п'ять вузлів) порівнюватимуться з різною кількістю регіональних серверів. Той самий скрипт оновлення, що й у попередньому тесті, використовував таблицю з одним мільярдом рядків і оновленням на 10 мільйонів рядків за допомогою 'workloada'. Тест використовував один клієнт із потоками YCSB, встановленими на 51. Те саме налаштування застосовуються для макслогів і конвеєрів (256 і 20 відповідно).  
Результати інформативні, хоча й не дивують. Масштабований характер HBase у поєднанні з масштабуванням Isilon свідчив, що більше — це краще. Цей тест рекомендується проводити клієнтам у їхньому середовищі як частину власних вправ з визначення розміру. Тут дев'ять серверів, які запускають п'ять вузлів Isilon, і, здається, ще є простір для нових до досягнення точки зменшення віддачі.

Більше клієнтів

Остання серія тестів була призначена для перевірки меж апаратної конфігурації. Це було зроблено для визначення верхньої межі параметрів, які тестувалися. У цій серії тестів використовуються два додаткові сервери для запуску клієнтів. Крім того, з кожного сервера запускаються два YCSB-клієнти, що дозволяло працювати до шести клієнтів у кожному. Кожен клієнт керував 512 потоками, загалом 4096 потоків. Було створено дві різні таблиці. Одна таблиця з 4 мільярдами рядків, розділених на 600 регіонів, і інша з 400 мільйонами рядків, розділених на 90 регіонів.  
Графіки нижче показують, що розмір таблиці має мало значення в цьому тесті. Графіки Isilon Heat знову показують, що існує певна відсоткова різниця у кількості операцій з файлами. Більшість відмінностей відповідали різницям між таблицею з чотирма мільярдами рядків і таблиці з 400 мільйонами рядків.

Висновок

HBase є хорошим кандидатом для роботи на Isilon, головним чином через архітектури масштабування від масштабування до масштабування. HBase виконує багато кешування самостійно, і, розділяючи таблицю на велику кількість регіонів, HBase може масштабуватися з даними. Інакше кажучи, вона добре піклується про власні потреби, а файлова система забезпечує стійкість додатків. Тестування не змогло підняти навантаження до межі, щоб щось зламалося. Якщо HBase розрахований на 800 000 операцій із затримкою менше 3 мс, ця архітектура її підтримує. HBase підтримує безліч коригувань і коригувань продуктивності як на стороні клієнта, так і для самої HBase. Тестування всіх цих коригувань і коригувань було поза межами цього тесту.