Нужно разделять stateless-сервисы и stateful-сервисы. Первые Вы можете раскладывать по нескольким хостам и не париться, а вот другие надо думать как именно их масштабировать, и какие гарантии нужны. По хорошему, само Ваше приложение должно быть stateless, и не монтировать никаких директорий, куда бы складывало файлы на длительное хранение, а заливало бы эти файлы для длительного хранения на другой специальный файловый сервер хоть по S3 bucket интерфейсу, хоть по, прости господи, FTP.
Ещё здесь Важен вопрос каковы Вам нужны гарантии в данной ситуации. Если у Вас файлов мало, то можно тупо копировать файл на каждый из хостов (постоянной фоновой синхронизацией). Если файлов очень-очень много, то на один хост они никогда не влезут и нужно делать размазывание файлов по нескольким хостам с определенным уровнем избыточности (мы ведь не хотим потерять файлы навсегда, когда на одном из хостов полетит диск).
Каковы есть/приходят на ум варианты:
- Поднять на всех хостах распределенную файловую систему (CephFS, GlusterFS, и т.п.). Монтируем в контейнер приложения volume под этой системой и тупо пишем туда файлы как обычно. Распределенная ФС самостоятельно размажет файлы по хостам в зависимости от желаемых настроек. Читаем файлы из той же директории.
Плюсы: не нужно менять код приложения, легко использовать, простая концепция в понимании.
Минусы: при интенсивной работе с файлами может не хватать производительности (подобные ФС считаются медленными), при отвале части хостов может не работать запись (так как требуется кворум n/2 + 1), эксплуатация/поддержка подобных систем может быть не самой тривиальной задачей (веселой починки сломавшегося Ceph-кластера).
- Поднять на всех хостах Minio (свой poor man's S3 bucket), либо другой свой отдельный файловый сервер. Работает в двух режимах: single (одна нода работает только со своими файлами, запись в несколько надо надо делать на стороне приложения, и фоновую синхронизацию тоже самостоятельно) и distributed (ноды обьединены в кворумный кластер с размазыванием файлов).
Плюсы: S3 bucket интерфейс, легкая эксплуатация, можно монтировать как ФС.
Минусы: возможно нужно менять код приложения (чтобы уметь работать с S3), производительность на чтение в distributed режиме медленная (сравнима с распределенными ФС из пункта 1).
- Просто монтировать на каждом хосте локальную директорию, для которой настроить постоянную фоновую синхронизацию через BitTorrent Sync какой-то (а может даже просто rsync).
Плюсы: производительность обычной ФС, никаких кворумов (а значит блокировок на запись), легко использовать (монтируешь и вперёд).
Минусы: файлы доступны на других хостах только через какое-то время, а значит приложение должно уметь это учитывать, возможна потеря данных (нода приняла файлы и сгорела не успев их отсинхронизировать на другие), если файлы не влезают на один хост - то вариант не подходит, либо шардить (размазывать) придётся руками самостоятельно в приложении.
- Использовать готовое отказоустойчивое облако: AWS Bucket, DigitalOcean Space и т.п.
