Opzioni per sincronizzare in modo efficiente 1 milione di file con server remoti?

In un'azienda per cui lavoro abbiamo una cosa chiamata "playlist" che sono piccoli file ~ 100-300 byte ciascuno. Ce ne sono circa un milione. Circa 100.000 di loro vengono cambiati ogni ora. Queste playlist devono essere caricate su altri 10 server remoti in diversi continenti ogni ora e deve avvenire rapidamente in meno di 2 minuti idealmente. È molto importante che anche i file eliminati sul master vengano eliminati su tutte le repliche. Attualmente utilizziamo Linux per la nostra infrastruttura.

Stavo pensando di provare rsync con l'opzione -W per copiare interi file senza confrontare i contenuti. Non l'ho ancora provato, ma forse le persone che hanno più esperienza con rsync potrebbero dirmi se è un'opzione praticabile?

Quali altre opzioni vale la pena considerare?

Aggiornamento: ho scelto l'opzione lsyncd come risposta, ma solo perché era la più popolare. Altre alternative suggerite sono valide anche a modo loro.

Poiché anche gli aggiornamenti istantanei sono accettabili, è possibile utilizzare lsyncd .
Guarda le directory (inotify) e si rsynctrasforma in slave.
All'avvio farà un pieno rsync, quindi ci vorrà del tempo, ma dopo che verranno trasmessi solo i cambiamenti.
La visione ricorsiva delle directory è possibile, se un server slave non è attivo, la sincronizzazione verrà ritentata fino al suo ritorno.

Se questo è tutto in una singola directory (o in un elenco statico di directory) puoi anche usare incron .
Lo svantaggio è che non consente la visualizzazione ricorsiva delle cartelle ed è necessario implementare la funzionalità di sincronizzazione da soli.

Prendi in considerazione l'utilizzo di un filesystem distribuito, come GlusterFS . Progettato pensando alla replica e al parallelismo, GlusterFS può scalare fino a 10 server molto più agevolmente rispetto alle soluzioni ad hoc che coinvolgono inotify e rsync.

Per questo particolare caso d'uso, è possibile creare un volume GlusterFS a 10 server di 10 repliche (ovvero 1 replica / mattone per server), in modo che ogni replica sia un mirror esatto di ogni altra replica nel volume. GlusterFS propagherà automaticamente gli aggiornamenti del filesystem a tutte le repliche.

I client in ogni posizione contatteranno il loro server locale, quindi l'accesso in lettura ai file sarebbe veloce. La domanda chiave è se la latenza di scrittura può essere mantenuta accettabilmente bassa. L'unico modo per rispondere è provarlo.

Dubito rsyncche funzionerebbe normalmente, perché scansionare un milione di file e confrontarlo con il sistema remoto 10 volte richiederebbe troppo tempo. Vorrei provare a implementare un sistema con qualcosa del genere inotifyche mantiene un elenco di file modificati e li invia ai server remoti (se comunque queste modifiche non vengono registrate in altro modo). È quindi possibile utilizzare questo elenco per identificare rapidamente i file necessari per il trasferimento, magari anche con rsync (o meglio 10 istanze parallele di esso).

Modifica: con un po 'di lavoro, potresti persino usare questo approccio inotify / log watch per copiare i file non appena si verifica la modifica.

Alcune altre alternative:

• Inserisci un lavoro in RabbitMQ o Gearman per spegnerlo in modo asincrono ed eliminare (o aggiungere) lo stesso file su tutti i server remoti ogni volta che elimini o aggiungi un file sul server primario.
• Archivia i file in un database e utilizza la replica per mantenere sincronizzati i server remoti.
• Se si dispone di ZFS è possibile utilizzare la replica ZFS .
• Alcune SAN hanno la replica dei file. Non ho idea se questo può essere utilizzato su Internet.

Questo sembra essere un caso d'uso ideale per il libro di fiabe per MongoDB e forse GridFS . Poiché i file sono relativamente piccoli, MongoDB da solo dovrebbe essere sufficiente, sebbene possa essere conveniente usare l'API GridFS.

MongoDB è un database nosql e GridFS è un archivio di file costruito su di esso. MongoDB ha molte opzioni integrate per la replica e lo sharding , quindi dovrebbe adattarsi molto bene nel tuo caso d'uso.

Nel tuo caso probabilmente inizierai con un set di repliche che consiste nel master situato nel tuo datacenter primario (forse un secondo, nel caso in cui desideri eseguire il failover nella stessa posizione) e i tuoi dieci "slave" distribuiti in tutto il mondo. Quindi eseguire i test di carico per verificare se le prestazioni di scrittura sono sufficienti e controllare i tempi di replica sui nodi. Se hai bisogno di più prestazioni, puoi trasformare l'installazione in una più frammentata (principalmente per distribuire il carico di scrittura su più server). MongoDB è stato progettato con il ridimensionamento di enormi configurazioni con hardware "economico", in modo da poter inserire un gruppo di server economici per migliorare le prestazioni.

Vorrei usare un backend S3 e poi montarlo su tutti i server di cui ho bisogno - In questo modo, tutti sono sincronizzati all'istante comunque

Un'opzione che non sembra essere stata ancora menzionata è l'archiviazione di tutti i file in un file compresso. Ciò dovrebbe ridurre in modo significativo le dimensioni totali e rimuovere tutte le spese generali derivanti dalla gestione di milioni di singoli file. Sostituendo l'intero set di file in un unico grande aggiornamento, puoi anche essere certo che i file rimossi vengono rimossi dalle repliche.

Il rovescio della medaglia è ovviamente che stai trasferendo molti file inutilmente. Ciò può essere compensato o meno dalle dimensioni ridotte grazie alla compressione. Inoltre non ho idea di quanto tempo ci vorrebbe per comprimere quel numero di file.