Sincronizzazione di milioni di file tra due server Linux


10

Ho un server che esporta una directory contenente ~ 7 milioni di file (principalmente immagini) dal suo disco locale ai client di rete tramite NFS .

Ho bisogno di aggiungere un secondo per il bene di HA, e per mantenerlo sincronizzato con il primo con il minor delta possibile tra i due.

La ricerca suggerisce di utilizzare lsyncd o altre soluzioni basate su inotify per questo, ma dato il numero di file che creano gli orologi inotify richiede un'eternità. Stessa cosa per rsync .

Altre soluzioni possibili sembra essere DRDB , o un cluster file system , quali Ceph o glusterfs , ma non ho alcuna esperienza con quelli e non sanno quale sarebbe più appropriato e gestire bene che molti file e continuano ad offrire prestazioni decenti.

Si noti che l'attività viene in gran parte letta con poca scrittura.


2
DRDB funziona bene ed è semplice da configurare e comprendere in una configurazione cluster a 2 macchine; tuttavia non si ridimensionerà in un prossimo futuro. Potrebbero esserci anche altri approcci all'argomento. highscalability.com/blog/2012/6/20/…
Rui F Ribeiro,

Hai provato a correre rsyncin modalità demone? Ciò accelererà la generazione iniziale dell'elenco dei file quando si esegue il rsynccomando, ma richiederà molta RAM a seconda della quantità di file.
Thomas,

quanto ritardo puoi tollerare? se è possibile tollerare alcuni minuti (o più), utilizzando btrfso zfspotrebbe essere un'opzione, combinato con un processo cron per creare snapsnot e / zfs sendo btrfs sendal server di backup. molto più veloce e un carico di lavoro molto più leggero (sia per i mittenti che per i ricevitori) rispetto a rsync perché lo snapshot + send non ha bisogno di confrontare i timestamp dei file o i checksum.
Cas

A proposito, con ceph hai anche la possibilità di usarlo come archivio oggetti (ad es. Come s3 di amazon o swift di openstacks) invece di un filesystem. In effetti, la fs di ceph è effettivamente sovrapposta al suo negozio di oggetti.
Cas

@Thomas: il completamento del rsync -ademone (sulla fonte) richiede 200 minuti, il che è più di quanto sia accettabile. @cas: btrfs sendpotrebbe valere la pena dare un'occhiata. Non riesco a spostarmi in un archivio oggetti poiché non sono lo sviluppatore dell'app che utilizza i file.
user60039

Risposte:


1

Sono propenso a suggerire una replica che è indipendente dai dati, come drbd. Il gran numero di file farà sì che qualsiasi cosa in esecuzione a un livello superiore rispetto a "block storage" trascorra una quantità eccessiva di tempo a camminare sull'albero, come hai scoperto usando rsync o creando inotify watch.

La versione breve della mia storia personale lo conferma: non ho usato Ceph, ma sono abbastanza sicuro che questo non rientri nel loro obiettivo di mercato principale in base alla sua somiglianza con Gluster. Tuttavia, ho cercato di implementare questo tipo di soluzione con Gluster negli ultimi anni. È attivo e funzionante per la maggior parte del tempo, anche se diversi aggiornamenti di versione principali, ma non ho avuto problemi di fine. Se il tuo obiettivo è più ridondanza che prestazioni, Gluster potrebbe non essere una buona soluzione. Soprattutto se il tuo modello di utilizzo ha molte chiamate stat (), Gluster non funziona molto bene con la replica. Questo perché le chiamate stat ai volumi replicati vanno a tutti i nodi replicati (in realtà "mattoni", ma probabilmente avrai solo un mattone per host). Se hai una replica a 2 vie, ad esempio, ogni stat () di un client attende una risposta da entrambi i mattoncini per assicurarsi che stia utilizzando i dati correnti. Quindi hai anche il sovraccarico FUSE e la mancanza di memorizzazione nella cache se stai usando il filesystem gluster nativo per la ridondanza (piuttosto che usare Gluster come backend con NFS come protocollo e automounter per ridondanza, che fa ancora schifo per il motivo stat ()) . Gluster funziona davvero bene con file di grandi dimensioni in cui è possibile diffondere i dati su più server; lo striping e la distribuzione dei dati funzionano bene, poiché è proprio quello che serve. E la più recente replica di tipo RAID10 offre prestazioni migliori rispetto ai vecchi volumi replicati direttamente. Ma, in base a quello che immagino sia il tuo modello di utilizzo, lo sconsiglio. Quindi hai anche il sovraccarico FUSE e la mancanza di memorizzazione nella cache se stai usando il filesystem gluster nativo per la ridondanza (piuttosto che usare Gluster come backend con NFS come protocollo e automounter per ridondanza, che fa ancora schifo per il motivo stat ()) . Gluster funziona davvero bene con file di grandi dimensioni in cui è possibile diffondere i dati su più server; lo striping e la distribuzione dei dati funzionano bene, poiché è proprio quello che serve. E la più recente replica di tipo RAID10 offre prestazioni migliori rispetto ai vecchi volumi replicati direttamente. Ma, in base a quello che immagino sia il tuo modello di utilizzo, lo sconsiglio. Quindi hai anche il sovraccarico FUSE e la mancanza di memorizzazione nella cache se stai usando il filesystem gluster nativo per la ridondanza (piuttosto che usare Gluster come backend con NFS come protocollo e automounter per ridondanza, che fa ancora schifo per il motivo stat ()) . Gluster funziona davvero bene con file di grandi dimensioni in cui è possibile diffondere i dati su più server; lo striping e la distribuzione dei dati funzionano bene, poiché è proprio quello che serve. E la più recente replica di tipo RAID10 offre prestazioni migliori rispetto ai vecchi volumi replicati direttamente. Ma, in base a quello che immagino sia il tuo modello di utilizzo, lo sconsiglio. che fa ancora schifo per la ragione stat ()). Gluster funziona davvero bene con file di grandi dimensioni in cui è possibile diffondere i dati su più server; lo striping e la distribuzione dei dati funzionano bene, poiché è proprio quello che serve. E la più recente replica di tipo RAID10 offre prestazioni migliori rispetto ai vecchi volumi replicati direttamente. Ma, in base a quello che immagino sia il tuo modello di utilizzo, lo sconsiglio. che fa ancora schifo per la ragione stat ()). Gluster funziona davvero bene con file di grandi dimensioni in cui è possibile diffondere i dati su più server; lo striping e la distribuzione dei dati funzionano bene, poiché è proprio quello che serve. E la più recente replica di tipo RAID10 offre prestazioni migliori rispetto ai vecchi volumi replicati direttamente. Ma, in base a quello che immagino sia il tuo modello di utilizzo, lo sconsiglio.

Tieni presente che probabilmente dovrai trovare un modo per avere elezioni principali tra le macchine o implementare il blocco distribuito. Le soluzioni di dispositivi a blocchi condivisi richiedono un filesystem che è a conoscenza di più master (come GFS) o richiede che solo un nodo monti il ​​file system read-write. I filesystem in generale non amano quando i dati vengono modificati a livello di dispositivo a blocchi sotto di essi. Ciò significa che i tuoi clienti dovranno essere in grado di dire qual è il master e indirizzare le richieste di scrittura lì. Ciò potrebbe rivelarsi un grosso fastidio. Se GFS e tutta la sua infrastruttura di supporto è un'opzione, drbd in modalità multi-master (lo chiamano "dual primario") potrebbe funzionare bene. https://www.drbd.org/en/doc/users-guide-83/s-dual-primary-mode per ulteriori informazioni al riguardo.

Indipendentemente dalla direzione che segui, ti accorgerai che questo è ancora un dolore abbastanza grande da fare in tempo reale senza solo dare a una società SAN un carico di denaro.


Sono nelle fasi iniziali della migrazione dai comandi rsync in cron all'utilizzo di un filesystem distribuito. Se Gluster esegue stat () su tutti i mattoni, potrebbe essere necessario riconsiderarlo come soluzione.
Jesusaur,

1
Questo è solo il caso in un filesystem replicato; funziona stat()su tutti i mattoni che hanno repliche del blocco specifico che stai guardando. Ad esempio, se si dispone di una replica a strisce 2x2, statverrebbe eseguito sui due mattoni con il blocco replicato, ma non sugli altri due. Nella mia applicazione con molti file di piccole dimensioni (dell'ordine di un milione di file con 4K di dati ciascuno), né NFS né FUSE hanno fornito buone prestazioni su volumi replicati. E la georeplicazione su ~ 20 macchine era molto inaffidabile in diverse configurazioni.
dannysauer,

1
Il tuo chilometraggio può variare, ma mi sono spostato da Gluster ovunque (che stavo usando esclusivamente per la replica, non per tutte le altre cose davvero interessanti che Gluster effettivamente fa bene) per sincronizzare su filesystem nativi. :) Sto cercando di passare a lsyncd ( github.com/axkibe/lsyncd ) ora invece di cron, quindi posso avvicinarmi in tempo reale senza il sovraccarico di Gluster.
dannysauer,

0

Sono passato da rsync a ceph con l'aiuto della configurazione di Proxmox VE.

Ora gestisco 14 TB in un cluster con replica live. Per quasi 4 anni.

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.