vSphere 6 – Platform Services Controller (PSC): Design

In vSphere 6.0 l’architettura è  cambiata abbastanza e ci sono alcuni nuovi concetti da imparare. In questo post illustrerò i cambi nell’architettura e mi concentrerò sul Platform Services Controller (PSC) poiché determinerà come installerete o aggiornerete il vostro ambiente. Troverete molti altri blog che parlano del PSC, l’obiettivo di questo post è quelli di aiutarvi dandovi un’idea di quali sono i cambiamenti dell’architettura in vSphere 6.0 e quali sono le decisioni di design che si devono prendere in relazione al Platform Services Controller (PSC) quando si installa (o aggiorna) un ambiente per vSphere 6.

Nelle prime versioni, il lato applicativo (Management, Operations ecc.) era accorpato con la sicurezza e l’autenticazione. Con la versione 5.1 e successive, e l’introduzione del SSO, abbiamo iniziato a vedere la separazione tra i servizi di sicurezza e l’applicativo. Con vSphere 6.0, questa transizione è completata e l’architettura è stata divisa in due entità separate: un “Management Node” e il “Platform Services Controller” (PSC).

2

Il Management Node contiene tutte le applicazioni e i servizi dedicati a far funzionare e gestire l’ambiente:

•vSphere Management

•Infrastructure Monitoring

•APIs ecc.

Invece il Platform Services Controller (PSC) contiene i componenti per la sicurezza dell’infrastruttura.

•Single Sign On

•Licensing

•Certificate Management

•Identity Management etc.

3

E’ importante sapere che, sebbene le decisioni sulla topologia di installazione per il  Platform Services Controller potrebbero essere simili al SSO, si tratta di molto di più del semplice SSO: ci sono molti più servizi, che lo rendono un grande aggregato di servizi. In passato, molte persone pensavano che separare il SSO fosse dispendioso per un solo servizio. Ora ci sono molti servizi aggregati per cui avrebbe senso nella maggior parti dei casi.

Il Management Node ha gli stessi componenti usati in passato per cui il processo decisionale per essi è simile al passato. Il Platform Service Node, however, è un cambiamento di cui vale la pena parlare perché impatta decisioni di design.

Embedded o esterno?

Questa domanda viene fatta durante l’installazione di vCenter ed è qualcosa che dovrebbe essere decisa prima di arrivare a questo punto. Per quale motivo? Perchè una volta presa questa decisione sarete vincolati ad essa. Cambiarla richiederà una reinstallazione. Quale è la differenza? Le funzionalità sono le stesse. “Embedded” significa che l’installazione verrà fatta sullo stesso serve come veniva fatto nel “Simple Install” in vSphere 5.x, mentre la modalità “External” è simile al “Custom Install” e significa avere un server separato per l’installazione (senza vCenter e i suoi componenti).

Ora che sappiamo questo quali sono i punti principali da considerare?

Scalabilità

La domanda importante qui è: Quanti vCenters o “PSC Enabled Solutions” avremo nell’ambiente? Con “PSC Enabled Solutions”, ci si riferisce a quelle soluzioni che useranno o possono utilizzare il PSC per autenticazione o altri servizi come per esempio vRealize Automation.

Pensate a lungo termine. Se siete un organizzazione che vuole avere siti geograficamente distribuiti, che vuole resilienza e che ha vRealize Automation o prodotti simili, un PSC Esterno sarebbe la scelta da prendere. Dovreste possibilmente considerare anche un set up con alta affidabilità come fatto da molte organizzazioni per il SSO.

Se avete un singolo sito e prevedete che la vostra organizzazione non andrà oltre gli 8 vCenter o PSC Enabled solutions, allora potete procedere tranquillamente usando l’installazione con il PSC Embedded. Comunque, è importante ricordare che VMware attualmente raccomanda di non superare gli 8 PSCs.

Vale la pena ricordare che è anche possibile una configurazione ibrida, ad esempio si può avere un mix di deployment PSC embedded o esterni, in base a quello che si adatta meglio alla vostra implementazione. Basta essere consapevoli di averne un numero ragionevole. Inoltre, tenete a mente che se si sceglie la versione appliance, il PSC è già lì. Non importa se i PSC siano embedded, esterni o ibridi (Windows o Appliance), tutti si replicano tra loro in modo automatico e sono mantenuti in sincrono.

1

Così come potreste avere diversi vCenters che lavorano con un singolo SSO, un singolo PSC è sufficiente per far funzionare il vostro intero ambiente.

Server Loading

Ora che ci sono ancora più componenti in bundle nel PSC, dipenderà dalle vostre politiche per determinare se valga la pena o meno separare il PSC dal server vCenter. Separare richiede una licenza aggiuntiva di Windows (non è un problema se si sta utilizzando la versione appliance), ma comporterà un minore  utilizzo delle risorse server. Tuttavia, se le regole all’interno della vostra organizzazione prevedono meno server ma di maggiori dimensioni, mantenere insieme le componenti vi fornirà un minor overhead di gestione.

Una volta prese la vostra decisione, l’installazione è piuttosto semplice; basta scegliere l’opzione quando appare. Scegliere l’opzione embedded è come eseguire la “Simple” install. Se scegliete l’opzione external, non sarete in grado di installare vCenter sullo stesso server per cui vi servirà un’altra VM per effettuare l’installazione. Una volta che almeno un PSC è stato deployato, potrete andare avanto con l’installazione di vCenter. Durante l’installazione, quando vi verrà richiesto, puntate al server che esegue il ruolo PSC; per il resto, l’installazione è la stessa.

 

Leave a Reply

Your email address will not be published. Required fields are marked *