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


giovedì 10 dicembre 2015

VEEAM: consistenza del backup e integrazione con vss

Quando si parla di consistenza del backup e di integrazione tra i VMware Tolls e  MS VSS  si fatica a trovare documentazione completa. Scrivo questo post con lo scopo di aggregare e riassumere informzazioni raccolte da varie fonti.

Un backup di una VM (vale anche di una macchina fisica) può essere considerato:

INCONSISTENTE: il backup copia tutti i files, anche quelli aperti e soggetti a modifiche durante il processo di backup.
CRASH CONSISTENT: a differenza del precedente, tutti i dati vengono copiati nello stesso momento, quindi durante il backup non ci possono essere scritture di files ma tutto ciò che è in memoria o in una operazione di I/O non terminata, non viene salvato. I dati sono identici ai dati che avremmo dopo un crash di sistema.
FILE SISTEM CONSISTENT: è consistente se nel momento in cui faccio la snap, committo tutte le write su disco.
APPLICATION CONSISTENT: se il produttore dell'applicazione, mette a disposizione un VSS WRITER, nel momento in cui la snap VSS viene innescata, l'applicazione viene notificata e compie tutte le operazioni necessarie effinchè non ci siano operazioni pendenti.

Il VSS quindi si fonda su 3 componenti che devono  coordinarsi tra loro:
VSS WRITER: installato da ogni applicazione VSS AWARE, si occupa di coordinare le attività di backup con l'applicazione . In una macchina win, si elencano tramite il comando
vssadmin list writers
VSS REQUESTOR: è spesso l'applicazione di backup, si occupa di coordinare le attività di backup con quelle VSS: in pratica richiede che la snap VSS venga innescata.
VSS PROVIDER: il quale si occupa di creare e gestire le shadow copies. Potrebbe essere il OS ed il file system o un hardware provider installato su uno storage array.


Vsphere supporta il VSS fin dalla versione 4.1 per diverse versioni di guest windows (2008 e 2012 inclusi). I VMwareTools, installati nei guest, fanno da VSS requestor ma non producono una shadow copy application aware: I VMware Tools utilizzano il VSS per garantire che lo stato transazionale delle applicazioni sia ottimale, ma non applicano nessuna tecnica applicativa per garantire un restore corretto, e non fanno nessun transaction log pruning/trunking. Quindi, utilizzando i VMware Tools come VSS requestor, otteniamo un backup consistente a livello di transazione, ma non abbiamo garanzie di un restore corretto, in conformità con i requisiti imposti da MS.

Per ottenere dei backup completamente application aware,
VEEAM BACKUP AND REPLICATION utilizza una feature chiamata Application-aware image processing (AAIP): è un processo a diversi stadi che:

1) identifica le applicazioni compatibili all'interno della VM
2) attraverso il VSS, opera una quiescenza a livello applicativo, assicurando la consistenza transazionale dei dati.
3) Imposta le applicazioni, per poter essere restorate in modalità VSS-aware al prossimo startup.
4) Se il backup termina correttamente, si occupa del transaction logs pruning.





NSX logical switch: 2 Virtual to Virtual Unicast Communication

Nel post precedente, abbiamo visto con quali dati vengono popolate le tabelle del NSX logical switch:
VTEP-TABLE: relazione tra VNI e VTEP, presente su ogni host.
MAC-TABLE: relazione  tra VM MAC e VTEP, presente solo sul controller.
ARP-TABLE: relazione  tra VM MAC e VM IP, presente solo sul controller.

Utilizzando queste tabelle, il NSX controller può sopprimere le richieste ARP nel dominio L2 (segmento VXLAN) in cui le VM sono connesse. In questo modo iene eliminata la maggiore fonte di traffico in rete.
Analiziamo la situazione con un semplice esempio:


1. La VM1 generates una richieta ARP request (L2 broadcast packet) per determinare le informazioni MAC/IP della VM2.
2. ESXi-1 intercetta la richiesta e genera una richiesta al  controller, per conoscere le informazioni MAC/IP della VM2.
3. Il controller riceve la richiesta.
4. Il controller verifica la  ARP table, cercando le informazioni.
5. Le info vengono inviate al ESXi-1 con un  ARP report message.
6. ESXi-1 riceve il control plane message e popola la sua taebella locale con le info necessarie:
VNI, VM2 IP, VM2 MAC, VTEP IP 
7. ESXi-1 genera una ARP response a nome della  VM2 (il source MAC address in the frame is MAC2) e lo invia a  VM1 (che vede un messaggio proveniente direttamente da VM2)
8. VM1 popola la sua ARP cache, ed è in grado di inviare dati alla VM2


1. VM1 genera un data packet diretto alla VM2.
2. ESXi-1 conosce dove si trova la VM2 dall  ARP report ricevuta dal controller precedentemente  (control plane learning), quindi incapsula il pacchetto generato dalla VM1 in un pacchetto VXLAN destinato al VTEP del ESXi2 (10.20.10.11).
3. ESXi-2 riceve il pacchetto, lo decapsula, utilizza le info presenti per conoscere la location della VM1,associa il VM1 MAC e IP addresses al VTEP of ESXi-1 (data plane learning)
4. La frame viene inviata a  VM2.

Ora,  ESXi-1 ed ESXi-2 hanno popolato le loro tabelle locali ed il traffico può fluire in entrambe le direzioni.