Как передавать большие файлы между микросервисами?

Question

[Rodion]

Добрый день!

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

Тезисно:
- Есть хранилище тяжёлых файлов (примерно по 1ТБ на каждый)
- Есть набор микросервисов-воркеров, которые по заданию в определённый момент хотят загрузить файл из хранилища и в определённый момент выгрузить его обратно
- Между хранилищем и микросервисами - сесть одна, локальная
- Сами сервисы написаны на Python
- Передача файлов в данный момент организована открытием подпроцессов (стандартной библиотекой subprocess) с командой scp /local-file user@host:remote

Считаю текущий вариант не оптимальным и почти неуправляемым. Есть какие-то более лучшие практики организации передачи больших файлов туда-обратно? Желательно, чтобы это хорошо работало в Docker контейнерах сквозь docker volumes.

Рассматриваю вариант в сторону чистого Nginx (обычной отдачей статики) или найденного minio решения (которое ещё не изучил).

Comments

[Сергей Горностаев]

Зависит от того, для чего вы их передаёте между микросервисами и хранилищем, а также от того, что за хранилище.

[Rodion]

Сергей Горностаев, Хм... файлы передаются, грубо говоря, на другое железо для использования другой полноценной службой и процессинг там - чёрный ящик. После процессинга (время не определено) его результат (в виде файла) заменяется заменяет устаревший.

Хранилище там - RAID массивы из SSD накопителей: точнее не скажу, не знаю.

Answer 1

[Иван Шумов]

Зависит от характера процессинга файлов и разделения зоны ответственности. Есть как варианты s3-хранилищ, так и стриминг через кафку, так и никуда не девающиеся сетевые протоколы (nfs и iscsi если правильно уже помню аббревиатуры)

Comments

[Rodion]

Про s3 можно подробнее? Я так понимаю, в таком случае идёт своего рода привязка к облакам типа Amazon и прочих. В моём же случае - уже есть RAID хранилище из большого набора SSD накопителей и отсутствие желания и возможностей использовать облачные решения.

[Иван Шумов]

Rodion, minio это тоже s3. Ужасно спроектированный, но все-же

[Сергей Горностаев]

Rodion, S3 - это тип хранилищ, без привязок. И у этого типа есть например потоковое API, позволяющее асинхронно читать и писать файлы небольшими блоками.

[Иван Шумов]

Сергей Горностаев, чанки это вообще основы основ http протокола ) не помню как они конкретно в s3 реализованы, не удивлюсь если это одно и то же. Но по факту на полёт не влияет

[Сергей Горностаев]

Иван Шумов, у в проекте меня S3 на Ceph, файлы читаются, обрабатываются и пишутся реактивными стримами без нагрузки на память и диск контейнеров. Весьма удобно.

[Иван Шумов]

Сергей Горностаев, ceph неплох по отзывам, да. А вот minio в мало-мальском проде колом встаёт

[Rodion]

Иван Шумов, Сергей Горностаев,

А что насчёт GlusterFS...? Только вспомнил что когда-то на одном из проектов (правда он так и не запустился) использовался именно он; к сожалению даже не помню с какими целями.

Answer 2

[uvelichitel]

Самый быстрый способ передачи между nix системами командой nc. Можно её использовать вместо scp.
Если профиль процессинга таков что микросервис часто использует одни и те же тяжёлые файлы, то можно держать на машине с сервисом локальную копию такого часто используемого файла. Синхронизировать с хранилищем командой rsync. При этом будут передаваться только сделанные изменения, трафик существенно сократится, работать будет быстрее.
Ну и первым приходит в голову очевидный вопрос -- а почему не запускать обработки на машине хранилища, что бы тяжёлые файлы не гонять?

Comments

[Rodion]

Всё логично и верно, но условия и суть сервиса (как услуги) такова, что передача файлов туда-обратно - это часть бизнес-процесса.

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