Какую файловую систему использовать для разнесения бекэнда и фронтэнда?

Question

[Валентин]

Хочу разнести на разные машины бекэнд и фронтэнд. Сами машины находятся в разных ДЦ с разными IP-адресами. Один хостинг российский - на нем будет nginx+статика, другой буржуйский джанга+постгрес для бекэнда.

Так вот для удобного аплода media-файлов хочу подмонтировать удаленную файловую систему на ВМ с бекэндом. Т.е. чтобы в настройках можно было просто указать MEDIA_ROOT = /mnt/remotedrive и не добавлять никакие дополнительные либы в код проектов. Таким образом файл будет проливаться из бекенда сразу на другой сервак.

Что посоветуете использовать и почему? NFS, SFTP, FTP etc? Или есть какой-то другой вариант.

Comments

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

Я бы посоветовал так не делать.

[sim3x]

Для такого есть django-storages.readthedocs.io/en/latest/backends/...

[Валентин]

sim3x, документацию я читать умею, но кто сказал, что мне надо использовать амазон?

[sim3x]

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

Answer 1

[Алексей Черемисин]

Вариантов немного, конечно же NFS, но есть возможность повеситься при обращении к файловой системе (причем на очень продолжительное время), когда она (NFS) недоступна например из-за отсутствия связи.
Со своей стороны я бы такого не делал, а поставил бы какой нибудь CDN сервис типа S3, куда и бросал бы файлы. Например minio https://www.minio.io
Вот еще один интересный проект, немного не S3, но по архитектуре довольно прикольный - https://github.com/chrislusf/seaweedfs

Comments

[Валентин]

Для nfs есть какой-нибудь вариант указать fallback?

[Алексей Черемисин]

Валентин, Честно говоря не помню, но не ошибусь, если скажу что в рамках NFS3/NFS4 такого функционала нет. Возможно есть в PNFS, но это отдельно разворачивать нужно, да и в стандартном кернельном сервере его нет, нужно ставить ganesha.
Поэтому и не рекомендую использовать файловые системы под это дело. У них другие задачи, вам же не критично показать код ошибки, при доступе к медиафайлу.

Что касается NFS, то это самый быстрый механизм дял доступа к удаленной файловой системе в линуксе. Мы, например используем NFS на кластере в пару десятков серверов, но это все локально в датацентре. Если же распрелеленно и для web, то я не советую таким образом отдавать данные.

[Валентин]

Алексей Черемисин, у меня задача - окучивать пачку мелких сайтов, медиа для них загружается из админки. Мне не сильно критично временная приостановка непосредственно аплода.

Почему не sshfs/ftpfs?

[Алексей Черемисин]

Вот, есть в automount опция

fileserv host1,host2:/server/export/point

Но это будет работать только (!) при монтировании, и не спасет вас от ситуации обрыва связи при уже подмонтированной NFS. А здесь еще вступит в свои права ядро, которое до последнего будет пытаться достучаться до файлов, ядро то ведь не знает, что у него повис NFS, ему в рамках VFS все равно, через чего идет обращение, через сеть или через SATA/SAS.

[Алексей Черемисин]

Валентин а чем sshfs/ftpfs принципиально отличается от nfs? Это же все равно Файловая Система (!), пусть и через FUSE, которая при монтировании и доступу к файлу/каталогу прорастет в ядро через VFS, будет сидеть ссылками и точками доступа в кешах ядра.
Любое отключение хоть локальной, хоть удаленной файловой системы без размонтирования равносильно вытаскиванию жесткого диска из сервера на горячую!
Да и сетевые файловые системы придуманы немного не для того, они нужны для прозрачной работы программ с удаленным хранилищем, как будто оно здесь и сейчас, включая, по возможности всякие POSIX вызовы.

Ну и по поводу:

Мне не сильно критично временная приостановка непосредственно аплода

У вас может остановиться не только аплоад, у вас встанет все, что хоть откроет файл/каталог через удаленную файловую систему, собственно весь IO пойдет на смарку.

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

[Алексей Черемисин]

Валентин, Ну и в догонку, а что вам запрещает сразу заливать файлы куда нужно? Через свой собственный json/rest/WEB-API? Я в своих приложениях так и делаю.

[Валентин]

Алексей Черемисин, у меня нет времени добавлять api на пачку клиентских сайтов.

[Валентин]

Алексей Черемисин, за minio спасибо, классная вещь.

Answer 2

[Иван]

SSHFS

Comments

[Валентин]

И что, не тормозит? пинг между серваками 20мс.

Answer 3

[Пума Тайланд]

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

Comments

[Валентин]

А мне надо чтобы файлы автоматом попали на фронтенд.

[Пума Тайланд]

Валентин, ну если важна производительность надо их копировать на фронт а не прокидывать по сетевой файлухе

Answer 4

[chupasaurus]

Заливайте на бекенд, а дальше пусть nginx на фронте кеширует, он для этого в том числе и нужен

Comments

[Валентин]

Это как?

[chupasaurus]

Валентин, Официальный гайд, документация (proxy_cache*).

[Валентин]

chupasaurus, так мне придется на бекэнде тоже держать nginx для передачи статики фронтэнду только для дальнейшего кеширования. Без этого можно?

[chupasaurus]

Валентин, Не надо, джанго как брала файлы с диска (а там уже есть кеш от ОС), так и будет.

Answer 5

[Валентин]

Во-первых - такие монтирования аукнутся во внештатных ситуациях. Во-вторых - nginx ведь кэшировать умеет, ну вот пусть и кэширует.