O NFS Ganesha concede acesso de NFS ao Object Gateway ou CephFS. No SUSE Enterprise Storage 6, as versões 3 e 4 do NFS são suportadas. O NFS Ganesha é executado no espaço do usuário, em vez do kernel, e interage diretamente com o Object Gateway ou o CephFS.
Os clientes nativos CephFS e NFS não são restritos por bloqueios de arquivos obtidos por meio do Samba, e vice-versa. Os aplicativos que dependem do bloqueio de arquivos compatível com vários protocolos poderão ter os dados corrompidos se os caminhos de compartilhamento do Samba com suporte do CephFS forem acessados por outros meios.
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:
No mínimo, um nó precisa receber a função role-ganesha
.
Você pode definir apenas uma role-ganesha
por minion.
O NFS Ganesha precisa de um Object Gateway ou CephFS para funcionar.
O NFS com base no kernel precisa ser desabilitado nos minions com a função role-ganesha
.
Este procedimento fornece um exemplo de instalação que usa as FSAL (File System Abstraction Layers – Camadas de Abstração do Sistema de Arquivos) do Object Gateway e do CephFS do NFS Ganesha.
Se você não fez isto, execute as fases 0 e 1 do DeepSea antes de continuar esse procedimento.
root@master #
salt-run
state.orch ceph.stage.0root@master #
salt-run
state.orch ceph.stage.1
Após executar a fase 1 do DeepSea, edite o /srv/pillar/ceph/proposals/policy.cfg
e adicione a linha
role-ganesha/cluster/NODENAME
Substitua NODENAME pelo nome de um nó no cluster.
Verifique também se uma role-mds
e uma role-rgw
foram atribuídas.
Execute pelo menos as fases 2 e 4 do DeepSea. É recomendável executar a fase 3 entre elas.
root@master #
salt-run
state.orch ceph.stage.2root@master #
salt-run
state.orch ceph.stage.3 # optional but recommendedroot@master #
salt-run
state.orch ceph.stage.4
Verifique se o NFS Ganesha está ativo confirmando se o serviço NFS Ganesha está em execução no nó do minion:
root@master #
salt
-I roles:ganesha service.status nfs-ganesha MINION_ID: True
Esta seção apresenta um exemplo de como definir uma configuração ativa-passiva de dois nós dos servidores NFS Ganesha. A configuração requer a SUSE Linux Enterprise High Availability Extension. Os dois nós são denominados earth
e mars
.
Os serviços que têm a própria tolerância a falhas e o próprio balanceamento de carga não devem ser executados em nós do cluster com limitação de serviços de failover. Portanto, não execute os serviços Ceph Monitor, Servidor de Metadados, iSCSI ou Ceph OSD em configurações de Alta Disponibilidade.
Para obter detalhes sobre a SUSE Linux Enterprise High Availability Extension, consulte https://www.suse.com/documentation/sle-ha-15/.
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.
Prepare os nós do NFS Ganesha no master Salt:
Execute as fases 0 e 1 do DeepSea.
root@master #
salt-run
state.orch ceph.stage.0root@master #
salt-run
state.orch ceph.stage.1
Atribua aos nós earth
e mars
a função role-ganesha
em /srv/pillar/ceph/proposals/policy.cfg
:
role-ganesha/cluster/earth*.sls role-ganesha/cluster/mars*.sls
Execute as fases de 2 a 4 do DeepSea.
root@master #
salt-run
state.orch ceph.stage.2root@master #
salt-run
state.orch ceph.stage.3root@master #
salt-run
state.orch ceph.stage.4
Registre a SUSE Linux Enterprise High Availability Extension no earth
e no mars
.
root #
SUSEConnect
-r ACTIVATION_CODE -e E_MAIL
Instale o ha-cluster-bootstrap em ambos os nós:
root #
zypper
in ha-cluster-bootstrap
Inicialize o cluster no earth
:
root@earth #
ha-cluster-init
Permita que o mars
ingresse no cluster:
root@mars #
ha-cluster-join
-c earth
Verifique o status do cluster. Você deve ver dois nós adicionados ao cluster:
root@earth #
crm
status
Em ambos os nós, desabilite o início automático do serviço NFS Ganesha no momento da inicialização:
root #
systemctl
disable nfs-ganesha
Inicie o shell do crm
no earth
:
root@earth #
crm
configure
Os próximos comandos são executados no shell do crm.
No earth
, execute o shell do crm para executar os comandos a seguir a fim de configurar o recurso nos daemons do NFS Ganesha como clone do tipo de recurso systemd:
crm(live)configure#
primitive nfs-ganesha-server systemd:nfs-ganesha \ op monitor interval=30scrm(live)configure#
clone nfs-ganesha-clone nfs-ganesha-server meta interleave=truecrm(live)configure#
commitcrm(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 ]
Crie um IPAddr2 primitivo com o shell do crm:
crm(live)configure#
primitive ganesha-ip IPaddr2 \ params ip=192.168.2.1 cidr_netmask=24 nic=eth0 \ op monitor interval=10 timeout=20crm(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
Para configurar um relacionamento entre o servidor NFS Ganesha e o IP Virtual flutuante, usamos colocalização e ordenação.
crm(live)configure#
colocation ganesha-ip-with-nfs-ganesha-server inf: ganesha-ip nfs-ganesha-clonecrm(live)configure#
order ganesha-ip-after-nfs-ganesha-server Mandatory: nfs-ganesha-clone ganesha-ip
Use o comando mount
do cliente para garantir que a configuração do cluster foi concluída:
root #
mount
-t nfs -v -o sync,nfsvers=4 192.168.2.1:/ /mnt
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 earthroot@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.
Defina o recurso de 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
é uma lista de endereços IP separados por caracteres de espaço. Será feito ping regular dos endereços IP para verificar se há interrupções de rede. Se um cliente sempre precisar de acesso ao servidor NFS, adicione-o à host_list
.
Crie um clone:
crm(live)configure#
clone ganesha-ping-clone ganesha-ping \
meta interleave=true
O comando a seguir cria uma restrição para o serviço NFS Ganesha. Ele força o serviço a se mover para outro nó quando a host_list
está inacessível.
crm(live)configure#
location nfs-ganesha-server-with-ganesha-ping
nfs-ganesha-clone \
rule -inf: not_defined ping or ping lte 0
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:
Copie /srv/salt/ceph/ganesha/default.sls
para /srv/salt/ceph/ganesha/ha.sls
.
Remova a entrada .service
do /srv/salt/ceph/ganesha/ha.sls
de modo que fique com esta aparência:
include: - .keyring - .install - .configure
Adicione a seguinte linha a /srv/pillar/ceph/stack/global.yml
:
ganesha_init: ha
Esta seção apresenta um exemplo da configuração ativa-ativa simples do NFS Ganesha. O objetivo é implantar dois servidores NFS Ganesha em camadas sobrepondo o mesmo CephFS existente. Os servidores serão dois nós do cluster do Ceph com endereços separados. Os clientes precisam ser distribuídos entre eles manualmente. O “failover” nessa configuração significa desmontar e remontar manualmente o outro servidor no cliente.
Para nossa configuração de exemplo, você precisa do seguinte:
Cluster do Ceph em execução. Consulte a Seção 5.3, “Implantação do cluster” para obter detalhes sobre como implantar e configurar o cluster do Ceph usando o DeepSea.
Pelo menos um CephFS configurado. Consulte o Capítulo 11, Instalação do CephFS para obter mais detalhes sobre como implantar e configurar o CephFS.
Dois nós do cluster do Ceph com o NFS Ganesha implantado. Consulte o Capítulo 12, Instalação do NFS Ganesha para obter mais detalhes sobre como implantar o NFS Ganesha.
Embora os nós do NFS Ganesha possam compartilhar recursos com outros serviços relacionados do Ceph, recomendamos o uso de servidores dedicados para melhorar o desempenho.
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.
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 nodeid
s. 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.comcephadm@adm >
ganesha-rados-grace -p cephfs_metadata -n ganesha add ses6min2.example.comcephadm@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
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.
Mais informações podem ser encontradas no Capítulo 21, NFS Ganesha: Exportar dados do Ceph pelo NFS.