Guida alla distribuzione
- Informazioni sulla Guida
- I SUSE Enterprise Storage
- II Distribuzione e upgrade del cluster
- III Installazione di servizi aggiuntivi
- IV Distribuzione del cluster sopra SUSE CaaS Platform 4 (tecnologia in anteprima)
- A Aggiornamenti alla manutenzione di Ceph basati sulle release intermedie upstream "Nautilus"
- Glossario
- B Aggiornamenti della documentazione
11 Installazione di CephFS #
Il file system Ceph (CephFS) è un file system POSIX compatibile che utilizza un cluster di storage Ceph per memorizzare i dati. CephFS utilizza lo stesso sistema di cluster dei dispositivi di blocco Ceph, storage oggetto Ceph con le API S3 e Swift o associazioni native (librados).
Per utilizzare CephFS, deve essere presente un cluster di storage Ceph in esecuzione e almeno un server metadati Ceph in esecuzione.
11.1 Scenari e guida CephFS supportati #
Con SUSE Enterprise Storage 6, SUSE introduce il supporto ufficiale per molti scenari in cui si utilizza il componente CephFS distribuito e scalato. Questa voce descrive i limiti concreti e fornisce una guida per i casi d'uso suggeriti.
Una distribuzione CephFS supportata deve rispettare questi requisiti:
Almeno un Metadata Server. SUSE consiglia di distribuire diversi nodi con il ruolo MDS. Solo uno sarà
attivoe il restopassivo. Ricordare di menzionare tutti i nodi MON nel comandomountquando si monta il CephFS da un client.I client sono SUSE Linux Enterprise Server 12 SP3 o versioni più recenti o SUSE Linux Enterprise Server 15 o versioni più recenti e utilizzano il driver del modulo
cephfsdel kernel. Il modulo FUSE non è supportato.Le quote CephFS sono supportate in SUSE Enterprise Storage 6 ed è possibile impostarle su qualsiasi sottodirectory del file system Ceph. La quota consente di limitare il numero di
byteofilememorizzati al di sotto del punto specificato nella gerarchia della directory. Per ulteriori informazioni, vedere Sezione 19.6, «Impostazione delle quote CephFS».CephFS supporta modifiche del layout del file come documentato in Sezione 11.3.4, «Layout di file». Tuttavia, mentre il file system è montato da qualsiasi client, i nuovi pool di dati potrebbero non venire aggiunti a un file system CephFS esistente (
ceph mds add_data_pool). Possono essere aggiunti solo mentre il file system non è montato.Almeno un server di metadati. SUSE consiglia di distribuire diversi nodi con il ruolo MDS. Per default, i daemon MDS aggiuntivi iniziano come daemon di
standby, fungendo da backup per l'MDS attivo. Sono inoltre supportati più daemon MDS attivi (fare riferimento alla Sezione 11.3.2, «Dimensione cluster MDS»).
11.2 Metadata Server Ceph #
Il Metadata Server (MDS) Ceph memorizza i metadati per il CephFS. I dispositivi di blocco Ceph e lo storage oggetto Ceph non utilizzano MDS. I MDS consentono agli utenti del file system POSIX di eseguire comandi di base, come ls o find, senza caricare eccessivamente il cluster di storage Ceph.
11.2.1 Aggiunta di un Metadata Server #
È possibile distribuire MDS durante il processo di distribuzione iniziale del cluster come descritto in Sezione 5.3, «Distribuzione del cluster», oppure aggiungerlo a un cluster già distribuito come descritto in Sezione 2.1, «Aggiunta di nuovi nodi cluster».
Dopo aver distribuito MDS, consentire al servizio Ceph OSD/MDS nelle impostazioni del firewall del server dove è distribuito MDS: avviare yast, selezionare › › e nel menu a discesa selezionare . Se per il nodo Ceph MDS non è consentito traffico completo, il montaggio di un file system non riesce, anche se altre operazioni possono funzionare correttamente.
11.2.2 Configurazione di un Metadata Server #
È possibile definire con precisione il comportamento di MDS inserendo opzioni pertinenti nel file di configurazione ceph.conf.
Impostazioni del server di metadati #
- mon force standby active
Se è impostata su "true" (default), i monitor forzano l'attivazione della modalità di riproduzione in standby. Viene impostata nelle sezioni
[mon]o[global].mds cache memory limitIl limite di memoria software (in byte) che il MDS applica per la cache. Gli amministratori devono utilizzare questa invece della precedente impostazione
mds cache size. Il valore predefinito è 1 GB.mds cache reservationLa prenotazione della cache (memoria o nodi) da mantenere per la cache MDS. Il MDS, quando inizia a toccare la prenotazione, revoca le capacità del client finché la dimensione della cache si riduce per ripristinare la riserva. Il default è 0,05.
- mds cache size
Numero di inode da memorizzare nella cache. Un valore pari a 0 (default) indica un numero illimitato. Si consiglia di utilizzare
mds cache memory limitper limitare la quantità di memoria utilizzata dalla cache MDS.- mds cache mid
Punto di inserimento di nuovi elementi nell'LRU della cache (a partire dall'alto). Il valore di default è 0.7.
- mds dir commit ratio
Frazione della directory modificata prima che Ceph esegua il commit tramite un aggiornamento completo al posto di uno parziale. Il valore di default è 0,5.
- mds dir max commit size
Dimensioni massime di un aggiornamento della directory prima che Ceph lo suddivida in transazioni più piccole. Il valore di default è 90 MB.
- mds decay halflife
Half-life della temperatura della cache MDS. Il valore di default è 5.
- mds beacon interval
Frequenza espressa in secondi dei messaggi beacon inviati al monitor. Il valore di default è 4.
- mds beacon grace
Intervallo senza beacon prima che Ceph dichiari lento un MDS e possibilmente lo sostituisca. Il valore di default è 15.
- mds blacklist interval
Permanenza nel black list degli MDS con errori nella mappa OSD. Questa impostazione consente di controllare il tempo di permanenza dei daemon MDS con errori nel black list della mappa OSD. Non influisce sulla permanenza nel back list degli elementi aggiunti manualmente da un amministratore. Ad esempio, il comando
ceph osd blacklist addutilizzerà il tempo di black list di default. Il valore di default è 24 * 60.- mds reconnect timeout
Intervallo di tempo espresso in secondi da attendere per la riconnessione dei client durante il riavvio di MDS. Il valore di default è 45.
- mds tick interval
Frequenza di esecuzione dei task periodici interni da parte di MDS. Il valore di default è 5.
- mds dirstat min interval
Intervallo di tempo minimo espresso in secondi in cui tentare di evitare la propagazione delle statistiche ricorsive nell'albero. Il valore di default è 1.
- mds scatter nudge interval
Rapidità di propagazione delle modifiche dirstat. Il valore di default è 5.
- mds client prealloc inos
Quantità di numeri inode da preallocare per sessione client. Il valore di default è 1000.
- mds early reply
Determina se MDS deve consentire ai client di visualizzare i risultati delle richieste prima di eseguire il commit sul journal. L'impostazione di default è "true".
- mds use tmap
Utilizza la mappa semplice per gli aggiornamenti della directory. L'impostazione di default è "true".
- mds default dir hash
Funzione da utilizzare per l'hashing dei file sui frammenti della directory. Il valore di default è 2 (ovvero "rjenkins").
- mds log skip corrupt events
Determina se MDS deve tentare di ignorare gli eventi del journal danneggiati durante la riproduzione del journal. L'impostazione di default è "false".
- mds log max events
Numero massimo di eventi nel journal prima dell'avvio della limitazione. Impostarla a 1 (default), per disabilitare i limiti.
- mds log max segments
Numero massimo di segmenti (oggetti) nel journal prima dell'avvio della limitazione. Impostarla a -1 per disabilitare i limiti. Il valore di default è 30.
- mds log max expiring
Numero massimo di segmenti da estinguere in parallelo. Il valore di default è 20.
- mds log eopen size
Numero massimo di inode in un evento EOpen. Il valore di default è 100.
- mds bal sample interval
Determina la frequenza di campionamento della temperatura della directory per le decisioni di frammentazione. Il valore di default è 3.
- mds bal replicate threshold
Temperatura massima prima che Ceph tenti di replicare i metadati su altri nodi. Il valore di default è 8000.
- mds bal unreplicate threshold
Temperatura minima prima che Ceph interrompa la replica dei metadati su altri nodi. Il valore di default è 0.
- mds bal split size
Dimensioni massime della directory prima che MDS suddivida un frammento di directory in bit più piccoli. Il valore di default è 10000.
- mds bal split rd
Temperatura di lettura della directory massima prima che Ceph suddivida un frammento di directory. Il valore di default è 25000.
- mds bal split wr
Temperatura di scrittura della directory massima prima che Ceph suddivida un frammento di directory. Il valore di default è 10000.
- mds bal split bits
Numero di bit in base a cui suddividere un frammento di directory. Il valore di default è 3.
- mds bal merge size
Dimensioni minime della directory prima che Ceph tenti di unire i frammenti di directory adiacenti. Il valore di default è 50.
- mds bal interval
Frequenza espressa in secondi degli scambi di workload tra MDS. Il valore di default è 10.
- mds bal fragment interval
Ritardo espresso in secondi tra la capacità di suddivisione o unione di un frammento e l'esecuzione della modifica della frammentazione. Il valore di default è 5.
- mds bal fragment fast factor
Rapporto in base al quale i frammenti possono superare le dimensioni di suddivisione prima che venga eseguita immediatamente una suddivisione ignorando l'intervallo di frammentazione. Il valore di default è 1.5.
- mds bal fragment size max
Dimensioni massime di un frammento prima che eventuali nuove voci vengano rifiutate con ENOSPC. Il valore di default è 100000.
- mds bal idle threshold
Temperatura minima prima che Ceph riesegua la migrazione di un sottoalbero al relativo albero superiore. Il valore di default è 0.
- mds bal mode
Metodo di calcolo del carico MDS:
0 = Ibrido.
1 = Velocità e latenza della richiesta.
2 = Carico della CPU.
Il valore di default è 0.
- mds bal min rebalance
Temperatura minima del sottoalbero prima che Ceph esegua la migrazione. Il valore di default è 0.1.
- mds bal min start
Temperatura minima del sottoalbero prima che Ceph esegua la ricerca di un sottoalbero. Il valore di default è 0.2.
- mds bal need min
Frazione minima delle dimensioni di destinazione di un sottoalbero da accettare. Il valore di default è 0,8.
- mds bal need max
Frazione massima delle dimensioni di destinazione di un sottoalbero da accettare. Il valore di default è 1.2.
- mds bal midchunk
Ceph eseguirà la migrazione dei sottoalberi superiori a tale frazione delle dimensioni di destinazione del sottoalbero. Il valore di default è 0.3.
- mds bal minchunk
Ceph ignorerà i sottoalberi inferiori a tale frazione delle dimensioni di destinazione del sottoalbero. Il valore di default è 0,001.
- mds bal target removal min
Numero minimo di iterazioni del servizio di bilanciamento prima che Ceph rimuova una destinazione MDS meno recente dalla mappa MDS. Il valore di default è 5.
- mds bal target removal max
Numero massimo di iterazioni del servizio di bilanciamento prima che Ceph rimuova una destinazione MDS meno recente dalla mappa MDS. Il valore di default è 10.
- mds replay interval
Intervallo di polling del journal quando in modalità di riproduzione in standby ("hot standby"). Il valore di default è 1.
- mds shutdown check
Intervallo di polling della cache durante la chiusura di MDS. Il valore di default è 0.
- mds thrash fragments
Ceph unirà o suddividerà in frammenti le directory in modo casuale. Il valore di default è 0.
- mds dump cache on map
Ceph eseguirà il dump dei contenuti della cache MDS in un file su ciascuna mappa MDS. L'impostazione di default è "false".
- mds dump cache after rejoin
Ceph eseguirà il dump dei contenuti della cache MDS in un file dopo essere rientrato nella cache durante il processo di recupero. L'impostazione di default è "false".
- mds standby for name
Un daemon MDS andrà in standby per un altro daemon MDS il cui nome è specificato in questa impostazione.
- mds standby for rank
Un daemon MDS andrà in standby per un altro daemon MDS di questa classificazione. Il valore di default è -1.
- mds standby replay
Determina se un daemon MDS Ceph deve effettuare il polling e riprodurre il log di un MDS attivo ("hot standby"). L'impostazione di default è "false".
- mds min caps per client
Imposta il numero minimo di capacità che un client può sospendere. Il valore di default è 100.
- mds max ratio caps per client
Imposta il rapporto massimo di capacità correnti che possono essere richiamate durante la pressione della cache MDS. Il valore di default è 0,8.
Impostazioni dell'utilità di journaling del server di metadati #
- journaler write head interval
Frequenza con cui aggiornare l'oggetto di intestazione del journal. Il valore di default è 15.
- journaler prefetch periods
Numero di intervalli di striping per la lettura in avanti durante la riproduzione del journal. Il valore di default è 10.
- journal prezero periods
Numero di intervalli di striping da azzerare prima della posizione di scrittura. Il valore di default è 10.
- journaler batch interval
Latenza aggiuntiva massima espressa in secondi impostata in modo artificiale. Il valore di default è 0,001.
- journaler batch max
Numero massimo di byte in base a cui ritardare lo svuotamento. Il valore di default è 0.
11.3 CephFS #
Se si ha un cluster di storage Ceph in stato corretto con almeno un server metadati Ceph, è possibile creare e montare il file system Ceph. Accertare che il client disponga di connettività di rete e di un corretto portachiavi di autenticazione.
11.3.1 Creazione di CephFS #
Un CephFS richiede almeno due pool RADOS: uno per i dati e uno per i metadati. Quando si configurano tali pool, considerare:
L'utilizzo di un più alto livello di replica per il pool metadati, in quanto eventuali perdite di dati in questo pool possono rendere l'intero file system inaccessibile.
L'utilizzo di storage a più bassa latenza, come i SSD per il pool di metadati, in quanto verrà migliorata la latenza osservata delle operazioni del file system sui client.
Quando si assegna un role-mds in policy.cfg, i pool richiesti vengono creati automaticamente. È possibile creare manualmente i pool cephfs_data e cephfs_metadata per l'ottimizzazione delle prestazioni manuali prima di configurare il Metadata Server. DeepSea non crea questi pool se esistono già.
Per ulteriori informazioni sulla gestione dei pool, vedere Capitolo 11, Gestione di pool di memorizzazione.
Per creare i due pool richiesti, ad esempio "cephfs_data" e "cephfs_metadata", con le impostazioni di default da utilizzare con CephFS, eseguire i comandi indicati:
cephadm@adm >ceph osd pool create cephfs_data pg_numcephadm@adm >ceph osd pool create cephfs_metadata pg_num
È possibile utilizzare i pool EC invece dei pool replicati. Si consiglia di utilizzare solo pool EC per requisiti di basse prestazioni e accesso casuale non frequente, ad esempio storage a freddo, backup, archiviazione. CephFS sui pool EC richiede l'attivazione di BlueStore e il pool deve avere l'opzione allow_ec_overwrite impostata. È possibile impostare questa opzione eseguendo ceph osd pool set ec_pool allow_ec_overwrites true.
La codifica di cancellazione aggiunge significativo overhead alle operazioni del file system, in particolare i piccoli aggiornamenti. Questo overhead è inerente all'impiego della codifica di cancellazione come meccanismo di tolleranza dell'errore. Questa penalità è un compromesso per overhead di spazio di storage sensibilmente ridotto.
Quando si creano i pool, è possibile abilitare il file system con il comando ceph fs new:
cephadm@adm > ceph fs new fs_name metadata_pool_name data_pool_nameAd esempio:
cephadm@adm > ceph fs new cephfs cephfs_metadata cephfs_dataÈ possibile controllare che il file system sia stato creato elencando tutti i CephFS disponibili:
cephadm@adm >cephfs lsname: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]
Dopo aver creato il file system, il MDS sarà in grado di entrare in uno stato attivo. Ad esempio, in un singolo sistema MDS:
cephadm@adm >cephmds state5: 1/1/1 up
Suggerimento: altri argomenti
Ulteriori informazioni su task specifici, ad esempio montaggio, smontaggio e impostazione CephFS avanzata, sono disponibili in Capitolo 19, File system in cluster.
11.3.2 Dimensione cluster MDS #
Un'istanza CephFS può essere servita da più daemon MDS attivi. Tutti i daemon MDS attivi assegnati a un'istanza CephFS distribuiscono la struttura di directory del file system tra di loro e perciò aumentano il carico dei client concorrenti. Per aggiungere un daemon MDS attivo a un'istanza CephFS, ne è necessario uno di standby di riserva. Avviare un daemon aggiuntivo o utilizzare un'istanza standby esistente.
Il comando seguente visualizza il numero corrente di daemon MDS attivi e passivi.
cephadm@adm > ceph mds statIl comando seguente imposta il numero di MDS attivi a due in un'istanza del file system.
cephadm@adm > ceph fs set fs_name max_mds 2
Per ridurre il cluster MDS prima di un aggiornamento, sono necessari due passaggi. Innanzitutto, impostare max_mds in modo che rimanga solo un'istanza:
cephadm@adm > ceph fs set fs_name max_mds 1disattivare quindi esplicitamente gli altri daemon MDS attivi:
cephadm@adm > ceph mds deactivate fs_name:rank
dove rank è il numero di un daemon MDS attivo di un'istanza del file system, compreso tra 0 e max_mds-1.
Si consiglia di lasciare almeno un MDS come daemon di standby.
11.3.3 Aggiornamenti e cluster MDS #
Durante gli aggiornamenti di Ceph, i flag della caratteristica su un'istanza del file system possono cambiare (di solito aggiungendo nuove caratteristiche). I daemon incompatibili (ad esempio le versioni precedenti) non sono in grado di funzionare con una caratteristica incompatibile impostata e rifiutano di avviarsi. Questo significa che l'aggiornamento e il riavvio di un daemon può provocare l'arresto e il rifiuto di avvio di tutti gli altri daemon non ancora aggiornati. Per questo motivo, si consiglia di ridurre il cluster MDS attivo alla dimensione uno e di interrompere tutti i daemon in standby prima di aggiornare Ceph. I passaggi manuali di questa procedura di aggiornamento sono i seguenti:
Aggiornare i pacchetti relativi al Ceph con
zypper.Ridurre a un'istanza il cluster MDS attivo come descritto sopra e interrompere tutti i daemon MDS di standby tramite le relative unità
systemdsu tutti gli altri nodi:cephadm@mds >systemctl stop ceph-mds\*.service ceph-mds.targetRiavviare quindi solo il singolo daemon MDS rimanente, provocandone il riavvio con il binario aggiornato.
cephadm@mds >systemctl restart ceph-mds\*.service ceph-mds.targetRiavviare tutti gli altri daemon MDS e reimpostare l'impostazione
max_mdsdesiderata.cephadm@mds >systemctl start ceph-mds.target
Se si utilizza DeepSea, seguire questa procedura nel caso in cui il pacchetto ceph sia stato aggiornato durante le fasi 0 e 4. È possibile eseguire questa procedura mentre i client hanno l'istanza CephFS montata e l'I/O è in corso. Tenere tuttavia presente che vi sarà una breve pausa di I/O durante il riavvio del MDS. I client si ripristinano automaticamente.
È opportuno ridurre al massimo possibile il carico di I/O prima di aggiornare un cluster MDS. Un cluster MDS inattivo passa più rapidamente attraverso questa procedura di aggiornamento. Al contrario, su un cluster molto carico con più daemon MDS è essenziale ridurre il carico in anticipo per impedire di travolgere un singolo daemon MDS da I/O ininterrotti.
11.3.4 Layout di file #
Tramite il layout dei file è possibile controllare in che modo i relativi contenuti vengono mappati agli oggetti Ceph RADOS. È possibile leggere il e scrivere sul layout di un file utilizzando gli attributi estesi virtuali ( o xattrs).
Il nome degli attributi xattrs di layout è diverso, a seconda se si tratta di un file normale o di una directory. Gli attributi xattrs di layout dei file normali sono denominati ceph.file.layout, mentre quelli delle directory sono chiamati ceph.dir.layout. Laddove negli esempi si fa riferimento a ceph.file.layout, sostituire la parte .dir. come opportuno nel caso delle directory.
11.3.4.1 Campi di layout #
Sono riconosciuti i seguenti campi di attributo:
- pool
ID o nome di un pool RADOS in cui verranno memorizzati gli oggetti dati del file.
- pool_namespace
Spazio dei nomi RADOS all'interno di un pool di dati su verranno scritti gli oggetti. È vuoto per default, per indicare uno spazio dei nomi di default.
- stripe_unit
Dimensioni espresse in byte di un blocco di dati utilizzato nella distribuzione RAID 0 (Striping) di un file. Tutte le unità di striping di un file hanno le stesse dimensioni. L'ultima unità di striping in genere è incompleta: rappresenta i dati nella parte finale del file e lo "spazio" inutilizzato, fino a raggiungere le dimensioni definite per l'unità di striping.
- stripe_count
Numero di unità di striping consecutive che costituiscono uno "segmento" RAID 0 (Striping) dei dati del file.
- object_size
Dimensioni espresse in byte degli oggetti RADOS in cui i dati del file sono suddivisi in porzioni.
Suggerimento: dimensioni oggetto
RADOS applica un limite configurabile alle dimensioni dell'oggetto. Se si aumentano le dimensioni dell'oggetto CephFS oltre tale limite, le operazioni di scrittura potrebbero non riuscire. L'impostazione OSD è
osd_max_object_size, pari a 128 MB per default. Gli oggetti RADOS di dimensioni molto elevate potrebbero impedire un normale svolgimento delle operazioni del cluster, pertanto non si consiglia di aumentare il limite delle dimensioni dell'oggetto oltre quello di default.
11.3.4.2 Lettura del layout con getfattr #
Utilizzare il comando getfattr per leggere come stringa singola le informazioni sul layout di un file file di esempio:
root #touch fileroot #getfattr -n ceph.file.layout file # file: file ceph.file.layout="stripe_unit=4194304 stripe_count=1 object_size=419430
Per leggere i singoli campi di layout:
root #getfattr -n ceph.file.layout.pool file # file: file ceph.file.layout.pool="cephfs_data"root #getfattr -n ceph.file.layout.stripe_unit file # file: file ceph.file.layout.stripe_unit="4194304"
Suggerimento: ID o nome del pool
Durante la lettura dei layout, in genere il pool viene indicato con il nome. Tuttavia, nei rari casi in cui i pool sono appena stati creati, potrebbe venire invece restituito un ID.
Le directory non disporranno di un layout esplicito finché questo non viene personalizzato. Se il layout non è mai stato modificato, i tentativi di lettura non riusciranno e di conseguenza verrà utilizzato il layout della directory antenato successiva con un layout esplicito.
root #mkdir dirroot #getfattr -n ceph.dir.layout dir dir: ceph.dir.layout: No such attributeroot #setfattr -n ceph.dir.layout.stripe_count -v 2 dirroot #getfattr -n ceph.dir.layout dir # file: dir ceph.dir.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 pool=cephfs_data"
11.3.4.3 Scrittura dei layout con setfattr #
Utilizzare il comando setfattr per modificare i campi di layout di un file file di esempio:
cephadm@adm >ceph osd lspools 0 rbd 1 cephfs_data 2 cephfs_metadataroot #setfattr -n ceph.file.layout.stripe_unit -v 1048576 fileroot #setfattr -n ceph.file.layout.stripe_count -v 8 file # Setting pool by ID:root #setfattr -n ceph.file.layout.pool -v 1 file # Setting pool by name:root #setfattr -n ceph.file.layout.pool -v cephfs_data file
Nota: file vuoto
Quando i campi di layout di un file vengono modificati tramite setfattr, questo file deve essere vuoto, altrimenti si verificherà un errore.
11.3.4.4 Cancellazione dei layout #
Se si desidera rimuovere un layout esplicito da una directory mydir di esempio e ripristinare l'ereditarietà del layout del relativo antenato, eseguire quanto riportato di seguito:
root # setfattr -x ceph.dir.layout mydirAllo stesso modo, se è stato impostato l'attributo "pool_namespace" e si desidera modificare il layout per utilizzare invece lo spazio dei nomi di default, eseguire:
# Create a directory and set a namespace on itroot #mkdir mydirroot #setfattr -n ceph.dir.layout.pool_namespace -v foons mydirroot #getfattr -n ceph.dir.layout mydir ceph.dir.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 \ pool=cephfs_data_a pool_namespace=foons" # Clear the namespace from the directory's layoutroot #setfattr -x ceph.dir.layout.pool_namespace mydirroot #getfattr -n ceph.dir.layout mydir ceph.dir.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 \ pool=cephfs_data_a"
11.3.4.5 Ereditarietà dei layout #
Quando vengono creati, i file ereditano il layout della relativa directory superiore. Tuttavia, le successive modifiche al layout della directory superiore non vengono applicate a quelle secondarie:
root #getfattr -n ceph.dir.layout dir # file: dir ceph.dir.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data" # file1 inherits its parent's layoutroot #touch dir/file1root #getfattr -n ceph.file.layout dir/file1 # file: dir/file1 ceph.file.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data" # update the layout of the directory before creating a second fileroot #setfattr -n ceph.dir.layout.stripe_count -v 4 dirroot #touch dir/file2 # file1's layout is unchangedroot #getfattr -n ceph.file.layout dir/file1 # file: dir/file1 ceph.file.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data" # ...while file2 has the parent directory's new layoutroot #getfattr -n ceph.file.layout dir/file2 # file: dir/file2 ceph.file.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"
I file creati come discendenti della directory ereditano anche il suo layout se non è stato impostato nessun layout per le directory intermedie:
root #getfattr -n ceph.dir.layout dir # file: dir ceph.dir.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"root #mkdir dir/childdirroot #getfattr -n ceph.dir.layout dir/childdir dir/childdir: ceph.dir.layout: No such attributeroot #touch dir/childdir/grandchildroot #getfattr -n ceph.file.layout dir/childdir/grandchild # file: dir/childdir/grandchild ceph.file.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"
11.3.4.6 Aggiunta di un pool di dati al server di metadati #
Prima che sia possibile utilizzare un pool con CephFS, è necessario aggiungerlo al server di metadati:
cephadm@adm >ceph fs add_data_pool cephfs cephfs_data_ssdcephadm@adm >ceph fs ls # Pool should now show up .... data pools: [cephfs_data cephfs_data_ssd ]
Suggerimento: chiavi cephx
Assicurarsi che le chiavi cephx in uso consentano al client di accedere a questo nuovo pool.
È quindi possibile aggiornare il layout su una directory in CephFS per utilizzare il pool aggiunto:
root #mkdir /mnt/cephfs/myssddirroot #setfattr -n ceph.dir.layout.pool -v cephfs_data_ssd /mnt/cephfs/myssddir
Tutti i nuovi file creati all'interno di tale directory erediteranno il suo layout e posizioneranno i dati nel pool appena aggiunto. Il numero di oggetti nel pool di dati primario potrebbe continuare ad aumentare, anche se i file vengono creati nel pool appena aggiunto. Si tratta di un comportamento normale: i dati del file vengono memorizzati nel pool specificato dal layout, ma una piccola quantità di metadati viene conservata nel pool di dati primario per tutti i file.