Conectar clientes NFS

Nesta página, descrevemos como conectar clientes NFS.

Antes de começar

Se você usa um firewall para controlar o tráfego de rede e quer permitir o tráfego NFS, consulte Regras de firewall para acesso a volumes NFS.

Instale as ferramentas do cliente NFS com base no tipo de distribuição Linux para preparar o cliente:

RedHat

Execute este comando:

sudo yum install -y nfs-utils

SuSe

Execute este comando:

sudo yum install -y nfs-utils

Debian

Execute este comando:

sudo apt-get install nfs-common

Ubuntu

Execute este comando:

sudo apt-get install nfs-common

Controle de acesso a volumes usando políticas de exportação

O controle de acesso a volumes no NFSv3 e no NFSv4.1 é baseado no endereço IP do cliente. A política de exportação do volume contém até 20 regras de exportação. Cada regra é uma lista separada por vírgulas de IPs ou CIDRs de rede que definem os clientes permitidos ativados para montar o volume. Uma regra também define o tipo de acesso que os clientes têm, como Leitura e gravação ou Somente leitura.

Use as guias a seguir para revisar as políticas com base nas versões do NFS:

NFS sem Kerberos

Todas as versões do NFS sem Kerberos usam o tipo de segurança AUTH_SYS. Nesse modo, é necessário gerenciar as regras de exportação para permitir apenas clientes confiáveis e que possam garantir a integridade do ID do usuário e do ID do grupo.

Como medida de segurança, os servidores NFS mapeiam automaticamente as chamadas NFS com UID=0 (raiz) para UID=65534 (anônimo), que tem permissões limitadas no sistema de arquivos. Para mais informações, consulte Squash de ID do usuário.

NFSv4.1 com Kerberos

O NFSv4.1 com Kerberos usa políticas de exportação e autenticação adicional com Kerberos para acessar volumes. É possível configurar regras de exportação para aplicar o seguinte:

  • Somente Kerberos (krb5)

  • Assinatura do Kerberos (krb5i)

  • Privacidade do Kerberos (krb5p)

Práticas recomendadas para políticas de exportação

Recomendamos as seguintes práticas recomendadas para políticas de exportação:

  • Ordene as regras de exportação da mais específica para a menos específica.

  • Exporte apenas para os clientes confiáveis, como clientes ou CIDRs específicos com os clientes confiáveis.

  • Limite o acesso raiz a um pequeno grupo de clientes de administração confiáveis.

Regra Clientes permitidos Acesso Acesso raiz Descrição
1 10.10.5.3,
10.10.5.9		 Leitura e gravação Ativado Clientes de administração. O usuário raiz permanece raiz e pode gerenciar
todas as permissões de arquivo.
2 10.10.5.0/24 Leitura e gravação Desativado Todos os outros clientes da rede 10.10.5.0/24 podem ser montados,
mas o acesso raiz é mapeado para ninguém.
3 10.10.6.0/24 Somente leitura Desativado Outra rede pode ler dados do volume, mas
não grava.

Depois que um cliente monta um volume, o acesso no nível do arquivo determina o que um usuário tem permissão para fazer. Para mais informações, consulte Controle de acesso no nível do arquivo NFS para volumes no estilo UNIX.

Gerenciar políticas de exportação

Use as instruções a seguir para atualizar a política de exportação de um volume usando a Google Cloud CLI.

gcloud

Atualizar um volume com uma política de exportação

Atualize um volume com uma regra de política de exportação:

gcloud netapp volumes update VOLUME_ID \
  --project=PROJECT_ID \
  --location=LOCATION \
  --export-policy=access-type=ACCESS_TYPE,allowed-clients=ALLOWED_CLIENTS_IP_ADDRESSES,has-root-access=TRUE_OR_FALSE,nfsv3=NFSV3,nfsv4=NFSV4

Substitua as seguintes informações:

  • VOLUME_ID: o ID do volume.

  • PROJECT_ID: o nome do projeto em que o volume está.

  • LOCATION: o local do volume.

  • ACCESS_TYPE: o tipo de acesso precisa ser READ_WRITE, READ_ONLY ou READ_NONE.

  • ALLOWED_CLIENTS_IP_ADDRESSES: uma lista de endereços IP ou intervalos de clientes permitidos separados por vírgula.

  • NFSV3: definido como true ou false para aplicar essa regra ao NFSv3.

  • NFSV4: definido como true ou false para aplicar essa regra ao NFSv4.

Adicionar várias regras de política de exportação

Para adicionar várias regras de exportação, repita o bloco de parâmetros export-policy. Cada bloco de parâmetros export-policy consiste em vários pares de chave-valor no formato a seguir:

--export-policy=KEY1=VALUE1,KEY2=VALUE2,KEY3=VALUE3...

Exemplo: usar dois pontos e vírgula como separador

Se você especificar vários endereços IP ou CIDRs para allowed-clients, a Google Cloud CLI poderá não analisar os valores corretamente porque a flag --export-policy usa vírgulas como separador padrão entre chaves diferentes, como access-type e nfsv3. Se um valor, como allowed-clients, também contiver vírgulas, o analisador não poderá distinguir entre um novo par de chave-valor e um endereço IP adicional na lista allowed-clients. Para distinguir essas vírgulas, configure a Google Cloud CLI para usar um separador de parâmetros diferente com a saída da Google Cloud CLI.

O comando a seguir mostra o exemplo de Práticas recomendadas para políticas de exportação. A primeira regra usa dois pontos como separador de parâmetros para analisar corretamente a lista allowed-clients separada por vírgulas. A segunda e a terceira regras usam a vírgula padrão como separador.

gcloud netapp volumes update my_volume --location=us-east4 \
--export-policy=^:^access-type=READ_WRITE:allowed-clients="10.10.5.3,10.10.5.9":nfsv3=true:nfsv4=true:has-root-access=true \
--export-policy=access-type=READ_WRITE,allowed-clients=10.0.5.0/24,nfsv3=true,has-root-access=false \
--export-policy=access-type=READ_ONLY,allowed-clients=10.0.6.0/24,nfsv3=true,has-root-access=false

Exemplo: usar squash-mode como parâmetro

O exemplo a seguir usa o parâmetro alternativo squash-mode para criar uma regra NO_ROOT_SQUASH para hosts de administrador e uma regra ALL_SQUASH para um intervalo CIDR.

gcloud netapp volumes update my_volume --location=us-east4 \
--export-policy=^:^allowed-clients="10.10.5.3,10.10.5.9":nfsv3=true:access-type=READ_WRITE:squash-mode=NO_ROOT_SQUASH \
--export-policy=allowed-clients=10.0.2.0/24,nfsv3=true,access-type=READ_WRITE,squash-mode=ALL_SQUASH,anon-uid=2000

Para mais informações sobre outras flags opcionais, consulte SDK Google Cloud para política de exportação de volumes.

Squash de ID do usuário

As políticas de exportação do NFS fornecem controles para o squash de ID do usuário e do grupo, que permite remapear IDs de usuário e grupo para um ID de usuário anônimo para fins de segurança.

Root squash

Os servidores NFS melhoram a segurança ao remapear o usuário raiz (UID=0) para ninguém (UID=65534), o que torna a raiz um usuário sem privilégios para acesso a arquivos no volume. Esse recurso é conhecido como root squash. A opção de desativá-lo e manter os privilégios da raiz é chamada de no_root_squash em servidores NFS.

Por padrão, os volumes sem uma política de exportação definida são inacessíveis aos endereços IP do cliente. Ao criar uma regra de política de exportação no Google Cloud console, as configurações padrão incluem acesso de leitura e gravação e root squash. A Google Cloud API, a Google Cloud CLI e o Terraform ofereciam suporte ao controle do root squash usando o has-root-access parâmetro. Embora has-root-access ainda seja aceito, ele foi substituído pelo parâmetro squash-mode.

Como prática recomendada, crie uma regra de exportação dedicada que ative o acesso raiz para seus hosts de administrador confiáveis e desative o acesso raiz para outros clientes. Coloque essa regra primeiro, antes de regras mais genéricas.

Squash de ID do usuário e do grupo

O parâmetro squash-mode fornece controle sobre o squash de IDs de usuário e grupo para um UID anônimo, o que pode ser útil para diretórios públicos de caixa de depósito SFTP. Esse parâmetro também substitui o parâmetro has-root-access e tem suporte na API, na Google Cloud CLI e no Terraform.

O parâmetro squash-mode aceita os seguintes valores:

  • no-root-squash: nesse modo, o usuário raiz permanece raiz e não é remapeado para ninguém (UID=65534).

  • root-squash: essa configuração remapeia o usuário raiz para ninguém.

  • all-squash: essa opção fornece acesso anônimo para todos os usuários, incluindo a raiz. Todos os usuários são remapeados para o UID e o GID especificados pelo parâmetro anon-uid. Ao usar all-squash, também é necessário especificar anon-uid e definir access-type como READ_WRITE.

Considerações

Considere o seguinte para regras de política de exportação com squash mode:

  • Uma política de exportação oferece suporte a apenas uma regra all-squash.

  • Quando all-squash está ativado, o usuário raiz é compactado para anônimo. Isso pode ser substituído por uma regra de maior prioridade que usa no-root-squash.

  • A replicação de volume não é compatível com volumes com uma regra de política de exportação no estilo squash-mode.

  • Para o nível de serviço Flex File, all-squash não muda a propriedade do inode raiz do volume automaticamente. Para fazer isso, adicione uma regra de exportação no-root-squash, permitindo que o usuário raiz use chown para mudar a propriedade do inode raiz para o UID necessário.

  • O parâmetro has-root-access tem suporte. Use has-root-access ou squash-mode, mas não os dois parâmetros simultaneamente.

  • Para o nível de serviço Flex Unified, all-squash não tem suporte.

Instruções de montagem para clientes NFS

Use as instruções a seguir para receber instruções de montagem para clientes NFS usando o Google Cloud console, a Google Cloud CLI ou o modo ONTAP.

Console

  1. Acesse a página NetApp Volumes no Google Cloud console.

    Acessar o NetApp Volumes

  2. Clique em Volumes.

  3. Clique em Mostrar mais.

  4. Selecione Instruções de montagem.

  5. Siga as instruções de montagem mostradas no Google Cloud console.

  6. Identifique o comando de montagem e use as opções de montagem, a menos que a carga de trabalho tenha requisitos específicos de opção de montagem.

    Somente NFSv3: se o aplicativo não usar bloqueios ou se você não tiver configurado os clientes para ativar a comunicação NSM, recomendamos que você adicione a opção de montagem nolock.

gcloud

Consulte as instruções de montagem de um volume:

 gcloud netapp volumes describe VOLUME_NAME \
    --project=PROJECT_ID \
    --location=LOCATION \
    --format="value(mountOptions.instructions)"

Substitua as seguintes informações:

  • VOLUME_NAME: o nome do volume.

  • PROJECT_ID: o nome do projeto em que o volume está.

  • LOCATION: o local do volume.

Para mais informações sobre outras flags opcionais, consulte a documentação do SDK Google Cloud sobre volumes.

Modo ONTAP

Siga estas etapas para identificar o nome do host ou o endereço IP do volume e o caminho de exportação:

  1. Consulte todas as interfaces de rede do serviço data_cifs.

  2. Determine o caminho de exportação, que corresponde ao caminho de junção especificado para o volume.

  3. Crie o caminho de montagem no formato <var>IP</var>:<var>junction-path</var>. Adicione as opções de montagem necessárias.

Depois de identificar os comandos necessários, consulte Modo ONTAP para instruções sobre como enviar comandos ONTAP ao pool de armazenamento.

Instruções adicionais do NFSv4.1

Ao ativar o NFSv4.1 para volumes dos níveis de serviço Flex Unified, Standard, Premium e Extreme, o NFSv4.2 é ativado automaticamente para esses volumes. O comando de montagem do Linux sempre monta a versão mais alta disponível do NFS, a menos que você especifique a versão a ser montada. Se você quiser montar com o NFSv4.1, use o parâmetro -o vers=4.1 no comando de montagem.

No NFSv3, os usuários e grupos são identificados por IDs de usuário (UID) e IDs de grupo (GID) enviados pelo protocolo NFSv3. É importante garantir que o mesmo UID e GID representem o mesmo usuário e grupo em todos os clientes que acessam o volume. O NFSv4 removeu a necessidade de mapeamento explícito de UID e GID usando identificadores de segurança. Os identificadores de segurança são strings formatadas como <username|groupname>@<full_qualified_domain>. Um exemplo de identificador de segurança é bob@example.com. O cliente precisa traduzir os UIDs e GIDs usados internamente em um identificador de segurança antes de enviar uma solicitação NFSv4 ao servidor. O servidor precisa traduzir os identificadores de segurança em UIDs e GIDs para uma solicitação recebida e vice-versa para a resposta. A vantagem de usar traduções é que cada cliente e o servidor podem usar UIDs e GIDs internos diferentes. No entanto, a desvantagem é que todos os clientes e o servidor precisam manter uma lista de mapeamento entre UIDs e GIDs e nomes de usuários e grupos. As informações de mapeamento nos clientes podem vir de arquivos locais, como /etc/passwd e /etc/groups, ou de um diretório LDAP. A configuração desse mapeamento é gerenciada por rpc.idmapd, que precisa ser executado no cliente.

No NetApp Volumes, o LDAP precisa fornecer informações de mapeamento, sendo o Active Directory o único servidor LDAP compatível com RFC2307bis. Ao usar o Kerberos para NFSv4, o identificador de segurança armazena principais do Kerberos no formato username@DOMAINNAME, em que DOMAINNAME (em letras maiúsculas) se torna o nome do realm.

IDs numéricos

Para usuários que não querem configurar os mapeamentos de nomes e, em vez disso, usar o NFSv4 como substituto do NFSv3, o NFSv4 introduziu uma opção chamada numeric ID, que envia strings de texto codificadas de UID e GID como identificadores de segurança. Isso simplifica o processo de configuração para os usuários.

É possível verificar a configuração do cliente usando o comando a seguir:

     cat /sys/module/nfs/parameters/nfs4_disable_idmapping

O valor padrão é Y, que ativa IDs numéricos. O NetApp Volumes oferece suporte ao uso de IDs numéricos.

Configurar rpc.idmapd no cliente NFS

Independentemente do tipo de IDs ou identificadores de segurança usados, é necessário configurar rpc.idmapd no cliente NFS. Se você seguiu as instruções de instalação dos utilitários do cliente na seção Antes de começar , ele já estará instalado, mas talvez não esteja em execução. Algumas distribuições iniciam automaticamente o uso de systemd ao montar os primeiros volumes NFS. A configuração mínima necessária para rpc.idmapd é configurar a definição de domínio. Caso contrário, a raiz do usuário será exibida como ninguém com UID=65534 or 4294967295.

Use as instruções a seguir para configurar rpc.idmapd no cliente NFS:

  1. No cliente, abra o arquivo /etc/idmapd.conf e mude o parâmetro de domínio para um dos seguintes:

    • Se o volume não estiver ativado para LDAP, domain = defaultv4iddomain.com.

    • Se o volume estiver ativado para LDAP, domain = <FDQN_of_Windows_Domain>.

  2. Ative as mudanças em rpc.idmapd executando o seguinte comando:

     nfsidmap -c

Suporte ao NFSv4.2

Os níveis de serviço Flex Unified, Standard, Premium e Extreme agora oferecem suporte ao protocolo NFSv4.2, além do NFSv4.1, em volumes que já têm o NFSv4.1 ativado.

Ao montar um volume NFS, o comando de montagem do Linux seleciona automaticamente a versão mais alta disponível do NFS. A montagem de um volume ativado para NFSv4.1 é definida automaticamente como NFSv4.2, a menos que a opção de montagem vers=4.1 seja especificada explicitamente.

O NetApp Volumes oferece suporte a atributos estendidos do NFS xattrs com o NFSv4.2. O uso e as limitações de xattrs, conforme detalhado em TR-4962, também são aplicáveis.

Regras de firewall para acesso a volumes NFS

O NFS usa várias portas para se comunicar entre o cliente e um servidor. Para comunicação entre o Google Compute Engine e o NetApp Volumes, essas portas não são bloqueadas por padrão. Se você usar um firewall, será necessário ativar o acesso às seguintes portas para o CIDR completo do PSA do NetApp Volume ou para os endereços IP de volume individuais:

  • 111 TCP/UDP portmapper

  • 635 TCP/UDP mountd

  • 2049 TCP/UDP nfsd

  • 4045 TCP/UDP nlockmgr (somente para NFSv3)

  • 4046 TCP/UDP status (somente para NFSv3)

Os endereços IP do NetApp Volumes são atribuídos automaticamente do intervalo CIDR atribuído ao serviço durante o peering de rede. Para mais informações, consulte Configurar o acesso a serviços particulares.

Uso de bloqueio consultivo com NFSv3

Se você usar bloqueios consultivos com NFSv3, será necessário executar o daemon rpc.statd no cliente para oferecer suporte ao Network Lock Manager, que funciona com o NFS para fornecer bloqueio de arquivo e registro consultivo no estilo System V pela rede. O cliente NFS precisa abrir uma porta de entrada para rpc.statd receber retornos de chamada do Network Lock Manager. Na maioria das distribuições Linux, rpc.statd é iniciado quando você monta o primeiro compartilhamento NFS. Ele usa uma porta aleatória que pode ser identificada usando o comando rpcinfo -p. Para tornar rpc.statd compatível com firewalls, configure-o para usar uma porta estática.

Para definir portas estáticas para rpc.statd, consulte os seguintes recursos:

Se você não usar bloqueios consultivos do NFSv3 ou o Network Lock Manager, poderá montar os compartilhamentos do NFSv3 com a opção de montagem nolock.

O NFSv4.1 implementa a função de bloqueio no protocolo NFSv4.1, que é executado na conexão TCP iniciada pelo cliente com o servidor NFSv4.1 na porta 2049. O cliente não precisa abrir portas de firewall para tráfego de entrada.

Conectar o Linux ao LDAP

Se você estiver usando grupos estendidos do NFSv3 ou NFSv4.1 com identificadores de segurança, configure o NetApp Volumes para usar o Active Directory como servidor LDAP usando um Active Directory anexado a um pool de armazenamento.

Para manter informações de usuário consistentes entre o cliente e o servidor NFS, talvez seja necessário configurar o cliente para usar o Active Directory como serviço de nome LDAP para informações de usuário e grupo.

Use os seguintes recursos para configurar o LDAP:

Ao usar o NFS Kerberizado, talvez seja necessário usar os guias de implantação mencionados nesta seção para configurar o LDAP e garantir a consistência entre o cliente e o servidor.

A seguir

Conecte volumes de grande capacidade com vários endpoints de armazenamento.