Elaborato Trapasso Giuseppe N46-000877

Questo elaborato vuole esporre le funzionalità ed i vantaggi delle reti virtuali, ormai quasi indispensabili per avere una buona competitività nel mercato dell’ ICT (Information & Communication Technology), ponendo un focus particolare sull’azienda leader in questo settore che è VMware e su i prodotti che offre. Il testo è diviso in tre capitoli. Nel primo si traccia una panoramica generale sulle reti fisiche ed i problemi derivanti dalla loro installazione e gestione, si spiega perché le reti virtuali sono tanto importanti per gli ambienti aziendali, quali problemi risolvono e si arriva quindi a discutere la nascita delle Virtual Network partendo dai concetti base di macchina virtuale. Il capitolo successivo sarà incentrato sugli strumenti ed i servizi offerti da VMware, vedremo come la virtualizzazione può risolvere molti dei problemi legati alla configurazione ed alla gestione di reti fisiche e come i software messi a disposizione da VMware possano aiutare le aziende a gestire facilmente server e reti virtuali nei loro Data Client, offrendo parallelamente una buona perfomance, migliore sicurezza ed una più semplice troubleshooting (risoluzione dei problemi). In alcuni paragrafi si cercherà di sottolineare i vantaggi che questi strumenti e queste tecnologie portano alle aziende. Infine analizzeremo in un terzo capitolo alcuni casi d’uso delle tecnologie VMware immaginando dei casi aziendali a scopo esemplificativo. 3

Capitolo 1: Dalle reti fisiche ai benefici della virtualizzazione

Prima dell’avvento delle macchine virtuali le architetture hardware che si adoperavano per ogni tipo di utilizzo (calcolo, storage di dati, backup, ecc.) richiedevano costi molto elevati sia in hardware che in software, così come costi di manodopera e manutenzione. La virtualizzazione fu introdotta da IBM per permettere un migliore partizionamento di queste risorse tra più utenti. Si ci accorse quindi che astrarre le risorse in un livello logico e separarle da quello fisico poteva portare diversi vantaggi. Il primo caso di virtualizzazione lo abbiamo, appunto, con IBM negli anni ’70. Poi, fra gli anni ottanta e novanta, la virtualizzazione venne trascurata a causa dell’avvento dei personal computer e solo nel 1999 VMware offre il primo strumento di virtualizzazione chiamato x86 Virtual Platform, nato insieme ad altri progetti (ad esempio il progetto Xen), che avevano come target la server virtualization. Nel 2005 la stessa azienda lancia VMware Player, un player per macchine virtuali gratuito, e da allora lo sviluppo di questa tecnologia progredì fino alla Network virtualization e il Cloud Computing.

1.1 I limiti delle Physical Network

Le reti fisiche, seppur utilizzate per parecchi anni ed ancora adesso, presentano delle problematiche di sviluppo e gestione. Da un punto di vista di design le macchine fisiche dovevano essere dimensionate su misura, nei progetti a larga scala, per ogni software che sarebbe stato eseguito su di esse. La manutenzione era costosa perché diversi tipi di server, ad esempio di storage o di calcolo, richiedevano diversi gruppi di esperti con abilità specifiche differenti. Distribuire server fisici nei Data Center poteva richiedere tempi di consegna dell’ordine di giorni o anche 4

settimane. Altro problema frequente era il downtime (periodo morto o tempo di attesa) nato nel dover, ad esempio, applicare una patch ad ogni macchina o risolvere un problema di manutenzione. Tutti questi aspetti sono stati il trampolino di lancio delle reti virtuali nei Data Client. E’ adesso possibile dimensionare le risorse destinate ad una specifica applicazione, ed eventualmente cambiarle dopo l’installazione, senza dover modificare le macchine fisiche, possiamo ridurre in maniera significativa i costi di manutenzione che avviene quasi completamente a livello software, e la fornitura di una rete virtuale non impiega più settimane ma minuti. Vediamo adesso qualche concetto base dell’architettura di una rete fisica ed altri problemi legati al suo corretto funzionamento. 1.1.1

Architettura di una rete fisica Prendendo come riferimento la Figura 1 possiamo vedere l’architettura di rete di un singolo Data Center, esaminiamo i vari componenti che saranno più volte ripresi nel resto della trattazione. 1.

VPN (Virtual Private Network) permette ad una macchina di connettersi da una rete ad un’altra per utilizzare le sue risorse, la connessione è tipicamente criptata e sicura. 2.

Firewall, è usato per salvaguardare la rete, o componenti della rete, da intrusioni e filtrare i pacchetti in entrata o in uscita. 3.

Uno switch è un apparato di livello 2 che permette di fare commutazione dei frame. 5

Esso può servire quindi per estendere una certa LAN interconnettendo due spezzoni di rete con lo stesso indirizzo di rete. 4.

Questo elemento è chiamato Load Balancer o bilanciatore di carico ed è usato per bilanciare il traffico di un applicazione o della rete fra un gruppo di server, con lo scopo di migliorare le prestazioni. 5.

Un router è invece un apparato di livello 3 che permette principalmente di fare instradamento dei pacchetti. Riceve pacchetti di dati da una linea, ne identifica il destinatario e li inoltra ad una nuova linea. 6.

Le macchine fisiche sono interconnesse fra loro e possono inviare e ricevere dati l'un l'altra. Sono interconnesse alla rete tramite schede di interfaccia di rete chiamate NIC e tramite i cavi di rete. Nella virtualizzazione su queste macchine vengono installati i server ESXi che sono alla base delle reti virtuali VMware. 7.

I server fisici sono organizzati in “racks” o scaffali per facilitarne manutenzione, raffreddamento ed alimentazione. 1.1.2

Problemi e difficoltà tecniche Quando una rete fisica con l’architettura vista in precedenza viene installata, bisogna collegare tutti gli switch ad uno switch principale (core switch), poi collegare ogni macchina fisica ad uno switch ed etichettare i cavi per avere una più semplice troubleshooting in futuro. Inizia quindi la configurazione di ogni singolo switch, l'assegnazione ed il testing degli indirizzi IP, l'installazione di altri eventuali componenti come schede di rete, driver e firewall. E’ facile vedere che già questa prima fase di installazione richiede molto tempo ed eventuali errori possono compromettere il funzionamento dell’intera struttura. Prima di distribuire la rete bisogna considerare i requisiti delle applicazioni che si vorranno installare sui server. Ogni implementazione fisica può variare e dipendere da ciò che le applicazioni richiedono. Un e-mail server, per esempio, deve prevedere nel design di sviluppo alcuni basilari sistemi di sicurezza contro attacchi IP o una certa velocità nell'invio della posta. Altro esempio potrebbe essere un server di attiva gestione degli account che, per ovvie ragioni di sicurezza, deve essere separato da server contenenti dati sensibili come un business 6

server o database server. Il costo di questa segmentazione può essere ridotto usando un firewall o una VLAN ma non avremo i livelli di efficienza raggiunti con la virtualizzazione. Nelle reti c'è inoltre l'esigenza di dividere differenti indirizzi (e quindi usare differenti switch) per differenti tipi di traffico. Ad esempio: traffico di tipo gestionale che serve alla gestione di switch, router e firewall, traffico di produzione che supporta dati aziendali, diretti ai database o traffico utente. Potrebbe servire un canale privato per il Test Development Traffic, traffico dedicato all’ ambiente di sviluppo aziendale ed i laboratori. Se il numero di utenza in una rete è alto, possono esserci problemi di congestione del traffico, allora per aumentare la performance bisogna allargare la banda. Altri problemi possono derivare ad esempio dall'utilizzo di streaming multimediali come invio di conversazioni vocali o video. Tutte queste problematiche si convertono in scelte di configurazione che posso richiedere molte risorse, tempo e ed essere sorgenti di problematiche. Cambiare i parametri di rete dopo la sua installazione costa parecchio. 1.1.3

Problematiche aziendali ed economiche Le richieste degli utenti possono aumentare nel tempo o raggiungere picchi a seconda dei periodi, se il sistema non è sufficientemente flessibile e dinamico, problema basilare delle reti fisiche, i servizi offerti potrebbero non rispondere in maniera sufficientemente veloce alle richieste dei clienti. I nuovi servizi resi disponibili online richiedono continuamente nuove interfacce, configurazioni, firewall ed altre caratteristiche avanzate che un’azienda dovrebbe facilmente implementare per restare aggiornata con i tempi. Il downtime è, come già detto, un altro problema importante: gli attacchi di rete sono sempre più sofisticati e richiedono pertanto frequenti aggiornamenti dei sistemi di sicurezza e di rete in genere, ma questi aggiornamenti portano periodi morti indesiderati. Gli impiegati di un’ azienda devono ricevere corsi di aggiornamento e training per riuscire ad affrontare correttamente configurazioni e sviluppo per nuove tecnologie, si immagini invece se bastasse avere dimestichezza con uno solo strumento software per poter configurare e riconfigurare una rete in poco tempo. Cosa possibile con gli strumenti di gestione per reti virtuali. 7

1.2 L’arrivo delle reti virtuali

Virtualizzare vuol dire creare una versione virtuale di risorse e dispositivi come: dispositivi di memorizzazione, sistemi operativi, server ed anche reti, dove gli strumenti di un framework dividono queste risorse fra uno o più ambienti in esecuzione. Anche qualcosa di semplice come partizionare un Hard Disk è considerato virtualizzazione, perché da un solo dispositivo fisico se ne estraggono due o più che hanno in totale le stesse risorse. I dispositivi, i software e gli utenti finali possono interagire con le risorse virtuali proprio come se fossero risorse fisiche. La virtualizzazione converte risorse fisiche in risorse software, la rivoluzione fatta da VMware è di annullare la dipendenza fra le virtual machine e l'hardware dei singoli server. 1.2.1 Le macchine virtuali Una macchina virtuale o Virtual Machine (VM) è l’emulazione software di una macchina che esegue programmi proprio come la macchina fisica. In queste macchine le risorse fisiche sono astratte ad un livello virtuale e possono essere utilizzate tutte o in parte nell’esecuzione. Grazie a questo processo possiamo avere diversi vantaggi: più sistemi operativi possono coesistere nella stessa macchina, possiamo avere una macchina virtuale con un diverso instruction set della macchina fisica su cui è installata, generalmente le virtual machine forniscono alta portabilità, disaster recovery e manutenzione semplificata. Esistono macchine virtuali sia a livello desktop che server, analizziamo le prime. La virtualizzazione a livello desktop agisce su più livelli. E’ possibile portare nel Cloud le risorse ed il sistema operativo del singolo desktop o di più dispositivi, ad esempio in un utilizzo aziendale, per condividere risorse, effettuare backup, aggiornare software in tempo reale ed in parallelo o altro ancora. Queste funzioni sono rese disponibili da VMware Horizon Mirage. La virtualizzazione delle macchine può estendersi poi a dispositivi di diversa tipologia (tablet, smartphone, netbook) o anche estendere uno stesso ambiente di lavoro a più dispositivi: immaginiamo di voler modificare un’ agenda digitale sul nostro telefono e trovare le stesse modifiche anche nei nostri personal computer. Questi servizi sono offerti da altri prodotti Vmware come Horizon view ed Horizon-workspace ma non verranno approfonditi perché esulano l’argomento centrale di questa tesi. L’aspetto delle macchine virtuali che più ci ricollega alle virtual 8

network è la virtualizzazione server, lasciamo i dettagli e gli strumenti utilizzati a questi scopi nel prossimo capitolo, or

ci limiteremo a sottolinearne l’utilità ed i benefici nelle reti virtuali. 1.2.2 Virtual Network Abbiamo visto come una virtual machine è la rappresentazione virtuale delle risorse fisiche di un sistema. In maniera molto simile possiamo dire che una virtual network è la rappresentazione virtuale dei componenti di una rete fisica. La network virtualization può essere descritta come la riduzione di reti fisiche in software, i principali componenti (switch, adapter, ecc..) sono essenzialmente gli stessi ma non esistono fisicamente e possono essere visti come dei “magical objects” che funzionano più o meno allo stesso modo dei corrispettivi elementi fisici. L’adapter virtuale è progettato per operare nello stesso modo di una scheda di rete fisica e può essere configurato nelle virtual machine esattamente nella stessa maniera. Abbiamo ancora bisogno di configurare un indirizzo IP per far comunicare le nostre virtual machine con il mondo esterno, gli switch virtuali in questo si comportano come switch fisici e connettono le nostre macchine ad una rete fisica o ad altre reti virtuali. Come vedremo meglio in seguito, nell’ambiente vSphere gli switch vengono eseguiti come parte del software e su ogni server, in particolare su ogni ESXi host, sono caricati dal kernel proprio come molti altri componenti di un sistema operativo. E’ possibile usare altri elementi software, che non richiedono un hardware di base specifico, per riprodurre gli stessi servizi usati in un mondo fisico come: firewall, load balancer, VLAN (o VXLAN come vedremo) ecc… E’ importante non dimenticare che c’è comunque la necessità di connettersi ad una rete fisica da qualche parte lungo il processo, anche se nelle tecniche più moderne (si veda NSX nel prossimo capitolo) la rete fisica è utilizzata solo come un IP BackPlane. Anche se la rete virtuale si comporta più o meno come una rete fisica, la differenza principale è che la gestione delle risorse e dei componenti (in questo caso virtuali) avviene a livello software e può essere distribuita o replicata in diversi host. 9

1.3 Differenze fra Network Virtualization, Network Functions Virtualization e Software Defined Networking

La necessità di rendere più agile la configurazione e la gestione delle reti ha portato negli anni alla nascita di diverse tecnologie, alcune simili fra loro ed alcune anche complementari ma fondamentalmente diverse. Queste sono principalmente la Network Virtualization (NV), Network Functions Virtualization (NFV) e le Software Defined Networking (SDN). Diamo a queste sigle una definizione ed una descrizione. Con il passare del tempo le richieste di cambiamenti alla rete diventavano sempre più frequenti e difficili da gestire, il problema che gli amministratori di rete si ponevano era principalmente: Come posso spostare facilmente una virtual machine in un diverso dominio logico? La risposta arrivò con le virtual network. L’idea è quella di creare un segmento logico in una rete esistente, dividendo la rete a livello del flusso dati. Si tratta del così detto overlay, si può immaginare come un tunnel fra due o più host di una rete, realizzato senza dover cambiare fisicamente la topologia di base. Questo è utile perché gli amministratori di rete non devono modificare quello che hanno già fatto, possono effettuare cambiamenti sulla rete già esistente. Con le virtual network possiamo quindi cambiare la topologia di rete in maniera semplice, centralizzata, e senza dover modificare l’hardware. Possiamo ora però offrire tutti i servizi di cui gode una normale rete fisica? In questo entra in gioco la NFV, se l’amministratore può settare una virtual machine con un click, perché non dovrebbe poter configurare un firewall o una VPN nello stesso modo? Questo è esattamente ciò che NFV permette. Dai servizi di gateway, a quelli di sicurezza, ai sistemi di incapsulamento, tutto ciò che una rete fisica offriva ora è possibile virtualmente grazie a NFV. Il prossimo stadio della ricerca sulla gestione delle virtual machine nelle reti ci porta invece al Software Defined Networking. Il SDN nasce da alcuni ricercatori della Stanford University intorno al 2008 i quali, stanchi di dover cambiare il software dei dispositivi di rete per ogni nuovo approccio sperimentato, decisero di elaborare un sistema che avrebbe reso il comportamento della rete programmabile e controllabile tramite un entità centrale. L’evoluzione di questa intuizione porta al SDN, che vuole una completa divisione del livello di controllo da quello fisico dei dati. Il pannello di controllo può inviare task agli switch e riprogrammare la rete tramite un protocollo di controllo, 10

attualmente il più utilizzato è chiamato OpenFlow. I clienti conoscono le differenza fra queste tecniche ma non vogliono doversele procurare separatamente, ecco perché VMware le mette a disposizione tutte insieme nei suoi prodotti, offrendo strumenti completi come NSX.

1.4 Benefici tecnici, aziendali ed economici delle reti virtuali

La virtualizzazione di reti rimuove i vincoli fra il software virtualizzato e le reti fisiche, le virtual network sono progettate per essere facilmente flessibili e ed è possibile spostare le macchine virtuali all’interno della rete cambiandone la topologia senza ulteriori costi di re design. Basti immaginare ai guadagni nel poter fornire qualsiasi topologia di rete in poco tempo e senza dover apportare nessuna modifica all’hardware già presente nelle rete fisica o alle applicazioni precedentemente sviluppate su quella rete. Il vero obiettivo delle reti virtuali è astrarre le reti in un livello di rete virtualizzata rendendole indipendenti dalle componenti hardware così da semplificare molto la distribuzione e l'utilizzo delle stesse, inoltre la sicurezza non richiede hardware dedicati e strumenti come il firewall possono essere aggiornati e modellati sulla nuova infrastruttura di rete. Proprio come le virtual machine gestiscono le risorse, le reti virtuali creano un pool unico di capacità di rete che può essere segmentato in differenti reti logiche e sotto-reti. In questa gerarchia le reti possono essere ridimensionate senza riconfigurare l'hardware fisico, o è possibile aggiungere servizi di rete come il firewall e VPN senza problemi. Virtualizzare le macchine ha ridotto di molto i tempi di sviluppo dei server, ma questo guadagno viene attenuato se dobbiamo configurare un server prima di azionare la nostra virtual machine. Inoltre abbiamo vincoli sulla disposizione fisica della rete, e dipendenze hardware richiedono esperti specifici. Con le virtual network questi aspetti sono superati, migliorando lo sviluppo e la manutenzione. Si può avere un 30% o più di guadagno in OpEx (Operating Expenditure: spese relative a gestione e manutenzione di un prodotto) sulle operazioni nella rete. Aziende potrebbero voler sviluppare un applicazione, o migliorarne una, su una rete già esistente. Le virtual network possono emulare la rete in questione durante lo sviluppo e il testing dell'applicazione permettendo di fare nell'ordine di ore quello che verrebbe fatto in settimane. Ma la flessibilità di un’ applicazione entra in contrasto con la 11

sicurezza, le aziende oggi devono essere sempre più attente a cambiare i fattori di controllo e migliorare la sicurezza, ed il trade-off fra flessibilità e sicurezza è arduo anche con l’utilizzo di reti virtuali. Una più veloce distribuzione dei server e set-up delle applicazioni può permettere alle aziende di essere più competitive. Inoltre riducendo la quantità di apparecchiature hardware si riducono i costi delle macchine, degli spazi, della manutenzione, dello scaling, del raffreddamento e dell’alimentazione dei server, risparmiandone in tempo e denaro. 12

Capitolo 2: Realizzazione e gestione di reti virtuali

Prima di entrare nel dettaglio dei software di gestione VMware è bene fare alcune riflessioni generali su come una rete virtuale si presenti e quali siano le principali differenze ed analogie con una rete puramente fisica. Alcuni aspetti delle virtual network possono sembrare simili a quelli di una physical network o potrebbero apparire addirittura più complessi e di difficile gestione, non dobbiamo però dimenticare che quello che avviene nelle reti virtuali avviene perlopiù in sofwtare, questo ne cambia l’approccio e ne semplifica le operazioni di configurazione e manutenzione. Vedremo in questo capitolo le tecniche principali offerte da VMware per la gestione di reti virtuali ed una tabella finale di paragone fra le più avanzate tecniche a disposizione.

2.1 Distinguere una rete virtuale da una rete fisica

Le applicazioni di una rete virtuale hanno bisogno di un dimensionamento delle risorse dedicate e di una quantità di spazio libero in un server proprio come per le reti fisiche, queste vengono però installate in specifici server chiamati ESXi e operano in macchine virtuali ciascuna con uno specifico sistema operativo e carico di lavoro associato. Un server ESXi è un prodotto VMware per la virtualizzazione a livello aziendale, è un evoluzione del precedente ESX. La grossa differenza tra ESX e ESXi è la Service Console. ESX ne è provvisto mentre ESXi no. I vantaggi di avare la Service Console sono: la possibilità di utilizzare driver di terze parti per hardware specifico, utilizzo di software di backup scritto specificatamente per ESX e la possibilità di eseguire tramite script alcune attività direttamente sulla shell della Service Console, senza passare da tool di terze parti. Ma ci sono 13

anche alcuni contro: bisogna mantenere aggiornata la Service Concole poiché è soggetta ad attacchi informatici e crea overhead a livello hardware e nella gestione. ESXi è molto più snello, è più stabile perché non è soggetto a kernel panic che possono derivare dall'utilizzo di driver di terze parti e con la vMA (Virtual Management Assistant) può fare tutto quello che si faceva con la Server Console di ESX. La vMA ha un unico difetto ossia, non avendo visibilità "all'interno" del codice del vmKernel, utilizza lo stack di rete per inviare dei comandi alle API del vmKernel ESXi, non ha quindi un accesso diretto. ESXi ha comunque una shell diretta che permette di eseguire troubleshooting se necessario. Tornando alla nostra rete virtuale, essa dovrà essere collegata a diversi dispositivi come in un mondo puramente fisico, ma con molte meno dipendenze. Il traffico fra dispositivi della stessa rete o, ancora più importante, fra applicazioni ed utenti esterni alla rete utilizza anche in questo caso un protocollo TCP/IP dobbiamo però introdurre nuove tipologie di traffico dati a quelle viste in precedenza. Traffico vMotion: è il traffico gestito da un potente e molto utilizzato strumento VMware chiamato vMotion. Questo oggetto permette di spostare o copiare un’ intera virtual machine da un host ESXi all’altro senza creare downtime o interferire con il lavoro degli altri host, per fare questo necessita di un canale di traffico dedicato ed ad altra priorità. Traffico di Fault Tolerance: Fault Tolerance (FT) fornisce disponibilità ininterrotta alle applicazioni in caso di guasti dei server, creando un' istanza detta shadow (o secondaria) di una macchina virtuale sempre aggiornata rispetto alla macchina virtuale primaria. In caso di guasti all'hardware, FT attiva automaticamente il failover, eliminando i downtime ed evitando perdite di dati. Dopo il failover, FT crea una nuova macchina virtuale secondaria per garantire una protezione continua dell'applicazione. Anche questo traffico necessita un canale dedicato ad alta priorità. Traffico di Virtual SAN (VSAN): tutti gli host che partecipano ad un cluster Virtual SAN mantengono questo flusso di traffico. VSAN è un software di storage a livello supervisore (esamineremo l’entità supervisore parlando del NSX) che astrae e mette insieme la parte flash dei server ed i dischi di memoria per creare uno strato di storage a livello supervisore 14

persistente e ad alta performance. (il nome potrebbe essere ironicamente riferito al Cluster Sun di Oracle) Questi ed altri flussi di traffico aggiuntivi sembrano far apparire una rete fisica meno complessa e più facile da gestire rispetto ad una virtuale, in realtà nelle reti virtuali la segmentazione del traffico può essere facilmente realizzata in pochi passi utilizzando un unico sistema di gestione centralizzato. Per realizzare una rete virtuale fondamentalmente si crea un virtual switch in software, questo appare alle virtual machine come uno switch fisico, possiamo quindi collegare le macchine virtuali allo switch virtuale ed il traffico continua a scorrere come nelle reti fisiche. Sostanzialmente con lo switch virtuale possiamo fare le stesse cose che faremmo con quello fisico, ma in software, questo ci permette di applicare facilmente politiche di funzionamento alle nostre macchine virtuali o ad un loro sottoinsieme, rende la configurazione più facile e presuppone un minore utilizzo di cavi. Uno switch fisico è dotato di porte che possiamo utilizzare per collegarlo ai nostri Server, allo stesso modo un virtual switch è dotato di porte virtuali a cui possiamo collegare le nostre virtual machine, singolarmente o in gruppi chiamati Port Group. Lo switch virtuale utilizza anch’esso un adapter a cui vengono connesse le macchine virtuali, ma si tratta di un adapter virtuale chiamato virtual NIC o vNIC. La rete virtuale si connette tramite il virtual switch alla rete fisica sottostante utilizzando gli adapter fisici (NIC), ed il traffico scorre senza che la rete noti alcuna differenza.

2.2 Strumenti di virtualizzazione di base: VMware vSphere

La gente, soprattutto se clienti e non esperti del settore, fa confusione riguardo questa piattaforma offerta da VMware, iniziamo facendo alcuni chiarimenti su cos’è vSphere e cosa non è. Diciamo fin da subito dire che vSphere non è un particolare software che possiamo installare ed utilizzare! vSphere è una suite, ovvero comprende numerosi componenti software al suo interno. I componenti fondamentali sono ESXi, vSphere client e vCenter Server. ESXi è il server di virtualizzazione. E’ il supervisore di livello più basso del sistema. Tutte le machine virtuali delle rete si appoggiano su server ESXi. Per installare, accedere o gestire queste machine virtuali situate su un server ESXi, abbiamo bisogno di altre 15

componenti della suite vSphere chiamate vSphere client e vCenter Server. Ora, il vSphere client permette all’amministratore di connettersi ai server ESXi ed accedere o gestire le machine virtuali. vSphere client è installato sulla macchina del cliente (ad esempio il computer portatile dell’amministratore di sistema). Il vSphere client è quindi usato per inviare task alle machine in cui è installato il server ESXi. Sorge spontaneo chiedersi cosa sia vCenter Server e perchè abbiamo bisogno di questo terzo componente. Ci sono operazioni che un semplice client in un personal computer non può svolgere, si provi ad esempio ad usare vMotion per clonare una macchine virtuale da un host all’altro. vCenter Server è simile a vSphere client ma è situato in un server dedicato e quindi molto più potente. vCenter server è installato su un server Windows o Linux. VMware vCenter Server è un applicazione di gestione che permette di gestire i server ESXi in maniera centralizzata. vSphere client è allora usato per accedere a vCenter Server e gestire le macchine virtuali tramite questo. Possiamo dire che in grossi ambienti vCenter Server è una componente fondamentale, la licenza vCenter è venduta separatamente. Si consideri il diagramma in Figura 2 per avere un’ idea più chiara. Riassumendo: vSphere è una sofware suite, ESXi è un server supervisore installato su una macchina fisica. vSphere Client è installato in personal computer ed usato per accedere ESXi Server ed installare e gestire le macchine sui server ESXi. vCenter server è installato come macchina virtuale su un ESXi server. vCenter Server è un componente vSphere maggiormente usato in ambienti medio-grandi dove ci sono diversi ESXi server e dozzine di macchine virtuali. Per accedere a vCenter Server si utilizza anche vSphere Client ed è 16

utilizzato a scopi gestionali. Quindi utilizzeremo vSphere client per accedere direttamente I server ESXi in ambienti più piccoli, mentre ci appoggeremo su un vCenter Server per sistemi più estesi. Adesso entriamo nello specifico e vediamo le due principali architetture realizzate nella server virtualization grazie a vSphere. 2.2.1 Virtual Stantard Switch (VSS) Uno dei componenti basilari delle reti virtuali è il Virtual Standard Switch (VSS). E' una componente software collegata agli switch fisici e su cui appoggiano tutte le macchine virtuali tramite i virtual adapter o così detti vNIC. Gli adapter virtuali funzionano come adapter fisici e richiedono driver allo stesso modo, la differenza fondamentale è che possono supportare diversi tipi di driver e quindi operare in diversi sistemi operativi, è sufficiente selezionare il tipo di adapter virtuale da voler utilizzare tramite un apposito tool. Il VSS è connesso ad un ESXi host fisico e le mcchine a lui collegate possono essere gestite dagli ESXi host oppure da un vCenter Server, se gestito da server possiamo effettuare i cambiamenti che desideriamo su più host contemporaneamente, sia manualmente che automaticamente. Possiamo raggruppare insieme più virtual machine, quando ha senso, e operare settaggi comuni. Come già detto un VSS ha delle porte virtuali a cui sono connesse le macchine virtuali ed altre a cui sono connesse le macchine fisiche tramite NIC, due macchine connesse allo stesso VSS hanno il vantaggio di poter comunicare fra loro internamente allo stesso host, senza dover inviare traffico nel mondo esterno. Se invece vogliamo far comunicare una macchina con il mondo esterno dobbiamo utilizzare un UpLink come faremmo con uno switch fisico, questo nelle rete virtuali lo possiamo ottenere utilizzando un UpLink adapter che non è niente di più che un NIC fisico (physical NIC o pNIC) associato ad uno switch reale. Possiamo anche associare diversi vNIC ad una macchina virtuale, potremmo volere che una macchina comunichi internamente ad un VSS con una seconda macchina, e che poi trasferisca questi dati ad una rete esterna tramite un secondo VSS, per farlo ci basta installare due adapter e collegarli con switch virtuali diversi. Potremmo anche voler raggruppare diverse macchine virtuali in diverse reti per divederle logicamente all’interno del nostro ambiente, per fare questo dobbiamo solo creare un nuovo 17

VSS per ogni gruppo di virtual machine. Se i gruppi sono molti questa soluzione non è più efficace, ricordiamo infatti che il Virtual Standard Switch è pensato per ambienti medio piccoli, ambienti più sofisticati richiedono altre soluzioni come il Virtual Distributed Switch o NSX che vedremo in seguito. Una soluzione che possiamo già ottenere con un VSS è la creazione di Port Group. Questo consente di raggruppare virtual machine logicamente ed applicare differenti politiche a interi gruppi di macchine virtuali, gestire opportunamente diverse politiche in diversi Port Group può garantire una migliore sicurezza, segmentazione della rete, migliore performance e gestione del traffico. Ogni gruppo è identificato da una label usata per assicurarsi che diverse macchine virtuali su diversi ESXi host possano connettersi alla stessa sotto-rete o VLAN. Ricapitolando, osserviamo la Figura 3, il traffico di una virtual machine passa dai vNIC per arrivare al Port Group al quale è stata assegnata, lì passa per lo switch virtuale e può comunicare con un’altra virtual machine dello stesso VSS senza uscire dal server, o con il mondo esterno attraverso adapter fisici, una virtual machine può inoltre avere più di un vNIC per connettersi con diverse reti IP contemporaneamente. Il traffico in entrata fa lo stesso percorso ma all’inverso. Come detto all’inizio di questo capitolo una rete virtuale può avere diversi tipi di traffico, anche più di quanti ne avrebbe una rete fisica, e questo può portare a problemi di latenza o 18

congestione. Una buona pratica per attenuare i problemi è quella di creare uno switch virtuale per ogni tipo di traffico differente, ad esempio sarebbe utile avere un VSS dedicato al solo traffico utilizzato da vMotion per la clonazione di macchine fra host. Questo ci riporta alla conclusione che il VSS non è una soluzione adatta ad ambienti troppo grandi. 2.2.2 Virtual Distributed Switch (VDS) Quando la rete diventa complessa e gli host aumentano di numero è sempre più difficile mantenere una configurazione consistente. Per quello che abbiamo visto finora la configurazione dovrebbe essere manualmente replicata su ogni host, questo può essere faticoso, una semplice installazione di vMotion richiede che ogni host abbia almeno un Port Group dedicato ed un identificativo, quello che ci serve è la possibilità di configurare un singolo host e vedere la nostra configurazione replicata in ogni altro host. Per risolvere questo ed altri disagi, insieme a VSS, vSphere fornisce un Virtual Distributed Switch (VDS). Il VDS come il VSS è controllato tramite vCenter Server, per la sua natura distribuita può essere gestito solo così, ed a differenza del modello standard non è limitato al contesto del singolo ESXi perché è installato in maniera distribuita su più host. Essendo associato a più host può effettuare configurazioni in parallelo fra tutti loro, mantenendo così uno stato consistente anche attraverso host multipli (Figura 4). 19

Un VDS funziona come un singolo switch ma attraverso tutti gli host ad esso associati, ogni host ha un proxy switch che contiene i settaggi di rete configurati al livello logico del VDS. Come un VSS lo switch distribuito può consentire il passaggio di traffico fra macchine collegate allo stesso switch o con reti esterne, in questo i Port Group sono distribuiti su host diversi e necessitano quindi una label di rete per essere riconosciuti, una copia di ogni Port Group creato verrà replicata su tutti gli host associati a quel VDS ed ogni modifica nelle politiche adottate su un gruppo verrà anch’essa mantenuta consistente su tutte le copie. Fra ogni host fisico ed il VDS c’è un ulteriore livello di astrazione chiamato dvUpLink, le politiche di net timing, load balancing e failure recovery nello switch e nei Port Group sono applicate dal livello dvUpLink. Come detto è possibile applicare configurazioni in parallelo su tutti gli host tramite un vCenter Server, questo riduce le tempistiche, i costi e migliora la troubleshooting, qualcuno potrebbe notare che un errore di configurazione sul singolo host verrebbe replicato su ogni host, questo può essere in parte risolto con sistemi di rollback forniti dal VDS. L’architettura degli switch virtuali, sia standard che distribuiti, è costruita su due livelli: il Data Plane contenente i dati relativi allo switch ed il Management layer che contiene le istruzioni di controllo. Come già ribadito il Management layer nel VDS è centralizzato, ma ci sono altre differenza fra VSS e VDS da poter sottolineare. Il VSS consente sistemi di traffic shaping solo sul traffico in uscita e supporta la tecnologia VLAN ma non pVLAN (private VLAN), il VDS, al contrario, ha controlli sul traffico anche in entrata, supporta le pVLAN, consente una potenziale personalizzazione del Data e Management Plane. Ulteriori caratteristiche di un VDS sono: integrazione di LACP (link aggregation control protocol) che configura automaticamente aggregazioni di link fra gli host e gli switch fisici di accesso alla rete, template per il backup e ripristino a livello di controllo, supporto di estensioni con switch virtuali realizzati da terze parti come Cisco Nexus 1000V o IBM 5000v, protocolli per l’analisi remota ed il Netflow, ed altro ancora. Per utilizzare un VDS sono necessarie almeno due licenze VMware: vSphere Enterprise Plus level e vCenter Server, in sistemi complessi queste licenze erano spesso affiancate da un altro 20

elemento chiamato vCenter Server heartbeat che però dal 2 Giugno 2014 non è più disponibile e VMware ne ha bloccato la vendita ed il supporto. Da un punto di vista manageriale avere una gestione centralizzata è già di per sé un grande guadagno, è ormai chiaro come questo faciliti la manutenzione e la supervisione dello stato della rete, ma altre caratteristiche del VDS possono essere importanti. Un metodo che configuri automaticamente l’aggregazione di link fra gli host ed il livello fisico di accesso alla rete è un vantaggio gestionale non indifferente ed è reso possibile dal LACP integrato nel VDS. Spesso alcune applicazioni aziendali hanno importanza critica e si vorrebbe che il traffico sui canali che utilizzano sia sempre ad alta priorità e protetto da congestione, VDS utilizza vSphere Network I/O Control (NIOC) per configurare le regole e le politiche a livello di macchina virtuale ed assicurare sempre la disponibilità delle risorse I/O per le applicazioni aziendali critiche. NIOC esegue il monitoraggio della rete ed in caso di rilevamento di congestioni trasferisce automaticamente le risorse alle applicazioni con priorità maggiore. Grazie a NIOC, è possibile migliorare la produttività degli amministratori, estendere la virtualizzazione ad un numero maggiore di carichi di lavoro e rendere l'infrastruttura ancora più flessibile. A questo si aggiunge un sistema di tagging che è molto importante nell’ambito del QoS (Qality of Service) e permette di identificare i pacchetti del traffico VoIP dando una priorità interna al Port Group del traffico di produzione. Vediamo ora i limiti del VDS: intanto VDS è un prodotto per aziende medie o, al limite, medio-grandi, per ambienti su più larga scala non è più una soluzione efficiente, non permette di creare sotto-reti che coprano livelli di rete superiore (network overlay), implementare firewall, NAT o gateway su se stesso, o agire da Load Balancer. Ecco perché abbiamo bisogno di tecniche più avanzate di virtual networking.

2.3 Strumenti di virtualizzazione avanzati: vCSN, VXLAN e NSX

Partendo dalla virtualizzazione dei server, ed arrivando poi ad un livello logico superiore che sono le reti virtualizzate, si abbandona la complessità dell'ingegneria delle reti fisiche e dei problemi relativi all'hardware ed è possibile utilizzare prodotti software per la gestione delle reti. NSX permette di creare reti per ambienti complessi con un hardware general purpose 21

alla base, mentre vCNS permette la gestione di applicazioni aziendali e della loro sicurezza con protocolli di sicurezza basati sul Cloud. vCNS è un insieme di servizi avanzati per applicazioni basate su vSpehere o vCloud, servizi come DHCP, NAT, VPN, Loab Balancer, Firewall, Static routing. Supporta il VXLAN Overlay, di cui parleremo nello specifico, ha una UI di gestione e funziona solo su server ESXi. NSX è un sistema basato su supervisori distribuiti. Prevede anche la gestione di: DHCP, NAT, VPN, Load Balancer e Firewall. Supporta il routing statico e dinamico (BGP, OSPF) e vari tipi di overlay (VXLAN, STT, GRE). A differenza di molti altri prodotti VMware può funzionare su diversi tipi di host oltre ad ESXi, come: KVM, Xen, Hyper-V. Fornisce un set di API per la gestione e la programmabilità della rete. 2.3.1 Virtual Extensible Local Area Network (VXLAN) La VLAN è di per se utile nella creazione di sotto-reti, ma ha delle limitazioni: limitato numeri di reti L2 (layer 2) isolate, diametro limitato per le reti L2, numero massimo di 4094 network ID assegnati nello stesso tempo, impossibilità di cambiare la configurazione fisica della rete su richiesta. Si introduce allora la Virtual Extensible LAN (VXLAN). E' una tecnologia di overlay, una rete di overlay è una rete L3 costruita su un esistente rete L2. VXLAN incapsula un frame L2 in un pacchetto IP L3. La comunicazione è stabilita attraverso un VXLAN Tunnel End Point o VTEP. I VTEP sono i nodi che forniscono le funziona di incapsulamento e de-incapsulamento. Normalmente se una macchina virtuale deve comunicare con un’ altra macchina di una differente sotto-rete, bisogna usare un collegamento di livello 3 per colmare il gap fra le reti, possiamo invece usare vShield Gateway (componente di vCNS, come vedremo) per gestire la comunicazione con segmenti VXLAN. Questa tecnologia richiede componenti che sono tipicamente inclusi nella vCloud suite che comprende anche vSphere Distribuited Switch e vShield Edge Gateway. Il VDS installa un VTEP in ogni host della rete virtuale, a questo si aggiunge anche un controll adapter chiamato VMK che gestisce il traffico di controllo di tipo VXLAN, ed un VXLAN PortGroup che contiene le informazioni necessarie per gestire traffico VXLAN attraverso 22

PortGroup tramite pNIC. La componente vShield crea invece un gateway logico che fa da ponte fra il traffico VXLAN e non. Quindi l’utilizzo di VXLAN conviene principalmente per comunicare fra reti diverse senza dover configurare qualcosa negli switch, per avere più di 4098 VLAN ID e perchè non richiede upgrade software al livello degli switch per funzionare. 2.3.2 vCloud Network & Security (vCNS) Immaginiamo la nostra rete come un appartamento, dove internet è il mondo esterno. Per entrare nel nostro appartamento bisogna identificarsi e chiedere il permesso, perché bloccati da una porta. Possiamo vedere le porte come firewall che filtrano il traffico in ingresso ed in uscita. All'interno dell'appartamento ci sono poi diverse porte che dividono i diversi ambienti, nelle reti abbiamo diverse sotto-reti e possiamo applicare firewall aggiuntivi anche per quelle. Questa gestione della sicurezza sarebbe ardua se fatta singolarmente per ogni rete fisica e per ogni dispositivo di sicurezza, con l'uso di strumenti come vCNS si può più facilmente gestire la sicurezza di rete, e disporremo anche di alcuni servizi che i classici switch di rete non offrono. VCNS rende ancora più facile la gestione delle virtual network, aiuta a creare reti per i clienti ed aiuta i clienti ad implementare sotto-reti e servizi facilmente. Questo vuol dire che adesso oltre a creare reti virtuali al volo, possiamo fornirle di strumenti aggiuntivi come firewall, DHCP, NAT ecc. Questi servizi fanno parte della 23

vCloud suite che comprende anche vSphere ed altri strumenti necessari a creare e gestire una rete tramite vCNS. Quelle fin’ ora menzionate non sono le uniche cose che questa suite può fare, oltre al VXLAN che abbiamo visto in dettaglio, vCNS dispone di cinque componenti principali, tutti protetti e facilmente gestibili nell'ambiente vCloud. Il componente più semplice è vShield manager, interagisce con il vCentral Server usando un plug-in di vSphere client e permette di gestire, archiviare e controllare tutti i componenti vCNS usando una semplice interfaccia. Per gli altri quattro componenti si faccia riferimento alla Figura 5. Focalizzeremo la nostra attenzione su vShield Edge Gateway quindi facciamo solo un breve accenno agli altri elementi. vShield Data Security è la componente che protegge i nostri dati nei server fornendo la possibilità di assegnare politiche personalizzare e di offrire maggior sicurezza ai dati sensibili. vShield Endpoint garantisce sicurezza all'interno dei sistemi operativi in cui sono installate le applicazioni, e che sono in comunicazione con la rete. vShield App è un servizio di firewall che protegge le applicazioni da attacchi network based. Infine vShield Edge Gateway consente il controllo e la sicurezza di servizi a livello Gateway o in macchine virtuali selezionate come quelle di un Port Group o un Distributed Switch Port Group. vSphere Edge Gateway fornisce classici servizi di gateway fra cui il Load Balancing, che è davvero utile se vogliamo gestire il traffico in entrata, ad esempio se il traffico è diretto 24

ad uno specifico IP fra tanti IP interni, possiamo scegliere fra vari algoritmi di balancing come il RoundRobin. Se un gateway fallisce in una rete fisica la connessione con la rete è persa, localmente si può settare il gateway in una configurazione di così detta 'alta disponibilità' (high availability) che permette di indentificare rapidamente i guasti e ridurre al minimo il downtime che ne deriva. Tornando all’esempio dell’appartamento possiamo immagine il vCNS come colui che ci permette di chiudere a chiave le nostre porte, configurando firewall a livello virtuale per filtrare il traffico in entrata o anche implementare il NAT evitando conflitti di indirizzi IP pubblici. Ricordiamo che tutte queste funzionalità (alcune delle quali potrebbero sembrare scontate in una rete) sono adesso sviluppate in software e non erano ad esempio disponibili con la sola suite vSphere. Il vShpere Edge Gateway supporta anche il DHCP quindi non bisogna preoccuparsi di assegnare manualmente un indirizzo IP ad ogni macchina, inoltre ci da la possibilità di scegliere il range di IP da poter utilizzare. Sempre grazie al nostro gateway virtuale è possibile creare connessioni private fra reti o fra la nostra rete ed internet attraverso VPN, questo crea un tunnel di comunicazione fra le parti che rende il passaggio dati più sicuro grazie ad un sistema di criptaggio. Queste ed altre funzioni fanno parte di vCNS, che può essere associato ad altre soluzioni VMware per aumentarne la sicurezza e la troubleshooting. 2.3.3 NSX Come più volte sottolineato, configurare una rete puramente fisica chiede tempi e costi decisamente alti perché ogni componente va configurato separatamente, ed un singolo errore può infettare l’intero sistema. Con le reti virtuali è possibile ridurre i tempi da giorni a minuti, grazie a NSX è possibile rendere operativa una rete virtuale con la stessa semplicità con cui si crea una macchina virtuale, basta modificare qualche network segment, qualche virtual machine, qualche switch e qualche router, applicare delle politiche di sicurezza e abbiamo una rete virtuale pronta all’uso, che può essere salvata, consegnata ed abilitata proprio come una virtual machine. Si immagini di inserire un supervisore fra la rete fisica e le virtual machine, è possibile collegare macchine virtuali alla rete senza passare per la rete 25

fisica, che è usata solo come un IP BackPlane. Si possono ottenere servizi web e software in maniera più semplice senza bisogno di configurare hardware, VLAN fisiche, cambiare configurazioni di firewall, ecc. Questo migliora molto l’identificazione e la prevenzione dei problemi derivanti da sbagli di configurazione, NSX utilizza un sistema di configurazione automatica e fornisce parecchie informazioni da tutti i supervisori per risolvere facilmente errori e problematiche. Ogni supervisore ha uno switch virtuale, quindi c'è un sovraccarico (overhead) molto piccolo. E tutto questo non richiede nessun hardware dedicato, NSX funziona sull’ hardware già posseduto dal cliente. NSX è una suite completa di tutti gli elementi software necessari ad amministrare una rete virtuale in maniera semplice, include switch logici, router, firewall, load balancer, VPN, QoS, monitoring ed i sistemi di sicurezza di vCNS. Permette di sviluppare qualsiasi tipologia di rete tramite API programmabili e funzionanti con qualsiasi rete fisica IP alla base, e su supervisori installati su qualsiasi tipo di server, collegabili con ogni tipo di rete esterna, e utilizzabili con qualsiasi piattaforma Cloud (vCloud, OpenStack, CloudStack). NSX si trova al livello virtuale, fra quello fisico ed il Cloud. L'indipendenza con il livello Cloud è fornita, come accennato, da una serie di API esponendo i servizi di rete ad ogni piattaforma di livello più alto. L'isolamento dal livello fisico è invece garantito dall'overlay tramite il VXLAN. L'architettura NSX (Figura 7) è disegnata utilizzando un design pattern a tre livelli: 26

Management Plane, Control Plane e Data Plane. Il Management Plane offre le API con il mondo esterno, il Control Cluster è il cuore dell' architettura ed offre una mappatura in tempo reale dello stato del sistema progettato e quello attualmente in uso, queste informazioni sono usate per settare gli switch ed aggiornare i firewall attraverso dei task delegati dal Control Cluster ad ogni supervisore, consentendo così di mantenere la topologia e le caratteristiche di rete desiderate. Il Data Plane contiene i supervisori, gli switch, le macchine virtual ecc.. e svolge i task inviati dal Control Cluster. L’amministratore di sistema può effettuare il login ad un client che è connesso con il sistema e detiene in ogni momento tabelle, mappature della rete e dati messi a disposizione dai supervisori, è così più facile monitorare la rete e risolvere problemi. L'amministratore può avere un chiaro quadro dello stato delle reti tramite le componenti di gestione del NSX, è possibile proprio come per le virtual machine avere istantanee del sistema, effettuare backup, ripristini ecc. NSX Control Cluster fornisce un livello di controllo logicamente centralizzato ma fisicamente distribuito, ogni macchina NSX ed il cluster condividono una pari porzione del carico di lavoro e mantengono un backup per ogni componente del cluster. La componente di controllo ha visibilità su tutte le virtual machine ed i servizi della rete. Sulla base della topologia desiderata comunica in tempo reale con i vari componenti settando l'appropriata configurazione. Se la topologia della rete desiderata cambia dinamicamente il Control Cluster aggiorna i dispositivi necessari a soddisfare le nuove specifiche. NSX possiede anche servizi di Gateway per la comunicazione sicura con l'esterno. Questi Gateway forniscono tutti i classici servizi (firewall, NAT, ecc..). Alcune applicazioni in reti non virtuali potrebbero voler comunicare con le reti NSX, esiste quindi anche un servizio di gateway L2 per collegamenti con VLAN di altre reti fisiche. Dovendo gestire reti di grosse dimensione NSX, a differenza di vCNS, supporta anche algoritmi di routing dinamico. Ogni supervisore ha un NSX Virtual Switch con un Data Plane programmabile di livello L2 L4 ed un database di configurazione. Inoltre esistono dei canali di comunicazioni fra supervisori che incapsulano i dati ed offrono accoppiamento fra supervisori e rete fisica in modo analogo all'incapsulamento ed accoppiamento fra virtual machine e macchine fisiche. 27

Abbiamo dunque scoperto che NSX è lo strumento più completo e maggiormente utilizzato nei grandi ambienti, permette di cambiare topologia di rete facilmente, migliorarne il monitoraggio e la sicurezza, distribuire il carico di lavoro su ogni virtual machine che può essere spostata lungo la rete assieme e tutti i servizi ad essa connessi, e tutto questo senza mettere mano alla rete fisica sottostante.

2.4 vCNS e NSX al confronto

Vediamo ora in una tabella le principali caratteristiche di vCNS e NSX messe a confronto:

Componenti

Switching Routing Firewall Load Balancer VPN Supporto dei Supervisori Gestione

vCNS

Virtual Distributed Swtich con VXLAN overlay (richiede multicast nella rete fisica) Router virtuale centralizzato, Routing sia statico che routing statico, supporta il NAT dinamico, sia distribuito che centralizzato, supporta il NAT Firewall virtuali, Virtualization aware Load Balancer virtuale

NSX

NSX vSwitch, overlay completo della rete virtuale, Bridging da livello logico a fisico (da VXLAN a VLAN) Firewall virtuali distribuiti, Virtialization and Identity aware, monitoraggio attivo Load Balancer logico, Load Balancer L7 VPN site-to-site e ad accesso VPN site-to-site e ad accesso remoto Solo server ESXi remoto ESXi, KVN, Xen server, Hyper-V Gestione basilare tramite UI Service Composer , NSX Manager, NSX API 28

Capitolo 3: Casi d’uso

Dopo aver ribadito più e più volte che gli elementi analizzati possano migliorare la troubleshooting di Data Client anche medio-grandi, concludiamo questo elaborato mostrando degli esempi di problematiche aziendali risolte tramite l’utilizzo degli strumenti VMware visti. Vedremo in particolare le ultime due suite software discusse, vCNS e NSX.

3.1 vCNS Use Case

Una grande azienda gestisce applicazioni e servizi web per la ricerca e l’affitto di hotel in Europa. Questa azienda dopo anni di attività ha comprato un’altra azienda più piccola che gestiva servizi online di autonoleggio, l’idea è quella di accorpare i due settori per offrire ai clienti un’unica piattaforma dove poter sia prenotare la propria stanza che affittare un’ auto per il periodo di vacanza. Problema: Le macchine virtuali precedentemente installate su una rete dovrebbero ora comunicare con una nuova sotto-rete installata in un’ aggregazione di switch fisicamente distante. Si è pensato di creare un tunnel di comunicazione diretto per collegare le virtual machine delle due sotto-reti in maniera diretta, la cosa è possibile ma gli amministratori di rete sottolineano che richiederebbe la riconfigurazione di parecchi device esponendosi troppo ad errori e problematiche. Inoltre si vuole che le nuove applicazioni abbiano le stesse politiche di sicurezza di quelle già esistenti ma non è conveniente, per lo stesso motivo, riconfigurare ogni firewall nella nuova sottorete. Soluzione: Utilizzando vCNS è possibile collegare le due sotto-reti tramite un sistema VXLAN, questo 29

porterebbe gli stessi risultati di un tunnel L2 ma senza problemi di riconfigurazioni, semplicemente incapsulando i dati e inviandoli in una rete di overlay L3. Con la stessa suite è poi possibile riconfigurare tutti i firewall contemporaneamente applicando le stesse politiche di sicurezza sull’intero gruppo di applicazioni coinvolto.

3.2 NSX Use Case

Una software-house produttrice di videogiochi lancia sul mercato un nuovo gioco online con un’ idea vincente. Negli anni il gioco riscatta un notevole successo, l’utenza sale a dismisura e vengono acquistati nuovi server fino ad un sistema che comprende circa 300 macchine. Problema: Nella competizione mondiale in cui l’azienda si ritrova catapultata, necessita ora di un sistema più efficace per distribuire le sue patch, per gestire l’utenza, per riconfigurare facilmente una rete in cui gli utenti connessi continuano ad aumentare e per migliorare la sicurezza degli account. Il tutto senza dover riconfigurare ognuna delle centinaia di macchine che possiede. Soluzione: NSX consente la gestione di sistemi molto grandi, anche circa 500 server, e la cosa più importante è che non richiede sostituzioni o modifiche all’hardware presente. L’azienda può quindi installare NSX sulla sua rete fisica e riconfigurare una nuova topologia di rete in breve tempo. Riducendo il downtime, grazie ai supervisori ed i vSwitch distribuiti, può aggiornare i server senza privare l’utenza dei suoi servizi per troppo tempo. La gestione della rete è più facile ed i feedback degli utenti possono essere risolti molto più rapidamente, gli amministratori di rete applicheranno infine politiche di sicurezza più consone alla nuova mole di account senza dover riconfigurare fisicamente ogni firewall. 30

Bibliografia

[1]VMware, https://mylearn.vmware.com/mgrreg/courses.cfm?ui=www_edu&a=one&id_sub ject=52533 (Tutte le figure utilizzate nell’ elaborato sono tratte dal corso presente in questo riferimento) [2] IEEE, JOURNAL OF LIGHTWAVE TECHNOLOGY, VOL. 31, NO. 4, FEBRUARY 15, 2013, http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6272301 [3]Cloudtweaks, December 3, 2012, http://cloudtweaks.com/2012/12/the-history-of virtualization/ [4] VMware, http://www.vmware.com/it/products/horizon-mirage [5] VMware, http://www.vmware.com/products/vsphere/features/vmfs.html

[6] VMware, http://www.vmware.com/it/products/vsphere/features/fault-tolerance.html

[7] VMware, https://www.vmware.com/products/vcenter-server-heartbeat.html

[8] Prayson Pate , March 30, 2013, http://www.sdncentral.com/technology/nfv-and-sdn whats-the-difference/2013/03 [9] VMware, http://www.vmware.com/it/products/vsphere/features-network-io-control 31