This post is also available in: Inglese

Con il nuovo VMware vSphere 6.0 vi sono molti cambiamenti, alcuni dei quali riguardano anche il vCenter, sia nelle funzionalità, ma anche nella sua architettura. E sia per la versione installabile Windows che per la versione distribuita sotto forma di virtual appliance (vCSA).

Per questo motivo alcuni aspetti relativi al design ed al deployment di questa componente sono cambiati rispetto alla versione precedente (vedere Progettare un VMware vCenter 5.5). Altre considerazione sono rimaste invariate, ad esempio se utilizzare un’infrastruttura fisica o virtuale per il vCenter, se utilizzare un database interno od esterno, o su come migliorare il livello di disponibilità del vCenter (in realtà qua c’è una novità legata al nuovo FT-SMP).

Notare che VMware ha anche da poco rilasciato un documento specifico sull’argomento: VMware vCenter Server 6.0 Deployment Guide.

Riguardo le scelte tra vCenter Server installabile o quella appliance ora la vCSA è competamente comparabile con la versione Windows ed è stata persino migliorata nell’installazione e nella gestione degli aggiornamenti.

Quello che cambia radicamente è la struttura del nuovo vCenter, dove i vari componenti sono stati semplificati, sia nell’installazione, ma anche nell’organizzazione, visto che ora vi sono due ruoli ben distinti. I ruoli sono cambiati rispetto a vCenter 5.1 e 5.5 dove vi erano di fatto 4 componenti (anche se sarebbe più corretto chiamarli ruoli) principali: SSO, Web Client, Inventory Service e vCenter Server. Queste componenti potevano essere installate su un singolo sistema (che poi era la modalità della vCSA o dell’installazione Simple per Windows) oppure essere installati individualmente su più sistemi:

In realtà gli scenari di deployment erano leggermente diversi e prevedevano solo alcune combinazioni particolari (vedere Progettare un VMware vCenter 5.5).

Ovviamente vi era poi il quito componente principale dato dal database server, con diverse opzioni anche in questo caso, sostanzialmente la versione embedded (SQL Express per Windows e vPostgres nella vCSA) oppure esterno.

La compenente chiamata VMware Single Sign-On (SSO) è quella che ha subito più cambiamenti nel corso di queste versioni di vSphere:

• 5.1 – prima versione (SSO 1.0)
• 5.5 – seconda versione (SSO 2.0)
• 6.0 – terza versione e ora integrata con altri servizi in quella che si chiama platform services controller

Platform Services

A partire da vSphere 6.0 il SSO è stato incluso un un ruolo particolare chiamato VMware Platform Services Controller (PSC) (in realtà durante la beta iniziale era stato chiamato Infrastructure Controller IC).

Questa nuova componente dell’architettura di vCenter include tutti questi servizi:

• Single Sign-On (SSO)
  • Secure Token Service (STS)
  • Identity Management Service (IdM)
  • Directory Service (VMDir)
• VMware Licensing Service (New)
• VMware Certificate Authority (VMCA – New)
• Certificate Store
• Service (Product) Registration
• Misc Services (New)
  • Authentication Framework Daemon (AFD)
  • Component Manager Service (CM)
  • HTTP Reverse Proxy

Altri servizi “comuni” potrebbero essere aggiunti in futuri all’interno della Platform Services Controller. Questi servizi comuni non lo sono solo dal punto di vista di vSphere ma anche per tutti gli altri software della vCloud Suite 6.0, inclusi quindi including vCAC, vCOPS, …

E altro aspetto interessante è la possibilità di avere più PSC in una configurazione ad altra disponibilità (un po’ come succedeva con SSO nella versione 5.5): i dati sono automaticamente replicati tra ogni PSC, l’unica accortezza e requisito è disporre di un load balancer esterno.

Tra i vari servizi comuni si può notare anche il nuovo sistema gestione dei certificati digitali introdotto con vSphere 6.0: VMware Certificate Authority (VMCA) è di fatto la root certificate authority che rilascerà e gestirà tutti i certificati. Il provisioning degli stessi è automatico (sullo stile di quanto avviene con la CA Microsoft) nel momento in cui un host viene aggiunto ad un vCenter Server

Nel caso di scenari di aggiornamento, la PSC sarà istanziata direttamente dove era presente il SSO.

Management Services

La seconda parte con la quale può essere modularizzato il nuovo vCenter Server è quella che integra le componenti rimanenti:

• vCenter Server: ovviamente il cuore del sistema.
• vSphere Web Client: la parte server del nuovo vSphere Web Client, introdotto in modo timido con vSphere 5.0 (e diventato usabile solo con la 5.5).
• Inventory Service: il servizio inventory Service memorizza le informazioni dell’inventario, velocizzando le operazioni di ricerca e accesso degli oggetti.
• Profile-Driven Storage: necessario per implementare una parte della logica di SDS.
• vSphere Auto Deploy: lo strumento per realizzare un’infrastruttura di deploy automatico degli host ESXi.
• Syslog Collector: il server fornito da VMware (che comunque non rimpiazza altre soluzioni o lo stesso Log Insight di VMware) per raccogliere log tramite protocollo syslog.
• ESXi Dump Collector: strumento per la raccolta dei log di supporto, o almeno dei dump degli host ESXi.
• Virtual Datacenter Service: nuovo servizio introdotto in vSphere 6.0.
• vFabric Postgres (opzionale se scegliete il database embedded): il database di vCenter nel caso si scelga di installarlo durante il vCenter all’interno della stessa macchina. Ovviamente si può usare anche un database server esterno, ma la novità è che ora sia la vCSA che la versione Windows utilizzano Postgres come DBMS embedded.

Anche in questo caso vi potranno essere nuovi servizi introdotti in versioni future.

Questa componente di management rimane non scalabile (almeno non nel modo della PSC), non replicata nei dati e con limitate e specifiche soluzioni di alta disponibilità. Varrebbero le stesse considerazioni di vCenter 5.5 dove quindi solo VMware HA potrebbe essere usato, ma in realtà pare che, in alcuni casi particolari, sarà supportato anche il nuovo multi-CPU VMware FT introdotto con vSphere 6.0. Dovrebbe essere anche gestibile all’interno di un cluster Failover Microsoft, ma anche in questo caso è meglio aspettare la documentazione del prodotto finale.

A partire da vSphere 6.0 non i vari servizi elencati in precedenza non saranno più installabili separatamente (come poteva avvenire fino a vCenter 5.5). Durante un eventuale aggiornamento, tutti i servizi saranno installati sulla macchina con il vCenter Server.

L’unica eccezione (in tutti i sensi) rimane il vSphere Update Manager (VUM), che può essere installato su macchina dedicata o separata e comunque rimane ancora un software solo per Windows e che utilizza ancora come database (anche nella versione embedded) solo SQL Server (o SQL Express nella versione embedded).

Scenari di deployment

Questi rimangono simili alla versione 5.x dove sostenzialmente vi erano solo due diversi scenari:

• Singolo sistem
• Più sistemi

Il secondo si articola poi in due altri scenari, rendendo quindi del tutto simile al caso del vCenter 5.5:

Per maggiori informazioni vedere questi due post (in inglese), rilasciati di recente, che descrivono in dettaglio i vari scenari:

• KB 2108548: List of recommended topologies for vSphere 6.0.x
• vSphere Datacenter Design – vCenter Architecture Changes in vSphere 6.0 – Part 1
• vSphere Datacenter Design – vCenter Architecture Changes in vSphere 6.0 – Part 2

Ma la prima grande novità è che ora i vari scenari sono identici sia che si utilizzi la versione installabile su Windows che si utilizzi la vCSA, infatti le opzioni di deployment sono del tutto equivalenti: versione virtual appliance (sulla sinistra) e versione Windows (sulla destra).

Gli scenari possibili dipendono solo da come viene gestita la componente di PSC:

• vCenter Server con un Embedded PSC
• vCenter Server con un PSC esterno

Per molti sistemi medio piccoli, la prima soluzione sarà più che sufficiente (soprattutto per i vari casi PMI italiani): un unico sistema (a questo punto magari vCSA, visto che ha le stesse funzionalità) per tutto. Sia nel caso che si scelta il vCSA o la versione Windows l’installazione (o il deployment per la vCSA) di “tutto in uno” è molto seplice e persino più veloce che nella versione 5.5.

In questi casi si può persino valutare se utilizzare un database embedded, che per entrambi i casi è diventato Postgres e ha nuovi limiti più alti (vedere i limiti di scalabilità), oppure un DBMS esterno (per la versione Windows: SQL 2008 R2, 2012 and 2014, Oracle  11g and 12c).

Notare che anche nel caso di avere un PSC embedded vi più essere il caso di più sistemi (nei casi multi site): i vari PSC saranno “collegati” tra di loro con il nuovo linked mode.

Installare il vCenter Server con la componente di Platform Services Controller embedded ha i seguenti vantaggi:

• La connessione tra vCenter Server e Platform Services Controller non richiede comunicazione di rete e si riduce quindi l’impatto di questa dipendenza.
• Nel caso si usino sistemi Windows, si risparmia almeno una licenza Windows (notare però che è pure possibile avere PSC e vCenter misti, uno su vCSA e uno su Windows o persino viceversa).
• Meno macchine da gestire.
• Non servirà alcun load balancer esterno per gestire più Platform Services Controller.

D’altra parte utilizzare un PSC embedded ha anche alcuni svantaggi che vanno considerati:

• La parte di Platform Services Controller comunque consuma risorse e puù essere richiesta anche da altri prodotti VMware… averla separata permette di condividerla e ottimizzare le risorse.
• Il numero massimo di Platform Services Controllers per ogni sito è otto (8). Su ambienti grandi è quindi necessario separarlo da vCenter Server.

La logica suggerita da VMware è di utilizzare l’installazione del PSC embedded quando si hanno singoli siti stand-alone e di medio-piccole dimensioni. Diventa comunque suggerito l’uso di un PSC esterno, nel momento in cui si iniziano ad utilizzare anche altri software che lo richiedono (vCenter Server, vRealize Automation, …) o dove vi sono configurazioni più complesse.

Notare che, esattamente come il SSO della versione 5.5, anche il PSC non richiede un DMBS esterno.

L’opzione di separare vCenter Server da PSC è sicuramente più adatta per grossi ambienti. Anche in questo caso è possibile avere database di vCenter embedded o esterni.

Separare il vCenter Server da Platform Services Controller comporta una serie di potenziali vantaggi:

• Meno risorse utilizzate, minore interferenza tra servizi e processi. Permette anche di calibrare le risorse per ciascun componente.
• Non si ha il limite di massimo 8 sistemi vCenter Server con Platform Services Controllers embedded.

D’altra parte avere un Platform Services Controller esterno può comportare alcuni possibili svantaggi:

• Dipendenza di rete forte da considerare.
• Più macchine e quindi (nel caso Windows) più VM da licenziare.
• Più macchine da gestire.

Notare che oltre al caso di sistemi misti Windows / vCSA è pure possibile avere sistemi misti dal punto di vista del deployment del Platform Services Controllers.

vCSA senza più limitazioni

Come già ribadito, finalmente la versione virtual appliance del vCenter 6.0 è del tutto equivalente alla versione installabile su Windows: stesso numero massimo di hosts, VM, cluster per vCenter, uguali funzionalità di linked mode (non più basate su ADAM e quindi portabili cross-platform), supporto IPv6, supporto a molti plugin e piena compabilità con PowerCLI.

Tra l’altro nel caso della vCSA tutti i limiti massimi sono raggiungibili anche con il database embedded (non così per la versione Windows con il nuovo database embedded, che ha limiti più ampi, ma minori della vCSA).

L’unico limite rimane la parte di VUM, che continua ad essere solo un servizio Windows e quindi non inglobabile all’interno della vCSA.

Curiosità della nuova vCSA è che rimane sempre basata su una SuSE (SLES 11 SP3), ma che ora ha una shell ufficiale (appliance shell) come pure di una interfaccia grafica per il deployment (questa per ora sembra essere solo per Windows) che permette, ad esempio di fare il sizing delle VM e il deployment dei vari componenti. Ma notare tutta l’installazione può essere fatta anche da script.

Anche il patching dell’appliance è stato migliorato. Già era un punto di forza per l’enorme semplicità, ma richiedeva di scaricare un file di grosse dimensioni. Ora invece sono disponibili patch più piccole e quindi plausibilmente più agili anche nella distribuzione (si pensi ai problemi degli ultimi mesi di bug legati ai software OpenSource).

Ribadiamo ancora la possibilità di mischiare anche componenti con Windows (ad esempio la parte vCenter) con componenti basate su vCSA (ad esempio la PSC)! Quindi grande flessibilità di scelta.

Rimangono dei limiti… beh… a parte VUM (o a qualunque software solo Windows da installare su server a parte) esiste ancora la limitazione dei database supportati, che si limita al solo Oracle (come DBMS esterno).

Scalabilità senza limitazioni?

The new vSphere 6.0 has increase the limits, also for the vCenter Center that now can handle 1000 hosts, 10000 powered on VMs (both number are the same of v5.5) and cluster with 64 ESXi nodes and 8000VMs per each cluster. Much interesting remain the possiblity to sizing the vCenter for tiny, small, medium, large environments (there was already something similar in previous version, but here it is improved) and of course to scale it on multiple systems as described before. Note that the embeded vPostgres on Windows is limited to 20 hosts and 200 virtual machines. The vCenter Server Appliance supports embedded vPostgres at full scale, 1000 host and 10,000 virtual machines and is the recommended database for the vCenter Server appliance. My wish is that next version of vCenter will be only a vCSA based solution, in order to make it scalable like the vRealize Operations 6.0 that have a great scale-out model, actually available only in the PSC part of vCenter. But how could be cool if also the other part can scale in the same way?

Deployment and installation

Installation could be perform with a wizard or thought scripted installation for both vCenter Server for Windows and vCSA in order to reduce the overall download time and improve automation capabilities respectively. Also the packaging is quite different, becoming more modular (with several msi for the Windows version), and also more small in footprint (the ISO of the vCenter 5.x has become really too big). For more information see also the Installation blog post.

Disponibilità

Inizialmente non sembravano esserci novità sul lato disponibilità del vCenter, ma emergono via via novità interessanti.

A parte il PSC che ha le sue soluzioni di alta disponibilità, la parte di servizi legata al vCenter Server può essere messa in alta disponibilità in vari modi:

• VMware HA (esattamente come in precedenza)
• Microsoft Clustering che tornerà ad essere supportato in vCenter Server 6.0 (e persino in vCenter Server 5.5 U3, quando uscirà).
• Il nuovo SMP-FT dovrebbe essere supportato solo in alcuni scenari, ma al momento bisogna aspettare la documentazione finale.

Andrea Mauro

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.