Ieri è stato presentato vSphere 5 e una serie di altre novità importantissime dell’intero portafoglio di VMware, un evoluzione importante che, ancora una volta, sancisce il predominio tecnologico che questa azienda ha nei confronti di tutti gli altri fornitori di software per la virtualizzazione (in particolare mi rifersico a Microsoft e Citrix con le rispettive famiglie di prodotti basate su Hyper-V e Xen).
Rimando tutte le disquisizioni tecniche ad una serie di post che Fabio farà nei prossimi giorni e mi voglio soffermare su un particolare inquietante anche perchè, immediatamente dopo la presentazione, tutto il focus degli utenti si è spostato sul nuovo modello di licenza!
Le nuove licenze
VMware, fino a ieri, aveva un modello licenza basato sul numero di CPU (1 CPU==1 Licenza) e, in funzione della versione del prodotto, c’era una limitazione di 6 o 12 core per CPU e di RAM fisica installata sul server (fino ad 1TB per la Enterprise Plus).
Da ieri è stata tolta la limitazione sul numero di core e sulla ram fisica ma è stato aggiunto un limite massimo di vRAM (Memoria virtuale vista dalla CPU) per ogni licenza! (qui il documento ufficiale sul nuovo licensing)
Questa piccola modifica è devastante e può impattare sensibilmente nei costi di licenziamento di una infrastruttura basata su VMware, ecco perchè: Se prima avevo un’infrastruttura composta di 4 server con 2 CPU e 96GB di RAM fisica per ognuno (abbastanza facile da trovare come configurazione) dovevo acquistare 8 licenze mentre ora, per essere in regola con il nuovo sistema, devo aggiungerne delle altre in funzione della memoria totale allocata dalle VM. Questo perchè ogni 48 GB (questo è il limite della Enterprise Plus, le altre sono più basse) devo aggiungere una licenza!
Esempi pratici
Un precisazione prima di fare esempi: la vRAM non viene conteggiata per singolo host ma è gestita in un pool e si conta il totale della vRAM delle VM accese viste dal vCenter.
Poniamo, ad esempio, che che il totale della RAM allocata (grazie a tutti i meccanismi messi a disposizione da vSphere posso allocare più RAM di quella fisicamente disponibile) in questa infrastruttura sia circa del 30% superiore a quella fisica (96*4+30% = circa 500GB), in questo caso ci troveremo a dover acquistare 11 licenze!!!!
Se il costo è alto per un infrastrutture di piccole dimensioni può diventare scabroso nel caso di installazioni con grandi quantitativi di RAM allocata: molti server dell’ultima generazione supportano fino a 2TB di RAM fisica (con 4 CPU) ma anche se prendessimo una configurazione server/blade con macchine da due CPU della serie E7 di intel (10 Core) e 256GB di RAM ci troveremmo costretti ad acquistare qualche cosa come 6 licenze già senza fare over commitment della memoria!
Se, ad esempio, il server in oggetto (2 CPU/256GB) gestisse un quantitativo di vRAM nell’ordine di 300GB dovrei acquistare 7 licenze Enterprise plus dal non proprio economicissimo costo di 3034€ più manutenzione (TOTALE 21238€ + manutenzione).
Nota Finale
Tutti quelli che lavorano con la virtualizzazione sanno che la potenza della CPU non è più un problema da tempo, quindi VMware sta correndo ai ripari per potersi garantire un adeguato “flusso di cassa” ma, facendo così, oltre a far arrabbiare i suoi utenti darà più spazio ai concorrenti (soprattutto quelli price sensitive come gli ISP, ad esempio). Inoltre, la virtualizzazione faceva da “cuscinetto” alle richieste del management per macchine virtuali con più ram di quella effettivamente utilizzata e vmware faceva la “magia” dell’overcommitment, che ora invece ha un costo e complicherà la vita di tutti.
Da un lato posso capire la necessità di spremere tutto quello che si può (anche se è un atteggiamento molto poco apprezzato dai clienti e che ricorda decisamente quello di Oracle) ma dall’altro vedo l’hypervisor come un semplice abilitante, mentre la differenza vera la fanno tutti i prodotti a corredo (vCloud, SRM, ecc) che vanno aggiunti on top alle licenze di base, perchè accanirsi su quelle?
Molto d’accordo..
io ho fatto una proiezione su una parte del nostro ambiente di produzione:
15 esx con 2 socket (esacore) e 128 gb di ram cadauno (1920 Gb ram).
quindi a livello di licensing me la “cavo” con 30 licenze enterprise plus..
con il nuovo sistema 1920/48 = 40 ne dovrò acquistare almeno 10 in più per cluster,
e considerando che ho un’altro cluster simile..e un terzo arriverà a brave, sinceramente i costi cominciano a diventare importanti, un po troppo secondo me..il prezzo a vm sta diventando proibitivo (aggiungiamoci poi storage..antivirus…monitoraggio..backup etc etc etc).
Mi sembra di capire che il bilanciamento ottimale è 2 CPU e 96 GB ram ?
ciao
Se hai la ent+ si, 2CPU/96GB. Ma con le CPU attuali è ridicolo!
Inoltre dovresti anche rivedere pesantemente i consumi energetici, le porte degli switch FC e Network, ecc.
Letteralmente un bagno di sangue.
Stando così le cose la gente si farà sempre meno scrupoli a valutare offerte di public cloud (tipo Amazon) per tutte le VM meno critiche!
credo che alla fine sia quello che loro vogliono..
sinceramente in italia, per quante aziende ha senso farsi un proprio cloud?
mah vedremo 🙂
a presto ciao
Maestro, sento una perturbazione nella forza ™
Concordo in toto ed aggiungo che, se visto in prospettiva non squisitamente tecnica, la “nuova” politica ha senso (almeno per loro) eccome e basta considerare due prospettive che credo siano l’una cara ad EMC e l’altra VMWARE:
1) le features piu’ hot ruotano attorno:
a) storage awarness/integrazione/api (VAII/VASA,ecc.) che richiederanno ai vendor non EMC di rincorrere le “loro” (intendo EMC) soluzioni (bah la VSA ancora non l’ho “squadrata”)
b) nuovo HA stack e soprattuto stretched cluster (storage Heartbeat) che strizza molto l’occhio a metro cluster vplexc) cloud “readiness” a go go incentrato IMHO sulla logica pay per VM (intendo la somma di tutto APM,capacity planning,deploy,ecc.) pensando al chargeback2) VMWARE sta investendo un sacco di soldi per costruirsi il suo application stack da proporre come alternativa a quello Microsoft sia on premise che e soprattutto in salsa cloud od ibrida..ed allora io penso.. visto che Microsoft sta variando il licensing verso il pay per cpu che consente n istanze per la gioia di chi seguiva il mantra “scale up before scale out” che fino all’altro ieri VMWARE professava,vedi vedi che se metto una vRAM tax do un colpo alla botte ed uno alla moglie e vado a limitare in numero di istanze per host on premise (dove tutto comincia…intendo come sviluppo applicazioni) rendendo piu’ appetibili i miei SAAS,PAAS,BADASSS?! che non si portan dietro anche i balzelli Microsoft (e si Windows,SQL,ecc. Datacenter perdono discretamente di valore “aggiunto” nel nuovo assetto) ?! Insomma se il costo per VM sale mi passa la voglia di creare VM a spron battuto sugli host o di usare l’memory overcommit/compression etc. (ma non erano features?) e forse penso davvero al cloud pubblico..Ah naturalmente c’e’ il mistero in salsa vRAM tax della “svista” VDI cioe’ di come far crescere il figlio gobbo VIEW essendo al primo salmo che “overcommit is beautiful” .Non so se e’ una reazione al fatto che alle fine la virtualizzazione diventerà commodity ma fra tutte le reazioni quella alla “Oracle” era la peggiore.Comunque compliementi per il blog!Saluti,Antonio
Antonio non sono sicuro di essere riuscito a seguire il ragionamento nel suo insieme ma sul rapporto occulto VMware/EMC ti posso dire che al Centro Leoni di Milano (dove abbiamo la sede entrambi) se parcheggiamo nei “loro” posti ci mettono le ganasce alle ruote.
Massimo
In effetti mi sono espresso a farfugli ma a quest’ora la mia mente e’ ormai pregiudicata=)
Ad ogni modo Massimo (immagino quello di IT 2.0 ?=) le mie sono ovviamente
congetture da avvocato del diavolo..
sul primo punto non pensavo ad un “rapporto oscuro” con accezzione cosi’ negativa,
ma non posso credere che il rapporto matrigna-cenerentola comunque non incida
minimamente in fase di design delle suddette api e non abbia un risvolto positivo
nel ready to market fermo restando che poi le interfaccie/api siano pubbliche e che i
competitor (HP,IBM,netapp,ecc…) abbiano accesso ai dev kit/supporto/ecc per tempo..
la vedo come pratica comune (piaccia o no) che ci sia un imprinting cosiccome accade,
per citare un analogo a me caro, nei working groups 802.x IEEE con Cisco..
no quello non e’ cosi’ “maligno” anche se e’ comunque un segno di come IMHO la “culture”
VMWARE stia travalicando l’aspetto squisitamente tecnofilo dell’era Rosenblum/Green
(per la felicita’ degli azionisti=)
Cio’ che e’ piu’ machiavellico e’ il secondo punto cioe’ di come la vRAM tax
abbia un target molto piu’ articolato del semplice arginare il fenomeno di host
“ultradensi” con ratio cpu/core vs pRAM impari che leggo in rete.
Non credo agli autogol clamorosi per cui qualcuno avra’ ben valutato
che il cambio di rotta violi uno dei mantra professati (prima che la parola cloud
esondasse) che era appunto il scale-up..tutti, VMWARE in prima fila, parlavano del
memory TPS/overcommit/compression come un punto chiave e differenziatore dalla
concorrenza che consentiva appunto alti consolidation ratios (ancora maggiori se
adiuvati da SIOC/NETIOC/VAAI/ecc)..tante’ che si creata pressione su Microsoft stessa a
modificare il licensing almeno nell’ottica del pay per socket con instanze illimitate
(parlo di sku “Datacenter”) proprio perche’ la densita’ per socket trovava un cap
nella RAM piu’ che nelle cpu ncore, cap che gli hw vendor stavano colmando,non solo sui
server classici (vedi HP DL500G7 in su) ma anche nei “blade” (penso ad HP ma anche
ai memory extenders di IBM/DELL).
Ma questo e’ l’aspetto “diretto”..l’aspetto indiretto riguarda il nuovo sbilanciamento
che porta sul lato costi licensing e se vogliamo propositivo delle soluzioni Microsoft:
la spinta alle sku “Datacenter” e’ andata di pari passo con la richiesta di avere si’
degli host “densi” ma anche di evolvere sempre piu’ il paradigna HA Microsoft
(MSCTS) da attivo/passivo ad attivo/attivo in modo da sfruttarli al meglio
senza “sprechi” basta considerare la logica dei DAG di Exchange o dei prossimi DAG
SQL sposta l’attenzione di Microsoft sui megaclyces/IOPS piuttosto che pRAM e benche’
pensi al scale out non cozza con lo scale up specie se pensiamo ad istanze multiple
attive/attive consolidate su pochi host.
Ora l’aver messo un licensing sulla combinazione pCPU+vRAM e non pCPU+pRAM o solo pRAM
“limita” (nel senso di costi) lo scale up aggiunge un costo extra che insinua un
valore propositivo in piu’ per rivalutare il datacenter “classico” OS centrico
(dove Microsoft guadagna di piu’) in favore di soluzioni cloud PAAS/SAAS OS agnostiche
(cio’ che bramava SUN con JAVAOS) dove VMWARE puo’ proporre il suo application stack
in construzione a suon di acquisizioni (zimbra,rabbitmq,wavemaker,spring,ecc..)
e dove la scala e la remunerativa’ non e’ appannaggio solo dei soliti noti.
Quindi per concludere non so quale sia l’effetto primario e quale quello secondario
voluti da questo cambio di baricentro ma nell’ottica di cui sopra IMHO assume molto
piu’ senso. Per il VDI e le sku “Desktop” o il VIEW bundle beh li mi pare piu’
chiaro e meno machiavellico =)
Secondo voi devo smettere coi funghetti colorati? =)
Saluti
Beh Antonio o finisci tu oppure inizio io (coi funghetti colorati) perche’ faccio fatica a starti dietro.
Sei troppo “denso” (tanto per stare in tema 🙂 )Massimo. P.S. si’ quello di IT 2.0.
Antonio,
Concordo con Massimo.
Di integratzioni con VMWARE (soprattutto lato storage) ne ho viste di ottime da molti storage vendor, anche migliori di quelle di EMC in certi casi.
Le API sono pubblicate regolarmente e con il dovuto anticipo a tutti gli HW vendor, infatti ieri abbiamo assistito anche all’annuncio di molti vendor proprio sul supporto alla 5 in tutti i suoi aspetti.
Ciao,
ES
Molto d’accordo..
io ho fatto una proiezione su una parte del nostro ambiente di produzione:
15 esx con 2 socket (esacore) e 128 gb di ram cadauno (1920 Gb ram).
quindi a livello di licensing me la “cavo” con 30 licenze enterprise plus..
con il nuovo sistema 1920/48 = 40 ne dovrò acquistare almeno 10 in più per cluster,
e considerando che ho un’altro cluster simile..e un terzo arriverà a brave, sinceramente i costi cominciano a diventare importanti, un po troppo secondo me..il prezzo a vm sta diventando proibitivo (aggiungiamoci poi storage..antivirus…monitoraggio..backup etc etc etc).
Mi sembra di capire che il bilanciamento ottimale è 2 CPU e 96 GB ram ?
ciao
Se hai la ent+ si, 2CPU/96GB. Ma con le CPU attuali è ridicolo!
Inoltre dovresti anche rivedere pesantemente i consumi energetici, le porte degli switch FC e Network, ecc.
Letteralmente un bagno di sangue.
Stando così le cose la gente si farà sempre meno scrupoli a valutare offerte di public cloud (tipo Amazon) per tutte le VM meno critiche!
credo che alla fine sia quello che loro vogliono..
sinceramente in italia, per quante aziende ha senso farsi un proprio cloud?
mah vedremo 🙂
a presto ciao
Maestro, sento una perturbazione nella forza ™
Concordo in toto ed aggiungo che, se visto in prospettiva non squisitamente tecnica, la “nuova” politica ha senso (almeno per loro) eccome e basta considerare due prospettive che credo siano l’una cara ad EMC e l’altra VMWARE:
1) le features piu’ hot ruotano attorno:
a) storage awarness/integrazione/api (VAII/VASA,ecc.) che richiederanno ai vendor non EMC di rincorrere le “loro” (intendo EMC) soluzioni (bah la VSA ancora non l’ho “squadrata”)
b) nuovo HA stack e soprattuto stretched cluster (storage Heartbeat) che strizza molto l’occhio a metro cluster vplexc) cloud “readiness” a go go incentrato IMHO sulla logica pay per VM (intendo la somma di tutto APM,capacity planning,deploy,ecc.) pensando al chargeback2) VMWARE sta investendo un sacco di soldi per costruirsi il suo application stack da proporre come alternativa a quello Microsoft sia on premise che e soprattutto in salsa cloud od ibrida..ed allora io penso.. visto che Microsoft sta variando il licensing verso il pay per cpu che consente n istanze per la gioia di chi seguiva il mantra “scale up before scale out” che fino all’altro ieri VMWARE professava,vedi vedi che se metto una vRAM tax do un colpo alla botte ed uno alla moglie e vado a limitare in numero di istanze per host on premise (dove tutto comincia…intendo come sviluppo applicazioni) rendendo piu’ appetibili i miei SAAS,PAAS,BADASSS?! che non si portan dietro anche i balzelli Microsoft (e si Windows,SQL,ecc. Datacenter perdono discretamente di valore “aggiunto” nel nuovo assetto) ?! Insomma se il costo per VM sale mi passa la voglia di creare VM a spron battuto sugli host o di usare l’memory overcommit/compression etc. (ma non erano features?) e forse penso davvero al cloud pubblico..Ah naturalmente c’e’ il mistero in salsa vRAM tax della “svista” VDI cioe’ di come far crescere il figlio gobbo VIEW essendo al primo salmo che “overcommit is beautiful” .Non so se e’ una reazione al fatto che alle fine la virtualizzazione diventerà commodity ma fra tutte le reazioni quella alla “Oracle” era la peggiore.Comunque compliementi per il blog!Saluti,Antonio
Antonio non sono sicuro di essere riuscito a seguire il ragionamento nel suo insieme ma sul rapporto occulto VMware/EMC ti posso dire che al Centro Leoni di Milano (dove abbiamo la sede entrambi) se parcheggiamo nei “loro” posti ci mettono le ganasce alle ruote.
Massimo
In effetti mi sono espresso a farfugli ma a quest’ora la mia mente e’ ormai pregiudicata=)
Ad ogni modo Massimo (immagino quello di IT 2.0 ?=) le mie sono ovviamente
congetture da avvocato del diavolo..
sul primo punto non pensavo ad un “rapporto oscuro” con accezzione cosi’ negativa,
ma non posso credere che il rapporto matrigna-cenerentola comunque non incida
minimamente in fase di design delle suddette api e non abbia un risvolto positivo
nel ready to market fermo restando che poi le interfaccie/api siano pubbliche e che i
competitor (HP,IBM,netapp,ecc…) abbiano accesso ai dev kit/supporto/ecc per tempo..
la vedo come pratica comune (piaccia o no) che ci sia un imprinting cosiccome accade,
per citare un analogo a me caro, nei working groups 802.x IEEE con Cisco..
no quello non e’ cosi’ “maligno” anche se e’ comunque un segno di come IMHO la “culture”
VMWARE stia travalicando l’aspetto squisitamente tecnofilo dell’era Rosenblum/Green
(per la felicita’ degli azionisti=)
Cio’ che e’ piu’ machiavellico e’ il secondo punto cioe’ di come la vRAM tax
abbia un target molto piu’ articolato del semplice arginare il fenomeno di host
“ultradensi” con ratio cpu/core vs pRAM impari che leggo in rete.
Non credo agli autogol clamorosi per cui qualcuno avra’ ben valutato
che il cambio di rotta violi uno dei mantra professati (prima che la parola cloud
esondasse) che era appunto il scale-up..tutti, VMWARE in prima fila, parlavano del
memory TPS/overcommit/compression come un punto chiave e differenziatore dalla
concorrenza che consentiva appunto alti consolidation ratios (ancora maggiori se
adiuvati da SIOC/NETIOC/VAAI/ecc)..tante’ che si creata pressione su Microsoft stessa a
modificare il licensing almeno nell’ottica del pay per socket con instanze illimitate
(parlo di sku “Datacenter”) proprio perche’ la densita’ per socket trovava un cap
nella RAM piu’ che nelle cpu ncore, cap che gli hw vendor stavano colmando,non solo sui
server classici (vedi HP DL500G7 in su) ma anche nei “blade” (penso ad HP ma anche
ai memory extenders di IBM/DELL).
Ma questo e’ l’aspetto “diretto”..l’aspetto indiretto riguarda il nuovo sbilanciamento
che porta sul lato costi licensing e se vogliamo propositivo delle soluzioni Microsoft:
la spinta alle sku “Datacenter” e’ andata di pari passo con la richiesta di avere si’
degli host “densi” ma anche di evolvere sempre piu’ il paradigna HA Microsoft
(MSCTS) da attivo/passivo ad attivo/attivo in modo da sfruttarli al meglio
senza “sprechi” basta considerare la logica dei DAG di Exchange o dei prossimi DAG
SQL sposta l’attenzione di Microsoft sui megaclyces/IOPS piuttosto che pRAM e benche’
pensi al scale out non cozza con lo scale up specie se pensiamo ad istanze multiple
attive/attive consolidate su pochi host.
Ora l’aver messo un licensing sulla combinazione pCPU+vRAM e non pCPU+pRAM o solo pRAM
“limita” (nel senso di costi) lo scale up aggiunge un costo extra che insinua un
valore propositivo in piu’ per rivalutare il datacenter “classico” OS centrico
(dove Microsoft guadagna di piu’) in favore di soluzioni cloud PAAS/SAAS OS agnostiche
(cio’ che bramava SUN con JAVAOS) dove VMWARE puo’ proporre il suo application stack
in construzione a suon di acquisizioni (zimbra,rabbitmq,wavemaker,spring,ecc..)
e dove la scala e la remunerativa’ non e’ appannaggio solo dei soliti noti.
Quindi per concludere non so quale sia l’effetto primario e quale quello secondario
voluti da questo cambio di baricentro ma nell’ottica di cui sopra IMHO assume molto
piu’ senso. Per il VDI e le sku “Desktop” o il VIEW bundle beh li mi pare piu’
chiaro e meno machiavellico =)
Secondo voi devo smettere coi funghetti colorati? =)
Saluti
Beh Antonio o finisci tu oppure inizio io (coi funghetti colorati) perche’ faccio fatica a starti dietro.
Sei troppo “denso” (tanto per stare in tema 🙂 )Massimo. P.S. si’ quello di IT 2.0.
Antonio,
Concordo con Massimo.
Di integratzioni con VMWARE (soprattutto lato storage) ne ho viste di ottime da molti storage vendor, anche migliori di quelle di EMC in certi casi.
Le API sono pubblicate regolarmente e con il dovuto anticipo a tutti gli HW vendor, infatti ieri abbiamo assistito anche all’annuncio di molti vendor proprio sul supporto alla 5 in tutti i suoi aspetti.
Ciao,
ES
Premetto che sono stato informato (e mi e’ stato spiegato) il nuovo licensing qualche mese fa. Non ricordo i dettagli anche (e forse) perche’ la mia reazione e’ stata “No big deal. Non cambia nulla di fatto”. Mi riprometto di ristudiarmelo meglio per farmi un’opinione piu’ precisa visto i commenti che leggo su twitter.
Ah, premetto anche che lavoro per VMware (piccolo dettaglio 🙂 ).
Premesso tutto cio’ gli esempi riportati mi hanno fatto pensare ad un articolo che ho scritto nel lontano 2007 : http://it20.info/2007/11/virtualization-hardware-sizing-quick-and-dirty-approach/
dove parlavo di un sizing del pollice e considerare 2/4GB pRAM per core. Con l’attuale licensing, assumendo CPU con 12 core siamo a 96/12=8GB vRAM. Considerando il tuo rapport di vRAM = pRAM+30% (concordo) ci siamo dentro abbondantemente.
Inoltre il tutto mi fa venire in mente un altro articolo scritto nel 2009 http://it20.info/2009/12/from-scale-up-vs-scale-out-to-scale-down/
dove notavo (magari sbagliando) un trend “al ribasso” delle configurazioni di CPU (visto l’incremento di core). La mia teoria era che per supportare lo stesso numero di VM si potevano via via dimezzare i socket (mantenendo la RAM inalterata – per la regola del pollice sopra).
Ora, e’ chiaro che se in una situazione del genere mantengo i socket invariati e raddoppio la RAM finisco (col vecchio modello) di pagare lo stesso e supportare il doppio delle VM. Vado a spanne… vuoto per pieno.
Credo che alla base di questo cambiamento di licensing ci sia la necessita’ di tutelarsi da questo trend evitando di far pagare di piu’ ma, al tempo stesso, evitando di perdere fatturato (che alla fine e’ quello che permette di continuare ad investire per produrre sw di qualita’).
Ho sentito di casi dove l’uso pesante di questo trend (altissima densita’ elaborativa in termini di socket/RAM) aveva portato a offerte di soluzioni dove la componente HW cubava per il 91% e quella SW (leggi VMware) per il 9%. Quando immagino concorderete che il rapporto, in realta’, e’ invertito (IMO).
Massimo.
Massimo,
grazie per il tuo contributo,
capisco il tuo punto di vista (e quindi quello di VMware) che vede assottigliare sempre più la sua parte nei progetti di infrastruttura.
E’ vero anche che gli stessi vendor di server guadagnano meno ad ogni nuova generazione perchè vendono meno hardware per fare le stesse cose.
Rimango della mia opinione: secondo me, più che chiedere troppo per il licensing di base, sarebbe molto meglio spingere gli utenti finali a valutare seriamente tutte le opzioni che VMware ha (e che gli altri non hanno) come SRM o vCloud.
ES
Non posso dire di essere in disaccordo sullo spingere altri layer dello stack ma tu sai meglio di me che non e’ un processo immediato.
Sugli hw vendor non so… Secondo me il ragionamento da fare e’ più complesso e la riduzione potrebbe non essere così lineare come rischia di essere sul software. Comunque mi riservo la possibilità di sbagliare 🙂
Per correttezza… Ho fatto un errore. Non e’ 96/12 ma 48/12=4GB di vRAM contro i 2 o 4 GB di pRAM che suggerivo nel mio vecchio post.
Premetto che sono stato informato (e mi e’ stato spiegato) il nuovo licensing qualche mese fa. Non ricordo i dettagli anche (e forse) perche’ la mia reazione e’ stata “No big deal. Non cambia nulla di fatto”. Mi riprometto di ristudiarmelo meglio per farmi un’opinione piu’ precisa visto i commenti che leggo su twitter.
Ah, premetto anche che lavoro per VMware (piccolo dettaglio 🙂 ).
Premesso tutto cio’ gli esempi riportati mi hanno fatto pensare ad un articolo che ho scritto nel lontano 2007 : http://it20.info/2007/11/virtualization-hardware-sizing-quick-and-dirty-approach/
dove parlavo di un sizing del pollice e considerare 2/4GB pRAM per core. Con l’attuale licensing, assumendo CPU con 12 core siamo a 96/12=8GB vRAM. Considerando il tuo rapport di vRAM = pRAM+30% (concordo) ci siamo dentro abbondantemente.
Inoltre il tutto mi fa venire in mente un altro articolo scritto nel 2009 http://it20.info/2009/12/from-scale-up-vs-scale-out-to-scale-down/
dove notavo (magari sbagliando) un trend “al ribasso” delle configurazioni di CPU (visto l’incremento di core). La mia teoria era che per supportare lo stesso numero di VM si potevano via via dimezzare i socket (mantenendo la RAM inalterata – per la regola del pollice sopra).
Ora, e’ chiaro che se in una situazione del genere mantengo i socket invariati e raddoppio la RAM finisco (col vecchio modello) di pagare lo stesso e supportare il doppio delle VM. Vado a spanne… vuoto per pieno.
Credo che alla base di questo cambiamento di licensing ci sia la necessita’ di tutelarsi da questo trend evitando di far pagare di piu’ ma, al tempo stesso, evitando di perdere fatturato (che alla fine e’ quello che permette di continuare ad investire per produrre sw di qualita’).
Ho sentito di casi dove l’uso pesante di questo trend (altissima densita’ elaborativa in termini di socket/RAM) aveva portato a offerte di soluzioni dove la componente HW cubava per il 91% e quella SW (leggi VMware) per il 9%. Quando immagino concorderete che il rapporto, in realta’, e’ invertito (IMO).
Massimo.
Massimo,
grazie per il tuo contributo,
capisco il tuo punto di vista (e quindi quello di VMware) che vede assottigliare sempre più la sua parte nei progetti di infrastruttura.
E’ vero anche che gli stessi vendor di server guadagnano meno ad ogni nuova generazione perchè vendono meno hardware per fare le stesse cose.
Rimango della mia opinione: secondo me, più che chiedere troppo per il licensing di base, sarebbe molto meglio spingere gli utenti finali a valutare seriamente tutte le opzioni che VMware ha (e che gli altri non hanno) come SRM o vCloud.
ES
Non posso dire di essere in disaccordo sullo spingere altri layer dello stack ma tu sai meglio di me che non e’ un processo immediato.
Sugli hw vendor non so… Secondo me il ragionamento da fare e’ più complesso e la riduzione potrebbe non essere così lineare come rischia di essere sul software. Comunque mi riservo la possibilità di sbagliare 🙂
Per correttezza… Ho fatto un errore. Non e’ 96/12 ma 48/12=4GB di vRAM contro i 2 o 4 GB di pRAM che suggerivo nel mio vecchio post.