PernixData FVP 2.0 rilasciata

pernixdatafvp20version01

E’ stata rilasciata la nuova versione di PernixData FVP 2.0 che introduce nuove ed interessanti funzioni come DFTM, pieno supporto per datastore NFS, Fault Domains ed Adaptive Network Compression.

Il software utilizzato per accelerare le operazioni di read e write nello storage condiviso, con la nuova release 2.0 pone PernixData FVP in una posizione predominante nel mercato come soluzione flash-caching.

 

Novità

Le nuove funzioni principali introdotte con questa nuova release sono le seguenti:

  • Datastore NFS pienamente supportati.
  • Distributed Fault Tolerant Memory (DFTM): supporto RAM come dispositivo flash aggiuntivo.
  • Fault Domains.
  • Adaptive Network Compression.

 

Panoramica

Installata la nuova release, tramite il vSphere Web Client accedere alla schermata principale di PernixData FVP. A prima vista è possibile notare alcune piccole differenze rispetto alla versione precedente.

pernixdatafvp20version02

Il Flash Cluster è stato rinominato in FVP Cluster poichè anche la RAM è adesso supportata in aggiunta ai dispositivi SSD e flash card.

pernixdatafvp20version03

Nella sezione Resources le risorse vengono ora riferite sia ai dispositivi flash che alla RAM.

pernixdatafvp20version04

Nell’area Performance Summary è presente una nuova voce identificata come FVP Network Saving che riflette la banda risparmiata come risultato della funzione Adaptive Network Compression.

pernixdatafvp20version05

 

Supporto per datastore NFS

Nella versione 2.0 i datastore NFS sono ora pienamente supportati. Durante la creazione del cluster, i datastore o le VM da accelerare possono essere aggiunte posizionandosi nella sezione Datastores/VMs.

pernixdatafvp20version06

Cliccando sul bottone Add Datastores, vengono visulizzati tutti i datastore disponibili nel cluster vSphere che possono essere utilizzati nel cluster FVP per essere accelerati. Nella lista compaiono adesso anche i datastore NFS che possono essere accelerati in modalità Write Through e con replica Write Back.

pernixdatafvp20version07

Nei datastore NFS che vengono accelerati, non cambia niente dal punto di vista funzionale e il tutto rimane invariato.

 

Supporto RAM

Un’altra nuova funzione della release 2.0, in aggiunta ai dispositivi SSD e flash card, anche la RAM disponibile viene ora visualizzata come risorsa che può essere utilizzata per l’accelerazione.

pernixdatafvp20version08

E’ possibile utilizzare la RAM disponibile nell’host selezionato ed utilizzarla per il  l’FVP Cluster. RAM e i dispositivi flash SSD non possono essere aggiunti dallo stesso host.

pernixdatafvp20version09

Quando viene selezionata la RAM bisogna specificare la quantità da impiegare per l’accelerazione. La quantità minima di RAM che è possibile aggiungere all’FVP Cluster è di 4 GB per server mentre la quantità massima è di 1 TB per server. La RAM deve essere aggiunta in multipli di 4 GB.

pernixdatafvp20version10

Quando si utilizza la RAM come risorsa, ci sono alcuni punti da tenere presente:

  • Non è richiesto che ogni host partecipi in termini di risorse nell’FVP Cluster.
  • Non è richiesto che tutti gli host forniscano la stessa quantità di RAM nel cluster.

Per modificare la quantità di RAM per l’accelerazione, posizionarsi in Manage > Acceleration Resources, selezionare l’Host desiderato e cliccare su Edit. Impostare il valore che si desidera configurare.

pernixdatafvp20version11

Tutte le funzionalità previste nella versione 1.5 sono ora supportate anche per la RAM.

 

RAM vs Write Back policy

In modalità Write Back le VM prelevano la RAM dall’host in cui vengono fatte girare per la loro accelerazione. Tutte le operazioni di I/O Read e Write richiamano la RAM dall’host in cui vengono eseguite.

Tutte le operazioni di write vengono replicate nella RAM di un altro host come specificato nella configurazione abilitata in Write Back + 1.

Quando la VM utilizza il sistema per effettuare l’operazione di vMotion da un host ad un altro, accede alla RAM dell’host in cui girava precedentemente.

 

Fault Domains

I Fault Domains è un’altra nuova funzione introdotta in questa release e consente agli amministratori di allineare il design degli FVP Cluster con il design dei Datacenter. E’ utile per controllare dove la replica va ad appoggiarsi quando è utilizzata la modalità di Write Back.

Con i Fault Domains è possibile partizionare logicamente gli host nel cluster vSphere in due Fault Domains differenti.

Se viene  impostata la policy Write Back, quando un datastore viene aggiunto all’FVP Cluster nella precedente versione andava specificato il numero di repliche che dovevano essere utilizzate (0,1,2). Ora va specificato su quale Fault Domain il Peer deve collocarsi.

pernixdatafvp20version12

 

Creare un Fault Domain

Nella sezione Fault Domains, come default gli host configurati nell’FVP Cluster sono riportati sotto la voce Default Fault Domain.

pernixdatafvp20version13

Durante la configurazione del Fault Domain, è possibile aggiungere gli host in qualsiasi ordine ed impostare dove la replica punta quando le VM girano in un qualsiasi host membro del Fault Domain.

Per creare un nuovo Fault Domain cliccare sul bottone Add Fault Domain e digitare un Name.

pernixdatafvp20version14

Per partizionare logicamente l’host cliccare un Fault Domain appena creato e cliccare sul bottone Add Host. Selezionare poi dalla lista un host e cliccare OK per confermare.

pernixdatafvp20version15

Ripetere la stessa procedura per creare Fault Domains aggiuntivi.

pernixdatafvp20version16

 

Associare i Fault Domains

Selezionare un Fault Domain creato precedentemente e cliccare su Edit Association. Gli altri Fault Domains disponibili sono visulizzati nella finestra Edit Associations. Selezionare un Fault Domain disponibile (es. fault02) e cliccare su OK per confermare.

pernixdatafvp20version17

Effettuare la stessa operazione per il fault02 Fault Domain. Come risultato si ottiene che le VM che girano nell’host  fault01 avranno la replica che punterà al Fault Domain fault02.

pernixdatafvp20version18

Se dovuto al DRS o alle custom rules configurate in vSphere le VM vengono spostate in host differenti in fault01 o fault02, la replica viene automaticamente modificata.

 

Adaptive Network Compression

L’ultima funzione introdotta in FVP 2.0 è l’Adaptive Network Compression. Nel caso di restrizioni nella banda della rete, specialmente negli ambienti a 1 GB, quando la modalità Write Back è utilizzata, la latency della replica verso le risorse remote può a volte impattare sulle performance delle VM.

La compressione si attiva nello step precedente alla fase di pushing dei dati nella rete per effettuare un’altra copia: i dati sono trasmessi in modalità compressa verso le risorse remote.

Il costo della compressione in termini di CPU workload è di circa il 2% e non dovrebbe comportare un peggioramento importante delle prestazioni del sistema ed inoltre questa funzione è abilitata principalmente per gli ambienti a 1 GB poichè in ambienti a 10 GB non sono stati riscontrati miglioramenti significativi.

La tecnologia FVP è intelligente a sufficienza per capire se un ambiente è configurato con switch a 10 GB e quindi non abilita la compressione.

 

Licenze

Sono disponibili quattro edizioni per agevolare qualsiasi esigenza dei data center.

pernixdatafvp20version19

 

PernixData FVP si conferma come una valida soluzione da tenere presente nel caso si riscontrassero sofferenze prestazionali dell’I/O nello storage condiviso. Semplice da installare, semplice da configurare, facile da usare.

firma