Home > vmware, vsphere > vCenter 6.0 – le principali architetture di deployment

vCenter 6.0 – le principali architetture di deployment

Anche se non è ancora disponibile la release definitiva, grazie ad alcuni documenti ufficiali rilasciati da VMware (in particolare la vCenter Server 6.0 Deployment Guide) è possibile far luce sulle nuove architetture possibili per vCenter 6.0

In vCenter 6.0 i componenti che costituiscono l’installazione sono stati raggruppati in due entità:

  • il vCenter Server
  • il Platform Service Controller (PSC) che comprende il vCenter Single Sign-On, il License Server e la VMware Certificate Authority (VMCA)

E’ cosi’ possibile avere due tipologie di installazione:

  • embedded: tutti i componenti, tranne eventualmente il database, sono installati nella stessa macchina
  • external: il vCenter Server è installato in una macchina e il PSC in un’altra

L’installazione di tipo embedded è raccomandata per le configurazioni standalone con un solo vCenter e senza necessità di replicare il PSC, mentre quella di tipo external è necessaria nel caso di più’ vCenter, di necessità di replicare il PSC o in caso di SSO esterno.

Requisiti

Ci sono alcuni requisiti comuni sia all’installazione del vCenter Windows che per la vCenter Server Appliance (VCSA):

  1. DNS: deve essere funzionante la risoluzione DNS del FQDN, dello short name e il reverse lookup di tutti i sistemi
  2. orario: è necessario che l’ora di tutti i sistemi sia correttamente sincronizzata
  3. password: la password del Single Sign-on deve contenere solo caratteri ASCII

Di questi tre requisiti, il terzo secondo me è da tenere ben presente per evitarsi alcuni “mal di testa” alla SSO 5.1/5.5

 

vCenter su Windows

Per quanto riguarda l’installazione Windows una delle cose più’ interessanti, secondo me, è l’abbandono di SQL Express a favore di PostgreSQL come database locale: con PostgreSQL il nuovo limite supportato è di 20 hosts e 200 VM, decisamente più’ interessante del vecchio limite di 5 host/50VM.
L’aggiornamento alla 6.0 può’ avvenire solo da una 5.0 o successiva e, in caso fosse in uso il db SQL Express, il processo di upgrade lo migrerà a PostgreSQL

 

vCenter Server Appliance

Anche la vCenter Server Appliance utilizza PostgreSQL, ma senza limitazioni (supporta quindi fino a 1000 host/10000VM) e addirittura viene deprecato (anche se ancora supportato) l’uso di database esterni.
Il deploy dell’appliance è possibile solo su host ESXi 5.0 o superiori e l’upgrade è possibile solo dalla versione 5.1 update 3 o superiore.

 

Le architetture di riferimento

Considerando le nuove caratteristiche, VMware individua 6 architetture di riferimento:

  • nuova installazione embedded: è la tipologia piu’ semplice di installazione, raccomandata per ambienti standalone
  • upgrade di un sistema standalone (tutti i componenti sono installati su un’unica macchina): il processo di upgrade si occupa di aggiornare tutti i componenti e di migrare l’eventuale SQL Express a PostgreSQL
  • nuova installazione external: raccomandata per tutti casi tranne lo standalone, è necessario installare prima il PSC e successivamente il vCenter Server, di fatto eseguendo due volte il wizard di installazione
  • upgrade con Single Sign-On esterno: in questo caso è necessario prima aggiornare il Single Sign-On, trasformandolo in PSC e successivamente aggiornare il vCenter
  • nuova installazione Single Sign-On in alta affidabilità: raccomandata in caso di vCenter Server multipli o in caso di requisiti di alti livelli di uptime del Single Sign-On. Questa architettura prevede di installare piu’ PSC dietro a un load balancer opportunamente configurato
  • upgrade di un Single Sign-On in alta affidabilità: in questo caso è necessario aggiornare prima tutti i Single Sign-On a PSC, configurare correttamente il load balancer e aggiornare il vCenter Server

Ovviamente vale la pena ricordarsi che in alcune situazioni l’HA del cluster vSphere puo’ essere sufficiente per garantire il livello di uptime desiderato.

  1. 9 Mar 2015 at 10:21

    “la password del Single Sign-on deve contenere solo caratteri ASCII”

    EH?! WTF? Molti sysadmin europei fanno apposta a mettere caratteri non-ASCII nelle password. Sara’ il caso di scriverlo a caratteri cubitali.

    Quindi io che mettevo sempre つづく come password devo sceglierne un’altra :)

    • 9 Mar 2015 at 10:27

      Gia’… quando l’ho letto ho avuto la tua stessa reazione…

  2. Luca Dell'Oca
    9 Mar 2015 at 13:12

    Kudos a Luigi per la citazione presa a piene mani dagli anime :)

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: