Ho letto con la solita attenzione il post di Massimo in particolare perché il titolo coincideva stranamente con le riflessioni che sto facendo per decidere la strada da prendere nell’evoluzione della nostra piattaforma virtuale.

Il punto di vista di Massimo è strettamente tecnico/operativo e nello specifico credo che l’unica considerazione mancante riguarda un fattore molto importante che manca nell’equazione.

Non è infatti solo un problema di rapporto CPU/RAM con VM ma, pur rimanendo nel campo esclusivamente tecnico, di ben altri fattori.

Nella mia esperienza di erogazione di servizi internet su Farm virtualizzate i fattori di scelta, per l’evoluzione delle farm, sono:

• Ridondanza
• Performance
• Manutenibilità
• Alta disponibilità

Il principio guida della ridondanza è di non mettere (traducendo forzatamente dall’inglese) tutte le uova in un paniere ed assicurare adeguata copertura anche in caso di failure hardware. Questo è sicuramente un tradeoff di una eventuale scelta di downsizing.

Le performance sono merce preziosa, soprattutto quando è necessario coniugare il consolidamento con la variabilità dell’incremento di carico dovuto agli utenti. Inoltre, almeno nella mia personale esperienza, ci sono dei ruoli che poco si addicono ad essere virtualizzati (DBServer e Fileserver) e per loro natura richiederebbero discorsi di scale-up.
Nonostante VMware si affanni ad affermare che il gap di performance è minimo, il bus di un server, i suoi dischi, la connessione in SAN è pur sempre condivisa e le macchine virtuali sono sempre al di sotto delle performance nominali di un hardware corrispondente alle risorse assegnate.

La concorrenza con Microsoft e Cytrix ha spinto VMWare ad integrare sempre più funzioni all’interno del suo ESX. Non ho ancora in produzione una 4 ma già dalla 3.01 alla 3.5 è visibile l’aumento di complessità dell’infrastruttura e dei servizi esterni accessori. Questo è un fattore moltiplicativo della complessità della farm che ospita generando un numero di vincoli in costante ascesa. Anche l’eventuale scale-over di una farm ha delle ripercussioni sulla sua manutenibilità: l’aggiunta di server dai core diversi, di fatto, neutralizza i vantaggi di aggiungere un nodo dovendo disabilitare alcune funzionalità di failover e resource management.

L’HA di VMware è sicuramente una funzione utile ma non alla sua piena maturazione nella 3.x: è sempre necessario rimanere nei parametri di disponibilità di risorse indicate dalle varie guide e/o software altrimenti possono verificarsi spiacevoli situazioni di risorse contese tra più host o interruzione delle connettività. In questo caso, la strada del downsizing è assolutamente impraticabile. L’alta disponibilità, a mio giudizio, non è solo la possibilità, come accademicamente definita, di proteggere un servizio dalla indisponibilità ma, e soprattutto, di farlo garantendo un livello di perfomance adeguato al suo utilizzo a regime.

Se a questi fattori puramente tecnici aggiungiamo i fattori economici (licenze acquisite) è chiaro che non è possibile parlare di uno scale down ma, almeno questa è la conclusione a cui sono arrivato io, ad un license optimization che permetta di ridurre il numero di server (ma senza esagerare) aumentandone la potenza del singolo, mantenendo una manutenibilità accettabile e aumentando le performance.

Come accontentare necessità infinite con risorse limitate…