Eh sì, decisamente. Per chi di voi sia ancora rimasto legato alla vecchia versione di ESX, magari perchè vuol continuare a fare i backup della versione free, sappia che dopo mesi di tribolazioni e tentativi, io ci ho rinunciato. Se volete creare un server che fa parecchio I/O su disco, evitate l’accoppiata ESX 3.5 e Windows 2008. Punto.
Non ho ancora capito bene il vero motivo, VMWare da la colpa al Context Switching di microsoft (alzi la mano chi si voleva suicidare a vedere Windows Vista impiegare ore per copiare un file di qualche giga…), Microsoft nega, fatto sta che alla fine VMWare è riuscita a mettere le cose a posto con ESX 4.0; e ad oggi su ESX 3.5 Windows 2003 è di molto più veloce di Windows 2008.
Voglio approfittare di questo post anche per invitarvi a non ragionare come il cliente che ha sollevato questo problema: fintanto che continuate a pensare come nel mondo fisico prenderete delle cantonate pazzesche. Sono arrivato da lui a inizio pomeriggio e dopo 10 minuti gli ho dato la risposta. Un consulente Microsoft ragionando in modo classico stava elucubrando da due giorni su deframmentazioni, indicizzazione files, drivers, formati raid della san, raw mappings… Tutto inutile, il problema è quello che vi ho detto prima.
Quindi, se volete la risposta dolente come il mio cliente, tipo chirurgo dopo la sala operatoria, o aggiornate a ESX 4, o mettete Windows 2003, o fate una macchina fisica.
Ciao, pare che il kernel di 2008 R2 faccia un utilizzo molto piu’ spinto dei thread, possibile che l’aggiunta di una VCPU migliori le cose ?
Ciao, pare che con R2 qualche problema sia stato risolto. Dovrei e vorrei fare delle prove per verificare se il miglioramento è stato significativo. Alla fine, file services esclusi, in larga parte le prestazioni dipenderanno dall’applicativo coinvolto: sql e esxchange scalano molto bene sui multi processori, anche virtualizzati. Per altri ambienti bisognerà fare delle prove o affidarsi a documenti tecnici di altri che già hanno provato.