Questo post è disponibile anche in: Inglese

In un post di alcuni mesi fa avevo discusso a grandi linee di alcuni modelli di storage, introducendo alcuni semplici concetti, tra cui i modelli di tipo scale-in (o, più propriamente scale-up) rispetto a quello di tipo scale-out. Modelli diversi corrispondono ad approcci diversi con diversi pro e contro per ciascuno.

Paradossalmente non è che la terminologia aiuti e spesso di chiamano scale-out oggetti che forse scale-out non lo sono. Del resto manca una vera e propria definizione su cosa sia (o cosa non sia) uno storage scale-out: ve ne sono alcune, ma limite ai contesti del mondo NAS (come questa definizione o questo tutorial SNIA), in altri casi sono più definizioni da marketing che arrivano direttamente da alcuni vendor.

Normalmente uni scale-out storage dovrebbe comportare:

  • Una soluzione basata su multi-device (o multi-array) che vengono poi aggregati come pool di risorse viste come un unico insieme logico
  • Capacità di scalare sia in termini di capacità che di prestazioni
  • Gestione unica e centralizzata di tutti i sistemi
  • Qualche funzione di fault-tolerance o high availability o di data protection attraverso i vari sistemi

Banalizzando potremmo considerare una soluzione di tipo scale-in (scale-up) un modo per incrementare la capacità (e le prestazioni della parte di back-end), ma non il numero di storage controller (e la parte di front-end ); mentre invece una soluzione scale-out è un insieme di più arrays (senza storage condiviso tra i vari array) visti un singolo array logico con la somma delle diverse capacità e prestazioni.

Storage-Scaleout-Scalein

Nel mondo reale, in realtà le cose sono un po’ più complicate e non è solo nero e bianco, dato che esistono anche altri tipi di modelli. In un post (in inglese),  di Hans De Leenheer (Why Windows Scale Out File Server is not exactly a scale-out storage), sono spiegati  diversi modelli e anche come collogare il Scale-Out File Server (SOFS) di Microsoft, che è un modello più simile ad un full mesh back-end storage, più che ad uno scale-out storage in senso stretto.

In realtà, dal punto di vista dei front-end o visto come un NAS, la soluzione SOFS è effettivamente un modello scale-out, ma il back-end è condiviso e questo ne limita la potenziale capacità di crescita e scaling, soprattutto se abbinata (come normalmente è) alla tecnologia di Storage Spaces, che richiede shared-JBOD (e questi sono veramente limitati come numero di dispositivi collegabili). Non vuol dire che il SOFS sia una soluzione peggiore (o per forza migliore), semplicemente è un modello diverso rispetto uno storage scale-out tradizionale.

Per altre ragioni, neppure una soluzione come Dell EqualLogic può veramente considerarsi una soluzione di tipo (full) scale-out storage, dato che pecca di funzinalità (automatiche) di disponibilità distribuita (esiste una funzione chiamata SyncRep per fornire data protection, ma non è automatica nel recovery, almeno non nei firmware correnti).

Persino lo stora scale-out storage in senso stretto si è evoluto delle prime generazioni (ad esempio Left-Hand prima dell’acquisizione da parte di HP) a nuove generazioni e persino nuovi modelli con scalabilità molto spinta (uno dei primi di questa nuova generazione probabilmente è stata la soluzione di Nutanix) dove si parla persino di “Web-Scale” al posto di semplice scale-out.

In questi nuovi modelli di solito non ci sono limiti (o sono ragionevolmente elevati) di scalabilità, ma soprattutto è possibile scalare in modo spesso deterministico e lineare sia per la capacità che per le prestazioni, come in questo esempio fornito da Coho Data:

Coho-ScaleOut

Tanti altri vendor con delle proprie soluzioni di scale-out storage (come, ad esempio, SolidFire) aggiungo un loro punto di vista a quali sono i vantaggi della loro architettura (ed in generale di quelle full scale-out). Ma ovviamente non è solo bianco o nero. Esistono vari storage con approcci un po’ ibridi o diversi. E nonostante in molti si siano spostati verso approcci scale-out (anche VMware con la sua VSAN, per esempio), non tutti sono fermamente convinti in questo modello o, quanto meno, dicono la loro.

Ad esempio, Pure Storage, ha risposto ad alcune critiche da XtremIO direttamente dal loro blog, con un post che contiene anche alcune considerazioni sul discorso scale-out vs. scale-in:

Scale-out vs. scale-up is somewhat of an academic discussion, customers should ultimately be asking about the max capacity a given cluster can support, and how much hardware / RUs / cost is required to get there. Pure was designed with a similar Infiniband/RDMA clustered controller interconnect architecture to XtremIO, we’ve just focused first on maximizing vertical scale before horizontal scale (vertical scale is more cost-effective than horizontal scale, horizontal scale becomes important when you need to expand performance beyond what vertical scale can deliver).

Naturalmente è un punto di vista come un altro. Del resto sono modelli abbastanza diversi che spesso è cercare di comparare mele con pere (o peggio ancora angurie con cetrioli).

Rimane comunque innegabili i vantaggi dei modelli scale-out (o web-scale) che non sono altrettanto facili da ottenere con soluzioni basate su storage condiviso: nessun single point of failure (è vero che un JBOD condiviso difficilmente si rompe, ma è comunque un potenziale single point of failure) e approccio distribuito e “lineare, con la potenzialità di implementare soluzioni di tipo “fault domain” con resilienza su un intero insieme (armadio o in alcuni casi persino datacenter, utilizzando metro-cluster e soluzioni che le supportino).

Per contro una soluzione scale-out dipende maggiormente dalla rete sia in termini di latenza che di prestazioni (la replica dei dati deve essere comunque fatta sulla rete). Tra l’altro la rete (“Ethernet”) non è che sia a livello 2 facilmente scalabile su numeri interessanti. Da questo punto di vista è decisamente interessante l’approccio di Coho che integra Software Defined Storage con Software Defined Network, dove quest’ultima è usata per “commutare” i percorsi di rete necessari allo storage.

Andrea MauroAbout Andrea Mauro (2794 Posts)

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


Related Post:

Share