Распределенная файловая система для картинок. Желательно что бы в системе монтировалась как обычная.

Ceph? GlusterFS?

Вот как раз про них хотел спросить - А они могут быть смонтированы как обычная файловая система? Ну что бы nginx просто из папки раздавал файлы, не задумываясь где он на самом деле храниться.

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

NFS вполне себе распределённое.

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

Вам нужно определиться с архитектурой (distributed, replicated, dispersed, etc) и учесть пропускную способность. Возможно, этот подход для Вашей задачи неприменим. Если ноды географически разнесены, затея контрпродуктивна даже если 80% операций - чтение (скорость лежит до момента fdatasync всех реплик). Архитектурно присутствуют жесткие требования по идентичному объему bricks. При использовании механизмов гео-репликации скорость работы гео-распределенного хранилища стабилизируется (два независимых SAN регулярно синхронизируются с помощью rsync), т.е в единый момент времени нет консистентности, один пул видит файл, второй - еще нет.

Все то же самое актуально для Ceph, не считая отсутствия требований к объему osd.

По части общих временных данных, я решал похожую задачу с помощью двух пулов gluster, один геораспределенный для статических данных, второй - внутренний, хранящий базу stdb. Могут возникнуть нюансы с блокировками, не знаю, насколько это актуально для вашего приложения.

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

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

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

Есть опыт с NFS на довольно популярном высоконагруженном международном проекте. Проблем не было, но это всё же не уровень Facebook или Netflix. С другой стороны, у вас точно будет такое же количество запросов, как у них?

А если делать по-уму, то статику не проще ли отдавать через какую-нибудь связку S3/minio + CDN?

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

Это в локальном окружении нужно будет. А как CDN в локалке сделать?

Кстати а как вообще было устроено NFS? 1 сервер и несколько клиентов? Т.е. все писали на одну физическую машину получается?

Ну т.е. правильно понимаю что ты предлагаешь сделать промежуточный код скажем на php или чем угодно еще который будет по ид картиник вытаскивает ее из S3 хранилища и отдавать отдельной байты? Т.е. под кажду картинку будет запускаться скрикт с логикой, а не просто nginx отдавай файл.

Nginx должен и сам уметь лазать в S3. Я не пробовал, но я о-очень удивлюсь, если такого нет.

Так куда лучше копать - Ceph,gluesterFS, MinIO?

MinIO

Да, был один сервер NFS, который монтировался на нескольких серверах с nginx. Записей было мало, в основном, все файлы были статическими, объем загружаемых был минимален.