Готовое решение Dell EMC для хранилищ НРС PixStor — расширение емкости

Нет

Содержание

1. Введение
   1. Архитектура решения
   2. Компоненты решения
2. Характеристики производительности
   1. Последовательные клиенты производительности IOzone N для N-файлов
   2. Производительность последовательного IOR N для клиентов с 1 файлом
   3. Случайные небольшие блоки IOzone Performance N clients to N files
   4. Производительность метаданных с помощью MDtest при использовании пустых файлов
   5. Производительность метаданных с помощью MDtest при использовании 4 файлов кибибайт
3. Выводы и планы на будущее

 

---

Введение

Современные среды ВЫСОКОПРОизводительных вычислений повышают спрос на высокоскоростное хранилище, которое также часто требует большой емкости и распределенного доступа с помощью нескольких стандартных протоколов, таких как 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) 80–12 Тбайт, 3,5-дюймовые жесткие диски NL SAS3 , варианты 900 Гбайт @15K, 1,2 Тбайт @10K, 1,8 Тбайт @10K, 2,4 Тбайт @10K, 4 Тбайт NLS, 8 Тбайт NLS, 10 Тбайт NLS, 12 Тбайт NLS.     8 LUN, линейный RAID 6 8+2, размер фрагмента 512 Кбайт. 4 твердотельных накопителя SAS3 емкостью 1,92 Тбайт для метаданных — 2 накопителя RAID 1 (или 4 глобальных резервных жестких диска, если используется дополнительный модуль метаданных с высоким спросом)
Опциональная подсистема хранения метаданных с высоким спросом		От 1 до 2 твердотельных накопителей Dell EMC PowerVault ME4024 (4 накопителя ME4024 при необходимости, только в большой конфигурации) 24 2,5-дюймовых твердотельных накопителя SAS3 по 960 Гбайт (варианты: 480 Гбайт, 960 Гбайт, 1,92 Тбайт) 12 LUN, линейный RAID 1.
Контроллеры 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 вычислительных узлов, Когда требовалось большее количество потоков, эти потоки равномерно распределялись на вычислительных узлах (т. е. 32 потока = 2 потока на узел, 64 потока = 4 потока на узел, 128 потоков = 8 потоков на узел, 256 потоков = 16 потоков на узел, 512 потоков = 32 потока на узел, 1024 потока = 64 потока на узел. Целью было моделировать большее количество параллельных клиентов с ограниченным количеством вычислительных узлов. Поскольку эталонные тесты поддерживают большое количество потоков, для каждого теста использовалось максимальное значение до 1024 (задано для каждого теста), при этом избегая чрезмерного переключения контекста и других связанных побочных эффектов, влияющих на результаты производительности.

Таблица 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 потоков и переключение контекста влияли на результаты, сообщается о меньшем количестве, чем реальная производительность решения.

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

Поскольку на производительность можно перейти общее количество операций ввода-вывода, количество файлов в каталоге и количество потоков, было решено сохранить фиксированное общее количество файлов на 2 файла MiB (2^21 = 2097152), количество файлов на каталог, исправленное на 1024, и количество каталогов, измененное по мере изменения количества потоков, как показано в табл. 3.

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