Ciao a tutti,
sempre in via di implementazione di un nuovo server, mi è sorto un grosso dubbio circa l' utilità di un doppio processore.
La macchina che ospiterà i due processori sarà l' host esxi 5.1 sul quale verranno create 6 VM.
Ora il dubbio è il seguente:
partendo dal presupposto che non tutte le applicazioni sono create per un utilizzo a doppio processore
e che le VM di Esxi 5.1,nonostante l' assegnate vCPU, quello che vedono è il processore reale....
è giusto pensare all' acquisto di un server con CPU di questo tipo se poi le applicazioni non sono in grado di sfruttarla ?
Ci sono funzionalità di Esxi che intervengono in tal senso ?
Grazie a tutti,
e con l' occasione... tanti Auguri !
In realtà se un'applicazione è scritta per usare un solo processore non hai tanto spazio di manovra a livello di vHardware... osserverai in ogni caso l'utilizzo di una vCPU.
In ogni caso vale la regola aurea di VMware: assegna il minor numero di vCPU possibile (partendo da 1 ovviamente) ed aumenta le risorse della VM in virtù di reali necessità.
Ciao!
--
Rocco Sicilia
ciao, buona parte dei processori moderni da server hanno almeno 6 core. Se valga la pena di avere il doppio processore dipende dal livello di consolidamento, ovvero da quante VM (e con che carichi) ci gireranno sopra.
Per esempio sto per comprare un server da dedicare quasi esclusivamente a una VM: siccome l'attuale VM ha 4 vCPU, avere la seconda CPU (fisica) non mi serve, oltretutto mi costerebbe una licenza in più di vSphere. Quindi non la prendo ![]()
E' chiaro che in caso di guasto della CPU il server intero si ferma.
Le applicazioni di oggi dovrebbero essere multi-thread piuttosto che multi processo.
E comunque anche l'archittettura multi-core è un caso di multi-processo SMP.
Anzi... l'architettura multiprocessore di oggi è molto diversa da quella di un tempo (oggi è di tipo NUMA, prima solo di tipo UMA) e quindi un'appliacazione moltiprocesso con un sistema operativo datato potrebbe persino comportarsi male (nel fisico). Nel virtuale ci pensa l'hypervisor (ove possibile).
Morale... a parte alcuni aspetti secondari (cache, accesso alla memoria, ...) non c'è grossa differenza tra multi-core e multi-processore...
Ho banalizzato volutamente alcuni concetti, ma giusto per rendere l'idea.
In albiente virtuale, in effetti, tra 2 CPU Dual Core e 1 CPE Quad Core non vi è tanta differenza visto che ci pensano gli hypervisor a distribuire le richieste sulle vCPU.
Ma non è da sottovalutare la questione "fault": avere due CPU ti consente di non subire un disservizio prolungato in caso una delle due si guasti.
--
Rocco Sicilia
intanto grazie per le risposte ed auguri !
non vi è tanta differenza visto che ci pensano gli hypervisor a distribuire le richieste sulle vCPU.
questo conferma quello cercavo di capire....
il fatto che ci siano 1 o 2 processori non interessa l' applicazione finale sulla VM, in quanto l' hypervisor a monte assegna le risorse gia "mascherate".
Parlando dal lato pratico
per assegnare le VCPU posso tranquillamente giocare sul prodotto tra il numero delle vitual socket e i numeri di cores senza farmi tanti scrupoli
oppure
se un' applicazione non assicura il multi-thread o il multi processo DEVO settare un core unico ?
In realtà se un'applicazione è scritta per usare un solo processore non hai tanto spazio di manovra a livello di vHardware... osserverai in ogni caso l'utilizzo di una vCPU.
In ogni caso vale la regola aurea di VMware: assegna il minor numero di vCPU possibile (partendo da 1 ovviamente) ed aumenta le risorse della VM in virtù di reali necessità.
Ciao!
--
Rocco Sicilia
Scusami vale a dire che un' applicazione non multithread al massimo puo utilizzare 1 sola vCPU quando magari alla VM vengono assegnate 3 vCPU ?
Se si, come mi rendo conto se 1 vCPU puo bastare ? ( senza sbatterci le corna
)
grazie
In realtà il discorso è un po' più complesso ![]()
Esistono ancora, anche se sempre meno usate, applicazioni puramente "sequential" che non sono in grado di utilizzare più core. In questo caso potresti trovarti nella situazione non non poter migliorare le prestazioni di quell'applicazione se non utilizzando CPU più motenti in quanto mettere più CPU non sarebbe d'aiuto.
Oggi nessuno più sviluppa senza tener conto del Multi-threadeding, quindi una cosa simile potrebbe accadare solo con software "ereditato" da situazioni passate. Spero non sia il tuo caso ![]()
Prevedere cose ti servirà è arduo, di solito ci si basa su tabelle fornite da chi ha sviluppato il software o da test di performance.
--
Rocco Sicilia
Non è completamente vero, esistono anche oggi applicazioni che sono single-thread, in tema VMware l'esempio classico è il SQL Express utilizzato come database di default per vCenter…
L'unico modo per sapere per certo se un applicativo è multi-thread è per prima cosa richiedere informazioni a chi l'ha sviluppato.
Luca.
Oppure analizzare come si comporta aggiungendo core e/o CPU.
Ad esempio con i tool di sysinternals.
Vero, SQL Express è single-thread ma, come spesso avviene in questi casi, ha più scheduler che gli permettono di utilizzare più core... in consizioni ottimali e quando tutto va bene
Quindi non la metterei tra le applicazioni puramente "sequential" a cui mi riferivo.
Ciao!
--
Rocco Sicilia
ok,
allora nel caso di SQL Express,
se dovesse gestire un DB enorme con grossa attività di calcolo, dovrei avere un processore allucinante visto che l' applicazione può sfruttare una sola Vcpu..... Possibile che VMware non abbia superato questo limite ?
Dovrò avere a breve un Server con 2 CPU Xeon e5-2630 e una situazione analoga.... Pensavo di essere ben coperto sul piano delle performance e invece.... che amarezza.
Bhe, credo che tutto concordino della necessità di valutare l'applicazione giusta per lo scopo
Se devi crescere molto devi tener conto che la scalabilità verticale ha dei vincoli tecnologici.
In ogni caso la virtualizzazione di VMware oggi non è un sistema di "grid computing" dove le CPU possono essere viste come un'unica entità.
Ma non disperare... prima accertati della situazione ![]()
Ciao!
--
Rocco Sicilia
Nel caso di SQL Express NON puoi gestire un DB grosso.
Ha anche dei limiti sulla max dimensione dei file.
Per fortuna l' uso di SQL Express è stato richiesto dal fornitore dell' applicazione..... Almeno su quello è stato chiaro.
Beh, diciamo che l'esempio non è proprio corretto.
Sei hai un DB enorme non usi certo SQL Express, per tutti i limiti che ha.
Se usi la versione standard saprà utilizzare il multi thread.
Conseguentemente sfrutterai le vCPU aggiuntive.
Ciao
E sull'indirizzamento della memoria, che forse è ancora peggio come limite della singola CPU, se non ricordo male ad esempio SQL 2005 indirizza al massimo 1 Gb di RAM.
La soluzione reale, su ambienti di produzione è mettere un SQL Standard.
Luca.
None of the above. The limitations of SQL Server Express are:
- Maximum 10 GB per database.
- Uses no more than 1 processor.
- Uses no more than 1 GB of internal memory.
Effettivamente è per un utilizzo di basso profilo....
Fate attenzione anche a quei produttori che basano i loro software su SQL Express dicendo che va benissimo e bullandosi che così fanno risparmiare i clienti. Mi è capitato un caso dove a un certo punto il gestionale si è bloccato completamente per raggiunto limite del database (era un SQL Express 2005, quindi con limite a 4 Gb, i 10 Gb sono stati incrementati con SQL Express 2008), e la migrazione volante a un SQL Standard è stata un bagno di sangue… sangue versato dal produttore del gestionale ovviamente ![]()
Luca.
Luca Dell'Oca ha scritto:
Fate attenzione anche a quei produttori che basano i loro software su SQL Express dicendo che va benissimo e bullandosi che così fanno risparmiare i clienti.
Sottoscrivo!!!
E purtroppo è pratica abbastanza comune...
--
Rocco Sicilia
