Richiedi Informazioni

Disaster recovery: MongoDB e GridFS per la replicazione dei dati, ma non solo

Tra i diversi task che un sistemista deve saper integrare al meglio, c’è il backup e la replicazione dei dati in caso di fault delle varie macchine, o nella peggiore delle ipotesi, di disaster recovery.

Questo task viene eseguito facilmente grazie a dei tool estremamente collaudati e automatizzati, configurati per ogni singolo caso.

Ma c’è chi ha migliorato di gran lunga queste operazioni, integrando a sua volta nuove funzionalità, grazie ad un database engine e un filesystem layer. Siete curiosi di saperne di più?

Da Rsync a MongoDB e GridFS.
Se Rsync è da sempre la soluzione più utilizzata per la creazione di backup giornalieri o settimanali, di contro soffre di alcuni problemi di “vecchiaia”. La possibilità di generare statistiche, notificare eventuali errori nell’operazione di backup, eseguire dei task successivi alla corretta copia dei file – monitoraggio completo, se preferite – lo rendono piuttosto limitato.

LogicMonitor ha tirato fuori dal cilindro una soluzione davvero interessante: utilizzare un database engine noSQL come MongoDB per l’archiviazione di metadata relativi alle operazioni di backup, il tutto integrato con GridFS.

Come funziona?
GridFS è un filesystem realizzato come layer sulla base di MongoDB: permette di archiviare i file destinati al backup (suddivisi in frammenti da 256kb) come fossero semplicemente dei dati inseriti a DB e legati ai rispettivi metadata.

I vantaggi sono molti: replicazione immediata – utile se i dati devono essere distribuiti in sedi diverse – possibilità di recuperare ed eliminare file con una semplice query, nessuna frammentazione, monitoraggio automatico.

Ma c’è di più. Grazie ad una recente estensione scritta ad-hoc, c’è la possibilità di servire i file direttamente da DB a webserver tralasciando il filesystem. Da un benchmark trovato in Rete, con questo sistema Nginx si aggirerebbe sulle 6.500 richieste al secondo.

Ma funziona davvero?
Per il momento ho solo effettuato dei test, è nei miei piani di fare un deploy in produzione alla prima occasione utile. Certo, prima di lanciarmi in produzione vorrò effettuare, di concerto con i clienti che me lo consentiranno, dei test in produzione.

Innanzitutto perché i database noSQL – e a maggior ragione GridFS – non hanno una grande casistica di utilizzo e sufficiente documentazione da potermi far sentire sicuro al cento per cento. In secondo luogo perché il mio modus operandi è di ingegnerizzare delle soluzioni ad-hoc in funzione delle specifiche del cliente, per cui grid+mongo potrebbero non essere l’unica (o la migliore soluzione).

Come sempre, non sbatto la porta in faccia alle novità, ma preferisco andare cauto. Se desideri lavorare con un’azienda che ha un approccio one-to-one ai propri clienti ed alle loro necessità tecniche, non esitare a contattarci.