mercoledì 1 marzo 2017

REST API con vcenter 6.5 parte 2

Nel primo articolo di questa serie , abbiamo visto come utilizzare le vcsa REST API con il client POSTMAN.
Nell'ultima parte del post abbiamo creato una nuova VM, inserendo manualmente le string che indicano il Guest OS type,il datastore,il folder, ad il resource pool.
Ora proviamo ad utilizzare gli esempi presenti nella collection vSphere Automation REST Samples, che, come indica la descrizione, utilizzerà alcune variabili d'ambiente popolandole automaticamente attra verso javascript. Alcune variabili dovranno essere popolate manualmente eccole:




Il sample VM CREATE WITH DEFAULTS, raggruppa tutte le API CALLS per la creazione di una VM, esso necessita di ulteriori variabili d'ambiente popolate (datastore, vm folder,  resource pool).

Dopo aver eseguito il login, passiamo al METODO GET find datastore, il quale ricerca un datastore inserito manualmente (Datastore0 nelnostro esempio) e attraverso la  call postman.setEnvironmentVariable(key, value) imposta la variabile datastore, che verrà poi utilizzata dalla request CREATE WITH DEFAULTS.




Le variabili necessarie da quest'ultima request sono datastore, VM folder e resource pool, tutte vengono popolate automaticamente con le REQUEST FIND DATASTORE; FIND RESOURCE POOLS e FIND VM FOLDER




REST API con vcenter 6.5 parte 1

La versione 6.5 di vcsa sono state introdotte alcune API REST, vediamo come utilizzarle.
Oltre alle API sono stati creati alcuni SDK per utilizzare le API da vari linguaggi (Java, Python, .NET, Perl, Ruby) o da un semplice client REST come postman.
Per inziare, installiamo postman, scarichiamo il SDK per REST ed importiamo in postman i due file json  che troviamo in VMware-vSphere-Automation-SDK-REST-6.5.0\client\samples\postman
Per importarle basta lanciare postman, cliccare import > import file> choose files > e selezionare i 2 files json
Ora, nel nostro postman troveremo 2 nuove collezioni:
Ora, esplorando la libreria vSphere Automation REST Resources troviamo diverse richieste, REST, ordinate e raggruppate in folder, che andremo ad inviare al nostr vcenter.
Spesso le richieste fanno uso di variabili racchiuse in doppia parentesi graffa,
ad esempio {{vc}} 
Cliccando sulla rotellina in alto a destra, possiamo preimpostare il valore di alcune di queste variabili:


Ora, iniziamo ad utilizzare le richieste.
Innazi tutto dobbiamo autenticarci al  vcenter: entriamo nel folder Authentication e selezioniamo login
Notiamo che in alto a destra abbiamo selezionato il set di variabili creato in precedenza.
Esaminando la richiesta di login, ci rendiamo conto che stiamo usanod un metodo Post verso la URL  /rest/com/cmware/cis/session (in vcenter) con un'autenticazione di tipo basic, utilizzando il nome del vcenter, llo user name e la password attraverso le variabili d'ambiente.




Se il login non va a buon fine, basta disabilitare la verifica SSL in  File > Settings > General tab > SSL certificate verification, turn off (serve il restart di postman)
Dopo esserci loggati, è il momento di esplorare l'ambiente: possiamo avere la lista degli host utilizzando la richiesta LIST nel folder HOSTS, oppure l'elenco dei datastore o delle VM 

Per avere qualche dettaglio più approfondito, potremmo cliccare VM > get DETAILS
ma, attenzione, nella URL dovremo inserire il VM ID che abbiamo ricavato dal comando precedente (VM > LIST)


Possiamo anche creare una VM, utilizzando il metofo POST, VM > CREATE WITH DEFAULTS. La gran parte dei devices assegnati alla VM si basa sui default impostati per il tipo di guest OS scelto. Importante è preimpostre alcuni parametri nella sezione 'body' come il Guest OS type,il datastore,il folder, ad il resource pool.






giovedì 14 luglio 2016

VSAN IOPS limit

Impostando un IOPS limit per un oggetto in VSAN (tipicamente un vmdk), andiamo a limitare le risorse (IOPS) consumabili da un VM. La IO size per questo parametro è impostata a 32KB, ciò significa che se la nostra VM avrà un IO size da 64KB e noi imposteremo un IOPS limit a 10,000 IOPS, otterremo che quellaVM potrà, al massimo, eseguire 5000 IOPS.


giovedì 16 giugno 2016

VSAN deduplication and compression

Virtual SAN 6.2, nella versione all flash,  introduce le features di deduplica e compressione che permettono di ridurre lo spazio fisico occupato sulle SSD. Si abilitano a livello globale, per l'intero cluster, utilizzando un semplice drop-down menu. Abilitandolo verrà riformattato l'intero datastore, senza provocare nessun downtime per le VM in esso contenute. Non è possibile abilitare le features per singole VM.
Le operazione di deduplica e compressione vengono eseguite dopo aver ottenuto la write acknowledge in modo di minimizzare l'impatto sulle performances.
La deduplica avviene nel momento in cui i dati  passano dalla cache ai dischi capacitivi (de-staging), utilizzando un algoritmo SHA-1 che calcola una ash per ogni blocco da 4K e riduce ad unico blocco tutti i  blocchi identici all'interno di un singolo disk group, le copie identiche distribuite su diversi disk.group non vengono deduplicate.
Dopo aver deduplicato e prima che il blocco venga scritto sui dischi capacitivi,  interviene l'algoritmo di compressione (LZ4) sui blocchi da 4K comprimibili a 2K. Se il fattore di compressione dovesse essere inferiore, il blocco non vine compresso in quanto l'utilizzo di risorse computazionali per comprimere/decomprimere il blocco non varrebbe il minimo risparmio di spazio.
I metadati necessari alle 2 features vengono distribuiti su tutti i dischi capacitivi (occupando circa il 6% dell spazio disponibile) impedendo la rimozione di un singolo disco (se un disco si guasta, l'intero dik group verrà ricostruito)

domenica 15 maggio 2016

vsanSparse: Virtual SAN 6.0 Snapshots





Le snapshot ‘tradizionali’: quelle fatte con vSphere su VM ospitate in datastores VMFS, NFS senza VAAI-NAS e VSAN 5.5 vengono dette vmfsSparse o redo log. Utilizzano una unit size di 512 bytes.  Quando viene fatta una snapshot di una VM viene creato un child delta vmdk ed il vmdk superiore (parent) viene considerato una copia Point in Time (PIT).
Nel nuovo delta verranno eseguite tutte le operazioni di tipo write, mentre nei diversi PIT verranno eseguite le read:



Con l’introduzione di VSAN 6.0, viene introdotto un nuovo formato per le snapshot chiamato vsanSparse che garantisce delle performances nettamente migliori rispetto al vmfsSparse utilizzando la tecnica del redo-log associata ad una cache in memoria.
Quando viene fatta una snapshot di tipo vsanSparse viene creato un child delta vmdk ed il vmdk superiore (parent) viene considerato una copia Point in Time (PIT), fin qui, nulla di diverso rispetto al formato tradizionale.
Un oggetto di tipo VMDK delta (trattandosi di VSAN dobbiamo parlare di oggetti e non di files), è composto da un insieme di grains a loro volta costituiti da blocchi che contengono i dati. La allocation unit size è di 512 bytes, ciò significa che se la VM farà una write da, supponiamo, 8KB, questa verrà presa in carico dal vsanSparse driver che la scomporrà in 2 chunks da 4KB a loro volta composti da 8 grains da 512 bytes Dopo aver ottenuto l’acknowledge, lo stesso vsanSparse driver scriverà il riferimento del blocco scritto in una ‘in-memory’ metadata cache, e successivamente confermerà l’acknowledge al guest OS.
Così facendo, ogni lettura verrà fatta solo sul delta contenente l’ultima versione del blocco indicato appunto dalla ‘in-memory’ metadata cache migliorando le performances in maniera sensibile. Chiaramente se nella cache non abbiamo nessuna info circa il blocco letto (cache miss) il vsanSparse driver dovrà leggere tutti i delta per trovare l’ultima versione del dato, come avviene nel vmfsSparse tradizionale.


martedì 26 aprile 2016

VSAN 6.2 Hands-On-Lab

Spesso ricevo richieste sul come impostare un laboratorio per testare le funzionalità di VSAN.
Essendo un prodotto software con dei prerequisiti HW non indifferenti, io raccomando sempre di testarne le funzionalità utilizzando i VMware Hands-on-labs
Trattasi di una serie di laboratori preimpostati e gratuiti che permettono di testare diversi prodotti VMware e non solo.
In particolare, il lab HOL-SDC-1608 permette di testare tutte le funzionalità di VSAN 6.2
E' suddiviso in 9 moduli, eseguibili in qualsiasi ordine, in modo di poter testare solo ciò che interessa, i moduli sono:

Module 1 - Virtual SAN 6.0 Setup and Enablement (30 Minutes)
Module 2 - Virtual SAN 6.0 with vMotion, Storage vMotion and HA Interoperability (60 minutes)
Module 3 - Virtual SAN 6.0 Storage Level Agility (60 minutes)
Module 4 - Useful CLI Commands (30 minutes)
Module 5 - Virtual SAN 6.0 Monitoring (30 Minutes)
Module 6 - Virtual SAN 6.0 Troubleshooting (60 minutes)
Module 7 - Extending Virtual SAN with Additional File Services (60 minutes)
Module 8 - Securing Virtual SAN Data with Encryption (45 minutes)
Module 9: Identify and Resolve Virtual SAN Issues (30 minutes)

Come vedete, per ogni modulo vengono indicata una stima relativa ai minuti necessari al completamento, tenete conto che per ogni laboratorio avete comunque a disposizione 90 minuti.
Navigando all'interno del laboratorio, troverete un manuale dettagliato che illustrerà tutti i passi per completare il laboratorio nonché tutte le info utili necessarie a capirne le features e le potenzialità.

lunedì 21 dicembre 2015

ESXi 6.0: tecniche per la RAM rexclamation

In ESXi 6 esistono sono 5 stati di occupazione di memoria in cui le tecniche di memory reclamation vengono innescate:
High (400% di minFree), le Large Pages (2MB) di RAM vengono preventivamente suddivise in Small Pages(4KB), deduplicabili dal TPS.
Clear (100% di minFree), viene innescato il TPS (se abilitato, vedi KB2097593)
Soft (64% di minFree), viene innescato il BALOONING
Hard (32% di minFree), viene innescato il MEMORY COMPRESSION
Low (16% di minFree), viene innescato il VMKERNEL SWAPPING

Il valore minFree viene calcolato in percentuale variabile sulla rami fisica presente:
6% dei primi 4GB di RAM fisica presente sull'host (circa 245MB)
4% da 4 a 12GB  di RAM fisica presente sull'host (circa 327MB)
2% da 12 a 28GB  di RAM fisica presente sull'host (circa 327MB)
1% della RAM rimanente.

Quindi, per un host con 100GB di RAM otterremo:
(6%*4)+(4%*8)+(2%16)+(1%72)=
245MB+327MB+327MB+720MB = 1619MB

Quindi, per lo stesso host con 100GB di RAM avremo la ram in stato di occupazione High, quando la RAM libera sarà inferiore al 400% di 1619MB
TOT RAM 100
High = ram libera inferiore a 6476MB
Clear= ram libera inferiore a 1629MB
Soft= ram libera inferiore a 1036MB
Hard= ram libera inferiore a  518MB
Low= ram libera inferiore a 259MB

Per maggiori info circa le tecniche innescate vi rimando a questo pdf