Reading Time: 11 minutes

Le scelte in fase di pianificazione sul progettare e realizzare il VMware vCenter Server (e i relativi servizi) sono mano mano cresciute al crescere della versione e ovviamente possono anche cambiare al cambiare della versione (si pensi ad esempio alla componente di SSO introdotta nella 5.1, ma pesantemente cambiata e migliorata nella 5.5).

Durante l’ultima Nordic VMUG User Conference avevo tenuto una sessione sugli aspetti relativi alla progettazione del vCenter e, visto che la sessione era stata gradita, ho pensato di svilupparne un piccolo post in italiano riepilogativo di alcune scelte. Ovviamente esistono molti altri riferimenti, alcuni molto interessanti e anche da una prospettiva diversa e non solo tecnica, come ad esempio quello di Max Mortillaro (vCenter Server Design Considerations).

VMware LogoIn linea di massima le principali scelte (o almeno quelle più significative) sono:

In molti casi le risposte possono essere semplici o “forzate”: ad esempio per quanto riguarda la disponibilità del vCenter Server l’unica soluzione supportata ufficialmente è l’uso di VMware HA (visto che l’anno scorso VMware vCenter Heartbeat è stato dismesso). Ma anche se la risposta è ovvia, non è l’unico aspetto di disponibilità da dover considerare: per quanto riguarda la parte di DMBS, come si può procedere quando è esterno? In questo caso la risposta arriva direttamente dalla KB 1024051 (supported vCenter Server high availability options) che spiega come sia possibile, a partire dalla versione 5.5, avere un database SQL clusterizzato (KB 2059560) o anche un Oracle RAC (KB 2002531).

Il realtà anche il discorso vCenter in HA cambierà, visto che da vCenter Server 5.5 U3 (e ovviamente anche 6.0) sarà possibile (nuovamente) clusterizzare i servizi di vCenter Server, oltre che ovviamente (come già spiegato) la parte di backend database. Maggiori informazioni saranno disponibili quando questi prodotti saranno rilasciati.

Nel caso si scelga l’appliance molte risposte e scelte sono già implicite dato che, ad esempio, si può solo usare in ambiente virtuale. Vi sono però limiti del prodotto (almeno fino alla versione 5.5 inclusa) e limiti anche sulla scelta dei DBMS esterni. D’altra parte comporta numerosi vantaggi come ho descritto in un post precedente (vCenter Server Installable vs. Appliance) o durante #vBrownbag Tech Talks nell’ultimo VMworld Europeo.

Riguardo alle dipendenze esterne, bisogna ricordarsi che o il nome o l’IP del vCenter non saranno più modificabili (a meno un bel bagno di sangue nel sistemare vari file e varie righe del database); quindi la logica vuole che si usino i nomi completi (FQDN nel mondo DNS), in questa caso è obbligatorio avere impostato correttamente sia la risoluzione diretta (nome in IP) che quella inversa (IP in nome) e, possibilmente che funzionino sia per i nomi corti che quelli completi.

Per l’autenticazione, nel caso si voglia utilizzare come back-end l’Active Directory, allora il vCenter Server deve essere joinato al dominio AD. Bisogna però notare che esistono anche altre identity sources supportate nella versione 5.5:

  • Active Directory as an LDAP server (non più supportato)
  • OpenLDAP
  • KB 2064977
  • Local OS
  • Local SSO

Uno degli aspetti più interessanti dal punto di vista del design è quanti sistemi possono essere utilizzati per implementare questo servizi. Considerando che (da vSphere 5.1) esistono quattro ruoli/componenti principali (SSO, Web Client, Inventory Service, vCenter Server) in teoria si potrebbero distribuire su più sistemi:

vCenter-Roles

Ma in realtà il massimo della scalabilità si ottiene distribuendo queste componenti non in modo arbitrario, ma mantenendo alcune logiche (ad esempio quelle di prossimità). Vi è inoltre da considerare che alcune componenti possono avere più istanze (ed inoltre che alcune componenti possono avere particolari soluzioni di alta disponibilità).

Di fatto, a partire da vSphere 5.5, esistono tre scenari di deployment: singolo sistema, più sistemi in un singolo site, più sistemi in più site.

vCenter5-Deployment

Sistema singolo

Design-vCenter-1Nel caso si pianifichi di utilizzare un singolo sistema per tutte le componenti del vCenter si otterrà una soluzione meno scalabile, ma sicuramente più semplice e gestibile (e con meno dipendenze)

In questi casi il DBMS può essere locale oppure esterno a seconda della dimensione dell’ambiente e dei requisiti funzionali. In particolare se si sceglie come database interno quello embedded allora la dimensione dell’ambiente dovrà essere per forza limitato. Avere però anche il database nello stesso sistema permette di ottenere un unico “appliance” con poche dipendenze verso l’esterno e gestibile quasi con una “black box”.

In fase di installazione, la modalità “Simple” permette di installare tutte le componenti in poco tempo (rispetto ad installare ogni componente singolarmente) e con pochi click.

Questa configurazione può gestire da 1 a 1000 host e da 1 a 10000 VM, salvo nel caso di database di tipo embedded (per la versione di vCenter 5.x installabile si tratta di SQL Express) dove il limite scende ad un massimo di 5 host o 50 VM (quindi solo per ambienti piccoli). In realtà usando la vCSA 5.5, sempre con il database embedded, questo limite sale fino a 100 host o 3000 VM (rendendo quindi questi numeri decisamente interessanti per installazioni anche medie).

Esiste anche l’ottimo articolo VMware KB 2052334 (Installing vCenter Server 5.5 best practices) che illustra diversi aspetti da considerare per un corretto deploy di vCenter.

Alcuni di questi riguardano i requisiti minimi per un deploy con il “Simple Install” dove tutte le componenti (vCenter Single Sign-On, vSphere Web Client, vCenter Inventory Service, e vCenter Server) sono su un singolo sistema:

Host Hardware for Simple Install Deployment Minimum Requirement
Processor Intel or AMD x64 processor with two or more logical cores, each with a speed of 2GHz.
Memory 12GB.
Memory requirements are higher if the vCenter Server database runs on the same machine as vCenter Server.
vCenter Server includes several Java services: VMware VirtualCenter Management Webservices (tc Server), Inventory Service, and Profile-Driven Storage Service. When you install vCenter Server, you select the size of your vCenter Server inventory to allocate memory for these services. The inventory size determines the maximum JVM heap settings for the services. You can adjust this setting after the installation if the number of hosts in your environment changes. For more information, see the recommendations in JVM Heap settings for vCenter Server.
Disk storage 40-60GB of free disk space is required after the installation, depending on the size of your inventory. You should provide more space to allow for future growth of your inventory.
Disk storage requirements are higher if the vCenter Server database runs on the same machine as vCenter Server, depending on the size of those databases.
In vCenter Server 5.x, the default size for vCenter Server logs is 450MB larger than in vCenter Server 4.x. Make sure the disk space allotted to the log folder is sufficient for this increase.
Network speed 1Gbps
Da notare il requisito di memoria suggerito che non è 8 GB come scritto nella guida di vSphere, ma sale a 12 GB nel caso di un sistema tutto in uno. Molti non volevano utilizzare il vCSA solo perché come requisiti minimi 8GB, ma a conti fatti richiede meno della versione installabile. Ovviamente siamo parlando di configurazioni supportate, non di configurazioni che funzionano (nel mio lab il vCenter 5 GB)… ma in produzione ha senso progettare qualcosa basandosi su configurazioni non supportate?

Più sistemi

Nel caso dell’utilizzo di più sistemi esistono due diversi scenari di deployment a seconda di come viene installata la parte di SSO (in particolare a che tipo di configurazione si sceglie):

  • vCenter Single Sign-On for and additional vCenter in an existing site: di fatto tutto in un solo sito
  • vCenter Single Sign-On for and additional vCenter with a new site: viene configurato un nuovo Lookup Services pensato per una configurazione multi sito

Il concetto di sito di SSO (introdotto nella versione 5.5) è molto simile a quello di Active Directory, ma ovviamente le topologie che si ottengono sono diverse.

Design-vCenter-2 Nello scenario singolo SSO Server (normalmente con un suo Web Client locale, per poterlo gestire nella parte di autenticazione) si hanno più vCenter Servers (ciascuno con il suo Inventory service) in un’unico sito (o datacenter).

La parte di DBMS può essere una sola centralizzata, ma solo dal punto di vista logico: ogni singolo vCenter Server dovrà avere un suo database dedicato. Normalmente, in questo scenario, la funzione di linked mode è utilizzata per “aggregare” i vari vCenter in modo da gestirlo tutti da un singolo client.

Questa soluzione puù anche essere utilizzata nel caso si utilizzi la vCSA, dato che è possibile avere SSO (che dovrà essere installato su Windows) e DBMS esterni, però si perde la funzionalità di linked mode (dato che è una della funzioni non implementa nella versione appliance, almeno nella versione 5.x).

Per migliorare la disponibilità della parte di SSO è prevista una configurazione in HA con due SSO Server ed un load balancer esterno; per maggiori informazioni vedere la KB 2033588 (Configuring VMware vCenter Single Sign On for High Availability).

vCenter5-MultiSiteNello scenario multi-server e multi-site, introdotto dalla versione 5.5, si sfrutta invece la funzione di replica dei dati di SSO 5.5 (ricordiamo che nella versione 5.1 era necessario un DBMS esterno, che ora è integrato e distribuito tra i vari SSO). Quindi la componente di SSO è una dal punto di vista logico, ma è in realtà locale in ciascun sistema che, di fatto, rappresenta ancora una soluzione dove tutte le componenti sono locali.

Anche in questo caso il linked mode può essere usato per aggregare i vari vCenter Server.

La parte di DMBS può essere locale in ciascun sistema o esterna, ma sempre con la logica di un database dedicato per ogni vCenter Server.

Alcuni criteri personali

Personalmente preferisco avere, se possibile, tutto in uno e in virtuale e ultimamente sto sempre più apprezzando la versione appliance (seppur con i suoi limiti). Anche il database, a meno di avere la necessità di altri database per altri servizi di gestione, preferisco inglobarlo nella stessa VM con un SQL locale (anche qui la vCSA 5.5 aiuta visti i limiti maggiori del database embedded). Sicuramente per PMI la scelta è praticamente obbligata, sia per minimizzare l’uso di risorse, ma soprattutto per ridurre la complessità.

Chiaro che quando gli host aumentano e quindi pure i cluster aumentano, l’uso di un cluster di management diventa obbligatorio e necessario, mitigando tra l’altro quei pochi difetti che si hanno con un deploy del vCenter in virtuale. E se l’ambiente è veramente grande conviene iniziare ad utilizzare una configurazione multi-sistema. D’altra parte però in Italia la maggior parte delle realtà è fatta da ambienti veramente “piccoli”, normalmente con un solo cluster.

Anche se di recente sto impiegando sempre di più la vCSA, nei casi di versione installabile oramai utilizzo solo Windows Server 2012 R2 (fino a qualche anno fa solo 2008 R2) ma con macchina rigorosamente dedicata solo a vCenter Server e relative componenti. Nel caso di versone installabile, VUM trova spesso spazio naturale direttamente nella VM del vCenter (fino a decine di host non impatta in modo significativo).

Share

Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-24. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-23. Nutanix NTC 2014-20. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.