Partilhar via

Perguntas Frequentes sobre NFS no Azure NetApp Files

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 mais 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?

Os Arquivos NetApp do Azure não oferecem suporte a NFSv4.2 nem a seus recursos auxiliares (incluindo operações de arquivo esparsas, atributos estendidos e rótulos de segurança). Embora você possa montar um volume NFS4.1 nos Arquivos NetApp do Azure com o protocolo NFSv4.2, o uso do NFSv4.2 não é suportado.

Os volumes dos Arquivos NetApp do Azure podem ser montados usando o protocolo NFSv4.2 de duas maneiras:

  • Especificando 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 para a versão NFS mais alta suportada permitida. Dependendo da distribuição Linux, isso pode resultar no NFSv4.2 sendo usado como o protocolo NFS mais alto disponível.

Muitos clientes podem ter problemas se não suportarem totalmente o NFSv4.2 ou a funcionalidade de atributos estendidos do NFSv4.2. Como o NFSv4.2 não é suportado com os Arquivos NetApp do Azure, quaisquer problemas com o NFSv4.2 estão fora do escopo de suporte. 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.

Para obter mais informações, consulte Compreender os protocolos NAS nos ficheiros Azure NetApp.

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 implementados em diferentes regiões
  • volumes distribuídos por diferentes zonas de disponibilidade dentro da mesma região

Se estiver a usar volumes regionais (sem zonas de disponibilidade) ou volumes dentro da mesma zona de disponibilidade, pode ser usado o mesmo caminho do ficheiro, no entanto o caminho do ficheiro deve ser único dentro de cada sub-rede delegada ou atribuído a subredes delegadas diferentes.

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 aquele período, o contrato de arrendamento do cliente será liberado.

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

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 .snapshot diretório nunca é visível para os 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.

O tempo de acesso será automaticamente atualizado ao ler ficheiros?

Não, o tempo de acesso não será atualizado ao ler ficheiros. Este comportamento garante acesso de baixa latência e alto desempenho aos seus dados.

Oracle dNFS

Existem patches Oracle necessários com o dNFS?

Importante

Os clientes que usam Oracle 19c e superior devem garantir que tenham aplicado a correção para o bug 32931941 da Oracle. A maioria dos pacotes de patches atualmente em uso pelos clientes Oracle *não* inclui este 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 a ser atualizado enquanto estava a ser 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. A base de dados congela quando ocorrem movimentos de endpoint de armazenamento backend.
  2. A base de dados fica inativa durante eventos de manutenção do serviço Azure NetApp Files.
  3. Breves interrupções do Oracle durante a operação normal, que podem ou não ser percetíveis.
  4. Desligamentos lentos do Oracle: se monitorizares o processo de encerramento, podes observar pausas que podem resultar em atrasos de minutos à medida que a E/S dNFS ultrapassa o tempo limite.
  5. Comportamento incorreto de cache de resposta dNFS em leituras que poderá travar um banco de dados.

Os patches incluem uma alteração na gestão de sessões dNFS e na cache de respostas 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 clientID e sessionID entroncamento a nível de cluster para que o NFSv4.1 funcione com múltiplos caminhos, o que não é suportado pelo Azure NetApp Files. Como resultado, você experimentará um bloqueio durante a inicialização do dNFS

Próximos passos

  • Last updated on