venerdì 27 settembre 2013

Gestione dinamica dei dati: dall'HSM a FAST VP

La gestione gerarchica del dato.

Quando fu introdotto il concetto di “Hierarchical Storage Management”, il principio alla base di questa tecnica era molto chiaro: ridurre il costo di memorizzazione dati (su disco) e semplificare il recupero di dati da supporti più lenti (tipicamente nastri); un processo schedulabile (batch)  analizzava le informazioni relative all’acceso ai file, decideva quali di questi potevano essere “migrati” su supporti più lenti ed a basso costo ed operava lo spostamento.
Questa tecnica è possibile in quanto la densità di accesso ai dati, identificata come skew, cioè la percentuale di spazio disco che soddisfa la maggioranza delle operazioni di lettura e scrittura, da sempre vede il concentrarsi della maggioranza delle attività su una piccola porzione dello spazio a disposizione delle applicazioni.
Le varie tecniche, ancorché tutte validissime, avevano però un piccolo difetto: il dato “migrato” doveva essere riportato sui supporti “primari” per poter essere fruibile e le attività di “migrazione” erano a carico del server.
Gli anni a venire ci hanno consegnato nuovi acronimi: da ILM o “Information Lifecycle Management” arrivando ai più recenti quali: Automated Tiered Storage o, ancora, Auto Tiering.
Se è vero che il principio alla base non è cambiato è altrettanto vero che le tecniche di movimentazione del dato si sono evolute negli anni, spostando i processi di gestione direttamente all’interno dei sistemi Storage, divenuti via via più intelligenti, invece che essere governati dai server come in passato.
Questo, per altro, garantisce una granularità di movimentazione decisamente più efficente (ad esclusione di alcune implementazioni) nel momento in cui l’elemento interessato alla “migrazione” non è più un intero file ma una “porzione” del “volume logico” (Chunk).

Questa ottimizzazione si deve grazie all’introduzione di tecnologie quali il “Virtual Provisioning”, anche conosciuto come “Thin Provisioning”, una tecnica che consente di presentare ai server un volume “Logico” o “Virtuale” che ha una corrispondenza “Fisica” equamente distribuita all’interno del sistema Storage.

Anche se il principio è concettualmente lo stesso, ogni produttore di sistemi Storage ha implementato questa funzionalità in modo differente.

Tornando ai concetti di “Gestione Gerarchica del Dato”, o se preferite “Gestione del Ciclo di Vita del Dato”, in casa EMC la soluzione, disponibile su tutte le piattaforme storage, è conosciuta come FAST o, nella sua accezione più diffusa, come FAST VP (Fully Automated Storage Tiering for Virtual Pool).
Il principio è abbastanza semplice: monitorando continuamente le attività di accesso ai dati è possibile identificare quali, tra questi, risultano essere più o meno “attivi” ed assegnare, in base a politiche definite dinamicamente dall’utente, il livello di Storage (Tier) più appropriato. In questo modo i dati più “attivi” verranno posizionati sul livello in grado di offrire le migliori prestazioni, mentre quelli “inattivi” saranno spostati sul livello meno prestazionale ed a più basso costo.

A questo punto è importante considerare alcuni aspetti che determinano l’efficacia di questa tecnologia ed in particolare:
  • La frequenza di movimentazione dei dati.
  • La dimensione dell’elemento che viene movimentato.
Nella maggior parte dei casi, un singolo dato assumerà nel tempo attributi differenti: in alcune fasi risulterà utilizzato con alta frequenza, mentre in altre risulterà “inattivo”: è molto importante che la reazione del sistema storage al cambio di “accesso” avvenga in modo tempestivo, in modo da allineare il posizionamento del dato in funzione del livello di servizio più appropriato; un sistema storage che ad esempio “risponda” a questo cambiamento nell’arco di  pochi minuti risulterà molto più efficace di un sistema apparente simile ma che abbia bisogno di qualche ora prima di riuscire ad individuare quali dati devono essere spostati e dove.

La dimensione dell’elemento che viene movimentato ha invece una ripercussione diretta sulla efficienza di utilizzo dei livelli di Storage (tier); a parità di numero di blocchi da movimentare, più piccole sono le dimensioni degli stessi e più efficace è l’utilizzo del livello storage più prestazionale, ovvero i dischi allo stato Solido (SSD o EFD), che sono quelli a costo più elevato.

I due aspetti sopra descritti incidono, oltre che sull’efficacia della soluzione, anche sull’utilizzo delle risorse “computazionali” che ogni sistema Storage possiede. Ad esempio, sui sistemi della fascia High End di EMC, i sistemi Symmetrix VMAX, la dimensione minima dell’elemento movimentato è 8MB e la movimentazione stessa del dato è continua, con una finestra di analisi minima di 10 minuti.

Come accennato in precedenza, ogni produttore di sistemi storage utilizza parametri differenti; è quindi fondamentale analizzare quanto le diverse soluzioni possano rendere questa tecnologia più o meno efficace.

La tecnologica di Storage Tiering è ovviamente indipendente rispetto alla tipologia di Server e/o Sistema Operativo: le funzionalità messe a disposizione dello storage quindi risultano disponibili per tutte le applicazioni in modo trasparente. Sui sistemi Storage EMC, questa tecnologia è disponibile per tutti, o quasi, gli ambienti operativi Open Systems, Mainframe e iSeries (AS/400).

L’evoluzione più recente, in casa EMC, ha visto l’introduzione di concetti di movimentazione del dato al di fuori dei sistemi Storage, verso livelli ancor più prestazionali, all’interno dei server, o, al contrario, verso sistemi Storage a loro volta “virtualizzati” attraverso i sistemi Storage principali.
In futuro è prevedibile che queste tecniche assumano una connotazione gestionale eterogenea; sistemi Storage in grado di muovere i dati verso altri sistemi Storage, aventi caratteristiche differenti quali, ad esempio, deduplica e compressione (quest’ultima già disponibile).

Per saperne di più accedi alla pagina dedicata alle soluzioni Storage EMC su EMC Community Network; posta le tue domande e riceverai supporto.


Stefano Panigada

Nessun commento:

Posta un commento