Witam,

Mam małe pytanie odnośnie przechowywania plików na tym samym serwerze co aplikacja. W mojej aplikacji będzie przechowywane bardzo dużo plików różnego typu. Zastanawia mnie czy w takich wypadkach istnieje technika gdzie istnieje serwer tylko dla www oraz serwer plików. Przez serwer www wysyłamy plik a on natomiast na serwer plików.

Chciałbym tak zrobić, żeby zmniejszyć koszty utrzymania serwera aplikacyjnego. Natomiast serwer plików miał by tylko usługę jako przestrzeń dysków i nic po za tym więc jeśli by brakowało miejsca to będę musiał tylko dokupić giga. Ograniczy to też transfer na serwerze aplikacyjnym.

Czy istnieje taka technika ? Może macie jakieś doświadczenie w tym temacie albo znacie jakieś dobre artykuły ?

Pozdrawiam.

Artykułu do czego? Chyba każdy serwis, gdzie przechowuje się duże ilości plików tak robi. Aplikacja jednak do tego musi być dostosowana: czy to do zarządzania plikami poprzez SFTP, czy też na jakimś storagu od Amazona.

Dobra zarzędzie abstrakcji systemu plikóww PHP: https://github.com/KnpLabs/Gaufrette.

@pedro84
Dzięki wielkie za odpowiedź.

A czy w czasie upload`u plików przez użytkowników to muszę przez FTP wrzucać te pliki na inny serwer ?

Możesz najpierw u siebie do tmp, potem przenosisz, albo bezpośrednio na storage. Od wielu zmiennych to zależy.

Mógłbyś zrobić na zasadzie jakiegoś API.
Aplikacja wysyła zgłoszenie do API na Storage, a ten sobie pobiera plik.

Pytanie zasadnicze, czy są to dedyki/vpsy czy shared? Jeśli dedyki, to możesz zrobić prosty NFS z podmontowaniem zewnętrznego serwera, ewentualnie stworzenie jakiejś "chmury" czyli elastyczność podpięcia kolejnych maszyn.

Hej,

@ohm jeszcze nic nie wiadomo, chcieliśmy dedyka na aplikację a na serwer plików jakiś inny serwer. NFS - możesz rozwinąć ten skrót bo chyba nie chodzi o Need For Speed

@Pyton_000. Też myślałem o tym ale raczej odpada na razie.

@pedro84 dzięki za link do "Gaufrette".
Bawię się tym i jest to super narzędzie !

Korzystam z Symfony2 i obecnie zrobiłem sobie service, dzięki któremu będę w całej aplikacji mógł upload`ować pliki nie patrząc na to gdzie będą przechowywane (czy na lokalu czy na innym serwerze) ale i tak zawsze do nich będę miał dostęp.

Dzięki wielkie za odpowiedzi.

NFS - network filesystem
Co do innych rozwiązań tzw. chmurowych to jeszcze są takie opcje: https://en.wikipedia.org/wiki/Comparison_of...ed_file_systems

No jak masz dostęp do shella, to sshfs, montujesz katalog i pliki z temp przenosisz tam.

@by_ikar @ohm
A jak użytkownik prześle mi plik, który potem prześle przez FTP na inny serwer (serwer plików) to będzie chyba okey ? Już implementuje takie rozwiązanie w swojej aplikacji więc mam nadzieję, że będzie ok

Ma to jedną wadę.
Może się zdarzyć przypadek że będziesz miał xxx otwartych połączeń FTP i/lub blokadę otwarcia kolejnych.

Rozwiązanie z API jest o tyle elastyczne że dodajesz plik do kolejki pobrań i nie martwisz się o nic. Po pobraniu wysyłasz tylko zwrotną wiadomość aby z serwera app usunięto plik.

Rozwiązanie na opóźnienie jest takie, że najpierw trzymasz dowiązanie do serwera aplikacji, a po zwrotce z API storage zmieniasz dowiązanie na tamten i usuwasz sobie plik. Koniec

FTP to niestety słabe rozwiązanie, byle jakieś przerwanie połączenia między serwerami i plik leży uszkodzony. Nie masz zbyt dużego manewru żeby sprawdzić czy taki plik jest prawidłowo przesłany.

Ktos wyzej napisal o NFS - mozna, mozna tez GlusterFS i wtedy masz odrazu replikacje, mozna tez DRBD.
Co do API, FTP, i innych wynalazkow, taaak... moze jak jest jeden plik na jakis czas to moze i zadziala, ale na twoim miejscu bym zapomnial o takich "rozwiazaniach"
Masz inny problem i go bedzie ciezko przeskoczyc - duzo plikow. NFS sprawdza sie jak masz duzy ruch IO do niewielu plików, przy setkach i wiecej malych plikow wydajnosc drastycznie spada. To samo gluster, replikacja dziala fajnie ale jest wolny. Jak chcesz serwowac duzo malych plikow na duza skale to nie ma bata musisz je albo shardowac (consistent hashing) albo masz duzy zasob a'la serwer aplikacyjny i wiele malych serwerow z reverse cached proxy (nginx / varnish), ktore robia za cache.

Ja dedyka brałem z SDC - w opcji ECO 0 - jak na moje potrzeby wystaczającej. Jak na razie - jestem zadowolony, szczególnie, ze maja w porządku support.