Сводка

10 мин

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

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

Создайте контрольный список на основе следующего списка рекомендаций.

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

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

Например, рабочая нагрузка HPC может последовательно считывать данные из большого файла (например, медиа-ассета из задания на рендеринг или файла геномной последовательности) с большого числа высокопроизводительных вычислительных машин HPC. В то же время может потребоваться работать с базой данных (например, для работы с планировщиком HPC). Типы трафика отличаются и могут потребовать развертывания на различных решениях для хранения.

Решения для хранения данных могут быть разработаны для оптимизации различных задач. Файловое хранилище NAS, построенное на Ubuntu с использованием локальных дисков NVMe, будет отлично справляться с однопоточными операциями, например, когда один клиент копирует данные из NAS на локальный диск. Но он может не масштабироваться для параллельного доступа большим числом клиентов.

Кроме того, может потребоваться решение, оптимизирующее большое количество небольших файлов. Традиционное решение NAS, например Azure NetApp Files, обеспечивает оптимальную производительность для такого трафика. Но вам также может потребоваться обработать, а затем сохранить большие файлы и свести к минимуму затраты на это. Хранилище BLOB-объектов Azure с многоуровневым хранением обеспечивает гибкость в таких случаях, но может не показать высокой производительности при односторонней операции копирования.

Запишите следующие типы трафика в контрольном списке:

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

Например, контрольный список может отражать:

Многопотоковый трафик.
Чтение тяжелых (75% против 25%).
Средний размер файла в диапазоне от 10 ГБ до 200 ГБ. Около 50 000 файлов.
Последовательный тяжелый (80% против 20%).

Кроме того, следует учитывать крупные рабочие нагрузки, которые планируется запустить в данной архитектуре. Если существует более одного или двух, убедитесь, что в требованиях нет значительного расхождения.

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

Следующая категория учитывает расположение данных. Необходимо ли хранить данные в локальной среде? Существуют ли проблемы с изменениями данных во время выполнения рабочей нагрузки HPC? Планируется ли изменение данных выполняться только в локальной среде, только в Azure или в обоих расположениях?

Ниже приведены некоторые элементы локальности для контрольного списка:

Исходные данные в локальной среде, в Azure или и то, и другое?
Результаты данных в локальной среде, в Azure или обоих?
Должны ли рабочие нагрузки HPC в Azure координироваться с временными шкалами изменения исходных данных?
- Временные шкалы помогают сообщить о риске устаревших данных.
Конфиденциальные данные или данные HIPAA?
- Чувствительность данных определяет требуемый уровень проверки подлинности и шифрования.

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

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

Требования к производительности должны выглядеть примерно так:

Пропускная способность с одним потоком (в ГБИТ/с)
Пропускная способность с несколькими потоками (в GBps)
Ожидаемые максимальные IOPS
Средняя задержка (мс)

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

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

Учет необходимого протокола доступа клиентов. Как мы обсуждали, существуют разные версии NFS (и SMB, клиентский протокол Windows). Если вы планируете использовать NFSv4, укажите, какие функции протокола необходимы (например, списки управления доступом).

Ниже приведены некоторые элементы для контрольного списка:

Необходимые версии NFS
- Если версия 4, ожидаемое поведение протокола (списки управления доступом, шифрование)
Решение параллельной файловой системы

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

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

Некоторые элементы списка:

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

Примечание о вместимости холодного уровня: архивные уровни сочетают более низкие затраты на хранение данных с более высокими затратами на операции по извлечению данных. Кроме того, уровни архива имеют длительное время извлечения данных. Они не должны считаться частью ваших горячих или теплых уровней.

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

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

В ваш список:

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