lunedì 14 dicembre 2015

VEEAM: consistenza del backup e integrazione con vss

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. Potremmo paragonarlo ad un copy-and-paste di una cartella con file aperti.

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 (power-off del sistema operativo). In uno scenario virtuale VMware, le snapshot garantiscono questo livello di consistenza poichè il file disco vmdk che andremo a prelevare rimarrà immodificabile durante tutto il processo di prelievo del dato.

FILE SYSTEM CONSISTENT: per raggingere questo livello di consistenza, le snapshot e gli strumenti di VMware non sono più sufficienti: in questo caso infatti è richiesta una collaborazione da parte del sistema operativo che dovrà preoccuparsi di non danneggiare il file system. A differenza del "crash consistent", in questo caso il sistema operativo si preoccuperà di terminare e chiudere tutte le operazioni di scrittura sul file system prima di permettere la creazione della snapshot da parte di VMware.
VMware comunica con il sistema operativo guest e richiede la sua collaborazione attraverso le VMware Tools: se queste non dovessero infatti essere installate, il backup non potrà avere una consistenza superiore alla "crash consistent".

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. A differenza del "file system consistent", in questo caso si richiede collaborazione da parte delle singole applicazioni che, in maniera autonoma e non governata dal sistema operativo, si servono della memoria ram per attività di scrittura su disco (cosidette attività transazionali).

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.

giovedì 10 dicembre 2015

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 connection-table VNI

venerdì 26 settembre 2014

vSphere storage polcies nel web client

L'utilizzo delle sorage policies e degli storage profiles con il vSphere web client è meno articolato rispetto all'utilizzo delle stesse features nel client tradizionale.

Come in passato, se abbiamo dello storage che attraverso le API VASA, è in grado di comunicare al vCenter le caratteristiche delle LUN, avremo già nel sistema alcune storage capabilities e quando da HOME > VM STORAGE POLICIES andremo a creare una nuova policy, ci verranno elencate le STORAGE CAPABILITIES esistenti con cui potremo creare un set di regole che descriveranno la nostra policies (installando la VSAN vengono create 5 capabilities).
.
Se invece vogliamo lavorare con le USER DEFINED STORAGE CAPABILITIES, nel web client dobbiamo affidarci ai TAG: ogni datastore potrà essere descritto con diversi TAG (dall'inventario datastores/manage/tags) e quando andremo a creare una nuova storage policy potremo utilizzare i TAG assegnati ai DATASTORES per creare il set di regole desiserato.
Per visualizzare tutti i TAG creati, è possibile cliccare TAGS dalla web client HOME.



Ogni TAG deve appartenere ad una CATEGORY ed ogni categoria verrà associata ad uno o più tipi di oggetti (entità) del nostro vcenter (datastore, host, vm, network ecc.)

martedì 9 settembre 2014

PernixData FVP nel Partner Verified and Supported Products (PVSP) di VMware

In un post precedente, si diceva che il software PernixData FVP viene installato a livello di hypervisor, quindi si tratta di un estensione, di un modulo che estende le funzionalità del vmkernel.
Alcuni clienti mi hanno chiesto se un modulo di terze parti installato a livello di vmkernel, potrebbe provocare 'problemi' di supporto da parte di VMware ad eventuali problemi aperti. La risposta è che da marzo 2014 FVP è stato aggiunto al VMware Partner Verified and Supported Product Program, ed è quindi riconosciuto da VMware come prodotto ufficialmente pronto per essere installato nella piattaforma vSphere. Maggiori informazione le potete trovare in una press release di PernixData, nell'elenco dei Partner Verified and Supported Products (PVSP) sul sito VMware e nella VMware  KB 2073257.

lunedì 1 settembre 2014

vSphere storage polcies nel web client

L'utilizzo delle sorage policies e degli storage profiles con il vSphere web client è meno articolato rispetto all'utilizzo delle stesse features nel client tradizionale.

Come in passato, se abbiamo dello storage che attraverso le API VASA, è in grado di comunicare al vCenter le caratteristiche delle LUN, avremo già nel sistema alcune storage capabilities e quando da HOME > VM STORAGE POLICIES andremo a creare una nuova policy, ci verranno elencate le STORAGE CAPABILITIES esistenti con cui potremo creare un set di regole che descriveranno la nostra policies (installando la VSAN vengono create 5 capabilities).
.
Se invece vogliamo lavorare con le USER DEFINED STORAGE CAPABILITIES, nel web client dobbiamo affidarci ai TAG: ogni datastore potrà essere descritto con diversi TAG (dall'inventario datastores/manage/tags) e quando andremo a creare una nuova storage policy potremo utilizzare i TAG assegnati ai DATASTORES per creare il set di regole desiserato.
Per visualizzare tutti i TAG creati, è possibile cliccare TAGS dalla web client HOME.




Ogni TAG deve appartenere ad una CATEGORY ed ogni categoria verrà associata ad uno o più tipi di oggetti (entità) del nostro vcenter (datastore, host, vm, network ecc.)

sabato 26 luglio 2014

VAAI

Con l'installazione del nuovo firmware sul mio storage IBM DS3500 FC, abbiamo finalmente il supporto per le VAAI, Con l'aiuto di unpdf pubblicato nel dicembre 2012, cerchiamo di approfondire questo argomento.
Le vSphere® Storage APIs – Array Integration (VAAI), sono un insieme di primitive storage  che permettono di scaricare sullo storage alcune operazioni tradizionalmente compiute dagli hosts, delegando allo storage queste operazioni si ottengono benefici in termini di velocità con cui le operazioni vengono eseguite e si utilizzano meno risorse sugli hosts.

VAAI PER LO STORAGE A BLOCCHI:

Atomic Test & Set (ATS)

tutte le operazioni che richiedono un update dei metadati VMFS, richiedono un lock sul file system in modo che altri hosts che accedono allo stesso file system non possano richiedere un update degli stessi metadati contemporaneamente. Senza le VAAI questo meccanismo avviene con le SCSI reservation: un'intera LUN viene vista in modo esclusivo dall'host che ne sta scrivendo i metadati, gli altri host non riescono ad accedere alla LUN finché l'operazione non termina. Con le VAAI viene utilizzato il ATS, che permette di riservare solo i blocchi che devono essere scritti e non l'intero volume.

XCOPY (Extended Copy)

senza le VAAI un'operazione di clonazione o migrazione da un datastore ad un altro, viene eseguita utilizzando il VMkernel software Data Mover driver, consumando cicli di host CPU, buffer DMA e coda HBA. Con questa primitiva viene delegata allo storage l'operazione di lettura/scrittura dei dati.

Write Same (Zero) 

Quando viene creato un VMDK thick eager, viene innescato un comando SCSI per scrivere un insieme di zero nei blocchi che compongono il VMDK. Anche con questa operazione, vengono coinvolte parecchie risorse fisiche, delegando l'attività allo storage si risparmia in tempo e in risorse. La stessa primitiva viene utilizzata per l'azzeramento di nuovi blocchi in un disco thin

VAAI PER LO STORAGE NAS

Full File Clone

Questa primitiva permette alle NAS di clonare i dischi virtuali senza l'ausilio del data mover. La differenza principale rispetto alla XCOPY dello storage a blocchi è che questa primitiva non viene utilizzata per lo storage vmotion.

Fast File Clone/Native Snapshot Support

La creazione delle snapshot viene delegata alle NAS, invece di essere eseguita daglio hosts. E' molto utile quando si di essa si basano altre primitive come la VMware View Composer™ Array Integration (VCAI) che scarica sulla NAS la creazione di VM linked clones per VMware View. Un operazione molto simile 
viene fatta anche da VCloud director.

Extended Statistics

Con questa primitiva è possibile creare dei files thick sulle NAS (senza di essa sulle NAS si possono solo creare files thin).

VAII PER LO STORAGE THIN

Se viene utilizzato dello storage di tipo thin provisioned, lo storage stesso non viene informato quando si è liberato dello spazio a fronte di un cancellazione o migrazione di una VM. Per risolvere questa anomalia è stata creata la primitiva Dead Space Reclamation fa in modo che l'host informi lo storage che si è liberato dello spazio in modo di poter avere una delle info (all'interno dei vsphere clients) corrette. Questa primitiva non viene innescata automaticamente ma attraverso un processo manuale, vi rimando al documento citato in precedenza per una descrizione dettagliata dei comandi necessari.
La primitiva Thin Provisioning Stun serve a non dover sospendere tutte le VM all'interno di un datastore che ha raggiunto il 100% dello spazio occupato, utilizzando questa api, verranno sospese solo le VM che richiedono nuovi blocchi di storage.
La Thin Provisioning Space Threshold Warning serve ad emettere un warning se un datastore thin raggiunge una certa soglia di spazio occupato.

Con il comando esxcli storage core device vaai status get -d naa.xxx è possibile conoscere quali primitive sono supportate per un certo storage. Nel caso del mio DS3500 ottengo:
~ # esxcli storage core device vaai status get -d naa.60080e5000242f68000009504ea1b0fe
naa.60080e5000242f68000009504ea1b0fe
   VAAI Plugin Name:
   ATS Status: supported
   Clone Status: supported
   Zero Status: supported
   Delete Status: unsupported
~ #

Nota: Per ottenere il naa della mia SAN ho utilizzato il comando esxcli storage core device list

Un post un po' vecchio ma sempre molto interessante circa le VAAI lo trovate cliccando qui.