Con l’uscita di vSphere 6.0, molti vorranno provarlo in ambiente di laboratorio o test (prima di portarlo direttamente in produzione). Per la creazione di un lab è possibile continuare ad utilizzare le pratiche suggerite per quanto riguarda vSphere 5.x (vedere ad esempio Realizzare un lab vSphere 5): o si utilizzano almeno 2 server fisici (meglio 3 se volete provare anche VSAN) o, più realisticamente, si lavora in un ambiente nested (all’interno di un ambiente di virtualizzazione) sfruttando un server ESXi o una macchina con Workstation (o Fusion).
Ovviamente esistono anche altri modi per testare i nuovi prodotti, dei quali i VMware Hands on Labs rappresentano una valida alternativa, considerando che sono comunque ambienti sì limitati, ma reali (benché nested)… quindi è possibile ignoare la traccia proposta dal lab e giocare con lo stesso… anche “romperlo”, tanto basterà ricaricarlo di nuovo per partire in un ambiente pulito.
Uno dei problemi che si hanno con il nuovo vSphere 6 è che legato ai requisiti minimi, che non solo sono stati aumentati (in particolare per ESXi) ma sono persino diventati stringenti e mandatori! L’installazione NON procede proprio se non sono soddisfatti i requisiti minimi… solo dopo è possibile “limare” il proprio ambiente cercando di ridurre qualche cosa (normalmente l’unico spazio di manovra è sulla RAM).
ESXi
Il nuovo ESXi 6.0 ha dei requisiti di tutto rispetto:
- 1 GB di spazio di disco (si consiglia in realtà di più, ma con 1 GB o poco meno è possibile creare il layout delle partizioni richiesto al funzionamento di ESXi)… ovviamente poi c’è da pensare allo spazio per le VM
- 4 GB di RAM (funziona anche con 4000MB, ma con meno potreste avere problemi), almeno durante l’installazione
- 2 core o 2 CPU
- Workstation 9, 10, 11 (ESXi 5 funziona, anche se la versione 11 ha un tipo nuovo chiamato ESXi 2015) oppure ESXi 5.5 (utilizzando ESXi 5 come tipo guest e controllando da vSphere Web Client che l’opzione di nested VT sia attivata per il processore)… oppure anche versione recenti di Fusion
Notare che in ambiente virtuale, ESXi non solo include già le VMware Tools (comodo ad esempio per spegnerlo), ma risulta persino MOLTO veloce nell’avvio, in meno di 30 secondi, a prescindere dal tipo di disco, avrete ESXi up and running (ovviamente se mantenete i 4 GB minimi richiesti).
Con meno di 3.9 GB, durante l’installazione della GA avrete un messaggio bloccante che non avete rispettato i requisiti minimi. Per curiosità nella RC in realtà succedevano stranezze tipo che il modulo e1000 (da usare in ambiente virtualizzato) non veniva caricato:
In realtà anche la GA con meno di 3.8 GB può avere comportamenti molto strani durante l’installazione. Molti moduli potrebbero non essere caricati correttamente. Oppure potrebbe rimanere bloccato a tempo indeterminato nella fase “user loaded successfully” phase (se tentate di installarlo con 2.5 GB di RAM).
Dopo l’installazione, con 3.2 GB di RAM si riesce ad avviare ESXi (con un po’ più di tempo)… Con meno di 3 GB il tempo diventa potenzialmente inaccettabile e comunque potrebbero iniziare seri problemi nel caricamento dei moduli (in ALT+F12 potreste vedere alcuni errori seri). Quindi il mio consiglio è rimanere sopra i 3 GB di RAM (+ la memoria che vi potrebbe servire per delle VM dentro l’ESXi virtuale).
In teoria si potrebbe cercare di disattivare alcuni servizi (alcuni sono visibili nella GUI in Configuration / Security Profile, molti altri sono visibili solo da CLI in /etc/init.d), ma non sembra cambiare molto la quantità di RAM utilizzata.
Ho anche provato a rimuovere e disattivare alcuni moduli del vmkernel (ad esempio quelli di tutte le schede FC)… il comando è il seguente (e chiede poi un reboot):
esxcfg-module -d module_name
Però qua si risparmiano veramente KB o pochi MB di RAM, quindi non so quanto nel possa valere la pena.
vCenter Windows
I requisiti minimi rimangono quelli di vCenter 5.5: ossia almeno 8 GB di RAM e 2 vCPU. L’installazione NON parte se non sono soddisfatti questi requisiti minimi. Ma dopo l’installazione è possibile ridurre la quantità di memoria con lo scotto di rendere più lento il sistema e molto più lento l’avvio dello stesso.
Come sistema operativo consiglio Windows Server 2012 R2 che presenta comunque il vantaggio di essere molto veloce nell’avvio (non vuol dire che i servizi di vCenter saranno poi altrettanto veloci!).
Per una soluzione di vCenter “embedded” su un singolo sistema Windows, con tanto di database e VUM server, serviranno almeno 6.8 GB di RAM per avere un ambiente un minimo “usabile”.
vCSA
L’uso dell’appliance virtuale è sicuramente una valida alternativa (se non altro per l’enorme velocità di deployment). I requisiti minimi sono documentati nell’articolo di KB 2106572 (VMware KB: Minimum requirements for the VMware vCenter Server 6.x Appliance), ma sono di fatto quelli della versione Windows: almeno 8 GB di RAM e 2 vCPU.
Con la versione 6.0 la vCSA può avere diverse modalità di deployment, ma in un lab tipicamente verrà installata in modalità “embedded node” (e questa guida può aiutare). Il principale problema che si potrebbe avere è che non è supportata (e non è proprio immediata) l’installazione della vCSA su VMware Workstation (o Fusion). Questo però il nuovo wizard di deployment si aspetta un ESXi come destinazione!
In realtà è ancora possibile installare la vCSA su un ambiente Workstantion (o Fusion) e basta seguire questa guida.
Il trucco è prendere il file OVA dalla ISO della vCSA (nella versione 6.0 viene solo distribuita come ISO): il file si chiama vcsa/vmware-vcsa e va prima rinominato come vmware-vcsa.ova in modo che Fusion o Workstation lo possano riconoscere ed importare. A questo punto è improtante NON accendere la VM. Questo perché partirebbe un wizard di inizializzazione alla ricerca di parametri di configurazione che non sono ancora stati passati.
Per fornire questi parametri si può utilizzare un trucco come descritto in questo post: Installare vCloud Director in un lab.
O meglio ancora, modificare il file VMX della vCSA aggiungendo le opportune righe con i parametri del vostro ambiente. Questi sono un possibile esempio:
guestinfo.cis.deployment.node.type = "embedded"
guestinfo.cis.vmdir.domain-name = "vsphere.local"
guestinfo.cis.vmdir.site-name = "Site-Name"
guestinfo.cis.vmdir.password = "VMware1!"
guestinfo.cis.appliance.net.addr.family = "ipv4"
guestinfo.cis.appliance.net.mode = "dhcp"
guestinfo.cis.appliance.root.passwd = "VMware1!"
guestinfo.cis.appliance.ssh.enabled = "true"
Per maggiori informazioni è possibile leggere questo post.
A questo punto è possibile accendere la VM e aspettare che venga configurata. Dopo l’inizializzazione è possibile ridurre i parametri di memoria della VM. Con 7.5 GB la VM parte ancora con tempi ragionevoli… con meno tende a diventare troppo lenta e a non caricare correttamente i servizi. Del resto l’uso della memoria è molto “spinto”:
Vero che c’è molta cached memory, ma serve anche per rendere accettabile il comportamento del sistema. Solo nel caso abbiate dischi SSD si potrebbe provare a scendere ulteriormente con i parametri di memoria..
Ma in questo caso è opportuno controllare in console (usate ALT+F2 e poi ALT+F1) che tutto venga avviato correttamente (in realtà in una configurazione embedded non tutti i servizi vengono avviati).
Per cercare di “limare” un po’ la memoria si potrebbero disattivare dei servizi, ma la verità è vi sono pochi servizi Linux da disattivare e pure quelli di vCenter (visibili dal Web Client) sono nella maggior parte necessari (e alcuni come Auto Deploy sono già disattivati):
Si gioca comunque si qualche MB di RAM che si va a risparmiare.
Per quanto riguarda lo spazio su disco, utilizzando il thin provisioning, prevedere almeno 16 GB di spazio consumato.
Conclusioni
Nella versione RC era possibile “spremere” di più sia ESXi che la vCSA… ma siamo comunque molto lontani dagli ambienti realizzabili con la 4.x dove bastava poco più di 1 GB di RAM per ESXi e 4 GB per il vCenter Windows. Con i nuovi requisiti può risultare molto difficile avere un lab su un portatile, a meno di avere almeno 16 GB di RAM.
Gli hands on lab, o altre soluzioni di tipo hosted (ci potrebbero essere interessanti annunci nel prossimi mesi) potrebbero diventare sempre più popolari, sia per la velocità di fruizione (non tanto del lab, ma almeno di tutto il tempo di provisioning che vi risparmiate), sia per accesso a molte tecnologie (incluse quelle di partner di terze parti).
E per quanto riguarda Autolab? Questo potente tool di deployment e provisioning è ancora alla versione per vSphere 5.5, ma so che l’autore vi sta lavorando e quindi aspettatevi interessanti novità nel futuro.