Il mondo dei FileSystem Distribuiti è un mondo interessante, ma non privo di insidie. In questo articolo proveremo a scovare quelli che sono i problemi che potrebbero trasformare un bel progetto in un disastro completo.
Partiamo con il fare una distinzione. Ci sono due modi per progettare un'infrastruttura di virtualizzazione, il modo tradizionale ed il modo distribuito.
Infrastruttura tradizionale
L'infrastruttura tradizionale è composta da uno o più nodi ed una SAN. I nodi si occupano di erogare capacità computazionale (CPU e RAM) e la SAN si occupa di passare la parte di storage con le varie LUN. Non ci soffermiamo troppo sulle varie sfaccettature che questa architettura consente, volontariamente ho semplificato lo schema per non aggiungere "carne al fuoco". Inoltre nello schema la SAN è collegata in iSCSI, questo ci facilita le comparazioni architetturali.
Infrastruttura distribuita
Nell'infrastruttura distribuita ogni nodo apporta, a beneficio di tutti, non solo la propria capacità computazionale ma anche il proprio storage. Non esiste, pertanto, una vera e propria SAN. I nodi sono normalmente molto meno performanti, ma in quantità maggiore.
Alcuni approfondimenti preliminari
Qui abbiamo parlato degli errori comuni commessi da chi dimensiona una SAN.
Qui, invece, abbiamo parlato di architetture, ridondanze e performance.
Questo, invece, è un articolo che entra molto nel dettaglio delle performance, vitali e fondamentali in un sistema di virtualizzazione, in grado di vanificare qualsiasi investimento se mal dimensionato.
In linea di massima, consiglio al lettore curioso un approfondimento di tutto il tag Storage di questo blog.
Il laboratorio
Per testare gli argomenti presi in esame e fortemente motivati da una sana curiosità verso quella che potrebbe essere una tecnologia rivoluzionaria, abbiamo creato un'infrastruttura con 10 nodi CEPH. A breve creeremo anche un laboratorio vSAN vmware. Lo so... comporta tempo, ne abbiamo poco, ma ritenere che la ricerca sia meno prioritaria dell'attività commerciale denota una visione aziendale non lungimirante. Ma questo è un altro discorso.
I 10 nodi consentono un'infrastruttura virtuale e mettono a disposizione CEPH. In CEPH, ogni disco (che per prassi è un disco fisico dedicato) diviene un OSD che possiamo suddividere in classi. I dischi con le stesse classi verranno aggregati. (in foto il test di 2 fault con dei pool con replica a 3)
In questo laboratorio abbiamo creato 3 FileSystem Distribuiti per un totale di 14 dischi dedicati:
- HD300 è formato da soli 2 dischi SATA su due nodi diversi
- Pool 32 è un pool di 8 dischi da 500Gb SATA, 1 per 8 nodi
- SSD è un pool di 4 dischi SSD da 500Gb, sempre distribuiti 1 per nodo
Come funziona la replica?
E' improprio, ma immaginiamo un RAID sparpagliato su molti nodi. In fase di creazione del Pool di OSD (quindi dell'Array, per usare sempre il paragone con il RAID) potremo decidere il numero di repliche del dato, quindi quanto vorremo sacrificare il nostro spazio in favore della resilienza al guasto.
Va detto: i dischi non devono essere tutti uguali come nel RAID tradizionale. Qui ogni nodo apporta il suo. L'accortezza, al massimo, è di creare dischi che come performance siano paragonabili. Inutile mettere un SSD all'interno di un Pool con 10 SATA.
La seconda accortezza è di non avere tagli troppo differenti in quanto un disco da 4Tb in un pool di 10 dischi da 250Gb non ha molto senso per una palese ed ovvia difficoltà di replica e distribuzione del dato. Il disco di grandi dimensioni verrà più interessato dalle operazioni di IO, questo è evidente.
Differenze progettuali tra le due architetture
E' evidente, le due architetture differiscono profondamente. A mio avviso non ha senso valutare un'infrastruttura distribuita con meno di 6 nodi (e che in previsione devono scalare nel breve periodo in numero maggiore). Proviamo comunque a schematizzarne i pregi ed i difetti di ognuna.
Tradizionale (PRO)
- E' facile da manutenere, ogni elemento è identificabile e la diagnostica di problemi di performance è relativamente semplice
- Da un punto di vista di licensing, con le nuove politiche basate su core e socket, è decisamente più economica
- I consumi energetici sono minori in quanto le macchine da tenere accese sono certamente meno. Il contenimento dei costi energetici è un problema sempre più presente nelle aziende.
- L'infrastruttura di rete può essere anche economica, avere interfacce in Gigabit non è scandaloso. Con l'architettura distibuita il 10Gbit è il minimo sindacale, senza se e senza ma, e questo decuplica i costi sul networking.
- Se voglio la performance pura, questa si sposa più con l'architettura tradizionale in cui i nodi sono molto spinti come capacità computazionale. E' comunque sempre vero che una VM sfrutta al massimo quanto eroga il proprio nodo fisico, quindi se i nodi sono tanti ma economici, nessun nodo potrà erogare performance comparabili con uno "ben carrozzato".
- In una SAN, l'aumento dei dischi coincide con l'aumento degli IOPS. A differenza dell'architettura distribuita dove il collo di bottiglia è sempre la NIC (preferenzialmente dedicata) dell'host che ospita la macchina virtuale.
Distribuita (PRO)
- Estremamente scalabile, basta aggiungere nodi
- Molto improntata al fault tolerance, non c'è un singolo point of failure, i nodi sono totalmente e indiscutibilmente indipendenti
- Relativamente economica da un punto di vista hardware, i nodi costano molto meno in quanto hanno caratteristiche meno spinte e si può investire meno nella ridondanza del singolo nodo (a differenza del costo della parte rete)
- Non c'è una SAN da acquistare e da manutenere
Conclusioni
"Non è tutto oro quel che luccica". Mi ha colpito la facilità con cui a caldo è possibile aumentare o diminuire il numero di dischi ed anche le repliche. Ma la sorpresa è stata amara quando abbiamo approfondito la parte di performance. La rete ad 1 Gbit NON è affatto sufficiente, le macchine sono troppo lente, le latenze estenuanti, hdparm restituiva un valore di circa 80MB/s su qualsiasi Pool (sia SATA sia SSD), quindi il nodo va veloce quanto la NIC dedicata alla parte storage, sempre e comunque meno di un FC o di un DAS. Questo comporta la necessità di salire come minimo a 10Gbit, con costi anche molto elevati. Da un punto di vista si risparmia sull'hardware dei nodi e della SAN, da un altro invece si spende sulla componente networking.
Nel frattempo ho ordinato 6 NIC a 10GbE ed uno switch Full 10Gbit (la ricerca costa! purtroppo solo il Cliente lungimirante comprende che gli esperimenti è meglio farli in laboratorio e non sulla sua pelle, e questo è incompatibile con una valutazione al massimo ribasso). Questo ci consentirà di fare dei test e capire se il livello di performance è accettabile, anche per applicazioni ad alto IO. Approfondiremo questa parte nel prossimo articolo, così come approfondiremo anche tutta la parte vmware vSAN.
Ultima nota: il FileSystem Distribuito consuma RAM e CPU, non poco, quindi i nodi devono essere dimensionati molto attentamente per non incorrere in freeze in caso di operazioni di riallineamento.
Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione, anche parziale, è vietata salvo autorizzazione.
