Quale protocollo di condivisione file di rete offre le migliori prestazioni e affidabilità? [chiuso]

Abbiamo una configurazione con alcuni server Web bilanciati in base al carico. Vogliamo avere una sorta di archivio di rete condiviso a cui tutti i server Web possano accedere. Sarà utilizzato come luogo per archiviare i file caricati dagli utenti. Tutto esegue Linux.

Dovremmo usare NFS, CIFS, SMB, fuse + sftp, fuse + ftp? Ci sono così tante scelte là fuori per i protocolli di condivisione dei file di rete, è molto difficile sceglierne uno. Fondamentalmente vogliamo solo montare permanentemente questa condivisione su più macchine. Le funzionalità di sicurezza sono meno preoccupanti perché non saranno accessibili dalla rete da nessun'altra parte rispetto ai server che la montano. Vogliamo solo che funzioni in modo affidabile e rapido.

Quale dovremmo usare?

Io voto per NFS.

NFSv4.1 ha aggiunto la funzionalità pNFS Parallel NFS, che rende possibile l'accesso ai dati in parallelo. Mi chiedo che tipo di client stiano usando l'archiviazione se solo Unix fosse simile a NFS in base ai dati sulle prestazioni.

La risposta breve è utilizzare NFS. Secondo questa sparatoria e la mia esperienza, è più veloce.

Ma hai più opzioni! Dovresti considerare un cluster FS come GFS, che è un filesystem a cui più computer possono accedere contemporaneamente. Fondamentalmente, condividi un dispositivo a blocchi tramite iSCSI che è un filesystem GFS. Tutti i client (iniziatori nel linguaggio iSCSI) possono leggere e scrivere su di esso. Redhat ha un white paper . Puoi anche usare il cluster OCFS di FS Oracle per gestire la stessa cosa.

Il documento redhat fa un buon lavoro elencando i pro ei contro di un cluster FS vs NFS. Fondamentalmente se si desidera ridimensionare molto spazio, GFS probabilmente vale la pena. Inoltre, l'esempio GFS utilizza una SAN Fibre Channel come esempio, ma potrebbe essere altrettanto facilmente una SAN RAID, DAS o iSCSI.

Infine, assicurati di esaminare i frame jumbo e, se l'integrità dei dati è fondamentale, usa il checksum CRC32 se usi iSCSI con i frame jumbo.

Abbiamo un cluster Web con caricamento del carico a 2 server. Abbiamo provato i seguenti metodi per sincronizzare il contenuto tra i server:

• Le unità locali su ciascun server sincronizzate con RSYNC ogni 10 minuti
• Una condivisione CIFS centrale (SAMBA) con entrambi i server
• Una condivisione NFS centrale per entrambi i server
• Un'unità SAN condivisa che esegue OCFS2 ha montato entrambi i server

La soluzione RSYNC era la più semplice, ma ci sono voluti 10 minuti per mostrare le modifiche e RSYNC ha caricato così tanto sui server che abbiamo dovuto limitare con uno script personalizzato per metterlo in pausa ogni secondo. Eravamo anche limitati a scrivere solo sull'unità sorgente.

L'unità condivisa con le prestazioni più veloci è stata l' unità cluster OCFS2 fino a quando non è diventata pazza e si è schiantato sul cluster. Non siamo stati in grado di mantenere la stabilità con OCFS2. Non appena più di un server accede agli stessi file, il caricamento sale attraverso il tetto e i server iniziano a riavviarsi. Questo potrebbe essere un fallimento della formazione da parte nostra.

Il prossimo migliore è stato NFS . È stato estremamente stabile e tollerante ai guasti. Questa è la nostra configurazione attuale.

SMB (CIFS) ha avuto alcuni problemi di blocco. In particolare, i web server non vedevano modifiche ai file sul server SMB. SMB tendeva anche a bloccarsi in caso di errore sul server SMB

La nostra conclusione è stata che OCFS2 ha il massimo potenziale ma richiede MOLTE analisi prima di utilizzarlo in produzione. Se si desidera qualcosa di diretto e affidabile, consiglierei un cluster di server NFS con Heartbeat per il failover.

Ti suggerisco POHMELFS - è stato creato dal programmatore russo Evgeniy Polyakov ed è davvero, molto veloce.

In termini di affidabilità e sicurezza, probabilmente CIFS (aka Samba) ma NFS "sembra" molto più leggero, e con un'attenta configurazione, è possibile non esporre completamente i tuoi dati preziosi ad ogni altra macchina sulla rete ;-)

Nessun insulto alla roba FUSE, ma sembra ancora ... fresco, se sai cosa intendo. Non so se ancora mi fido, ma potrei essere solo io che sono un vecchio misty, ma il vecchio fogeyismo a volte è garantito quando si tratta di preziosi dati aziendali.

Se vuoi montare permanentemente una condivisione su più macchine e puoi giocare con alcune delle stranezze (principalmente problemi UID / GID), quindi usa NFS. Lo uso e lo uso da molti anni.

NFS. È provato e vero e puoi avere una configurazione solida come una roccia. Le prestazioni di GFS sono generalmente orribili, specialmente su filesystem con un numero elevato di piccoli file. Non ho usato OCFS, ma generalmente disapprovo il concetto di filesystem del cluster. Poi c'è Lustre, ma questa è un'altra lattina di vermi ...

Vorrei sconsigliare NFS. In poche parole: avevamo una web server farm, con JBoss, Apache, Tomcat e Oracle che utilizzavano tutte le condivisioni NFS per i file di configurazione e la registrazione comuni.

Quando la condivisione NFS è scomparsa (è vero che si è verificato un evento raro) l'intera cosa è semplicemente crollata (prevedibile davvero, e ho consigliato ai "devlopers" di non utilizzare questa scorciatoia del tempo di configurazione).

Sembra che ci sia un problema con la versione di NFS che stavamo usando che, se la destinazione scompariva durante una scrittura, il client sarebbe caduto in un ciclo di attesa senza fine, aspettando che la destinazione NFS tornasse. Anche se la casella NFS è stata ricollegata, il ciclo non è ancora terminato.

Stavamo usando un mix di RHEL 3,4,5. Lo storage era su RHEL4, i server erano su RHEL5, la rete di storage era una lan separata e non funzionava su vlans.

Se è presente un front-end con bilanciamento del carico, che controlla la singola memoria, ciò non strozzerebbe il sistema?

Hai preso in considerazione una connessione iSCSI di sola lettura al tuo archivio, con uno script basato sugli eventi per spostare il file caricato nell'archivio tramite ftp / scp quando viene caricato un file?

L'unica volta che ho implementato con successo una memoria centralizzata per più testine di lettura è stata su un array di memoria EMC ... Tutti gli altri tentativi economici hanno avuto i loro svantaggi.

Considerato GFS? GFS è un filesystem a cluster e, nella mia esperienza, è abbastanza affidabile. Può avere più di un diario, si adatta abbastanza bene

Ma dovresti installare alcuni servizi cluster e GFS non è esattamente noto per la sua rapidità. Otoh, è sempre stato abbastanza veloce per me, ma ymmv.

Saresti fuori di testa a considerare un FS distribuito come GFS e iSCSI è eccessivo.

Se vuoi semplicemente vai con NFS. È semplice e veloce e con supporti morbidi abbastanza robusti. Considera anche di disabilitare tutta la posta indesiderata associata. Ho desktop Linux che catturano tutte le loro directory home e applicazioni da NFS, funziona benissimo.

Se vuoi una velocità oltraggiosa vai con Lustre, che è significativamente più facile da configurare di GFS ed è molto simile a RAID NFS. Usiamo Lustre per i nostri cluster.

Potrei essere un po 'in ritardo, utilizziamo un Dell Dell MD3220 con cluster a doppia porta, la nostra unità ha 2 controller in caso uno si spenga in secondo luogo continuerà a funzionare fino a quando non risolviamo il problema. Poiché HDD, FAN, alimentatore e controller sono tutti Hotswap, sostituiamo le parti dentro e fuori. A partire dal formato utilizziamo NFS.

Se hai già server web ovunque e sei bravo a gestirli, perché non prendere in considerazione WebDAV?

Risposta semplice +1 per NFS. Ho condivisioni NFS che sono state montate per anni senza problemi.

Se stai cercando un'affidabilità eccellente, considera la possibilità di inserire DRBD nel mix anche per un filesystem NFS distribuito con failover automatico.

L'unica altra opzione (che conosco) è l'iSCSI ma può essere una seccatura da configurare ...

Hai un sacco di opzioni, con una varietà di costi. SAN condivisa con FC, iSCSI o una delle aggiunte più recenti. In ogni caso, possono essere costosi da configurare ed è comunque necessario eseguire un file system compatibile con i cluster. I filesystem a cluster sono un mondo di dolore. Per ogni speranza di successo sono necessarie reti separate ad alta velocità e bassa latenza per la comunicazione e i dati del cluster. Anche con ciò, è probabile che si verifichino problemi tecnici che provocano la recinzione e la morte di un nodo.

L'unico file system del cluster che ho trovato che funziona senza problemi è VMFS. Ma è così specializzato, non sarebbe utile anche se fosse disponibile per uso generale.

NFS è probabilmente la strada da percorrere per la tua configurazione. Se sei preoccupato per la resilenza, devi procurarti una scatola NFS in cluster adeguata. Puoi fare una configurazione homebrew, ma colpiresti il ​​problema sopra. La migliore scommessa (se hai i soldi), è cluster NetApp filer. È un'opzione costosa, ma il clustering funziona davvero senza problemi. Non solo, sono molto veloci.

Vorrei fare eco all'avvertimento che alcuni hanno dato contro NFS - anche se NFS è probabilmente la soluzione migliore (strano come sembra).

Avevo un client NFS che dovevo disconnettere da AC per spegnerlo perché il server NFS era scomparso e il client ha rifiutato (nel kernel) di sbloccare o arrestare perché il server NFS era scomparso.

Per farlo nel modo giusto, insisto su NFSv4, mi attengo alle connessioni TCP, uso i frame jumbo e uso un cluster NFS. Non puoi permetterti di far sparire il tuo server NFS.

GFS è un voodoo seriamente nero. La quantità di lavoro richiesta per far funzionare un semplice cluster a due client è sconcertante rispetto alle alternative. OCFS2 è molto più semplice da implementare ma è molto esigente quando si tratta delle versioni del modulo kernel coinvolte su tutti i server collegati - e questo è solo l'inizio.

A meno che tu non abbia davvero bisogno del tipo di accesso a basso livello offerto da un filesystem del cluster, NFS o CIFS è probabilmente tutto ciò di cui hai bisogno.

In una grande server farm avevamo diversi milioni di pagine HTML create dall'utente. NFS non ha funzionato così bene, quindi abbiamo finito per metterli in una tabella mysql. Il sovraccarico rispetto alla traversata di un albero di directory era più o meno lo stesso.

Ho usato SFTP e ha funzionato bene per i miei scopi - NFS è stato il mio primo ricorso, ma la stranezza degli ID utente / gruppo mi ha fatto cadere piuttosto rapidamente.

Basta impostare l'autenticazione con chiave pubblica e sarai in gran parte impostato. Potrebbe esserci un sovraccarico della CPU un po 'più pesante per la crittografia SSH, ma il lato positivo non ho mai riscontrato problemi con la corruzione dei dati.

FTP potrebbe comunque adattarsi ai tuoi scopi, poiché è più leggero. Presumibilmente vuoi che i tuoi server web facciano il servizio web, non il lavoro ssh.