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.