Хранилище для рабочих нагрузок Azure HPC

Статья
12/21/2024

Доступ к хранилищу является важным фактором, который следует учитывать при планировании высокой производительности вычислительных вычислений (HPC). Крупномасштабные рабочие нагрузки HPC в определенных средах могут создавать требования к хранилищу данных и доступу, превышающим возможности традиционных облачных файловых систем. В этой статье приведены рекомендации по выбору правильного хранилища для рабочих нагрузок Azure HPC. Она также предоставляет рекомендации по хранению рабочих нагрузок HPC в энергетических, финансовых и производственных отраслях.

Рассмотрим следующие факторы, связанные с требованиями приложения, чтобы решить, какое решение хранилища следует использовать:

Латентность
Операции ввода-вывода в секунду (IOPS)
Производительность
Размеры и количество файлов
Время выполнения задания
Стоимость
Расположение хранилища — локальная среда и Azure

Дополнительные сведения см. в статье Сведения о факторах, влияющих на выбор хранилища HPC в Azure.

На следующей схеме показано дерево принятия решений, которое подходит для конкретной системы хранения HPC.

Рекомендации по проектированию HPC

Выберите решение, которое лучше всего подходит для ваших уникальных требований к ввода-выводам и емкости.

Сетевая файловая система

Сетевая файловая система (NFS) часто используется для предоставления доступа к общим расположениям хранилища. Виртуальная машина сервера, использующая NFS, предоставляет общий доступ к локальной файловой системе. В Azure эта файловая система хранится на одном или нескольких виртуальных жестких дисках (VHD), размещенных в службе хранилища Azure. Затем клиенты могут подключить общие файлы сервера и получить доступ к общему расположению напрямую.

NFS часто используется для домашних каталогов и пространств проектов, требующих доступа ко всем узлам. Он может предоставить пространство для исследовательских групп, которые совместно используют данные. Как правило, рабочие нагрузки пропускной способности горизонтально масштабируются с небольшим количеством зависимостей между отдельными задачами. Планировщики заданий разделяют работу между узлами и координируют действия. NFS — это обычное общее хранилище на узлах, к которым осуществляется доступ через сети TCP/IP.

NFS обеспечивает простоту настройки и обслуживания и поддерживается как в операционных системах Linux, так и в Windows. Несколько серверов NFS можно использовать для распространения хранилища по сети, но отдельные файлы доступны только через один сервер.

Для маломасштабных рабочих нагрузок рекомендуется запустить NFS на головном узле с помощью виртуальной машины, оптимизированной для хранения , имеющей большие временные диски, или виртуальных машин серии D с использованием Azure Premium Storage, в зависимости от ваших требований. Это решение подходит для рабочих нагрузок, имеющих 500 ядер или меньше.

В сценариях HPC файловый сервер часто может служить узким местом, которое замедляет общую производительность. Попытки доступа к неиспользуемым в кэше данным с одного сервера NFS на более высоких скоростях, чем задокументированные для максимальных IOPS и пропускной способности на виртуальную машину, приводят к ограничению скорости.

В сценарии, когда десятки клиентов пытаются работать с данными, хранящимися на одном сервере NFS, можно легко достичь этих ограничений. Эти ограничения могут привести к снижению производительности всего приложения. Чем более ваше приложение HPC похоже на чистый сценарий с одним ко многим, тем быстрее вы столкнетесь с этими ограничениями.

Параллельные файловые системы в Azure

Параллельные файловые системы распределяют хранилище на уровне блока между несколькими сетевыми узлами хранилища. Данные файлов распределяется между этими узлами, что означает, что данные файлов распределяется между несколькими устройствами хранения. Это распределение объединяет любые индивидуальные запросы ввода-вывода хранилища на множестве узлов хранения, доступных через общее пространство имен.

Для обеспечения высокой степени параллелизма используются несколько устройств хранения и нескольких путей к данным. Этот подход сокращает количество узких мест, создаваемых одновременным доступом только к одному узлу. Однако параллельная операция ввода-вывода может быть сложной для координации и оптимизации при работе непосредственно на уровне интерфейса API или POSIX ввода-вывода. Введя промежуточные уровни доступа к данным и координации, параллельные файловые системы предоставляют разработчикам приложений высокоуровневый интерфейс между уровнем приложения и уровнем ввода-вывода.

Рабочие нагрузки интерфейса передачи энергетических сообщений (MPI) имеют уникальные требования, которые требуют низкой задержки связи между узлами. Узлы подключены через высокоскоростное взаимодействие и не легко адаптируются для совместного использования с другими рабочими нагрузками. Приложения MPI используют все высокопроизводительные взаимодействия через режим Pass-Through в виртуализированных средах. Хранилище для узлов MPI обычно представляет собой параллельную файловую систему, например Lustre, доступ к которому также осуществляется через высокоскоростное взаимодействие. Lustre и BeeGFS обычно используются для обработки высоких требований к пропускной способности при сейсмической обработке. В меньшей степени они также используются для моделирования водохранилища.

Параллельные файловые системы, такие как Lustre, используются для рабочих нагрузок энергии HPC, требующих доступа к большим файлам, одновременного доступа с нескольких вычислительных узлов и больших объемов данных. Реализация параллельных файловых систем упрощает масштабирование с точки зрения возможностей и производительности. Эти файловые системы используют преимущества передачи удаленного прямого доступа к памяти с большой пропускной способностью и сокращением использования ЦП. Параллельная файловая система часто используется в качестве временного хранилища и предназначена для задач, требующих оптимизированного ввода-вывода. Примерами являются настройка рабочей нагрузки, предварительная обработка, запуск и постобработка.

Оркестрированная параллельная файловая служба, такая как Azure Managed Lustre, работает для 50 000 или более ядер, со скоростью чтения и записи до 500 ГБ/с и 2,5 ПБ хранилища. Дополнительные сведения см. в статье Параллельные виртуальные файловые системы вMicrosoft Azure.

Компоненты HPC

Azure NetApp Files и локальные диски обычно используются для обработки рабочих нагрузок, более чувствительных к задержкам и операциям ввода-вывода в секунду, таких как сейсмическая интерпретация, подготовка модели и визуализация. Рассмотрите возможность использования Azure NetApp Files для рабочих нагрузок до 4000 ядер, с пропускной способностью до 6,5 ГиБ/с, а также для нагрузок, которые выигрывают от или требуют многопротокольного доступа к одному и тому же набору данных с использованием NFS и SMB.
Управляемый Lustre обеспечивает более быстрое хранилище большой емкости для нагрузок высокопроизводительных вычислений. Это решение работает для средних и больших рабочих нагрузок и может поддерживать 50 000 или более ядер с пропускной способностью до 500 ГБИТ/с и емкостью хранилища до 2,5 PiB.
Хранилище BLOB-объектов Azure уровня "Стандартный" или "Премиум" является экономичным, так как это облачное предложение с наименьшей стоимостью. Эта служба предоставляет доступ на эксабайтном уровне с высокой пропускной способностью и низкой задержкой там, где это необходимо, интуитивно понятный интерфейс файловой системы и много-протокольный доступ (REST, HDFS, NFS). NFS версии 3.0 можно использовать в конечной точке службы хранения блобов для рабочих нагрузок с высокой пропускной способностью и интенсивными операциями чтения. Вы можете оптимизировать затраты, перейдя на более холодные уровни хранилища. Этот подход позволяет управлять жизненным циклом на основе последнего обновления или времени доступа и интеллектуальным распределением данных с помощью настраиваемых политик.
Рабочие нагрузки в нефтегазовой отрасли могут потребовать передачи больших объемов данных между локальными системами и облаком. Автономная миграция использует службы устройств, такие как Azure Data Box. Миграция через Интернет использует сетевые службы, такие как Azure ExpressRoute.

В следующей таблице приведено сравнение Blob Storage, Azure Files, Managed Lustre и Azure NetApp Files.

Категория	Хранилище BLOB-объектов	Файлы Azure	Управляемый Lustre	Azure NetApp Files
Варианты использования	Лучше всего подходит для крупномасштабных рабочих нагрузок, ориентированных на последовательный доступ с интенсивным чтением, где данные поступают один раз и изменяются минимально. Низкая общая стоимость владения, если есть легкое обслуживание. Некоторые примеры сценариев включают крупномасштабные аналитические данные, высокопроизводительные вычисления, чувствительные к пропускной способности, резервное копирование и архивирование, автономное вождение, рендеринг мультимедиа и секвенирование генома.	Высокодоступный сервис, который наиболее подходит для рабочих нагрузок случайного доступа. Для общих папок NFS Служба файлов Azure обеспечивает полную поддержку файловой системы POSIX. Встроенный драйвер CSI позволяет легко использовать его с платформ на основе виртуальных машин и контейнеров, таких как экземпляры контейнеров Azure и Служба Azure Kubernetes (AKS). Некоторые примеры сценариев включают общие файлы, базы данных, домашние каталоги, традиционные приложения, ERP, CMS, миграции NAS, которые не требуют расширенного управления и пользовательских приложений, требующих горизонтального масштабирования хранилища файлов.	Managed Lustre — это полностью управляемая параллельная файловая система, которая лучше всего подходит для средних и больших рабочих нагрузок HPC. Позволяет запускать приложения HPC в облачной среде без нарушения их совместимости, обеспечивая привычную функциональность, характеристики и производительность параллельной файловой системы Lustre. Эта служба помогает защитить долгосрочные инвестиции в приложения.	Полностью управляемая файловая служба в облаке с поддержкой NetApp, которая имеет расширенные возможности управления. Azure NetApp Files подходит для рабочих нагрузок, требующих случайного доступа. Она обеспечивает широкую поддержку протокола и улучшенную защиту данных. Некоторые примеры сценариев включают миграцию локального корпоративного NAS, требующую широких возможностей управления, рабочих нагрузок, чувствительных к задержкам, таких как SAP HANA, интенсивных на IOPS высокопроизводительных вычислений или рабочих нагрузок, требующих одновременного доступа с несколькими протоколами.
Доступные протоколы	NFS 3.0 ОТДЫХ Azure Data Lake Storage	малый и средний бизнес NFS 4.1 (Взаимодействие между протоколом отсутствует)	Блеск	NFS 3.0 и 4.1 SMB (малый и средний бизнес)
Ключевые функции	Интегрирована с Azure HPC Cache для рабочих нагрузок с низкой задержкой. Интегрированное управление, включая управление жизненным циклом, неизменяемые блобы, переключение при отказе данных и индекс метаданных.	Зональная избыточность для обеспечения высокой доступности. Постоянная задержка в пределах нескольких миллисекунд. Предсказуемая производительность и затраты, которые масштабируются с увеличением емкости.	Большая емкость хранилища до 2,5 ПБ. Низкая задержка, около 2 мс. Создавайте новые кластеры за считанные минуты. Поддерживает контейнерные рабочие нагрузки с помощью AKS.	Крайне низкая задержка, вплоть до субмиллисекунды. Широкие возможности управления NetApp ONTAP, такие как SnapMirror Cloud. Согласованный гибридный облачный интерфейс.
Производительность (на единицу объема)	До 20 000 операций ввода-вывода в секунду. До 100 ГиБбит/с пропускной способности.	До 100 000 операций ввода-вывода в секунду. До 80 ГиБбит/с пропускной способности.	До 100 000 операций ввода-вывода в секунду. До 500 Гибит/с пропускной способности.	Ориентировочно до 460 000 операций ввода-вывода в секунду. До 36 ГиБбит/с пропускной способности.
Шкала	До 2 PiB для одного тома. Примерно 4,75 ТиБ для одного файла. Нет минимальных требований к емкости.	До 100 ТиБ для одного тома. До 4 ТиБ для одного файла. Минимальная емкость 100-ГиБ.	До 2,5 PiB для одного тома. До 32 PB для одного файла. Минимальная емкость 4 ТиБ.	До 100 ТиБ для одного тома. До 16 ТиБ для одного файла. Согласованный гибридный облачный интерфейс.
Ценообразование	Цены на BLOБ-хранилище	Цены на файлы Azure	цены на Управляемый Lustre	Ценообразование на Azure NetApp Files

Рекомендации по производству

Важно убедиться, что необходимые данные достигают компьютеров кластера HPC в нужное время. Вы также хотите убедиться, что результаты этих отдельных компьютеров быстро сохраняются и доступны для дальнейшего анализа.

Распределение трафика рабочей нагрузки

Рассмотрим типы трафика, который создает среда HPC и обрабатывает. Этот шаг особенно важен, если вы планируете выполнять несколько типов рабочих нагрузок и планируете использовать хранилище для других целей. Рассмотрите и запишите следующие типы трафика:

Один поток и несколько потоков
Отношение трафика чтения к трафику записи
Средний размер и количество файлов
Случайные и последовательные шаблоны доступа

Локальность данных

Эта категория учитывает расположение данных. Осведомленность о локальности помогает определить, можно ли использовать копирование, кэширование или синхронизацию в качестве стратегии перемещения данных. Заранее проверьте следующие элементы локальности:

Если исходные данные расположены локально, в Azure или в обоих местах
Если данные результатов находятся локально, в Azure, или в обоих местах
Если рабочие нагрузки HPC в Azure должны быть согласованы с временными шкалами изменения исходных данных
Если включены конфиденциальные данные или данные, защищенные Законом о переносимости и подотчетности медицинского страхования

Требования к производительности

Требования к производительности для решений хранилища обычно суммируются следующим образом:

Однопоточная пропускная способность
Пропускная способность с несколькими потоками
Ожидаемое максимальное число IOPS
Средняя задержка

Каждый фактор влияет на производительность, поэтому эти числа служат руководством для ожидаемых результатов конкретного решения. Например, рабочая нагрузка HPC может включать обширное создание и удаление файлов в рамках рабочего процесса. Эти операции могут повлиять на общую пропускную способность.

Методы доступа

Учитывайте требуемый протокол доступа к клиенту и ясно определите, какие функции протокола вам нужны. Существуют разные версии NFS и SMB.

Рассмотрите следующие требования:

Требуются ли версии NFS/SMB
Ожидаемые функции протокола, такие как списки управления доступом или шифрование
Решение параллельной файловой системы

Общее требование к емкости

Емкость хранилища в Azure является следующим вопросом. Это помогает определить полную стоимость решения. Если вы планируете хранить большое количество данных в течение длительного времени, вы можете рассмотреть возможность распределения по уровням в рамках решения хранилища. Многоуровневая архитектура объединяет более дешевые варианты хранения с более дорогими вариантами, обеспечивающими высокую производительность, в горячем уровне. Рассмотрим следующие требования к емкости:

Общая емкость, требуемая
Требуемая общая емкость горячего уровня
Общая емкость теплого уровня, необходимая
Общая емкость холодного уровня, требуемая

Метод проверки подлинности и авторизации

Для требований проверки подлинности и авторизации, таких как использование сервера LDAP или Windows Server Active Directory, обязательно включите необходимые вспомогательные системы в архитектуру. Если необходимо поддерживать такие возможности, как сопоставление UID или GID с пользователями Windows Server Active Directory, убедитесь, что решение хранилища поддерживает эту возможность.

Рассмотрите следующие требования к сети:

Локальный (UID или GID только на файловом сервере)
Каталог (LDAP или Windows Server Active Directory)
Сопоставление UID или GID с пользователями Windows Server Active Directory или нет

Создайте свою собственную параллельную файловую систему

Аналогично NFS, можно создать файловую систему BeeGFS или Lustre с несколькими узлами. Производительность этих систем в основном зависит от выбранного типа виртуальных машин. Можно использовать образы, найденные в Azure Marketplace, для BeeGFS или для Lustre, реализованного компанией DDN под названием Whamcloud. Если вы используете образы от других поставщиков, таких как BeeGFS или DDN, вы можете приобрести их службы поддержки. Вы можете использовать BeeGFS и Lustre под своими лицензиями GPL без дополнительных расходов, помимо затрат на компьютеры и диски. Эти средства можно легко развертывать с помощью скриптов Azure HPC с временными локальными дисками для временного хранения данных или Azure Premium SSD или хранилища дисков Azure Ultra для постоянного хранения.

Cray ClusterStor

Это проблема для больших рабочих нагрузок для репликации производительности больших вычислительных кластеров с большими средами Lustre. Другие проблемы включают достижение высокой пропускной способности в ТБ/с и потенциальное управление ПБ хранилища. Теперь эти рабочие нагрузки можно запустить с помощью Cray ClusterStor в решении Azure. Этот подход — это чистое развертывание Lustre без операционной системы, размещенное в соответствующем центре обработки данных Azure. Параллельные файловые системы, такие как BeeGFS и Lustre, обеспечивают максимальную производительность из-за их архитектуры. Но эта архитектура и использование этих технологий имеет высокую цену управления.

Дальнейшие действия

В следующих статьях приведены рекомендации, которые помогут вам в различных точках во время внедрения облака.

Поделиться через