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.

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

 

VMware NSX: uno dei fondamenti del SDDC

VMware NSX è uno dei pilastri sui quali si appoggia la strategia di VMware per il software-defined data center (SDDC). Il principio è quello di estendere le caratteristiche della virtualizzazione quali: astrazione, pooling di risorse, automazione e controllo dalla parte computing alla rete ed allo storage. La virtualizzazione di questi due ultimi elementi consentirà ai datacenter ed ai loro amministratori di superare le barriere del mondo fisico migliorando la velocità e l’agilità nella gestione riducendone i costi.

NSX è la piattaforma di virtualizzazione del network e della sicurezza disponibile per ambienti vSphere e non. NSX can può essere amministrato attraverso la vSphere Web Client, via riga di comando (CLI), e attraverso le REST API. Lo scopo della soluzione è fornire una piattaforma che, al pari di quello che è successo per le virtual machine, consenta di amministrare in modo efficace da un’unica interfaccia il networking della propria infrastruttura, “riproducenco” i layers dal 2 al 7 come conosciuto nei modelli di rete.

Se la rete è l’elemento più noto/citato del lavoro di NSX, il prodotto offre un nuovo modello di gestione della sicurezza della rete grazie a Security Profiles che possono essere distribuiti e quindi “imposti” a livello delle porte virtuali sulle quali insistono le VM.

NSX mette a disposizione dell’ambiente una libreria di servizi di rete la cui combinazione contribisce alla messa in opera di complesse architetture di rete senza alcuna specifica richiesta sulle VM già in esecuzione. Si parla di servizi come:

  • logical switches
  • logical routers
  • logical firewalls
  • logical load balancers
  • logical VPN

La messa in opera di questi servizi logici può essere fatta e mantenuta indipendentemente dagli apparati fisici a disposizione separando, di fatto la parte di configurazione, “detta control plane”, da quella fisica dove avviene il trasferimento dei dati detta “IO plane”

Alcuni esempi per la messa in opera di NSX possono essere:

  • automazione del Datacenter,
  • velocizzazione nel fornire la rete ai servizi applicativi
  • semplificazione dell’eterogeneità dell’hardware
  • semplicità di interconnessione tra applicazioni “private” e quelle ospitate nei cloud pubblici

Per maggiori informazioni è possibile consultare la pagina del prodotto sul sito VMware

Modulo integrazione vCloud Air in vSphere 6

Nella homepage del vSphere Web Client nella versione 5.5 appariva in bella mostra l’icona del plug-in di vCloud Air (prima ancora vCloud Hybrid Services), software non disponibile invece in vSphere 6.

vCloudAir-Plugin in vSphere 5.5

vCloudAir-Plugin in vSphere 5.5

L’integrazione con vCloud Air è ora disponibile attraverso l’installazione di “vCloud Air Hybrid Cloud Manager”, nuova applicazione che consente a vSphere di comunicare direttamente con l’ambiente vCloud Air e progettato per:

  • avere un unico punto di controllo ed amministrazione delle VM sia nel proprio ambiente (on-premises) che di quelle presenti nel cloud attraverso vSphere Web Client;
  • migrare, in modo bidirezionale da una location all’altra e solo con un minimo downtime, i propri workload/servizi composti siano essi compoosti da singole VM oppure da un gruppo, senza la necessità di alterare o riconfigurare le applicazioni;
  • avere la possibilità di portare la rete aziendale all’interno dell’ambiente vCloud Air attraverso VPN Layer 2, consentendo alle VM di mantenere gli stessi IP e MAC address

Diversi possono essere i casi d’uso di questo nuovo Plug-in:

  • estendere la batteria delle applicazioni aziendali nel cloud senza dover cambiare le procedure di deployment o le proprie VM;
  • sfruttare le risorse esterne per i workload di test e di sviluppo che potrebbero consumare le risorse del proprio datacenter interno;
  • collocare nel cloud le applicazione mobili/web, destinate a soggetti esterni all’azienda mantenendone il controllo con gli strumenti già conosciuti in azienda.

E possibile avere maggiori informazioni nella vCloud Air Hybrid Cloud Manager.

Cloud Pubblico quale “sito” per il proprio DR

E’ innegabile che con la virtualizzazione e la conseguente trasformazione in software (VM) di ciò che prima era hardware, affrontare il tema del Disaster Recovery si è semplificato, anche se non sempre economico. VMware con vCenter Site Recovery Manager, ha proposto la sua soluzione per indirizzare la questione supportando da subito la replica del dato via array e, successivamente, attraverso l’host (host-based). Ciò che fino a qualche tempo fa non poteva essere evitato era l’esistenza di un sito secondario nel quale inviare il dato, vincolo non sempre semplice da superare che, oltre alla proprietà dell’infrastruttura (se non delle pareti) implicava la manutenzione della stessa.

Nell’era del Cloud, del “qualsiasi cosa as a service”, non potevano mancare le proposte di DRaaS che permettono rendere ancora più “popolare” l’adozione di una soluzione di protezione del proprio datacenter. Il DRaaS fa comunque sorgere altre tipologie di questioni come: la piattaforma di partenza e quella di destinazione, quale strumento di replica usare, la possibilità di testare il piano di DR, il livello di automazione fornito in caso di disastro e, non per ultimo, la possibilità di tornare indietro (failback).

VMware attraverso i suoi servizi vCloud Air ha una specifica offerta chiamata appunto VMware vCloud Air Disaster Recovery Services concepita intorno al concetto di “one-cloud” che promette al consumatore di utilizzare gli strumenti di VMware sia a casa propria che nel Cloud (di VMware). Il servizio è stato pensato per offrire ai clienti vSphere la protezione delle VM replicandole con vSphere Replicator attraverso la sottoscrizione di un abbonamento che, oltre al dimensionamento delle risorse, prevede anche una durata (dal singolo mese ai 3 anni). Per maggiori informazioni è possibile consultare le VMware vCloud Air Disaster Recovery – FAQ.

Cosa è cambiato dopo il VMworld US 2015?

Nella prima “vita” del servizio non si poteva parlare di un vero e proprio DR gestito in quanto non era possibile creare (quindi gestire) un piano di DR; tuttavia era consentito automatizzare i processi grazie all’installazione del plug-in per vRealize Orchestartor.

Nel recente VMworld 2015, appena concluso negli Stati Uniti, VMware ha annunciato una serie di miglioramenti:

Disater Recovery OnDemand: si tratta di una opzione nella quale il vendor aggiungerà una opzione per il pagamento di quanto si sta utilizzando, ovvero il consumatore pagherà una cifra flat per ogni VM protetta e per il relativo consumo di spazio. In caso di test del DR o in caso di disastro il cliente pagherà la componente computazionale per le VM in esecuzione. Se un’azienda dovesse decidere di rimanere nel cloud a seguito di un disastro sarà solo necessario convertire il contratto per il servizio di DRaaS in quello vCloud Air Virtual Private Cloud;

Site Recovery Manager Air: è la declinazione di “VMware vCloud Air Disaster Recovery” per tutti i clienti che hanno apprezzato le funzionalità di SRM senza la necessità di dover installare nella propria infrastruttura il software ed affrontare i relativi processi di aggiornamento. Questa soluzione fornisce tutti gli strumenti per la progettazione, il test, l’esecuzione e l’orchestrazione dell’intero progetto di business continuity e disaster recovery in modalità “self-service”.

VMware vCloud Air Disaster Recovery OnDemand e Site Recovery Manager Air saranno disponibili a nell’ultimo quadrimestre del 2015 per il clienti “early access program”

Per maggiori informazioni è possibile consultare gli articoli:

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 c e 192 CUDA cores per ogni GPU (equivalente ad una Kepler k600 GPU)

GRID K2: 2 GPU con Kepler k600  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 ttraverso 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 espicitamente 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.

Migrare da vCenter su MS-Windows al vCenter Server appliance

Un tassello mancante dall’introduzione di del vCenter Virtual Appliance (VCSA) è uno strumento che possa consentire la migrazione tra le due piattaforme sia per il sistema operativo che per il database. La risposta a questa esigenza arriva, ancora una volta, dai flings di VMware, trattasi quindi di un software distribuito “as is” quindi è necessario leggere attentamente requisiti e limiti e considerare che in specifiche situazioni la migrazione potrebbe non essere “smooth”. Il VCVA Converter Appliance è una VM che consente di migrare il vCenter Server su Windows con un DB esterno basato su Microsoft SQL, verso il vCenter Server Appliance usando il DB embedded ovvero vPostgres database. Il risultato sarà che il sistema target appliance utilizzerà lo stesso IP del vCenter di partenza. Tra i requisiti:

  • vCenter Server su Windows a partire da vSphere 5.5
  • la versione del VCSA (target) dovrà corrispondere al vCenter di partenza (esempio da vCenter Server Windows 5.5u1 verso VCSA 5.5u1)
  • il VCSA dovrebbe essere configurato con lo stesso numero di CPU e la stessa quantità di memoria del vCenter Windows
  • tutte le componenti di vCenter (Inventory Service, vSphere Web Client, VMware Single Sign On) devono essere installate sullo stesso host del vCenter Server
  • Il DB server deve essere esterno ovvero SQL Server e vCenter Server devono risiedere su host separato
  • il DB server supportato è Microsoft SQL è 2008R2
  • l’appliance per la migrazione deve essere in grado di comunicare sia con il vCenter sorgente ed il relativo DB server e con il VCSA di destinazione,

Tra le limitazioni della versione 0.9

  • SQL Express Database non è supportato
  • Gli script degli allarmi non vengono migrati
  • Le configurazioni legate alla Linked Mode non vengono migrate
  • i plug-in non vengono migrati
  • la migrazione richiede il downtime del vCenter Server

Per maggiori informazioni è possibile consultare la pagina relativa al flings.

Competenza Software-Defined Storage

il 26 dicembre VMware ha annunciato una nuova competenza per i propri partners, trattasi della Software-Defined Storage Competency (SDS Competency). Il materiale per il completamento della competenza è già disponibile da qualche tempo sulla partner University ed è strutturata, come al solito, in tre aree: vendita, prevendita e post-vendita.

La maturazione della competenza, oltre ad incrementare le proprie capacità nella proposizione di soluzioni Storage Defined Software come Virtual SAN, consentirà di vedersi riconosciuto il 15%, come previsto da Solution Rewards, su tutti i codici prodotto eleggibili venduti.

Una nota importante riguarda i partner che hanno maturato in passato le competenze DV e BT, per i quali la competenza SDS è “garantita d’ufficio” fino al 31 Luglio 2015 con l’biettivo di smarcare i requisiti entro la scadenza sopracitata.

Per maggiori informazioni è possibile consultare il post sul blog VMware.

Trend Micro Deep Security Agentless e VMware Vcloud Director

Trend Micro Deep Security è un prodotto in grado di fornire funzionalità di antimalware, firewall, intrusion prevention, web reputation ed integrity monitoring ad un infratruttura vSphere utilizzando una Virtual appliance installata in ogni host e senza la necessità di dover installare un  agente nelle VM. Il prodotto si integra con ambienti VMware vCloud in modalità multitenant: dà quindi la possibilita agli amministratori deglle varie organizations di proteggere autonomamnete le loro vm/vapp , senza vedere o interferire con le vm/vapp di altre org utilizzando un unico deep security server (deep security manager o DSM) ed una deep security virtual appliance (DSVA) presente in ogni host. Vediamo insieme i passi per implementare come implementare queste funzionalità.

L’amministratore di vCloud dovrà integrare il vCenter con il DSM entrando nella  DSM web GUI, nell’area ‘computers’  e cliccando col tasto desto sull’albero ‘computers’ preme il tasto ADD VMWARE VCENTER

Verranno chieste anche le specifiche di vShield manager:

Un prerequisito necessario è il vShield endpoint installato in ogni host ESX: Lo si fa facilmente dal client vShield:

Ora dobbiamo importare nel DSM i due software che andremo ad installare negli host: il trend micro filter driver e la deep security virtual appliance

Sempre dalla gui di DSM, selezionando col tasto destro i vari host ESXi, potremo installare il filter driver premendo ‘prepare ESX

ATTENZIONE: per installare il filter driver gli host verranno messi in maintenance mode e successivamente riavviati.

Dopo aver preparato un host, il wizard ci propone di installare (deploy) e successivamente attivare la DSVA

Ci viene proposto di attivare la protezione per le VM presenti nell’host ma, per ora, proseguiamo senza proteggere le VM

E’ il momento di attivare la Multi Tenancy in DSM (è richiesto un codice di licenza specifico)

Ora possiamo creare un tenant per ogni organizzazione cloud a cui vogliamo offrire la protezione. Nel mio esempio abbiamo due organizzazioni ed attiveremo la protezione per la organizzazione QA

Nella DSM creiamo il tenant per l’org QA inserendo un account name, uno username con relativa password che serviranno all’organization administrator per loggarsi nella DSM web GUI.

A questo punto l’organization administrator può loggarsi alla DSM gui

Per ora non vedrà nessun computer protetto

Dovrà quindi aggiungere le proproe risorse cloud

In Provider Type scegliamo vCloud Private Cloud

Il Name e la Description sono due campi descrittivi

Endpoint IP è l’indirizzo del server vcloud

User Id è l’utenza del organization administrator, la corretta sintassi è utenza@organizzazione

Password del organization administrator

L’organization administrator vede le proprie vapp e le VM che le compongono, cliccando col tasto destro su ognina di esse può attivare la protezione agentless.

 

Horizon Mirage Bandwith Limit

Dalla versione 5.1 di Horizon Mirage, è stata introdotta la possibilità di impostare un limite di banda in upload/download per i client che si trovano in alcune subnet o in alcuni domini.

Chiaramente è una funzionalità molto utile per far si che i clients che si trovano in uffici remoti non consumino tutta la banda con le attività mirage.

Per impostare il limite, nella mirage console, clicchiamo col tasto destro su system configuration e selezioniamo SETTINGS. Ora ci spostiamo sul tab BANDWITH LIMITING

Come vedete, per default non c’è nessun limite impostato. Ora, per impostare i limiti desiderati, creiamo un file csv contenente le regole nel formato:   SubnetMaskV4,Site,Download limit,Upload limit.

 

Nell’esempio, impostiamo un limite di 500KB/s in upload e di 350KB/s in download per tutti i clients della subnet 172.16.0.0/16.

Impostiamo un limite di 300KB/s in entrambe le direzioni per il client 172.16.0.11

Impostiamo un limite di 200 e 100 KB/s per i cliient del dominio sitoA ed un limite di 2048 1024 per i client del dominio sitoB. Importando il file otteniamo:

La regola di precedenza è la più restrittiva. Se ,ad esempio, un client appartiene al sitoA, alla subnet 172.16.0.0  ed il suo indirizzo è 172.16.0.111, i suoi limiti saranno 200 KB/s in upload e 100 KB/s in download. Vince questa regola, NON perchè è stata inserita per ultima ma perchè è la più restrittiva.

Impostare la banda in upload e in download per una intera subnet (o dominio) , significa che se all’interno della subnet ci sono attività parallele di download ed upload, la banda massima utilizzabile sarà la sommo dei due limiti.