Quali sono gli svantaggi dell'esecuzione di un database all'interno di una macchina virtuale? Come li supero? [chiuso]

L'esecuzione di qualsiasi cosa all'interno di una macchina virtuale avrà un certo livello di prestazioni, ma quanto influisce davvero sulle prestazioni di un sistema di database?

Ho trovato questo documento di riferimento accademico con alcuni benchmark interessanti, ma è stato un test limitato usando solo Xen e PostgreSQL. La conclusione è stata che l'utilizzo di una macchina virtuale "non ha un costo elevato in termini di prestazioni" (sebbene si possa pensare che i dati effettivi dicano diversamente).

Quali sono gli svantaggi tecnici, amministrativi e di altro tipo associati all'esecuzione di un database all'interno di una macchina virtuale?

Si prega di pubblicare risposte che possono essere supportate da fatti oggettivi, non mi interessano le speculazioni o qualsiasi altro argomento semi-religioso (la passione geek è buona in molti modi, ma non ci aiuterà qui).

Detto ciò,

• Quali problemi si presentano quando si esegue il database in una macchina virtuale? (si prega di inviare riferimenti)
• Questi problemi sono significativi?
  • Sono significativi solo in determinati scenari?
• Quali sono le soluzioni alternative?

Sebbene molti venditori di DB siano stati molto lenti nel fare questo, quasi tutti ora supportano ufficialmente il loro software in esecuzione in un ambiente virtualizzato.

Eseguiamo molte istanze Oracle 11g in linux su ESXi ed è certamente possibile ottenere ottime prestazioni. Come per tutto il ridimensionamento dell'hardware, è sufficiente assicurarsi che l' host di virtualizzazione disponga di molte risorse (RAM, CPU) e che il livello del disco sia in grado di fornire qualsiasi prestazione di I / O richiesta.

Come dice ErikA, questo sta diventando sempre più comune. Sono nel campo di SQL Server e personalmente non ho alcun sistema di produzione in esecuzione nelle macchine virtuali, ma non esiterei (dopo un po 'più di studio sull'argomento). Tuttavia, ci sono sicuramente alcune cose da prendere in considerazione prima di percorrere quel percorso (almeno per SQL Server). Disk IO (come altri hanno già detto) e l'allocazione della memoria sono solo 2 esempi. Le cose saranno diverse anche tra diversi hypervisor.

Brent Ozar è un esperto riconosciuto nella virtualizzazione di SQL Server, in particolare in VMWare. Consiglio vivamente di leggere il suo materiale.

http://www.brentozar.com/community/virtualization-best-practices/

C'è can e poi c'è dovrebbe . Una corvetta può andare a 150 miglia all'ora, ma dovresti sulle autostrade pubbliche? Puoi farti del male inutilmente.

I database sono sistemi operativi guest. In base alla progettazione, quando iniziano, prendono blocchi di una risorsa e la gestiscono direttamente per motivi di prestazioni. Non appena si rende il sistema operativo principale del server di database un ospite nell'ambiente di hosting virtualizzato, si posiziona un livello di arbitrato con l'hypervisor tra l'elemento allocato a blocchi di disco e RAM e il server di database. Rallenterà. Più le tue query sono inefficienti, più rallenterà. Queste inefficienze possono essere mascherate oggi su hardware dedicato, ma non appena introdurrai l'arbitrato alla tua risorsa dipendente, scoprirai molto velocemente.

Ciò che molti contatori di bean che richiedono la virtualizzazione non riescono a riconoscere è che i server di database, come sistemi operativi guest, offrono il proprio livello di consolidamento. Non vi è alcun motivo per cui non sia possibile spostare consolidare più istanze di database logici su un server fisico, anche al punto di spostare indirizzi IP, impostare nomi host aggiuntivi, ecc., Per consentire lo svolgimento di questa coalescenza naturale di servizi. E, con questo modello, non solo si mantengono i risparmi sui costi che la gestione sta spingendo per un numero ridotto di host fisici, ma si mantiene l'accesso al blocco alle risorse fisiche senza l'impingement dell'hypervisor arbitrario, che a volte può prendere decisioni benefiche altri.

Lo stesso vale per altri sistemi operativi guest, come Java. Le soluzioni di virtualizzazione sono in genere ambienti occupati e l'hypervisor deve prendere molte decisioni su chi "ottiene il token" su una risorsa. Ogni volta che puoi eliminare quel livello, starai meglio.

Unisci più istanze utilizzando prima il livello del sistema operativo guest naturale. Probabilmente sarai in grado di raggiungere più facilmente il consolidamento della tua piattaforma e gli obiettivi prestazionali.

Ci sono due cose da realizzare qui:

• L'unità di prestazioni del DB per unità di hardware è leggermente inferiore per un db virtualizzato. Ciò significa che è necessario acquistare un po 'più di hardware per ottenere lo stesso livello di prestazioni.
• Ciò non significa che lo stesso livello o un livello desiderato di prestazioni non siano ottenibili. I vantaggi ottenuti da una migliore gestione e altri vantaggi (come un HA più semplice) sono spesso molto più che compensati dall'aumento marginale dei costi dell'hardware.

Detto questo, dove lavoro la nostra installazione di SQL Server è uno dei due soli server che non ho intenzione di virtualizzare presto (l'altro è il controller di dominio primario).

L'esecuzione di SQL Server è una macchina virtuale, a condizione che sia possibile fornire risorse sufficienti alla macchina virtuale per eseguire l'applicazione. Se nel mondo fisico hai bisogno di 24 core e 256 GB di RAM, devi fornire 24 vCPU e 256 GB di RAM nel mondo virtuale.

Ho appena scritto un articolo nella rivista SQL Server degli ultimi mesi su come eseguire SQL Server con VMware vSphere.

Gestisco due database, uno PostgreSQL e l'altro MySQL, in un ambiente virtuale (Xen) in cui i dom0 sono altamente disponibili. I file system domU si trovano tutti su un LUN SAN iSCSI, creato con volumi logici LVM2. Il database MySQL è esclusivamente per Cacti, quindi non vede molto utilizzo e si trova anche sul LUN iSCSI.

Il database PostgreSQL è il database per il nostro ambiente di staging e pertanto vede un utilizzo maggiore rispetto al db MySQL. Per questo motivo, il database si trova su un set RAID10 locale e DRBD replicato nel secondo nodo del cluster. Tuttavia, in termini di carico reale, questo database di gestione temporanea non vede alcun carico molto elevato. Il che, secondo me, lo rende un candidato buono / eccezionale da virtualizzare.

Alcuni dei vantaggi per la nostra organizzazione sono stati il ​​ridotto consumo energetico, lo spazio su rack risparmiato e il sovraccarico amministrativo dell'hardware.

Il nostro database di produzione principale, d'altra parte, non riesco a immaginare di diventare virtuale ....

Lavoro con server MSSQL e MySQL su numerosi server. Un paio di anni fa ero titubante nell'iniziare la configurazione di server SQL su macchine virtuali perché avevo sentito parlare dei problemi di prestazioni nell'esecuzione di un server SQL su una macchina virtuale. Tuttavia, sono rimasto sorpreso dopo aver configurato i miei primi server SQL coppia e non ho visto alcun cambiamento nelle prestazioni. Sempre più server su cui lavoro sono su VM e quasi tutti i client aziendali più grandi per cui lavoro hanno virtulizzato i server SQL.

Sì, la VM aggiunge alcuni costi generali e se hai intenzione di ospitare più VM su una singola scatola avrai bisogno di un bel server robusto. Un problema comune in termini di risorse a cui prestare attenzione è l'aggiunta di ulteriori macchine virtuali e il diradamento delle risorse disponibili. È prassi comune pianificare un po 'di crescita, ma se hai acquistato il tuo server per ospitare 2 o 3 VM e ora sono in esecuzione 10 VM, probabilmente vedrai un impatto sulle prestazioni.

Mentirei se dicessi che non ho mai visto problemi di prestazioni con un server SQL su una VM. Ma ho imparato che se si riscontrano scarse prestazioni, probabilmente c'è qualcosa che non va nell'ambiente.