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

Не требуется

Не требуется

Введение

Серия тестов производительности была выполнена в кластере Isilon X410 с использованием пакета сравнительной оценки YCSB и CDH 5.10.

Лабораторная тестовая среда была настроена с пятью узлами Isilon x410, работающими под управлением OneFS v8.0.0.4 и более поздних версий v8.0.1.1. Были выполнены эталонные тесты потоковой передачи больших блоков сетевой файловой системы (NFS). Ожидаемый теоретический совокупный максимум для тестов составлял ~700 Мбайт/с (3,5 Гбайт/с) операций записи и ~1 Гбайт/с чтения (5 Гбайт/с) на узел.

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

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

Внутренняя сеть между вычислительными узлами и системой Isilon имеет пропускную способность 10 Гбит/с с заданными пакетами Jumbo Frame (MTU=9162) для сетевых плат и портов коммутатора.
CDH 5.10 был настроен для работы в зоне доступа в кластере Isilon. Сервисные учетные записи были созданы в локальном поставщике Isilon и локально в клиентских файлах /etc/passwd. Все тесты выполнялись с использованием базового тестового клиента без специальных привилегий.

Статистика Isilon отслеживалась как с помощью IIQ, так и с помощью пакета Grafana/Data Insights. Статистика CDH отслеживалась с помощью Cloudera Manager, а также с помощью Grafana.

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

Первая серия тестов была направлена на определение соответствующих параметров на стороне 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 - Максимальное количество файлов журнала упреждающей записи (WAL) - Это значение, умноженное на размер блока HDFS (dfs.blocksize), представляет собой размер WAL, который должен быть воспроизведен при сбое сервера. Это значение обратно пропорционально частоте сбросов на диск.
• hbase.wal.regiongrouping.numgroups - При использовании нескольких HDFS WAL в качестве WALProvider это задает количество журналов упреждающей записи, которые должен выполнять каждый RegionServer. Результаты показывают количество конвейеров HDFS. Операции записи для данного региона направляются только в один конвейер, распределяя общую нагрузку RegionServer.

   
Философия заключалась в том, чтобы распараллелить как можно больше записей. Это достигается увеличением количества WAL, а затем количества потоков (конвейеров) на WAL. Предыдущие два графика показывают, что для заданного числа 'maxlogs', 128 или 256, не видно никаких реальных изменений. Это означает, что тест не влияет на результаты на стороне клиента. Количество «конвейеров» на файл варьировалось, что показывало тенденцию, указывающую на параметр, чувствительный к распараллеливанию. Следующий вопрос заключается в том, где кластер Isilon «мешает» дисковому вводу-выводу, сети, ЦП или 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, которая содержит настройки производительности для службы узла данных. На следующей диаграмме показан рост производительности по сравнению с предыдущим набором запусков. Для этих запусков для hbase.regionserver.maxlogs задано значение 256, а для hbase.wal.regiongrouping.numgroups — значение 20.    
Анализ этих тестовых запусков показывает явное снижение при большом количестве потоков, что может быть проблемой на стороне Isilon или на стороне клиента. Тестирование показывает и впечатляет 200 тысяч операций в секунду при задержке < обновления 3 мс. Каждый тестовый запуск обновления выполнялся быстро и мог выполняться последовательно. На приведенном ниже графике показано равномерное распределение между узлами Isilon для каждого тестового запуска.
Диаграмма Heat показывает, что файловые операции являются операциями записи и блокировки, соответствующими природе добавочных процессов WAL.

Региональное масштабирование сервера

Следующая проверка состояла в том, чтобы определить, как узлы Isilon (пять узлов) будут работать с серверами другого региона. Тот же сценарий обновления, что и в предыдущем тесте, был выполнен для таблицы с 1 миллиардом строк и обновлением из 10 миллионов строк с использованием «workloada». В тесте использовался один клиент с потоками YCSB, равными 51. Применяются одинаковые параметры для maxlogs и pipelines (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. Тестирование всех этих корректировок и настроек выходило за рамки данного теста.