Reading Time: 5 minutes

Nel mio incontro con Avere Systems, durante l’ultimo evento Powering the cloud, ho avuto modo di parlare con Rebecca Thompson (VP Marketing) and Bernhard “Bernie” Behn (Principal Technical Marketing Engineer).

Avere Systems è un’azienda specializzata in soluzioni di NAS Optimization, pensate per scalare in performance e capacità (in modo indipendente) e sfruttare al meglio le soluzioni di storage Flash-based usando funzionalità di real-time tiering.

L’azienda è stata fondata nel 2008 ba un gruppo di esperti di storage. Il presidente e CEO Ronald Bianchini, Jr. era stato Senior Vice President in NetApp e prima ancora, CEO e Co-Founder di Spinnaker Networks, azienda che la sviluppato l’archiettura Storage Grid poi acquistata da NetApp. Da notare anche che il CTO Michael Kazar ha lavorato su diverse versioni del Carnegie Mellon University’s Andrew File System, come pure sull’Andrew Toolkit.

La sede principale si trova a Pittsburgh (PA), ma hanno anche un ufficio in EMEA in UK.

Durante l’incontro abbiamo discusso di come la loro si differenzia rispetto ad altre e soprattutto come cercano di ridurre il problema della latenza degli storage (NAS based).

In una soluzione tradizione di storage vi sono alcuni possibili “generatori” di latenza:

  • HDD latency (tipico per dischi grossi come i SATA, può essere parzialmente ridotto aumentando la velocità dei dischi e/o il loro numero o usando soluzioni SSD)
  • Storage CPU latency (su molti NAS entry level i processori sono molto limitati)
  • Geographic latency (rende poco adatto l’uso di storage NAS su WAN, ovviamente la latenza dipende dalla distanza, ma soprattutto dalla banda disponibile)

Le soluzioni tradizionali per ridurre la latenza dello storage portano ad un incremento dei costi dello stesso.

Nella soluzione di Avere Systems, di definiscono due diversi ruoli:

  • Edge Filer (vicino agli host), prodotto da Avere, che è in grado di ridurre la latenza, aumentare le prestazioni (accelerando le operazioni di lettura, ma anche quelle di scrittura e quelle sui metadati) e garantendo una scalabilità lineare all’aumentare del numero di edge..
  • Core Filer (lo storage tradizionale), che a questo punto può essere ottimizzato sulla capacità, anche mischiando soluzioni di storage di tipo diverso.

Rispetto ad altre soluzioni basate su tecnologia flash, questo approccio risolve alcuni problemi tipici:

  • Filer-Side Flash: in questa soluzione le flash sono lato storage e ovviamente le VM critiche devono essere posizionati sugli storage accelerati, ma il rischio (con una non corretta distribuzione) è trovarsi delle flash non usate. E comunque non può ottimizzare storage remoti.
  • Server-Side Flash: in questa soluzione le flash sono lato host e le VM critiche vanno posizionate sugli host accelerati. In queste soluzioni, per ragioni di consistenza, la cache è di tipo read-only. L’altra problematica è che sono richiesti driver particolari per sfruttare questa architettura.

Con la soluzione Avere FTX Edge Filer si ha a disposizione un Global Flash Pool che può effetturare funzioni di caching sia in lettura che in scrittura, sia sui dati ma anche sui metadati, come pure sulle operazioni di lock. Questo perché il protocollo di storage viene “terminato” sull’edge, trasformandolo in una sorta di “proxy”.

Quando i nodi sono più di due, non solo è possibile scalare le prestazioni della soluzione (in modo completamente lineare, fino a 50 nodi), ma anche implementare una soluzione di HA, dove ogni nodo dispone di un altro di peer, pur mostrando agli host un unico global namespace (basato sulla A3 architecture).

Considerando il traffico che può essere ottimizzato, con queste soluzioni è possibile raggiungere densità maggiori. Si stima un rapporto 100:1 di off-load per VM tipiche in VMware, dove quindi solo 1% del traffico transita poi sui core filer. Notare che tutti gli esempi e case sono al momento basati su architettura VMware (però portabili anche ad altre soluzioni) e che stanno pure sviluppando soluzioni specifiche di off-load con le funzioni VAAI per NAS.

Lato front-end le soluzioni supportano SMB2 (non ci sono ancora date ufficiali per il supporto SMB3) e NFS. Lato back-end solo NFS (sarebbe interessante vedere se prevederanno anche specifici connettori per cloud provider di storage).

Un caso d’uso abbastanza interessante è lo scenario ROBO (Remote Office/Branch Office): in questo caso si può centralizzare tutti gli storage nella sede centrale e disporre nelle periferie di host ESXi con relativi edge filer.

Per maggiori informazioni (in inglese) vedere anche:

Vedere anche: Altri report dell’evento Powering the Cloud 2012.

Share