SQL e altri database: i pro e i contro della virtualizzazione

Il tema della virtualizzazione è spesso al centro delle discussioni aziendali. E ora, con la virtualizzazione delle applicazioni desktop, dei server e degli storage, le operazioni sui database in macchine virtuali offrono senza dubbio notevoli benefici.

I vantaggi della virtualizzazione

Oltre all'utilizzo ottimale dell’hardware, ai risparmi in termini di energia e a una gestione dei database semplificata, la virtualizzazione fornisce ai sistemi di CRM, ERP o BI "affamati" di risorse ancora più vantaggi.

• Migrazione live: si possono migrare database virtuali da un server fisico ad un altro senza interrompere le operazioni.

• Soluzioni ad alta disponibilità, convenienti e facili da implementare.

• Implementazione flessibile, dinamica e automatizzata di nuove istanze del sistema quando necessario (scalabilità).

• Possibilità di sviluppare rapidamente nuovi database: utilizzando diverse virtual machine con diversi tipi e versioni di database è possibile svolgere sviluppo e test in modo più agile secondo il principio try-and-error. I diversi sistemi possono essere adattati, modificati o cancellati senza alcuna difficoltà, senza correre il rischio, in determinate circostanze, di danneggiare i database.

• Miglioramento della disponibilità: separando tra loro le macchine virtuali il sistema è in grado di continuare a funzionare senza dover sacrificare le performance nel caso in cui si verifichino dei problemi con una VM.

Gli svantaggi della virtualizzazione dei database

Non c’è da meravigliarsi se la virtualizzazione dei database sia in costante crescita. Nonostante tutti questi vantaggi, però, questo processo potrebbe nascondere degli svantaggi se venisse effettuato in maniera troppo veloce e senza una sufficiente pianificazione.

Si potrebbero quindi verificare dei problemi relativi a diversi aspetti.

• Virtualizzazione con componenti hardware sottodimensionati: i database generalmente richiedono l’impiego di molte risorse, sia nel sistema “reale” sia in quello virtuale. I database virtualizzati che si basano su Microsoft SQL Server, così come quelli che utilizzano Oracle o simili necessitano - proprio come i database “reali” - di processori potenti e di spazi di memoria molto grandi, in modo che i dati possano essere velocemente processati dal sistema. Se questi requisiti non sono forniti dalla virtual machine, è possibile un peggioramento delle performance.

• Licenze: in alcuni casi, come per i database Oracle più vecchi, non è possibile trasferire 1:1 le licenze alle macchine virtuali. Prima di effettuare lo spostamento dei database dalla macchina fisica alle macchine virtuali è necessario considerare quante istanze e quanti processori sono attualmente in uso per comparare i costi delle licenze del server fisico esistente con quelli della sua controparte virtuale.

• Mancanza o non sufficiente competenza dello staff: i database, per loro stessa natura, sono complessi e questo aspetto non è cambiato nemmeno con la virtualizzazione. Questa nuova tecnologia introduce un ulteriore livello di complessità di cui gli amministratori (DBA) devono tenere conto nella gestione dei database. Se all’interno della società non c’è alcuna distinzione tra gli amministratori che si occupano di virtualizzazione e i DBA, allora l’amministratore dovrà acquisire una profonda conoscenza dei database in ambienti virtualizzati oltre al suo “normale” know-how.

• Scarsa collaborazione tra gli amministratori IT e i DBA: molti amministratori di database non hanno un reale accesso a quelli che sono gli aspetti più specifici della virtualizzazione, dato che questi verranno gestiti dagli amministratori IT. Quando si verifica un problema con un database virtuale causato da un’anomalia nella VM o nel sistema virtuale, spesso si possono verificare ritardi nella risoluzione del problema.

Come evitare problemi con i database virtuali

Sono diverse le motivazioni che possono causare la perdita di database virtuali, esse riguardano principalmente:

• volumi riformattati di Datastore VMware

• volumi danneggiati di Datastore VMFS

• file sytem della macchina guest danneggiato

• file virtuali corrotti (VMDK/VHD)

• file system accidentalmente cancellati (VMDK/VHD)

Ciò mette in evidenza come i malfunzionamenti o la scomparsa dei dati virtuali o dei database virtualizzati non siano causati esclusivamente da un guasto hardware ma anche, in molti casi, dall’errore umano.

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 una 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.