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.
Il Flash Cluster è stato rinominato in FVP Cluster poichè anche la RAM è adesso supportata in aggiunta ai dispositivi SSD e flash card.
Nella sezione Resources le risorse vengono ora riferite sia ai dispositivi flash che alla RAM.
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.
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.
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.
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.
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.
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.
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.
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.
Creare un Fault Domain
Nella sezione Fault Domains, come default gli host configurati nell'FVP Cluster sono riportati sotto la voce Default Fault Domain.
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.
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.
Ripetere la stessa procedura per creare Fault Domains aggiuntivi.
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.
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.
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.
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.
