Sincronizzazione bidirezionale in tempo reale di un grande albero di file tra due server Linux distanti


21

Per albero di file di grandi dimensioni intendo circa 200k file e in costante crescita. Un numero relativamente piccolo di file viene modificato in ogni ora.

Per bidirezionale intendo che possono verificarsi cambiamenti su entrambi i server e devono essere inviati all'altro, quindi rsync non sembra appropriato.

Per distante intendo che i server si trovano entrambi nei data center, ma geograficamente distanti tra loro. Attualmente ci sono solo 2 server, ma possono espandersi nel tempo.

In tempo reale, va bene che ci sia un po 'di latenza tra la sincronizzazione, ma eseguire un cron ogni 1-2 minuti non sembra giusto, dal momento che una piccolissima frazione di file può cambiare in una determinata ora, figuriamoci in un minuto.

EDIT : Questo è in esecuzione su VPS, quindi potrei essere limitato sui tipi di cose a livello di kernel che posso fare. Inoltre, i VPS non sono ricchi di risorse, quindi eviterei soluzioni che richiedono un sacco di RAM (come Gluster?).

Qual è l'approccio migliore / più "accettato" per farlo? Sembra che questo sarebbe un bisogno comune, ma non sono stato ancora in grado di trovare un approccio generalmente accettato, il che è stato sorprendente. (Sto cercando la sicurezza delle masse. :)

Mi sono imbattuto in lsyncd per attivare una sincronizzazione a livello di modifica del filesystem. Sembra intelligente ma non molto comune, e sono un po 'confuso dai vari approcci di lsyncd. Si sta usando solo lsyncd con rsync, ma sembra che questo potrebbe essere fragile per bidirezionalità poiché rsync non ha una nozione di memoria (ad es. Per sapere se un file eliminato su A deve essere eliminato su B o se si tratta di un nuovo file su B che dovrebbe essere copiato in A). lipsync sembra essere solo un'implementazione lsyncd + rsync, giusto?

Quindi sta usando lsyncd con csync2 , in questo modo: https://icicimov.github.io/blog/devops/File-system-sync-with-Csync2-and-Lsyncd/ ... Mi sto inclinando verso questo approccio, ma csync2 è un po 'strano, anche se ho fatto un test di successo. Sono principalmente preoccupato di non essere stato in grado di trovare molte conferme da parte della community di questo metodo.

Le persone qui sembrano apprezzare molto Unison, ma sembra che non sia più in fase di sviluppo attivo e non è chiaro che abbia un trigger automatico come lsyncd.

Ho visto Gluster menzionato, ma forse è eccessivo per quello che mi serve?

AGGIORNAMENTO: finalmente ho scelto la soluzione originale che ho citato: lsyncd + csync2. Sembra funzionare abbastanza bene, e mi piace l'approccio architettonico di avere i server uniti in modo molto libero, in modo che ogni server possa funzionare indefinitamente da solo, indipendentemente dalla qualità del collegamento tra di loro.


Che tipo di modifiche devi gestire? EG creazione, cancellazione, modifica.
sciurus,

Inoltre, ti aspetti conflitti? Lo stesso file potrebbe essere modificato su entrambi i server?
sciurus,

Tutte le modifiche: creazione, cancellazione, modifica. Esistono potenziali conflitti, ma dovrebbero essere rari. Non mi dispiacerebbe se ricevessi semplicemente un avviso su un conflitto che avrei dovuto risolvere manualmente.
dlo

Risposte:


5

DRBD in modalità Dual-primary con un proxy è un'opzione.


Il proxy sembra non essere né open source né gratuito, giusto? Non sono sicuro di comprendere la conseguenza di non avere un proxy in modalità asincrona: durante un lungo periodo di inattività, se non è presente un proxy, il buffer di output [piccolo?] Potrebbe riempirsi e perderemmo la sincronizzazione? È difficile riprendersi da quello?
dlo,

Vedi la mia risposta sopra. Non credo che il proxy sia la cosa di cui hai bisogno. Anche durante un breve periodo di inattività, il drbd-meta-device segnerà i blocchi "sporchi" e li trasferirà dopo che la connessione sarà di nuovo attiva. Penso che la differenza principale tra proxy e modalità asincrona sia che la modalità asincrona utilizza un buffer massimo di alcuni MB. Successivamente si sincronizza prima di riempire nuovamente il buffer. Il proxy consente un buffer più grande (necessario se si ha una latenza elevata o si può scrivere molto più velocemente a livello locale che remoto).
Nils,

2

Invece di sincronizzare, perché non condividere lo stesso filesystem su NFS?


2
NFS è orribile, semplicemente orribile. Qualsiasi cosa sarebbe meglio di NFS
AliGibbs

2
Uno dei punti principali dell'installazione multi-server è il failover / ridondanza. Quindi un server deve essere in grado di continuare senza l'altro.
DO

Avresti dovuto menzionarlo nella tua domanda allora - non c'è bisogno di votare una risposta perfettamente ragionevole!
Bart B,

a proposito, non l'ho votato a fondo, lo ha fatto qualcun altro. Ma sì, avrei dovuto dirlo per cominciare.
DO

@Bart: Beh - ha detto che esiste un accesso simultaneo su due siti distanti. Quindi, anche se imposti HA-NFS sarebbe una cattiva soluzione, dal momento che una parte soffrirebbe di latenza durante l'accesso a NFS. E non ho neppure votato a fondo. Ma sono stato amministratore NFS abbastanza a lungo da supportare AliGibbs. : - /
Nils,

2

L'implementazione di un filesystem distribuito è probabilmente meglio che hackerarlo insieme a strumenti e script, specialmente se il cluster di server crescerà. Sarai anche in grado di gestire meglio un nodo abbattuto.

Non credo che Gluster (o AFS) sia eccessivo.


Gluster richiede 1 GB di RAM? gluster.com/community/documentation/index.php/… ... Sono anche su un VPS, quindi non sono sicuro di apportare modifiche a livello di kernel che AFS potrebbe richiedere. Ma sto iniziando a vedere che un corretto fs distribuito è il percorso migliore.
dlo,

Sì, mi dispiace non aver capito prima che stavi usando host VPS. Le impronte di memoria del gluster, sia server che client, non sono piccole e possono crescere in modo sostanziale. DRBD sembra più appropriato.

AFS è la strada da percorrere.
Anthony Giorgio,

2

Nel tuo caso, consiglierei una combinazione di DRBD in modalità dual-primary e gfs o ocfs.

Lo svantaggio di DRBD in dual-primario è che funzionerà in modalità sincrona. Ma la velocità di scrittura non sembra essere importante qui, giusto?

Un'alternativa a DRBD potrebbe essere un Soft-Raid1 che utilizza molti (2+) target iSCSI - ma preferirei DRBD con due nodi.


1
La modalità sincrona sarebbe negativa: non ne ho bisogno e non vorrei compromettere le prestazioni poiché i server sono connessi su una WAN attraverso i continenti. Ma non puoi avere il dual-primario in modalità asincrona?
dlo

Attualmente sto usando DRBD 8.3.5 - lì devi essere in modalità sync ("C") per entrare in doppia modalità primaria. Non ho esperienza personale con il proxy DRBD ma sembra essere simile a Veritas Volume Replicator - ma ciò non è adatto dal momento che si desidera l'accesso in scrittura su entrambi i lati. La modalità di sincronizzazione a livello di blocco potrebbe non essere così male come pensi - forse gfs e / o ocfs possono bufferizzare le scritture.
Nils,

Ho appena controllato un articolo tedesco confrontando GFS2 e OCFS2. Da questo almeno OCFS2 sembra supportare l'accesso al file system con buffer. GFS2 è raccomandato in quell'articolo poiché è più vecchio. Vedi la documentazione di RedHat su GFS2 per dettagli su GFS2 - usa anche il buffering - ma per ottenere le migliori prestazioni dovresti usare dirs diversi per le scritture simultanee.
Nils,

0

Come dimostrato sopra, sono disponibili molte soluzioni, ognuna con i suoi vantaggi e svantaggi.

Penso che prenderei in considerazione la possibilità di mettere l'intero albero sotto il controllo della versione ( Subversion , per esempio) e di controllare periodicamente / aggiornare da entrambi i server nei lavori cron.


0

Avendo appena terminato un po 'una ricerca per quanto riguarda la stessa cosa, vado con un po' di brio. Tuttavia, non ho eseguito o trovato alcun test delle prestazioni.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.