Для многих рабочих нагрузок HPC достижение наилучшей комплексной эффективности приложения или рабочей нагрузки зависит от выбора оптимальной технологии размещения файлов во время их обработки или конфигурации сетевого стека для обеспечения оптимальной работы MPI или других протоколов передачи данных. В этом модуле рассматриваются варианты решения этих задач, предлагаемые AWS, а также критерии оценки соотношения цена/производительность для выбора оптимальных решений для каждой рабочей нагрузки
Рассматриваемые темы
- Хранилище для HPC на AWS
- Масштабируемость сети для рабочих нагрузок HPC
Общие сведения о вариантах хранилищ на AWS. AWS предоставляет множество вариантов – от хранилища для высокопроизводительных объектов до множества типов файловых систем, которые можно прикрепить к инстансу EC2. Помимо производительности типы хранилищ отличатся по ряду других параметров, в том числе по стоимости и масштабируемости. Приведенная ниже таблица поможет вам подобрать оптимальный вариант хранилища данных HPC.
Совместно используемые файловые системы для HPC. Для создания общего хранилища можно использовать различные способы, например простое монтирование по протоколу NFS в том EBS, сборку томов EBS с использованием Intel Lustre или управляемый сервис AWS, который называется EFS. Аналогично типу инстанса можно протестировать варианты хранилищ и выбрать наиболее эффективный тип файловой системы.
Хранилище, прикрепленное к инстансу. Предлагаются также различные варианты объема хранилища EBS для большого числа операций ввода-вывода в секунду, для общих задач и различных вариантов магнитных носителей. Многие приложения HPC очень хорошо работают с менее дорогими универсальными хранилищами и магнитными томами хранилищ типа EBS. Аналогично выбору типа инстанса, нетрудно протестировать и выбрать оптимальный объем хранилища EBS.
Конфигурация хранилища лаборатории. Варианты конфигурации хранилища, используемые в автоматизации EnginFrame по умолчанию, описаны ниже.
- Скрипты интеграции монтируют том EFS под /efs на главном и вычислительных узлах. Эти файловые системы содержат каталог для приложений и каталог буферизации, в котором по умолчанию размещаются отдельные каталоги для каждого из заданий
- AWS ParallelCluster также имеет том EBS gp2, который прикреплен к главному узлу и монтируется по протоколу NFS на вычислительные узлы как /shared
- Каталог /home из основного инстанса также монтируется на вычислительные узлы по протоколу NFS. Поскольку каталог устанавливается на ту же файловую систему ОС, его не рекомендуется использовать для постоянного хранения данных
Производительность этих совместно используемых файловых систем может значительно варьироваться для различных рабочих нагрузок. Лучший способ понять, какая из них лучше всего подойдет для ваших задач – провести сравнительный тест на /efs (конфигурируется как расположение по умолчанию в EnginFrame) и /shared.
Текущая конфигурация сетей AWS. В настоящее время AWS поддерживает улучшенную сетевую конфигурацию на основе технологии SR-IOV (Single Root I/O Virtualization). SR-IOV – это способ виртуализации устройств, обеспечивающий более высокую производительность ввода-вывода и более низкий уровень использования ЦПУ, чем традиционные реализации. Для поддерживаемых инстансов Amazon EC2 эта функция обеспечивает лучшую пропускную способность в пакетах в секунду (PPS), снижение внутренних задержек в инстансах и крайне низкий джиттер сети. Ее эффективность была протестирована для высокопроизводительных вычислений (HTC), приложений с «чрезвычайной параллельностью», а также «сильносвязанных» или основанных на MPI или OpenMP приложений HPC.
Скорость работы сети зависит от типа и размера инстанса, например r4.16xlarge обеспечивает 20-гигабитную подключаемость между инстансами, при использовании той же группы размещения (логическое группирование инстансов), и оптимизацию сети.
Конфигурация лабораторной сети. По умолчанию лаборатория создает новую группу размещения, в которой должны запускаться все вычислительные узлы кластера. Это обеспечивает низкую задержку и высокую скорость взаимодействия между узлами, что особенно полезно при работе приложений MPI. При наличии проблемы с HTC, которая выражается в горизонтальном масштабировании на десятки тысяч узлов и более (что превышает возможности лаборатории), стоит распределить нагрузку между несколькими группами размещения, чтобы придать EC2 большую гибкость в размещении большого числа узлов. Отключить использование фиксированной группы размещения можно, установив следующий параметр в конфигурации AWS ParallelCluster:
placement_group = NONE
Совет. При необходимости масштабирования кластера на большое число узлов, вы можете связаться со своим менеджером по технической поддержке или с архитектором программных решений HPC, которые могут проверить целевую архитектуру, помочь определить потенциальные «узкие места» и выбрать оптимальные для ваших целей технологии.