Con il nuovo rilascio di vCenter Server Appliance (VCSA) 5.5, VMware ha compiuto un deciso passo avanti nel rendere questa soluzione decisamente appetibile non più soltanto per ambienti di test o piccole installazioni, ma anche per ambienti di medie e grandi dimensioni. In particolare, i nuovi limiti di 100 hosts e 3000 VM rendono sicuramente appetibile VCSA non solo per installazioni piccole (il classico bundle con la licenza Essentials Plus e tre server) ma anche strutture di medie dimensioni. Ambienti con 100 hosts e 3000 VM non sono per niente comuni.
A mio avviso, ci sono però alcune considerazioni da fare, che vanno al di là dei meri limiti di elementi gestibili.
Scalabilità
Il continuo ripetere che adesso VCSA ha nuovi ed accresciuti limiti, in parte distrae da altri fattori che penso siano più importanti nel decidere quale versione usare. Anche in ambienti dove VCSA sarebbe perfettamente in grado di gestire tutta l’infrastruttura, ho visto nonostante ciò non raggiungere mai questi valori, nemmeno utilizzando vCenter Installabile (che arriva a 1000 hosts e 10000 VM ).
Solitamente in ambienti anche di grandi dimensioni, si preferisce limitare il numero di hosts e VM per vCenter e avere piuttosto diversi vCenter, magari in linked mode. Questo per due serie di motivi: innanzitutto, la limitazione dei failure domain. Se si ferma vCenter, molte attività sono precluse. I cluster ESXi continuano a funzionare, ma ogni operazione sull’infrastruttura è preclusa, così come non si può fare nessuna attività con vCloud Director o con View Composer…
Secondo, le risorse per eseguire un vCenter per ambienti di quelle dimensioni iniziano ad essere proibitivi sia in termini di RAM che CPU.
Piuttosto, un grosso limite alla scalabilità di VCSA viene dal mancato supporto del Linked Mode, specie se implementato negli ambienti di grandi dimensioni di cui parlavo prima. Da un punto di vista dell’alta affidabilità inoltre, nemmeno vCenter HeartBeat è supportato.
Database
VCSA utilizza internamente un database Postgres (per favore, gente di VMware, NON chiamatelo vPostgres come ho letto in giro…). La gestione di questo database è affidata interamente all’appliance, e penso che un DBA avrebbe qualche problema a gestirlo insieme agli altri database aziendali.
L’alternativa è quella di utilizzare un database esterno, configurazione supportata da VCSA ma solo se il database esterno è Oracle. L’idea del database esterno secondo me fa a pugni con l’idea stessa di VCSA: se lo si vuole usare per risparmiare sulla licenza Microsoft e poi ci si affida ad Oracle, non vedo dove sia il vantaggio a questo punto.
vCenter Update Manager
Uno dei limiti fortissimi di VCSA, anche quando usato in piccoli ambienti dove la protezione della singola appliance è più che sufficiente e la rende quindi ideale, è il mancato supporto ad Update Manager direttamente all’interno dell’appliance stessa. E’ possibile installare Update Manager in un’altra virtual machine, che però deve essere Microsoft. Ancora, abbiamo risparmiato la licenza Windows per vCenter per poi doverne reintrodurre un’altra da utilizzare per Update Manager.
Futuri sviluppi
Non ho idea di quali saranno ovviamente, ma io personalmente ne apprezzerei diversi.
Per prima cosa, il supporto ad Update Manager. Non so il motivo per cui dopo oramai diverse versioni di VCSA Update Manager non sia ancora integrato, ma sicuramente la sua introduzione nelle prossime versioni è in assoluto la funzione più desiderabile.
Inoltre, se viene utilizzato già Postgres come database interno, perchè non offrire il supporto a questo database anche quando installato esternamente, e magari anche per il vCenter Installabile? Postgres è una soluzione matura, affidabile e molto potente. L’eventuale scusa che sia opensource e quindi senza il supporto ufficiale di un vendor penso abbia poco fondamento, dato che internamente è già supportato. Garantire l’alta affidabilità del database di vCenter è possibile ad oggi solo utilizzando versioni clusterizzate sia di Oracle che di MS SQL, ma questo comporta un esborso ulteriore, dato che le licenze cluster di questi database costano più di quelle base. Versioni clusterizzate di Postgres ridurrebbero sensibilmente i costi.
Ancora più importante, una vera soluzione per il futuro potrebbe essere l’introduzione di una versione di vCenter scalabile orizzontalmente, creando una struttura composta da più vCenter in parallelo, tutti collegati tra loro, per cui la perdita di una della appliance non comporterebbe nessun problema. Linked Mode offre una gestione condivisa tra più vCenter, ma non costituisce un sistema “scale-out” dove un vCenter può gestire gli oggetti di un altro vCenter in caso di suo crash.
Un paio di anni fa, se non ricordo male al VMworld 2011, VMware al suo stand aveva in un angolo una “technology preview” di una soluzione denominata “distributed vCenter”. Sarebbe interessante sapere che fine abbia poi fatto…
[Questo post è un lavoro originale di Luca Dell’Oca, pubblicato sul blog www.virtualtothecore.com ]