Quoto in toto quanto scritto da Luca, e aggiungo (la tematica mi interessa un sacco):
di prodotti di terze parti ci sono sicuramente quelli di VKernel, e quelli di quest (parte della suite Foglight/vFoglight).
A parte l'attenzione ai costi della soluzione di chargeback/showback, okkio ai seguenti aspetti (che valgono in assoluto per il chargeback/showback, non solo per il virtuale):
- cost model: tipicamente si sceglie fra 3 strade:
TFR (Tiered Flat Rate), ovvero "canone fisso" impostato con costi legati per es. a template, che identificano la "classe" di vm che stai erogando (gold, silver, bronze, ecc), in cui i fattori di costo possono essere i + vari: numero di vcpu, quantita' di vram, dimensione dei virtual disk, tier di storage impiegato, appartenenza a resource pool, shares di DRS, ecc. E' il modello piu' semplice da impiegare ma e' anche il meno preciso, perche' devi arrotondare i costi (in genere per eccesso) un po' con la mannaia. Ti obbliga anche in qualche modo a standardizzarti (ammesso che tu possa) su questi "vm tier" che non necessariamente possono matchare il sizing che fai/ti serve per le specifiche applicazioni. In aggiunta, e' abbastanza "unfair" rispetto ai consumatori, perche' non tiene in conto le effettive risorse consumate (2 utenti con vm identiche ma una idle e una con cpu a stecca pagano uguale, anche se incidono in modo completamente diverso sullo sfruttamento delle risorse del tuo cluster).
MRU (Measured Resource Utilization), ovvero misurazione delle effettive risorse utilizzate: molto + fico perche' paghi esattamente quello che consumi, partendo dall'assegnazione di costi per metrica per periodo (ad es. 0.01 eur per megahertz al mese, chesso'). La parte difficile qui sta nel quantificare i costi per le varie metriche, perche' non e' sempre semplice scorporare i costi dei singoli componenti dal "tutto" (magari puoi capire quanto ti costa la ram degli host... ma come spalmi i costi di sp e cache di uno storage array? e se usi autotiering? chi paga la parte flash e chi la parte sata? non impossibile, ma e' un bell'esercizio). Okkio che qui le metriche le devi avere tendenzialmente tutte, e non tutte le soluzioni di chargeback/showback sono in grado di gestirle tutte (alcuni misurano cpu, ram, network... ma magari manca la gestione di spazio disco e i/o disco...). Visto che e' molto + difficile da "disegnare", generalmente si parte con un modello TFR e poi si affina il tiro con MRU...
Misto (TFR + MRU), ovvero un canone flat (generalmente piu' basso), e aggiunta delle metriche a consumo, magari per quelle piu' onerose (spazio disco, iops, ram). E' il meglio dei due mondi, ma cmq non di banale implementazione.
Non e' finita qui: oltre alle metriche "virtuali" (ovvero risorse computazioniali, di rete, di storage, ecc) per i quali i sistemi di chargeback/showback ti danno evidenza dell'effettivo consumo, dovresti poi anche considerare costi "nascosti", tipo licenze (OS, antivirus, software applicativi) e costi di infrastruttura (consumo energetico, cooling, ecc.).
In generale, la linea guida da seguire e' che il chargeback/showback NON va usato per ribaltare i costi di infrastruttura (server, licenze, consumi, ecc.) ma deve rappresentare un ribaltamento dei costi per il SERVIZIO che viene offerto. Why? perche' fa + cloud ;-).
Scherzi a parte, oltre ad essere + cloud oriented come approccio, l'analisi dei costi si concentra su quello che viene veramente erogato (il servizio) e non sui singoli asset tecnologici. Questo, oltre a valorizzare il valore aggiunto che ci mette il supereroe sysadmin (eheh), evita anche che il ribaltamente dei costi faccia da freno all'innovazione (del tipo: perche' dovrei pagare di + per il tuo nuovo storage fico che vuoi comprare? a me va benissimo di pagare poco per quello che c'e'... e' un problema tuo (del sysadmin) fargli reggere i miei trilioni di iops.. ecc ecc).
Riassumendo: il chargeback/showback e' una tematica complessa (e imho molto interessante). Ocio pero' a non ridurla a una mera misurazione/billing dei costi perche' ottieni l'effetto contrario a quello desiderato. Va introdotta come nuova prassi organizzativa, a cui deve poi seguire un riscontro derivato dalla tecnologia.
Ah, dimenticavo... ad oggi e' ancora considerato l'unico antidoto conosciuto al virusel del vSprawl.. (se applicato secondo la ricetta del medico 🙂 ).
Bye
PJ
