Fino alla versione 5.x di vSphere, il vCenter Server non era adatto ad implementare funzioni orientate al cloud, in particolare mancava di funzioni multi-tenant, ma soprattutto un concetto più generico come quello di virtual datacenter. A tale scopo, VMware ha introdotto vCloud Director che diventava lo strato di astrazione di un’infrastruttura vSphere atto per essere poi gestito e automatizzato in stile cloud.
Di fatto la vCloud Suite (che includeva vSphere e vCloud Director, più altre componenti) erano le fondamenta per creare un Software Defined DataCenter (SDDC).
Ma durante il VMworld 2013, VMware ha deciso per una nuova strategia riguardo vCloud Director (vCD) relegandolo praticamente solo ai vCloud provider, rendendolo meno strategico per i normali private cloud (e non a caso anche il nuovo percorso VCP-Cloud è cambiato sostanzialmente, dove ora la componente vCloud Automation Center la fa da padrone).Come viene colmato questo vuoto di funzionalità in VMware vSphere 6.0? Premesso che il vCloud Director continua ad esistere (nella versione 5.6 per i soli Service Provider) come pure la vCloud Suite (che però non include più vCloud Director), il nuovo vCenter Server ora ingloba alcune funzionalità di vCloud Director rendendolo decisamente più orientato al cloud (comunque non può ancora sostituire completamente un vCloud Director).
Tra le nuove funzionalità troviamo:
- Virtual Datacenter: simile a quanto già fornito in vCloud Director, ma con una serie di limitazioni (probabilmente risolte nelle prossime versioni).
- Policy Based Management: non è un segreto che oramai per VMware tutto deve essere gestito e controllato tramite policy… del resto rientra nella vision del SDDC.
- vApp Enhancement: le vApp esistono sia in vSphere che in vCloud Director dove sono più ricche perché incorporano molte più informazioni. Per ora le nuove vSphere 6 vApp possono includere la network topology e, in futuro, diventare equiparabili a quelle di vCloud Director.
- Multi‐Site Content Library: contenitore di VM templates, vApps, immagini ISO condivisibile e cross vCenter.
Virtual Data Center (VDC) and Policy Based Management (PBM) will NOT be included in the vSphere 6.0 GA release.
Bisogna aspettare la GA, ma al momento pare che il rilascio di queste feature sia rimandato, per poter testare maggiormente i prodotti che li andranno ad utilizzare.
Alcuni di questi oggetti, in particolare i Virtual Datacenter e le Content Library sono facilmente individuabili nell’inventario di vCenter:
E per chi prima usava vCloud Director nel proprio cloud privato? Beh… è decisamente ora di passare a vSphere 6.0 ed eventualmente a vRealize Autormation (nuovo nome di vCloud Automation Center).
VMware will move functionality that is today part of vCD into its virtualization platform (vSphere and vCenter Server). In addition, some functionality will be pushed into the vRealize Automation (vRA) product line.
Tra le funzionalità cloud, ovviamente, vi è anche l’integrazione con vCloud Air (in precedenza noto come vCloud Hybrid Service) usando un vSphere Web Client Plug-in (scaricabile ed installabile direttamente con un account di tipo SSO admin, utilizzando il vSphere Web Client). Questo però era già in parte presente nelle versioni precedenti, quindi non è una novità in assoluto.
VMware vSphere Virtual Datacenter
Questo nuovo oggetto di vCenter, chiamato Virtual Datacenter, è un contenitore di risorse, tipicamente cluster vSphere.. Diventa anche il punto di integrazione primario tra diversi prodotti della famiglia vCloud Suite.
In questa nuova visione ed implementazione di un Software Defined Datacenter vi sono chiaramente due diversi ruoli rappresentati nella figura seguente:
Questi ruoli richiamano quello di provider e consumer tipici di qualunque architettura cloud. In questo il Virtual Datacenter è un provider di risorse che le aggrega in pool.
Al momento le risorse sono aggiunge a questi pool in qualità di vSphere DRS cluster. Un Virtual Datacenter può “pescare” risorse all’interno del pool, con l’unico limite che per ora tutte le risorse di un pool devono essere controllate da uno stesso vCenter. Ma in futuro sarà anche possibile avere più vCenter all’interno dello stesso sito.
Come già detto, questo concetto di è del tutto simile ad un vCloud Director Provider Virtual Datacenter (PvDC).
Sopra questo strato vi possono essere altri strumenti come vRealize Automation che implementino qualcosa di simile alle organization vDC di vCloud Director. Oppure semplicemente le varie vApp nel caso di un’infrastruttura a singolo tenant.
La creazione di un nuovo Virtual Datacenter è molto semplice e i pre-requisiti sono simili a quelli di vCloud Director (ovviamente in questo caso non vi sarà un agente aggiuntovo, dato che l’agente utilizzato rimane quello del vCenter Server):
- Il cluster vSphere deve essere abilitato per il DRS (in modalità semi-automatic o fully-automatic)
- Host standalone non possono essere aggiunti direttamente ad un Virtual Datacenter
In realtà i requisiti di vCloud Director erano molti di più (ad esempio servirano i vDS già configurati, la componente di vCloud Network and Security, …), ma era anche più flessibile, ad esempio era possibile aggiungere un semplice resource pool e non l’intero cluster DRS.
Per creare un nuovo Virtual Datacenter in vCenter bisogna utilizzare il Web Client e :
- Creare un nuovo Virtual Datacenter
- Aggiungere un cluster esistente alle risorse del Virtual Datacenter
Per poter rimuovere risorse da un Virtual Datacenter bisogna procedere nel seguente modo:
- Per togliere un singolo host: mettere l’host in maintenance mode, ovviamente e VM rimarranno nel VDC, visto che saranno state migrate su altri nodi rimasti.
- Per togliere un cluster: basta rimuovere il cluster dalle risorse del VDC, ma in questo caso le VM rimarranno nel cluster e saranno rimosse dal VDC (a meno di migrarle prima in un altro cluster).
VM Policy Based Management
Nel nuovo vCenter Server vi sono diverse policy, del resto come detto in precedenza tutto viene incentrato sulle VM e lavorare con le policy a questo livello permetterà poi di trasferire queste regole quando si migreranno le VM, anche tra cloud diversi.
Ma tornando a vSphere 6.0, si possono notare due diverse nuove voci: VM Placement Policies e Anti-Affinity Policy.
Entrambe fanno pare un nuovo meccasismo di gestione delle policy chiamato policy-based automation (PBM) for VM workload placement che può fornire diversi tipi di regole:
- PBM – Tag-Based Policies
- PBM – VM Anti-Affinity Policies
Ma prima bisogna spiegare cosa realmente è una placement policy? Di fatto è una o più regole per dedidere su quali risorse allocare una particolare VM. Concettualmente le VM Storage Profile policy (introdotte in vSphere 5.0) potrebbero rientrare in questa nuova categoria, ma la verità è che, per ora, rimangono due concetti separati.
Poichè un Virtual Datacenter può essere composto da più risorse (più cluster DRS) queste policy permettono di scegliere come posizionare le VM.
Ad esempio in base a particolari tag. Notare che i tag non sono un concetto nuovo in vSphere, dato che sono sempre stati presenti nel Web Client, fin dalla versione 5.1. I tag sono una generalizzazione dei campi custom utilizzabili nel vSphere Client per aggiungere informazioni alle VM. Con la grossa differenza che nel Web Client è possibile taggare qualunque oggetto e anche con tanti tag differenti
In vSphere 6.0 i tag possono ora essere raggruppati in diverse categorie e anche essere associati a particolari tipi di oggetti ad esempio VMs o vApp), con tanto di possibilità di avere singoli tag o più tag per ogni oggetto (si potrebbe ad esempio usare questa funzione per crearsi un inventario software di ogni VM).
Con policy basate su tag si potrebbe ad esempio verificare la compliance del software ed assicurarsi che, ad esempio, VM con Windows Server finiscano solo su cluster con host licenziati.
Vi sono le Anti-Affinity policy che corrispondono esattamente alle regole di anti-affinity di un cluster DRS o SDRS: se volete tenere separare due VM due diversi gruppi di risorse per implementare, ad esempio, una fault domain geografico o una resilienza a livello di rack. Actually remediation of those kind of policies are limited: there is the ability to execute manual remediation per VM (like was with first version of VM Storage Profile), but in future roadmap we can expect a fully automated remediation (if desidered).
Content Library
Questo nuovo concetto deriva dal concetto di Catalog esistente in vCloud Director (strano che sia stato utilizzato un nome che richiama più la stessa funzionalità di System Center VMM). Tramite le vCenter Content Library provides è possibile gestire in modo semplice e centralizzato template di VM, vApp, immagini IS, script e tutti quegli oggetti semistatichi utili normalmente ai vSphere Admins (ma anche ai VM admins).
Le principali funzioni delle Content Library sono:
- Memorizzare e gestire contenuti in modo centralizzato
- Fornire funzioni avanzate per le gestione dei template in vCenter
- Condividere contenuti, in modo da salvarli una volta sola, ma poi riutilizzarli tutte le volte che servono
- Utilizzare un modello Publish/Subscribe (esattamente come nei Catalog di vCloud Director)
La configurazione di una nuova library è molto semplice ed è già possibile pubblicarne il contenuto in questa fase iniziale. Oppure è possibile sottoscriversi ad un contenuto di una library giù esistente.
Per una nuova library è possibile scegliere se memorizzarla su un datastore o un filesystem locale o un percorso di rete NFS (purtroppo non è supportato direttamente il protocollo SMB).
Per maggiori informazioni, vedere anche questo post (in inglese): vSphere 6.0 blog – Multi Site Content Library.