Готовое решение Dell EMC для хранилищ НРС PixStor
Summary: Эталонная архитектура для решения, а также первоначальная оценка производительности.
Symptoms
Статья написана Марио Гальегосом из лаборатории HPC and AI Innovation Lab, октябрь 2019 г.
Cause
Resolution
Содержание
- Введение
- Архитектура решения
- Компоненты решения
- Характеристики производительности
- Последовательная производительность IOzone N клиентов для N файлов
- Последовательная производительность IOR N клиентов для 1 файла
- Производительность произвольных небольших блоков IOzone N клиентов для N файлов
- Производительность метаданных с MDtest при использовании пустых файлов
- Производительность метаданных с MDtest при использовании файлов размером 4 КиБ
- Производительность метаданных при использовании MDtest с файлами 3K
- Расширенная аналитика
- Выводы и планы на будущее
Введение
Современные среды HPC предъявляют повышенные требования к высокоскоростному хранилищу, которое также часто требует большой емкости и распределенного доступа с помощью нескольких стандартных протоколов, таких как NFS, SMB и т. д. Эти высокие требования к HPC обычно покрываются параллельными файловыми системами, которые обеспечивают одновременный доступ к одному файлу или набору файлов с нескольких узлов, очень эффективно и безопасно распределяя данные по нескольким LUN на нескольких серверах.Архитектура решения
В этом блоге мы представляем новейшее дополнение Dell EMC к решениям параллельных файловых систем (PFS) для сред HPC — Dell EMC Ready Solution для хранилищ HPC PixStor Storage. На рис. 1 показана эталонная архитектура, в которой используются серверы Dell EMC PowerEdge R740 и массивы хранения данных PowerVault ME4084 и ME4024 с программным обеспечением PixStor от нашей партнерской компании Arcastream.PixStor включает в себя широко распространенную файловую систему General Parallel File System, также известную как Spectrum Scale, в качестве компонента PFS, в дополнение к программным компонентам Arcastream, таким как расширенная аналитика, упрощенное администрирование и мониторинг, эффективный поиск файлов, расширенные возможности шлюза и многие другие.
Рисунок 1: Эталонная архитектура.
Компоненты решения
Планируется выпустить это решение с масштабируемыми процессорами Intel Xeon 2-го поколения (Cascade Lake), а также на некоторых серверах будет использоваться самая быстрая доступная оперативная память (2933 МТ/с). Однако из-за аппаратного обеспечения для создания прототипа решения и определения его производительности серверы с масштабируемыми процессорами Intel Xeon 1-го поколения Использовались процессоры Skylake и более медленная оперативная память. Поскольку узким местом решения являются SAS-контроллеры массивов Dell EMC PowerVault ME40x4, после замены ЦП и ОЗУ Skylake на предполагаемые ЦП Cascade Lake с более быстрыми ОЗУ существенной разницы в производительности не ожидается. Кроме того, несмотря на то, что на момент настройки системы была доступна последняя версия PixStor, поддерживающая RHEL 7.6, было решено продолжить процесс контроля качества и использовать Red Hat® Enterprise Linux® 7.5 и предыдущую минорную версию PixStor для характеристики системы. После обновления системы до процессоров Cascade Lake программное обеспечение PixStor также будет обновлено до последней версии, и будут выполнены некоторые выборочные проверки производительности, чтобы убедиться, что производительность остается близкой к показателям, указанным в этом документе.Из-за описанной выше ситуации в таблице 1 приведен список основных компонентов решения. В среднем столбце содержатся планируемые компоненты, которые будут использоваться во время выпуска и, следовательно, будут доступны заказчикам, а последний столбец представляет собой список компонентов, фактически используемый для характеристики производительности решения. Перечисленные накопители или данные (NLS 12 Тбайт) и метаданные (SSD 960 Гбайт) используются для определения характеристик производительности, а более быстрые диски могут обеспечить более высокие показатели произвольных операций ввода-вывода в секунду и улучшить операции создания и удаления метаданных.
Наконец, для полноты картины был включен список возможных жестких дисков для хранения данных и твердотельных накопителей для метаданных, основанный на поддерживаемых накопителях, как указано в таблице поддержки Dell EMC PowerVault ME4, доступной через Интернет.
Таблица 1 Компоненты, которые будут использоваться во время выпуска, и компоненты, используемые на испытательном стенде
Характеристики производительности
Для характеристики этого нового готового решения мы использовали оборудование, указанное в последнем столбце таблицы 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 процессора Intel(R) Xeon(R) Gold E5-2697v4, 18 ядер, тактовая частота 2,30 ГГц
Объем памяти на клиентский узел
12 модулей RDIMM, 16 ГБ, 2400 МТ/с
BIOS
2.8.0
Ядро OS
3.10.0-957.10.1
Версия GPFS
5.0.3
Последовательная производительность IOzone N клиентов для N файлов
Производительность последовательных клиентов N для N файлов измерялась с помощью IOzone версии 3.487. Количество выполненных тестов варьировало от одного до 1024 потоков.
Эффекты кэширования были сведены к минимуму путем настройки пула страниц GPFS на 16 ГиБ и использования файлов, размер которых в два раза превышает этот размер. Важно отметить, что для GPFS этот параметр устанавливает максимальный объем памяти, используемый для кэширования данных, независимо от объема установленной и свободной оперативной памяти. Кроме того, важно отметить, что в предыдущих решениях Dell EMC HPC размер блока для больших последовательных передач составлял 1 МиБ, GPFS форматировался с блоками 8 МиБ, поэтому это значение используется в бенчмарке для оптимальной производительности. Оно может выглядеть слишком большим, и, по-видимому, занимает слишком много места, но GPFS использует распределение подблоков для предотвращения этой ситуации. В текущей конфигурации каждый блок был разделен на 256 подблоков по 32 КиБ каждый.
Для выполнения эталонного теста операций записи и чтения использовались следующие команды, где Threads — это переменная с числом используемых потоков (от 1 до 1024, увеличенным в степенях числа 2), а threadlist — это файл, который выделяет каждый поток на отдельном узле с помощью циклического перебора для их равномерного распределения по 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 одновременных клиентов. Обратите внимание, что максимальная производительность чтения составила 23 ГБ/с при 32 потоках, и, скорее всего, узким местом был интерфейс InfiniBand EDR, в то время как массивы ME4 все еще имели дополнительную производительность. Также обратите внимание, что максимальная производительность записи 16,7 была достигнута немного раньше при 16 потоках, и она, по-видимому, низкая по сравнению со спецификациями массивов ME4.
Здесь важно помнить, что предпочтительный режим работы GPFS разбросан, и решение было отформатировано для его использования. В этом режиме блоки выделяются с самого начала псевдослучайным образом, распределяя данные по всей поверхности каждого жесткого диска. Хотя очевидным недостатком является меньшая начальная максимальная производительность, такой уровень производительности поддерживается практически постоянно, независимо от объема используемого пространства в файловой системе. В отличие от других параллельных файловых систем, которые изначально используют внешние дорожки, которые могут содержать больше данных (секторов) за один оборот диска, и, следовательно, обеспечивают максимально возможную производительность, которую могут обеспечить жесткие диски, но поскольку система потребляет больше пространства, используются внутренние дорожки с меньшим количеством данных за один оборот, что приводит к снижению производительности.
Последовательная производительность IOR N клиентов для 1 файла
Последовательная производительность клиентов N для одного общего файла измерялась с помощью IOR версии 3.3.0, а также OpenMPI v4.0.1 для выполнения теста на 16 вычислительных узлах. Количество выполненных тестов варьировало от одного потока до 1024.
Эффекты кэширования были сведены к минимуму путем настройки пула страниц GPFS на 16 ГиБ и использования файлов, размер которых в два раза превышает этот размер. В этом эталонном тесте для оптимальной производительности использовались блоки по 8 МиБ. В предыдущем разделе, посвященном тестам производительности, приведено более полное объяснение этих вопросов.
Для выполнения эталонной проверки операций записи и чтения использовались следующие команды, где 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 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 Последовательная производительность
Из результатов видно, что производительность снова очень быстро возрастает с увеличением количества используемых клиентов, а затем достигает плато, которое является полустабильным для чтения и очень стабильным для записи вплоть до максимального количества потоков, используемых в этом тесте. Таким образом, последовательная обработка больших файлов с одним общим файлом стабильна даже для 1024 одновременных клиентов. Обратите внимание, что максимальная производительность чтения составила 23,7 ГБ/с при 16 потоках, и, скорее всего, узким местом был интерфейс InfiniBand EDR, в то время как массивы ME4 все еще имели дополнительную производительность. Кроме того, производительность чтения снижалась с этого значения до выхода на плато на уровне около 20,5 Гбайт/с, с кратковременным снижением до 18,5 Гбайт/с при 128 потоках. Аналогичным образом, обратите внимание, что максимальная производительность записи 16,5 была достигнута при 16 потоках, что очевидно является низким показателем по сравнению со спецификациями массивов ME4.
Производительность произвольных небольших блоков IOzone N клиентов для N файлов
Производительность между Random N клиентами и N файлами измерялась с помощью IOzone версии 3.487. Количество выполненных тестов варьировало от одного потока до 1024. В этом бенчмарке использовались блоки размером 4 КиБ для эмуляции трафика небольших блоков.
Эффекты кэширования были сведены к минимуму за счет установки переменного пула страниц GPFS на 16 ГиБ и использования файлов в два раза большего размера. В первом разделе тестирования производительности содержится более полное объяснение того, почему это эффективно для GPFS.
Следующая команда использовалась для выполнения теста производительности в режиме случайного ввода-вывода как для записи, так и для чтения, где Threads была переменной с числом используемых потоков (от 1 до 1024, увеличенным в степенях числа 2), а threadlist была файлом, который выделил каждый поток на отдельном узле с помощью циклического перебора для их однородного распределения по 16 вычислительным узлам../iozone -i2 -c -O -w -r 4K -s 32G -t $Threads -+n -+m ./threadlist
Рис. 4. Случайная производительность
от N до N Из результатов видно, что производительность записи начинается с высокого значения почти 8,2 тыс. операций ввода-вывода в секунду и неуклонно растет до 128 потоков, после чего достигает плато и остается близкой к максимальному значению в 16,2 тыс. операций ввода-вывода. С другой стороны, производительность чтения начинается с очень малого при более чем 200 IOPS и увеличивает производительность почти линейно с количеством используемых клиентов (имейте в виду, что количество потоков удваивается для каждой точки данных) и достигает максимальной производительности в 20,4 тыс. IOPS при 512 потоках без признаков достижения максимума. Однако использование большего количества потоков на текущих 16 вычислительных узлах с двумя ЦП каждый, где каждый ЦП имеет 18 ядер, имеет ограничение, заключающееся в том, что не хватает ядер для выполнения максимального количества потоков IOzone (1024) без переключения контекста (16 x 2 x 18 = 576 ядер), что значительно ограничивает производительность. В будущем тестировании с большим количеством вычислительных узлов можно будет проверить, какой производительности произвольного чтения можно достичь при 1024 потоках с IOzone, или IOR можно будет использовать для изучения поведения с более чем 1024 потоками.
Производительность метаданных с MDtest при использовании пустых файлов
Производительность обработки метаданных измерялась с помощью MDtest версии 3.3.0 с поддержкой OpenMPI v4.0.1 для выполнения теста производительности на 16 вычислительных узлах. Выполняемые тесты варьировались от одного потока до 512 потоков. Бенчмарк использовался только для файлов (без метаданных каталогов), чтобы получить количество созданий, статистики, операций чтения и удаления, которое может обработать решение.
Чтобы правильно оценить данное решение в сравнении с другими решениями Dell EMC для хранения данных HPC, был использован опциональный модуль метаданных высокого спроса, но с одним массивом ME4024, хотя в большой конфигурации, испытанной в этой работе, было выделено два массива ME4024.
Этот дополнительный модуль часто запрашиваемых метаданных может поддерживать до четырех массивов ME4024, и рекомендуется увеличить количество массивов ME4024 до 4, прежде чем добавлять еще один модуль метаданных. Ожидается, что дополнительные массивы ME4024 будут линейно увеличивать производительность метаданных с каждым дополнительным массивом, за исключением, возможно, операций Stat (и операций чтения для пустых файлов), поскольку эти показатели очень высоки, в какой-то момент ЦП станут узким местом, и производительность не будет продолжать расти линейно.
Следующая команда была использована для выполнения эталонного теста, где потоки были переменной с количеством используемых потоков (от 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
Поскольку на показатели производительности может влиять общее количество IOPS, количество файлов в каталоге и количество потоков, было решено сохранить фиксированное общее количество файлов размером 2 МиБ (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. Производительность метаданных — пустые файлы
Во-первых, обратите внимание, что выбранный масштаб был логарифмическим с основанием 10, чтобы можно было сравнивать операции, которые имеют различия на несколько порядков; В противном случае некоторые операции выглядели бы как плоская линия, близкая к 0 на нормальном графике. Логарифмический граф с основанием 2 может быть более подходящим, так как количество потоков увеличивается в степенях числа 2, но график будет выглядеть довольно похоже, и люди, как правило, лучше обрабатывают и запоминают числа, основанные на степенях числа 10.
Система получает очень хорошие результаты, когда операции Stat и Read достигают своего пикового значения при 64 потоках с 11,2 млн операций/с и 4,8 млн операций в секунду соответственно. Операции удаления достигли максимальной производительности 169,4 тыс. операций в секунду при 16 потоках, а операции создания достигли пика в 512 потоков при 194,2 тыс. операций в секунду. Операции STAT и чтения различаются сильнее, но после достижения пикового значения производительность не падает ниже 3 млн операций в секунду для операций STAT и 2 млн операций в секунду для операций чтения. Создание и удаление становятся более стабильными, когда они достигают плато и остаются выше 140 тыс. операций в секунду для удаления и 120 тыс. операций в секунду для создания.
Производительность метаданных с MDtest при использовании файлов размером 4 КиБ
Этот тест почти идентичен предыдущему, за исключением того, что вместо пустых файлов использовались небольшие файлы размером 4 КиБ.
Следующая команда была использована для выполнения эталонного теста, где потоки были переменной с количеством используемых потоков (от 1 до 512, увеличивалось по степени числа 2), а файл 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 и Remove, достигая своего пикового значения в 128 потоков с 7,7 млн операций в секунду и 1 млн операций в секунду соответственно. Операции удаления достигли максимальной производительности 37,3 тыс. операций в секунду, а операций создания — 55,5 тыс. операций в секунду при 512 потоках. Операции «Характеристика» и «Удаление» имеют большую вариативность, но как только они достигают своего пикового значения, производительность не падает ниже 4 млн операций в секунду для характеристик и 200 тысяч операций в секунду для удаления. Создание и чтение колеблются меньше всего и постоянно увеличиваются по мере увеличения количества потоков.
Поскольку эти числа относятся к модулю метаданных с одним массивом ME4024, производительность будет возрастать для каждого дополнительного массива ME4024, однако нельзя просто предполагать линейное увеличение для каждой операции. Если весь файл не помещается в индексный дескриптор для такого файла, целевые объекты данных на ME4084 будут использоваться для хранения файлов 4K, что в некоторой степени ограничивает производительность. Так как размер индексного дескриптора составляет 4 КиБ, и он все еще должен хранить метаданные, внутри будут находиться только файлы размером около 3 КиБ, а все файлы большего размера будут использовать целевые объекты данных.
Производительность метаданных при использовании MDtest с файлами 3K
Этот тест практически полностью идентичен предыдущим, за исключением того, что использовались небольшие файлы размером 3 КиБ. Основное отличие заключается в том, что эти файлы полностью помещаются внутри индексного дескриптора. Таким образом, узлы хранения данных и их ME4084 не используются, что повышает общую скорость за счет использования только твердотельных накопителей для хранения данных и меньшего объема сетевых доступов.
Следующая команда была использована для выполнения эталонного теста, где потоки были переменной с количеством используемых потоков (от 1 до 512, увеличивалось по степени числа 2), а файл 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 3K -e 3K
Рис. 7. Производительность метаданных — небольшие файлы (3K)
Система показывает очень хорошие результаты для операций Stat и Read, достигая пикового значения в 256 потоков с 8,29 млн операций в секунду и 5,06 млн операций в секунду соответственно. Операции удаления достигли максимальной производительности 609 тыс. операций в секунду при 128 потоках, а операции создания достигли пика в 78 тыс. операций в секунду при 512 потоках. Операции статистики и чтения более вариативны, чем операции создания и удаления. Удаление сопровождается небольшим падением производительности для двух более высоких точек потоков, что позволяет предположить, что устойчивая производительность после 128 потоков составит чуть более 400 тыс. операций в секунду. Количество создателей продолжало увеличиваться до 512 потоков, но, похоже, выходит на плато, поэтому максимальная производительность все еще может быть ниже 100 тыс. операций в секунду.
Поскольку небольшие файлы, подобные этим, полностью хранятся в модуле метаданных на основе SSD, приложения, требующие превосходной производительности малых файлов, могут использовать один или несколько дополнительных модулей метаданных с высокими требованиями для повышения производительности малых файлов. Однако файлы, которые помещаются в индексный дескриптор, очень малы по текущим стандартам. Кроме того, поскольку целевые объекты метаданных используют массивы RAID1 с относительно небольшими твердотельными накопителями (максимальный размер — 19,2 Тбайт), емкость будет ограничена по сравнению с узлами хранения. Поэтому необходимо соблюдать осторожность, чтобы избежать переполнения целевых объектов метаданных, что может привести к ненужным сбоям и другим проблемам.
Расширенная аналитика
Среди возможностей PixStor мониторинг файловой системы с помощью расширенной аналитики может быть важен для значительного упрощения администрирования, помогая заранее или реактивно находить проблемы или потенциальные проблемы. Далее мы кратко рассмотрим некоторые из этих возможностей.
На рис. 8 показана полезная информация, основанная на емкости файловой системы. Слева — общий объем используемого пространства файловой системы и первые десять пользователей по используемой емкости файловой системы. Справа — историческое представление с данными об используемой емкости за многие годы, а затем о десяти основных типах используемых файлов и десяти основных наборах файлов, основанных на используемой емкости в формате, аналогичном диаграммам Парето (без линий для нарастающих итогов). С помощью этой информации можно легко найти пользователей, получающих больше своей справедливой доли файловой системы, тенденции использования емкости для принятия решений, связанные с будущим увеличением емкости, тем, какие файлы занимают большую часть пространства или какие проекты занимают большую часть емкости.
Рис. 8. Аналитика PixStor — представление
о емкости На рисунке 9 приведено представление количества файлов с двумя очень полезными способами поиска проблем. В первой половине экрана отображаются десять самых активных пользователей в круговой диаграмме, а также десять основных типов файлов и десять лучших наборов файлов (например, проекты) в формате, похожем на диаграммы Парето (без линий для кумулятивных итогов), и все они основаны на количестве файлов. Эта информация может быть использована для ответа на некоторые важные вопросы. Например, какие пользователи монополизируют файловую систему, создавая слишком много файлов, какой тип файлов создает кошмар для метаданных или какие проекты используют большую часть ресурсов.
Нижняя половина имеет гистограмму с количеством файлов (частотой) для размеров файлов с использованием 5 категорий для различных размеров файлов. Это можно использовать для получения представления о размерах файлов, используемых в файловой системе, которые, согласованные с типами файлов, могут использоваться для принятия решения о пользе сжатия.
Рис. 9. PixStor Analytics — просмотр количества файлов
Выводы и планы на будущее
Текущее решение смогло обеспечить достаточно хорошую производительность, которая, как ожидается, будет стабильной независимо от используемого пространства (так как система была отформатирована в рассеянном режиме), как видно из таблицы 4. Кроме того, решение линейно масштабируется по мере добавления дополнительных модулей узлов хранения, и можно ожидать аналогичного увеличения производительности от дополнительного модуля часто запрашиваемых метаданных. Это решение предоставляет заказчикам HPC очень надежную параллельную файловую систему, используемую многими кластерами HPC из списка Top 500. Кроме того, он предоставляет исключительные возможности поиска, расширенный мониторинг и управление, а добавление дополнительных шлюзов позволяет обмениваться файлами по универсальным стандартным протоколам, таким как NFS, SMB и другие, с любым количеством клиентов, сколько необходимо.
Таблица 4 Пиковая и устойчивая производительность
Пиковая производительность
Стабильная производительность
Запись
Чтение
Запись
Чтение
Крупные последовательные операции N клиентов для N файлов
16,7 ГБ/с
23 ГБ/с
16,5 ГБ/с
20,5 ГБ/с
Крупные последовательные операции N клиентов для одного общего файла
16,5 ГБ/с
23,8 Гбайт/с
16,2 ГБ/с
20,5 ГБ/с
Произвольные операции с небольшими блоками N клиентов для N файлов
15,8 тыс. iops
20,4 тыс. iops
15,7 тыс. iops
20,4 тыс. iops
Метаданные: создание пустых файлов
169,4 тыс. IOPS
127,2 тыс. операций ввода-вывода в секунду
Метаданные: операция Stat для пустых файлов
11,2 млн операций ввода-вывода в секунду
3,3 млн операций ввода-вывода в секунду
Метаданные: чтение пустых файлов
4,8 млн операций ввода-вывода в секунду
2,4 млн IOPS
Метаданные: удаление пустых файлов
194,2 тыс. операций ввода-вывода в секунду
144,8 тыс. операций ввода-вывода в секунду
Метаданные: создание файлов 4 КиБ
55,4 тыс. операций ввода-вывода в секунду
55,4 тыс. операций ввода-вывода в секунду
Метаданные: операция Stat для файлов 4 КиБ
6,4 млн операций ввода-вывода в секунду
4 млн операций ввода-вывода в секунду
Метаданные: чтение файлов 4 КиБ
37,3 тыс. операций ввода-вывода в секунду
37,3 тыс. операций ввода-вывода в секунду
Метаданные: удаление файлов 4 КиБ
1 млн операций ввода-вывода в секунду
219,5 тыс. операций ввода-вывода в секунду
Поскольку решение предназначено для использования с ЦП Cascade Lake и более быстрым ОЗУ, после окончательной настройки системы будут выполнены выборочные проверки производительности. Также протестируйте дополнительный модуль часто запрашиваемых метаданных как минимум с 2 ME4024 и файлами размером 4 КиБ, чтобы получить более полные данные о масштабировании производительности метаданных при использовании целевых устройств. Кроме того, производительность узлов шлюза будет измерена и опубликована вместе с соответствующими результатами выборочных проверок в новой статье блога или в техническом документе. Наконец, планируется тестирование и выпуск дополнительных компонентов решения для обеспечения еще большего количества возможностей.