Usar armazenamento de blob montado em NFS com o Cache HPC do Azure

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

O Cache HPC do Azure usa o armazenamento de blob 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 as estratégias e limitações que você deve entender ao usar destinos de armazenamento ADLS-NFS.

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

• Descrição geral das funcionalidades
• Considerações sobre desempenho
• Limitações e problemas conhecidos
• Procedimento de instruções e guia de solução de problemas

Compreender os requisitos de consistência

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

Para contornar essa diferença, o Cache HPC do Azure desabilita automaticamente o cache de atributos NFS em qualquer contêiner de blob habilitado para NFS usado como 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 NFS para atualizar esses arquivos. Como o Cache HPC do Azure usa apenas NFS, ele não pode editar nenhum arquivo que foi criado com a API REST do Azure. (Saiba mais sobre problemas conhecidos com APIs de armazenamento de blob)

Não é 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 de Blob do Azure em vez de NFS, o Cache HPC do Azure estará restrito a estas ações nos arquivos originais:

• Liste o arquivo em um diretório.
• Leia o arquivo (e mantenha-o no cache para leituras subsequentes).
• Exclua o arquivo.
• Esvazie o arquivo (trunce para 0).
• Salve uma cópia do arquivo. A cópia é marcada como um arquivo criado por NFS e pode ser editada usando NFS.

O Cache HPC 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 ao destino de armazenamento.

É importante entender essa limitação, porque 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.

Gorjeta

Saiba mais sobre cache de leitura e gravação em Compreender modelos de uso de cache.

Cenários de cache de gravação

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

• Mais de 15% de gravações
• Mais de 15% grava, verificando se há alterações no servidor de backup a cada 30 segundos
• Mais de 15% de gravações, verificando se há alterações no servidor de backup a cada 60 segundos
• Mais de 15% grava, grava de volta no servidor a cada 30 segundos

Os modelos de uso de cache de gravação devem ser usados somente em arquivos criados com NFS.

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

Veja como tentar armazenar gravações em cache em arquivos criados por REST coloca os dados em risco:

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

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

3. Após algum tempo, o cache tenta 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 dizer à máquina cliente que suas alterações não foram aceitas e o cache não tem como atualizar o arquivo original. Assim, as mudanças dos clientes serão perdidas.

Ler cenários de cache

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

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

• Ler textos pesados 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 por 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 arquivos, desde que eles não sejam armazenados em cache. Por exemplo, os clientes podem acessar arquivos do contêiner, mas gravar suas alterações novamente como um novo arquivo, ou podem salvar arquivos modificados em um local diferente.

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

Os contêineres de blob habilitados para NFS não suportam o Gerenciador de Bloqueio de Rede (NLM), que é um protocolo NFS comumente usado para proteger arquivos contra conflitos.

Se o fluxo de trabalho NFS foi originalmente escrito 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 blob habilitado para NFS, certifique-se de que seus clientes desativem o NLM quando montarem o cache.

Para desativar o NLM, use a opção -o nolock no comando dos mount 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 diferentes sistemas operacionais, verifique a documentação do seu sistema operacional cliente (man 5 nfs) para obter detalhes.

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

O Cache HPC 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.

Nota

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

Uma das limitações descritas no artigo Considerações de desempenho do blob habilitado para NFS é que o armazenamento ADLS-NFS não é muito eficiente na substituição de arquivos existentes. Se você usar o Cache HPC do Azure com armazenamento de blob 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 é ocultada dos clientes.

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

Próximos passos

• Saiba mais sobre os pré-requisitos de destino de armazenamento ADLS-NFS
• Criar uma conta de armazenamento de blob habilitada para NFS