Para implantar o NFS Ganesha com êxito, você precisa adicionar uma função role-ganesha ao /srv/pillar/ceph/proposals/policy.cfg. Para obter os detalhes, consulte a Seção 5.5.1, “Arquivo policy.cfg”. O NFS Ganesha também precisa da role-rgw ou da role-mds no policy.cfg.

Embora seja possível instalar e executar o servidor NFS Ganesha em um nó do Ceph existente, é recomendável executá-lo em um host dedicado com acesso ao cluster do Ceph. Normalmente, os hosts de clientes não fazem parte do cluster, mas eles precisam ter acesso via rede ao servidor NFS Ganesha.

Para habilitar o servidor NFS Ganesha a qualquer momento após a instalação inicial, adicione a role-ganesha ao policy.cfg e reexecute pelo menos as fases 2 e 4 do DeepSea. Para obter os detalhes, consulte a Seção 5.3, “Implantação do cluster”.

O NFS Ganesha é configurado por meio do arquivo /etc/ganesha/ganesha.conf que existe no nó do NFS Ganesha. No entanto, esse arquivo é sobregravado toda vez que a fase 4 do DeepSea é executada. Portanto, recomendamos editar o gabarito usado pelo Salt, que é o arquivo /srv/salt/ceph/ganesha/files/ganesha.conf.j2 no master Salt. Para obter detalhes sobre o arquivo de configuração, consulte o Seção 21.2, “Configuração”.

Os seguintes requisitos devem ser atendidos antes da execução das fases 2 e 4 do DeepSea para instalar o NFS Ganesha:

Nessa configuração, earth tem o endereço IP 192.168.1.1, e mars tem o endereço 192.168.1.2.

Além disso, dois endereços IP virtuais flutuantes são usados, permitindo aos clientes se conectarem ao serviço independentemente do nó físico no qual está sendo executado. 192.168.1.10 é usado para administração do cluster com Hawk2, e 192.168.2.1 é usado exclusivamente para exportações NFS. Isso facilita aplicar as restrições de segurança mais tarde.

O procedimento a seguir descreve a instalação de exemplo. Mais detalhes podem ser encontrados em https://www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/art_sleha_install_quick.html.

Em caso de falha em um dos nós do NFS Ganesha (por exemplo, earth), corrija o problema e limpe o recurso. Apenas depois que o recurso estiver limpo, será possível fazer failback dele para o earth, caso haja falha no mars do NFS Ganesha.

Para limpar o recurso:

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

Pode acontecer de um servidor não conseguir acessar o cliente por causa de um problema de rede. Um recurso de ping pode detectar e minimizar esse problema. A configuração desse recurso é opcional.

O DeepSea não oferece suporte à configuração de HA do NFS Ganesha. Para evitar falha no DeepSea após a configuração de HA do NFS Ganesha, exclua a inicialização e interrupção do serviço NFS Ganesha da fase 4 do DeepSea:

Para nossa configuração de exemplo, você precisa do seguinte:

Após implantar os nós do NFS Ganesha, verifique se o cluster está operante e se os pools padrão do CephFS estão lá:

cephadm@adm > rados lspools
cephfs_data
cephfs_metadata

Verifique se ambos os nós do NFS Ganesha têm o arquivo /etc/ganesha/ganesha.conf instalado. Adicione os seguintes blocos, se eles ainda não existirem, ao arquivo de configuração para habilitar o RADOS como o back end de recuperação do 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"
}

Você pode descobrir os valores para rados_pool e pool_namespace verificando a linha existente na configuração do formato:

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

O valor para a opção nodeid corresponde ao FQDN da máquina, e o valor das opções UserId e Ceph_Conf podem ser encontrados no bloco RADOS_URLS existente.

Como as versões legadas do NFS nos impedem de aumentar o período extra com antecedência e, portanto, prolongar uma reinicialização do servidor, desabilitamos as opções para o NFS anterior à versão 4.2. Desabilitamos também a maior parte do cache do NFS Ganesha, já que as bibliotecas do Ceph já realizam um cache agressivo.

O back end de recuperação “rados_cluster” armazena suas informações nos objetos RADOS. Embora não sejam muitos dados, desejamos que estejam altamente disponíveis. Usamos o pool de metadados do CephFS para essa finalidade e declaramos um novo namespace “ganesha” nele para diferenciá-lo dos objetos CephFS.

Nota: IDs de Nó do Cluster

A maior parte da configuração é idêntica entre os dois hosts, no entanto, a opção nodeid no bloco “RADOS_KV” precisa ser uma string exclusiva para cada nó. Por padrão, o NFS Ganesha define nodeid como o nome de host do nó.

Se você precisa usar valores fixos diferentes dos nomes de host, pode definir nodeid = 'a', por exemplo, em um nó e nodeid = 'b' no outro nó.

Precisamos verificar se todos os nós no cluster se reconhecem. Isso é feito por meio de um objeto RADOS que é compartilhado entre os hosts. O NFS Ganesha usa esse objeto para comunicar o estado atual com relação a um período extra.

O pacote nfs-ganesha-rados-grace contém uma ferramenta de linha de comando para consultar e manipular esse banco de dados. Se o pacote não estiver instalado em pelo menos um dos nós, instale-o com

root # zypper install nfs-ganesha-rados-grace

Usaremos o comando para criar o BD e adicionar os dois nodeids. Em nosso exemplo, os dois nós do NFS Ganesha são denominados ses6min1.example.com e ses6min2.example.com. Em um dos hosts do NFS Ganesha, execute

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

Isso cria o banco de dados extra e adiciona ambos “ses6min1.example.com” e “ses6min2.example.com” a ele. O último comando descarta o estado atual. Os hosts recém-adicionados sempre são considerados para impor o período extra, portanto, os dois têm o flag “E” definido. Os valores “cur” e “rec” mostram as épocas atual e de recuperação, que é como mantemos o controle dos hosts que podem realizar a recuperação e quando.

Em ambos os nós do NFS Ganesha, reinicie os serviços relacionados:

root # systemctl restart nfs-ganesha.service

Após a reinicialização dos serviços, verifique o banco de dados extra:

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

Nota: O Flag “E” foi Limpo

Observe que os flags “E” dos dois nós foram limpos, indicando que não estão mais impondo o período extra e agora estão no modo de operação normal.

Após concluir todas as etapas anteriores, você poderá montar o NFS exportado de um dos dois servidores NFS Ganesha e executar as operações normais do NFS neles.

Nossa configuração de exemplo considera que, se um dos dois servidores NFS Ganesha ficar inativo, você o reiniciará manualmente em 5 minutos. Após 5 minutos, o Servidor de Metadados poderá cancelar a sessão mantida pelo cliente NFS Ganesha e todo o estado associado a ela. Se os recursos da sessão forem cancelados antes que o restante do cluster entre no período extra, os clientes do servidor talvez não possam recuperar todo o estado deles.