Un esempio potremmo essere noi stessi che spesso siamo in giro per l’Europa o per il mondo e vogliamo accedere a dati da un dispositivo mobile in ogni momento. Un cloud storage nasce proprio per ospitare dati che debbano soddisfare tale esigenza (oltre che molte altre)..
Atmos può essere una buona risposta dal momento che consente di avere una soluzione scale-out disegnata per essere in configurazione “attivo-attivo”. Questo vuol dire che le operazioni di lettura e\o scrittura possono avvenire su qualunque nodo, in qualunque sito esso sia, locale o “public”.
Con un approccio di questo tipo è possibile limitare al massimo (o addirittura eliminare in toto) le operazioni di configurazione per accedere al dato in modo ubiquo o per rispondere a disastri dei siti produttivi. Questo risultato è possibile grazie ai meccanismi di Replication e GeoParity.
Atmos replica sincrona e asincrona
Atmos supporta due tipi di replica: sincrona e asincrona. Tali meccanismi di replica possono essere applicati in modo disgiunto o anche in concomitanza a seconda del livello di protezione che si vuole rispettare.
Queste repliche, o copie, possono essere usate per rispondere alle esigenze di disponibilità, disaster recovery, distribuzione di contenuti e prestazioni di lettura. Le repliche garantiscono che i dati siano disponibili, nonostante eventuali guasti hardware; che gli utenti, indipendentemente dalla loro ubicazione, possano avere una copia dei dati accedibile nel sito più vicino rispetto alla loro posizione geografica.
È importante determinare quante e quali tipi di repliche devono essere definiti per ciascuna classe di oggetto. Il concetto di policy associate al singolo oggetto non è banale.. è possibile definire con semplici tag differenti politiche di protezione, replica, accesso..
Atmos permette di ottenere il meglio dalla propria architettura se l’applicazione (o le applicazioni) che devono sfruttare le sue risorse sono in grado di farlo al meglio e nella maniera più smart possibile (integrazione delle API CAS od utilizzo dei protocolli “web based” REST ed S3).
In una replica sincrona Atmos scrive il dato per il numero di volte imposto dalla policy di protezione prima che l’applicazione venga aggiornata con la conferma di scrittura, questo ovviamente diventa un problema se la scrittura deve avvenire attraverso una rete WAN.
Spesso le repliche asincrone vengono utilizzate proprio per avere una ulteriore copia in un sito (RMG) remoto per fini di sicurezza, DR o per migliorare le prestazioni di lettura richieste da utenti geograficamente vicini alla replica.
Il numero, la posizione e il tipo di replica per ogni singolo oggetto possono essere controllati utilizzando tag di metadati associati all'oggetto stesso. Attraverso tale politica, ad ogni replica può essere assegnato un posto specifico (es. - "sameAs" o "diverse da "Milan"), oppure si può utilizzare il "tag $ client", ovvero il dato viene scritto sul nodo Atmos che ha risposto al client applicativo. In questo modo i dati possono essere classificati così da avere la protezione adeguata per singola applicazione, invece di operare con una politica di protezione generic anche per dati critici.
Atmos GeoParity
GeoParity è un’opzione di replica basata su policy, che offre eccellenti caratteristiche di affidabilità dei dati. Concettualmente GeoParity è simile ad un RAID, il dato viene scisso in contenuto informative vero e proprio ed una serie di metadati che contribuiscono alla sua ricostruzione in caso di perdita di una o più parti. La differenza è che GeoParity utilizza uno schema di codifica più complesso per i frammenti di ridondanza in modo tale che il dato possa essere ricostruito anche a fronte della perdita di un numero elevato (fino a 6) di frammenti originali. Atmos è in grado di posizionare i frammenti di dato e metadato in dischi, nodi, e potenzialmente anche RMG, diversi in modo da garantirsi una protezione molo elevata.
GeoParity: come funziona
Atmos implementa GeoParity con l'algoritmo Cauchy Reed-Solomon, e utilizza due diverse implementazioni. Il primo è una configurazione 9/12, in cui un oggetto è diviso in 9 frammenti di dati e 3 frammenti di metadato. Questo permette di supportare fino a 3 errori dovuti, ad esempio, alla perdita di dischi contemporanea. L’overhead è del 33%, rispetto al 100% per una configurazione RAID-1, o 25% per una configurazione RAID-5.
La seconda configurazione è un'opzione di 10/16, in cui ci sono 10 frammenti di dati e 6 frammenti di metadato. Questa configurazione tollera fino a 6 errori contemporanei, ha un sovraccarico di archiviazione del 60%, ma con un maggiore costo in termini di prestazioni rispetto alla configurazione 9/12.
Esiste un MD5 checksum intrinseco che viene calcolato ad ogni operazione di scrittura. Una volta che un client richiede l'oggetto, il checksum viene calcolato nuovamente e controllato con quello memorizzato per verificare la bontà del dato.
Configurazioni consigliate per un / Architettura Attivo Attivo
Per esempio, si consideri il sistema di seguito. i dati sono memorizzati utilizzando uno schema di 9/12 GeoParity e costituiscono il contenuto informative di un sito web di e-commerce. In base alla mia ricerca , quando navigo per cercare un oggetto da acquistare, sono diretto alla copia più vicina in modo da avere una risposta ottimale.
Tuttavia, cosa succede se il sito locale è indisponibile? Ad esempio, per un intervento di manutenzione.
Con un'architettura attivo / attivo e GeoParity invece di vedere il classico messaggio "Sito temporaneamente non disponibile", il sistema Atmos avrebbe riconosciuto che il sito era giù ed in modo trasparente mi avrebbe reindirizzato ad un sito remoto dove avrei potuto continuare a navigare. Tutto questo viene fatto automaticamente senza modificare l'applicazione, senza alcuna azione da parte dell'amministratore e nessun impatto sulla navigazione (al massimo una latenza superiore e quindi un tempo di risposta non ottimizzato).
Abbiamo visto a grandi linee perché Atmos può essere una soluzione ottimale per rispondere alle esigenze di cui abbiamo parlato all'inizio dell’articolo; nel prossimo post vedremo quali sono i passi per installare e cominciare ad utilizzare una versione virtuale di una appliance Atmos.
Per maggior informazioni su Atmos:
- un white paper sull'architettura di Atmos.
- la pagina dedicata ad Atmos sul sito EMC.
Marco Del Plato
