Soluzione 1:
Io voto per NFS.
NFSv4.1 ha aggiunto la funzionalità Parallel NFS pNFS, che rende possibile l'accesso parallelo ai dati. Mi chiedo che tipo di client stiano utilizzando lo storage, se solo simile a Unix, allora sceglierei NFS in base ai dati sulle prestazioni.
Soluzione 2:
La risposta breve è usare 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 possono accedere più computer contemporaneamente. Fondamentalmente, condividi un dispositivo a blocchi tramite iSCSI che è un filesystem GFS. Tutti i client (iniziatori nel gergo iSCSI) possono leggere e scrivere su di esso. Redhat ha un whitepaper. Puoi anche utilizzare il cluster FS OCFS di 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 vuoi molto spazio per ridimensionare, GFS probabilmente vale lo sforzo. 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, utilizza il checksum CRC32 se utilizzi iSCSI con i frame jumbo.
Soluzione 3:
Disponiamo di un cluster Web con bilanciamento del carico di 2 server. Abbiamo provato i seguenti metodi per sincronizzare i contenuti tra i server:
- Unità locali su ogni server sincronizzate con RSYNC ogni 10 minuti
- Un CIFS (SAMBA) centrale condividi su entrambi i server
- Un NFS centrale condividi su entrambi i server
- Un'unità SAN condivisa che esegue OCFS2 montato entrambi i server
RSYNC la soluzione era la più semplice, ma ci sono voluti 10 minuti prima che le modifiche venissero visualizzate e RSYNC ha caricato così tanto sui server che abbiamo dovuto limitarlo con uno script personalizzato per metterlo in pausa ogni secondo. Inoltre, eravamo limitati a scrivere solo sull'unità di origine.
Il Drive condiviso più veloce è stato OCFS2 unità in cluster fino a quando non è impazzita e ha bloccato il cluster. Non siamo stati in grado di mantenere la stabilità con OCFS2. Non appena più di un server accede agli stessi file, il carico sale alle stelle e i server iniziano a riavviarsi. Questo potrebbe essere un errore di allenamento da parte nostra.
Il secondo migliore è stato NFS . È stato estremamente stabile e tollerante ai guasti. Questa è la nostra configurazione attuale.
PMI (CIFS) ha avuto qualche problema di chiusura. In particolare, le modifiche ai file sul server SMB non venivano visualizzate dai server web. SMB tendeva anche a bloccarsi durante il failover del server SMB
La nostra conclusione era che OCFS2 ha il maggior potenziale ma richiede MOLTE analisi prima di utilizzarlo in produzione. Se desideri qualcosa di semplice e affidabile, consiglierei un cluster di server NFS con Heartbeat per il failover.
Soluzione 4:
Ti suggerisco POHMELFS:è stato creato dal programmatore russo Evgeniy Polyakov ed è molto, molto veloce.
Soluzione 5:
In termini di affidabilità e sicurezza, probabilmente CIFS (ovvero Samba) ma NFS "sembra" molto più leggero e, con un'attenta configurazione, è possibile non esporre completamente i propri preziosi dati a tutte le altre macchine della rete;-)
Nessun insulto alla roba FUSE, ma sembra ancora... fresca, se capisci cosa intendo. Non so se mi fido ancora, ma potrei essere solo io che sono un vecchio nebbioso, ma il vecchio nebbioso a volte è giustificato quando si tratta di preziosi dati aziendali.
Se vuoi montare in modo permanente una condivisione su più macchine e puoi giocare con alcune delle stranezze (principalmente problemi di UID/GID), usa NFS. Lo uso e lo uso da molti anni.