Для всех указанных выше эталонных тестов на тестовом стенде использовались клиенты, описанные в таблице 2 ниже. Поскольку количество вычислительных узлов, доступных для тестирования, составляло всего 16, когда требовалось большее количество потоков, эти потоки равномерно распределялись по вычислительным узлам (т. е. 32 потока = 2 потока на узел, 64 потока = 4 потока на узел, 128 потоков = 8 потоков на узел, 256 потоков =16 потоков на узел, 512 потоков = 32 потока на узел, 1024 потока = 64 потока на узел). Целью было моделирование большего количества одновременно работающих клиентов с ограниченным количеством доступных вычислительных узлов. Поскольку некоторые эталонные тесты поддерживают большое количество потоков, использовалось максимальное значение до 1024 (указанное для каждого теста), избегая влияния чрезмерного переключения контекста и других связанных побочных эффектов на результаты производительности.

Таблица 2. Тестовый стенд для клиентов

Последовательная производительность IOzone N клиентов для N файлов

Производительность последовательных клиентов N для N файлов измерялась с помощью IOzone версии 3.487. Выполняемые тесты варьировались от одного потока до 1024 потоков, увеличиваясь по степени числа 2.

Эффекты кэширования на серверах были сведены к минимуму путем настройки пула страниц GPFS на 16 ГиБ и использования файлов, размер которых в два раза превышает этот размер. Важно отметить, что для настраиваемых GPFS устанавливается максимальный объем памяти, используемый для кэширования данных, независимо от объема установленной и свободной оперативной памяти. Кроме того, важно отметить, что в предыдущих решениях DellEMC для высокопроизводительных вычислений размер блоков для больших последовательных передач составляет 1 МиБ, GPFS был отформатирован с использованием блоков по 8 МиБ, и поэтому это значение используется в эталонном тесте для оптимальной производительности. Оно может выглядеть слишком большим, и, по-видимому, занимает слишком много места, но GPFS использует распределение подблоков для предотвращения этой ситуации. В текущей конфигурации каждый блок был разделен на 256 подблоков по 32 КиБ каждый.

Следующие команды были использованы для выполнения эталонного теста операций чтения и записи, где значение $Threads было переменной с количеством используемых потоков (от 1 до 1024, увеличивалось по степени числа 2), а файл threadlist использовался для распределения каждого потока на разные узлы методом циклического перебора для равномерного распределения потоков между 16 вычислительными узлами.

Чтобы исключить любые возможные эффекты кэширования данных от клиентов, размер данных в файлах был в два раза больше общего объема оперативной памяти в используемых клиентах. То есть, поскольку каждый клиент имеет 128 ГиБ ОЗУ, для количества потоков, равного или превышающего 16, размер файла составлял 4096 ГиБ, разделенных на количество потоков (для управления этим значением использовалась переменная $Size ниже). В случаях с менее 16 потоками (что означает, что каждый поток выполнялся на отдельном клиенте) размер файла был установлен в два раза больше объема памяти на клиент, то есть 256 ГиБ.

iozone -i0 -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./threadlist
iozone -i1 -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./threadlist

Рис. 2. Последовательная производительность N для N

В результатах можно заметить, что производительность записи увеличивается с увеличением количества используемых потоков, а затем достигает плато около 64 потоков для операций записи и 128 потоков для операций чтения. Затем производительность чтения также быстро возрастает с количеством потоков, а далее остается стабильной до достижения максимального количества потоков, разрешенного IOzone, поэтому последовательная производительность больших файлов стабильна даже для 1024 параллельных клиентов. Производительность записи снижается примерно на 10% при 1024 потоках. Однако, поскольку в клиентском кластере меньше указанного количества ядер, неизвестно, связано ли снижение производительности с заменой и аналогичными издержками, которые не наблюдаются на вращающихся носителях (поскольку задержка NVMe очень низкая по сравнению с вращающимся носителем), или же синхронизация данных RAID 10 становится узким местом. Для уточнения этого момента требуется больше клиентов. Аномалия операций чтения наблюдалась в 64 потоках, когда производительность не масштабировалась со скоростью, наблюдаемой для предыдущих точек данных, а затем в следующей точке данных перемещалась к значению, очень близкому к устойчивой производительности. Для поиска причины такой аномалии требуется дополнительное тестирование, но это не входит в сферу охвата этого блога.

Максимальная производительность чтения для операций чтения была ниже теоретической производительности устройств NVMe (~102 Гбайт/с) или производительности каналов EDR, даже если предположить, что один канал в основном используется для трафика NVMe over Fabrics (4 EDR BW ~96 Гбайт/с).
Однако это не удивительно, так как конфигурация оборудования не сбалансирована по отношению к устройствам NVMe и HCA IB в каждом сокете ЦП. Один адаптер CX6 находится под CPU1, а CPU2 содержит все устройства NVMe и второй адаптер CX6. Любой трафик хранилища, использующий первый HCA, должен использовать UPI для доступа к устройствам NVMe. Кроме того, любое ядро в используемом CPU1 должно получать доступ к устройствам или памяти, назначенным CPU2, поэтому страдает локальность данных и используются ссылки UPI. Это может объяснить снижение максимальной производительности по сравнению с максимальной производительностью устройств NVMe или скоростью линии для HCA CX6. Альтернативой исправлению этого ограничения является сбалансированная конфигурация оборудования, которая подразумевает снижение плотности до половины за счет использования R740 с четырьмя разъемами x16 и использования двух расширителей PCIe x16 для равномерного распределения устройств NVMe на двух ЦП и наличия одного HCA CX6 под каждым ЦП.

Последовательная производительность IOR N клиентов для 1 файла

Последовательная производительность клиентов N для одного общего файла измерялась с помощью IOR версии 3.3.0, а также OpenMPI v4.0.1 для выполнения теста на 16 вычислительных узлах. Выполняемые тесты варьировались от одного потока до 512 потоков, так как не было достаточно ядер для 1024 и более потоков. В этом эталонном тесте для оптимальной производительности использовались блоки по 8 МиБ. В предыдущем разделе тестирования производительности приведено более полное объяснение того, почему это важно.

Эффекты кэширования данных были сведены к минимуму за счет установки для пула страниц GPFS значения 16 ГиБ, а общий размер файла в два раза превышал общий объем ОЗУ в используемых клиентах. То есть, поскольку каждый клиент имеет 128 ГиБ ОЗУ, для количества потоков, равного или превышающего 16, размер файла составлял 4096 ГиБ, и это общее количество было разделено на количество потоков (для управления этим значением использовалась переменная $Size ниже). В случаях с менее 16 потоками (что означает, что каждый поток выполнялся на отдельном клиенте) размер файла был в два раза больше объема памяти на клиент, умноженного на количество потоков, или, другими словами, каждому потоку было предложено использовать 256 ГиБ.

Следующие команды были использованы для выполнения эталонного теста операций чтения и записи, где значение $Threads было переменной с количеством используемых потоков (от 1 до 1024, увеличивалось по степени числа 2), а файл 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 $ G

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 $ G

Рис. 3. Последовательная производительность N для 1

В результатах можно наблюдать высокую производительность чтения и записи независимо от неявной необходимости в механизмах блокировки, так как все потоки получают доступ к одному файлу. Производительность снова повышается очень быстро вместе с количеством используемых потоков, а затем достигает плато относительно стабильной производительности чтения и записи до максимального количества потоков, используемых в этом тесте. Обратите внимание, что максимальная производительность чтения составляла 51,6 Гбайт/с при 512 потоках, но плато производительности достигается примерно при 64 потоках. Аналогичным образом обратите внимание, что максимальная производительность записи 34,5 Гбайт/с достигалась при 16 потоках и достигала плато, которое можно наблюдать до максимального количества используемых потоков.

Производительность произвольных небольших блоков IOzone N клиентов для N файлов

Произвольная производительность клиентов N для N файлов измерялась с помощью IOzone версии 3.487. Выполняемые тесты варьировались от одного потока до 1024 потоков, увеличиваясь по степени числа 2.

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

Эффекты кэширования были снова сведены к минимуму за счет установки для пула страниц GPFS значения 16 ГиБ, и чтобы исключить любые возможные эффекты кэширования данных от клиентов, размер данных в файлах был в два раза больше общего объема оперативной памяти в используемых клиентах. То есть, поскольку каждый клиент имеет 128 ГиБ ОЗУ, для количества потоков, равного или превышающего 16, размер файла составлял 4096 ГиБ, разделенных на количество потоков (для управления этим значением использовалась переменная $Size ниже). В случаях с менее 16 потоками (что означает, что каждый поток выполнялся на отдельном клиенте) размер файла был установлен в два раза больше объема памяти на клиент, то есть 256 ГиБ.

iozone -i0 -I -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./nvme_threadlist                                     <= Create the files sequentially
iozone -i2 -I -c -O -w -r 4k -s $ G -t $Threads -+n -+m ./nvme_threadlist                                      <= Perform the random reads and writes.

Рис. 4. Произвольная производительность N для N

По результатам можно заметить, что производительность записи начинается с высокого значения 6 тыс. IOPS и стабильно увеличивается до 1024 потоков, где, по-видимому, достигается плато с более чем 5 млн IOPS, если можно использовать больше потоков. С другой стороны, производительность чтения начинается с 5 тыс. IOPS и стабильно повышается с количеством используемых потоков (помните, что количество потоков удваивается для каждой точки данных) и достигает максимальной производительности 7,3 млн IOPS при 1024 потоках без признаков приближения к плато. При использовании большего количества потоков требуется более 16 вычислительных узлов, чтобы избежать нехватки ресурсов и излишней замены, что может привести к снижению видимой производительности, когда узлы NVMe могут поддерживать производительность.

Производительность метаданных с MDtest при использовании файлов размером 4 КиБ

Производительность обработки метаданных измерялась с помощью MDtest версии 3.3.0 с поддержкой OpenMPI v4.0.1 для выполнения теста производительности на 16 вычислительных узлах. Выполняемые тесты варьировались от одного потока до 512 потоков. Эталонный тест использовался только для файлов (без метаданных каталогов), получая количество созданий, статистики, операций чтения и удаления, которые может обрабатывать решение, а результаты сравнивались с решением большого размера.

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

Поскольку тот же модуль часто запрашиваемых метаданных использовался для предыдущей сравнительной оценки решения DellEMC Ready Solution для хранилища HPC PixStor, результаты метаданных будут очень похожи на результаты в предыдущих блогах. По этой причине исследования с пустыми файлами не проводились, и вместо этого использовались файлы размером 4 КиБ. Поскольку файлы 4 КиБ не могут поместиться в индексный дескриптор вместе с информацией о метаданных, узлы NVMe будут использоваться для хранения данных для каждого файла. Поэтому MDtest может дать общее представление о производительности небольших файлов для операций чтения и остальных операций метаданных.

Следующая команда была использована для выполнения эталонного теста, где значение $Threads было переменной с количеством используемых потоков (от 1 до 512, увеличивалось по степени числа 2), а файл 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 -w 4K -e 4K

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

Таблица 3. MDtest: распределение файлов в каталогах

Рис. 5. Производительность метаданных — файлы 4 КиБ

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

Система получает очень хорошие результаты, как сообщалось ранее, при достижении пикового значения операций статистики при 64 потоках с почти 6,9 млн операций в секунду, а затем снижается для достижения плато более высокого количества потоков. Операции создания достигают максимума 113 тыс. операций в секунду при 512 потоках, поэтому ожидается, что они будут продолжать увеличиваться при использовании большего количества клиентских узлов (и ядер). Операции чтения и удаления достигли максимума при 128 потоках, достигая пика почти 705 тыс. операций в секунду для операций чтения и 370 тыс. операций в секунду для операций удаления, а затем достигают плато. Операции STAT различаются сильнее, но после достижения пикового значения производительность не падает ниже 3,2 млн операций в секунду для операций STAT. Операции создания и удаления более стабильны, когда они достигают плато и остаются выше 265 тыс. операций в секунду для удаления и 113 тыс. операций в секунду для создания. Наконец, операции чтения достигают плато с производительностью выше 265 тыс. операций в секунду.

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

Узлы NVMe являются важным дополнением к решению для хранения данных HPC, которое обеспечивает очень высокопроизводительный уровень с хорошей плотностью, высокой производительностью произвольного доступа и очень высокой последовательной производительностью. Кроме того, решение линейно масштабируется по емкости и производительности по мере добавления дополнительных модулей узлов NVMe. Производительность узлов NVMe можно просмотреть в таблице 4, ожидается, что она будет стабильной, и эти значения можно использовать для оценки производительности для другого количества узлов NVMe.
Однако помните, что каждая пара узлов NVMe будет обеспечивать половину любого числа, указанного в таблице 4.
Это решение предоставляет заказчикам HPC очень надежную параллельную файловую систему, используемую многими кластерами HPC из списка Top 500. Кроме того, оно предоставляет исключительные возможности поиска, расширенные возможности мониторинга и управления, а также дополнительные шлюзы, позволяющие предоставлять общий доступ к файлам с помощью распространенных стандартных протоколов, таких как NFS, SMB и другие, по мере необходимости.

Таблица 4. Максимальная и стабильная производительность для 2 пар узлов NVMe

Поскольку узлы NVMe использовались только для данных, возможная будущая работа может включать их использование для данных и метаданных и содержать автономный уровень на основе флеш-накопителей с более высокой производительностью метаданных из-за более высокой пропускной способности и более низкой задержки устройств NVMe по сравнению с SSD SAS3 за RAID-контроллерами. Кроме того, если у заказчика чрезвычайно высокие требования к метаданным и он требует решения более плотного, чем может обеспечить модуль часто запрашиваемых метаданных, некоторые или все распределенные устройства RAID 10 можно использовать для метаданных так же, как устройства RAID 1 на ME4024 используются в настоящее время.
Еще один блог, который скоро будет опубликован, будет описывать характеристики узлов PixStor Gateway, которые позволяют подключать решение PixStor к другим сетям с помощью протоколов NFS или SMB и могут горизонтально масштабировать производительность. Кроме того, в ближайшее время решение будет обновлено до HDR100, и ожидается, что в другом блоге будет обсуждаться эта работа.