Автор статьи: Нирмала Сандарараджан (Nirmala Sundararajan), лаборатория Dell EMC HPC and AI Innovation Lab, ноябрь 2019 г.
Готовые решения Dell EMC для высокопроизводительного хранилища НРС BeeGFS
В таблицах 1 и 2 приведены технические характеристики сервера управления и сервера метаданных/хранения соответственно. В таблице 3 описаны версии программного обеспечения, используемого для решения.
Таблица 1. Конфигурация PowerEdge R640 (сервер управления) | |
---|---|
Server | Dell EMC PowerEdge R640 |
Процессор | 2 процессора Intel Xeon Gold 5218, 2,3 ГГц, 16 ядер |
Модули | 12 модулей DIMM DDR4 2666 МТ/с по 8 Гбайт — 96 Гбайт |
Локальные диски | 6 2,5-дюймовых жестких дисков SAS, 300 Гбайт, 15 000 об/мин |
RAID-контроллер | Интегрированный RAID-контроллер PERC H740P |
Управление по дополнительному каналу | iDRAC9 Enterprise с Lifecycle Controller |
Блоки питания | Два блока питания мощностью 1100 Вт. |
Версия BIOS | 2.2.11 |
Операционная система | CentOS™ 7.6 |
Версия ядра | 3.10.0-957.27.2.el7.x86_64 |
Таблица 2. Конфигурация PowerEdge R740xd (серверы метаданных и хранения) | |
---|---|
Server | Dell EMC PowerEdge R740xd |
Процессор | 2 процессора Intel Xeon Platinum 8268, 2,90 ГГц, 24 ядра |
Модули | 12 модулей DIMM DDR4 2933 МТ/с по 32 Гбайт — 384 Гбайт |
Плата BOSS | 2 SATA SSD M.2 емкостью 240 Гбайт в конфигурации RAID 1 для ОС |
Локальные накопители | 24 2,5-дюймовых накопителя U.2 Dell Express Flash NVMe P4600 1,6 Тбайт SFF |
Плата Mellanox EDR | 2 платы Mellanox ConnectX-5 EDR (разъемы 1 и 8) |
Управление по дополнительному каналу | iDRAC9 Enterprise с Lifecycle Controller |
Блоки питания | Два блока питания мощностью 2000 Вт |
Таблица 3. Конфигурация программного обеспечения (серверы метаданных и хранения) | |
---|---|
BIOS | 2.2.11 |
CPLD | 1.1.3 |
Операционная система | CentOS™ 7.6 |
Версия ядра | 3.10.0-957.el7.x86_64 |
iDRAC | 3.34.34.34 |
Инструмент для управления системой | OpenManage Server Administrator 9.3.0-3407_A00 |
Mellanox OFED | 4.5-1.0.1.0 |
NVMe SSD | QDV1DP13 |
*Intel® Data Center Tool | 3.19.0 |
BeeGFS | 7.1.3 |
Grafana | 6.3.2 |
InfluxDB | 1.7.7 |
Эталонный тест IOzone | 3.487 |
В приведенном выше примере показаны две разные файловые системы, смонтированные на одном клиенте. Для целей этого тестирования в качестве клиентов использовались 32 узла C6420.$ cat /etc/beegfs/beegfs-mounts.conf
/mnt/beegfs-medium /etc/beegfs/beegfs-client-medium.conf
/mnt/beegfs-small /etc/beegfs/beegfs-client-small.conf
На рис. 8 показана тестовая платформа, на которой выделены соединения InfiniBand с зоной NUMA. Каждый сервер имеет два IP-канала. Трафик, передаваемый через зону NUMA 0, обрабатывается интерфейсом IB0, а трафик, передаваемый через зону NUMA 1, обрабатывается интерфейсом IB1.# cat /proc/sys/kernel/numa_balancing
0
Таблица 4. Конфигурация клиента | |
---|---|
Клиенты | 32 вычислительных узла Dell EMC PowerEdge C6420 |
BIOS | 2.2.9 |
Процессор | 2 процессора Intel Xeon Gold 6148, 2,40 ГГц и 20 ядер на процессор |
Модули | 12 модулей DIMM DDR4 2666 МТ/с емкостью 16 Гбайт — 192 Гбайт |
Плата BOSS | 2 загрузочных диска M.2 емкостью 120 Гбайт в RAID 1 для ОС |
Операционная система | Red Hat Enterprise Linux Server версии 7.6 |
Версия ядра | 3.10.0-957.el7.x86_64 |
Соединение | 1 плата Mellanox ConnectX-4 EDR |
Версия OFED | 4.5-1.0.1.0 |
Для оценки последовательных операций чтения и записи использовался эталонный тест IOzone в режиме последовательного чтения и записи. Эти тесты проводились на множестве потоков, начиная с 1 потока и далее по степеням числа 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:
На рис. 9 показано, что пиковая производительность чтения составляет 132 Гбайт/с при 1024 потоках, а пиковая скорость записи составляет 121 Гбайт/с при 256 потоках. Каждый накопитель может обеспечивать пиковую производительность 3,2 Гбайт/с для чтения и 1,3 Гбайт/с для операций записи, что обеспечивает теоретическую пиковую производительность 422 Гбайт/с для операций чтения и 172 Гбайт/с для операций записи. Однако здесь сеть является ограничивающим фактором. В общей сложности у нас есть 11 каналов InfiniBand EDR для серверов хранения данных, установленных в системе. Каждый канал может обеспечивать теоретическую пиковую производительность 12,4 Гбайт/с, что обеспечивает общую теоретическую пиковую производительность 136,4 Гбайт/с. Достигнутая пиковая производительность чтения и записи составляет 97% и 89% от теоретической пиковой производительности соответственно.
Производительность записи в один поток составляет ~3 Гбайт/с, а скорость чтения — ~3 Гбайт/с. Наблюдалось линейное масштабирование производительности, пик составлял 256 потоков, а затем производительность начинала снижаться. При более низком числе потоков производительность операций чтения и записи одинаковая. Поскольку до 8 потоков у нас есть 8 клиентов, записывающих 8 файлов в 24 целевых объекта, то есть не все целевые объекты хранения полностью используются. В системе имеется 33 целевых объекта хранения, поэтому для полного использования всех серверов требуется не менее 11 потоков. При увеличении количества параллельных потоков производительность чтения стабильно возрастает, и мы наблюдаем почти аналогичную производительность при 512 и 1024 потоках.
Кроме того, мы наблюдаем, что производительность чтения ниже, чем при операциях записи для количества потоков от 16 до 128, а затем производительность чтения начинает масштабироваться. Это связано с тем, что хотя операция чтения PCIe является непроведенной операцией, требующей как запроса, так и завершения, операция записи PCIe — это операция «запустил и забыл». После передачи пакета уровня транзакции на уровень канала данных операция завершается. Операция записи — это «проведенная» операция, которая состоит только из запроса.
Пропускная способность чтения обычно ниже, чем пропускная способность записи, поскольку для чтения требуется две транзакции, а не одна запись для одного и того же объема данных. PCI Express использует модель разделенной транзакции для операций чтения. Операция чтения включает в себя следующие шаги:
Пропускная способность при чтении зависит от времени задержки между отправкой запроса на чтение и времени, необходимого заверителю для возврата данных. Однако, если приложение отправляет достаточное количество запросов на чтение для устранения этой задержки, пропускная способность увеличивается. Именно поэтому, когда производительность чтения ниже, чем у операций записи при количестве потоков от 16 до 128, мы наблюдали увеличенную пропускную способность при увеличении количества запросов. Более низкая пропускная способность наблюдалась, когда инициатор ожидает завершения перед отправкой последующих запросов. Более высокая пропускная способность регистрируется, когда отправляется несколько запросов, чтобы компенсировать задержку после возврата первых данных.
Для оценки производительности произвольных операций ввода-вывода использовался IOzone в произвольном режиме. Испытания проводились на количестве потоков от 4 до 1024. Параметр прямого ввода-вывода (-I) использовался для запуска IOzone, чтобы все операции обходили кэш-память буфера и направлялись непосредственно на диск. Количество использованных полос BeeGFS — 3, размер блока — 2 Мбайт. В IOzone используется размер запроса 4 КиБ. Производительность измеряется в операциях ввода-вывода в секунду (IOPS). Кэш ОС был удален между запусками на серверах и клиентах 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 для 1 файла IOR, а также дополнительные сведения о рекомендациях по проектированию, настройке и конфигурации.