Utilizzo delle piattaforme di virtualizzazione VMware con ... delle piattaforme di virtualizzazione...

Utilizzo delle piattaforme di virtualizzazione VMware con EMC VPLEX

Best practice di pianificazione

Riepilogo

Questo white paper descrive le caratteristiche e le funzionalità di EMC® VPLEX™ rilevanti per le piattaforme di virtualizzazione VMware. Vengono quindi presentate le best practice di configurazione di un ambiente VMware per un utilizzo ottimale di EMC VPLEX e discusse le metodologie per passare da un’implementazione VMware già in uso alla famiglia EMC VPLEX.

Maggio 2010

Utilizzo delle piattaforme di virtualizzazione VMware con EMC VPLEX Best practice di pianificazione 2

Copyright © 2010 EMC Corporation. Tutti i diritti riservati.

Le informazioni contenute nel presente documento sono accurate alla data di pubblicazione. Le informazioni sono soggette a modifica senza preavviso.

LE INFORMAZIONI CONTENUTE NELLA PRESENTE DOCUMENTAZIONE VENGONO FORNITE “COME SONO”. EMC CORPORATION NON RICONOSCE ALCUNA GARANZIA DI NESSUN GENERE INERENTE LE INFORMAZIONI RIPORTATE NELLA PRESENTE PUBBLICAZIONE, TRA CUI GARANZIE IMPLICITE DI COMMERCIABILITÀ O IDONEITÀ AD UN DETERMINATO SCOPO.

L’uso, la copia e la distribuzione del software EMC descritto nella presente pubblicazione richiedono una licenza software valida.

Per un elenco aggiornato dei nomi di prodotti di EMC, vedere i marchi di EMC Corporation sul sito web di EMC.

Tutti gli altri marchi utilizzati in questo documento appartengono ai rispettivi proprietari.

P/N h7118


Sommario In sintesi .............................................................................................................. 4 Introduzione ........................................................................................................ 4

Destinatari ................................................................................................................................................. 4 Panoramica di EMC VPLEX ................................................................................ 5

Architettura EMC VPLEX ........................................................................................................................ 5 Famiglia EMC VPLEX ............................................................................................................................. 6 Architettura di clustering di EMC VPLEX ............................................................................................. 6

Provisioning dello storage VPLEX per ambienti VMware ............................... 8 Considerazioni sulla connettività .................................................................... 17 Percorsi multipli e bilanciamento del carico .................................................. 20

VMware ESX Server versione 3 e il bilanciamento statico del carico .............................................21 VMware ESX Server versione 4 e NMP ..............................................................................................22 VMware ESX Server versione 4 con PowerPath/VE .........................................................................23

Funzionalità di PowerPath/VE ..........................................................................................................24 Gestione di PowerPath/VE ................................................................................................................25

Migrazione di ambienti VMware esistenti in ambienti VPLEX ....................... 27 Migrazioni senza interruzioni con Storage vMotion ...........................................................................27 Migrazione con l’incapsulamento dei dispositivi esistenti .................................................................29

Implementazioni di VMware in un ambiente VPLEX Metro ........................... 36 Configurazione cluster di VMware........................................................................................................36 Migrazione senza interruzioni delle macchine virtuali con vMotion .................................................41 Modifica della configurazione di volumi di VPLEX Metro non replicati ...........................................42 vCenter Server virtualizzato su VPLEX Metro ....................................................................................46

Conclusioni ....................................................................................................... 48 Bibliografia ........................................................................................................ 48


In sintesi La famiglia di prodotti EMC® VPLEX™ con sistema operativo EMC GeoSynchrony™ fornisce numerose nuove caratteristiche e funzionalità per l’era del cloud computing. EMC VPLEX rimuove le barriere fisiche e consente agli utenti di accedere simultaneamente a un’unica copia di dati in diverse posizioni geografiche, rendendo possibile la migrazione trasparente delle macchine virtuali in esecuzione tra data center. Questa funzionalità permette la condivisione trasparente dei carichi tra più siti e la flessibilità di ricollocare i carichi di lavoro tra siti in previsione di eventi pianificati. Inoltre, in caso di evento imprevisto che causa interruzione delle attività in uno dei data center, i servizi interessati possono essere riavviati sul sito ancora in funzione con il minimo sforzo e migliorando gli obiettivi RTO (Recovery Time Objective).

La piattaforma di virtualizzazione VMware consente di virtualizzare l’intera infrastruttura IT, inclusi server, storage e reti. Il software VMware aggrega tali risorse e presenta un gruppo uniforme di elementi nell’ambiente virtuale. VMware vSphere 4 offre quindi al data center tutta la potenza del cloud computing, riducendo i costi IT e aumentando l’efficienza dell’infrastruttura. Ai provider di servizi di hosting, VMware vSphere 4 offre inoltre un percorso più economico ed efficiente per erogare servizi cloud compatibili con le infrastrutture dell’internal cloud del cliente. VMware vSphere 4 fornisce prestazioni e scalabilità significativamente migliorate rispetto alla prima generazione di prodotto, VMware Infrastructure 3, allo scopo di consentire l’implementazione sull’internal cloud anche delle applicazioni che richiedono un utilizzo altamente intensivo delle risorse, come ad esempio i database di grandi dimensioni. Grazie a questi miglioramenti a livello di prestazioni e scalabilità, con VMware vSphere 4 è possibile disporre di un internal cloud completamente virtualizzato.

La famiglia EMC VPLEX rappresenta quindi il completamento ideale di un ambiente virtualizzato basato su tecnologie VMware. La capacità di EMC VPLEX di fornire local federation e distributed federation per la collaborazione trasparente di elementi fisici relativi ai dati all’interno di un singolo sito o di due siti a distanza, consente agli amministratori IT di abbattere le barriere fisiche e di ampliare il cloud basato su VMware. Le funzionalità di local federation di EMC VPLEX consentono di raggruppare soluzioni eterogenee di storage dei dati di un sito fisico e di presentare lo storage come un pool di risorse per la piattaforma di virtualizzazione VMware, soddisfacendo quindi le condizioni essenziali di un’offerta cloud. In particolare, un’estensione delle funzionalità di VPLEX a più data center consente agli amministratori IT di sfruttare le offerte di private cloud o di public cloud dei fornitori di servizi di hosting. Le sinergie rese possibili dall’utilizzo di una piattaforma di virtualizzazione VMware connessa a un sistema EMC VPLEX consente quindi di ridurre i costi complessivi di gestione e fornisce al contempo un servizio dinamico in grado di rispondere rapidamente alle esigenze in costante evoluzione delle aziende.

Introduzione Questo white paper presenta la famiglia EMC VPLEX, l’architettura in cluster su cui è basata, nonché le caratteristiche e le funzionalità rilevanti per le soluzioni compatibili con i private cloud. Il documento passa quindi ad esaminare il provisioning dello storage VPLEX ad ambienti VMware e fornisce indicazioni relative alla metodologia corretta per la connessione delle piattaforme di virtualizzazione VMware a EMC VPLEX e per la selezione di una policy a percorsi multipli che consenta di ottenere la massima resilienza possibile e le prestazioni migliori nell’ambiente virtualizzato. Il white paper presenta inoltre diverse tecniche di migrazione delle implementazioni di VMware esistenti a EMC VPLEX. Infine, vengono discusse le best practice per sfruttare appieno EMC VPLEX Metro in un ambiente VMware, per ottenere i massimi livelli di flessibilità, resilienza e protezione dei dati, riducendo al minimo i rischi di indisponibilità dei dati dovuta ad eventi non pianificati.

Destinatari Il white paper è destinato ad amministratori VMware, amministratori di storage ed architetti IT responsabili di progettazione, creazione, gestione e utilizzo degli ambienti IT virtualizzati in cui vengono impiegate le tecnologie VMware vSphere ed EMC VPLEX. La comprensione degli argomenti trattati presuppone la conoscenza della tecnologia VMware, EMC VPLEX e dei relativi software.


Panoramica di EMC VPLEX La famiglia EMC VPLEX con il sistema operativo EMC GeoSynchrony è una soluzione di storage federation basata su SAN che rimuove le barriere fisiche all’interno di uno o più data center virtualizzati. EMC VPLEX è la prima piattaforma al mondo che offre sia local federation che distributed federation. La local federation consente la collaborazione trasparente degli elementi di storage fisici all’interno di un sito, mentre la distributed federation supporta lo stesso tipo di collaborazione tra due siti a distanza. La distributed federation è resa possibile da una tecnologia all’avanguardia disponibile con VPLEX, AccessAnywhere™, che supporta la condivisione, l’accesso e il riposizionamento a distanza di una singola copia di dati.

L’utilizzo congiunto di un data center virtualizzato e di EMC VPLEX consente di risolvere i problemi IT con metodi innovativi e di introdurre al contempo nuovi modelli di elaborazione. In particolare, i clienti saranno in grado di:

Spostare le applicazioni virtualizzate sui data center Eseguire il bilanciamento e il riposizionamento dei carichi di lavoro tra siti Aggregare data center e garantire la availability in modalità “24 x forever”

Architettura EMC VPLEX EMC VPLEX è un’architettura di nuova generazione per la mobilità dei dati e l’accesso alle informazioni, basata sugli oltre 20 anni di esperienza EMC nella progettazione, nell’implementazione e nel perfezionamento di soluzioni di classe enterprise nell’ambito delle cache intelligenti e della protezione distribuita dei dati.

Come illustrato nella Figura 1, VPLEX è una soluzione per la storage federation sia di storage EMC che non EMC. VPLEX risiede tra i server e le risorse di storage eterogeneo e introduce una nuova architettura dalle caratteristiche esclusive:

Hardware clustering scalabile che consente di cominciare con una piccola implementazione iniziale e ampliarla successivamente, con livelli di servizio prevedibili

Caching avanzato dei dati, che utilizza cache SDRAM su vasta scala per migliorare le prestazioni e ridurre la latenza di I/O e le contese tra array

Coerenza della cache distribuita per condivisione, bilanciamento e failover automatici di I/O nel cluster

Vista coerente di una o più LUN sui cluster VPLEX, sia a distanza minima all’interno del data center sia su data center remoti in modalità sincrona, per nuovi modelli di high availability e riposizionamento dei carichi di lavoro.

Figura 1. Capacità di EMC VPLEX di eseguire la storage federation in ambienti eterogenei


Famiglia EMC VPLEX La famiglia EMC VPLEX comprende due prodotti:

VPLEX Local: è la soluzione più adatta per la storage federation di sistemi omogenei ed eterogenei all’interno di un data center e per la gestione della mobilità dei dati tra entità fisiche di storage dei dati.

VPLEX Metro: è la soluzione rivolta ai clienti che intendono sfruttare l’accesso simultaneo e la mobilità dei dati tra due siti remoti in modalità sincrona. VPLEX Metro consente anche a un sito VPLEX Metro remoto di presentare LUN senza che sia necessario lo storage fisico di queste LUN sul sito remoto.

Le soluzioni della famiglia EMC VPLEX, con le attuali caratteristiche delle rispettive architetture, sono illustrate nella Figura 2

Figura 2. Soluzioni della famiglia EMC VPLEX e caratteristiche delle rispettive architetture

Architettura di clustering di EMC VPLEX VPLEX utilizza una speciale architettura di clustering per consentire alle aziende di eliminare le barriere nei data center e permettere ai server in più data center di avere accesso simultaneo in lettura/scrittura a storage device in blocchi condivisi. Un cluster VPLEX, illustrato nella Figura 3, è completamente scalabile, sia mediante l’aggiunta di più motori, sia tramite la connessione di più cluster, per comporre una configurazione VPLEX Metro. Nella release iniziale, VPLEX Metro supporta un massimo di due cluster, che possono risiedere all’interno dello stesso data center o in due diversi siti, in modalità sincrona (distanti fino a un massimo di 100 chilometri circa). Le configurazioni di VPLEX Metro consentono agli utenti di spostare in modo trasparente e di condividere i carichi di lavoro, di consolidare i data center e di ottimizzare l’utilizzo delle risorse sui data center. Inoltre, i cluster VPLEX forniscono mobilità dei dati senza interruzioni, gestione dello storage eterogeneo e availability migliorata delle applicazioni.


Figura 3. Rappresentazione schematica di un sistema EMC VPLEX Metro Un cluster VPLEX è composto da uno, due o quattro motori. Il motore è responsabile della federation del flusso di I/O ed effettua il collegamento agli host e allo storage utilizzando connessioni Fibre Channel per il trasporto dei dati. Un singolo cluster VPLEX è costituito da un motore e dai componenti principali:

• Due director, che eseguono il software GeoSynchrony e si collegano a storage, host e altri director nel cluster con connessioni Fibre Channel e gigabit Ethernet

• Un alimentatore SPS (Standby Power Supply), che fornisce alimentazione di emergenza per supportare il motore in caso di interruzioni di corrente temporanee

• Due moduli di gestione, che contengono interfacce per la gestione remota di un motore VPLEX. Ogni cluster è costituito anche di:

• Un management server, che gestisce il cluster e fornisce un’interfaccia da una stazione di gestione remota

• Un cabinet EMC 40U standard che contiene tutte le apparecchiature del cluster In aggiunta, i cluster che contengono più di un motore sono dotati anche di:

Una coppia di switch Fibre Channel utilizzata per le comunicazione da un director all’altro, tra diversi motori


• Una coppia di alimentatori universali che fornisce alimentazione di emergenza agli switch Fibre Channel e consente al sistema di superare le interruzioni di corrente temporanee

Provisioning dello storage VPLEX per ambienti VMware EMC VPLEX fornisce un’interfaccia di gestione guidata e intuitiva per il provisioning dello storage a diversi sistemi operativi, inclusa la piattaforma di gestione VMware. Il sistema fornisce anche un’interfaccia CLI (Command Line Interface) per utenti avanzati. Nella Figura 4 viene illustrata l’interfaccia utente per il provisioning dello storage da un sistema EMC VPLEX.

Figura 4. Interfaccia di gestione GUI di EMC VPLEX

L’interfaccia di gestione basata su browser, come illustrato nella Figura 4, visualizza schematicamente i vari componenti coinvolti nel processo. Lo storage da EMC VPLEX viene presentato utilizzando un costrutto logico chiamato “visualizzazione di storage”, costituito da initiator registrati, porte VPLEX e dal volume virtuale. L’oggetto “Registered initiators” elenca i WWPN degli initiator che necessitano


dell’accesso allo storage. Nel caso di un ambiente VMware, l’entità “Registered initiator” contiene i WWPN degli HBA nei VMware ESX server connessi a EMC VPLEX. L’oggetto “VPLEX port” contiene le porte front-end dell’array VPLEX mediante il quale l’oggetto “Registered initiators” accede ai volumi virtuali. L’oggetto “Virtual Volume” è un’insieme di volumi che vengono ricavati dai volumi di storage forniti a EMC VPLEX dagli storage array back-end. Dall’inserto nell’angolo in basso a sinistra della Figura 4 è evidente che un volume virtuale viene creato da un “device” che può essere a sua volta costituito da una combinazione di diversi dispositivi creati su un’entità astratta chiamata “extension”, vale a dire da un’estensione. L’immagine mostra anche che un’estensione viene creata dal volume di storage presentato a EMC VPLEX.

Nella Figura 4, nell’inserto nell’angolo in basso a destra, sono raffigurate le sette fasi necessarie per il provisioning dello storage da EMC VPLEX. La procedura guidata supporta un meccanismo centralizzato per il provisioning dello storage a diversi membri del cluster nel caso di EMC VPLEX Metro. La prima fase nel processo di provisioning dello storage da EMC VPLEX è costituita dal discovery degli storage array connessi al sistema. Tale fase raramente deve essere eseguita, poiché EMC VPLEX esegue il monitoraggio proattivo delle modifiche all’ambiente di storage.

La seconda fase del processo consiste nella richiesta dello storage presentato a EMC VPLEX. Il processo di richiesta dello storage crea il volume di storage dell’oggetto illustrato nella Figura 4. La Figura 5 mostra un esempio del processo. Dalla figura si evince che il softwareVPLEX semplifica il processo suggerendo automaticamente nomi intuitivi per i dispositivi presentati dagli storage array.


Figura 5. Richiesta di volumi di storage utilizzando la procedura guidata di VPLEX

Una volta creati i volumi di storage, le estensioni devono essere ricavate da questi. Il sistema di gestione VPLEX fornisce una procedura guidata per questo tipo di attività. Cliccando sull’URL “Step 3: Create Extents from Storage Volumes”, come illustrato nella Figura 4 viene avviata la procedura guidata. Nella Figura 6 è illustrata la prima fase della procedura.


Figura 6. Prima fase della procedura guidata di creazione di un’estensione

Per rendere tutto più semplice, negli ambienti VMware si consiglia di creare una singola estensione sul volume di storage creato nel dispositivo presentato dallo storage array. In tal caso, non è necessario modificare le voci predefinite illustrate nell’area evidenziata in giallo nella figura. Una successiva fase della procedura guidata consente agli utenti di creare una singola estensione che amplia la capacità complessiva del volume di storage, come si può vedere nella Figura 7.

Figura 7. Specifica della capacità di un’estensione che viene creata da un volume di storage

Come illustrato nella Figura 7, cliccando sul pulsante Next gli utenti possono visualizzare la configurazione proposta ed eseguire il piano. La fase finale del processo consente di verificare le operazioni eseguite da EMC VPLEX. Le ultime due fasi della procedura sono illustrate nella Figura 8.


Figura 8. Creazione di un’estensione con la procedura guidata di VPLEX

La fase successiva nel processo di provisioning dello storage da EMC VPLEX per un ambiente VMware consiste nella creazione di un dispositivo VPLEX utilizzando l’estensione che è stata creata nella fase precedente. La procedura guidata per l’esecuzione può essere avviata dalla home page dello strumento di gestione dell’interfaccia utente per EMC VPLEX. Cliccando sull’URL “Step 4: Create Devices from Extents”, come illustrato nella Figura 4, viene visualizzata una nuova finestra pop-up, illustrata nella Figura 9.


Figura 9. Creazione di un dispositivo VPLEX utilizando un’estensione

Dalla figura si evince che la procedura guidata offre la possibilità di creare un volume virtuale utilizzando il dispositivo di VPLEX (l’area evidenziata in giallo nella Figura 9). L’opzione predefinita deve essere selezionata se non si pianifica di creare un volume virtuale che contiene più estensioni o quando si creano dispositivi per l’utilizzo in ambienti VPLEX Metro. Quando possibile, il volume virtuale per ambienti VMware deve essere creato utilizzando il mapping uno a uno, vale a dire con un singolo volume virtuale per ogni estensione. Questo serve principalmente a mantenere l’infrastruttura più semplice possibile. Tuttavia, per la presentazione della procedura guidata di creazione di volumi virtuali, come nella Figura 9, ai fini dell’esempio utilizzato per questo documento è stato creato un dispositivo VPLEX senza creare un volume virtuale.

Un volume virtuale può essere creato utilizzando uno o più dispositivi VPLEX. La Figura 10 mostra la procedura guidata per creare i volumi virtuali. Come si può vedere, il dispositivo VPLEX creato nella fase precedente costituisce il nome del volume di storage a cui viene aggiunto il prefisso “device_”.

Figura 10. Creazione di volumi virtuali da dispositivi VPLEX

Il volume virtuale può essere presentato alla piattaforma di virtualizzazione VMware, come discusso in precedenza, creando una visualizzazione di storage mediante l’associazione degli oggetti “Registered initiators”, “VPLEX ports” e “Virtual Volumes”. Per fare ciò, il WWN degli initiator sugli VMware ESX Server deve prima essere registrato su EMC VPLEX. La schermata mostrata nella Figura 11 viene visualizzata cliccando sull’ URL “Step 6: Register Initiators”.


Figura 11. Elenco degli initiator registrati e di cui è stato eseguito il login in EMC VPLEX

Quando gli initiator vengono sottoposti a zoning sulle porte front-end di EMC VPLEX, effettuano automaticamente il login a EMC VPLEX. Come illustrato nella Figura 11, questi initiator vengono visualizzati con il prefisso “UNREGISTERED-”, seguito dal WWPN dell’initiator. Tuttavia, gli initiator possono essere registrati manualmente prima che ne venga eseguito lo zoning sulle porte front-end di VPLEX. Il pulsante evidenziato in verde nella Figura 11 deve essere selezionato per eseguire l’operazione. Gli initiator che hanno eseguito il login in EMC VPLEX possono essere registrati evidenziando l’initiator non registrato e cliccando sul pulsante Register, come si può vedere nella Figura 12. L’inserto nella figura illustra la finestra che viene aperta cliccando il pulsante Register. L’inserto mostra anche la funzionalità offerta da EMC VPLEX per assegnare un nome intuitivo all’initiator non registrato e per selezionare un tipo di host per l’initiator in fase di registrazione.


Figura 12. Registrazione degli HBA di VMware su EMC VPLEX

La fase finale per il provisioning dello storage da EMC VPLEX all’ambiente VMware è costituita dalla creazione di una visualizzazione di storage. Per questo scopo si deve selezionare l’ultima procedura guidata (Step 7: Create Storage Views) nella home page del sistema di gestione di VPLEX. La Figura 13 illustra la finestra che viene aperta quando si seleziona l’ultima fase dalla home page. Nel riquadro di sinistra della finestra vengono visualizzate le fasi che servono per la creazione di una visualizzazione di storage. Avanzando nella procedura guidata, viene eseguito il provisioning dei volumi virtuali appropriati per la piattaforma di virtualizzazione, utilizzando il gruppo definito di porte VPLEX front-end. L’utilizzo consigliato delle porte di VPLEX per la connessione degli VMware ESX Server a EMC VPLEX viene discusso nella sezione “Considerazioni sulla connettività”.

Figura 13. Procedura guidata per la creazione di una visualizzazione di storage di VPLEX


Nella Figura 14 viene illustrata la visualizzazione di storage creata con la procedura guidata. Il WWN del volume virtuale presentato tramite visualizzazione viene evidenziato nella figura. Le informazioni vengono utilizzate dalla piattaforma di virtualizzazione VMware per identificare i dispositivi.

Figura 14. Visualizzazione dei dettagli di una visualizzazione di storage con l’interfaccia di gestione di VPLEX

È possibile eseguire il discovery dello storage appena sottoposto a provisioning sugli VMware ESX Server effettuando una nuova scansione del bus SCSI. Il risultato della scansione è mostrato nella Figura 15. Come si può vedere, VMware ESX Server ha accesso al dispositivo con WWN 6000144000000010a001b07360847619. Un veloce confronto del WWN con le informazioni evidenziate in verde nella Figura 14 conferma che il dispositivo di cui è stato eseguito il discovery da parte di VMware ESX Server è proprio il volume virtuale di VPLEX di cui si è appena effettuato il provisioning. La figura mostra anche che l’OUI (Organizationally Unique Identifier) FC per i dispositivi EMC VPLEX è 00:01:44.

Figura 15. Discovery dello storage VPLEX di cui è stato appena eseguito il provisioning su un VMware ESX Server


Una volta eseguito il discovery del dispositivo VPLEX da parte degli VMware ESX Server, questi ultimi possono essere utilizzati per creare un file system VMware (datastore) o utilizzati come RDM. Tuttavia, per prestazioni ottimali, è importante garantire che gli I/O al sistema EMC VPLEX siano allineati a un limite di blocco di 64 KB. In particolari scenari, esiste una remota probabilità di danneggiamento dei dati quando gli I/O a EMC VPLEX non sono allineati. Di conseguenza, EMC richiede che tutti gli I/O generati dal sistema operativo host per EMC VPLEX siano allineati al limite di blocco di 64 KB.

Il file system VMware creato utilizzando il client dell’infrastruttura VMware o il client vSphere esegue automaticamente l’allineamento ai blocchi del file system. Tuttavia, una partizione non allineata su un sistema operativo guest può avere impatto negativo sulle prestazioni e, come precedentemente menzionato, in certe circostanze può danneggiare i dati. Di conseguenza, è importante accertarsi che tutte le partizioni create sul sistema operativo guest (su un disco virtuale visibile da un file system VMware o su un RDM) siano allineate a multipli di 64 KB.

Considerazioni sulla connettività EMC VPLEX introduce un nuovo paradigma di storage federation che fornisce resilienza, prestazioni e availability migliorate. Nei paragrafi che seguono vengono discusse le indicazioni per la connessione degli VMware ESX Server a EMC VPLEX. Seguendo le raccomandazioni riportate si potrà disporre dei livelli più elevati possibili di connettività ed availability per la piattaforma di virtualizzazione VMware, anche durante le operazioni non consuete.

La best practice consigliata consiste nel dotare ciascun VMware ESX Server nell’ambiente VMware vSphere o nell’infrastruttura VMware di almeno due HBA fisici, ognuno dei quali connesso ad almeno due porte front-end su diversi director di EMC VPLEX. Questa configurazione garantisce un uso continuativo di tutti gli HBA su VMware ESX Server, anche se una delle porte front-end di EMC VPLEX dovesse rimanere off-line a causa di eventi di manutenzione pianificati o di interruzioni impreviste.

Quando la configurazione di un singolo motore VPLEX è connessa a un ambiente VMware vSphere o con infrastruttura VMware, ogni HBA deve essere connesso alle porte front-end fornite su entrambi i director A e B all’interno del motore VPLEX. La connettività alle porte front-end di VPLEX prevede prima la connessione di host univoci alla porta 0 di ognuno dei moduli di I/O che emulano i director front-end, quindi la connessione di host aggiuntivi alle rimanenti porte del modulo di I/O. Un esempio schematico del diagramma dei collegamenti per una piattaforma di virtualizzazione VMware a quattro nodi connessa a un solo motore VPLEX è illustrato nella Figura 16.


Figura 16. Connessione di un server VMware vSphere a un cluster VPLEX a un solo motore

Se sono disponibili più motori VPLEX, come nel caso delle configurazioni media e grande dei cluster VPLEX, gli HBA degli VMware ESX Server dovranno essere connessi a motori diversi. Ad esempio, il diagramma dei collegamenti per un cluster di VMware ESX Server a quattro nodi connesso a un cluster VPLEX a due motori è illustrato schematicamente nella Figura 17.

È importante notare che sia nella Figura 16 che nella Figura 17 la connettività tra i motori di VPLEX e gli storage array non è visualizzata. Per la connettività dai motori VPLEX agli storage array è opportuno che vengano seguite le raccomandazioni delle best practice per l’array. Una discussione delle best practice per la connessione dello storage back-end esula dallo scopo di questo white paper. I lettori interessati possono consultare il TechBook EMC VPLEX Architecture and Deployment: Enabling the Journey to the Private Cloud.


Figura 17. Connessione degli ESX Server a un cluster VPLEX a più motori

Quando VMware ESX Server viene connesso a un sistema EMC VPLEX attenendosi alle best practice discusse in questa sezione, il kernel di VMware procederà all’associazione di quattro percorsi a ciascun dispositivo presentato dal sistema. Nella Figura 18 vengono illustrati i percorsi disponibili e utilizzati dal kernel di VMware per uno dei dispositivi federati presentati da EMC VPLEX. Come si può vedere nella figura, il kernel di VMware è in grado di accedere al dispositivo mediante uno dei quattro percorsi possibili. È importante notare che EMC VPLEX è un array attivo/attivo che consente l’accesso simultaneo a qualsiasi dispositivo VPLEX da una qualunque delle porte front-end. Questa caratteristica viene automaticamente riconosciuta dal kernel di VMware, come mostrato nella parte evidenziata in verde della Figura 18.


Figura 18. Percorsi del kernel di VMware per un dispositivo VPLEX

La connettività dagli VMware ESX Server al cluster VPLEX a più motori è scalabile con l’aggiunta di ulteriori motori. Le metodologie discusse in questa sezione assicurano l’utilizzo di tutte le porte front-end consentendo al tempo stesso di sfruttare il massimo potenziale a livello di prestazioni e di bilanciamento del carico per la piattaforma di virtualizzazione di VMware.

Percorsi multipli e bilanciamento del carico VMware ESX Server fornisce funzionalità native di failover dei canali. ESX Server per sistemi di storage di tipo attivo/attivo assegna per impostazione predefinita il primo percorso di cui viene eseguito il discovery a uno qualsiasi dei dispositivi con collegamento SCSI come percorso preferito, con una policy di failover “fixed”. Il percorso viene sempre utilizzato come percorso attivo per l’invio di I/O a tale dispositivo, a meno che il percorso sia indisponibile a causa di un evento pianificato o non pianificato. I restanti percorsi di cui VMware ESX Server ha eseguito il discovery per il dispositivo vengono utilizzati come percorsi di failover passivi e impiegati solo in caso di guasto del percorso attivo. Pertanto, VMware ESX Server accoda automaticamente tutti gli I/O sul primo HBA disponibile nel sistema, mentre l’altro HBA non viene utilizzato attivamente fino a che non viene rilevato un guasto sull’HBA principale. Questo comportamento produce una configurazione sbilanciata sull’ESX Server e su EMC VPLEX. Esistono diverse modalità per risolvere il problema. Il metodo più adatto, come discusso nelle sezioni che seguono, dipende dalla versione di VMware ESX Server e dal software a percorsi multipli impiegato.


VMware ESX Server versione 3 e il bilanciamento statico del carico Su VMware ESX Server versione 3, ai dispositivi EMC VPLEX viene spesso applicata la policy di gestione dei percorsi “Most Recently Used”. Poiché VPLEX è un sistema di tipo attivo/attivo, è necessario garantire che la policy di failover dei percorsi venga impostata su “Fixed”. Inoltre, per ottenere bilanciamento del carico e percorsi multipli, è necessario procedere a un’assegnazione statica dei percorsi alternativi preferiti ai dispositivi esportati da EMC VPLEX. In base alle raccomandazioni della sezione precedente per la connessione dei VMware ESX Server a EMC VPLEX, ogni ESX Server deve avere almeno quattro percorsi separati. Con questo approccio, il file system che risiede su EMC VPLEX dovrebbe disporre di percorsi bilanciati anche sulle risorse disponibili. È importante notare che le modifiche al percorso preferito devono essere apportate su tutti gli ESX Server che accedono ai dispositivi VPLEX.

Il percorso preferito può essere impostato utilizzando le utility della riga di comando o il client dell’infrastruttura VMware. Un esempio viene mostrato nella Figura 19. La Figura 20 illustra invece le impostazioni del percorso preferito per due datastore, ognuno residente su un dispositivo EMC VPLEX presentato dalle porte front-end A0-FC00, A1-FC00, B0-FC00 e B1-FC00. Come si può vedere dalla figura, il percorso preferito per il secondo datastore è stato modificato per utilizzare il secondo HBA.

Figura 19. Impostazione del percorso preferito su VMware ESX Server versione 3


Figura 20. Dispositivi EMC VPLEX con bilanciamento statico del carico su ESX Server versione 3

VMware ESX Server versione 4 e NMP VMware ESX Server versione 4 include funzionalità avanzate di gestione dei percorsi e di bilanciamento del carico utilizzabili mediante le policy “Fixed”, “Round Robin” e “Most Recently Used”. La policy predefinita utilizzata dal kernel di ESX per gli array di tipo attivo/attivo è “Fixed”. Tuttavia, per la maggior parte degli array di tipo attivo/attivo, come gli array EMC Symmetrix, round-robin è la policy più adatta. Ciò nonostante, le funzionalità avanzate di gestione della cache fornite da EMC VPLEX possono essere interrotte con l’uso di un semplice algoritmo di bilanciamento del carico fornito dalla policy Round Robin. Pertanto, per i VMware ESX Server versione 4 connessi a EMC VPLEX, EMC consiglia l’uso della policy Fixed con bilanciamento statico del carico simile a quello consigliato per ESX Server versione 3. Inoltre, le modifiche apportate al percorso preferito devono essere eseguite su tutti gli ESX Server che accedono ai dispositivi VPLEX.

Il percorso preferito su VMware ESX Server versione 4 può essere impostato utilizzando il client vSphere. Nella Figura 21 viene illustrata la procedura che si può utilizzare per impostare il percorso preferito per un disco fisico in un ambiente VMware vSphere. La Figura 22 mostra le impostazioni del percorso preferito per due datastore, ognuno residente su un dispositivo EMC VPLEX presentato da porte front-end A0-FC00, A1-FC00, B0-FC00 e B1-FC00.

Figura 21. Impostazione del percorso preferito su VMware ESX Server versione 4


Figura 22. Dispositivi EMC VPLEX con bilanciamento statico del carico su ESX Server versione 4

VMware ESX Server versione 4 con PowerPath/VE EMC PowerPath®/VE offre funzionalità di multipathing di PowerPath per ottimizzare gli ambienti virtuali di VMware vSphere. PowerPath/VE consente di standardizzare la gestione dei percorsi in più ambienti eterogenei virtuali e fisici. PowerPath/VE consente di automatizzare e ottimizzare l’utilizzo di percorsi, storage e server in un ambiente virtuale dinamico. Con l’iperconsolidamento, un ambiente virtuale deve disporre di centinaia o migliaia di macchine virtuali indipendenti in esecuzione, incluse le macchine virtuali che gestiscono I/O a vari livelli di intensità. Le applicazioni con carichi intensi di I/O possono causare l’interruzione del flusso di I/O proveniente da altre applicazioni e prima di preoccuparsi della availability di PowerPath/VE, come discusso nelle sezioni precedenti, è necessario configurare manualmente il bilanciamento del carico su un sistema host ESX per correggere la situazione. Le operazioni manuali di bilanciamento del carico, per garantire adeguati tempi di risposta per ogni singola macchina virtuale, sono onerose in termini di tempo e difficili da portare efficacemente a termine dal punto di vista logistico.

PowerPath/VE funziona con VMware ESX ed ESXi come plug-in di multipathing (MPP) che fornisce funzionalità avanzate di gestione dei percorsi agli host ESX e ESXi. PowerPath/VE viene supportato solo con vSphere (ESX Server versione 4). Le precedenti versioni di ESX non dispongono di PSA, richiesti da PowerPath/VE.

PowerPath/VE si installa come modulo kernel sull’host di vSphere. Come illustrato nella Figura 23, PowerPath/VE viene collegato al framework in stack di I/O di vSphere I/O e in questo modo fornisce le funzionalità avanzate di multipathing di PowerPath (bilanciamento dinamico del carico e failover automatico) alla piattaforma VMware vSphere.


Figura 23. API di PowerPath/VE vStorage per il plug-in multipathing

Alla base della gestione dei percorsi di PowerPath/VE c’è un software residente su server, che viene inserito tra il livello del driver dei dispositivi SCSI e il resto del sistema operativo. Questo software del driver crea un singolo “pseudo-dispositivo” per un determinato volume di array (LUN), indipendentemente dal numero di percorsi fisici sui quali appare. Lo pseudo-dispositivo o volume logico rappresenta tutti i percorsi fisici a un determinato dispositivo. Viene quindi utilizzato per la creazione di un file system VMware o per il mapping raw device (RDM). Le entità possono di conseguenza essere utilizzate per l’accesso alle applicazioni e al database.

Il valore di PowerPath/VE dipende fondamentalmente dall’architettura di cui è dotato e dalla posizione nello stack di I/O. PowerPath/VE risiede sull’HBA e consente il supporto eterogeneo di sistemi operativi e storage array. Grazie all’integrazione con i driver di I/O, tutti i processi di I/O vengono eseguiti tramite PowerPath, che funge da unico punto di controllo e gestione degli I/O. Poiché PowerPath/VE risiede nel kernel di ESX, risulta collocato sotto il livello del sistema operativo guest, il livello delle applicazioni, il livello del database e il livello del file system. La posizione particolare di PowerPath/VE nello stack di I/O lo rende un punto di controllo e di gestione dell’infrastruttura, fornendo valore aggiunto ai livelli superiori dello stack.

Funzionalità di PowerPath/VE PowerPath/VE fornisce le seguenti funzionalità:

• Bilanciamento dinamico del carico: PowerPath è progettato per utilizzare tutti i percorsi, in qualsiasi momento. PowerPath distribuisce le richieste di I/O a una periferica logica su tutti i percorsi disponibili, invece che richiedere un unico percorso per sopportare l’intero carico di I/O.

• Ripristino automatico dei percorsi: la funzione di ripristino automatico riassegna periodicamente le periferiche logiche quando vengono ripristinati i percorsi su cui si è verificato un guasto. Una volta ripristinati, i percorsi eseguono il ribilanciamento degli I/O su tutti i canali attivi.

• Assegnazione di priorità ai dispositivi: l’impostazione di alta priorità per un solo o per più dispositivi ne migliora le prestazioni di I/O con svantaggio dei dispositivi rimanenti, ma mantenendo il miglior bilanciamento del carico possibile su tutti i percorsi. Si tratta di una funzionalità utile soprattutto in caso di più macchine virtuali su un host con requisiti di availability e delle prestazioni variabili.


• Ottimizzazione automatizzata delle prestazioni: PowerPath/VE identifica automaticamente il tipo di storage array e imposta la modalità di massima ottimizzazione delle prestazioni per impostazione predefinita. Per VPLEX, la modalità predefinita è Adaptive.

• Failover dinamico dei percorsi e ripristino dei percorsi: se un percorso riporta un guasto, PowerPath/VE ridistribuisce il traffico di I/O di quel percorso su percorsi funzionanti. PowerPath/VE interrompe l’invio degli I/O al percorso guasto e verifica che sia disponibile un percorso attivo alternativo. In caso di disponibilità, PowerPath/VE esegue il ridirezionamento degli I/O su tale percorso. PowerPath/VE è in grado di compensare più guasti nel canale di I/O (ad esempio HBA, cavi a fibra ottica, switch Fibre Channel, porta dello storage array).

• Monitoraggio/generazione report delle statistiche di I/O: oltre a bilanciare il carico di I/O, PowerPath/VE elabora le statistiche di tutti i processi di I/O per ogni percorso. L’amministratore può visualizzare le statistiche mediante il comando rpowermt.

• Test automatico dei percorsi: PowerPath/VE esegue periodicamente il test dei percorsi attivi e inattivi. Testando tra i percorsi attivi anche quelli che al momento non sono operanti, è possibile identificare un percorso guasto prima che un’applicazione invii il flusso di I/O a detto percorso. Contrassegnando il percorso come guasto prima che l’applicazione lo rilevi, si riducono timeout e ritardi dovuti alla reiterazione dei tentativi. Testando i percorsi identificati come guasti, PowerPath/VE ne ripristina automaticamente l’operatività una volta superato il test. Il carico di I/O verrà automaticamente bilanciato su tutti i percorsi disponibili.

Gestione di PowerPath/VE PowerPath/VE utilizza un gruppo di comandi, chiamato rpowermt, per monitorare, gestire e configurare PowerPath/VE per vSphere. Sintassi, argomenti e opzioni sono molto simili ai comandi powermt tradizionali utilizzati su tutte le altre piattaforme per sistemi operativi che supportano la funzionalità di multipathing di PowerPath. Esiste però una differenza notevole, in quanto rpowermt è uno strumento di gestione remota.

Non tutte le installazioni di vSphere dispongono di un’interfaccia della console di servizi. Per gestire un host ESXi i clienti possono utilizzare vCenter Server o vCLI (ovvero gli strumenti remoti di VMware) su un server remoto. PowerPath/VE per vSphere utilizza l’utility della riga di comando rpowermt sia per ESX che per ESXi. PowerPath/VE per vSphere non può essere gestito sull’host di ESX. Non esiste un’interfaccia utente locale o remota per PowerPath su ESX. Gli amministratori devono designare un sistema operativo guest o una macchina fisica per gestire uno o più host ESX. L’utility rpowermt viene supportata da Windows 2003 (a 32 bit) e da Red Hat 5 Update 2 (a 64-bit).

Quando il server host di vSphere è connesso ad EMC VPLEX, il modulo del kernel di PowerPath/VE in esecuzione sull’host di Sphere associa tutti i percorsi a ciascun dispositivo presentato dall’array e assegna il nome di uno pseudo-dispositivo (come discusso in precedenza). Un esempio è illustrato nella Figura 24, che mostra l’output di rpowermt display host=x.x.x.x dev=emcpower11. È importante notare che nell’output il dispositivo è dotato di quattro percorsi e viene visualizzata la modalità di ottimizzazione predefinita per i dispositivi VPLEX: ADaptive. Tuttavia, in base a quanto discusso nella sezione precedente, il sistema di gestione avanzata e di coerenza della cache utilizzato da EMC VPLEX non viene sfruttato appieno quando si applica la policy Adaptive. Pertanto, EMC consiglia di modificare la policy di gestione dei percorsi di PowerPath per tutti i dispositivi VPLEX da ADaptive a StreamIO (si). In futuro, gli algoritmi di PowerPath consentiranno l’assegnazione automatica della policy appropriata per i dispositivi EMC VPLEX rilevati.


Figura 24. Output del comando rpowermt display su un dispositivo VPLEX

La policy di gestione dei percorsi per i dispositivi VPLEX può essere modificata in StreamIO utilizzando il comando rpowermt. La Figura 25 illustra il comando che consente d apportare la modifica. La figura mostra anche la nuova policy applicata al dispositivo emcpower11 illustrato nella Figura 24.

Figura 25. Modifica della policy di gestione dei percorsi di PowerPath/VE per i dispositivi VPLEX

Il comando illustrato nella Figura 25 utilizza la definizione delle classi per i dispositivi VPLEX (Invista®) al fine di modificare la policy. Nel raro caso un cui la piattaforma di virtualizzazione VMware sia presentata sia a Invista che ai dispositivi VPLEX, la modifica alla policy di gestione dei percorsi deve essere eseguita dispositivo per dispositivo. Per ulteriori informazioni sull’esecuzione dell’operazione, sui comandi rpowermt e sull’output, consultare la PowerPath/VE for VMware vSphere Installation and Administration Guide disponibile su Powerlink®.

È importante precisare che, con un maggior numero di motori VPLEX disponibili in un cluster, la connettività può essere scalata in base alle esigenze. PowerPath/VE supporta fino a 32 percorsi per dispositivo. Attenersi alle metodologie consigliate per la connettività garantisce l’utilizzo di tutti i director front-end e di tutti i processori, assicurando il massimo delle prestazioni e il bilanciamento del carico per gli host di vSphere connessi a EMC VPLEX in associazione a PowerPath/VE.


Migrazione di ambienti VMware esistenti in ambienti VPLEX Le implementazioni esistenti delle piattaforme di virtualizzazione VMware possono essere migrate in ambienti VPLEX in diverse modalità. Il metodo più semplice per la migrazione a un ambiente VPLEX consiste nell’utilizzo di vMotion. Tuttavia, questa tecnica è applicabile solo se lo storage array dispone di spazio libero sufficiente per ospitare il datastore di maggiori dimensioni dell’ambiente VMware. Inoltre, l’utilizzo di vMotion può risultare lungo e complesso se è necessario convertire centinaia di macchine virtuali o di terabyte, se nelle macchine virtuali sono presenti snapshot oppure se la piattaforma di virtualizzazione è costituita da ESX Server 3.0 o versioni precedenti. Per questi scenari può essere utile sfruttare le funzionalità di EMC VPLEX per incapsulare i dispositivi esistenti. Tuttavia, questa metodologia non preserva dalle interruzioni, bensì richiede la pianificazione dei tempi di inattività per la piattaforma di virtualizzazione VMware.

Migrazioni senza interruzioni con Storage vMotion La Figura 26 mostra i datastore disponibili su VMware ESX Server versione 3.5 gestito da un server vSphere vCenter. La visualizzazione è disponibile utilizzando il plug-in sul lato client di EMC Virtual Storage Integrator, che estende le informazioni relative allo storage visualizzate mediante il client vSphere. Ulteriori informazioni su EMC Virtual Storage Integrator sono reperibili nella documentazione citata nella sezione “Bibliografia”.

La Figura 26 mostra che la macchina virtuale “W2K8 VM1 (VI3)” risiede sul datastore DataStore_1 nel dispositivo 4EC di un array Symmetrix VMAX™. L’inserto nella figura mostra la versione del kernel di ESX (3.5 build 153875) per il server 10.243.168.160.

Figura 26. Dettagli dello storage device EMC visualizzato con EMC Storage Viewer

La Figura 27 mostra i dispositivi visibili su ESX Server. Come si può vedere, esistono due dispositivi identificati come “Invista”, ma per i quali non vengono indicati maggiori dettagli. Questo avviene poiché EMC Virtual Storage Integrator non può in questa fase identificare più chiaramente i dispositivi visibili da EMC VPLEX. La figura mostra inoltre il numero NAA per i dispositivi. Come menzionato in precedenza, FC OUI, 00:01:44, corrisponde ai dispositivi EMC VPLEX. Dalla figura si evince quindi che VMware ESX Server viene presentato con dispositivi sia dagli array EMC Symmetrix VMAX che da EMC VPLEX.


Figura 27. Visualizzazione dei dispositivi EMC VPLEX presentati a un cluster di VMware ESX Server

La migrazione dei dati dagli array di Symmetrix VMAX allo storage presentato da VPLEX può essere eseguita utilizzando Storage vMotion, una volta creati di datastore appropriati sui dispositivi visibili da VPLEX.

La Figura 28 mostra le fasi necessarie per avviare la migrazione di una macchina virtuale da Datastore_1 al datastore di destinazione Target_1, che risiede su un dispositivo VPLEX. È importante sottolineare che, anche se per mostrare la procedura di migrazione è stato utilizzato ESX Server versione 3.5, lo stesso processo è applicabile in caso di ESX Server che eseguono la versione 4.0 o versioni successive. Inoltre, la procedura di migrazione guidata mostrata nella Figura 28 è disponibile solo se si utilizza vCenter Server versione 4.0 o successive. La funzionalità Storage vMotion è disponibile mediante l’utility della riga di comando per vCenter Server versione 2.5. Una trattazione dettagliata di Storage vMotion esula dagli scopi di questo white paper. Ulteriori informazioni su Storage vMotion sono reperibili nella documentazione relativa a VMware, elencata nella sezione “Bibliografia”.


Figura 28. Utilizzo di Storage vMotion per la migrazione delle macchine virtuali su dispositivi VPLEX

Migrazione con l’incapsulamento dei dispositivi esistenti Come già detto, anche se consente la migrazione senza interruzioni da un’implementazione esistente di VMware a EMC VPLEX, Storage vMotion non sempre è uno strumento adeguato. In questi casi, è possibile sfruttare le funzionalità di incapsulamento di EMC VPLEX. La procedura richiede la sospensione delle attività; è però possibile ridurre al minimo l’interruzione mediante pianificazione ed esecuzione appropriate.

Per procedere all’incapsulamento e alla migrazione di un’implementazione VMware esistente, è necessario attenersi alla procedura che segue.

1. Eseguire lo zoning delle porte back-end di EMC VPLEX sulle porte front-end dello storage array che fornisce correntemente le risorse di storage.

2. La fase successiva prevede la modifica del masking delle LUN sullo storage array, in modo da consentire l’accesso di EMC VPLEX ai dispositivi che ospitano i datastore di VMware. Nell’esempio utilizzato nella sezione precedente, i dispositivi 4EC (per Datastore_1) e 4F0 (per Datastore_2) sono stato sottoposti a masking per EMC VPLEX.

La Figura 29 mostra i dispositivi che sono visibili a EMC VPLEX dopo aver apportato le modifiche al masking e dopo avere eseguito una nuova scansione dello storage array su EMC VPLEX. La figura mostra anche l’output del comando SYMCLI dei dispositivi Symmetrix VMAX e dei corrispondenti WWN. Facendo un rapido confronto si può vedere che EMC VPLEX ha accesso ai dispositivi su cui si trovano i datastore di cui si deve eseguire l’incapsulamento.


Figura 29. Discovery dei dispositivi da incapsulare su EMC VPLEX

3. Una volta che i dispositivi sono visibili a EMC VPLEX, è necessario inoltrarne richiesta, Figura 30. Il flag “-appc” garantisce durante il processo di richiesta che il contenuto del dispositivo richiesto venga preservato e che il dispositivo venga incapsulato per ulteriori utilizzi all’interno di EMC VPLEX.

Figura 30. Incapsulamento dei dispositivi in EMC VPLEX con la conservazione dei dati esistenti

4. Dopo avere fatto richiesta dei dispositivi, deve essere creata una singola estensione che comprenda l’intero disco. La Figura 31 mostra questa fase per i due datastore da sottoporre a incapsulamento nell’esempio.


Figura 31. Creazione di estensioni su volumi di storage incapsulati richiesti da VPLEX

5. È necessario creare un dispositivo VPLEX (dispositivo locale) con un solo membro RAID 1, utilizzando l’estensione creata nella fase precedente. L’operazione viene mostrata nella Figura 32 per i due datastore, Datastore_1 e Datastore_2, che risiedono sul dispositivo 4EC e 4F0. Questa fase della procedura deve essere ripetuta per tutti i dispositivi degli storage array che devono essere incapsulati e presentati all’ambiente VMware.

Figura 32. Creazione di un dispositivo protetto VPLEX RAID 1 su dispositivi VMAX incapsulati

6. È necessario creare un volume virtuale su ciascun dispositivo VPLEX creato nella fase precedente. Nella Figura 33 viene mostrata l’operazione per i datastore di VMware Datastore_1 e Datastore_2.


Figura 33. Creazione di volumi virtuali su VPLEX per la presentazione sulla piattaforma di virtualizzazione VMware

7. È possibile creare una visualizzazione di storage su EMC VPLEX registrando manualmente il WWN degli HBA sui VMware ESX Server che fanno parte del dominio di virtualizzazione di VMware. La visualizzazione di storage deve essere creata a priori per consentire alla piattaforma di virtualizzazione VMware di accedere ai volumi virtuali che sono stati creati durante la fase 6. In questo modo, l’interruzione del servizio durante lo switchover dallo storage array originale su EMC VPLEX può essere ridotta al minimo. Un esempio di questa operazione per l’ambiente utilizzato un questo studio è illustrato nella Figura 34. Creazione di una visualizzazione di storage per presentare i dispositivi incapsulati agli VMware ESX Server

Figura 34. Creazione di una visualizzazione di storage per presentare i dispositivi incapsulati agli VMware ESX Server

8. Parallelamente alle operazioni condotte su EMC VPLEX, è necessario creare nuove aree che consentano agli VMware ESX Server coinvolti nella migrazione di accedere alle porte front-end di EMC VPLEX. Anche tali aree devono essere aggiunte all’impostazione dell’area appropriata. Inoltre, le aree che consentono a VMware ESX Server di accedere allo storage array i cui dispositivi stanno per essere incapsulati devono essere rimosse dall’impostazione dell’area. Tuttavia l’impostazione modificata dell’area non deve essere attivata fino all’apertura della finestra di manutenzione, quando sarà possibile arrestare le macchine virtuali VMware.


9. Nel momento in cui viene aperta la finestra di manutenzione, si devono arrestare tutte le macchine virtuali interessate dalla migrazione. L’operazione può essere effettuata utilizzando il client dell’infrastruttura VMware, vSphere Client o le utility della riga di comando che usano VMware SDK.

10. Il datastore originale risiede nei dispositivi presentati dal sistema VPLEX. Tuttavia, gli host di VMware ESX non eseguono automaticamente il mounting dei datastore, dato che VMware ESX considera i datastore come una snapshot e che il WWN dei dispositivi presentati mediante il sistema VPLEX è diverso dal WWN dei dispositivi presentati dal sistema Symmetrix VMAX.

VMware vSphere consente l’esecuzione del processo di resign dei datastore che sono considerati snapshot, dispositivo per dispositivo. In questo modo diminuisce il rischio di eseguire erroneamente il resign dei dispositivi incapsulati dal sistema VPLEX. L’uso di un mounting persistente offre anche altri vantaggi, come ad esempio la conservazione della cronologia di tutte le macchine virtuali. Di conseguenza, per un ambiente vSphere omogeneo, EMC consiglia l’utilizzo di mount persistenti per i datastore VMware incapsulati da VPLEX. Per gli ambienti VMware che contengono VMware ESX versione 3.5 o versioni precedenti, questa fase deve essere saltata.

È necessario attivare l’impostazione dell’area creata nella fase 8. Una nuova scansione manuale del bus SCSI su VMware ESX Server dovrebbe rimuovere i dispositivi originali e aggiungere i dispositivi incapsulati presentati dal sistema VPLEX.

La Figura 35 illustra un esempio di tale impostazione per un ambiente VMware vSphere. La figura mostra che tutte le macchine virtuali originali nell’ambiente sono ora contrassegnate come inaccessibili. Questo accade poiché i datastore Datastore_1 e Datastore_2 creati sui dispositivi presentati dal sistema VMAX non sono più disponibili.

Figura 35. Ripetizione della scansione del bus SCSI sugli VMware ESX Server

Nella figura che segue vengono mostrati i risultati successivi al mounting persistente dei datastore presentati da EMC VPLEX. Come si può vedere, tutte le macchine virtuali prima inaccessibili sono ora disponibili. Il mounting persistente dei datastore considerati snapshot consente di conservare sia l’UUID del datastore che l’etichetta. Dato che per le macchine virtuali viene stabilito un riferimento incrociato utilizzando l’UUID dei datastore, il mount persistente consente a vCenter Server


di eseguire nuovamente il discovery delle macchine virtuali precedentemente considerate inaccessibili.

Le fasi da 11 a 14 elencate di seguito non riguardano ambienti vSphere omogenei e possono essere ignorate.

Figura 36. Mounting persistente dei datastore sui dispositivi VPLEX incapsulati

11. Se nell’ambiente VMware è presente ESX Server versione 3.5 o versioni successive (anche se gestite da VMware vCenter Server versione 4), è consigliabile eseguire il resign dei dispositivi incapsulati presentati da EMC VPLEX. La raccomandazione si basa sul fatto che nelle release di VMware ESX Server il processo di resign dei dispositivi considerati snapshot non è selettivo ed è irreversibile. VMware ESX Server 4.0 e versioni successive fornisce agli utenti un meccanismo per eseguire in modo selettivo il resign dei dispositivi considerati snapshot.

Le macchine virtuali sui datastore devono essere rimosse dall’inventario di vCenter Server. L’operazione può essere effettuata utilizzando il client dell’infrastruttura virtuale, vSphere Client o le utility della riga di comando che usano VMware SDK. È importante precisare che, quando le macchine virtuali non sono registrate, tutte le informazioni cronologiche sulla macchina virtuale vengono eliminate dal database di Virtual Center.

12. Modificare il flag Advanced Settings, LVM.EnableResignature, su uno degli host VMware ESX, per eseguire il resign dei datastore ed attivare l’impostazione dell’area creata durante la fase 8.

L’impostazione dell’area che è stata creata nella fase descritta al punto 8 deve essere ora attivata. Una nuova scansione manuale del bus SCSI su VMware ESX Server dovrebbe rimuovere i dispositivi originali e aggiungere i dispositivi incapsulati presentati dal sistema EMC VPLEX.

La Figura 37 mostra i datastore dopo il completamento del processo di resign. Come si può vedere dalla figura, il prefisso snap-xxxxxxxx è stato aggiunto all’etichetta originale dei datastore.


Figura 37. Resign dei datastore su dispositivi VPLEX incapsulati

13. Una volta eseguito il discovery dei dispositivi VPLEX ed effettuato il resign dei datastore VMware, è necessario impostare il parametro avanzato LVM.EnableResignature su 0.

14. Le macchine virtuali non registrate nella fase descritta al punto 10 possono essere riaggiunte all’inventario di vCenter Server, utilizzando il client dell’infrastruttura virtuale, vSphere Client o le utility della riga di comando basate su VMware SDK. Figura 38. Aggiunta di macchine virtuali da dispositivi VPLEX di cui è stato eseguito il resign per vCenter Server

Figura 38. Aggiunta di macchine virtuali da dispositivi VPLEX di cui è stato eseguito il resign per vCenter Server


15. Una volta identificato o registrato correttamente le macchine virtuali, sarà possibile avviarle.

Il processo sopra descritto utilizza l’interfaccia della riga di comando di VPLEX per eseguire operazioni di gestione su EMC VPLEX. Le stesse operazioni di gestione possono essere tuttavia eseguite mediante l’uso dell’interfaccia utente di gestione fornita da VPLEX.

Implementazioni di VMware in un ambiente VPLEX Metro EMC VPLEX rimuove le barriere fisiche dei data center e consente agli utenti di accedere simultaneamente ai dati che si trovano in diverse posizioni geografiche1. In un contesto VMware, questa caratteristica consente l’uso di funzionalità prima non disponibili. In particolare, la possibilità di accedere simultaneamente allo stesso gruppo di dispositivi indipendentemente dalla loro collocazione fisica, abilita cluster geograficamente distribuiti basati sulla piattaforma di virtualizzazione VMware2

Configurazione cluster di VMware

. Questa funzionalità permette la condivisione trasparente dei carichi tra più siti e la flessibilità di ricollocare i carichi di lavoro tra siti in previsione di eventi pianificati, quali ad esempio la manutenzione hardware. Inoltre, in caso di evento imprevisto che causa interruzione delle attività in uno dei data center, i servizi interessati possono essere riavviati sul sito ancora in funzione in modo rapido, agevole e con il minimo sforzo. Ciò nonostante, la progettazione di un ambiente VMware deve tenere conto di numerosi potenziali scenari di guasto e ridurre il rischio di interruzione di servizio. Nei capitoli che seguono vengono discusse le best practice di progettazione di un ambiente VMware che consentono di mettere a punto una soluzione ottimale. Per ulteriori informazioni sulla configurazione di EMC VPLEX Metro, consultare il TechBook EMC VPLEX Architecture and Deployment: Enabling the Journey to the Private Cloud, disponibile su Powerlink.

Un cluster VMware HA utilizza una funzione heartbeat per stabilire se i nodi peer nel cluster sono raggiungibili e in grado di rispondere. In caso di problemi di comunicazione, il software di VMware HA in esecuzione su VMware ESX Server utilizza in genere il gateway predefinito per il kernel di VMware, allo scopo di determinarne eventualmente l’isolamento. Questo meccanismo è necessario poiché è impossibile stabilire a livello di programmazione se un’interruzione delle comunicazioni è dovuta a un guasto del server o della rete.

Lo stesso problema fondamentale appena descritto (vale a dire se la mancanza di connettività tra i nodi dei cluster VPLEX sia da attribuire a un problema di comunicazione della rete o del sito) riguarda i cluster VPLEX distanti. Un guasto della rete viene gestito in EMC VPLEX sospendendo automaticamente tutti gli I/O a un dispositivo (“scollegato”) su uno dei due siti, in base a un gruppo di regole predefinite. Le operazioni di I/O sullo stesso dispositivo nell’altro sito continueranno normalmente. Inoltre, poiché le regole vengono applicate ad ogni dispositivo singolarmente, è possibile disporre di dispositivi attivi in entrambi i siti, in caso di partizione della rete. L’applicazione delle regole per ridurre al minimo l’impatto delle interruzioni della rete ha effetto se si verifica un guasto del sito. In tal caso, a seconda delle regole che stabiliscono quale sito viene scollegato nell’eventualità di un’interruzione delle comunicazioni, il cluster VPLEX che si trova nel sito ancora operante sospenderà automaticamente il flusso di I/O ad alcuni dei dispositivi nello stesso sito. Per ovviare a questo problema, il software VPLEX consente di riprendere manualmente gli I/O ai dispositivi distaccati. Una trattazione più dettagliata della procedura per eseguire tali operazioni esula dallo scopo di questo white paper. Il TechBook EMC VPLEX Architecture and Deployment: Enabling the Journey to the Private Cloud può essere consultato per reperire ulteriori informazioni su EMC Metro-Plex.

La Figura 39 mostra la configurazione cluster consigliata per le implementazioni VMware che utilizzano i dispositivi presentati tramite EMC VPLEX Metro. Come si può vedere dalla figura, la piattaforma di virtualizzazione VMware è suddivisa in due cluster VMware separati. Ogni cluster include i VMware ESX Server che si trovano in ognuno dei data center fisici (sito A e sito B). Tuttavia, entrambi i cluster VMware 1 Anche se l’architettura di VPLEX è progettata per supportare accesso simultaneo a più siti, la prima versione del prodotto supporta una configurazione per due siti remoti in modalità sincrona. 2 La soluzione richiede l’estensione della rete VLAN a data center fisici differenti. Tecnologie come OTV (Overlay Transport Virtualization) di Cisco possono essere sfruttate per utilizzare il servizio.


sono gestiti in una singola entità Datacenter, che rappresenta la combinazione logica di più siti fisici che fanno parte della soluzione. Nella figura vengono illustrate anche, nell’inserto, le impostazioni per ciascun cluster. Dalla rappresentazione, VMware DRS e VMware HA sono attivi in ognuno dei cluster, quindi l’ambito operativo di tali componenti di VMware è limitato a una sola sede fisica.

Figura 39. Configurazione dei cluster VMware con l’utilizzo di dispositivi di EMC VPLEX Metro

Anche se la Figura 39 mostra solo due cluster VMware, è possibile suddividere i VMware ESX Server collocati in ognuna delle sedi fisiche in più cluster VMware. L’obiettivo della configurazione consigliata consiste nell’evitare che gli ESX Server in più sedi vengano mischiati in un unico oggetto cluster VMware.

I datastore VMware presentati alla rappresentazione logica dei data center fisici congiunti (sito A e sito B) sono illustrati nella Figura 40. La figura mostra che diversi datastore VMware sono presentati su entrambi i data center.3 Di conseguenza, la separazione logica dei domini WMware DRS e VMware HA non ha alcun impatto, come verrà spiegato nella sezione seguente, sulla capacità di VMware vCenter Server di eseguire migrazioni trasparenti al sito peer delle macchine virtuali che funzionano nel cluster designato in ogni sito. La figura evidenzia inoltre che una configurazione di VPLEX Metro non prevede di per sé il requisito di replica di tutti i volumi virtuali creati su EMC VPLEX Metro per tutte le sedi fisiche dei data center4

3 La creazione di un datastore condiviso visibile ai VMware ESX Server in entrambi i siti viene abilitata con la creazione di un dispositivo distribuito in EMC VPLEX Metro. Una trattazione dettagliata delle procedure per creare dispositivi distribuiti esula dallo scopo di questo white paper. Per ulteriori informazioni, consultare il TechBook EMC VPLEX Architecture and Deployment — Enabling the Journey to the Private Cloud.

4 È possibile presentare un volume virtuale che non è replicato ai cluster di VMware in entrambi i siti. In una configurazione di questo tipo, se l’attività di I/O generata nel sito che non dispone di una copia dei dati non si trova nella cache del cluster di VPLEX, in quello stesso sito, la condizione viene soddisfatta dallo storage array che ospita il volume virtuale. Questo genere di combinazione può penalizzare notevolmente le prestazioni e non protegge il cliente in caso di eventi non pianificati che si verificano nel sito che ospita la replica dello storage array o in caso di singola migrazione delle macchine virtuali tra data center.


Le macchine virtuali che si trovano sui datastore incapsulati in volumi virtuali con una singola copia di dati e che vengono presentate al cluster VMware in quella stessa sede sono, tuttavia, legate al sito e non possono essere spostate sul secondo sito senza interruzioni delle attività se si intende preservare la protezione dagli eventi non pianificati. La necessità di mantenere un gruppo di macchine virtuali su volumi virtuali non replicati può nascere da numerose ragioni, tra cui la criticità dal punto di vista aziendale delle macchine virtuali collocate nei datastore.

Figura 40. Visualizzazione di storage dei datastore presentati ai cluster VMware

Nella Figura 41 sono riportate informazioni aggiuntive rispetto a quelle della Figura 40. Quest’ultima figura include informazioni sulle macchine virtuali e i datastore nella configurazione utilizzata per questo studio. La figura illustra la collocazione in un datastore delle macchine virtuali che sono in esecuzione in una singola sede fisica. Nella figura è riportato anche il WWN del dispositivo SCSI che ospita il datastore “Distributed_DSC_Site_A”. La configurazione del volume virtuale di VPLEX Metro con il WWN illustrato nella Figura 41 è rappresentata nella Figura 42. La figura mostra che il volume virtuale viene esportato sugli host nel cluster VMware che si trova nel sito A.


Figura 41. Visualizzazione dei datastore e delle macchine virtuali utilizzate per questo studio


Figura 42. Informazioni dettagliate su un volume di Metro-Plex presentato a un ambiente VMware

La Figura 43 mostra le regole applicate sul volume virtuale che ospita il datastore Distributed_DSC_Site_A. Come si può vedere, le regole sono impostate per sospendere le attività di I/O nel sito B in caso di una partizione della rete. Le regole garantiscono quindi che se viene eseguita una partizione della rete le macchine virtuali che si trovano sul datastore Distributed_DSC_Site_A non subiscono alcun impatto. Analogamente, per le macchine che si trovano nel sito B, le regole sono impostate per garantire l’assenza di impatto sulle attività di I/O ai datastore, in caso di una partizione della rete.

Figura 43. Visualizzazione delle regole di scollegamento sui dispositivi distribuiti VPLEX


Migrazione senza interruzioni delle macchine virtuali con vMotion Un esempio della possibilità di migrazione delle macchine virtuali in esecuzione tra cluster, e quindi tra data center fisici, è illustrato nella Figura 44. La figura mostra chiaramente che dalla prospettiva di VMware vCenter Server la collocazione fisica dei data center non gioca alcun ruolo nel consentire lo spostamento in tempo reale dei carichi di lavoro tra siti (funzionalità supportata da EMC VPLEX Metro).

Figura 44. vCenter Server consente la migrazione in tempo reale delle macchine virtuali tra siti

La Figura 45 mostra una snapshot durante la migrazione senza interruzioni di una macchina virtuale da un sito all’altro. La figura illustra anche la console della macchina virtuale durante il processo di migrazione, evidenziando l’assenza di impatto per la macchina virtuale durante il processo.


Figura 45. La progressione di vMotion tra due siti fisici

È importante sottolineare che EMC sconsiglia di eseguire la migrazione di una sola macchina virtuale da un sito all’altro, poiché questa prassi non rispetta il paradigma discusso nei paragrafi precedenti. Una migrazione parziale delle macchine virtuali collocate in un datastore può provocare un’inutile interruzione del servizio in caso di partizione della rete. Ad esempio, dopo la corretta esecuzione della migrazione della macchina virtuale IOM02 illustrata nella Figura 44 e nella Figura 45, in caso di partizione della rete le regole applicate sul dispositivo collocato sul datastore sospenderanno le attività di I/O sul sito nel quale la macchina virtuale trasferita è in esecuzione. La sospensione delle attività di I/O causa un’interruzione improvvisa dei servizi forniti dalla macchina virtuale IOM02. Per evitare che si verifichi un evento del genere, EMC consiglia di eseguire la migrazione di tutte le macchine virtuali che si trovano su un datastore e di modificare quindi le regole applicate per il dispositivo che ospita il datastore interessato. Le nuove regole devono garantire il proseguimento degli I/O inviati al dispositivo che si trova nel sito sul quale è stata eseguita la migrazione.

Modifica della configurazione di volumi di VPLEX Metro non replicati Come spiegato nei paragrafi precedenti, EMC VPLEX Metro non limita la configurazione del volume virtuale esportato dal cluster. Una configurazione di VPLEX Metro può esportare una configurazione di volumi virtuali replicati e non replicati. Il tipo di volume virtuale da configurare viene stabilito in genere dai requisiti aziendali. Tuttavia, se i requisiti aziendali cambiano, la configurazione del volume virtuale su cui le macchine virtuali sono ospitate può essere modificata senza interruzione delle operazioni in un volume virtuale replicato e presentato a più cluster VMware, in sedi fisiche differenti per l’accesso simultaneo.

La Figura 46 mostra il datastore Conversion_Datastore correntemente disponibile solo su un cluster collocato in un unico sito (in questo caso, il sito A). Di conseguenza, le macchine virtuali contenute in questo datastore non possono essere migrate senza interruzioni sul secondo sito disponibile nella


configurazione di VPLEX Metro5

a meno che non venga abilitato l’accesso remoto per il dispositivo su cui il datastore Conversion_Datastore è stato creato o che la configurazione del dispositivo VPLEX non venga convertita in un dispositivo distribuito con copie dei dati sue entrambi i siti.

Figura 46. Datastore VMware disponibile su un solo sito, in una configurazione Metro-Plex

La Figura 47 mostra la configurazione del volume virtuale su cui il datastore è collocato. Come si vede dalla figura, il volume virtuale contiene un solo dispositivo disponibile sullo stesso sito. Se l’evoluzione dei requisiti aziendali impone la replica e la disponibilità del datastore in entrambi i siti, la configurazione può essere agevolmente modificata in caso sia disponibile sufficiente spazio di storage fisico nel secondo sito, che non contiene attualmente una copia dei dati.

5 Tecnologie come Storage VMotion possono essere utilizzate per eseguire la migrazione della macchina virtuale su un volume virtuale di VPLEX Metro replicato e disponibile in entrambi i siti, abilitando quindi la funzionalità di migrazione senza interruzioni della macchina virtuale tra siti. Questo tipo di approccio rende tuttavia il processo inutilmente complesso. Ciò nonostante, è possibile sfruttare il processo per spostare le macchine virtuali che non sono in grado di gestire il sovraccarico della replica sincrona.


Figura 47. Informazioni dettagliate relative a un volume virtuale Metro-Plex non replicato

Il processo di conversione di un dispositivo non replicato, incapsulato in un volume virtuale che viene replicato sul secondo sito e presentato al cluster VMware nel secondo sito è delineato di seguito. Il processo prevede quattro fasi:

1. Creazione di un dispositivo sul sito in cui deve risiedere la copia dei dati. Figura 48 Provisioning dello storage VPLEX per ambienti VMware. Il processo di creazione di un dispositivo, illustrato nella, è indipendente dal sistema operativo host ed è stato trattato nella sezione “Provisioning dello storage VPLEX per ambienti VMware”.

Figura 48. Creazione di un dispositivo su EMC VPLEX con l’uso dell’interfaccia utente

2. La fase successiva consiste nell’aggiunta del nuovo dispositivo come mirror al dispositivo esistente che deve essere protetto sulla distanza. L’operazione è illustrata nella Figura 49 e, come nel caso della fase precedente, è indipendente dal sistema operativo host che utilizza il volume virtuale creato utilizzando i dispositivi.


Figura 49. Modifica del tipo di protezione di un dispositivo VPLEX RAID 0 su RAID 1 distribuito

3. A questo punto è necessario creare o modificare il masking delle LUN su EMC VPLEX Metro per abilitare i VMware ESX Server collegati ai nodi sul secondo sito, per scendere al volume virtuale che contiene i dispositivi replicati. La Figura 50 mostra i risultati ottenuti dopo l’esecuzione del processo.


Figura 50. Creazione di una visualizzazione per esporre il volume virtuale di VPLEX sul secondo sito

4. È necessario eseguire il discovery sul cluster VMware nel secondo sito del volume virtuale di VPLEX appena esportato che contiene i dispositivi replicati. Il processo è analogo alla procedura di aggiunta di un qualsiasi dispositivo SCSI a un cluster VMware. Nella Figura 51 viene illustrato il datastore replicato ora disponibile sia sui cluster VMware nel sito A e nel sito B, dopo una nuova esecuzione della scansione del bus SCSI.

Figura 51. Visualizzazione degli WMware ESX Server che hanno accesso a un datastore

vCenter Server virtualizzato su VPLEX Metro VMware supporta istanze virtualizzate di vCenter Server 4.0 o versioni successive. L’esecuzione di vCenter Server e dei componenti associati in una macchina virtuale fornisce ai clienti grande flessibilità e comodità, poiché i vantaggi di un data center virtuale possono essere sfruttati per tutti i componenti di un’implementazione VMware. In un ambiente EMC VPLEX Metro, tuttavia, un’implementazione poco accurata di un vCenter Server in esecuzione su una macchina virtuale può comportare notevoli problemi in caso di guasto del sito. Ciò avviene soprattutto se vCenter Server viene utilizzato per gestire gli ambienti VMware implementati anche sullo stesso cluster EMC VPLEX Metro.


Come discusso nei paragrafi precedenti, in caso di guasto di un sito o di partizione della rete tra i siti, EMC VPLEX sospende automaticamente tutte le attività di I/O su un sito. Il sito su cui le attività di I/O vengono sospese è stabilito da una serie di regole attive quando si verifica l’evento. Questo comportamento consente di migliorare gli obiettivi RTO se si verifica il guasto di un sito e se VMware vCenter Server è collocato su un volume distribuito EMC VPLEX che è stato replicato su ambedue i siti. Il problema può essere spiegato meglio con l’uso di un esempio.

Si consideri il caso di un’implementazione di un ambiente VMware in cui vCenter Server e SQL Server sono in esecuzione su macchine virtuali diverse. Le due macchine virtuali sono però collocate su un dispositivo EMC VPLEX replicato (D) tra due siti A e B. In questo esempio si suppone che vCenter Server e SQL Server siano in esecuzione sul sito A. La best practice consigliata richiederà quindi che le attività di I/O al dispositivo D vengano sospese sul sito B. Questa indicazione consente alle macchine virtuali di ospitare le applicazioni di gestione vSphere per continuare l’esecuzione sul sito A in caso di partizione della rete6

1. Le attività di I/O al dispositivo D sul sito B devono essere riprese. Questo è possibile mediante l’interfaccia di gestione di VPLEX.

. Tuttavia, se un evento di interruzione provoca la perdita di tutti i servizi sul sito A, l’ambiente VMware diventerà ingestibile, perché l’istanza del dispositivo D sul sito B si troverà in uno stato di sospensione.Per porre rimedio, sono disponibili diverse azioni correttive, elencate di seguito:

2. Una volta riprese le attività di I/O al dispositivo D, è necessario dirigere vSphere Client su uno degli ESX Server sul sito B che ha accesso al datastore collocato sul dispositivo D.

3. La macchina virtuale su cui si trovano vCenter Server e l’istanza di SQL Server deve essere registrata tramite vSphere Client.

4. Una volta registrate le macchine virtuali, è necessario avviare dapprima SQL Server.

5. Quando SQL Server funziona a pieno regime, avviare vCenter Server.

Attenendosi alla procedura, si può ripristinare un ambiente di gestione VMware completamente operativo sul sito B in caso di guasto sul sito A.

L’esempio sopra riportato mostra chiaramente che la collocazione di vCenter Server su un dispositivo VPLEX Metro replicato può aggiungere ulteriore complessità all’ambiente in caso di guasto di un sito. Per ridurre questo rischio si possono utilizzar due possibili tecniche:

vCenter Server e SQL Server devono essere collocati su dispositivi EMC VPLEX non replicati. L’heartbeat di VMware può servire per replicare in modo trasparente i dati di vCenter tra i siti e fornire un meccanismo di ripristino in caso di guasto del sito. Questa soluzione consente a vCenter Server di eseguire il failover automatico sul sito ancora operativo con interventi davvero minimi. Per ulteriori informazioni, consultare la documentazione relativa a VMware vCenter Server Heartbeat.

vCenter Server e SQL Server possono essere collocati in un terzo sito indipendente che non subisce alcun impatto in caso di guasto del sito in cui si trovano gli VMware ESX Server. Questa soluzione consente ai servizi di gestione di VMware di essere disponibili anche durante la partizione della rete che interrompe le comunicazioni tra i siti in cui si trova EMC VPLEX Metro.

I clienti possono scegliere la soluzione più adeguata per il proprio ambiente in uso dopo aver valutato vantaggi e svantaggi di ognuna.

6 È importante sottolineare che, in caso di partizione della rete, la macchina virtuale in esecuzione sul sito B continuerà ad operare senza interruzioni. Tuttavia, poiché vCenter Server collocato sul sito A non dispone di connettività di rete ai server del sito B, l’ambiente VMware ESX Server sul sito B non potrà essere gestito. Questo porta all’indisponibilità di funzionalità avanzate come DRS e VMotion.


Conclusioni EMC VPLEX con sistema operativo EMC GeoSynchrony è una tecnologia di federation di classe enterprise basata su SAN che consente di aggregare e gestire pool di storage array con collegamento Fibre Channel, collocati sia in un singolo data center che in più data center a distanze supportate dalle reti metropolitane (MAN, Metropolitan Area Network). Grazie alla speciale architettura completamente scalabile, il caching avanzato dei dati e la coerenza della cache distribuita del sistema EMC VPLEX consentono massima resilienza e condivisione automatica dei carichi di lavoro, bilanciamento e failover dei domini di storage, nonché accesso locale e remoto ai dati con livelli di servizio prevedibili. Un data center basato sulla piattaforma di virtualizzazione VMware supportato con le funzionalità di EMC VPLEX fornisce prestazioni, scalabilità e flessibilità migliorate. La capacità di EMC VPLEX di fornire funzionalità di spostamento dei dati eterogenei e di gestione dei volumi senza interruzione delle operazioni, su distanze sincrone, consente ai clienti di offrire servizi cloud intelligenti ed economici in più sedi fisicamente dislocate.

Bibliografia Di seguito sono elencati i documenti che forniscono ulteriori informazioni su VPLEX, reperibili sul sito web di EMC e su Powerlink.

• Note tecniche alle best practice per la pianificazione e l’implementazione di EMC VPLEX • TechBook: EMC VPLEX Architecture and Deployment: Enabling the Journey to the Private Cloud Di seguito sono elencati i documenti che forniscono ulteriori informazioni sulle soluzioni EMC con prodotti VMware, reperibili sul sito web di EMC e su Powerlink. • •

White paper: Using VMware vSphere with EMC Symmetrix Storage white paper White paper: EMC Symmetrix VMAX and VMware Virtual Infrastructure – Applied Technology

• TechBook: Using EMC CLARiiON Storage with VMware vSphere and VMware Infrastructure • • Virtual Storage Integrator for vSphere Client 3.0 Product Guide (solo Powerlink)

TechBook: Using EMC Symmetrix Storage in VMware Virtual Infrastructure Environments

• EMC PowerPath/VE for VMware vSphere Version 5.4 and Service Pack Installation and Administration Guide (solo Powerlink)

Le informazioni seguenti sono reperibili sul sito web VMware: • Libreria online VMware vSphere • vCenter Server Heartbeat Reference Guide

http://www.italy.emc.com/collateral/hardware/white-papers/h6531-using-vmware-vsphere-with-emc-symmetrix-wp.pdf�



http://www.italy.emc.com/collateral/software/solution-overview/h2197-vmware-esx-clariion-stor-syst-ldv.pdf�

http://www.italy.emc.com/collateral/hardware/solution-overview/h2529-vmware-esx-svr-w-symmetrix-wp-ldv.pdf�

http://www.italy.emc.com/collateral/hardware/solution-overview/h2529-vmware-esx-svr-w-symmetrix-wp-ldv.pdf�

http://powerlink.emc.com/km/live1/en_US/Offering_Technical/Technical_Documentation/300-008-703.pdf�

http://powerlink.emc.com/km/live1/en_US/Offering_Technical/Technical_Documentation/300-008-703.pdf�

http://pubs.vmware.com/vsp40u1/wwhelp/wwhimpl/js/html/wwhelp.htm#href=welcome/welcome.html�

http://www.vmware.com/pdf/heartbeat_55_u2_reference_guide.pdf�

Utilizzo delle piattaforme di virtualizzazione VMware con ... delle piattaforme di virtualizzazione...

Documents

Transcript of Utilizzo delle piattaforme di virtualizzazione VMware con ... delle piattaforme di virtualizzazione...