Google Apps: disaster recovery e replica dei dati su più data centers

Siete pronti quando accade qualcosa ai server della vostra compagnia o del vostro sito web? Sapete subito come intervenire? Sono le giuste domande che si pone il post di Google di ieri dedicato all'annuncio dell'introduzione di una completa strategia di Disaster Recovery per i servizi di Google Apps: la schiera di servizi online che oggi vengono utilizzati da oltre 20 milioni di persone e 2 milioni di aziende.

Siete pronti quando accade qualcosa ai server della vostra compagnia o del vostro sito web? Sapete subito come intervenire? Sono le giuste domande che si pone il post di Google di ieri dedicato all’annuncio dell’introduzione di una completa strategia di Disaster Recovery per i servizi di Google Apps: la schiera di servizi online che oggi vengono utilizzati da oltre 20 milioni di persone e 2 milioni di aziende.

data-center-t01.jpg

Gli ultimi downtime, in particolare quelli relativi a Gmail, hanno costretto la compagnia a rivedere le proprie strategie nella gestione dei dati. L’articolo di Google spiega quali sono le tecniche utilizzate solitamente dalle compagnie che si occupano di hosting o di gestione di grandi quantità dati: bocciato l’uso di SAN, che reputa troppo costose, la soluzione rimane quella di avere più data centers a disposizione, sui quali replicare dati e servizi, in modo tale che questi possano continuare a funzionare con un leggero downtime.

Google parla della propria strategia di recovery utilizzando due termini RTO e RPO, rispettivamente Recovery Time Object e Recovery Point Object, due variabili che possono incidere fortemente sul ritorno online di una determinata applicazione o servizio dopo un disastro. Google afferma che nel caso della sua piattaforma questi due termini hanno valore 0, dato che tutti i dati vengono replicati, in maniera sincrona e real time, su più data centers, consentendo quindi un recupero istantaneo degli stessi nel caso di problemi.

Google non fa altro che utilizzare i propri data centers, collegati tra loro, per replicare i dati e il workload, in modo tale che nel caso un data centers dovesse “fallire”, il carico e i dati vengano spostati su un’altra struttura della compagnia, in real time, o al più con un downtime di pochi minuti.

Banda e data centers, il vantaggio di Google

Il post di Google è sicuramente un esempio chiaro della tecnologia attualmente nelle mani di Google: la replica dei dati è solo il punto di partenza dato che la compagnia si può permettere un’affidabilità basata su decine di strutture nel mondo, un numero che nessuno conosce con precisione. Questo significa però un ulteriore passo: questi data centers, per comunicare, necessitano di collegamenti ad altissima velocità.

Non si pone alcun problema, Google ha da sempre investito anche in questo aspetto, favorendo addirittura la posa di cavi sottomarini intercontinentali e facendo peering con le più grandi reti del mondo, in modo tale da avere sempre a propria disposizione canali a larga banda da utilizzare per trasferire i propri dati tra i data centers. Ma quel che rivela il post di Google è ancora più interessante: la compagnia, dice il post, non mantiene data centers di “backup” inattivi, in attesa che accada un problema per farli entrare in funzione. La struttura sembra sia perfettamente in grado di distribuire il workload globale dell’applicazione su più data center, un gigantesco cluster geografico che Google gestirebbe senza problemi.

Non vi sono informazioni su come Google abbia implementato questa tecnologia, e su come vengano trasferiti i workload da un data center all’altro, senza alcun downtime per l’applicazione.

Il concetto di Disaster Recovery

Capire cosa si intenda per Disaster Recovery è fondamentale per capire come funzioni il sistema di Google o qualsiasi altra tecnologia che consenta di implementare una simile soluzione.

La strategia di Disaster Recovery non mira a salvaguardare il dato in modo granulare, ovvero non ha, come obiettivo primario, la necessità di lavorare a livello di singolo file o directory. Come dice il nome stesso, questa strategia mira a salvaguardare l’intero sistema in blocco nel qual caso avvenga un grave failure hardware che comprometta in modo irreparabile il funzionamento del sistema stesso.

Questa la definizione data da Valeriano Manassero nell’articolo dedicato proprio alla spiegazione della differenza tra Disaster Recovery e Backup di HostingTalk.it. L’allestimento di un piano di disaster recovery è quindi molto più complesso rispetto a quello previsto per il backup dei dati e del sistema.

Vi è un lato hardware per l’implementazione di una perfetta tecnica di disaster recovery, da considerare nel caso non vi sia a disposizione un data center esteso, o più di uno, come nel caso di Google. Su HostingTalk.it è disponibile anche un articolo che introduce in maniera pratica al Disaster Recovery attraverso l’utilizzo di Bacula.