Perguntas frequentes sobre NFS em Azure NetApp Files

  • Artigo

Este artigo responde a perguntas frequentes sobre o protocolo NFS de Azure NetApp Files.

Quero montar um volume automaticamente quando uma VM do Azure for iniciada ou reinicializada. Como configurar o host para volumes NFS persistentes?

Para que um volume NFS seja montado automaticamente na inicialização ou na reinicialização da VM, adicione uma entrada ao arquivo /etc/fstab no host.

Confira Montar um volume para máquinas virtuais do Windows ou do Linux para obter detalhes.

O Azure NetApp Files dá suporte a qual versão do NFS?

O Azure NetApp Files dá suporte ao NFSv3 e ao NFSv4.1. É possível criar um volume usando qualquer uma das versões do NFS.

O Azure NetApp Files dá suporte oficial ao NFSv4.2?

Atualmente, o Azure NetApp Files não dá suporte oficial ao NFSv4.2 nem aos seus recursos auxiliares (incluindo operações de arquivos esparsos, atributos estendidos e rótulos de segurança). No entanto, a funcionalidade é ativada para o servidor NFS quando o NFSv4.1 é usado, o que significa que os clientes NFS podem fazer a montagem usando o protocolo NFSv4.2 de duas maneiras:

  • Especificar explicitamente vers=4.2, nfsvers=4.2 ou nfsvers=4,minorversion=2 nas opções de montagem.
  • Não especificar uma versão NFS nas opções de montagem e permitir que o cliente NFS negocie com a versão do NFS com maior suporte permitido.

Na maioria dos casos, se um cliente fizer a montagem usando NFSv4.2, nenhum problema será visto. No entanto, alguns clientes podem enfrentar problemas se não derem suporte total ao NFSv4.2 ou à funcionalidade de atributos estendidos do NFSv4.2. Além disso, como o NFSv4.2 não tem suporte no Azure NetApp Files, todos os problemas com o NFSv4.2 estão fora do escopo.

Para evitar problemas com a montagem de clientes do NFSv4.2 e para cumprir a capacidade de suporte, certifique-se de que a versão NFSv4.1 está especificada nas opções de montagem ou na configuração do cliente do NFS está definida para limitar a versão do NFS em NFSv4.1.

Como habilitar o squashing raiz?

É possível especificar se a conta raiz pode acessar o volume ou não usando a política de exportação do volume. Confira Configurar a política de exportação para um volume do NFS para obter detalhes.

Posso usar o mesmo caminho de arquivo para vários volumes?

O mesmo caminho de arquivo pode ser usado para:

  • volumes implantados em regiões diferentes
  • volumes implantados em diferentes zonas de disponibilidade na mesma região

Se estiver usando:

  • volumes regionais (sem zonas de disponibilidade) ou
  • volumes dentro da mesma zona de disponibilidade,

o mesmo caminho de arquivo pode ser usado, no entanto, o caminho de arquivo deve ser exclusivo em cada sub-rede delegada ou atribuído a sub-redes delegadas diferentes.

Para obter mais informações, consulte Criar um volume NFS para o Azure NetApp Files ou Criar um volume de protocolo duplo para o Azure NetApp Files.

Quando tento acessar volumes NFS por meio de um cliente Windows, por que o cliente demora muito para pesquisar pastas e subpastas?

Verifique se CaseSensitiveLookup está habilitado no cliente Windows para acelerar a pesquisa de pastas e subpastas:

  1. Use o seguinte comando do PowerShell para habilitar CaseSensitiveLookup:
    Set-NfsClientConfiguration -CaseSensitiveLookup 1
  2. Monte o volume no Windows Server.
    Exemplo:
    Mount -o rsize=1024 -o wsize=1024 -o mtype=hard \\10.x.x.x\testvol X:*

Como o Azure NetApp Files dá suporte ao bloqueio de arquivos do NFSv 4.1?

Para clientes NFSv4.1, o Azure NetApp Files dá suporte ao mecanismo de bloqueio de arquivos do NFSv4.1 que mantém o estado de todos os bloqueios de arquivo em um modelo baseado em concessão.

Seguindo a RFC 3530, o Azure NetApp Files define um período de concessão único para todos os estados mantidos por um cliente NFS. Se o cliente não renovar sua concessão dentro do período definido, todos os estados associados à concessão do cliente serão liberados pelo servidor.

Por exemplo, se um cliente que monta um volume ficar sem resposta ou falhar além dos tempos limites, os bloqueios serão liberados. O cliente poderá renovar sua concessão de forma explícita ou implícita, executando operações como a leitura de um arquivo.

Um período de carência define um período de processamento especial no qual os clientes poderão tentar recuperar seu estado de bloqueio durante a recuperação de um servidor. O tempo limite padrão para as concessões é de 30 segundos com um período de carência de 45 segundos. Após esse período, a concessão do cliente será liberada.

O Azure NetApp Files também dá suporte à interrupção de bloqueios de arquivos.

Para saber mais sobre o bloqueio de arquivos no Azure NetApp Files, consulte bloqueio de arquivos.

Por que o diretório .snapshot não está visível em um volume NFSv4.1, mas está visível em um volume NFSv3?

Por design, o diretório .snapshot nunca é visível para clientes NFSv4.1. Por padrão, o diretório .snapshot é visível para clientes NFSv3. Para ocultar o diretório .snapshot de clientes NFSv3, edite as propriedades do volume para ocultar o caminho do instantâneo.

Oracle dNFS

Há patches do Oracle necessários com o dNFS?

Importante

Os clientes que usam o Oracle 19c e posterior devem garantir que corrigiram o bug do Oracle 32931941. A maioria dos pacotes de patch usados atualmente pelos clientes do Oracle *não* inclui esse patch. O patch só foi incluído em um subconjunto de pacotes de patch recentes.

Se um banco de dados for exposto a esse bug, é muito provável que as interrupções de rede resultem em blocos fraturados e corrompidos. As interrupções de rede incluem eventos como realocação de ponto de extremidade de armazenamento, realocação de volume e manutenção do serviço de armazenamento. O bloco corrompido pode não ser necessariamente detectado de imediato.

Essa corrupção não é um bug no ONTAP nem no próprio serviço do Azure NetApp Files, mas o resultado de um bug do Oracle dNFS. A resposta a uma E/S de NFS durante determinados eventos de interrupção ou reconfiguração de rede não é tratada da maneira correta. O banco de dados gravará erroneamente um bloco que estava sendo atualizado, quando foi gravado. Em alguns casos, uma substituição posterior desse mesmo bloco corromperá silenciosamente o bloco corrompido. Caso contrário, os processos do banco de dados Oracle eventualmente o detectarão. Um erro deve ser registrado nos logs de Alerta e provavelmente a instância do Oracle será encerrada. Além disso, as operações DBV e RMAN podem detectar o bloco corrompido.

O Oracle publica o documento 1495104.1, que é atualizado continuamente com os patches de dNFS recomendados. Se o banco de dados usar o dNFS, verifique se a equipe do DBA está verificando se há atualizações neste documento.

Importante

Os clientes que usam o Oracle dNFS com o NFSv4.1 em volumes do Azure NetApp Files devem se certificar de executar as ações mencionadas em Há patches necessários para o uso do Oracle dNFS com NFSv4.1?.

Há patches necessários para uso do Oracle dNFS com o NFSv4.1?

Importante

Se os bancos de dados estiverem usando o Oracle dNFS com o NFSv4.1, precisam ser corrigidos quanto aos bugs do Oracle 33132050 e 33676296. Talvez seja necessário solicitar um backport para outras versões do Oracle. Por exemplo, no momento da gravação, esses patches estavam disponíveis para a versão 19.11, mas ainda não para 19.3. Se você mencionar esses números de bug no caso de suporte, os engenheiros de suporte do Oracle saberão o que fazer.

Esse requisito se aplica a sistemas e serviços baseados em ONTAP, em geral, que incluem o ONTAP local e o Azure NetApp Files.

Exemplos dos possíveis problemas se esses patches não forem aplicados:

  1. O banco de dados fica travado nas movimentações do ponto de extremidade de armazenamento de back-end.
  2. O banco de dados fica travado nos eventos de manutenção de serviço do Azure NetApp Files.
  3. O Brief Oracle fica travado durante a operação normal, o que pode ou não ser perceptível.
  4. Desligamentos lentos do Oracle: se você monitorar o processo de desligamento, observará pausas que podem somar minutos de atrasos, à medida que o tempo limite de E/S do dNFS é atingido.
  5. Comportamento incorreto do cache de resposta do dNFS nas leituras que travará um banco de dados.

Os patches incluem uma alteração no gerenciamento de sessão do dNFS e no cache de resposta do NFS, o que resolve esses problemas.

Se você não puder corrigir esses dois bugs, não deverá usar o dNFS com o NFSv4.1. Você pode desabilitar o dNFS ou alternar para o NFSv3.

Posso usar múltiplos caminhos com o Oracle dNFS e o NFSv4.1?

Ao usar o NFSv4.1, o dNFS não funcionará com vários caminhos. Se você precisar de vários caminhos, deverá usar o NFSv3. O dNFS requer o entroncamento de clientID e sessionID em todo o cluster para que o NFSv4.1 funcione com vários caminhos, o que não é compatível com o Azure NetApp Files. Como resultado, você enfrentará um travamento durante a inicialização do dNFS

Próximas etapas