PowerScale, Isilon OneFS. Тестирование производительности HBase в Isilon

Введение

Мы тестируем производительность кластера Isilon X410 с помощью пакета эталонных тестов YCSB и CDH 5.10.

Среда демонстрационной лаборатории CAE была настроена с 5 узлами Isilon x410, в которых используется OneFS 8.0.0.4 и более поздняя версия 8.0.1.1 Эталонные тесты потоковой передачи больших блоков NFS. в любом из этих тестов должны выполняться 5 операций записи со скоростью ~700 Мбайт/с (3,5 Гбайт/с) и 5 операций чтения со скоростью ~1 Гбайт/с (5 Гбайт/с).

(9) Вычислительные узлы — это серверы Dell PowerEdge FC630 под управлением CentOS 7.3.1611, каждый из которых сконфигурированных с процессором Intel Xeon® E5-2697 v4 2,30 ГГц с 512 Гбайт ОЗУ. Локальное хранилище — это 2 твердотельных накопителя в массиве RAID 1, отформатированном как XFS для операционной системы и файлов с пространством для царапин и попадания влаги.

Кроме того, для управления нагрузкой YCSB использовались три дополнительных периферийных сервера.

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

Начальное тестирование

В первой серии тестов были заданы соответствующие параметры на стороне HBASE, которые влияли на общий вывод данных. Мы использовали инструмент YCSB для создания нагрузки для HBASE. Этот начальный тест был выполнен с использованием одного клиента (периферийного сервера) с использованием фазы «нагрузки» 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 задайте, сколько журналов записи упреждающее для каждого региона Должен работать сервер. Это количество каналов HDFS. Операции записи для конкретного региона записывают только в один канал, распределяя общую нагрузку на сервер.

В рамках этой концепции мы выполнили параллелизацию как можно больше операций записи, чтобы увеличить количество WLS, а затем — количество потоков (конвейеров) на единицу стоеального каталога. На предыдущих двух диаграммах показано, что для заданного номера для «maxlogs» 128 или 256 мы не видим никаких реальных изменений, указывающих на то, что на самом деле мы не вставли в это число со стороны клиента. Не нужно менять количество «конвейеров» для каждого файла, хотя мы видим тенденцию, указывающее параметр, чувствительный к параллелизации. Следующий вопрос заключается в том, где Isilon «встает на пути» с дисками ввода-вывода, сетью, ЦП или OneFS, и можно посмотреть, какой отчет по статистике Isilon.


 
Графики сети и ЦП говорят о том, что кластер Isilon не используется и для его работы достаточно места. ЦП составляет > 80%, а пропускная способность сети — более 3 Гбайт/с.



На этих рисунках показана статистика протокола HDFS и способы их перевода с помощью OneFS. Размер операций HDFS кратно dfs.blocksize, что составляет 256 Мбайт. Интересно отметить, что на графике «Тепло» показаны операции с файлами 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 или проблема на стороне клиента. В предстоящих абзацах мы рассмотрим ряд дополнительных тестов. Но я могу сказать, что более 200 000 операций < при задержке обновления 3 мс впечатляют. Каждый из этих обновлений выполняется быстро, и я могу выполнять их один за другим, и на графике ниже показан ровный баланс между узлами Isilon для этих запусков.



На диаграмме Теплоотвода видно, что операции с файлами записывают и блокировются, соответствующие соотнося с характером процессов WAL.

Масштабирование серверов в регионе

Следующим тестом было определение того, как узлы Isilon (пять из них) будут перейти на серверы другого региона. Здесь был запущен тот же сценарий обновления, который выполнялся в предыдущем тесте. Таблица с одним миллиардом строк и 10 млн строк, обновленная с помощью «workloada» с одним клиентом и потоками YCSB на 51, мы также сохранили одинаковую настройку для maxlogs и конвейеров (256 и 20 соответственно).

 
Результаты информативны, хотя и не удивительно. Горизонтально масштабируемый характер HBase в сочетании с горизонтально масштабируемым характером Isilon и more=better. Это тест, который рекомендуется выполнять заказчикам в своих средах в рамках собственных упражнений по определению конфигурации. Это может перейти к снижению доходности, но в данном случае девять разнопроых серверов расширяют пять узлов Isilon, и, похоже, для них есть возможности для большего.

Больше клиентов

Последняя серия тестов выполняется из этого темного места, из-за которого вы хотите сломать тестируемую систему. В верхней части тестируемого параметра это вполне допустимый метод для научных исследований до тех пор, пока не произойдет поломка и вызов. В этой серии тестов у меня было два дополнительных сервера, с которых можно было запускать клиент. Кроме того, мы запустили два клиента YCSB на каждом из них, что позволяет мне выполнять масштабирование до шести клиентов, каждый из которых поддерживает 512 потоков, что в целом составляет 4096 потоков. Я снова создал две разные таблицы, одна из них — 4 миллиарда строк, разделенных на 600 областей, и одна с 400млнн рядами, разделенной на 90 регионов.  

 



 

Как видите, в этом тесте размер таблицы имеет мало значения. При повторном просмотре диаграмм «Тепловые диаграммы» Isilon можно увидеть несколько процентов разницы в количестве операций с файлами, в основном на лету с различиями в таблице с четырьмя миллиардами строками до 400 млн строк.

Заключение

HBase — это хороший кандидат для работы на isilon, в основном благодаря горизонтально масштабируемым архитектурам. HBase выполняет множество собственных функций кэширования и разделяет таблицу на множество областей, в которые вы получаете HBase для горизонтального масштабирования данных. Иными словами, она выполняет хорошо задачу, чтобы выполнять собственные потребности, а файловая система обеспечивает сохраняемость данных. Мы не смогли выровнять тесты нагрузки до упора, но если вам нужно четыре миллиарда строк в вашей архитектуре HBase и ожидать выполнения 800 000 операций с задержкой менее 3 мс, эта архитектура поддерживает эту функцию. Если вы заметили, что я не упоминал больше о какой-либо из множества других настроек на стороне клиента, которые можно применить к HBase, я ожидаю, что все эти настройки останутся действительными и выходящих за рамки этого теста.