This post is also available in: Inglese

PernixData FVP è un software di tipo Flash Hypervisor (pensato e progettato per il mondo VMware vSphere) in grado di aggregare server flash in un cluster scalabile (di tipo scale-out) con funzioni di data tier per accelerare le letture, ma anche le scritture rendendo più veloce lo storage condiviso esistente. Questa soluzione è stata una delle prime (se non la prima in assoluto) ad implementare una fault-tolerant write back usando flash locali.

Nel post precedente abbiamo visto la procedura di installazione di FVP 1.5 su vSphere 5.5, in questo post verrà descritta la procedura di configurazione di un Flash Cluster e il relativo utilizzo.

La configurazione di PernixData FVP è veramente molto semplice e può essere gestita indifferentemente dal vecchio vSphere Client oppure dal nuovo vSphere Web Client (a partire da FVP 1.5). In entrambi i casi le funzionalità sono identiche e pure le schermate (sono comunque schermate web) sono equivalenti.

Se si utilizza il vSphere Client si avrà un nuovo tab (PernixData) nelle viste relative ai cluster, agli host e alle VM (ovviamente bisognerà prima installare il plugin, come descritto nel post precedente).

Se si utilizza il vSphere Web Client si potrà notare una nuova voce in fondo all’area di navigazione dell’inventario (notare che in questo caso non sarà necessario installare nulla, visto che la voce viene registrata del Web Client durante la fase di installazione del FVP Manager).

Ho provato la configurazione con entrambi i tool, ma gli screenshot successi sono solo per la configurazione tramite Web Client (visto che il vecchio client sarà dismesso dalla prossima versione di vSphere).

Il wizard sintetizza i pochi passi che dovete segure per la configurazione del primo Flash Cluster (da notare che comunque si possono creare anche più Flash Cluster, nel caso si disponga di più flash locali e della versione di FVP completa):

Prima di tutto bisogna definire il nome del Flash Cluster ed associarlo al vSphere Cluster (di norma tutti gli host dovranno essere configurati, anche se nella modalità di accelerazione delle sole letture, potrei scegliere di accelerare solo alcuni host). A questo punto è possibile specificare quali sono i device flash locali da utilizzare:

In questo menu vengono visualizzati sono i device “liberi” e di tipo SSD e vengono nascosti quelli non locali, non di tipo SSD o quelli che presentano delle partizioni e/o formattazioni. Utilizzando il flag “show all device” è possibile capire il motivo per il quali altri dischi sono stati nascosti; questo è decisamente comodo (ad esempio VSAN non ha una funzione simile, o quanto meno non così immediata, e dovete assicurarvi di avere dischi blank prima di iniziare la configurazione).

Un modo semplice per “ripulire” un disco (senza utilizzare comandi da CLI, come ad esempio partUtil, oppure comandi specifici del proprio hardware) è aggiungerlo come datastore in vSphere e subito dopo cancellarlo (questo rimuoverà la tabella delle partizioni e lo renderà disponibile a FVP).

Notare che i dischi FVP non vengono “marcati” come in uso e quindi dall’interfaccia di gestione di vSphere si potrebbero erroneamente formattare come datastore VMFS (o assegnare come RDM); operazione che non ho verificato ma che (nel caso venga permessa) darebbe seri problemi. In questo caso sarebbe interessante se venisse utilizzata la funzione di filtering per “nascondere” i dischi già usati anche nell’interfaccia di gestione di vSphere.

Associate le risorse Flash, a questo punto è possibile associare il proprio Flash Cluster ad uno o più datastore VMFS (al momento FVP funziona solo per datastore a blocchi):

Notare che il default è di accelerare i datastore solo in lettorua (impostazione “write though”), ma è possibile cambiarlo, datastore per datastore con diverse opzioni di accelerazione in scrittura (“write back”):

Le diverse modalità di write back sono:

• Local flash only: le scritture sono realizzate solo sulla cache locale e successivamente sullo storage. Poiché questa modalità non è compatibile con l’HA (il contenuto della cache non sarebbe accessibile nel caso di failure di un host) non è raccomandato in produzione. MA può essere utile in laboratorio o in casi molto particolari per testare le prestazioni della cache.
• Local flash and 1 network flash device: le scritture sono realizzate in modo sincrono sia sulla cache locale che sulla cache di un altro nodo e successivamente scritte sullo storage. Questo fornisce un livello di disponibilità di tipo N+1 e va bene per ambienti medio/piccoli.
• Local flash and 2 network flash device: le scritture sono realizzate in modo sincrono sia sulla cache locale che sulla cache di altri due nodi e successivamente scritte sullo storage. Questo fornisce un livello di disponibilità di tipo N+1 e va bene per ambienti medio/grandi.

Notare che è possibile definire diverse cache policy sia per differenti datastore, ma anche per differenti VM in modo molto granulare.

Ovviamente la write back con ridondanza richiede un buon design della rete e link molto veloci per ridurre la latenza. Nel tab advanced è possibile configurare la rete che sarà usata per la replica tra cache (di default viene usata la rete del vMotion):

In un ambiente di produzione link a 10 Gbps sono non solo raccomandati, ma diventano quasi obbligatori, considerando anche che in FVP si può specificare solo una interfaccia per host.

A questo FVP è già attivo ed è possibile monitorare in vari modi come sta migliorando il vostro storage e le vostre VM:

Notare che, lato datastore, la policy di multi-path viene sostituita da una nuova specifica per PernixData, come in questo esempio (dove la policy iniziale era MRU):

Possibili problemi?

Davvero è tutto rose e fiori senza alcun problema? In verità ho riscontrato un paio di potenziali problemi minori in situazioni particolari durante la configurazione.

Ad esempio ho avuto alcuni problemi durante lo Storage vMotion delle VM: questo tipo di operazioni (ma come anche il deploy o il clone), benché supportate, vanno evitate in casi particolari come l’attivazione o la disattivazione del Flash Cluster. Questo perché durante queste fasi può rimanere un’inconsistenza nello stato delle VM all’interno di PernixData FVP:

In questo non avevo trovato una veloce soluzione per far uscire la VM da questo stato (dove non era possibile accelerarla). Un altro stato particolare che può accadere e quando la VM rimane bloccata sulla sola accelerazione in lettura. Sicuramente la CLI ha opzioni per sistemare queste inconsistenze. Ma il modo più semplice e veloce che ho trovato è stato di cancellare e rideploiare la VM (visto che nel mio caso era solo una VM da utilizzare per i test).

Problemi simili si hanno con VMware DPM (anche se effettivamente in produzione non l’ho mai visto): bisogna assicurarsi che tutti gli host siano accesi prima di configurare il Flash Cluster, altrimenti non sarà possibile configurare la modalità write back che richiede l’attivazione su tutti i nodi del cluster VMware. in questo caso l’unica soluzione per è quella di distruggere e ricreare il Flash Cluster quando tutti i nodi sono online.

Altre risorse

Vedere anche queste risorse (in inglese) relative alla configurazione e l’utilizzo di FVP:

• Deploying PernixData FVP with ESXi 5.x (Partner Support) (2073257)
• PernixData FVP – Configuration (Part 2 of 3)
• PernixData FVP in my lab. Part 2 – Installation
• Automating Pernixdata FVP – Part 1: Installation
• PernixData in the Lab

Andrea Mauro

Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-24. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-23. Nutanix NTC 2014-20. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.