Parla l`EMC Chief Oracle Architect

TRASFORMAZIONE DEL BACKUP
DALL'INTERNO
Intervista al Chief Oracle Architect di EMC
Che cos'è la trasformazione del backup e perché è tanto cruciale per l'integrità
e il benessere di un'organizzazione? In questa intervista Darryl Smith, Chief Oracle
Architect di EMC ed esperto delle tematiche riguardanti il backup, offre la visione
di un addetto ai lavori sull'esigenza di trasformare il backup e sul suo impatto
all'interno di EMC IT e sul nostro business.
Responsabile di tutti i database di EMC, principalmente Oracle ma anche SQL Server,
MySQL, Postgres e Greenplum, Smith descrive le persone e i cambiamenti di processo
intrapresi in EMC IT e gli effetti rivoluzionari che hanno prodotto. Accenna inoltre alle
"Se l'infrastruttura di backup non riesce
a tenere il passo con l'esplosione dei dati
o a eguagliare la mobility del cloud
computing, il database ne risentirà...
Per questo è fondamentale accertarsi
che l'infrastruttura di backup sia molto
più agile e dinamicamente scalabile di
quanto lo sia oggi". – Darryl Smith
attività future e offre il suo punto di vista sulla condizione ideale di backup. Per
ulteriori informazioni e risorse, visitare http://italy.emc.com.com/BackupLeader
COME ORACLE ARCHITECT PERCHÉ
IL BACKUP È IMPORTANTE PER GARANTIRE
LA SICUREZZA?
Ho la responsabilità di garantire che i database di EMC siano integri, funzionino
correttamente e siano in grado di fornire agli utenti di business le informazioni
necessarie. Se io o il mio team non veniamo in ufficio, tutto si ferma. Se il database
che supporta l'applicazione CRM o l'applicazione di Customer Support o qualunque
applicazione si stia eseguendo non è in funzione, neanche l'applicazione funziona.
E per il mio lavoro, il backup rappresenta un fattore cruciale. Una delle principali
difficoltà riscontrate quando abbiamo intrapreso il viaggio verso il cloud era che
la nostra infrastruttura di backup non riusciva a far fronte alla crescita in atto.
Ci affidavamo a infrastrutture legacy e a soluzioni di backup point-to-point, una
minaccia per la nostra tranquillità e per quella di molte organizzazioni oggigiorno.
PERCIÒ LA TRASFORMAZIONE DEL BACKUP
ASSUME UN RUOLO IMPORTANTE?
Sì, è un passaggio obbligato. Non si può continuare a eseguire backup nel modo in
cui si è sempre fatto in passato, perché con l'approccio tradizionale non si cresce e
tale approccio non è compatibile con le infrastrutture cloud virtualizzate. Il motivo è
che tutte le applicazioni, dai semplici sistemi di pianificazione delle sale conferenza alle
applicazioni di tipo Customer Support o ERP mission-critical, ruotano attorno ai dati.
Perciò, è fondamentale che i dati vengano protetti e questo non è possibile senza la
trasformazione del backup.
CIÒ PUÒ INFLUIRE SUGLI SFORZI VERSO
LA VIRTUALIZZAZIONE E IL CLOUD?
Esatto. Se l'infrastruttura di backup non riesce a tenere il passo con l'esplosione
dei dati o a eguagliare la mobility del cloud computing, il database ne risentirà.
E ciò può significare qualsiasi cosa, da una diminuzione delle prestazioni
dell'applicazione alla perdita dei dati o a un errore dell'intera applicazione,
che ovviamente può avere conseguenze critiche per il business. Per questo
è fondamentale accertarsi che l'infrastruttura di backup sia molto più agile
FOGLIO INFORMATIVO
e dinamicamente scalabile di quanto lo sia oggi.
CHE COSA È STATO FATTO NEGLI ULTIMI
DUE ANNI PER TRASFORMARE IL BACKUP?
Al momento abbiamo realizzato una virtualizzazione del 94% dal punto di vista dei
server e di circa l'84% per quanto riguarda i database e ormai stiamo completando
la virtualizzazione il più velocemente possibile. Ciò ha grosse implicazioni per
il backup.
All'inizio abbiamo utilizzato metodologie di backup tradizionali. Effettuavamo il backup
utilizzando un tradizionale sistema RMAN per la nostra utility di pianificazione dei
backup, EMC NetWorker, e impiegavamo dispositivi a nastro o dispositivi da disco a
nastro virtuale supportati da disco. I nastri sono ovviamente una tecnologia obsoleta
per cui li abbiamo sostituiti con dispositivi VTL. Tuttavia anche le VTL non costituivano
una soluzione scale-out per cui eravamo costantemente impegnati a misurare,
quantificare e limitare l'uso delle risorse.
Il nucleo del problema era proprio questo: disponevamo di un numero limitato di
risorse, un numero crescente di database e una quantità crescente di dati di cui
era necessario eseguire il backup. Per tenere il passo con la virtualizzazione,
abbiamo praticamente smontato le nostre piattaforme legacy. Anche gli storage
node di EMC NetWorker sono stati virtualizzati.
A CHE PUNTO È GIUNTA LA TRASFORMAZIONE
DEL BACKUP?
Nel giro di 24 mesi stiamo passando a un'infrastruttura scale-out. Abbiamo
abbandonato i dispositivi a nastro e stiamo sostituendo quelli a nastro virtuale con
appliance Data Domain, che possiedono capacità e throughput molto più elevati
e consentono di effettuare lo store dei dati per periodi di tempo molto più lunghi
grazie alla funzionalità di deduplica. Con questo primo passaggio siamo riusciti
a ridurre notevolmente le restrizioni di capacità. Ora sappiamo che, in caso di
necessità, possiamo eseguire il restore dei backup abbastanza velocemente, senza
bisogno di fare affidamento su nastri e storage fuori sede. La gestione del backup
presenta però ancora alcune restrizioni e necessita quindi di ulteriori miglioramenti.
Abbiamo inoltre eseguito attività di Database-as-a-Service in cui siamo riusciti ad
automatizzare completamente il backup e il ripristino per un funzionamento
autonomo. In passato, quando non c'era la proliferazione dei Big Data e il mobile
computing, potevamo configurare i backup e quasi dimenticarcene senza problemi.
Ora la vita è molto più complicata ma, essendo riusciti ad automatizzare i backup
e a creare uno script, non dobbiamo più preoccuparci della loro esecuzione perché
abbiamo rimosso le variabili.
Stiamo facendo lo stesso con alcuni database molto grandi. In collaborazione con i
team di backup, abbiamo progettato un backup con offload, ovvero creiamo un clone
dello storage, ne effettuiamo il mount su un proxy server o su uno storage node di
EMC NetWorker e da lì eseguiamo il backup del database. In questo modo il database
di backup o il proxy server è connesso direttamente all'appliance Data Domain senza
limiti delle risorse. Le operazioni di backup adesso vengono eseguite alla perfezione
e molto velocemente.
Questi sono solo due esempi di quanto stiamo realizzando con il team di backup per
offrire una soluzione di backup affidabile e scalabile, che non necessiti interventi una
volta configurata.
SEMBRA CHE STIATE LAVORANDO IN
MANIERA DIVERSA CON IL TEAM DI BACKUP.
COME SONO CAMBIATI I PROCESSI?
La sostituzione dell'infrastruttura è solo il punto di partenza per trasformare
il funzionamento dell'infrastruttura di backup. Abbiamo veramente bisogno di
migliorare il processo e le procedure. Un'utility di pianificazione di livello enterprise
è sicuramente conveniente. Ma la gestione manuale di singoli componenti e risorse
ostacola lo scale-out dinamico e non assicura l'agilità richiesta dal cloud computing.
In realtà, la chiave dell'intera trasformazione consiste nel fondere tutti questi gruppi,
membri e competenze individuali in un set di competenze più grande. Quando parliamo
dell'IT transformation, parliamo sempre della necessità di riunire le competenze.
Il che non significa necessariamente che una persona deve sapere tutto, bensì che
le persone con set di competenze diversi devono lavorare a stretto contatto per
entrare a far parte del team dell'architettura core e, nello stesso tempo, che le
conoscenze vengono condivise.
COME SONO CAMBIATI I RAPPORTI CON
IL TEAM DI BACKUP?
I rapporti stavano diventando tesi. Avevamo diverse difficoltà con i backup e i team
preposti dovevano intervenire continuamente per risolvere i problemi. La tensione
si avvertiva su entrambi i lati: sia il team di backup che i DBA erano estremamente
frustrati di dover gestire quotidianamente problemi e intervenire costantemente
per risolverli. Si trattava di una criticità costante che, oltre a rendere tesi i rapporti,
inficiava la capacità di offrire assistenza agli utenti di business.
Il team di backup opera in genere dietro le quinte: non se ne sente parlare e non
fa parte del servizio IT in senso lato né del processo decisionale. Esegue soltanto i
backup. Questo tipo di pensiero o cultura, tuttavia, non risponde più alle esigenze di
oggi. Il team di backup deve trasformarsi in una componente del team IT più grande
e contribuire alla trasformazione generale dell'IT. In caso contrario, si verificheranno
problemi. I database non funzioneranno come dovrebbero e si bloccheranno quando
si cercherà di cancellare i backup. In caso di guasto, non sarà possibile ripristinare il
sistema o i dati. È più che mai necessario integrare il backup a livello mainstream.
QUAL È IL FUTURO? QUANDO ARRIVERETE
ALLA CONDIZIONE DI BACKUP IDEALE?
Oggi non abbiamo ancora realizzato completamente il Backup-as-a-Service, ma lo
utilizziamo in forma limitata. Le nostre offerte di IT-as-a-Service, Infrastructure-as-aService e Database-as-a-Service utilizzano tutte backup completamente automatizzati
e forniti come servizio.
Alla fine del processo o come obiettivo di trasformazione della nostra infrastruttura
di backup, ci proponiamo di rendere i Backup Administrator responsabili
dell'infrastruttura e del capacity planning in modo da garantire che sia disponibile
capacità sufficiente. Quanto a me, come consumatore e come DBA che utilizza
i servizi di backup, devo potere configurare i miei backup, eseguirli in qualsiasi
momento ed effettuare i restore in base alle esigenze, senza bisogno di ricorrere
a un altro gruppo per verificare il funzionamento di qualcosa. Pertanto, la mia
condizione ideale è in pratica l'esecuzione di una console in cui posso pianificare
i backup di tutti i miei database senza preoccuparmi di non disporre di
sufficiente capacità.
È come l'alimentazione. Quando accendo le luci, mi aspetto che si illuminino
perché fornisco loro l'alimentazione necessaria. Vorrei che i miei backup fossero
altrettanto semplici.
QUALI TECNOLOGIE EMC STATE UTILIZZANDO?
IN CHE MODO HANNO MODIFICATO L'INTERO
PROCESSO?
Una delle nostre prime iniziative ha riguardato l'acquisto dei sistemi EMC Data
Domain, prima che EMC acquistasse la società. Li abbiamo scelti per la funzionalità
di deduplica. Naturalmente disponevamo già di Avamar, che offre una funzionalità
di deduplica abbastanza efficace. Avamar è fantastico per il backup dei sistemi
operativi e dei desktop ed è stato utilizzato massicciamente in questo senso.
Per quanto riguarda i database, però, avevamo bisogno di un sistema con capacità
molto più elevata e perciò abbiamo optato per Data Domain.
Abbiamo sempre utilizzato NetWorker, che semplifica notevolmente i backup. I DBA
erano abituati a utilizzare RMAN per eseguire i backup, ma RMAN doveva scrivere
su un dispositivo a nastro. I sistemi operativi generalmente non dispongono di
dispositivi a nastro integrati, per cui NetWorker funge da dispositivo a nastro virtuale
per i backup RMAN, integrandosi completamente nel nostro sistema. È sufficiente
che il DBA lo avvii e NetWorker, tramite gli storage node, effettua il backup, nel
nostro caso, nel dispositivo Data Domain. Questa integrazione è molto importante.
Una delle tecnologie più recenti che abbiamo preso in esame è DD Boost di
Data Domain, che si integra perfettamente con RMAN. Il DBA può dunque utilizzare
i backup dei tradizionali sistemi RMAN e sfruttare i vantaggi di un prodotto come
DD Boost, senza tuttavia conoscerlo, ma avendo il controllo totale su di esso.
Un altro motivo per cui siamo particolarmente concentrati sull'implementazione di
DD Boost è che questo consente di eseguire i backup con una quantità minore di
risorse, in quanto la deduplica del backup viene trasferita in gran parte sullo stesso
database server ed è così possibile trasmettere un numero molto inferiore di dati in
rete. In questo modo sono in grado di eseguire più backup contemporaneamente,
a prescindere se si tratti di database o di sistemi operativi. Ma soprattutto i miei
backup possono arrivare un po' più lontano. Per cui ora dispongo di un'infrastruttura
adeguata alla mobility del cloud computing.
Stiamo inoltre utilizzando appliance Data Domain per eseguire direttamente i backup.
Con prodotti come VMware Data Director possiamo configurare alcuni datastore
come mount NFS di Data Domain, creare cloni di storage e scriverli direttamente
nell'appliance Data Domain. E possiamo fare lo stesso con strumenti come Export
o Data Pump di Oracle oppure con backup manuali. In SQL Server a volte eseguiamo
backup manuali di file system direttamente in Data Domain.
EMC2, EMC e il logo EMC sono marchi o marchi registrati di EMC Corporation negli Stati Uniti e in altri
paesi. VMware è un marchio o marchio registrato di VMware, Inc. negli Stati Uniti e in altre giurisdizioni.
© Copyright 2012 EMC Corporation. Tutti i diritti riservati. 11/12 Foglio informativo H11297.
http://italy.emc.com/
EMC ritiene che le informazioni contenute in questo documento siano accurate al momento
della sua data di pubblicazione. Le informazioni sono soggette a modifica senza preavviso.