Utilize armazenamento em blob montado no NFS com o Azure HPC Cache

Pode usar contentores de blob montados no NFS com o Azure HPC Cache. Leia mais sobre o suporte ao protocolo NFS 3.0 no armazenamento Azure Blob no site de documentação do armazenamento Blob.

O Azure HPC Cache usa armazenamento blob, habilitado por NFS, no seu tipo de alvo de armazenamento ADLS-NFS. Estes alvos de armazenamento são semelhantes aos alvos normais do NFS, mas também têm alguma sobreposição com os alvos normais do Azure Blob.

Este artigo explica estratégias e limitações que deve compreender ao usar alvos de armazenamento ADLS-NFS.

Deves também ler a documentação do blob do NFS, especialmente as secções que descrevem cenários compatíveis e incompatíveis, e dar dicas de resolução de problemas:

Compreender os requisitos de consistência

A HPC Cache requer forte consistência para destinos de armazenamento ADLS-NFS. Por defeito, o armazenamento de blobs habilitado por NFS não atualiza estritamente os metadados dos ficheiros, o que impede que o HPC Cache compare com precisão as versões dos ficheiros.

Para contornar esta diferença, o Azure HPC Cache desativa automaticamente a cache de atributos NFS em qualquer contentor de blob habilitado por NFS usado como destino de armazenamento.

Esta configuração mantém-se durante toda a vida útil do contentor, mesmo que a remova da cache.

Pré-carregamento de dados com protocolo NFS

Num contentor de blob com NFS, um ficheiro só pode ser editado pelo mesmo protocolo usado quando foi criado. Ou seja, se usar a API REST do Azure para preencher um contentor, não pode usar o NFS para atualizar esses ficheiros. Como o Azure HPC Cache só usa NFS, não pode editar ficheiros criados com a API Azure REST. (Saiba mais sobre problemas conhecidos com APIs de armazenamento de blobs)

Não é um problema para a cache se o teu contentor estiver vazio, ou se os ficheiros foram criados usando NFS.

Se os ficheiros no teu contentor foram criados com a API Azure Blob REST em vez de NFS, o Azure HPC Cache fica restrito a estas ações nos ficheiros originais:

  • Liste o ficheiro num diretório.
  • Leia o ficheiro (e guarde-o na cache para leituras subsequentes).
  • Exclua o arquivo.
  • Esvazie o ficheiro (trunque-o para 0).
  • Guarda uma cópia do ficheiro. A cópia é marcada como um ficheiro criado pelo NFS e pode ser editada usando NFS.

O Azure HPC Cache não consegue editar o conteúdo de um ficheiro criado usando REST. Isto significa que a cache não pode guardar um ficheiro alterado de um cliente de volta para o alvo de armazenamento.

É importante compreender esta limitação, porque pode causar problemas de integridade de dados se usar modelos de utilização de cache de leitura/escrita em ficheiros que não foram criados com NFS.

Tip

Saiba mais sobre cache de leitura e escrita em Compreender modelos de utilização da cache.

Escrever cenários de cache

Estes modelos de utilização de cache incluem cache de escrita:

  • Mais de 15% escreve
  • Mais de 15% de operações de escrita, verificando o servidor de apoio para ver se há alterações a cada 30 segundos
  • Quando as operações de escrita ultrapassam 15%, verifica alterações no servidor de suporte de dados a cada 60 segundos
  • Mais de 15% de operações de escrita, escrever de volta ao servidor a cada 30 segundos

Os modelos de utilização de cache de escrita devem ser usados apenas em ficheiros criados com NFS.

Se tentar usar cache de escrita em ficheiros criados por REST, as alterações nos ficheiros podem perder-se. Isto acontece porque a cache não tenta guardar as edições de ficheiros no contentor de armazenamento imediatamente.

Aqui está como tentar fazer cache das gravações em ficheiros criados por REST coloca os dados em risco:

  1. A cache aceita edições dos clientes e devolve uma mensagem de sucesso a cada alteração.

  2. A cache mantém o ficheiro alterado no seu armazenamento e espera por alterações adicionais.

  3. Após algum tempo, a cache tenta guardar o ficheiro alterado no contentor de back-end. Neste ponto, recebe uma mensagem de erro porque está a tentar escrever num ficheiro criado por REST com NFS.

    Já é tarde demais para informar a máquina cliente que as alterações não foram aceites, e a cache não tem forma de atualizar o ficheiro original. Portanto, as alterações dos clientes serão perdidas.

Leia cenários de cache

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

Estes modelos de utilização utilizam apenas cache de leitura:

  • Leia textos pesados e pouco frequentes
  • Os clientes escrevem no destino NFS, contornando a cache
  • Leitura intensiva, verificando o servidor de suporte a cada 3 horas

Pode usar estes modelos de utilização com ficheiros criados pela API REST ou pelo NFS. Quaisquer escritas NFS enviadas de um cliente para o contentor de back-end continuarão a falhar, mas falharão imediatamente e devolverão uma mensagem de erro ao cliente.

Um fluxo de trabalho de cache de leitura pode ainda envolver alterações de ficheiros, desde que estas não estejam armazenadas em cache. Por exemplo, os clientes podem aceder a ficheiros a partir do contentor mas escrever as alterações como um novo ficheiro, ou podem guardar ficheiros modificados noutro local.

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

Os contentores de blobs habilitados por NFS não suportam o Network Lock Manager (NLM), que é um protocolo NFS frequentemente utilizado para proteger ficheiros de conflitos.

Se o seu fluxo de trabalho NFS foi originalmente escrito para sistemas de armazenamento hardware, as suas aplicações clientes podem incluir pedidos NLM. Para contornar esta limitação ao mover o seu processo para armazenamento blob com NFS, certifique-se de que os seus clientes desativam o NLM quando montam a cache.

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

Otimize operações de escrita nos contentores habilitados para NFS com Cache HPC

O Azure HPC Cache pode ajudar a melhorar o desempenho numa carga de trabalho que inclui a escrita de alterações num ADLS-NFS alvo de armazenamento.

Note

Tens de usar o NFS para preencher o teu contentor de armazenamento ADLS-NFS se quiseres modificar os seus ficheiros através do Azure HPC Cache.

Uma das limitações descritas no artigo sobre Considerações de Desempenho de blobs com NFS é que o armazenamento ADLS-NFS não é muito eficiente a sobrescrever ficheiros existentes. Se usar o Azure HPC Cache com armazenamento de blob montado no NFS, o cache trata de reescritas intermitentes à medida que os clientes modificam um ficheiro ativo. A latência de escrever um ficheiro para o container de back-end fica oculta para os clientes.

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

Passos seguintes

  • Last updated on