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.

Suggerimento

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 è 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

Avviso: non formattare, né modificare il dispositivo danneggiato

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_DEVICE
cephadm@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:

È 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.service
root # systemctl stop ceph-mon.target
root # systemctl start chronyd.service
root # 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:

Suggerimento: rete separata

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.

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

Importante: non impostare 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

Suggerimento: ripristino della partizione piena a causa della cache dei lavori

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:

1. Interrompere il servizio Salt master:

   root@master # systemctl stop salt-master

2. Modificare la configurazione di Salt correlata alla cache dei lavori modificando /etc/salt/master:

   job_cache: False
   keep_jobs: 1

3. Svuotare la cache dei lavori Salt master:

   root # rm -rfv /var/cache/salt/master/jobs/*

4. Avviare il servizio Salt master:

   root@master # systemctl start salt-master