Sono un grande fan di Ceph, la soluzione di software-defined storage open-source e massicciamente scalabile. La sua capacità di auto-guarigione e di far fronte a eventi di cluster altrimenti traumatici (oh, hai perso un nodo? nessun problema!), combinata con la sua mancanza di singoli punti di fallimento, lo rende uno dei miei preferiti.
Di seguito sono riportati tre semplici principi che possono aiutare a guidare la progettazione di cluster grandi o piccoli.
Se il tuo obiettivo principale sono i dollari per megabyte di memoria, allora naturalmente potresti gravitare verso i server che possono prendere il maggior numero di dischi, e i dischi più grandi che puoi ottenere.
Fate attenzione qui. Ci sono alcune considerazioni sui cluster “stretti e profondi”:
- Ogni nodo contiene una percentuale maggiore dei dati del tuo cluster. Esempio: in un cluster a tre nodi ogni nodo contiene il 33% dei dati. In un cluster di dieci nodi, è solo il 10% per nodo. La perdita di un singolo nodo in un piccolo cluster comporterà una migrazione di dati sostanzialmente maggiore, in particolare quando il cluster inizia a riempirsi, e potenzialmente un’interruzione se non avete configurato correttamente i rapporti pieni e quasi pieni del vostro cluster.
- Forzare più traffico di rete su meno nodi. Ceph è un sistema di storage basato sulla rete, quindi con meno nodi stai forzando un sacco di traffico client su un minor numero di NIC. Questo peggiora con l’aumento del numero di dischi per nodo, poiché si hanno più OSD che competono per una larghezza di banda limitata. Peggio ancora, durante gli eventi di recupero il tuo traffico di recupero compete con l’I/O del client sulla tua rete, impattando ulteriormente l’esperienza dell’utente.
- Per alti numeri di dischi per nodo, il controller del disco può essere un collo di bottiglia se non ha sufficiente larghezza di banda per trasportare tutti i tuoi dischi a piena velocità.
- Il tempo di recupero e di guarigione aumenta quando si perde un intero nodo, poiché più dati devono essere replicati e recuperati.
Le prestazioni del cluster aggregato scalano molto bene all’aumentare del numero di nodi. Qui puoi trovare un confronto tra un cluster a 3 nodi e uno a 5 nodi con BlueStore.
Se stai puntando a un grande cluster, resisti alla tentazione di impacchettare tutti i dischi nel minor numero di nodi possibile.
Per riassumere:
- Ceph scala molto bene all’aumentare del numero di nodi.
- Avere troppo pochi nodi nel cluster pone più dati del vostro cluster su ogni nodo, aumentando l’I/O e i tempi di recupero.
- Si può iniziare con un minimo di tre nodi, ma se ci si può permettere di distribuire i dischi su più nodi, è meglio farlo.
Essere generosi con la rete
Non ha senso mettere supporti veloci in un server e poi ostacolarli con una connessione di rete da 1GbE. Puntate a 10GbE per la produzione, come minimo, e meglio ancora cercate di avere più interfacce da 10Gb collegate con Link Aggregation Control Protocol (LACP) per aumentare la larghezza di banda. Ceph è un sistema di storage basato sulla rete, quindi una cosa che non dovrebbe mancare al cluster è la larghezza di banda della rete.
Separate sempre la rete pubblica dalla rete interna del cluster. La rete pubblica trasporterà il traffico client, mentre la rete interna trasporterà il traffico di heartbeat, replica e ripristino tra gli OSD. Se puoi risparmiare le NIC, porta queste due reti su interfacce separate. Separarle migliora la reattività per i client durante gli eventi di recupero, e aiuta gli eventi di recupero a completarsi più velocemente poiché l’I/O di recupero non compete con l’I/O del client sulla stessa NIC.
Ricorda anche che la rete interna trasporta il tuo traffico di replica, quindi ogni scrittura sulla rete pubblica causerà (n-1) scritture sulla rete interna, dove n è il numero di repliche. Ceph riconoscerà una scrittura al client solo quando è stata scritta nel journal/WAL di tutte le repliche – quindi non si vuole che le scritture di replica abbiano un collo di bottiglia sulla rete. Se stai facendo un uso pesante di pool replicati, considera di dimensionare la tua rete di cluster per essere n-1 volte più grande della rete pubblica.
Infine, per la ridondanza assicurati di cablare i tuoi nodi a switch top of rack ridondanti. Non vuoi perdere un intero nodo – o un insieme di nodi – perché un singolo switch è fallito!
Per riassumere:
- 10Gbit Ethernet per la produzione come minimo.
- Separate la vostra rete pubblica e quella del cluster, idealmente su NIC diverse ma almeno in VLAN/sottoreti diverse.
- Ricordate la regola (n-1) per i dati replicati – considerate di dimensionare la vostra rete interna per essere n-1 volte più grande di quella pubblica.
- Non dimenticate di cablare per la ridondanza, e di stabilire correttamente i vostri legami a livello di sistema operativo.
- E come extra: non dimenticate i jumbo frames sulle vostre interfacce!
Media flash per i metadati BlueStore.
Ceph riconosce una scrittura al client solo dopo che i dati sono stati scritti nel write-ahead log (WAL) dell’OSD primario e nei WAL di tutte le repliche. Quindi, più veloce è la scrittura sul WAL, più velocemente Ceph riconoscerà la scrittura, e migliori saranno le IOPS di scrittura per il client.
I tuoi WAL, e idealmente i tuoi metadati BlueStore RocksDB, dovrebbero essere sui supporti più veloci che puoi ottenere – SSD come minimo, e NVMe se possibile. Se stai costruendo un cluster full-HDD, considera fortemente di spendere un po’ di più per nodo e aggiungere almeno due dispositivi multimediali veloci per metadati e WAL.
Per evitare colli di bottiglia sul tuo dispositivo multimediale veloce considera la velocità di scrittura sostenuta dei tuoi dischi dati e confrontala con la scrittura sostenuta del tuo dispositivo veloce. Se il vostro HDD può scrivere a 100MB/s sostenuti, e il vostro SSD può gestire 500MB/s sostenuti, allora più di 4-5 OSD per SSD e sarete strozzati dall’SSD per le scritture. NVMe è perfetto per questo caso d’uso, dato che la loro velocità di scrittura sostenuta può raggiungere i gigabyte al secondo.
Infine, avere sempre più di un dispositivo SSD/NVMe per nodo per metadati/WAL per assicurarsi di non perdere tutti gli OSD sul nodo se un dispositivo di metadati fallisce.
Per riassumere:
- Ceph riconosce una scrittura ad un client quando è stata scritta nel WAL dell’OSD primario e nei WAL di tutte le repliche. Lo fa per preservare l’integrità dei tuoi dati.
- WAL e RocksDB dovrebbero essere sui supporti più veloci che puoi ottenere – idealmente NVMe – per ottenere una risposta al client il più velocemente possibile.
- Non sovrascrivere i tuoi dispositivi veloci per il tuo WAL/RocksDB. Se lo fai, stai solo spostando il collo di bottiglia sul tuo dispositivo veloce.
- Avere più di un dispositivo veloce per evitare di perdere tutti gli OSD su un nodo se il tuo dispositivo WAL fallisce.
Sommando
Ceph è un sistema di storage software-defined basato sulla rete che scala orizzontalmente in modo eccezionale. Qui sopra ci sono solo alcuni principi per aiutarvi a mettere insieme un sistema ad alte prestazioni – non andare troppo stretto o profondo, mantenere il cluster alimentato con la larghezza di banda, e utilizzare supporti veloci per i vostri metadati e WAL.