Per eseguire il login al Ceph Dashboard, puntare il browser verso il relativo URL includendo il numero di porta. Eseguire il comando seguente per trovare l'indirizzo:

cephuser@adm > ceph mgr services | grep dashboard
"dashboard": "https://host:port/",

Il comando restituisce l'URL su cui si trova il Ceph Dashboard. In caso di problemi con questo comando, vedere Book “Troubleshooting Guide”, Chapter 10 “Troubleshooting the Ceph Dashboard”, Section 10.1 “Locating the Ceph Dashboard”.

Figura 2.1: Schermata di login del Ceph Dashboard #

 

Eseguire il login con le credenziali create durante la distribuzione del cluster (vedere Book “Guida alla distribuzione”, Chapter 7 “Distribuzione del cluster di bootstrap mediante ceph-salt”, Section 7.2.9 “Configurazione delle credenziali di login del Ceph Dashboard”).

Suggerimento: account utente personalizzato

Se non si desidera utilizzare l'account admin di default per accedere al Ceph Dashboard, creare un account utente personalizzato con privilegi di amministratore. Per ulteriori dettagli, fare riferimento a Capitolo 11, Gestione di utenti e ruoli sulla riga di comando.

Importante

Non appena è disponibile un upgrade a una nuova versione principale di Ceph (nome in codice: Pacific), il Ceph Dashboard visualizza uno specifico messaggio nell'area di notifica superiore. Per eseguire l'upgrade, seguire le istruzioni indicate in Book “Guida alla distribuzione”, Chapter 11 “Upgrade da SUSE Enterprise Storage 7 a 7.1”.

Figura 2.2: Notifica di una nuova versione di SUSE Enterprise Storage #

 

L'interfaccia utente del dashboard è graficamente suddivisa in più blocchi: il menu dell'utility in alto a destra sulla schermata, il menu principale a sinistra e il pannello dei contenuti principale.

Figura 2.3: Home page del Ceph Dashboard #

 

Il menu dell'utility occupa il lato superiore destro della schermata e include i task generali correlati più al dashboard che al cluster Ceph. Facendo clic sulle opzioni, è possibile:

Il menu principale del dashboard occupa il lato superiore sinistro della schermata e copre gli argomenti seguenti:

Il pannello dei contenuti occupa la parte principale della schermata del dashboard. Nella home page del dashboard sono mostrati molti widget utili con informazioni sintetiche sullo stato corrente del cluster, sulla capacità e sulle prestazioni.

Spesso nel Ceph Dashboard si utilizzano elenchi: ad esempio, elenchi di pool, nodi OSD o dispositivi RBD. Tutti gli elenchi si aggiornano automaticamente per default ogni cinque secondi. I seguenti widget comuni consentono di gestire o regolare tali elenchi:

Fare clic su per attivare un aggiornamento manuale dell'elenco.

Fare clic su per visualizzare o nascondere colonne della tabella individuali.

Fare clic su e immettere (o selezionare) il numero di righe da visualizzare in un'unica pagina.

Fare clic all'interno di e filtrare le righe digitando la stringa da ricercare.

Utilizzare per modificare la pagina attualmente visualizzata se l'elenco è distribuito su più pagine.

Ogni widget del dashboard mostra specifiche informazioni sullo stato relative a un determinato aspetto di un cluster Ceph in esecuzione. Alcuni widget sono collegamenti attivi che, dopo essere stati selezionati, reindirizzano l'utente a una pagina dettagliata dell'argomento a cui fanno riferimento.

Suggerimento: ulteriori dettagli sul passaggio del mouse

Passando il mouse sopra alcuni widget grafici, è possibile visualizzare ulteriori dettagli.

2.6.1 Widget Stato #

 

I widget Stato forniscono una breve panoramica sullo stato corrente del cluster.

Figura 2.4: Widget Stato #

 

Stato del cluster

Mostra le informazioni di base sullo stato del cluster.

Host

Mostra il numero totale di nodi del cluster.

Monitor

Mostra il numero di monitor in esecuzione e il relativo quorum.

OSD

Mostra il numero totale di OSD, oltre al numero di OSD negli stati up e in.

Manager

Mostra il numero di Ceph Manager Daemon attivi e in standby.

Object Gateway

Mostra il numero di Object Gateway in esecuzione.

Server di metadati

Mostra il numero di server di metadati.

iSCSI Gateway

Mostra il numero di iSCSI Gateway configurati.

2.6.2 Widget Capacità #

 

I widget Capacità mostrano brevi informazioni sulla capacità di storage.

Figura 2.5: Widget Capacità #

 

Capacità di base

Mostra il rapporto tra la capacità di storage nominale disponibile e quella utilizzata.

Oggetti

Mostra il numero di oggetti dati memorizzati nel cluster.

Stato gruppo di posizionamento

Visualizza un grafico dei gruppi di posizionamento in base al relativo stato.

Pool

Mostra il numero di pool nel cluster.

Gruppi di posizionamento per OSD

Mostra il numero medio di gruppi di posizionamento per OSD.

2.6.3 Widget Prestazioni #

 

I widget Prestazioni fanno riferimento ai dati di base sulle prestazioni dei client Ceph.

Figura 2.6: Widget prestazioni #

 

Lettura/scrittura client

Numero di operazioni di lettura e scrittura dei client al secondo.

Velocità effettiva client

Quantità in byte al secondo di dati trasferiti ai e dai client Ceph.

Velocità effettiva di recupero

Velocità effettiva dei dati recuperati al secondo.

Pulitura

Mostra lo stato della pulitura (vedere la Sezione 17.4.9, «Pulitura di un gruppo di posizionamento»). Lo stato può essere inactive, enabled o active (inattivo, abilitato o attivo).

Fare clic su nel menu dell'utility e selezionare Gestione utenti.

L'elenco contiene il nome utente, il nome completo, l'indirizzo e-mail, un elenco dei ruoli assegnati, le informazioni sullo stato di abilitazione del ruolo e la data di scadenza della password di ciascun utente.

Figura 3.1: Gestione utenti #

 

Fare clic su Crea in alto a sinistra nell'intestazione della tabella per aggiungere un nuovo utente. Immettere il nome utente e la password e facoltativamente il nome completo e l'e-mail.

Figura 3.2: Aggiunta di un utente #

 

Selezionare l'icona a forma di penna per assegnare i ruoli predefiniti all'utente. Confermare con Crea utente.

Fare clic sulla riga di tabella corrispondente a un utente per evidenziarla. Selezionare Modifica per modificare i dettagli relativi all'utente. Confermare con Modifica utente.

Fare clic sulla riga di tabella corrispondente a un utente per evidenziarla. Selezionare la casella a discesa accanto a Modifica e selezionare Elimina dall'elenco per eliminare l'account utente. Attivare la casella di controllo Sì e confermare con Elimina utente.

Fare clic su nel menu dell'utility e selezionare Gestione utenti. Quindi, fare clic sulla scheda Ruoli.

L'elenco contiene il nome e la descrizione di ciascun ruolo e indica se si tratta di un ruolo di sistema.

Figura 3.3: Ruoli dell'utente #

 

Fare clic su Crea in alto a sinistra nell'intestazione della tabella per aggiungere un nuovo ruolo personalizzato. Immettere il nome e la descrizione e, accanto ad Autorizzazioni, selezionare le autorizzazioni appropriate.

Suggerimento: eliminazione definitiva dei ruoli personalizzati

Se si creano ruoli dell'utente personalizzati e si intende rimuovere il cluster Ceph con il comando ceph-salt purge in un secondo momento, è necessario innanzitutto eliminare definitivamente i ruoli personalizzati. Ulteriori dettagli sono disponibili nella Sezione 13.9, «Rimozione dell'intero cluster Ceph».

Figura 3.4: Aggiunta di un ruolo #

 

Suggerimento: attivazione multipla

Tramite l'attivazione della casella di controllo accanto al nome dell'argomento, si attivano tutte le autorizzazioni correlate a quest'ultimo. Se si attiva la casella di controllo Tutto, si attivano tutte le autorizzazioni correlate a tutti gli argomenti.

Confermare con Crea ruolo.

Fare clic sulla riga di tabella corrispondente a un utente per evidenziarla. Selezionare Modifica in alto a sinistra nell'intestazione della tabella per modificare la descrizione e le autorizzazioni di un ruolo personalizzato. Confermare con Modifica ruolo.

Fare clic sulla riga di tabella corrispondente a un ruolo per evidenziarla. Selezionare la casella a discesa accanto a Modifica e selezionare Elimina dall'elenco per eliminare il ruolo. Attivare la casella di controllo Sì e confermare con Elimina ruolo.

Fare clic su Cluster › Host per visualizzare un elenco dei nodi del cluster.

Figura 4.1: Hosts #

 

Fare clic sulla freccia a discesa accanto al nome di un nodo nella colonna Nome host per visualizzare i dettagli sulle prestazioni del nodo.

Nella colonna Servizi sono elencati tutti i daemon in esecuzione in ogni nodo correlato. Fare clic sul nome di un daemon per visualizzare la relativa configurazione dettagliata.

Fare clic su Cluster › Inventario per visualizzare un elenco dei dispositivi. L'elenco riporta il percorso, il tipo, la disponibilità, il produttore, il modello, la dimensione e gli OSD del dispositivo.

Fare clic per selezionare il nome di un nodo nella colonna Nome host. Quindi, fare clic su Identifica per identificare il dispositivo su cui è in esecuzione l'host. Questa operazione invia al dispositivo l'istruzione di far lampeggiare i LED. Selezionare la durata di questa azione su 1, 2, 5, 10 o 15 minuti. Fare clic su Esegui.

Figura 4.2: servizi #

 

Fare clic su Cluster › Monitor per visualizzare un elenco dei nodi del cluster con Ceph Monitor in esecuzione. Il pannello dei contenuti è suddiviso in due viste: Stato e Nel quorum o Non nel quorum.

Nella tabella Stato sono riportate le statistiche generali relative ai Ceph Monitor in esecuzione, inclusi:

I pannelli Nel quorum e Non nel quorum includono il nome, la classificazione, il numero, l'indirizzo IP pubblico e il numero di sessioni aperte di ogni monitor.

Fare clic sul nome di un nodo nella colonna Nome per visualizzare la configurazione del Ceph Monitor correlato.

Figura 4.3: Ceph Monitor #

 

Fare clic su Cluster › Servizi per visualizzare i dettagli su ciascuno dei servizi disponibili: crash, Ceph Manager e Ceph Monitor. L'elenco include il nome dell'immagine del container, l'ID dell'immagine del container, lo stato degli elementi in esecuzione, la dimensione e l'ultimo aggiornamento.

Fare clic sulla freccia a discesa accanto al nome di un servizio nella colonna Servizio per visualizzare i dettagli sul daemon. Nell'elenco dei dettagli sono inclusi il nome host, il tipo di daemon, l'ID del daemon, l'ID del container, il nome dell'immagine del container, l'ID dell'immagine del container, il numero di versione, lo stato e l'ultimo aggiornamento.

Figura 4.4: servizi #

 

Fare clic su Cluster › OSD per visualizzare un elenco dei nodi con daemon OSD in esecuzione. Nell'elenco sono inclusi il nome, l'ID, lo stato, la classe del dispositivo, il numero di gruppi di posizionamento, le dimensioni, l'utilizzo, il grafico delle operazioni di lettura/scrittura nel tempo e la frequenza delle operazioni di lettura/scrittura al secondo di ogni nodo.

Figura 4.5: Ceph OSD #

 

Selezionare Flag dal menu a discesa Configurazione a livello di cluster nell'intestazione della tabella per aprire una finestra popup contenente un elenco dei flag che si applicano all'intero cluster. È possibile attivare o disattivare i singoli flag e confermare con Invia.

Figura 4.6: Flag OSD #

 

Selezionare Priorità di recupero dal menu a discesa Configurazione a livello di cluster nell'intestazione della tabella per aprire una finestra popup contenente un elenco delle priorità di recupero OSD che si applicano all'intero cluster. È possibile attivare il profilo di priorità preferito e ottimizzare i singoli valori di seguito. Confermare con Invia.

Figura 4.7: Priorità di recupero OSD #

 

Fare clic sulla freccia a discesa accanto al nome di un nodo nella colonna Host per visualizzare una tabella estesa con i dettagli sulle impostazioni e le prestazioni del dispositivo. Sfogliando le diverse schede, è possibile visualizzare gli elenchi Attributi, Metadati, Integrità dispositivo, Contatore delle prestazioni, un Istogramma delle operazioni di lettura e scrittura e Dettagli sulle prestazioni.

Figura 4.8: Dettagli OSD #

 

Suggerimento: esecuzione di task specifici sugli OSD

Dopo aver fatto clic sul nome di un nodo OSD, la riga della tabella verrà evidenziata a indicare che è possibile eseguire task sul nodo. È possibile scegliere di eseguire una delle azioni seguenti: Modifica, Crea, Pulitura, Pulitura approfondita, Ripesa, Disattiva, Attiva, Declassa, Contrassegna come perso, Ripulisci, Elimina definitivamente o Elimina.

Fare clic sulla freccia verso il basso in alto a sinistra nell'intestazione della tabella accanto al pulsante Crea e selezionare il task che si desidera eseguire.

Fare clic su Cluster › Configurazione per visualizzare un elenco completo delle opzioni di configurazione del cluster Ceph. L'elenco contiene il nome dell'opzione, la descrizione breve, i valori attuali e di default e se l'opzione è modificabile.

Figura 4.14: Configurazione del cluster #

 

Fare clic sulla freccia a discesa accanto a un'opzione di configurazione nella colonna Nome per visualizzare una tabella estesa con le informazioni dettagliate sull'opzione, come il tipo di valore, i valori minimo e massimo consentiti, se è possibile aggiornarla al runtime e molto altro.

Dopo aver evidenziato un'opzione specifica, è possibile modificarne i valori facendo clic sul pulsante Modifica in alto a sinistra nell'intestazione della tabella. Confermare le modifiche con Salva.

Fare clic su Cluster › Mappa CRUSH per visualizzare una mappa CRUSH del cluster. Per ulteriori informazioni generali sulle mappe CRUSH, fare riferimento alla Sezione 17.5, «Modifica della mappa CRUSH».

Fare clic sulla radice, sui nodi o sui singoli OSD per visualizzare altri dettagli, come il peso crush, la profondità nell'albero della mappa, la classe di dispositivi dell'OSD e molto altro.

Figura 4.15: Mappa CRUSH #

 

Fare clic su Cluster › Moduli Manager per visualizzare un elenco dei moduli Ceph Manager disponibili. Ogni riga contiene il nome del modulo e informazioni sul suo stato di abilitazione o disabilitazione.

Figura 4.16: Moduli Manager #

 

Fare clic sulla freccia a discesa accanto a un modulo nella colonna Nome per visualizzare una tabella estesa con le impostazioni dettagliate nella tabella Dettagli di seguito. Modificarle facendo clic sul pulsante Modifica in alto a sinistra nell'intestazione della tabella. Confermare le modifiche con Aggiorna.

Fare clic sulla freccia a discesa accanto al pulsante Modifica in alto a sinistra nell'intestazione della tabella per abilitare o disabilitare un modulo.

Fare clic su Cluster › Log per visualizzare un elenco delle voci di log recenti del cluster. Ogni riga contiene la registrazione dell'orario, il tipo di voce del log e il messaggio registrato.

Fare clic sulla scheda Log delle revisioni per visualizzare le voci di log del sottosistema di revisione. Fare riferimento alla Sezione 11.5, «Controllo delle richieste API» per i comandi di abilitazione o disabilitazione della revisione.

Figura 4.17: Log #

 

Fare clic su Cluster › Monitoraggio per gestire e visualizzare i dettagli sugli avvisi di Prometheus.

Se Prometheus è attivo, nel relativo pannello dei contenuti è possibile visualizzare le informazioni dettagliate su Avvisi attivi, Tutti gli avvisi o Silenziamenti.

Nota

Se Prometheus non è stato distribuito, verranno visualizzati un'intestazione di informazioni e un collegamento alla documentazione pertinente.

Per aggiungere un nuovo pool, fare clic su Crea in alto a sinistra nella tabella dei pool. Nel modulo dei pool è possibile immettere il nome, il tipo, le applicazioni, la modalità di compressione e le quote relativi a un pool, incluso il numero massimo di byte e oggetti. Tale modulo calcola in anticipo il numero di gruppi di posizionamento più adatto per il pool specifico. Tale calcolo si basa sul numero di OSD nel cluster e sul tipo di pool selezionato con le relative impostazioni specifiche. Non appena viene impostato manualmente, il numero dei gruppi di posizionamento viene sostituito da un numero calcolato. Confermare con Crea pool.

Figura 5.2: Aggiunta di un nuovo pool #

 

Per eliminare un pool, selezionarlo nella riga della tabella. Fare clic sulla freccia a discesa accanto al pulsante Crea e fare clic su Elimina.

Per modificare le opzioni di un pool, selezionare il pool nella riga della tabella e fare clic su Modifica in alto a sinistra nella tabella dei pool.

È possibile modificare il nome del pool, aumentare il numero di gruppi di posizionamento e modificare l'elenco delle applicazioni e delle impostazioni di compressione del pool. Confermare con Modifica pool.

Per visualizzare altri dettagli su un dispositivo, fare clic sulla relativa riga nella tabella:

Figura 6.2: Dettagli RBD #

 

Per visualizzare la configurazione dettagliata di un dispositivo, fare clic sulla relativa riga nella tabella e sulla scheda Configurazione nella tabella inferiore:

Figura 6.3: Configurazione RBD #

 

Per aggiungere un nuovo dispositivo, fare clic su Crea in alto a sinistra nell'intestazione della tabella ed eseguire quanto riportato di seguito nella schermata Crea RBD:

Figura 6.4: Aggiunta di un nuovo RBD #

 

Per eliminare un dispositivo, selezionarlo nella riga della tabella. Fare clic sulla freccia a discesa accanto al pulsante Crea e fare clic su Elimina. Confermare l'eliminazione con Delete RBD (Elimina RBD).

Suggerimento: spostamento degli RBD nel cestino

L'eliminazione di un RBD è un'azione irreversibile. Se invece si seleziona l'opzione Sposta nel cestino, è possibile ripristinare il dispositivo in un secondo momento selezionandolo nella scheda Cestino della tabella principale e facendo clic su Ripristina in alto a sinistra nell'intestazione della tabella.

Per creare uno snapshot del dispositivo di blocco RADOS (RADOS Block Device, RBD), selezionare il dispositivo nella riga della tabella per visualizzare il pannello dei contenuti relativo ai dettagli della configurazione. Selezionare la scheda Snapshot e fare clic su Crea in alto a sinistra nell'intestazione della tabella. Immettere il nome dello snapshot e confermare con Crea snapshot RBD.

Dopo aver selezionato una snapshot, è possibile eseguire ulteriori azioni sul dispositivo, ad esempio rinominarlo, proteggerlo, clonarlo, copiarlo o eliminarlo. L'opzione Rollback consente di ripristinare lo stato del dispositivo dallo snapshot attuale.

Figura 6.5: Snapshot RBD #

 

È possibile eseguire la copia speculare delle immagini del dispositivo di blocco RADOS (RADOS Block Device, RBD) in modo asincrono tra due cluster Ceph. È possibile utilizzare il Ceph Dashboard per configurare la replica delle immagini RBD tra due o più cluster. Questa funzionalità è disponibile in due modalità:

La copia speculare è configurata su ogni singolo pool all'interno dei cluster peer ed è possibile configurarla su un sottoinsieme specifico di immagini all'interno del pool o per fare in modo che esegua automaticamente la copia speculare di tutte le immagini del pool quando è in uso soltanto la modalità basata sul journal.

Per la configurazione della copia speculare si utilizza il comando rbd, installato per default in SUSE Enterprise Storage 7.1. Il daemon rbd-mirror è responsabile del pull degli aggiornamenti delle immagini dal cluster peer remoto e della loro applicazione all'immagine nel cluster locale. Vedere la Sezione 6.6.2, «Abilitazione del daemon rbd-mirror» per maggiori informazioni sull'abilitazione del daemon rbd-mirror.

A seconda delle necessità di replica, è possibile configurare la copia speculare del dispositivo di blocco RADOS (RADOS Block Device, RBD) sulla replica a una o due vie:

Importante

Ogni istanza del daemon rbd-mirror deve essere in grado di connettersi contemporaneamente al cluster Ceph local e remote, ad esempio a tutti i monitor e agli host OSD. Inoltre, la larghezza di banda della rete tra i due data center deve essere sufficiente per gestire il workload della copia speculare.

Suggerimento: informazioni generali

Per informazioni generali e sull'approccio della riga di comando alla copia speculare del dispositivo di blocco RADOS, fare riferimento alla Sezione 20.4, «Copie speculari delle immagini RBD».

6.6.1 Configurazione dei cluster primario e secondario #

 

Nel cluster primario viene creato il pool originale con le immagini. Nel cluster secondario vengono replicati il pool o le immagini dal cluster primario.

Nota: denominazione relativa

I termini primario e secondario possono essere relativi nel contesto della replica, perché fanno riferimento più ai singoli pool che ai cluster. Ad esempio, nella replica bidirezionale, è possibile eseguire la copia speculare di un pool dal cluster primario a quello secondario mentre è in corso la copia speculare di un altro pool dal cluster secondario a quello primario.

cephuser@adm > rbd mirror pool disable POOL_NAME

cephuser@adm > rbd mirror pool peer bootstrap create [--site-name local-site-name] pool-name

cephuser@adm > rbd --cluster primary mirror pool peer bootstrap create --site-name primary
  image-pool eyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkL \
  W1pcnJvci1wZWVyIiwia2V5IjoiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1vbl9ob3N0I \
  joiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==

cephuser@adm > rbd mirror pool peer bootstrap import [--site-name local-site-name] \
[--direction rx-only or rx-tx] pool-name token-path

cephuser@adm > cat >>EOF < token
eyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkLW1pcn \
Jvci1wZWVyIiwia2V5IjoiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1vbl9ob3N0I \
joiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==
EOF
cephuser@adm > rbd --cluster secondary mirror pool peer bootstrap import --site-name secondary image-pool token

cephuser@adm > rbd mirror pool peer remove pool-name peer-uuid

Suggerimento: ulteriori informazioni sugli iSCSI Gateway

Per ulteriori informazioni generali sugli iSCSI Gateway, fare riferimento al Capitolo 22, Ceph iSCSI Gateway.

Per visualizzare un elenco di tutti i gateway e le immagini mappate disponibili, fare clic su Blocco › iSCSI nel menu principale. Si apre la scheda Panoramica, in cui vengono elencati gli iSCSI Gateway attualmente configurati e le immagini RBD mappate.

Nella tabella dei gateway sono elencati lo stato, il numero di destinazioni iSCSI e il numero di sessioni di ogni gateway. Nella tabella Immagini sono elencati il nome, il nome del pool correlato, il tipo di backstore e altri dettagli statistici di ciascuna immagine mappata.

Nella scheda Destinazioni sono elencate le destinazioni iSCSI attualmente configurate.

Figura 6.14: Elenco delle destinazioni iSCSI #

 

Per visualizzare ulteriori informazioni dettagliate su una destinazione, fare clic sulla freccia a discesa nella riga della tabella delle destinazioni. Si apre uno schema con struttura ad albero in cui sono elencati i dischi, i portali, gli iniziatori e i gruppi. Fare clic su un elemento per espanderlo e visualizzare i relativi contenuti dettagliati, facoltativamente insieme alla configurazione correlata, nella tabella a destra.

Figura 6.15: Dettagli sulla destinazione iSCSI #

 

6.7.1 Aggiunta di destinazioni iSCSI #

 

Per aggiungere una nuova destinazione iSCSI, fare clic su Crea in alto a sinistra nella tabella Destinazioni e immettere le informazioni richieste.

Figura 6.16: Aggiunta di una nuova destinazione #

 

1. Immettere l'indirizzo di destinazione del nuovo gateway.

2. Fare clic su Aggiungi portale e selezionare uno o più portali iSCSI dall'elenco.

3. Fare clic su Aggiungi immagine e selezionare una o più immagini RBD per il gateway.

4. Se è necessario utilizzare l'autenticazione per accedere al gateway, attivare la casella di controllo Autenticazione ACL e immettere le credenziali. Ulteriori opzioni di autenticazione avanzata sono disponibili dopo l'attivazione di Mutual authentication (Autenticazione reciproca) e Discovery authentication (Autenticazione rilevazione).

5. Confermare con Create Target (Crea destinazione).

Suggerimento: ulteriori informazioni

Per ulteriori informazioni generali e per una descrizione delle opzioni di configurazione QoS RBD, fare riferimento alla Sezione 20.6, «Impostazioni QoS».

È possibile configurare le opzioni QoS a livelli diversi.

La configurazione globale si trova in cima all'elenco e verrà utilizzata per tutte le immagini RBD di nuova creazione e per quelle immagini che non ignorano tali valori sul livello di pool o di immagine RBD. Un valore di opzione specificato globalmente può essere ignorato per ogni singolo pool o per ogni singola immagine. Le opzioni specificate in un pool verranno applicate a tutte le immagini RBD di tale pool a meno che non siano sostituite da un'opzione di configurazione impostata in un'immagine. Le opzioni specificate in un'immagine sostituiranno quelle specificate globalmente e quelle specificate in un pool.

In questo modo, è possibile definire i valori di default globalmente, adattarli a tutte le immagini RBD di un pool specifico e sostituire la configurazione del pool per le singole immagini RBD.

6.8.2 Configurazione delle opzioni in un nuovo pool #

 

Per creare un nuovo pool e configurarvi le opzioni di configurazione RBD, fare clic su Pool › Crea. Selezionare replicated (replicato) come tipo di pool. Sarà quindi necessario aggiungere il tag applicazione rbd al pool per poter configurare le opzioni QoS RBD.

Nota

Non è possibile configurare le opzioni di configurazione QoS RBD sui pool con codice di cancellazione. A questo scopo, è necessario modificare il pool dei metadati replicato di un'immagine RBD. La configurazione verrà quindi applicata al pool di dati con codice di cancellazione di tale immagine.

6.8.3 Configurazione delle opzioni in un pool esistente #

 

Per configurare le opzioni QoS RBD in un pool esistente, fare clic su Pool, quindi sulla riga di tabella corrispondente al pool e selezionare Modifica in alto a sinistra nella tabella.

Dovrebbe aprirsi la sezione Configurazione RBD nella finestra di dialogo, seguita dalla sezione Qualità di servizio.

Nota

Se le sezioni Configurazione RBD o Qualità di servizio non vengono visualizzate, è possibile che si stia modificando un pool con codice di cancellazione (erasure coded), il quale non può essere utilizzato per impostare le opzioni di configurazione RBD, o che il pool non sia configurato per l'utilizzo da parte delle immagini RBD. Nell'ultimo caso, assegnare il tag applicazione rbd al pool per visualizzare le sezioni di configurazione corrispondenti.

Per aggiungere una nuova esportazione NFS, fare clic su Crea in alto a sinistra nella tabella delle esportazioni e immettere le informazioni richieste.

Figura 7.3: Aggiunta di una nuova esportazione NFS #

 

Per eliminare un'esportazione, selezionarla ed evidenziarla nella riga della tabella. Fare clic sulla freccia a discesa accanto al pulsante Modifica e selezionare Elimina. Attivare la casella di controllo Sì e confermare con Elimina esportazione NFS.

Per modificare un'esportazione esistente, selezionare ed evidenziare l'esportazione nella riga della tabella e fare clic su Modifica in alto a sinistra nella tabella delle esportazioni.

Quindi, è possibile regolare tutti i dettagli dell'esportazione NFS.

Figura 7.4: Modifica di un'esportazione NFS #

 

Fare clic su File system nel menu principale per visualizzare la panoramica dei file system configurati. Nella tabella principale viene mostrato il nome e la data di creazione di ciascun file system e informazioni sul relativo stato di abilitazione o disabilitazione.

Facendo clic sulla riga di tabella corrispondente a un file system, sarà possibile visualizzare i dettagli sulla classificazione e sui pool aggiunti a quest'ultimo.

Figura 8.1: Dettagli CephFS #

 

Nella parte inferiore della schermata, è possibile visualizzare le statistiche con il numero in tempo reale degli inode MDS e delle richieste client correlati.

Figura 8.2: Dettagli CephFS #

 

Fare clic su Object Gateway › Daemon per visualizzare un elenco degli Object Gateway configurati. L'elenco include l'ID del gateway, il nome host del nodo del cluster su cui è in esecuzione il daemon del gateway e il numero di versione del gateway.

Fare clic sulla freccia a discesa accanto al nome del gateway per visualizzare le relative informazioni dettagliate. Nella scheda Contatori delle prestazioni vengono mostrati i dettagli delle operazioni di lettura/scrittura e le statistiche sulla cache.

Figura 9.1: Dettagli Gateway #

 

Fare clic su Object Gateway › Utenti per visualizzare un elenco degli utenti di Object Gateway esistenti.

Fare clic sulla freccia a discesa accanto al nome utente per visualizzare i dettagli sull'account utente, come le informazioni sullo stato o i dettagli sulla quota utenti o compartimenti.

Figura 9.2: Utenti Gateway #

 

9.2.1 Aggiunta di un nuovo utente Gateway #

 

Per aggiungere un nuovo utente Gateway, fare clic su Crea in alto a sinistra nell'intestazione della tabella. Inserire le credenziali, i dettagli della chiave S3 e delle quote utenti e compartimenti, quindi confermare con Crea utente.

Figura 9.3: Aggiunta di un nuovo utente Gateway #

 

I compartimenti Object Gateway (OGW) implementano la funzionalità dei container di OpenStack Swift e fungono da container per la memorizzazione degli oggetti dati.

Fare clic su Object Gateway › Compartimenti per visualizzare un elenco dei compartimenti Object Gateway.

9.3.1 Aggiunta di un nuovo compartimento #

 

Per aggiungere un nuovo compartimento Object Gateway, fare clic su Crea in alto a sinistra nell'intestazione della tabella. Immettere il nome del compartimento, selezionare il proprietario e impostare la destinazione di posizionamento. Confermare con Crea compartimento.

Nota

In questa fase è possibile inoltre abilitare il blocco selezionando Abilitato; a ogni modo, si tratta di un'impostazione che può essere configurata in seguito alla creazione. Consultare Sezione 9.3.3, «Modifica del compartimento» per maggiori informazioni.

9.3.2 Visualizzazione dei dettagli del compartimento #

 

Per visualizzare informazioni dettagliate su un compartimento Object Gateway, fare clic sulla freccia a discesa accanto al nome del compartimento.

Figura 9.4: Dettagli compartimento Gateway #

 

Suggerimento: quota compartimento

Sotto la tabella Dettagli, è possibile trovare i dettagli delle impostazioni relative al blocco e alla quota compartimenti.

9.3.3 Modifica del compartimento #

 

Selezionare ed evidenziare un compartimento, quindi fare clic su Modifica in alto a sinistra nell'intestazione della tabella.

È possibile aggiornare il proprietario del compartimento o abilitare il controllo versioni, l'autenticazione a più fattori o il blocco. Confermare le modifiche con Modifica compartimento.

Figura 9.5: Modifica dei dettagli del compartimento #

 

Per default, tutte le connessioni HTTP al dashboard sono protette da TLS/SSL. Per la connessione sicura è necessario un certificato SSL. È possibile utilizzare un certificato firmato da se stessi o generarne uno e farlo firmare da un'autorità di certificazione (CA) nota.

Suggerimento: disabilitazione di SSL

In alcune situazioni, potrebbe essere opportuno disabilitare il supporto SSL. Ad esempio, se il dashboard è in esecuzione dietro un proxy che non supporta SSL.

Prestare attenzione quando si disabilita SSL poiché i nomi utente e le password verranno inviati al dashboard senza cifratura.

Per disabilitare SSL eseguire:

cephuser@adm > ceph config set mgr mgr/dashboard/ssl false

Suggerimento: riavvio dei processi del Ceph Manager

In seguito alla modifica del certificato e della chiave SSL, è necessario riavviare manualmente i processi di Ceph Manager. Per farlo, eseguire

cephuser@adm > ceph mgr fail ACTIVE-MANAGER-NAME

o disabilitare e riabilitare il modulo del dashboard (questa azione comporta inoltre la rigenerazione del manager):

cephuser@adm > ceph mgr module disable dashboard
cephuser@adm > ceph mgr module enable dashboard

10.1.1 Creazione di certificati autofirmati #

 

La procedura di creazione di un certificato firmato da se stessi per la comunicazione sicura è semplice. In questo modo è possibile rendere operativo il dashboard più rapidamente.

Nota: complain del browser Web

La maggior parte dei browser Web creerà un complain relativo al certificato firmato da se stessi e richiederà una conferma esplicita prima di stabilire una connessione sicura al dashboard.

Per generare e installare un certificato firmato da se stessi, utilizzare il seguente comando integrato:

cephuser@adm > ceph dashboard create-self-signed-cert

10.1.2 Utilizzo dei certificati firmati dall'autorità di certificazione #

 

Per proteggere correttamente la connessione al dashboard ed eliminare i complain del browser Web per i certificati firmati da se stessi, si consiglia di utilizzare un certificato firmato da una CA.

È possibile generare una coppia di chiavi di certificato con un comando simile al seguente:

# openssl req -new -nodes -x509 \
  -subj "/O=IT/CN=ceph-mgr-dashboard" -days 3650 \
  -keyout dashboard.key -out dashboard.crt -extensions v3_ca

Il comando riportato sopra consente di generare i file dashboard.key e dashboard.crt. Dopo aver ottenuto il file dashboard.crt firmato dalla CA, abilitarlo per tutte le istanze di Ceph Manager eseguendo i comandi seguenti:

cephuser@adm > ceph dashboard set-ssl-certificate -i dashboard.crt
cephuser@adm > ceph dashboard set-ssl-certificate-key -i dashboard.key

Suggerimento: certificati diversi per ogni istanza del Manager

Se sono richiesti certificati diversi per ogni istanza di Ceph Manager, modificare i comandi e includere il nome dell'istanza come segue. Sostituire NAME con il nome dell'istanza di Ceph Manager (in genere il nome host correlato):

cephuser@adm > ceph dashboard set-ssl-certificate NAME -i dashboard.crt
cephuser@adm > ceph dashboard set-ssl-certificate-key NAME -i dashboard.key

Il Ceph Dashboard è associato a un indirizzo TCP/IP e a una porta TCP specifici. Per default, il Ceph Manager attualmente attivo che ospita il dashboard è associato alla porta TCP 8443 (o alla porta 8080 se SSL è disabilitato).

Nota

Se sugli host che eseguono Ceph Manager (e di conseguenza il Ceph Dashboard) è abilitato un firewall, potrebbe essere necessario modificare la configurazione per abilitare l'accesso a queste porte. Per ulteriori informazioni sulle impostazioni del firewall per Ceph, vedere Book “Troubleshooting Guide”, Chapter 13 “Hints and tips”, Section 13.7 “Firewall settings for Ceph”.

Per default, il Ceph Dashboard è associato a "::", corrispondente a tutti gli indirizzi IPv4 e IPv6 disponibili. È possibile modificare l'indirizzo IP e il numero di porta dell'applicazione Web per fare in modo che vengano applicati a tutte le istanze di Ceph Manager utilizzando i comandi seguenti:

cephuser@adm > ceph config set mgr mgr/dashboard/server_addr IP_ADDRESS
cephuser@adm > ceph config set mgr mgr/dashboard/server_port PORT_NUMBER

Suggerimento: configurazione delle istanze di Ceph Manager separatamente

Dal momento che ogni daemon ceph-mgr ospita la propria istanza del dashboard, potrebbe essere necessario configurare separatamente tali istanze. Modificare l'indirizzo IP e il numero di porta di un'istanza del Manager specifica utilizzando i comandi seguenti (sostituire NAME con l'ID dell'istanza ceph-mgr):

cephuser@adm > ceph config set mgr mgr/dashboard/NAME/server_addr IP_ADDRESS
cephuser@adm > ceph config set mgr mgr/dashboard/NAME/server_port PORT_NUMBER

Suggerimento: elenco degli endpoint configurati

Il comando ceph mgr services consente di visualizzare tutti gli endpoint attualmente configurati. Cercare la chiave dashboard per ottenere l'URL per l'accesso al dashboard.

Se non si desidera utilizzare l'account amministratore di default, creare un account utente diverso e associarlo almeno a un ruolo. Viene fornito un set di ruoli di sistema predefiniti che è possibile utilizzare. Per ulteriori informazioni, fare riferimento a Capitolo 11, Gestione di utenti e ruoli sulla riga di comando.

Per creare un utente con privilegi di amministratore, utilizzare il comando seguente:

cephuser@adm > ceph dashboard ac-user-create USER_NAME PASSWORD administrator

Per utilizzare la funzionalità di gestione di Object Gateway del dashboard, è necessario immettere le credenziali di login di un utente con il flag system abilitato:

Nota

Per default, il firewall è abilitato in SUSE Linux Enterprise Server 15 SP3. Per ulteriori informazioni sulla configurazione del firewall, vedere Book “Troubleshooting Guide”, Chapter 13 “Hints and tips”, Section 13.7 “Firewall settings for Ceph”.

Vi sono diversi aspetti da considerare:

Il Ceph Dashboard gestisce le destinazioni iSCSI tramite l'API REST fornita dal servizio rbd-target-api di Ceph iSCSI Gateway. Assicurarsi che sia installata e abilitata sugli iSCSI Gateway.

Nota

La funzionalità di gestione di iSCSI del Ceph Dashboard dipende dalla versione 3 più recente del progetto ceph-iscsi. Assicurarsi che il sistema operativo fornisca la versione corretta, altrimenti il Ceph Dashboard non abiliterà le funzioni di gestione.

Se l'API REST ceph-iscsi è configurata in modalità HTTPS e utilizza un certificato autofirmato, configurare il dashboard in modo che eviti la verifica del certificato SSL durante l'accesso all'API ceph-iscsi.

Disabilitare la verifica SSL dell'API:

cephuser@adm > ceph dashboard set-iscsi-api-ssl-verification false

Definire i gateway iSCSI disponibili:

cephuser@adm > ceph dashboard iscsi-gateway-list
cephuser@adm > ceph dashboard iscsi-gateway-add scheme://username:password@host[:port]
cephuser@adm > ceph dashboard iscsi-gateway-rm gateway_name

Single Sign-On (SSO) è un metodo di controllo dell'accesso che consente agli utenti di eseguire contemporaneamente il login su più applicazioni utilizzando un solo ID e una sola password.

Il Ceph Dashboard supporta l'autenticazione esterna degli utenti tramite il protocollo SAML 2.0. Dal momento che l'autorizzazione viene comunque eseguita dal dashboard, è necessario innanzitutto creare gli account utente e associarli ai ruoli desiderati. Tuttavia, il processo di autenticazione può essere eseguito da un provider di identità (IdP) esistente.

Per configurare Single Sign-On, utilizzare il comando seguente:

cephuser@adm > ceph dashboard sso setup saml2 CEPH_DASHBOARD_BASE_URL \
 IDP_METADATA IDP_USERNAME_ATTRIBUTE \
 IDP_ENTITY_ID SP_X_509_CERT \
 SP_PRIVATE_KEY

Parametri:

Nota: richieste SAML

Il valore dell'autorità di certificazione delle richieste SAML seguirà questo modello:

CEPH_DASHBOARD_BASE_URL/auth/saml2/metadata

Per visualizzare la configurazione SAML 2.0 corrente, eseguire:

cephuser@adm > ceph dashboard sso show saml2

Per disabilitare Single Sign-On, eseguire:

cephuser@adm > ceph dashboard sso disable

Per verificare se SSO è abilitato, eseguire:

cephuser@adm > ceph dashboard sso status

Per abilitare SSO eseguire:

cephuser@adm > ceph dashboard sso enable saml2

Per default, la funzione della policy password è abilitata insieme ai controlli seguenti:

La funzione della policy password può essere attivata o disattivata:

cephuser@adm > ceph dashboard set-pwd-policy-enabled true|false

I singoli controlli seguenti possono essere attivati o disattivati:

cephuser@adm > ceph dashboard set-pwd-policy-check-length-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-oldpwd-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-username-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-exclusion-list-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-complexity-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-sequential-chars-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-repetitive-chars-enabled true|false

Inoltre, sono disponibili le opzioni seguenti per configurare il comportamento della policy password.

Il Ceph Dashboard supporta la gestione di più account utente. Ogni account utente include un nome utente, una password (memorizzata in formato cifrato tramite il comando bcrypt), un nome facoltativo e un indirizzo e-mail facoltativo.

Gli account utente sono memorizzati nel database di configurazione di Ceph Monitor e sono condivisi a livello globale su tutte le istanze di Ceph Manager.

Utilizzare i comandi seguenti per gestire gli account utente:

Questa sezione descrive gli ambiti di sicurezza che è possibile assegnare a un ruolo dell'utente e come gestire i ruoli dell'utente e assegnarli agli account utente.

11.3.2 Specifica dei ruoli dell'utente #

 

Un ruolo consente di specificare un set di mappature tra un ambito di sicurezza e un set di autorizzazioni. Vi sono quattro tipi di autorizzazioni: "read" (lettura), "create" (creazione), "update" (aggiornamento) e "delete" (eliminazione).

Nell'esempio seguente viene specificato un ruolo in cui l'utente dispone delle autorizzazioni "read" e "create" per le funzioni relative alla gestione del pool e delle autorizzazioni complete per le funzioni relative alla gestione delle immagini RBD:

{
  'role': 'my_new_role',
  'description': 'My new role',
  'scopes_permissions': {
    'pool': ['read', 'create'],
    'rbd-image': ['read', 'create', 'update', 'delete']
  }
}

Nel dashboard è già fornito un set di ruoli predefiniti denominati ruoli di sistema. È possibile utilizzarli immediatamente dopo l'installazione da zero del Ceph Dashboard:

amministratore

Fornisce le autorizzazioni complete per tutti gli ambiti di sicurezza.

sola lettura

Fornisce l'autorizzazione in lettura per tutti gli ambiti di sicurezza a eccezione delle impostazioni del dashboard.

block-manager

Fornisce le autorizzazioni complete per gli ambiti "rbd-image", "rbd-mirroring" e "iscsi".

rgw-manager

Fornisce le autorizzazioni complete per l'ambito "rgw".

cluster-manager

Fornisce le autorizzazioni complete per gli ambiti "hosts", "osd", "monitor", "manager" e "config-opt".

pool-manager

Fornisce le autorizzazioni complete per l'ambito "pool".

cephfs-manager

Fornisce le autorizzazioni complete per l'ambito "cephfs".

11.3.2.1 Gestione dei ruoli personalizzati #

 

È possibile creare nuovi ruoli dell'utente utilizzando i comandi seguenti:

Per creare un nuovo ruolo:

cephuser@adm > ceph dashboard ac-role-create ROLENAME [DESCRIPTION]

Per eliminare un ruolo:

cephuser@adm > ceph dashboard ac-role-delete ROLENAME

Per aggiungere autorizzazioni di ambito a un ruolo:

cephuser@adm > ceph dashboard ac-role-add-scope-perms ROLENAME SCOPENAME PERMISSION [PERMISSION...]

Per eliminare le autorizzazioni di ambito da un ruolo:

cephuser@adm > ceph dashboard ac-role-del-perms ROLENAME SCOPENAME

11.3.2.2 Assegnazione dei ruoli agli account utente #

 

Utilizzare i comandi seguenti per assegnare i ruoli agli utenti:

Per impostare i ruoli dell'utente:

cephuser@adm > ceph dashboard ac-user-set-roles USERNAME ROLENAME [ROLENAME ...]

Per aggiungere ulteriori ruoli a un utente:

cephuser@adm > ceph dashboard ac-user-add-roles USERNAME ROLENAME [ROLENAME ...]

Per eliminare i ruoli da un utente:

cephuser@adm > ceph dashboard ac-user-del-roles USERNAME ROLENAME [ROLENAME ...]

Suggerimento: eliminazione definitiva dei ruoli personalizzati

Se si creano ruoli dell'utente personalizzati e si intende rimuovere il cluster Ceph con lo strumento di esecuzione ceph.purge in un secondo momento, è necessario innanzitutto eliminare definitivamente i ruoli personalizzati. Ulteriori dettagli sono disponibili nel Sezione 13.9, «Rimozione dell'intero cluster Ceph».

11.3.2.3 Esempio: creazione di un utente e di un ruolo personalizzato #

 

Questa sezione illustra la procedura di creazione di un account utente in grado di gestire le immagini RBD, visualizzare e creare pool Ceph e con l'accesso in sola lettura a qualsiasi altro ambito.

1. Creare un nuovo utente denominato tux:

    cephuser@adm > ceph dashboard ac-user-create tux PASSWORD

2. Creare un ruolo e specificare le autorizzazioni di ambito:

   cephuser@adm > ceph dashboard ac-role-create rbd/pool-manager
   cephuser@adm > ceph dashboard ac-role-add-scope-perms rbd/pool-manager \
    rbd-image read create update delete
   cephuser@adm > ceph dashboard ac-role-add-scope-perms rbd/pool-manager pool read create

3. Associare i ruoli all'utente tux:

   cephuser@adm > ceph dashboard ac-user-set-roles tux rbd/pool-manager read-only

Se si desidera stabilire un URL fisso per raggiungere il Ceph Dashboard o se non si desidera consentire connessioni dirette ai nodi del manager, è possibile configurare un proxy per l'inoltro automatico delle richieste in entrata all'istanza ceph-mgr attualmente attiva.

  cephuser@adm > ceph config set mgr mgr/dashboard/url_prefix URL_PREFIX

cephuser@adm > ceph config set mgr mgr/dashboard/standby_behaviour "error"

cephuser@adm > ceph config set mgr mgr/dashboard/standby_behaviour "redirect"

cephuser@adm > ceph config set mgr mgr/dashboard/standby_error_status_code 503

11.4.4 Configurazione HAProxy di esempio #

 

La configurazione di esempio seguente è da utilizzare per il pass-through TLS/SSL tramite HAProxy.

Nota

La configurazione è valida nelle condizioni seguenti: in caso di failover del dashboard, il client di front-end potrebbe ricevere una risposta di reindirizzamento HTTP (303) e verrà reindirizzato a un host non risolvibile.

Ciò avviene quando il failover si verifica durante due controlli di integrità di HAProxy. In questa situazione, il nodo del dashboard precedentemente attivo restituirà la risposta 303 che punta a un nuovo nodo attivo. Per evitare questa situazione, si consiglia di disabilitare il comportamento di reindirizzamento sui nodi di standby.

  defaults
    log global
    option log-health-checks
    timeout connect 5s
    timeout client 50s
    timeout server 450s

  frontend dashboard_front
    mode http
    bind *:80
    option httplog
    redirect scheme https code 301 if !{ ssl_fc }

  frontend dashboard_front_ssl
    mode tcp
    bind *:443
    option tcplog
    default_backend dashboard_back_ssl

  backend dashboard_back_ssl
    mode tcp
    option httpchk GET /
    http-check expect status 200
    server x HOST:PORT ssl check verify none
    server y HOST:PORT ssl check verify none
    server z HOST:PORT ssl check verify none

L'API REST del Ceph Dashboard è in grado di registrare le richieste PUT, POST e DELETE sul log di revisione di Ceph. La funzione di registrazione è disabilita per default, ma è possibile abilitarla con il comando seguente:

cephuser@adm > ceph dashboard set-audit-api-enabled true

Se abilitata, per ciascuna richiesta vengono registrati i parametri seguenti:

Una voce di log di esempio ha il seguente aspetto:

2019-02-06 10:33:01.302514 mgr.x [INF] [DASHBOARD] \
 from='https://[::ffff:127.0.0.1]:37022' path='/api/rgw/user/exu' method='PUT' \
 user='admin' params='{"max_buckets": "1000", "display_name": "Example User", "uid": "exu", "suspended": "0", "email": "user@example.com"}'

Suggerimento: disabilitazione della registrazione del payload della richiesta

La registrazione del payload della richiesta (l'elenco degli argomenti e dei relativi valori) è abilitata per default. È possibile disabilitarla nel modo seguente:

cephuser@adm > ceph dashboard set-audit-api-log-payload false

Il Ceph Dashboard è in grado di gestire le esportazioni NFS Ganesha che utilizzano CephFS oppure Object Gateway come backstore. Il dashboard gestisce i file di configurazione di NFS Ganesha memorizzati negli oggetti RADOS sul cluster CephFS. NFS Ganesha deve memorizzare parte della loro configurazione nel cluster Ceph.

Eseguire il comando seguente per configurare l'ubicazione dell'oggetto di configurazione di NFS Ganesha.

cephuser@adm > ceph dashboard set-ganesha-clusters-rados-pool-namespace pool_name[/namespace]

Adesso, è possibile gestire le esportazioni di NFS Ganesha tramite il Ceph Dashboard.

cephuser@adm > ceph dashboard set-ganesha-clusters-rados-pool-namespace cluster_id:pool_name[/namespace](,cluster_id:pool_name[/namespace])*

I plug-in del Ceph Dashboard estendono la funzionalità del dashboard. Il plug-in di debug consente la personalizzazione del comportamento del dashboard in base alla modalità di debug. È possibile abilitarlo, disabilitarlo o selezionarlo con il comando seguente:

cephuser@adm > ceph dashboard debug status
Debug: 'disabled'
cephuser@adm > ceph dashboard debug enable
Debug: 'enabled'
cephuser@adm > dashboard debug disable
Debug: 'disabled'

Per default, è disabilitato. Si tratta dell'impostazione consigliata per le distribuzioni di produzione. Se necessario, è possibile abilitare la modalità di debug senza dover riavviare.

È possibile individuare lo stato immediato del cluster mediante ceph status o ceph -s:

cephuser@adm > ceph -s
cluster:
    id:     b4b30c6e-9681-11ea-ac39-525400d7702d
    health: HEALTH_OK

  services:
    mon: 5 daemons, quorum ses-min1,ses-master,ses-min2,ses-min4,ses-min3 (age 2m)
    mgr: ses-min1.gpijpm(active, since 3d), standbys: ses-min2.oopvyh
    mds: my_cephfs:1 {0=my_cephfs.ses-min1.oterul=up:active}
    osd: 3 osds: 3 up (since 3d), 3 in (since 11d)
    rgw: 2 daemons active (myrealm.myzone.ses-min1.kwwazo, myrealm.myzone.ses-min2.jngabw)

  task status:
    scrub status:
        mds.my_cephfs.ses-min1.oterul: idle

  data:
    pools:   7 pools, 169 pgs
    objects: 250 objects, 10 KiB
    usage:   3.1 GiB used, 27 GiB / 30 GiB avail
    pgs:     169 active+clean

L'output fornisce le seguenti informazioni:

Suggerimento: calcolo dell'utilizzo dei dati da parte di Ceph

Il valore used riflette la quantità effettiva di spazio di memorizzazione non elaborato utilizzato. Il valore xxx GB / xxx GB indica la quantità disponibile (il numero inferiore) della capacità di memorizzazione complessiva del cluster. Il numero nozionale riflette le dimensioni dei dati memorizzati prima che vengano replicati, clonati o che ne venga eseguito lo snapshot. Pertanto, di norma la quantità di dati effettivamente memorizzata supera la quantità nozionale memorizzata, poiché Ceph crea repliche dei dati e può anche utilizzare capacità di memorizzazione per la clonazione e gli snapshot.

Altri comandi che consentono di visualizzare informazioni immediate sullo stato sono:

Per ottenere le informazioni aggiornate in tempo reale, inserire uno di questi comandi (incluso ceph -s) come argomento del comando watch:

# watch -n 10 'ceph -s'

Premere Ctrl–C quando non si desidera più visualizzare le informazioni.

Dopo l'avvio del cluster e prima della lettura e/o scrittura dei dati, verificare lo stato di integrità del cluster:

cephuser@adm > ceph health
HEALTH_WARN 10 pgs degraded; 100 pgs stuck unclean; 1 mons down, quorum 0,2 \
node-1,node-2,node-3

Suggerimento

Se sono state specificate ubicazioni non di default per la configurazione o il portachiavi, è possibile specificarne le ubicazioni:

cephuser@adm > ceph -c /path/to/conf -k /path/to/keyring health

Il cluster Ceph restituisce uno dei seguenti codici di stato di integrità:

Suggerimento

Se sono state specificate ubicazioni non di default per la configurazione o il portachiavi, è possibile specificarne le ubicazioni:

# ceph -c /path/to/conf -k /path/to/keyring health

Per verificare l'utilizzo e la distribuzione dei dati del cluster nei diversi pool, utilizzare il comando ceph df. Per ottenere ulteriori dettagli, utilizzare ceph df detail.

cephuser@adm > ceph df
--- RAW STORAGE ---
CLASS  SIZE    AVAIL   USED     RAW USED  %RAW USED
hdd    30 GiB  27 GiB  121 MiB   3.1 GiB      10.40
TOTAL  30 GiB  27 GiB  121 MiB   3.1 GiB      10.40

--- POOLS ---
POOL                   ID  STORED   OBJECTS  USED     %USED  MAX AVAIL
device_health_metrics   1      0 B        0      0 B      0    8.5 GiB
cephfs.my_cephfs.meta   2  1.0 MiB       22  4.5 MiB   0.02    8.5 GiB
cephfs.my_cephfs.data   3      0 B        0      0 B      0    8.5 GiB
.rgw.root               4  1.9 KiB       13  2.2 MiB      0    8.5 GiB
myzone.rgw.log          5  3.4 KiB      207    6 MiB   0.02    8.5 GiB
myzone.rgw.control      6      0 B        8      0 B      0    8.5 GiB
myzone.rgw.meta         7      0 B        0      0 B      0    8.5 GiB

Nella sezione RAW STORAGE dell'output è fornita una panoramica dello spazio di storage utilizzato dal cluster per i dati.

Nella sezione POOLS dell'output è fornito un elenco di pool e l'utilizzo nozionale di ciascuno di essi. L'output di questa sezione non riflette repliche, cloni o snapshot. Ad esempio, se si memorizza un oggetto con 1 MB di dati, l'utilizzo nozionale sarà 1 MB, ma quello effettivo può essere di 2 MB o più a seconda del numero di repliche, cloni e snapshot.

Nota

I numeri nella sezione POOLS sono nozionali. Non includono il numero di repliche, snapshot o cloni. Ne risulta che la somma delle quantità USED e %USED non verrà aggiunta alle quantità RAW USED e %RAW USED nella sezione RAW STORAGE dell'output.

È possibile verificare lo stato degli OSD per assicurarsi che siano attivi e funzionanti eseguendo:

cephuser@adm > ceph osd stat

oppure

cephuser@adm > ceph osd dump

È inoltre possibile visualizzare gli OSD in base alla rispettiva posizione nella mappa CRUSH.

ceph osd tree eseguirà la stampa di un albero CRUSH con un host, i rispettivi OSD, se attivi, e il relativo peso:

   cephuser@adm > ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME              STATUS  REWEIGHT  PRI-AFF
-1      3  0.02939  root default
-3      3  0.00980    rack mainrack
-2      3  0.00980            host osd-host
0       1  0.00980                    osd.0   up   1.00000   1.00000
1       1  0.00980                    osd.1   up   1.00000   1.00000
2       1  0.00980                    osd.2   up   1.00000   1.00000

Ceph impedisce la scrittura in un OSD pieno in modo da evitare perdite di dati. In un cluster operativo, quando questo è prossimo al rispettivo rapporto di riempimento si riceve un avviso. L'impostazione di default di mon osd full ratio è 0,95 o 95% della capacità, prima che venga interrotta la scrittura dei dati da parte dei client. L'impostazione di default di mon osd nearfull ratio è 0,85 o 85% della capacità, quando viene generato avviso sullo stato di integrità.

I nodi OSD pieni verranno segnalati da ceph health:

cephuser@adm > ceph health
  HEALTH_WARN 1 nearfull osds
  osd.2 is near full at 85%

oppure

cephuser@adm > ceph health
  HEALTH_ERR 1 nearfull osds, 1 full osds
  osd.2 is near full at 85%
  osd.3 is full at 97%

Il modo migliore per gestire un cluster pieno consiste nell'aggiungere nuovi host/dischi OSD che consentano al cluster di ridistribuire dati nello spazio di storage che si è appena reso disponibile.

Suggerimento: esclusione degli OSD pieni

Quando un OSD si riempie (utilizza il 100% del rispettivo spazio su disco), di norma questo si blocca rapidamente senza alcun avviso. Di seguito sono riportati alcuni suggerimenti utili per l'amministrazione dei nodi OSD.

• È necessario posizionare lo spazio su disco di ciascun OSD (di norma montato in /var/lib/ceph/osd/osd-{1,2..}) su un disco o una partizione dedicati sottostanti.

• Controllare i file di configurazione Ceph e assicurarsi che il log file Ceph non venga memorizzato nei dischi o nelle partizioni dedicati all'uso da parte degli OSD.

• Assicurarsi che la scrittura nei dischi o nelle partizioni dedicati all'uso da parte degli OSD non venga eseguita da altri processi.

Dopo aver avviato il cluster e precedentemente alla prima lettura e/o scrittura dei dati, verificare lo stato del quorum dei Ceph Monitor. Se il cluster sta già provvedendo alle richieste, controllare periodicamente lo stato dei Ceph Monitor per assicurarsi che siano in esecuzione.

Per visualizzare la mappa del monitoraggio, eseguire quanto riportato di seguito:

cephuser@adm > ceph mon stat

oppure

cephuser@adm > ceph mon dump

Per verificare lo stato del quorum per il cluster di monitoraggio, eseguire quanto riportato di seguito:

cephuser@adm > ceph quorum_status

Ceph restituirà lo stato del quorum. Ad esempio, un cluster Ceph costituito da tre monitoraggi può restituire quanto riportato di seguito:

{ "election_epoch": 10,
  "quorum": [
        0,
        1,
        2],
  "monmap": { "epoch": 1,
      "fsid": "444b489c-4f16-4b75-83f0-cb8097468898",
      "modified": "2011-12-12 13:28:27.505520",
      "created": "2011-12-12 13:28:27.505520",
      "mons": [
            { "rank": 0,
              "name": "a",
              "addr": "192.168.1.10:6789\/0"},
            { "rank": 1,
              "name": "b",
              "addr": "192.168.1.11:6789\/0"},
            { "rank": 2,
              "name": "c",
              "addr": "192.168.1.12:6789\/0"}
           ]
    }
}

Oggetti della mappa dei gruppi di posizionamento negli OSD. Quando si monitorano i gruppi di posizionamento, questi dovranno essere active e clean. Per una discussione dettagliata, fare riferimento alla Sezione 12.9, «Monitoraggio di OSD e gruppi di posizionamento».

Quando un cluster di memorizzazione Ceph si avvicina alla capacità massima, Ceph impedisce la scrittura o la lettura dai Ceph OSD come misura di sicurezza per evitare perdite di dati. Pertanto, non è consigliabile far avvicinare un cluster di produzione al rapporto di riempimento. Questa situazione andrebbe infatti a discapito dell'elevata disponibilità. Per default il rapporto di riempimento è impostato su 0,95, ovvero il 95% della capacità. Si tratta di un valore molto aggressivo per un cluster di test contenente un numero ridotto di OSD.

Suggerimento: aumento della capacità di storage

Durante il monitoraggio del cluster, prestare attenzione agli avvisi relativi alla percentuale nearfull. Ciò indica che nel caso di errori su alcuni OSD, potrebbe verificarsi una temporanea interruzione del servizio. Valutare la possibilità di aggiungere altri OSD per aumentare la capacità di storage.

In uno scenario comune per i cluster di prova, l'amministratore di sistema rimuove un Ceph OSD dal cluster di memorizzazione Ceph per osservare il ribilanciamento del cluster. Quindi, rimuove un altro Ceph OSD e così via fin quando il cluster non raggiunge il rapporto di riempimento e si blocca. Si consiglia di eseguire la pianificazione della capacità anche per il cluster di prova. In questo modo, sarà possibile calcolare la capacità di riserva necessaria per mantenere un'elevata disponibilità. Idealmente, è consigliabile pianificare una serie di errori dei Ceph OSD durante cui sia possibile recuperare il cluster e ripristinarlo allo stato active + clean senza sostituire immediatamente i Ceph OSD con errori. Anche se è possibile eseguire un cluster nello stato active + degraded, non è l'ideale per un normale funzionamento.

Nel diagramma seguente viene illustrato un cluster di memorizzazione Ceph semplificato che contiene 33 nodi Ceph e un Ceph OSD per host, ciascuno in grado di eseguire operazioni di lettura e scrittura su un'unità da 3 TB. La capacità effettiva di questo cluster di esempio è di 99 TB. L'opzione mon osd full ratio è impostata a 0,95. Se il cluster raggiunge i 5 TB di capacità rimanente, non consentirà ai client di leggere e scrivere dati. Di conseguenza, la capacità operativa del cluster di memorizzazione è 95 TB, non 99 TB.

Figura 12.1: Cluster Ceph #

 

In tale cluster, è normale che si verifichino errori su uno o due OSD. In uno scenario meno frequente ma possibile, può verificarsi un errore del router o dell'alimentazione del rack che causa la disattivazione simultanea di più OSD (ad esempio degli OSD da 7 a 12). In tale scenario, è consigliabile comunque puntare ad avere un cluster in grado di restare operativo e raggiungere lo stato active + clean, anche se ciò comporta l'aggiunta di alcuni host con ulteriori OSD in tempi brevi. Se l'utilizzo della capacità è troppo elevato, potrebbero verificarsi perdite di dati. Tuttavia, se l'utilizzo della capacità del cluster supera il rapporto di riempimento, è comunque preferibile scendere a compromessi sulla disponibilità dei dati per risolvere un'interruzione all'interno di un dominio di errore. Per questo motivo, si consiglia di effettuare una pianificazione seppur approssimativa della capacità.

Identificare due numeri per il cluster:

Se si divide la capacità totale del cluster per il numero di OSD contenuti, è possibile individuare la capacità media di un OSD del cluster. Moltiplicare questo numero per il numero di OSD su cui si prevede che si verificheranno errori in simultanea durante il normale funzionamento (un numero relativamente ridotto). Moltiplicare poi la capacità del cluster per il rapporto di riempimento fino a raggiungere la capacità operativa massima. Infine, sottrarre la quantità di dati degli OSD su cui si prevede che si verificheranno errori fino a raggiungere un rapporto di riempimento ragionevole. Ripetere la procedura indicata con un numero più elevato di errori sugli OSD (un rack di OSD) fino a ottenere un numero ragionevole per un rapporto di riempimento quasi completo.

Le impostazioni seguenti si applicano soltanto durante la creazione del cluster e vengono quindi memorizzate nella mappa OSD:

[global]
 mon osd full ratio = .80
 mon osd backfillfull ratio = .75
 mon osd nearfull ratio = .70

Suggerimento

Queste impostazioni si applicano soltanto durante alla creazione del cluster. In seguito, è necessario modificarle nella mappa OSD utilizzando i comandi ceph osd set-nearfull-ratio e ceph osd set-full-ratio.

Suggerimento: verifica del peso dell'OSD

Se alcuni OSD sono nearfull, ma in altri è invece disponibile una capacità elevata, potrebbero verificarsi dei problemi con il peso CRUSH per gli OSD nearfull.

Per ottenere un'elevata disponibilità e un'alta affidabilità occorre adottare un approccio a tolleranza di errore nella gestione dei problemi hardware e software. Ceph non dispone di un single point of failure ed è in grado di provvedere alle richieste di dati nella modalità "degraded" (danneggiata). Il posizionamento dei dati di Ceph introduce un livello di riferimento indiretto per fare in modo che i dati non vengano direttamente associati a specifici indirizzi OSD. Vale a dire che per il controllo degli errori di sistema occorre individuare il gruppo di posizionamento e gli OSD sottostanti alla radice del problema.

Suggerimento: accesso in caso di errore

Gli errori che si verificano in una parte del cluster possono impedire l'accesso a un determinato oggetto, ma non ad altri oggetti. Quando si verifica un errore, seguire la procedura di monitoraggio degli OSD e dei gruppi di posizionamento. Quindi, procedere con la risoluzione dei problemi.

Ceph in genere esegue il ripristino automatico. Tuttavia, se i problemi continuano a verificarsi, il monitoraggio degli OSD e dei gruppi di posizionamento consentirà di identificare il problema.

12.9.1 Monitoraggio degli OSD #

 

Un OSD può essere nello stato "in" (dentro il cluster) o nello stato "out" (fuori dal cluster). Contemporaneamente, può essere "up" (attivo e in esecuzione) o "down" (disattivato e non in esecuzione). Se un OSD è nello stato "up", può trovarsi dentro il cluster (sarà possibile leggere e scrivere i dati) o al di fuori di esso. Se si trovava all'interno del cluster e di recente è stato spostato al di fuori, Ceph eseguirà la migrazione dei gruppi di posizionamento in altri OSD. Se un OSD si trova fuori dal cluster, CRUSH non gli assegnerà alcun gruppo di posizionamento. Se un OSD è nello stato "down", deve essere anche "out".

Nota: stato non integro

Se un OSD è "down" e "in", è presente un problema e il cluster si trova nello stato non integro.

Se si esegue un comando come ceph health ceph -s o ceph -w, è possibile notare che il cluster non rimanda sempre lo stato HEALTH OK. Per quanto riguarda gli OSD, è prevedibile che il cluster non rimanderà lo stato HEALTH OK se:

• Il cluster non è stato ancora avviato (non risponderà).

• Il cluster è stato avviato o riavviato e non è ancora pronto, poiché è in corso la creazione dei gruppi di posizionamento e gli OSD sono in fase di peering.

• Un OSD è stato aggiunto o rimosso.

• La mappa del cluster è stata modificata.

Un aspetto importante del monitoraggio degli OSD consiste nell'assicurarsi che tutti gli OSD dentro il cluster siano attivi e in esecuzione quando lo è il cluster. Per verificare se tutti gli OSD sono in esecuzione, eseguire:

# ceph osd stat
x osds: y up, z in; epoch: eNNNN

Il risultato dovrebbe indicare il numero totale di OSD (x), quanti di questi sono nello stato "up" (y) e nello stato "in" (z) e l'epoca della mappa (eNNNN). Se il numero di OSD dentro il cluster ("in") superiore al numero di OSD attivi ("up"), eseguire il comando seguente per individuare i daemon ceph-osd non in esecuzione:

# ceph osd tree
#ID CLASS WEIGHT  TYPE NAME             STATUS REWEIGHT PRI-AFF
-1       2.00000 pool openstack
-3       2.00000 rack dell-2950-rack-A
-2       2.00000 host dell-2950-A1
0   ssd 1.00000      osd.0                up  1.00000 1.00000
1   ssd 1.00000      osd.1              down  1.00000 1.00000

Ad esempio, se un OSD con ID 1 è inattivo, avviarlo:

cephuser@osd > sudo systemctl start ceph-CLUSTER_ID@osd.0.service

Per informazioni sui problemi associati agli OSD interrotti o che non verranno riavviati, vedere il Book “Troubleshooting Guide”, Chapter 4 “Troubleshooting OSDs”, Section 4.3 “OSDs not running”.

12.9.2 Assegnazione di insiemi di gruppi di posizionamento #

 

Quando CRUSH assegna i gruppi di posizionamento agli OSD, osserva il numero di repliche del pool e assegna il gruppo di posizionamento agli OSD in modo che ogni replica di tale gruppo venga assegnata a un OSD diverso. Ad esempio, se il pool richiede tre repliche di un gruppo di posizionamento, CRUSH potrebbe assegnarle rispettivamente a osd.1, osd.2 e osd.3. CRUSH in realtà individua un posizionamento pseudo-casuale che tiene conto dei domini di errore impostati nella mappa CRUSH. Di conseguenza, in un cluster di grandi dimensioni sarà raro vedere gruppi di posizionamento assegnati agli OSD più vicini. Il set di OSD che deve contenere le repliche di un determinato gruppo di posizionamento viene chiamato acting set. In alcuni casi, un OSD dell'acting set è disattivato oppure non è in grado di provvedere alle richieste relative agli oggetti nel gruppo di posizionamento. In queste situazioni, gli scenari potrebbero essere i seguenti:

• Un OSD è stato aggiunto o rimosso. Quindi, CRUSH ha riassegnato il gruppo di posizionamento agli altri OSD e ha pertanto modificato la composizione dell'acting set, causando la migrazione dei dati con una procedura di "backfill".

• Un OSD era nello stato "down", è stato riavviato ed è in corso di recupero.

• Un OSD nell'acting set si trova nello stato "down" o non è in grado di provvedere alle richieste e un altro OSD ne assume provvisoriamente i compiti.

  Ceph elabora una richiesta client tramite l'up set, ovvero il set degli OSD che provvederanno effettivamente alle richieste. Nella maggior parte dei casi, l'up set e l'acting set sono praticamente identici. Se differiscono, potrebbe significare che Ceph sta eseguendo la migrazione dei dati, che è in corso il recupero di un OSD o che si è verificato un problema (ad esempio, in tali scenari generalmente Ceph rimanda uno stato HEALTH WARN con il messaggio "stuck stale").

Per recuperare un elenco dei gruppi di posizionamento, eseguire:

cephuser@adm > ceph pg dump

Per visualizzare gli OSD che si trovano all'interno dell'acting set o dell'up set per un determinato gruppo di posizionamento, eseguire:

cephuser@adm > ceph pg map PG_NUM
osdmap eNNN pg RAW_PG_NUM (PG_NUM) -> up [0,1,2] acting [0,1,2]

Il risultato dovrebbe indicare l'epoca di osdmap (eNNN), il numero di gruppi di posizionamento (PG_NUM), gli OSD nell'up set ("up") e quelli nell'acting set ("acting"):

Suggerimento: indicatore di problemi nel cluster

Una mancata corrispondenza tra l'up set e l'acting set potrebbe indicare che è in corso il ribilanciamento del cluster o un suo potenziale problema.

12.9.3 Peering #

 

Prima che sia possibile scrivere dati su un gruppo di posizionamento, quest'ultimo deve essere negli stati active e clean. Affinché Ceph possa determinare lo stato corrente di un gruppo di posizionamento, l'OSD primario di tale gruppo (il primo OSD nell'acting set) esegue il peering con gli OSD secondario e terziario per accordarsi sullo stato corrente del gruppo di posizionamento (presupponendo che si tratti di un pool con tre repliche del gruppo di posizionamento).

Figura 12.2: Schema di peering #

 

12.9.4 Monitoraggio degli stati del gruppo di posizionamento #

 

Se si esegue un comando come ceph health, ceph -s o ceph -w, è possibile notare che il cluster non rimanda sempre il messaggio HEALTH OK. Dopo aver verificato che tutti gli OSD siano in esecuzione, controllare anche gli stati del gruppo di posizionamento.

È prevedibile che il cluster non rimanderà lo stato HEALTH OK in alcune circostanze correlate al peering del gruppo di posizionamento:

• È stato creato un pool e non è stato ancora eseguito il peering dei gruppi di posizionamento.

• È in corso il recupero dei gruppi di posizionamento.

• Un OSD è stato aggiunto al cluster o rimosso da quest'ultimo.

• La mappa CRUSH è stata modificata ed è in corso la migrazione dei gruppi di posizionamento.

• Sono presenti dati incoerenti in repliche diverse di un gruppo di posizionamento.

• Ceph sta eseguendo la pulitura delle repliche di un gruppo di posizionamento.

• Ceph non dispone di sufficiente capacità di storage per il completamento delle operazioni di backfill.

Se a causa di una di queste circostanze Ceph rimanda il messaggio HEALTH WARN, non preoccuparsi. In molti casi, il cluster si ripristinerà automaticamente. In alcuni casi, può essere necessario intervenire. Un aspetto importante del monitoraggio dei gruppi di posizionamento consiste nell'assicurarsi che quando un cluster è attivo e in esecuzione, tutti i gruppi di posizionamento siano nello stato "active" e preferibilmente anche in quello "clean state". Per visualizzare lo stato di tutti i gruppi di posizionamento, eseguire:

cephuser@adm > ceph pg stat
x pgs: y active+clean; z bytes data, aa MB used, bb GB / cc GB avail

Il risultato dovrebbe indicare il numero totale di gruppi di posizionamento (x), quanti di questi si trovano in un determinato stato, ad esempio "active+clean" (y), e la quantità di dati memorizzati (z).

Oltre agli stati del gruppo di posizionamento, Ceph rimanderà anche la capacità di storage utilizzata (aa), quella rimanente (bb) e la capacità di storage totale del gruppo di posizionamento. Tali valori possono essere importanti nei casi in cui:

• Ci si sta avvicinando al valore impostato per near full ratio o full ratio.

• I dati non vengono distribuiti nel cluster a causa di un errore nella configurazione CRUSH.

Suggerimento: ID dei gruppi di posizionamento

Gli ID dei gruppi di posizionamento sono costituiti dal numero del pool (e non dal nome) seguito da un punto (.) e dall'ID del gruppo di posizionamento (un numero esadecimale). È possibile visualizzare il numero e il nome del pool dall'output di ceph osd lspools. Ad esempio, il pool di default rbd corrisponde al numero di pool 0. Un ID del gruppo di posizionamento completo è strutturato nel modo seguente:

POOL_NUM.PG_ID

E in genere ha il seguente aspetto:

0.1f

Per recuperare un elenco dei gruppi di posizionamento, eseguire quanto riportato di seguito:

cephuser@adm > ceph pg dump

È inoltre possibile formattare l'output in formato JSON e salvarlo in un file:

cephuser@adm > ceph pg dump -o FILE_NAME --format=json

Per interrogare un determinato gruppo di posizionamento, eseguire quanto riportato di seguito:

cephuser@adm > ceph pg POOL_NUM.PG_ID query

L'elenco seguente descrive in modo dettagliato gli stati dei gruppi di posizionamento più comuni.

CREATING

Quando si crea un pool, quest'ultimo creerà il numero di gruppi di posizionamento specificato. Ceph rimanderà lo stato "creating" durante la creazione di uno o più gruppi di posizionamento. In seguito alla creazione, verrà avviato il peering degli OSD che fanno parte dell'acting set del gruppo di posizionamento. Al completamento del peering, lo stato del gruppo di posizionamento deve essere "active+clean", per indicare che un client Ceph può avviare la scrittura su tale gruppo.

Figura 12.3: Stato dei gruppi di posizionamento #

 

PEERING

Quando Ceph esegue il peering di un gruppo di posizionamento fa in modo che gli OSD che ne memorizzano le repliche concordino sullo stato degli oggetti e dei metadati contenuti nel gruppo. Quando Ceph completa il peering, vuol dire che gli OSD che memorizzano il gruppo di posizionamento concordano sullo stato corrente del gruppo di posizionamento. Tuttavia, il completamento del processo di peering non implica che in ogni replica siano presenti i contenuti più recenti.

Nota: cronologia autorevole

Ceph non riconoscerà le operazioni di scrittura su un client finché tutti gli OSD dell'acting set non le salvano in modo permanente. Questa pratica consente di assicurare che almeno un membro dell'acting set conterrà un record di tutte le operazioni di scrittura riconosciute dall'ultima operazione di peering riuscita.

Tramite un record accurato delle operazioni di scrittura riconosciute, Ceph è in grado di creare e ampliare una nuova cronologia autorevole del gruppo di posizionamento, un set di operazioni completo e in corretta sequenza che, se eseguito, consente di aggiornare la copia dell'OSD di un gruppo di posizionamento.

ACTIVE

Quando Ceph completa il processo di peering, il gruppo di posizionamento può passare allo stato active. Lo stato active indica che i dati nel gruppo di posizionamento sono di norma disponibili all'interno del gruppo di posizionamento primario e nelle repliche delle operazioni di lettura e scrittura.

CLEAN

Quando un gruppo di posizionamento si trova nello stato clean, l'OSD primario e gli OSD di replica hanno eseguito correttamente il peering e non sono presenti repliche residue relative al gruppo di posizionamento. Ceph ha eseguito la replica di tutti gli oggetti nel gruppo di posizionamento per il numero corretto di volte.

DEGRADED

Quando un client scrive un oggetto nell'OSD primario, questo è responsabile della scrittura delle repliche sugli OSD di replica. Quando l'OSD primario scrive l'oggetto nello storage, il gruppo di posizionamento rimane nello stato danneggiato ("degraded") finché gli OSD di replica non confermano all'OSD primario la riuscita della creazione degli oggetti di replica da parte di Ceph.

Il motivo per cui un gruppo di posizionamento può avere lo stato "active+degraded" è il fatto che un OSD può essere nello stato "active" anche se non contiene ancora tutti gli oggetti. Se un OSD diventa disattivato, Ceph contrassegna ciascun gruppo di posizionamento assegnato a tale OSD come "degraded". Quando l'OSD ritorna attivo, gli altri OSD devono ripetere il peering. Tuttavia, un client può comunque scrivere un nuovo oggetto in un gruppo di posizionamento danneggiato se si trova nello stato "active".

Se un OSD è nello stato "down" e la condizione "degraded" persiste, Ceph può contrassegnare l'OSD disattivato come esterno al cluster ("out") e rimappare i dati da questo OSD a un altro OSD. L'intervallo di tempo in cui un OSD viene contrassegnato dallo stato "down" a quello "out" è controllato dall'opzione mon osd down out interval, impostata per default su 600 secondi.

Inoltre, un gruppo di posizionamento può trovarsi nello stato "degraded" se Ceph non riesce a trovare uno o più oggetti al suo interno. Sebbene non sia possibile eseguire operazioni di lettura o scrittura sugli oggetti non trovati, sarà comunque possibile accedere a tutti gli altri oggetti nel gruppo di posizionamento nello stato "degraded".

RECOVERING

Ceph è stato progettato per garantire una tolleranza agli errori su vasta scala in caso di problemi hardware e software. Quando un OSD diventa disattivato, i relativi contenuti potrebbero non essere aggiornati rispetto allo stato corrente delle altre repliche nei gruppi di posizionamento. Quando l'OSD ritorna attivo, i contenuti dei gruppi di posizionamento devono essere aggiornati per riflettere lo stato corrente. Durante questo intervallo di tempo, l'OSD potrebbe riportare lo stato "recovering".

La procedura di recupero non è sempre semplice, perché errori dell'hardware potrebbero causare errori a cascata in più OSD. Ad esempio, potrebbero verificarsi errori su uno switch di rete di un rack o di uno schedario a causa dei quali l'aggiornamento degli OSD di più computer host rispetto allo stato corrente del cluster non va a buon fine. Quando l'errore viene risolto, è necessario recuperare tutti gli OSD.

Ceph fornisce diverse impostazioni per bilanciare il conflitto delle risorse tra le nuove richieste di servizio e la necessità di recuperare gli oggetti dati e ripristinare i gruppi di posizionamento allo stato corrente. L'impostazione osd recovery delay start consente a un OSD di riavviarsi, ripetere il peering e persino elaborare alcune richieste di riproduzione prima di avviare il processo di recupero. L'impostazione osd recovery thread timeout consente di impostare un timeout del thread, poiché più OSD potrebbero generare errori, riavviarsi e ripetere il peering a frequenza sfalsata. L'impostazione osd recovery max active consente di limitare il numero di richieste di recupero che verranno elaborate contemporaneamente da un OSD per impedire errori di gestione delle richieste su tale OSD. L'impostazione osd recovery max chunk consente di limitare le dimensioni delle porzioni di dati recuperate per evitare un traffico eccessivo sulla rete.

BACK FILLING

Se viene aggiunto un nuovo OSD al cluster, CRUSH riassegnerà i gruppi di posizionamento dagli OSD già nel cluster a quello appena aggiunto. Se si forza il nuovo OSD ad accettare immediatamente i gruppi di posizionamento riassegnati, si può generare un carico eccessivo su quest'ultimo. Tramite il backfill dell'OSD con i gruppi di posizionamento, è possibile avviare questa procedura in background. Al completamento del backfill, il nuovo OSD inizierà a provvedere alle richieste quando sarà pronto.

Durante le operazioni di backfill, potrebbero essere visualizzati diversi stati: "backfill_wait" indica che un'operazione di backfill è in sospeso, ma non ancora in corso; "backfill" indica che un'operazione di backfill è in corso; "backfill_too_full" indica che un'operazione di backfill è stata richiesta, ma non è stato possibile completarla perché la capacità di storage è insufficiente. Se non è possibile eseguire il backfill di un gruppo di posizionamento, questo potrebbe essere considerato come incompleto ("incomplete").

In Ceph sono disponibili diverse impostazioni per la gestione del carico associato alla riassegnazione dei gruppi di posizionamento a un OSD (soprattutto ai nuovi OSD). Per default, osd max backfills consente di impostare su 10 il numero massimo di operazioni di backfill simultanee verso o da un OSD. Con backfill full ratio un OSD può rifiutare una richiesta di backfill se sta raggiungendo la percentuale di riempimento (90% per default) e apportare modifiche con il comando ceph osd set-backfillfull-ratio. Se un OSD rifiuta una richiesta di backfill, tramite osd backfill retry interval l'OSD può ripetere la richiesta (per default dopo 10 secondi). Gli OSD possono inoltre impostare i valori osd backfill scan min e osd backfill scan max per gestire gli intervalli di scansione (impostati su 64 e 512 per default).

REMAPPED

Se l'acting set che gestisce un gruppo di posizionamento cambia, viene eseguita la migrazione dei dati dall'acting set precedente all'acting set nuovo. La gestione delle richieste da parte del nuovo OSD primario può richiedere del tempo. Il processo potrebbe quindi chiedere al precedente OSD primario di continuare a provvedere alle richieste fino al completamento della migrazione del gruppo di posizionamento. Al termine della migrazione dei dati, la mappatura utilizza l'OSD primario del nuovo acting set.

STALE

Mentre Ceph utilizza gli heartbeat per verificare che gli host e i daemon siano in esecuzione, i daemon ceph-osd possono passare anche allo stato "stuck" e non segnalare statistiche in modo puntuale (ad esempio, in caso di un errore di rete temporaneo). Per default, i daemon OSD segnalano il relativo gruppo di posizionamento e le statistiche di avvio ed errori ogni mezzo secondo (0,5), ovvero con maggiore frequenza rispetto alle soglie di heartbeat. Se l'OSD primario dell'acting set di un gruppo di posizionamento non riesce a inviare segnalazioni al monitor o se gli altri OSD hanno segnalato l'OSD primario come disattivato, i monitor contrassegneranno il gruppo di posizionamento come inattivo ("stale").

All'avvio del cluster, è normale visualizzare lo stato "stale" fino al completamento del processo di peering. Se il cluster è in esecuzione da un po' di tempo ma i gruppi di posizionamento continuano a essere nello stato "stale", vuol dire che l'OSD primario di tali gruppi di posizionamento è disattivato o non segnala al cluster monitoraggio le statistiche relative al gruppo.

cephuser@adm > ceph osd map POOL_NAME OBJECT_NAME [NAMESPACE]

cephuser@adm > rados put test-object-1 testfile.txt --pool=data

cephuser@adm > rados -p data ls

cephuser@adm > ceph osd map data test-object-1
osdmap e537 pool 'data' (0) object 'test-object-1' -> pg 0.d1743484 \
(0.4) -> up ([1,0], p0) acting ([1,0], p0)

cephuser@adm > rados rm test-object-1 --pool=data

Per modificare la configurazione di un cluster Ceph esistente, seguire la procedura indicata di seguito:

Per aggiungere un nuovo nodo a un cluster Ceph, seguire la procedura indicata di seguito:

Suggerimento: rimozione degli OSD

Se sul nodo da rimuovere sono in esecuzione degli OSD, rimuovere innanzitutto questi ultimi dal nodo e verificare che non ne siano rimasti altri in esecuzione. Per ulteriori dettagli sulla rimozione degli OSD, fare riferimento alla Sezione 13.4.4, «Rimozione degli OSD».

Per rimuovere un nodo da un cluster, procedere come segue:

Importante

In caso di errore e se il minion che si sta tentando di rimuovere è nello stato di disattivazione permanente, sarà necessario rimuovere il nodo dal Salt Master:

root@master # salt-key -d minion_id

Quindi, rimuovere manualmente il nodo da pillar_root/ceph-salt.sls. In genere, questo si trova in /srv/pillar/ceph-salt.sls.

Questa sezione descrive come aggiungere, cancellare o rimuovere gli OSD in un cluster Ceph.

cephuser@adm > ceph orch device ls
HOST       PATH      TYPE SIZE  DEVICE  AVAIL REJECT REASONS
ses-master /dev/vda  hdd  42.0G         False locked
ses-min1   /dev/vda  hdd  42.0G         False locked
ses-min1   /dev/vdb  hdd  8192M  387836 False locked, LVM detected, Insufficient space (<5GB) on vgs
ses-min2   /dev/vdc  hdd  8192M  450575 True

13.4.2 Cancellazione dei dispositivi disco #

 

Per riutilizzare un dispositivo disco, è necessario innanzitutto cancellarlo (o rimuoverlo con zap):

ceph orch device zap HOST_NAME DISK_DEVICE

Esempio:

cephuser@adm > ceph orch device zap ses-min2 /dev/vdc

Nota

Se in precedenza l'utente ha distribuito gli OSD tramite i DriveGroups o l'opzione --all-available-devices mentre il flag unmanaged non era impostato, cephadm distribuirà automaticamente questi OSD in seguito alla loro cancellazione.

13.4.3 Aggiunta di OSD tramite la specifica dei DriveGroups #

 

I DriveGroups specificano i layout degli OSD nel cluster Ceph. Questi ultimi vengono definiti in un singolo file YAML. In questa sezione, verrà utilizzato drive_groups.yml come esempio.

L'amministratore deve specificare manualmente un gruppo di OSD correlati tra di loro (OSD ibridi distribuiti su unità HDD e SDD) o condividere le stesse opzioni di distribuzione (ad esempio lo stesso archivio dati, la stessa opzione di cifratura, gli stessi OSD stand-alone). Per evitare di elencare esplicitamente i dispositivi, i DriveGroups utilizzano un elenco di elementi di filtro che corrispondono ad alcuni campi selezionati dei rapporti di archivio di ceph-volume. In cephadm è fornito un codice che traduce tali DriveGroups in elenchi di dispositivi effettivi che l'utente potrà esaminare.

Il comando da eseguire per applicare la specifica OSD al cluster è:

cephuser@adm > ceph orch apply osd -i drive_groups.yml

Per visualizzare un'anteprima delle azioni e testare l'applicazione, è possibile utilizzare l'opzione --dry-run insieme al comando ceph orch apply osd. Esempio:

cephuser@adm > ceph orch apply osd -i drive_groups.yml --dry-run
...
+---------+------+------+----------+----+-----+
|SERVICE  |NAME  |HOST  |DATA      |DB  |WAL  |
+---------+------+------+----------+----+-----+
|osd      |test  |mgr0  |/dev/sda  |-   |-    |
|osd      |test  |mgr0  |/dev/sdb  |-   |-    |
+---------+------+------+----------+----+-----+

Se l'output di --dry-run soddisfa le aspettative, eseguire nuovamente il comando senza l'opzione --dry-run.

13.4.3.1 OSD non gestiti #

 

Tutti i dispositivi disco puliti disponibili corrispondenti alla specifica dei DriveGroups verranno utilizzati automaticamente come OSD dopo essere stati aggiunti al cluster. Per descrivere questo comportamento si parla di modalità gestita.

Per disabilitare la modalità gestita, aggiungere la riga unmanaged: true alle specifiche pertinenti, ad esempio:

service_type: osd
service_id: example_drvgrp_name
placement:
 hosts:
 - ses-min2
 - ses-min3
encrypted: true
unmanaged: true

Suggerimento

Per modificare gli OSD già distribuiti dalla modalità gestita a quella non gestita, aggiungere le righe unmanaged: true dove applicabile durante la procedura descritta nella Sezione 13.1, «Modifica della configurazione del cluster».

13.4.3.2 Specifica dei DriveGroups #

 

Di seguito è riportato un file della specifica dei DriveGroups di esempio:

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  drive_spec: DEVICE_SPECIFICATION
db_devices:
  drive_spec: DEVICE_SPECIFICATION
wal_devices:
  drive_spec: DEVICE_SPECIFICATION
block_wal_size: '5G'  # (optional, unit suffixes permitted)
block_db_size: '5G'   # (optional, unit suffixes permitted)
encrypted: true       # 'True' or 'False' (defaults to 'False')

Nota

L'opzione precedentemente chiamata "encryption" in DeepSea adesso si chiama "encrypted". Quando si applicano i DriveGroups in SUSE Enterprise Storage 7, assicurarsi di utilizzare questa nuova terminologia nella specifica del servizio, altrimenti ceph orch apply genererà un errore.

13.4.3.3 Creazione di corrispondenze dei dispositivi disco #

 

È possibile descrivere la specifica tramite i filtri seguenti:

• In base al modello di disco:

  model: DISK_MODEL_STRING

• In base al produttore del disco:

  vendor: DISK_VENDOR_STRING

  

  Suggerimento

  Utilizzare sempre caratteri minuscoli quando si immette il valore DISK_VENDOR_STRING.

  Per ottenere dettagli sul produttore e il modello del disco, esaminare l'output del comando seguente:

  cephuser@adm > ceph orch device ls
  HOST     PATH     TYPE  SIZE DEVICE_ID                  MODEL            VENDOR
  ses-min1 /dev/sdb ssd  29.8G SATA_SSD_AF34075704240015  SATA SSD         ATA
  ses-min2 /dev/sda ssd   223G Micron_5200_MTFDDAK240TDN  Micron_5200_MTFD ATA
  [...]

• Per indicare se si tratta di un disco rotativo o meno. Le unità SSD e NVME non sono rotative.

  rotational: 0

• Per distribuire un nodo utilizzando tutte le unità disponibili per gli OSD:

  data_devices:
    all: true

• Inoltre, tramite la limitazione del numero di dischi corrispondenti:

  limit: 10

13.4.3.4 Aggiunta di filtri ai dispositivi in base alle dimensioni #

 

È possibile filtrare i dispositivi disco in base alle dimensioni (valore esatto o intervallo di dimensioni). Il parametro size: accetta gli argomenti nel formato seguente:

• "10G" - include i dischi di dimensioni esatte.

• "10G:40G" - include i dischi di dimensioni comprese nell'intervallo.

• ":10G" - include i dischi di dimensioni inferiori o uguali a 10 GB.

• "40G" - include i dischi di dimensioni uguali o superiori a 40 GB.

Esempio 13.1: Corrispondenza in base alle dimensioni del disco #

 

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  size: '40TB:'
db_devices:
  size: ':2TB'

Nota: virgolette obbligatorie

Quando si utilizza il delimitatore ":", occorre racchiudere le dimensioni tra virgolette altrimenti il simbolo ":" verrà interpretato come un nuovo hash di configurazione.

Suggerimento: scorciatoie di unità

Al posto di Gigabyte (G), è possibile specificare le dimensioni in Megabyte (M) o Terabyte (T).

13.4.3.5 Esempi di DriveGroups #

 

Questa sezione include esempi di diverse configurazioni OSD.

Esempio 13.2: Configurazione semplice #

 

Questo esempio descrive due nodi con la stessa configurazione:

• 20 HDD

  • Produttore: Intel

  • Modello: SSD-123-foo

  • Dimensioni: 4 TB

• 2 SSD

  • Produttore: Micron

  • Modello: MC-55-44-ZX

  • Dimensioni: 512 GB

Il file drive_groups.yml corrispondente avrà l'aspetto seguente:

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
db_devices:
  model: MC-55-44-XZ

Tale configurazione è semplice e valida. Tuttavia, in futuro un amministratore può aggiungere dischi di altri produttori che non verranno inclusi. È possibile ovviare a questo problema riducendo i filtri sulle proprietà di base delle unità:

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  rotational: 1
db_devices:
  rotational: 0

Nell'esempio precedente, viene forzata la dichiarazione di tutti i dispositivi a rotazione come "dispositivi di dati" e tutti i dispositivi non a rotazione verranno utilizzati come "dispositivi condivisi" (wal, db).

Presupponendo che le unità di più di 2 TB saranno sempre i dispositivi di dati più lenti, è possibile applicare dei filtri in base alle dimensioni:

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  size: '2TB:'
db_devices:
  size: ':2TB'

Esempio 13.3: Configurazione avanzata #

 

Questo esempio descrive due configurazioni diverse: 20 HDD devono condividere 2 SSD, mentre 10 SSD devono condividere 2 NVMe.

• 20 HDD

  • Produttore: Intel

  • Modello: SSD-123-foo

  • Dimensioni: 4 TB

• 12 SSD

  • Produttore: Micron

  • Modello: MC-55-44-ZX

  • Dimensioni: 512 GB

• 2 NVMe

  • Produttore: Samsung

  • Modello: NVME-QQQQ-987

  • Dimensioni: 256 GB

È possibile definire tale configurazione con due layout come segue:

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: MC-55-44-XZ

service_type: osd
service_id: example_drvgrp_name2
placement:
  host_pattern: '*'
data_devices:
  model: MC-55-44-XZ
db_devices:
  vendor: samsung
  size: 256GB

Esempio 13.4: Configurazione avanzata con nodi non uniformi #

 

Gli esempi precedenti sono basati sul presupposto che tutti i nodi dispongano delle stesse unità. Tuttavia, non è sempre questo il caso:

Nodi da 1 a 5:

• 20 HDD

  • Produttore: Intel

  • Modello: SSD-123-foo

  • Dimensioni: 4 TB

• 2 SSD

  • Produttore: Micron

  • Modello: MC-55-44-ZX

  • Dimensioni: 512 GB

Nodi da 6 a 10:

• 5 NVMe

  • Produttore: Intel

  • Modello: SSD-123-foo

  • Dimensioni: 4 TB

• 20 SSD

  • Produttore: Micron

  • Modello: MC-55-44-ZX

  • Dimensioni: 512 GB

È possibile utilizzare la chiave "target" nel layout per indirizzare nodi specifici. La notazione della destinazione Salt consente di non complicare la configurazione:

service_type: osd
service_id: example_drvgrp_one2five
placement:
  host_pattern: 'node[1-5]'
data_devices:
  rotational: 1
db_devices:
  rotational: 0

seguito da

service_type: osd
service_id: example_drvgrp_rest
placement:
  host_pattern: 'node[6-10]'
data_devices:
  model: MC-55-44-XZ
db_devices:
  model: SSD-123-foo

Esempio 13.5: Configurazione esperta #

 

In tutti i casi descritti in precedenza si presupponeva che i WAL e i DB utilizzassero lo stesso dispositivo. È tuttavia possibile anche distribuire i WAL su un dispositivo dedicato:

• 20 HDD

  • Produttore: Intel

  • Modello: SSD-123-foo

  • Dimensioni: 4 TB

• 2 SSD

  • Produttore: Micron

  • Modello: MC-55-44-ZX

  • Dimensioni: 512 GB

• 2 NVMe

  • Produttore: Samsung

  • Modello: NVME-QQQQ-987

  • Dimensioni: 256 GB

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  model: MC-55-44-XZ
db_devices:
  model: SSD-123-foo
wal_devices:
  model: NVME-QQQQ-987

Esempio 13.6: Configurazione complessa (e improbabile) #

 

Nella configurazione seguente, si tenterà di definire:

• 20 HDD supportati da 1 NVMe

• 2 HDD supportati da 1 SSD (db) e 1 NVMe (wal)

• 8 SSD supportati da 1 NVMe

• 2 SSD stand-alone (cifrati)

• 1 HDD è di riserva e non deve essere distribuito.

Di seguito è riportato il riepilogo delle unità utilizzate:

• 23 HDD

  • Produttore: Intel

  • Modello: SSD-123-foo

  • Dimensioni: 4 TB

• 10 SSD

  • Produttore: Micron

  • Modello: MC-55-44-ZX

  • Dimensioni: 512 GB

• 1 NVMe

  • Produttore: Samsung

  • Modello: NVME-QQQQ-987

  • Dimensioni: 256 GB

La definizione dei DriveGroups sarà la seguente:

service_type: osd
service_id: example_drvgrp_hdd_nvme
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_hdd_ssd_nvme
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: MC-55-44-XZ
wal_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_ssd_nvme
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
db_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_standalone_encrypted
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
encrypted: True

Rimarrà un'unità HDD, poiché il file viene analizzato dall'alto verso il basso.