Con il crescente interesse per Rook, vogliamo discutere delle sue problematiche e difficoltà che potreste incontrare lungo il cammino.
Chi sono: 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 il punteggio) riguardo ai problemi con Ceph. Ho incontrato anche la maggior parte di questi problemi. I collegamenti ai materiali utilizzati sono alla fine del post.
Nel post su Rook menzioniamo Ceph non casualmente: Rook è fondamentalmente Ceph avvolto in Kubernetes, pertanto eredita tutti i suoi problemi. Iniziamo con i problemi di Ceph.
Semplificazione della gestione del cluster
Uno dei vantaggi di Rook è la comodità di gestione di Ceph tramite Kubernetes.
Tuttavia, Ceph contiene oltre 1000 parametri di configurazione, mentre tramite Rook possiamo modificare solo una parte di essi.
Esempio su Luminous
> ceph daemon mon.a config show | wc -l
1401
Rook si presenta come un modo semplice per installare e aggiornare Ceph
Con l'installazione di Ceph senza Rook non ci sono problemi: un playbook Ansible si scrive in 30 minuti, mentre per l'aggiornamento ci sono molte problematiche.
Citazione dal post di Krok
Esempio: comportamento errato delle tunabilità CRUSH dopo l'aggiornamento da Hammer 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 in uno stato health err e PG potenzialmente danneggiato
Non aggiornarsi, aspettare e testare? Ma lo utilizziamo Rook anche per semplificare gli aggiornamenti.
Difficoltà nel disaster recovery del cluster in Rook
Esempio: OSD si arresta con errori. Suspect che il problema sia in uno dei parametri nel file di configurazione, desideri cambiare la configurazione per un demone specifico, ma non puoi, perché hai Kubernetes e DaemonSet.
Non c'è alternativa. ceph tell osd.Num injectargs non funziona: l'OSD è down.
Difficoltà nel debug
Per alcune impostazioni e test di prestazioni è necessario accedere direttamente al socket del demone OSD. Nel caso di Rook, devi prima trovare il contenitore giusto, poi accedervi, scoprire che il tooling per il debug è assente e rimanere molto deluso.
Difficoltà nel sollevamento sequenziale degli OSD
Esempio: OSD si arresta per OOM, inizia il bilanciamento, dopo di che si bloccano i successivi.
Soluzione: Sollevare un OSD alla volta, aspettare che sia completamente attivato nel cluster e sollevare i successivi. (Maggiore dettaglio nel report Ceph. Anatomia di un disastro).
Nel caso di installazioni bare metal, questo è semplice da fare manualmente; nel caso di Rook e un OSD per nodo, non ci sono particolari problemi; i problemi si presenteranno se OSD > 1 per nodo.
Certo, sono risolvibili, ma stiamo portando Rook per semplificare, e invece ci ritroviamo con complicazioni.
Difficoltà nel determinare i limiti per i demoni Ceph
Per le installazioni bare metal, è relativamente semplice calcolare le risorse necessarie per il cluster — ci sono formule e ricerche a riguardo. Tuttavia, utilizzando CPU deboli, dovrai comunque condurre vari test di prestazioni e comprendere cos'è Numa; ma è comunque più semplice rispetto a Rook.
Nel caso di Rook, oltre ai limiti di memoria, che possono essere calcolati, sorge la questione della definizione del limite CPU.
E lì dovrai faticare con i test di prestazioni. Se imposti limiti troppo bassi ottieni un cluster lento, mentre se imposti limiti illimitati, avrai un utilizzo attivo della CPU durante il bilanciamento, il che influirà negativamente sulle tue applicazioni in Kubernetes.
Problemi di interazione di rete v1
Per Ceph si consiglia di utilizzare una rete di 2x10Gb. Una per il traffico dei clienti e l'altra per le esigenze di Ceph (bilanciamento). Se stai eseguendo Ceph su bare metal, questa separazione è facile da configurare; se stai usando Rook, la separazione delle reti ti causerà problemi poiché non tutti i cluster supportano la connessione di due diverse reti ai pod.
Problemi di 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 inizieranno a rallentare o potrebbero bloccarsi. Puoi ridurre la velocità di bilanciamento di Ceph, ma così facendo, con un bilanciamento prolungato, aumenta il rischio che il secondo nodo esca dal cluster a causa dei dischi o OOM, e lì avrai un cluster in modalità di sola lettura garantita.
Bilanciamento lungo — placcaggio lento delle applicazioni
Citazione dal post Ceph. Anatomia di un disastro.
Prestazioni del cluster di test:
Un'operazione di scrittura di 4 KB richiede 1 ms, con una prestazione di 1000 operazioni al secondo in 1 thread.
Un'operazione di 4 MB (dimensione dell'oggetto) richiede 22 ms, con una prestazione di 45 operazioni al secondo.
Di conseguenza, quando un dominio su tre fallisce, il cluster si trova temporaneamente 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 oggetti degradati.
Inizialmente leggiamo 4 MB in 22 ms, scriviamo 22 ms, e poi in 1 ms scriviamo 4 KB di dati veri e propri. In totale, ci vogliono 45 ms per un'operazione di scrittura su un oggetto degradato su SSD, mentre la performance standard era di 1 ms - un calo delle prestazioni di 45 volte.
Maggiore è la percentuale di oggetti degradati, peggiore diventa la situazione.
Quindi, la velocità di bilanciamento è critica per il corretto funzionamento del cluster.
Impostazioni specifiche del server per ceph
Ceph richiede un tuning specifico dell'host.
Esempio: impostazioni sysctl e JumboFrame, alcune di queste impostazioni possono avere un impatto negativo sul tuo payload.
La reale necessità di Rook rimane in discussione
Se sei nel cloud hai uno storage dal tuo fornitore cloud, che è molto più conveniente.
Se sei sui tuoi server, gestire ceph sarà più comodo senza Kubernetes.
Affitti server in qualche hosting a basso costo? Allora ti aspetta molto divertimento con la rete, i suoi ritardi e la larghezza di banda, che influisce negativamente su ceph.
In totale: L'implementazione di Kubernetes e l'implementazione dello storage sono compiti diversi con diverse premesse e diverse soluzioni - mescolarli significa fare un potenziale trade-off rischioso a favore di uno o dell'altro. Combinare queste soluzioni sarà molto difficile anche nella fase di progettazione, e c'è anche il periodo di sfruttamento.
Elenco delle fonti utilizzate:
Ma tu dici Ceph… è davvero così buono?
Ceph. Anatomia di un disastro
Fonte: habr.com
