Este post también está disponible en Español
Uno dei casi di utilizzo più interessanti di XtremIO è quello relativo al cost saving nel mondo dei DB.
Analizziamo brevemente la situazione attuale: in molti degli ambienti IT di oggi, con storage “tradizionali”, i database non possono operare in piena efficienza e offrire il rapporto costi/prestazioni che i clienti richiedono. I requisiti di cui i DB oggi hanno bisogno sono: una bassa latenza, elevate performance e throughput adeguato. Avere un ambiente a bassa latenza diventa estremamente vantaggioso quando è combinato con altre importanti funzionalità evolute.
In questo breve post, verranno analizzati degli aspetti quali cloning, facilità di utilizzo e licencing e il loro significato per il cost saving nel modo dei DB.
Prima di iniziare vogliamo introdurre un paio di concetti utili per capire meglio alcuni ragionamenti presenti nel documento; “service time” & “wall-clock-time”.
“Service time”: quando un processo (DB) deve aspettare per interagire con lo storage, il “wall-clock-time” viene sprecato, ciò significa perdita di denaro e di tempo che non può essere recuperato.
Il “wall-clock-time” fa riferimento al tempo effettivo necessario ad un host per completare un determinato compito. È la somma di tre termini, tempo di CPU, tempo diI/O più il ritardo di comunicazione sul canale (ad esempio, se i dati sono sparsi su più macchine). A differenza del tempo di CPU, che misura solo il tempo durante il quale il processore sta lavorando attivamente su un certo compito, il “wall-clock-time” misura il tempo totale per il completamento del processo.
La differenza tra i due consiste nel tempo trascorso a causa di ritardi programmati o in attesa di risorse che devono diventare disponibili, nel nostro caso, la componente storage.
Cloning / snaps: Una pratica normale nel mondo dei database è che spesso ci sono molte copie del medesimo ambiente. Vengono normalmente richieste copie per la produzione con lo scopo di effettuare dei back-up, così come copie per ambienti di test e sviluppo. In XtremIO la magia del “in-line data reduction” (deduplica) combinata con una tecnica unica che permette di fare copie del DB senza consumare spazio flash, è un aspetto fondamentale per quando riguarda il risparmio dei costi. Supportare simultaneamente ambienti di produzione, test & development è con XtremIO molto più semplice di quanto sia mai stato finora.
È possibile copiare (clone) un database ad una velocità impressionante perché i realtà vengono copiati solo i metadati (riferimenti ai blocchi sullo storage) contenuti in memoria.
È importante sottolineare che fare copie del DB di produzione per altri usi non è costoso con la tecnologia XtremIO. Oggi molti clienti sono costretti ad acquistare un altro storage dove installare gli ambienti del DB per test e sviluppo. Questo approccio implica di dover inserire anche in questi ambienti server e licenze DB. La tecnologia snap di XtremIO combinata con la deduplicazione in linea significa che i clienti possono ora utilizzare le copie istantanee (snap) per tutti i DB (produzione, test, sviluppo) rimanendo sullo stesso dispositivo di storage risparmiando nell’acquisto di un altro storage più ulteriori server / CPU / licenze db.
Facilità di utilizzo: Gli array XtremIO sono intrinsecamente ottimizzati per dare il massimo delle prestazioni senza bisogno di alcun tuning specifico. Basta mappare le LUN agli host per ottenere la migliore performance che l’array ha da offrire sfruttando in modo uniforme tutti i controller su tutti i dischi flash. Eliminando la complessità di configurazione e messa a punto (tuning) presenti nei DB storage, i sistemi XtremIO offrono una messa in esercizio (rollout) molto più semplice permettendo di affrontare futuri cambiamenti del carico di lavoro. Se il numero di utenti aumenta oppure se la modalità di accesso cambia con il tempo, XtremIO continuerà a fornire prestazioni elevate, senza alcun intervento da parte dell’amministratore. Questa facilità di installazione e gestione è davvero un aspetto molto importante da considerare nel risparmio sui costi.
In uno storage ibrido (dischi FC e dischi flash) non tutti i dati sono sui flash, quindi nel momento in cui si accede ai dati memorizzati sui dischi FC si hanno dei tempi di risposta nell’ordine dei millisecondi. Nel caso in cui si disponga di un sistema XtremIO è possibile garantire tempi di risposta nell’ordine dei microsecondi per qualsiasi tipo di accesso.
Negli ambienti tradizionali, il provisioninig di un DB richiede una attenta pianificazione del posizionamento delle LUN. Bisogna considerare le LUN per i dati, le LUN per i log, le LUN per l’area temporanea e così via. L’elevata bandwith e la bassa latenza di XtremIO rendono il posizionamento delle LUN indipendente dalle caratteristiche di I/O, semplificando quindi in modo radicale l’attività di provisioning che può avvenire in tre semplici passaggi.
Tutti i DB hanno presentano un diverso mix di operazioni di I/O: nei DB di tipo OLTP sono di norma presenti letture/scritture con blocchi piccoli, mentre nei DB di tipo DWH o Analytics si osservano letture/scritture sequenziali che utilizzano blocchi di I/O più grandi. Queste caratteristiche di workload comportano per gli amministratori del sistema uno studio dettagliato di quale tipologia di LUN utilizzare per ogni oggetto del DB. Una volta fatta questa attività, spesso si scopre che il comportamento del DB cambia con il tempo. Queste ragioni portano frequentemente ad una distribuzione non corretta dei dati.
Inoltre, è realmente difficile individuare workloads che siano puramente OLTP. Per esempio, per quasi tutti gli ambienti OLTP esiste l’esigenza di fare reporting, attività con profilo di carico più orientato all’analisi che alla transazione.
Consideriamo un dispositivo dalle performance predicibili e costanti come XtremIO, con una bassa latenza ed elevata larghezza di banda, in grado di eseguire diversi tipi di carico di lavoro, OLTP oppure DWH: con questo tipo di back-end sarà sufficiente effettuare il deployment senza i vincoli imposti dalle caratteristiche di I/O.
Ora pensiamo a cosa potrebbe succedere se il DB, o le applicazioni che girano su di esso, diventasse mission critical e il numero di accessi / utenti aumentasse di conseguenza. Il size iniziale prevedeva un certo numero di accessi su una certa capacità per garantire delle performance adeguate. Ora l’elevato numero di utenti diventa un collo di bottiglia per la applicazione ed è necessario rivedere l’architettura.
Negli array tradizionali, questo scenario ha due aspetti da considerare:
- a volte i dati possono essere molto sparsi (distribuiti su diversi punti del back-end)
- i dati possono essere molto densi (concentrati cioè su poche aree del back-end).
Nel primo caso, ci saranno dei lunghi “seek-time” sui dischi, mentre nel secondo caso, si creeranno degli hot-spot.
XtremIO è immune a tali problematiche in quanto ha un’architettura che si basa sulla conoscenza dei contenuti (“content awareness”) e per questo motivo i dati vengono memorizzati e distribuiti sull’array in modo simmetrico e bilanciato. Non è avere dei dischi flash nella architettura, ma avere XtremIO che rende questo possibile.
Esaminiamo nella parte finale di questa discussione sul come risparmiare sui costi dei DB; il licensing, forse l’aspetto più significativo da considerare.
XtremIO può effettivamente aiutare ad abbassare i costi di licenza dei database. Il modo in cui XtremIO può farlo è attraverso le sue straordinarie performance. Quando si utilizza uno storage convenzionale e si hanno delle latenze molto superiori a confronto con XtemIO, i DB server sono spesso in attesa di risposte dallo storage e questo tempo di attesa non è un tempo produttivo. In questi casi è quindi necessario avere un elevato numero di CPU e core per compensare tale tempo di inattività.
Con XtremIO il tempo di risposta è talmente veloce che le CPU non rimangono mai in attesa e il tempo di inattività della CPU scende notevolmente. Questo significa che si può fare la stessa quantità di lavoro con un minor numero di core.
Molte aziende licenziano i loro DB in base a su quanti core il software è in esecuzione. Con XtremIO è possibile avere un minor numero di core per svolgere lo stesso lavoro di un array convenzionale risparmiando in questo modo licenze DB.
E’ sempre importante ricordare che nel campo della bassa latenza di calcolo, i cicli di elaborazione host sono una risorsa che dobbiamo tenere sotto controllo. Utilizzando cicli di CPU host per esempio per estrarre i dati e alimentare o creare le copie di test & sviluppo significa un costo. Le licenze DB dovrebbero essere utilizzate per i soli compiti transazionali e non per estrarre i dati. Questo è un improprio utilizzo del DB software.
Avere delle CPU inattive non migliora le prestazioni ed è uno spreco di soldi.
Per concludere: con XtremIO, senza nessun particolare “tuning” al DB è possibile trasformare completamente gli ambienti dei database, sia dal punto di vista delle prestazioni e semplicità di utilizzo, come dal punto di vista dei costi.
Per ulteriori informazioni:
Database Storage. XtremIO All Flash Array
