VMware vcloud Director con Hitachi Compute Blade 2000 e Hitachi Virtual Storage Platform

Transcript

1 VMware vcloud Director con Hitachi Compute Blade 2000 e Hitachi Virtual Storage Platform Architettura di riferimento Henry Chu Agosto 2011 Soluzioni storage Hitachi

2 Feedback Hitachi Data Systems è lieta di ricevere il vostro feedback. Potete comunicarci il vostro parere inviando un' a SolutionLab@hds.com. Non dimenticate di menzionare il titolo di questo white paper nel vostro messaggio. 1

3 Indice Panoramica della soluzione... 4 Componenti della soluzione... 5 Hitachi Compute Blade Hitachi Virtual Storage Platform... 5 La famiglia Hitachi Adaptable Modular Storage VMware vcloud Director VMware vsphere Design della soluzione... 7 Infrastruttura di calcolo... 7 Infrastruttura di rete Infrastruttura di storage Prestazioni e scalabilità Prestazioni di calcolo Prestazioni di storage Prestazioni applicative Conclusione Appendice Terminologia

4 VMware vcloud Director con Hitachi Compute Blade 2000 e Hitachi Virtual Storage Platform Architettura di riferimento L'utilizzo di un'infrastruttura VMware vsphere può migliorare l'agilità dei data center e la loro efficacia. Tuttavia non tutti i silos infrastrutturali utilizzano le risorse in modo efficiente: per ogni silo il grado di utilizzazione può variare, da molto basso fino a un valore prossimo alla piena capacità. La gestione manuale delle risorse per affrontare i momenti di massima utilizzazione può richiedere del tempo e risultare complessa. Un modello a silos spesso comporta un utilizzo non efficiente delle risorse, che non soddisfa così le crescenti esigenze gestionali delle aziende. Un nuovo approccio privilegia un'infrastruttura con servizi condivisi per aggregare risorse da tutti i silos disponibili per tutte le organizzazioni. Tuttavia, per questa soluzione sono necessari una multi-tenancy integrata, elevata disponibilità, un sistema integrato di controllo della qualità di servizio e facilità di provisioning. VMware vcloud Director consente di affrontare e vincere queste sfide grazie a una piattaforma di cloud computing IaaS (Infrastructure as a Service, infrastruttura come servizio). La condivisione dell'infrastruttura VMware vsphere con vcloud Director fornisce pool di risorse dinamici, con capacità on-demand, sulla base di un modello selfservice. VMware vcloud Director introduce il concetto di provider virtual data center (vdc), che assicura una chiara separazione delle risorse organizzate in un pool. Ogni organizzazione utilizza i propri pool di risorse tramite portali self-service individuali. vcloud Director, costruito su vsphere, fornisce il livello di astrazione necessario per consentire mobilità all'infrastruttura cloud e multi-tenancy. L'infrastruttura sottostante deve assicurare grande disponibilità ed elasticità. Per consentire una fluida gestione delle risorse on-demand, anche l'infrastruttura di storage deve possedere le stesse caratteristiche. Hitachi Virtual Storage Platform è la piattaforma di storage ideale per VMware vcloud Director, poiché offre una capacità di virtualizzazione tale da consentire una gestione centralizzata di sistemi di storage multipli, inclusi quelli che non dispongono delle funzionalità di Virtual Storage Platform. Tutte le dotazioni e le funzioni di Hitachi Virtual Storage Platform possono essere applicate a un ambiente storage eterogeneo, rendendolo omogeneo. Hitachi Dynamic Provisioning può creare pool di risorse dinamici con disponibilità on-demand. Grazie a VMware vstorage APIs for Array Integration le risorse di storage vengono integrate in VMware vsphere, incrementando così l'efficienza operativa tramite l'accelerazione dell'hardware. L'architettura di riferimento è concepita per amministratori di sistemi di storage, vcloud, vsphere e applicazioni che devono gestire ambienti di grandi dimensioni e dinamici, richiede familiarità con i sistemi di storage basati su storage area network (SAN), VMware vsphere e le generali pratiche operative nell'ambito dello storage. 3

5 Panoramica della soluzione L'architettura di riferimento utilizza: Hitachi Compute Blade 2000 (CB 2000) Una piattaforma su server di classe enterprise Hitachi Virtual Storage Platform (VSP) Una soluzione di storage ad alte prestazioni ed elevata scalabilità Hitachi Adaptable Modular Storage 2100 (AMS 2100) Una soluzione di storage low cost, con funzione activeactive completamente operativa, di classe midrange Switch Brocade 5340 Fibre Channel Garantisce la connettività SAN alla rete dei data center VMware vsphere 4.1 La tecnologia di virtualizzazione che costituisce la base del cloud computing VMware vcloud Director 1.0 Piattaforma cloud basata su un'infrastruttura VMware vsphere per consentire l'utilizzo del cloud computing di tipo IaaS (Infrastructure as a Service, infrastruttura come servizio) In figura 1 si riporta un diagramma dell'architettura di riferimento che mostra la connettività di rete e Fibre Channel, caratterizzata da ridondanza. Figura 1 4

6 Componenti della soluzione Di seguito si descrivono i componenti dell'architettura di riferimento. Hitachi Compute Blade 2000 Hitachi Compute Blade 2000 è una piattaforma su blade server di classe enterprise, che offre le seguenti funzionalità: Un'architettura bilanciata che elimina i colli di bottiglia nelle prestazioni e nella produttività Virtualizzazione con partizione logica integrata Flessibilità di configurazione Risparmio energetico ecosostenibile Sistema di ripristino rapido basato su cold standby N+1, che consente la sostituzione dei server non funzionanti nel giro di pochi minuti La virtualizzazione con partizione logica è integrata nel firmware di Hitachi Compute Blade Questa tecnologia collaudata, di classe mainframe, unisce l'esperienza acquisita da Hitachi nel partizionamento logico alla tecnologia Intel VT, con miglioramenti in termini di prestazioni, affidabilità e sicurezza. La virtualizzazione con partizione logica integrata non compromette le prestazioni delle applicazioni e non richiede l'acquisto e l'installazione di componenti aggiuntivi. Hitachi Virtual Storage Platform Hitachi Virtual Storage Platform è una piattaforma di storage con scalabilità 3D che, grazie alla possibilità di combinare le funzioni di scale up, scale out e scale deep contemporaneamente in un singolo sistema di storage, consente di adeguare prestazioni, capacità, connettività e virtualizzazione in modo flessibile. Scale Up Per aumentare le prestazioni, la capacità e la connettività aggiungendo cache, processori, connessioni e dischi al sistema di base. Scale Out Per combinare più chassis in un singolo sistema logico con risorse condivise. Scale Deep Per estendere le funzioni avanzate della Virtual Storage Platform allo storage esterno multivendor. Hitachi Virtual Storage Platform dispone di funzionalità complementari a VMware vcloud Director. Pool di risorse con VMware DRS e Hitachi Dynamic Provisioning Hitachi Dynamic Provisioning, una funzionalità di Hitachi Virtual Storage Platform, aggrega le risorse di storage in un pool analogamente a come VMware DRS è in grado di aggregare le risorse computazionali. I provider virtual data center (vdc) in VMware vcloud Director sono associati direttamente VMware DRS per i pool di risorse computazionali e a Hitachi Dynamic Provisioning per i pool di risorse di storage. Le capacità di creazione di pool di VMware DRS e Hitachi Dynamic Provisioning sono in grado di creare una base di calcolo dinamica e attribuire le risorse ai provider virtual data center. Con Hitachi Dynamic Provisioning è possibile incrementare o ridurre la capacità di storage e le prestazioni, aumentando o diminuendo i blocchi di parità nel pool di dynamic provisioning. Hitachi Dynamic Provisioning consente inoltre l'oversubscription della capacità e fornisce la funzione di striping che consente un'ampia suddivisione su tutti i dischi del pool. 5

7 Agilità nell'elaborazione dei dati con Mware Storage vmotion e Hitachi Tiered Storage Manager Hitachi Tiered Storage Manager è in grado di migrare volumi logici allo storage interno ed esterno su Hitachi Virtual Storage Platform senza interruzioni della normale operatività. Utilizzate Hitachi Tiered Storage Manager per i volumi logici a livello del sistema di storage: le migrazioni eseguite con questa funzionalità sono completamente trasparenti per la macchina virtuale e per gli host ESX. La migrazione dei volumi logici in modalità non-disruptive garantisce la mobilità dei dati per i provider virtual data center. Si tratta di una soluzione di migrazione dei dati di storage multilivello per i provider virtual data center, in cui, a seconda delle esigenze gestionali, è possibile passare in modo dinamico a un livello di servizio superiore o inferiore. Storage vmotion è un componente di VMware che migra in modo non-disruptive i dischi della macchina virtuale ai datastore VMFS sugli host ESX. Utilizzate VMware Storage vmotion su una macchina virtuale a livello del datastore VMFS. Funzione di accelerazione dell'hardware per le normali operazioni vsphere Le operazioni chiave sui dati di Hitachi Virtual Storage Platform sono gestite da VMware vstorage APIs for Array Integration (VAAI) anziché dal layer del server ESX, in modo da ridurre l'utilizzo delle risorse e potenziali colli di bottiglia su server fisici, garantendo inoltre una performance del server più costante e una densità maggiore della macchina virtuale. Hitachi Virtual Storage Platform supporta tutte le primitive VMware vsphere 4.1 VAAI API. Le seguenti primitive API procurano vantaggi diretti in un ambiente vcloud: Full copy Consente a Hitachi Virtual Storage Platform di realizzare copie complete dei dati all'interno del sistema di storage, senza che siano necessarie la lettura e la scrittura da parte dell'host ESX. Le operazioni di lettura e scrittura vengono quindi scaricate su Hitachi Virtual Storage Platform, con una sostanziale riduzione dei tempi di provisioning per la clonazione delle macchine virtuali in vcloud Director. Hardware-assisted locking Consente all'host ESX di eseguire l'offload di operazioni di blocco su Hitachi Virtual Storage Platform L'offload delle operazioni di blocco consente di disporre di una piattaforma di storage ad alta scalabilità per vcloud Director, nel caso in cui le risorse di storage comuni siano condivise da un elevato numero di macchine virtuali. È disponibile anche un metodo di blocco granulare LUN che consente di eseguire il locking a livello dell'indirizzo LBA (logical block address) senza fare ricorso alle prenotazioni SCSI o senza dover bloccare l'intero LUN mediante altri host. Per ulteriori informazioni consultare la pagina Hitachi Virtual Storage Platform sul sito Internet di Hitachi Data Systems. Hitachi Adaptable Modular Storage 2000 Family I sistemi della famiglia Adaptable Modular Storage 2000, di classe midrange, sono dotati di Hitachi Dynamic Load Balancing Controller, che assicura un bilanciamento integrato, automatico e di tipo hardware del carico I/O front-toback-end, eliminando così per i soggetti che gestiscono lo storage l'esecuzione di task complessi e ai quali è necessario dedicare molto tempo. In questo modo il traffico I/O verso le unità disco back-end è gestito e bilanciato dinamicamente ed è condiviso in modo equo tra i due controller. L'architettura back-end point-to-point elimina ritardi nel traffico I/O e i problemi di contesa che si verificano con la topologia Arbitrated Loop di Fibre Channel, fornendo inoltre una larghezza di banda significativamente più elevata e un I/O perfettamente simultaneo. Grazie alle porte Fibre Channel con configurazione active-active l'utente non deve preoccuparsi della proprietà del controller; il traffico I/O viene infatti trasferito al controller mediante una comunicazione cross-path e qualsiasi percorso può essere utilizzato come percorso normale. I controller di Hitachi Dynamic Load Balancing bilanciano il carico del microprocessore trasversalmente ai diversi sistemi di storage. Se un microprocessore risulta troppo carico, il LU management si attiva immediatamente per eseguire il bilanciamento. Per ulteriori informazioni sulla serie Adaptable Modular Storage 2000 consultare il sito Internet Hitachi Data Systems Adaptable Modular Storage. 6

8 VMware vcloud Director 1.0 VMware vcloud Director 1.0 raggruppa le risorse dei data center formando un'infrastruttura di cloud computing, sfruttando l'efficiente pooling consentito da infrastrutture virtuali on-demand e autogestite per mettere a disposizione risorse utilizzabili come servizi. L'architettura di riferimento è focalizzata sull'utilizzo di VMware vcloud Director come livello IaaS (Infrastructure as a Service - infrastruttura come servizio). VMware vcloud Director, in abbinamento a VMware vsphere, estende le capacità della vostra infrastruttura virtuale nella fornitura dei servizi di cloud computing. Ulteriori informazioni su VMware vcloud Director sono disponibili sul sito Internet di VMware. VMware vsphere 4.1 VMware vsphere 4.1 è una piattaforma di virtualizzazione molto efficiente che fornisce un'infrastruttura per data center robusta, scalabile e affidabile. VMware vsphere dispone di funzionalità come VMware Distributed Resource Scheduler (DRS). VMware High Availability e VMware Fault Tolerance costituiscono una piattaforma facile da gestire. VMware vsphere 4.1 supporta vapp, un raggruppamento logico di una o più VM in formato aperto di virtualizzazione, in cui è possibile incapsulare un'applicazione multilivello con livelli di servizio e policy. L'utilizzo della policy di multipath round-robin fornita dall'hypervisor VMware ESX 4, con bilanciamento del carico dinamico grazie al controller simmetrico active-active di VMware DRS, consente di distribuire il carico su diversi host bus adapter (HBA) e porte di storage. Ulteriori informazioni sono disponibili alla pagina Internet VMware vsphere. Design della soluzione Di seguito sono descritte le infrastrutture di calcolo, di rete e di storage utilizzate per l'architettura di riferimento. Infrastruttura di calcolo L'infrastruttura di calcolo nell'architettura di riferimento è la seguente: VMware vcloud Director 1.0 VMware vsphere 4.1 Hitachi Compute Blade 2000 VMware vcloud Director 1.0 VMware vcloud Director crea risorse astratte dall'infrastruttura VMware vsphere. Ogni risorsa astratta viene quindi messa a disposizione con il deployment della sua stessa macchina virtuale. Il set completo delle risorse astratte costituisce lo stack delle risorse. La figura 2 rappresenta lo stack delle risorse di VMware vcloud Director utilizzato nell'architettura di riferimento. 7

9 Figura 2 Esistono provider virtual data center e organization virtual data center. Gli utenti finali accedono al virtual data center dell'organizzazione come portale self-service. L'utente effettua il login all'interfaccia web di VMware vcloud Director che consente l'accesso alle risorse computazionali, di rete e di storage allocate. Un organization virtual data center può allocare risorse computazionali in tre modi: Allocation Pool Una percentuale delle risorse allocate è assegnata a un organization virtual data center. L'overcommit è controllato dall'amministratore di sistema. Pay-As-You-Go Le risorse allocate sono assegnate a un organization virtual data center solo quando si crea una vapp. Reservation Pool Tutte le risorse allocate sono assegnate a un organization virtual data center. In qualsiasi momento gli utenti possono controllare l'overcommit della capacità. L'architettura di riferimento è stato utilizzato il modello Allocation Pool, che consente di controllare l'allocazione delle risorse nel miglior modo possibile. Le risorse sono assegnate a un'organizzazione con o senza overcommit. La tabella 1 mostra la distribuzione delle risorse per il pool di allocazione; in questo caso non è possibile l'overcommit delle risorse. 8

10 Tabella 1. Allocazione delle risorse a livello di organization virtual data center per pool senza overcommit Organizzazione di livello oro Organizzazione di livello Organizzazione di livello bronzo argento CPU 100% di 81 GHz 100% di 63 GHz 100% di 51 GHz Memoria 100% di 138GB 100% di 132 GB 100% di 123 GB Un organization virtual data center può essere autorizzato ad accedere ad un grande pool di risorse di CPU e di memoria contenuto nel pool di risorse del proprio provider virtual data center. La tabella 2 mostra la distribuzione delle risorse per i pool di allocazione che consentono l'overcommit delle risorse. Tabella 2. Allocazione delle risorse a livello di organization virtual data center per pool con overcommit Organizzazione di livello oro Organizzazione di livello Organizzazione di livello bronzo argento CPU 39% di 200 GHz 31% di 200 GHz 25% di 200 GHz Memoria 34% di 402 GB 33% di 402 GB 31% di 402 GB La percentuale di risorse prenotata può essere utilizzata per garantire un minimo di risorse sempre disponibile all'organization virtual data center. Eventuali risorse rimanenti sono disponibili per l'organization virtual data center solo quando possono essere fornite dal provider data center. Questo modello può essere utilizzato per l'overcommit di risorse. Le risorse computazionali possono essere modificate in modo dinamico per ogni organizzazione. Poiché le esigenze in termini di risorse computazionali delle singole organizzazioni sono in continuo mutamento, le risorse di CPU e di memoria possono essere incrementate o ridotte in modo individuale per venire incontro alle richieste del provider data center. Ogni organization virtual data center è associato a un provider data center, il quale può essere utilizzato per classificare determinare livelli di service level agreement o persino le tipologie applicative. In figura 2 sono riportati i tre provider data center utilizzati nell'architettura di riferimento: oro, argento e bronzo. Ciascuno di essi garantisce livelli diversi per quanto riguarda le risorse di CPU e di memoria. Ogni provider data center è associato a un pool di risorse all'interno di un cluster VMware vsphere DRS. Questi pool di risorse non sono creati da VMware vcloud Director, ma vengono creati manualmente con VMware vcenter e sono utilizzati per raggruppare logicamente diversi provider virtual data center. Di norma si consiglia di configurare solo un pool di risorse per ogni livello di servizio, in modo da differenziare i vari livelli. Per esempio, potete configurare un pool di risorse per ogni provider virtual data center di livello oro, argento e bronzo. Configurate e create tutti i pool di risorse di livello subordinato per mezzo di vcloud Director. VMware vsphere 4.1 L'infrastruttura VMware vsphere 4.1 rappresenta la base a seconda della quale vcloud Director definisce le risorse. Per ottenere le migliori prestazioni da vcloud Director è necessaria un'infrastruttura robusta e dall'elevata disponibilità. L'infrastruttura VMware vsphere è stata configurata in due parti: Cluster di management Fornisce le applicazioni e i servizi necessari a VMware vcloud Director. Cluster di risorse Fornisce le risorse a ogni macchina virtuale installata tramite VMware vcloud Director come cluster dedicato, con capacità di calcolo raw per il consumo da parte dei tenant. 9

11 Si garantisce così una chiara separazione tra le risorse destinate alle operazioni di management e le risorse cloud. Cluster di management La figura 3 rappresenta il cluster di management utilizzato per far fronte alle esigenze in termini di infrastruttura connesse con l'esecuzione di VMware vcenter, Oracle Database e VMware vcloud Director. Figura 3 Il cluster di management contiene i seguenti componenti e funzionalità: vcenter Server 4.1 Gestione generale dell'infrastruttura virtualizzata Oracle 11G Macchine virtuali Red Hat Enterprise Linux 5 con Oracle 11G. Necessario per le istanze del database di vcenter Server 4.1 e vcloud Director 1.0 vcloud Director 1.0 Cell Una singola istanza VMware vcloud Director che costituisce il componente core di vcloud Director. Si crea così un nuovo livello di astrazione che facilita la comunicazione tra i server vcenter ed ESX, con l'accettazione delle richieste dei clienti finali tramite un portale web integrato e le chiamate vcloud API. vshield Manager Componente di management di vshield Suite. È responsabile dell'installazione dell'agente vshield (vshield Edge), della configurazione delle regole del firewall e della gestione. VMware segnala la seguente raccomandazione in relazione al numero di celle necessarie: Numero di celle VMware vcloud = Numero di istanze VMware vcenter + 1 La cella aggiuntiva indicata nella formula viene utilizzata nei casi seguenti: Come cella di riserva per failover Quando è necessario disattivare una cella per interventi di manutenzione Inoltre su una singola cella vcloud dovrebbe essere mappata un'unica istanza vcenter, in modo da assicurare un consumo delle risorse maggiormente bilanciato tra le celle in termini di carico. Per altre informazioni sulle best practice relative a vcloud Director consultare VMware vcloud Director Prestazioni e best practice. 10

12 La tabella 3 descrive la configurazione della macchina virtuale per ogni servizio. VMware vcenter e VMware vcloud Director si trovano su macchine virtuali separate rispetto alle loro applicazioni database. Tabella 3. Configurazione della macchina virtuale per ogni servizio del cluster di management Applicazione SO CPU Memoria Disco Virtuale VMware vcenter 4.1 Microsoft Windows 2 vcpu 4096 MB 100 GB Eagerzeroedthick (SO) Server 2008 R2 Enterprise Oracle Database 11g (vc Microsoft Windows 4 vcpu 8192 MB 40 GB Eagerzeroedthick (SO), 256 GB DB) 2008 R2 Enterprise Eagerzeroedthick (DB) VMware vcloud Director Red Hat Enterprise 2 vcpu 4096 MB 40 GB Eagerzeroedthick (SO) 1.0 Linux 5.5 Oracle Database 11g (vcd Microsoft Windows 4 vcpu 8192 MB 40 GB Eagerzeroedthick (SO), 100 GB DB) 2008 R2 Enterprise Eagerzeroedthick (DB) Nel cluster di management il carico delle macchine virtuali è distribuito da Dynamic Resource Scheduler (DRS) di VMware tra due host hypervisor ESX 4.1. Quando gli host ESX sono configurati in un cluster VMware DRS, le risorse sono aggregate in un pool che consente il loro utilizzo come se fossero un'unica entità. Una macchina virtuale può utilizzare le risorse di ogni host nel cluster invece di dipendere da un unico host. VMware DRS gestisce queste risorse come un pool, assegnando automaticamente le macchine virtuali a un host e monitorando successivamente l'allocazione delle risorse. VMware DRS utilizza VMware vmotion per trasferire le macchine virtuali da un host all'altro se riscontra un vantaggio in termini di performance o sulla base di criteri di ottimizzazione. Il cluster ad alta disponibilità di VMware assicura ridondanza a tutte le macchine virtuali: se si verifica un malfunzionamento o un'interruzione sulla linea di un host ESX, le macchine virtuali assegnate ad esso si riavviano rapidamente su un altro host disponibile. Grazie all'architettura di riferimento è possibile il guasto di un solo host. Maggiore ridondanza si ottiene aggiungendo altri host ESX al cluster di management. Cluster di risorse La figura 4 mostra la configurazione del cluster di risorse che contiene le macchine virtuali per l'elaborazione del carico di lavoro dell'utente. Figura 4 11

13 In un cluster pool VMware DRS sono stati creati tre pool di risorse (oro, argento e bronzo), ognuno dei quali è mappato su un unico provider virtual data center. Questo tipo di mappatura 1:1 facilita la separazione delle caratteristiche in termini di prestazioni di ogni singolo provider virtual data center. Nel cluster di risorse il carico delle macchine virtuali è distribuito da DRS di VMware tra sei host ESX. Dal momento che tutte le risorse degli host ESX in un cluster VMware DRS sono aggregate in modo dinamico, è possibile incrementare o ridurre le risorse di CPU e memoria, aggiungendo o rimuovendo gli host ESX al cluster. La risorsa dinamica si riflette direttamente nel pool di risorse su cui è mappato il provider virtual data center. La configurazione massima supportata da VMware vcenter è di 32 host ESX in un cluster DRS. Una volta raggiunto il limite massimo con la funzione di scale-up, grazie alla scalabilità orizzontale è possibile creare un ulteriore cluster VMware DRS per ospitare altri 32 host ESX. Una singola istanza VMware vcenter può supportare al massimo 1000 host ESX. VMware High Availability (HA) fornisce ridondanza al cluster di risorse e alle macchine virtuali per l'elaborazione del carico di lavoro dell'utente: se si verifica un malfunzionamento o un'interruzione sulla linea di un host ESX, le macchine virtuali assegnate ad esso si riavviano rapidamente su un altro host disponibile. Hitachi Compute Blade 2000 Per l'infrastruttura VMware vsphere 4.1 è stato utilizzato Hitachi Compute Blade La tabella 4 mostra la configurazione hardware, mentre le 8 blade del server sono rappresentate nella figura 5. Tabella 4. Configurazione Hitachi Compute Blade 2000 Modello CPU RAM 8xX55A2 2 x 6 nuclei Intel Xeon 5670 a 2,93 GHz 72 GB DDR3 Registered Cache 12 MB DIMM Bus di sistema 6.40 GT/s 12

14 Figura 5 13

15 La tabella 5 mostra la distribuzione delle risorse di Hitachi Compute Blade Vi è la possibilità di una crescita parallela a quella dell'infrastruttura VMware vcloud e VMware vsphere. Tabella 5. Distribuzione delle risorse Hitachi Compute Blade 2000 Cluster di management Cluster di risorse Utilizzo VMware vcenter 4.1 Oracle Macchine virtuali per il carico di lavoro dell'utente Database 11g VMware vcenter Pool risorse oro DB VMware vcloud Director 1.0 Pool risorse argento vshield Manager 4.1 Pool risorse bronzo ESX0, ESX1 ESX2, ESX3, ESX4, ESx5, ESX6, ESX7 Blade del server 2 6 CPU 35,16 GHz 210,96 GHz Memoria 144 GB 432 GB Infrastruttura di rete L'infrastruttura di rete nell'architettura di riferimento è la seguente. La versione di Hitachi Compute Blade 2000 utilizzata in questa soluzione contiene l'hardware di rete descritto alla tabella 6. Tabella 6. Hardware di rete Hitachi Compute Blade 2000 Schede di rete NIC Modulo switch 0 Modulo switch 1 Modulo switch 2 Modulo switch 3 2 porte onboard Intel Gigabit Ethernet (SERDES) 1 porta mezzanine quad (SERDES) Intel Gigabit Ethernet Switch LAN 1 Gb 20 porte interne 1000Base-SERDES 4 porte esterne 1000Base- T/100Base-TX/10- Base-T Switch LAN 1 Gb 20 porte interne 1000Base-SERDES 4 porte esterne 1000Base- T/100Base-TX/10- Base-T Switch LAN 1 Gb/10 Gb 20 porte interne 1000Base-SERDES 4 porte esterne 1000Base-T/100Base- TX/10- Base-T 2 porte 10GBase- LR/SR (XFP) Switch LAN 1 Gb/10 Gb 20 porte interne 1000Base-SERDES 4 porte esterne 1000Base-T/100Base- TX/10- Base-T 2 porte 10GBase- LR/SR (XFP) Ogni blade del server contiene 6 schede di rete NIC Gigabit. Ogni scheda di rete è connessa tramite il midplane dello chassis alle porte interne del suo modulo switch. Nota La prima VMNIC (vmnic0) numerata in ESX è Intel LF-2. Non utilizzarla in ESX per il traffico di rete. 14

16 Cluster di management Ogni cluster contiene una rete di management, una per VMKernel e una per la macchina virtuale. Ogni rete del cluster è configurata per uno scopo specifico. La figura 6 mostra la configurazione di rete del cluster di management. Figura 6 Il cluster di management utilizza uno switch virtuale standard per la rete della console di servizio, di VMkernel e della macchina virtuale. Sono state usate due porte per la console di servizio. VMNIC1, dedicata alla console di servizio 1, fornisce le seguenti funzionalità: Traffico di management verso VMware vcenter La rete heartbeat VMware High Availability per gli altri host ESX sullo stesso cluster ad alta disponibilità VMware High Availability è un meccanismo di avvio del failover su rete. Per evitare un failover indesiderato di un servizio ad alta disponibilità o l'isolation response dell'host, utilizzare una rete aggiuntiva heartbeat VMware High Availability. VMNIC2, dedicata alla console di servizio 2, è la rete heartbeat ridondante per VMware High Availability. 15

17 Un altro vantaggio derivante dall'utilizzo di Hitachi Compute Blade 2000 per VMware High Availability è che la connessione tra le VMNIC e i moduli switch avviene mediante le porte SERDES collegate direttamente al midplane dello chassis, eliminando così l'eventualità che un cavo venga tirato accidentalmente o di un cablaggio difettoso. Dal momento che le strutture heartbeat ad alta disponibilità per ogni rete VMware High Availability si trovano su un unico modulo switch e dominio di trasmissione, si riduce l'eventualità che un malfunzionamento della rete esterna possa interrompere la rete heartbeat per VMware High Availability. VMNIC2 fornisce anche una rete dedicata VMkernel per il traffico VMware vmotion, per gestire il traffico vmotion tra i due host ESX nel cluster di management all'interno dello chassis. VMNIC3 e VMNIC5, dedicate al traffico tra macchine virtuali, agiscono congiuntamente per bilanciare il traffico in uscita. Cluster di risorse Il cluster di risorse fa uso dello stesso hardware del cluster di management, ma dispone di una configurazione leggermente diversa, concepita in modo specifico per le macchine virtuali VMware vcloud che elaborano il carico di lavoro dell'utente. La figura 7 mostra la configurazione di rete del cluster di risorse. Figura 7 La configurazione della scheda VMNIC per la console di servizio e VMkernel è identica a quella del cluster di management, mentre la rete della macchina virtuale viene configurata in vnetwork Distributed Switch (vds) di VMware. Centralizzata in un livello cluster, vds si estende a molteplici host ESX. Anche il management della rete degli host ESX è centralizzato, come consigliato per VMware vcloud Director. 16

18 Per il traffico tra macchine virtuali sono configurati due switch VMware vds dal livello 1 e dal livello 2, con due uplink per host ESX. Oltre a 6 host nel cluster di risorse, sono disponibili 12 uplink fisici (VMNICS) per ogni VMware vds. I due uplink disponibili per ogni host ESX per VMware vds agiscono congiuntamente per bilanciare il carico in uscita sulla base dell'algoritmo calcolato per l'id della porta. Ogni porta utilizzata dalle VMNIC sul modulo switch 2 e sul modulo switch 3 è inoltre configurata come trunk VLAN 802.1Q, per consentire a molteplici segmenti LAN il transito di traffico virtuale. I diversi livelli di VMware vds sono determinati dalla larghezza di banda dell'uplink per ogni modulo switch su chassis. La figura 8 mostra gli uplink esterni per ogni modulo switch. Figura 8 Il modulo switch 0, collegato al modulo di management 0 e al modulo di management 1, è dedicato alla rete di management degli host ESX, di VMware vcenter, delle blade individuali del server (tramite interfaccia web) e alla gestione dello chassis di Hitachi Compute Blade La rete di management utilizza una connessione Ethernet 1 Gbit. Il modulo switch 1 è dedicato al traffico VMware vmotion. Se il traffico VMware vmotion avviene tra le blade del server situate sullo stesso chassis, non è necessario un uplink esterno, mentre se è disponibile una rete VMware vmotion dedicata all'interno di un data center fisico, ai fini della connettività è possibile usare da tale switch l'uplink 10 Gbit. Il modulo switch 2, dedicato al traffico inter-chassis tra macchine virtuali di livello 2, utilizza connessioni in rame Ethernet 1 Gbit. Il modulo switch 3, dedicato al traffico inter-chassis tra macchine virtuali di livello 1, utilizza connessioni in fibra Ethernet 10 Gbit. 17

19 Infrastruttura di storage Si descrive qui l'infrastruttura di storage. Hitachi Compute Blade 2000 (CB 2000) consente di utilizzare schede HBA dual-port mezzanine con moduli switch dual per Fibre Channel oppure schede HBA dual per Fibre Channel PCIe. L'architettura di riferimento utilizza le schede Fibre Channel dual port 8G bit/sec Five-EX family PCIe di Hitachi. La figura 9 mostra l'architettura di rete della storage area Figura 9 Sono stati utilizzati due switch Brocade La prima porta su ogni HBA è stata collegata allo switch 1, mentre la seconda porta su ogni HBA è stata collegata allo switch 2. La policy di multipath sull'esx è stata impostata su round-robin Per la connessione allo switch 1 sono state utilizzate due porte, una da ogni cluster di Hitachi Virtual Storage Platform, mentre per la connessione allo switch 2 sono state utilizzate altre due porte, una da ogni cluster di Hitachi Virtual Storage Platform, Tale interconnessione consente di aumentare la ridondanza. Infatti, in caso di guasto di uno switch, l'host ESX dispone ancora di due percorsi, uno su ogni cluster di Hitachi Virtual Storage Platform. Analogamente sono state utilizzate due porte di ogni controller su Hitachi Adaptable Modular Storage 2100 per la connessione alle porte esterne di Hitachi Virtual Storage Platform. 18

20 La tabella 7 mostra la configurazione delle zone per il cluster di Tabella 7. Configurazione delle zone del cluster di management per il gruppo di host di storage Host Numero HBA host Nome della zona Porta di storage ESX 0 ESX 1 HBA1_1 HBA1_2 HBA1_1 HBA1_2 esx0_hba1_1_vsp_3b_4b esx0_hba1_2_vsp_5b_6b esx1_hba1_1_vsp_3b_4b esx1_hba1_2_vsp_5b_6b 3B 4B 5B 6B 3B 4B 5B 6B Per quanto riguarda la configurazione delle zone è stato utilizzato un initiator singolo, per cui ogni porta HBA è mappata su 2 porte di destinazione, una su ogni cluster di Hitachi Virtual Storage Platform. Con due porte per initiator e quattro porte di destinazione, sono disponibili in tutto quattro percorsi, che vengono utilizzati da ogni host ESX in modalità round-robin. Per semplificare la gestione e garantire la coerenza dei LUN mappati sugli host per il cluster di management, è stato utilizzato un unico gruppo di host di storage per le quattro porte di destinazione (3B, 4B, 5B, 6B) La tabella 8 mostra la configurazione delle zone per il cluster di risorse. 19