Saltar al contenutoSaltar alla navigazione delle pagine: pagina precedente [chiave d’accesso p]/pagina successiva [chiave d’accesso n]
Si applica a SUSE Enterprise Storage 6

12 Installazione di NFS Ganesha

NFS Ganesha fornisce accesso NFS a Object Gateway o a CephFS. In SUSE Enterprise Storage 6, sono supportate le versioni NFS 3 e 4. NFS Ganesha viene eseguito nello spazio utente invece che nello spazio kernel e interagisce direttamente con l'Object Gateway o CephFS.

Avviso
Avviso: accesso su più protocolli

I client CephFS e NFS nativi non sono limitati dai blocchi di file ottenuti tramite Samba e viceversa. I dati delle applicazioni basate sul blocco di file su più protocolli potrebbero risultare danneggiati se l'accesso ai percorsi della condivisione Samba supportati da CephFS viene effettuato in altri modi.

12.1 Preparazione

12.1.1 Informazioni generali

Per installare correttamente NFS Ganesha, occorre aggiungere un role-ganesha a /srv/pillar/ceph/proposals/policy.cfg. Per informazioni, vedere Sezione 5.5.1, «Il file policy.cfg». NFS Ganesha richiede inoltre un role-rgw o un role-mds presente in policy.cfg.

Sebbene sia possibile installare ed eseguire il server NFS Ganesha su un nodo Ceph già esistente, si consiglia di eseguirlo su un host dedicato con accesso al cluster Ceph. Gli host client non fanno in genere parte del cluster, ma devono avere accesso di rete al server NFS Ganesha.

Per abilitare il server NFS Ganesha in qualsiasi punto dopo l'installazione iniziale, aggiungere role-ganesha a policy.cfg e ripetere almeno le fasi 2 e 4 di DeepSea. Per informazioni, vedere Sezione 5.3, «Distribuzione del cluster».

NFS Ganesha è configurato tramite il file /etc/ganesha/ganesha.conf esistente sul nodo NFS Ganesha. Tuttavia, tale file viene sovrascritto ogni volta che si esegue la fase 4 di DeepSea. Perciò si consiglia di modificare il modello utilizzato da Salt, ossia il file /srv/salt/ceph/ganesha/files/ganesha.conf.j2 sul Salt master. Per informazioni sul file di configurazione, vedere Sezione 21.2, «Configurazione».

12.1.2 Riepilogo dei requisiti

Prima di poter eseguire le fasi 2 e 4 di DeepSea per installare NFS Ganesha, occorre soddisfare i seguenti requisiti:

  • Almeno un nodo deve essere assegnato a role-ganesha.

  • È possibile definire solo un role-ganesha per minion.

  • Per il funzionamento, NFS Ganesha richiede un Object Gateway o CephFS.

  • L'NFS basato sul kernel deve essere disabilitato sui minion con il ruolo role-ganesha.

12.2 Installazione di esempio

Questa procedura fornisce un'installazione di esempio che utilizza l'Object Gateway e CephFS File System Abstraction Layers (FSAL) di NFS Ganesha.

  1. Se non è già stato fatto, eseguire le fasi 0 e 1 di DeepSea prima di continuare con questa procedura.

    root@master # salt-run state.orch ceph.stage.0
    root@master # salt-run state.orch ceph.stage.1
  2. Dopo aver eseguito la fase 1 di DeepSea, modificare /srv/pillar/ceph/proposals/policy.cfg e aggiungere la riga

    role-ganesha/cluster/NODENAME

    Sostituire NODENAME con il nome di un nodo nel cluster.

    Accertare inoltre che siano assegnati un role-mds e un role-rgw.

  3. Eseguire almeno le fasi 2 e 4 di DeepSea. Si consiglia l'esecuzione della fase 3 tra le altre due fasi.

    root@master # salt-run state.orch ceph.stage.2
    root@master # salt-run state.orch ceph.stage.3 # optional but recommended
    root@master # salt-run state.orch ceph.stage.4
  4. Controllare che il servizio NFS Ganesha sia in esecuzione sul nodo minion per assicurarsi che NFS Ganesha sia attivo:

    root@master # salt -I roles:ganesha service.status nfs-ganesha
    MINION_ID:
        True

12.3 Configurazione attiva-passiva ad alta disponibilità

Questa sezione fornisce un esempio di come impostare una configurazione attiva-passiva a due nodi dei server NFS Ganesha. La configurazione richiede SUSE Linux Enterprise High Availability Extension. I due nodi sono denominati earth e mars.

Importante
Importante: co-location dei servizi

I servizi che dispongono di una propria tolleranza agli errori e di un proprio bilanciamento del carico non devono essere in esecuzione sui nodi del cluster a cui viene applicata la priorità per i servizi di failover. Pertanto, non eseguire i servizi Ceph Monitor, del server di metadati, iSCSI o Ceph OSD sulle configurazioni a elevata disponibilità.

Per informazioni su SUSE Linux Enterprise High Availability Extension, vedere https://www.suse.com/documentation/sle-ha-15/.

12.3.1 Installazione di base

In questa configurazione earth ha l'indirizzo IP 192.168.1.1 e mars l'indirizzo 192.168.1.2.

Inoltre, vengono utilizzati due indirizzi IP virtuali mobili che consentono ai client di connettersi al servizio indipendentemente dal nodo fisico sul quale è in esecuzione. 192.168.1.10 è utilizzato per amministrazione del cluster con Hawk2 e 192.168.2.1 esclusivamente per esportazioni NFS. Ciò semplifica la successiva applicazione delle limitazioni di sicurezza.

La procedura seguente descrive l'installazione di esempio. Ulteriori informazioni sono disponibili all'indirizzo https://www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/art_sleha_install_quick.html.

  1. Preparare i nodi NFS Ganesha sul Salt master:

    1. Eseguire le fasi 0 e 1 di DeepSea.

      root@master # salt-run state.orch ceph.stage.0
      root@master # salt-run state.orch ceph.stage.1
    2. Assegnare ai nodi earth e mars il role-ganesha in /srv/pillar/ceph/proposals/policy.cfg:

      role-ganesha/cluster/earth*.sls
      role-ganesha/cluster/mars*.sls
    3. Eseguire le fasi da 2 a 4 di DeepSea.

      root@master # salt-run state.orch ceph.stage.2
      root@master # salt-run state.orch ceph.stage.3
      root@master # salt-run state.orch ceph.stage.4
  2. Registrare SUSE Linux Enterprise High Availability Extension su earth e mars.

    root # SUSEConnect -r ACTIVATION_CODE -e E_MAIL
  3. Installare ha-cluster-bootstrap su entrambi i nodi:

    root # zypper in ha-cluster-bootstrap
    1. Inizializzare il cluster su earth:

      root@earth # ha-cluster-init
    2. Lasciare che mars si unisca al cluster:

      root@mars # ha-cluster-join -c earth
  4. Verificare lo stato del cluster. Si dovrebbero vedere due nodi aggiunti al cluster:

    root@earth # crm status
  5. Su entrambi i nodi, disabilitare l'avvio automatico del servizio NFS Ganesha durante il boot:

    root # systemctl disable nfs-ganesha
  6. Avviare la shell crm su earth:

    root@earth # crm configure

    I comandi successivi vengono eseguiti nella shell crm.

  7. Su earth, avviare la shell crm per eseguire i comandi indicati per configurare la risorsa per i daemon NFS Ganesha come cloni del tipo di risorsa systemd:

    crm(live)configure# primitive nfs-ganesha-server systemd:nfs-ganesha \
    op monitor interval=30s
    crm(live)configure# clone nfs-ganesha-clone nfs-ganesha-server meta interleave=true
    crm(live)configure# commit
    crm(live)configure# status
        2 nodes configured
        2 resources configured
    
        Online: [ earth mars ]
    
        Full list of resources:
             Clone Set: nfs-ganesha-clone [nfs-ganesha-server]
             Started:  [ earth mars ]
  8. Creare un IPAddr2 primitivo con la shell crm:

    crm(live)configure# primitive ganesha-ip IPaddr2 \
    params ip=192.168.2.1 cidr_netmask=24 nic=eth0 \
    op monitor interval=10 timeout=20
    
    crm(live)# status
    Online: [ earth mars  ]
    Full list of resources:
     Clone Set: nfs-ganesha-clone [nfs-ganesha-server]
         Started: [ earth mars ]
     ganesha-ip    (ocf::heartbeat:IPaddr2):    Started earth
  9. Per configurare una relazione tra il server NFS Ganesha e l'IP virtuale mobile, si utilizza collocazione e ordinamento.

    crm(live)configure# colocation ganesha-ip-with-nfs-ganesha-server inf: ganesha-ip nfs-ganesha-clone
    crm(live)configure# order ganesha-ip-after-nfs-ganesha-server Mandatory: nfs-ganesha-clone ganesha-ip
  10. Utilizzare il comando mount dal client per assicurare che la configurazione del cluster sia completa:

    root # mount -t nfs -v -o sync,nfsvers=4 192.168.2.1:/ /mnt

12.3.2 Effettuare la pulizia delle risorse

Nel caso di errore di NFS Ganesha in uno dei nodi, ad esempio earth, risolvere il problema ed effettuare la pulizia della risorsa. Solo dopo aver effettuato la pulizia, la risorsa può riposizionarsi in sicurezza su earth in caso di errore di NFS Ganesha su mars.

Per effettuare la pulizia della risorsa:

root@earth # crm resource cleanup nfs-ganesha-clone earth
root@earth # crm resource cleanup ganesha-ip earth

12.3.3 Impostazione della risorsa di ping

In alcune situazioni, il server potrebbe non essere in grado di raggiungere il client a causa di un problema di rete. Una risorsa di ping può rilevare e mitigare questo problema. La configurazione della risorsa è facoltativa.

  1. Definire la risorsa di ping:

    crm(live)configure# primitive ganesha-ping ocf:pacemaker:ping \
            params name=ping dampen=3s multiplier=100 host_list="CLIENT1 CLIENT2" \
            op monitor interval=60 timeout=60 \
            op start interval=0 timeout=60 \
            op stop interval=0 timeout=60

    host_list è un elenco di indirizzi IP separati da spazi. Viene eseguito regolarmente il ping sugli indirizzi IP per controllare eventuali indisponibilità di rete. Se un client deve sempre avere accesso al server NFS, aggiungerlo a host_list.

  2. Creare un clone:

    crm(live)configure# clone ganesha-ping-clone ganesha-ping \
            meta interleave=true
  3. Il comando seguente consente di creare un vincolo per il servizio NFS Ganesha. Forza il servizio a spostarsi su un altro nodo quando host_list non è raggiungibile.

    crm(live)configure# location nfs-ganesha-server-with-ganesha-ping
            nfs-ganesha-clone \
            rule -inf: not_defined ping or ping lte 0

12.3.4 DeepSea e HA di NFS Ganesha

DeepSea non supporta la configurazione HA (alta disponibilità) di NFS Ganesha. Per impedire a DeepSea di andare in errore dopo aver configurato HA di NFS Ganesha, escludere l'avvio e l'interruzione del servizio NFS Ganesha dalla fase 4 di DeepSea:

  1. Copiare /srv/salt/ceph/ganesha/default.sls in /srv/salt/ceph/ganesha/ha.sls.

  2. Rimuovere la voce .service da /srv/salt/ceph/ganesha/ha.sls in modo che abbia l'aspetto seguente:

    include:
    - .keyring
    - .install
    - .configure
  3. Aggiungere la riga seguente a /srv/pillar/ceph/stack/global.yml:

    ganesha_init: ha

12.4 Configurazione attiva-attiva

Questa sezione fornisce un esempio di una configurazione attiva-attiva semplice di NFS Ganesha. Lo scopo di questa configurazione consiste nel distribuire due server NFS Ganesha a un livello superiore dello stesso CephFS esistente. I server saranno due nodi del cluster Ceph con indirizzi separati. I client devono essere distribuiti tra questi ultimi manualmente. Il termine «failover» in questa configurazione indica lo smontaggio e il rimontaggio manuali dell'altro server sul client.

12.4.1 Prerequisiti

Per questa configurazione di esempio, è necessario quanto segue:

  • Cluster Ceph in esecuzione. Vedere la Sezione 5.3, «Distribuzione del cluster» per i dettagli sulla distribuzione e la configurazione del cluster Ceph tramite DeepSea.

  • Almeno un CephFS configurato. Vedere il Capitolo 11, Installazione di CephFS per ulteriori dettagli sulla distribuzione e la configurazione di CephFS.

  • Due nodi del cluster Ceph con NFS Ganesha distribuito. Vedere il Capitolo 12, Installazione di NFS Ganesha per ulteriori dettagli sulla distribuzione di NFS Ganesha.

    Suggerimento
    Suggerimento: utilizzo di server dedicati

    Sebbene i nodi NFS Ganesha possano condividere le risorse con altri servizi correlati a Ceph, si consiglia di utilizzare server dedicati per migliorare le prestazioni.

Dopo aver distribuito i nodi NFS Ganesha, verificare che il cluster sia operativo e che i pool CephFS di default siano presenti:

cephadm@adm > rados lspools
cephfs_data
cephfs_metadata

12.4.2 Configurazione di NFS Ganesha

Controllare che su entrambi i nodi NFS Ganesha si installato il file/etc/ganesha/ganesha.conf. Aggiungere i blocchi seguenti, se non ancora esistenti, al file di configurazione per abilitare RADOS come back-end di recupero di NFS Ganesha.

NFS_CORE_PARAM
{
    Enable_NLM = false;
    Enable_RQUOTA = false;
    Protocols = 4;
}
NFSv4
{
    RecoveryBackend = rados_cluster;
    Minor_Versions = 1,2;
}
CACHEINODE {
    Dir_Chunk = 0;
    NParts = 1;
    Cache_Size = 1;
}
RADOS_KV
{
    pool = "rados_pool";
    namespace = "pool_namespace";
    nodeid = "fqdn"
    UserId = "cephx_user_id";
    Ceph_Conf = "path_to_ceph.conf"
}

È possibile individuare i valori di rados_pool e pool_namespace controllando la riga già esistente nella configurazione del modulo:

%url rados://rados_pool/pool_namespace/...

Il valore dell'opzione nodeid corrisponde all'FQDN del computer e il valore delle opzioni UserId e Ceph_Conf può essere individuato nel blocco RADOS_URLS già esistente.

Le opzioni di NFS precedenti alla versione 4.2 sono disabilitate poiché tali versioni legacy di NFS impediscono la revoca della moratoria in una fase precedente, prolungando di conseguenza un riavvio del server. Inoltre, è disabilitata anche la maggior parte delle funzioni di memorizzazione nella cache di NFS Ganesha poiché le librerie Ceph eseguono già una memorizzazione aggressiva nella cache.

Il back-end di recupero "rados_cluster" memorizza le relative informazioni negli oggetti RADOS. Sebbene non si tratti di un'elevata quantità di dati, è preferibile impostarlo come altamente disponibile. A tal fine, viene utilizzato il pool di metadati CephFS all'interno del quale viene dichiarato un nuovo spazio dei nomi "ganesha" per distinguerlo dagli oggetti CephFS.

Nota
Nota: ID del nodo del cluster

La maggior parte delle impostazioni di configurazione è identica per i due host, tuttavia l'opzione nodeid nel blocco "RADOS_KV" deve essere una stringa univoca per ciascun nodo. Per default, NFS Ganesha imposta nodeid sul nome host del nodo.

Se è necessario utilizzare valori fissi diversi dai nomi host, è possibile ad esempio impostare nodeid = 'a' su un nodo e nodeid = 'b' sull'altro.

12.4.3 Popolamento del database extra del cluster

È necessario verificare che tutti i nodi nel cluster siano consapevoli della reciproca esistenza. Per farlo, ci si serve di un oggetto RADOS condiviso tra gli host. NFS Ganesha utilizza tale oggetto per comunicare lo stato corrente relativamente a una moratoria.

Il pacchetto nfs-ganesha-rados-grace contiene uno strumento a riga di comando per l'interrogazione e la gestione di questo database. Se il pacchetto non è installato su almeno uno dei nodi, installarlo con

root # zypper install nfs-ganesha-rados-grace

Verrà utilizzato il comando per creare il DB e aggiungere entrambi i nodeid. Nell'esempio, i due nodi NFS Ganesha sono denominati ses6min1.example.com e ses6min2.example.com. Su uno degli host NFS Ganesha, eseguire

cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha add ses6min1.example.com
cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha add ses6min2.example.com
cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha
cur=1 rec=0
======================================================
ses6min1.example.com     E
ses6min2.example.com     E

Questa procedura consente di creare il database extra e di aggiungervi "ses6min1.example.com" e "ses6min2.example.com". L'ultimo comando consente di eseguire il dump dello stato corrente. Si presuppone sempre che gli host appena aggiunti applichino la moratoria e di conseguenza viene impostato per entrambi il flag "E". I valori "cur" e "rec" indicano rispettivamente le epoche attuale e di recupero, tramite cui è possibile tenere traccia degli host a cui è consentito eseguire il recupero e quando.

12.4.4 Riavvio dei servizi NFS Ganesha

Su entrambi i nodi NFS Ganesha, riavviare i servizi correlati:

root # systemctl restart nfs-ganesha.service

In seguito al riavvio dei servizi, controllare il database extra:

cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha
cur=3 rec=0
======================================================
ses6min1.example.com
ses6min2.example.com
Nota
Nota: flag "E" cancellato

Notare che il flag "E" è stato cancellato da entrambi i nodi per indicare che questi non applicano più la moratoria e che si trovano adesso in modalità di funzionamento normale.

12.4.5 Conclusioni

Dopo aver completato tutti i passaggi precedenti, è possibile montare l'NFS esportato da uno dei due server NFS Ganesha ed eseguirvi le normali operazioni NFS.

Nella configurazione di esempio si presuppone che se uno dei due server NFS diventa inattivo, verrà riavviato manualmente dall'utente entro 5 minuti. Dopo questo intervallo di tempo, il server di metadati potrebbe annullare la sessione messa in attesa dal client NFS Ganesha e tutto lo stato a questa associato. Se le capacità della sessione vengono annullate prima che il resto del cluster entri nella moratoria, i client del server potrebbero non essere in grado di recuperare tutto il relativo stato.

12.5 ulteriori informazioni

Ulteriori informazioni sono disponibili all'indirizzo Capitolo 21, NFS Ganesha: esportazione dei dati Ceph tramite NFS.