Con l'aumento della popolarità di Rook, voglio parlare delle sue insidie e dei problemi che vi attendono lungo il cammino.
Su di me: Esperienza nella gestione di ceph dalla versione hammer, fondatore della community. su telegram.
Per non essere vago, farò riferimento ai post accettati da Habr (secondo la valutazione) riguardo ai problemi con ceph. Ho anche affrontato la maggior parte dei problemi menzionati in questi post. I link ai materiali utilizzati alla fine del post.
Nel post su Rook, menzioniamo ceph non per caso: Rook è essenzialmente ceph avvolto in kubernetes, quindi eredita tutti i suoi problemi. Iniziamo con i problemi di ceph.
Semplificazione della gestione del cluster
Uno dei vantaggi di Rook è la facilità di gestione di ceph tramite kubernetes.
Tuttavia, ceph contiene oltre 1000 parametri di configurazione, mentre tramite rook possiamo modificare solo una parte minore di essi.
Esempio su Luminous
> ceph daemon mon.a config show | wc -l
1401
Rook è posizionato come un modo conveniente per installare e aggiornare ceph.
Non ci sono problemi nell'installare ceph senza Rook: un playbook ansible si scrive in 30 minuti, mentre l'aggiornamento presenta molte difficoltà.
Citazione dal post di Krok
Esempio: comportamento errato dei tunables crush dopo l'aggiornamento da hummer a jewel.
> ceph osd crush show-tunables
{
…
"straw_calc_version": 1,
"allowed_bucket_algs": 22,
"profile": "unknown",
"optimal_tunables": 0,
…
}
Ma anche all'interno delle versioni minori ci possono essere problemi.
Esempio: Aggiornamento 12.2.6 che porta il cluster a uno stato di health err e PG teoricamente danneggiato.
Non aggiornare, attendere e testare? Ma stiamo usando Rook proprio per la comodità degli aggiornamenti.
Difficoltà nel disaster recovery del cluster in Rook
Esempio: OSD si arresta con errori che si presentano continuamente. Sospettate che il problema sia in uno dei parametri della configurazione, volete modificare la configurazione per un demone specifico, ma non potete, perché avete kubernetes e DaemonSet.
Non ci sono alternative. ceph tell osd.Num injectargs non funziona: l'OSD è inattivo.
Difficoltà di debug
Per alcune impostazioni e test delle performance è necessario collegarsi direttamente alla socket del demone osd. Nel caso di Rook, è necessario prima trovare il container giusto, poi accedervi, scoprire che il tool di debug è assente e rimanere molto delusi.
Difficoltà nel sollevare OSD in sequenza
Esempio: OSD si arresta per OOM, inizia il ribalancing, e successivamente si arrestano i successivi.
Soluzione: Alzare l'OSD uno alla volta, attendere il suo completo avvio nel cluster e sollevare il successivo. (Maggiori dettagli nel report Ceph. Anatomia dei disastri).
Nel caso di installazioni baremetal, questo si fa facilmente a mano; nel caso di Rook con un OSD per nodo, non ci sono particolari problemi, mentre sorgeranno problemi di avvio sequenziale se OSD > 1 per nodo.
Certo, sono risolvibili, ma noi portiamo Rook per semplificare e otteniamo complicazioni.
Difficoltà nella definizione dei limiti per i demoni ceph.
Per l'installazione baremetal di ceph è abbastanza facile calcolare le risorse necessarie per il cluster: ci sono formule e ricerche disponibili. Con CPU deboli, dovrai comunque eseguire una serie di test delle prestazioni e comprendere cosa significhi Numa, ma è comunque più semplice rispetto a Rook.
Nel caso di Rook, oltre ai limiti di memoria che possono essere calcolati, sorgerebbe il problema di impostare il limite CPU.
E qui dovrai sudare con i test delle prestazioni. In caso di limiti sottovalutati, avrai un cluster lento; se imposti un limite illimitato, sperimenterai un utilizzo intenso della CPU durante il bilanciamento, il che influirà negativamente sulle tue applicazioni in Kubernetes.
Problemi con l'interazione di rete v1.
Per ceph, si raccomanda di utilizzare una rete 2x10Gb. Una per il traffico client e l'altra per le necessità di servizio di ceph (bilanciamento). Se vivi con ceph su baremetal, questa separazione è facile da configurare; se utilizzi Rook, la separazione delle reti potrebbe causarti problemi, poiché non tutti i config dei cluster consentono di presentare al pod due reti diverse.
Problemi con l'interazione di rete v2.
Se decidi di non separare le reti, durante il bilanciamento il traffico ceph saturerà l'intero canale e le tue applicazioni in Kubernetes rallenteranno o potrebbero andare in crash. Puoi ridurre la velocità di bilanciamento di ceph, ma in questo modo, a causa di un lungo bilanciamento, aumenti il rischio che il secondo nodo esca dal cluster a causa di problemi con i dischi o OOM, il che porta a un accesso garantito in sola lettura sul cluster.
Bilanciamento lungo — lunghe attese per le applicazioni.
Citazione dal post Ceph. Anatomia dei disastri.
Prestazioni del cluster di test:
Un'operazione di scrittura di 4 KByte richiede 1 ms, con una capacità di 1000 operazioni al secondo in 1 thread.
Un'operazione di 4 MByte (dimensione dell'oggetto) richiede 22 ms, con una capacità di 45 operazioni al secondo.
Pertanto, quando uno dei tre domini fallisce, il cluster rimane per un certo tempo in uno stato degradato, e metà degli oggetti caldi si distribuisce su diverse versioni, quindi metà delle operazioni di scrittura inizierà con un ripristino forzato.
Il tempo di ripristino forzato viene calcolato approssimativamente: operazioni di scrittura su un oggetto degradato.
Prima leggiamo 4 MB in 22 ms, scriviamo in 22 ms e poi in 1 ms scriviamo 4 KB di dati propri. In totale, 45 ms per un'operazione di scrittura su un oggetto degradato su SSD, quando la prestazione standard era di 1 ms: un calo delle prestazioni di 45 volte.
Più alto è il nostro percentuale di oggetti degradati, più la situazione diventa critica.
Dunque, la velocità di bilanciamento è estremamente importante per il corretto funzionamento del cluster.
Impostazioni specifiche dei server per ceph
ceph potrebbe necessitare di una specifica ottimizzazione dell'host.
Esempio: impostazioni sysctl e lo stesso JumboFrame, alcune di queste impostazioni possono influenzare negativamente il vostro payload.
La reale necessità di Rook rimane in discussione
Se siete nel cloud, avete uno storage dal vostro fornitore di cloud, il che è decisamente più comodo.
Se siete sui vostri server, la gestione di ceph sarà più semplice senza kubernetes.
State affittando server in un hosting a basso costo? Allora vi aspettano molte sfide con la rete, le sue latenze e la larghezza di banda, che influiscono negativamente su ceph.
In totale: L'implementazione di kubernetes e l'implementazione dello storage sono compiti diversi con vari input e diverse opzioni di soluzione: mescolarli significa fare un potenziale trade-off rischioso a favore dell'uno o dell'altro. Combinare queste soluzioni sarà molto difficile anche in fase di progettazione, e c'è anche un periodo di esercizio.
Elenco della letteratura utilizzata:
Ma voi dite Ceph… è davvero così buono?
Ceph. Anatomia di un disastro
Fonte: habr.com
