FAQ de NFS para o Azure NetApp Files

  • Artigo

Este artigo responde a perguntas frequentes (FAQs) sobre o protocolo NFS dos Arquivos NetApp do Azure.

Quero ter um volume montado automaticamente quando uma VM do Azure é iniciada ou reinicializada. Como configuro meu host para volumes NFS persistentes?

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

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

Que versão NFS é suportada pelos Ficheiros NetApp do Azure?

Os Arquivos NetApp do Azure dão suporte a NFSv3 e NFSv4.1. Você pode criar um volume usando qualquer versão NFS.

Os Arquivos NetApp do Azure suportam oficialmente NFSv4.2?

Atualmente, os Arquivos NetApp do Azure não oferecem suporte oficial ao NFSv4.2 nem a seus recursos auxiliares (incluindo operações de arquivo esparsas, 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 montar usando o protocolo NFSv4.2 de duas maneiras:

  • Especificando vers=4.2explicitamente , nfsvers=4.2ou 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 para a versão NFS mais alta suportada permitida.

Na maioria dos casos, se um cliente monta usando NFSv4.2, nenhum problema pode ser visto. No entanto, alguns clientes podem ter problemas se não suportarem totalmente a funcionalidade de atributos estendidos NFSv4.2 ou NFSv4.2. Além disso, como o NFSv4.2 não é suportado atualmente com os Arquivos NetApp do Azure, quaisquer problemas com o NFSv4.2 estão fora do escopo.

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

Como faço para ativar o esmagamento de raiz?

Você pode especificar se a conta raiz pode acessar o volume ou não usando a política de exportação do volume. Consulte Configurar política de exportação para um volume 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 diferentes regiões
  • volumes implantados em diferentes zonas de disponibilidade dentro da mesma região

Se estiver a utilizar:

  • 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 do arquivo deve ser exclusivo dentro de cada sub-rede delegada ou atribuído a diferentes sub-redes delegadas.

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

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

Certifique-se de que CaseSensitiveLookup está ativado 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 servidor Windows.
    Exemplo:
    Mount -o rsize=1024 -o wsize=1024 -o mtype=hard \\10.x.x.x\testvol X:*

Como o Azure NetApp Files oferece suporte ao bloqueio de arquivos NFSv4.1?

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

De acordo com a RFC 3530, os Arquivos NetApp do Azure definem um único período de concessão 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 deixar de responder ou falhar além dos tempos limites, os bloqueios serão liberados. O cliente pode renovar sua concessão explícita ou implicitamente 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 podem 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 locação do cliente será liberada.

Os Arquivos NetApp do Azure também dão suporte à quebra de bloqueios de arquivos.

Para saber mais sobre o bloqueio de arquivos nos Arquivos NetApp do Azure, consulte Bloqueio de arquivos.

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

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

Oracle dNFS

Existem patches Oracle necessários com o dNFS?

Importante

Os clientes que usam Oracle 19c e superior devem garantir que eles sejam corrigidos para 32931941 de bugs da Oracle. A maioria dos pacotes de patches atualmente em uso pelos clientes Oracle * não* inclui esse patch. O patch só foi incluído num subconjunto de pacotes de patches recentes.

Se um banco de dados for exposto a esse bug, é altamente provável que interrupções de rede resultem em corrupção de bloco fraturado. As interrupções de rede incluem eventos como realocação de ponto de extremidade de armazenamento, realocação de volume e eventos de manutenção do serviço de armazenamento. A corrupção pode não ser necessariamente detetada imediatamente.

Essa corrupção não é um bug no ONTAP nem no próprio serviço Azure NetApp Files, mas o resultado de um bug do Oracle dNFS. A resposta a uma E/S NFS durante uma determinada interrupção de rede ou eventos de reconfiguração é manipulada incorretamente. O banco de dados gravará erroneamente um bloco que estava sendo atualizado como foi escrito. 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 acabarão detetando-o. Um erro deve ser registrado nos logs de alerta e a instância Oracle provavelmente será encerrada. Além disso, as operações dbv e RMAN podem detetar a corrupção.

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

Importante

Os clientes que usam o Oracle dNFS com NFSv4.1 nos volumes do Azure NetApp Files devem garantir a execução das ações mencionadas em Há algum patch necessário para o uso do Oracle dNFS com NFSv4.1?.

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

Importante

Se seus bancos de dados estiverem usando Oracle dNFS com NFSv4.1, eles precisarão ser corrigidos para bugs da Oracle 33132050 e 33676296. Talvez seja necessário solicitar um backport para outras versões do Oracle. Por exemplo, no momento da redação deste artigo, esses patches estão disponíveis para a versão 19.11, mas ainda não para a versão 19.3. Se você citar esses números de bugs no caso de suporte, os engenheiros de suporte da Oracle sabem o que fazer.

Este requisito aplica-se a sistemas e serviços baseados em ONTAP em geral, o que inclui ONTAP no local e Arquivos NetApp do Azure.

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

  1. O banco de dados trava em movimentos de ponto de extremidade de armazenamento de back-end.
  2. O banco de dados trava em eventos de manutenção do serviço Azure NetApp Files.
  3. Breve Oracle trava durante a operação normal que pode ou não ser percetível.
  4. Desligamentos lentos do Oracle: se você monitorar o processo de desligamento, verá pausas que podem somar minutos de atrasos à medida que a E/S dNFS expira.
  5. Comportamento incorreto de cache de resposta dNFS em leituras que travarão um banco de dados.

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

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

Posso usar multipathing com Oracle dNFS e NFSv4.1?

Ao usar o NFSv4.1, o dNFS não funcionará com vários caminhos. Se você precisar de vários caminhos, terá que usar NFSv3. O dNFS requer todo clientID o cluster e sessionID entroncamento para que o NFSv4.1 funcione com vários caminhos, que os Arquivos NetApp do Azure não suportam. Como resultado, você experimentará um bloqueio durante a inicialização do dNFS

Próximos passos