SQL e altri database: i pro e i contro della virtualizzazione - Parte 2

Nella prima parte di questo articolo sulla virtualizzazione dei database vi abbiamo mostrato i vantaggi e gli svantaggi dell’utilizzo di questa tecnologia. In questa seconda parte vorremmo rispondere a queste domande:

• È meglio utilizzare o non utilizzare la virtualizzazione?
• Che cosa è bene considerare?

Ma soprattutto:

• Cosa potrebbe succedere nel caso in cui un database virtuale dovesse scomparire?

Il caso reale seguente, risolto dal nostro laboratorio di recupero dati, vi mostrerà le possibili conseguenze.

Recupero di database virtuali “spariti”: un esempio pratico

Un istituto finanziario senza database

Il caso di una banca operativa a livello internazionale mostra come il processo di virtualizzazione dei database spesso non si verifichi senza ostacoli e come tali ostacoli possano portare, in caso di malfunzionamento, a dover effettuare un restore dei dati molto complesso.

L’istituto aveva perso i database contenenti i dati dei clienti e delle transazioni. La causa: dopo un normale servizio di manutenzione, un server VMware ESX composto da 3 LUN (Logical Unit Numbers) rifiutava tutti i servizi e non riusciva più ad avviarsi. Persino il sistema di emergenza in cluster non funzionava perché il link di replicazione non era stato precedentemente disconnesso.

L’intervento di recupero effettuato dagli specialisti di data recovery di Ontrack si è dimostrato molto più complesso di quanto immaginabile. Il file system VMFS del server era seriamente danneggiato e doveva essere ricostruito in più passaggi. Solo dopo aver effettuato questa operazione i database SQL affetti dal problema sono stati copiati ed è stato così possibile creare un nuovo database funzionante per i dati dei clienti e delle transazioni.

Virtualizzazione dei database: quando farla

È una falsa credenza che si possano gestire volumi di dati sempre maggiori ricorrendo semplicemente alla virtualizzazione dei database.

È perciò sconsigliabile virtualizzare i database che funzionano su un hardware fisico quasi al massimo della sua capacità.

Prima di procedere con la virtualizzazione bisognerebbe quindi analizzare il comportamento di carico giornaliero e basarsi sui risultati ottenuti per capire le risorse hardware necessarie. Solo in questo modo ci si può assicurare che quando verrà effettuato un consolidamento del server e del database non si assista a un drastico calo nelle prestazioni in seguito al non aver investito adeguatamente nelle risorse necessarie.

La scelta di implementare un processo di virtualizzazione dipende inoltre, in larga parte, anche dal modo in cui i database vengono utilizzati.

Il database server, indipendentemente che si tratti di SQL o di Oracle, a volte viene realmente utilizzato solo fino ad un certa soglia.

Se viene segnalato un 30% di impiego delle risorse è un parametro di riferimento che si applica a un database server sul quale girano poche istanze di SQL o di altro database.

Ad ogni modo, quando si tratta di database di business intelligence, di data mining, di transazioni online o di ERP o CRM, la questione è ben diversa. In questo caso è possibile che l’hardware esistente del database server sia già al pieno utilizzo – processori, hard disk, SSD, etc.

Chi pensa di poter creare risorse dal nulla, soltanto virtualizzando i suoi database, si sbaglia di grosso anche se con la virtualizzazione di un database, l'hardware esistente può essere utilizzato in maniera più efficace.

Chi non comprende questo semplice aspetto non solo rischia che i database business-critical scompaiano ma mette a rischio l'intera azienda: proprio in virtù della loro fondamentale importanza a un database devono sempre essere assicurate disponibilità, scalabilità e velocità.

Database virtuali: l’importanza di un servizio di recupero dati

Se qualcosa dovesse andare storto, solo poche aziende saranno in grado di recuperare i loro server virtuali e i loro database virtualizzati autonomamente.

Diventa quindi ancora più importante munirsi di un piano di emergenza dettagliato e pronto all’uso in ogni momento, da applicare in casi estremi come questi.

Poichè molti dei malfunzionamenti del sistema e delle situazioni di perdita di dati sono difficili da gestire e risolvere dai dipendenti stessi, è consigliabile assicurarsi di includere un servizio specializzato di recupero dati durante la stesura del piano di emergenza.

Rivolgersi ad aziende specializzate nel recupero dati come Ontrack, che ha risolto casi molto complessi in cui non erano più presenti database virtuali, è il modo più sicuro per ripristinare i dati e garantire il corretto funzionamento dei database.