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

Введення

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

Лабораторне середовище CAE POC було налаштовано з 5 вузлами Isilon x410, які працюють під керуванням OneFS 8.0.0.4 і пізніших 8.0.1.1 NFS великих потокових тестів блоків, ми повинні очікувати 5x ~700 МБ/с запису (3,5 ГБ/с) і 5x ~1 ГБ/с читання (5 ГБ/с) для наших теоретичних сукупних максимумів у будь-якому з цих тестів.

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

Також було три додаткові периферійні сервери, які використовувалися для навантаження YCSB.

Внутрішня мережа між обчислювальними вузлами та Isilon становить 10 Гбіт/с з набором Jumbo Frames (MTU=9162) для мережевих адаптерів та портів комутаторів.

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

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

ycsb load hbase10 -P workloads/workloada1 -p table='ycsb_40Mtable_nr' -p columnfamily=сім'я -threads 256 -p recordcount=40000000

hbase.regionserver.maxlogs - Максимальна кількість файлів журналу випередження запису (WAL). Це значення, помножене на розмір блоку HDFS (dfs.blocksize), є розміром WAL, який потрібно відтворити повторно при збої сервера. Ця величина обернено пропорційна частоті промивок диска.

hbase.wal.regiongrouping.numgroups - При використанні Multiple HDFS WAL в якості WALProvider, встановлює, скільки журналів запису повинен запускати кожен RegionServer. Результатом є така кількість трубопроводів HDFS. Записи для заданого регіону надходять лише до одного конвеєра, розподіляючи загальне навантаження на RegionServer.

Філософія тут полягала в тому, щоб розпаралелити якомога більше записів, тому збільшення кількості WAL, а потім кількості потоків (pipeline) на WAL досягає цього. Попередні два графіки показують, що для даного числа для «maxlogs» 128 або 256 ми не бачимо реальних змін, які б вказували на те, що ми насправді не натискаємо на це число з боку клієнта. Змінюючи кількість «конвеєрів» на файл, ми бачимо тенденцію, що вказує на параметр, чутливий до розпаралелювання. Наступне питання полягає в тому, де Isilon «заважає» з дисковим введенням-виведенням, мережею, процесором або OneFS, і ми можемо подивитися, що повідомляє статистика Isilon.


 
Графіки мережі та процесора говорять нам, що кластер Isilon недостатньо використовується і має простір для додаткової роботи. Процесор становитиме 80%, а пропускна здатність мережі становитиме > понад 3 ГБ/с.



Ці графіки показують статистику протоколу HDFS і те, як вона транслюється OneFS. Операції HDFS кратні dfs.blocksize, який тут становить 256 МБ. Цікаво те, що графік «Heat» показує операції з файлами OneFS, і ви можете побачити кореляцію записів і блокувань. У цьому випадку HBase робить додавання до WAL, тому OneFS блокує файл WAL для кожного запису, який додається. Це те, що ми очікуємо від стабільних записів у кластеризованій файловій системі. Схоже, що вони сприяють обмежувальному фактору в цьому наборі тестів.

Оновлення HBase

Цей наступний тест полягав у тому, щоб провести ще кілька експериментів у пошуку того, що відбувається в масштабі, тому я створив таблицю з одним мільярдом рядків, на створення якої пішла добра година, а потім запустив YCSB, який оновив 10 мільйонів рядків за допомогою налаштувань «workloada» (читання/запис 50/50). Це було запущено на одному клієнті, і я також шукав найбільшу пропускну здатність, яку я міг згенерувати, тому я запустив це як функцію від кількості потоків YCSB. Ще одне зауваження полягало в тому, що ми зробили деяке налаштування Isilon і перейшли на OneFS 8.0.1.1, яка має налаштування продуктивності для служби вузлів даних. Ви можете побачити зростання продуктивності в порівнянні з попереднім набором пробіжок. Для цих прогонів ми встановлюємо hbase.regionserver.maxlogs = 256 і hbase.wal.regiongrouping.numgroups = 20

Дивлячись на ці прогони, перше, що кидається в очі, це падіння при великій кількості ниток. Мені було цікаво, чи це проблема Isilon, чи проблема на стороні клієнта. Ми побачимо деякі подальші тести щодо цього в наступних параграфах. Але я можу сказати, що їзда на 200K+ Ops із затримкою оновлення 3 < мс вражає. Кожне з цих оновлень було швидким, і я міг робити їх один за одним, і графік нижче показує рівномірний баланс між вузлами Isilon для цих запусків.



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

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

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

 
Результати інформативні, хоч і не дивні. Масштабна природа HBase у поєднанні з масштабованою природою Isilon та more==better. Це тест, який я б рекомендував клієнтам проводити у своєму середовищі як частину власної вправи з визначення розміру. Можливо, справа дійде до точки спадної віддачі, але тут у нас є дев'ять здоровенних серверів, які штовхають п'ять вузлів Isilon, і, схоже, є місце для більшого.

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

Остання серія тестів походить з того глибокого темного місця, яке викликає бажання зламати систему, яку ви тестуєте. Врешті-решт, це цілком обґрунтований науковий метод – проводити тест до тих пір, поки все не зламається, і дзвонити, тим самим знаючи, яка верхня межа параметрів, що перевіряються. У цій серії тестів у мене було два додаткових сервера, з яких я міг використовувати клієнт, крім того, я запустив два клієнти YCSB на кожному з них, що дозволило мені масштабувати до шести клієнтів кожен, керуючи 512 потоками, що в цілому становило б 4096 потоків. Я повернувся назад і створив дві різні таблиці: одну з 4 мільярдами рядків, розділених на 600 регіонів, а іншу з 400 мільйонами рядків, розділених на 90 областей.  

 



 

Як бачите, розмір столу в цьому тесті має невелике значення. Знову поглянувши на діаграми Isilon Heat, можна побачити, що існує деяка відсоткова різниця в кількості операцій з файлами, в основному збігається з відмінностями таблиці з чотирьох мільярдів рядків до 400 мільйонів рядків.

Висновок

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