GlusterFS è una buona scelta per mantenere sincronizzati i server web?

9

Ho 2 server web, con la possibilità di dover aggiungere più server lungo la strada. In questo momento mantengo sincronizzati questi server usando lsyncd + csync2. Funziona bene dal punto di vista delle prestazioni perché tutti i file si trovano su entrambi i server (non è necessario l'accesso alla rete per aprire i file localmente), ma non così bene in altri casi.

Un esempio di ciò è se elimino un file sul server 1 e carica immediatamente un nuovo file sul server 1 con lo stesso nome. Il file verrebbe quindi eliminato dal server 2 nel frattempo, causando l'eliminazione del file appena caricato sul server 1 mentre il server 2 invia l'evento di eliminazione al server 1 per completare il "cerchio di aggiornamento".

Non posso fare a meno di pensare che ci debba essere un modo migliore per mantenere sincronizzati i server. Ho esaminato GlusterFS e vedo che un'installazione in cui tutti i file vengono replicati su tutti i server è scoraggiata. Tuttavia, sto eseguendo sistemi CMS come Drupal su questi server. Tali sistemi CMS spesso aprono molti file e sono preoccupato che troppo traffico di rete per ottenere questi file rallenti le richieste.

Sarebbe un'idea cercare di sostituire lsyncd + csync2 con GlusterFS impostato per replicare tutti i file su tutti i nodi, o è una cattiva idea?

— sbrattla
fonte

2

Potrei fraintendere il tuo problema qui, ma perché non utilizzare l'archiviazione di rete condivisa tra server?

— mveroone,

1

@Kwaio: vorrei "rispecchiare" tutti i server web (sia gli script che i contenuti caricati dall'utente) in quanto ciò eviterà i tempi di inattività se qualcosa va storto con il server che ospita l'archivio condiviso. In altre parole, non voglio fare affidamento su un'impostazione in cui tutti i server web si affidano nuovamente a un singolo archivio di file.

— sbrattla,

Quindi perché non un cluster di archiviazione di rete ad alta disponibilità?

— mveroone,

Certo, ma cosa implica? Hardware?

— sbrattla,

Non sono uno specialista, ma ciò significa avere l'archiviazione di rete speculare in un'architettura master-slave su 2 cluster e un sistema che cambia in caso di guasto del master. La maggior parte dei produttori di dispositivi di archiviazione di rete ha soluzioni per questo, anche se si potesse costruirlo da soli con dispositivi Linux, il che richiederebbe un sacco di sviluppo.

— mveroone,

2

BitTorrent Sync può fare l'atto per te. Lo sto usando per mantenere i file sincronizzati tra alcuni server interni a casa mia e sta facendo il lavoro meravigliosamente. L'altra cosa a cui devi pensare è il database back-end quando la tua app utilizza un CMS. Assicurati che sia in corso la replica di MySQL o qualcosa del genere.

— whiskykilo
fonte

Interessante. In che modo BitTorrent Sync gestisce i conflitti? Supponiamo di avere 5 server Web e che un file venga aggiornato sul server A. Quindi, 2 secondi dopo, lo stesso file viene aggiornato sul server C prima che la modifica su A abbia raggiunto C. Il software dispone di algoritmi per impostare quale server vince in questi casi?

— sbrattla,

La mia comprensione è che BitTorrent Sync confronterà la data / ora di modifica su entrambe le copie e manterrà solo le ultime, che potrebbero essere ideali o potrebbero essere dannose per il caso d'uso.

— whiskykilo,

1

Gluster risolverebbe il problema che hai perché può contenere i blocchi, propagare le modifiche - eliminare il file su tutti gli altri nodi, ma può aggiungere ulteriore latenza che può essere un problema per un server web. La prossima alternativa è DRBD + OCFS2 o GFS, ma è probabilmente più complesso come con il gluster che stai usando il filesystem sottostante - non funziona a livello di blocco quindi se i server non sono sincronizzati non è troppo difficile da riparare, i file possono si corrompono così facilmente a causa di cervelli divisi, ecc ...

Lo stiamo usando per un mailserver ed è piuttosto lento per le directory con molti file. Dovresti assolutamente testare tutto prima di distribuire. Attualmente sto testando il mount NFS perché funziona meglio per file di piccole dimensioni.

— Jure1873
fonte

1

GlusterFS è difficile da implementare. Per i dati Web, il livello di sincronizzazione dei file come Unison è molto più semplice da distribuire e gestire.

DRBD è una soluzione perfetta per mantenere la sincronizzazione dei dati a livello di blocco. Ma devi formattarli in un formato speciale come OCFS2 o qualcosa di simile.

— truongtx
fonte

GlusterFS non è come DRBD - non funziona a livello di blocco, ma a livello di file. Ma credo che l'unisono sia più facile da distribuire.

— Jure1873,

-3

Perché non usi uno strumento come un burattino ? Scrivi una volta in una fonte e una volta pronto distribuiscilo sui bersagli usando "burattino" o mcolletive. È ben documentato. E puoi facilmente aggiungere server in seguito, se necessario.

Puoi anche fare affidamento su strumenti che utilizzano inotify, come lsyncd, funzionando a livello di kernel. Controlla le modifiche in una cartella e attiva una sincronizzazione. Ma se uno strumento dedicato alla sincronizzazione di file su un cluster come csync2 non è abbastanza, non so quale sarà.

Per essere sicuri, le modifiche avvengono anche sul server 2 o solo sul server 1?

— Rosco
fonte

3

Downvoted: Puppet non è un buon modo per mantenere i file sincronizzati tra i server. Si tratta comunque di uno strumento geniale per la gestione di configurazione del server .

— Craig Watson,

Le modifiche possono verificarsi su qualsiasi server, poiché partecipano a una configurazione con bilanciamento del carico. Gli utenti possono caricare file su qualsiasi server e di conseguenza tale file dovrebbe essere disponibile su tutti i server poiché il traffico viene distribuito tra i server.

— sbrattla,

1

Bene, in questo caso fantoccio non è quello che vuoi (ma comunque, @Craig Watson, un file è un file, configurazione o HTML, è ancora un file). Dubito che GlusterFS sia pronto per la produzione, quindi se vuoi davvero qualcosa di sicuro, è meglio usare un server NFS ad alta disponibilità.

— Rosco,