NFS Ganesha: Exportar dados do Ceph pelo NFS | Guia de Administração

documentation.suse.com › Documentação do SUSE Enterprise Storage 6 › Guia de Administração › Acessando os dados do cluster › NFS Ganesha: Exportar dados do Ceph pelo NFS

ConteúdoConteúdo

Guia de Administração

Navegação←→

Aplica-se a SUSE Enterprise Storage 6

21 NFS Ganesha: Exportar dados do Ceph pelo NFS #

21.1 Instalação
21.2 Configuração
21.3 Funções personalizadas do NFS Ganesha
21.4 Iniciando ou reiniciando o NFS Ganesha
21.5 Definindo o nível de registro
21.6 Verificando o compartilhamento NFS exportado
21.7 Montando o compartilhamento NFS exportado

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.

Nota: Desempenho do NFS Ganesha

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.

21.1 Instalação #

Para obter instruções, consulte o Capítulo 12, Instalação do NFS Ganesha.

21.2 Configuração #

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.

21.2.1 Configuração de serviço #

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.

21.2.1.1 Seção RADOS_URLS #

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";
}

Ceph_Conf: Local do caminho do arquivo de configuração do Ceph.
UserId: O ID de usuário cephx.
watch_url: O URL do objeto RADOS para observar notificações de recarregamento.

21.2.1.2 Seção RGW #

RGW {
  ceph_conf = "/etc/ceph/ceph.conf";
  name = "name";
  cluster = "ceph";
}

ceph_conf: Aponta para o arquivo ceph.conf. Durante a implantação com o DeepSea, não é necessário mudar esse valor.
name: O nome do usuário do cliente Ceph que o NFS Ganesha utiliza.
cluster: O nome do cluster do Ceph. Atualmente, o SUSE Enterprise Storage 6 suporta apenas um nome de cluster, que é ceph por padrão.

21.2.1.3 URL do objeto RADOS #

%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.

21.2.1.4 Mudando as portas padrão do NFS Ganesha #

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;
}

21.2.2 Configuração de exportações #

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.

21.2.2.1 Seção de exportação principal #

Export_Id

Cada exportação precisa ter um “Export_Id” exclusivo (obrigatório).

Path

Caminho de exportação no pool do CephFS relacionado (obrigatório). Isso permite que os subdiretórios sejam exportados do CephFS.

Pseudo

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.

Access_Type

“RO” para acesso apenas leitura, “RW” para acesso de leitura-gravação e “None” para nenhum acesso.

Dica: Limitar Acesso aos Clientes

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";
		[...]
 }
[...]
}

Squash

Opção “squash” do NFS.

FSAL

“Camada de Abstração do Sistema de Arquivos” de exportação. Consulte a Seção 21.2.2.2, “Subseção FSAL”.

21.2.2.2 Subseção FSAL #

EXPORT
{
  [...]
  FSAL {
    Name = CEPH;
  }
}

Nome: 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.

21.3 Funções personalizadas do NFS Ganesha #

É 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.

21.3.1 Usuários diferentes do Object Gateway para NFS Ganesha #

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.j2
root@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.j2
root@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.j2
root@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.conf
root@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.

21.3.2 Separando a FSAL do CephFS e do Object Gateway #

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.j2
root@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.j2
root@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.

21.3.3 Operações suportadas #

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.

21.4 Iniciando ou reiniciando o NFS Ganesha #

Para habilitar e iniciar o serviço NFS Ganesha, execute:

root@minion > systemctl enable nfs-ganesha
root@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.

21.5 Definindo o nível de registro #

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.

21.6 Verificando o compartilhamento NFS exportado #

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)

21.7 Montando o compartilhamento NFS exportado #

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

Imprimir esta página