Готовое решение Dell EMC для хранилищ НРС PixStor — расширение емкости
Summary: Готовое решение Dell EMC для хранилищ НРС PixStor — расширение емкости
Symptoms
Автор: Джон Догегос из лаборатории HPC and AI Innovation Lab, апрель 2020 г.
Cause
Resolution
Содержание
- Введение
- Архитектура решения
- Компоненты решения
- Характеристики производительности
- Последовательные клиенты производительности IOzone N для N-файлов
- Производительность последовательного IOR N для клиентов с 1 файлом
- Случайные небольшие блоки IOzone Performance N clients to N files
- Производительность метаданных с помощью MDtest при использовании пустых файлов
- Производительность метаданных с помощью MDtest при использовании 4 файлов кибибайт
- Выводы и планы на будущее
Введение
Современные среды ВЫСОКОПРОизводительных вычислений повышают спрос на высокоскоростное хранилище, которое также часто требует большой емкости и распределенного доступа с помощью нескольких стандартных протоколов, таких как NFS, SMB и др. На эти высокие требования HPC обычно распространяются параллельные файловые системы, которые обеспечивают параллельный доступ к одному файлу или набору файлов с нескольких узлов, очень эффективно и безопасно распределяют данные между несколькими lun на нескольких серверах.Архитектура решения
Этот блог представляет собой параллельное решение параллельной файловой системы (PFS) для сред HPC — готового решения Dell EMC для систем хранения данных HPC PixStor, в котором массивы PowerVault ME484 EBOD используются для увеличения емкости решения. Рис. 1. представляет эталонную архитектуру, которая описывает добавление SAS для расширения емкости в существующие массивы хранения Данных PowerVault ME4084.Решение PixStor включает в себя широко распространенную параллельную файловую систему Spectrum Scale, которая также называется компонентом PFS, в дополнение ко многим другим программным компонентам Arcastream, таким как расширенная аналитика, упрощенное администрирование и мониторинг, эффективный поиск файлов, расширенные возможности шлюза и многие другие.
Рис. 1. Эталонная архитектура.
Компоненты решения
Планируется, что это решение будет выпущено с новейшими масштабируемыми процессорами Intel Xeon Xeon 2-го поколения, процессорами Cascade Lake и некоторыми серверами, которые будут использовать самый быстрый доступный объем ОЗУ (2933 МТ/с). Однако, поскольку в настоящее время доступно оборудование для работы с прототипом решения для характеристики производительности, серверы на базе масштабируемых процессоров Intel Xeon Xeon 1-го поколения (например, Xeon). Для характеристик этой системы использовались процессоры Skylake и в некоторых случаях более медленная оперативная память. Поскольку узким местом решения являются контроллеры SAS массивов DellEMC PowerVault ME40x4, после замены процессоров Skylake и ОЗУ на процессоры Cascade Lake и более быструю ОЗУ существенного несоответствия производительности не ожидается. Кроме того, решение было обновлено до последней версии PixStor (5.1.1.4), которая поддерживает RHEL 7.7 и OFED 4.7 для характеристик системы.Из-за ранее описанной ситуации в табл. 1 содержится список основных компонентов решения, но при возникновении расхождений первый столбец описания содержит компоненты, используемые во время выпуска и, следовательно, доступные для заказчиков, а последний столбец — компоненты, которые фактически используются для описания производительности решения. Накопители, перечисленные для данных (NLS 12 Тбайт) и метаданных (SSD-накопители 960 Гбит/с), — это накопители, используемые для оценки производительности. Более быстрые накопители могут обеспечивать более эффективные показатели произвольных операций ввода-вывода в секунду и могут улучшить операции создания/удаления метаданных.
Наконец, для полноты был включен список возможных жестких дисков данных и твердотельных накопителей метаданных, который основан на поддерживаемых дисках, как перечислено в таблице поддержки DellEMC PowerVault ME4, доступной онлайн.
Таблица 1 Компоненты, используемые во время выпуска и используемые в тестовом стенде
| Компонент решения |
В выпуске |
Тестовая стенд |
|
| Возможность внутреннего подключения |
Dell Networking S3048-ON Gigabit Ethernet |
||
| Подсистема хранения данных |
1–4 системы Dell EMC PowerVault ME4084 От 1 до 4 жестких дисков Dell EMC PowerVault ME484 (по одному на ME4084) |
||
| Опциональная подсистема хранения метаданных с высоким спросом |
От 1 до 2 твердотельных накопителей Dell EMC PowerVault ME4024 (4 накопителя ME4024 при необходимости, только в большой конфигурации) |
||
| Контроллеры RAID-системы хранения |
SAS 12 Гбит/с |
||
| Емкость при настроенной конфигурации |
Сырой: 8064 Тбайт (7334 ТиБ или 7,16 ПиБ) в формате ~ 6144 Гбайт (5588 ТиБ или 5,46 ПиБ) |
||
| Процессор |
Gateway |
2 процессора Intel Xeon Gold 6230, 2,1 ГГц, 20 ядер/40 потоков, 10,4 ГТ/с, кэш 27,5 Мбайт, Turbo, HT (125 Вт), DDR4 2933 МГц |
- |
| Метаданные с высоким спросом |
2 12-ядерных процессора Intel Xeon Gold 6136, 3,0 ГГц |
||
| Узел хранения |
2 12-ядерных процессора Intel Xeon Gold 6136, 3,0 ГГц |
||
| Узел управления |
2 процессора Intel Xeon Gold 5220, 2,2 ГГц, 18 ядер/36 потоков, 10,4 ГТ/с, кэш 24,75 Мбайт, Turbo, HT (125 Вт), DDR4 2666 МГц |
2 12-ядерных процессора Intel Xeon Gold 5118, 2,3 ГГц |
|
| Модули |
Gateway |
12 модулей RDIMM 16 ГиБ, 2933 МТ/с (192 ГиБ) |
- |
| Метаданные с высоким спросом |
24x 16GiB 2666 MT/s RDIMM (384 GiB) |
||
| Узел хранения |
24x 16GiB 2666 MT/s RDIMM (384 GiB) |
||
| Узел управления |
12 модулей DIMM емкостью 16 Гбайт, 2666 МТ/с (192 ГиБ) |
12 модулей RDIMM 8 ГиБ, 2666 МТ/с (96 ГиБ) |
|
| Операционная система |
Red Hat Enterprise Linux 7.6 |
Red Hat Enterprise Linux 7.7 |
|
| Версия ядра |
3.10.0-957.12.2.el7.x86_64 |
3.10.0-1062.9.1.el7.x86_64 |
|
| ПО PixStor |
5.1.0.0 |
5.1.1.4 |
|
| Масштабируемость спектра (GPFS) |
5.0.3 |
5.0.4-2 |
|
| Высокопроизводительное сетевое подключение |
Двухпортовая плата Mellanox ConnectX-5 InfiniBand EDR/100 GbE и 10 GbE |
Mellanox ConnectX-5 InfiniBand EDR |
|
| Высокопроизводительный коммутатор |
2 коммутатора Mellanox SB7800 (HA — с резервированием) |
1 mellanox SB7700 |
|
| Версия OFED |
Mellanox OFED-4.6-1.0.1.0 |
Mellanox OFED-4.7-3.2.9 |
|
| Локальные диски (ОС и анализ/мониторинг) |
Все серверы, кроме узла управления 3 твердотельных накопителя SAS3 емкостью 480 Гбайт (RAID1 + HS) для ОС RAID-контроллер PERC H730P Узел управления 3 твердотельных накопителя SAS3 емкостью 480 Гбайт (RAID1 + HS) для ОС RAID-контроллер PERC H740P |
Все серверы, кроме узла управления 2 диска SAS 300 Гбайт, 15 000 об/мин (RAID 1) для ОС RAID-контроллер PERC H330 Узел управления 5 накопителей SAS 300 Гбайт, 15 000 об/мин (RAID 5) для ОС и анализа RAID-контроллер PERC H740P |
|
| Управление системами |
iDRAC 9 Enterprise + DellEMC OpenManage |
iDRAC 9 Enterprise + DellEMC OpenManage |
|
Характеристики производительности
Чтобы охарактеризовать это новое решение Ready Solution, мы использовали оборудование, указанное в последнем столбце таблицы 1, включая дополнительный модуль метаданных с высоким спросом. Для оценки производительности решения использовались следующие эталонные тесты:- Последовательное значение IOzone N–N
- Последовательное значение IOR N к 1
- Случайная IOzone
- Тест MDtest
Таблица 2. Стенд для тестирования клиента
| Количество клиентских узлов |
16 |
| Клиентский узел |
C6320 |
| Количество процессоров на клиентский узел |
2 18-ядерных процессора Intel(R) Xeon(R) Gold E5-2697v4, 2,3 ГГц |
| Память на клиентский узел |
12 модулей RDIMM 16 ГиБ, 2400 МТ/с |
| BIOS |
2.8.0 |
| Ядро ОС |
3.10.0-957.10.1 |
| Версия GPFS |
5.0.3 |
Последовательные клиенты производительности IOzone N для N-файлов
Производительность последовательного «N clients to N files» измерялась в IOzone версии 3.487. Тесты различались в диапазоне от одного потока до 1024 потоков, и результаты решения с расширенной емкостью (4 массива ME4084 + 4 модуля ME484) контрастируют с решением большого размера (4 массива ME4084). Последствия кэширования были сведом к минимуму: пул страниц GPFS был установлен в значение 16 ГиБ, а размер файлов был в два раза больше. Важно отметить, что для GPFS, который не может установить максимальный объем памяти, используемой для кэширования данных, независимо от объема установленной оперативной памяти и свободного места. Кроме того, важно отметить, что, хотя в предыдущих решениях Dell EMC для ВЫСОКОПРОИЗВОДИТЕЛЬНЫХ ВЫЧИСЛЕНИЙ размер блока для крупной последовательной передачи составляет 1 МиБ, формат GPFS был отформатирован с 8 блоками МиБ и поэтому значение используется в эталонном тесте для оптимальной производительности. Это может выглядеть слишком большим и, на практике, слишком большим объемом пространства, но GPFS использует распределение субблока для предотвращения такой ситуации. В текущей конфигурации каждый блок был подразделирован на 256 подблок по 32 кибибайт каждый.Для выполнения эталонного теста операций записи и чтения использовались следующие команды, где Потоки были переменной с количеством используемых потоков (с 1 по 1024 с добавлением с помощью двух), а список потоков — файл, который выделял каждый поток на разных узлах, используя циклический перебор для равномерного распространения потоков между 16 вычислительными узлами.
./iozone -i0 -c -e -w -r 8M -s 128G -t $Threads -+n -+m ./threadlist
./iozone -i1 -c -e -w -r 8M -s 128G -t $Threads -+n -+m ./threadlist
Рис. 2. Последовательная производительность с N на N
Результаты показывают, что производительность очень быстро растущих с количеством используемых клиентов, а затем достигает стабилена, который стабилен, пока не достигается максимальное количество потоков, которое разрешает IOzone, и поэтому стабильная производительность последовательных файлов большого файла даже для 1024 параллельных клиентов. Обратите внимание, что производительность чтения и записи в два раза больше дисков. Максимальная производительность чтения была ограничена пропускной способностью двух каналов IB EDR, используемых на узлах хранения от 8 потоков, и массивы ME4 могут иметь дополнительную производительность. Обратите внимание, что максимальная производительность записи увеличись с 16,7 до 20,4 Гбайт/с при 64 и 128 потоках и ближе к максимальным техническим характеристикам массивов ME4 (22 Гбайт/с).
Здесь важно помнить, что предпочтительный режим работы GPFS разбраснен, и решение было отформатировано для использования в таком режиме. В этом режиме блоки выделяются из самого начала работы псевдопамятью, распределяя данные по всей поверхности каждого жесткого диска. Хотя очевидный недостаток — это меньший начальный максимальный уровень производительности, этот уровень производительности сохраняется довольно постоянной независимо от того, сколько места используется в файловой системе. В отличие от других параллельных файловых систем, которые изначально используют внешние дорожки, которые могут содержать больше данных (секторов) на дисковую революцию и поэтому имеют максимальную производительность, которую могут обеспечить жесткие диски, но, поскольку система использует больше места, используются внутренние дорожки с меньшим объемом данных на революцию, что, в свою очередь, позволяет сократить производительность.
Производительность последовательного IOR N для клиентов с 1 файлом
Производительность одного общего файла для последовательных клиентов N измерялась iOR версии 3.3.0 при помощи OpenMPI версии 4.0.1 для выполнения эталонного теста для 16 вычислительных узлов. Тесты проводились в диапазоне от одного потока до 512 потоков (поскольку ядер было недостаточно для 1024 потоков), и результаты были контрастными с решением без расширения емкости.Последствия кэширования были сведом к минимуму: пул страниц GPFS был установлен в значение 16 ГиБ, а размер файлов был в два раза больше. В этих эталонных тестах для оптимальной производительности использовались 8 блоков MiB. Более подробное описание этих вопросов приведено в предыдущем разделе тестирования производительности.
Для выполнения эталонного теста операций записи и чтения использовались следующие команды, где Потоки были переменной с количеством используемых потоков (с 1 по 1024 с инкрементами по двум), а my_hosts.$Threads — это соответствующий файл, который выделял каждый поток на разных узлах, используя циклический перебор для равномерного распределения между 16 вычислительными узлами.
mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -w -s 1 -t 8m -b 128G
mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -r -s 1 -t 8m -b 128G
Рис. 3. Последовательная производительность с коэффициентом от N до 1
. По результатам мы снова видим, что дополнительные накопители обеспечивают производительность чтения и записи. Производительность снова очень высокая с количеством используемых клиентов, а затем достигает стабилена, которая достаточно стабильна для операций чтения и записи до максимального количества потоков, используемых в этом тесте. Обратите внимание, что максимальная производительность чтения составляет 24,8 Гбайт/с при 16 потоках, а узким местом был интерфейс InfiniBand EDR, а массивы ME4 по-прежнему имеют дополнительную производительность. С этого момента производительность чтения уменьшаась с этого значения до достижения уровня 23,8 Гбайт/с. Обратите внимание, что максимальная производительность записи 19.3 достигается при 8 потоках и достигает затор.
Случайные небольшие блоки IOzone Performance N clients to N files
Производительность случайных N-клиентов и N файлов измерялась с помощью FIO версии 3.7, а не традиционной Iozone. Как было указано в предыдущем блоге, цель была заключается в том, чтобы воспользоваться преимуществами большей глубины очереди для изучения максимальной возможной производительности, которую могут обеспечить массивы ME4084 (предыдущие тесты для разных решений ME4 показали, что массивам ME4084 требуется большее давление ввода-вывода, которое может обеспечить Iozone для достижения ограничений произвольного ввода-вывода).Тесты различались в диапазоне от одного потока до 512 потоков, поскольку количество клиентских ядер не могло быть достаточно для 1024 потоков. Каждый поток использовал разный файл, и потокам был назначен циклический перебор на узлах клиента. В этом эталонном тесте использовались 4 блока кибибайт для эмуляции трафика небольших блоков и при использовании глубины очереди 16. Сравниваются результаты использования решения большого размера и увеличения емкости.
Эффекты кэширования были снова минимизированы: пул страниц GPFS был не в состоянии использовать 16 ГиБ и с помощью файлов, в два раза большего размера. В первом разделе тестирования производительности приведено более полное объяснение того, почему это значение введите в GPFS.
Рис. 4.
Производительность произвольной записи с N на основе результатов, как мы видим, начинается с 29,1 тыс. операций ввода-вывода в секунду и непрерывно увеличивается до 64 потоков, где кажется, что она останавливается на уровне около 40 000 IOps. С другой стороны, производительность чтения начинается с 1,4 тыс. операций ввода-вывода в секунду и повышает производительность практически линейно с количеством используемых клиентов (обратите внимание, что количество потоков удваивается для каждой точки данных) и достигает максимальной производительности 25 600 IOPS при 64 потоках, где, кажется, приближается к достижению разгона. Для использования большего количества потоков потребуется более 16 вычислительных узлов, чтобы избежать нехватки ресурсов и снижения очевидной производительности, в то время как массивы могут поддерживать производительность.
Производительность метаданных с помощью MDtest при использовании пустых файлов
Производительность метаданных измерялась с помощью MDtest версии 3.3.0 при помощи OpenMPI 4.0.1 для выполнения эталонного теста для 16 вычислительных узлов. Выполняемые тесты различались в диапазоне от одного потока до 512 потоков. Эталонный тест использовался только для файлов (без метаданных каталогов), для получения количества создания, статистики, операций чтения и удаления решения. Результаты были контрастными с решением большого размера.Для правильной оценки решения по сравнению с другими решениями Dell EMC для хранения данных HPC и предыдущими результатами блога использовался дополнительный модуль метаданных с высоким спросом, но с одним массивом ME4024 даже для большой конфигурации и тестирования в этой работе было назначено два модуля ME4024. Этот модуль метаданных с высоким спросом может поддерживать до четырех массивов ME4024. Перед добавлением другого модуля метаданных рекомендуется увеличить количество массивов ME4024 до 4. Ожидается, что дополнительные массивы ME4024 линейно повысят производительность метаданных с каждым дополнительным массивом, за исключением операций Stat (и операций чтения для пустых файлов), поскольку количество очень высоки, в какой-то момент ЦП станут узким местом, а производительность не будет продолжать линейно увеличиваться.
Для выполнения эталонного теста использовалась следующая команда, где Потоки были переменной с количеством используемых потоков (с 1 по 512 инкрементами с помощью двух), а my_hosts.$Threads — это соответствующий файл, который выделял каждый поток на разных узлах, используя циклический перебор для их однородного распространения между 16 вычислительными узлами. Как и в случае эталонного теста произвольных операций ввода-вывода, максимальное количество потоков было ограничено 512, поскольку количество ядер недостаточно для 1024 потоков и переключение контекста влияли на результаты, сообщается о меньшем количестве, чем реальная производительность решения.
Поскольку на производительность можно перейти общее количество операций ввода-вывода, количество файлов в каталоге и количество потоков, было решено сохранить фиксированное общее количество файлов на 2 файла MiB (2^21 = 2097152), количество файлов на каталог, исправленное на 1024, и количество каталогов, измененное по мере изменения количества потоков, как показано в табл. 3.mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefix /mmfs1/perftest/ompi --mca btl_openib_allow_ib 1 /mmfs1/perftest/lanl_ior/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F
Таблица 3. Распределение файлов по каталогам по MDtest
| Количество потоков |
Количество каталогов на поток |
Общее количество файлов |
| 1. |
2048 |
2,097,152 |
| 2. |
1024 |
2,097,152 |
| 4. |
512 |
2,097,152 |
| 8 |
256 |
2,097,152 |
| 16 |
128 |
2,097,152 |
| 32 |
64 |
2,097,152 |
| 64 |
32 |
2,097,152 |
| 128 |
16 |
2,097,152 |
| 256 |
8 |
2,097,152 |
| 512 |
4. |
2,097,152 |
| 1024 |
2. |
2,097,152 |
Рис. 5. Производительность метаданных — пустые файлы
Во-первых, обратите внимание, что выбранная масштабируемость была logarithmic с основанием 10, что позволяет сравнивать операции с разницей в несколько порядка. В противном случае некоторые операции будут выглядеть как плоская линия, близкое к 0, на обычном графике. График журналов с основанием 2 может быть более подходящим, поскольку количество потоков увеличивается с помощью 2, но график будет очень похожим, и люди, как правило, обрабатывают и запоминают лучшее число на основе питания 10.
Система получает очень хорошие результаты, когда операции Stat и Read достигают пикового значения в 64 потока, при этом операций ввода-вывода в секунду почти 11 млн и 4,7 млн операций в секунду соответственно. Операции удаления достигли максимального значения в 170,6 тыс. операций при 16 потоках, а операции создания достигли максимального значения при 32 потоках при 222,1 тыс. операций в секунду. Операции Stat и Read имеют более высокую изменчивость, но после достижения максимального значения производительность не опуститесь ниже 3 млн операций в секунду для статистики и 2 млн операций в секунду для операций чтения. Создание и удаление более стабильны после достижения стабилении и остаются более 140 000 операций удаления и 120 000 операций для создания. Обратите внимание, что дополнительные диски не влияют на большую часть операций с метаданными в пустых файлах, как ожидалось.
Производительность метаданных с помощью MDtest при использовании 4 файлов кибибайт
Этот тест практически идентичен предыдущему, за исключением того, что вместо пустых файлов использовались небольшие файлы размером 4 Кбайт.Для выполнения эталонного теста использовалась следующая команда, где Потоки были переменной с количеством используемых потоков (с 1 по 512 инкрементами с помощью двух), а my_hosts.$Threads — это соответствующий файл, который выделял каждый поток на разных узлах, используя циклический перебор для их однородного распространения между 16 вычислительными узлами.
mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefix /mmfs1/perftest/ompi --mca btl_openib_allow_ib 1 /mmfs1/perftest/lanl_ior/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F -w 4K -e 4K
Рис. 6. Производительность метаданных — небольшие файлы (4K)
Система получает очень хорошие результаты для операций Stat и Removal, достигая максимального значения при 256 потоках со значением 8,2 млн операций в секунду и 400 000 операций в секунду соответственно. Операции чтения достигли максимального значения в 44,8 тыс. операций и операций создания, достигая максимального значения с 68,1 тыс. операций в секунду (обе операции при 512 потоках). Операции Stat и Removal имеют более изменчивость, но после достижения максимального значения производительность не опуститесь ниже 3 млн операций в секунду для статистики и 280 000 операций для удаления. Создание и чтение имеют меньшую изменчивость и продолжают расти по мере увеличения количества потоков. Как можно наблюдать, дополнительные диски расширения емкости обеспечивают только незначительные изменения в производительности метаданных.
Поскольку эти цифры предназначены для модуля метаданных с одним массивом ME4024, производительность каждого дополнительного массива ME4024 будет возрастать, однако нельзя предположить линейное увеличение для каждой операции. Если весь файл не помещается в индексный дескриптор для такого файла, целевые данные на ME4084 будут использоваться для хранения файлов 4K, что в определенной степени ограничивает производительность. Поскольку индексный дескриптор имеет размер 4 Кбайт и по-прежнему необходимо хранить метаданные, в него будут вместить только файлы около 3 кибибайт, и любой файл больше, чем файл, который будет использовать целевые данные.
Выводы и планы на будущее
Решение с расширенной емкостью удалось повысить производительность не только для произвольных доступов, но и для последовательной производительности. Это было ожидаемо, так как в разрозненном режиме ведет себя как случайный доступ, и наличие большего количества дисков позволяет улучшить это. Ожидается, что производительность, представленная в табл. 4, будет стабильной для пустой файловой системы до тех пор, пока она почти не будет заполнена. Кроме того, по мере добавления дополнительных модулей узлов хранения данных решение линейно масштабируется по емкости и производительности. Кроме того, можно ожидать аналогичного увеличения производительности за счет опционального модуля метаданных с высоким спросом. Это решение предоставляет заказчикам HPC очень надежную параллельную файловую систему, используемую многими из 500 кластеров HPC из топ-500. Кроме того, это решение предоставляет исключительные возможности поиска, расширенные возможности мониторинга и управления, а также дополнительные шлюзы, которые обеспечивают общий доступ к файлам с помощью стандартных протоколов NFS, SMB и т. д. для нужного количества клиентов.
Таблица 4 Пиковая и стабильная производительность
|
|
Максимальная производительность |
Стабильная производительность |
||
| Написать |
Чтение |
Написать |
Чтение |
|
| Крупные последовательные N-клиенты для N-файлов |
20,4 Гбайт/с |
24,2 Гбайт/с |
20,3 Гбайт/с |
24 Гбайт/с |
| Крупные последовательные N-клиенты в одном общем файле |
19,3 Гбайт/с |
24,8 Гбайт/с |
19,3 Гбайт/с |
23,8 Гбайт/с |
| Случайные малые блоки N клиенты N к N-файлам |
40 KIOps |
25,6 КИОп |
40,0 КИОп |
19.3KIOps |
| Метаданные Создание пустых файлов |
169 400 IOps |
123 500 IOps |
||
| Стат метаданных пустые файлы |
11 млн IOps |
3,2 млн IOps |
||
| Чтение пустых файлов метаданных |
4,7 млн операций ввода-вывода в секунду |
2,4 млн IOps |
||
| Удаление пустых файлов с метаданных |
170,6 тыс. операций ввода-вывода в секунду |
156 500 IOps |
||
| Создание файлов с метаданными по 4 Кбайт |
68 100 IOps |
68 100 IOps |
||
| Файлы метаданных Stat 4KiB |
8,2 млн операций ввода-вывода в секунду |
3 млн IOps |
||
| Чтение метаданных 4 Кбайт файлов |
44 800 IOps |
44 800 IOps |
||
| Удаление 4 Кбайт-файлов с метаданными |
400 000 IOps |
280 000 IOps |
||
Поскольку решение предназначено для выпуска с процессорами Cascade Lake и более высокой скоростью ОЗУ, после завершения настройки системы будут выполняться некоторые проверки места производительности. Протестируйте дополнительный модуль метаданных с высоким спросом, в котором должны быть как минимум 2 файла ME4024 и 4 Кбайт, чтобы лучше документировать масштабирование производительности метаданных при использовании целевых данных. Кроме того, производительность узлов шлюза будет измеряться и отображаться вместе с соответствующими результатами проверок в новом блоге или техническом документе. Наконец, планируется протестировать и выпуск дополнительных компонентов решения, чтобы предоставить еще больше возможностей.