Распределенная ФС для картинок

Кто что использует для подобного?

Ты не поверишь! reiserfs.

Тебе CDN нужен

можно люстру заюзать https://www.lustre.org/

но что-то мне подсказывает, что тебе просто нужен нормальный NAS и быстрая сеть до него

М, нет, предполагается что есть несколько серверов разных ДЦ (3-4 машины). Нагрузка не такая заоблачная чтобы был нужен cdn. Т.е это даже не критические данные, но с одной стороны не хочется ими. нагружать основную БД, а с другой их потеря это небольшое неудобство для пользователей, которого тоже избежать хочется.

Может s3 и не такое уже плохое решение, смотрю там до 50Гб вроде даже бесплатный доступ, или мне кажется?

5gb хранилища, первый год бесплатный, но это по сути и есть NAS

для распределенного хранения картинок?

Извини за занудство, но распределенное хранение это не самоцель. А точная цель не была в явном виде озвучена. К необходимости «распределенности» приходят по разным причинам.

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

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

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

Может мне и обычный rsync по крону подойдет ;))

https://tracker.ceph.com/projects/ceph/wiki/

Возможно вам подойдет IPFS

Ceph по идее для этого предназначен.

Кажется никакого навороченного тормозного говна типа ceph, lustre и, боже упаси, ipfs вам тут нахрен не нужно, вам просто нужна простейшая репликация файлов между серверами.

В самом простом случае (картинки только добавляются, лаг репликации не критичен) это можно сделать тупейшим rsync’ом по крону (все сервера со всеми, или только с соседями, в зависимости от допустимой нагрузки и желаемых задержек). Картинка добавленная на любой сервер за конечное время расползётся на все.

Требований и условий вы никаких не указали, поэтому развивать мысль на более сложные случае не вижу смысла.

Да, в принципе рсинк подходит. Но единственное что хочется - при появлении картинки копирование начинается сразу, с минимальной задержкой

Ну используй для этого любой удобный push механизм. Хоть явно rsync’ни этот файл на все живые сервера с машины где он появился. Можешь даже синхронно.

То что можно это сделать понятно. Ищу что-то готовое ) Т.е rsync + обвязка которая будет его запускать это ок. Есть ли такая обвязка? Чтобы он стартовал по событию, если упал то как-то ждал и повторял например

Тогда тебе нужно inotifywatch в режиме демона с перенаправлением вывода в while read. Небольшой скриптик на баше вопрос закроет.

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

https://github.com/chrislusf/seaweedfs

Он сообщить удосужился, а ты прочитать нет.

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

Но это и из самого поста вполне очевидно.

inotifywatch -e create ему нужен, а не крон, но крон с интервалом в полчаса тоже не помешает для надёжности.

хранения картинок

Дрочишь небось?

Очевидно же, что событие это изменение файлов..

На тебя дорогой)

Большое спасибо ) Попробую такую штуку!

S3 не предлагать, интересует именно решение которое можно самостоятельно поднять.

minio уже советовали? Плюсом идёт совместимость c S3 и её тулзами.

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

Описывают так: пришёл клиент, таким-то протоколом соединился с таким-то сервером, передал ему файл, сервер сохранил его на диск по временному пути, после завершения приёма сделал fsync, переместил файл из временного места в постоянный каталог хранилища и отдал клиенту success. Требования - потерять данные нельзя (либо нестрашно, клиент зальёт ещё раз); клиенту запросившему только что залитую картинку допустимо её не увидеть (либо допустимо в случае отвала сервера, либо не допустимо ни в каком случае); ответ клиенту должен возвращаться в течение 100мс (либо не страшно что подождёт минуту) и т.д.

В этой схеме в зависимости от требований я бы тебе сказал - можно сделать push rsync’ом на все сервера с каким-то таймаутом после перемещения файла в хранилище до отдачи ok клиенту, это будет эквивалент синхронной репликации, клиенту вернётся ok когда файл уже будет на всех живых серверах и его можно будет прочитать (кроме случая когда отставший сервер возвращается в строй, но это решается так-то и так-то), но нужно дольше ждать, особенно когда какой-то сервер отвалится и под выросшей нагрузкой.

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

Можно ещё ослабить требования и делать push после отдачи ok клиенту (можно из сервера, а можно и из какой-нибудь мониторилки ФС что может быть где-то проще) - это уже ближе к eventual consistency. Можно и потерять данные о чём клиент не узнает, и клиент можно запросить картинку которая не успела разъехаться. Но это всё ещё удовлетворяет единственно озвученному тобой требованию «копирование начинается сразу, с минимальной задержкой».

Ты какие-то отдельные слова из того что я пишу читаешь, да?

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

lsync

Вот кстати неплохой совет, попробуй.

lsync

OxiD, а вот и готовое решение без велосипедов как по заказу. Под капотом те же rcync и inotify. Не слушай меня, слушай его.

https://help.ubuntu.ru/wiki/lsyncd