cephx
NFS Ganesha é um servidor NFS (consulte Sharing File Systems with NFS (Compartilhando sistemas de arquivos com o NFS)) executado em um espaço de endereço de usuário, e não como parte do kernel do sistema operacional. Com o NFS Ganesha, você pode conectar seu próprio mecanismo de armazenamento, como Ceph, e acessá-lo de qualquer cliente NFS.
Os compartimentos de memória do S3 são exportados para o NFS por usuário. Por exemplo, usando o caminho NÓ_DO_GANESHA:/NOMEDEUSUÁRIO/NOMEDOCOMPARTIMENTODEMEMÓRIA
.
Por padrão, um CephFS é exportado por meio do caminho NÓ_DO_GANESHA:/cephfs
.
Devido ao aumento da sobrecarga do protocolo e da latência adicional causado por saltos extras de rede entre o cliente e o armazenamento, o acesso ao Ceph por meio de um NFS Gateway pode reduzir significativamente o desempenho do aplicativo quando comparado aos clientes nativos do CephFS ou Object Gateway.
Para obter instruções, consulte o Capítulo 12, Instalação do NFS Ganesha.
Para obter uma lista de todos os parâmetros disponíveis no arquivo de configuração, consulte:
man ganesha-config
man ganesha-ceph-config
para obter as opções da FSAL (File System Abstraction Layer – Camada de Abstração do Sistema de Arquivos) do CephFS.
man ganesha-rgw-config
para obter as opções da FSAL do Object Gateway.
Esta seção inclui informações para ajudar você a configurar o servidor NFS Ganesha para exportar os dados de cluster acessíveis por meio do Object Gateway e do CephFS.
A configuração do NFS Ganesha consiste em duas partes: serviço e exportações. A configuração de serviço é controlada por /etc/ganesha/ganesha.conf
. Observe que as mudanças nesse arquivo serão sobregravadas quando a fase 4 do DeepSea for executada. Para mudar as configurações permanentemente, edite o arquivo /srv/salt/ceph/ganesha/files/ganesha.conf.j2
localizado no master Salt. A configuração de exportações é armazenada no cluster do Ceph como objetos RADOS.
A configuração de serviço é armazenada em /etc/ganesha/ganesha.conf
e controla todas as configurações de daemon do NFS Ganesha, incluindo onde a configuração de exportações é armazenada no cluster do Ceph. Observe que as mudanças nesse arquivo serão sobregravadas quando a fase 4 do DeepSea for executada. Para mudar as configurações permanentemente, edite o arquivo /srv/salt/ceph/ganesha/files/ganesha.conf.j2
localizado no master Salt.
A seção RADOS_URLS
configura o acesso do cluster do Ceph para leitura da configuração do NFS Ganesha dos objetos RADOS.
RADOS_URLS { Ceph_Conf = /etc/ceph/ceph.conf; UserId = "ganesha.MINION_ID"; watch_url = "rados://RADOS_POOL/ganesha/conf-MINION_ID"; }
Local do caminho do arquivo de configuração do Ceph.
O ID de usuário cephx.
O URL do objeto RADOS para observar notificações de recarregamento.
RGW { ceph_conf = "/etc/ceph/ceph.conf"; name = "name"; cluster = "ceph"; }
Aponta para o arquivo ceph.conf
. Durante a implantação com o DeepSea, não é necessário mudar esse valor.
O nome do usuário do cliente Ceph que o NFS Ganesha utiliza.
O nome do cluster do Ceph. Atualmente, o SUSE Enterprise Storage 6 suporta apenas um nome de cluster, que é ceph
por padrão.
%url rados://RADOS_POOL/ganesha/conf-MINION_ID
O NFS Ganesha suporta a leitura da configuração de um objeto RADOS. A diretiva %url
permite especificar um URL RADOS que identifique o local do objeto RADOS.
O URL RADOS pode ter dois formatos: rados://<POOL>/<OBJETO>
ou rados://<POOL>/<NAMESPACE>/<OBJETO>
, em que POOL
é o pool RADOS onde o objeto é armazenado, NAMESPACE
é o namespace do pool onde o objeto é armazenado e OBJETO
é o nome do objeto.
Para suportar os recursos de gerenciamento do NFS Ganesha do Ceph Dashboard, você precisa seguir uma convenção de nome do objeto RADOS para cada daemon de serviço. O nome do objeto deve estar no formato conf-MINION_ID
, em que MINION_ID corresponde ao ID do minion Salt do nó em que o serviço está sendo executado.
O DeepSea já se encarrega de gerar corretamente esse URL, e você não precisa fazer nenhuma modificação.
Por padrão, o NFS Ganesha usa a porta 2049 para NFS e 875 para suporte a rquota. Para mudar os números de porta padrão, use as opções NFS_Port
e RQUOTA_Port
na seção NFS_CORE_PARAM
. Por exemplo:
NFS_CORE_PARAM { NFS_Port = 2060; RQUOTA_Port = 876; }
A configuração de exportações é armazenada como objetos RADOS no cluster do Ceph. Cada bloco de exportação é armazenado em seu próprio objeto RADOS denominado export-<id>
, em que <id>
deve corresponder ao atributo Export_ID
da configuração de exportação. A associação entre as exportações e os serviços do NFS Ganesha é feita por meio dos objetos conf-MINION_ID
. Cada objeto de serviço contém uma lista de URLs de RADOS para cada exportação feita por esse serviço. Um bloco de exportação tem a seguinte aparência:
EXPORT { Export_Id = 1; Path = "/"; Pseudo = "/"; Access_Type = RW; Squash = No_Root_Squash; [...] FSAL { Name = CEPH; } }
Para criar o objeto RADOS para o bloco de exportação acima, primeiro precisamos armazenar o código do bloco de exportação em um arquivo. Em seguida, podemos usar a ferramenta RADOS CLI para armazenar o conteúdo do arquivo gravado anteriormente em um objeto RADOS.
cephadm@adm >
rados -p POOL -N NAMESPACE put export-EXPORT_ID EXPORT_FILE
Após criar o objeto de exportação, poderemos associar a exportação a uma instância de serviço adicionando o URL RADOS correspondente do objeto de exportação ao objeto de serviço. As seções a seguir descrevem como configurar um bloco de exportação.
Cada exportação precisa ter um “Export_Id” exclusivo (obrigatório).
Caminho de exportação no pool do CephFS relacionado (obrigatório). Isso permite que os subdiretórios sejam exportados do CephFS.
Caminho de exportação de destino do NFS (obrigatório para NFSv4). Ele define em qual caminho de exportação do NFS os dados exportados estarão disponíveis.
Exemplo: com o valor /cephfs/
e após a execução de
root #
mount GANESHA_IP:/cephfs/ /mnt/
Os dados do CephFS estão disponíveis no diretório /mnt/cephfs/
no cliente.
“RO” para acesso apenas leitura, “RW” para acesso de leitura-gravação e “None” para nenhum acesso.
Se você deixar Access_Type = RW
na seção EXPORT
e limitar o acesso a um cliente específico na seção CLIENT
, outros clientes ainda poderão se conectar. Para desabilitar o acesso a todos os clientes e habilitar o acesso apenas a clientes específicos, defina Access_Type = None
na seção EXPORT
e, em seguida, especifique um modo de acesso menos restritivo para um ou mais clientes na seção CLIENT
:
EXPORT { FSAL { access_type = "none"; [...] } CLIENT { clients = 192.168.124.9; access_type = "RW"; [...] } [...] }
Opção “squash” do NFS.
“Camada de Abstração do Sistema de Arquivos” de exportação. Consulte a Seção 21.2.2.2, “Subseção FSAL”.
EXPORT { [...] FSAL { Name = CEPH; } }
Define o back end que o NFS Ganesha usa. Os valores permitidos são CEPH
para CephFS ou RGW
para Object Gateway. Dependendo da opção, uma role-mds
ou role-rgw
deve ser definida em policy.cfg
.
É possível definir funções personalizadas do NFS Ganesha para nós de cluster. Na sequência, essas funções são atribuídas aos nós em policy.cfg
. As funções permitem o seguinte:
Nós separados do NFS Ganesha para acessar o Object Gateway e o CephFS.
Atribuição de usuários diferentes do Object Gateway a nós do NFS Ganesha.
A existência de usuários diferentes do Object Gateway permite que os nós do NFS Ganesha acessem compartimentos de memória diferentes do S3. É possível usar os compartimentos de memória do S3 para controle de acesso. Nota: Os compartimentos de memória do S3 não devem ser confundidos com os do Ceph usados no Mapa CRUSH.
O seguinte procedimento de exemplo para o master Salt mostra como criar duas funções do NFS Ganesha com usuários diferentes do Object Gateway. Neste exemplo, as funções gold
e silver
são usadas, e o DeepSea já fornece arquivos de configuração de exemplo para elas.
Abra o arquivo /srv/pillar/ceph/stack/global.yml
com o editor de sua preferência. Crie o arquivo se ele não existir.
O arquivo precisa incluir as seguintes linhas:
rgw_configurations: - rgw - silver - gold ganesha_configurations: - silver - gold
Mais tarde, essas funções poderão ser atribuídas em policy.cfg
.
Crie um arquivo /srv/salt/ceph/rgw/users/users.d/gold.yml
e adicione o seguinte conteúdo:
- { uid: "gold1", name: "gold1", email: "gold1@demo.nil" }
Crie um arquivo /srv/salt/ceph/rgw/users/users.d/silver.yml
e adicione o seguinte conteúdo:
- { uid: "silver1", name: "silver1", email: "silver1@demo.nil" }
Agora, os gabaritos para o ganesha.conf
precisam ser criados para cada função. O gabarito original do DeepSea é um bom ponto de partida. Crie duas cópias:
root@master #
cd
/srv/salt/ceph/ganesha/files/root@master #
cp
ganesha.conf.j2 silver.conf.j2root@master #
cp
ganesha.conf.j2 gold.conf.j2
As novas funções exigem chaveiros para acessar o cluster. Para conceder acesso, copie o ganesha.j2
:
root@master #
cp
ganesha.j2 silver.j2root@master #
cp
ganesha.j2 gold.j2
Copie o chaveiro para o Object Gateway:
root@master #
cd
/srv/salt/ceph/rgw/files/root@master #
cp
rgw.j2 silver.j2root@master #
cp
rgw.j2 gold.j2
O Object Gateway também precisa da configuração para as diferentes funções:
root@master #
cd
/srv/salt/ceph/configuration/files/root@master #
cp
ceph.conf.rgw silver.confroot@master #
cp
ceph.conf.rgw gold.conf
Atribua as funções recém-criadas aos nós de cluster em /srv/pillar/ceph/proposals/policy.cfg
:
role-silver/cluster/NODE1.sls role-gold/cluster/NODE2.sls
Substitua NODE1 e NODE2 pelos nomes dos nós aos quais você deseja atribuir as funções.
Execute as Fases de 0 a 4 do DeepSea.
O seguinte procedimento de exemplo para o master Salt mostra como criar duas novas funções diferentes que usam o CephFS e o Object Gateway:
Abra o arquivo /srv/pillar/ceph/rgw.sls
com o editor de sua preferência. Crie o arquivo se ele não existir.
O arquivo precisa incluir as seguintes linhas:
rgw_configurations: ganesha_cfs: users: - { uid: "demo", name: "Demo", email: "demo@demo.nil" } ganesha_rgw: users: - { uid: "demo", name: "Demo", email: "demo@demo.nil" } ganesha_configurations: - ganesha_cfs - ganesha_rgw
Mais tarde, essas funções poderão ser atribuídas em policy.cfg
.
Agora, os gabaritos para o ganesha.conf
precisam ser criados para cada função. O gabarito original do DeepSea é um bom ponto de partida. Crie duas cópias:
root@master #
cd
/srv/salt/ceph/ganesha/files/root@master #
cp
ganesha.conf.j2 ganesha_rgw.conf.j2root@master #
cp
ganesha.conf.j2 ganesha_cfs.conf.j2
Edite o ganesha_rgw.conf.j2
e remova a seção:
{% if salt.saltutil.runner('select.minions', cluster='ceph', roles='mds') != [] %} [...] {% endif %}
Edite o ganesha_cfs.conf.j2
e remova a seção:
{% if salt.saltutil.runner('select.minions', cluster='ceph', roles=role) != [] %} [...] {% endif %}
As novas funções exigem chaveiros para acessar o cluster. Para conceder acesso, copie o ganesha.j2
:
root@master #
cp
ganesha.j2 ganesha_rgw.j2root@master #
cp
ganesha.j2 ganesha_cfs.j2
A linha caps mds = "allow *"
pode ser removida do ganesha_rgw.j2
.
Copie o chaveiro para o Object Gateway:
root@master #
cp
/srv/salt/ceph/rgw/files/rgw.j2 \ /srv/salt/ceph/rgw/files/ganesha_rgw.j2
O Object Gateway precisa da configuração para a nova função:
root@master #
cp
/srv/salt/ceph/configuration/files/ceph.conf.rgw \ /srv/salt/ceph/configuration/files/ceph.conf.ganesha_rgw
Atribua as funções recém-criadas aos nós de cluster em /srv/pillar/ceph/proposals/policy.cfg
:
role-ganesha_rgw/cluster/NODE1.sls role-ganesha_cfs/cluster/NODE1.sls
Substitua NODE1 e NODE2 pelos nomes dos nós aos quais você deseja atribuir as funções.
Execute as Fases de 0 a 4 do DeepSea.
A interface RGW NFS suporta a maioria das operações em arquivos e diretórios, com as seguintes restrições:
Links, incluindo links simbólicos, não são suportados.
Listas de controle de acesso (ACLs, Access Control Lists) do NFS não são suportadas.Propriedade e permissões de usuário e grupo do Unix são suportadas.
Diretórios não podem ser movidos ou renomeados.Você pode mover arquivos entre diretórios.
Apenas E/S de gravação completa e sequencial é suportada.Portanto, as operações de gravação são forçadas a ser uploads. Muitas operações comuns de E/S, como edição de arquivos no local, certamente falharão porque realizam armazenamentos não sequenciais. Há utilitários de arquivo que aparentemente gravam em sequência (por exemplo, algumas versões de tar
do GNU), mas podem falhar por causa de armazenamentos não sequenciais infrequentes. Ao montar usando o NFS, a E/S sequencial de um aplicativo costuma ser forçada a realizar gravações sequenciais no servidor NFS por meio da montagem síncrona (opção -o sync
). Os clientes NFS que não podem montar de maneira síncrona (por exemplo, Microsoft Windows*) não poderão fazer upload de arquivos.
O NFS RGW suporta operações de leitura-gravação apenas para tamanhos de blocos menores do que 4 MB.
Para habilitar e iniciar o serviço NFS Ganesha, execute:
root@minion >
systemctl
enable nfs-ganesharoot@minion >
systemctl
start nfs-ganesha
Reinicie o NFS Ganesha com:
root@minion >
systemctl
restart nfs-ganesha
Quando o NFS Ganesha é iniciado ou reiniciado, ele tem um tempo de espera extra de 90 segundos para o NFS v4. Durante o período extra, as novas solicitações dos clientes são ativamente rejeitadas. Portanto, os clientes podem enfrentar lentidão nas solicitações durante o período extra do NFS.
Mude o nível de depuração padrão NIV_EVENT
editando o arquivo /etc/sysconfig/nfs-ganesha
. Substitua NIV_EVENT
por NIV_DEBUG
ou NIV_FULL_DEBUG
. O aumento do nível de detalhes do registro pode gerar grandes quantidades de dados nos arquivos de registro.
OPTIONS="-L /var/log/ganesha/ganesha.log -f /etc/ganesha/ganesha.conf -N NIV_EVENT"
É necessário reiniciar o serviço ao mudar o nível de registro.
Ao usar o NFS v3, você pode verificar se os compartilhamentos NFS foram exportados no nó do servidor NFS Ganesha:
root@minion >
showmount
-e / (everything)
Para montar o compartilhamento NFS exportado (conforme configurado na Seção 21.2, “Configuração”) em um host de cliente, execute:
root #
mount
-t nfs -o rw,noatime,sync \ nfs_ganesha_server_hostname:/ /path/to/local/mountpoint