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.

venerdì 4 dicembre 2015

NSX logical switch: 1 tables


La comunicazione layer 2 sul NSX Logical Switch, fa leva sulle VXLAN, che permette di espandere un dominio L2 (logical switch), attraverso diversi hosts e rack, indipendentemente dalla connessione tra gli hosts/rack stessi (L2 o L3). Il NSX controller node, si occupa di gestire 3 tabelle fonamentali: VTEP, MAC e RAP tables.

INDIVIDUAZIONE DEL CONTROLLER NODE RELATIVO AD UN VNI

Ogni VNI viene gestito da uno dei 3 controller nodes, per indivisuare quello di pertinenza, basta connettersi ad un qualsiasi controller node, e digitare il comando:
show control-cluster logical-switches vni VNI


Ora abbiamo indivduato il master controller del VNI 5003 e possiamo procedere con l'analisi delle 3 tabelle.

ATTENZIONE: negli esempi sottostanti non c'è corrispondenza tra gli indirizzi IP dei VTEP mostrati nelle immagini e quelli estrapolati dalle tabelle, 
Nelle immagini vedete:
VTEPIP  10.20.10.10-11-12 
che nelle tabelle corrispondono ai 
VTEP IP 172.16.0.51-52-53



VNI-VTEP REPORT:




Nel momento in cui, su un host ESXi, la prima VM si connette ad un segmento VXLAN, (vm1 sul esx1 e vm2 sul esx2, nel nostro esempio), gli host inviano un messaggio ‘control plane’ al controller node che gestisce quel segmento, il quale popola la propria VTEP TABLE e replica il messaggio a tutti gli altri hosts che ospitano VM connesse a quel segmento (ecco perché nel nostro esempio non è stato inviato al ESX3. Il messaggio contiene il mapping tra VNI e VTEP.
Dal controller node, possiamo visualizzare la vtep table con il comando:
show control-cluster logical-switches vtep-table VNI



Quindi ogni host conosce l'indirizzo IP ed il MAC, di tutti i VTEP che gestiscono quel VNI.

VNI-MAC REPORT






Il secondo flusso di informazioni inviato da ESXi al controller è il MAC delle VM localmente connesse ad un VNI (segmento VXLAN). Il controller usa queste informazioni per popolare la propria MAC TABLE ma non replica queste info agli altri hosts. Quindi ogni host conosce i MAC delle VM ospitate.
Dal controller node, possiamo visualizzare la MAC table con il comando:
show control-cluster logical-switches mac-table VNI


VNI-IP REPORT



Il terzo flusso di informazioni, inviato da ESXi al controller, è l'indirizzo IP delle VM, utilizzato dal controller per popolare la propria ARP table per poter, successivamente, sopprimere le richieste  ARP in broadcast.
Dal controller node, possiamo visualizzare la ARP table con il comando:
show control-cluster logical-switches arp-table VNI











venerdì 10 aprile 2015

vGPU in vSphere 6.0/Horizon 6.1 con NVIDIA GRID K1 K2

Recentemente ho implementato un ambiente vsphere 6.0 + Horizon View 6.1 con delle NVIDIA GRID GPU. Con questa feature, diamo la possibilità a diverse VM di utilizzare una scheda grafica NVIDIA (K1 o K2) installata su di un host,  sfruttando il driver NVIDIA  sviluppato per macchine fisiche, i guests utilizzeranno queste vGPU condivise nello stesso modo in cui utilizzerebbero una GPU riservata (Pass-through) ottenendo un completo supporto applicativo.

Le 2 schede grafice supportate sono:
GRID K1: 4 GPU con 4GB DDR3 e 192 CUDA cores per ogni GPU (equivalente ad una Kepler k600 GPU)
GRID K2: 2 GPU con 4GB DDR5  e 1536 CUDA cores per ogni GPU (equivalente ad una  Kepler k5000 GPU)


Ogni  guest che utilizza una vGPU verrà acceso in un host del cluster che abbia a bordo una scheda grafica con delle GPU disponibili per quel guest. All'interno di un singolo host, i guests vengono distribuiti su tutte le GPU fisiche disponibili.
La condivisione avviene attraverso l'assegnazione di profili, ogni profilo assegna una quantità di RAM ed un numero di diaply massimo per ogni VM, ecco l'elenco dei profili attualmente disponibili:



INSTALLAZIONE:

1) installazione del NVIDIA GRID vGPU Manager in ogni server ESXi del cluster:
Il download del VIB viene fatto dalla pagina dei download di NVIDIA, selezionando:

per installare i VIB, dopo aver messo l'host in maintenance mode, ci si connette in SSH e si lancia il comando:
esxcli software vib install --no-sig-check -v /<path>/ NVIDIA-vgx-VMware-346.27-1OEM.600.0.0.2159203.x86_64.VIB
Al termine dell'installazione, anche se non esplicitamente richiesto, dobbiamo operare un reboot dell'host.

2) in vcenter creare un cluster che ospiterà con tutti i server con una scheda GRID

3)  nel cluster creare un nuova windows VM a cui aggiungiamo uno SHARED PCI DEVICE di tipo NVIDIA GRID VGPU ed assegnamo il profilo desiderato:



4) Al power on della VM, verrà assegnata una vGPU utilizzando in toto o in parte una GPU fisica. Ora è il momento di installare i drivers all'interno del guest. Faacendo sempre riferimento all'area download del sito invidia, scarichiamo e successivamente installiamo i drivers corretti per il guest OS


5) Volendo utilizzarla come master image di un pool view (sia linked che full clone) basterà spegnerla, ricavarne una snapshot od un template e nella creazione del pool impostare:
Default Display Porotocol = PCOIP
Allow User to choose Protocol = NO
3D Render = NVIDIA GRID VGPU


Chiaramente queste VM sono legate al device PCI (GPU) e quindi non supportano il vMotion ma possono essere spostate a freddo su un host che contine GPU dello stesso tipo.

Qui sotto potete vedere un filmato relativo ad una VM che sta ultilizzando una vGPU con profilo k260q, la console della VM è raggiungibile con protocollo PCOIP da un thin client Praim A9050

video




vSwitch e DVS: number of ports

In vista dell'esame VCP6-DCV, di cui è da poco uscita la versione beta, un corsista mi chiede:
"un vswitch è, come in passato, composto da 120 porte ? Serve ancora il reboot per modificarne il numero ? Lo stesso vale per un distribuito? Dove lo vedo nella web gui?"

Fcciamo chiarezza:

Usando il vSphere Client tradizionale, dalle proprietà di un vSwitch standard vedo che è composto da 120 porte, ne posso modificare il numero fino ad un massimo di 4088 e, per questa operazione è necessario un reboot. In realtà questa informazione non è corretta: dalla versione 5.5 il numero di porte di un  vSwitch standard è impostato con Elastic il numero minimo di porte viene incrementato/decrementato  di 8 in 8 secondo necessità (KB2064511).

Sempre utilizzando il client tradizionale, vedo che il numero di porte di un DVS è dato dalla somma delle porte di ogni portgroup, per default un pgroup viene creato con 8 porte, ed è un valore modificabile senza la necessità di un reboot. Dalla GUI si evince che il binding è di tipo static (la porta viene assegnata e riservata da un VM nel momento in cui viene connessa allo switch), e può essere modificato in dynamic (la porta viene assegnata alla VM solo nel momento in cui la VM è accesa e la scheda di rete è connessa allo switch, è una modalità deprecata fin dalla 5.0) o ephemeral (la porta viene creata ed asegnata solo nel momento in cui la VM è accesa e la scheda di rete è connessa allo switch, se la macchina viene spenta o disconnessa, la porta viene cancellata).

Utilizando il web client, per quanto riguarda il DVS, le info non si discostano molto rispetto alle info del client tradizionale: il numero di porte di un DVS è dato dalla somma delle porte di ogni portgroup. esistono i 3 tipi di binding e per il binding di tipo static esiste un'ulteriore opzione chiamata Port Allcocation: selezionando elastic, il numero di porte specificato costituisce il numero minimo di porte che poi verrà incrementato  di 8 in 8 secondo necessità mentre selezionando fixed il numero di porte specificato costituisce il numero massimo di porte che non verrà incrementato.

martedì 17 febbraio 2015

VPX operational dashboard

Nel vSphere web client, cliccando HOME > LOG BROWSER abbiamo uno strumento che ci permette di visualizzare i logs di VCenter e degli host ESXi.


Esiste anche un altro tool per visualizzare atri log esistenti a livello di VCenter: il VPX Operational Dashboard (VOD). Per accedere a questo tool, puntiamo a https://<VC_hostname>/vod/index.html.

Tra le varie informzioni disponibili, cliccando HOST STATUS possiamo visulaizzare il MOID di ogni host