PowerEdge. Dell Ready Solutions для высокопроизводительных хранилищ НРС BeeGFS

Статья написана Нирмалой Сундарараджан из Dell HPC and AI Innovation Lab в ноябре 2019 г.

Содержание

1. Введение
2. Эталонная архитектура решения
3. Требования к оборудованию и программному обеспечению
4. Сведения о конфигурации решения
   • Служба управления
   • Служба метаданных
   • Служба хранения
   • Клиентские службы
5. R740xd, 24 накопителя NVMe, подробные сведения о сопоставлении процессоров
6. Характеристики производительности
   • Операции последовательного чтения и записи N-N
   • Операции произвольного чтения и записи N-N
7. Выводы и планы на будущее
    

Введение

Команда Dell HPC с гордостью объявляет о выпуске «Dell EMC Ready Solutions для хранилищ HPC BeeGFS», последнего дополнения к портфелю решений для хранения HPC. В этом решении используются серверы R740xd, каждый из которых оснащен 24 накопителями Intel P4600 1,6 Тбайт NVMe, флэш-накопителями Express Flash смешанного назначения и двумя адаптерами Mellanox ConnectX-5 InfiniBand EDR. В этой конфигурации с 24 накопителями NVMe 12 твердотельных накопителей NVMe подключаются к коммутатору PCIe, и каждый коммутатор подключается к одному ЦП с помощью платы расширения x16 PCIe. Кроме того, каждый интерфейс IB подключен к одному ЦП. Такая сбалансированная конфигурация, в которой каждый процессор подключен к одному адаптеру InfiniBand, и работает с 12 твердотельными накопителями NVMe, обеспечивает максимальную производительность, гарантируя, что процессоры в равной степени заняты обработкой запросов ввода-вывода к накопителям NVMe и от них.

Основное внимание в решении уделяется высокопроизводительному вводу-выводу, и оно было разработано как высокоскоростное скретч-решение. В основе этого решения лежит использование высокоскоростных твердотельных накопителей NVMe, которые обеспечивают высокую пропускную способность и низкий уровень задержек за счет устранения узких мест планировщика и очереди на уровне блоков. Файловая система BeeGFS также поддерживает высокую совокупную пропускную способность ввода-вывода.

Эталонная архитектура решения

На рис. 1 показана эталонная архитектура решения. Сервер управления подключается к серверам хранения метаданных только через Ethernet. Каждый сервер метаданных и хранения данных имеет два канала InfiniBand и подключен к частной сети через Ethernet. Клиенты имеют один канал InfiniBand и подключены к частному интерфейсу через Ethernet.

Рисунок 1:  Готовые решения Dell для хранилищ НРС BeeGFS — эталонная архитектура

Требования к оборудованию и программному обеспечению

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

Сведения о конфигурации решения

Архитектура BeeGFS состоит из четырех основных служб:

• Служба управления
• Служба метаданных
• Служба хранения
• Клиентские службы

За исключением клиентской службы, которая является модулем ядра, службы управления, метаданных и хранения являются процессами пользовательского пространства. На рис. 2 показано, как эталонная архитектура Dell EMC Ready Solutions для хранилищ HPC BeeGFS сопоставляется с общей архитектурой файловой системы BeeGFS.

Рис. 2.  Файловая система BeeGFS на PowerEdge R740xd с SSD NVMe

Служба управления

Каждая файловая система или пространство имен BeeGFS имеет только одну службу управления. Служба управления — это первая служба, которую необходимо настроить, поскольку при настройке всех других служб они должны зарегистрироваться в службе управления. PowerEdge R640 используется в качестве сервера управления. Помимо хостинга службы управления (beegfs-mgmtd.service), на нем также размещается служба мониторинга (beegfs-mon.service), которая собирает статистику из системы и предоставляет ее пользователю, используя базу данных временных рядов InfluxDB. Для визуализации данных в beegfs-mon имеются предварительно заданные панели Grafana, которые можно использовать без дополнительной настройки. Сервер управления оснащен 6 жесткими дисками емкостью по 300 Гбайт, сконфигурированными в RAID 10 для операционной системы и InfluxDB.

Служба метаданных

Служба метаданных — это горизонтально масштабируемая служба. Это означает, что в файловой системе BeeGFS может быть много служб метаданных. Однако каждая служба метаданных имеет ровно один целевой объект метаданных для хранения метаданных. В целевом объекте метаданных BeeGFS создает один файл метаданных для каждого созданного пользователем файла. Метаданные BeeGFS распределяются по каталогам. Служба метаданных обеспечивает распределение данных для клиентов и не участвует в доступе к данным между открытием и закрытием файлов.

PowerEdge R740xd с 24 накопителями Intel P4600 1,6 Тбайт NVMe, накопители используются для хранения метаданных. Поскольку требования к емкости хранения для метаданных BeeGFS очень малы, вместо использования выделенного сервера метаданных для размещения Target (MDT) использовались только 12 дисков в зоне NUMA 0, а остальные 12 дисков в массивах Storage T(ST) хоста зоны NUMA.

На рис. 3 показан сервер метаданных. 12 накопителей, заключенных в желтый прямоугольник, являются MDT в зоне NUMA 0, а 12 накопителей, заключенных в зеленый прямоугольник, являются объекты ST в зоне NUMA 1. Такая конфигурация позволяет не только избежать проблем с NUMA, но и обеспечивает достаточное количество ресурсов хранения метаданных для упрощения масштабирования емкости и производительности по мере необходимости.

Рис. 3.  Сервер метаданных

На рис. 4 показана конфигурация RAID сервера метаданных. На нем изображено, как на сервере метаданных, на накопителях в зоне NUMA 0, размещаются объекты MDT, а на накопителях в зоне NUMA 1 размещаются данные хранения, в то время как на серверах хранения размещаются ST в обеих зонах NUMA.

Рис. 4.  Конфигурация дисков на сервере

метаданных 12 дисков, используемых для метаданных, настроены как 6 дисков RAID 1 из двух дисков, каждый из которых служит в качестве MDT. Выполняется шесть служб метаданных, каждая из которых обрабатывает один объект MDT. Остальные 12 накопителей хранилища сконфигурированы в 3 дисковых группы RAID 0 по четыре накопителя в каждой. В зоне NUMA 1 выполняются три службы хранения, по одной для каждого объекта ST. Таким образом, сервер, который одновременно размещает метаданные и целевые устройства хранения, содержит 6 объектов MDT и 3 объекта ST. Кроме того, он использует шесть служб метаданных и три службы хранения. Каждый объект MDT представляет собой файловую систему EXT4 на основе конфигурации RAID 1. Объекты ST работают на базе файловой системы XFS, настроенной в конфигурации RAID 0.
 

Служба хранения

Как и служба метаданных, служба хранения также является горизонтально масштабируемой. В файловой системе BeeGFS может быть много экземпляров службы хранения. Однако, в отличие от службы метаданных, для одной службы хранения может быть несколько целей хранения. В сервисе хранения хранится содержимое чередующихся пользовательских файлов, также известное как файлы блоков данных.

На рис. 5 показаны 5 серверов PowerEdge R740xd, используемых в качестве серверов хранения данных.

Рисунок 5.  Выделенные серверы хранения данных Каждый

сервер хранения сконфигурирован с 6 группами RAID 0, каждая из которых состоит из четырех дисков, таким образом, размещая 6 ST на сервер (3 на зону NUMA), как показано на рис. 6 ниже.

  Конфигурирование дисков на серверах

хранения данных В общей сложности конфигурация базовой эталонной архитектуры содержит 6 объектов MDT и 33 объекта ST. Пять выделенных серверов хранения обеспечивают неформатированную емкость 211 Тбайт и полезную емкость 190 Тбайт. Расчетная полезная емкость в ТиБ = количество накопителей x емкость на накопитель в Тбайт x 0,99 (издержки файловой системы) x (10^12/2^40). Это идеальное оперативное решение средней ценовой категории с достаточным количеством ресурсов хранения метаданных, чтобы упростить добавление дополнительных серверов хранения по мере роста требований к емкости.

Принимая во внимание следующие факторы, для целевых устройств хранения данных была выбрана конфигурация RAID 0, а не конфигурация RAID 10.

1. Производительность записи измерялась с помощью команды dd путем создания файла размером блока 10 Гбайт размером блок 1 Мбайт и прямого ввода-вывода для данных. Для устройств RAID 0 средняя скорость составила около 5,1 Гбайт/с на каждое устройство, тогда как для устройств RAID 10 — 3,4 Гбайт/с на каждое устройство.
2. Эталонные тесты StorageBench показали, что максимальная пропускная способность для конфигурации RAID 0 составляет 5,5 Гбайт/с, а для конфигурации RAID 10 — 3,4 Гбайт/с. Эти результаты похожи на результаты, полученные с помощью команд dd.
3. RAID 10 обеспечивает уровень использования дисковой емкости 50% и аналогичное снижение производительности записи на 50%. Использование RAID 10 — это дорогостоящий способ обеспечения резервирования хранилища.
4. Накопители NVMe являются дорогостоящими и обеспечивают высокую скорость работы, которая лучше всего используется в конфигурации RAID 0

Клиентские службы

Клиентский модуль BeeGFS должен быть загружен на всех хостах, которые должны иметь доступ к файловой системе BeeGFS. Когда beegfs-client загружен, он монтирует файловые системы, определенные в файле/etc/beegfs/beegfs-mounts.conf , вместо обычного подхода, основанного на /etc/fstab. Внедрение этого подхода запускает beegfs-client, как любую другую службу Linux, с помощью сценария запуска службы. Также это позволяет автоматически перекомпилировать клиентский модуль BeeGFS после обновления системы. 

После загрузки клиентского модуля выполняется монтирование файловых систем, определенных в файле beegfs-mounts.conf. Можно подключить несколько экземпляров beegfs на одном клиенте, как показано ниже:

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

В приведенном выше примере показаны две разные файловые системы, смонтированные на одном клиенте. Для целей этого тестирования в качестве клиентов использовались 32 узла C6420.

R740xd, 24 накопителя NVMe, подробные сведения о сопоставлении процессоров

В конфигурации с 24 накопителями NVMe на сервере PowerEdge R740xd имеются две платы моста x16 NVMe, подающие питание на коммутатор PCIe на распределительной плате, который разветвляет и подает питание на накопители (накопители x4) спереди, как показано на рис 7 ниже.


Рис. 7.  R740xd с 24 накопителями NVMe: сведения о сопоставлении процессоров

При использовании неравномерного доступа к память (NUMA) системная память разделена на зоны, называемые узлами, которые выделяются процессорам или сокетам. Доступ к локальной памяти процессора осуществляется быстрее, чем к памяти, подключенной к удаленным процессорам системы. Многопоточное приложение обычно работает лучше, если потоки обращаются к памяти на одном узле NUMA. Проблемы NUMA оказывают значительное влияние на производительность, обычно начиная с 10% снижения производительности или выше. Для повышения производительности службы настроены на использование определенных зон NUMA, чтобы избежать ненужного использования межсокетных каналов UPI, что снижает задержку. Каждая зона NUMA обрабатывает 12 накопителей и использует один из двух интерфейсов InfiniBand EDR на серверах. Разделение NUMA достигается путем ручной настройки балансировки NUMA за счет создания файлов пользовательских блоков systemd и настройки множественной адресации. Поэтому автоматическая балансировка NUMA отключена, как показано ниже:

# cat /proc/sys/kernel/numa_balancing
0

На рис. 8 показана тестовая платформа, на которой выделены соединения InfiniBand с зоной NUMA. Каждый сервер имеет два IP-канала, и трафик через зону NUMA 0 обрабатывается интерфейсом IB0, а трафик через зону NUMA 1 обрабатывается интерфейсом IB1.

Рис. 8.  Конфигурация опытного образца
 

Характеристики производительности

В этом разделе представлена оценка производительности, которая помогает охарактеризовать решение Dell EMC Ready Solution для высокопроизводительного хранилища НРС BeeGFS. Для получения дополнительной информации и обновлений найдите технический документ, который будет опубликован позже. Производительность системы оценивалась с помощью эталонного теста IOzone. Это решение протестировано на пропускную способность при последовательном чтении и записи, а также при произвольном чтении и записи. В таблице 4 описана конфигурация серверов C6420, которые использовались в качестве клиентов BeeGFS для исследований производительности, описанных в этой статье блога.
 

Последовательные операции записи и чтения N-N

Для оценки последовательных операций чтения и записи использовался эталонный тест IOzone в режиме последовательного чтения и записи. Эти тесты проводились на множестве потоков, начиная с одного потока и далее по степеням числа 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 /path/to/threadlist

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

# 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
ParentID: root
Metadata node: node001-numa0-4 [ID: 4]
Stripe pattern details:
+ Type: RAID0
+ Chunksize: 2M
+ Number of storage targets: desired: 3
+ Storage Pool: 1 (Default)
Inode hash path: 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.  Совокупный размер файла последовательного теста IOzone 8 Тбайт.

На рис. 9 показано, что пиковая производительность чтения составляет 132 Гбайт/с при 1024 потоках, а пиковая скорость записи составляет 121 Гбайт/с при 256 потоках. Каждый накопитель может обеспечивать пиковую производительность 3,2 Гбайт/с для чтения и 1,3 Гбайт/с для операций записи, что обеспечивает теоретическую пиковую производительность 422 Гбайт/с для операций чтения и 172 Гбайт/с для операций записи. Однако здесь сеть является ограничивающим фактором. В общей сложности у нас есть 11 каналов InfiniBand EDR для серверов хранения данных в установке. Каждый канал может обеспечивать теоретическую пиковую производительность 12,4 Гбайт/с, что обеспечивает общую теоретическую пиковую производительность 136,4 Гбайт/с. Достигнутая пиковая производительность чтения и записи составляет 97% и 89% от теоретической пиковой производительности соответственно.

Производительность записи в один поток составляет ~3 Гбайт/с, а скорость чтения — ~3 Гбайт/с. Наблюдалось линейное масштабирование производительности, пик составлял 256 потоков, а затем производительность начинала снижаться. При более низком числе потоков производительность операций чтения и записи одинаковая. Потому что до восьми потоков у нас есть восемь клиентов, записывающих восемь файлов в 24 целевых объекта, что означает, что не все целевые объекты хранения полностью используются. В системе имеется 33 целевых объекта хранения, поэтому для полного использования всех серверов требуется не менее 11 потоков. При увеличении количества параллельных потоков производительность чтения стабильно возрастает, и мы наблюдаем почти аналогичную производительность при 512 и 1024 потоках.

Кроме того, мы наблюдаем, что производительность чтения ниже, чем при операциях записи для количества потоков от 16 до 128, а затем производительность чтения начинает масштабироваться. Это связано с тем, что хотя операция чтения PCIe является непроведенной операцией, требующей как запроса, так и завершения, операция записи PCIe — это операция «запустил и забыл». После передачи пакета уровня транзакции на уровень канала данных операция завершается. Операция записи — это «проведенная» операция, которая состоит только из запроса.

Пропускная способность чтения обычно ниже, чем пропускная способность записи, поскольку для чтения требуется две транзакции, а не одна запись для одного и того же объема данных. PCI Express использует модель разделенной транзакции для операций чтения. Операция чтения включает в себя следующие шаги:

• Инициатор отправляет запрос на чтение памяти (MRR).
• Заверитель отправляет подтверждение MRR.
• Заверитель возвращает завершение с данными.

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

Произвольные операции записи и чтения N-N

Для оценки производительности произвольных операций ввода-вывода использовался IOzone в произвольном режиме. Испытания проводились на количестве потоков от 4 до 1024. Параметр прямого ввода-вывода (-I) использовался для запуска IOzone, чтобы все операции обходили кэш-память буфера и направлялись непосредственно на диск. Количество использованных полос BeeGFS — 3, размер блока — 2 Мбайт. В IOzone используется размер запроса 4 КиБ. Производительность измеряется в операциях ввода-вывода в секунду (IOPS). Кэш ОС был удален между запусками на серверах BeeGFS и клиентах BeeGFS. Ниже приведена команда, используемая для выполнения произвольных операций записи и чтения.

Операции произвольного чтения и записи: iozone -i 2 -w -c -O -I -r 4K -s $Size -t $Thread -+n -+m /path/to/threadlist

Рис. 10.  Производительность произвольного чтения и записи с использованием IOzone с совокупным размером файла 8 Тбайт.

Пик произвольной записи составляет ~3,6 млн IOPS при 512 потоках, а пик произвольного чтения — ~3,5 млн IOPS при 1024 потоках, как показано на рисунке 10. Производительность операций записи и чтения выше при большем количестве запросов ввода-вывода. Это связано с тем, что стандарт NVMe поддерживает до 64 тыс. операций в очереди ввода-вывода и до 64 тыс. команд на очередь. Большой пул очередей NVMe обеспечивает более высокий уровень параллелизма операций ввода-вывода и, следовательно, мы наблюдаем, что количество операций ввода-вывода в секунду превышает 3 миллиона.

Выводы и планы на будущее

В этом блоге анонсируется выпуск решения Dell EMC для высокопроизводительного хранилища BeeGFS и рассматриваются характеристики его производительности. Пиковая производительность последовательного чтения и записи составляет ~132 Гбайт/с и ~121 Гбайт/с соответственно, а пиковая скорость произвольной записи — ~3,6 млн IOPS, скорость произвольного чтения — ~3,5 млн IOPS.

Эта статья блога — первая часть серии о «решении для хранения BeeGFS», которая написана с акцентом на оперативную емкость с высокой производительностью. Ждите вторую статью из этой серии, в которой мы расскажем, как можно масштабировать решение, увеличивая количество серверов для повышения производительности и емкости. В третьей части серии блогов будут обсуждаться дополнительные функции BeeGFS и будет освещено использование «StorageBench», встроенного эталонного теста BeeGFS для целевых показателей хранения данных.

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

Справочные материалы

[1] Документация BeeGFS:  https://www.beegfs.io/wiki/
[2] Подключение двух интерфейсов в одной подсети:  https://access.redhat.com/solutions/30564