Trascrizione del webcast
Carlos Nieves: Buongiorno, buon pomeriggio e, per alcuni di voi, anche buona sera. Grazie per essere qui con noi oggi. Mi chiamo Carlos Nieves e sarò il vostro moderatore per questo evento. Vorrei dare il benvenuto a tutti voi alla presentazione di oggi, incentrata sul tema dei dati "caldi" e "freddi", sulla loro influenza sulle decisioni relative al posizionamento dei dati e su come gestirli. Oggi è con noi anche il nostro relatore, Augie Gonzalez. Augie è direttore del marketing di prodotto e uno dei nostri esperti tecnici in materia di software-defined storage .
Prima di iniziare la presentazione di oggi, vorrei illustrare alcuni aspetti organizzativi. Innanzitutto, la presentazione includerà alcune domande di sondaggio, quindi vi invitiamo a votare e a partecipare man mano che le domande verranno poste. Inoltre, al termine della presentazione terremo una sessione di domande e risposte; vi invitiamo quindi a inviare le vostre domande in qualsiasi momento utilizzando l’apposita casella. Al termine della sessione di domande e risposte selezioneremo il vincitore dell’estrazione a sorte di una carta regalo Amazon del valore di 200 dollari. Abbiamo incluso anche alcune risorse nella sezione degli allegati, quindi sentitevi liberi di consultarle. Inoltre, questa presentazione verrà registrata. La condivideremo con tutti i partecipanti e sarà disponibile anche on-demand. Infine, non dimenticate di valutare la presentazione e di fornirci un feedback, che per noi è molto prezioso. Detto questo, vi affido al nostro esperto di soluzioni tecniche, Augie Gonzalez. Augie?
Augie Gonzalez: Ehi, grazie Carlos. Allora, quando guardo questa foto, mi viene da sorridere un po’. Mi ricorda le grandi differenze di temperatura tra la primavera qui nella splendida Florida e quella di tutti quelli che vivono a nord di noi, ma in realtà questo netto contrasto di temperatura si riscontra anche nei tuoi dati. Vediamo quindi come si presenta la situazione.
Uno dei motivi per cui ne stiamo parlando è che questo influisce sulle nostre spese: quanto spendiamo per dati relativamente inattivi che non meritano lo stesso investimento dei normali dati attivi, sui quali facciamo così tanto affidamento. Lo sappiamo perché abbiamo dedicato parecchio tempo all’analisi dei dati di telemetria provenienti da migliaia di siti, e questo ci offre una prospettiva davvero chiara sulla distribuzione dei dati attivi rispetto a quelli inattivi in ambienti come il vostro.
Date un’occhiata a questi grafici. Sono molto rappresentativi di ciò che osserviamo in generale. Quindi, se doveste considerare la norma degli scenari, questo è ciò che trovereste in media. E lasciate che ve lo illustri. L’asse di sinistra è davvero significativo – e vedete quel grande picco. In pratica vi indica la temperatura. Quindi picchi molto alti a sinistra – quel verde arriva fino all’estremità del rosso. Ciò indica i dati più attivi, quelli a cui si accede più frequentemente. Come potete vedere, la curva si appiattisce man mano che ci si sposta verso destra e verso il basso. Comincia a calare drasticamente intorno al 20%. In sostanza, ciò significa che la maggior parte dei dati più richiesti rappresenta circa il 20% della capacità complessiva del pool a cui avete accesso. È un dato molto significativo perché indica che solo una piccola frazione di tutti i dati a vostra disposizione è effettivamente abbastanza importante da giustificarne un accesso frequente.
Ora, il secondo grafico che vedete qui, la linea ondulata – quelle linee arancioni, gialle e ambrate – indicano l’età dei dati. Si tratta del tempo trascorso da quando questi dati sono stati raccolti per la prima volta. Anche qui si osserva lo stesso fenomeno: la temperatura, quando viene registrata per la prima volta, è attiva – è “calda” – ma nel giro di poche ore, di fatto, questi dati diventano relativamente obsoleti e inutilizzati, e invecchiano molto rapidamente. Ne parlerò più approfonditamente quando tratteremo dell’emivita dei dati, ma questo serve solo a preparare il terreno. Si tratta di un fenomeno molto, molto comune. Se analizzaste i vostri scenari, notereste un andamento molto simile.
Le variazioni di temperatura vengono spesso descritte in termini generali come “dati caldi” – dove per “dati caldi” si intende un’elevata frequenza di utilizzo, un accesso frequente, sempre attivi. La seconda categoria è solitamente associata ai “dati tiepidi”, dove l’utilizzo è più moderato – non così frequente come nel caso dei dati caldi. Poi ci sono le informazioni a cui si accede raramente, che verrebbero trattate come – lasciamole come “dati freddi”. In realtà ce n’è un’altra di queste. Si chiamano “dati congelati” e ne parleremo più avanti. Non importa se si utilizzano i gradi Fahrenheit o Celsius: il concetto è lo stesso. Si tratta di una correlazione molto forte, indipendentemente dal sistema di misura utilizzato.
Ciò che è importante, però, è che mentre ci concentriamo principalmente su ciò che ci interessa e che è rilevante in un determinato momento, se poteste dare un’occhiata all’intero volume di dati con cui avete a che fare, vi accorgereste che questi dati “caldi” rappresentano solo una piccola frazione – una quantità sproporzionatamente esigua rispetto al volume complessivo. Anche i dati “tiepidi” costituiscono una piccola parte, ma entrambi rappresentano in realtà solo la punta dell’iceberg.
La maggior parte delle informazioni che conservate e per le quali spendete una bella somma sono dati inattivi. È interessante, perché tendiamo a perderlo di vista molto rapidamente. Siamo concentrati sulla gestione dell’azienda e a volte trascuriamo questo aspetto a nostre spese.
Per fornire cifre più concrete, bisogna considerare la capacità media gestita e di quanto sia cresciuta anche solo negli ultimi due anni e più. In alcuni casi, il numero di petabyte conservati è quasi sestuplicato. Ora, il vostro ambiente potrebbe essere più piccolo di questo, ma probabilmente la percentuale relativa di crescita è simile, a seconda del settore in cui operate. Quindi rifletteteci. Nel caso in cui qualcuno conservi quasi 10 petabyte di dati, se solo il 20% di questi fosse attivo e davvero importante, e si spendesse la stessa somma di denaro per quel 20% per salvaguardarlo, proteggerlo e mantenerlo attivo e aggiornato, proprio come si fa per gli altri 8 petabyte… wow, si sta sprecando un sacco di denaro nel posto sbagliato, denaro che potreste investire meglio altrove.
Ora parleremo dei modi per affrontare la questione, ma prima vorrei capire quanti tipi diversi di dispositivi di archiviazione utilizzate attualmente. Mi interessa davvero capire come gestite questa separazione tra dati “hot”, “warm” e “cold”. Quindi vorrei che compilaste il questionario scegliendo una di queste opzioni, una sola. Se utilizzate tutti gli stessi dispositivi di archiviazione, indipendentemente dalla temperatura – in modo da avere fondamentalmente una visione unica della situazione; non cercate di fare alcuna distinzione oggi. Alcuni di voi potrebbero scegliere di dividere a metà, utilizzando un tipo di archiviazione per i dati attivi e un altro per quelli di archivio. Vorrei saperlo. E coloro che hanno adottato un approccio un po’ più sofisticato e attento a questo aspetto, potrebbero utilizzare 3 o più tipi per farlo. A seconda che li conserviate in sede o meno, sceglierete l’opzione C o D. Potrebbero esserci poi altri casi che si collocano a metà strada. Non ne sono sicuro, ma se poteste rispondere in modo letterale, ne saremmo lieti. Vi concedo circa 10 secondi per rispondere – scegliete una delle due opzioni – e poi discuteremo dei risultati della votazione.
Ok, ecco come stanno iniziando a delinearsi i risultati del sondaggio. Vi darò solo una rapida snapshot possiamo proseguire con la trasmissione. Circa il 20% utilizza un solo dispositivo di archiviazione, indipendentemente dalla temperatura. È interessante. Circa il 26% ne utilizza due, uno per i dati attivi e uno per quelli d’archivio. Solo circa il 4% utilizza tre o più tipi, tutti on-premise. E poi c’è il resto: un mix di livelli on-premise e cloud , che rappresenta circa il 43%. Quindi, niente male. Sembra che molti di voi stiano facendo un lavoro ragionevole nel suddividere il mix e gestirlo correttamente. Questo è positivo. Siete già sulla strada giusta.
Ora parliamo di questa “emivita”. È un concetto che ho appreso da Nucleus Research. Hanno analizzato diversi settori per capire quanto fossero importanti i dati dopo pochi minuti, dopo alcune ore e dopo alcuni giorni, giungendo ad alcune conclusioni significative. Hanno paragonato questo concetto all’emivita dei materiali radioattivi, dove alcune sostanze rimangono attive per molto tempo e possono ancora causare danni. Ebbene, per quanto riguarda l’emivita dei dati, tende a valere il contrario. In un certo senso, per le informazioni tattiche – rappresentate dalla curva blu che vedete qui – in media entro 30 minuti dall’arrivo dei dati, questi non sono più particolarmente utili nel processo decisionale. Questo è curioso in un certo senso, perché in pratica significa che se devo prendere decisioni entro pochi minuti dall’arrivo di queste informazioni, se aspetto oltre quel limite o esamino quei dati in un momento successivo a quel periodo, essi non hanno davvero alcun valore per me. Non influiscono: in pratica potrei anche buttarli via, perché non influenzeranno più il modo in cui affronto le mie scelte.
Questo accade con i fornitori. Ad esempio, stiamo cercando di adottare una gestione delle scorte e delle consegne just-in-time. Questo è un ambito. Anche parte della programmazione nel settore aereo a volte risente di questo ordine di grandezza. La considerano una decisione molto tattica che devono prendere in modo molto spontaneo. Quindi, se non consultano quei dati proprio in quel momento o entro pochi minuti, non saranno particolarmente utili. Infatti, se si aspettasse di stampare i report – è uno dei punti che sottolineano. Se si aspettasse che una stampante producesse alcune di queste informazioni, sarebbero già obsolete nel momento stesso in cui l’inchiostro le stamperebbe.
Ora, ci sono anche i dati operativi. Pensate alla parte tattica come a quella iniziale: bisogna agire in tempo reale. Quella operativa è invece quella in cui le decisioni basate su questi dati si estendono magari per giorni o qualche settimana. Quindi ciò che accade è che la pendenza si attenua: il valore di quei dati è più graduale. Infatti, in questo ambito si dice che, all’incirca – e c’è una deviazione standard molto ampia – ma dopo circa 8 ore, solo il 30% dei dati che arrivano successivamente e che rimangono in sospeso per oltre 8 ore sarà utile per qualcosa di diverso dalla pianificazione futura e da alcune analisi predittive successive. Ma dopo 8 ore non influisce realmente sulle vostre scelte operative.
Ora, la linea verde, che sembra quasi una linea retta – e, ribadisco, si tratta di un dato aggregato che copre un’ampia varietà di settori, e parte del loro ragionamento è che non dipende tanto dal settore specifico, quanto piuttosto dalla fase del processo decisionale in cui ci si trova. Qui si parla della natura strategica. Quindi, le questioni strategiche sono decisioni che vengono prese, ad esempio, su base trimestrale o annuale. In questo caso l’emivita diminuisce in modo molto più graduale. Quindi, dopo circa 56 ore, se ricordo bene, ritengono ancora che il 70% di quei dati sarà importante per aiutarli nelle scelte strategiche a lungo termine. Questo avrà un peso e farà parte dei criteri che userete per determinare non solo la “temperatura” dei dati – come criterio di selezione per stabilire quanto investire sui dati – ma anche quale sia la loro emivita. E se la sua emivita è lunga, allora ovviamente c’è una buona ragione per spendere di più su di essi. Se invece la durata è molto breve, allora non appena non sono più utili, si dovrebbe considerare di trasferirli in un archivio molto più economico, anche se si desidera conservarli per riferimento e pianificazione futuri.
Abbiamo già dato un’occhiata all’iceberg. Probabilmente questo… cliccherò su questo punto così potrete vedere la distribuzione relativa di quella capacità, in media, in un ampio ventaglio di ambienti dei clienti. Come vedete, una piccola fetta, dell’ordine del 20% dei dati, è costituita da dati “caldi”; i dati “tiepidi” rappresentano forse il doppio di quella percentuale, mentre i dati “freddi” costituiscono la parte più consistente, con alcuni che rientrano poi in quella categoria di dati “glaciali”, ovvero congelati.
Ciò che è importante tenere a mente in questo contesto è la percentuale – anzi, non la percentuale, ma il volume effettivo dei dati “caldi”, che tende a rimanere piuttosto costante. Questo dato si basa sugli input dei sensori, sugli input in tempo reale che si ricevono e sulle informazioni transazionali che si raccolgono. A meno che la vostra azienda non stia crescendo in modo significativo, si tratta di un numero piuttosto limitato. Ciò che tende ad accumularsi sono i dati "freddi" e "congelati". Questi continuano ad accumularsi nel tempo, ed è per questo che l’iceberg diventa così profondo e pesante nella parte sommersa. È proprio questo che dobbiamo capire: come allocare al meglio lo spazio di archiviazione appropriato per ciascuno di questi scopi.
Il problema, ovviamente, è capire come procedere. A volte li considero quasi come dei “contenitori” separati gli uni dagli altri. Abbiamo preparato alcuni video illustrativi al riguardo, ma in questa rappresentazione quello che voglio mostrarvi è la classica segmentazione dello spazio di archiviazione per distinguere i dati “caldi”, “tiepidi”, “freddi” e “congelati”, pensando al tipo di spazio di archiviazione a cui li assegnereste.
Molte persone a cui lo chiederesti direbbero: “Beh, conservo i miei dati ‘caldi’ – devono essere super veloci, a bassa latenza. Devo metterli in un flash ”. Allora, che ne pensi? Quello è proprio l’array all’estrema sinistra. Potrei utilizzare un array di storage ibrido, in grado di ospitare sia dischi a stato solido che dischi rotanti, come repository “warm”. E per lo storage secondario, potrei usare semplicemente una soluzione economica e ad alta capacità – un JBOD, ad esempio, o semplicemente grandi dischi rotanti. Per tutto il resto, invece, lo considero una risorsa elastica a mia disposizione nel cloud.
La questione diventa quindi, innanzitutto: da dove si comincia? Da dove si inizia a esaminare e valutare quali dati sono rilevanti e quali no? Una volta stabilito questo, quale sarà la situazione tra qualche minuto rispetto alla stessa conclusione a cui si è giunti osservando i dati per la prima volta? Si tratterà ancora della stessa conclusione a cui si giungerebbe in seguito? E, dato ciò, con quale frequenza si dovrebbe verificare, e quanto tempo ci vorrebbe per farlo ogni volta?
In sostanza, ciò che abbiamo sottolineato nell’abstract è che non si tratta di qualcosa che un essere umano possa fare. Non esiste un modo efficace per farlo con l’intervento umano. A chi ci prova, in base alle esperienze che ho osservato nel sondaggio precedente, posso dire che prevedo che si tratti di misure molto impegnative che si finiscono per dover adottare se si è costretti a eseguire qualsiasi operazione manualmente; ciò potrebbe infatti causare alcuni rallentamenti per gli utenti mentre si cerca di spostare i dati da un posto all’altro, e ovviamente è un lavoro faticoso anche per voi. Man mano che affronteremo questo problema, vi forniremo alcuni consigli su come automatizzare tale processo.
Una cosa che mi è capitato di sentire quando ne ho parlato in passato è che la gente dice: “Ehi, aspetta un attimo. Perché ti occupi di tutti questi diversi tipi di storage e tutto il resto? Perché non ne scegli semplicemente uno? Scegline uno. Magari usa un sistema ibrido, un grande e vecchio array ibrido. Si occuperà di tutto questo”. Beh, il motivo è che farlo è estremamente costoso.
Se si cercasse di dotare gli array ibridi di una capacità sufficiente a gestire tutti questi dati, in particolare quelli inattivi e congelati, non sarebbe possibile: la maggior parte delle persone non può permetterselo. Solo le organizzazioni più facoltose sono in grado di farlo. Quindi ciò che dobbiamo fare è trovare modi, più sfumati, per affrontare il problema, riconoscendo che occorre una combinazione di diverse classi di storage per bilanciare al meglio la capacità.
Il motivo per cui dico che è così costoso è che questo dato proviene da uno studio di Gartner, in cui sostanzialmente si cercava di analizzare la differenza di prezzo e il costo per terabyte tra un array SSD, unflash , un array ibrido e un array interamente su disco rigido. E il costo per terabyte di unflash è circa 6 volte superiore. Quindi, se decidessi di passare completamenteflash, va bene se te lo puoi permettere, ma cavolo, è un sovrapprezzo notevole che stai spendendo per componenti destinati a diventare relativamente obsoleti in breve tempo. Probabilmente non è l’approccio economicamente più vantaggioso. Alcuni potrebbero analizzarlo attentamente e dire: «Cavolo, quei soldi dovresti spenderli per qualcos’altro». Responsabile dal punto di vista finanziario: credo di aver sentito descrivere la questione in questi termini.
L’immagine che vorremmo lasciarvi qui è quella di come DataCore affronta la questione dal punto di vista della virtualizzazione. Si tratta di un diagramma molto semplice. Mette in evidenza che al livello superiore si trovano i consumatori di storage: i carichi di lavoro, che si tratti di sistemi bare metal, server virtualizzati o carichi di lavoro containerizzati. Tutti questi possono fondamentalmente attingere a pool di capacità che presentano diversi livelli, commisurati alla “temperatura” dei dati e al loro valore.
In questo caso, il software si assume tale responsabilità e utilizza l’apprendimento automatico per distinguere ciò a cui si accede effettivamente con frequenza da ciò a cui non si accede, e, grazie all’intelligenza artificiale, decide poi in tempo reale dove collocarlo al meglio, mentre la strumentazione interna e la telemetria ci forniscono informazioni su ciò che sta accadendo. In questo modo, è in grado di rispondere direttamente ai modelli di comportamento che si stanno verificando, indipendentemente dal fatto che si stia osservando il processo o meno.
Riteniamo di essere l’unico fornitore indipendente di software in grado di farlo su tutta la linea – ovvero in grado non solo di integrare queste diverse soluzioni di storage progettate appositamente per tali scopi, ma anche di gestire l’auto-tiering. Potete quindi fare le vostre ricerche sulla concorrenza, e credo che alla fine arriverete a questa conclusione.
Il tiering automatizzato dello storage è essenzialmente un modo per trovare il miglior compromesso, se la si vede in questo modo, tra prestazioni ottimali, latenza minima e l’importo speso per il servizio, ovvero il costo. Approfondiremo questo argomento più nel dettaglio, ma vedrete come siamo in grado di migrare dinamicamente i blocchi tra le diverse classi di storage; tale migrazione sarà determinata dalla frequenza di accesso e potrà essere sovrascritta dalle vostre preferenze utente, ove necessario.
Pensateci dal punto di vista della granularità. In realtà è ancora più interessante. Pensate a un database Oracle o SQL. Verrebbe da pensare che, se ne aveste il controllo manuale, direste: “Ok, questo è un database Oracle. Qui ci sono tutti i dati finanziari, tutte le transazioni più impegnative avvengono qui. Quindi lo collocherò su unflash , perché è lì che generiamo la maggior parte dei nostri profitti. Deve essere il più reattivo possibile”.
Beh, se aveste gli strumenti adeguati, vi accorgereste che solo una piccola parte di quel database viene effettivamente utilizzata intensamente. Il rest … ecco, è più o meno l’immagine rest sto mostrando a sinistra. Ci sono queste zone “calde” in rosso a cui si accede molto frequentemente. Notereste alcune parti dello stesso database a cui si accede con moderata frequenza, e poi altre a cui praticamente non si accede quasi mai.
Cosa fa il software DataCore in questo caso? Non cerca di ingigantire la cosa… ok, quello è l’intero blocco che… è un database SQL. Devo trasferire tutto su unflash . In realtà è molto più intelligente di così, molto più sofisticato. Analizza la situazione e dice: «Ok, posso suddividere questo database, in pratica, nel volume su cui risiede in blocchi, e a quei blocchi posso assegnare e allocare lo spazio in modo specifico in base ai blocchi più utilizzati che posso collocare su flash, mentre il sottoinsieme a cui si accede con moderata frequenza lo posso collocare su uno storage a costo inferiore». Poi tutto il resto, a cui si accede raramente, lo metterò in un array di dati 3-three. Questo cambierà man mano che cambierà il comportamento degli utenti di quei database. Quindi effettuerà questi cambiamenti nell’allocazione e nell’assegnazione di quei blocchi di conseguenza, man mano che la situazione evolve, senza alcun intervento manuale.
Una delle cose che potreste chiedervi è: “Beh, ora che abbiamo tutto questo in atto, in che altro modo possiamo dare una mano?”. Quindi, oltre al tiering automatico gestito dall’intelligenza artificiale e dal machine learning che avviene dietro le quinte, stiamo anche memorizzando i dati nella cache. Quindi, ogni picco di traffico che rileviamo, lo memorizziamo nella cache RAM vicina all’applicazione per accelerare ulteriormente il valore di tutto ciò che arriva e necessita di un po’ più di spinta. Ovviamente non è opportuno farlo per qualcosa che è inattivo, perché non si vuole occupare la cache con quel tipo di dati. Quindi, tali dati tendono naturalmente a spostarsi all’estrema destra. Pertanto, i dati meno attivi vengono collocati su storage a basso costo, mentre quelli più attivi vengono collocati su quello più veloce. Questa è l’essenza di tutto il messaggio, ciò che stiamo cercando di trasmettere qui.
Dal punto di vista visivo, è possibile monitorare questi aspetti all’interno del software grazie a una serie di grafici dinamici e tracciati che mettiamo a disposizione. Lo facciamo sia in tempo reale che in modo storico, in modo che possiate vederlo. Quello che vi sto mostrando ora è come avviene automaticamente la messa a punto e le heat maps il software presenta nella console quando lo state visualizzando, oltre che in alcune delle analisi nel backend.
Ciascuno dei gruppi di righe che vedete – il primo gruppo corrisponde al livello 1 – mostra quanto spazio gli viene assegnato e quanto ne viene effettivamente utilizzato. Le successive 4 o 5 righe rappresentano il livello secondario, mentre l’ultimo gruppo di righe corrisponde al terzo livello in questo scenario specifico. Noterete che, al variare della composizione dei carichi di lavoro, anche l’allocazione subirà delle variazioni. È semplicemente un modo per tenere sotto controllo la situazione.
Forse vi starete chiedendo come facciamo a definire questi livelli. È molto semplice. In sostanza, quando si introduce un nuovo sistema di archiviazione nel nostro pool virtualizzato, si specifica a quale livello si desidera che appartenga. A volte capita che, pur disponendo di un sistema di archiviazione molto veloce, ci siano – lo chiamerò così – motivi di natura “politica”. Abbiamo appena speso un sacco di soldi per questo array. Lo trattiamo come livello 1, anche se potrebbe avere caratteristiche molto simili a quelle di qualche altro livello che abbiamo, ma vogliamo riservare un trattamento preferenziale proprio a questo. Quindi possiamo definire esplicitamente un livello per una determinata risorsa nel nostro pool. In questo caso, perflash nostroflash , lo designiamo come livello 1. Il nostro array ibrido verrebbe designato come livello 2, mentre qualsiasi sistema secondario, come lo storage di massa, potremmo designarlo come livello 3 o 4.
Per quanto sia facile farlo, è anche possibile modificare questa configurazione. Quindi, quando arriva il tuo storage – supponiamo che ora, oltreflash , voglia introdurre dello NVMe diretto all’interno di DataCore, che sta virtualizzando il pool – questi sarebbero estremamente veloci e reattivi. Potrei quindi assegnare loro un'etichetta ora, al momento della loro introduzione come tier 1, e spostareflash nel mio tier 2. Posso farlo in background senza influire, disturbare o causare alcun tempo di inattività per gli utenti. Questi ultimi vedrebbero semplicemente il vantaggio di avere un tier 1 estremamente veloce a disposizione, e il software si occuperebbe automaticamente di migrare i blocchi in quel tier, se necessario. Lo stesso vale per le configurazioni a cascata. Se si disponesse di uno storage di livello 3 o 4 davvero economico che si desidera introdurre nel pool, si procederebbe allo stesso modo. A quel punto potremmo sostanzialmente dire: «Ok, ora quello è il posto migliore dove collocarlo» – e lasciare che sia il software a occuparsene.
Ci sono anche circostanze particolari che suggeriscono, e possono addirittura imporre, di ignorare l’intelligenza che sta operando in questo contesto, perché potrebbe esserci un’attività di breve durata che si desidera, in effetti, fissare consapevolmente. Credo che questo sia uno dei termini che si usano: "assegnare a un livello" per un breve periodo di tempo. Quindi, alla fine del trimestre, devo preparare alcuni report speciali, anche se in genere questi set di dati vengono consultati con relativa rarità. Quello che vogliamo fare è sfruttare lo storage più veloce possibile per eseguire questa operazione immediatamente, in modo da poter identificare determinati volumi e modificare esplicitamente il profilo di storage per collocarli su un determinato tipo di storage. Posso farlo probabilmente in due casi estremi – che di solito è ciò che vediamo fare dai nostri clienti. Uno è quando dicono che si tratta di dati super critici, quindi assicuriamoci che ottengano tutti i vantaggi dello storage più veloce, oltre a – in questo caso vedete a sinistra il profilo di storage “critico”. La classe di prestazioni è impostata al massimo, così come la priorità di replica, la priorità di ripristino e qualsiasi funzione di auto-tiering è disabilitata. Durante questo periodo lo indico esplicitamente.
Il secondo caso è quando ho qualcosa che, diciamo, è un backup. Voglio che i miei backup – quei blocchi che vengono utilizzati durante il backup – vengano collocati esplicitamente sul mio tier 3 o sul mio storage di tipo secondario, che so essere più economico. Quindi, per qualsiasi volume utilizzato per i backup, lo designo: sovrascrivo il normale auto-tiering e indico di collocarli sullo storage secondario, e il software lo farà volentieri per te. In questi casi particolari è possibile intervenire quando lo si ritiene necessario.
Questo mi porta alla nostra seconda domanda del sondaggio, e sono davvero curioso di capire, viste le variazioni che mi avete mostrato poco fa – e per chi di voi ne ha altri 2 o 3 – quali strumenti utilizzate per trasferire i dati su un supporto di archiviazione diverso? Man mano che si raffredda, passa da “molto caldo” agli altri. Anche qui ci sono 4 opzioni. Oggi non posso farlo. Non lo farò. Immagino che siano proprio quelli che hanno indicato un solo tipo di dispositivo di archiviazione. Alcuni di voi potrebbero utilizzare tecniche di copia, in particolare tecniche di copia basate sull’host. In pratica, si copia il contenuto da qualche parte e poi si elimina l’originale. E potrebbero essercene alcuni che utilizzano anche strumenti di migrazione dell’archiviazione come Storage vMotion. Quindi, per favore, dateci la vostra opinione e vedete come si confronta con quella degli altri.
Ecco cosa mi risulta al momento: stiamo ricevendo le informazioni tecniche che ci consentiranno di prendere alcune decisioni per il rest presentazione. Il 33% al momento afferma di non poterlo fare oggi – probabilmente l’unico motivo per cui siete qui. Un altro 32% dice di copiare i dati e poi cancellare l’originale, e vi capisco perfettamente. So quanto sia difficile. Circa il 13% sta effettuando una sorta di migrazione della sorgente utilizzando strumenti come vMotion, mentre il restante 23% circa sta utilizzando qualche altra tecnica, di cui mi piacerebbe molto sapere di più. Ottimo, grazie per aver risposto a queste domande.
Questo potrebbe essere un altro approccio. Con DataCore, in pratica si dispone di un auto-tiering tra array. È la massima flessibilità. In sostanza, significa che è possibile collegare qualsiasi tipo di storage a blocchi a disposizione per soddisfare i requisiti primari, secondari e terziari, inserirlo nel pool e lasciare che sia il software a decidere dove collocarlo al meglio. Funziona sia con lo storage esistente che con quello futuro. Abbiamo clienti che utilizzano questa soluzione da oltre 10 anni. Ovviamente, nel corso di questo periodo hanno introdotto e dismesso una notevole quantità di apparecchiature, il tutto senza alcuna interruzione del servizio.
Come vi ho mostrato, è possibile definire in modo specifico quali di questi elementi compongono ciascun livello. In questo modo è possibile distinguere tra le soluzioni ad alte prestazioni, quelle di fascia media e quelle a basso costo. Ciò si rivela vantaggioso anche in termini di prestazioni delle applicazioni. Infatti, se si collocano sia dati relativamente obsoleti che dati “caldi” sullo stesso sistema di archiviazione, ciò che accade è che gli array di archiviazione tendono, man mano che si riempiono, a subire un peggioramento dei tempi di risposta. In pratica, si compromette non solo la capacità — sovraccaricandola di lavoro extra — ma si riduce anche l’efficacia della risposta in tempo reale. Pertanto, quando si riescono a rimuovere quei carichi secondari e a collocarli altrove, si dispone di più spazio e più risorse per soddisfare i requisiti di prestazioni elevate. Anche in questo caso, nelle situazioni in cui si desidera ignorare questa impostazione, è possibile farlo.
Ci sono altri ambiti in cui abbiamo riscontrato che queste tecniche offrono approcci validi. Uno di questi è quando si hanno diverse — le definirei “preferenze di linea di business”. I vostri clienti potrebbero avervi chiesto: «Ho bisogno di un fornitore specifico per soddisfare questa esigenza, perché in passato ho avuto buoni risultati con lui», e incoraggiare il reparto IT ad acquistarlo per questo progetto. Quindi lo fate. A quel punto, ciò che potete fare è assegnarlo esplicitamente a quel progetto e magari condividere quella risorsa anche con altri che hanno esigenze minori. Questo vi offre un grado di flessibilità che prima non avevate. In qualsiasi momento potete decidere: «Ok, ora la rimetto nel pool e lascio che tutti possano usufruire di quella risorsa». Non deve necessariamente rimanere isolata. Anzi, può essere condivisa laddove esiste una capacità in eccesso.
Può essere utilizzato anche per gestire fusioni e acquisizioni. Quindi, ci imbattiamo sempre più spesso in aziende che, man mano che acquisiscono altre società e ne incorporano l’intero patrimonio IT, si trovano a dover gestire molteplici varianti, fornitori e modelli di storage, e non sanno davvero come razionalizzarli o come dar loro un senso. Ecco il modo più semplice per raggrupparli in pool comuni e poi assegnarli. Ok, so che qui potrebbe trattarsi di HP. Vedo che qui potrebbero esserci alcune apparecchiature Dell EMC provenienti da queste operazioni di fusione e acquisizione. Identifichiamole in base ai livelli, inseriamole semplicemente nei pool virtualizzati e lasciamo che sia il software a decidere dove collocare al meglio i carichi di lavoro utilizzando queste tecniche.
A proposito, è utile anche quando vengono installate nuove generazioni di apparecchiature. In questo modo, quando si hanno apparecchiature vecchie e nuove che coesistono, è possibile trattarle tutte allo stesso modo. Potreste notare che quelle più vecchie sono un po’ datate. Non funzionano più altrettanto bene, anche se di per sé sono dello stesso modello e della stessa marca, ma possiamo classificarle in livelli leggermente diversi.
Penso che, da un certo punto di vista, si possa considerare la questione sulla base di ciò che già esiste, ma altrettanto importante — come nel caso di questo cliente, Architectural Nexus— è la possibilità di integrare soluzioni di storage di nuova generazione a qualsiasi livello si scelga e ci si possa permettere, senza tempi di inattività. Penso che l’abbiano spiegato molto bene: con DataCore non si tratta mai di un’operazione radicale. È possibile acquistare l’hardware più recente e implementarlo dove serve, ottenendo immediatamente i vantaggi dell’hardware di ultima generazione senza perdere l’investimento nell’infrastruttura dati esistente.
In sostanza, significa che posso integrare nuove attrezzature, oggetti nuovi di zecca che mi attraggono e per i quali è stato stanziato un budget. Posso comunque continuare a sfruttare le attrezzature esistenti, magari riducendone le prestazioni. Poi, a un certo punto, quando il loro ciclo di vita finanziario sarà giunto al termine, potrò eliminarle del tutto dal parco attrezzature. Tutte queste fasi possono avvenire senza alcun momento di inattività.
I vantaggi economici sono notevoli. Se ne parliamo è perché questo aspetto incide direttamente sui vostri profitti. Riuscire ad allineare la spesa per lo storage al valore temporale dei dati deve diventare una responsabilità fondamentale che ci assumiamo d’ora in poi, dato l’enorme volume di dati esistenti e tenendo conto di quanti di essi siano di scarso interesse o secondari e non giustifichino lo stesso livello di spesa.
Un vantaggio collaterale, che in questo caso è molto significativo, è che, distanziandovi e isolando il tipo di storage che utilizzate dai consumatori in questo modo — le software-defined storage — acquisite anche un maggiore potere negoziale. In altre parole, lo storage diventa una risorsa intercambiabile. È quindi possibile cambiare fornitore se quello attuale non vi tratta particolarmente bene, ovvero non vi offre condizioni vantaggiose. Mentre in passato dipendevate da procedure specifiche legate a quel modello e a quel fornitore, ora ne siete completamente svincolati. Disponete di un insieme uniforme di software-defined storage che, indipendentemente da ciò che scegliete di sostituirlo, garantisce la continuità operativa. Lo stesso processo che utilizzavate per l’allocazione, la protezione e l’ottimizzazione dell’utilizzo rimane in vigore. Questo vi darà la possibilità di ottenere ogni volta l’offerta migliore. Un elemento molto importante della struttura complessiva.
Date un’occhiata ad alcune risorse. Credo che anche Carlos ne indicherà alcune, ma ci sono diverse descrizioni sull’argomento e un video, oltre a un white paper che è uno degli allegati che vi mettiamo a disposizione. Questo vi fornirà qualche informazione in più e quantificherà alcune delle discussioni che abbiamo avuto oggi.
Detto questo, passiamo ad alcune domande del pubblico. Ne esaminerò alcune proprio ora. La prima è: “È possibile avere diversi set di profili per diversi tipi di dati? Si tratta di un’azienda di ingegneria del software che dispone di terabyte di dati con requisiti diversi: progetti estivi, substrati di coltivazione, ecc.” È esattamente quello che state cercando di fare. Posso definire un profilo come «critico», «normale» o «di archivio», e posso anche creare profili personalizzati per indicarne il valore relativo rispetto a tutto il resto.
Eccone un’altra. “Che tipo di scenario si riscontra comunemente per la protezione dell’archiviazione dei dati — hot, warm o cold — e quali tipi di aziende lo utilizzano?” È un fenomeno trasversale. Non si tratta di un comportamento specifico di un determinato settore verticale o di un’industria in particolare. Quello che si nota è che ce ne sono di più: ad esempio, lavoriamo con molte organizzazioni sanitarie che si occupano di cure vitali, ed è molto, molto chiaro per loro cosa sia “hot” e quale percentuale di questi dati richieda soluzioni speciali e super veloci, quali siano quelli che stanno diventando obsoleti e quali abbiano requisiti di archiviazione a lungo termine. In questo caso è più evidente. È un’espressione più naturale della loro attività. In altri casi, non è così evidente perché non hanno mai analizzato i dati in questo modo. E speriamo che, comprendendo ciò di cui abbiamo discusso oggi, iniziate a guardarli con questi occhi. Sarà importante.
Sto dando un’occhiata ad altre domande qui. Ok, “Al di fuori dell’interfaccia grafica, come posso modificare a livello di programmazione gli attributi di tiering?” Interessante. Sì, quindi parte di ciò che accade oggi in molti di questi scenari è che dobbiamo gestire l’orchestrazione esternamente. La persona non può trovarsi fisicamente davanti a una console a eseguire queste operazioni e a effettuare queste scelte. Insomma, non sarebbe un buon uso del proprio tempo. Esistono quindi metodi condizionali e programmatici. Offriamo una soluzione completa: REST per richiamare non solo le opzioni di tiering, ma anche qualsiasi altra funzione disponibile tramite il software DataCore, accessibile tramite rest . Per chi PowerShell , offriamo anche quella opzione.
Un’altra domanda è: «Con quale frequenza il software decide di spostare i blocchi tra i livelli?» Si tratta di una scelta dinamica che il software compie autonomamente. Una delle cose che il software fa fondamentalmente è cercare opportunità in cui il sistema non sia così occupato da impedire lo spostamento dei dati in quel momento, perché ciò costituirebbe un uso improprio delle risorse. Quindi cerca queste opportunità. Ok, qui ho un po’ di respiro. Questo è un buon momento. Ma lo fa regolarmente. Quindi non è qualcosa che devi programmare né devi preoccuparti che avvenga solo in determinate ore. Succede costantemente su quelle risorse e su quei volumi che hai assegnato a questa funzionalità.
«DataCore ha sede negli Stati Uniti?» Sì, è così. Siamo però un’azienda presente in tutto il mondo. Ovunque tu sia, possiamo raggiungerti. [Ride] E credo che queste siano tutte le domande che ho. Carlos, hai altro da aggiungere?
Carlos: No, non vedo altre domande, Augie. Grazie ancora per aver tenuto una presentazione molto istruttiva e ricca di informazioni. Vorrei solo ricordare alcune cose, per incoraggiare nuovamente tutti a dare un’occhiata alla sezione degli allegati. Lì troverete un white paper relativo a questo argomento. Inoltre, invito tutti a fornirci un feedback valutando il relatore e la presentazione; vi ricordo anche che questa presentazione è stata registrata, la condivideremo con tutti i partecipanti e sarà disponibile anche on-demand.
Finalmente siamo pronti a proclamare il vincitore dell’estrazione della carta regalo Amazon da 200 dollari. Il vincitore è Mike Carter di Advance Auto Parts. Ripeto: Mike Carter di Advance Auto Parts. Ti contatteremo a breve per fornirti ulteriori informazioni e inviarti la tua carta regalo. Detto questo, Augie, grazie ancora per la presentazione. Vorrei ringraziare il pubblico per aver partecipato. Rimanete in contatto con noi. Organizziamo webinar ogni mese, quindi, in attesa del prossimo, grazie e buona giornata.