Usar o armazenamento de blobs montado em NFS com o Azure HPC Cache

Você pode usar contêineres de blob montados em NFS com o HPC Cache do Azure. Leia mais sobre o suporte ao protocolo NFS 3.0 no Armazenamento de Blobs do Azure no site de documentação do Armazenamento de Blobs.

O HPC Cache do Azure usa o armazenamento de blobs habilitado para NFS em seu tipo de destino de armazenamento ADLS-NFS. Esses destinos de armazenamento são semelhantes aos destinos de armazenamento NFS regulares, mas também têm alguma sobreposição com destinos regulares de Blob do Azure.

Este artigo explica estratégias e limitações que você deve entender ao usar o ADLS-NFS como destinos de armazenamento.

Você também deve ler a documentação do blob do NFS, especialmente estas seções que descrevem cenários compatíveis e incompatíveis, e dar dicas de solução de problemas:

Entender os requisitos de consistência

O HPC Cache requer uma consistência forte para destinos de armazenamento ADLS-NFS. Por padrão, o armazenamento de blobs habilitado para NFS não atualiza estritamente os metadados de arquivo, o que impede que o HPC Cache compare com precisão as versões do arquivo.

Para contornar essa diferença, o HPC Cache do Azure desabilita automaticamente o cache de atributo NFS em qualquer contêiner de blob habilitado para NFS usado como um destino de armazenamento.

Essa configuração persiste durante o tempo de vida do contêiner, mesmo se você removê-lo do cache.

Pré-carregar dados com o protocolo NFS

Em um contêiner de blob habilitado para NFS, um arquivo só pode ser editado pelo mesmo protocolo usado quando foi criado. Ou seja, se você usar a API REST do Azure para preencher um contêiner, não poderá usar o NFS para atualizar esses arquivos. Como o HPC Cache do Azure usa apenas o NFS, ele não pode editar nenhum arquivo que tenha sido criado com a API REST do Azure. (Saiba mais sobre problemas conhecidos com APIs de armazenamento de blobs)

Não será um problema para o cache se o contêiner estiver vazio ou se os arquivos foram criados usando NFS.

Se os arquivos em seu contêiner foram criados com a API REST do Blob do Azure em vez de NFS, o HPC Cache do Azure fica restrito a essas ações nos arquivos originais:

  • Liste o arquivo em um diretório.
  • Leia o arquivo (e mantenha-o no cache para leituras subsequentes).
  • Excluir o arquivo.
  • Deixe o arquivo vazio (reduza-o a zero).
  • Salve uma cópia do arquivo. A cópia é marcada como um arquivo criado pelo NFS e pode ser editada usando NFS.

O HPC Cache do Azure não pode editar o conteúdo de um arquivo que foi criado usando REST. Isso significa que o cache não pode salvar um arquivo alterado de um cliente de volta para o destino de armazenamento.

É importante entender essa limitação, pois ela pode causar problemas de integridade de dados se você usar modelos de uso de cache de leitura/gravação em arquivos que não foram criados com NFS.

Dica

Saiba mais sobre o cache de leitura e gravação em Noções básicas sobre modelos de uso de cache.

Cenários de cache de gravação

Esses modelos de uso de cache incluem cache de gravação:

  • Maior que 15% escritas
  • Maior que 15% gravações, verificando se há alterações no servidor de backup a cada 30 segundos
  • Mais de 15% de gravações, verificando o servidor de suporte para alterações a cada 60 segundos
  • Maior que 15% de gravações, grave de volta no servidor a cada 30 segundos

Modelos de uso de cache de escrita devem ser utilizados apenas para arquivos criados utilizando o NFS.

Se você tentar usar o cache de gravação em arquivos criados pelo REST, suas modificações nos arquivos poderão ser perdidas. Isso ocorre porque o cache não tenta salvar edições de arquivo no contêiner de armazenamento imediatamente.

Veja como tentar armazenar em cache as gravações em arquivos criados pelo REST compromete a segurança dos dados:

  1. O cache aceita edições de clientes e retorna uma mensagem de sucesso em cada alteração.

  2. O cache mantém o arquivo alterado em seu armazenamento e aguarda alterações adicionais.

  3. Depois que algum tempo tiver passado, o cache tentará salvar o arquivo alterado no contêiner de back-end. Neste ponto, ele receberá uma mensagem de erro porque está tentando gravar em um arquivo criado por REST com NFS.

    É tarde demais para informar ao computador cliente que suas alterações não foram aceitas e que o cache não tem como atualizar o arquivo original. Portanto, as alterações dos clientes serão perdidas.

Ler cenários de cache

Cenários de cache de leitura são apropriados para arquivos criados com NFS ou com a API REST do Blob do Azure.

Esses modelos de uso usam apenas o cache de leitura:

  • Ler gravações pesadas e pouco frequentes
  • Os clientes gravam no destino NFS, ignorando o cache
  • Leia pesado, verificando o servidor de backup a cada 3 horas

Você pode usar esses modelos de uso com arquivos criados pela API REST ou pelo NFS. Todas as gravações NFS enviadas de um cliente para o contêiner de back-end ainda falharão, mas falharão imediatamente e retornarão uma mensagem de erro ao cliente.

Um fluxo de trabalho de cache de leitura ainda pode envolver alterações de arquivo, desde que estas não sejam cacheadas. Por exemplo, os clientes podem acessar arquivos do contêiner, mas gravar suas alterações novamente como um novo arquivo ou salvar arquivos modificados em um local diferente.

Reconhecer limitações do NLM (Network Lock Manager)

Os contêineres de blob habilitados para NFS não dão suporte ao NLM (Network Lock Manager), que é um protocolo NFS comumente usado para proteger arquivos contra conflitos.

Se o fluxo de trabalho NFS foi originalmente gravado para sistemas de armazenamento de hardware, seus aplicativos cliente podem incluir solicitações NLM. Para contornar essa limitação ao mover seu processo para o armazenamento de blobs habilitado para NFS, verifique se os clientes desabilitam o NLM ao montar o cache.

Para desabilitar o NLM, use a opção -o nolock no comando mount dos seus clientes. Essa opção impede que os clientes solicitem bloqueios NLM e recebam erros em resposta. A nolock opção é implementada de forma diferente em sistemas operacionais diferentes; verifique a documentação do sistema operacional do cliente (man 5 nfs) para obter detalhes.

Simplificar gravações em contêineres habilitados para NFS com o HPC Cache

O HPC Cache do Azure pode ajudar a melhorar o desempenho em uma carga de trabalho que inclui a gravação de alterações em um destino de armazenamento ADLS-NFS.

Note

Você deve usar o NFS para preencher seu contêiner de armazenamento ADLS-NFS se quiser modificar seus arquivos por meio do Azure HPC Cache.

Uma das limitações descritas no artigo sobre considerações de desempenho em blob habilitado para NFS é que o armazenamento ADLS-NFS não é muito eficiente ao substituir arquivos existentes. Se você usar o HPC Cache do Azure com armazenamento de blobs montado em NFS, o cache manipulará regravações intermitentes à medida que os clientes modificam um arquivo ativo. A latência de gravar um arquivo no contêiner de back-end está oculta dos clientes.

Tenha em mente as limitações explicadas acima em Pré-carregar dados com o protocolo NFS.

Próximas Etapas 

  • Last updated on