cephx
rados
ha esito negativo con un OSD pieno/var
In questo capitolo sono descritti i vari problemi che è possibile riscontrare durante il funzionamento di un cluster Ceph.
Se si riscontrano problemi durante l'esecuzione di SUSE Enterprise Storage 6 correlati ad alcuni dei suoi componenti, come Ceph o Object Gateway, segnalarli al supporto tecnico SUSE. L'utility consigliata per questa operazione è supportconfig
.
Poiché supportconfig
è un software modulare, assicurarsi che sia installato il pacchetto supportutils-plugin-ses
.
tux >
rpm -q supportutils-plugin-ses
Qualora mancasse sul server Ceph, installarlo con
root #
zypper ref && zypper in supportutils-plugin-ses
Sebbene sia possibile utilizzare supportconfig
sulla riga di comando, si consiglia di utilizzare il modulo YaST correlato. Ulteriori informazioni su supportconfig
sono disponibili in https://www.suse.com/documentation/sles-15/singlehtml/book_sle_admin/book_sle_admin.html#sec.admsupport.supportconfig (in lingua inglese).
rados
ha esito negativo con un OSD pieno #
rados
è un'utility da riga di comando che consente di gestire la memorizzazione di oggetti RADOS. Per ulteriori informazioni, vedere man 8 rados
.
Se si invia un oggetto di grandi dimensioni a un cluster Ceph con l'utility rados
, come
cephadm@adm >
rados -p mypool put myobject /file/to/send
è possibile che si riempia lo spazio OSD correlato compromettendo seriamente le prestazioni del cluster.
In rare circostanze come bug del kernel o hardware danneggiato/mal configurato, il file system sottostante (XFS) in cui un OSD memorizza i rispettivi dati potrebbe essere danneggiato o impossibile da montare.
Se si è certi del buon funzionamento dell'hardware e il sistema è configurato correttamente, segnalare un bug a fronte del sottosistema XFS del kernel di SUSE Linux Enterprise Server e contrassegnare l'OSD in questione come inattivo:
cephadm@adm >
ceph osd down OSD_ID
Sebbene l'utilizzo di xfs_repair
per correggere il problema nel file system possa sembrare una soluzione ragionevole, evitare di farlo in quanto con questo comando il file system viene modificato. È possibile avviare l'OSD ma il suo funzionamento potrebbe essere influenzato.
Adesso, cancellare il disco sottostante e ricreare l'OSD eseguendo:
cephadm@osd >
ceph-volume lvm zap --data /dev/OSD_DISK_DEVICEcephadm@osd >
ceph-volume lvm prepare --bluestore --data /dev/OSD_DISK_DEVICE
Se si riceve il messaggio Too Many PGs per OSD (Troppi gruppi di posizionamento per OSD)
dopo aver eseguito ceph status
, significa che il valore di mon_pg_warn_max_per_osd
(300 per default) è stato superato. Tale valore viene paragonato al rapporto del numero di gruppi di posizionamento per OSD. Vale a dire che la configurazione del cluster non è ottimale.
Una volta creato il pool, è impossibile ridurre il numero dei gruppi di posizionamento. È possibile eliminare tranquillamente i pool che ancora non contengono dati e ricrearli con un numero inferiore di gruppi di posizionamento. Laddove i pool contengono già dati, l'unica soluzione consiste nell'aggiungere OSD al cluster in modo che il rapporto dei gruppi di posizionamento per OSD scenda.
Se si riceve il messaggio di stato stuck inactive (bloccato inattivo)
dopo aver eseguito ceph status
, significa che Ceph non sa dove replicare i dati memorizzati per soddisfare le regole di replica. Questo problema può verificarsi subito dopo l'installazione iniziale di Ceph e viene corretto automaticamente. In altri casi, potrebbe essere necessaria un'iterazione manuale, come la riattivazione di un OSD interrotto o l'aggiunta di un nuovo OSD al cluster. In casi molto rari, potrebbe essere utile ridurre il livello di replica.
Se i gruppi di posizionamento sono bloccati per sempre, è necessario verificare l'output di ceph osd tree
. L'output deve presentare una struttura ad albero, simile all'esempio nella Sezione 27.7, «OSD inattivo».
Se l'output di ceph osd tree
è non gerarchico come nell'esempio seguente
cephadm@adm >
ceph osd tree
ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY
-1 0 root default
0 0 osd.0 up 1.00000 1.00000
1 0 osd.1 up 1.00000 1.00000
2 0 osd.2 up 1.00000 1.00000
Verificare che la mappa CRUSH correlata presenti una struttura ad albero. Se anch'essa è non gerarchica, o è priva di host come nell'esempio riportato sopra, può significare che la risoluzione del nome host non funzioni correttamente nel cluster.
Se la gerarchia è errata, ad esempio la radice contiene host ma gli OSD sono nel livello superiore e non sono assegnati automaticamente agli host, sarà necessario spostare gli OSD alla posizione corretta nella gerarchia. È possibile effettuare tale operazione utilizzando i comandi ceph osd crush move
e/o ceph osd crush set
. Per informazioni più dettagliate, vedere Sezione 9.5, «Modifica della mappa CRUSH».
All'avvio dell'OSD, a questo viene assegnato un peso. Più elevato è il peso, maggiori sono le possibilità che il cluster scriva dati nell'OSD. Il peso viene specificato in una mappa CRUSH del cluster o viene calcolato dallo script di avvio degli OSD.
In alcuni casi, il valore calcolato per il peso degli OSD può essere arrotondato a zero. Vale a dire che l'OSD non è pianificato per la memorizzazione dei dati e in esso non viene scritto alcun dato. Solitamente il motivo è dovuto alle dimensioni troppo piccole del disco (meno di 15 GB) che deve essere sostituito con uno più grande.
Il daemon dell'OSD è in esecuzione o interrotto/inattivo. Se un OSD è inattivo, i motivi generali possono essere tre:
Errore del disco rigido.
Crash dell'OSD.
Crash del server.
È possibile visualizzare lo stato dettagliato degli OSD eseguendo
cephadm@adm >
ceph osd tree
# id weight type name up/down reweight
-1 0.02998 root default
-2 0.009995 host doc-ceph1
0 0.009995 osd.0 up 1
-3 0.009995 host doc-ceph2
1 0.009995 osd.1 up 1
-4 0.009995 host doc-ceph3
2 0.009995 osd.2 down 1
Nell'elenco dell'esempio osd.2
risulta inattivo. Quindi si può verificare se il disco in cui risiede l'OSD è montato:
root #
lsblk -f
[...]
vdb
├─vdb1 /var/lib/ceph/osd/ceph-2
└─vdb2
È possibile controllare il motivo per cui l'OSD è inattivo esaminando il rispettivo file di log /var/log/ceph/ceph-osd.2.log
. Una volta rilevato e corretto il motivo per cui l'OSD non è in esecuzione, avviarlo con
root #
systemctl start ceph-osd@2.service
Non dimenticare di sostituire 2
con il numero effettivo dell'OSD che è stato interrotto.
Quando si ottimizzano le prestazioni del cluster, è molto importante identificare lo spazio di memorizzazione/gli OSD lenti all'interno del cluster. Il motivo di tale rallentamento è che se i dati vengono scritti nel disco (più) lento, l'operazione di scrittura completa rallenta poiché attende sempre che venga completata su tutti i dischi correlati.
Può essere utile individuare il collo di bottiglia nello spazio di memorizzazione. È necessario esaminare ogni singolo OSD per trovare quelli che rallentano il processo di scrittura. Per effettuare un benchmark su un singolo OSD, eseguire:
ceph tell
osd.OSD_ID_NUMBER bench
Ad esempio:
cephadm@adm >
ceph tell osd.0 bench
{ "bytes_written": 1073741824,
"blocksize": 4194304,
"bytes_per_sec": "19377779.000000"}
Quindi, è necessario eseguire questo comando su ciascun OSD e confrontare il valore bytes_per_sec
per ottenere gli OSD (più) lenti.
Le informazioni relative all'orario devono essere sincronizzate su tutti i nodi del cluster. Se l'orario di un nodo non è completamente sincronizzato, è possibile ricevere avvisi sullo sfasamento di orario quando si verifica lo stato del cluster.
La sincronizzazione dell'orario viene gestita con NTP (vedere http://en.wikipedia.org/wiki/Network_Time_Protocol). Impostare ciascun nodo per sincronizzarne l'orario con uno o più server NTP, preferibilmente sullo stesso gruppo di server NTP. Se lo sfasamento di orario persiste su un nodo, seguire la procedura indicata di seguito per correggerlo:
root #
systemctl stop chronyd.serviceroot #
systemctl stop ceph-mon.targetroot #
systemctl start chronyd.serviceroot #
systemctl start ceph-mon.target
È quindi possibile verificare la differenza di fuso orario con chronyc sourcestats
.
Gli orologi dei Ceph monitor devono essere sincronizzati con un margine di 0,05 secondi tra loro. Per ulteriori informazioni consultare Sezione 25.4, «Sincronizzazione dell'orario dei nodi».
Le prestazioni del cluster possono risultare scadenti a causa di vari motivi. Tra questi i problemi di rete. In tal caso, è possibile notare il raggiungimento del quorum da parte del cluster, nodi OSD e di monitoraggio offline, trasferimenti dei dati prolungati o numerosi tentativi di riconnessione.
Per verificare se le prestazioni del cluster vengono danneggiate da problemi di rete, esaminare i file di log Ceph nella directory /var/log/ceph
.
Per correggere problemi di rete sul cluster, focalizzarsi sui seguenti punti:
Diagnostica della rete di base. Provare lo strumento di esecuzione degli strumenti di diagnostica DeepSea net.ping
per effettuare il ping tra i nodi del cluster per verificare che l'interfaccia individuale sia in grado di raggiungere un'interfaccia specifica e il tempo di risposta medio. Verrà inoltre segnalato qualsiasi tempo di risposta specifico molto più lento di quello medio. Ad esempio:
root@master #
salt-run net.ping
Succeeded: 8 addresses from 7 minions average rtt 0.15 ms
Provare a convalidare tutta l'interfaccia con l'abilitazione per frame jumbo:
root@master #
salt-run net.jumbo_ping
Succeeded: 8 addresses from 7 minions average rtt 0.26 ms
Benchmark delle prestazioni di rete. Provare lo strumento di esecuzione delle prestazioni di rete DeepSea net.iperf
per testare la larghezza di banda della rete del nodo interno. In un determinato nodo del cluster, vengono avviati come server alcuni processi iperf
(in base al numero di core CPU). I nodi del cluster rimanenti verranno utilizzati come client per generare traffico di rete. Viene segnalata la larghezza di banda accumulata di tutti i processi iperf
per nodo. Ciò deve riflettere la velocità massima raggiungibile della rete effettiva su tutti i nodi del cluster. Ad esempio:
root@master #
salt-run net.iperf cluster=ceph output=full
192.168.128.1:
8644.0 Mbits/sec
192.168.128.2:
10360.0 Mbits/sec
192.168.128.3:
9336.0 Mbits/sec
192.168.128.4:
9588.56 Mbits/sec
192.168.128.5:
10187.0 Mbits/sec
192.168.128.6:
10465.0 Mbits/sec
Verificare le impostazioni firewall sui nodi del cluster. Assicurarsi che non blocchino le porte/i protocolli richiesti per il funzionamento di Ceph. Per ulteriori informazioni sulle impostazioni firewall, vedere Sezione 25.9, «Impostazioni firewall per Ceph».
Verificare che l'hardware di rete, come le schede di rete, i cavi o i commutatori, funzioni correttamente.
Per garantire una comunicazione di rete veloce e sicura tra i nodi del cluster, configurare una rete separata utilizzata esclusivamente dai nodi OSD e di monitoraggio del cluster.
/var
#
Per default, il Salt master salva ogni restituzione dei minion per ciascun lavoro nella rispettiva cache dei lavori. È quindi possibile utilizzare la cache in un momento successivo per ricercare i risultati dei lavori precedenti. Il percorso predefinito della directory della cache è /var/cache/salt/master/jobs/
.
Ciascun lavoro restituito da ogni minion viene salvato in un singolo file. Nel tempo questa directory può raggiungere dimensioni molto grandi, a seconda del numero di lavori pubblicati e del valore dell'opzione keep_jobs
nel file /etc/salt/master
. L'opzione keep_jobs
consente di definire il numero di ore (24 per default) per le quali conservare le informazioni sui lavori dei minion precedenti.
keep_jobs: 24
keep_jobs: 0
Se si imposta keep_jobs
su "0", la pulizia della cache dei lavori non verrà eseguita mai, con il possibile risultato di una partizione piena.
Se si desidera disabilitare la cache dei lavori, impostare job_cache
su "False":
job_cache: False
Quando la partizione con i file di cache dei lavori si riempie a causa dell'impostazione keep_jobs
errata, seguire la procedura indicata di seguito per liberare spazio su disco e migliorare le impostazioni della cache dei lavori:
Interrompere il servizio Salt master:
root@master #
systemctl stop salt-master
Modificare la configurazione di Salt correlata alla cache dei lavori modificando /etc/salt/master
:
job_cache: False keep_jobs: 1
Svuotare la cache dei lavori Salt master:
root #
rm -rfv /var/cache/salt/master/jobs/*
Avviare il servizio Salt master:
root@master #
systemctl start salt-master