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, SUSE introduce il supporto ufficiale per molti scenari in cui si utilizza il CephFS componente 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à "attivo" e il resto "passivo". Ricordare di menzionare tutti i nodi MDS nel comando
mountquando si monta il CephFS da un client.Le snapshot CephFS sono disattivate (default) e non supportate in questa versione.
I client sono basati su SUSE Linux Enterprise Server 12 SP2 o SP3, mediante il driver del modulo kernel
cephfs. Il modulo FUSE non è supportato.Le quote CephFS non sono supportate in SUSE Enterprise Storage, in quanto il supporto per le quote è implementato solo nel client FUSE.
CephFS supporta modifiche del layout del file come documentato in http://docs.ceph.com/docs/jewel/cephfs/file-layouts/. 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.
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 4.3, «Distribuzione del cluster», oppure aggiungerlo a un cluster già distribuito come descritto in Sezione 1.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.
Dimensione cache MDS #
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.
Per un elenco dettagliato delle opzioni di configurazione correlate a MDS, vedere http://docs.ceph.com/docs/master/cephfs/mds-config-ref/.
Per un elenco dettagliato delle opzioni di configurazione "journaler" di MDS, vedere http://docs.ceph.com/docs/master/cephfs/journaler/.
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 7, 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:
root #ceph osd pool create cephfs_data pg_numroot #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:
root # ceph fs new fs_name metadata_pool_name data_pool_nameAd esempio:
root # ceph fs new cephfs cephfs_metadata cephfs_dataÈ possibile controllare che il file system sia stato creato elencando tutti i CephFS disponibili:
root #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:
root #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 13, 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.
root # ceph mds statIl comando seguente imposta il numero di MDS attivi a due in un'istanza del file system.
root # ceph fs set fs_name max_mds 2
Per ridurre il cluster MDS prima di un aggiornamento, sono necessari due passaggi. Primo, impostare max_mds in modo che rimanga solo un'istanza:
root # ceph fs set fs_name max_mds 1disattivare quindi esplicitamente gli altri daemon MDS attivi:
root # 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. Per ulteriori informazioni, vedere http://docs.ceph.com/docs/luminous/cephfs/multimds/.
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 arrestare tutti i daemon di 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 il cluster MDS attivo come descritto sopra a 1 istanza e arrestare tutti i daemon MDS di standby con le unità
systemdsu tutti gli altri nodi:root #systemctl stop ceph-mds\*.service ceph-mds.targetRiavviare quindi solo il singolo daemon MDS rimanente, provocandone il riavvio con il binario aggiornato.
root #systemctl restart ceph-mds\*.service ceph-mds.targetRiavviare tutti gli altri daemon MDS e riconfigurare l'impostazione
max_mdsdesiderata.root #systemctl start ceph-mds.target
Se si utilizza DeepSea, seguire questa procedura nel caso in cui il pacchetto ceph sia stato aggiornato nelle 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.