Завершение процесса обучения модели — это, как правило, не конец проблемы, а только её начало.

Сразу же возникают вопросы. Как передать результаты команде аналитиков из соседнего отдела? Где найти актуальную копию того размеченного набора данных, с которым работали на прошлой неделе? Следующему этапу конвейера (pipeline) результаты инференса нужны уже через несколько минут — придется ли снова запускать задачу копирования?

Большинство команд вкладывают значительные средства в инфраструктуру для обучения: быстрые диски, сети с поддержкой RDMA, специализированные коммутаторы. Однако этап передачи данных зачастую по‑прежнему выполняется вручную: копирование через scp, открытие доступа к общей папке на GPU‑сервере и опора на устные договоренности о том, в какой именно директории лежит верная версия. Если практиковать такой подход достаточно долго, каждая из этих привычек обрастает собственным набором проблем.

Функция S3 Compatible Share, доступная начиная с версии QSM 4.3.1, призвана устранить именно этот пробел. Она позволяет использовать один и тот же общий файловый ресурс одновременно для работы с объектным API (S3) и файловыми протоколами (NFS/SMB). Никаких дублирующих наборов данных или фоновой синхронизации — только один комплект файлов с двумя способами доступа к ним.

Важное замечание: в этой статье вы не найдете показателей пропускной способности, задержки (latency) или IOPS. Этому вопросу посвящен отдельный раздел ниже.

1. Распространенные проблемы при обучении ИИ сегодня

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

Первый способ — копирование в общую директорию. По завершении обучения результаты переносятся в доступную всем папку: иногда это делает сам скрипт обучения (в качестве последней команды), а иногда — инженер вручную.

Проблема в том, что сама операция копирования не сохраняет информацию о версии. Возьмем, к примеру, файл checkpoint.pt: попав в общую папку, он выглядит точно так же, как файл трехнедельной давности, и ничто не указывает на то, какой из них является актуальным. Начинают плодиться директории с названиями вроде v2, v2_final, v2_final_new и так далее. При этом копии появляются не сразу, так как каждый запуск обучения и каждое изменение параметров добавляют новый слой данных. Затраты на хранение растут линейно, но дело не только в нехватке места. Главная проблема в том, что после заполнения хранилища никто не решается ничего удалять, а информация о версиях сохраняется лишь в чьей‑то памяти.

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

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

Третий способ предполагает использование двух протоколов и двух систем хранения. Локальный вычислительный узел работает с S3, а смежные команды — с NFS; таким образом, у каждой стороны своя система, а между ними действует задача синхронизации, непрерывно переносящая результаты обучения в отдельное общее хранилище.

Очевидная цена такого решения — удвоение объема требуемого хранилища. Менее заметная проблема кроется в самой задаче синхронизации: интервал ее выполнения определяет период расхождения данных между системами, а со временем обычно не остается никого, кто по‑настоящему отвечал бы за этот процесс.

Описанный здесь S3-совместимый общий ресурс (S3 Compatible Share) — это, по сути, усовершенствованная версия второго подхода.

Из трех вариантов именно второй кажется наиболее подходящим решением: одна копия данных, отсутствие необходимости в синхронизации и путаницы с версиями.

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

1. Где именно физически находятся данные. Если последующие этапы обработки (downstream) считывают данные с вычислительного узла, то эти данные остаются внутри вычислительного уровня. В результате сохраняются все описанные выше проблемы: конкуренция за ресурсы, зависимость доступности от одной машины и отсутствие защиты данных.

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

2. Более важный момент: в момент записи данные уже находятся в общем хранилище. В модели с чтением с вычислительного узла данные сначала записываются в ходе обучения, а затем забираются другими потребителями; следовательно, всегда присутствует этап их извлечения — будь то копирование, монтирование или разовый экспорт.

   При использовании S3-совместимого общего ресурса такой этап отсутствует. Операция PUT в рамках задачи обучения записывает данные непосредственно на массив хранения, и как только объект появляется там, он одновременно становится доступен как файл в точке монтирования NFS. Суть не в том, что данные перемещаются за пределы вычислительного уровня, а в том, что они туда даже не попадают.

2. Два протокола, три архитектуры

В предыдущем разделе было указано, что данные должны размещаться на массиве хранения, а не внутри вычислительного узла. Следующий вопрос касается более низкого уровня: каким образом протоколы S3 и NFS/SMB получают доступ к данным, когда те уже находятся на массиве?

A Подход A: объектный шлюз

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

Решение заключается в том, чтобы установить перед ним отдельный сервис преобразования запросов. Когда клиент отправляет запрос S3 PUT, этот сервис создает каталоги, открывает файл и записывает данные на массив; при поступлении запроса GET сервис открывает файл, считывает его содержимое и формирует HTTP‑ответ. Сам шлюз не хранит данные, а лишь обеспечивает их передачу.

Клиент ──S3──▶ Шлюз (выполняет преобразование, ничего не сохраняет) ──▶ Хранилище ──NFS/SMB──▶ Дальнейшие компоненты

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

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

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

• Через шлюз проходит весь объектный трафик, поэтому пропускная способность сети и вычислительная мощность процессора шлюза становятся ограничивающими факторами производительности. Для повышения скорости приходится добавлять новые узлы, что, в свою очередь, требует настройки балансировки нагрузки.

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

Подход B: запланированная синхронизация

Необходимо две системы хранения данных — одну для S3, а другую для файловых протоколов, — и настройте задачу репликации для периодического перемещения данных между ними.

Клиент ──S3──▶ Объектное хранилище

│ задача синхронизации (каждые N минут)

▼

Downstream ──NFS──▶ Файловое хранилище

Преимущество заключается в том, что обе стороны работают в «родном» формате, без промежуточного слоя. Однако у этого решения есть и прямые издержки:

• Удвоение объема данных, поскольку одни и те же сведения фактически хранятся в двух экземплярах.

• Временной интервал, в течение которого данные в системах различаются, определяется периодичностью задачи синхронизации. Если потребителю данных (downstream‑системе) результаты обучения требуются в течение минуты, этот подход просто не подходит.

• Задача синхронизации требует постоянного сопровождения. В случае сбоя, как показывает практика, со временем обычно не остается никого, кто бы по‑настоящему отвечал за этот процесс.

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

Подход C: общее пространство имен

S3 и NFS/SMB работают как параллельные службы на одном и том же массиве хранения, причем каждая из них напрямую считывает и записывает одни и те же файлы. Здесь нет ни дополнительного пространства, ни задач синхронизации.

Клиент ──S3───┐

├──▶ Тот же массив, те же файлы

Downstream ──NFS──┘

Разница особенно наглядна при сравнении с подходом А: в данном случае промежуточный шлюз полностью исключается, и система хранения данных начинает взаимодействовать с протоколом S3 напрямую. С точки зрения клиента эти варианты неразличимы — в обоих случаях отправляются S3-запросы к конечной точке, и не требуется менять ни строчки кода. Различие заключается лишь в том, что именно обрабатывает запрос на принимающей стороне: промежуточный сервер, требующий обслуживания, или сама система хранения, где уже находятся данные.

Третий вариант — это S3-совместимый общий ресурс (S3 Compatible Share).

Side by side

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

3. Что такое S3-совместимый файловый ресурс

Если из этой статьи вам запомнится лишь одна фраза, пусть это будет следующая:

Корнем баскета является сам путь к файловому ресурсу.

Здесь нет ни отдельного объектного тома, ни уровня трансляции, ни дублирующей копии данных. Администратор создает в XInsight группу хостов (Host Group) типа «S3 Compatible Share», привязывает к ней ровно одну файловую шару, а затем выбирает необходимые сервисы доступа к данным — S3, NFS или SMB/CIFS — в любой комбинации. Сервисы можно добавлять или удалять в любой момент, при этом перемещения самих данных не происходит.

После активации система работает в обоих направлениях:

• Объект, загруженный через S3 PUT, становится обычным файлом в дереве каталогов. Его можно прочитать (например, командой cat), вычислить для него контрольную сумму (md5sum) или обработать любой утилитой, работающей с файлами.

• Файл, записанный по протоколу NFS, становится обычным объектом в списке баскета (bucket), и его можно получить с помощью любого S3 SDK.

Имя баскета формируется на основе имени шары и должно соответствовать правилам именования S3: строчные латинские буквы (a‑z), цифры (0–9) и дефисы; длина — от 3 до 63 символов. Если сгенерированное имя совпадает с именем уже существующего баскета, в создании будет отказано. Этот момент стоит продумать до массового создания шар: лучше сразу определить правила именования, чем потом исправлять их по отдельности.

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

4. Как выполняется отображение пространства имен

Само правило сопоставления простое: ключ объекта — это путь относительно корня сегмента, а косая черта в ключе обозначает реальный уровень каталога.

Например, такой ключ:

datasets/2026/run-14/checkpoint.pt

отображается как:

/mnt/ml-results/datasets/2026/run-14/checkpoint.pt

Одна и та же строка выступает в роли ключа с одной стороны и пути — с другой. Это также означает, что принятая вами схема именования ключей в S3 определяет структуру каталогов в файловой системе (и наоборот), поэтому, планируя одно, вы фактически планируете и другое.

5. Действия со стороны администратора

Процесс состоит из четырех этапов:

1. Создание группы хостов (Host Group) в XInsight с типом «S3 Compatible Share» (общий ресурс, совместимый с S3).

2. Привязка общего файлового ресурса.

3. Активация необходимых сервисов передачи данных (S3, NFS, SMB — в любом сочетании).

4. Выпуск ключа доступа с ограничением области действия (на уровне баскета или конкретного префикса).

Те же операции доступны через REST API системы QSM 4, что позволяет автоматизировать весь процесс. Кроме того, сервис S3 предоставляет собственный интерфейс командной строки (CLI) и REST‑интерфейс для администрирования на уровне объектов.

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

6. Конфигурация клиента

На стороне клиента это стандартная конфигурация S3. Рассмотрим пример с использованием s3cmd:

Скрытый текст

Стоит отметить несколько моментов: используется адресация в стиле path‑style; поддерживаются протоколы SigV4 и SigV2 (поэтому устаревшие клиенты также могут подключаться); регион по умолчанию — us‑east-1.

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

7. Запись через S3, чтение как файла

Контейнер и анализирующий узел, к которому подключен тот же общий ресурс.

Контейнер выполняет загрузку без монтирования и без использования клиентского модуля ядра — просто посредством стандартного запроса PUT:

$ s3cmd put ./checkpoint-014.pt \

      s3://ml-results/datasets/2026/run-14/checkpoint-014.pt

upload: './checkpoint-014.pt' -> 's3://ml-results/datasets/2026/run-14/checkpoint-014.pt'

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

$ ls -l /mnt/ml-results/datasets/2026/run-14/

-rw-r--r-- 1 analyst analysts 2147483648 Aug 21 09:31 checkpoint-014.pt

Никакого экспорта, никакой второй копии.

Чтобы убедиться, что это действительно тот же самый файл, а не какая‑то фоновая копия, можно сравнить размер и контрольную сумму:

Скрытый текст

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

8. Запись в файл, чтение через S3

В обратную сторону это работает так же. На компьютере аналитика это обычная копия:

Скрытый текст

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

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

• Content‑Type определяется на основе расширения файла. Если расширение неизвестно или отсутствует, присваивается тип application/octet‑stream. Приведенный выше пример наглядно это демонстрирует: для файла с расширением.parquet устанавливается тип octet‑stream.

• ETag вычисляется в момент чтения.

• Значение Last‑Modified берется из атрибута mtime (времени последнего изменения) файла.

Если логика вашего конвейера обработки (пайплайна) зависит от MIME‑типа, предусмотрите это заранее, чтобы тип octet‑stream не нарушил работу цепочки операций.

9. Отличия в поведении по сравнению с AWS S3

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

1. Запрос PUT возвращает код 201 Created, а не 200 OK. На такие SDK, как s3cmd, aws‑cli и boto3, это никак не влияет, однако код, написанный вручную и проверяющий условие status == 200, ошибочно воспримет успешную операцию как сбой.

2. В ответах отсутствуют заголовки x-amz-request-id и x-amz-id-2. Некоторые системы логирования и трассировки рассчитаны на обязательное наличие этих полей, поэтому убедитесь, что ваши инструменты корректно обрабатывают их отсутствие.

3. Клиенты не могут создавать или удалять баскеты (buckets). Команда s3cmd rb возвращает ошибку 501 Not Implemented, что является ожидаемым поведением. Удаление данных — это отдельная явная административная операция, которая не выполняется через клиентское приложение.

4. Не поддерживается неявное рекурсивное удаление «папок». Ключ вида folder/ представляет собой обычный объект, и команда DELETE удаляет только этот объект. Очистка всего префикса (prefix) требует получения списка объектов и их последующего удаления порциями; именно так внутренне работает команда s3cmd del --recursive.

5. Максимальный размер одного запроса PUT составляет 5 ГиБ. Для объектов большего размера используется многочастная загрузка (multipart); популярные SDK переключаются на этот режим автоматически и, как правило, не требуют вмешательства с вашей стороны.

6. Запрос политики баскета (bucket policy) возвращает ошибку 501, а запрос CORS — 404 NoSuchCORSConfiguration. Авторизация определяется не политикой, а областью действия самого ключа доступа (баскет плюс префикс).

7. ACL объектов реализованы лишь для обеспечения совместимости. Запрос GET ?acl всегда возвращает фиксированный ACL с правами доступа private, чтобы графические клиенты, ожидающие наличия ACL, не завершались аварийно. За этим ответом не стоит реальное состояние ACL, и изменение настроек доступа не дает никакого эффекта.

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

9. Незавершенная многочастная загрузка видна на уровне файловой системы в виде отдельных фрагментов. Это еще не объект S3, и он не будет отображаться в списках объектов, однако при рекурсивном обходе со стороны файловой системы эти фрагменты будут обнаружены. Если ваш конвейер сканирует весь каталог и загружает всё найденное, это создает риск попадания «мусора» в ваш набор данных.

10. Практический подход: публикация контрольных точек

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

Операция S3 PUT либо еще не началась, либо уже полностью завершена. Пока идет загрузка большого файла в S3, объект не отображается в списке содержимого баскета (листинге), так как он становится видимым только после окончания загрузки. Таким образом, если объект виден, значит, он полностью записан.

При записи через файловый протокол ситуация обратная. Когда вы копируете (командой cp) большой файл в точку монтирования, файловая система сначала создает пустой файл и постепенно наполняет его данными. В процессе записи команда ls будет показывать этот файл, даже если он еще не достиг окончательного размера.

Если объединить оба этих механизма в одном пространстве имен, напрашивается следующий вывод: файл, записываемый в данный момент по протоколу NFS, может быть уже виден со стороны S3, причем он ничем не отличается от полностью записанного файла. Клиенты S3 привыкли исходить из принципа «если я вижу файл, значит, он готов», но в данном случае это допущение не работает.

Правильный подход — сделать публикацию файла явным действием. Существует два основных шаблона реализации.

Шаблон 1: использование промежуточного префикса (staging prefix). Файл загружается в место, которое не отслеживается потребителями; затем с помощью операции копирования на стороне сервера (server‑side copy) он перемещается в целевую директорию, где становится доступным сразу в готовом виде; после этого промежуточная копия удаляется.

Скрытый текст

Вариант 2: маркер завершения. Если вы хотите избежать лишнего копирования на стороне сервера, используйте файл‑маркер с расширением .done; в этом случае клиенты будут ожидать появления маркера, а не самого файла с данными. Этот маркер выглядит одинаково при работе через NFS, поэтому потребители с обеих сторон могут использовать одну и ту же логику обработки.

Скрытый текст

И последнее: механизм кросс‑протокольной блокировки не распространяется на одновременную запись в один и тот же файл с обеих сторон. Приложение должно самостоятельно обеспечивать последовательное выполнение таких операций; этот момент необходимо согласовать еще на этапе проектирования, а не выявлять уже в процессе эксплуатации.

11. Два домена авторизации, которые никогда не пересекаются

Права доступа в S3 и права доступа в файловой системе — это два совершенно разных мира, между которыми нет никакого соответствия ни в том, ни в другом направлении.

На стороне S3 используются ключ доступа и секретный ключ, ограниченные рамками конкретного баскета и префикса, с поддержкой механизмов подписи SigV2 и SigV4. На стороне файловой системы настройки включают конфигурацию общего ресурса (share) на массиве, правила доступа для хостов, а также владельца и права доступа в формате POSIX.

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

С другой стороны, это упрощает аудит: четко разграничено, кто и по какому протоколу получает доступ к данным — никаких «серых зон» или неопределенности.

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

12. S3 — самый простой способ вывода данных из контейнера

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

Не нужно ничего монтировать, не требуется устанавливать в образ дополнительные компоненты или зависеть от модулей ядра; в результате образ остается «чистым», а запуск контейнера с привилегиями не требуется. Модель прав доступа строится на учетных данных: вместе с задачей передается ключ, ограниченный рамками конкретного баскета или префикса. Недолговечные поды появляются и исчезают, не оставляя после себя «зависших» точек монтирования и не переходя в состояние ожидания ввода‑вывода (D‑state) при сбое на стороне сервера. Кроме того, HTTP‑интерфейс позволяет работать через границы сети, где монтирование непрактично или запрещено. Добавьте к этому видимость объекта целиком (потребителям не приходится гадать, завершилась ли запись файла) и возможность использования стандартных SDK и инструментов без какой‑либо специфической интеграции с конкретным поставщиком.

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

Суть не в том, что один протокол лучше другого. Главное — выбор протокола больше не определяет место хранения данных. Одни и те же данные доступны обоими способами, поэтому выбор протокола остается именно выбором протокола — и не более того.

13. Требования и модель конфигурации

При планировании следует учитывать неизменную зависимость:

Одна группа хостов = один S3-совместимый общий ресурс = один файловый ресурс = один баскет

Прочее:

• QSM 4.3.1 на поддерживаемых моделях; отдельная лицензия не требуется

• Управление через XInsight или REST API QSM 4; сервис S3 имеет собственный интерфейс командной строки (CLI) и REST‑интерфейс. Уровень управления (control plane) отделен от тракта передачи данных (data path)

• Общий ресурс (share) размещается в пуле с защитой RAID и двумя контроллерами, работающими в режиме Active‑Active. Снимки (snapshots) и стандартные сервисы работы с файловыми ресурсами QSM 4 применяются в обычном порядке

• Отключение сервиса S3 лишь приостанавливает доступ к объектам: привязка, сам ресурс, данные и основные настройки прав доступа сохраняются, а повторное включение восстанавливает доступ. Удаление — это всегда отдельная, явная операция

• Данный тип ресурса не поддерживает ни версионирование (Versioning), ни блокировку объектов (Object Lock). Если требуются соответствие нормативным стандартам или неизменяемость данных (immutability), следует выбирать тип хранилища, обеспечивающий эти функции

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

14. Контрольный список перед развертыванием

Проектирование общих ресурсов

• Определите, какие группы соответствуют каким протоколам, и активируйте только действительно необходимые службы (дополнительные можно будет добавить позже без перемещения данных).

• Выберите схему именования общих ресурсов, обеспечивающую создание корректных имен баскетов (строчные буквы, цифры, дефисы; длина от 3 до 63 символов).

• Убедитесь в отсутствии конфликтов имен с уже существующими баскетами.

Права доступа

• Проектируйте оба домена авторизации совместно, а не по отдельности.

• Ограничивайте область действия ключей максимально узко — до уровня баскета или префикса.

• Помните, что списки ACL и политики здесь не действуют; значение имеет только область действия ключа.

Поведение приложения

• Используйте явный механизм публикации (префикс для промежуточной стадии или файл‑маркер) вместо опроса (polling).

• Не допускайте одновременной записи в один и тот же файл с обеих сторон либо реализуйте сериализацию доступа на уровне приложения.

• Убедитесь, что клиенты корректно обрабатывают ответ 201 Created и отсутствие заголовка x-amz-request-id.

• Приведите все клиентские приложения к единой форме нормализации Unicode; рекомендуется использовать NFC.

Эксплуатация

• Исключите из процессов резервного копирования, сканирования и загрузки данных служебные каталоги, названия которых начинаются с точки.

• Не допускайте размещения более ~100 000 объектов в одном каталоге, так как это негативно сказывается как на скорости листинга в S3, так и на операциях с файлами.

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

• Рассчитывайте емкость и параметры параллельной обработки на основе проверенных конфигураций, а не предельных характеристик платформы.

15. О показателях эффективности

Как уже упоминалось, в этой статье не приводятся конкретные показатели производительности. И вот почему.

Производительность объектного хранилища зависит от ряда независимых факторов: распределения размеров объектов (обработка множества мелких файлов и небольшого числа крупных — это принципиально разные задачи), структуры каталогов и количества записей на каждом уровне, используемого протокола (S3 поверх HTTP или смонтированный сетевой ресурс, с поддержкой RDMA или без нее), степени параллелизма и соотношения операций чтения и записи, а также конфигурации пула и типа носителей.

Любые опубликованные цифры получены в строго определенных условиях. Стоит изменить модель оборудования, версию прошивки или характер доступа к данным — и выводы могут оказаться совершенно иными. А значит, для вашей конкретной среды эти показатели имеют ограниченную ценность.

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

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

• Фиксируйте параметры доступа, размер объектов и степень параллелизма вместе с каждым полученным показателем; без этих данных цифры спустя несколько месяцев потеряют смысл.

• Сначала измерьте производительность для каждого протокола по отдельности, а затем — при их одновременной работе.

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

16. Типовая конфигурация

Система хранения данных располагается между вычислительным уровнем и остальной частью организации. Серверы, выполняющие задачи ИИ, записывают результаты по протоколу S3, не выполняя операций монтирования. Команды, занимающиеся последующей аналитикой и работой с приложениями, монтируют общий ресурс по протоколу NFS или SMB и считывают эти же файлы напрямую. Облачные приложения и конвейеры автоматизации используют ту же конечную точку S3.

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

Заключение

Если кратко: задача обучения записывает результаты в S3 — это наиболее простой путь вывода данных из контейнера; смежные команды монтируют тот же общий ресурс и считывают тот же самый файл; данные файла становятся доступными как объекты без необходимости их перемещения; таким образом, во всей системе существует лишь одна копия данных.

Стоит еще раз подчеркнуть ключевые ограничения, поскольку их необходимо учитывать на этапе проектирования, а не сталкиваться с ними как с неожиданностью в процессе эксплуатации. Поскольку временные характеристики публикации для этих двух протоколов различаются, требуется явный механизм публикации. Домены авторизации независимы друг от друга, но их настройку необходимо планировать комплексно. Требования к версионированию и неизменяемости данных подразумевают использование другого типа хранилища.

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