Skip to main content
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Enjoy members-only rewards and discounts
  • Create and access a list of your products
  • Manage your Dell EMC sites, products, and product-level contacts using Company Administration.

Готовые решения Dell EMC для высокопроизводительного хранилища НРС BeeGFS

Summary: PowerEdge R740xd, PowerEdge R640, PowerSwitch S3048-ON, Mellanox SB7890, BeeGFS v7.1.3, HPC and AI Innovation Lab, HPC, высокопроизводительное решение BeeGFS для хранения данных, IOzone, производительность последовательного чтения и записи, производительность произвольного чтения и записи, BeeGFS High Performance Storage Solution, IOzone, Sequential Read and Write Performance, Random Read and Write Performance ...

This article may have been automatically translated. If you have any feedback regarding its quality, please let us know using the form at the bottom of this page.

Article Content


Symptoms

Автор статьи: Нирмала Сандарараджан (Nirmala Sundararajan), лаборатория Dell EMC HPC and AI Innovation Lab, ноябрь 2019 г.

Cause

Готовые решения Dell EMC для высокопроизводительного хранилища НРС BeeGFS

Resolution

Содержание

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

Введение

Команда Dell EMC 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 SSD NVMe подключаются к коммутатору PCIe, и каждый коммутатор подключается к одному ЦП через плату расширения x16 PCIe. Кроме того, каждый интерфейс IB подключен к одному ЦП. Такая сбалансированная конфигурация, в которой каждый ЦП подключен к одному адаптеру InfiniBand и обрабатывает 12 SSD NVMe, обеспечивает максимальную производительность, гарантируя, что процессоры одинаково заняты обработкой запросов ввода-вывода на накопители NVMe и с них.

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

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

На рис. 1 показана эталонная архитектура решения. Сервер управления подключается к серверам хранения метаданных только через Ethernet. Каждый сервер метаданных и хранения данных имеет два канала InfiniBand и подключен к частной сети через Ethernet. Клиенты имеют один канал InfiniBand и подключаются к частному интерфейсу через Ethernet.
Dell EMC Ready Solutions для хранилищ НРС BeeGFS — эталонная архитектура
Рис. 1.  Dell EMC Ready Solutions для хранилищ НРС 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
* Для обновления микропрограммы SSD Intel P4600NVMe и управления ей

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

Архитектура BeeGFS состоит из четырех основных служб:
  • Служба управления
  • Служба метаданных
  • Служба хранения
  • Клиентские службы
За исключением клиентской службы, которая является модулем ядра, службы управления, метаданных и хранения являются процессами пользовательского пространства. На рис. 2 показано, как эталонная архитектура Dell EMC Ready Solutions для хранилищ HPC BeeGFS сопоставляется с общей архитектурой файловой системы BeeGFS.
Файловая система BeeGFS на PowerEdge R740xd с SSD NVMe
Рис. 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 очень низкие, вместо использования выделенного сервера метаданных для размещения MetaData Targets (MDT) используются только 12 накопителей в зоне NUMA 0, в то время как на остальных 12 накопителях в зоне NUMA размещены Storage Targets (ST).

На рис. 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. Выполняется 6 служб метаданных, каждая из которых обрабатывает один объект MDT. Остальные 12 накопителей хранилища сконфигурированы в 3 дисковых группы RAID 0 по 4 накопителя в каждой. В зоне NUMA 1 выполняются три службы хранения, по одной для каждого объекта ST. Таким образом, сервер, который одновременно размещает метаданные и целевые устройства хранения, содержит 6 объектов MDT и 3 объекта ST. Кроме того, он использует 6 служб метаданных и три службы хранения. Каждый объект MDT представляет собой файловую систему EXT4 на основе конфигурации RAID 1. Объекты ST работают на базе файловой системы XFS, настроенной в конфигурации RAID 0.
 

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

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

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

На каждом сервере хранения настроены 6 групп RAID 0, каждый из 4 накопителей, таким образом, на каждом сервере размещается 6 объектов ST (по 3 на зону NUMA), как показано на рис. 6 ниже.
Конфигурирование дисков на серверах хранения данных
Рис. 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 ниже.

R740xd, 24x NVMe Подробные сведения о сопоставлении процессоров
Рис. 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 для исследований производительности, представленных в этой статье блога.
 
Таблица 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

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

Для оценки последовательных операций чтения и записи использовался эталонный тест 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: 

  • Для параметра tuneTargetChooser в файле конфигурации метаданных задано значение «roundrobin». 
  • Для параметра tuneNumWorkers было установлено значение 24 для метаданных и 32 для хранилища. 
  • Для параметра connMaxInternodeNum присвоено значение 32 для метаданных, 12 для хранилища и 24 для клиентов.

Совокупный размер файла последовательного теста IOzone 8 Тбайт
Рис. 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 потоков, а затем производительность начинала снижаться. При более низком числе потоков производительность операций чтения и записи одинаковая. Поскольку до 8 потоков у нас есть 8 клиентов, записывающих 8 файлов в 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. Ниже приведена команда, используемая для выполнения произвольных операций записи и чтения.

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


Производительность произвольного чтения и записи с использованием IOzone с совокупным размером файла 8 Тбайт
Рис. 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, а также дополнительные сведения о рекомендациях по проектированию, настройке и конфигурации.


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

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

Article Properties


Affected Product

PowerSwitch S3048-ON, Mellanox SB7800 Series, PowerEdge R640, PowerEdge R740XD

Last Published Date

25 Mar 2024

Version

7

Article Type

Solution